最近是否常聽到某某國家所屬雲端服務異常中斷造成巨大的商業損失呢？而即使是Google也不例外,我們在先前作負載平衡時都是同一區域內,但試想最好的解藥其實是預防,當你的機制做越完善當別人在哭的時候你可以轉頭偷笑一下...
不能這麼沒有同理心,要記得好好安慰人家知道嗎？

GCP有個不太明顯的選單...好奇的我來看看啥功能都沒有，心想這是做辛酸的嗎？

喲!這不就是之前在建立負載平衡服務時有個標準與進階兩種層級的選項,預設是進階..所以全部都是預設@@

好啦!來深入一點來看,最大重點就是標準無法跨區而進階可以,這說白了就是全域負載平衡GSLB嘛!

很明顯無法跨區的標準層級只能區域內各自獨立無法串連跨區提升高可用性

而進階層級就可以直接在同個LB綁下面多個後端集區內來自不同的地理區位置GCE服務悠!

不囉說直接來實測一下,我們拿這LB作範例也可以看到後端集區就綁定一組東亞網路群組下的GCE

綁定LB需要配合個體群組(範本做水平擴展)或是網路端點群組,我們這次的示範情境比較適合用網路端點來做,可以看到吃的是東南亞另一個172.16.x.x的網路GCE(需確認妳的後端GCE當初建立是在a,b,c哪個要選對不然後面設定端點會找不到)

設定完成就直接建立

第二組網路端點設定完成(東南亞)

先確保這東南亞的GCE網站是OK的,沒錯就是它

這是原來就綁在LB上的GCE網站(東亞),記得這是新版2016的IIS預設頁,這樣方便等會區分

重點設定來了,進到負載平衡服務看到原來就有綁定一組Pool

在同個Pool新增剛剛建立的網路端點群組包含GCE與IP的設置(如果沒有跨區是根本選取不到的..看起來有幾分像悠!)

設定上去了就直接更新吧!

OK確認後端兩組端點的GCE健康狀態都正常,大概會需要幾分鐘的時間等待

直接來測試網站,記得一樣是LB的Public IP,走的是原本東亞的預設IIS網站(其實多次F5都一樣發現並非輪循)

把東亞這台GCE模擬異常直接關機

大概需要10幾秒的時間會先出現502伺服器bad Gateway,再繼續連已經正常(接手給東南亞來提供服務)

再把東亞這台GCE模擬系統修復直接開機

確認已經上線了,健康狀態正常

立刻回到東亞預設網站.

因為也可能GSLB有就近地理區提供服務的優先序,我們都在台灣,東亞機房也就是台灣彰濱,模擬從東南亞來連連

一樣還是連到第一組東亞的預設網站

所以目前看來GCP的全域負載平衡並無法有多種模式的A-A,只能當作A-S主要異常時的立即切換的情境應用.

好了!今天就先到這裡啦!!大家81