6.Azure负载均衡（下）

那接下来我就可以创建一个负载均衡来放在WEB01和WEB02的前面。

创建一个负载均衡器

输入负载均衡的名称，以及类型：

内部：内部负载均衡器 (ILB) 仅将流量定向到云服务内的资源，或使用 *** 来访问 Azure 基础结构；

公共：Azure 负载均衡器将传入流量的公用 IP 地址和端口号映射到虚拟机的专用 IP 地址和端口号，对于来自虚拟机的响应流量，则进行反向的映射。借助负载均衡规则，可在多个虚拟机或服务之间分配特定类型的流量。 例如，可将 Web 请求流量负载分配到多个 Web 服务器或 Web 角色。

在这里我选择的是公共。当然也是加入到我现有的资源组里

创建完成以后，我们需要添加后端池

选择我们之前的可用性集以及我们的WEB01和WEB02的网卡绑定

完成后可以看到后端的2台虚拟机

接下来创建负载均衡的侦听器，什么是侦听器？侦听器就是检测我们后端虚拟机是否还存活的一种检测手段，类似一个侦查员，利用端口是否通来判定后端的每一台虚拟机是否还存活，如果不通就代表死掉了，就会把流量切换到存活的虚拟机去。

基于TCP80端口进行端口侦听检测，每5秒检测一次，如果联系2次失败就判定该虚拟机死掉了，那么就会触发流量切换了。

设置完侦听器以后，我们就需要设置负载均衡的规则了，意思是公网上哪些端口需要进行转发到我的后端服务器。

设置我们需要负载均衡需要转发的端口，以及后端池是什么，采用什么侦听器，以及会话持续性。

会话持续性：会话持续性指定来自客户端的流量在会话持续期间博旭由后端池中的同一台虚拟机进行处理。

• 无：指定来自同一客户端的连续请求可以由任何虚拟机进行处理。

• 客户端IP：指定来自同一客户端IP地址的连续请求将由同一虚拟机进行处理。

• 客户端IP和协议：指定来自同一客户端IP地址和协议组合的连续请求讲由同一虚拟机处理。

空闲超时：保持TCP或HTTP连接打开而不依赖于客户端发送保持活动消息。

浮动IP（直接服务器返回）：建议仅在配置SQL AlwaysOn可用性组侦听器时使用此功能。它仅在创建规则且端口和后端端口匹配时才能启用。

创建完毕就可以看到这个规则了。

前段IP就是我们对外访问的地址了，如果我们之前选择负载均衡对外是静态的公网IP地址，只需要把域名解析到这个公网IP地址就OK了。

如果是动态的负载均衡公网IP地址，那么可以设置别名，然后把自己域名的别名指向这里设置的Azure别名即可。

试下我们的访问是否OK，第一次出现了Apache的页面。

我再回车刷新一次，出现了IIS的页面

当然用NLB的Azure别名地址也是可以访问的

这就表示我的负载均衡生效开始工作了。当然我还可以做一个测试就是关掉一台WEB虚拟机，例如我关掉WEB01（Windows Server IIS）,然后再访问NLB负载均衡的地址，可以看到我的WEB01已经无法打开了，但访问我的NLB负载均衡公网地址依然可以打开但已经把流量都转向到了WEB02，Apache页面了：

当然如果您也可以利用负载均衡做针对某一台虚拟机的端口转发，在这里我在WEB01服务器上新建了一个IIS的站点是81端口，编写了一个简单的html的页面：

在Windows防火墙和NSG那里都开启81端口的入站允许。

接着就可以配置负载均衡的如入站NAT规则了

可以添加一个入站NAT规则

配置完成以后，我们访问看是否OK？因为我负载均衡设置的公网IP端口8080，NAT重定向到WEB01的81端口，所有测试是OK通过的。

到这里我的4层负载均衡配置及测试就到这里结束了。