Windows Server 群集配置的最佳做法

WindowsServer群集配置的最佳做法本页内容群集和应用程序部署服务器负载负载平衡群集和应用程序部署以前我们曾经介绍过主动/主动或主动/被动群集和应用程序，由于早期的产品仅支持2节点群集，因此这种形式的部署是它的自然结果。但是在一些情况下，这可能会导致混淆，因为这些术语可以用不同的方式来解释，具体取决于上下文是1)给定的应用程序实例如何运行2)不同的应用程序实例如何运行，或是3)群集中的节点是否正在执行有用的工作。为了完全了解特定应用程序和群集的部署，我们需要了解以下信息：•有多少个应用程序实例正在运行？•在群集中有多少个相同数据的实例？•数据实例是否会移动？•相同应用程序的不同实例是否运行在不同的群集节点中？•不同的应用程序可以运行在不同的群集节点上吗？•应用程序给服务器带来了何种类型的负载，以及如何在故障转移之后重新分配这些负载？在介绍如何部署应用程序之前，我们必须首先定义什么是应用程序。在本文中，应用程序被定义为向终端用户或客户端提供一种服务的运行中的代码和数据。可以用一对不同的示例来解释这一点：工作站上运行的一个MicrosoftWord实例是一个应用程序实例。如果有多个Word实例正在运行，则每个实例会被视为一个不同的应用程序实例。然而，还有更为复杂的应用程序。例如，对于MicrosoftSQLServer来说，一个数据库被视为一个应用程序实例。而多个独立的数据库则被视为不同的应用程序实例。但是，一个数据库可以分区成多个SQLServer实例并使用SQLServer查询引擎联系在一起。这种情况下，联系在一起从而提供一个数据库镜像的这组SQLServer应用程序实例就可以视为一个应用程序实例。基本上，将以下五种属性放在一起就可以全面了解部署的目的，并可以解释部署的原因或是表现部署的特点：•服务器负载多少服务器资源被它所支持的应用程序所消耗，以及故障转移会如何影响这种资源利用？•应用程序样式应用程序是整个在一个节点上运行，还是被分割成多个较小程序块在群集中运行？•应用程序部署在给定部署下应用程序块如何在群集中分配？•故障转移策略在故障转移后应用程序会执行何种操作？•应用程序实施应用程序本身如何被实施？返回页首服务器负载在部署应用程序时，很重要的一点就是要考虑应用程序会对服务器资源产生什么要求。如果使用群集，则还有一些相关问题需要考虑：在故障转移后如何重新分配负载？服务器负载基础让我们来看一个最简单的示例，一个主动/主动式2节点文件服务器群集，其中节点A和节点B各服务于一个共享。如果节点A出现故障，它的资源就会移给节点B，从而增加了节点B的负载。实际上，如果节点A和B在出现故障前都仅运行各自容量的50%，那么在故障转移完成后，节点B将会完全饱和（100%的容量），这从性能上来说是可以承受的。尽管不是最好的情况，但是您要记住的很重要的一点是，如果所有应用程序仍在运行，即使性能有所下降，相对于没有群集提供的高可用性保护的情况来说，这都是一个100%的进步。但是这带来了风险的概念，以及为了保护应用程序的性能和可用性，您可以接受多少数量的应用程序的问题。为了清楚地说明这个问题，我们有意选择了最坏的情况（一个主动/主动2节点群集，每个节点运行一个应用程序，每个应用程序消耗一半的服务器资源）。如果再加上一个节点，这种平衡就会改变：有更多的服务器用来支持负载，但如果三个节点都运行在50%的容量，而有两个节点出现故障，则剩下的服务器将无法处理那两个故障节点累积的应用程序负载。当然，两个故障的可能性相对来说小于一个故障，因此风险相对来说也比较小。尽管如此，在群集中部署应用程序时仍必须考虑负载/风险平衡。群集中节点越多，就有越多种分配工作负载的选择。如果您要求所有群集应用程序在运行时不能有任何性能下降，那么您可能需要考虑使用某种形式的主动/被动配置。但即使是在这种情况下，您也必须考虑不同配置的风险。如果您在任何情况下都无法接受哪怕是最轻微的性能下降，那么您将需要为每个主动节点配备一个专用的被动节点。另一方面，如果您认为多个故障同时出现的风险较小，您也可以有另外的选择。如果您具有4个节点或8个节点的群集，您可能会考虑N+I配置。在1.4.3节会详细介绍N+I，它是主动/被动形式的一种变体，其中N个节点是主动节点，I个节点是被动节点或保留节点。通常，I的值小于N，这样N+I群集拓扑就可以处理I个故障而不会出现任何性能下降。风险就在于，如果出现多于I个故障，那么性能就有可能下降，不过再说一次，同时出现多个故障的可能性是很小的。因此，N+I群集是一个非常有用的配置，它在100%的被动服务器容量与较低水平的多个群集节点故障风险之间均衡了硬件成本。服务器负载更现实的一些配置上述示例比较简单，它假定应用程序将整个负载都加在一台服务器身上，因此在故障转移的情况下，它的资源利用不能分布到其余的多台服务器中。实际情况通常不是这样（尤其是文件和打印服务器），因此，让我们再来看看其他4节点群集（就称为ABCD吧）的示例，这个群集具有节点A、B、C和D。通常情况下，一台服务器将会支持多个应用程序的负载。如果正常情况下每台服务器的负载率为25%，那么ABCD群集就可以在其中三个成员出现故障的情况下存活，而不会丧失应用程序的可用性（这几乎是最坏的情况）。以下数字序列说明了4节点群集在出现连续节点故障情况下的应用程序负载。阴影区域表示运行中的应用程序的容量要求。更进一步，以下示例假定应用程序在任何给定服务器上的负载都是可分的，可以重新分配到任何存活的节点上。图1.1：正常条件下运行的群集（每个节点的负载率为25%）图1.2：一个节点故障后的群集。请注意应用程序负载的重新分配。图1.3：两个节点故障后的群集。现在每个存活节点的负载率大约为50%。图1.4：在三个节点故障后，剩下的一个存活节点已运行在满容量。如果每个节点以75%的容量运行，那么在没有合理的故障转移策略的情况下，即使是一个节点故障也可能导致应用程序可用性丢失。然而，您可以根据应用程序来指定在出现服务器故障的情况下，一部分应用程序应当故障转移到节点A、B、C和D。如果应用程序均匀分布到存活节点上，那么现在这个群集在失去一个节点的情况下仍可存活，因为出现故障的服务器负载已被平均分配给三个存活的节点（75%的三分之一是25%）。最后的结果就是三个完全负载的服务器（本来每个节点运行75%的容量，现在又加上25%），但所有应用程序仍然可用。作为上述示例的变体，以下数字序列将介绍一个4节点群集，每个节点大约运行33%的容量。更进一步，在这个示例中，应用程序负载是不可分的，在故障转移的情况下也不能分布到多个其他服务器中（这可能是一个应用程序或是多个依赖于相同资源的应用程序）。图2.1：正常条件下运行的群集（每个节点的负载率为33%）图2.2：一个节点故障后的群集。请注意重新分配后的应用程序负载。图2.3：第二个节点故障后的群集。每个存活的节点现在大约运行在66%的容量。请注意，如果再有一个节点出现故障，这个群集将不能支持全部四个应用程序。图2.4：在出现第三个故障后，唯一存活的服务器只能支持四个应用程序中的三个。另外一种故障转移策略是“故障转移对”(FailoverPairs)，也称为“伙伴对”(BuddyPairs)。假定四台服务器中每台服务器的负载率为50%或更少，那么一个故障转移伙伴就可以与每台服务器关联。这种配置使得群集在出现两个故障的情况下仍可存活。有关“故障转移对”的更详细信息将在1.4.1节介绍。利用前面的“故障转移对”示例，我们可以通过使两台服务器的负载达到100%容量并配备两台被动备份服务器，将它转为一个主动/被动配置。这种主动/被动配置在两个故障的情况下也可以存活，但是在正常情况下，有两台服务器没有利用。而且，这些100%负载的服务器的性能也比不上“故障转移对”配置，后者每台服务器仅运行在50%负载。在这两个示例中，请注意您具有相同数量的服务器、相同数量的应用程序以及相同数量的存活率（即可以有多少个节点出现故障而不会危及应用程序可用性）。但是，无论是从性能上还是从经济性来说，“故障转移对”都明显优于主动/被动模式。仍旧使用ABCD4节点群集，让我们来看看如果我们将它配置为N+I群集（会在1.4.3节中详细介绍）——其中三个节点运行在100%容量，一个节点作为备用节点——又会怎样。这个群集只能在一个故障的情况下存活。但是与前面一样，跟每台服务器运行在75%容量的情况相比，您仍然拥有相同数量的服务器、应用程序以及相同的存活率，但在您让被动节点备份运行在100%负载的主动节点时，从性能上和经济性上仍然可以承受。应用程序样式现在是考虑应用程序设计的一些方面，以及它如何影响应用程序部署的时候了。群集中运行的应用程序可以归纳为：•单实例在单实例应用程序中，在任何时间点上群集中只有一个应用程序实例在运行。这种情况的一个示例就是服务器群集中的DHCP服务。在任何时间点上，群集中只有一个DHCP服务在运行。利用服务器群集提供的故障转移支持，这个服务具有高度的可用性。单实例应用程序通常具有不能分区到其他节点的状态。在DHCP的情况中，已租用的IP地址范围相对较小，但在较大的环境中时可能具有较高的不稳定性。为了避免在群集中同步状态的复杂性，这个服务会作为单实例应用程序运行。图3：单实例应用程序在上述示例中，群集具有四个节点。根据定义，单实例应用程序一次只能运行在一个节点上。•多实例多实例应用程序由相同代码的多个实例或代码的多个不同代码块组成，可以在群集中执行这些实例或代码块，并通过集成各自的结果来提供一个服务。这些实例的集成向终端用户或客户端计算机提供了一个服务的假象。根据应用程序和数据的类型，有两种不同类型的多实例应用程序：•克隆的应用程序。克隆的应用程序是一个逻辑应用程序，由针对相同数据集运行的两个或多个相同代码实例组成。每个应用程序实例都是自包含的，从而允许客户端可以向任何一个应用程序实例发出请求，并且无论请求哪个实例，都可以保证客户端收到相同的结果。克隆的应用程序是可以缩放的，因为可以部署其他应用程序来服务于客户端请求，并且这些实例可以部署在不同节点，从而使得应用程序可以超过一个节点的容量。通过将应用程序实例部署在不同的节点上，可使应用程序具有高度的可用性。在承载应用程序实例的节点出现故障的情况下，运行在其他节点上的实例仍然可以服务于客户端请求。通常情况下，客户端请求会在群集的节点之间实现负载平衡，以便将客户端请求分配给多个应用程序实例。在这种环境下运行的应用程序不会具有跨越多个客户端请求的长时间在内存中运行的状态，因为每个客户端请求均被视为独立的操作，并且每个请求都可以独立实现负载平衡。此外，数据集必须在整个应用程序内保持一致。作为结果，克隆是一种通常用于具有只读数据或数据不经常更改的应用程序的技术。Web服务器前端、可伸缩边缘服务器（例如防火墙阵列和中间层业务逻辑）均属此类。这些应用程序通常被称为无状态应用程序1，它们可以在可供所有克隆应用程序实例使用的永久存储中省去面向客户端会话的状态，但是，客户端必须在后续请求中提供一个令牌或密钥，这样不管哪个应用程序实例服务于哪个请求，都可以将请求与正确的客户端状态关联。MicrosoftWindows平台提供了“网络负载平衡”作为基本的基础结构，用于构建有能力将客户端请求分配到各个节点的扩充群集。ApplicationCenter提供了一个管理这些环境的映像视图。图4：克隆的应用程序在上述示例中，相同的应用程序App运行在每个节点上。每个应用程序实例都访问相同的数据集，即数据集A-Z。本示例显示每个实例都访问它自己的数据集（使用某种形式的分段或复制技术创建并保持一致），一些应用程序可以共用相同的数据集（群集可使用诸如文件共享的技术访问数据）。图5：:使用文件共享的克隆应用程序•分区应用程序。具有长时间在内存中运行的状态或具有大型、经常更新的数据集的应用程序不容易进行克隆。这些应用程序通常称为有状态应用程序。在应用程序的多个实例中保持数据一致的成本是极为