Google Cloud雲端平台介紹

VM與Load Balancing

Regions and Zones

雲端運算平台通常都會建立多個Zone與Region。這是由多個資料中心建立起一個Zone，多個Zone會建立起一個Region。在全世界各地都有不同Region的雲端平台。這樣做的目的有三：

1. 高可用度(High Availability) — 避免因為資料中心掛到造成服務不可用
2. 網路的低延遲(Low latency) — 盡量靠近終端使用者，這樣網路的延遲時間才會減少
3. 合規 — 各國的法規不盡相同，但大部分都希望把資料留在自己國家內

而一間企業通常要做到這種程度的多個資料中心，基本上除非是跨國的大企業。否則很少有企業有這樣的財力建立起這種超大規模的資料中心。

GCE(Google Compute Engine)

簡單的來說就是GCP的VM。

GCE的功能通常有:

• 建立與管理整個VM instance的生命週期
• 如果有需要Auto scaling的能力，需要加入Load Balancing的功能。
• VM需要storage(也就是硬碟)才能運作。在GCP稱為Persisten Disk(走的是NAS的方式)
• 託管的網路連線與配置

GCP VM的規格

GCP的VM有以下三種類別:

• General Purpose (E2, N2, N2D, N1) : 一般性的使用， 通常是Web與application servers或是開發環境。
• Memory Optimized (M2, M1): 這通常是給需要大量記憶體的DB或分析工具使用的。
• Compute Optimized (C2): 這是需要高速運算的Application。例如遊戲業需要的高速運算伺服器。

範例:

若我們要選擇一個GCP的VM，GCP的機器名稱如上圖最左邊的欄位。例如e2-standard-2，它們分別代表

• e2 — 這是指CPU的世代規格，e系列是GCP最舊也是最便宜的VM系列
• standard — 代表這適合哪種工作負載，例如web或Application或是DB
• 2 — 代表這一台VM有多少個vCPU。在上表中我們可以觀察到CPU與memory是有比例的(1:4)。

選好的規格之後，下一個就是要用哪一種OS了，在GCP裡這稱為Image。通常會有兩種:

• Public — 這是GCP提供的標準OS。也是會把OS license算在我們費用之中的。
• Custom — 這通常是會加上我們自有的Application。自帶OS license也可以歸在這一類image

內部與外部IP

外部IP就是Public IP，可以連結Internet。而內部IP就是Private IP，在LAN內使用的。GCP內所有的VM可以沒有Public IP，但至少需要一個內部IP。

另外，若我們沒有reserve Public IP。在我們停止(重開機不算)該台VM時，Public IP就會不見。下次再開機時就是另一個不同的Public IP。

如過我們有在GCP上進行保留Public IP的動作。除了這個IP可以給原VM使用，我們也可以轉移這個IP給其他VM使用。有一點: 如果我們保留的這個IP沒有在使用，哪GCP就會針對這個沒在用的IP收錢，反之就不收錢。

如何加快VM的設定時間

通常有以下三種方式可以加速我們VM的設定時間:

• Startup script
• Instance Template
• Custom Image

Startup script(也可以稱Bootstrapping)。通常是VM在啟動時，自動的上補丁(patch)或是安裝我們想要安裝的程式。

當我們從一個乾淨的OS安裝好所有的補丁與需要的程式並且還沒開始投入運作時，通常IT人員為了以後的作業方便，都會建立一個Gold image(Instance template)。這個template可以包含所有VM的屬性，像是machine type, image, labels, startup script等等。

除了用在建立相同的VM instance之後，也會用在managed instance groups，這是用在scale out/in的機制之下。不過instance template的缺點在於，如果這個template有任何需要update的需求時，我們必須把它變成activity instance，做完修改之後再把這個instance變成一個靜態的Image。

Custom Image與Startup Script是光譜的兩邊。Startup Scripts是在機器開機後開始自動執行所有要安裝的Application與設定，而Custom Image則是把這些事情預先做好，然後變成一個Image。

所以這一個Custom Image的來源的可以是instance, a persistent disk, a snapshot, 另一個 image。並且是可以share給其他GCP project(其他人)的。

以下是我們在日常維運GCP的VM時會遇到的一些問題解方。

第一個問題是要在GCP上使用VM需要有哪些條件。再來是如果有合規或授權限制，需要在特定的硬體上運行VM需要使用甚麼樣機器。第三個則是大規模的日常管理維運需要藉助GCP的哪種服務。第四個則是，進入單一Linux機器的console要如何連接。最後兩個則是對外Internet的一些限制方式。

Instance Group

所謂Instance Group是指單一邏輯實體內有一堆VM。而我們不需每一個VM instance直接控制，而是透過Instance Group來進行控制。而這個單一實體的的VM的生命週期是非常相同的。

而Instance Group有兩種類型:

• Managed — 這是使用template建立完全一模一樣的VM。它的功能在於有Auto scaling, auto healing 與managed releases。
• Unmanaged — 這是在同一群VM中，每一個VM中的設定不盡相同。而且沒有上述managed的這些功能。

不論是哪一種Instance Group的範圍可以設定在Zone或Region level。通常建議在Region level以取得整個Instance Group的高可用性。

MIG(Managed Instance Group)

上面說道MIG內的VM instance都是從template來建立的。它的重要功能如下:

1. VM數量的可維護性 —如果有任何的VM掛掉，MIG會自動替換有問題的VM，來維持我們所設定的機器數量
2. Auto scaling — 根據負載來自動加減機器的數量
3. 維持高可用度 — 若把MIG的範圍設定在region level，則不須擔心當任一GCP的機房掛掉時，服務掛掉
4. 當Application有update/upgrade時，不會有downtime。rolling updates(逐步替換)與Canary Deployment都有支援

在MIG中，Instance Template是必要的選項。在其他MIG的設定中，Auto scaling的設定需要選擇最小/最大的Instance數量。並且是根據甚麼指標(GCP的監控服務 — Operations Suite)來變大或縮小VM數量:

1. CPU的使用率(全體平均值或單一Instance) — 如70% CPU Utilization
2. Load Balancing使用率 — RPS(Request per second) — 如每秒 100次request

另一個選項是"Cool-down period"，這是指一個新的VM被啟用後，要等待多少時間(單位是秒)之後根據指標決定下一個VM是否啟用，主要是讓我們的Instance Group scale out/in的頻率不要太頻繁。Scale In Controls這個選項是讓機器數量短時間不要下降太快。例如在10分鐘內降幅不要高於10%或是5分鐘內最多不可以關超過3台VM之類的。

另一個是autohealing，配置具有初始延遲的運作狀況檢查（在檢查運作狀況之前，應該等待多久讓應用程式完成初始化？）

MIG的Update

上面我們提到了在MIG中，我們如果有任何的update需要對VM做更新時的一些方法。其中Rollimg update是逐步更換Instance Group中VM到新的版本。

我們可以指定特定的template來更換，這是金絲雀的佈署方式(canary testing)。另外也可以指定執行時間，是要立即(proactive)執行或是稍後執行，例如我們要更改整個Instance Group的size大小(Opportunistic)。執行時的忍受政策:

• Maximum surge: 每個時間點更換多少台VM？(這通常用在 Update Replace)
• Maximum unavailable: 更新期間可以有多少個機器不能運作(這通常用在Update restart)？如果把這個選項的數字設定為零，哪麼我們在update的過程中就部會有任何capacity的損失(因為期間會有額外的機器出現)。

Cloud Load Balancing

這是GCP的Fully distributed, software defined managed service。重要的功能如下:

1. Health check — 會去檢查Instance是否正常。若否，則會替換掉有問題的。
2. Auto Scaling
3. Global load balancing with single anycast IP。這通常是For internet的Load Balancer

啟用LB可以讓我們的backned service達到以下三種能力

1. High Availability
2. Auto Scaling
3. Resiliency

Load Balancing的類型

GCP的LB有三種類型，如上圖左邊有L7/L4/L3，所以相對於支援上圖右邊的Protocol。大部分的Application layer只能走Http/Https等L7的協定，但是有少數的Application於L4的協定溝通(這是因為需要High Performance)。

L3的協定通常是不可靠的網路協定，因為是跑IP Package。在L4又分成以下三種:

• TCP (Transmission Control): 可靠度(Reliability) > 效能(Performance)
• TLS (Transport Layer Security): Secure TCP
• UDP (User Datagram Protocol): 效能> 可靠度

Cloud Load Balancing的術語

Backend — 從Load Balancing接收流量的endpoint group(例如: instance groups)

Frontend —指定 IP 位址、連接埠和協定。 此 IP 位址是我們的client會連接的前端 IP。 如果有流量加密(如SSL/TLS)，則憑證也必須在這裡指定.

Host and path rules (For HTTP(S) Load Balancing) — 定義一些規則來將不同需求或類型的流量導到不同的backned。可以基於以下三種類型規則來導流:

• By Path — 如不同的網址- jasonkao.com/a 與jasonkao.com/b
• By Host — 不同的站台-asite.jason.com 與 bsite.jason.com
• By HTTP headers (Authorization header) 與methods (POST, GET,等)

Load Balancing — SSL/TLS Termination/Off loading

從Client到Backend service的過程中，第一關通常是從Internet連到LB(通常走HTTPS)。接下來從LB到backend(如VM)，這一段屬於GCP內部網路。流量可加密也可不用加密。SSL/TLS Termination/Off loading意旨，Client to LB(through Internet)是加密的(HTTPS/TLS)，LB to backend是不加密的(HTTP/TCP)。

下圖為當我們依需求來選擇需要使用GCP的哪一種LB。

下表為GCP LB的功能表

多個Region中的 MIG 之間的Load Balancing

GCP的HTTP(S) Load Balancing可以將流量送到同一個Region(不同Zone)的MIG，也可以將流量送到不同Region(也可以是不Zone)的MIG。而用的都是同一個對外Public IP。user的流量會送到離它最近的Region(基於網路Low latency)。

LB也會檢查其Backend的服務是否正常。如果healthy檢查失敗，LB將會restart有問題的instance(前提是firewall要對health check有設定allow)。流量可以設定特定的Region，當這個Region整個掛掉時Global LB會把流量導到另一個Region。

HTTP(S) LB的概念

根據上圖，又右至左:

• Backend — 可以是MIG或是Microservice
• Backend service — 可以是一組Backend或是Cloud storage的bucket
• URL maps — 根據不同位置陸路由到不同的backend service。例如上圖 /service-a 與 / service-b就是不同的backend service

每一個backend service可以有多個backend，並且這些backend都可以處於不同的Region(如下圖所示)。

如果要做到Global Load Balancing到不同的Region，我們的GCP網路等級需要Premium Tier(這個在Frontend的設定中選擇)。

GCE與LB的架構設計

在設計GCP平台時我們需要針對以下要求進行強化，這也是一般地端資料中心會有的要求:

• 建立韌性(Resiliency)
• 強化可用性(Availability)
• 強化擴充性(Scalability)
• 增強效能(Performance)
• 強化安全
• 降低成本
• 與其他等等要求……

甚麼是可用性?

就是當使用者需要使用應用程式或服務時，它們就要可以使用。我們通常用一段時間的百分比來計算可用度，例如99.99的可用度(也就是4個九)。以下為一個可用度規格表。

哪麼針對GCE與LB的高可用度，我們該如何設計呢?以下為一些設計要點:

• 每個微服務有多個Regional Instance Groupd
• 使用Global HTTPS LB分配負載
• 配置Instance Group和LB的health check
• VM instance啟用live migration

這個優點在於

1. 如果某個Region掛了，其他的Region還是可用
2. GCP的Global LB是具高可用度的
3. health check確保了Auto healing的機制

可擴充性

而所謂的可擴充性意指:
系統要每秒處理 100 筆交易。 預計負載為下個月會增加10倍。我們能否在不降低效能的情況下應對用戶、流量或資料大小的成長？較多的服務需求是否與資源成成比例的增加？

我們需要有能力去應對"計畫性"與"非計畫性"資源擴張的需求。這種做法通常有兩種:

1. Scale up/down — 也就是單一個Instance(如VM)不斷的往上加資源(CPU/Memory/HDD)，但很快會達到極限。不管我們使用哪一朵雲，我們都可以看到每個VM instance都有最大的容量極限。
2. Scale out/in — 增加instance的數量，並不斷往上加。這種方式的擴充的另一個效益是增加系統的可用性，因為機器數量變多。

剛剛提到另一個功能是所謂的Live Migration，功能就跟Vmware 的Vm migration一樣。為了不受底層機器的影響。Live Migration的特點如下:

• 它會migrate到同一個zone的不同實體機(Host)
• 不會更改VM的任何屬性
• 支援具有local SSD 的instance
• 不支援 GPU 和preemptible instances

所以我們需要針對"Availability Policy"做出符合我們需求的設定:

關於底層主機維護：定期基礎設施維護期間應該執行什麼動作？

1. Migrate（預設選項）：將VM Instance遷移到其他硬體
2. 終止：對VM instance執行關閉

自動重新啟動 — 如果VM Instance因非人為因素而停機，則重新啟動VM instance。通常的原因是GCP底層的維護事件、非計劃性的硬體故障等。

另外我們也可以在VM上加入GPU的功能，這可以幫助我們進行關於AI/ML的任務作業。不過這也會導致較高的成本發生。我們也需要使用安裝了 GPU library（深度學習）的Image，否則，GPU將不會有作用。

GPU 的限制：
並非所有機器類型都支援（例如，shared-core或memory-optimized機器類型不支援）。在Host維護時只能“Terminate VM instance”。所以具有GPU VM的可用性政策應該是: Automatic restart — on。

安全性

1. 使用Firewall Rules
2. 盡量使用 Internal(Private) IP
3. 當有合規要求時可以使用Sole-tenant nodes
4. 建立一個hardened custom image

效能

• 選擇適合我們系統需求的 Machine Family
• 使用 GPU與TPU來增加效能
  使用GPU來加速機器學習與資料處裡系統
  使用 TPU 在機器學習工作負載中執行大規模矩陣運算
• 用 hardened custom image而不是在啟動時安裝軟體(這要視狀況，有好有壞)

韌性

所謂韌性意指 — “即系統的一個或多個部分發生故障，系統也能提供可接受的服務”。所以在GCE/LB的韌性架構應該是LB+VM(MIG功能的)，並且有可用的資料。例如使用GCP的operation suite並且在VM中安裝Agent將log送到Cloud Logging。為意外（和變化）做好準備，像是啟用Live migration和Automatic restart（如果可以選的話）。配置正確的health check還有DR: 將最新image複製到多個region。

成本

GCE的價格模式有兩種SUD(Sustained use discounts)與CUD(Committed use discounts)，與Spot VM。

SUD是GCP會幫我們計算自動折扣的，機器開得越久折扣越多(如下圖所示)。例如如果我們每月使用 N1、N2 機器類型的時間超過 25%，則每增加一分鐘即可享受 20% 到 50% 的折扣。

這適用於 GKE 和 GCE所建立的instance。但是不適用於某些機器類型（例如：E2 和 A2），也不適用於由 App Engine Flex 和 Dataflow 建立的VM instance。基本上就是使用在某些IaaS的VM上。

所謂CUD就是我們跟GCP承諾一個長期租約(1或3年)。通常這是可預測的系統並且不會有太大變化的，例如ERP。長租的折扣最多可以打到3折(70% off)。適用狀況與限制同SUD。

所謂Spot VM是是很便宜的VM(60% — 91% discount off)。這種的VM價格比CUD還要低。所以我們的Application要跑在這一類的VM需要有高度的fault tolerant。這比較適合來跑batch processing jobs，像是跑月報資料。

Spot VM的限制有

• 沒有高可用度
• 沒有SLA也無法傳換成一般性的VM
• 沒有Automatic Restarts
• 不能用Free tier來使用Preemptible VM

GCE的使用費率是以秒計費，沒開機就不算錢(HDD還是有算錢)。所以我們在使用GCP時永遠都要有Budget alerts，不然很可能費用超標。