高可用性 (AppFabric 1.1 キャッシュ)

高可用性を有効にすると、キャッシュされた各オブジェクトまたは領域のコピーが、異なるキャッシュ ホストで維持されます。キャッシュ クラスターは、これらのコピーの保守を管理し、プライマリ コピーが使用できない場合はコピーをアプリケーションに提供します。キャッシュが有効なアプリケーションを高可用性にするために、コードを変更する必要はありません。次の図は、高可用性機能が有効になっている場合に、オブジェクトおよび領域のコピーが異なるホストに格納されるしくみを示したものです。

"Velocity" の高可用性の概要

高可用性の構成

高可用性は、クラスター構成設定のキャッシュ レベルで構成します。キャッシュのプロパティとしての高可用性は、キャッシュの初期作成時に、New-Cache コマンドの Secondaries パラメーターを 1 に設定することで有効にできます。これにより、キャッシュされている各オブジェクトまたは領域の 1 つのコピーが必要であることが、キャッシュ管理 Windows PowerShell コマンドレットに通知されます。Secondaries パラメーターを 0 に設定すると、高可用性機能は無効になります。新しいキャッシュを作成するとき、高可用性オプションは既定で無効になります。キャッシュ構成設定の編集方法の詳細については、「Windows PowerShell でキャッシュ構成設定を編集する」を参照してください。

Microsoft AppFabric 1.1 for Windows Server キャッシュ機能の高可用性機能を使用する場合は、キャッシュ クラスターのすべてのノードで、Windows Server 2008 または Windows Server 2008 R2 の Enterprise Edition (またはそれ以上) が実行されている必要があります。すべての高可用性キャッシュ ノードがサポートされるオペレーティング システムで実行していることを確認してください。サポートされるオペレーティング システムの詳細については、「AppFabric インストール ガイド」 (https://go.microsoft.com/fwlink/?LinkId=169172) の「ソフトウェア要件」セクションを参照してください。

セカンダリ コピー記憶域

キャッシュ クラスターは、オブジェクトおよび領域のセカンダリ コピーを格納する場所を選択します。AppFabric は、キャッシュされたオブジェクトをクラスター内のすべてのキャッシュ ホストに分散させるのと同様に、これらのオブジェクトのセカンダリ コピーもクラスター内のすべてのキャッシュ ホストに分散させます。

整合性の維持方法

高可用性が有効かどうかにかかわらず、キャッシュが有効なアプリケーションは、キャッシュされたオブジェクトのプライマリ コピーしか存在しない場合と同様に動作します。Add メソッド、Put メソッド、および Remove メソッドの呼び出しは、最初に、プライマリ オブジェクトが存在する任意のキャッシュ ホスト上のプライマリ オブジェクトで開始されます。プライマリ オブジェクトまたは領域を保持しているキャッシュ ホストへの呼び出しが開始された後、結果のアクションは高可用性が有効かどうかによって異なります。

高可用性が有効になっている場合は、追加の手順として、セカンダリ コピーを保持しているホストに対し、変更が行われようとしていることが通知されます。その後、オブジェクトのプライマリ コピーを保持するキャッシュ ホストは、他のホストからの受信確認を待ってから、操作が完了したことの受信確認をクライアントに返信ます。

たとえば、次の図のキャッシュ ホスト A および B を見てください。キャッシュ ホスト A は、要求を受信すると直ちに要求の処理を開始し、キャッシュ ホスト B に変更を通知します。キャッシュ ホスト B は、受信確認をキャッシュ ホスト A に返信します。キャッシュ ホスト A は、受信確認を受け取ると、変更を完了し、キャッシュが有効なアプリケーションに受信確認を返信します。このような処理により、オブジェクトまたは領域のセカンダリ コピーがプライマリ コピーと常に同じ状態であることが保証されます。この処理は、強い整合性と呼ばれます。

"Velocity" の高可用性の整合性

パフォーマンスに関する考慮事項

オブジェクトまたは領域のセカンダリ コピーを保持するキャッシュ ホストは、プライマリ コピーに関するすべての変更に対して受信確認を行う必要があるので、キャッシュが有効なアプリケーションからの書き込みの応答時間で、若干のパフォーマンス低下が発生します。このようなパフォーマンスへの影響は、既にキャッシュに存在する項目の読み取りでは発生しません。また、オブジェクトのプライマリ コピーを保持するキャッシュ ホストが失われた場合に、そのオブジェクトのキャッシュへの再ロードに要する時間も考慮する必要があります。

キャッシュ ホストで障害が発生した場合の影響

キャッシュ ホストで障害が発生した場合でも (クラスターの実行を維持するのに十分な数のキャッシュ ホストがまだ使用可能であるとすると)、キャッシュが有効なアプリケーションに関しては何も変わりありません。キャッシュ クラスターは、オブジェクトのセカンダリ コピーを保持していたキャッシュ ホストに、オブジェクトに対する要求を再ルーティングします。クラスター内では、すべてのプライマリ オブジェクトのセカンダリ コピーが昇格されて、新しいプライマリ オブジェクトになります。その後、この新しいプライマリ オブジェクトのセカンダリ コピーが、クラスター内の他のキャッシュ ホストに配布されます。障害が発生したキャッシュ ホストのセカンダリ オブジェクトは、新しいセカンダリ オブジェクトによって置き換えられて、クラスター内に配布されます。この処理は領域にも適用されます。

高可用性機能によってキャッシュ ホストの障害からアプリケーションを保護するには、3 台以上のキャッシュ ホストがキャッシュ クラスターのメンバーになっている必要があります。高可用性対応キャッシュには厳密な整合性要件があり、キャッシュされたオブジェクトまたはリージョンのコピーが常に 2 つ存在する必要があるためです。キャッシュまたはリージョンのコピーを 2 つ保持するためには、高可用性対応キャッシュでは 2 台以上のキャッシュ ホストが機能する必要があります。

たとえば、次の表で示すように、3 台のサーバーで構成されるキャッシュ クラスターに HACache という名前の高可用性対応キャッシュを作成してあるものとします。また、SQL Server がクラスター管理の役割を実行するように構成されているものとします (これは、リード ホストが失われる可能性をこの例で考慮する必要がないようにするためです)。

時刻 キャッシュ ホスト 1 キャッシュ ホスト 2 キャッシュ ホスト 3 HACache (高可用性対応の名前付きキャッシュ)

T1

実行中

実行中

実行中

使用可能

T2

実行中

実行中

停止

使用可能

T3

実行中

停止

停止

使用不可能

T1 では、3 台のキャッシュ ホストが使用可能で、キャッシュされているオブジェクトまたは領域の 2 つのコピーを、使用可能な 3 台のサーバーのいずれかに格納できます。T2 では、1 台のキャッシュ サーバーで障害が発生していますが、まだ 2 台のキャッシュ ホストを使用してキャッシュされているオブジェクトまたは領域の 2 つのコピーを格納できるので、HACache は引き続き使用できます。T3 では、もう 1 台のキャッシュ ホストで障害が発生し、HACache は使用できなくなります。これは、キャッシュされているオブジェクトまたは領域の 2 番目のコピーを格納するために使用できるキャッシュ ホストがないためです。

高可用性に関する他の推奨事項

キャッシュされているデータの可用性を最適化するには、次の推奨事項を考慮してください。

  • 使用するキャッシュ ホストの数を増やします。

  • 分散キャッシュ システムをファイアウォールの境界内に展開し、すべてのサーバー メンバーを同じドメインにします。これには、キャッシュ クライアント、キャッシュ ホスト、プライマリ データ ソース サーバー、およびクラスター構成の保存場所をホスティングしているサーバーが含まれます。

  • SQL Server またはカスタム プロバイダーを使用して、キャッシュ クラスターの構成設定を格納します。

  • クラスターを停止する必要のある、コストのかかる構成の変更を最小限にします。可能な場合は、キャッシュ クラスター全体を停止してクラスター構成設定のキャッシュ構成を変更する代わりに、名前付きキャッシュを再作成します。

  • 必ず、サーバーを再起動する前に Stop-CacheHost コマンドを使用してキャッシュ サービスを停止します。リード ホストがクラスター管理の役割を実行している場合、キャッシュ サービスを停止する行為によって、キャッシュ クラスター全体がシャットダウンすると (大部分がリード ホストを実行していないため)、Stop-CacheHost コマンドレットは失敗します。

関連項目

概念

AppFabric キャッシュの物理アーキテクチャ図 (AppFabric 1.1 キャッシュ)
AppFabric キャッシュの論理アーキテクチャ図 (AppFabric 1.1 キャッシュ)

  2012-03-05