MS Ignite 2017 网络服务新功能之高可用-负载均衡篇
本周可谓普大喜奔的一周，一年一度的MS Ignite大会再次召开，老规矩一大波新产品新功能扑面而来。我最近会抽时间把新功能陆续梳理出来给大家做介绍和演示（排名不分先后，完全取决于Preview的就绪情况）。今天我们先来一篇高可用之负载均衡篇，AZURE在负载均衡产品上从Day1的三四层负载均衡到Day2的四到七层负载均衡，产品在不断快速迭代演进，本次微软发布了第二代三四层负载均衡产品，相较以前有以下几点重大提升：
1. 可扩展性：单个负载均衡后端计算池实例数从100提升至1000；
2. 灵活性：上一代负载均衡后端计算池要求配置在同一个高可用集下才可以进行挂载，本代产品不在有此限制，后端计算池成员可随意组合；
3. 高可用性：一方面提供了对AZ可用区的支持实现同区域下跨中心的负载均衡（AZURE Vnet是可跨AZ的，负载均衡在不同AZ下采用相同头端IP）；另一方提供了HighAvailabilityPort功能的支持，该功能可谓重量级的功能为AZURE中的NVA高可用架构提供里利器。
4. 可运维性：支持完整的性能metric日志可以结合平台Azure Monitor，Azure Log Analytics服务做灵活的运维管理。
进入主题，今天主要给大家演示一下HighAvailabilityPort的亮点所在。为什么挑这个说，这里面是有梗的，在传统数据中心中的网络产品在做高可用架构的时候通常使用组播地址作为控制平面状态同步协议来实现设备的集群架构，而在公有云中恰恰虚拟网络中普遍不支持组播转发，这就使得很多高可用架构在公有云虚拟网络无法落地。通常的处理方法我们通过将传统的控制平面同步进行解耦为无状态同步从而摆脱对组播的依赖，无状态解耦后需要负载均衡方式将流量分担到多个节点上实现水平扩展。这个提供负载均衡角色的节点谁来扮演？传统云端负载均衡产品都是会做NAT（源地址NAT或目的地址NAT），这个时候在有些网络服务场景下就不适用了（比如防护墙场景，流量在穿越防火墙的时候目的地址并不是防火墙本身）。自己通过搭建计算实例来实现负载均衡角色，负载均衡功能虽然达到了但是这一层的高可用谁来保证（这台计算实例是个单点故障）。如果平台级（云平台云生提供PaaS级具备高可用性）的负载均衡产品（支持NAT模式及非NAT模式），那就完美适配了。AZURE SLBv2 + HighAvailabilityPort 呼之欲出，完美架构。
组网介绍：
VM1地址：12.0.0.4 CentOS，扮演客户端
VM2地址：13.0.0.4 CentOS , 扮演服务端（http）
LB地址：12.0.1.4
NVA1地址：12.0.2.4 CentOS，开启ip forward扮演防火墙
NVA2地址：12.0.2.5 CentOS，开启ip forward扮演防火墙
本文CentOS上的配置不在赘述，下面介绍负载均衡的配置方法
1. 创建新版负载均衡器（Standard Load Balancer）
注：目前该功能在如下区域支持，East US2, Central US, North Europe, West Central US, West Europe, Southeast Asia，目前该功能在Preview阶段，使用前需要先注册preview（方法参见如下链接：https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-overview）
跟以前创建负载均衡不同的是，注意选择SKU类型为Standard
2. 创建后端资源池
注：这里面有个小小的坑，如果你希望放在后端资源池中的实例已经关联了实例级公网IP，请检查该公网IP SKU类型是否为Standard。以前是Basic，所以需要考虑重新建立Standard SKU 公网IP或者实例不挂载公网IP。
是不是很嗨森，再也不用把实例都放在一个高可用集中啦。为什么限制被打破啦？大家可以去看看AZURE Availability Zone。
3. 创建健康检查策略
跟上一代负载均衡创建方法没有区别
4. 创建HighAvailabiltyPort负载均衡策略
勾选HA Ports，嘿嘿，发现不用写端口啦，潜台词就是甭管你往上送什么都可以负载均衡到后端。
5. 创建UDR自定义路由策略
本组网中上述拓扑中，如果不设置自定义路由，默认VM1去往VM2的流量直接互通不会穿过NVA1或NVA2，通过自定义路由将VM2地址的路由下一跳指向负载均衡器，负载均衡器上的HAPorts策略将流量负载均衡到NVA1或NVA2上，VM2到VM1反向访问相同原理。
配置结束了，在Portal里面勾勾点点就完成了，CLI和PowellShell还有ARM模板都是支持部署的（实测目前CLI的api version还有些问题，所以这里就不给大家用脚本举例了）。
做些测试：
VM1访问VM2 curl http://13.0.0.4
在NVA1和NVA2上打开tcmpdump观察流量是否经过，同时在VM2上打开tcpdump确认VM1的访问请求最终达到VM2
流量被负载均衡到NVA1
多次模拟请求，流量被负载均衡到NVA2
换个姿势，来个ICMP看看行不行（传说只支持TCP和UDP）
顺便测个收敛时间，11s，完爆之前的主备切换更改UDR的解决方案。
好啦，今天到这里啦，Ignite launch好玩的东西好多，慢慢来，下次给大家介绍一期安全的更新。
老规矩资源汇总：
1. 新版负载均衡介绍：https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-overview
2. HighAvailabilityPorts介绍：https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview
3. AvailabilityAzone介绍：https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
