Cloudflare API bị ngừng hoạt động
(news.ycombinator.com)- Sự cố với Cloudflare Dashboard và API đã được chuyển sang trạng thái đã giải quyết sau khi đưa Control Plane API và các dịch vụ sản phẩm trở lại trung tâm dữ liệu chính ở Portland
- Các tính năng Dashboard, Alerts, Zero Trust, WARP, Pages, Workers và các dịch vụ khác phụ thuộc vào hạ tầng API có thể đã gặp yêu cầu thất bại và hiển thị lỗi
- Cloudflare đã đánh giá tình trạng mất điện tại trung tâm dữ liệu và thực hiện failover dịch vụ; sau khi điện được khôi phục một phần tại trung tâm dữ liệu cốt lõi ở Bắc Mỹ, các dịch vụ quan trọng được chuyển sang trung tâm dữ liệu dự phòng để giảm tác động
- Tác động được chia thành data plane và control plane; Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates và các dịch vụ khác đã lần lượt trải qua các trạng thái unavailable, degraded và restored theo từng thời điểm
- Một phần log Logpush và dữ liệu phân tích đã bị mất trong sự cố; các log gần thời điểm kết thúc có khả năng được khôi phục, nhưng phạm vi tác động tổng thể chưa thể xác định trong lúc sự cố đang diễn ra
Phạm vi ảnh hưởng của sự cố Dashboard và API
- Cloudflare đã điều tra và khắc phục sự cố với Cloudflare Dashboard và các API liên quan; người dùng có thể gặp lỗi hoặc thất bại khi gửi yêu cầu đến Dashboard/API
- Sự cố lan sang nhiều dịch vụ phụ thuộc vào hạ tầng API của Cloudflare
- Alerts
- Dashboard functionality
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare cho biết sự cố này không ảnh hưởng đến việc phân phối tệp được cache của Cloudflare CDN hoặc các tính năng bảo mật khác trên Cloudflare Edge
Failover sau sự cố mất điện và khôi phục tại Portland
- Cloudflare vừa đánh giá tình trạng mất điện ảnh hưởng đến trung tâm dữ liệu, vừa đồng thời thực hiện failover dịch vụ
- Sau khi điện tại trung tâm dữ liệu cốt lõi ở Bắc Mỹ được khôi phục một phần, một số dịch vụ cốt lõi đã được failover sang trung tâm dữ liệu dự phòng để giảm tác động
- Trong quá trình khôi phục, nhiều bản cập nhật lặp lại các trạng thái như “gradual improvement” và “restore full functionality”
- Ở giai đoạn cuối, Control Plane API và các dịch vụ sản phẩm được đưa trở lại trung tâm dữ liệu chính ở Portland
- Từ 2023-11-06 17:00 UTC, Cloudflare bắt đầu khôi phục Control Plane API và Product Services về các primary HA datacenters ở Portland
- Thời gian khôi phục được thông báo là khoảng 2 giờ, trong đó khả năng sẵn sàng của Cloudflare API và Dashboard có thể bị suy giảm
- Từ 2023-11-06 18:30 UTC, Pages và Workers Control Plane API cùng Product Services cũng bắt đầu được khôi phục về trung tâm dữ liệu chính ở Portland
- Sau khi hoàn tất khôi phục, Cloudflare tiếp tục theo dõi độ ổn định và các edge case
Các chức năng bị gián đoạn ở data plane
- Tác động ở data plane được định nghĩa là phạm vi mà toàn bộ chức năng của sản phẩm chịu ảnh hưởng một phần hoặc toàn bộ
- Các dịch vụ bị ảnh hưởng ban đầu gồm Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API, Alert Notification System
- Các dịch vụ chính có thay đổi trạng thái trong quá trình khôi phục gồm:
- Logpush: nhiều khách hàng không nhận được log, và một phần log có thể đã bị mất. Sau đó nhiều job hơn đã được khôi phục, và phần lớn job được thông báo sẽ phục hồi trước 07:00 UTC
- Analytics / GraphQL API: dữ liệu analytics của nhiều khách hàng ở trạng thái unavailable trên Dashboard và API; sau đó một phần hoặc phần lớn analytics đã được khôi phục nhưng vẫn còn một số dataset chưa phục hồi
- Workers Analytics Engine: vẫn ở trạng thái unavailable trong nhiều bản cập nhật
- Stream API: chuyển từ not available sang degraded performance but available, rồi sau đó được restored
- Healthchecks: chuyển từ not available sang restored nhưng chưa có analytics, sau đó Healthcheck analytics cũng được restored
- Radar: tiếp tục ở trạng thái degraded rồi sau đó Cloudflare Radar được khôi phục về operational status
- Support Services: trong thời gian cổng hỗ trợ unavailable, khách hàng Enterprise có thể gửi ticket qua địa chỉ email hỗ trợ Enterprise; sau đó Portal, Phone và Chat trở lại trạng thái operational
- CASB: ở trạng thái not available hoặc degraded performance; các CASB Findings hiện có vẫn xem được nhưng scanning bị offline. Sau đó CASB API trở lại online, scanning engine đang khôi phục và không dự kiến mất dữ liệu
- DEX: từ trạng thái not available chuyển sang DEX API online; dữ liệu fleet status, HTTP và Traceroute Test Result đang được khôi phục, dự kiến hoàn tất vào khoảng Saturday Nov 4 15:00 UTC
- DNS Updates: chuyển từ degraded sang restored
Thay đổi cấu hình bị hạn chế ở control plane
- Tác động ở control plane được định nghĩa là trường hợp chức năng sản phẩm vẫn chạy ở edge nhưng các thay đổi đối với cấu hình hiện có bị ảnh hưởng
- Các dịch vụ bị ảnh hưởng ban đầu gồm 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
- Các dịch vụ chính có thay đổi trạng thái trong quá trình khôi phục gồm:
- Cloudflare API: được cập nhật sang trạng thái degraded but accessible hoặc restored
- Cloudflare Pages: chuyển từ degraded but online sang restored; trong một thời gian, việc tạo/xóa project và direct upload deployments ở trạng thái degraded
- Magic Transit / Magic WAN: từ trạng thái không thể thay đổi chuyển sang trạng thái configuration plane hoạt động nội bộ; với các thay đổi khẩn cấp, người dùng được hướng dẫn liên hệ account team
- Argo Smart Routing: phần cấu hình vẫn hoạt động nhưng smart updates và analytics ở trạng thái offline
- Billing API / Registrar API: trong một khoảng thời gian chỉ có thể thực hiện read-only operations
- Lists: việc cập nhật list item bị tạm dừng; trên Dashboard vẫn hoạt động nhưng qua API có thể trả về lỗi 429. Sau đó dịch vụ chuyển sang restored nhưng trong một thời gian chỉ có thể chỉnh sửa qua Dashboard
- SSL / SSL for SaaS: có độ trễ trong SSL provisioning và custom hostname validation, sau đó được restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments cũng lần lượt trải qua các trạng thái degraded, unavailable và restored tùy theo từng bản cập nhật
Log bị mất và phân tích sau sự cố
- Cloudflare cho biết một phần log Logpush và dữ liệu analytics đã bị mất trong sự cố
- Các log gần thời điểm kết thúc sự cố có khả năng được khôi phục, nhưng trong lúc sự cố đang diễn ra vẫn chưa thể biết toàn bộ phạm vi ảnh hưởng
- Một bản cập nhật cho biết mọi pipeline log và analytics sẽ trở lại trạng thái operational trước 7AM UTC ngày Saturday 4th November 2023
- Các bản cập nhật sau đó mô tả rằng “phần lớn log đã bị mất trong thời gian sự cố”, và cho biết sẽ cung cấp đánh giá đầy đủ sau khi sự cố được giải quyết
- Có thể xem thêm chi tiết trong post-mortem on Cloudflare control plane and analytics outage của Cloudflare
1 bình luận
Ý kiến trên Hacker News
Khi tôi làm ở đó cách đây hơn 3 năm một chút, kiến trúc là nếu PDX gặp sự cố thì hệ thống xương sống cũng gặp sự cố
Những thứ như chống DDoS đã được xử lý ngay trong từng PoP, nên các đợt flood L3/L7 hoặc kiểu tấn công mới vẫn ổn, nhưng gần như mọi thứ còn lại được tính toán ở PDX rồi phân phối dưới dạng dữ liệu cấu hình tới từng PoP
Luồng là PoP tạo/thu thập dữ liệu → gửi tới PDX → tính toán tại PDX → phân phối cập nhật/dữ liệu về PoP; nếu PDX chết, nhiều tính năng phụ thuộc vào dữ liệu mới nhất sẽ dần chạy trong trạng thái cũ kỹ
Tôi không nghĩ mọi thứ đã thay đổi hoàn toàn kể từ đó, nên đây nhiều khả năng không chỉ đơn giản là “API sập”, mà là trạng thái suy giảm hiệu năng khi các tính năng như cân bằng tải, cache phân cấp, Argo Smart Routing, Warp/Zero Trust chạy với thông tin trạng thái đã cũ vì không có cập nhật từ PDX
Ngay cả khi “chỉ API sập” thì nhiều hệ thống tự động hóa của khách hàng cũng chặn tấn công bằng cách gọi API, nên với kẻ tấn công, một khoảng thời gian cơ hội khá lớn đã mở ra
Trước khi tôi nghỉ, họ đang đầu tư vào việc dựng AMS, nhưng các bài kiểm thử failover lớn chưa từng thành công, và hầu hết dịch vụ cần trạng thái mới nhất đều không biết đến cách đó
Nói thêm, phần lớn observability cũng dựa trên PDX, nên xin chia sẻ với các đội và SRE hiện đang phải chạy trong tình trạng gần như không nhìn thấy gì phía trước
Cloudflare nói họ đang đánh giá việc mất điện ảnh hưởng tới datacenter, đồng thời tiến hành failover dịch vụ
Nguồn điện lưới bị mất nên họ chuyển sang máy phát, nhưng máy phát cũng hỏng; có vẻ một phần điện lưới đã trở lại và một phần site đang được khôi phục
https://puck.nether.net/pipermail/outages/2023-November/0149...
Tuy nhiên ý định và thực tế luôn có khoảng cách, và đã có nhiều lý do được nêu ra vì sao failover tự động hoặc thủ công khẩn cấp sang datacenter ở phía bên kia Trái Đất không phải là giải pháp thực tế cho nhiều workload
Cloudflare làm rất nhiều kiểm thử chaos, và cũng kiểm thử việc cô lập mạng của toàn bộ datacenter rất thường xuyên
Tôi rất muốn lẻn vào cuộc họp bàn xem vì sao sự cố lần này lại khác đến vậy
Tôi chỉ trực tiếp làm một trong hai, nhưng marketing thì lúc nào cũng gộp chúng lại với nhau
Nếu không phải người dùng enterprise tùy biến topology cache phân cấp qua API, tôi nghĩ topology cache cũ đi vài ngày hay vài tuần nhìn chung cũng không sao
Tuy vậy, như đã nói, rất nhiều thứ khác có thể gặp vấn đề
Dù bảo trì và lập kế hoạch trước tốt đến đâu, xác suất một điều kiện không lường trước hoặc không được chuẩn bị vì chi phí xảy ra và làm sập hạ tầng cốt lõi cuối cùng vẫn không bằng 0
Vì UI dashboard có vẻ dùng API để cập nhật, nên có khả năng là do hiệu năng truy cập API bị suy giảm
Dù trong UI trông như cập nhật DNS đã được phản ánh, thực tế nó không được truyền đi; sau sự cố, phải xóa toàn bộ domain trong dashboard Cloudflare rồi tạo lại thì SSL và việc truyền DNS mới hoạt động trở lại
Đã 12 giờ trôi qua mà vấn đề vẫn tiếp diễn
Tôi đang học một khóa sản xuất nhạc trực tuyến, video được đưa lên Cloudflare Stream và không video nào phát được
https://www.cloudflare.com/products/cloudflare-stream/
Vấn đề điểm lỗi đơn của một nửa Internet lại tiếp tục lộ diện
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Tôi tưởng chỉ dashboard và các chức năng bên trong dashboard bị ảnh hưởng, nhưng nghe nói dịch vụ streaming video của Cloudflare không hoạt động thì có vẻ không phải vậy
Tôi không rõ, nhưng Cloudflare khiến tôi hơi bất an
Tôi không hiểu vì sao nhiều người lại nghĩ có thể để một phần lớn Internet phụ thuộc vào một công ty như vậy
Có thể nhận thức của tôi sai, nhưng Cloudflare trông như một đối thủ thách thức đáng tin cậy trước các gã khổng lồ mang tính độc quyền nhóm, và tôi mong có nhiều Cloudflare hơn
Thực tế tôi không biết nhiều dịch vụ tương tự nào có gói miễn phí hào phóng như Cloudflare
Nếu dùng TLS đúng cách thì nó cung cấp bảo mật đầu cuối, nhưng khi dùng Cloudflare, Cloudflare có thể truy cập toàn bộ lưu lượng dạng văn bản thuần
Nếu một site nhỏ có thể trở thành mục tiêu DoS thì cuối cùng vẫn phải dùng Cloudflare
Đó là ấn tượng cá nhân của tôi, và có thể tôi sai
Tôi đã tự hỏi có phải họ đã commit lại bug đó vài ngày trước không
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
Hóa ra không phải, mà trông giống như sự cố điện ở trung tâm dữ liệu lõi
Chi tiết có trong các bình luận khác
Đến mức này thì tôi bắt đầu thấy thích sự cố như phản xạ Pavlov rồi
Chỉ riêng tuần trước đây đã là sự cố thứ hai rồi
Nói thêm vào câu trả lời cho bình luận đã chết, chuyện này chẳng liên quan gì đến việc chọn ngôn ngữ lập trình
DreamHost cũng gặp vấn đề ở PDX từ 4:54 sáng giờ Thái Bình Dương
https://www.dreamhoststatus.com
Có thông tin rằng Flexential PDX02 đã mất điện vào thời điểm tương tự khi việc này bắt đầu
Cloudflare vừa thông báo rằng họ đang đánh giá tình trạng mất điện ảnh hưởng đến trung tâm dữ liệu, đồng thời tiến hành failover dịch vụ
Phía Flexential của chúng tôi có 5 máy phát điện, hệ thống pin dự phòng dưới tầng hầm và các khu vực cách ly
Điều ấn tượng nhất là trang trạng thái thực sự vẫn hoạt động
Tất nhiên rất có thể nó được host ở nơi khác, nhưng mỗi lần có sự cố lớn tôi luôn nghĩ như vậy và bật cười
Trông không ổn lắm
Hy vọng họ không vì chuyện này mà ngừng dùng chính dịch vụ của mình
Toàn bộ việc triển khai Vercel và edge functions cũng không hoạt động
Trang trạng thái ghi rằng “chúng tôi đã xác định vấn đề ở một trong các nhà cung cấp thượng nguồn là nguyên nhân gốc rễ và đang phối hợp để giảm thiểu”
Tôi tự hỏi có phải edge functions bên trong dùng Workers không
Liên kết: https://www.vercel-status.com/
Một liên kết khác trong cùng thread nói rằng Flexential PDX02 mất điện vào cùng thời điểm
Có vẻ điện lưới bị cắt nên họ chuyển sang máy phát, nhưng máy phát cũng lỗi; một phần điện lưới đã trở lại nên một phần site đang được khôi phục
Nghe như toàn bộ trung tâm dữ liệu đã sập, và failover của Cloudflare không xử lý trơn tru như kỳ vọng
https://puck.nether.net/pipermail/outages/2023-November/0149...
Không biết nên tự hào hay nên sợ khi nhận ra khá nhiều sản phẩm kiểu này thực chất chỉ là wrapper bọc quanh sản phẩm của Cloudflare
Trong trường hợp này thì có vẻ không phải wrapper; App Platform của DO khá tinh vi để chỉ đơn giản chạy trên Workers
Tôi đoán một số workload cốt lõi đang dùng Workers
Thời điểm thật tệ
Chiều nay là buổi công bố kết quả kinh doanh quý