Virtual अंडे और टोकरियां

छोटे व्यवसायों के IT professionals से बात करते समय, virtualization deploy करने में हिचकिचाहट का एक प्रमुख कारण जो सामने आता है वह है “सभी अंडे एक टोकरी में मत रखो।”

मैं देख सकता हूं यह चिंता कहां से आती है। Virtualization कई guest operating systems को एक single physical system में contain करने की अनुमति देता है जो hardware failure की स्थिति में, उस पर रहने वाले सभी guest systems को एक साथ, एक ही बार में fail कर देता है। यह बुरा लगता है, लेकिन शायद यह उतना बुरा नहीं है जितना हम पहले मान लेते हैं।

अंडों और टोकरियों की idiom का विचार यह है कि हमें अपने सभी resources को एक साथ जोखिम में नहीं डालना चाहिए। यह generally investing पर लागू किया जाता है, investors को diversify करने और bonds, stocks, funds और commodities जैसी कई अलग-अलग companies और types of securities में invest करने के लिए प्रोत्साहित करता है। अंडों (या पैसे) के मामले में हम एक interchangeable commodity के बारे में बात कर रहे हैं। एक अंडा दूसरे जितना अच्छा है। अंडों का एक set naturally redundant है।

यदि हमारे पास एक दर्जन अंडे हैं और हम छह तोड़ देते हैं, तो हम अभी भी एक omelette बना सकते हैं, शायद एक छोटी, लेकिन हम अभी भी खा सकते हैं। एक छोटी omelette खाना likely एक बड़ी जितना nearly satisfying है – हम किसी भी case में भूखे नहीं रहेंगे। अपने already redundant अंडों को multiple baskets में रखना हमें अपनी bets hedge करने की अनुमति देता है। हां, दो baskets ले जाने का मतलब है कि हमारे पास किसी एक पर ध्यान देने का कम समय है इसलिए यह कुछ अंडों को खोने का risk बढ़ाता है लेकिन सभी अंडों को खोने की संभावना कम करता है। अंडों के case में, यह वास्तव में एक wise proposition है। इसी तरह, अपनी retirement की तैयारी करने का एक smart तरीका।

यह theory, क्योंकि इसे careful analysis या उचित समझ के बिना idiom के रूप में दोहराया जाता है, फिर server virtualization जैसे unrelated areas पर लागू की जाती है। Servers, हालांकि, अंडों की तरह नहीं हैं। Servers, विशेष रूप से छोटे businesses में, शायद ही कभी interchangeable commodities होते हैं जहां usual twelve के बजाय छह का काम करना काफी हो। आमतौर पर servers प्रत्येक एक unique role निभाते हैं और सभी business के functioning के लिए relatively critical होते हैं। यदि एक server critical नहीं है तो यह पहले स्थान पर खुद को acquire और maintain करने की लागत को justify करने में unlikely है और इसलिए संभवतः exist नहीं करेगा। जब servers interchangeable होते हैं, जैसे एक large, stateless web farm या compute cluster में, तो उन्हें इस तरह configure किया जाता है जो single physical box की confines से परे capacity expand करने के साधन के रूप में होता है और इसलिए इस discussion के scope से बाहर आते हैं।

Business में IT services आमतौर पर, कम से कम कुछ हद तक, एक "chain dependency" होती हैं। यानी, वे interdependent हैं और एक single service का loss अन्य services को impact कर सकती है या तो क्योंकि वे technically interdependent हैं (जैसे एक line of business application database पर dependent है) या क्योंकि वे workflow interdependent हैं (जैसे एक office worker को email से जानकारी के साथ edit करने के लिए file server का काम करना जरूरी है जबकि phone या instant messenger पर changes discuss कर रहे हों।) इन cases में, email, network authentication या file services जैसी एक single key service का loss एक disproportionate working ability loss create कर सकता है। यदि दस key services हैं और एक down हो जाती है, तो company productivity IT services perspective से likely दस percent से बहुत अधिक drop करती है, extreme cases में possibly near one hundred percent। यह हमेशा सच नहीं होता, कुछ unique cases में workers एक lost service को effectively "work around" कर पाते हैं, लेकिन यह बहुत असामान्य है। भले ही लोग काम करते रह सकें, वे likely usual से बहुत कम productive हैं।

Physical servers के साथ व्यवहार करते समय, प्रत्येक server अपना own point of failure represent करता है। इसलिए यदि हमारे पास दस servers हैं, तो हमारे पास उन्हीं में से केवल एक server होने की तुलना में outage की संभावना दस गुना अधिक है। हम जो प्रत्येक server जोड़ते हैं वह अपना risk लेकर आता है। यदि प्रत्येक failure का outage factor 2.5 है – यानी business को financially, say, एक दिन के लिए पच्चीस percent revenue impact करना – तो एक दशक में हमारा total average impact ढाई total site outages के equivalent है। मैं यहां factors और averages की concept का उपयोग इसे आसान बनाने के लिए करता हूं, average outage की length या impact को determine करना आवश्यक नहीं है क्योंकि हमें केवल scenarios की तुलना करने के लिए relative impact determine करना है। यह केवल specific figures की आवश्यकता के बिना एक event type की cumulative outage financial impact को दूसरे से compare करने का एक साधन है – यह आपको यह determine करने में मदद नहीं करता कि आपका spend क्या होना चाहिए, बस relative reliability।

Virtualization के साथ हमारे पास consolidate करने की obvious ability है। इस example में हम यह मान लेंगे कि हम इन सभी दस existing servers को एक single server में collapse कर सकते हैं। जब हम यह करते हैं तो हम अक्सर "all our eggs in one basket" response trigger करते हैं। लेकिन यदि हम कुछ risk analysis चलाते हैं तो हम देखेंगे कि यह usually केवल fear और uncertainty है और mathematically supported risk नहीं है। यदि हम ऊपर के example के समान risks मानें तो हमारा single server, average पर, एक दशक में एक बार, सिर्फ एक total site outage incur करेगा।

इसकी तुलना पहले example से करें जिसने ढाई total site outages के equivalent damage किया – virtualized, consolidated solution का risk पारंपरिक solution का केवल चालीस percent है।

अब ध्यान रखें कि यह इस assumption पर आधारित है कि कुछ services खोने का मतलब खोई गई service के strict value से अधिक financial loss है, जो लगभग हमेशा ऐसा होता है। यहां तक कि यदि खोई गई service individual service के loss से अधिक नहीं है तो हम केवल break even पर हैं और चिंता करने की जरूरत नहीं है। दुर्लभ cases में एक single system खोने से impact उसके "slice of the pie" से कम हो सकता है, normally क्योंकि लोग flexible हैं और failed system के आसपास काम कर सकते हैं – जैसे यदि instant messaging fail हो जाती है और लोग instant messaging restore होने तक email का उपयोग करने के लिए simply switch कर लेते हैं, लेकिन ये cases दुर्लभ हैं और normally कई में से कुछ systems तक isolated होते हैं, जबकि ERP, CRM और email जैसे अधिकांश systems outage की event में disproportionally large impacts रखते हैं।

तो हम यहां जो देखते हैं वह यह है कि normal circumstances में दस servers से एक server पर दस services को move करने से generally हमारा risk कम होगा, न कि बढ़ेगा – "eggs in a basket" theory के सीधे विपरीत। और यह purely hardware failure perspective से है। Consolidation कई अन्य महत्वपूर्ण reliability factors भी प्रदान करता है, हालांकि, जो हमारे case study पर significant impact कर सकते हैं।

Consolidation के साथ हम IT department द्वारा monitor और manage किए जाने वाले hardware की मात्रा कम करते हैं। Fewer servers का मतलब है कि जो remain हैं उन पर अधिक समय और ध्यान दिया जा सकता है। अधिक ध्यान का मतलब है issues को जल्दी पकड़ने का बेहतर chance और parts को hand पर रखने का अधिक opportunity। बेहतर monitoring और maintenance बेहतर reliability की ओर ले जाती है।

संभवतः सबसे महत्वपूर्ण factor, हालांकि, consolidation के साथ यह है कि significant cost savings हैं और यह, यदि सही तरीके से approach किया जाए, तो improved reliability के opportunities प्रदान कर सकता है। Servers की total cost में dramatic reduction के साथ यह tempting हो सकता है कि budgets tight रखें और purely cost savings को directly leverage करने का attempt करें। Understandable और कुछ businesses के लिए यह correct approach हो सकता है। लेकिन यह वह approach नहीं है जो मैं eggs और baskets की notion के खिलाफ struggling करते समय recommend करूंगा।

इसके बजाय एक more moderate approach apply करके significant cost savings रखते हुए लेकिन फिर भी relatively speaking single server पर अधिक spend करते हुए आप एक higher end (read: अधिक reliable) server acquire कर सकते हैं, better parts use कर सकते हैं, on-site spares रख सकते हैं, आदि। Virtualization की cost savings को अक्सर single server approach के पक्ष में equation को आगे shift करते हुए increased reliability में directly turned किया जा सकता है।

जैसा कि मैंने एक अन्य article में कहा था, एक brick house किसी wind storm में survive करने की अधिक संभावना है बजाय एक या दो straw houses के। किसी चीज का अधिक होना necessarily इसे अधिक reliable choice नहीं बनाता।

ये benefits purely virtualization के consolidation aspect से आते हैं न कि virtualization से ही। Virtualization अलग से भी extended risk mitigation features प्रदान करता है। System imaging और rapid restores, साथ ही different hardware पर restores, लगभग किसी भी virtualization platform के major advantages हैं। यह disaster recovery strategy में एक important role play कर सकता है।

बेशक, ये सभी concepts purely यह demonstrate करने के लिए हैं कि single box virtualization और consolidation legacy "one app to one server" approach को beat कर सकते हैं और फिर भी पैसे बचा सकते हैं – यह दिखाते हुए कि eggs और baskets का example misleading है और इस scenario में लागू नहीं होता। इन factors के आधार पर traditional environment से directly virtualized environment में move करने में बहुत कम trepidation होनी चाहिए।

यह ध्यान दिया जाना चाहिए कि virtualization फिर traditional commodity hardware की reliability को extend कर सकता है, mainframe-like failover features प्रदान करता है जो non-virtualized platforms प्रदान करने में सक्षम नहीं हैं। यह commodity hardware को larger, अधिक expensive RISC platforms के साथ अधिक firmly line में move करता है। ये features protection का extreme level ला सकती हैं लेकिन अक्सर उन IT shops के लिए above और beyond होती हैं जो non-failover, legacy hardware server environment से initially migrate कर रहे हैं। High availability एक बेहतरीन feature है लेकिन अक्सर costly है और बहुत अक्सर unnecessary है, विशेष रूप से जैसे-जैसे companies past में relatively unreliable environments से आज अधिक reliable environments में move करती हैं। यह देखते हुए कि हमने already reliability को बढ़ाया है जो past में जरूरी माना जाता था, इस बात की बहुत अच्छी संभावना है कि reliability में extreme jump अभी जरूरी नहीं है, लेकिन high availability की लागत में बड़ी गिरावट के कारण, यह काफी संभव है कि यह cost justified होगा जहां पहले नहीं हो सकता था।

इसी तरह, virtualization को अक्सर इसलिए fear किया जाता है क्योंकि इसे एक new, unproven technology के रूप में देखा जाता है। यह निश्चित रूप से असत्य है लेकिन small business और commodity server space में इसकी यह impression है। वास्तव में, हालांकि, virtualization को IBM ने 1960s में पहली बार introduce किया था और तब से यह high end mainframe और RISC servers का – वे systems जो best reliability demand करते हैं – एक mainstay रहा है। Commodity server space में virtualization एक larger technical challenge था और real world में effectively use करने के लिए efficient enough implement होने से पहले बहुत लंबा समय लगा। लेकिन commodity server space में भी virtualization 1990s के अंत से available है और इसलिए आज approximately fifteen years पुराना है जो nascent technology होने के point से बहुत far past है – IT की दुनिया में यह positively venerable है। Commodity platform virtualization एक mature field है जिसमें कई highly respected, extremely advanced vendors और products हैं। सभी या लगभग सभी server applications के लिए standard के रूप में virtualization का use एक long established और accepted "enterprise pattern" है और एक जिसे अब किसी भी और हर size की companies द्वारा easily adopt किया जा सकता है।

Virtualization, perhaps counter-intuitively, actually एक reliability strategy का एक बहुत critical component है। Risk add करने के बजाय, virtualization को almost एक risk mitigation platform के रूप में approach किया जा सकता है – कई avenues के माध्यम से आपके computing platforms की reliability बढ़ाने के लिए एक toolkit।