Azure负载均衡器和SQL Server【下】

Azure负载均衡器的各种组件如何与SQL Server一起使用的。

将Azure负载均衡器与AlwaysOn可用性组一起使用

在Azure网络中，我们不能依靠vanilla网络路由来允许流量流向添加至虚拟主机news.webhostingtalk.cn/的辅助IP地址，例如那些作为Windows Server故障转移集群一部分而被分配的IP地址。因此，如果我们要创建一个可用性组监听器，那我们将无法与其建立连接。相反，我们必须依靠Azure负载均衡器来确定可用性组当前所在的位置，并在那里路由流量。当故障转移发生时，负载均衡器必须检测到这种情况，并将流量路由到新的主副本中。

完成此项工作的要求如下：

▲作为AlwaysOn拓扑（主副本和辅助副本）一部分的所有虚拟机都必须是同一可用性组的一部分。

▲分配给这些虚拟机的主网络接口卡必须是同一负载均衡器后端池的一部分。 即便您有多个AlwaysOn可用性组，只要组中的所有副本都包含在池中，您就可以使用相同的后端池。

▲AlwaysOn组的监听器必须使用与负载均衡器的前端配置相同的IP地址。如果有多个AlwaysOn组，那您就必须拥有多个前端配置（和多个相应的规则）。

▲监听器IP集群资源必须与探测端口配置在一起；这是WIndows集群服务将监听的端口，它能进行健康检查，从而确定资源在集群的给定成员上是否处于联机状态。

▲负载均衡器必须具有一个健康探测器，该探测器使用的端口必须与AlwaysOn监听器集群资源的探测端口一致，这样负载均衡器才能确定组当前所在的位置。

▲必须配置连接前端配置、后端池和探测组件的负载均衡规则。

当这些都就绪后，实际连接的路由方式如下：

1. 负载均衡器会定期探测后端池中的所有虚拟机，以检查哪些虚拟机在配置的探测端口上进行了响应。在任何给定的时间内，应该只有一台虚拟机在进行响应，因为AlwaysOn组只能安装在给定的副本上。

2. 当传入数据包到达负载均衡器时，通过配置的（公共或私人）前端IP地址，负载均衡器会把数据包路由到当前托管可用性组的虚拟机中。

讨论完这些话题之后，我们还需要探讨最后一个主题，即：从网络角度来看，如何才能正确保护AlwaysOn可用性组的安全。

保护AlwaysOn组中的数据库

正如我们在前一篇文章中讨论的那样，Azure中的网络默认是公开的（私有的）或关闭的（公共的）。也就是说，源自当前（或任何连接的）VNets的任何流量默认是被允许的，但任何来自专用网络（即互联网）之外的流量都是被禁止的。 在大多数情况下，私人流量都不足以正确保护我们的SQL Server，所以我们需要添加一些规则。下方是我们在典型的三层设计中进行设置的方式：

▲允许端口80和443上的互联网流量传输至Web服务器

▲允许端口443上的流量从Web服务器传输至应用程序服务器

▲允许端口1433上的流量从应用程序服务器传输至SQL Server

▲阻止所有其它入站流量

但是，如果我们按这种方式进行设置，并将SQL服务器配置在AlwaysOn拓扑中，而且还使用Azure负载均衡器，那我们很快就会发现我们无法连接至AlwaysOn负载平衡监听器的IP地址。在告诉你们为什么会出现这种情况之前，我想让你们假设一下发生这种情况的原因。请回想一下之前的部分（如有必要，请重新阅读一下文章），思考一下Azure负载均衡器是如何确定哪个服务器当前托管了AlwaysOn AG集群组的。您想明白什么了吗？

如果您认为“ 这是因为Azure负载均衡器需要能够基于配置的健康探测器来探测SQL Server虚拟机，从而确定集群组所在的位置”，那么恭喜您答对了！

在内部Azure网络的默认设置中，这不算什么问题，因为其中存在一个默认规则，它会允许被标记为来自负载均衡器的所有流量。但是，我们添加了自己的“拒绝所有传入数据”规则，这会覆盖任何默认的网络安全组规则，从而阻止探测流量。因此，我们必须添加一个新的规则，该规则的优先级别要比“拒绝所有传入数据”规则低（这样它就会被首先进行评估），并允许带有“Azure负载均衡器”标签的流量进入（这样我们就可以知道流量是来自于该负载均衡器本身，且与一些连接到负载平衡IP地址的外部源相对），用于Windows集群资源上配置的探测端口。 以下是进行该配置的示例屏幕截图：

小结

在本文中，介绍了Azure负载均衡器，并讨论了它们为何对高可用性SQL Server实例的设置来说不可或缺。 即使您不负责设置或维护这些负载均衡器，牢牢掌握它们连接至SQL的工作方式依然很重要。 正如与SQL（活动目录、网络、存储）交互的许多其它三级技术一样，我们必须充分了解，我们可以为责任方提供具体要求。