Cloudflare API kesintisi
(news.ycombinator.com)- Cloudflare Dashboard ve API kesintisi, Control Plane API ile ürün hizmetleri Portland’daki birincil veri merkezine geri alındıktan sonra resolved durumuna geçti
- Dashboard işlevleri, Alerts, Zero Trust, WARP, Pages ve Workers gibi API altyapısına bağlı hizmetlerde istek başarısızlıkları ve hata göstergeleri yaşanabildi
- Cloudflare, veri merkezindeki güç kaybını değerlendirirken hizmetleri failover etti; Kuzey Amerika’daki çekirdek veri merkezinin elektriği kısmen geri geldikten sonra etkileri azaltmak için kritik hizmetleri yedek veri merkezine aktardı
- Etki, veri düzlemi ve kontrol düzlemi olarak ayrıldı; Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream ve DNS Updates gibi hizmetler zaman içinde unavailable, degraded ve restored durumları arasında gidip geldi
- Bazı Logpush günlükleri ve analiz verileri olay sırasında kayboldu; olayın bitişine yakın günlüklerin kurtarılma ihtimali vardı ancak toplam etki kapsamı olay sürerken kesinleşmemişti
Dashboard ve API kesintisinin kapsamı
- Cloudflare, Cloudflare Dashboard ve ilgili API sorununu araştırıp düzeltti; kullanıcılar Dashboard/API isteklerinde başarısızlık veya hata göstergeleri yaşayabildi
- Kesinti, Cloudflare API altyapısına bağlı birçok hizmete yayıldı
- Alerts
- Dashboard functionality
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare, bu sorunun Cloudflare CDN’in önbellekteki dosya sunumunu veya Cloudflare Edge’in diğer güvenlik işlevlerini etkilemediğini belirtti
Güç kaybı sonrası failover ve Portland geri dönüşü
- Cloudflare, veri merkezini etkileyen güç kaybını değerlendirirken aynı anda hizmetleri failover etti
- Kuzey Amerika’daki çekirdek veri merkezinin elektriği kısmen geri geldikten sonra, bazı kritik hizmetler etkileri azaltmak için yedek veri merkezine failover edildi
- Kurtarma sürecinde birçok güncellemede “gradual improvement” ve “restore full functionality” durumları tekrarlandı
- Son aşamada Control Plane API ve ürün hizmetleri Portland’daki birincil veri merkezine geri alındı
- 2023-11-06 17:00 UTC itibarıyla Portland’daki primary HA datacenters üzerinde Control Plane API ve Product Services’in geri yüklenmesine başlandı
- Kurtarma çalışmasının yaklaşık 2 saat süreceği bildirildi ve bu süre boyunca Cloudflare API ile Dashboard erişilebilirliği düşebildi
- 2023-11-06 18:30 UTC itibarıyla Pages ve Workers Control Plane API ile Product Services de Portland’daki birincil veri merkezine geri alınmaya başlandı
- Kurtarma tamamlandıktan sonra da Cloudflare kararlılığı ve edge case’leri izlemeye devam etti
Veri düzleminde bozulan işlevler
- Veri düzlemi etkisi, ürünlerin tam işlevselliğinin kısmen veya tamamen etkilenmesi olarak tanımlandı
- İlk etkilenen hizmetler arasında Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API ve Alert Notification System yer aldı
- Kurtarma sırasında durumu değişen başlıca hizmetler şunlardı
- Logpush: Birçok müşteri günlük alamadı ve bazı günlükler kaybolmuş olabilir. Daha sonra daha fazla job kurtarıldı ve job’ların büyük kısmının 07:00 UTC’ye kadar geri geleceği bildirildi
- Analytics / GraphQL API: Birçok müşterinin analytics verisi Dashboard ve API üzerinde unavailable durumdaydı; daha sonra analytics’in bir kısmı veya çoğu geri geldi ancak bazı dataset’ler eksik kaldı
- Workers Analytics Engine: Birden fazla güncellemede unavailable durumda kaldı
- Stream API: not available durumundan degraded performance but available durumuna geçti, ardından restored oldu
- Healthchecks: not available durumundan analytics olmadan restored durumuna geçti, ardından Healthcheck analytics de restored oldu
- Radar: degraded durumda kaldıktan sonra Cloudflare Radar operational status durumuna geri döndü
- Support Services: Support portal unavailable durumdayken Enterprise müşterileri ticket açmak için Enterprise support email address kullanabildi; daha sonra Portal, Phone ve Chat operational duruma geçti
- CASB: not available veya degraded performance durumundaydı; mevcut CASB Findings görüntülenebiliyordu ancak scanning offline durumdaydı. Daha sonra CASB API online oldu, scanning engine’in kurtarıldığı ve veri kaybı beklenmediği bildirildi
- DEX: not available durumundan DEX API online durumuna geçti; fleet status, HTTP ve Traceroute Test Result data için kurtarma sürüyordu ve Saturday Nov 4 15:00 UTC civarında tamamlanması bekleniyordu
- DNS Updates: degraded durumundan restored durumuna geçti
Kontrol düzleminde sınırlı yapılandırma değişiklikleri
- Kontrol düzlemi etkisi, ürün işlevlerinin edge üzerinde çalışmaya devam ettiği ancak mevcut yapılandırma değişikliklerinin etkilendiği durum olarak tanımlandı
- İlk etkilenen hizmetler arasında 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 ve Cloudflare Images yer aldı
- Kurtarma sırasında durumu değişen başlıca hizmetler şunlardı
- Cloudflare API: degraded but accessible veya restored olarak güncellendi
- Cloudflare Pages: degraded but online durumundan restored durumuna geçti; bir süre project oluşturma/silme ve direct upload deployments işlemleri degraded kaldı
- Magic Transit / Magic WAN: değişiklik yapılamayan durumdan configuration plane’in dahili olarak çalıştığı duruma geçti; acil değişiklikler için account team ile iletişime geçilmesi istendi
- Argo Smart Routing: configuration çalışıyordu ancak smart updates ve analytics offline durumdaydı
- Billing API / Registrar API: bir süre yalnızca read-only operations mümkündü
- Lists: list item update geçici olarak durduruldu ve Dashboard’da çalışsa da API’de 429 hatası dönebildi. Daha sonra restored durumuna geçti ancak bir süre değişiklikler yalnızca Dashboard üzerinden yapılabildi
- SSL / SSL for SaaS: SSL provisioning delay ve custom hostname validation delay yaşandı, ardından restored oldu
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments de güncellemelere göre degraded, unavailable ve restored durumları arasında gidip geldi
Kaybolan günlükler ve olay sonrası analiz
- Cloudflare, olay sırasında bazı Logpush günlükleri ve analytics verilerinin kaybolduğunu açıkladı
- Olayın sonuna yakın günlüklerin kurtarılma ihtimali vardı ancak süreç devam ederken toplam etki kapsamı henüz bilinmiyordu
- Bir güncellemede tüm günlük ve analytics pipeline’larının Saturday 4th November 2023 7AM UTC itibarıyla operational duruma geleceği belirtildi
- Sonraki bir güncellemede ise “günlüklerin çoğu olay sırasında kayboldu” ifadesi kullanıldı ve olay çözüldükten sonra kapsamlı bir değerlendirme paylaşılacağı belirtildi
- Ayrıntılar için Cloudflare’ın post-mortem on Cloudflare control plane and analytics outage yazısına bakılabilir
1 yorum
Hacker News görüşleri
3 yıldan biraz önce çalıştığım dönemde, PDX giderse omurga sistemin de gittiği bir yapı vardı
DDoS savunması gibi şeyler zaten her PoP içinde işleniyordu; bu yüzden L3/L7 flood’lar ya da yeni saldırılar sorun olmuyordu ama geri kalanların neredeyse tamamı PDX’te hesaplanıp yapılandırma verisi olarak her PoP’a dağıtılıyordu
Akış PoP’un veri üretmesi/toplaması → PDX’e göndermesi → PDX’te hesaplama → güncelleme/verinin PoP’a dağıtılması şeklindeydi; PDX ölürse güncel veriye bağımlı birçok özellik giderek bayatlamış durumda çalışmaya başlardı
O zamandan beri her şeyin değişmiş olduğunu sanmıyorum; bu yüzden bunun sadece “API down” olmasından ziyade yük dengeleme, hiyerarşik önbellek, Argo Smart Routing, Warp/Zero Trust gibi özelliklerin PDX güncellemeleri olmadan eski durum bilgileriyle çalıştığı bir performans düşüşü durumu olması daha olası
Diyelim ki gerçekten sadece “API down” olsun; yine de birçok müşterinin otomasyonu saldırıları API çağrılarıyla engellediği için saldırganlar açısından epey büyük bir fırsat penceresi açılmış oluyor
Ayrılmadan hemen önce AMS’i devreye almak için yatırım yapılıyordu ama büyük bir failover testi hiç başarılı olmamıştı; güncel duruma ihtiyaç duyan servislerin çoğu da bu yöntemi bilmiyordu
Ek olarak gözlemlenebilirliğin büyük kısmı da PDX tabanlıydı; şu anda önünü göremeden koşmak zorunda kalan ekiplere ve SRE’lere geçmiş olsun
Cloudflare, veri merkezini etkileyen güç kaybını değerlendirirken aynı anda servis failover’ı yürüttüğünü söyledi
Şebeke elektriği kesilip jeneratöre geçilmiş ama jeneratör de arızalanmış; şebeke elektriğinin bir kısmı geri gelmiş ve sitenin bir bölümünde toparlanma sürüyor gibi
https://puck.nether.net/pipermail/outages/2023-November/0149...
Ancak niyetle gerçeklik her zaman ayrışır; dünyanın öbür ucundaki bir veri merkezine otomatik ya da acil durumlarda elle failover yapmanın birçok iş yükü için gerçekçi bir çözüm olmamasının çeşitli nedenleri olduğunu duymuştum
Cloudflare çok fazla kaos testi yapar ve tüm veri merkezi ağının izole edilmesini de çok düzenli test eder
Bu olayın neden bu kadar farklı olduğunu tartışacakları toplantıya gizlice girebilmeyi isterdim
İkisinden yalnızca birini bizzat geliştirmiştim ama pazarlama tarafı bunları her zaman birlikte anardı
API ile hiyerarşik önbellek topolojisini özelleştiren kurumsal bir kullanıcı değilseniz, önbellek topolojisinin birkaç gün ya da birkaç hafta bayat kalması genel olarak sorun olmayabilir
Ancak söylediğin gibi başka birçok şey sorun yaşayabilir
Bakım ve ön planlama ne kadar iyi yapılırsa yapılsın, sonunda öngörülmemiş ya da maliyet nedeniyle hazırlık yapılmamış bir koşulun ortaya çıkıp kritik altyapıyı düşürme olasılığı sıfır değildir
Dashboard UI güncellemeler için API’yi kullanıyor gibi göründüğünden, bunun muhtemelen API erişimindeki performans düşüşünden kaynaklanması olası
UI’da DNS güncellemesi uygulanmış gibi görünse de gerçekte yayılmıyordu; kesintiden sonra SSL ve DNS yayılımının tekrar çalışması için Cloudflare dashboard’unda domain’i tamamen silip yeniden oluşturmamız gerekti
12 saat geçtiği halde sorun hâlâ devam ediyor
Çevrim içi müzik prodüksiyonu dersi alıyorum; videolar Cloudflare Stream’e yüklenmiş ve hiçbiri oynatılmıyor
https://www.cloudflare.com/products/cloudflare-stream/
İnternetin yarısı için tek hata noktası sorunu sürekli kendini gösteriyor
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Yalnızca dashboard’u ve dashboard içindeki özellikleri etkiliyor sanıyordum; ama Cloudflare video streaming çalışmıyor denince öyle değil mi acaba diye düşündüm
Tam bilemiyorum ama Cloudflare biraz içime sinmiyor
Neden bu kadar çok kişinin internetin büyük bir bölümünün tek bir şirkete bağımlı olmasına izin vermeyi normal gördüğünü anlamıyorum
Algım yanlış olabilir ama Cloudflare bana oligopol devlerine karşı güvenilir bir meydan okuyucu gibi görünüyor; daha fazla Cloudflare olmasını isterdim
Gerçekten Cloudflare kadar cömert bir ücretsiz katman sunan benzer bir hizmet pek bilmiyorum
TLS doğru kullanıldığında uçtan uca güvenlik sağlar, ancak Cloudflare kullanınca Cloudflare tüm düz metin trafiğe erişebilir
Küçük bir site DoS hedefi olabiliyorsa sonunda Cloudflare kullanmak zorunda kalıyor
Bu benim kişisel izlenimim; yanlış da olabilir
Birkaç gün önce o hatayı tekrar commit’lediler mi diye düşündüm
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
Değilmiş; çekirdek veri merkezi güç arızası gibi görünüyor
Ayrıntılar diğer yorumlarda var
Bu noktada Pavlov’un köpeği gibi kesintiden keyif almaya başladım
Sadece geçen hafta içinde şimdiden ikinci kesinti
Ölü yorum yanıtına ek olarak, bunun programlama dili seçimiyle hiçbir ilgisi yok
DreamHost’ta da Pasifik saatiyle 04:54’ten beri PDX’te sorun var
https://www.dreamhoststatus.com
Flexential PDX02’nin bu olayın başladığına yakın bir zamanda güç kaybettiği bildiriliyor
Cloudflare az önce veri merkezini etkileyen güç kaybını değerlendirirken aynı anda servis failover’ı yürüttüğünü duyurdu
Bizim taraftaki Flexential’da 5 jeneratör, bodrumda batarya yedeği ve izole bölgeler var
En etkileyici olan şey, durum sayfasının gerçekten çalışıyor olması
Elbette büyük ihtimalle başka bir yerde barındırılıyordur, ama her büyük kesintide hep aynı şeyi düşünüp gülüyorum
Pek iyi görünmüyor
Umarım bu olay yüzünden kendi servislerini kullanmayı bırakmazlar
Vercel deployment’ları ve genel olarak edge function’lar da çalışmıyor
Durum sayfasında “temel nedenin üst sağlayıcılarımızdan birindeki bir sorun olduğunu belirledik ve azaltma için birlikte çalışıyoruz” deniyor
Edge function’lar içeride Workers mı kullanıyor acaba diye düşündüm
Bağlantı: https://www.vercel-status.com/
Aynı başlıktaki başka bir bağlantıda Flexential PDX02’nin de aynı zamanda güç kaybettiği yazıyor
Şebeke elektriği kesilip jeneratöre geçilmiş, ama jeneratör de arızalanmış; şebeke elektriğinin bir kısmı geri gelmiş ve sitenin bir kısmı kurtarılıyor gibi görünüyor
Tüm veri merkezi çökmüş ve Cloudflare’in failover’ı bunu beklendiği kadar sorunsuz karşılayamamış gibi duyuluyor
https://puck.nether.net/pipermail/outages/2023-November/0149...
Bu ürünlerin epey çoğunun Cloudflare ürünlerini saran birer wrapper’dan ibaret olmasıyla gurur mu duymalıyız, korkmalı mıyız bilemiyorum
Bu durumda wrapper değil gibi; DO’nun App Platform’u sadece Workers üzerine kurulmuş olamayacak kadar gelişmiş
Birkaç çekirdek iş yükünün Workers kullandığını tahmin ediyorum
Zamanlama kötü
Bugün öğleden sonra çeyreklik finansal sonuç açıklaması var