キャッシュ サーバーの更新 (Windows Server AppFabric キャッシュ)

Windows Server AppFabric キャッシュ クラスターは、連携して動作する 1 台以上のサーバーで構成され、単一のインメモリ キャッシュを提供します。 キャッシュ クラスターのサーバーの更新が必要になることがあり、このような更新では再起動が必要な場合があります。 ここでは、キャッシュ クラスターでのパッチ適用シナリオの情報を提供します。

スケジュールされた保守

この問題に対する最も簡単な解決策は、保守時間枠をスケジュールして、すべてのキャッシュ サーバーで更新を実行することです。 このシナリオでは、Stop-CacheCluster コマンドでキャッシュ クラスターを停止し、コンピューターを更新してから、Start-CacheCluster コマンドでキャッシュ クラスターを起動します。 この方法は、需要の少ない時間帯があるキャッシュに最適です。 キャッシュ クラスターに対するクライアント アプリケーションの需要が一定している場合は、キャッシュ クラスターを稼動させたままアップグレードを行う他の方法を検討します。

キャッシュ サーバーの順次更新

キャッシュ クラスターを実行状態にしたまま、個別のキャッシュ サーバーを更新できます。 そのためには、キャッシュ クラスターに 2 台以上のキャッシュ ホストが含まれる必要があります。 基本的な手順は次のとおりです。

1. クラスター内のサーバーの 1 台を Stop-CacheHost コマンドで停止します。

2. そのサーバーを更新して再起動します。

3. Start-CacheHost コマンドを使用してサーバーを起動します。

4. 各キャッシュ サーバーで順番にこの手順を繰り返します。

この手順は単純ですが、いくつか注意点があるので次にそれについて説明します。

リード ホストの更新

クラスター管理の役割は、キャッシュ クラスター内のキャッシュ ホストを適切に管理するために設けられています。 XML プロバイダーを使用してキャッシュ クラスターの構成設定を保存する場合は、キャッシュ ホストの中からリード ホストを指定することで、この役割を実行します。 キャッシュ クラスターが動作状態を維持するには、過半数のリード ホストが実行されている必要があります。 これは、キャッシュ サーバーの順次更新に影響します。 たとえば、2 台のサーバーで構成される次のようなキャッシュ クラスターについて考えます。

ホスト名	リード ホストか
CacheServer1	はい
CacheServer2	いいえ

この例では、CacheServer1 はこの 2 ノード キャッシュ クラスターのリード ホストです。 リード ホストの過半数は実行状態を維持する必要があるため、キャッシュ クラスターを停止しない限り CacheServer1 を停止することはできません。 この例では、両方のサーバーをリード ホストにしても役に立ちません。一方のサーバーを停止すると、リード ホストの過半数が実行状態であるとはいえなくなるためです。 この問題を解決するには、キャッシュ ホスト サーバーをさらに追加し、Export-CacheClusterConfig コマンドおよび Import-CacheClusterConfig コマンドですべてのサーバーをリード ホストにします。 リード ホストの指定を変更する方法の詳細については、「クラスター管理の役割とリード ホスト指定の設定」を参照してください。 次のようにキャッシュ クラスターを変更することを検討します。

ホスト名	リード ホストか
CacheServer1	はい
CacheServer2	はい
CacheServer3	はい

この新しい構成では、3 台のサーバーすべてがリード ホストです。 このようにすると、一度に 1 台のキャッシュ サーバーを停止して更新を実行できます。

System.Data.SqlClient プロバイダーにはこのような問題はありません。これは、SQL Server はリード ホストではなくクラスター管理の役割を実行するためです。 リード ホストの詳細については、「リード ホストとクラスター管理」を参照してください。

高可用性を使用するキャッシュでのキャッシュ ホストの更新

高可用性は、キャッシュされている項目のセカンダリ コピーを別のキャッシュ ホストに作成します。 プライマリ キャッシュ ホストが使用できなくなった場合、キャッシュされている項目はセカンダリ キャッシュ ホストから提供されます。 したがって、キャッシュされているデータは失われません。 この機能の詳細については、「高可用性」を参照してください。 本質的に、高可用性を実現するには少なくとも 3 台のサーバーがキャッシュ クラスターに存在している必要があります。 1 台のサーバーにキャッシュされた項目が存在し、もう 1 台はセカンダリ コピーを保持し、3 番目のサーバーはプライマリ サーバーまたはセカンダリ サーバーがダウンした場合に高可用性の要件を実現します。 稼動しているキャッシュ ホストが 2 台しかない場合は、高可用性を維持するための 3 番目のサーバーが存在しないため、どちらのサーバーも個別に停止できません。

キャッシュで高可用性機能が使用されているかどうかを判定するには、Windows PowerShell スクリプトを使用します。 各キャッシュの Secondaries プロパティを順番に調べる PowerShell スクリプトの例を次に示します。

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

キャッシュ クラスターにサーバーが 3 台以上あったとしても、順番に更新を始める前に、Get-CacheHost でその稼動状態を確認する必要があります。

クライアント アプリケーションに関する考慮事項

キャッシュ クラスターを停止しないでキャッシュ ホストを順番に更新する場合、キャッシュ クラスターにアクセスして使用するクライアント アプリケーションに関していくつかの重要な考慮事項があります。

1. アプリケーションは、キャッシュ クラスターに最初に接続するため、1 台以上のキャッシュ ホストを名前で参照します。 これは、アプリケーション構成ファイルを使用して、またはプログラムにより行われます。 クライアント アプリケーションが 1 台のキャッシュ ホストしか参照しない場合、そのホストがダウンしている間は、キャッシュ クラスターに対して新しい接続を確立できません。 クライアント アプリケーションは、可能な場合は複数のキャッシュ ホストを参照する必要があります。 ただし、クライアント アプリケーションはすべてのキャッシュ ホストを参照する必要はありません。 参照されたキャッシュ ホストが、クラスター全体に対するゲートウェイとして機能します。

2. キャッシュ ホストが停止しているとき、アプリケーションは停止しているキャッシュ ホストで以前に見つかった項目を検索できません。 そのような項目は、アプリケーションで再設定する必要があります。

3. キャッシュ ホストが停止しているとき、アプリケーションは一時的にさまざまな DataCacheException 例外を受け取る場合があります。 キャッシュ クラスターがキャッシュ ホストの喪失に対応することで、このような例外は自動的に解決されます。 アプリケーションは、一般的な例外を予期するように設計されている必要があります。 クライアントでは、再試行のロジックを実装するか、または例外が解決されるまでソース データを使用できます。 詳細については、「エラーの処理」を参照してください。

4. キャッシュ ホストが停止しているとき、アプリケーションは高可用性を使用するキャッシュに一時的に書き込むことができなくなる場合があります。 キャッシュ ホストが停止した後、キャッシュされている項目の新しいコピー (セカンダリ) が別のキャッシュ ホストに作成されます。

関連項目

概念

キャッシュ クラスターの一般的な管理タスク (Windows Server AppFabric キャッシュ)

  2011-12-05