前提条件: 分散型 AG を SQL Server VM に移行する

分散型可用性グループ (AG) を使用して、SQL Server のスタンドアロン インスタンスまたは Always On 可用性グループを Azure Virtual Machines (VM) 上の SQL Server に移行します。

この記事では、分散型 AG を使用して SQL Server インスタンスまたは可用性グループを複数の SQL Server VM に移行するためのソースとターゲットの環境を準備するための前提条件について説明します。

分散型可用性グループを使用したスタンドアロン インスタンスからのデータベース (または複数のデータベース) の移行は、Windows Server フェールオーバー クラスターや、ソースまたはターゲット上の可用性グループ リスナーを必要としない単純なソリューションです。 可用性グループを移行するには、クラスターと、ソースとターゲットの両方のリスナーが必要です。

ソース SQL Server

インスタンスまたは可用性グループを移行するには、ソース SQL Server グループが次の前提条件を満たす必要があります。

• スタンドアロン インスタンスの移行では、サポートされている最小バージョンは SQL Server 2017 です。 可用性グループの移行では、SQL Server 2016 以降がサポートされます。
• SQL Server のエディションはエンタープライズである必要があります。
• Always On 機能を有効にする必要があります。
• 移行するデータベースは、フル モードでバックアップされています。
• 可用性グループが既にある場合は、正常な状態である必要があります。 このプロセスの一環として可用性グループを作成する場合は、移行を開始する前に正常な状態である必要があります。
• SQL Server インスタンス (既定では 1433) とデータベース ミラーリング エンドポイント (既定では 5022) によって使用されるポートは、ファイアウォールで開く必要があります。 可用性グループ内のデータベースを移行するには、リスナーによって使用されるポートもファイアウォールで開いている必要があります。

ターゲットの SQL Server VM

ターゲットの SQL Server VM の移行準備を整える前に、VM が次の前提条件を満たしていることを確認してください。

• 移行を実行する Azure アカウントは、ターゲットの SQL Server VM が含まれているリソース グループの所有者または共同作成者として割り当てられています。
• 自動シード処理を使用して分散型可用性グループ (DAG) を作成するには、DAG のグローバル プライマリ (ソース) のインスタンス名が、DAG のフォワーダー (ターゲット) のインスタンス名と一致する必要があります。 グローバル プライマリとフォワーダーの間にインスタンス名の不一致がある場合は、手動シード処理を使用して DAG を作成し、後でデータベース ファイルを手動で追加する必要があります。
• わかりやすくするために、ターゲット SQL Server インスタンスはソース SQL Server インスタンスのバージョンと一致する必要があります。 移行プロセス中にターゲットの上位バージョンの SQL Server を使用してアップグレードする場合は、この一連の記事で説明されている自動シード処理に依存するのではなく、データベースを手動でシード処理する必要があります。 詳細については、「SQL Server の上位バージョンへの移行」を参照してください。
• SQL Server のエディションはエンタープライズである必要があります。
• Always On 機能を有効にする必要があります。
• SQL Server インスタンス (既定では 1433) とデータベース ミラーリング エンドポイント (既定では 5022) によって使用されるポートは、ファイアウォールで開く必要があります。 可用性グループ内のデータベースを移行するには、リスナーによって使用されるポートもファイアウォールで開いている必要があります。

接続

ソースとターゲットの SQL Server インスタンスは、ネットワーク接続が確立されている必要があります。

ソース SQL Server インスタンスがオンプレミス ネットワーク上にある場合は、オンプレミス ネットワークとターゲット SQL Server VM が存在する仮想ネットワークとの間にサイト間 VPN 接続または Azure ExpressRoute 接続を構成します。

ソース SQL Server インスタンスが、ターゲット SQL Server VM とは異なる Azure 仮想ネットワーク上にある場合は、仮想ネットワーク ピアリングを構成します。

認証

ソースとターゲットの SQL Server インスタンス間の認証を簡略化するには、両方のサーバーを同じドメインに参加させます。できれば、ソース側にあるドメインを使用し、ドメイン ベースの認証を適用します。 これは推奨される方法であるため、このチュートリアル シリーズの手順では、ソースとターゲットの両方の SQL Server インスタンスが同じドメインに含まれると想定しています。

ソースとターゲットのサーバーが異なるドメインに含まれている場合は、2 つのドメイン間のフェデレーションを構成するか、ドメインに依存しない可用性グループを構成します。

次のステップ

前提条件を満たすようにソースとターゲットの両方の環境を構成したら、SQL Server のスタンドアロン インスタンスまたは Always On 可用性グループをターゲット SQL Server VM に移行する準備が整います。