सिर्फ इसलिए कि आप कर सकते हैं…

मैं यह अवधारणा virtualization से जुड़ी चर्चाओं में हर समय देखता हूँ। यह एक व्यापक, अधिक सामान्य अवधारणा है लेकिन virtualization वह “hot, new technology” है जिसका सामना कई IT organizations को करना पड़ रहा है और यह वह space प्रतीत होता है जहाँ वर्तमान में हम “just because you can, doesn’t mean you should” की समस्याओं को सबसे अधिक प्रचलित रूप से सर उठाते देखते हैं। IT में हर चीज़ की तरह, यह महत्वपूर्ण है कि सभी technical decisions को एक business context में रखा जाए ताकि हम समझ सकें कि हम जो करना चुनते हैं वह क्यों करते हैं और लोकप्रिय deployment methodologies या इससे भी बदतर, myths के आधार पर अंधाधुंध निर्णय न लें।

Virtualization को ही, मैं यह बताना चाहूँगा, मेरा मानना है कि आज x64 computing space में काम करने वालों के लिए एक default decision होना चाहिए, जहाँ specific hardware needs, latency sensitive applications आदि जैसी स्पष्ट और स्पष्ट आवश्यकता होने पर ही systems को बिना virtualization के deploy किया जाए। किसी विशेष जरूरत के अभाव में, virtualization कई vendors से लागू करने के लिए मुफ्त है और आज और भविष्य में environment को future-proof करने में दोनों तरह से कई लाभ प्रदान करता है।

यह कहते हुए, मैं आज अक्सर देखता हूँ कि companies virtualization को best practice के रूप में नहीं बल्कि सभी perceived IT problems के रामबाण के रूप में deploy कर रही हैं। यह निश्चित रूप से नहीं है। Virtualization IT toolbox में रखने के लिए एक बहुत महत्वपूर्ण tool है और एक जिसे हम बहुत बार use करेंगे, लेकिन यह हर समस्या को हल नहीं करता और इसे हर दूसरे tool की तरह ही treat किया जाना चाहिए जो हमारे पास है और केवल तब उपयोग किया जाना चाहिए जब उचित हो।

जब virtualization चर्चाओं में एक topic के रूप में आती है तो मैं कई बातें बार-बार देखता हूँ। आज कई companies virtualization की ओर बढ़ रही हैं, इसलिए नहीं कि उन्होंने business need की पहचान की है, बल्कि इसलिए कि यह वर्तमान trending topic है और लोगों को लगता है कि यदि वे virtualization implement नहीं करते तो किसी तरह वे पीछे छूट जाएंगे या कुछ mythical functionality से चूक जाएंगे। यह सामान्यतः अच्छा है क्योंकि यह virtualization adoption बढ़ा रहा है, लेकिन यह बुरा है क्योंकि अच्छे IT और business decision making processes को bypass किया जा रहा है। जो होता है वह अक्सर यह है कि virtualization hype की लहर में IT departments को लगता है कि न केवल उन्हें virtualization implement करना है बल्कि ऐसे तरीकों से करना है जो उनके business के लिए उचित नहीं हो सकते।

चार चीज़ें हैं जिन्हें मैं अक्सर virtualization से जुड़ी देखता हूँ, अक्सर virtualization requirements के रूप में स्वीकार की जाती हैं, चाहे वे किसी दिए गए business environment में समझ में आएं या नहीं। ये हैं server consolidation, blade servers, SAN storage और high availability या live failover।

Consolidation को virtualization के लाभ के रूप में इतना बखान किया जाता है कि मुझे लगता है कि अधिकांश IT departments भूल जाते हैं कि इसे implement करने के अन्य महत्वपूर्ण कारण भी हैं। स्पष्ट रूप से consolidation लगभग सभी deployments के लिए एक बड़ा लाभ है और मौजूदा resources के बेहतर उपयोग के माध्यम से इसे लगभग हमेशा हासिल किया जा सकता है। यह काफी दुर्लभ company है जो एक से अधिक physical server चलाती है जो limited consolidation के माध्यम से कुछ लागत नहीं बचा सकती और बड़े organizations में datacenter footprints को काफी कम होते देखना असामान्य नहीं है।

हालांकि, extreme cases में, केवल इसलिए virtualization projects को छोड़ना आवश्यक नहीं है क्योंकि consolidation बाहर निकली हो। ये cases उन companies के लिए exist करती हैं जिनके पास high utilization systems हैं और preemptive consolidation investment के लिए कम budget है। लेकिन ये shops अभी भी “in place” systems को one to one basis पर virtualize कर सकती हैं ताकि आज virtualization के अन्य लाभ प्राप्त किए जा सकें और जब hardware को replace करने की आवश्यकता हो तब consolidation की ओर देखा जा सके। यह महत्वपूर्ण है कि virtualization को इसलिए न छोड़ें क्योंकि इसका सबसे प्रसिद्ध लाभ आपके environment में वर्तमान समय में लागू नहीं होता।

Blade servers को अक्सर virtualization environments के लिए एकमात्र विकल्प के रूप में देखा जाता है। Blades standard virtualization environment में अधिक traditional computational workloads की तुलना में बेहतर play कर सकते हैं लेकिन यह दोनों अत्यधिक विवादास्पद है और जरूरी applicable data नहीं है। Blades के लिए एक अच्छा scenario होना जरूरी नहीं कि यह business के लिए अच्छा scenario हो। सिर्फ इसलिए कि blades इस तरह उपयोग किए जाने पर normally से बेहतर perform करते हैं, इसका मतलब यह नहीं कि वे traditional servers से बेहतर perform करते हैं – केवल यह कि उन्होंने संभवतः अंतर को कम किया है।

Blades को virtualizing करते समय वही कठोर criteria का उपयोग करके evaluate किया जाना चाहिए जब virtualizing न करते हों और, अक्सर, वे long term business value प्रदान करने में विफल रहेंगे जो उन्हें more flexible alternatives पर चुनने के लिए आवश्यक है। Blades virtualization के लिए necessity से बहुत दूर हैं और अक्सर, मेरी राय में, वास्तव में एक बहुत खराब विकल्प हैं।

सबसे आम misconceptions में से एक यह है कि virtualization की ओर जाने से SAN जैसे shared storage की ओर भी जाना होगा। यह mindset virtualization से अन्य लाभ प्राप्त करने की इच्छा की स्पष्ट प्रतिक्रिया है जो यदि SAN की जरूरत नहीं है तो उससे बहुत लाभ उठाते हैं। Systems के बीच load balance या failover करने की क्षमता shared storage backend होने से काफी facilitated होती है। यह एक myth है कि यह एक hard requirement है, लेकिन replicated local storage अपनी खुद की complexities और limitations लाता है।

लेकिन shared storage virtualization का necessity से दूर है और, हर चीज़ की तरह, इसे अपने आप evaluate किया जाना चाहिए। यदि virtualization आपके environment के लिए समझ में आता है लेकिन आपको ऐसी कोई features की जरूरत नहीं है जिनके लिए SAN की आवश्यकता हो, तो shared storage के बिना virtualize करें। कई cases हैं जहाँ local storage backed virtualization एक आदर्श deployment scenario है। पहले गंभीर विचार दिए बिना इस approach को dismiss करने की कोई जरूरत नहीं है।

Virtualization की अंतिम प्रमुख assumed necessary feature आपके operating system के लिए system level high availability या instant failover है। बिना किसी संदेह के, system layer पर high availability एक phenomenal benefit है जो virtualization हमें लाता है। हालांकि, virtualization implement करने से पहले कुछ companies को इस level पर high availability की जरूरत थी और इसे virtualization के साथ करने के लिए आवश्यक infrastructure और software की price tag अक्सर इतनी अधिक होती है कि इसे justify करना बहुत महंगा हो जाता है।

High availability systems complex और अक्सर overkill होते हैं। यह बहुत दुर्लभ business system है जिसे सबसे critical systems के लिए भी transparent failover की जरूरत होती है और उस requirement वाली companies के पास पहले से ही failover processes मौजूद होंगी। मैं देखता हूँ कि companies virtualization देखते समय हर समय high availability की ओर बढ़ रही हैं क्योंकि एक vendor ने मूल requirements को dramatically oversell करने का अवसर देखा। High availability की लागत शायद ही कभी downtime में associated reduction से revenue की potential loss द्वारा justified होती है। Non-highly available virtualization के साथ, एक failed hardware device के लिए downtime को minutes में measured किया जा सकता है यदि backups अच्छी तरह से handled हों। इसका मतलब है कि high availability को प्रति वर्ष केवल कुछ minutes के unplanned downtime को eliminate करने में अपनी लागत justify करनी होगी, added system complexity द्वारा assumed किसी भी additional risks को घटाकर। यहाँ तक कि सबसे बड़े organizations में भी यह शायद ही कभी किसी बड़े पैमाने पर justified है और more moderately sized company में यह सामान्यतः uncommon है। लेकिन आज हम पाते हैं कि कई small businesses extreme cost पर high availability systems implement कर रही हैं उन systems पर जो आसानी से minimal financial loss के साथ multi-day outages झेल सकती हैं, सिर्फ इसलिए कि marketing literature ने इस concept को promote किया।

किसी भी चीज़ की तरह, virtualization और उन सभी associated possibilities को जो यह table पर लाता है, उन्हें उन्हें consider करने वाले organization के context में individually evaluate करने की जरूरत है। यदि individual feature आपके business के लिए समझ में नहीं आती तो यह न मानें कि आपको वह feature खरीदनी या implement करनी है। कई organizations virtualize करती हैं लेकिन इनमें से कुछ ही, यदि कोई हो, “assumed” features का उपयोग करती हैं। Virtualization को एक black box के रूप में न देखें, parts को देखें और उन्हें वैसे ही consider करें जैसे आप किसी अन्य technology project को consider करते।

जो अक्सर एक snowball effect में होता है जहाँ एक feature, संभवतः high availability, को proper business assessment किए बिना necessary मान लिया जाता है। फिर एक shared storage system, जिसे अक्सर high availability के लिए required माना जाता है, एक और assumed cost के रूप में जोड़ा जाता है। भले ही high availability features खरीदे न जाएं, SAN उपयोग करने का निर्णय पहले से हो सकता है और plan में बदलाव के बाद भी इसे revisit करने में विफल रहा जाए। मेरे अनुभव में, इस प्रकृति के projects में कभी-कभी project पर कुल expenditure का पचास प्रतिशत से अधिक उन products पर खर्च होना बहुत आम है जिनके खरीदने का कारण बताने में purchaser असमर्थ है।

यह अवधारणा virtualization पर नहीं रुकती। इसे उन सभी चीज़ों तक extend करें जो आप करते हैं। IT को business के perspective में रखें और यह न मानें कि एक technology के साथ जाने का मतलब यह है कि आपको उन अन्य technologies को अपनाना होगा जो इसके साथ popularly associated हैं।