主要主机和群集管理（AppFabric 1.1 缓存）

Microsoft AppFabric 1.1 for Windows Server 缓存群集是一组动态服务器，这些服务器相互协作，为应用程序数据提供一个统一的逻辑缓存。为此，需要一些开销才能安排缓存主机之间的群集操作。群集管理角色负责管理缓存主机，并最终管理缓存群集。

对于缓存群集管理角色的执行方式，有以下两个主要选项。第一个选项是由特殊的缓存主机（称为主要主机）来执行此角色。此选项也称为“装载”。第二个选项是由 SQL Server 来执行此角色。此选项也称为“卸载”，因为责任已从缓存群集本身转交给 SQL Server。

如果将缓存群集配置数据存储在共享的网络文件夹 (XML) 中，则必须使用装载来进行主要主机的管理。请注意，主要主机与未指定为主要主机的其他缓存主机执行相同的缓存任务，但前者还额外负责与其他主要主机协同工作，以执行群集管理角色。

在 Windows Server AppFabric 1.0 中，对于将其配置数据存储在 SQL Server 中的缓存群集，默认的选项是将缓存群集管理角色转交给 SQL Server。在 AppFabric 1.1 中，此情况有所改变。对于新缓存群集，默认选项是始终使用装载，即由主要主机管理缓存群集。这样可以提高缓存群集的可用性，因为如果配置存储不可用，无论该存储是 XML 文件还是 SQL Server 数据库，缓存群集仍可保持部分功能。请注意，在这种情况下，对缓存群集配置的检查或更改操作将无法进行。

备注

如果将现有的 AppFabric 1.0 缓存群集升级到 AppFabric 1.1，该升级不会改变缓存群集管理行为。如果升级的缓存群集使用的是卸载选项，而您希望进行更改，则必须使用 Windows PowerShell 命令重新创建缓存群集。有关详细信息和示例，请参阅自动安装（AppFabric 1.1 缓存）。若要更轻松地重新创建群集，可以使用 Export-CacheClusterConfig 和 Import-CacheClusterConfig 命令。然而，您必须确保将 leadHostManagement 属性设置为“true”。有关详细信息，请参阅主要主机和群集管理（AppFabric 1.1 缓存）。

您还可以将所有缓存群集管理角色转交给 SQL Server。首先，您必须使用 New-CacheCluster 命令手动创建缓存群集，并将 Offloading 参数设置为“true”。另一个要求是，Provider 必须为 SQL Server (System.Data.SqlClient)。

下表显示了您在安装时的选择如何与您用于群集管理的选项相关联。有关选择适合您的配置选项的详细信息，请参阅群集配置存储选项。

群集配置存储类型	群集配置存储位置	群集管理
XML 文件	共享网络文件夹	主要主机
SQL Server 数据库	SQL Server	SQL Server 或主要主机（默认）
自定义提供程序	自定义存储	主要主机

群集管理角色职责

以下是两个主要的配置设置，用于确定在群集管理方面，群集的工作方式：

• leadHostManagement：此群集级别设置确定将由谁来执行群集管理角色。如果为 true，则主要主机执行群集管理角色。如果您选择在共享网络文件夹中存储群集配置设置，则此设置唯一有效的值是 true。False 表明 SQL Server 或自定义提供程序会执行群集管理角色。当使用 SQL Server 或自定义提供程序存储群集配置设置时，您可以将此设置设为 true，让主要主机执行群集管理角色。

• leadHost：此缓存主机级别设置确定当主要主机执行群集管理角色时，哪些缓存主机将作为主要主机。即使 SQL Server 将执行群集管理角色，安装程序也会指定主要主机，以防您稍后更改 leadHostManagement 设置。

有关更改这些设置的详细信息，请参阅设置群集管理角色和主要主机指定 (AppFabric 1.1)。

当主要主机执行群集管理角色时

如果 leadHostManagement 和 leadHost 设置都为 true，则缓存主机会在群集中提升至责任更大的级别，并被指定为主要主机。主要主机除了执行普通缓存主机缓存数据相关的操作之外，它还要与其他主要主机一起管理群集操作。

当主要主机出现故障时

为了缓存群集保持可用，大多数主要主机必须保持可用。这在小型群集中的风险远高于大型群集，因为只要几个服务器故障即可导致群集本身关闭。

备注

在主要主机执行群集管理角色时，如果大多数主要主机出现故障，则整个缓存群集将会关闭。

例如，设想下图中显示的六服务器缓存群集。在此示例中，主要主机执行群集管理角色，并将两个缓存主机指定为主要主机。

如果群集中的任一普通缓存主机出现故障，此群集可能会一直运行。非主要主机上的数据会丢失（假定未启用高可用性），但群集的其余部分会继续提供服务并存储数据。实际上，即使未指定为主要主机的四个缓存主机全部失去，群集仍可以保持运行。

只要其中一个主要主机出现故障，整个缓存群集就会关闭，因为不再是大多数主要主机在运行。若要减少此问题，您可以选择指定其他主要主机。

指定其他主要主机

您可以在安装之后指定其他主要主机。但是，应考虑到分配过多主要主机可能也存在问题，这一点很重要：

• 为了让缓存群集保持在运行状态，必须始终有大多数的主要主机可用。指定为主要主机的主机越多，群集能够承受并保持可运行的服务器故障越少。

• 在小群集中，一个或两个主要主机故障可能会导致群集故障，我们建议您指定更多的主要主机。

• 在大群集中，五到七个主要主机应该足以确保在 50 个缓存服务器范围内的群集响应速度更快。

有关如何更改主要主机指定的详细信息，请参阅设置群集管理角色和主要主机指定 (AppFabric 1.1)。

Microsoft AppFabric 1.1 for Windows Server 中的变化

为了提高缓存群集的可用性，AppFabric 1.1 更改了用于指定默认主要主机的过程。AppFabric 1.1 会自动将添加到缓存群集的每个缓存主机设置为主要主机，最多可设置七个主要主机。您仍可以使用 Set-CacheHostConfig 命令（将 IsLeadHost 参数设置为“true”）来指定更多的主要主机。通过将 IsLeadHost 设置为“false”，还可以从主要主机角色中删除缓存主机。

当 SQL Server 执行群集管理角色时

在启用卸载的情况下创建缓存群集后，leadHostManagement 的设置为 false。在这种情况下，无论 leadHost 设置如何，每个缓存主机仅承担与缓存数据相关的非主要主机的普通责任。用于存储群集配置设置的 SQL Server 实例还用于执行群集管理角色。

如果发生服务器故障时

在 SQL Server 执行群集管理角色（卸载）时，为了使群集保持可用，必须有一个或多个缓存主机能够访问 SQL Server 数据库。

例如，设想下图中显示的六服务器缓存群集。

在此示例中，SQL Server 执行群集管理角色，所有六个缓存主机可以将其资源专用于缓存客户端的数据访问。

如果群集中的任何一个缓存主机发生故障，则这些服务器上的数据都会丢失（假定未启用高可用性），但群集会继续运行。其他缓存主机上的数据会继续提供给缓存客户端。事实上，在这种情况下，如果群集丢失了六个缓存主机中的五个，它仍可以继续工作。

如果 SQL Server 出现故障，则整个群集会在几分钟之内关闭。若要减小此问题，强烈建议您使用 Microsoft Windows Server 2008 故障转移群集 (https://go.microsoft.com/fwlink/?LinkId=130692)（可能为英文网页）承载缓存群集配置存储位置的群集数据库资源和群集管理角色。

另请参阅

概念

AppFabric 缓存物理体系结构图（AppFabric 1.1 缓存）
AppFabric 缓存逻辑体系结构图（AppFabric 1.1 缓存）

  2012-03-05