跳到主要內容

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>");
1 則留言
閱讀完整內容

透過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){  
17 則留言
閱讀完整內容

存取docker container內的檔案

Docker既然是container概念存在，就想到應該可以透過原filesystem找到對應的container內的檔案 Google了一下，在/var/lib/docker/這個目錄底下可以找到對應的container實際存在的位置... 列印一下目錄可以發現aufs/mnt下有一堆長檔名的資料夾... 透過docker ps或是進入到docker container後，可以看得到docker的instance id 範例中是：61ba7253b842 因此進入到"/var/lib/docker/aufs/mnt/"後，後面加讓instance id後，在透過tab補字可以列出該container相關資訊 其中會包含一個有"-init"跟一個純instance id的資料夾... 列表一下這兩個資料夾 其中無"-init"的目錄存放的就是container對應的磁碟位置 測試一下檔案的存取....，切到該目錄下，touch一個檔案... 結果真的可以在container內部看到對應touch出來的檔案 透過可見的目錄位置，container與host在某個層鍍上可以互通許多東西喲... 檔案傳輸也不用再透過scp或ftp方式存取，超方便的拉！
張貼留言
閱讀完整內容