练习 - 确定并解决入站网络连接问题

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>
```
这次，应用不会生成任何输出，最终可能会超时，并显示消息“向负载均衡器发送请求时出错: 操作已取消”。按 Enter 停止应用程序。
在 Azure 门户中，选择“仪表板”>“dashboard-learn-ts-loadbalancer”。
查看显示运行状况探测状态和数据路径可用性的仪表板。可能需要将时间范围更改为过去 30 分钟。它应该如下图所示，其中两个指标均降为零。

此图显示虚拟机未响应负载均衡器的运行状况探测请求。它们被标记为运行不正常。在这些虚拟机上运行的客户端和应用程序之间没有可用的数据路径。

诊断和修复问题

第一步检查虚拟机是否正在运行。我们一次解决一个虚拟机问题。先看一下 appretailvm1。稍后会检查 appretailvm2。

测试 appretailvm1 虚拟机

无法直接对 appretailvm1 或 appretailvm2 虚拟机进行 ping 操作，因为它们具有仅对同一子网上的其他虚拟机可用的专用地址。首先连接到跳转框，跳转框具有公共 IP 地址，并且位于同一子网中。然后，可从此处对虚拟机进行 ping 操作。

退回到 Cloud Shell。
运行以下命令以获取跳转盒虚拟机的 IP 地址。
```
bash ~/load-balancer/src/scripts/jumpboxip.sh
```
运行以下命令以获取运行初始安装脚本时创建的密码。复制此密码以供下一步使用。
```
cd ~/load-balancer/src/scripts
cat passwd.txt
```
使用上述命令输出中的 IP 地址和密码登录到 Jump Box。如果使用其他用户名，请替换 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% 的虚拟机显示为正常。

选择图表以转到负载均衡器的“指标”页面。可以使用此页面刷新图表，并放大特定时间段。
在 Cloud Shell 中，运行以下命令以离开跳转盒。
```
exit
```
使用负载均衡器的 IP 地址再次运行压力测试应用程序。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
与之前一样，测试仍然失败。现在有从负载均衡器到至少一个虚拟机的路径，但此路径在虚拟网络外部运行的客户端上不起作用。按 Enter 停止压力测试应用。

检查子网的 NSG 规则

此问题可能是由阻止外部流量的网络安全规则引起的。

在 Azure 门户中，转到资源组“learn-ts-loadbalancer-rg”。
选择“retailappnsg”网络安全组。此安全组确定允许通过虚拟网络的流量。
选择“入站安全规则”。尽管存在规则允许来自虚拟网络中运行的负载均衡器的传入流量，但不存在规则允许来自虚拟网络外部的通过端口 80 的流量。
选择添加。此时会显示“添加入站安全规则”窗格。
输入下列设置，再选择“添加”。

属性值

源任意

源端口范围 *

目标任意

服务自定义

目标端口范围 80

协议 TCP

操作 Allow

优先级 100

名称 Port_80

描述 HTTP 端口
在 Cloud Shell 中，使用负载均衡器的 IP 地址再次运行压力测试应用程序。
```
cd ~/load-balancer/src/stresstest
dotnet run <ip address>
```
应用程序现已运行，但只能从 retailappvm1 虚拟机获得响应。允许应用程序运行两到三分钟。按 Enter 停止。
在 Azure 门户上，转到仪表板。
选择平均数据包计数指标的图表。请注意压力测试应用程序最近一次运行的峰值。当两个虚拟机都可用时，此值应至少是先前记录的值的两倍。尽管现在已有正常工作的系统，但正在工作的虚拟机即将过载。

属性	值
源	任意
源端口范围	*
目标	任意
服务	自定义
目标端口范围	80
协议	TCP
操作	Allow
优先级	100
名称	Port_80
描述	HTTP 端口

测试 appretailvm2 虚拟机

似乎 appretailvm2 虚拟机可能无法正确处理请求。需要检查此虚拟机是否已启动，以及负载均衡器是否可以连接到该虚拟机。

在 Cloud Shell 中，使用上述命令输出中的 IP 地址和密码登录到 Jump Box
```
ssh azureuser@<jump box ip address>
```
尝试对 appretailvm2 虚拟机进行 ping 操作。
```
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 规则。此更改允许 TCP 的端口 80 上的入站网络流量。

你已将负载均衡的 HTTP 服务恢复为完全运行。