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

  • [アーティクル]

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

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

クラウド監視の概要

次の図は、Windows Server 2016 で複数サイトに拡張されたフェールオーバー クラスター クォーラム構成を示しています。 この構成例 (図 1) では、2 つのデータセンター (サイトと呼ばれます) に 2 つのノードがあります。 クラスターが 2 つ以上のデータセンターにまたがる可能性があります。 また、各データセンターにはそれぞれ 3 つ以上のノードを含めることもできます。 このセットアップでの一般的なクラスター クォーラム構成 (自動フェールオーバー 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)。
  • ストレージ アカウントのコストが非常に低くなります (blob ファイルごとに書き込まれるデータは小さく、blob ファイルはクラスターノードの状態が変化したときに 1 回だけ更新されます)。
  • 組み込みのクラウド監視リソースの種類。

クラウド監視をクォーラム監視として使用して複数サイトに拡張されたクラスターを示す図クラウド監視をクォーラム監視として使用して複数サイトに拡張されたクラスター

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

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

フェールオーバー クラスターを展開しており、すべてのノードが (Azure の拡張機能によって) インターネットにアクセスできる場合は、クォーラム監視リソースとしてクラウド監視を構成することをお勧めします。

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

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

Windows Server 2012 R2 以降では、クラスターが監視の投票を自動的に管理し、ノードが動的クォーラムで投票するため、常に監視を構成することをお勧めします。

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

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

  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. [ハブ] メニューで、[新規] -> [データ + ストレージ] -> [ストレージ アカウント] の順に選択します。
  3. [ストレージ アカウントを作成する] ページで、次の手順を実行します。

    1. ストレージ アカウントの名前を入力します。
      ストレージ アカウント名の長さは 3 から 24 文字である必要があり、数字と小文字のみを使用できます。 ストレージ アカウント名は、Azure 内で一意である必要もあります。

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

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

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

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

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

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

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

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

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

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

Note

エンドポイント URL は、クラウド監視リソースによって自動的に生成されます。 ご利用のファイアウォールでポート 443 が開いていて、クラスターと Azure Storage の間で使用しているファイアウォールの許可リストに含まれていることを確認します。

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

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

Azure Storage アカウントの作成と管理の詳細については、Azure ストレージ アカウントの概要に関するページを参照してください。

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

クラウド監視の構成は、フェールオーバー クラスター マネージャーに組み込みの既存のクォーラム構成ウィザード内に統合されています。

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

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

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

    フェールオーバー クラスター マネージャー UI の [Configure Cluster Quorum Settings](クラスター クォーラム設定の構成) へのメニュー パスのスナップショット図 6. クラスター クォーラム設定

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

    クラスター クォーラム ウィザードの [select the quorum witness](クォーラム監視の選択) ラジオ ボタンのスナップショット図 7. クォーラム構成の選択

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

    クラウド監視を選択するための該当のラジオ ボタンのスクリーンショット図 8. クォーラム監視の選択

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

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

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

      1. 初めて作成する場合は、プライマリ アクセス キーを使用します。
      2. プライマリ アクセス キーをローテーションする場合は、セカンダリ アクセス キーを使用します。

    3. (省略可能なパラメーター) 別の Azure サービス エンドポイント (たとえば、中国の Microsoft Azure サービス) を使用する場合は、エンドポイント サーバー名を更新します。

      クラスター クォーラム ウィザードの [Cloud Witness configuration](クラウド監視の構成) ペインのスナップショット図 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 送信ポートにネットワークプロキシ経由でアクセスできることを確認します。 Azure では、エンドポイントとして .core.windows.net が使用されます。 クラスターと Azure Storage の間で使用しているファイアウォールの許可リストに含まれていることを確認する必要があります。

参照