フェールオーバー クラスターのクラウド監視を展開する

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016

クラウド監視はフェールオーバー クラスター クォーラム監視の一種であり、Microsoft Azure を使用してクラスター クォーラムで投票を提供します。 このトピックでは、クラウド監視機能の概要、それがサポートするシナリオ、およびフェールオーバー クラスターのクラウド監視を構成する方法について説明します。 詳細については、「クラスター監視を 設定する」を参照してください

クラウド監視の概要

次の図は、複数サイトのストレッチ フェールオーバー クラスター クォーラム構成を示Windows Server 2016。 この構成例 (図 1) では、2 つのデータセンター (サイトと呼ばれます) に 2 つのノードがあります。 クラスターが 2 つ以上のデータセンターにまたがる可能性があります。 また、各データセンターには 2 つ以上のノードを含めすることもできます。 このセットアップでの一般的なクラスター クォーラム構成 (自動フェールオーバー SLA) では、各ノードに投票権が与えます。 いずれかのデータセンターで停電が発生した場合でもクラスターの実行を維持するために、クォーラム監視に追加の投票が 1 つ与えられる。 計算は単純です。合計投票数は 5 であり、クラスターを実行し続けるには 3 つの投票が必要です。

ファイル共有監視をクォーラム監視として使用する、他の 2 つのサイトに 2 つのノードを持つ 3 番目の独立したサイトのファイル共有監視ファイル共有監視

1 つのデータセンターで停電が発生した場合、他のデータセンターのクラスターが稼働し続ける機会を均等に与えるために、2 つのデータセンター以外の場所でクォーラム監視をホストする必要があります。 これは通常、クォーラム監視 (ファイル共有監視) として使用されるファイル共有をバッキングするファイル サーバーをホストするために、3 番目の独立したデータセンター (サイト) を必要とすることです。

ほとんどの組織には、ファイル共有監視をサポートするファイル サーバーをホストする 3 つ目の独立したデータセンターは存在しません。 つまり、組織は主に 2 つのデータセンターの 1 つでファイル サーバーをホストします。拡張機能により、そのデータセンターがプライマリ データセンターになります。 プライマリ データセンターで停電が発生したシナリオでは、他のデータセンターの投票数が 2 回しか得ないのに対し、クラスターは停止し、必要な 3 票のクォーラムの過半数を下回る結果になります。 ファイル サーバーをホストするデータセンターが 3 番目に分離されているお客様の場合、ファイル共有監視をサポートする高可用性ファイル サーバーを維持するオーバーヘッドが発生します。 ファイル共有監視用ファイル サーバーがゲスト OS で実行されているパブリック クラウドでの仮想マシンのホストは、セットアップとメンテナンスの両方の点で大きなオーバーヘッドになります。

クラウド監視は、新しい種類のフェールオーバー クラスター クォーラム監視で、Microsoft Azureポイントとして使用されます (次の図を参照)。 Azure Blob Storageを使用して BLOB ファイルの読み取り/書き込みを行います。このファイルは、スプリットブレイン解決の場合の調書ポイントとして使用されます。

このアプローチには大きな利点があります。

  • データMicrosoft Azure使用します (3 番目の独立したデータセンターは必要はありません)。
  • 標準の使用可能な Azure Blob Storageを使用します (パブリック クラウドでホストされている仮想マシンの追加のメンテナンス オーバーヘッドはありません)。
  • 同Azure Storageアカウントは、複数のクラスター (クラスターごとに 1 つの BLOB ファイル、BLOB ファイル名として使用されるクラスターの一意の ID) に使用できます。
  • $cost Storage アカウントへの低いデータ (BLOB ファイルごとに書き込まれた小さなデータ、クラスター ノードの状態が変更された場合に BLOB ファイルが 1 回だけ更新されます)。
  • 組み込みのクラウド監視リソースの種類。

クォーラム監視としてクラウド監視を使用するマルチサイトストレッチ クラスターと、クォーラム監視としてクラウド監視を使用するマルチサイト ストレッチ クラスターを示す図

前の図に示すように、3 番目の独立したサイトは必要ありません。 クラウド監視は、他のクォーラム監視と同様に、投票を取得し、クォーラム計算に参加できます。

クラウド監視: 単一監視の種類でサポートされるシナリオ

すべてのノードが (Azure の拡張機能によって) インターネットに到達できるフェールオーバー クラスターのデプロイがある場合は、クォーラム監視リソースとしてクラウド監視を構成する必要があります。

クォーラム監視としてのクラウド監視の使用がサポートされているシナリオの一部を次に示します。

  • ディザスター リカバリーのストレッチ マルチサイト クラスター (前の図を参照)。
  • 共有記憶域のないフェールオーバー クラスター (SQL Always Onなど)。
  • 仮想マシン ロール (または他のパブリック クラウドMicrosoft Azureホストされているゲスト OS 内で実行されているフェールオーバー クラスター。
  • プライベート クラウドでホストされている、Virtual Machinesのゲスト OS 内で実行されているフェールオーバー クラスター。
  • Storageスケールアウト ファイル サーバー クラスターなど、共有記憶域があるクラスターと共有記憶域を使用しないクラスター。
  • 小規模なブランチ オフィス クラスター (2 ノード クラスターでも)

R2 Windows Server 2012、クラスターが監視の投票を自動的に管理し、ノードが動的クォーラムで投票する場合は常に監視を構成する必要があります。

クラスターのクラウド監視を設定する

クラスターのクォーラム監視としてクラウド監視を設定するには、次の手順を実行します。

  1. クラウド監視として使用する Azure Storage アカウントを作成する
  2. クラウド監視をクラスターのクォーラム監視として構成します。

クラウド監視として使用する Azure Storage アカウントを作成する

このセクションでは、ストレージ アカウントを作成し、そのアカウントのエンドポイント URL とアクセス キーを表示およびコピーする方法について説明します。

クラウド監視を構成するには、アービトレーション用の BLOB ファイルの格納に使用できる有効な Azure ストレージ アカウントが必要です。 クラウド監視では、Microsoft ストレージ アカウントの下に、よく知られた msft-cloud-witness というコンテナーが作成されます。 クラウド監視により、msft-cloud-witness コンテナーの下に 1 つの BLOB ファイルが書き込まれます。この BLOB ファイルの名前には、対応するクラスターの一意の ID が使用されます。 つまり、同じ Microsoft Azure ストレージ アカウントを使用して、複数の異なるクラスターに対してクラウド監視を構成できるということです。

複数の異なるクラスターに対して同じ Azure ストレージ アカウントを使用してクラウド監視を構成すると、1 つの msft-cloud-witness コンテナーが自動的に作成されます。 このコンテナーには、クラスターごとに 1 つの BLOB ファイルが格納されます。

Azure ストレージ アカウントを作成するには

  1. Azure portal にサインインします。
  2. [ハブ] メニューの [新規 ] - [ > データとStorage - Storage > 選択します。
  3. [ストレージ アカウントを作成する] ページで、次の手順を実行します。
    1. ストレージ アカウントの名前を入力します。
      ストレージ アカウント名の長さは 3 から 24 文字である必要があり、数字と小文字のみを使用できます。 ストレージ アカウント名は、Azure 内で一意である必要もあります。

    2. [アカウントの種類][汎用] を選択します。
      クラウド監視に BLOB ストレージ アカウントを使用することはできません。

    3. [パフォーマンス] には [Standard] を選択します
      クラウド監視に Azure Premium Storage を使用することはできません。

    4. [ レプリケーション]で、必要に応じ、ローカル冗長ストレージ (LRS) または ゾーン冗長ストレージ (ZRS) を選択します。
      フェールオーバー クラスタリングでは、アービトレーション ポイントとして BLOB ファイルを使用します。ここでは、データの読み取り時に一定の整合性が保証される必要があります。 そのため、クラウド監視がオンプレミスに存在するクラスターの場合、または同じリージョン内の異なる可用性ゾーンにデプロイされていない Azure 内のクラスターである場合は、レプリケーションの種類として [ローカル冗長ストレージ] を選択する必要があります。 クラスター ノードが同じリージョンにあるが可用性ゾーンが異なる場合は、レプリケーションの種類として ゾーン 冗長ストレージを 使用 します。

Azure ストレージ アカウントのストレージ アクセス キーを表示およびコピーする

Microsoft Azure ストレージ アカウントを作成すると、自動的に生成される 2 つのアクセス キー (プライマリ アクセス キーとセカンダリ アクセス キー) に関連付けられます。 クラウド監視を初めて作成した場合は、プライマリ アクセス キーを使用します。 クラウド監視に使用するキーに関する制限はありません。

ストレージ アクセス キーを表示およびコピーするには、次のようにします

Azure portal で、お使いのストレージ アカウントに移動し、 [すべての設定][アクセス キー] の順にクリックすると、アカウントのアクセス キーを表示、コピー、再生成できます。 [アクセス キー] ブレードには、アプリケーションで使用するためにコピーできるプライマリ キーとセカンダリ キーを使用して事前に構成された接続文字列も含まれています (図 4 を参照)。

図4: Microsoft Azure アクセス キーの管理] ダイアログStorageスナップショット

ストレージ アカウントを作成すると、次の形式で URL が生成されます: https://<Storage Account Name>.<Storage Type>.<Endpoint>

クラウド監視では、ストレージの種類として常に BLOB が使用されます。 Azure では、エンドポイントとして .core.windows.net が使用されます。 クラウド監視を構成する際は、シナリオに従って別のエンドポイントで構成することもできます (たとえば、中国の Microsoft Azure データセンターに異なるエンドポイントがある場合など)。

注意

エンドポイント URL は、クラウド監視リソースによって自動的に生成されます。URL に対して追加の構成手順を行う必要はありません。

次のAzure portalストレージ アカウントに移動し、[すべての設定]をクリックし、[プロパティ] をクリックしてエンドポイント URL を表示およびコピーします (図 5 を参照)。

クラウド監視エンドポイント リンクのスナップショット 図5: クラウド監視エンドポイント URL リンク

アカウントの作成と管理の詳細については、「Azure Storage アカウントについて」をAzure Storageしてください。

クラスターのクォーラム監視としてクラウド監視を構成する

クラウド監視の構成は、既存のクォーラム構成ウィザードに組み込フェールオーバー クラスター マネージャー。

クラウド監視をクォーラム監視として構成するには

  1. フェールオーバー クラスター マネージャーを起動します。

  2. クラスターを右クリックし、[ >>] - [クラスター クォーラム >>構成] をクリックします (図 6 を参照)。 これにより、クラスター クォーラムの構成ウィザードが起動します。

    図 6の図 6の「クラスター クォーラムの構成」設定のメニュー パスフェールオーバー クラスター マネージャースナップショット。クラスター クォーラム 設定

  3. [クォー ラム構成の選択] ページで 、[ クォーラム監視の選択] を選択します (図 7 を参照)。

    クラスター クォーラム ウィザード図7 の [クォーラム監視の選択] ラジオ ボタンのスナップショット。クォーラム構成を選択する

  4. [クォー ラム監視の選択 ] ページで、[ クラウド監視の構成] を選択します (図 8 を参照)。

    クラウド監視図8を選択するための適切なオプションボタンのスナップショット。クォーラム監視を選択する

  5. [クラウド監視の構成] ページで、次の情報を入力します。

    1. (必須パラメーター) Azureストレージ アカウント名。

    2. (必須パラメーター) ストレージ アカウントに対応するアクセス キー。

      1. 初めて作成する場合は、プライマリアクセスキーを使用します。
      2. プライマリアクセスキーをローテーションする場合は、セカンダリアクセスキーを使用します。
    3. (省略可能なパラメーター) 別の Azure サービス エンドポイント (たとえば、中国の Microsoft Azure サービス) を使用する場合は、エンドポイント サーバー名を更新します。

      クラスタークォーラムウィザードの [クラウド監視の構成] ウィンドウのスナップショット図 9: クラウド監視を構成する

  6. クラウド監視が正常に構成されたら、フェールオーバークラスターマネージャースナップインに新しく作成した監視リソースを表示できます (図10を参照)。

    クラウド監視の正常な構成図 10: クラウド監視の正常な構成

PowerShell を使用したクラウド監視の構成

既存の Set-ClusterQuorum PowerShell コマンドには、クラウド監視に対応する新しいパラメーターが追加されています。

コマンドレットを使用してクラウド監視を構成するには Set-ClusterQuorum 、次の PowerShell コマンドを使用します。

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>

別のエンドポイント (まれ) を使用する必要がある場合は、次のようにします。

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey> -Endpoint <servername>

クラウド監視での Azure Storage アカウントに関する考慮事項

フェールオーバー クラスターのクォーラム監視としてクラウド監視を構成する場合は、次の点を考慮してください。

  • フェールオーバー クラスターでは、アクセス キーを格納する代わりに、Shared Access Security (SAS) トークンが生成され、安全に格納されます。
  • 生成された SAS トークンは、アクセス キーが有効なままである限り有効です。 プライマリ アクセス キーをローテーションする場合は、プライマリ アクセス キーを再生成する前に、まず (そのストレージ アカウントを使用しているすべてのクラスターでの) クラウド監視をセカンダリ アクセス キーで更新することが重要です。
  • クラウド監視では、Azure ストレージ アカウント サービスの HTTPS REST インターフェイス使用します。 つまり、すべてのクラスター ノードで HTTPS ポートを開く必要があります。

クラウド監視でのプロキシに関する考慮事項

クラウド監視では、HTTPS (既定のポート 443) を使用して、Azure blob service との送信方向の通信を確立します。 HTTPS 送信ポートにネットワークプロキシ経由でアクセスできることを確認します。

参照