API Cloudflare Down

 (news.ycombinator.com)
1 poin oleh GN⁺ 2023-11-05 | 1 komentar | Bagikan ke WhatsApp
  • Gangguan pada Cloudflare Dashboard dan API masuk status resolved setelah Control Plane API dan layanan produk dikembalikan ke pusat data utama Portland
  • Fitur Dashboard, Alerts, Zero Trust, WARP, Pages, Workers, dan lainnya yang bergantung pada infrastruktur API dapat mengalami kegagalan permintaan dan tampilan error
  • Cloudflare melakukan failover layanan sambil mengevaluasi kehilangan daya listrik di pusat data, lalu mengurangi dampak dengan memindahkan layanan inti ke pusat data cadangan setelah daya di pusat data inti Amerika Utara sebagian pulih
  • Dampaknya terbagi antara data plane dan control plane; Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates, dan lainnya berganti-ganti status unavailable, degraded, dan restored pada waktu yang berbeda
  • Sebagian log Logpush dan data analitik hilang selama insiden; log yang mendekati waktu berakhirnya insiden kemungkinan dapat dipulihkan, tetapi cakupan dampak keseluruhan belum dapat dipastikan selama insiden berlangsung

Cakupan dampak gangguan Dashboard dan API

  • Cloudflare menyelidiki dan memulihkan masalah terkait Cloudflare Dashboard dan API-nya; pengguna dapat mengalami kegagalan permintaan Dashboard/API atau tampilan error
  • Gangguan ini merambat ke berbagai layanan yang bergantung pada infrastruktur Cloudflare API
    • Alerts
    • Dashboard functionality
    • Zero Trust
    • WARP
    • Cloudflared
    • Waiting Room
    • Gateway
    • Stream
    • Magic WAN
    • API Shield
    • Pages
    • Workers
  • Cloudflare menyatakan masalah ini tidak memengaruhi penyajian file cache oleh Cloudflare CDN maupun fitur keamanan lain di Cloudflare Edge

Failover setelah kehilangan daya dan pemulihan Portland

  • Cloudflare melakukan failover layanan sambil mengevaluasi kehilangan daya listrik yang memengaruhi pusat data
  • Setelah daya di pusat data inti Amerika Utara pulih sebagian, beberapa layanan inti di-failover ke pusat data cadangan, sehingga dampaknya berkurang
  • Dalam proses pemulihan, beberapa pembaruan berulang kali menyebut status “gradual improvement” dan “restore full functionality”
  • Pada tahap akhir, Control Plane API dan layanan produk dikembalikan ke pusat data utama Portland
    • Mulai 2023-11-06 17:00 UTC, pemulihan Control Plane API dan Product Services ke primary HA datacenters di Portland dimulai
    • Pekerjaan pemulihan diperkirakan memakan waktu sekitar 2 jam, dan selama periode ini ketersediaan Cloudflare API dan Dashboard dapat menurun
    • Mulai 2023-11-06 18:30 UTC, Pages dan Workers Control Plane API serta Product Services juga mulai dipulihkan ke pusat data utama Portland
    • Setelah pemulihan selesai, Cloudflare tetap memantau stabilitas dan edge case

Fitur yang rusak di data plane

  • Dampak data plane didefinisikan sebagai cakupan ketika keseluruhan fungsi produk terdampak sebagian atau sepenuhnya
  • Layanan yang terdampak pada awalnya mencakup Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API, dan Alert Notification System
  • Layanan utama yang statusnya berubah selama pemulihan adalah sebagai berikut
    • Logpush: Banyak pelanggan tidak menerima log, dan sebagian log mungkin hilang. Setelah itu lebih banyak job dipulihkan, dan sebagian besar job diperkirakan pulih hingga 07:00 UTC
    • Analytics / GraphQL API: Data analytics milik banyak pelanggan berada dalam status unavailable di Dashboard dan API; kemudian sebagian atau sebagian besar analytics pulih, tetapi beberapa dataset masih tersisa
    • Workers Analytics Engine: Tetap dalam status unavailable dalam beberapa pembaruan
    • Stream API: Berpindah dari not available ke degraded performance but available, lalu kemudian menjadi restored
    • Healthchecks: Berpindah dari not available ke restored tanpa analytics, lalu Healthcheck analytics juga berpindah ke restored
    • Radar: Tetap dalam status degraded sebelum Cloudflare Radar pulih ke operational status
    • Support Services: Selama Support portal unavailable, pelanggan Enterprise dapat mengajukan ticket melalui Enterprise support email address, lalu Portal, Phone, dan Chat menjadi operational
    • CASB: Berada dalam status not available atau degraded performance; CASB Findings yang sudah ada dapat dilihat, tetapi scanning offline. Setelah itu CASB API menjadi online, scanning engine sedang dipulihkan, dan diinformasikan bahwa kehilangan data tidak diperkirakan terjadi
    • DEX: Berpindah dari status not available ke DEX API online; fleet status, HTTP, dan Traceroute Test Result data sedang dipulihkan, dengan perkiraan pemulihan sekitar Saturday Nov 4 15:00 UTC
    • DNS Updates: Berpindah dari degraded ke restored

Perubahan konfigurasi yang dibatasi di control plane

  • Dampak control plane didefinisikan sebagai cakupan ketika fungsi produk tetap berjalan di edge, tetapi perubahan konfigurasi yang sudah ada terdampak
  • Layanan yang terdampak pada awalnya mencakup 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, dan Cloudflare Images
  • Layanan utama yang statusnya berubah selama pemulihan adalah sebagai berikut
    • Cloudflare API: Diperbarui menjadi status degraded but accessible atau restored
    • Cloudflare Pages: Berpindah dari degraded but online ke restored; selama beberapa waktu pembuatan/penghapusan project dan direct upload deployments berada dalam status degraded
    • Magic Transit / Magic WAN: Berpindah dari kondisi tidak dapat diubah ke kondisi configuration plane berjalan secara internal; untuk perubahan darurat, pengguna diminta menghubungi account team
    • Argo Smart Routing: Configuration berfungsi, tetapi smart updates dan analytics offline
    • Billing API / Registrar API: Selama periode tertentu hanya read-only operations yang dapat dilakukan
    • Lists: Pembaruan list item dihentikan sementara; berfungsi di Dashboard tetapi dapat mengembalikan error 429 di API. Setelah itu berpindah ke restored status, tetapi selama beberapa waktu hanya dapat diubah lewat Dashboard
    • SSL / SSL for SaaS: Terjadi SSL provisioning delay dan custom hostname validation delay, lalu kemudian menjadi restored
    • Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments juga berganti-ganti status degraded, unavailable, dan restored sesuai pembaruan

Log yang hilang dan analisis pascainsiden

  • Cloudflare menyatakan bahwa selama insiden sebagian log Logpush dan analytics data hilang
  • Log yang dekat dengan waktu berakhirnya insiden kemungkinan dapat dipulihkan, tetapi selama insiden berlangsung cakupan dampak keseluruhan belum diketahui
  • Dalam salah satu pembaruan, diinformasikan bahwa semua log dan analytics pipeline akan berada dalam status operational hingga Saturday 4th November 2023 7AM UTC
  • Dalam pembaruan berikutnya, Cloudflare menyatakan “sebagian besar log hilang selama insiden” dan akan memberikan evaluasi penuh setelah insiden terselesaikan
  • Detail lebih lanjut dapat dilihat di post-mortem on Cloudflare control plane and analytics outage dari Cloudflare

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-05
Pendapat Hacker News

  • Saat saya bekerja di sana sedikit lebih dari 3 tahun lalu, strukturnya adalah jika PDX mati, sistem tulang punggung ikut mati
    Hal-hal seperti pertahanan DDoS sudah ditangani di dalam tiap PoP, jadi banjir L3/L7 atau serangan baru masih baik-baik saja, tetapi hampir semua sisanya dihitung di PDX lalu didistribusikan ke tiap PoP sebagai data konfigurasi
    Alurnya adalah PoP membuat/mengumpulkan data → mengirim ke PDX → dihitung di PDX → pembaruan/data didistribusikan ke PoP, dan jika PDX mati, banyak fitur yang bergantung pada data terbaru makin lama berjalan dalam keadaan usang
    Saya rasa tidak semuanya berubah sejak itu, jadi alih-alih sekadar “API down”, ini kemungkinan besar adalah kondisi penurunan performa di mana fitur seperti load balancing, tiered cache, Argo Smart Routing, Warp/Zero Trust berjalan dengan informasi status lama tanpa pembaruan dari PDX
    Kalaupun hanya “API down”, banyak otomatisasi pelanggan memblokir serangan lewat pemanggilan API, jadi bagi penyerang ini membuka jendela peluang yang cukup besar
    Menjelang saya keluar, mereka sedang berinvestasi untuk membangun AMS, tetapi uji failover besar belum pernah berhasil, dan sebagian besar layanan yang membutuhkan status terbaru tidak mengetahui cara itu
    Selain itu, sebagian besar observability juga berbasis PDX, jadi saya bersimpati kepada tim dan SRE yang sekarang mungkin sedang berlari tanpa bisa melihat ke depan

    • Ada unggahan dari pihak lain bahwa terjadi gangguan total PDX02, dan jika melihat pembaruan status terbaru, ini tampaknya merupakan akar penyebabnya
      Cloudflare mengatakan mereka sedang mengevaluasi kehilangan daya yang memengaruhi pusat data sambil sekaligus melakukan failover layanan
      Listrik utilitas terputus sehingga mereka beralih ke generator, tetapi generator juga gagal, dan tampaknya sebagian listrik utilitas sudah kembali sehingga pemulihan sebagian situs sedang berjalan
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • Jika ingatan saya benar, AMS adalah pusat data baru yang dimaksudkan untuk menggantikan atau memperkuat LUX, yang sebelumnya juga berperan sebagai cadangan failover untuk PDX
      Namun niat dan kenyataan selalu berjarak, dan saya pernah mendengar banyak alasan mengapa failover otomatis atau manual darurat ke pusat data di sisi lain bumi bukan solusi realistis untuk banyak workload
      Cloudflare banyak melakukan chaos testing, dan juga sangat rutin menguji isolasi jaringan pusat data secara penuh
      Saya ingin diam-diam ikut rapat yang membahas kenapa insiden kali ini begitu berbeda
    • Berdasarkan kondisi beberapa tahun lalu, tiered cache dan Argo adalah fitur yang berbeda
      Saya hanya membangun langsung salah satunya, tetapi pihak marketing selalu menggabungkannya dalam penyebutan
      Jika bukan pengguna enterprise yang mengustomisasi topologi tiered cache lewat API, topologi cache yang usang beberapa hari atau beberapa minggu sepertinya umumnya masih tidak apa-apa
      Namun seperti yang dikatakan, banyak hal lain bisa mengalami masalah
    • Generator, AC, UPS, dan automatic transfer switch semuanya adalah perangkat mekanis sehingga rentan rusak
      Sebaik apa pun pemeliharaan dan perencanaan sebelumnya, pada akhirnya kemungkinan infrastruktur inti mati karena kondisi yang tidak diperkirakan atau tidak disiapkan karena biaya bukanlah 0
    • Selama sebagian besar durasi gangguan, pembaruan DNS juga mati
      Karena UI dashboard tampaknya memakai API untuk pembaruan, kemungkinan besar ini akibat penurunan performa akses API
      Walaupun di UI pembaruan DNS tampak diterapkan, propagasi sebenarnya tidak terjadi, dan setelah gangguan, SSL serta propagasi DNS baru kembali berfungsi setelah domain dihapus seluruhnya dari dashboard Cloudflare lalu dibuat ulang

  • Sudah 12 jam berlalu, tetapi masalahnya masih berlanjut
    Saya sedang mengikuti kursus produksi musik online, videonya diunggah ke Cloudflare Stream dan tidak ada satu pun yang bisa diputar
    https://www.cloudflare.com/products/cloudflare-stream/
    Masalah single point of failure untuk separuh internet terus muncul lagi

    • Sekarang sudah 24 jam berlalu, tetapi Stream masih belum pulih
    • Tertulis “masalah ini tidak memengaruhi penyajian file cache melalui Cloudflare CDN atau fitur keamanan lain di Cloudflare Edge”
      https://www.cloudflarestatus.com/incidents/hm7491k53ppg
      Saya kira dampaknya hanya pada dashboard dan fitur di dalam dashboard, tetapi kalau streaming video Cloudflare tidak bisa, mungkin bukan begitu

  • Saya tidak begitu tahu, tapi Cloudflare terasa agak mengganjal
    Saya tidak mengerti mengapa begitu banyak orang berpikir tidak apa-apa membiarkan sebagian besar internet bergantung pada satu perusahaan

    • Secara prinsip saya setuju, tetapi rasanya pernyataan seperti ini lebih mudah ditempelkan pada Cloudflare dibanding perusahaan seperti Amazon(AWS), Google, atau Microsoft
      Persepsi saya bisa saja keliru, tetapi Cloudflare terlihat seperti penantang tepercaya terhadap perusahaan-perusahaan raksasa oligopolistik, dan saya berharap ada lebih banyak Cloudflare
    • Saya rasa bukan karena orang berpikir mereka harus bergantung pada Cloudflare, melainkan karena Cloudflare secara umum punya kinerja bagus dan layanan dasarnya gratis
      Saya sebenarnya tidak tahu layanan serupa yang menawarkan tier gratis semurah hati Cloudflare
    • Bukan hanya soal ketergantungan; masalahnya juga Cloudflare secara desain adalah man-in-the-middle untuk lalu lintas TLS dalam jumlah sangat besar
      Jika TLS digunakan dengan benar, ia menyediakan keamanan end-to-end, tetapi jika memakai Cloudflare, Cloudflare dapat mengakses semua lalu lintas plaintext
    • Tidak ada alternatif yang gratis atau bahkan murah
      Jika sebuah situs kecil bisa menjadi target DoS, pada akhirnya harus memakai Cloudflare
    • Cloudflare terasa memiliki susunan produk yang cukup adil, tidak seperti penyedia cloud lain yang berusaha memeras sampai sen terakhir
      Itu kesan pribadi saya, dan bisa saja salah

  • Saya sempat mengira bug itu di-commit ulang beberapa hari lalu
    https://blog.cloudflare.com/cloudflare-incident-on-october-3...
    Ternyata bukan, sepertinya ini gangguan listrik di data center inti
    Detailnya ada di komentar-komentar lain

    • Setiap kali Cloudflare down, kita seperti mendapat tulisan menarik sebagai kompensasi
      Sampai-sampai sekarang jadi menikmati insiden seperti Pavlov

  • Ini sudah insiden kedua dalam minggu lalu saja
    Menambahkan ke balasan komentar yang sudah mati, ini sama sekali tidak ada hubungannya dengan pilihan bahasa pemrograman

  • DreamHost juga mengalami masalah di PDX sejak pukul 04.54 Waktu Pasifik
    https://www.dreamhoststatus.com

  • Flexential PDX02 dilaporkan kehilangan daya sekitar waktu kejadian ini mulai terjadi

    • Sepertinya terkait
      Cloudflare baru saja mengumumkan bahwa mereka sedang menilai kehilangan daya yang berdampak pada data center, sekaligus melakukan failover layanan
    • Penasaran bagaimana itu bisa terjadi
      Flexential di pihak kami punya 5 generator, backup baterai di bawah tanah, dan zona isolasi
    • Menurutmu ini sebab atau akibat?

  • Yang paling mengesankan adalah halaman status benar-benar berfungsi

    • “Didukung oleh Atlassian Statuspage”
    • Ironis bahwa ada begitu banyak layanan yang mengalami gangguan, tetapi halaman status jarang sekali ikut down
      Tentu kemungkinan besar di-host di tempat lain, tetapi setiap kali ada insiden besar, saya selalu memikirkan hal yang sama dan tertawa

  • Kelihatannya tidak bagus
    Semoga mereka tidak berhenti melakukan dogfooding layanan sendiri karena kejadian ini
    Deployment Vercel dan edge function secara umum juga tidak berfungsi
    Halaman status menyebutkan, “kami telah mengidentifikasi masalah pada salah satu penyedia upstream sebagai akar penyebabnya, dan sedang bekerja sama untuk mitigasi”
    Saya jadi bertanya-tanya apakah edge function secara internal memakai Workers
    Tautan: https://www.vercel-status.com/

    • Kemungkinan besar edge function adalah Workers dengan sedikit kode tambahan seperti pengumpulan metrik
    • Pembaruan dari pihak Cloudflare mengatakan mereka sedang menilai kehilangan daya yang berdampak pada data center, sekaligus melakukan failover layanan
      Tautan lain di thread yang sama menyebutkan Flexential PDX02 kehilangan daya pada waktu yang sama
      Sepertinya listrik utilitas putus lalu beralih ke generator, tetapi generatornya juga gagal, dan sebagian listrik utilitas sudah kembali sehingga sebagian situs sedang dipulihkan
      Terdengar seperti seluruh data center down, dan failover Cloudflare tidak menangani situasinya semulus yang diharapkan
      https://puck.nether.net/pipermail/outages/2023-November/0149...
    • DigitalOcean juga terdampak: https://status.digitalocean.com/incidents/bw3r3j9b5ph5
      Saya tidak tahu apakah harus bangga atau takut bahwa cukup banyak produk seperti ini ternyata tidak lebih dari wrapper di atas produk Cloudflare
      Dalam kasus ini sepertinya bukan wrapper, dan App Platform milik DO cukup canggih untuk sekadar dibangun di atas Workers saja
      Dugaan saya, beberapa workload inti memakai Workers
    • Benar: https://news.ycombinator.com/item?id=29003514

  • Timing-nya buruk
    Sore ini ada pengumuman kinerja kuartalan

    • Mungkin ada yang mencoba buru-buru men-deploy sesuatu untuk diumumkan dalam pengumuman kinerja