Managed Instance のリンク移行のための環境を準備する - Azure Arc での SQL Server の移行

適用対象:SQL Server

この記事は、Azure Portal で Azure Arc によって有効になっている SQL Server インスタンスを Azure SQL Managed Instance に移行するための Managed Instance リンク移行の環境を準備する際に役立ちます。

このリンクを使用すると、分散型可用性グループを使用したリアルタイム レプリケーション (オンライン移行) を使用して、SQL Server データベースを Azure SQL Managed Instance に移行できます。

[前提条件]

Azure portal を使用して SQL Server データベースを Azure SQL Managed Instance に移行するには、次の前提条件が必要です。

• 有効な Azure サブスクリプション。 アカウントがない場合は、無料アカウントを作成してください。
• Azure Arc によって有効になっているサポートされている SQL Server のインスタンスに、Azure 拡張機能を使用した SQL Server バージョン 以降。 拡張機能は、 Azure portal または Azure CLI を使用してアップグレードできます。

サポートされている SQL Server のバージョン

Azure SQL Managed Instance の General Purpose サービス レベルと Business Critical サービス レベルの両方で、Managed Instance リンクがサポートされています。 リンク機能を使用した移行は、Windows Server 上の SQL Server の Enterprise、Developer、Standard の各エディションで動作します。

次の表に、リンクでサポートされている SQL Server の最小バージョンを示します。

逆移行は、対応する 更新ポリシーを使用して SQL マネージド インスタンスから SQL Server 2025 および SQL Server 2022 に対してのみサポートされます。 ネイティブ バックアップや復元などの他のツールを使用して移行を手動で元に戻したり、SSMS でリンクを手動で構成したりできます。

Permissions

このセクションでは、Azure portal を使用して SQL Server インスタンスを SQL Managed Instance に移行するために必要なアクセス許可について説明します。

ソース SQL Server インスタンスでは、次のアクセス許可が必要です。

• 最小限の特権を有効にした場合、データベース移行プロセス中に sysadmin などの必要なアクセス許可が必要に応じて付与されます。
• 最小限の特権を使用できない場合、移行を実行するユーザーには、ソース SQL Server インスタンスに対する sysadmin アクセス許可が必要です。 さらに、移行をキャンセルする必要がある場合は、 アカウントに NT AUTHORITY\SYSTEM アクセス許可を手動で割り当てます。

Managed Instance リンクを使用して移行するには、SQL Managed Instance ターゲットに対する次のいずれかのアクセス許可が必要です。

• SQL マネージド インスタンス貢献者 役割
• サブスクリプション レベルの共同作成者ロールまたは所有者ロール

最小限のアクセス許可については、「 カスタムアクセス許可」を参照してください。

SQL Server インスタンスを準備する

SQL Server インスタンスを準備するには、次の手順を実行します。

• サポートされているバージョンを確認します。
• masterします。
• 可用性グループ機能を有効にします。
• 起動時に適切なトレース フラグを追加します。
• SQL Server を再起動し、構成を検証します。
• データベースを完全復旧モデルに設定します。
• Azure の信頼されたルート証明機関キーを SQL Server にインポートします。

これらの変更を有効にするには 、SQL Server を再起動 する必要があります。

サービスの更新プログラムをインストールする

SQL Server バージョンに対する適切なサービス更新プログラムがインストールされていることを確認してください。サポート対象バージョン表を参照してください。 更新プログラムをインストールする必要がある場合は、更新中に SQL Server インスタンスを再起動する必要があります。

お使いの SQL Server バージョンを確認するには、次の Transact-SQL (T-SQL) スクリプトを SQL Server で実行します。

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

マスター データベースにデータベース マスター キーを作成する

このリンクでは、証明書を使用して、SQL Server と SQL Managed Instance の間の認証と通信を暗号化します。 データベース マスター キーは、リンクによって使用される証明書を保護します。 データベース マスター キーが既にある場合は、この手順をスキップできます。

master データベースにデータベース マスター キーを作成します。 次のスクリプトの <strong_password> の代わりにご自分のパスワードを挿入し、機密情報として安全な場所に保管します。 この T-SQL スクリプトを SQL Server で実行します。

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

データベース マスター キーがあることを確認するために、SQL Server で次の T-SQL スクリプトを使用します。

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

SQL Server 2016 インスタンスを準備する

SQL Server 2016 (13.x) の場合、 リンクの SQL Server 2016 の準備の前提条件に関するページに記載されている追加の手順を完了する必要があります。 リンクでサポートされている SQL Server 2017 (14.x) 以降のバージョンでは、これらの追加の手順は必要ありません。

可用性グループを有効にする

リンク機能は、Always On 可用性グループ機能に依存しており、これは既定では有効になっていません。 詳細については、「Always On 可用性グループ機能を有効にする」を参照してください。

Always On 可用性グループ機能が有効になっていることを確認するには、SQL Server で次の T-SQL スクリプトを実行します。

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

可用性グループ機能が有効になっていない場合は、以下の手順に従って有効にします。

1. SQL Server 構成マネージャーを開きます。

2. 左側のウィンドウから [SQL Server サービス] を選択します。

3. SQL Server サービスを右クリックし、[ プロパティ] を選択します。

   

4. [Always On 可用性グループ] タブに移動します。

5. [ Always On 可用性グループを有効にする ] チェック ボックスをオンにし、[ OK] を選択します。

   

   • SQL Server 2016 (13.x) を使用していて、メッセージ で This computer is not a node in a failover clusterオプションが無効になっている場合は、リンクの SQL Server 2016 の前提条件の準備に関するページで説明されている手順に従います。 これらの手順を完了したら、この手順に戻り、もう一度やり直してください。

6. ダイアログで [OK] を選択します。

7. SQL Server サービスを再起動します。

起動時のトレース フラグを有効にする

リンクのパフォーマンスを最適化するには、起動時に次のトレース フラグを有効にします。

• -T1800: このトレース フラグは、可用性グループ内のプライマリ レプリカとセカンダリ レプリカのログ ファイルが、512 バイトや 4 KB などの異なるセクター サイズのディスク上にある場合のパフォーマンスを最適化します。 プライマリ レプリカとセカンダリ レプリカの両方で 4 KB のディスク セクター サイズが使用されている場合、このトレース フラグは必要ありません。 詳しくは、KB3009974 を参照してください。
• -T9567: このトレース フラグは、自動シード処理時の可用性グループのデータ ストリーム圧縮を有効にします。 圧縮によってプロセッサの負荷が増加しますが、シード処理中の転送時間が大幅に短縮されます。

起動時にこれらのトレース フラグを有効にするには、次の手順を使用します。

1. SQL Server 構成マネージャーを開きます。

2. 左側のウィンドウから [SQL Server サービス] を選択します。

3. SQL Server サービスを右クリックし、[ プロパティ] を選択します。

   

4. [起動時のパラメーター] タブに移動します。[起動時のパラメーターの指定] に「-T1800」と入力し、[追加] を選択して起動時のパラメーターを追加します。 次に、「-T9567」と入力して [追加] を選択し、他のトレース フラグを追加します。 [適用] を選択して変更を保存します。

   

5. [OK] を選択して [プロパティ] ウィンドウを閉じます。

詳細については、「トレース フラグを有効にするための構文」を参照してください。

SQL Server を再起動して構成を検証する

SQL Server のバージョンをアップグレードしたり、可用性グループ機能を有効にしたり、スタートアップ トレース フラグを追加したりする必要がない場合は、このセクションをスキップできます。

サポートされているバージョンの SQL Server を使用していることを確認したら、Always On 可用性グループ機能を有効にし、スタートアップ トレース フラグを追加した後、SQL Server インスタンスを再起動して、次のすべての変更を適用します。

1. SQL Server 構成マネージャーを開きます。

2. 左側のウィンドウから [SQL Server サービス] を選択します。

3. SQL Server サービスを右クリックし、[再起動] を選択 します。

   

再起動後、次の T-SQL スクリプトを SQL Server で実行して、SQL Server インスタンスの構成を検証します。

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

SQL Server のバージョンは、適切なサービス更新プログラムが適用されたサポートされているバージョンのいずれかである必要があります。 Always On 可用性グループ機能を有効にする必要があり、 -T1800 と -T9567 トレース フラグが有効になっている必要があります。 次のスクリーンショットは、適切に構成された SQL Server インスタンスで予想される結果の例です。

データベースを完全復旧モデルに設定する

リンクを介して移行されたデータベースは、完全復旧モデルにあり、少なくとも 1 つのバックアップを持っている必要があります。

移行するすべてのデータベースについて、SQL Server で次のコードを実行します。 <DatabaseName> を実際のデータベース名に置き換えます。

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Azure の信頼されたルート証明機関のキーを SQL Server にインポートする

Azure が発行する SQL Managed Instance 公開キー証明書を信頼するには、Azure の信頼されたルート証明機関 (CA) キーを SQL Server にインポートする必要があります。

ルート CA キーは 、Azure 証明機関の詳細からダウンロードできます。 少なくとも、 DigiCert グローバル ルート G2 証明書と Microsoft RSA ルート証明機関 2017 証明書をダウンロードし、SQL Server インスタンスにインポートします。

サンプルの C:\certs\<name of certificate>.crt パスなど、SQL Server インスタンスにローカルの証明書を保存し、次の Transact-SQL スクリプトを使用してそのパスから証明書をインポートします。 <name of certificate>を実際の証明書名 (DigiCert Global Root G2 と Microsoft RSA Root Certificate Authority 2017) に置き換えます。これは、これら 2 つの証明書に必要な名前です。

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

最後に、次の動的管理ビュー (DMV) を使用して、作成されたすべての証明書を確認します。

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

ネットワーク接続を構成する

リンクが機能するには、SQL Server と SQL Managed Instance の間にネットワーク接続が必要です。 選択するネットワーク オプションは、SQL Server インスタンスが Azure ネットワーク上にあるかどうかによって異なります。

Azure 外部の SQL Server

Azure の外部で SQL Server インスタンスをホストする場合は、次のいずれかのオプションを使用して、SQL Server と SQL Managed Instance の間に VPN 接続を確立できます。

• サイト間 VPN 接続
• Azure ExpressRoute 接続

Azure 仮想マシン上の SQL Server

SQL Managed Instance をホストするのと同じ Azure 仮想ネットワーク内の Azure Virtual Machines に SQL Server をデプロイするのが最も簡単な方法です。これは、2 つのインスタンス間にネットワーク接続が自動的に存在するためです。 詳細については、「クイックスタート: Azure SQL Managed Instance に接続するように Azure VM を構成する」を参照ください。

Azure Virtual Machines インスタンス上の SQL Server が SQL マネージド インスタンスとは異なる仮想ネットワークにある場合は、2 つの仮想ネットワークを接続する必要があります。 このシナリオを機能させるために、仮想ネットワークが同じサブスクリプションに存在する必要はありません。

仮想ネットワークを接続するには、次の 2 つのオプションがあります。

• Azure 仮想ネットワーク ピアリング
• VNet 間 VPN ゲートウェイ (Azure Portal、PowerShell、Azure CLI)

ピアリングは Microsoft バックボーン ネットワークを使用するため、推奨されます。 そのため、接続の観点からは、ピアリングされた仮想ネットワーク内の仮想マシンと同じ仮想ネットワーク内の仮想マシン間の待機時間に顕著な違いはありません。 仮想ネットワーク ピアリングは、同じリージョン内のネットワーク間でサポートされます。 グローバル仮想ネットワーク ピアリングは、2020 年 9 月 22 日より後に作成されたサブネットでホストされているインスタンスでサポートされています。 詳細については、「よく寄せられる質問 (FAQ)」をご覧ください。

環境間のネットワーク ポート

接続メカニズムに関係なく、ネットワーク トラフィックが環境間を流れるには、次の要件を満たす必要があります。

SQL Managed Instance をホストするサブネット上のネットワーク セキュリティ グループ (NSG) 規則では、次のことが許可されている必要があります。

• 送信元 SQL Server IP アドレスからトラフィックを受信する受信ポート 5022 とポート範囲 11000 ~ 11999
• 送信先の SQL Server IP アドレスにトラフィックを送信する送信ポート 5022

SQL Managed Instance では、5022 ポートを変更できません。

SQL Server とホスト OS をホストするネットワーク上のすべてのファイアウォールで、次のことが許可されている必要があります。

• MI サブネット /24 (10.0.0.0/24 など) の送信元 IP 範囲からのトラフィックを受信するために開かれたインバウンド ポート 5022
• MI サブネット (例: 10.0.0.0/24) の送信先 IP 範囲にトラフィックを送信するために開かれたアウトバウンド ポート 5022 とポート範囲 11000-11999

5022 ポートは SQL Server 側でカスタマイズできますが、ポート範囲 11000 ~ 11999 をそのまま開く必要があります。

次の表で、各環境でのポートのアクションについて説明します。

Windows ファイアウォールでポートを開くには、SQL Server インスタンスの Windows ホスト OS で次の PowerShell スクリプトを使用します。

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

次の図は、オンプレミスネットワーク環境の例を示しています。環境内のすべてのファイアウォールには、SQL Server インスタンスをホストする OS ファイアウォール、企業のファイアウォールとゲートウェイなど、 ポートを開く必要があることを示しています。

URL を許可リストに追加する

ネットワーク セキュリティ設定によっては、SQL Managed Instance FQDN と Azure で使用されるリソース管理エンドポイントの一部の URL を許可リストに追加することが必要になる場合があります。

許可リストに次のリソースを追加します。

• SQL Managed Instance の完全修飾ドメイン名 (FQDN)。 たとえば、 managedinstance.a1b2c3d4e5f6.database.windows.netと指定します。
• Microsoft Entra 機関
• Microsoft Entra のエンドポイントリソースID
• リソース管理エンドポイント
• サービス エンドポイント

「 政府向けクラウドの SSMS の構成 」セクションの手順に従って、SQL Server Management Studio (SSMS) の ツール インターフェイスにアクセスし、許可リストに追加する必要があるクラウド内のリソースの特定の URL を特定します。

TDE で保護されたデータベースの証明書を移行する (省略可能)

Transparent Data Encryption (TDE) によって保護された SQL Server データベースを SQL マネージド インスタンスにリンクする場合は、リンクを使用する前に、対応する暗号化証明書をオンプレミスまたは Azure VM SQL Server インスタンスから SQL マネージド インスタンスに移行する必要があります。 詳細な手順については、「TDE で保護されたデータベースの証明書を Azure SQL Managed Instance に移行する」を参照してください。

サービスマネージド TDE キーで暗号化されたSQL Managed Instance は、SQL Server にリンクできません。 暗号化されたデータベースを SQL Server にリンクできるのは、カスタマー マネージド キーを使用して暗号化し、移行先サーバーがデータベースの暗号化に使用したのと同じキーにアクセスできる場合のみです。 詳細については、Azure Key Vault を使った SQL Server TDE の設定に関する記事を参照してください。

ネットワーク接続をテストする

移行を開始する前に、SQL Server インスタンスと SQL Managed Instance の間のネットワーク接続をテストします。 移行プロセスの一環として、Azure portal から直接接続をテストできます。 ただし、Transact-SQL と SQL Server エージェントを使用して、接続を手動でテストすることもできます。 詳細については、「 ネットワーク接続のテスト」を参照してください。

Azure portal を使用して接続をテストするには、次の手順に従います。

1. SQL Server インスタンス リソースの [データベース移行] ウィンドウで [データの移行] を選択します。

2. MI リンク オプションを選択します。

3. 移行するターゲット データベースを選択し、[ 次へ: 設定] を使用して次のタブに移動します。

4. [ 設定] タブで、リンクの名前とソース可用性グループを指定します。 次に 、テスト接続 を使用して、SQL Server と SQL Managed Instance の間のネットワーク接続を検証します。

   

次の点を考慮してください。

• 誤検知を回避するには、ネットワーク パス上のすべてのファイアウォールでインターネット制御メッセージ プロトコル (ICMP) トラフィックを許可する必要があります。
• 誤検知を回避するには、ネットワーク パスに沿ったすべてのファイアウォールで、独自の SQL Server UCS プロトコル上のトラフィックを許可する必要があります。 プロトコルをブロックすると、接続テストが成功する可能性がありますが、リンクの作成に失敗します。
• パケット レベルのガードレールを使用した高度なファイアウォールセットアップは、SQL Server と SQL Managed Instance の間のトラフィックを許可するように適切に構成する必要があります。

制限事項

次の制限が適用されます。

• Managed Instance リンクの制限は、Azure portal を使用した移行に適用されます。
• 移行をキャンセルするには、ソース SQL Server インスタンスに対する sysadmin アクセス許可が必要です。 SQL Server インスタンスが最小限の特権を使用していない場合は、 アカウントに NT AUTHORITY\SYSTEM アクセス許可を手動で割り当てます。
• 移行のために Azure portal を使用してリンクを構成することは、SQL Server Management Studio (SSMS) または Transact-SQL (T-SQL) を使用して手動で作成されたリンクと互換性がありません。 詳細については、 既知の問題 を確認してください。
• Azure portal を使用した移行の監視は、監視 ライセンス要件を満たす SQL Server インスタンスでのみ使用できます。

一般的な問題のトラブルシューティング

Azure SQL Managed Instance に移行するときの一般的な問題のトラブルシューティングについては、「移行に関する 問題のトラブルシューティング」を参照してください。

関連コンテンツ

• Managed Instance のリンクのベスト プラクティス
• Azure Arc での SQL Server の移行
• LRS 移行用の環境を準備する
• Azure Arc で有効になっている SQL Server の概要
• 移行エクスペリエンスのフィードバックを製品グループに直接送信する
• Azure SQL Managed Instance への移行 - Azure Arc での SQL Server の移行