ノート:
- このチュートリアルでは、Oracle Cloudへのアクセスが必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
- Oracle Cloud Infrastructureの資格証明、テナンシおよびコンパートメントの値の例を使用します。演習を完了するときに、これらの値をクラウド環境に固有の値に置き換えます。
OCIへのDR用のMicrosoft SQL Server分散Always On可用性グループのデプロイ
イントロダクション
Distributed Always On可用性グループ(分散可用性グループ)は、SQL Serverの従来の可用性グループの機能を拡張するMicrosoft SQL Serverの強力な機能です。
分散可用性グループを使用すると、異なるOracle Cloud Infrastructure (OCI)リージョンで実行されている複数のWindows Serverフェイルオーバー・クラスタ(WSFC)にまたがるディザスタ・リカバリ(DR)ソリューションを作成できます。
これにより、OCIで実行されているクリティカルなSQL Serverデータベースの可用性、ディザスタ・リカバリ機能および地理的分散を高レベルで実現できます。
このチュートリアルの除外
このチュートリアルでは、単一の Microsoft SQL Server Always On可用性グループの段階的な作成については説明しません。詳細は、OCIでのHAおよびDR用のMicrosoft SQL Server Always On可用性グループのデプロイを参照してください。
次の公式の Microsoftドキュメントを参照してください。
目的
- OCIでMicrosoft SQL Server分散Always On可用性グループ・ソリューションを作成します。
前提条件
-
分散可用性グループの構成要素は次のとおりです。
-
VCNs: OCI Virtual Cloud Networks (VCNs)を2つの別々のOCIリージョンに作成し、Dynamic Routing Gateways (DRG)リモート・ピアリングを介して接続します。
-
AOAG 1:これはOCIリージョン1で実行されています。レプリケートされるデータベースが正常に実行される場所です。これは、次の例(パリOCIリージョン)のSQL Server #1およびSQL Server #2で実行されているWSFCに基づいています。
-
AOAG 2:これはOCIリージョン2で実行されています。これは、次の例(Marseille OCIリージョン)のSQL Server #3およびSQL Server #4で構成されたWSFCで実行されているAlways On可用性グループは完全に独立しています。
-
分散AOAG:これは、レプリケートするSQLデータベースに作成された論理構成です。
次の図は、分散可用性グループの論理表現を示しています。
-
-
独立したAlways On可用性グループを2つ作成します(最初のリージョンに1つ、2番目のリージョンに1つ)。詳細は、OCIでのHAおよびDR用のMicrosoft SQL Server Always On可用性グループのデプロイを参照してください。
現在、ピアリングされた2つの異なるOCIリージョンで実行されている2つの独立したAlways On可用性グループがあります。この例では、OCIリージョンはParisおよびMarseilleです。
-
最初のリージョンには最初のWSFCクラスタ(
paris-wsfc
)があり、最初のSQL Always On可用性グループ(paris-aoag
)とSQL Always On可用性グループのSQLリスナー(paris-sql-list
)があります。2つのWindowsノードは、
sql-srv1
およびsql-srv2
です。 -
2つ目のリージョンでは、2つ目のWSFCクラスタ(
marseille-wsfc
)と2つ目のSQL Always On可用性グループ(marseille-aoag
)と、2つ目のSQL Always On可用性グループのSQLリスナー(mars-sql-list
)があります。2つのWindowsノードは、
sql-srv3
およびsql-srv4
です。 -
SQL Serverの観点からは、
sql-srv1
(paris-aoag
)から始めて、この例では、最初のAlways On可用性グループと新しく作成されたdistributed-aoag
でレプリケートされたデータベースのDemoDBを確認できます。 -
したがって、
sql-srv3
(marseille-aoag
)で接続すると、この例では、最初のAlways On可用性グループ、新しく作成されたdistributed-aoag
および2番目のAlways On可用性グループ(Marseille)で作成された2番目のAlways On可用性グループであるmarseille-aoag
でレプリケートされるデータベースであるDemoDBも確認できます。
-
タスク1: 分散可用性グループの作成
すでに実行されている2つの基礎となるAlways On可用性グループで構成される分散可用性グループ(distributed-aoag
)を作成します。
すでに説明したように、2つの独立したAlways On可用性グループが、すでに2つの異なるOCIリージョンで稼働していると想定しています。
2番目のAlways On可用性グループ(marseille-aoag
)は、スタンバイ・グループにはデータベースが関連付けられていないため、実際には、2番目のAlways On可用性グループは、分散可用性グループの作成前に空である必要があるため、可用性データベースが関連付けられていません。2つ目のAlways On可用性グループは、初期データベースを関連付けて通常どおり作成でき、その後、2つ目のAlways On可用性グループの作成にのみ使用されたこのデータベースを削除できます。これは、グラフィカル・インタフェースでは、データベースに関連付けられたAlways On可用性グループを作成できないためです。
-
最初のAlways On可用性グループで分散可用性グループを作成します。
最初のサーバー(この例ではParisサイトの
sql-srv1
ノード)でSQL Serverに接続し、次のSQLコマンドを実行します。ノート:
-
リスナー名は、
paris-sql-list
およびmars-sql-list
です。 -
使用するTCPポート、
5022
はエンドポイントのポートであり、使用する必要があります。これは通常、リスナー・ポート(1433
)とは異なります。 -
可用性グループ名は、すでに実行されているAlways On可用性グループで使用される名前にしてください。
USE MASTER; CREATE AVAILABILITY GROUP [distributed-aoag] WITH (DISTRIBUTED) AVAILABILITY GROUP ON 'paris-aoag' WITH ( LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'marseille-aoag' WITH ( LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ); GO
-
-
2番目のAlways On可用性グループで分散可用性グループに参加します。
2番目のAlways On可用性グループ(Marseilleサイト
sql-srv3
サーバー)の最初のサーバーでSQL Serverに接続し、次のSQLコマンドを実行します。USE MASTER; ALTER AVAILABILITY GROUP [distributed-aoag] JOIN AVAILABILITY GROUP ON 'paris-aoag' WITH ( LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'marseille-aoag' WITH ( LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ); GO
-
従来の可用性グループとは異なり、分散可用性グループはWSFCのリソース・グループやロールを必要としないことを理解することが重要です。すべてのメタデータはSQL Server内で管理されます。つまり、SQL Server Management Studioでも、分散可用性グループ内のデータベースの名前は直接表示されません。
この情報を表示するには、次のTransact-SQLスクリプトを実行します。
--View metadata and status of the Distributed Availability Group SELECT r.replica_server_name, r.endpoint_url, rs.connected_state_desc, rs.role_desc, rs.operational_state_desc, rs.recovery_health_desc,rs.synchronization_health_desc, r.availability_mode_desc, r.failover_mode_desc FROM sys.dm_hadr_availability_replica_states rs INNER JOIN sys.availability_replicas r ON rs.replica_id=r.replica_id ORDER BY r.replica_server_name
ノート:リージョン間の潜在的なネットワーク・レイテンシに対応するために、プライマリおよびセカンダリAlways On可用性グループを非同期コミット・レプリケーションで構成しました。これにより、プライマリ・データベースのパフォーマンス・オーバーヘッドが最小限に抑えられます。各Always On可用性グループ内で、高可用性を確保するために、レプリカ間の同期コミット・レプリケーションを選択しました。ただし、非同期コミット・レプリカ間のフェイルオーバー(分散可用性グループの場合)では、データ損失を減らすには、フェイルオーバーを開始する前に同期コミット・モードへの一時的な切替えが必要です。failover_modeの場合、分散可用性グループに使用可能なモードは手動のみです。
タスク2: 分散可用性グループのフェイルオーバー手順
このタスクでは、2つのAlways On可用性グループ間のフェイルオーバーについて説明します。データベースのフェイルオーバー手順は、次の簡単な手順とチェックによって構成されます。
-
初期チェック。
-
プライマリAlways On可用性グループとセカンダリAlways On可用性グループについて、可用性モードを非同期から同期に変更します。
-
スクリプトを実行して、同期が適切かどうかを確認します。
-
プライマリAlways On可用性グループのロールをプライマリからセカンダリに変更します。
-
セカンダリAlways On可用性グループへのフェイルオーバー。
-
プライマリAlways On可用性グループとセカンダリAlways On可用性グループについて、可用性モードを同期から非同期に変更します。
ステップに従います。
-
次のスクリプトを実行して、同期が正常かどうかを確認します。まず、現在のプライマリ・サイトの現在のプライマリSQLで、次にセカンダリ・サイトのプライマリSQLで確認します。
実行結果は、
CONNECTED_STATE
=CONNECTED
およびSYNCHRONIZATION_HEALTH
=HEALTHY
である必要があります。select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag join sys.availability_replicas ar on ag.group_id=ar.group_id left join sys.dm_hadr_availability_replica_states ars on ars.replica_id=ar.replica_id where ag.is_distributed=1 GO
-
可用性モードを変更します。次のスクリプトを、まず現在のプライマリ・サイトの現在のプライマリSQL Serverで実行し、次にセカンダリ・サイトのプライマリSQL Serverで実行します。
--Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG USE MASTER; ALTER AVAILABILITY GROUP [distributed-aoag] MODIFY AVAILABILITY GROUP ON 'paris-aoag' WITH ( AVAILABILITY_MODE = SYNCHRONOUS_COMMIT ), 'marseille-aoag' WITH ( AVAILABILITY_MODE = SYNCHRONOUS_COMMIT );
-
データ損失がないことを確認するには、このステップの結果を確認します。ステータスは
SYNCHRONIZED
で、last_hardened_lsn
はグローバル・プライマリとフォワーダの両方のデータベースごとに一致する必要があります。-- Run this query on the Global Primary and the forwarder -- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and forwarder -- If not rerun the query on both side every 5 seconds until it is the case -- SELECT ag.name , drs.database_id , db_name(drs.database_id) as database_name , drs.group_id , drs.replica_id , drs.synchronization_state_desc , drs.last_hardened_lsn FROM sys.dm_hadr_database_replica_states drs INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;
-
現在のプライマリ・サイトの現在のプライマリSQL Serverで
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
を設定する準備ができました。--Run this script into Primary AOAG USE MASTER; ALTER AVAILABILITY GROUP [distributed-aoag] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
これで、プライマリAlways On可用性グループのロールをプライマリからセカンダリに変更する準備ができました。
--Run this script into Primary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG USE MASTER; ALTER AVAILABILITY GROUP [distributed-aoag] SET (ROLE = SECONDARY);
-
セカンダリAlways On可用性グループのロールをセカンダリからプライマリに変更します。次のスクリプトは、このロール変更を実行し、データベースの読取りまたは書込み操作を有効にします。また、分散可用性グループ内のAlways On可用性グループのロールもそれに応じて更新されます。
--Run this script into Secondary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG ALTER AVAILABILITY GROUP [distributed-aoag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
ステータスを確認するには、次のスクリプトを実行します。
--check the status on the new primary (formerly standby site) select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag join sys.availability_replicas ar on ag.group_id=ar.group_id left join sys.dm_hadr_availability_replica_states ars on ars.replica_id=ar.replica_id where ag.is_distributed=1 GO
-
新しいプライマリSQL Serverで、
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
の設定を解除します。--Run this script into Primary AOAG ALTER AVAILABILITY GROUP [distributed-aoag] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
プライマリ・サイトとセカンダリ・サイトの両方で次のスクリプトを実行して、可用性モードを標準モードに戻します。
--Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG ALTER AVAILABILITY GROUP [distributed-aoag] MODIFY AVAILABILITY GROUP ON 'paris-aoag' WITH ( AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT ), 'marseille-aoag' WITH ( AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT );
タスク3: 分散Always On可用性グループのフェイルバック手順
プライマリ・サイトとしてParisを復元し、セカンダリ・サイトとしてMarseilleを復元するには、タスク2で概説されているように、新しいスイッチオーバーを実行して同期を元に戻します。
関連リンク
承認
- 著者 - Alessandro Volpi (クラウド・ソリューション・スペシャリスト)
その他の学習リソース
docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。
製品ドキュメントは、Oracle Help Centerを参照してください。
Deploy Microsoft SQL Server Distributed Always On Availability Groups for DR on OCI
G23257-01
December 2024