Array Splitting का इतिहास

IT क्षेत्र का अधिकांश rote knowledge, विशेष रूप से SMB क्षेत्र का, 1990s के अंत में विभिन्न कारकों के आधार पर उभरा। सबसे बड़े कारक यह थे कि अचानक छोटे-से-छोटे businesses computerize होने की दौड़ में लग गए, Microsoft ने Windows NT 4 को इतना stable बना दिया था कि SMB IT के लिए एक standard base उपलब्ध हो गई, Internet युग अंततः स्थापित हो गया था और Microsoft ने certification और training programs शुरू किए जिसने industry में knowledge dissemination को नया रूप दे दिया। इन सभी बातों ने मिलकर नई training और best practices की आवश्यकता पैदा की और नई सोच, लेखन, documentation, training, best practices, rules of thumb आदि का एक बड़ा विस्फोट किया।

कुछ वर्षों तक लगभग पूरे क्षेत्र को एक ही छोटे knowledge set पर trained किया गया और कई rules of thumb de facto standards बन गए। उस समय का अधिकांश knowledge rote सीखा गया और mentor से intern तक एक ऐसे cycle में पारित किया गया जिसने 1998 के technical knowledge को 2012 की अप्रश्नित, stone-set प्रक्रियाओं में बदल दिया। उस समय यह प्रभावी था क्योंकि ये practices प्रासंगिक थीं, लेकिन वह पंद्रह साल पहले था – technology, economics, use cases और knowledge तब से काफी बदल चुके हैं।

इसका सबसे अच्छा उदाहरण था Microsoft SQL Server की प्रसिद्ध recommendation: operating system के लिए RAID 1, database files के लिए RAID 5 और logs के लिए एक और RAID 1। यह setup product के लगभग पूरे जीवनकाल में बना रहा और इतना प्रचारित हुआ कि यह SMB space में server design के लगभग सभी पहलुओं में फैल गया। Operating system के लिए RAID 1 और data के लिए RAID 5 का उपयोग इतना व्यापक है कि इसे अक्सर बिना किसी विचार के मान लिया जाता है कि यह उस समय क्यों recommend किया गया था।

आइए इतिहास की जांच करें और देखें कि R1/5/1 1998 में क्यों अच्छा था और आज क्यों नहीं होना चाहिए। कुछ perspective ध्यान में रखें – जब ये recommendations पहली बार आईं (1995 के आसपास) और आज के बीच का अंतर बहुत बड़ा है। मानसिक रूप से 1995 पर जाएं और उस समय के समकक्ष अंतर के बारे में सोचें। यह ऐसा होता जैसे पहले Apple ][ owners के लिए early Internet age में home computing की recommendations का उपयोग करना! 1978 में 8-bit home computer era अभी-अभी शुरू हो रहा था। Commodore अभी दो साल बाद अपना पहला home computer (VIC-20) release करने वाला था। Apple ][+ अभी एक साल दूर था। लोग analog cassette drives को storage के रूप में उपयोग करने लगने वाले थे। COBOL और Fortran ही केवल serious business languages थीं। मूल रूप से, अंतर अविश्वसनीय है। चीजें बदलती हैं।

पहले, हमें उन कारकों को देखना होगा जो 1990s के अंत में मौजूद थे और जिन्होंने हमारे historic setup की आवश्यकता बनाई।

1. Drives छोटी थीं, बहुत छोटी। एक बड़े database array में चार 2.1GB SCSI drives का R5 array हो सकता था जिसमें single array पर सिर्फ ~6GB usable storage होती थी। Parity RAID failure का failure domain छोटा था (URE fail rates जैसी चीजों की तुलना में।)
2. Drive connection technologies parallel और slow थीं। उस समय की hard drives आज की drives से थोड़ी ही धीमी थीं लेकिन connection technologies एक बड़ी bottleneck थीं। Bus bottlenecks कम करने के लिए traffic को split करना सामान्य था।
3. SCSI drive technology ही servers के लिए उपयोग की जाती थी। Server में PATA (जिसे उस समय IDE कहते थे) का उपयोग अकल्पनीय था।
4. Drives प्रति gigabyte महंगी थीं इसलिए capacity बनाए रखते हुए cost savings लगभग सभी businesses के लिए मुख्य मुद्दा था।
5. Filesystems नाजुक थीं और drives की तुलना में अधिक बार fail होती थीं।
6. Hardware RAID आवश्यक था और केवल basic RAID levels 1 और 5 सामान्यतः उपलब्ध थे। RAID 6 और RAID 10 अधिकांश businesses के लिए कई साल दूर थे। RAID 0 को छोड़ दिया गया क्योंकि इसमें कोई redundancy नहीं है।
7. Storage systems कभी-कभार ही servers के बीच shared होती थीं इसलिए access लगभग हमेशा एक single request queue को dedicated था।
8. Storage caches बहुत छोटे थे या मौजूद ही नहीं थे जिससे drive access limitations सीधे operating system पर पड़ती थीं। इसका मतलब था कि अलग-अलग read/write या random/sequential access mixes को handle करने के लिए अलग-अलग characteristics वाले अलग arrays होना।
9. Drive failure सामान्य था और storage system design की प्रमुख चिंता था।
10. अक्सर drive array size physical limitations द्वारा सीमित होती थी इसलिए array splitting के निर्णय अक्सर चुनाव से नहीं बल्कि आवश्यकता से लिए जाते थे।
11. उपरोक्त कारकों के संयोजन का मतलब था कि RAID 1 system के उन हिस्सों के लिए सबसे अच्छा था जहाँ छोटा size स्वीकार्य था और access highly sequential या write heavy था, और RAID 5 उन हिस्सों के लिए बेहतर था जहाँ capacity reliability से अधिक महत्वपूर्ण थी और access highly random और read heavy था।

मूल recommendations जारी होने के लगभग दो दशकों में, ये सभी कारक बदल गए हैं। कुछ मामलों में परिवर्तन cascading हैं जहाँ general use RAID 5 से general use RAID 10 पर जाने से दोनों common array types – RAID 1 और RAID 10 – समान access characteristics share करने लगे, इसलिए load type के आधार पर एक या दूसरे का उपयोग करने की आवश्यकता या इच्छा समाप्त हो गई।

1. Drives अब बड़ी हैं। जरूरत को squeeze करने के बजाय, हमारे पास आमतौर पर अतिरिक्त capacity है। एक terabyte से अधिक की single drives सामान्य हैं, यहाँ तक कि servers में भी। Parity के failure domains बड़े हैं (URE fail rates जैसी चीजों की तुलना में।)
2. Drive connections serial और तेज हैं। Drive connections अब bottleneck नहीं हैं।
3. SATA अब servers पर सामान्य है जो पहले जैसा नहीं था, URE के लिए संभावित risks को skew कर रहा है।
4. Capacity अब सस्ती है लेकिन performance और reliability अब खर्च की गई dollars के लिए मुख्य चिंताएं हैं।
5. Filesystems आज अत्यधिक robust हैं और filesystem failures array reliability की बड़ी तस्वीर में “background noise” हैं।
6. Hardware RAID और software RAID दोनों आज options हैं और उपलब्ध RAID levels में कई options हैं, लेकिन सबसे महत्वपूर्ण यह है कि RAID 10 ubiquitously उपलब्ध है।
7. Storage systems सामान्यतः shared हैं जिससे sequential access और भी कम सामान्य है।
8. Storage caches सामान्य हैं और अक्सर बहुत बड़े हैं। 512MB और 1GB caches आज सामान्य माने जाते हैं – 1995 के कई arrays आज RAID controller की memory में पूरी तरह fit हो सकते हैं। Storage capacity की तुलना में caches तेजी से बढ़ने और पिछले दो वर्षों में storage में L2 cache के रूप में solid state drives के जुड़ने के साथ, छोटे businesses के लिए भी यह संभव है कि databases और अन्य performance sensitive applications पूरी तरह cache से चलें।
9. Drive failure असामान्य है और storage system design के लिए मामूली चिंता का विषय है (अन्य failure types की तुलना में।)
10. Drive array size शायद ही कभी physical limitations द्वारा सीमित होती है।
11. RAID 1 और RAID 10 का आज के principle array types के रूप में उपयोग का मतलब है कि performance tuning के लिए अलग-अलग array levels का उपयोग करने का कोई फायदा नहीं है।

ये कारक इस बात पर प्रकाश डालते हैं कि 1995 का split array system उस समय क्यों उचित था और आज क्यों नहीं है। OBR10, जो आज का standard है, उस समय उपलब्ध और cost prohibitive नहीं था। RAID 5 1995 में अपेक्षाकृत safe था, लेकिन आज नहीं। Decision process में शामिल लगभग हर कारक पिछले सत्रह वर्षों में नाटकीय रूप से बदल गया है और SSD के अधिक सामान्य होने, auto-tiering, और बड़े caches और pure SSD storage systems के साथ यह बदलता रहेगा।

पिछले दो दशकों में storage design में बदलाव उन खतरों को भी उजागर करता है जो IT को तब face करना पड़ता है जब क्षेत्र का एक बड़ा हिस्सा, engineering में सामान्य रूप से, basic “rules of thumb” या “best practices” को आवश्यक रूप से underlying principles को समझे बिना सीखता है। पारंपरिक mechanical या civil engineering के विपरीत जहाँ करियर के दौरान एक बार या शायद कभी नहीं नई advances और significant factor changes हो सकती हैं, IT अभी भी इतनी तेजी से बदलती है कि करियर के दौरान basic rules of thumb के पूर्ण “rethinks” कई बार आवश्यक होते हैं। शायद वार्षिक नहीं, लेकिन प्रति दशक एक बार या उससे अधिक लगभग हमेशा आवश्यक होता है।

Uniprocessing से multithreaded architectures की ओर वर्तमान बदलाव एक और इसी तरह का, महत्वपूर्ण परिवर्तन है जिसके लिए IT क्षेत्र को system design को संभालने के तरीके को पूरी तरह से बदलना होगा।