キャッシュ サーバーのメンテナンスに関する考慮事項

  • [アーティクル]

Microsoft AppFabric 1.1 for Windows Server キャッシュ機能は、物理サーバーに依存してキャッシュ クラスターをサポートします。すべてのサーバーは、ある時点でメンテナンスが必要になり、そのときに再起動する必要のある場合が多くあります。このトピックでは、メンテナンスでサーバーの再起動が必要なときに、キャッシュ クラスターのダウンタイムを最小化または回避するための重要な考慮事項について説明します。詳細については、「キャッシュ サーバーの更新」を参照してください。

サーバーの再起動

単一サーバーでの展開時、クラスター構成の保存場所はキャッシュ クラスターの単一障害点となります。リード ホストがクラスター管理の役割を果たす場合、あまりに多くの間違ったキャッシュ サーバーを再起動すると、キャッシュ クラスターもシャットダウンされる可能性があります。

クラスター構成の保存場所

クラスター構成の保存場所は、SQL Server データベースか共有ネットワーク フォルダーのいずれかです。このような場所にアクセスできなければ、キャッシュ クラスターは数分以上実行できなくなります。SQL Server またはファイル サーバーをホストしているサーバーを再起動する前に、Stop-CacheCluster コマンドを使用してキャッシュ クラスターをシャットダウンします。このコマンドは、すべてのキャッシュ サーバー上のキャッシュ ホストの Windows サービスを正しい順序で停止します。クラスター構成の保存場所の詳細については、「クラスター構成の保存オプション」を参照してください。

キャッシュ サーバー

一般に、キャッシュ サーバーの再起動は一度につき 1 台だけ行うことをお勧めします。再起動でサーバーをシャットダウンするとき、特別な手順は必要ありません。キャッシュ ホストの Windows サービスのみを停止する場合、Stop-CacheHost コマンドを使用します。Microsoft AppFabric 1.1 for Windows Server を使用すると、Graceful スイッチを指定してキャッシュ済みデータを他のキャッシュ ホストに移動してから、停止することもできます。Windows サービス コンソールを使用したサービスの停止はサポートされていません。再起動後は、Start-CacheHost コマンドを使用して、キャッシュ ホストの Windows サーバーがクラスターに再度参加できるようにします。詳細については、「Windows PowerShell を使用した AppFabric 1.1 キャッシュ機能の管理」を参照してください。

リード ホストがクラスター管理の役割を果たしているとき、キャッシュ クラスターを使用可能な状態に維持するには、大多数のリード ホストを使用可能な状態に維持する必要があります。使用しているクラスターでこれに該当する場合は、一度に少数のリード ホストだけ再起動して、キャッシュ クラスターがシャットダウンされないようにします。リード以外のホストはキャッシュ クラスターの実行状態に影響することなく、いつでも再起動できます。リード ホストの詳細については、「リード ホストとクラスター管理 (AppFabric 1.1 キャッシュ)」を参照してください。

ヒント

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

SQL Server がクラスター管理の役割を果たす場合、キャッシュ ホストがリード ホストであるかどうかを考慮する必要はありません。クラスターは 1 台のキャッシュ ホストだけで実行を続けることができます。

キャッシュ サーバー上のキャッシュ ホストの Windows サービスが停止したときは常に、そのコンピューターのメモリ内のデータはすべてフラッシュされます。サーバーの再起動によるデータ損失からアプリケーションを防護しやすくするには、名前付きキャッシュの高可用性機能を有効にします。パフォーマンスにある程度の影響は出ますが、オーバーヘッドが増えてもキャッシュの再ロードに比べれば負担は少ないと言えます。

高可用性機能を使用してキャッシュ ホストの障害 (または停止) からアプリケーションを防護しやすくするには、3 台以上のキャッシュ ホストがキャッシュ クラスターのメンバーである必要があります。高可用性対応キャッシュには厳密な整合性要件があり、キャッシュされたオブジェクトまたはリージョンのコピーが常に 2 つ存在する必要があるためです。キャッシュまたはリージョンのコピーを 2 つ保持するためには、高可用性対応キャッシュでは 2 台以上のキャッシュ ホストが機能する必要があります。詳細については、「高可用性 (AppFabric 1.1 キャッシュ)」を参照してください。

クラスターを実行し続けるために必要なサーバーの最少数に加え、アプリケーションのメモリ ニーズを考慮することも重要です。アプリケーションのキャッシュ ニーズは、キャッシュ サーバーが再起動したという理由だけで変わることはありません。アプリケーションのキャッシュ ニーズをサポートするには、十分な数のキャッシュ サーバーが実行し続けることが重要です。

管理上の推奨事項

再起動の手順を簡素化するため、構成設定の保存には SQL Server データベースを使用し、その SQL Server のインスタンスにクラスター管理の役割を持たせることをお勧めします。そうすれば、メンテナンス時にどのキャッシュ サーバーが再起動されるのかは問題にならなくなります。

キャッシュ クラスターの可用性を最適化するには、Windows Server 2008 のフェールオーバー クラスタリング機能を使用して、キャッシュ クラスター構成の保存場所のための "クラスター化された" データベースまたはフォルダー リソースをホストすることをお勧めします。保存場所のクラスター化では、複数の Windows Server 2008 サーバーを使用して、"クラスター化された" 構成の保存場所をホストできます。また、キャッシュ クラスター構成の保存場所の可用性に影響することなく、一度に 1 つのフェールオーバー クラスタリング ノードを再起動できます。

できるだけ現時点のアプリケーション ニーズを満たす以上のキャッシュ サーバーを追加することによって、キャッシュ クラスターのサイズを大きくします。これにより、キャッシュ クラスターのパフォーマンスに重大な影響を及ぼすことなく、少数のキャッシュ サーバーを再起動できるようになります。

ダウンタイムが必要なアクション

いくつかのアクションでは、キャッシュ クラスターのダウンタイムが必要になります。次に示すアクションすべてに共通するテーマは、キャッシュ クラスター構成への変更が必要であるということです。

  2012-03-05