Cloudflare control plane और analytics सिस्टम आउटेज पर पोस्टमॉर्टम
(blog.cloudflare.com)- 2 नवंबर 2023 को 11:43 UTC से Cloudflare के control plane और analytics सेवाएं बाधित रहीं, जिससे dashboard/API बदलाव, logs और analytics functions प्रभावित हुए
- आउटेज की शुरुआत Flexential द्वारा संचालित Oregon के PDX-04 power outage से हुई, जहां सबसे बड़ा analytics cluster और high-availability cluster उपकरणों का एक-तिहाई से अधिक हिस्सा मौजूद था
- utility feed, generator, UPS और circuit breaker recovery में लगातार गड़बड़ियों ने PDX-04-विशेष Kafka·ClickHouse dependencies के कारण high-availability design को तोड़ दिया
- 2 नवंबर 13:40 UTC पर Europe disaster recovery site पर failover का फैसला लिया गया और 17:57 UTC तक अधिकांश customer impact कम हो गया, लेकिन log processing, कुछ bespoke API, Magic WAN manual configuration और Stream uploads ज्यादा देर तक प्रभावित रहे
- Cloudflare ने GA products के high-availability requirements, validated disaster recovery plans, पूरे core datacenter removal को शामिल करने वाले chaos testing, और log-loss prevention plans को Code Orange के तहत आगे बढ़ाया
आउटेज का दायरा और ग्राहक प्रभाव
- 2 नवंबर 2023 को 11:43 UTC से Cloudflare के control plane और analytics services में आउटेज शुरू हुआ
- control plane का मतलब customer-facing interfaces जैसे website और API है
- analytics services में logging और analytics reporting शामिल हैं
- पूरा incident 2 नवंबर 11:44 UTC से 4 नवंबर 04:25 UTC तक चला
- 2 नवंबर 17:57 UTC पर disaster recovery facility से अधिकांश control plane बहाल हो गया
- disaster recovery facility online होने के बाद, अधिकांश products में कई customers को शायद समस्या नहीं हुई होगी
- कुछ services को बहाली में अधिक समय लगा, और उन services का उपयोग करने वाले customers को पूरी तरह समाधान होने तक समस्याएं दिख सकती थीं
- raw log service incident की अधिकांश अवधि में ज्यादातर customers के लिए उपलब्ध नहीं थी
- Cloudflare की network और security services पूरे incident के दौरान अपेक्षित रूप से चलती रहीं
- एक अवधि ऐसी थी जब customers इन services में बदलाव नहीं कर सके
- Cloudflare network से गुजरने वाला traffic प्रभावित नहीं हुआ
मूल डिजाइन: Oregon के 3 datacenters पर आधारित high availability
- Cloudflare का control plane और analytics system मुख्य रूप से Oregon के Hillsboro के आसपास स्थित 3 datacenters के servers पर चलता है
- ये 3 datacenters एक-दूसरे से स्वतंत्र हैं, और हर एक में कई utility power feeds और कई redundant, independent network connections हैं
- इन facilities को इतनी दूरी पर चुना गया कि प्राकृतिक आपदा एक साथ सबको प्रभावित न कर सके, लेकिन इतना पास भी रखा गया कि active-active redundant data clusters चलाए जा सकें
- तीनों facilities लगातार data sync करती हैं
- design के अनुसार, अगर एक facility offline हो जाए तो बाकी facilities संचालन जारी रख सकें
- यह high-availability design 4 साल पहले लागू किया जाना शुरू हुआ था
- अधिकांश core control plane systems को high-availability clusters में migrate कर दिया गया था
- कुछ नए products की services अभी तक high-availability cluster में शामिल नहीं हुई थीं
- logging system को जानबूझकर high-availability cluster में शामिल नहीं किया गया था
- logs को network edge पर queue में रखा जाता है और फिर Oregon core या regional logging facilities में भेजा जाता है, इसे distributed problem की तरह handle किया जाता है
- अगर logging facility offline हो जाए, तो analytics logs edge पर रुके रहते हैं, और analytics delay को स्वीकार्य माना गया था
PDX-04 power outage की शुरुआत
- तीन Oregon facilities में सबसे बड़ी facility Flexential द्वारा संचालित PDX-04 है
- Cloudflare का सबसे बड़ा analytics cluster यहीं स्थित है
- high-availability cluster उपकरणों का एक-तिहाई से अधिक भी इसी facility में है
- यह उन services का default location भी है जो high-availability cluster में onboard नहीं हुई थीं
- Cloudflare इस facility की कुल क्षमता का लगभग 10% उपयोग करने वाला अपेक्षाकृत बड़ा customer है
- 2 नवंबर 08:50 UTC पर PDX-04 को बिजली देने वाली Portland General Electric(PGE) की independent power feeds में से एक में unplanned maintenance event हुआ
- इस event की वजह से PDX-04 की एक feed बंद हो गई
- Flexential ने बंद हुई feed की भरपाई के लिए generator चालू किया
- Flexential ने Cloudflare को generator power पर failover होने की जानकारी नहीं दी
- Cloudflare के observability tools power source बदलने का पता नहीं लगा सके
- अगर पहले से सूचना होती, तो Cloudflare इस facility को करीब से monitor कर सकता था और इस पर निर्भर control plane services को दूसरी जगह shift कर सकता था
- Flexential का बाकी utility feed और generator को एक साथ चलाना भी असामान्य था
- Flexential 10 generators चलाता है, जिनमें redundancy शामिल है, और वे facility का पूरा load संभाल सकते हैं
- केवल बाकी utility feed से भी facility चलाई जा सकती थी
- Cloudflare को यह स्पष्ट जवाब नहीं मिला कि Flexential ने utility power और generator power साथ में क्यों चलाई
अपुष्ट कारण और generator shutdown
- बाद की घटनाओं का root cause और कुछ operational decisions Flexential की ओर से स्पष्ट रूप से पुष्टि नहीं किए गए
- एक संभावित कारण यह हो सकता है कि Flexential ने PGE के DSG program में भाग लिया हो
- DSG ऐसा program है जिसमें regional utility company datacenter generators का उपयोग grid को अतिरिक्त बिजली देने के लिए कर सकती है
- इसके बदले utility company generator maintenance और fuel supply में मदद करती है
- Cloudflare को Flexential द्वारा DSG program की सूचना देने का कोई रिकॉर्ड नहीं मिला
- incident के समय DSG सक्रिय था या नहीं, इसका जवाब भी नहीं मिला
- लगभग 11:40 UTC पर PDX-04 के PGE transformer में ground fault हुआ
- Cloudflare का मानना है कि यह transformer datacenter में आने वाली दूसरी feed की voltage कम करने वाला उपकरण रहा होगा, लेकिन इसकी पुष्टि नहीं हुई
- यह भी पुष्टि नहीं हुई कि ground fault, पहली feed को प्रभावित करने वाले PGE के unplanned maintenance event से जुड़ा था या नहीं
- 12,470V high-voltage line में ground fault होने पर नुकसान रोकने के लिए electrical system को तेजी से shut down करने के लिए डिजाइन किया जाता है
- इसी protective action ने PDX-04 के सभी generators भी बंद कर दिए
- नतीजतन utility line और सभी 10 generators offline हो गए
- PDX-04 में UPS battery banks थे, जिनके बारे में बताया गया था कि वे लगभग 10 मिनट तक facility को चलाए रख सकते हैं
- यह समय power outage और generator auto-restart के बीच का gap भरने के लिए था
- Cloudflare के equipment failure observations के आधार पर batteries 4 मिनट में fail होने लगीं
- Flexential को generators restore करने में 10 मिनट से काफी अधिक समय लगा
बिजली बहाली में देरी और पहली सूचना
- Cloudflare को औपचारिक पुष्टि नहीं मिली, लेकिन Flexential कर्मचारियों से generator restoration में बाधा डालने वाले तीन factors के बारे में पता चला
- ground fault के कारण circuits जिस तरह trip हुए, उससे generators तक physical access करके manual restart करना पड़ा
- Flexential की access control system को battery backup power नहीं मिली थी, इसलिए वह offline थी
- रात की shift में अनुभवी operations या electrical specialists नहीं थे; वहां केवल security staff और नौकरी के पहले सप्ताह में एक unescorted technician था
- 11:44 से 12:01 UTC के बीच, generators पूरी तरह restart होने से पहले ही UPS batteries discharge हो गईं और datacenter के सभी customers ने power खो दी
- Flexential ने इस दौरान भी Cloudflare को facility issue की जानकारी नहीं दी
- Cloudflare ने 11:44 UTC पर पहली बार datacenter समस्या नोट की, जब facility को बाहरी दुनिया से जोड़ने वाले 2 routers offline हो गए
- routers तक direct या out-of-band management से पहुंच न होने पर Cloudflare ने Flexential से संपर्क किया और local team को facility भेजा
- Flexential का Cloudflare को पहला outage message 12:28 UTC पर आया
- message में कहा गया था कि PDX-04 का power issue लगभग 12:00 UTC पर शुरू हुआ, engineers restoration पर काम कर रहे हैं, और हर 30 मिनट में update दिया जाएगा
high-availability design में सामने आई dependency समस्या
- PDX-04 को निर्माण से पहले Tier III certified design मिला था और उससे high-availability SLA की उम्मीद थी, लेकिन Cloudflare ने इस facility के offline होने की संभावना भी योजना में रखी थी
- अपेक्षित प्रभाव analytics outage, edge पर log queueing और delays, तथा high-availability cluster में integrate न हुई low-priority services के temporary interruption तक सीमित होना चाहिए था
- बाकी दो datacenters द्वारा high-availability cluster संभालना और core services को online रखना बड़े स्तर पर योजना के अनुसार काम किया
- समस्या यह थी कि high-availability cluster में होने वाली कुछ services, केवल PDX-04 पर चलने वाली services पर निर्भर थीं
- log processing और analytics के लिए Kafka और ClickHouse केवल PDX-04 में उपलब्ध थे
- high-availability cluster में चल रही कुछ services इन्हीं पर निर्भर थीं
- यह dependency अधिक loosely coupled होनी चाहिए थी, failure को अधिक gracefully handle करना चाहिए था, और इसे पहले ही खोज लिया जाना चाहिए था
- Cloudflare ने high-availability cluster testing में बाकी दोनों facilities में से प्रत्येक को, और दोनों को साथ में भी, पूरी तरह offline किया था
- PDX-04 के high-availability हिस्से को offline करने वाले tests भी किए गए थे
- लेकिन पूरे PDX-04 facility को पूरी तरह offline करने वाला test नहीं किया गया था
- नए products और संबंधित databases को high-availability cluster में integrate कराने की requirements भी बहुत ढीली थीं
- product teams के alpha stage तक पहुंचने के रास्ते अलग-अलग थे
- समय के साथ backends को best practices के अनुसार migrate करना मॉडल था, लेकिन GA घोषित करने से पहले इसे औपचारिक requirement नहीं बनाया गया
- नतीजतन product-by-product redundancy protection एकसमान तरीके से काम नहीं कर रही थी
disaster recovery site पर स्विच
- 12:48 UTC पर Flexential ने generators restart किए और facility के कुछ हिस्सों में power वापस आई
- datacenter power restoration आमतौर पर एक circuit करके धीरे-धीरे किया जाता है
- जब Cloudflare circuits को वापस चालू करने की कोशिश की गई, तब circuit breakers खराब पाए गए
- यह पता नहीं चल सका कि breakers ground fault या surge के कारण खराब हुए, या पहले से ही उनमें समस्या थी
- Flexential ने खराब breakers बदलना शुरू किया
- facility में उपलब्ध stock से ज्यादा breakers खराब निकले, इसलिए नए breakers मंगवाने पड़े
- Cloudflare ने देखा कि अपेक्षा से अधिक services offline थीं, और Flexential restoration timeline नहीं दे पा रहा था, इसलिए 13:40 UTC पर Europe के disaster recovery site पर failover करने का फैसला लिया गया
- पूरे control plane का केवल छोटा हिस्सा ही failover करना था
- अधिकांश services बाकी दो core datacenters के high-availability systems पर चलती रहीं
- 13:43 UTC पर disaster recovery site से पहली service चालू की गई
- यह site disaster की स्थिति में core control plane services देने के लिए डिजाइन की गई थी
- यह कुछ log processing services को support नहीं करती थी
- services चालू होने के बाद, पहले fail हो रही API calls एक साथ आने लगीं और thundering herd समस्या हुई
- Cloudflare ने request volume नियंत्रित करने के लिए rate limiting लागू की
- इस अवधि में अधिकांश product customers को dashboard या API से changes करते समय intermittent errors दिखाई दे सकती थीं
- 17:57 UTC तक disaster recovery site पर ले जाई गई services स्थिर हो गईं और अधिकांश customers पर सीधा प्रभाव कम हो गया
- Magic WAN जैसे कुछ systems में अभी भी manual configuration की आवश्यकता थी
- log processing और कुछ bespoke API-related services, PDX-04 की restoration तक उपलब्ध नहीं हो सकीं
कुछ products की देरी से बहाली और PDX-04 restart
- कुछ products disaster recovery site पर सही तरीके से नहीं चल सके
- इनमें मुख्य रूप से वे नए products थे जिनके disaster recovery procedures पूरी तरह implement और test नहीं किए गए थे
- इनमें नए video uploads के लिए Stream service और कुछ अन्य services शामिल थीं
- Cloudflare teams ने दो रास्तों पर एक साथ काम किया
- disaster recovery site पर उन services को फिर से implement किया
- उन्हें high-availability cluster में migrate किया
- Flexential ने खराब circuit breakers बदले, दोनों utility feeds restore कीं, और 22:48 UTC पर stable power की पुष्टि की
- Cloudflare ने तय किया कि चूंकि teams पूरे दिन emergency response में लगी थीं, इसलिए अधिकांश staff आराम करेगा और अगली सुबह PDX-04 में return-to-service work शुरू करेगा
- इस फैसले से कुल restoration में देरी हुई, लेकिन अतिरिक्त गलतियों की संभावना कम करने के लिए यह निर्णय लिया गया
- 3 नवंबर की सुबह से PDX-04 services की restoration शुरू हुई
- network equipment को physical boot किया गया
- हजारों servers चालू किए गए और services restore की गईं
- incident के दौरान कई बार power cycling हुई हो सकती थी, इसलिए datacenter के अंदर services की स्थिति अज्ञात थी
- सुरक्षित restoration procedure पूरे facility के complete bootstrap का पालन करना था
- configuration management servers को manually online लाया गया, जिसमें 3 घंटे लगे
- इसके बाद बाकी servers को bootstrap method से rebuild किया गया
- प्रत्येक server rebuild में 10 मिनट से 2 घंटे तक लगे
- कई servers पर parallel execution किया गया, लेकिन service dependencies के कारण कुछ recovery steps sequential रहे
- सभी services 4 नवंबर 2023 को 04:25 UTC पर पूरी तरह restore हो गईं
- अधिकांश customers के लिए dashboard और API की अधिकतर analytics में data loss नहीं होने की उम्मीद है, क्योंकि analytics data Europe core datacenter में भी stored था
- कुछ datasets जो EU में replicate नहीं हुए थे, उनमें स्थायी gaps रह गए
- Logpush उपयोग करने वाले customers के logs incident की अधिकांश अवधि में process नहीं हुए, और जो logs नहीं मिले वे recover नहीं किए जा सके
Code Orange और सुधार योजना
- Cloudflare ने कहा कि उसे Flexential से अभी भी कई सवालों के जवाब चाहिए, लेकिन full datacenter outage को भी planning assumption मानना होगा
- Google के Code Yellow और Code Red की तरह, उसने Code Orange नाम की अपनी प्रक्रिया शुरू की, जिसका उद्देश्य major incidents या crises के दौरान engineering resources को समस्या समाधान पर केंद्रित करना है
- non-core engineering functions को control plane की high reliability सुनिश्चित करने वाले कामों पर लगाया गया
- planned changes इस प्रकार हैं
- सभी services के control plane configuration से core datacenter dependencies हटाना, और जहां संभव हो Cloudflare के distributed network को पहले चलने लायक बनाना
- यह सुनिश्चित करना कि सभी core datacenters offline होने पर भी network पर चलने वाला control plane काम करता रहे
- core datacenters पर निर्भर GA products और features के लिए यह अनिवार्य करना कि वे किसी specific facility पर software dependency के बिना high-availability clusters पर निर्भर हों
- GA products और features के लिए tested और reliable disaster recovery plans अनिवार्य करना
- system failures के blast radius का test करना और outage से प्रभावित services की संख्या कम करना
- सभी datacenter functions के लिए अधिक सख्त chaos testing लागू करना, जिसमें हर core datacenter facility को पूरी तरह हटाने वाले scenarios भी शामिल हों
- सभी core datacenters का गहन audit करना और standards compliance सुनिश्चित करने के लिए re-audit plan बनाना
- सभी core facility failures की स्थिति में भी logs न खोएं, इसके लिए logging और analytics disaster recovery plan बनाना
- Cloudflare ने निष्कर्ष निकाला कि जरूरी systems और procedures होने के बावजूद, उन्हें follow कराने और unknown dependencies को test कराने वाली सख्ती पर्याप्त नहीं थी
1 टिप्पणियां
Hacker News की रायें
पोस्ट का ज़्यादातर हिस्सा किसी खास vendor का नाम लेकर ज़िम्मेदारी डालने और root cause का अनुमान लगाने में लगाना अजीब चुनाव था
यह खुलासा करना कि वे facility में एक बड़े ग्राहक हैं, और vendor द्वारा Confidential चिह्नित किए गए electrical diagrams को भी postmortem में शामिल करना भी काफ़ी अनुचित लगता है
घटना के trigger और context को समझाना समझ में आता है, लेकिन postmortem का focus vendor नहीं, Cloudflare की outage होनी चाहिए
Flexential को भी अपना postmortem करना चाहिए, लेकिन Cloudflare को उनकी तरफ़ से अंदाज़ा लगाकर सार्वजनिक रूप से बताने की ज़रूरत नहीं है
किसी और के narrative बनाने से पहले Cloudflare की तरफ़ से proactive explanation देने का उद्देश्य भी हो सकता है
तीन parties और कई interconnected systems वाली स्थिति में, Cloudflare अगर आगे ऐसी compound failure modes को design में शामिल करना चाहता है, तो अंत तक यह जानना कि क्या हुआ था, वाजिब है
निजी तौर पर, Cloudflare ने जो जानकारी साझा की, उसके लिए मैं आभारी हूँ
core काम न कर पाने की 99% ज़िम्मेदारी Cloudflare पर है
किसी third party में इतनी गहराई से खोदना उल्टा दिखाता है कि यह घटना Cloudflare के लिए कितनी शर्मनाक है
लगता है circuit breaker inspection भी ठीक से नहीं किया गया, और relatively नई facility होने के बावजूद generator batteries charge करने के लिए 10 घंटे का आधा समय भी नहीं मिल पाया
इस maintenance के दौरान उन्हें पूरी तरह generators पर switch करना चाहिए था, और शायद PGE की मदद करने के चक्कर में ऐसा नहीं कर पाए
मुझे लगता है Cloudflare CEO सही हैं। data center services के लिए आप पूर्ण redundancy की उम्मीद करके पैसे देते हैं, और कहा जाता है कि इस location पर 18MW है, लेकिन दिखने में यह भी साफ़ नहीं कि feeds सिर्फ़ 2 हैं या नहीं
अगर एक feed down हो जाए तो 2N configuration आनी चाहिए, और generators हों तो समस्या नहीं होनी चाहिए
तो अब तक समझ में आए initial event की explanation शामिल होना भी सही है
follow-up analysis आने की संभावना काफ़ी लगती है
https://twitter.com/eastdakota/status/1720688383607861442?t=...
quoted हिस्से को देखें तो outage का root cause single data center dependency था
ज़्यादातर core control plane systems को high-availability cluster में move कर दिया गया था, लेकिन कुछ नए products अभी नहीं थे; और high-availability cluster में होने वाली कुछ services PDX-04 में ही चलने वाली services पर निर्भर थीं; साथ ही कुछ products disaster recovery site पर ठीक से नहीं चल पाए
Internet के महत्वपूर्ण हिस्से को संभालने वाली Cloudflare जैसी company के लिए यह काफ़ी शर्मनाक है
कहा गया कि Cloudflare ने कई teams को तेज़ innovation की अनुमति दी, इसलिए products initial alpha तक अलग-अलग रास्तों से गए, और समय के साथ best practices पर move करते हैं, लेकिन general availability से पहले इसे mandatory condition नहीं बनाया गया
यह साफ़ management failure है। क्या ग्राहकों को Cloudflare के internal standards के हिसाब से alpha-quality software ही बेच दिया गया था?
https://news.ycombinator.com/item?id=38113503
self-awareness की कमी लगती है
यह amateur-level है, खासकर यह बात गंभीर है कि नई services high availability के बिना launch हुईं
इस outage से थोड़ा प्रभावित व्यक्ति के तौर पर, मुझे यह postmortem अपर्याप्त लगता है
75% हिस्सा PDX-04 की power failure और Flexential की ज़िम्मेदारी पर है; text से लगता है कि वहाँ जो हुआ वह disaster के क़रीब था, इसलिए यह समझ में आता है
लेकिन 2 नवंबर UTC तक power पूरी तरह restore हो गई थी, और उसके बाद भी Cloudflare को complete recovery में लगभग 30 घंटे और लगे, ऐसा लिखा है
recovery outage से भी लंबी रही, लेकिन post बस इतना कहता है कि बहुत सारी services एक-दूसरे पर निर्भर थीं। मैं और detail जानना चाहता हूँ कि full operational recovery में इतना समय क्यों लगा
क्या recovery process से खुद कोई lessons नहीं मिले? या सच में edge से “brain” तक data को फिर से sync करने में ही इतना समय लगा?
एक और missing part खास तौर पर enterprise customers के साथ communication की कमी है। Cloudflare support status page के अलावा लगभग चुप था, और वास्तविकता में करने के लिए बहुत कुछ न भी रहा हो, फिर भी communication की कोशिश ज़रूरी थी
postmortem में Flexential की communication कमी को दोष देने के बाद तो और भी ज़्यादा; Cloudflare के products मुझे पसंद हैं, लेकिन मुझे लगता है इस incident से और निष्कर्ष निकालने चाहिए
हालांकि इसे postmortem कहना थोड़ा off लगता है। complete postmortem में ऊपर बताए स्तर की detail होनी चाहिए
logging down हो तो exactly कौन-सी services fail होती हैं? क्या यह अनजाने में ऐसा बना था? किसी ने notice क्यों नहीं किया?
Cloudflare की पोस्टमॉर्टम analysis इतनी thorough है, यह अच्छी बात है
ईमानदार और transparent explanation लगभग हर दूसरी company की vague communication strategy की तुलना में refreshing है
हम भी प्रभावित हुए थे, लेकिन ऐसे लेखों की वजह से उल्टा छोड़कर जाने का मन नहीं करता। कोई भी गलती कर सकता है और बुरा दिन आ सकता है; फर्क इस बात से पड़ता है कि उसके बाद response कैसे दिया जाता है
power failure के लिए एक paragraph काफी था, और उसके बाद बात Cloudflare की तरफ मुड़नी चाहिए थी। datacenter failures हो सकते हैं
असली सीख इस बात में है कि उस स्थिति को ठीक से ध्यान में रखकर recover न कर पाने वाली Cloudflare की response कैसी थी
हम CloudFlare Images पर काफी निर्भर हैं, और पिछले 30 दिनों में यह 67 घंटे से ज्यादा down रहा
9 अक्टूबर को 22 घंटे, 2–4 नवंबर को 42 घंटे, बीच-बीच में लगभग 1 घंटे के outages हुए, और पिछले महीने की availability 90.6% रही
transparency उन providers के बीच शानदार differentiator है जो 99.9% availability की range में compete करते हैं, लेकिन अगर barely single-digit 9 से ऊपर पहुंच रहे हों तो इसका खास मतलब नहीं रहता
इससे behavior improve करने में ज्यादा मदद नहीं मिलती, और incentives और खराब हो सकते हैं
यहां process errors को ठीक करने की बात सराहनीय है। हालांकि तेजी से move करने और पूरी तरह sure होने के बीच tension होता है
आम तौर पर ऐसी चीज़ों को मौसम जैसा treat किया जाता है, यानी बारिश में भीगने के बाद raincoat खरीदना
मैं जानना चाहूंगा कि development को process से बांधे बिना reliability को culture का हिस्सा कैसे बनाया जाए
system को software से model किया जा सकता है, और traffic analysis से उस model को validate किया जा सकता है। अगर virtual experiments से reliability experiment cost घट सके, तो शायद release से पहले ज्यादा issues पकड़े जा सकें
यह लेख पढ़कर उल्टा Cloudflare पर मेरा भरोसा कम हो गया, यह अजीब है
वे Flexential पर unprofessional तरीके से काम करने का कड़ा आरोप लगा रहे हैं, और संभव है कि ऐसा हुआ हो
लेकिन जिस पूरे system पर लोग निर्भर हैं उसका down हो जाना Cloudflare की तरफ से एक बहुत बड़ी redundancy failure है। ऐसे एक datacenter के खत्म होने पर भी service चलती रहनी चाहिए
खास तौर पर यह चिंता की बात है कि intended design ही इस बात से शुरू होता है: “Cloudflare का control plane और analytics systems मुख्य रूप से Oregon Hillsboro के पास 3 datacenters के servers पर चलते हैं”
दुनिया भर में इस्तेमाल होने वाले control plane के लिए कहीं ज्यादा व्यापक geographic distribution चाहिए। यह defective implementation नहीं बल्कि intended design stage था, यह और भी हैरान करने वाला है
अगर कोई नया product consumers को दे रहे हैं, तो redundancy design top priority नहीं होना चाहिए? यह optional था, यही surprising है
मैं भी कुछ systems में Cloudflare इस्तेमाल करता हूं, क्योंकि मुझे भरोसा था कि ऐसे incidents होने पर भी शानदार failover होगा। अब फिर सोच रहा हूं कि Cloudflare Workers ऐसे design decisions से सच में safe हैं या नहीं
disaster recovery site चालू करने पर failing API calls की भीड़ से service overwhelmed हो गई, यह भी आखिरकार इसलिए हुआ क्योंकि Cloudflare का core design पर्याप्त रूप से redundant नहीं था
Flexential पर जिम्मेदारी डालने की कोशिश करने वाले इस लेख से निराशा हुई। customer के नजरिए से, अगर Flexential कल earthquake में गायब भी हो जाए, तो Cloudflare से उम्मीद है कि वह इसे gracefully handle करेगा
इतने critical cluster को पूरी तरह एक जाने-माने earthquake और tsunami risk zone में रखना क्या अच्छा idea है?
European disaster recovery भी ठीक से काम करती नहीं लगी
“हमने PDX-04 facility को पूरी तरह offline करने का test कभी नहीं किया था” — यह एक कड़वा सबक है
लेकिन जब तक datacenter की power physically बंद न की जाए, या कम से कम बाहरी दुनिया से network न काटा जाए, तब तक असली disaster test नहीं हुआ
facility operator को दोष दिया जा सकता है, लेकिन आखिरकार एक datacenter पूरी तरह offline होकर कभी वापस न आए, तब भी recover कर पाना चाहिए
natural disaster उस facility को धरती से मिटा भी सकता है
“क्योंकि team पूरे दिन emergency response में लगी रही, हमने फैसला किया कि ज्यादातर लोग rest करें और सुबह PDX-04 पर वापस लौटने का काम शुरू करें। इस फैसले ने full recovery को delay किया, लेकिन हमें लगता है कि इससे additional mistakes जुड़ने की संभावना कम हुई” — यह हिस्सा अच्छा लगा
ऐसी reports में human fatigue को अक्सर underestimate किया जाता है। बहुत ज्यादा थके हुए हालत में बड़े outage को fix करने की कोशिश सिर्फ avoidable mistakes बढ़ाती है
Cloudflare के scale की organization में यह कैसे काम करेगा, पता नहीं, लेकिन हमारे यहां भी बड़े outage पर employees के shifts में काम करने और सोने का plan है
समस्या यह है कि जागकर या connect होकर आने वाले नए लोगों को current outage state hand over करने का तरीका चाहिए
Mike Tyson के शब्दों में, चेहरे पर मुक्का लगने से पहले तक हर किसी के पास plan होता है
लेख की structure काफी चौंकाने वाली है। blog का 75% हिस्सा third party की कहानी से भरा है, और Cloudflare की अपनी recovery efforts को बहुत कम paragraphs में cover किया गया है
आगे का path दिखाना positive है, लेकिन सोचता हूं कि अभी failures और situation को ही acknowledge करके, बाद में धूल बैठने पर बिना speculation वाली पूरी postmortem analysis क्यों नहीं निकाली गई
investors इस लेख या summary को देखकर इसे महीनों की rework और millions of dollars cost वाली deep problem के बजाय simple supplier issue मानकर आगे बढ़ सकते हैं
document अच्छा नहीं है
3 datacenters वाला high-availability setup था, जो पूरी तरह fail हो गया
document की शुरुआत datacenter operator को दोष देने से क्यों भरी है? datacenter facility management Cloudflare के control से बाहर है
Cloudflare ने यह gamble किया कि उसके control में मौजूद high-availability configuration testing ठीक से न करने पर भी कोई समस्या नहीं होगी
datacenter operations की problem operator के साथ discuss करनी चाहिए, लेकिन वह दोनों parties के बीच की बात है, इस postmortem में आने वाली चीज़ नहीं
अहम बात को सच में बहुत गहराई में दबा दिया गया है। काफी देर स्क्रॉल करने के बाद यह वाक्य आता है
“कुछ सेवाएँ, जिन्हें high-availability cluster में होना चाहिए था, PDX-04 में ही चलने वाली सेवाओं पर निर्भर थीं”
असल मुद्दा यही है
अगर “disaster” site बनाते हैं, तो test करने का कोई-न-कोई तरीका ढूँढना ही चाहिए
कहा गया कि services चालू होते ही fail हो रही API calls का सैलाब आ गया, जिससे thundering herd problem पैदा हुई, और request volume को control करने के लिए rate limiting implement की गई
लेकिन लगता है यह बात लेख के अंत वाली items में छूट गई है
अब जिज्ञासा यह है कि जब system इतना complex हो कि metastable failure[1] पैदा कर सकता हो और real traffic से test करने की गुंजाइश न हो, तब cold failover कैसे design किया जाए
implementation में इस्तेमाल होने वाली techniques का अंदाज़ा लगाया जा सकता है, लेकिन समस्या यह है कि design और testing से कैसे verify करें कि वे techniques वास्तविक स्थिति में काम करेंगी
एक और बात जो पूरी तरह छूटी लगती है: outage 2 नवंबर 11:43 UTC पर शुरू हुआ, लेकिन European disaster recovery site पर switch करने का फैसला 13:40 UTC पर लिया गया
फैसला लेने में इतना समय क्यों लगा? समझ में आता है कि यह हल्का-फुल्का फैसला नहीं है, लेकिन भले ही ज्यादातर समय उन्हें उम्मीद रही हो कि power जल्द बहाल हो जाएगी, 2 घंटे बहुत ज्यादा हिचकिचाहट जैसे लगते हैं
कोई भी commitments हों, switch दबाने के लिए पहले से तय threshold होना चाहिए। क्या वह threshold सचमुच इतनी दूर रखी गई थी?
[1] http://charap.co/metastable-failures-in-distributed-systems/
अक्सर failure पैदा करने वाली चीज़ खुद redundant systems ही होती हैं