練習 - 識別並解決輸入網路連線問題

40 分鐘

在我們的案例中，已對網路設定進行了變更。您收到警示，表示後端集區中的虛擬機器對健康情況探查沒有回應。現在您需要診斷這些失敗的原因，並加以修正。

在本練習中，您會使用指令碼來重新設定環境，並使健康狀態探查失敗。您會使用本課程模組中學到的技能，讓負載平衡的 HTTP 服務能夠再度全面運作。

重新設定負載平衡器並重新測試

在 Azure Cloud Shell 中，設定資源群組名稱。
```
export RESOURCEGROUP=learn-ts-loadbalancer-rg
```
前往 src/scripts 資料夾。
```
cd ~/load-balancer/src/scripts
```
執行下列命令來重新設定負載平衡器、網路和虛擬機器。此指令碼會介紹一些您將診斷並修正的問題。
```
bash reconfigure.sh
```
執行下列命令，移動到 src/stresstest 資料夾。
```
cd ~/load-balancer/src/stresstest
```
再次執行壓力測試，並將 <ip address>替換成負載平衡器的 IP 位址。如果您不記得此位址，請再次執行 src/scripts/findip.sh 指令碼。
```
dotnet run <ip address>
```
這次，應用程式不會產生任何輸出，且最後可能逾時並顯示「將要求傳送至 Load Balancer 時發生錯誤: 作業已取消」訊息。請按 Enter 鍵停止應用程式。
在 Azure 入口網站中，選取 [儀表板]>[dashboard-learn-ts-loadbalancer]。
檢閱顯示健康狀態探查狀態和資料路徑可用性的儀表板。您可能需要將時間範圍變更為過去 30 分鐘。儀表板看起來應該如下圖，且這兩個計量都已降至零。

此圖表顯示虛擬機器未回應來自負載平衡器的健康狀態探查要求。因此，這些虛擬機器已標示為狀況不良。用戶端與這些虛擬機器上執行的應用程式之間沒有可用資料路徑。

診斷並修正問題

第一步是要檢查虛擬機器是否正在執行。讓我們一次解決一部虛擬機器的問題。因此先看一下 appretailvm1。稍後再檢查 appretailvm2。

測試 appretailvm1 虛擬機器

您無法直接 ping appretailvm1 或 appretailvm2 虛擬機器，因為這些虛擬機器的私人位址僅供相同子網路上其他虛擬機器使用。首先，請連線到具有公用 IP 位址，且位於相同子網路中的跳躍方塊。然後您可從該處 ping 虛擬機器。

返回 Cloud Shell。
執行下列命令，取得跳躍方塊虛擬機器的 IP 位址。
```
bash ~/load-balancer/src/scripts/jumpboxip.sh
```
執行下列命令，取得在執行初始安裝指令碼時所建立的密碼。複製此密碼以供下一個步驟使用。
```
cd ~/load-balancer/src/scripts
cat passwd.txt
```
使用上一個命令輸出中的 IP 位址和密碼登入跳躍方塊。如果使用了不同的使用者名稱，請使用該名稱取代 azureuser。
```
ssh azureuser@<jump box ip address>
```
在跳躍方塊中，執行下列命令來測試 retailappvm1 虛擬機器是否正在執行。
```
ping retailappvm1 -c 10
```
retailappvm1 虛擬機器應該會回應，指出該虛擬機器正在執行。下一步是要確認 Web 應用程式是否正在這部虛擬機器上執行。
執行下列命令，將 HTTP GET 要求傳送至 retailappvm1 虛擬機器。
```
curl -v http://retailappvm1
```
同樣地，此命令應該會成功。

檢查健康狀態探查和路由規則

retailappvm1 虛擬機器已啟動，且應用程式正在該虛擬機器上執行。負載平衡器與後端集區中的虛擬機器之間一定存在問題。

在 Azure 入口網站中搜尋監視器。
在 [監視器 - 概觀] 頁面上，選取 [服務健康狀態]。
選取 [資源健康狀態]。
在 [資源類型] 方塊中，選取 [負載平衡器]。在資源清單中，選取 [retailapplb]。
等候幾分鐘，以便評估負載平衡器的健康狀態。
在 [健康狀態歷程記錄] 中，展開最上方事件，並檢閱建議的步驟。這些步驟建議檢查負載平衡器中的 VIP (路由規則) 和 DIP (健康狀態探查) 端點。
移至資源群組 learn-ts-loadbalancer-rg，然後選取 [retailapplb]。
選取 [負載平衡規則]>[retailapprule]。此規則會在前端 IP 位址的連接埠 80 上接收 TCP 流量，並將其傳送至後端集區中所選虛擬機器上的連接埠 80。雖然健康狀態探查所使用的連接埠看起來很可疑，但此設定似乎是正確的。目前設定為連接埠 85。
關閉 [retailapprule] 頁面。
選取 [健康狀態探查]>[retailapphealthprobe]。
將 [連接埠] 從 85 改回 80，然後選取 [儲存]。
請等待數分鐘。
在 Azure 入口網站左側的功能表中，選取 [儀表板]。
在儀表板上，選取顯示 [健康狀態探查狀態] 和 [資料路徑可用性] 計量的圖表。 [資料路徑可用性] 計量應該上升到 100，但 [健康狀態探查狀態] 計量會停留在 50 左右。現在有一個從負載平衡器到至少一部虛擬機器的路徑可用，但只有 50% 的虛擬機器會顯示為狀況良好。

選取圖表以移至 Load Balancer 的 [計量] 頁面。您可在此頁面重新整理圖表，並放大特定的時間週期。
在 Cloud Shell 中，執行下列命令以離開跳躍方塊。
```
exit
```
使用負載平衡器的 IP 位址再次執行壓力測試應用程式。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
和之前一樣，測試仍然會失敗。現在有一個從負載平衡器到至少一部虛擬機器的路徑，但此路徑無法從虛擬網路外部執行的用戶端運作。按 Enter 停止壓力測試應用程式。

檢查子網路的 NSG 規則

此問題可能是因為網路安全性規則封鎖了外部流量所造成。

在 Azure 入口網站中，前往資源群組 learn-ts-loadbalancer-rg。
選取 [retailappnsg] 網路安全性群組。此安全性群組會決定允許通過虛擬網路的流量。
選取 [輸入安全性規則]。雖然有一項規則允許來自負載平衡器 (在虛擬網路中執行) 的傳入流量，但並沒有任何規則允許源自虛擬網路外部的流量通過連接埠 80。
選取新增。 [新增輸入安全性規則] 窗格隨即出現。

輸入下列設定，然後選取 [新增]。

屬性	數值
來源	任何
來源連接埠範圍	*
Destination	任意
服務	自訂
目的地連接埠範圍	80
通訊協定	TCP
動作	允許
優先順序	100
名稱	Port_80
描述	HTTP 連接埠

在 Cloud Shell 中，使用負載平衡器的 IP 位址再次執行壓力測試應用程式。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
應用程式開始執行，但您只會收到來自 retailappvm1 虛擬機器的回應。允許應用程式執行二或三分鐘。按 Enter 以停止。
在 Azure 入口網站中，前往儀表板。
選取 [平均封包計數] 計量的圖表。請注意最新執行的壓力測試應用程式尖峰值。此值至少應是稍早兩部虛擬機器都可使用時的記錄值兩倍。雖然現在有可運作的系統，但工作虛擬機器仍有多載的危險。

測試 appretailvm2 虛擬機器

appretailvm2 虛擬機器似乎無法正確處理要求。您需要檢查這部虛擬機器是否已啟動，以及負載平衡器是否可以連線到此虛擬機器。

在 Cloud Shell 中，使用上一個命令輸出中的 IP 位址和密碼登入跳躍方塊
```
ssh azureuser@<jump box ip address>
```
嘗試 ping appretailvm2 虛擬機器。
```
ping retailappvm2 -c 10
```
虛擬機器無法回應，且 ping 命令報告 100% 的封包遺失。 retailappvm2 虛擬機器未執行，或發生網路問題。
在 Azure 入口網站中，前往資源群組 learn-ts-loadbalancer-rg。
選取 retailappvm2 虛擬機器。
[概觀] 頁面會顯示虛擬機器已停止。選取 [開始]，然後等待機器開始執行。
返回連線到跳躍方塊的 Cloud Shell，並重複執行 ping 命令。
```
ping retailappvm2 -c 10
```
ping 作業這次應該會成功。
測試在 retailappvm2 虛擬機器上執行的應用程式是否回應。
```
wget retailappvm2
```
此命令逾時。可能是應用程式未執行，或網路發生問題。選取 Ctrl+C 來停止命令。
在跳躍方塊上，登入 retailappvm2 虛擬機器。出現提示時，請輸入稍早指定的相同密碼。
```
ssh azureuser@retailappvm2
```
執行下列命令，測試此虛擬機器上的應用程式。
```
wget retailappvm2
```
此命令應會成功，並建立包含回應的檔案 index.html。
檢查此 index.html 檔案。
```
cat index.html
```
此檔案應包含訊息 retailappvm2，並顯示此虛擬機器如預期回應。
關閉 retailappvm2 虛擬機器的連線。
```
exit
```
關閉跳躍方塊的連線。
```
exit
```
retailappvm2 虛擬機器已啟動，且應用程式正在執行，卻無法從虛擬機器外部連線至應用程式。此狀況表示網路發生問題。
在 Azure 入口網站中，前往資源群組 learn-ts-loadbalancer-rg。
選取 retailappnicvm2nsg 網路安全性群組。
選取 [輸入安全性規則]。

網路安全性群組的輸入規則會封鎖所有使用 TCP 通訊協定的外部流量。此規則的優先順序在開啟連接埠 80 的規則之前，所以會優先執行。
選取 retailappvnetnsgrulevm2denyall 規則，將優先順序變更為 300，然後選取 [儲存]。
等候兩分鐘，然後前往 [儀表板]。
選取顯示 [健康狀態探查狀態] 計量的圖表。此計量的值應該增加到 100。您可能需要重新整理圖表數次。
切換至 Cloud Shell，使用負載平衡器的 IP 位址再次執行 stresstest 應用程式。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
您現在應該會看到來自 retailappvm1 和 retailappvm2 的訊息。您已還原系統的完整連線。
按 Enter 以停止應用程式。

摘要

在本練習開始時，您看到虛擬機器未回應來自負載平衡器的健康狀態探查要求。您發現並解決了探查和資料路徑的混合問題：

在負載平衡器規則 retailapprule 中，健康狀態探查使用的連接埠誤設為連接埠 85，而不是 80。您將規則更新為使用連接埠 80。
網路安全性群組 retailappnsg 沒有允許連接埠 80 流量的輸入安全性規則。所以網路安全性群組封鎖了健康狀態探查。您新增了輸入安全性規則，以允許連接埠 80 的流量。
您檢查了 VM retailappvm2，發現其已停止。所以重新開機 VM。
啟動 VM retailappvm2 並看到應用程式開始執行後，還是無法連線到應用程式。網路安全性群組的輸入規則封鎖了所有使用 TCP 通訊協定的網路流量。此「全部拒絕」規則優先於允許連接埠 80 流量的輸入安全性規則。您變更了「全部拒絕」規則的優先順序，使其位於連接埠 80 規則之後。此變更允許連接埠 80 的 TCP 輸入網路流量。

您傳回了負載平衡的 HTTP 服務以完整作業。