Azure Traffic Manager 偵測端點 (Endpoint) 之機制

  • Article

Microsoft Azure Traffic Manager 可以提供用戶跨資料中心之負載平衡或失敗回復 (Failover)，用戶經常詢問 Azure Traffic Manager 失敗回復時偵測端點 (End Point) 的運作方式，到底所設定的主要資料中心端點失效多久後才會切換至備援的資料中心端點? DNS TTL (Time-To-Live) 時間設定成很短有助於縮短停機時間嗎?

image

針對此類問題 https://msdn.microsoft.com/en-us/library/azure/dn339010.aspx 提供了詳細描述，在此簡述如後。Microsoft Azure Traffic Manager 偵測端點的步驟如下圖:

IC697947

  1. GET – 依據用戶的設定，Azure Traffic Manager 偵測系統會發出 HTTP GET 去偵測端點。
  2. 200 OK – 倘若 10 秒鐘內偵測系統收到 HTTP 200 OK 之訊息回覆，代表此一 Azure Cloud Services 或 Azure Websites 端點運作正常。只要是回傳非 HTTP 200 OK 之訊息或超過 10 秒未回應都視為端點偵測到問題。
  3. 間隔 30 秒檢查一次 – 偵測系統的檢查動作每 30 秒會執行一次。
  4. 系統發生問題，端點無回應 – 倘若在 30 秒偵測間隔中端點發生問題，Azure Traffic Manager 是無法得知的，必須等到下一次偵測檢查才會發現。
  5. 確認端點出現問題 (4 次嘗試) – 當 Azure Traffic Manager 偵測系統發送 HTTP GET 而超過 10 秒未獲回應，偵測系統將持續以 30 秒為間格偵測三次，確認端點是否真的停止運作，這意味著 Azure Traffic Manager 至少要花費 1.5 分鐘來確認端點真的已經停止運作， 在連續三次的偵測中若有一次順利在 10 秒內收到 HTTP 200 OK 回應，就視為監測端點已經恢復正常。
  6. 標註端點發生問題 – 當連續四次偵測回應都失敗後，Azure Traffic Manager 偵測系統會標註該端點失效。Azure Traffic Manager 對外服務的 domain name 開始啟用備援資料中的端點取代原本這個已經無法運作的端點。
  7. 存取出問題端點的用戶流量開始降低 – 終端用戶的流量仍持續前往這個已經無法運作的端點，終端用戶開始感受此服務無法正常運作，由於終端用戶端與輔助 DNS Server 已經緩存 (cached) 了這個無法運作的端點 IP Address，隨著時間推進，DNS Server 逐步更新 domain name 的 IP Address，繼續流向這個無法運作端點的流量會逐漸減少。而 Azure Traffic Manager 監測系統繼續以 30 秒為間隔進行檢查。
  8. 出問題端點已經沒有用戶流量 – Azure Traffic Manager DNS TTL 預設時間是 5 分鐘 (300 秒)，因次當超過 DNS TTL 時間後，所有用戶會取得服務端點的新 IP Address，也就是備援資料中心的端點。原本出問題的資料中心端點已經沒有來自終端用戶的流量了。 而 Azure Traffic Manager 監測系統繼續以 30 秒為間隔進行檢查。
  9. 出問題端點已經恢復正常，用戶流量開始逐漸增加 – 原本出問題的端點可能在這個時間點恢復正常，但是 Azure Traffic Manager 仍不知道，要等到每 30 秒偵測程序完成後，才會標註系統恢復正常。
  10. 用戶流量回到原本資料中心的端點 - 當 Azure Traffic Manager 送出 HTTP GET 並在 10 秒內收到 200 OK 回應後，開始將對外端點切回原本的 DNS name ，當 DNS TTL 時間過後，所有用戶 DNS 緩存內容都會更新回原本主要資料中心的 IP Address， 所有用戶的流量會回到原本的資料中心。

了解 Microsoft Azure Traffic Manager 失敗回復 (Failover) 偵測機制之後，我們可以知道利用此失敗回復的機制而主要資料中心發生問題時，如果使用 DNS TTL 300 秒的預設值，終端用戶至多會感受到 5 分鐘的停機時間，因為 DNS 會緩存已經出問題的 IP Address 直到 DNS TTL 時間超過，而縮短 DNS TTL 時間到 1.5 分鐘以內的意義並不大，因為 Azure Traffic Manager 需要至少 1.5 分鐘的時間連續三次 30 秒間隔的偵測動作來確認端點失效，DNS TTL 過短也會讓 DNS 查詢變得頻繁，而影響系統回應時間。