フェールオーバー クラスターのクラウド監視を展開する
クラウド監視は、フェールオーバー クラスター クォーラム監視の一種であり、Microsoft Azure を使ってクラスター クォーラムでの投票を提供します。 この記事には、クラウド監視機能の概要、サポートされているシナリオ、フェールオーバー クラスター用にクラウド監視を構成する手順が含まれます。 詳細については、「クラスター監視のセットアップ」を参照してください。
クラウド監視とは
始める前に、「クラスターとプール クォーラムの概要」を読んで、クラスター クォーラムとクォーラム監視がどのようなことかを再確認しておいてください。
まず最初に、次の図に示すような、複数のサイトに拡張された Windows Server のフェールオーバー クラスター クォーラムの構成例を見てみましょう。
この例は、2 つのオンサイト データセンターの 2 つのノードを含む簡略化された構成です。 一般的なクラスターでは、各ノードに 1 つの投票権があり、"ファイル共有監視" によってクォーラム監視に対してさらに 1 つの投票権が与えられます。 この追加投票権により、データセンターの 1 つが稼働しなくなっても、クラスターは実行し続けることができます。 この例では、クラスター クォーラムには 5 つの投票権があり、実行を継続するために必要な投票は 3 つだけです。
ただし、2 つのデータセンターに加えて、"ファイル共有監視" という名前の 3 つ目のデータセンターがあることに気付くかもしれません。 このデータセンターは、他の 2 つのサイトから独立して維持されており、システム ファイル共有をバックアップするファイル サーバーをホストします。 ファイル共有監視は、このクラスター クォーラム構成ではクォーラム監視として機能し、データセンターの 1 つが予期せずシャットダウンした場合でもシステムが実行し続けるようにします。
ファイル共有監視を設けると、ファイル サーバーの高可用性を維持するのに十分な冗長性が提供されます。 ただし、別サイトの別サーバーでファイル共有監視をホストするには、セットアップ、定期的なメンテナンス、他サイトへの独立した接続が必要であることに注意が必要です。
クラウド監視は、物理的なデータセンターではなく、クラウド内の Azure VM をクォーラム監視として使うため、従来のクラスター クォーラム監視構成とは異なります。 クラウド監視では、クォーラムに達するための決定投票としてシステムが使用する BLOB ファイルの読み取りと書き込みに、Azure Blob Storage が使われます。 次の図は、クラウド監視を使用する構成の例を示したものです。
ご覧のように、クラウド監視の構成では、3 つ目のデータセンターは必要ありません。 クラウド監視は、他のクォーラム監視と同様に、追加の投票権を持っており、他のデータセンターの 1 つが停止した場合に全体がシャットダウンするのを防ぐのに役立ちます。 ただし、クォーラム監視を格納するための追加サイトは必要ありません。 また、クラウド監視では、オンサイトのデータセンターの場合は必要になる定期的な物理的メンテナンスも必要ありません。
クラウド監視機能を使うと、冗長性に加えて、他にもいくつかのメリットがあります。
クォーラムを実現するために、追加のデータセンターを別に使用する必要はありません。
Azure Blob Storage を使うと、パブリック クラウドで VM をホストする場合に通常必要になる余分なメンテナンス オーバーヘッドが不要になります。
複数のクラスターに同じ Azure ストレージ アカウントを使用できます。 唯一の要件は、クラスターごとに 1 つの BLOB のみを使用し、クラスターの一意 ID の後に BLOB ファイル名を指定することです。
BLOB ファイルは、必要なデータが多くなく、クラスター ノードの状態が変化した場合にのみ更新されるため、ストレージ アカウントの継続的なコストが削減されます。
Azure には、クラウド監視リソースの種類が組み込まれています。
前提条件
クラウド監視を構成するには、アクティブなサブスクリプションを含む Azure アカウントと、有効な Azure 汎用ストレージ アカウントが必要です。 クラウド監視は、このストレージ アカウントを使って、投票の仲裁に必要な BLOB ファイルを格納するための msft-cloud-witness コンテナーを作成します。
Note
クラウド監視は、次の種類の Azure ストレージ アカウントと互換性がありません。
- BLOB ストレージ
- Azure Premium Storage
また、このアカウントと、クラウド監視によって自動的に作成される msft-cloud-witness コンテナーを使って、複数の異なるクラスター用にクラウド監視を構成することもできます。 各クラスターには独自の BLOB ファイルがあり、コンテナーに格納されます。
Azure ストレージ アカウントを作成するとき、クラウド監視の構成対象のクラスターが、オンプレミスの場合、または Azure の同じ Azure リージョンと可用性ゾーン内にある場合は、[レプリケーション] フィールドを構成するときに [ローカル冗長ストレージ (LRS)] を選びます。 クラスターが同じ Azure リージョンではあっても、異なる可用性ゾーン内にある場合は、代わりに [ゾーン冗長ストレージ (ZRS)] を選びます。
次のサポートされているシナリオのいずれかを使う必要があります。
「クラウド監視とは」で示したような、拡張されたマルチサイト クラスター用のディザスター リカバリー。
共有ストレージのないフェールオーバー クラスター (SQL Always On など)。
Microsoft Azure 仮想マシン ロールまたは他のパブリック クラウドでホストされているゲスト OS 内で実行されているフェールオーバー クラスター。
ゲスト OS 内で実行されているプライベート クラウドでホストされている VM で構成されるフェールオーバー クラスター。
スケールアウト ファイル サーバー クラスターなど、共有記憶域をあり/なしの記憶域クラスター。
小規模なブランチ オフィス クラスター (2 ノード クラスターの場合も)。
Windows Server 2012 R2 以降を使っている場合は、監視を常に構成することをお勧めします。 それ以降のバージョンの Windows Server のクラスターでは、監視の投票とそのノードの投票が動的クォーラムによって自動的に管理されます。
また、フェールオーバー クラスターと Azure ストレージ アカウント サービスの間のすべてのファイアウォールで、ポート 443 (HTTPS ポートとも呼ばれます) からのトラフィックが許可されていることを確認する必要もあります。 クラウド監視では、Azure Storage サービスに HTTPS REST インターフェイスが使われます。 そのため、クラウド監視が意図したとおりに動作するには、フェールオーバー クラスター内のすべてのノードでポート 443 を開く必要があります。
Azure ストレージ アカウントを作成すると、自動的に生成されたプライマリとセカンダリのアクセス キーに、それが関連付けられます。 クラウド監視を初めて設定するときは、プライマリ アクセス キーを使うことをお勧めします。 その後は、プライマリまたはセカンダリどちらのアクセス キーでも使用できます。
クラスターのクォーラム監視としてクラウド監視を構成する
クラウド監視の構成は、フェールオーバー クラスター マネージャー アプリケーションに組み込まれているクォーラム構成セットアップ ワークフローまたは PowerShell を使って、行うことができます。
クォーラム構成セットアップ ワークフローを使ってクラウド監視を構成するには:
フェールオーバー クラスター マネージャーを開きます。
クラスターの名前を右クリックします。
次のスクリーンショットに示すように、[その他の操作]>[Configure Cluster Quorum Settings] (クラスター クォーラム設定の構成) に移動して、クラスター クォーラム構成ワークフローを開始します。
[クォーラム構成の選択] ページで、 [クォーラム監視を選択する] を選択します。
[クォーラム監視の選択] ページで、 [クラウド監視を構成する] を選択します。
[クラウド監視の構成] ページで、次の情報を入力します。
Azure ストレージ アカウントの名前。
ストレージ アカウントに関連付けられているアクセス キー。
クラウド監視を初めて作成する場合は、プライマリ アクセス キーを使います。
プライマリ アクセス キーをローテーションする場合は、代わりにセカンダリ アクセス キーを使います。
Note
アクセス キーを直接格納する代わりに安全に格納するための Shared Access Security (SAS) トークンが、フェールオーバー クラスターによって生成されます。 このトークンは、それが関連付けられているアクセス キーが有効な間だけ有効です。 プライマリ アクセス キーをローテーションする場合は、プライマリ キーを再生成する前に、そのストレージ アカウントとセカンダリ キーを使っているすべてのクラスターで、クラウド監視を更新する必要があります。
オプションとして、クラウド監視に別の Azure サービス エンドポイント (Azure China など) を使う予定の場合は、別の既存サーバーの名前を [Endpoint server name] (エンドポイント サーバー名) フィールドに入力できます。
構成が成功すると、次のスクリーンショットに示すように、フェールオーバー クラスター マネージャーのアコーディオン メニューに新しいクラウド監視が表示されるはずです。
![新しく構成されたクラウド監視が赤い枠線で強調表示されているフェールオーバー クラスター マネージャー アプリケーションの [クラスター コア リソース] ウィンドウのスクリーンショット。](media/deploy-a-cloud-witness-for-a-failover-cluster/cloudwitness_11.png)
クラウド監視でのプロキシに関する考慮事項
クラウド監視では、HTTPS (既定のポート 443) を使用して、Azure BLOB Service との送信方向の通信を確立します。 Azure では、エンドポイントとして .core.windows.net が使用されます。 クラスターと Azure Storage との間で使用しているファイアウォール許可リストに、このエンドポイントを含めておく必要があります。 Azure Storage にアクセスするためにプロキシが必要な場合は、必要なプロキシ設定を使用して Windows HTTP サービス (WinHTTP) を構成します。 フェールオーバー クラスターでは、HTTPS 通信に WinHTTP が使用されます。
Netsh コマンドを使用して既定のプロキシ サーバーを構成するには、次の手順に従います。
Note
- これにより、WinHTTP の既定のプロキシ構成が変更されます。 WinHTTP を使用するすべてのアプリケーション (Windows サービスを含む) が、その影響を受ける可能性があります。
管理者特権でコマンド ラインを開きます。
- [スタート] に移動し、「cmd」と入力します。
- [コマンド プロンプト] を右クリックし、 [管理者として実行] を選択します。
次のコマンドを入力し、Enter キーを押します。
netsh winhttp set proxy proxy-server="<ProxyServerName>:<port>" bypass-list="<HostsList>"例:
netsh winhttp set proxy proxy-server="192.168.10.80:8080" bypass-list="<local>; *.contoso.com"
詳細については、「Netsh コマンドの構文、コンテキスト、形式」を参照してください。