這邊開始介紹Elastic Load Balancing服務，以下簡稱ELB，玩過F5, Citrix, A10, LVS, HAproxy的人對這種服務一定不陌生，簡單說如果你前端有多個Instance（VM）或服務，但需要有一個高可用或是附載均衡的機制，在AWS上就要使用這個服務，如下圖，上面是Client連到Load Balacner，以下簡稱LB，透過LB把請求送到後端Instance，如果有一個Instance無法工作，LB自動導到正常服務的Instance，達到高可用服務。
如下圖，AWS的Free Tier可以讓我們免費使用每月750小時，但又分每月15GB的Classic load balancers使用量與15 LCUs的Application使用量。
我們先來看看ELB的分類，如下圖，可以看到ELB有三種類型的服務可以選擇，這邊我們就只討論Applications Load Balancer與Network Load Balancer，為什麼不討論Classic Load Balancer，因為這是舊架構的東西，再看一下Platforms分類，Classic除了VPC外還多了一個EC2-Classic，這是早期的EC2的架構，相信只要是剛開始的使用者應該都用不到。
而Applications Load Balancer與Network Load Balancer使用情況怎麼區分？最簡單就是Protocols來區分，Applications只支援HTTP和HTTPS，只要是使用這兩種的服務，可以毫不猶豫地選擇使用Applications，Network則是走TCP協定，比如說資料庫，JAVA服務可以使用Network，Network又提供靜態IP，根據AWS文件敘述，這個模式的效能更好，如果有效能的需求也可以直接選擇使用Network模式。
Applications Load Balancer的運作方式如下圖，先建立Listener，而它的作用是接收請求的連線後轉發連線到後段的Target Group，建立好Listener後，預設會有一個Default Rulec會將流量導入到後端的Target Group，也可以新增自訂的Rule將特定流量導入到想要的Target Group；一個Load Balancer可以有多個Listener，而一個Listener可以配置多個Target Group，假設我們有三個網站，而這三個網站放在個別的Instance，這時只要建立一個Applications Load Balancer與三個Target Group，然後再設定規則讓不同來源的網址導入到相對應的Target Group即可，而Target Group則是將Target加入，Target就是對應已經建立好的EC2 Instance，這邊也會針對Target設定健康檢查(Health check)的規則，如果Health check檢查不過，來自Listener的流量則會導入到Health check正常的Target來達到高可用的效果。
計費方式這邊就不詳談，在ELB的官方介紹頁面也有詳細的介紹（最下方有計算範例），可以先透過那邊的範例得知大概使用的費用。
計費方式這邊就不詳談，在ELB的官方介紹頁面也有詳細的介紹（最下方有計算範例），可以先透過那邊的範例得知大概使用的費用。
上圖是這次Lab架構圖，我們沿用搭建一個簡單Windows與Linux LAB環境(一) Free Tier介紹與LAB環境介紹的LAB環境來實作ELB的功能，這次LAB目標有下面幾個
- 建立Load Balancer
- 測試負載均衡與高可用性
- 設定ELB的Access Log
在完成Lab後，使用者連到Load Balacer會導入到Linux或是Windows的網站，然後在將Windows的IIS服務停掉，接著一直重新Refresh網頁，看是否正常，最後我們在設定ELB的Access Log來完成這次Lab。
沒有留言:
張貼留言