From 405a107ca04a8a2c12885b2eda7cad068e2cc591 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lu=20Shueh=20Chou=5B=E5=91=82=E5=AD=B8=E6=B4=B2=5D?= Date: Wed, 15 May 2024 09:52:48 +0800 Subject: [PATCH] sre: managing load --- .../managing-load.md | 52 +++++++++++++------ 1 file changed, 37 insertions(+), 15 deletions(-) diff --git a/src/feedback/site-reliability-workbook/managing-load.md b/src/feedback/site-reliability-workbook/managing-load.md index c1692434..5187cf8e 100644 --- a/src/feedback/site-reliability-workbook/managing-load.md +++ b/src/feedback/site-reliability-workbook/managing-load.md @@ -21,11 +21,11 @@ tags: SRE-workbook ## Google Cloud Load Balancing 第一段先透過 Google 雲端的負載平衡機制（GCLB），來提出幾個建議的模式供參考。 -從使用者的請求送出，到最終到達提供服務的節點，中間的每一個環節都負載管理，都值得探討。 +從使用者的請求送出，到最終到達提供服務的節點，中間的每一個環節的負載管理，都值得探討。 要均衡使用者送出的請求，最方便的就是使用 DNS。 DNS 透過使用者的 IP 給予最適當的資料中心 IP，來達到負載的分散。 -但是這需要把使用者的 IP 保留下來，而且當資料中心失能時，要讓使用者重新請求新的 IP， +但是使用者會快取 IP，如果資料中心失能時，要有個機制讓使用者重新請求新的 IP， 而不是等到期限到期才去重新請求。 這些都是實作上的困難，所以 GCLB 採用 Anycast 的機制。 @@ -39,7 +39,7 @@ Anycast 在路由過程中，路由器會判斷最近的資料中心，並送往 但這仍會有幾個問題： - 單一的資料中心仍可能被附近的使用者沖垮 -- 使用者可能會因為切換路由路徑而斷開連線 +- 使用者可能會因為切換路由路徑而斷開連線，例如搭火車的時候 ### 跨資料中心時確保連線的維持 @@ -51,23 +51,45 @@ title: Stabilized Anycast --- flowchart TB u[User] --10.0.0.1--> i((ISP)) - subgraph "Data-center 1" + subgraph "Data Center 1" direction TB - u1[router] --> lb1[Load balancers
Maglev] - p1[HTTP Reverse Proxies] + u1[router] --> lb1[Load balancers: Maglev] + p1[HTTP Reverse Proxies: GFE] end - subgraph "Data-center 2" + subgraph "Data Center 2" direction TB - u2[router] --> lb2[Load balancers
Maglev] - lb2 --> p2[HTTP Reverse Proxies] + u2[router] --> lb2[Load balancers: Maglev] + lb2 --> p2[HTTP Reverse Proxies: GFE] end i --10.0.0.1--> u1 i --10.0.0.1--> u2 - lb1 -.Stabilized
Anycast.-> lb2 + lb1 -.Stabilized Anycast.-> lb2 ``` -當連線在 `Data-center 1` 建立時，路由器下面的負載平衡器 -（Google 命名為 [*Maglev*](https://research.google/pubs/maglev-a-fast-and-reliable-software-network-load-balancer/)） -會把連線資訊同步給其他資料中心。 -而這個負載平衡器只會處理 L4 的封包，並且透過 Equal-Cost Multi Path（ECMP）的轉送方式， -達成可以讓多個負載平衡共享連線資訊，當需要提高負載能力時，只需要單純的增加機器即可。 +當連線在 `Data Center 1` 建立時，路由器下面的負載平衡器 +（Google 使用 [*Maglev*](../../essay/web/maglev.md)） +如果發現叢集內的服務失能，就會把連線拋轉給其他資料中心。 + +```mermaid +flowchart TB + m1[Maglev] + m2[Maglev] + gslb[GSLB] + g1[GFE] + g2[GFE] + bs1[Backend Service] + bs2[BackendService] + m1 -.-gslb-.- g1 + m2 -.-gslb-.- g2 + m1 --> g1 + m2 --> g2 + g1 --> bs1 + g2 -.- bs2 + g2 --> bs1 +``` + +拋轉的機制是由 Global Software Load Balancer（GSLB）來處理， +他會檢查兩個 Google Front End（GFE）的連線數，和 GFE 的上游服務請求分佈跟節點健康度來調度負載。 +GFE 通常就會是 TCP 和 SSL sessions 的處理位置，並且根據 HTTP 路徑等資訊分配請求。 +除此之外，他也會把送給服務的請求[重新加密](https://cloud.google.com/docs/security/encryption-in-transit)， +以及服務的健康檢查和無中斷的抽離失能節點。