デュアルAZ展開パターン
Windows Server Failover Cluster（WSFC）ノードとして構成された IBM Cloud Windows Server 2019 Standard 仮想サーバーと、 SQL Server Always On 可用性グループが各ノードに構成された SQL Server Enterprise エディションが、デュアル AZ 展開パターンの基礎を形成します。 このアーキテクチャは、MS ADDNSと立会サーバーとして使用されるWindowsファイル共有とともに、可用性の高い SQL Server 展開を提供します。
ここに示すデュアルAZの展開パターンは、高可用性を必要とする本番用データベースに適しており、以下のコア技術を活用している：
- 同じMZR内の3つのAZにサブネットを持つ IBM Cloud VPC。
- セキュリティ・グループは、コンポーネント間のトラフィック・フローを制御するために使用される。
- サーバーへの管理アクセスに使用される1つ以上のbastionホスト。
- インターネット・アクセスを許可するために、要塞ホストに接続されたフローティングIP（FIP）。
- 同じforestdomain内の Active Directory ドメインコントローラーである AZ1 1と AZ2の 2つのWindows Server 2019 Standard仮想サーバー。
- Windows Server 2019 Standard仮想サーバー2台（ AZ1 1と AZ2 2に1台ずつ）をWindows Server Failover Cluster（WSFC）ノードとする。
- クラスタークォーラムを有効にするためのファイル共有を提供する第3のAZのWindows 2019 Standard仮想サーバー。
- Windows Server Failover Cluster は、サーバーリソースの基礎となるクラスタリング技術であり、Windows サーバーの高可用性 Always On 可用性グループの前提条件です。
- Always On 可用性グループは、1 つまたは複数のクラスタノードにまたがる個別のデータベース セットを高可用性に保つ機能を提供し、データベースレベルで動作します。 可用性グループは、1つのプライマリ・レプリカと最大8つのセカンダリ・レプリカで構成され、同期または非同期のデータ・レプリケーションを使用します。 このデプロイメントでは、AZ間のレイテンシが低いため、同期レプリケーションが使用されている。
- 分散ネットワーク名は、WSFCおよびAlways On可用性グループの名前リソースで、クラスタリソースの名前解決に使用されます。
この展開パターンでは、フェイルオーバークラスターインスタンス（FCI）は利用しません。 FCIの主な要件は、クラスタノードが共有ストレージにアクセスできることです。 共有ストレージは IBM Cloud VPC 環境にはネイティブではなく、Storage Spaces Directなどのテクノロジーを使って共有ストレージを作成することは可能だ。 Storage Spaces Directの詳細については、 Storage Spaces Directの概要を参照してください。
Windows Server フェールオーバークラスター
Windows 上で HA 用の Always On 可用性グループを導入するには、Windows Server フェイルオーバークラスタ（WSFC）が必要です。 アベイラビリティ・グループの各アベイラビリティ・レプリカは、WSFCの異なるノードに存在する必要があります。 可用性データベースのセキュリティ構成を簡素化するため、SQLサーバー・インスタンス（サービス・アカウント）はドメイン・サービス・アカウントで実行することを推奨する。
Windows Server Failover Cluster（WSFC）はWindows Serverの機能であり、クラスターノードとして動作する各サーバーはこの機能を有効にしておく必要がある。 WSFCは "スプリットブレイン "症候群を防ぐため、定足数投票に依存しており、定足数モードにはいくつかある：
- Nodeの過半数 - アクティブなクラスタノードが定足数を決定します。 クラスターが健全な状態を維持するためには、少なくとも半数以上の賛成票が必要である。
- Nodeとファイル共有の多数決 - リモートファイル共有は、定足数投票に関与するアクティブノードの投票証人として機能します。 Nodeと同様に、クラスターが健全な状態を維持するためには、投票可能な票の少なくとも半分が賛成票でなければならない。
- Nodeとディスクの多数決 - 共有ディスクは、定足数投票に関与するアクティブノードとともに、投票証人として機能する。
- ディスクのみ - 共有ディスクが証人として機能し、どのノードがディスクにアクセスできるかによってクォーラムが決定される。 最低得票数は定められていない。
マイクロソフトが推奨するSQLサーバーは以下の通り：
- 投票ノードの数が奇数の場合は、 Node多数決クォーラムモードを使用する。
- 投票ノードの数が偶数の場合は、 Nodeとファイル共有の多数決定足数モードを使用します。
この展開パターンでは、Windowsファイル共有が第3の可用性ゾーン AZ3 3のWindowsサーバーで利用できるようになります。 プライマリノードと並んで AZ1 1にファイル共有を配置した場合、AZ AZ2 内のノード2は自動フェイルオーバーが発生するための半分の票を得ることができないため、AZが利用できない場合、自動フェイルオーバーは発生しません。
常時オンの可用性グループ
アベイラビリティ・グループは、1組のプライマリ・データベースと最大8組のセカンダリ・データベースをサポートする。 セカンダリー・データベースはバックアップではないので、データベースとそのトランザクション・ログを定期的にバックアップすることが不可欠である。 常時オンの可用性グループには、WSFC、EXTERNAL、NONEの3つのクラスタ・タイプ・オプションのいずれかが必要です。
- WSFC - クラスタのフェイルオーバーを管理するためにWindows Server Failover Cluster（WSFC）を使用します。 これはWindowsサーバーの高可用性グループの前提条件である。
- External - 外部クラスタ・マネージャを使用します。 例えば、 Linux 上の SQL Serverは Pacemakerをサポートしている。 Linux クラスタ上のアベイラビリティ・グループは、HAを保証するために少なくとも2つの同期レプリカを必要とするが、自動リカバリのためには少なくとも3つのレプリカを必要とする。
- なし - クラスターレス・アベイラビリティ・グループとして知られ、当初はリード・スケール・アベイラビリティ・グループと呼ばれていた。 ただし、このオプションはアベイラビリティ・グループの機能のサブセットのみを提供し、自動フェイルオーバーは含まれません。 この機能には、手動による計画的フェイルオーバーと強制フェイルオーバー、同期と非同期の両方のレプリケーション・モード、読み取り可能なセカンダリー・ノード、セカンダリー・レプリカのバックアップが含まれる。 WSFCクラスタを使用しない可用性グループでも、読み取り可能なセカンダリノード、読み取り専用ルーティング、およびロードバランシングを提供できます。 フェイルオーバーは外部ツールで自動化できる。 SQL Server 2019の新機能である自動トラフィックリダイレクトは、読み取り/書き込みトラフィックをプライマリノードに戻すルーティングを提供し、リスナーを必要としないため、これを軽減するのに役立ちます。
可用性グループの概念を説明するために、以下の用語を使用する：
- 可用性グループ - 個別のユーザー・データベースの複製環境をサポートする。
- HA可用性グループ - 一緒にフェイルオーバーするデータベースのグループ。
- Read-scale可用性グループ - 読み取り専用ワークロードのために SQL Serverの他のインスタンスにコピーされるデータベースのグループ。
- プライマリ・レプリカ - プライマリ・データベースをクライアントからの読み書き接続に利用可能にし、各プライマリ・データベースのトランザクション・ログ・レコードを各セカンダリ・データベースに送信します。
- セカンダリ・レプリカ - 最大8個のセカンダリ・レプリカ。各レプリカはセカンダリ・データベースをホストし、HAアベイラビリティ・グループのフェイルオーバー・ターゲットとして機能する。
同期モード
可用性グループのセカンダリ・レプリカは、以下の同期モードのいずれかで構成できます：
- 同期 - プライマリ・レプリカでトランザクションがコミットされる前に、すべてのセカンダリ・レプリカでログがハード化される（トランザクションがトランザクション・ログにコミットされる）。 これは、ネットワークレイテンシが高い場合、高度なトランザクションワークロードのパフォーマンスに影響を与える可能性がありますが、ゼロデータ損失を保証します。 1つのAGにつき2つの同期コミット・レプリカを持つことができる。 このモードは、同じAZまたはMZR内のインスタンスに最適である。
- 非同期 - トランザクションは、プライマリ・レプリカ上のトランザクション・ログでハード化された時点でコミットされたとみなされる。 すべてのセカンダリレプリカでログがハード化される前に問題が発生した場合、データ損失の可能性があり、リカバリポイントは、すべてのセカンダリレプリカで成功した直近のコミットトランザクションになります。 このモードは、異なるMZRのインスタンスや、AZとオンプレミス間のインスタンスに適している。
フェイルオーバー・モード
アベイラビリティ・グループがフェイルオーバーすると、セカンダリ・レプリカが新しいプライマリとなり、プライマリ・レプリカが利用可能な場合はセカンダリ・レプリカとなります。
- 自動フェイルオーバー - 自動フェイルオーバーはHAを提供し、その成功のためには適切に構成されたリスナーとWSFCオブジェクトに依存する。 同期コミット・アベイラビリティ・モード・レプリカのみが、自動フェイルオーバーの宛先になることができます。 自動フェイルオーバーを促す条件を 1 から 5 のスケールで構成できます。1 は、プライマリ・レプリカの SQL Server サービスが完全に停止した場合のみフェイルオーバーが開始されることを示し、5 は、クリティカルからそれほど深刻でない SQL Server エラーのいずれかを示します。 デフォルトは3で、停電やプライマリレプリカが応答しない場合だけでなく、いくつかのクリティカルなサーバー状態の場合にも自動的な失敗を促します。 これらの「柔軟なフェイルオーバー・ポリシー」の条件については、 Always On 可用性グループの柔軟な自動フェイルオーバー・ポリシーを構成する を参照してください。
- 計画的フェイルオーバー - 計画的フェイルオーバーは、データ損失の可能性がない場合にのみ発生する。 具体的には、コードやSSMSダイアログ・ボックスで警告を確認するためにFORCEパラメータを使用せずにフェイルオーバーが発生することを意味します。 セカンダリ・レプリカへの計画的フェイルオーバーが可能なのは、シンクロナス・コミット・アベイラビリティ・モードのみです。 非同期コミット・アベイラビリティ・モードのレプリカを同期に移行し、SYNCHRONIZEDの状態を待ってから、データを失うことなく計画的なフェイルオーバーを実行できます。 計画的なフェイルオーバーは、常にSSMS、T-SQL、または PowerShellを使用して開始する必要があります。
- 強制フェイルオーバー - 手動で開始する強制フェイルオーバーは、プライマリ・ノードの喪失などクラスタが不利な状況に陥った場合にのみ開始する必要があります。 SSMSウィザード、T-SQLコマンド、または PowerShellから開始し、最後の手段としてWindows Server Failover Cluster Managerからのみ開始します。
- WSFC クォーラムがダウンしている場合のフェイルオーバーの強制 - WSFC にクォーラムがない場合、WSFC に基づくアベイラビリティ・グループのフェイルオーバーを強制することはできません。 まず、コンフィギュレーション・マネージャーで投票を "不正に "行い、ノードのウェイトを変更することで、クォーラムを強制する必要がある。 この手順は、災害によってクラスタ・ノードの大半が停止した場合など、緊急時にのみ検討する必要があります。 これは PowerShell スクリプトで実現でき、過半数の投票がなければ、オンライン・ノードにプライマリー・ロールを強制することができる。
フェイルオーバーは、データファイルの損失やトランザクションログの破損によってデータベースが疑わしくなるといったデータベースの問題によって引き起こされるものではない。
その他の種類の可用性グループ
以下の可用性グループはこの配置パターンでは使用されないが、この配置パターンを適応または拡張したいソリューショナーにとっては興味深いかもしれない：
- 基本可用性グループ - 可用性グループの限定版で、 SQL Server Standard エディションでのみサポートされる。 単一のセカンダリ・レプリカは読み取りやバックアップができず、各ベーシック・アベイラビリティ・グループがサポートできるレプリカは2つだけですが、1つのサーバにつき複数のベーシック・アベイラビリティ・グループを構成することができます。 基本的なアベイラビリティ・グループでは、同期または非同期のレプリケーション、手動または自動のフェイルオーバーなど、アベイラビリティ・グループと同じ機能の多くを使用できます。
- 分散アベイラビリティ・グループ - これにより、アベイラビリティ・グループは別のアベイラビリティ・グループをセカンダリ・レプリカとして扱うことができます。 読み取り専用のセカンダリレプリカをグローバルに分散し、ワークロードを地域の読み取り専用セカンダリレプリカにオフロードすることができる。 それぞれのリスナーを持つ2つのアベイラビリティ・グループは、同じネットワークやWSFC内にある必要はない。 これにより、マルチサイト展開における地理的に離れたHAとDRが可能になる。 分散アベイラビリティ・グループを使えば、WSFCがリージョンをまたぐ必要はない。 プライマリ可用性グループとセカンダリ可用性グループ間の自動フェイルオーバーはありません。 プライマリでない可用性グループは、読み取り専用のクエリーしか提供できませんが、プライマリ・レプリカ自体は持っています。 セカンダリ可用性グループのプライマリレプリカは、セカンダリ可用性グループの他のセカンダリレプリカへのトランザクションのレプリケーションを担当します。 このアーキテクチャは、各可用性グループで異なるバージョンのWindows Serverを使用できるため、OSや SQL Serverのバージョンアップに便利です。 分散シナリオの各可用性グループは独自のリスナーを持っていますが、分散可用性グループ全体としてはリスナーを持っていません。 アプリケーションは、おそらくDNSエイリアスの助けを借りて、フェイルオーバー後に各アベイラビリティ・グループに直接接続し、読み取り可能なセカンダリ・レプリカを利用する。
分散ネットワーク名
この配置では、クラスタリソースの名前解決に使用される、WSFCおよびAlways On可用性グループの名前リソースであるDistributed Network Names（DNN）を使用します。 標準的なネットワーク・ネーム・リソースと異なるのは、ノードのIPアドレスとは別のIPアドレスを必要とせず、フェイルオーバーが発生してもネットワーク上でGARP（Gratuitous Address Resolution Protocol）を使用する必要がない点である。 Windows Server 2019では、 Active Directory ドメインサービスのクラスタ名オブジェクト（CNO）でもあるWSFCの名前も、データベースリスナーもDNNで作成できる。