High Availability पर कब विचार करें?

“High Availability कोई ऐसी चीज नहीं जो आप खरीदते हैं, यह कुछ ऐसा है जो आप करते हैं।” – John Nicholson

IT में High Availability (HA) solutions से अधिक universally desired चीजें कम हैं। मेरा मतलब है, सच में, वे शब्द कहें और कोई भी IT Pro तुरंत कहेगा कि वे यही चाहते हैं। अपने servers, apps, storage और, निश्चित रूप से, यहां तक कि अपने desktops के लिए HA। यदि किसी भी system के बगल में एक checkbox होता जो बस “HA” कहता, तो हम उसे क्यों नहीं check करेंगे? हम करेंगे, निश्चित रूप से। कोई भी स्वेच्छा से ऐसा system नहीं चाहता जो बहुत fail हो। Failure बुरी, success अच्छी।

पहले, हालांकि, हमें HA को define करना होगा। HA का अर्थ कई चीजें हो सकती हैं। कम से कम, HA का अर्थ यह होना चाहिए कि प्रश्न में system की availability “सामान्य” से अधिक होनी चाहिए। सामान्य क्या है? यह अकेला define करना काफी कठिन है। HA एक loose term है, कम से कम। इसके सबसे सामान्य उपयोग के context में, हालांकि, जो सामान्य enterprise hardware पर चलने वाले common applications हैं, मैं HA चर्चाओं के लिए यह starting point प्रदान करूंगा:

Normal या Standard Availability (SA) को एक common mainline server पर एक common enterprise operating system चलाने वाले common enterprise application की availability के रूप में define किया जाएगा जो best practices environment में enterprise support के साथ हो। इसके अच्छे examples में Exchange शामिल हो सकता है जो Windows Server पर चल रहा है, जो HP Proliant DL380 पर चल रहा है (सबसे common mainline commodity server)। या BIND (DNS server) के लिए जो Red Hat Enterprise Linux पर Dell PowerEdge R730 पर चल रहा है। ये केवल एक rough baseline स्थापित करने के लिए उपयोग किए जाने वाले examples हैं। इसे measure करने का कोई बड़ा तरीका नहीं है, लेकिन एक अच्छे support contract और वास्तविक दुनिया में rapid repair या replacement के साथ, इस प्रकार के system की reliability के बारे में माना जाता है कि human failure शामिल न होने पर चार से पांच nines की reliability (99.99% uptime या उससे अधिक) के बीच है।

High Availability (HA) को आमतौर पर Standard Availability की तुलना में significantly अधिक availability होने के रूप में define किया जाना चाहिए। Significantly अधिक कम से कम एक order of magnitude की वृद्धि होनी चाहिए। इसलिए कम से कम पांच nines की reliability और संभवतः छह nines। (99.9999% uptime।)

Low Availability (LA) को आमतौर पर Standard Availability की तुलना में significantly कम availability होने के रूप में define किया जाएगा, जहां significantly का अर्थ फिर से कम से कम एक order of magnitude है। इसलिए LA को आमतौर पर लगभग 99% से 99.9% या उससे कम availability माना जाएगा।

यहां measurement बहुत कठिन है क्योंकि human factors, environmental और अन्य विभिन्न configurations के uptime को निर्धारित करने में एक बड़ी भूमिका निभाते हैं। एक ही gear का उपयोग एक भूमिका में five nines प्राप्त कर सकता है जबकि दूसरे में एक भी प्राप्त करने में विफल हो सकता है। Datacenter की quality, support staff का skill, parts replacement की rapidity, monitoring की granularity और कई अन्य factors overall reliability को significantly प्रभावित करेंगे। हालांकि, यह जरूरी नहीं कि हमारे लिए एक समस्या हो। अधिकांश मामलों में हम system design के उन portions का evaluate करने में सक्षम हो सकते हैं जिन्हें हम इस तरह नियंत्रित करते हैं कि relative reliability निर्धारित की जा सके ताकि कम से कम हम यह दिखा सकें कि एक approach दूसरे से बेहतर होगी, ताकि हम well informed decision making का लाभ उठा सकें, भले ही accurate failure rate models आसानी से नहीं बनाए जा सकते।

यह ध्यान रखना महत्वपूर्ण है कि एक sample baseline set of examples प्रदान करने के अलावा जिससे काम किया जाए, high availability या low availability की definitions में कुछ भी इस बारे में नहीं बात करता कि ये levels कैसे प्राप्त की जानी चाहिए - इसका अर्थ वे terms नहीं हैं। Terms baseline के संबंध में reliability के resultant sets हैं और कुछ नहीं। Commonly assumed approaches का उपयोग किए बिना high availability प्राप्त करने के कई तरीके हैं और low availability प्राप्त करने के practically unlimited तरीके हैं।

बेशक HA को हर layer पर define किया जा सकता है। हमारे पास HA platforms या OS हो सकते हैं लेकिन उनके ऊपर fragile applications हो सकती हैं। इसलिए यह समझना बहुत महत्वपूर्ण है कि किसी भी दिए गए समय पर हम किस level पर बात कर रहे हैं। दिन के अंत में, एक business केवल services की high availability delivery की परवाह करेगा, चाहे यह कैसे भी प्राप्त हो, या कहां। अंतिम परिणाम मायने रखता है न कि यह कैसे accomplish किया गया इसके “under the hood” विवरण, या हमेशा की तरह, ends justify the means।

आज IT departments के लिए platform layer पर नए और flashy HA tools से distracted होना और stack में ऊपर और नीचे HA देखना भूल जाना बहुत सामान्य है ताकि यह सुनिश्चित हो सके कि हम business को highly available services प्रदान करते हैं; बजाय केवल एक layer को देखने के जबकि business को उतना ही, या उससे भी अधिक, vulnerable छोड़ते हैं।

वास्तविक दुनिया में, हालांकि, HA हमेशा एक option नहीं है और, जब यह होती है, तो यह एक cost के साथ आती है। वह cost लगभग हमेशा monetary होती है और आमतौर पर extra complexity के साथ भी आती है। और जैसा कि हम अच्छी तरह जानते हैं, कोई भी complexity additional risk भी वहन करती है और वह risk, यदि हम सावधान नहीं हैं, तो HA प्राप्त करने का प्रयास वास्तव में विफल हो सकता है और हमें LA या Low Availability के साथ भी छोड़ सकता है।

एक बार जब हम समझते हैं कि हमारा क्या मतलब है इसके लिए यह आवश्यक language, तो हम इस बारे में बात करना शुरू कर सकते हैं कि high availability, standard availability और यहां तक कि low availability हमारे लिए कब सही हो सकती है। हम granularity के इस high level का उपयोग करते हैं क्योंकि system reliability को measure करना इतना कठिन है कि बहुत detailed होना valueless हो जाता है।

वैचारिक रूप से, सभी systems में downtime का risk होता है और कुछ भी हमेशा up नहीं रह सकता, यह impossible है। Reliability में पैसे लगते हैं, सामान्यतः, सब कुछ बराबर होने पर। इसलिए यह निर्धारित करने के लिए कि किसी workload के लिए availability का कौन सा level सबसे उपयुक्त है, हमें risk mitigation की cost (औसत downtime की मात्रा बदलने में लगने वाले पैसे) निर्धारित करनी होगी और उसे downtime की cost के खिलाफ compare करना होगा।

यह tricky और complicated हो जाता है क्योंकि downtime की cost निर्धारित करना काफी कठिन है, फिर downtime का risk निर्धारित करना और भी कठिन है। कई मामलों में, downtime एक flat number नहीं है, लेकिन यह हो सकती है। इस cost को $5/minute या $20K/day या इसी तरह express किया जा सकता है। लेकिन एक और बेहतर tool एक “loss impact curve” बनाना होगा जो दिखाए कि समय के साथ पैसे कैसे खोते हैं (एक reasonable interval के भीतर।)

उदाहरण के लिए, एक company पहले पांच मिनट तक आसानी से कोई नुकसान नहीं face कर सकती जिसमें धीरे-धीरे बढ़ता हुआ, लेकिन छोटा, नुकसान होता है जब तक कि लगभग चार घंटे में काम बंद नहीं हो जाता क्योंकि लोग अब कागज पर नहीं जा सकते या जो भी हो, और तब नुकसान लगभग शून्य से काफी बड़े हो जाते हैं। या कुछ companies उस क्षण एक बड़ा नुकसान उठा सकती हैं जब systems down हों लेकिन समय के साथ नुकसान धीरे-धीरे कम होता है। नुकसान केवल दिन के कुछ निश्चित समय पर ही impactful हो सकता है। शायद रात या lunch के दौरान outages trivial हों लेकिन mid morning या mid afternoon प्रमुख हों। हर company का impact, risk और उस risk को mitigate करने की क्षमता अलग-अलग है, अक्सर dramatically।

कभी-कभी यह company में काम करने वाले लोगों पर निर्भर करता है। क्या वे सभी खुशी से आवश्यक bathroom, coffee, snack या यहां तक कि lunch breaks लेंगे उस समय जब कोई system fail हो ताकि वे ठीक होने पर काम पर वापस आ सकें? क्या लोग जल्दी घर जाएंगे और एक बड़े outage की भरपाई के लिए कल जल्दी आएंगे? क्या कोई machinery है जो idle बैठेगी? क्या customers को respond करने की क्षमता प्रभावित होगी? क्या life support systems fail होंगे? संभावित impacts अनगिनत हैं और विभिन्न प्रकार की failures को mitigate करने के संभावित तरीके भी अनगिनत हैं। यह सब consider करना होगा। Downtime की cost corporate revenues का एक fraction प्रति minute हो सकती है या downtime customers या विश्वास के नुकसान का कारण बन सकती है जो minute by minute generate होने वाले revenue से अधिक impactful है।

एक बार जब हमारे पास deal करने के लिए कुछ rough loss numbers हों तो हमारे पास कम से कम एक starting point है। यहां तक कि यदि हम केवल जानते हैं कि revenue ~$10/minute है और losses ~$5/minute के आसपास expected हैं, तो हमारे पास एक starting point है। यदि हमारे पास एक full curve या अधिक detailed numbers के साथ एक study किया गया है, तो सब बेहतर है। अब हमें यह figure out करना होगा कि हमारी baseline roughly क्या होगी। एक well maintained server, premises पर चल रही, एक अच्छे support contract और अच्छे backup and restore procedures के साथ, काफी आसानी से four nines की reliability प्राप्त कर सकती है। इसका अर्थ है कि हम हर पांच साल में लगभग पांच घंटे की downtime अनुभव करेंगे। यह वास्तव में अधिकांश environments में SA की generally expected downtime से कम है और potentially उत्कृष्ट environments जैसे high quality datacenters में nearby parts और service के साथ expected levels से बहुत कम है।

इसलिए, लगभग पांच साल में पांच घंटे के हमारे baseline example के आधार पर, हम अपने potential risk figure out कर सकते हैं। यदि हम ~$5/minute खोते हैं और हम हर पांच साल में roughly 300 minutes की downtime expect करते हैं तो हम हर आधे decade में $1,500 के potential loss पर देख रहे हैं।

इसका अर्थ है कि अत्यधिक मामले में हम उस risk को mitigate करने के लिए कभी भी $1,500 नहीं खर्च कर सकते, यह financially बेतुका होगा। यह कई कारणों से होता है। सबसे बड़े में से एक यह है कि यह केवल एक risk है, $1,500 को खोने से बचाने के लिए $1,500 खर्च करना बहुत कम sense बनाता है, लेकिन यह एक बहुत सामान्य गलती है जब लोग इन numbers का सावधानी से analyze नहीं करते।

सबसे बड़ा factor यह है कि कोई भी mitigation technique पूरी तरह से effective नहीं है। यदि हम अपने four nines system को five nines system पर ले जाते हैं तो हम average downtime का केवल 90% reduce करेंगे, हमें $1,500 के loss से $150 के loss पर ले जाएंगे। यदि हमने उस reduction के लिए $1,500 खर्च किए, तो कुल “loss” अभी भी $1,650 होगा (protection की cost एक प्रकार का financial loss है।) Risk mitigation की cost anticipated remaining impact के साथ मिलकर risk की anticipated cost mitigation के बिना से अभी भी कम होनी चाहिए, नहीं तो mitigation ही pointless या actively damaging है।

कई लोग प्रश्न कर सकते हैं कि risk mitigation की कुल cost कम क्यों होनी चाहिए और बराबर क्यों नहीं क्योंकि निश्चित रूप से, इसका अर्थ यह होना चाहिए कि हम एक “risk break even” point पर हैं? यह surface पर सच लगता है, लेकिन क्योंकि हम risk से deal कर रहे हैं यह ऐसा नहीं है। Risk mitigation एक certain cost है - financial damage जो हम आज उठाते हैं इस उम्मीद में कि कल losses कम होंगी। लेकिन कल का risk एक guess है, hopefully एक well educated one, लेकिन केवल एक guess। आज की cost certain है। कल के possible damage को reduce करने की उम्मीद में आज certain damage उठाना तभी sense बनाता है जब आज का damage छोटा हो और कल का expected या possible damage बहुत बड़ा हो और mitigation की effectiveness significant हो।

“कल के possible cost” को reduce करने के लिए “upfront certain cost” के विचार में money के time value का विचार शामिल है। यहां तक कि यदि एक outage एक known size और time की होती, तो हम आज उसे mitigate करने के लिए वही पैसे खर्च नहीं करेंगे जो हम कल करते क्योंकि हमारा पैसा आज अधिक valuable है।

सबसे dramatic cases में, हम कभी-कभी IT departments को शायद कुछ हजार डॉलर खोने से बचने के लिए, शायद, कभी-कभी कई वर्षों में, दसों या सैकड़ों हजारों डॉलर upfront खर्च करने की demand करते देखते हैं। एक strategy जिसे हम “कल maybe headache से बचने के लिए आज खुद को चेहरे पर shoot करना” के रूप में refer कर सकते हैं।

Risk mitigation के evaluate करने की concept में यह शामिल है लेकिन इसे specifically mention किया जाना चाहिए कि IT equipment के case में attempted risk mitigation के कई examples हैं जो उतने effective नहीं हो सकते जितने माने जाते हैं। उदाहरण के लिए, एक ही rack में बैठे दो servers होने से host hardware failure के risk को mitigate करने के लिए potentially बहुत effective होगा, लेकिन natural disasters, site loss, fire, electrical shock के अधिकांश cases, fire suppression activation, network interruptions, अधिकांश application failure, ransomware attack या अन्य reasonably possible disasters के खिलाफ mitigate नहीं करेगा।

Storage devices को “dual controllers” के साथ equip करना सामान्य है जो high reliability का एक strong impression देता है, लेकिन generally ये controllers shared components के साथ एक single chassis के अंदर होते हैं और यहां तक कि यदि components shared नहीं हैं, तो अक्सर firmware shared होता है और components के बीच communications complex होते हैं; अक्सर ऐसी failures की ओर leading करते हैं जहां एक component की failure दूसरे की failure trigger करती है - जिससे वे जब लोगों ने उन्हें खरीदते समय HA expect की थी उसके बजाय quite frequently LA devices बन जाते हैं। इसलिए यह consider करना बहुत critical है कि risk mitigation strategy किन risks को mitigate करेगी और mitigation technique के effective होने की संभावना है या नहीं। कोई भी technique पूरी तरह से effective नहीं है, failure की हमेशा एक chance होती है, लेकिन कुछ strategies और techniques दूसरों की तुलना में अधिक broadly effective हैं और कुछ simply misleading या actually counter productive हैं। यदि हम सावधान नहीं हैं, तो हम costly products या techniques implement कर सकते हैं जो actively हमारे goals को undermine करती हैं।

High availability की pursuit में उपयोग की जाने वाली कुछ techniques और products rather expensive हैं, जिनमें redundant hardware खरीदना, दूसरी building lease करना, expensive generators install करना या special software license करना शामिल हो सकता है। Low cost techniques और software भी हैं, लेकिन अधिकांश मामलों में high availability की ओर कोई भी movement के result में investment capital का एक respectively large outlay होगा। यह absolutely critical है कि याद रखा जाए कि high availability एक process है, simply high availability खरीदने का कोई तरीका नहीं है। HA प्राप्त करने के लिए अच्छे documentation, procedures, planning, support, equipment, engineering और अधिक की आवश्यकता है। Systems की दुनिया में, HA को normally पहले environmental perspective से approach किया जाता है जिसमें failover power generators, redundant HVAC systems, power conditioning, air filtration, fire suppression systems और अधिक शामिल हैं ताकि availability के लिए environment सुनिश्चित हो। यह अकेला अक्सर further investment को unnecessary बना सकता है क्योंकि यह incredible results deliver कर सकता है। फिर आता है HA system design यह सुनिश्चित करते हुए कि technology stack की केवल एक layer highly available नहीं है बल्कि पूरा stack critical applications, data या services को यथासंभव अधिक समय तक functional रहने की अनुमति देता है। फिर site to site redundancy देखना floods, hurricanes, blizzards आदि का सामना करने में सक्षम होने के लिए। बेशक हमारी ओर से remotely hosted cloud computing services का उपयोग करने जैसी completely अलग techniques भी हैं। जो मायने रखता है वह यह है कि high availability के लिए broad thinking और planning की आवश्यकता है, इसे एक line item के रूप में simply नहीं खरीदा जा सकता और इसे एक resulting uptime या uptime की likelihood प्रदान करने की क्षमता से judge किया जाता है जो एक “standard” system design deliver करने की तुलना में बहुत अधिक है।

जो अक्सर surprising, almost shocking, कई businesses और विशेष रूप से IT professionals के लिए होता है, जो शायद ही कभी financial risk analysis undertake करते हैं और जिन्हें लगातार बताया जाता है कि HA किसी भी business के लिए एक necessity है और latest HA products खरीदना unquestionably उनके budgets कैसे खर्च किए जाने चाहिए, यह है कि जब numbers crunch किए जाते हैं और risk mitigation strategies की costs और effectiveness की reality consider की जाती है तो high availability का किसी भी organization में, विशेष रूप से छोटे या highly disparate workloads वाले, बहुत कम place है। Small and medium business market में यह लगभग universal है कि high availability approaches की cost और complexity (जो बदले में risk लाती है, mostly experience की कमी के रूप में techniques और risk assessment के आसपास) उस outage के potential damage को offset करने के लिए कभी भी बहुत costly होती है जिससे mitigation protect करने की उम्मीद है। बेशक exceptions हैं, और कई businesses हैं जिनके लिए high availability solutions absolutely sensible हैं, लेकिन ये exception हैं और norm से बहुत दूर हैं।

यह भी sensible है कि high availability की जरूरतों को department, company या technology wide के बजाय एक workload basis पर आधारित माना जाए। एक small business में सभी workloads के लिए एक common platform share करना सामान्य है और एक single workload की high availability की आवश्यकता अन्य, कम critical, workloads को अपने साथ sweep कर सकती है। यह perfectly fine है और critical workload के risk mitigation की cost को कम critical workloads को ancillary benefit के माध्यम से offset करने का एक बेहतरीन तरीका है। एक बड़े organization में जहां differing workloads के लिए platform approaches की plethora used होती है, यह सामान्य है कि केवल certain workloads जो दोनों highly critical (downtime impact से risk के संदर्भ में) और practically risk mitigated (risk को mitigate करने की क्षमता different types के workloads के बीच dramatically vary कर सकती है) हों, उन पर high availability applied हो और अन्य workloads को standard techniques पर छोड़ दिया जाए।

Workloads के examples जो critical हो सकते हैं और high availability के साथ effectively address किए जा सकते हैं, एक online ordering system हो सकता है जहां multi-regional replication द्वारा created latency का overall system पर बहुत कम impact है लेकिन orders खोना बहुत financially impactful हो सकता है यदि कोई system fail हो। एक workload का example जहां high availability implement करना easy हो सकता है लेकिन ineffectual हो सकती है, वह commonly asked HR questions serve करने वाला एक internal intranet site होगा; इस तरह के system के लिए occasional occasional small amounts of downtime से बचना simply cost effective नहीं होगा। एक system का example जहां risk high है लेकिन risk mitigation की cost या effectiveness इसे impractical या यहां तक कि impossible बनाती है, एक financial “tick” database हो सकता है जिसके लिए massive amounts of low latency data ingest करने की आवश्यकता होती है और एक replica maintain करने की क्षमता न केवल incredibly costly होती बल्कि latency introduce कर सकती थी जो system की पर्याप्त रूप से perform करने की क्षमता को undermine करती। हर business और workload unique है और इसे carefully evaluate किया जाना चाहिए।

बेशक high availability techniques को stages में actioned किया जा सकता है; यह all or nothing endeavor नहीं है। System level failure के risk को mitigate करने के लिए application layer fault tolerance होना practical हो सकता है जो system hardware, virtualization platform या storage की failure के खिलाफ protect करे। लेकिन उसी workload के लिए single site के loss के खिलाफ protect करना valuable नहीं हो सकता। यदि कोई workload केवल एक particular site को service करता है या sites के बीच fail करने के लिए आवश्यक large investment के लिए simply पर्याप्त valuable नहीं है तो यह आसानी से “बीच में” fall कर सकता है। Workloads के लिए partially high availability solutions ही implement करना बहुत सामान्य है, अक्सर इसलिए कि एक IT department उनके केवल एक portion के लिए responsible हो सकता है और power support और HVAC जैसी चीजों पर कोई say नहीं होती, लेकिन शायद सबसे सामान्य इसलिए क्योंकि कुछ high availability techniques high visibility के रूप में देखी जाती हैं और management को sell करना easy है जबकि अन्य, जैसे high quality power और air conditioning, अक्सर नहीं होते हालांकि वे easily better bang for the buck provide कर सकते हैं। अच्छे कारण हैं कि क्यों certain techniques choose की जा सकती हैं और अन्य नहीं क्योंकि वे different risk components को affect करती हैं और कुछ risks का किसी individual business या workload पर differing impact हो सकता है।

High availability के लिए सावधानीपूर्वक विचार की आवश्यकता है कि क्या यह consider करने योग्य है और implementation के लिए और भी सावधानीपूर्वक विचार। True HA systems बनाने के लिए significant amount of effort और expertise और generally substantial cost की आवश्यकता होती है। यह समझने के लिए कि HA के कौन से components valuable हैं और कौन से नहीं, न केवल extensive technical expertise बल्कि financial और managerial skills भी आवश्यक हैं। Departments को truly यह समझने के लिए extensively साथ काम करना होगा कि HA किसी organization को कैसे impact करेगी और यह कब investment के लायक होगी। यह critical है कि यह याद रखा जाए कि किसी organization या workload के लिए high availability की आवश्यकता कुछ भी किन्तु एक foregone conclusion है और यह पाने पर कम से कम surprising नहीं होना चाहिए कि extensive high availability या यहां तक कि casual high availability practices economically impractical निकलती हैं।

कई मायनों में यह इसलिए है क्योंकि standard availability ऐसी state में पहुंच गई है कि continuously कम और कम risk mitigate करना है। Business infrastructure में उपयोग किए जाने वाले technology components, सबसे notably servers, networking gear और storage, इतने reliable हो गए हैं कि जिस downtime से हमें protect करना है वह काफी कम है। Knee jerk high availability की आवश्यकता की belief का अधिकांश एक अलग era से आता है जब reliable hardware unaffordable था और यहां तक कि सबसे expensive equipment modern standards के अनुसार rather unreliable था। यह feeling of impending doom कि कोई भी device किसी भी moment fail हो सकती है, एक older era से आती है, वर्तमान से नहीं। Modern equipment, obviously अभी भी risks वहन करती है, amazingly reliable है।

अन्य risks के अतिरिक्त, high availability solutions में over-investing financial और business risks वहन करती है जो substantial हो सकती हैं। यह business uncertainty के सामने technical debt बढ़ाती है। क्या होगा यदि business अचानक grow हो, या इससे भी बुरा, यदि यह अचानक contract हो, direction change करे, purchase हो जाए या completely out of business हो जाए? High availability में investment already spent है भले ही इसकी protection की आवश्यकता गायब हो जाए। क्या होगा यदि technology या location change हो? High availability investment का कुछ या सभी expected end of life से पहले lost हो सकता है।

IT practitioners के रूप में, technology solutions के benefits, risks और costs का evaluate करना हमारे core में है। Business infrastructure में बाकी सब की तरह, risk mitigation का प्रकार निर्धारित करना, protection का value और financially proper कितना है, यह हमारी key responsibility है और इसे glossed over या ignored नहीं किया जा सकता। हम simply यह assume नहीं कर सकते कि high availability की आवश्यकता है, न ही यह कि इसे simply skip किया जा सकता है। इस nature के analysis में IT organizations को अपनी greatest value में से कुछ लाती है। यहां हमारे पास सबसे अधिक shine करने की potential है।