次の方法で共有


SQL Server Always On フェールオーバー クラスター インスタンスを Azure VMware Solution に移行する

この記事では、SQL Server フェールオーバー クラスター インスタンスを Azure VMware Solution に移行する方法について説明します。 現在、Azure VMware Solution サービスは、オンプレミスの vCenter Server を Azure VMware Solution で実行されているものに接続するための VMware ハイブリッド リンク モードをサポートしていません。 この制約のため、このプロセスでは移行に VMware HCX を使う必要があります。 HCX の構成について詳しくは、「Azure VMware Solution に VMware HCX をインストールしてアクティブ化する」をご覧ください。

VMware HCX は、仮想マシンに接続された物理共有モードの SCSI コントローラーを備えた仮想マシンの移行をサポートしていません。 ただし、ここで示す手順を実行し、VMware HCX コールド移行を使ってクラスターを構成するさまざまな仮想マシンを移動すると、この制限を解消できます。

図には、Azure VMware Solution に関する SQL Server フェールオーバーのアーキテクチャが示されています。

Note

この手順では、クラスターを完全にシャットダウンする必要があります。 移行中は SQL Server サービスが利用できなくなるため、それに応じてダウンタイム期間を計画してください。

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 でした。

前提条件

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

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

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

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

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

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

移行中のダウンタイムは、移行するデータベースのサイズと、Azure クラウドへのプライベート ネットワーク接続の速度によって異なります。 SQL Server フェールオーバー クラスター インスタンス Always On を Azure VMware Solution に移行するには、データベースとすべてのクラスター ノードの完全なダウンタイムが必要ですが、事前に承認された変更期間内のピーク時以外の時間に移行を実行するように計画する必要があります。

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

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

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

Windows Server フェールオーバー クラスターでは、クラスターを維持するためにクォーラム メカニズムが必要です。

奇数個の投票要素を使った実現には、クラスター内の奇数個のノードまたは監視を使います。 監視は 3 つの異なる形式で構成できます。

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

クラスターがディスク監視を使っている場合は、フェールオーバー クラスターの移行を使って、ディスクをクラスター共有ストレージと共に移行する必要があります。

クラスターがオンプレミスで実行されているファイル共有監視を使用している場合、移行されたクラスターの監視の種類は以下のように Azure VMware Solution のシナリオによって異なります。

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

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

フェールオーバー クラスターの移行

説明のために、このドキュメントでは、Windows Server 2019 Datacenter と SQL Server 2019 Enterprise を備えた 2 ノード クラスターを使っています。 この手順では、Windows Server 2022 および SQL Server 2022 もサポートされます。

  1. vSphere クライアントから、クラスターの 2 番目のノードをシャットダウンします。

  2. クラスターの最初のノードにアクセスし、[フェールオーバー クラスター マネージャー] を開きます。

    • 2 番目のノードがオフライン状態にあり、すべてのクラスター化されたサービスとストレージが最初のノードの管理下にあることを確認します。 図には、Windows Server フェールオーバー クラスター マネージャーのクラスター ストレージの検証が示されています。

    • クラスターをシャットダウンします。

      図には、Windows Server フェールオーバー クラスター マネージャーを使用したシャットダウン クラスターが示されています。

    • すべてのクラスター サービスがエラーなしで正常に停止していることを確認します。

  3. クラスターの最初のノードをシャットダウンします。

  4. vSphere クライアントから、クラスターの 2 番目のノードの設定を編集します。

    • 仮想マシン構成からすべての共有ディスクを削除します。
    • [データストアからファイルを削除する] チェックボックスがオンになっていないことを確認します。オンになっていると、データストアからディスクが完全に削除されます。 そうなった場合は、以前のバックアップからクラスターを復旧する必要があります。
    • 共有ストレージに使用される仮想 SCSI コントローラーで、[SCSI バス共有][物理] から [なし] に設定します。 通常、これらのコントローラーは VMware 準仮想化型です。
  5. 最初のノードの仮想マシン設定を編集します。 SCSI コントローラーの [SCSI バス共有][物理] から [なし] に設定します。

  6. vSphere クライアントから、HCX プラグイン領域に移動します。 [サービス][移行]>[移行] の順に選びます。

    • 2 番目のノードの仮想マシンを選びます。
    • リモート プライベート クラウドで vSphere クラスターを設定します。これは、移行された SQL Server VM をコンピューティング コンテナーとしてホストします。
    • リモート ストレージとして vSAN データストアを選びます。
    • 仮想マシンを特定のフォルダーに配置する場合は、フォルダーを選びます。 これは必須ではありませんが、Azure VMware Solution プライベート クラウド内のさまざまなワークロードを分離するためにお勧めします。
    • ソースと同じ形式を維持します。
    • [移行プロファイル] として [コールド移行] を選びます。
    • [拡張] [オプション][カスタム属性の移行] を選択します。
    • オンプレミスのネットワーク セグメントに、Azure の適切なリモート ストレッチ セグメントがあることを確認します。
    • [検証] を選び、すべての検証が完了し、状態が合格であることを確認します。 最も一般的なエラーは、ストレージ構成に関連するものです。 物理共有設定が行われている SCSI コントローラーがないことを再度確認します。
    • [実行] を選ぶと移行が開始します。
  7. 最初のノードに対して同じプロセスを繰り返します。

  8. Azure VMware Solution vSphere クライアントにアクセスし、最初のノード設定を編集して、共有ディスクを管理する SCSI コントローラーを共有する物理 SCSI バスに設定し直します。

  9. vSphere クライアントでノード 2 の設定を編集します。

    • 共有ストレージを管理する SCSI コントローラーで、SCSI バス共有を [物理] に戻します。
    • 追加ストレージとして、クラスター共有ディスクをノードに追加します。 それらを 2 番目の SCSI コントローラーに割り当てます。
    • すべてのストレージ構成が移行前に記録されたものと同じであることを確認します。
  10. 最初のノードの仮想マシンの電源をオンにします。

  11. VMware リモート コンソールを使って最初のノード VM にアクセスします。

    • 仮想マシンのネットワーク構成を確認し、オンプレミスと Azure リソースにアクセスできることを確認します。

    • [フェールオーバー クラスター マネージャー] を開き、クラスター サービスを確認します。

      図には、フェールオーバー クラスター マネージャーでのクラスターの概要が示されています。

  12. 2 番目のノードの仮想マシンの電源をオンにします。

  13. VMware リモート コンソールから 2 番目のノード VM にアクセスします。

    • Windows Server からストレージにアクセスできることを確認します。
    • フェールオーバー クラスター マネージャーで、2 番目のノードが [オンライン] 状態として表示されていることを確認します。 図には、フェールオーバー クラスター マネージャーでのクラスター ノードの状態が示されています。
  14. SQL Server Management Studio を使って、SQL Server クラスター リソースのネットワーク名に接続します。 すべてのデータベースがオンラインでアクセス可能であることを確認します。

図には、移行されたクラスター インスタンス データベースへの SQL Server Management Studio の接続の検証が示されています。

インフラストラクチャ内の他のシステムやアプリケーションから SQL Server への接続を調べます。 データベースを使っているすべてのアプリケーションが引き続きアクセスできることを確認します。

詳細