跳到主要內容

HTTP Load Balancer

測試情境

本次的目的是想要證明HTTP load balancer (HLB)在偵測不同地區流量導向的功能是否OK...

由於HLB的backend server限制以instance group為單位加入,而instance group限制僅可以加入同一個zone中的server instance,因此這次我們開兩個zone的機器,並且把機器分別掛在該zone的instance group中,如果到時候從台灣的連線回覆台灣地區主機的資訊,而美國地區連線則由美國地區主機回覆,則代表HLB可以正確分流不同地區的流量,由該地區主機負責... 

架構說明

本次的設定架構如下:

http-load-balancer (107.178.248.201) ---------->  instance-group-1 / 104.199.154.208 (asia-east-a) 
                                                             \
                                                              \ -------> instance-group-us / 104.154.41.113 (us-central1-a) 



其中hlb為本次設定的http-load-balancer名稱,其下設定hlb-fw1附掛一組IP做hlb的入口,並且設定backend service: hlb-bkend-1收容instance-group-1與instance-group-us兩個分別收容來自APAC與US的主機。

上面總表是以整組的方式呈現,部分的元件在該表中已經被隱藏,我們可以在HLB的進入頁面列表出,選擇advance view來顯示HLB的詳細元件....



Forwarding rules - 顯示HLB所attach的入口IP,每個forwarding rule會預設掛載一個target...



選擇target item或是點選Target proxies的頁籤,可以看到該預設proxy的設定,主要會看到proxy跟url map的對應狀況



選擇Backend services頁籤,可以看到以設定的backend service: hlb-bkend-1,我們可以點進去看詳細的backend service的設定



這邊可以看到該Backend中有兩個instance group的主機群,並且有個frontend location的圖示,分別把default route指定到instance-group-1中。



最後是Health check,在這個頁籤中,可以設定HLB針對哪個協定的哪個port做監控,這邊必須注意後端的主機必須服務在該位置,以避免被HLB納入不正常的主機而Pass掉...



上面設定都完成後,可以直接從所開立的APAC與US主機上直接透過curl分別測試HLB的IP、APAC主機IP、US主機IP...

直接測試US Server與測試APAC Server:

直接連US server:


直接連ㄍAPAC server:


來自US client連線測試HLB:



來自APAC client連線測試HLB:



初步測試,這邊可以看到來自各個地區的用戶應當會就近連線到鄰近該地區的主機,因此回應部分才會分別顯示不同地區的機器...

當HLB設定完成後,在無流量狀況下,backend service的圖表狀態如下:


而分別從不同地區request HLB的話,可以看到Frontend Location的部分有來自Asia與North America兩個地點的流量,並且分別導到不同的instance group...



這時候我們把request的流量開大一點,可以發現Asia與North Ameriac中間多一台黃色的線,顯示7.1 RPS的流量,代表在US的機器(instance-group-us)在流量附載超過設定時候,HLB會將流量往instance-group-1丟...



結論

上面的測驗原則上證明HLB可以擔任全球分散流量的樞紐,透過HLB導向各地區的主機群,也讓機器被攻擊的風險可以分散在不同的地區。

針對應用的部分,HLB很適合擔心被攻擊的服務,如果您在不同的地區設定了伺服器,並請透過HLB串聯,則當某個特定地區機器受到大量攻擊時候,則可以只影響到該主機群,而不用擔心影響整個服務... 不過,服務器的配置上仍需要考慮到機器數量與request數量的比例,畢竟HLB最後仍是會將流量導到剩下的主機上...

留言

這個網誌中的熱門文章

Google指令碼基本操作介紹 - Web Server篇

Google的指令碼是什麼東西呢?!原則上他就是Google的一份靜態檔案,但是透過Google的雲端服務平台的一些能力,將靜態檔案內的scriptlet片段拉到Google的後端作運算,寫起來就像在寫JavaScript(這邊說Node.js可能比較貼切,因為同為server side language)或JSP,而在scriptlet片段中,則可以操作許多Google的API服務,甚至他提供你連接JDBC的能力、URL呼叫的能力...等,宛如就是一套完整的雲端程式語言(這樣說應該不為過拉,這真是個創新!),有並駕於App Engine的氣勢喔!
Google指令碼的範圍很廣,筆者也仍在摸索中,之前介紹過透過Sheet+指令碼做一個簡單的URL監控(這裡),而本篇簡單介紹一下指令碼如何製作一個Web Server(嚴格說起來是Web Page拉,但是具備Server端運作功能喔!)。您將可以體驗到No-Hosting Web Server的威力!
指令碼是Google Drive的一個服務,Google將指令碼(Code)以檔案方式寄存在Drive中,類似的靜態檔案服務的應用,最近滿火紅的!

首先開啟指令碼時候,選擇"作為網路應用程式的指令碼",檔案開啟後,會有愈設定程式碼片段供編輯


程式碼片段大致上如下,是一個doGet function,Web base的指令碼需要認得doGet()作為server的進入點 如果選擇到空白專案的話,只要把doGet function建上即可

作為一個Cloud IDE,Google當然也有把Code Hint擺上來,透過簡單的提示,寫啟程是來就更容易拉!

而Web部分物件的建立主要是透過HtmlService這個模組來進行操作,我們利用他來output html, load static html page, load template html page..等,範例如下:
Output HTML: // Script-as-app template.
function doGet(e) {
  return HtmlService.createHtmlOutput("<h1>HELLO!</h1>");
}
透過上HtmlService的createHtmlOutput的功能,…

透過Google Apps Script結合Google Form做即時郵件通知

體驗過Google Apps Script的功能後,也發現他結合GmailApps的模組GmailApps的應用可以用在表單填寫完成後,做發信的通知 例如您開立了一個訂購的表單,為了要在第一時間通知商家有訂單進入 就可以直接呼叫Gmail做發信的通知,讓手持Smart Phone的我們可以很快的知道生意上門了!
下面規劃三個function,其中: onCommit():為form commit時候觸發的function,需要掛載於form commit trigger上
jsonArrToTable():目的將json array解析成為一個Table
getLastRowTable():目的將整個table的回傳過濾為剩下第一筆(表頭,含有Form的欄位說明)與最後一筆(原則上就是剛剛送出的那一筆表單)完整程式碼如下: function onCommit(){
  var sheet = SpreadsheetApp.getActiveSheet();
  var rows = sheet.getDataRange();
  var numRows = rows.getNumRows();
  var values = rows.getValues();
  var content = getLastRowTable(values);
  var htmlBody = "Hi Admin: <br/><br/>有訂單拉,檢查一下吧! <br/><br/>" + content + '<br/><br/>Send by Google Apps';
  GmailApp.sendEmail(
    "your-email-address@gmail.com", 
    "Order Confirm Notice", 
    htmlBody, 
    {from: 'from-email-address@gmail.com', htmlBody:htmlBody}
  ); 
}
function getLastRowTable(arr){
  var newArr = new Array();
  newArr.p…

透過Google Cloud Storage建置您的靜態網站

大家知道靜態網站的服務越來越先進,透過Github Page或是S3都可以快速的建置好可以提供服務的靜態網站,這次要介紹的是Google Cloud Storage上建置靜態網站的功能...
首先我們先準備一個美美的靜態網站,不少人可能想到用PC的網頁編輯器,我這邊是使用Jetstrap的雲端服務來拉出基本的版型:


左上方的是提供下載專案的地方,下載之後可以解壓縮後看到裡面的html跟css相關檔案


接下來就是透過Google Cloud Storage來把這個些檔案變成一個網站囖,設定相當簡單...
Step 1 : 在Google Cloud Storage建置您的domain bucket,並把相關檔案上傳到這個bucket裡面
這邊需要先有Cloud Platform Project,並且開通好Cloud Storage的服務,這邊不贅述這些設定... 我在這邊建立的是gsweb.micloud.tw這個網站,因此bucket用這個命名(這邊必須注意,Google會針對domain name進行認證,如果domain name非自己所屬,或被別人註冊了,將無法使用該domain name來建立bucket),並且將檔案上傳,主頁修改為index.html。

這邊完成後,仍需要在最右邊的"SHARED PUBLICLY"的地方勾選發佈,讓全世界的人可以看到您的網站...
Step 2 : 透過gcutil將bucket變成一個網站
下面指令可以讓您設定一個bucket成為靜態網站,並且指定一個主頁,以及錯誤頁面,相關的help可以透過gsutil help setwebcfg來檢視...
$ gsutil web set -m index.html -e 404.html gs://gsweb.micloud.tw



Step 3 : 設定Domain name CNAME對應
接下來您需要到您的DNS server上指定一筆CNAME記錄,將yourdomain.com對應到c.storage.googleapis.com,指定完成後,在nslookup的查詢會類似這樣:


這也表示您的網站應該已經生效了: