閱讀筆記: 「Cloudflare 06/21 災後報告」

標題: 「Cloudflare 06/21 災後報告」
類別: networks
連結: https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/

Cloudflare 官方文章詳細解釋 06/21/2022 當天到底發生什麼事情導致用戶受到影響，

這次的問題影響範圍概括了 Cloudflare 底下的 19 個資料中心，而很不幸的這 19 個資料中心剛好都是負責處理繁忙的全球流量，所以受到影響的用戶數量才會如此的多。
問題主因是網路設定的調整(有問題先猜BGP，不行再猜DNS…)，整體的發生時間沒有非常長

1. 06:27 UTC 問題發生
2. 06:58 UTC 第一個資料中心修復並且上線
3. 07:42 UTC 所有資料中心修復並且上線

過去 18 個月以來， Cloudflare 致力於將其底下繁忙的資料中心進行架構改造來達成更為堅韌與彈性的網路架構，內部稱該架構為 Multi-Colo POP(MCP)，影響的 19 個資料中心包含 Tokyo, Singapore … 等

新架構最重要的部分就是其網路的部分是基於 Clos network 的架構設計，透過多層次的設計達成類似 mesh network 般的網路連結，該架構使得未來要維護與調整時能夠更輕鬆針對部分網路設備去處理而不會影響到整體網路(文章有架構圖片)。

這次的問題主要跟 BGP 有關，Cloudflare 更新 BGP 的過程中有部分的 subnet 沒有順利的被傳遞出去，最終使得部分 subnet 的流量無法被順利轉發，進而導致整個網路問題。

文章內部有針對 BGP 問題更詳細的介紹，熟悉 BGP 的朋友可以花點時間看一下

這次的問題影響範圍很廣，Cloudflare 針對下列三面向反思了一下問題的發生原因

Process

雖然嶄新的 MCP 架構其目的就是要提供更好更強的可用性，但是將舊架構給升級到新架構的過程中還是不夠完善。整體的更新流程直到最後一步驟才算是真正的接觸到全新 MCP 架構，這使得如果中間更新流程有錯必須要到最後才會觀察到 MCP 資料中心的網路炸了。
改善的方式則是未來的這些流程與自動化必須要加入更多關於 MCP 架構的測試來確保整體部署不會遇到預期外的結果。

Architecture

路由器的錯誤設定使得正確的路由規則沒有辦法順利的被傳達下去，最終使得網路封包無法如預期般地到達這些資料中心。
所以修復過程中就是要找出這些錯誤的設定並且修正，最終使得這些 BGP 能夠將正確的路由政策給轉發下去。

Automaiton

當前的自動化流程中有非常多的部分可以改進，這些改進有機會完全或是部分的去減緩問題發生時的影響程度。
有兩個目標是想要透過改善自動化機制達成的

1. 減少問題發生時的影響範圍
2. 減少問題發生時的修復時間

CDN 不通先上社群看同業有沒有哀嚎，大概就可以知道是不是自己的問題了?

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力