SQL Server Always On 可用性グループを Azure VMware Solution に移行する

[アーティクル]
12/18/2023

この記事では、SQL Server Always On 可用性グループを Azure VMware Solution に移行する方法について説明します。 VMware HCX の場合は、VMware vMotion の移行手順に従ってください。

Microsoft SQL Server (2019 および 2022) は、オンプレミス環境にデプロイされた仮想マシンを使った Windows Server (2019 および 2022) Data Center エディションでテストされました。 Windows Server と SQL Server は、Microsoft と VMware のベストプラクティスと推奨事項に従って構成されています。オンプレミスのソースインフラストラクチャは、Dell PowerEdge サーバーと Intel Optane P4800X SSD NVMe デバイス上で実行されている VMware vSphere 7.0 Update 3 と VMware vSAN でした。

前提条件

SQL Server インスタンスを Azure VMware Solution に移行するための前提条件は次のとおりです。

クラスター内のすべてのノードのストレージとネットワーク構成を確認して記録します。
すべての SQL Server データベースのバックアップを維持します。
SQL Server をホストしている (1 つまたは複数の) 仮想マシンをバックアップします。
VMware vSphere Distributed Resource Scheduler (DRS) グループおよびルールから仮想マシンを削除します。
VMware HCX は、オンプレミスのデータセンターと、移行されたワークロードを実行する Azure VMware Solution プライベートクラウドとの間に構成する必要があります。 HCX の構成方法の詳細については、Azure VMware Solution のドキュメントを参照してください。
SQL Server によって使用されているすべてのネットワークセグメントと、それを使うワークロードが Azure VMware Solution プライベートクラウドに拡張されていることを確認します。この手順を確認するには、「VMware HCX ネットワーク拡張機能の構成」を参照してください。

移行用のネットワーク構成として、VPN 経由の VMware HCX または ExpressRoute 接続のいずれかを使用できます。

VPN 経由の VMware HCX では、帯域幅が制限されているため、通常、(非運用環境など) 長時間のダウンタイムに耐えられるワークロードに適しています。

次のいずれかの場合は、ExpressRoute 接続による移行をお勧めします。

運用環境
データベースサイズが大きいワークロード
ダウンタイムを最小限に抑える必要があるシナリオでは、ExpressRoute 接続による移行をお勧めします。

ダウンタイムに関するさらなる考慮事項については、次のセクションで説明します。

ダウンタイムに関する考慮事項

移行中のダウンタイムは、移行するデータベースのサイズと、Azure クラウドへのプライベートネットワーク接続の速度によって異なります。 SQL Server 可用性グループの移行は、ソリューションのダウンタイムを最小限に抑えて実行できますが、事前に承認された変更期間内のピーク時以外の時間に移行を実行するのが最適です。

次の表は、各 SQL Server トポロジの移行の推定ダウンタイムを示しています。

シナリオ	予想されるダウンタイム	メモ
SQL Server スタンドアロンインスタンス	低	移行は VMware vMotion を使って行われ、データベースは移行期間中も使用できますが、移行中に重要なデータをコミットすることはお勧めできません。
SQL Server Always On 可用性グループ	低	プライマリレプリカは、最初のセカンダリレプリカの移行中に常に使用でき、Azure への初期フェールオーバー後に、セカンダリレプリカはプライマリになります。
SQL Server Always On フェールオーバークラスターインスタンス	高	クラスターのすべてのノードがシャットダウンされ、VMware HCX コールド移行を使って移行されます。ダウンタイムの期間は、データベースのサイズと Azure クラウドへのプライベートネットワークの速度によって異なります。

Windows Server フェールオーバークラスターのクォーラムに関する考慮事項

Microsoft SQL Server Always On 可用性グループは Windows Server フェールオーバークラスターに依存しているため、クラスターの一貫性を維持するためにクォーラム投票メカニズムが必要です。

奇数個の投票要素が必要です。これは、クラスター内の奇数個のノードまたは監視を使うことによって実現されます。監視は 3 つの異なる方法で構成できます。

ディスク監視
ファイル共有監視
クラウド監視

クラスターがディスク監視を使っている場合は、このドキュメントで説明されている手順を使って、ディスクを残りのクラスター共有ストレージと共に移行する必要があります。

クラスターがオンプレミスで実行されているファイル共有監視を使っている場合、移行されたクラスターの監視の種類は Azure VMware Solution のシナリオによって異なり、考慮すべきオプションがいくつかあります。

データセンター拡張機能: オンプレミスでファイル共有監視を維持します。ワークロードはデータセンターと Azure 全体に分散されます。したがって、データセンターと Azure の間の接続は常に利用できる必要があります。いずれの場合も、帯域幅の制約を考慮し、それに応じて計画を立てます。
データセンターの撤退: このシナリオには 2 つのオプションがあります。どちらのオプションでも、処理中にロールバックが必要になった場合に備えて、移行中にオンプレミスでファイル共有監視を維持できます。
- Azure VMware Solution プライベートクラウドに新しいファイル共有監視をデプロイします。
- Azure VMware Solution プライベートクラウドと同じリージョンの Azure Blob Storage で実行されるクラウド監視をデプロイします。
ディザスターリカバリーと事業継続: ディザスターリカバリーのシナリオの場合、最良かつ最も信頼性の高いオプションは、Azure Storage で実行されるクラウド監視を作成することです。
アプリケーションのモダン化: このユースケースの場合、最適なオプションは、クラウド監視をデプロイすることです。

クォーラムの構成と管理の詳細については、フェールオーバークラスタリングのドキュメントを参照してください。 Azure Blob Storage でのクラウド監視のデプロイの詳細については、フェールオーバークラスターのクラスタークォーラムの管理に関するページを参照してください。

SQL Server Always On 可用性グループの移行

管理資格情報を使って、SQL Server Management Studio で Always On 可用性グループにアクセスします。
- プライマリレプリカを選んで、[可用性グループのプロパティ] を開きます。
- 移行するレプリカについてのみ、[可用性モード] を [非同期コミット] に変更します。
- 可用性グループのすべてのメンバーの [フェールオーバーモード] を [手動] に変更します。
オンプレミスの vCenter Server にアクセスし、HCX 領域に進みます。
[サービス] で [移行]>[移行] の順に選びます。
- 移行するデータベースのセカンダリレプリカを実行している仮想マシンを 1 台選択します。
- リモートプライベートクラウドに vSphere クラスターを設定します。これにより、移行された SQL Server VM がコンピューティングコンテナーとしてホストされるようになります。
- リモートストレージとして vSAN データストアを選びます。
- フォルダーを選択します。これは必須ではありませんが、Azure VMware Solution プライベートクラウド内のさまざまなワークロードを分離するためにお勧めします。
- ソースと同じ形式を維持します。
- [移行プロファイル] として [vMotion] を選びます。
- [拡張オプション] で [カスタム属性の移行] を選びます。
- オンプレミスのネットワークセグメントに、Azure の適切なリモートストレッチセグメントがあることを確認します。
- [検証] を選び、すべての検証が完了し、状態が合格であることを確認します。最も一般的なエラーは、ストレージ構成に関連したものです。物理共有設定を持つ仮想 SCSI コントローラーがないことを再度確認します。
- [移動] を選択して移行を開始します。
移行が完了したら、移行されたレプリカにアクセスし、可用性グループ内の残りのメンバーとの接続を確認します。
SQL Server Management Studio で、[可用性グループダッシュボード] を開き、レプリカが [オンライン] として表示されていることを確認します。
- 移行中にレプリカがプライマリと同期していないため、[フェールオーバーの準備] 列の [データ損失] 状態は想定されるものです。
可用性グループのプロパティを再度編集し、[可用性モード] を [同期コミット] に戻します。
- セカンダリレプリカは、移行中にプライマリレプリカに加えられたすべての変更の同期を開始します。同期済み状態になるまで待ちます。
SSMS の [可用性グループダッシュボード] で、[フェールオーバーの開始] ウィザードを選択します。
移行されたレプリカを選び、[次へ] を選択します。
次の画面で、DB 管理者の資格情報を使ってレプリカに接続します。
変更内容を確認し、[完了] を選択してフェールオーバー操作を開始します。
次の画面でフェールオーバーの進行状況を監視し、操作が終了したら [閉じる] を選択します。
SQL Server Management Studio (SSMS) の [オブジェクトエクスプローラー] ビューを更新し、移行されたインスタンスがプライマリレプリカになっていることを確認します。
可用性グループの残りのレプリカに対して手順 1 から 6 を繰り返します。

Note

一度に 1 つのレプリカを移行し、各移行後にすべての変更がレプリカに同期されていることを確認します。 HCX 一括移行を使ってすべてのレプリカを同時に移行しないでください。
すべてのレプリカの移行が完了したら、SQL Server Management Studio を使って Always On 可用性グループにアクセスします。
- ダッシュボードを開き、どのレプリカにもデータ損失がなく、すべてが同期済み状態であることを確認します。
- 可用性グループのプロパティを編集し、すべてのレプリカで [フェールオーバーモード] を [自動] に設定します。