リード ホストとクラスター管理 (AppFabric 1.1 キャッシュ)
Microsoft AppFabric 1.1 for Windows Server キャッシュ クラスターは、連携して動作する動的なサーバー グループであり、アプリケーションのデータ用に単一の論理キャッシュを提供します。この連携動作を実現するには、キャッシュ ホスト間でクラスター操作を調整するためのオーバーヘッドが生じます。クラスター管理の役割には、キャッシュ ホストを管理する責任があり、最終的にはキャッシュ クラスターを管理する責任があります。
キャッシュ クラスター管理の役割を実行する方法には、2 つの主要なオプションがあります。第 1 のオプションは、この役割が、リード ホストと呼ばれる特別なキャッシュ ホストにより実行されることです。これは "オンロード" とも呼ばれます。第 2 のオプションは、この役割が 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 またはリード ホスト (既定) |
カスタム プロバイダー |
カスタム ストア |
リード ホスト |
クラスター管理の役割の作業
クラスター管理に関してクラスターがどのように機能するかは、2 つの主な構成設定によって決定されます。
leadHostManagement: このクラスターレベル設定は、クラスター管理の役割が何によって実行されるかを決定します。true の場合、リード ホストがクラスター管理の役割を実行します。クラスター構成設定を共有ネットワーク フォルダーに保存する場合、この設定の有効な値は true のみです。false の場合、SQL Server またはカスタム プロバイダーのいずれかがクラスター管理の役割を実行します。SQL Server またはカスタム プロバイダーを使用してクラスター構成設定を保存する場合は、この設定を true にしてリード ホストにクラスター管理の役割を実行させることができます。leadHost: このキャッシュ ホストレベル設定は、リード ホストがクラスター管理の役割を実行する場合に、どのキャッシュ ホストがリード ホストになるかを決定します。SQL Server がクラスター管理の役割を実行する場合でも、インストール プログラムはリード ホストを指定します。後になってleadHostManagementの設定を変更した場合は、この指定が使用されます。
これらの設定を変更する方法の詳細については、「クラスター管理の役割とリード ホスト指定を設定する (AppFabric 1.1)」を参照してください。
リード ホストがクラスター管理の役割を実行する場合
leadHostManagement および leadHost の設定が true の場合、キャッシュ ホストのクラスター内での責任レベルが引き上げられ、リード ホストに指定されます。リード ホストは、データのキャッシングに関連した標準キャッシュ ホストの操作を実行する以外にも、他のリード ホストと連携してクラスター操作を管理します。
リード ホストにエラーが発生した場合
キャッシュ クラスターを使用可能な状態に維持するためには、大部分のリード ホストを使用可能な状態に維持する必要があります。このことは、大規模なクラスターよりも小規模なクラスターにおいて、より多くのリスクを伴います。少ない数のサーバー障害でもクラスターのシャットダウンにつながるからです。
ヒント
リード ホストがクラスター管理の役割を実行する場合、大部分のリード ホストに障害が発生すると、キャッシュ クラスター全体がシャットダウンされます。
たとえば、次の図に示すように 6 台のサーバー からなるキャッシュ クラスターがあるとします。この例では、リード ホストがクラスター管理の役割を実行し、2 台のキャッシュ ホストがリード ホストに指定されています。
.gif "キャッシュ クラスターのリード ホスト")
クラスター内の標準キャッシュ ホストのいずれかに障害が発生した場合、クラスターは実行を継続することができます。リード ホスト以外のホストのデータは失われます (高可用性が有効化されていないと想定した場合)。ただし、クラスターの残りのホストは引き続きデータの処理と保存を実行できます。実際には、リード ホストに指定されていない 4 台のキャッシュ ホストがすべて失われても、クラスターは機能し続けることができます。
リード ホストのうち 1 台でも障害が発生した場合には、大部分のリード ホストが実行中ではなくなるため、キャッシュ クラスター全体がシャットダウンされます。この問題を軽減するために、追加のリード ホストを指定するというオプションがあります。
追加のリード ホストの指定
インストール後に、追加のリード ホストを指定できます。ただし、指定するリード ホストの数が多すぎても問題になるという点を考慮することが重要です。
キャッシュ クラスターが実行状態を維持するには、大部分のリード ホストが常に使用可能な状態である必要があります。リード ホストに指定するホストの数が多いほど、より少ない数のサーバー障害がクラスターの稼働不能状態につながります。
1 つか 2 つのリード ホスト障害がクラスター障害につながる小規模なクラスターでは、より多くのリード ホストを指定することをお勧めします。
大規模なクラスターでは、キャッシュ サーバー数が 50 台の範囲のクラスターを応答可能に維持するには、5 ～ 7 台のリード ホストで十分です。
リード ホストの指定を変更する方法の詳細については、「クラスター管理の役割とリード ホスト指定を設定する (AppFabric 1.1)」を参照してください。
Microsoft AppFabric 1.1 for Windows Server での変更点
キャッシュ クラスターの可用性を高めるため、AppFabric 1.1 では既定のリード ホストの指定に使用される処理が変更されています。AppFabric 1.1 では、キャッシュ クラスターに追加される各キャッシュ ホストをリード ホストとして自動的に設定します (最大で 7 つのリード ホスト)。IsLeadHost パラメーターを "true" に設定した Set-CacheHostConfig コマンドを使用して、追加のリード ホストを指定することもできます。IsLeadHost を "false" に設定すると、リード ホストの役割からキャッシュ ホストを削除することもできます。
SQL Server がクラスター管理の役割を実行する場合
オフロードを有効にしてキャッシュ クラスターが作成された場合、leadHostManagement 設定は false になります。この場合、leadHost の設定に関係なく、各キャッシュ ホストは、データのキャッシングに関連した非リード ホストの標準作業のみを実行します。クラスター構成設定の保存に使用される SQL Server のインスタンスが同時にクラスター管理の役割も実行します。
サーバー障害が発生した場合
SQL Server がクラスター管理の役割を実行する (オフロードする) 場合、クラスターが使用可能な状態を維持するには、1 台以上のキャッシュ ホストが SQL Server データベースにアクセスできる必要があります。
たとえば、次の図に示すように 6 台のサーバー からなるキャッシュ クラスターがあるとします。
.gif "SQL Server に設定されたクラスター管理の役割")
この例では、SQL Server がクラスター管理の役割を実行し、6 台のキャッシュ ホストすべてのリソースをキャッシュ クライアントのデータ アクセス専用とすることができます。
クラスター内のいずれかのキャッシュ ホストに障害が発生した場合、これらのサーバー上のデータは失われますが (高可用性が有効化されていないと想定した場合)、クラスターは実行状態を維持します。その他のキャッシュ ホスト上のデータは、キャッシュ クライアントから引き続き使用できます。実際には、このシナリオにおいて、クラスターの 6 台のキャッシュ ホストのうち 5 台が失われても、クラスターは機能し続けることができます。
SQL Server に障害が発生した場合は、数分以内にクラスター全体がシャットダウンされます。この問題を軽減するために、キャッシュ クラスター構成の保存場所およびクラスター管理の役割用に "クラスター化された" データベース リソースをホストする際には、Microsoft Windows Server 2008 フェールオーバー クラスタリング (https://go.microsoft.com/fwlink/?LinkId=130692) を使用することを強くお勧めします。
関連項目
概念
AppFabric キャッシュの物理アーキテクチャ図 (AppFabric 1.1 キャッシュ)
AppFabric キャッシュの論理アーキテクチャ図 (AppFabric 1.1 キャッシュ)
2012-03-05