एक बड़ा RAID 10 – Server Storage में एक नया मानक

1990 के दशक के अंत में एक नए server बनाने का सामान्य नियम था कि operating system को अपने छोटे, अलग RAID 1 array पर रखें और applications तथा data को एक अलग RAID 5 array में रखें। यह कई कारणों से किया जाता था, जिनमें से कई अब समय के साथ भुला दिए गए हैं। मुख्य कारण यह थे कि storage capacity बेहद महंगी थी, disk छोटी थीं, filesystem नियमित रूप से खराब होते थे और physical hard drive अन्य प्रकार की विफलताओं की तुलना में बहुत अधिक दर से fail होती थीं। लोगों को physical hard drive failures से बचाने, filesystem corruption से सुरक्षा और अपनी जरूरतों के लिए पर्याप्त capacity प्राप्त करने की आवश्यकता थी।

आज storage का परिदृश्य बदल गया है। Filesystem अविश्वसनीय रूप से मजबूत हैं और filesystem से ही होने वाला corruption लगभग अनसुना हो गया है और journalling जैसी technologies की बदौलत, इसे लगभग हमेशा जल्दी और प्रभावी ढंग से ठीक किया जा सकता है जिससे end users के data loss की रक्षा होती है। आज लगभग कोई भी filesystem corruption की चिंता नहीं करता।

आधुनिक filesystem पहले की तुलना में कहीं अधिक capacity को संभाल सकते हैं। 1990 के दशक के अंत और 2000 के दशक की शुरुआत में ऐसा होना असामान्य नहीं था कि drive array को किसी भी single filesystem से बड़ा बनाना आसान था। आज यह उचित रूप से वैसा नहीं है क्योंकि सभी सामान्य filesystem कम से कम कई terabytes और अक्सर petabytes, exabytes या उससे अधिक data को संभाल सकते हैं।

Hard drive 1990 के दशक के अंत की तुलना में कहीं अधिक विश्वसनीय हैं। पूरी drive के fail होने की दर बहुत कम है, यहां तक कि कम खर्चीली drives में भी। इतनी कम कि array failures (पूरे RAID array में data loss) अब primarily failing arrays की चिंता करती है, न कि hard drives की विफलता की। हम अब hard drives को बेतरतीब ढंग से नहीं बदलते। बड़े arrays के लिए यह असामान्य नहीं है कि वे अपने पूरे जीवनकाल में एक भी drive खोए बिना चलें।

Capacities में नाटकीय रूप से वृद्धि हुई है। 4.3GB hard drives के बजाय अब हम 3TB drives install कर रहे हैं। पंद्रह साल से भी कम समय पहले की तुलना में एक single spindle पर लगभग एक हजार गुना अधिक capacity।

ये कारक मिलकर server storage design के लिए एक नाटकीय रूप से अलग दृष्टिकोण की आवश्यकता पैदा करते हैं और storage design करते समय शुरुआत के बारे में "rule of thumb" में बदलाव लाते हैं।

पुराने दृष्टिकोण को RAID 1 + RAID 5 के रूप में लिखा जा सकता है। RAID 1 space operating system के लिए उपयोग किया जाता था जबकि RAID 5 space, जो presumably बहुत बड़ा था, data और applications के लिए उपयोग किया जाता था। इस design ने दो storage concerns को विभाजित किया, operating system की सुरक्षा में अधिकतम प्रयास लगाया (जो disaster की स्थिति में recover करना बहुत कठिन था और जिस पर data accessibility के लिए निर्भर था) को अत्यधिक विश्वसनीय RAID 1 पर रखा। कम खर्चीला RAID 5, जबकि कुछ अधिक जोखिम भरा था, आमतौर पर data के लिए चुना जाता था क्योंकि अधिकांश मामलों में RAID 1 पर data store करने की लागत बहुत अधिक थी। यह उस समय समझ में आने वाला tradeoff था।

आज, हमारी बहुत अलग चिंताओं के साथ, एक नए दृष्टिकोण की आवश्यकता है, और इस नए दृष्टिकोण को "One Big RAID 10" के रूप में जाना जाता है – यानी एक single, बड़ा RAID 10 array जिसमें operating system, applications और data सभी एक साथ store होते हैं। बेशक, यह केवल हम इसे handy बनाने के लिए कहते हैं, एक ऐसी प्रणाली में जहां single disk से परे performance या capacity की जरूरत नहीं है वहां हम "One Big RAID 1" कहेंगे, लेकिन बहुत से लोग RAID 1 को RAID 10 समूह में शामिल करते हैं इसलिए पूर्व कहना आसान है।

और भी सुविधाजनक रूप से, हम इसे OBR10 के रूप में संक्षिप्त करते हैं।

क्योंकि storage की लागत काफी कम हो गई है और premium में होने के बजाय आज आमतौर पर प्रचुर मात्रा में उपलब्ध है, क्योंकि filesystem अविश्वसनीय रूप से विश्वसनीय हैं, क्योंकि RAID 1 और RAID 10 समान performance characteristics share करते हैं और क्योंकि non-disk failure triggered array failures background noise से data loss के प्राथमिक कारणों की ओर स्थानांतरित हो गई हैं, RAID 10 की ओर और array splitting को समाप्त करने की ओर जाना नया मानक दृष्टिकोण बन गया है।

RAID 10 के साथ हमारे पास अब वह highly available और resilient storage है जो पहले केवल operating system के लिए रखी जाती थी, जो हमारे सभी data के लिए उपलब्ध है। हमें सभी data के लिए mirrored RAID performance का लाभ और extra spindles का लाभ मिलता है। हमें बेहतर drive capacity utilization और उस बेहतर utilization पर आधारित performance मिलती है।

Databases के साथ सामान्यतः की जाने वाली log files की पारंपरिक splitting (कुख्यात RAID 1 + RAID 5 + RAID 1 दृष्टिकोण) भी अब आवश्यक नहीं है क्योंकि RAID 10 सभी data में optimum performance characteristics बनाए रखता है। RAID 10 के साथ हम उन लगभग सभी कारकों को समाप्त कर देते हैं जो कभी हमें arrays को split करने के लिए प्रेरित करते थे।

एकमात्र महत्वपूर्ण कारक, जिसका उल्लेख नहीं किया गया है, जिसके लिए split arrays को पारंपरिक रूप से फायदेमंद माना जाता था, वह है access contention – विभिन्न processes की एक ही समय में disk के विभिन्न हिस्सों तक पहुंच की आवश्यकता जिससे drive head कम आदर्श pattern में घूमता है और drive performance कम होती है। 1990 के दशक के अंत में जब पुराना rule of thumb विकसित हुआ था तब Contention एक बड़ी बात थी।

आज, drive contention अभी भी मौजूद है लेकिन large RAID caches के उपयोग से इसे काफी हद तक कम किया गया है। 90 के दशक के अंत में drive caches कुछ megabytes थे या अक्सर अनुपस्थित। आज 256MB एक tiny cache है और average servers में केवल RAID card पर 1-2GB cache के साथ deploy किए जाते हैं। कुछ systems memory cache के अतिरिक्त secondary cache जोड़ने के लिए additional solid state drive based caches को integrate करना शुरू कर रहे हैं। ये आसानी से सैकड़ों gigabytes के अत्यंत high speed cache जोड़ सकते हैं जो लगभग किसी भी spindle operation को contention की चिंता करने से buffer कर सकते हैं। इसलिए contention की समस्या को वर्षों से अन्य तरीकों से हल किया गया है लेकिन, अन्य technology changes की तरह, effectively हमें arrays को split करने की आवश्यकता वाली पारंपरिक चिंताओं से मुक्त कर दिया है।

Array contention की तरह, 1990 के दशक के अंत में arrays splitting का एक और बहुत कम सामान्य कारण उस युग की SCSI और ATA technologies की सीमाओं के कारण communications bus performance में सुधार करना था। इन्हें भी, आधुनिक arrays में serial communications mechanisms, SAS और SATA में जाने के साथ समाप्त कर दिया गया है। हम अब प्रत्येक array के लिए single bus की capacity तक सीमित नहीं हैं और पहले की तुलना में बहुत अधिक लचीलेपन के साथ बहुत बड़े हो सकते हैं। Bus contention लगभग समाप्त हो गया है।

यदि सुरक्षा के लिए space split करने की आवश्यकता है, जैसे log file growth, तो यह physical array splitting के बजाय partitioning के माध्यम से प्राप्त किया जा सकता है। सामान्यतः आप partitioning को minimize करना चाहेंगे क्योंकि यह overhead बढ़ाता है और drives की खुद को tune करने की क्षमता कम करता है, लेकिन ऐसे मामले हैं जहां यह बेहतर दृष्टिकोण है। लेकिन इसके लिए यह आवश्यक नहीं है कि underlying physical storage पारंपरिक रूप से जैसी विभाजित हो। Partitioning से भी बेहतर, जब उपलब्ध हो, logical volume management है जो partitions की सीमाओं के बिना partition-जैसे separations बनाता है।

तो अंत में, server storage के लिए नया rule of thumb है "One Big RAID 10।" कोई और RAID 5 नहीं, कोई और array splitting नहीं। यह reliability, performance, ease of management और moderate cost effectiveness के बारे में है। सभी rules of thumb की तरह, यह हर एकल instance पर लागू नहीं होता, लेकिन यह पुराने मानक की तुलना में बहुत अधिक व्यापक रूप से लागू होता है। RAID 1 + RAID 5, एक मानक के रूप में, हमेशा कुछ अवांछनीय के साथ "काम चलाने" और एक बुरी स्थिति से सर्वोत्तम बनाने का प्रयास था। OBR10 ऐसा नहीं है। नया मानक एक वांछित मानक है – यह वास्तव में हम जैसे चलाना चाहते हैं, न कि कुछ जिसके साथ हम "फंसे" हैं।

किसी नए server के लिए storage design करते समय, OBR10 से शुरुआत करें और केवल तभी इससे दूर जाएं जब यह specifically आपकी technology needs को पूरा नहीं करता। आपको OBR10 का उपयोग करने को justify करने की कभी आवश्यकता नहीं होनी चाहिए, केवल इसे न उपयोग करने को justify करना होगा।