リード ホストとクラスター管理 (Windows Server AppFabric キャッシュ)

Windows Server AppFabric キャッシュ クラスターは、連携して動作する動的なサーバー グループであり、アプリケーションのデータ用に単一の論理キャッシュを提供します。この連携動作を実現するには、キャッシュ ホスト間でクラスター操作を調整するためのオーバーヘッドが生じます。クラスター管理の役割には、キャッシュ ホストを管理する責任があり、最終的にはキャッシュ クラスターを管理する責任があります。

クラスター管理の役割が何によって実行されるかについては、分散キャッシュ システムをどのように展開するかに応じて 2 つのオプションがあります。クラスター構成設定を SQL Server データベースに保存する場合は、その SQL Server インスタンスを使用してクラスター管理の役割を実行することもできます。

クラスター構成設定を共有ネットワーク フォルダーに保存する場合、クラスター管理の役割は、リード ホストと呼ばれる特殊なキャッシュ ホストによって常に実行されます。リード ホストは、リード ホストに指定されていない他のキャッシュ ホストと同じ作業を実行しますが、リード ホストには、他のリード ホストと連携してクラスター管理の役割を実行するという追加の責任があります。

次の表に、インストール時の選択とクラスター管理のオプションとの関係を示します。これらの構成オプションから実際の環境に適したオプションを選択する方法については、「クラスター構成の保存オプション (Windows Server AppFabric キャッシュ)」を参照してください。

クラスター構成の保存の種類	クラスター構成の保存場所	クラスター管理
XML ファイル	共有ネットワーク フォルダー	リード ホスト
SQL Server データベース	SQL Server	SQL Server (既定) またはリード ホスト
カスタム プロバイダー	カスタム ストア	カスタム ストア

クラスター管理の役割の作業

クラスター管理に関してクラスターがどのように機能するかは、2 つの主な構成設定によって決定されます。

• leadHostManagement: このクラスターレベル設定は、クラスター管理の役割が何によって実行されるかを決定します。true の場合、リード ホストがクラスター管理の役割を実行します。クラスター構成設定を共有ネットワーク フォルダーに保存する場合、この設定の有効な値は true のみです。false の場合、SQL Server またはカスタム プロバイダーのいずれかがクラスター管理の役割を実行します。SQL Server またはカスタム プロバイダーを使用してクラスター構成設定を保存する場合は、この設定を true にしてリード ホストにクラスター管理の役割を実行させることができます。

• leadHost: このキャッシュ ホストレベル設定は、リード ホストがクラスター管理の役割を実行する場合に、どのキャッシュ ホストがリード ホストになるかを決定します。SQL Server がクラスター管理の役割を実行する場合でも、インストール プログラムはリード ホストを指定します。後になって leadHostManagement の設定を変更した場合は、この指定が使用されます。

設定を変更する方法の詳細については、「クラスター管理の役割とリード ホスト指定の設定 (Windows Server AppFabric キャッシュ)」を参照してください。

これら 2 つのプロパティを使用する場合、キャッシュ ホストの動作を決定する状況として 4 つの状況が考えられます。それらの状況を次の表に示します。

leadHostManagement クラスターレベル設定	leadHost キャッシュ ホスト設定	組み合わせの設定の説明	有効なキャッシュ ホスト作業
false	false	SQL Server またはカスタム プロバイダーがクラスター管理の役割を実行します。これはリード ホストではありません。	標準キャッシュ ホストの操作のみです。
false	true	SQL Server がクラスター管理の役割を実行します。leadHostManagement の設定を true に変更した場合は、これがリード ホストになります。	標準キャッシュ ホストの操作のみです。
true	false	リード ホストがクラスター管理の役割を実行しますが、これはリード ホストではありません。	標準キャッシュ ホストの操作のみです。
true	true	リード ホストがクラスター管理の役割を実行します。これはリード ホストです。	標準キャッシュ ホストの操作を実行し、他のリード ホストと連携してクラスターを管理します。

リード ホストがクラスター管理の役割を実行する場合

leadHostManagement および leadHost の設定が true の場合、キャッシュ ホストのクラスター内での責任レベルが引き上げられ、リード ホストに指定されます。リード ホストは、データのキャッシングに関連した標準キャッシュ ホストの操作を実行する以外にも、他のリード ホストと連携してクラスター操作を管理します。

リード ホストにエラーが発生した場合

キャッシュ クラスターを使用可能な状態に維持するためには、大部分のリード ホストを使用可能な状態に維持する必要があります。このことは、大規模なクラスターよりも小規模なクラスターにおいて、より多くのリスクを伴います。少ない数のサーバー障害でもクラスターのシャットダウンにつながるからです。

ヒント

リード ホストがクラスター管理の役割を実行する場合、大部分のリード ホストに障害が発生すると、キャッシュ クラスター全体がシャットダウンされます。

たとえば、次の図に示すように 6 台のサーバー からなるキャッシュ クラスターがあるとします。この例では、リード ホストがクラスター管理の役割を実行し、2 台のキャッシュ ホストがリード ホストに指定されています。

クラスター内の標準キャッシュ ホストのいずれかに障害が発生した場合、クラスターは実行を継続することができます。リード ホスト以外のホストのデータは失われます (高可用性が有効化されていないと想定した場合)。ただし、クラスターの残りのホストは引き続きデータの処理と保存を実行できます。実際には、リード ホストに指定されていない 4 台のキャッシュ ホストがすべて失われても、クラスターは機能し続けることができます。

リード ホストのうち 1 台でも障害が発生した場合には、大部分のリード ホストが実行中ではなくなるため、キャッシュ クラスター全体がシャットダウンされます。この問題を軽減するために、追加のリード ホストを指定するというオプションがあります。

ヒント

Windows サービスがクラスター管理の役割を実行している場合、そのサービスは Stop-CacheHost コマンドによって停止されません。停止するとクラスター全体がシャットダウンされます。

追加のリード ホストの指定

AppFabric 構成ウィザードでは、[Cluster Size] ボックスの一覧を使用して、クラスター内に存在するリード ホストの適切な数を決定できるようになっています。インストール後に追加のリード ホストを指定する場合も、同じ方法で指定できます。ただし、指定するリード ホストの数が多すぎても問題になるという点を考慮することが重要です。

• キャッシュ クラスターが実行状態を維持するには、大部分のリード ホストが常に使用可能な状態である必要があります。リード ホストに指定するホストの数が多いほど、より少ない数のサーバー障害がクラスターの稼働不能状態につながります。

• 1 つか 2 つのリード ホスト障害がクラスター障害につながる小規模なクラスターでは、より多くのリード ホストを指定することをお勧めします。

• 大規模なクラスターでは、キャッシュ サーバー数が 50 台の範囲のクラスターを応答可能に維持するには、5 ～ 7 台のリード ホストで十分です。

リード ホストの指定を変更する方法の詳細については、「クラスター管理の役割とリード ホスト指定の設定 (Windows Server AppFabric キャッシュ)」を参照してください。

SQL Server がクラスター管理の役割を実行する場合

クラスターの leadHostManagement の設定が false の場合、leadHost の設定には関係なく、各キャッシュ ホストは、データのキャッシングに関連した非リード ホストの標準作業のみを実行します。このシナリオでは、クラスター構成設定の保存に使用される SQL Server のインスタンスが同時にクラスター管理の役割も実行します。

サーバー障害が発生した場合

SQL Server がクラスター管理の役割を実行する場合、クラスターが使用可能な状態を維持するには、1 台以上のキャッシュ ホストが SQL Server データベースにアクセスできる必要があります。

たとえば、次の図に示すように 6 台のサーバー からなるキャッシュ クラスターがあるとします。

この例では、SQL Server がクラスター管理の役割を実行し、6 台のキャッシュ ホストすべてのリソースをキャッシュ クライアントのデータ アクセス専用とすることができます。

クラスター内のいずれかのキャッシュ ホストに障害が発生した場合、これらのサーバー上のデータは失われますが (高可用性が有効化されていないと想定した場合)、クラスターは実行状態を維持します。その他のキャッシュ ホスト上のデータは、キャッシュ クライアントから引き続き使用できます。実際には、このシナリオにおいて、クラスターの 6 台のキャッシュ ホストのうち 5 台が失われても、クラスターは機能し続けることができます。

SQL Server に障害が発生した場合は、数分以内にクラスター全体がシャットダウンされます。この問題を軽減するために、キャッシュ クラスター構成の保存場所およびクラスター管理の役割用に "クラスター化された" データベース リソースをホストする際には、Microsoft Windows Server 2008 フェールオーバー クラスタリング (https://go.microsoft.com/fwlink/?LinkId=130692) を使用することを強くお勧めします。

関連項目

概念

Windows Server AppFabric キャッシュの物理アーキテクチャ図
Windows Server AppFabric キャッシュ論理アーキテクチャ図
クラスターの構成設定 (Windows Server AppFabric キャッシング)
クラスター管理の役割とリード ホスト指定の設定 (Windows Server AppFabric キャッシュ)

  2011-12-05