フェールオーバー グループの構成 - CLI
この記事では、CLI で Azure Arc 対応 SQL Managed Instance 向けにディザスター リカバリーを構成する方法について説明します。 続行する前に、Azure Arc 対応 SQL Managed Instance - ディザスター リカバリーの情報と前提条件を確認してください。
前提条件
Azure Arc で有効な SQL Managed Instance の 2 つのインスタンス間でフェールオーバー グループを設定する前に、次の前提条件を満たす必要があります。
BasePrice
またはLicenseIncluded
の 1 つとして--license-type
を使用したプライマリ サイトでプロビジョニングされた Azure Arc データ コントローラーと Arc 対応 SQL マネージド インスタンス。- 次の条件でプライマリとしての ID 構成を使用したセカンダリ サイトでプロビジョニングされた Azure Arc データ コントローラーと Arc 対応 SQL マネージド インスタンス。
- CPU
- メモリ
- Storage
- サービス レベル
- Collation
- その他のインスタンス設定
- セカンダリ サイトのインスタンスでは
--license-type
がDisasterRecovery
であることが必要です。 このインスタンスは、ユーザー オブジェクトのない新しいものである必要があります。
Note
- マネージド インスタンスの作成中に、
--license-type
を指定することが重要です。 これにより、DR インスタンスをプライマリ データ センターのプライマリ インスタンスからシード処理できるようになります。 デプロイ後にこのプロパティを更新しても、同じ効果はありません。
デプロイ プロセス
2 つのインスタンス間で Azure フェールオーバー グループを設定するには、次の手順を実行します。
- プライマリ サイトで分散型可用性グループのカスタム リソースを作成する
- セカンダリ サイトで分散型可用性グループのカスタム リソースを作成する
- ミラーリング証明書からバイナリ データをコピーする
sync
モードまたはasync
モードのいずれかで、プライマリとセカンダリのサイト間に分散型可用性グループを設定します
次の図は、適切に構成された分散可用性グループを示しています。
同期モード
Azure Arc データ サービスのフェールオーバー グループでは、sync
と async
の 2 つの同期モードをサポートしています。 同期モードは、インスタンス間でのデータの同期方法、および場合によってはプライマリ マネージド インスタンスのパフォーマンスに直接影響します。
プライマリとセカンダリのサイト間の距離が数マイル以内である場合は、sync
モードを使用します。 それ以外の場合は、プライマリ サイトのパフォーマンスへの影響を避けるために async
モードを使用します。
Azure フェールオーバー グループを構成する - 直接モード
Azure Arc データ サービスが directly
接続モードでデプロイされている場合は、次の手順に従います。
前提条件が満たされたら、次のコマンドを実行して、2 つのインスタンス間に Azure フェールオーバー グループを設定します。
az sql instance-failover-group-arc create --name <name of failover group> --mi <primary SQL MI> --partner-mi <Partner MI> --resource-group <name of RG> --partner-resource-group <name of partner MI RG>
例:
az sql instance-failover-group-arc create --name sql-fog --mi sql1 --partner-mi sql2 --resource-group rg-name --partner-resource-group rg-name
上のコマンドの内容は次のとおりです。
- プライマリとセカンダリの両方のサイトに必要なカスタム リソースを作成します
- ミラーリング証明書をコピーし、インスタンス間でフェールオーバー グループを構成します
Azure フェールオーバー グループを構成する - 間接モード
Azure Arc データ サービスが indirectly
接続モードでデプロイされている場合は、次の手順に従います。
プライマリ サイトでマネージド インスタンスをプロビジョニングします。
az sql mi-arc create --name <primaryinstance> --tier bc --replicas 3 --k8s-namespace <namespace> --use-k8s
kubectl config use-context <secondarycluster>
を実行してセカンダリ クラスターにコンテキストを切り替えます。そして、ディザスター リカバリー インスタンスとなるマネージド インスタンスをセカンダリ サイトでプロビジョニングします。 この時点では、システム データベースは、包含可用性グループの一部ではありません。Note
--license-type DisasterRecovery
はマネージド インスタンス中に指定することが重要です。 これにより、DR インスタンスをプライマリ データ センターのプライマリ インスタンスからシード処理できるようになります。 デプロイ後にこのプロパティを更新しても、同じ効果はありません。az sql mi-arc create --name <secondaryinstance> --tier bc --replicas 3 --license-type DisasterRecovery --k8s-namespace <namespace> --use-k8s
ミラーリング証明書 - インスタンス フェールオーバー グループ CR (カスタム リソース) 作成には、マネージド インスタンスのミラーリング証明書プロパティ内のバイナリ データが必要です。
これは次のような方法で達成できます。
(a)
az
CLI を使用している場合、最初にミラーリング証明書ファイルを生成したら、そのファイルをポイントします。同時に、インスタンス フェールオーバー グループを構成し、バイナリ データがファイルから読み取られ、CR にコピーされるようにします。 証明書ファイルは、フェールオーバー グループの作成後には必要ありません。(b)
kubectl
を使用している場合、マネージド インスタンス CR のバイナリ データを直接コピーして、インスタンス フェールオーバー グループの作成に使用される yaml ファイルに貼り付けます。上記の (a) の使用:
プライマリ インスタンスのミラーリング証明書ファイルを作成します。
az sql mi-arc get-mirroring-cert --name <primaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s
例:
az sql mi-arc get-mirroring-cert --name sqlprimary --cert-file $HOME/sqlcerts/sqlprimary.pem --k8s-namespace my-namespace --use-k8s
セカンダリ クラスターに接続し、セカンダリ インスタンスのミラーリング証明書ファイルを作成します。
az sql mi-arc get-mirroring-cert --name <secondaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s
例:
az sql mi-arc get-mirroring-cert --name sqlsecondary --cert-file $HOME/sqlcerts/sqlsecondary.pem --k8s-namespace my-namespace --use-k8s
ミラーリング証明書ファイルが作成されたら、セカンダリ インスタンスからプライマリ インスタンス クラスターの共有/ローカル パスに証明書をコピーします。また、その逆も同様に行います。
両方のサイトにフェールオーバー グループ リソースを作成します。
Note
SQL インスタンスの名前がプライマリ サイトとセカンダリ サイトの両方で異なっていることを確認してください。また、両方のサイトで
shared-name
の値が同じである必要があります。az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary failover group resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name> --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s
例:
az sql instance-failover-group-arc create --shared-name myfog --name primarycr --mi sqlinstance1 --role primary --partner-mi sqlinstance2 --partner-mirroring-url tcp://10.20.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance2.pem --k8s-namespace my-namespace --use-k8s
セカンダリ インスタンスで、次のコマンドを実行してフェールオーバー グループのカスタム リソースを設定します。 この場合の
--partner-mirroring-cert-file
は、上記 3(a) で説明されているように、プライマリ インスタンスから生成されたミラーリング証明書ファイルを含むパスを指す必要があります。az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for secondary failover group resource> --mi <local SQL managed instance name> --role secondary --partner-mi <partner SQL managed instance name> --partner-mirroring-url tcp://<primary IP> --partner-mirroring-cert-file <primary.pem> --k8s-namespace <namespace> --use-k8s
例:
az sql instance-failover-group-arc create --shared-name myfog --name secondarycr --mi sqlinstance2 --role secondary --partner-mi sqlinstance1 --partner-mirroring-url tcp://10.10.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance1.pem --k8s-namespace my-namespace --use-k8s
Azure フェールオーバー グループの正常性状態を取得する
プライマリ ロール、セカンダリ ロール、現在の正常性状態などのフェールオーバー グループに関する情報は、プライマリまたはセカンダリのサイトのカスタム リソースで表示できます。
フェールオーバー グループのカスタム リソースを一覧表示するには、プライマリまたはセカンダリのどちらか、または両方のサイトで以下のコマンドを実行します。
kubectl get fog -n <namespace>
次のように、カスタム リソースについて記述して、フェールオーバー グループの状態を取得します。
kubectl describe fog <failover group cr name> -n <namespace>
フェールオーバー グループ操作
マネージド インスタンス間でフェールオーバー グループを設定したら、状況に応じて別のフェールオーバー操作を実行できます。
考えられるフェールオーバーのシナリオは次のとおりです。
両方のサイトのインスタンスは正常な状態にあるため、フェイルオーバーを実行する必要があります。
- プライマリ SQL MI で
role=secondary
を設定して、データ損失なしでプライマリからセカンダリへの手動フェールオーバーを実行します。
- プライマリ SQL MI で
プライマリ サイトが異常/到達不能であり、フェールオーバーを実行する必要があります。
- プライマリ Azure Arc 対応 SQL Managed Instance がダウン/異常/到達不能になっている
- セカンダリ Azure Arc 対応 SQL Managed Instance は、データ損失の可能性があるため、プライマリに強制的に昇格する必要がある
- 元のプライマリ Azure Arc 対応 SQL Managed Instance がオンラインに戻ると、
Primary
ロールおよび異常な状態として報告されるため、フェールオーバー グループに参加し、データを同期できるように、強制的にsecondary
ロールにする必要があります。
手動フェールオーバー (データ損失なし)
az sql instance-failover-group-arc update ...
コマンド グループを使用して、プライマリからセカンダリへのフェールオーバーを開始します。 geo プライマリ インスタンス上の保留中のトランザクションは、フェールオーバーの前に geo セカンダリ インスタンスにレプリケートされます。
直接接続モード
次のコマンドを実行して、ARM API を使用して direct
接続モードで手動フェールオーバーを開始します。
az sql instance-failover-group-arc update --name <shared name of failover group> --mi <primary instance> --role secondary --resource-group <resource group>
例:
az sql instance-failover-group-arc update --name myfog --mi sqlmi1 --role secondary --resource-group myresourcegroup
間接接続モード
次のコマンドを実行して、kubernetes API を使用して indirect
接続モードで手動フェールオーバーを開始します。
az sql instance-failover-group-arc update --name <name of failover group resource> --role secondary --k8s-namespace <namespace> --use-k8s
例:
az sql instance-failover-group-arc update --name myfog --role secondary --k8s-namespace my-namespace --use-k8s
データ損失のある強制的なフェールオーバー
geo プライマリ インスタンスが使用できなくなった状況では、geo セカンダリ DR インスタンスで次のコマンドを実行すると、強制フェールオーバーでプライマリに昇格しますが、データ損失の可能性があります。
geo セカンダリ DR インスタンスで、次のコマンドを実行して、データ損失を伴うプライマリ ロールに昇格します。
Note
--partner-sync-mode
が sync
として構成されている場合、セカンダリがプライマリに昇格されるときに async
にリセットする必要があります。
直接接続モード
az sql instance-failover-group-arc update --name <shared name of failover group> --mi <instance> --role force-primary-allow-data-loss --resource-group <resource group> --partner-sync-mode async
例:
az sql instance-failover-group-arc update --name myfog --mi sqlmi2 --role force-primary-allow-data-loss --resource-group myresourcegroup --partner-sync-mode async
間接接続モード
az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-primary-allow-data-loss --partner-sync-mode async
geo プライマリ インスタンスが使用可能になったら、以下のコマンドを実行してフェールオーバー グループに取り込み、データを同期します。
直接接続モード
az sql instance-failover-group-arc update --name <shared name of failover group> --mi <old primary instance> --role force-secondary --resource-group <resource group>
間接接続モード
az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-secondary
必要に応じて、--partner-sync-mode
を sync
モードに戻すことができます。
フェールオーバー後の操作
データ損失の有無にかかわらず、プライマリ サイトからセカンダリ サイトへのフェールオーバーを実行したら、以下を行う必要が生じる可能性があります。
- アプリケーションの接続文字列を更新して、新しく昇格したプライマリ Arc SQL マネージド インスタンスに接続します
- 引き続きセカンダリ サイトから運用ワークロードを実行する予定の場合は、
--license-type
をBasePrice
またはLicenseIncluded
に更新して、消費された仮想コアの課金を開始します。