- AWS ने गुरुवार रात से ऑपरेशनल समस्याओं की सूचना दी, और नॉर्दर्न वर्जीनिया के US-East-1 रीजन में डेटा सेंटर के ओवरहीट होने से जुड़ी आउटेज ने Coinbase और FanDuel जैसे ट्रेडिंग प्लेटफ़ॉर्म्स को प्रभावित किया
- AWS ने शुक्रवार दोपहर 3:29 बजे (ET) अपडेट में कहा कि पूर्ण रिकवरी में अभी भी कई घंटे लगने की उम्मीद है, और रिकवरी का काम पहले के अनुमान से धीमा चल रहा है
- AWS ने समझाया कि समस्या उस रीजन के एकल Availability Zone में हुई, और शेष हार्डवेयर को बहाल करने के लिए अतिरिक्त cooling system capacity को online लाया जा रहा है
- FanDuel ने कहा कि प्लेटफ़ॉर्म तक यूज़र्स की पहुंच न होने वाली तकनीकी दिक्कतों की जांच के बाद यह व्यापक AWS आउटेज से जुड़ी पाई गई, और यूज़र्स ने cash out न कर पाने से बेटिंग में नुकसान होने की शिकायत की
- Coinbase ने कहा कि कई AWS क्षेत्रों में आई आउटेज ने core trading services में लंबा व्यवधान पैदा किया, और पोस्ट किया कि मुख्य समस्या पूरी तरह हल हो गई है
रिकवरी की प्रगति
- AWS ने शुक्रवार सुबह 9:51 बजे (ET) अपडेट में कहा, “हम अतिरिक्त cooling system capacity को online लाने के लिए सक्रिय रूप से काम कर रहे हैं, जिससे प्रभावित क्षेत्र के शेष हार्डवेयर को बहाल किया जा सके”
- AWS EC2 instances की आउटेज को ठीक कर रहा है, जो virtual server capacity उपलब्ध कराते हैं
- AWS Health Dashboard ने गुरुवार रात 8:25 बजे (ET) पहली बार पोस्ट किया कि वह “instance outage की जांच कर रहा है”
- AWS ने कोई अतिरिक्त बयान नहीं दिया
सेवा-वार प्रभाव
- FanDuel ने गुरुवार रात 9 बजे (ET) X पर कहा कि उसे यूज़र्स को प्लेटफ़ॉर्म तक पहुंचने से रोकने वाली मौजूदा तकनीकी दिक्कतों की जानकारी है और वह जांच कर रहा है
- लगभग 2 घंटे बाद FanDuel ने अपडेट किया कि यह समस्या व्यापक AWS आउटेज से जुड़ी है
- FanDuel यूज़र्स ने शिकायत की कि प्लेटफ़ॉर्म पर cash out न कर पाने से उन्हें बेटिंग में नुकसान हुआ
- Coinbase ने भी शुक्रवार को X पर पोस्ट किया कि कई AWS क्षेत्रों की आउटेज ने “core trading services में लंबा व्यवधान” पैदा किया
- Coinbase ने उसी पोस्ट में कहा कि मुख्य समस्या पूरी तरह हल हो गई है
क्लाउड मार्केट का संदर्भ
- AWS क्लाउड infrastructure technology मार्केट का लगभग एक-तिहाई हिस्सा रखता है
- AWS लाखों कंपनियों को सेवाएं देता है
1 टिप्पणियां
Hacker News की राय
AWS US-East 1 अब भी इंटरनेट की Achilles' heel बना हुआ है
आप कई regions और availability zones में build कर सकते हैं, लेकिन AWS में US-East 1 की समस्या से बड़े असर वाले incidents बार-बार हुए हैं, और इससे यह उतना redundant और resilient नहीं लगता जितना AWS संकेत देता है
China के बाहर public cloud की सारी identity और access services, यानी कर्मचारियों की भाषा में “aws partition के लिए IAM”, us-east-1 में centralized हैं. Accounts, billing, और permissions को लगातार एक जैसा देखने के लिए ऐसी centralization practically ज़रूरी है
IAM भी पूरी तरह स्वतंत्र software stack नहीं है, और यह DynamoDB जैसी कुछ services पर निर्भर करता है, जबकि वे services फिर IAM पर circular dependency रखती हैं
us-east-1 outage के दौरान कभी-कभी दूसरे regions में existing auth tokens या sessions चलते रहते हैं, लेकिन नए tokens issue नहीं हो पाते. मुझे याद है कि पिछली नौकरी में on-call लोगों से कहा जाता था कि outage खत्म होने तक अपनी SSH sessions या AWS console browser tabs बंद न करें, क्योंकि वे lock out हो सकते थे
पिछले 3 साल में मैंने एक startup को लगभग पूरी तरह use-1 में चलाया है, और region outage सिर्फ एक बार हुआ, वह भी partial outage था, इसलिए ज़्यादातर instances पर असर नहीं पड़ा
ईमानदारी से कहूँ तो इसका एक फायदा यह भी है कि हमारे customers की systems भी सब use-1 में हैं, इसलिए outage का customer impact से correlation रहता है
एक काल्पनिक जादुई दुनिया में load कई cloud providers में बराबर बँटा होता, और single point of failure जैसी कोई चीज़ नहीं होती
मेरी पहली girlfriend के साथ भी सब अच्छा रहा होता, मेरे जुड़वाँ बच्चे English और Korean दोनों में fluent होते, और मुझे भी पता होता कि बड़े service deploy करते समय सिर्फ AWS पर निर्भर नहीं रहना चाहिए
US healthcare भी afford किया जा सकता. लेकिन हक़ीक़त में एक और दिन बीतता है, और AWS US-East 1 इंटरनेट के बड़े हिस्से को गिरा सकता है
2 regions हैं तो 2x capacity, 3 regions हैं तो 1.5x capacity तैयार रखनी होगी, और multi-region setup में machines पहले से running होनी चाहिए. यह उम्मीद नहीं करनी चाहिए कि outage के दौरान आप instances launch कर लेंगे या capacity हासिल कर लेंगे, और multi-region hosting की अतिरिक्त complexity भी संभालनी होगी
मज़ेदार है कि multi-region / multi-AZ setup इतनी खुली दिखावेबाज़ी जैसा लग सकता है, फिर भी सब इसे cloud religion के creed की तरह मानते रहते हैं
इस तरह की betting ख़तरनाक है. क्योंकि AWS को गिरा सकने वाला कोई कर्मचारी भी bet लगा सकता है
ऐसी bets उतनी harmless नहीं होतीं जितनी दिखती हैं, क्योंकि bet लगाने वाला कई बार नतीजे को प्रभावित या बदल भी सकता है
कुल मिलाकर, मैं इस बात से सहमत हूँ कि ऐसे prediction markets insider trading और नकारात्मक scenarios को बढ़ावा दे सकते हैं. इससे हालात का फ़ायदा उठाकर profit कमाने की motivation बनती है
मैंने सोचा था कि data center cooling लगभग पहले से plan की जाती है, और जितना cool कर सकें उससे ज़्यादा install नहीं करते
यहाँ जिज्ञासा यह है कि cooling equipment खराब हुआ था, overheating का कोई बाहरी कारण था, या Amazon data center cooling capacity को overbook कर रहा है
हमें exact root cause नहीं बताया गया, लेकिन लगता था कि floors और roof के बीच की piping redundant नहीं थी, और repair में लगभग 24 घंटे लगे
Data center cooling में, बाकी सबकी तरह, over-provisioning और under-provisioning दोनों साथ मौजूद होते हैं
बड़े heat-exchange equipment आमतौर पर N+1 होते हैं, और बहुत critical छोटे-load facilities में 2N/3N तक configuration होती है, इसलिए वे over-provisioned होते हैं. ऐसा इसलिए क्योंकि इन्हें regular inspection के लिए बंद करना पड़ता है, इनकी failure rate पारंपरिक data center parts से अधिक होती है, और repair के लिए specialized staff व लंबा procurement time चाहिए होता है
बड़ी facilities में, जैसे-जैसे N बढ़ता है, cooling का N+3 या उससे ज़्यादा होना भी असामान्य नहीं है. हमेशा कुछ न कुछ maintenance में होता है, या कोई ऐसा unit parts का इंतज़ार कर रहा होता है जिनका उत्पादन बंद हो चुका है और shelf के लिए custom बनवाने पड़ते हैं, क्योंकि यह पूरा equipment बदलने से सस्ता पड़ता है
दूसरी तरफ, अगर facility की सारी computing capacity अचानक average power usage से 100% पर चली जाए, तो cooling capacity पार हो जाएगी, इसलिए यह under-provisioned भी है. बिजली और दूसरे paths भी अक्सर overload हो जाते हैं, और industry की प्रकृति कुछ हद तक overselling जैसी है
आमतौर पर यह बड़ी समस्या नहीं बनती. Computing load का कुल capacity के 100% तक पहुँचना दुर्लभ है, और अगर पहुँचता भी है तो ज़्यादा देर नहीं रहता, और facilities को cooling या power capacity की धार पर रखकर design नहीं किया जाता
समस्या तब बनती है जब कई घटनाएँ एक साथ intersect करती हैं. Cooling system average load के 200% को संभालने के लिए design किया जाता है, ताकि maintenance और failures के लिए पर्याप्त margin रहे
मंगलवार को repair technician एक unit देखने आता है, bearing defect मिल जाता है, part किसी दूसरे state से मंगवाना पड़ता है, और fan assembly को नुकसान के जोखिम से बचाने के लिए equipment रातभर बंद रखा जाता है
बगल के दो cooling units थोड़ा ज़्यादा काम करने लगते हैं, उनमें से एक में हल्का imbalanced motor होता है या कोई fuse ढीला होकर गर्म हो रहा होता है, और वह part जो सालों से टिका था, बढ़े हुए duty cycle की वजह से फट जाता है
अब N+2 facility में दो units बाहर हो गए, लेकिन average load के 200% baseline के हिसाब से यह अभी भी critical नहीं है
पहले failed unit के दूसरी तरफ वाला तीसरा unit भी बढ़े हुए load में अपनी defect की वजह से fail हो जाए, तो N+2 facility में तीन units बाहर हो जाते हैं. फिर भी average load के 200% design के हिसाब से यह अभी catastrophe नहीं है
लेकिन सुबह 4 बजे हैं, on-site operator इस defect को ठीक नहीं कर सकता, vendor 7 बजे उठेगा और 9 बजे पहुँचेगा. तब तक load बढ़ना शुरू हो जाता है
यह चीज़ US के किसी न किसी data center में लगभग हर दिन होती है, और शायद हर data center में साल में एक बार तो होती ही होगी
अगली जो घटना जुड़ती है वही news बनती है. कोई बड़ा customer सोचता है कि अभी बड़े batch job शुरू करने का अच्छा समय है. कोई fintech market open होने से पहले बड़ा model चला देता है, या कोई oil company नए oil field पर तेज analysis शुरू कर देती है
10,000 नए VM launch कर दिए जाते हैं. सामान्य दिनों में spare capacity रहती है, इसलिए कोई समस्या नहीं होती
लेकिन cooling सिर्फ average cooling capacity के 200% के लिए plan की गई थी, और इस बार ये nodes हल्के-फुल्के busy nodes नहीं बल्कि optimized high-intensity numerical computation चला रहे हैं, जो maximum power खींचते हैं और maximum waste heat पैदा करते हैं
अब सिर्फ कुल machines की गिनती वाला load नहीं, बल्कि average waste-heat impact भी बहुत बढ़ जाता है. फिर cascading failures शुरू होते हैं और cooling N-4 पर पहुँच जाती है
Server fans तेज़ घूमने लगते हैं, ज़्यादा power खाते हैं, और cooling N-5 हो जाती है. हर तरफ alarms बजने लगते हैं
Cooling units की safety systems load और refrigerant pressure बढ़ने पर एक-एक करके trip करती जाती हैं, और cooling N-6, N-7, और आखिर में 0 हो जाती है
इस साल EU में क्या Hetzner का uptime AWS से बेहतर रहा है, यह जानने की जिज्ञासा है
Hetzner का UI इतना confusing लगता है कि manage करना मुश्किल है
संबंधित पोस्ट: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
हमेशा East 1 ही होता है. मज़ाक अलग, लेकिन समझ नहीं आता कि east-1 दूसरे regions की तुलना में इतना बार-बार क्यों गिरता है
Architecture के हिसाब से तो यह दूसरे regions जैसा ही होना चाहिए
इस पर दूसरे regions से ज़्यादा load होगा, और जब यह शुरू में बनाया गया था तब अनुभव कम था, इसलिए इसमें technical debt और architecture/engineering debt भी ज़्यादा होगी
याद है कि IAM और कुछ S3 configs जैसी services east-1 को single point of failure की तरह depend करती हैं
Coinbase ने कहा कि कई availability zones down हुई थीं, लेकिन AWS की घोषणा में कहा गया कि असर सिर्फ एक availability zone पर था
जानना चाहता हूँ कि किसी को इससे ज़्यादा detail पता है या नहीं
मैं us-east-1 में systems चला रहा हूँ, और incident के दौरान az4 के बाहर भी ऐसे intermittent connection issues दिखे जिन्हें explain करना मुश्किल था और पहले कभी नहीं देखा था
कई environments में सिर्फ single-AZ EBS volumes थोड़े खराब हुए, इसलिए यह निश्चित रूप से single availability zone (use-az4) की समस्या थी
मैंने पहले यह लाइन देखी थी कि “अगर कोई आपका दोस्त है, तो वह आपको USE1 इस्तेमाल नहीं करने देगा”, और फिर Slack में यह message आया कि USE1 और वहाँ deploy की गई सारी चीज़ें टूट गई हैं, तो वही बात याद आ गई
यहाँ comments में वही परिचित बातें हैं कि us-east-1 centralized है, AWS का single point of failure है, इसे ठीक करना चाहिए, और वहाँ चीज़ें नहीं रखनी चाहिए
लेकिन इस बार की घटना multi-AZ region के भीतर एक zone में मौजूद एक data center की समस्या थी
IAM/R53 वगैरह वहाँ centralized हैं, और उन services को de-centralized, cross-region architecture में बदलना अच्छा होगा. लेकिन us-east-1 खुद पहले से 6 zones वाला multi-AZ region है, और 2026 में 7वाँ zone आने वाला है, और zones के भीतर भी कई data centers हैं
जहाँ तक मुझे याद है, IAM जैसी global services जब गिरती हैं, तो कारण अक्सर “अगर यह cross-region होता तो नहीं मरता” से ज़्यादा implementation या dependency bugs होते हैं
इस बार AWS-wide global service outage नहीं था. जो सेवा ज़्यादा प्रभावित दिखी वह शायद MSK थी, और वह भी AWS की तुलना में Kafka की समस्या ज़्यादा लगती है
मैं सोच रहा हूँ कि ऐसी चीज़ें समुद्र के पास क्यों नहीं बनाते. जैसे nuclear power plants को भी बहुत cooling capacity चाहिए होती है
Heat exchanger के साथ 2-loop circulation से heat बाहर निकाली जा सकती है
1990s में दुनिया के लगभग आधे internet traffic ने MAE-East से होकर गुज़रा, और उसी का नतीजा था कि AWS ने अपना पहला region वहीं रखा. us-east-1, eu-west-1 से 2 साल पहले और us-west-1 से 3 साल पहले आया था
Data centers बनाने और उन्हें supply करने वाले लोग और कंपनियाँ बढ़ीं, तो Dulles Corridor कई कंपनियों के data centers का बड़ा hub बन गया
AWS के भीतर us-east-1 पहला region था, इसलिए यह बहुत अधिक complex और अजीब है, और दूसरे AWS services के कई control planes इस पर निर्भर हो गए. इसलिए यह दूसरे regions की तुलना में ज़्यादा बार गिरता है, और जब गिरता है तो Spain के eu-south-2 की तरह नहीं बल्कि national news बन जाता है
NoVA factories का मामला नहीं, बल्कि data centers का उदाहरण है; यह Paul Krugman के Nobel-winning research वाले economic cluster जैसा है
एक Hosting.com का SOMA data center था, जो इतना गर्म हो गया कि roof से hose से पानी छिड़ककर ठंडा करना पड़ा, और दूसरा Alibaba का Chai Wan data center था, जो इतना गर्म हुआ कि वहाँ चल रही हर चीज़, control plane सहित, down हो गई
इसलिए मुझे नहीं लगता कि समुद्र के पास होने से emergency heat rejection के लिहाज़ से कोई अतिरिक्त लाभ मिलता है. Heat को बाहर निकालने की capacity तय होती है, और चाहे जगह समुद्र किनारे हो या Nebraska के बीचोंबीच, पूरे system को एक निश्चित performance target पूरा करने के लिए design करना ही पड़ेगा
Slides में data center location selection को प्रभावित करने वाले factors थे, जिनमें पर्याप्त जगह और उस data center के लिए skilled labor मिलना भी शामिल था. उन्होंने यह भी कहा था कि कभी-कभी अगला data center कहाँ बनेगा, इसमें politics भी शामिल होती है
Coastal land बहुत महँगी होती है, और अगर दूरस्थ coast पर जाएँ तो power access अच्छी न होने की संभावना रहती है
Coastal sites आमतौर पर ज़्यादा severe weather को झेलती हैं
और कुछ बातें predict करना मुश्किल है. Diablo Canyon nuclear plant को मलबे और jellyfish migration की वजह से seawater cooling intake blockage की समस्या हुई थी
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
पानी पर्याप्त गहरा भी होना चाहिए, नहीं तो वह surface temperature तक गर्म हो जाएगा. और इसकी economics पारंपरिक evaporative cooling से competitive भी होनी चाहिए
इसका textbook example Toronto है. वहाँ coast के काफ़ी पास गहरी freshwater lake है, और downtown में real estate इतनी महँगी है कि पारंपरिक तरीका मुश्किल हो जाता है
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System