धीमी OS Drives, तेज़ Data Drives

वर्षों में मैंने पाया है कि लोग अक्सर operating system partition के लिए high performance, highly reliable data storage की ओर गलती करते हैं लेकिन critical data stores के लिए slow, “cost effective” storage चुनते हैं। मैं हैरान हूँ कि यह कितनी बार होता है और अब, hypervisors के आगमन के साथ, मैं वही व्यवहार वहाँ भी दोहराते देख रहा हूँ – पहले से मौजूद समस्याओं को बढ़ाते हुए।

आज कई systems में हम केवल system के सभी components द्वारा shared एक single storage array से deal करते हैं। इन मामलों में हम अपने storage system performance को misbalance करने की समस्या का सामना नहीं करते। यह इस approach का एक बड़ा फायदा है और एक प्रमुख कारण है कि यह इतना highly recommended क्यों है। सभी performance एक shared pool में है और जिन components को performance की आवश्यकता है उनकी उस तक पहुँच है।

कई मामलों में, चाहे increased performance या reliability design के प्रयास में हो या technical necessity से, मैं पाता हूँ कि लोग अपने storage arrays को अलग कर रहे हैं और hypervisors और operating systems को एक array पर और data को दूसरे पर रख रहे हैं। लेकिन जो मुझे चौंकाता है वह यह है कि hypervisor या operating system के लिए dedicated arrays अक्सर capacity में staggeringly large और performance में extremely high होती हैं – अक्सर 15,000 RPM spindles या यहाँ तक कि solid state drives का भारी खर्च पर उपयोग करते हुए। लगभग हमेशा RAID 1 में (जैसा कि 1998 के common standards के अनुसार।)

यहाँ जो समझना ज़रूरी है वह यह है कि operating systems का खुद effectively कोई storage IO requirements नहीं है। थोड़ी सी है, ज़्यादातर system logging के लिए, लेकिन यही सब जो चाहिए वह है। Operating system partitions लगभग पूरी तरह से static हैं। Required components memory में load होते हैं, ज़्यादातर boot time पर, और फिर उन्हें access नहीं किया जाता। यहाँ तक कि उन मामलों में जहाँ logging की आवश्यकता होती है, कई बार ये logs एक central logging system को भेजे जाते हैं न कि system storage area पर जिससे वह ज़रूरत कम या यहाँ तक कि पूरी तरह समाप्त हो जाती है।

Hypervisors के साथ यह effect और भी extreme है। चूँकि hypervisors पारंपरिक operating systems की तुलना में बहुत lighter और कम robust होते हैं, वे embedded systems की तरह behave करते हैं और कई मायनों में, वास्तव में कई मामलों में embedded systems हैं। Hypervisors system boot time पर memory में load होते हैं और कुछ अवसरों पर logging को छोड़कर जब एक system चल रहा होता है तो उनके media की almost never again ज़रूरत होती है। क्योंकि hypervisors physical size में छोटे होते हैं यहाँ तक कि एक full hypervisor को storage से completely read करने के लिए आवश्यक कुल समय बहुत slow media पर भी बहुत कम होता है, क्योंकि कुल size बहुत छोटी है।

इन कारणों से, operating systems के लिए storage performance का बहुत कम या कोई consequence नहीं है और विशेष रूप से hypervisors के लिए। Fast storage और slow storage के बीच अंतर वास्तव में केवल system boot time को impact करता है जहाँ एक second या तीस seconds का अंतर शायद ही कभी notice किया जाएगा, यदि बिल्कुल भी। एक system के startup के दौरान कभी-कभी कुछ extra seconds कब notice करेगा और अधिकांश मामलों में, startups दुर्लभ events हैं जो एक planned maintenance window के दौरान automated, routine system reboot के दौरान सप्ताह में अधिक से अधिक एक बार होते हैं या बहुत कम, कभी-कभी केवल एक बार हर कई वर्षों में, उन systems के लिए जो केवल emergencies में offline लाए जाते हैं। यहाँ तक कि सबसे slow conceivable storage system इस role के लिए आवश्यकता से कहीं faster है।

Slow storage भी आम तौर पर system logging activities के लिए आवश्यकता से कई गुना faster है। उन दुर्लभ मामलों में जहाँ logging बहुत intense है हमारे पास इस समस्या से निपटने के कई choices हैं। यहाँ सबसे obvious और common solution यह है कि logs को operating system या hypervisor द्वारा उपयोग किए जाने वाले drive array के अलावा किसी अन्य drive array पर भेजा जाए। यह एक बहुत easy solution है और ultimately उन मामलों में बहुत practical है जहाँ यह warranted है। दूसरा common और highly useful solution यह है कि simply local device पर logs रखने से refrain किया जाए और उन्हें एक remote log collection utility जैसे Splunk, Loggly या ELK पर भेजा जाए।

दूसरी major concern जो अधिकांश लोगों को अपने operating systems और hypervisors के आसपास होती है वह reliability है। इन अपेक्षाकृत unimportant aspects पर अधिक efforts focus करना common है बजाय often irreplaceable data के। हालाँकि, operating systems और hypervisors को ज़रूरत पड़ने पर fresh installs और ज़रूरत पड़ने पर manual reconfiguration का उपयोग करके scratch से आसानी से rebuilt किया जा सकता है। जो details खो सकती हैं वे आम तौर पर recreate करने में अपेक्षाकृत trivial हैं।

इसका मतलब यह नहीं है कि इन system filesystems का backup नहीं लिया जाना चाहिए, निश्चित रूप से उन्हें (अधिकांश मामलों में) backup लिया जाना चाहिए। लेकिन बस इस मामले में यदि backups भी fail हो जाएं, यह कम ही होता है कि किसी OS partition या filesystem का loss वास्तव में tragedy है बल्कि केवल एक inconvenience। लगभग सभी मामलों में original data तक पहुँच के बिना recover करने के तरीके हैं, जब तक कि “data” filesystem अलग हो। और operating systems और hypervisors की nature के कारण, change दुर्लभ है इसलिए backups आम तौर पर कम frequent हो सकते हैं, संभवतः केवल तब manually triggered जब updates लागू किए जाते हैं!

DevOps और Cloud computing spaces में कई modern systems के साथ operating systems और hypervisor filesystems को पूरी तरह से disposable मानना बहुत common हो गया है क्योंकि वे remotely एक system image या configuration management system द्वारा defined किए जाते हैं। इन मामलों में, जो अधिक से अधिक common होते जा रहे हैं, data protection या backups की कोई आवश्यकता नहीं है क्योंकि पूरा system किसी विशेष interaction के बिना, almost instantly, recreate होने के लिए designed है। System पूरी तरह से self-replicating है। यह system filesystem protection की आवश्यकता को और trivialize करता है।

एक साथ लेकर, performance के आसपास की कमी और protection और reliability के आसपास की कमी, जो primarily simple recreation के माध्यम से handle की जाती है, और हमारे पास एक system filesystem है जिसकी बहुत अलग needs हैं जो हम आमतौर पर मानते हैं। इसका मतलब यह नहीं है कि हमें अपने storage के साथ reckless होना चाहिए, हम अभी भी एक system चल रहा होने पर storage failure से बचना चाहते हैं और unnecessarily rebuild करना एक waste of time और resources है यहाँ तक कि अगर यह catastrophic साबित न हो। इसलिए एक careful balance बनाना महत्वपूर्ण है।

यह, निश्चित रूप से, इन्हीं कारणों से है कि data के समान storage array पर operating system या hypervisor शामिल करना अब common practice है – क्योंकि data files तक access के साथ ही system files तक storage access की बहुत कम या कोई आवश्यकता नहीं है, इसलिए हम OS के लिए fast boot times और data access times पर कोई adverse impact नहीं होने का great synergy प्राप्त करते हैं एक बार system online होने के बाद। यह primary means है जिसके द्वारा आज system designers storage के efficient use की आवश्यकता को tackle करते हैं।

जब operating system या hypervisor को data रखने वाले arrays से अलग किया जाना चाहिए जो मyriad कारणों से अभी भी हो सकता है, हम आम तौर पर कम लागत पर reasonable reliability प्राप्त करना चाहते हैं। Traditional storage (local disks) का उपयोग करते समय इसका मतलब है operating system storage के लिए small, slow, low cost spinning drives का उपयोग करना, आम तौर पर simple RAID 1 configuration में। एक real world example 5400 RPM “eco-friendly” SATA drives का उपयोग possible smallest sizes में है। ये कम power draw करती हैं और acquire करने के लिए बहुत inexpensive हैं। SSDs और high speed SAS drives से बचा जाएगा क्योंकि वे irrelevant protection के लिए premium cost करते हैं और पूरी तरह से wasted performance के लिए।

कम traditional storage में कई systems के लिए low priority storage को shared, slow arrays पर consolidate करने के लिए एक low cost, high density SAN का उपयोग करना common है जो replicated नहीं हैं। यह केवल बड़े environments में effective है जो additional architectural design को justify कर सकते हैं और storage consolidation process में necessary cost savings बनाने के लिए enough density achieve कर सकते हैं लेकिन बड़े environments में यह अपेक्षाकृत आसान है। SAN boot devices cost savings के लिए कई servers पर very low cost arrays का leverage कर सकते हैं। Virtual space में इसका मतलब OS virtual disks के लिए उपयोग किया गया एक low performance datastore और data virtual disks के लिए एक अन्य, high performance pool हो सकता है। इसका boot SAN strategy के समान effect होगा लेकिन अधिक modern setting में और इसे accomplish करने के लिए hood के नीचे SAN architecture का आसानी से leverage कर सकता है।

अंत में, और सबसे dramatically, hypervisors के साथ एक general rule of thumb है कि उन्हें traditional storage के बजाय SD cards या USB thumb drives पर install किया जाए क्योंकि उनकी performance और reliability needs traditional operating systems की तुलना में भी बहुत कम हैं। Normally यदि इस nature का कोई drive चल रहे system के दौरान fail हो जाए तो यह actually बिना किसी समस्या के running रहेगा क्योंकि drive को initially system boot करने के बाद कभी उपयोग नहीं किया जाता। केवल reboot के दौरान कोई issue मिलेगा और, उस समय, एक backup boot device का उपयोग किया जा सकता है जैसे कि एक secondary SD card या USB stick। यह VMware vSphere के लिए official recommendation है, अक्सर Microsoft representatives द्वारा HyperV के लिए recommended है और HyperV के OEM vendors के माध्यम से officially supported है और Xen, XenServer और KVM systems के लिए अक्सर recommended है, लेकिन इतने broadly supported नहीं। Hypervisor storage के लिए SD cards या USB drives का उपयोग effectively एक virtualization server को एक embedded system बना देता है। जबकि यह system administrators को unnatural लग सकता है जो traditionally disks को servers के लिए एक necessity के रूप में सोचने के आदी हैं, यह याद रखना महत्वपूर्ण है कि enterprise class, highly critical systems जैसे routers और switches decades तक चलते हैं और same reasons के लिए exact same strategy का उपयोग करते हैं।

SD cards या USB drives के साथ इस embedded style mode में hypervisors के लिए एक common strategy यह है कि दो ऐसे devices हों, जो actually एक SD card और एक USB drive हो सकते हैं, प्रत्येक में hypervisor की एक copy हो। यदि एक device fail हो जाता है, तो दूसरे device पर booting करना एक traditional RAID 1 system जितना लगभग प्रभावी है। लेकिन अधिकांश traditional RAID 1 setups के विपरीत, हमारे पास system updates का एक समय में केवल एक boot device को update करके और दूसरे boot device को update करने से पहले process को test करके testing का अपेक्षाकृत आसान means भी है जिससे हमारे पास एक reliable, well tested fall back है यदि कोई version update गलत हो जाए। यह process actually large UNIX RISC systems पर common था जहाँ boot devices अक्सर local software RAID 1 sets थे जो एक similar practice को support करते थे, विशेष रूप से AIX और Solaris circles में common।

यह भी ध्यान दिया जाना चाहिए कि जबकि यह approach अधिकांश hypervisor scenarios के लिए best practice है, actually कोई कारण नहीं है कि इसे full operating system filesystems पर भी क्यों नहीं लागू किया जा सकता, सिवाय इसके कि यह अक्सर अधिक काम होता है। कुछ OSes, विशेष रूप से Linux और BSD एक embedded fashion में install होने में बहुत adept हैं और SD card या USB drive पर installation के लिए थोड़ी planning के साथ आसानी से adapted किए जा सकते हैं। यह approach बिल्कुल भी common नहीं है लेकिन कोई technical कारण नहीं है कि right circumstances में, यह एक excellent approach क्यों नहीं होगी सिवाय इस fact के कि लगभग कभी नहीं एक OS को physical hardware पर install किया जाना चाहिए बजाय एक hypervisor के ऊपर। उन मामलों में जहाँ physical installs आवश्यक हैं तो यह approach अत्यधिक valid है।

Storage systems के लिए design और planning करते समय, यह ध्यान रखें कि जब system running हो तो read और write patterns वास्तव में कैसे दिखेंगे। और याद रखें कि storage कई traditional guidelines develop होने के बाद से काफी dramatically बदल गई है और उन्हें develop करने के लिए उपयोग किए गए सभी knowledge आज उतने ही रूप से लागू नहीं होते। सोचें न केवल कि कौन से storage subsystems storage performance का उपयोग करने की कोशिश करेंगे बल्कि वे एक दूसरे के साथ कैसे interact करेंगे (उदाहरण के लिए, क्या दो systems कभी एक ही समय पर storage access request नहीं करते या क्या वे regularly conflict करेंगे) और उनकी access performance महत्वपूर्ण है या नहीं। सामान्य operating system functions एक database server पर exceedingly slow हो सकते हैं बिना negative impact के, जो मायने रखता है वह केवल वह speed है जिस पर database accessed हो सकता है। Application binaries तक access भी अक्सर irrelevant होती है क्योंकि वे भी, एक बार memory में load होने के बाद, वहाँ बने रहते हैं और केवल memory speed ongoing performance को impact करती है।

इसमें से कुछ भी यह suggest करने के लिए नहीं है कि OS और data storage subsystems को एक दूसरे से अलग करना advised है, यह अक्सर नहीं है। मैंने पहले लिखा है कि इन subsystems को consolidate करना काफी अक्सर best course of action है और यह अभी भी सच है। लेकिन ऐसे कई reasonable cases भी हैं जहाँ certain storage needs को एक दूसरे से splitting करना sense बनाता है, अक्सर large scale systems के साथ deal करते समय जहाँ हम certain needs के लिए high cost storage और अन्य needs के लिए low cost storage dedicating करके cost कम कर सकते हैं और यह उन मामलों में है जहाँ मैं demonstrate करना चाहता हूँ कि operating systems और hypervisors को सबसे extreme cases को छोड़कर performance और reliability दोनों के संदर्भ में lowest priority माना जाना चाहिए।