Cloudflare API डाउन

 (news.ycombinator.com)
1 पॉइंट द्वारा GN⁺ 2023-11-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare Dashboard और API की रुकावट Control Plane API और product services को Portland के मुख्य datacenter पर वापस ले जाने के बाद resolved स्थिति में आ गई
  • API infrastructure पर निर्भर Dashboard features, Alerts, Zero Trust, WARP, Pages, Workers आदि में request failures और error displays हो सकते थे
  • Cloudflare ने datacenter में बिजली कटने का आकलन करते हुए services को failover किया, और North America के core datacenter में बिजली आंशिक रूप से बहाल होने के बाद core services को backup datacenter पर शिफ्ट कर असर कम किया
  • असर data plane और control plane में बंटा था, और Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates आदि समय के हिसाब से unavailable, degraded, restored स्थितियों के बीच बदलते रहे
  • incident के दौरान कुछ Logpush logs और analytics data खो गए; अंत के समय के आसपास के logs के recover होने की संभावना थी, लेकिन चल रहे incident के दौरान पूरे impact scope की पुष्टि नहीं हुई थी

Dashboard और API outage का दायरा

  • Cloudflare ने Cloudflare Dashboard और संबंधित API issues की जांच व recovery की, और users को Dashboard/API request failures या error displays का सामना करना पड़ सकता था
  • outage Cloudflare API infrastructure पर निर्भर कई services तक फैल गया
    • Alerts
    • Dashboard functionality
    • Zero Trust
    • WARP
    • Cloudflared
    • Waiting Room
    • Gateway
    • Stream
    • Magic WAN
    • API Shield
    • Pages
    • Workers
  • Cloudflare ने कहा कि यह समस्या Cloudflare CDN की cached files serving या Cloudflare Edge की अन्य security features को प्रभावित नहीं करती

बिजली कटने के बाद failover और Portland recovery

  • Cloudflare ने datacenter को प्रभावित करने वाले बिजली कटने का आकलन करते हुए साथ-साथ services को failover किया
  • North America के core datacenter में बिजली आंशिक रूप से बहाल होने के बाद, कुछ core services को backup datacenter पर failover किया गया, जिससे असर कम हुआ
  • recovery process में कई updates में “gradual improvement” और “restore full functionality” स्थितियां दोहराई गईं
  • अंतिम चरण में Control Plane API और product services को Portland के मुख्य datacenter पर वापस लाया गया
    • 2023-11-06 17:00 UTC से Portland के primary HA datacenters पर Control Plane API और Product Services की recovery शुरू की गई
    • recovery work के लिए लगभग 2 घंटे बताए गए थे, और इस दौरान Cloudflare API और Dashboard availability घट सकती थी
    • 2023-11-06 18:30 UTC से Pages और Workers Control Plane API तथा Product Services को भी Portland के मुख्य datacenter पर recover करना शुरू किया गया
    • recovery पूरी होने के बाद भी Cloudflare ने stability और edge cases की monitoring जारी रखी

data plane में टूटे features

  • data plane impact को उस दायरे के रूप में परिभाषित किया गया जहां product की पूरी functionality आंशिक या पूरी तरह प्रभावित हुई
  • शुरुआती प्रभावित services में Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API, Alert Notification System शामिल थे
  • recovery के दौरान जिन प्रमुख services की स्थिति बदली, वे इस प्रकार हैं
    • Logpush: कई customers को logs नहीं मिले, और कुछ logs खो गए हो सकते थे। बाद में और jobs recover हुए, और बताया गया कि अधिकांश jobs 07:00 UTC तक recover हो जाएंगे
    • Analytics / GraphQL API: कई customers का analytics data Dashboard और API में unavailable था, और बाद में कुछ या अधिकांश analytics recover हुए, लेकिन कुछ datasets बाकी थे
    • Workers Analytics Engine: कई updates में unavailable ही रहा
    • Stream API: not available से degraded performance but available में गया, और बाद में restored स्थिति में आ गया
    • Healthchecks: not available से analytics के बिना restored स्थिति में आया, और बाद में Healthcheck analytics भी restored में गया
    • Radar: degraded स्थिति जारी रही, फिर Cloudflare Radar operational status में recover हुआ
    • Support Services: Support portal unavailable होने के दौरान Enterprise customers Enterprise support email address पर ticket खोल सकते थे, और बाद में Portal, Phone, Chat operational हो गए
    • CASB: not available या degraded performance स्थिति में था, और मौजूदा CASB Findings देखे जा सकते थे लेकिन scanning offline थी। बाद में CASB API online हुआ और बताया गया कि scanning engine recovery में है तथा data loss की उम्मीद नहीं है
    • DEX: not available स्थिति से DEX API online में गया, और fleet status, HTTP, Traceroute Test Result data recovery में थे; Saturday Nov 4 15:00 UTC के आसपास recovery की उम्मीद थी
    • DNS Updates: degraded से restored में गया

control plane में सीमित configuration changes

  • control plane impact को उस दायरे के रूप में परिभाषित किया गया जहां product functionality edge पर चलती है, लेकिन मौजूदा configuration changes प्रभावित होते हैं
  • शुरुआती प्रभावित services में Magic Transit, Argo Smart Routing, Workers KV, WAF, Rate Limiting, Rules, WARP/Zero Trust Registration, Waiting Room, Load Balancing and Healthchecks, Cloudflare Pages, Zero Trust Gateway, DNS Authoritative and Secondary, Cloudflare Tunnel, Workers KV namespace operations, Magic WAN, Cloudflare Images शामिल थे
  • recovery के दौरान जिन प्रमुख services की स्थिति बदली, वे इस प्रकार हैं
    • Cloudflare API: degraded but accessible या restored स्थिति में update हुआ
    • Cloudflare Pages: degraded but online से restored में गया, और कुछ समय तक project creation/deletion तथा direct upload deployments degraded थे
    • Magic Transit / Magic WAN: changes unavailable स्थिति से configuration plane के internally काम करने की स्थिति में गया, और urgent changes के लिए account team से संपर्क करने की सलाह थी
    • Argo Smart Routing: configuration काम कर रहा था, लेकिन smart updates और analytics offline थे
    • Billing API / Registrar API: कुछ समय तक केवल read-only operations संभव थे
    • Lists: list item update अस्थायी रूप से suspended था, और Dashboard में काम करता था लेकिन API में 429 error लौटा सकता था। बाद में restored status में गया, लेकिन कुछ समय तक केवल Dashboard से ही edits संभव थे
    • SSL / SSL for SaaS: SSL provisioning delay और custom hostname validation delay था, और बाद में restored स्थिति में आ गया
    • Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments भी updates के हिसाब से degraded, unavailable, restored स्थितियों के बीच बदलते रहे

खोए हुए logs और post-mortem

  • Cloudflare ने कहा कि incident के दौरान कुछ Logpush logs और analytics data खो गए
  • incident खत्म होने के समय के करीब के logs के recover होने की संभावना थी, लेकिन चल रहे incident के दौरान पूरे impact scope का अभी पता नहीं था
  • एक update में बताया गया कि सभी logs और analytics pipeline Saturday 4th November 2023 7AM UTC तक operational स्थिति में होंगे
  • बाद के update में कहा गया कि “अधिकांश logs incident के दौरान खो गए”, और incident resolve होने के बाद पूरा assessment देने की बात कही गई
  • अधिक जानकारी Cloudflare के post-mortem on Cloudflare control plane and analytics outage में देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-11-05
Hacker News की राय

  • जब मैंने लगभग 3 साल पहले वहाँ काम किया था, तब संरचना ऐसी थी कि PDX बंद हो जाए तो केंद्रीय सिस्टम बंद हो जाता था
    DDoS defense जैसी चीज़ें पहले से हर PoP के अंदर संभाली जाती थीं, इसलिए L3/L7 flood या नए हमलों से निपटा जा सकता था, लेकिन लगभग बाकी सब कुछ PDX में compute होने के बाद config data के रूप में हर PoP में deploy किया जाता था
    फ्लो यह था: PoP data generate/collect करता → PDX को भेजता → PDX में compute होता → updates/data वापस PoP में distribute होते, और अगर PDX बंद हो जाए तो latest data पर निर्भर कई features धीरे-धीरे stale state में चलने लगते थे
    मुझे नहीं लगता कि उसके बाद सब कुछ बदल गया होगा, इसलिए यह सिर्फ “API डाउन” से ज़्यादा, load balancing, tiered cache, Argo Smart Routing, Warp/Zero Trust जैसी सुविधाओं के PDX update के बिना पुरानी state information पर चलने से performance degradation की स्थिति होने की संभावना है
    भले ही केवल “API डाउन” ही हो, बहुत-से customer automation API calls के ज़रिए attacks को block करते हैं, इसलिए attackers के लिए यह काफ़ी बड़ा मौका बन जाता है
    नौकरी छोड़ने से ठीक पहले AMS स्थापित करने में निवेश हो रहा था, लेकिन बड़े failover tests कभी सफल नहीं हुए थे, और latest state की ज़रूरत वाली ज़्यादातर services उस तरीके को जानती भी नहीं थीं
    जोड़कर कहूँ तो ज़्यादातर observability भी PDX-आधारित थी, इसलिए जो टीमें और SREs अभी बिना साफ़ visibility के भाग-दौड़ कर रहे होंगे, उन्हें मेरी संवेदनाएँ

    • दूसरी तरफ़ से किसी ने PDX02 की पूरी outage होने की बात पोस्ट की थी, और latest status updates देखें तो यही root cause लगता है
      Cloudflare ने कहा कि वह data center को प्रभावित करने वाली power loss का आकलन करते हुए साथ ही service failover भी चला रहा है
      utility power कट गई थी और generator पर switch किया गया, लेकिन generator भी fail हो गया; अब कुछ utility power वापस आई है और लगता है site का कुछ हिस्सा recover हो रहा है
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • अगर मुझे सही याद है, AMS एक नया data center था जिसे पहले PDX के failover सहायक की भूमिका निभाने वाले LUX को replace या reinforce करने के लिए लाया जा रहा था
      लेकिन इरादा और हक़ीक़त में हमेशा फ़र्क होता है, और मैंने कई वजहें सुनी थीं कि दुनिया के दूसरे छोर वाले data center में automatic या emergency manual failover करना बहुत-से workloads के लिए व्यावहारिक समाधान नहीं था
      Cloudflare बहुत chaos testing करता है, और पूरे data center network isolation की testing भी बहुत नियमित रूप से करता है
      यह घटना आखिर इतनी अलग क्यों थी, इस पर होने वाली discussion meeting में छिपकर बैठना दिलचस्प होगा
    • कुछ साल पहले तक tiered cache और Argo अलग-अलग features थे
      मैंने सीधे तौर पर उनमें से केवल एक बनाया था, लेकिन marketing में दोनों को हमेशा साथ बाँधकर पेश किया जाता था
      अगर आप API से tiered cache topology customize करने वाले enterprise user नहीं हैं, तो cache topology कुछ दिन या कुछ हफ़्ते पुरानी हो जाए तब भी शायद आम तौर पर ठीक रहेगा
      लेकिन जैसा कहा, दूसरी बहुत-सी चीज़ें समस्या झेल सकती हैं
    • generator, air conditioner, UPS, और automatic transfer switch सब mechanical devices हैं, इसलिए breakdown के लिए संवेदनशील होते हैं
      maintenance और advance planning कितनी भी अच्छी हो, अंततः ऐसी परिस्थितियाँ आ सकती हैं जिनकी उम्मीद नहीं की गई थी या जिनके लिए लागत के कारण तैयारी नहीं की गई, और ऐसे में critical infrastructure के गिरने की संभावना 0 नहीं होती
    • outage के काफ़ी समय तक DNS updates भी बंद रहे
      dashboard UI updates के लिए API का उपयोग करता दिखता है, इसलिए संभवतः यह API access performance degradation के कारण था
      UI में DNS updates लागू होते हुए दिख रहे थे, लेकिन असली propagation नहीं हो रही थी, और outage के बाद Cloudflare dashboard में domain को पूरी तरह delete करके फिर से बनाना पड़ा, तब जाकर SSL और DNS propagation ने फिर काम करना शुरू किया

  • 12 घंटे बीत गए, फिर भी समस्या जारी है
    मैं online music production की class ले रहा हूँ, और videos Cloudflare Stream पर अपलोड हैं, लेकिन एक भी play नहीं हो रही
    https://www.cloudflare.com/products/cloudflare-stream/
    इंटरनेट के आधे हिस्से के single point of failure की समस्या फिर सामने आ रही है

    • अब 24 घंटे हो चुके हैं और Stream अभी भी recover नहीं हुआ है
    • इसमें लिखा है, “यह समस्या Cloudflare CDN के ज़रिए cached files की delivery या Cloudflare Edge की दूसरी security features को प्रभावित नहीं करती”
      https://www.cloudflarestatus.com/incidents/hm7491k53ppg
      मुझे लगा था कि असर सिर्फ dashboard और उसके अंदर की functionality पर है, लेकिन अगर Cloudflare video streaming काम नहीं कर रही, तो शायद बात वैसी नहीं है

  • मुझे ठीक-ठीक नहीं पता, लेकिन Cloudflare कुछ असहज-सा लगता है
    समझ नहीं आता कि इतने लोग इंटरनेट के बड़े हिस्से के लिए एक ही कंपनी पर निर्भर रहना क्यों ठीक मानते हैं

    • सिद्धांत रूप से मैं सहमत हूँ, लेकिन ऐसा लगता है कि ऐसी बात Amazon(AWS), Google, Microsoft जैसी कंपनियों की तुलना में Cloudflare पर ज़्यादा आसानी से चिपक जाती है
      मेरी धारणा ग़लत भी हो सकती है, लेकिन Cloudflare इन oligopolistic दिग्गज कंपनियों के मुक़ाबले एक भरोसेमंद challenger जैसा लगता है, और काश Cloudflare जैसी और कंपनियाँ होतीं
    • मुझे नहीं लगता कि लोग Cloudflare पर निर्भर रहना चाहते हैं; बल्कि Cloudflare का track record अच्छा है और इसकी base services मुफ़्त हैं, इसलिए ऐसा हुआ है
      सच कहूँ तो Cloudflare जैसी उदार free tier देने वाली मिलती-जुलती service मुझे ज़्यादा नहीं पता
    • निर्भरता के अलावा, यह भी समस्या है कि design के हिसाब से Cloudflare विशाल TLS traffic के man-in-the-middle की भूमिका में है
      TLS सही तरह इस्तेमाल किया जाए तो end-to-end security देता है, लेकिन Cloudflare इस्तेमाल करने पर Cloudflare को सारा plaintext traffic access करने की क्षमता मिल जाती है
    • कोई मुफ़्त, बल्कि सस्ता विकल्प भी नहीं है
      अगर कोई छोटी site DoS का निशाना बन सकती है, तो आखिरकार Cloudflare का इस्तेमाल करना ही पड़ता है
    • Cloudflare दूसरी cloud providers की तरह आख़िरी पैसे तक निचोड़ने की कोशिश नहीं करता, और उसका product packaging काफ़ी fair लगता है
      यह मेरी निजी छाप है, और मैं ग़लत भी हो सकता हूँ

  • लगा था कि कुछ दिन पहले उस bug को फिर से commit कर दिया गया है
    https://blog.cloudflare.com/cloudflare-incident-on-october-3...
    ऐसा नहीं था, यह मुख्य डेटा सेंटर में बिजली की खराबी जैसा लग रहा है
    ज़्यादा जानकारी दूसरे comments में है

    • जब भी Cloudflare डाउन होता है, मुआवज़े की तरह कोई दिलचस्प पोस्ट पढ़ने को मिल जाती है
      अब तो हालत ऐसी है कि Pavlov के कुत्ते की तरह outage का मज़ा आने लगा है

  • पिछले हफ्ते में ही यह दूसरी outage है
    dead comment के जवाब में जोड़ूँ तो, इसका programming language के चुनाव से कोई संबंध नहीं है

  • DreamHost में भी Pacific time सुबह 4:54 से PDX में समस्या है
    https://www.dreamhoststatus.com

  • बताया गया है कि Flexential PDX02 ने इसी घटना की शुरुआत के आसपास बिजली खो दी थी

    • यह जुड़ा हुआ लगता है
      Cloudflare ने अभी कहा है कि वह डेटा सेंटर को प्रभावित करने वाली power loss का आकलन करते हुए साथ ही service outage mitigation पर काम कर रहा है
    • यह कैसे हुआ होगा, सोच रहा हूँ
      हमारे यहाँ के Flexential में 5 generators, basement में battery backup, और isolation zones हैं
    • तुम्हें क्या लगता है, cause क्या है और effect क्या?

  • सबसे प्रभावशाली बात यह है कि status page सच में काम कर रही है

    • “Atlassian Statuspage द्वारा संचालित”
    • यह विडंबना है कि ढेरों services आउटेज में चली जाती हैं, लेकिन status page शायद ही कभी डाउन होती है
      हाँ, संभव है कि उसे कहीं और host किया गया हो, लेकिन हर बड़े outage पर यही सोचकर हँसी आती है

  • ज़्यादा अच्छा नहीं लग रहा
    उम्मीद है कि इस वजह से वे अपनी ही service इस्तेमाल करना बंद नहीं करेंगे
    Vercel deployments और edge functions भी काम नहीं कर रहे
    status page पर लिखा है, “हमने अपने upstream providers में से एक की समस्या को root cause के रूप में पहचाना है और mitigation के लिए उनके साथ काम कर रहे हैं”
    सोच रहा हूँ कि क्या edge functions अंदर ही अंदर Workers का इस्तेमाल करते हैं
    लिंक: https://www.vercel-status.com/

    • काफ़ी संभव है कि edge functions असल में Workers ही हों, बस उनके साथ metrics collection जैसी छोटी अतिरिक्त code जुड़ी हो
    • Cloudflare की ओर से update में कहा गया है कि वह डेटा सेंटर को प्रभावित करने वाली power loss का आकलन करते हुए साथ ही service outage mitigation पर काम कर रहा है
      इसी thread के दूसरे link में कहा गया है कि Flexential PDX02 ने भी उसी समय बिजली खो दी
      utility power चली गई, generator पर switch किया गया, लेकिन generator भी fail हो गया, और लगता है कि कुछ utility power लौट आने से site का कुछ हिस्सा restore किया जा रहा है
      पूरा डेटा सेंटर डाउन हो गया था, और ऐसा लगता है कि Cloudflare का failover उम्मीद के मुताबिक़ सुचारु रूप से काम नहीं कर पाया
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • DigitalOcean भी प्रभावित है: https://status.digitalocean.com/incidents/bw3r3j9b5ph5
      समझ नहीं आता कि इस बात पर गर्व करना चाहिए या डरना चाहिए कि इन products में से काफ़ी सारे बस Cloudflare products के ऊपर wrappers हैं
      इस मामले में शायद wrapper नहीं है; DO का App Platform सिर्फ Workers के ऊपर रखा गया layer होने से काफ़ी ज़्यादा परिष्कृत है
      अंदाज़ा है कि कई core workloads Workers का इस्तेमाल करते हैं
    • सही: https://news.ycombinator.com/item?id=29003514

  • timing खराब है
    आज दोपहर quarterly earnings announcement है

    • हो सकता है कोई earnings announcement में दिखाने वाली किसी चीज़ को जल्दी-जल्दी deploy करने की कोशिश कर रहा हो