リンクのために環境を準備する - Azure SQL Managed Instance

適用対象:Azure SQL Managed Instance

この記事では、データベースを SQL Server と Azure SQL Managed Instance 間のレプリケーションを行うために、Managed Instance のリンク用に環境を準備する方法について説明します。

Note

ダウンロード可能なスクリプトを使用して、Managed Instance リンク用の環境の準備を自動化できます。 詳細については、リンク設定の自動化に関するブログを参照してください。

前提条件

SQL Server と Azure SQL Managed Instance 間のリンクを作成するには、次の前提条件が必要です。

• 有効な Azure サブスクリプション アカウントがない場合は、無料アカウントを作成してください。
• 必要なサービス更新プログラムがインストールされている SQL Server のサポート対象バージョン。
• Azure SQL Managed Instance。 ない場合はこれを開始します。
• 最初のプライマリにするサーバーを決定し、リンクを作成する場所を決定します。 SQL Managed Instance プライマリから SQL Server セカンダリへのリンクの構成は、SQL Server 2022 CU10 以降でのみサポートされます。

注意事項

リンク機能で使用する SQL managed instance を作成するときは、SQL Server で使用されるインメモリ OLTP 機能のメモリ要件を考慮してください。 詳細については、「Azure SQL Managed Instance のリソース制限の概要」を参照してください。

アクセス許可

SQL Server の場合、sysadmin アクセス許可が必要です。

Azure SQL Managed Instance の場合、SQL Managed Instance 共同作成者のメンバーであるか、カスタム ロールに対して次のアクセス許可を持っている必要があります。

Microsoft.Sql/ リソース	必要なアクセス許可
Microsoft.Sql/managedInstances	/read、/write
Microsoft.Sql/managedInstances/hybridCertificate	/action
Microsoft.Sql/managedInstances/databases	/read、/delete、/write、/completeRestore/action、/readBackups/action、/restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/read、/write、/delete、/setRole/action
Microsoft.Sql/managedInstances/endpointCertificates	/read
Microsoft.Sql/managedInstances/hybridLink	/read、/write、/delete
Microsoft.Sql/managedInstances/serverTrustCertificates	/write、/delete、/read

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

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';

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

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%';

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

リンク機能は、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'

重要

SQL Server 2016 (13.x) では、可用性グループ機能を有効にする必要がある場合、「SQL Server 2016 の前提条件を準備する - Azure SQL Managed Instance リンク」に記載されている追加の手順を完了する必要があります。 これらの追加の手順は、リンクでサポートされている SQL Server 2019 (15.x) 以降のバージョンでは必要ありません。

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

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

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

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

   

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

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

   

   • SQL Server 2016 (13.x) を使用している場合で、[Always On 可用性グループを有効にする] オプションがメッセージ This computer is not a node in a failover cluster. で無効になっている場合は、「SQL Server 2016 の前提条件を準備する - Azure SQL Managed Instance リンク」に記載されている追加の手順に従います。 そのような追加の手順を完了したら、もう一度こちらの手順をやり直してください。

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

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

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

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

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

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

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

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

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

   

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

   

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

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

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

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

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

Azure Virtual Machines 上の SQL Server

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

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

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

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

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

Azure 外部の SQL Server

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

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

ヒント

データをレプリケートするときの最適なネットワーク パフォーマンスを実現するために、ExpressRoute をお勧めします。 実際のユース ケースに十分な帯域幅を持つゲートウェイをプロビジョニングしてください。

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

接続メカニズムに関係なく、ネットワーク トラフィックが環境間を流れるようにするために満たさなければならない要件があります。

マネージド インスタンスをホストするサブネットのネットワーク セキュリティ グループ (NSG) 規則では、次を許可する必要があります。

• 送信元 SQL Server IP からのトラフィックを受信するためのインバウンド ポート 5022 とポート範囲 11000-11999
• 送信先 SQL Server IP にトラフィックを送信するためのアウトバウンド ポート 5022

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

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

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

環境	対処
SQL Server (Azure 内)	ネットワーク ファイアウォールのポート 5022 で、SQL Managed Instance のサブネット IP 全体に対して受信と送信両方のトラフィックを開きます。 必要に応じて、SQL Server ホスト OS (Windows/Linux) のファイアウォールで同じようにします。 ポート 5022 での通信を許可するには、VM をホストする仮想ネットワークにネットワーク セキュリティ グループ (NSG) ルールを作成します。
SQL Server (Azure 外部)	ネットワーク ファイアウォールのポート 5022 で、SQL Managed Instance のサブネット IP 全体に対して受信と送信両方のトラフィックを開きます。 必要に応じて、SQL Server ホスト OS (Windows/Linux) のファイアウォールで同じようにします。
SQL Managed Instance	Azure portal で NSG 規則を作成して、ポート 5022 およびポート範囲 11000 - 11999 上で、SQL Server をホストする IP アドレスとネットワークからの送受信トラフィックを許可します。

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

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 ファイアウォールおよび企業のファイアウォールやゲートウェイなど、環境内のすべてのファイアウォールに開いているポートが必要であることを示しています。

重要

• ホスト サーバーおよびネットワーク上の企業のファイアウォールやゲートウェイも含め、ネットワーク環境内のすべてのファイアウォールでポートを開く必要があります。 企業環境では、企業ネットワーク レイヤーで追加のポートを開くため、このセクションの情報をネットワーク管理者に示すことが必要な場合があります。
• SQL Server 側でエンドポイントをカスタマイズすることもできますが、SQL Managed Instance のポート番号は変更したりカスタマイズしたりできません。
• マネージド インスタンスをホストするサブネットと SQL Server の IP アドレス範囲が、重複していてはなりません。

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

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

許可リストに追加する必要があるリソースの一覧を次に示します。

• SQL Managed Instance の完全修飾ドメイン名 (FQDN)。 例: managedinstance1.6d710bcf372b.database.windows.net。
• Microsoft Entra 機関
• Microsoft Entra エンドポイントのリソース ID
• Resource Manager エンドポイント
• サービス エンドポイント

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

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

リンクが機能するためには、SQL Server と SQL Managed Instance との間に、双方向のネットワーク接続が必要です。 SQL Server 側でポートを開き、SQL Managed Instance 側で NSG ルールを構成したら、SQL Server Management Studio (SSMS) または Transact-SQL を使用して接続をテストします。

SSMS

SSMS で SQL Server と SQL Managed Instance の間のネットワーク接続をテストするには、次の手順に従います。

1. SSMS でプライマリ レプリカとなるインスタンスに接続します。

2. オブジェクト エクスプローラーで、データベースを展開し、セカンダリにリンクするデータベースを右クリックします。 [タスク]>Azure SQL Managed Instance リンク>[テスト接続] を選択して、ネットワーク チェッカー ウィザードを開きます。

   

3. ネットワーク チェッカー ウィザードの [概要] ページで [次へ] を選択肢ます。

4. すべての要件が [前提条件] ページで満たされている場合は、[次へ] を選択します。 それ以外の場合は、満たされていない前提条件を解決し、[検証の再実行] を選択します。

5. [ログイン] ページで、[ログイン] を選択して、セカンダリ レプリカになるもう一方のインスタンスに接続します。 [次へ] を選択します。

6. [ネットワーク オプションの指定] ページで詳細を確認し、必要に応じて IP アドレスを指定します。 [次へ] を選択します。

7. [概要] ページで、ウィザードが実行する操作を確認し、[完了] を選択して 2 つのレプリカ間の接続をテストします。

8. [結果] ページを確認して、2 つのレプリカ間に接続が存在することを確認し、[閉じる] を選択して完了します。

T-SQL

T-SQL を使用して接続をテストするには、双方向で接続をチェックする必要があります。 まず、SQL Server から SQL Managed Instance への接続をテストしてから、SQL Managed Instance から SQL Server への接続をテストします。

SQL Server から SQL Managed Instance への接続をテストする

SQL Server で SQL Server Agent を使用して、SQL Server から SQL Managed Instance への接続テストを実行します。

1. SQL Managed Instance に接続し、次のスクリプトを実行して、後で必要になるパラメーターを生成します。

   SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'DnsRecordName'
   
   UNION
   
   SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
   FROM (
       SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
           RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_partitions fp
       INNER JOIN sys.dm_hadr_fabric_replicas fr
           ON fp.partition_id = fr.partition_id
       INNER JOIN sys.dm_hadr_fabric_nodes fn
           ON fr.node_name = fn.node_name
       WHERE service_name LIKE '%ManagedServer%'
           AND replica_role = 2
   ) t1
   LEFT JOIN (
       SELECT value AS Cluster,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE parameter_name = 'ClusterName'
       ) t2
       ON (t1.JoinCol = t2.JoinCol)
   INNER JOIN (
       SELECT [value] AS AppName
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE section_name = 'SQL'
           AND parameter_name = 'InstanceName'
       ) t3
       ON (t1.AppName = t3.AppName)
   
   UNION
   
   SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'HadrPort';
   

   結果は次の例のようになります。

   

   結果を保存し、次の手順に使用します。 これらのパラメーターはフェールオーバー後に変更される可能性があるため、必要に応じて再度生成してください。

2. SQL Server に接続します。

3. 新しいクエリ ウィンドウを開き、次のスクリプトを貼り付けます。

   --START
   -- Parameters section
   DECLARE @node NVARCHAR(512) = N''
   DECLARE @port NVARCHAR(512) = N''
   DECLARE @serverName NVARCHAR(512) = N''
   
   --Script section
   IF EXISTS (
           SELECT job_id
           FROM msdb.dbo.sysjobs_view
           WHERE name = N'TestMILinkConnection'
           )
       EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
           @delete_unused_schedule = 1
   
   DECLARE @jobId BINARY (16),
       @cmd NVARCHAR(MAX)
   
   EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
       @enabled = 1,
       @job_id = @jobId OUTPUT
   
   SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test Port 5022',
       @step_id = 1,
       @cmdexec_success_code = 0,
       @on_success_action = 3,
       @on_fail_action = 3,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test HADR Port',
       @step_id = 2,
       @cmdexec_success_code = 0,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
       @server_name = N'(local)'
   GO
   
   EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
   GO
   
   --Check status every 5 seconds
   DECLARE @RunStatus INT
   
   SET @RunStatus = 10
   
   WHILE (@RunStatus >= 4)
   BEGIN
       SELECT DISTINCT @RunStatus = run_status
       FROM [msdb].[dbo].[sysjobhistory] JH
       INNER JOIN [msdb].[dbo].[sysjobs] J
           ON JH.job_id = J.job_id
       WHERE J.name = N'TestMILinkConnection'
           AND step_id = 0
   
       WAITFOR DELAY '00:00:05';
   END
   
   --Get logs once job completes
   SELECT [step_name],
       SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
       SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
       [run_status],
       [run_duration],
       [message]
   FROM [msdb].[dbo].[sysjobhistory] JH
   INNER JOIN [msdb].[dbo].[sysjobs] J
       ON JH.job_id = J.job_id
   WHERE J.name = N'TestMILinkConnection'
       AND step_id <> 0
       --END
   

4. @node、@port、および @serverName のパラメーターを、最初の手順で取得した値に置き換えます。

5. スクリプトを実行し、結果を確認します。 次の例のような結果が表示されるはずです。

   

6. 結果を確認します。

   • TcpTestSucceeded での各テストの結果は TcpTestSucceeded : True である必要があります。
   • RemoteAddresses は、SQL Managed Instance サブネットの IP 範囲に属している必要があります。

   応答が失敗である場合は、次のネットワーク設定について確認します。

   • ネットワーク ファイアウォール "および" SQL Server ホスト OS (Windows/Linux) ファイアウォールの両方に、SQL Managed Instance の "サブネット IP 範囲" 全体へのトラフィックを許可するルールが存在する。
   • SQL Managed Instance をホストする仮想ネットワークに、ポート 5022 での通信を許可する NSG ルールが存在する。

SQL Managed Instance から SQL Server への接続をテストする

SQL Managed Instance が SQL Server に到達できることを確認するには、最初にテスト エンドポイントを作成します。 次に、SQL Agent を使用して、SQL マネージド インスタンスからポート 5022 で SQL Server に ping する tnc コマンドを使用して PowerShell スクリプトを実行します。

テスト エンドポイントを作成するには、SQL Server に接続して、次の T-SQL スクリプトを実行します。

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

SQL Server エンドポイントがポート 5022 で接続を受信していることを確認するには、次の PowerShell コマンドを SQL Server インスタンスのホスト オペレーティング システムで実行します。

tnc localhost -port 5022

テストが成功すると、TcpTestSucceeded : True と表示されます。 その後、SQL マネージド インスタンスでの SQL Server Agent ジョブの作成へと進んで、SQL マネージド インスタンスからポート 5022 で SQL Server テスト エンドポイントをテストすることができます。

次に、NetHelper という SQL マネージド インスタンスに対して SQL Server Agent ジョブを作成します。それには、SQL マネージド インスタンスに対して次の T-SQL スクリプトを実行します。 置換前のコード:

• SQL マネージド インスタンスからアクセスできる SQL Server の IP アドレスを使用した <SQL_SERVER_IP_ADDRESS>。

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

ヒント

SQL マネージド インスタンスから接続プローブ用に SQL Server の IP アドレスを変更する必要がある場合は、EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' を実行して NetHelper ジョブを削除し、前回のスクリプトを使用して NetHelper ジョブを再作成します。

次に、ジョブの実行に役立つストアド プロシージャ ExecuteNetHelper を作成し、ネットワーク プローブから結果を取得します。 SQL マネージド インスタンスで次の T-SQL スクリプトを実行します。

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

SQL マネージド インスタンスで次のクエリを実行します。これにより、NetHelper エージェント ジョブを実行して結果のログを表示するストアド プロシージャが実行されます。

-- Run on managed instance
EXEC ExecuteNetHelper;

接続が成功すると、ログに True が表示されます。 接続が失敗すると、ログに False が表示されます。

接続が失敗である場合は、以下の項目について確認します。

• ホスト SQL Server インスタンス上のファイアウォールで、ポート 5022 での受信および送信の通信が許可されている。
• SQL Managed Instance をホストする仮想ネットワークの NSG ルールで、ポート 5022 での通信が許可されている。
• SQL Server インスタンスが Azure VM 上にある場合、NSG ルールで、VM をホストする仮想ネットワークのポート 5022 での通信が許可されている。
• SQL Server が実行中である。
• SQL Server にテスト エンドポイントが存在している。

問題を解決したら、マネージド インスタンス上で EXEC ExecuteNetHelper を実行して NetHelper ネットワーク プローブを再実行します。

最後に、ネットワークのテストが成功したら、次の T-SQL コマンドを使用して、SQL Server のテスト エンドポイントと証明書を削除します。

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

注意事項

次の手順に進むのは、ソース環境とターゲット環境の間のネットワーク接続を検証済みの場合だけにしてください。 それ以外の場合は、進める前に、ネットワーク接続の問題のトラブルシューティングを行ってください。

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

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

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

SSMS のインストールする

SQL Server Management Studio (SSMS) は、Managed Instance のリンクを使用する最も簡単な方法です。 SSMS バージョン 19.0 以降をダウンロードして、クライアント コンピューターにインストールします。

インストールが終了したら、SSMS を開き、サポートされている SQL Server インスタンスに接続します。 ユーザー データベースを右クリックし、メニューに [Azure SQL Managed Instance リンク] オプションが表示されることを確認します。

政府クラウド用に SSMS を構成する

SQL Managed Instance を政府機関向けクラウド用にデプロイする場合は、正しいクラウドを使うように SQL Server Management Studio (SSMS) 設定を変更する必要があります。 SQL Managed Instance を政府機関向けクラウドにデプロイしない場合は、このステップをスキップしてください。

SSMS の設定を更新するには、次の手順のようにします。

1. SSMS を開きます。
2. メニューから [ツール] を選んだ後、[オプション] を選びます。
3. [Azure サービス] を展開して、[Azure Cloud] を選びます。
4. [Azure クラウドの選択] で、ドロップダウン リストを使って AzureUSGovernment または別の政府機関クラウド (AzureChinaCloud など) を選びます。

パブリック クラウドに戻る場合は、ドロップダウン リストから [AzureCloud] を選びます。

関連するコンテンツ

• Managed Instance のリンク機能の概要
• SSMS を使用して SQL Server と SQL Managed Instance の間のリンクを構成する
• スクリプトを使用して SQL Server と SQL Managed Instance の間のリンクを構成する