フェールオーバー クラスターのクラウド監視を展開する
クラウド監視は、フェールオーバー クラスター クォーラム監視の一種であり、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 を使って、行うことができます。
Server Managerで、[ツール] 選択し、[フェールオーバー クラスター マネージャー] 選択します。
左側のウィンドウの フェールオーバー クラスター マネージャーで、構成するクラスターを選択します。
右側のウィンドウの [アクション] で、[その他 アクション] を選択し、[クラスター クォーラム設定 構成]を選択します。
[クラスター クォーラムの構成ウィザード] で、[次へ] を選択します。
[Quorum 構成オプションの選択] で、[Quorum 監視を選択する]、[次へ] の順に選択します。
[クォーラム監視の選択] で、[ファイル クラウド監視の構成]、[次へ] の順に選択します。
[クラウド監視の構成] で、以下の情報を入力し、[次へ] を選択します。
Azure ストレージ アカウントの名前。
ストレージ アカウントに関連付けられているアクセス キー。
クラウド監視を初めて作成する場合は、プライマリ アクセス キーを使います。
プライマリ アクセス キーをローテーションする場合は、代わりにセカンダリ アクセス キーを使います。
Note
フェールオーバー クラスターでは、アクセス キーを直接格納する代わりに、セキュリティで保護されたストレージ用の Shared Access Signature (SAS) トークンが生成されます。 トークンは、関連付けられているアクセス キーが有効である限り有効なままです。 プライマリ アクセス キーをローテーションする場合は、プライマリ キーを再生成する前に、そのストレージ アカウントを使用しているすべてのクラスター上のクラウド監視をセカンダリ キーで更新します。
Azure サービス エンドポイント
クラウド監視に別の Azure サービス エンドポイント (Azure China など) を使用する予定の場合は、Azure サービス エンドポイント フィールドに別の既存のサーバーの名前を入力できます。
[確認] で、クォーラム設定を確認し、[次へ]を選択します。
[概要] で、監視の構成を確認し、[完了] を選択します。
構成のさらに詳細な情報を確認するには、[レポートの表示] を選択します。
クラウド監視が作成されたら、フェールオーバー クラスター マネージャーの中央のウィンドウに移動し、クラスター コア リソース 下に表示されます。
クラウド監視でのプロキシに関する考慮事項
クラウド監視では、HTTPS (既定のポート 443) を使用して、Azure BLOB Service との送信方向の通信を確立します。 Azure では、エンドポイントとして .core.windows.net が使用されます。 このエンドポイントが、クラスターと Azure Storage の間で使用しているファイアウォール許可リストに含まれていることを確認する必要があります。 Azure Storage にアクセスするためにプロキシが必要な場合は、必要なプロキシ設定を使用して Windows HTTP サービス (WinHTTP) を構成します。 フェールオーバー クラスターでは、HTTPS 通信に WinHTTP が使用されます。
netsh コマンドを使用して、管理者特権の PowerShell ウィンドウを開き、次のコマンドを実行することで、既定のプロキシ サーバーを構成できます。
Note
このコマンドを実行すると、WinHTTP の既定のプロキシ構成が変更されます。 WinHTTP を使用する Windows サービスを含むすべてのアプリケーションが影響を受ける可能性があります。
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"