トレーニング
認定資格
Microsoft Certified: Azure Database Administrator Associate - Certifications
Microsoft PaaS リレーショナル データベース オファリングを使用して、クラウド、オンプレミス、ハイブリッド リレーショナル データベースの SQL Server データベース インフラストラクチャを管理します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server
重要
Azure Stack HCI が Azure Local の一部になりました。 製品ドキュメントの名前変更が進行中です。 ただし、古いバージョンの Azure Stack HCI (22H2 など) は引き続き Azure Stack HCI を参照し、名前の変更は反映されません。 詳細情報。
Windows Server フェールオーバー クラスタリング は、Azure Stack HCI および Windows Server クラスターで実行されているワークロードの高可用性を実現します。 これらのリソースは、リソースをホストするノードが稼働していると可用性が高いと見なされます。ただし、クラスターでは通常、半分を越えるノードが実行されている必要があり、その場合に "クォーラム" を持つとされます。
クォーラムは、ネットワークにパーティションがあり、ノードのサブセットが相互に通信できない場合に発生する可能性がある split-brain シナリオを防ぐために設計されています。 これにより、ノードの両方のサブセットがワークロードを所有し、同じディスクに書き込もうとするため、多数の問題が発生する可能性があります。 ただし、フェールオーバー クラスタリングのクォーラムの概念ではこれを回避できます。これにより、これらのノード グループの 1 つだけが強制的に実行され続けるので、これらのグループの 1 つだけがオンラインのままです。
クォーラムでは、クラスターがオンライン状態を維持しながら耐えることができる障害数が決定されます。 クォーラムは、クラスター ノードのサブセット間の通信に問題がある場合にシナリオを処理するように設計されているため、複数のサーバーが同時にリソース グループをホストし、同じディスクに同時に書き込もうとしません。 このクォーラムの概念を持つことにより、クラスター サービスはノードのサブセットの 1 つで停止し、特定のリソース グループの真の所有者が 1 人だけであることを確認します。 停止されたノードは、ノードのメイン グループと再び通信でき、自動的にクラスターに再参加し、クラスター サービスを開始します。
Azure Stack HCI と Windows Server 2019 には、独自のクォーラム メカニズムを持つシステムのコンポーネントが 2 つあります。
次の表に、シナリオごとのクラスター クォーラムの結果の概要を示します。
サーバー ノード | 1 つのサーバー ノード障害に耐えることができる | 1 つのサーバー ノード障害に耐えた後、別の障害にも耐えることができる | 同時に発生する 2 つのサーバー ノード障害に耐えることができる |
---|---|---|---|
2 | 50/50 | いいえ | いいえ |
2 + 監視 | はい | いいえ | いいえ |
3 | はい | 50/50 | いいえ |
3 + 監視 | はい | はい | いいえ |
4 | はい | はい | 50/50 |
4 + 監視 | はい | イエス | はい |
5 以上 | はい | イエス | はい |
ノードで障害が発生した場合、またはノードのサブセットが別のサブセットとの接続を失った場合、オンライン状態を維持するには、残りのノードがクラスターの "過半数" を占めることを確認する必要があります。 これを確認できない場合、これらはオフラインになります。
ただし、"過半数" の概念は、ノードの合計数が奇数 (たとえば、5 つのノードのうち 3 つのノード) である場合にのみ正常に機能します。 それでは、ノード数が偶数であるクラスター (たとえば、4 つのノードを持つクラスター) の場合はどうなるでしょうか。
クラスターで "投票の合計数" を奇数にできる方法は 2 つあります。
残っているノードが 問題であることを正常に確認するたびに、 majority の定義が、生存者の間に含まれるように更新されます。 これにより、クラスターでは、1 つのノードが停止し、その後別のクラスターが順次停止することを許容できます。 連続する障害の発生後に適用される、この "投票の合計数" の概念は "動的クォーラム" と呼ばれます。
動的監視では、"投票の合計数" が奇数になるように監視の投票が切り替えられます。 投票数が奇数の場合、監視は投票を持ちません。 偶数の投票がある場合、ミラーリング監視サーバーには投票があります。 動的監視は、監視エラーが原因でクラスターがダウンするリスクを大幅に軽減します。 クラスターでは、クラスター内で使用可能な投票ノード数に基づいて、監視の投票を使用するかどうかが決定されます。
動的クォーラムは、以下で説明する方法で動的監視と連携します。
動的クォーラムにより、ノードに動的に投票を割り当て、投票の過半数を失うことを回避できます。また、クラスターを 1 つのノード (最後に残ったもの) で実行できます。 例として、4 つのノードのクラスターを見ていきましょう。 クォーラムでは、3 票が必要であるとします。
この場合、クラスターは 2 つのノードが停止するとダウンします。
ただし、動的クォーラムではこれが発生するのを回避します。 クォーラムで必要とされる "投票の合計数" は、使用可能なノードの数に基づいて決定されるようになりました。 そのため、動的クォーラムでは、3 つのノードを失ってもクラスターは稼働し続けます。
上記のシナリオは、記憶域スペース ダイレクトが有効になっていない一般的なクラスターに適用されます。 ただし、記憶域スペース ダイレクトが有効になっている場合、クラスターは 2 つのノードの障害のみをサポートできます。 これについては、プール クォーラムに関するセクションで詳しく説明します。
1 票の合計から投票の "過半数" が決定されるように、1 つのノードの投票がゼロに設定されます。 投票しないノードが予期せず停止した場合、残りのノードは 1/1 となり、クラスターは存続します。 投票するノードが予期せず停止した場合、残りのノードは 0/1 となり、クラスターは停止します。 投票するノードの電源が正常に切断されると、投票はもう一方のノードに譲渡され、クラスターは存続します。 監視を構成することが重要であるのは、このためです。
両方のノードが投票し、さらに監視も投票します。これにより、3 票の合計から "過半数" が決定されます。 いずれかのノードが停止した場合、残りのノードは 2/3 となり、クラスターは存続します。
すべてのノードが投票するため、"過半数" は 3 票の合計から決定されます。 いずれかのノードが停止した場合、残りのノードは 2/3 となり、クラスターは存続します。 この時点で、クラスターは監視なしの 2 つのノードとなり、シナリオ 1 になります。
すべてのノードが投票するため、監視は最初は投票しません。 "過半数" は 3 票の合計から決定されます。 1 つの障害が発生した後に、クラスターには監視ありの 2 つのノードが残ります。これで、シナリオ 2 に戻ります。 これで、2 つのノードとなり、監視が投票します。
1 つのノードの投票がゼロに設定され、"過半数" は 3 票の合計から決定されます。 1 つの障害が発生した後に、クラスターは 3 つのノードになり、シナリオ 3 になります。
すべてのノードと監視が投票し、5 票の合計から "過半数" が決定されます。 1 つの障害が発生した後、シナリオ 4 になります。 2 つの障害が同時に発生すると、シナリオ 2 になります。
すべてのノードが投票するか、1 つを除いてすべてが投票し、合計が奇数になるようにします。 記憶域スペース ダイレクトは、2 つ以上のノードを処理できないため、現時点では、監視は必要ありません。
クォーラムのしくみを理解したところで、クォーラム監視の種類を見てみましょう。
フェールオーバー クラスタリングでは、次の 3 種類のクォーラム監視がサポートされています。
ここまでは、クラスター レベルで動作するクラスター クォーラムについて説明しました。 次に、プール レベルで動作する (つまり、ノードとドライブが停止した場合、プールが稼働状態を維持できる) プール クォーラムについて詳しく見ていきましょう。 記憶域プールは、クラスター化と非クラスター化の両方のシナリオで使用するように設計されているため、異なるクォーラム メカニズムを持ちます。
次の表に、シナリオごとのプール クォーラムの結果の概要を示します。
サーバー ノード | 1 つのサーバー ノード障害に耐えることができる | 1 つのサーバー ノード障害に耐えた後、別の障害にも耐えることができる | 同時に発生する 2 つのサーバー ノード障害に耐えることができる |
---|---|---|---|
2 | はい | いいえ | いいえ |
2 + 監視 | はい | いいえ | いいえ |
3 | はい | いいえ | いいえ |
3 + 監視 | はい | いいえ | いいえ |
4 | はい | いいえ | いいえ |
4 + 監視 | はい | イエス | はい |
5 以上 | はい | イエス | はい |
ドライブに障害が発生した場合、またはドライブの一部のサブセットが別のサブセットとの接触を失った場合、残っているドライブがメタデータをホストしている場合は、それらがプールの 問題 を構成していることを確認して、オンライン状態を維持する必要があります。 これを確認できない場合、これらはオフラインになります。 プールは、クォーラム用に十分なディスク (50% + 1) があるかどうかに基づいて、オフラインになるか、またはオンライン状態を維持するエンティティです。 クラスター自体が引用符で囲まれている限り、クラスター データベースは +1 にすることができます。
ただし、プール クォーラムのしくみはクラスター クォーラムとは次の点で異なります。
16 個のドライブはそれぞれ 1 つの投票を持ち、ノード 2 にも 1 つの投票があります (これがプール リソースの所有者であるため)。 "過半数" は 16 票の合計から決定されます。 ノード 3 と 4 が停止した場合、残りのサブセットには 8 個のドライブとプール リソースの所有者があるため、9/16 票になります。 そのため、プールは存続します。
16 個のドライブはそれぞれ 1 つの投票を持ち、ノード 2 にも 1 つの投票があります (これがプール リソースの所有者であるため)。 "過半数" は 16 票の合計から決定されます。 最初に、ドライブ 7 が停止します。 ノード 3 と 4 が停止した場合、残りのサブセットには 7 個のドライブとプール リソースの所有者があるため、8/16 票になります。 ここで、プールには過半数がないため停止します。
トレーニング
認定資格
Microsoft Certified: Azure Database Administrator Associate - Certifications
Microsoft PaaS リレーショナル データベース オファリングを使用して、クラウド、オンプレミス、ハイブリッド リレーショナル データベースの SQL Server データベース インフラストラクチャを管理します。