次の方法で共有

Azure SQL Managed Instance の接続アーキテクチャ

  • [アーティクル]

適用対象: Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance の接続アーキテクチャと、コンポーネントからマネージド インスタンスに通信トラフィックがどのように転送されるかについて説明します。

概要

SQL Managed Instance のインスタンスは、マネージド インスタンス専用の Azure Virtual Network 内とサブネット内に配置されます。 このデプロイでは、以下が提供されます。

  • セキュリティで保護された Virtual Network ローカル (VNet ローカル) IP アドレス。
  • オンプレミス ネットワークを SQL Managed Instance に接続する機能。
  • SQL Managed Instance をリンク サーバーまたは別のオンプレミス データ ストアに接続する機能。
  • SQL Managed Instance を Azure リソースに接続する機能。

接続アーキテクチャの概要

SQL Managed Instance は、仮想クラスターと類似の構成属性でグループ化され参加している分離された一連の専用仮想マシン上でホストされるサービス コンポーネントで構成されています。 サービス コンポーネントには、お客様の Virtual Network サブネット内にデプロイされるものもあれば、Microsoft が管理するセキュリティで保護されたネットワーク環境で動作するものもあります。

2022 年 11 月以降の Azure SQL Managed Instance の接続アーキテクチャの概要を示す図。

お客様のアプリケーションは、SQL Managed Instance に接続できます。また、クエリを実行して、仮想ネットワーク、ピアリングされた仮想ネットワーク、または VPN か Azure ExpressRoute によって接続されたネットワーク内のデータベースを更新できます。

次の図は、SQL Managed Instance に接続するエンティティを示しています。 マネージド インスタンスと通信するために必要なリソースも示されています。 図の一番下にある通信プロセスは、SQL Managed Instance にデータ ソースとして接続するお客様のアプリケーションとツールを表しています。

2022 年 11 月以降の Azure SQL Managed Instance の接続アーキテクチャのエンティティを示す図。

SQL Managed Instance は、データ プレーンとコントロール プレーンという 2 つのプレーンで動作する、シングルテナントのサービスとしてのプラットフォーム オファリングです。

"データ プレーン" は、互換性、接続、ネットワーク分離のため、お客様のサブネット内にデプロイされます。 データ プレーンは、Azure Storage、認証のためのMicrosoft Entra ID (旧称 Azure Active Directory)、テレメトリ収集サービスなどの Azure サービスに依存します。 SQL Managed Instance を含むサブネットからそれらのサービスに向かって送信されるトラフィックが表示されます。

"コントロール プレーン" には、自動化されたエージェントを介したデプロイ、管理、コア サービス メンテナンスの機能が用意されています。 これらのエージェントは、サービスを運用するコンピューティング リソースに排他的にアクセスできます。 ssh またはリモート デスクトップ プロトコルを使ってこれらのホストにアクセスすることはできません。 コントロール プレーンの通信はすべて暗号化され、証明書を使って署名されます。 通信相手の信頼性を確認するために、SQL Managed Instance では、証明書失効一覧を使ってこれらの証明書が確認されます。

通信の概要

アプリケーションは、3 種類のエンドポイントを経由して SQL Managed Instance に接続できます。 これらのエンドポイントは対応するシナリオが異なり、ネットワーク特性や動作も異なります。

Azure SQL Managed Instance に対する VNet ローカル、パブリック、プライベート エンドポイントの表示範囲を示す図。

VNet ローカル エンドポイント

VNet ローカル エンドポイントは、SQL Managed Instance に接続するための既定の手段です。 VNet ローカル エンドポイントは、サブネットのアドレス プールにある (したがって VNet ローカルの) IP アドレスまたは仮想ネットワークにローカルなエンドポイントに解決される、<mi_name>.<dns_zone>.database.windows.net という形式のドメイン名です。 VNet ローカル エンドポイントを使用して、すべての標準接続シナリオで SQL マネージド インスタンスを接続できます。

VNet ローカル エンドポイントは、プロキシ接続の種類とリダイレクト接続の種類の両方をサポートしています。

VNet ローカル エンドポイントに接続する場合、基となる IP アドレスが変わることがあるため、常にそのドメイン名を使います。

パブリック エンドポイント

パブリック エンドポイントは、インターネットから到達可能なパブリック IP アドレスに解決される、<mi_name>.public.<dns_zone>.database.windows.net という形式の省略可能なドメイン名です。 パブリック エンドポイントの場合、ポート 3342 上の TDS トラフィックのみが SQL Managed Instance に到達できます。統合シナリオ (フェールオーバー グループ、Managed Instance リンク、他の同様のテクノロジなど) には使用できません。

パブリック エンドポイントに接続する場合、基となる IP アドレスが変わることがあるため、常にそのドメイン名を使います。

パブリック エンドポイントでは、接続の種類の設定に関係なく、常にプロキシ接続の種類が使用されます。

パブリック エンドポイントの設定方法については、「Azure SQL Managed Instance のパブリック エンドポイントを構成する」を参照してください。

プライベート エンドポイント

プライベート エンドポイントは、現在 Azure SQL Managed Instance へのトラフィックを実施する別の Virtual Network 内にあるオプションの固定 IP アドレスです。 1 つの Azure SQL Managed Instance は、複数の仮想ネットワークに複数のプライベート エンドポイントを持つことができます。 プライベート エンドポイントの場合、ポート 1433 上の TDS トラフィックのみが SQL Managed Instance に到達できます。統合シナリオ (フェールオーバー グループ、Managed Instance リンク、他の同様のテクノロジなど) には使用できません。

プライベート エンドポイントに接続する場合、IP アドレス経由で Azure SQL Managed Instance に接続することはサポートされていないため、常にドメイン名を使用します。

プライベート エンドポイントでは、接続の種類の設定に関係なく、常にプロキシ接続の種類が使用されます。

プライベート エンドポイントの詳細と構成方法については、「Azure Private Link for Azure SQL Managed Instance」で説明します。

仮想クラスターの接続アーキテクチャ

次の図は、仮想クラスター アーキテクチャの概念上のレイアウトを示しています。

Azure SQL Managed Instance の仮想クラスター接続アーキテクチャを示す図。

VNet ローカル エンドポイントのドメイン名は、内部ロード バランサーのプライベート IP アドレスに解決されます。 このドメイン名はパブリック ドメイン ネーム システム (DNS) ゾーンに登録されており、パブリックに解決できますが、その IP アドレスはサブネットのアドレス範囲に属し、既定ではその仮想ネットワークの内部からのみ到達できます。

ロード バランサーは、SQL Managed Instance のゲートウェイにトラフィックを送信します。 同じクラスター内で複数の Managed Instance を実行できるため、ゲートウェイは、接続文字列の内容どおりに、SQL Managed Instance のホスト名を使って、トラフィックを適切な SQL Engine サービスにリダイレクトします。

クラスターを作成すると、dns-zone の値が自動的に生成されます。 新しく作成されたクラスターで 2 番目のマネージド インスタンスがホストされる場合は、プライマリ クラスターとゾーン ID が共有されます。

ネットワークの要件

Azure SQL Managed Instance では、委任されたサブネットのアスペクトを特定の方法で構成する必要があります。これは、サービス支援サブネット構成を使用して実現できます。 ユーザーは、サービスに必要なもの以外に、サブネット ネットワーク構成を次のように完全に制御できます。

  • 一部またはすべてのポートでトラフィックを許可またはブロックする
  • ルート テーブルにエントリを追加して、仮想ネットワーク アプライアンスまたはゲートウェイ経由でトラフィックをルーティングする
  • カスタム DNS 解決を構成する
  • ピアリングまたは VPN を設定する

SQL Managed Instance がデプロイされるサブネットは、次の要件を満たしている必要があります。

  • 専用サブネット: SQL Managed Instance に使われるサブネットは、SQL Managed Instance サービスのみに委任できます。 このサブネットはゲートウェイ サブネットにすることはできません。このサブネットには SQL Managed Instance リソースのみをデプロイできます。
  • サブネットの委任: SQL Managed Instance のサブネットは Microsoft.Sql/managedInstances リソース プロバイダーに委任する必要があります。
  • ネットワーク セキュリティ グループ: ネットワーク セキュリティ グループは SQL Managed Instance サブネットに関連付けする必要があります。 SQL Managed Instance がリダイレクト接続用に構成されている場合は、ネットワーク セキュリティ グループを使ってポート 1433 およびポート 11000 から 11999 上のトラフィックをフィルター処理することで、SQL Managed Instance のデータ エンドポイントへのアクセスを制御できます。 管理トラフィックのフローが中断されないように、サービスにより、必要に応じて規則が自動的にプロビジョニングされ、最新の状態が保たれます。
  • ルート テーブル: ルート テーブルは SQL Managed Instance サブネットに関連付けられている必要があります。 このルート テーブルにエントリを追加できます。たとえば、仮想ネットワーク ゲートウェイ経由でトラフィックをオンプレミスにルーティングしたり、ファイアウォールなどの仮想ネットワーク アプライアンスを介して送信する既定の 0.0.0.0/0 ルートを追加したりできます。 Azure SQL Managed Instance は、ルート テーブル内の必要なエントリを自動的にプロビジョニングおよび管理します。
  • 十分な IP アドレス: SQL Managed Instance サブネットには、少なくとも 32 個の IP アドレスが必要です。 詳細については、SQL Managed Instance 用のサブネットのサイズの決定に関する記事を参照してください。 SQL Managed Instance のネットワーク要件を満たすように既存のネットワークを構成した後、そのネットワークに Managed Instance をデプロイできます。 それ以外の場合は、新しいネットワークとサブネットを作成します。
  • Azure のポリシーで許可する:Azure Policy を使って SQL Managed Instance サブネットまたは仮想ネットワークを含むスコープ内のリソースの作成または変更を防ぐ場合、そのようなポリシーで SQL Managed Instance による内部リソースの管理を妨げてはなりません。 正常な動作のために、次のリソースをポリシーの拒否効果から除外する必要があります。
    • リソース名が \_e41f87a2\_ で始まる場合、種類 Microsoft.Network/serviceEndpointPolicies のリソース
    • 種類 Microsoft.Network/networkIntentPolicies のすべてのリソース
    • 種類 Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies のすべてのリソース
  • 仮想ネットワーク上のロック: 専用サブネットの仮想ネットワーク、その親リソース グループ、またはサブスクリプションに対するロックによって、SQL Managed Instance の管理とメンテナンスの操作が妨げられる可能性があります。 リソースのロックを使う場合は、特に注意してください。
  • レプリケーション トラフィック: 2 つの Managed Instance 間のフェールオーバー グループのレプリケーション トラフィックは、ハブ ネットワーク経由でルーティングするのではなく、直接やり取りするようにします。
  • カスタム DNS サーバー: 仮想ネットワークがカスタム DNS サーバーを使うように構成されている場合、その DNS サーバーはパブリック DNS レコードを解決できる必要があります。 Microsoft Entra 認証などの機能を使うには、さらに完全修飾ドメイン名 (FQDN) 解決が必要になる可能性があります。 詳細については、Azure SQL Managed Instance でのプライベート DNS 名の解決に関する記事をご覧ください。

サービス支援サブネット構成

サービスのセキュリティ、管理容易性、可用性を向上させるために、SQL Managed Instance では、Azure 仮想ネットワーク インフラストラクチャのサービス支援サブネット構成とネットワーク インテント ポリシーを使用して、SQL Managed Instance の最小要件が満たされるようにネットワーク、関連コンポーネント、ルート テーブルを構成します。

自動的に構成されたネットワーク セキュリティとルート テーブル ルールは、お客様に表示され、次のいずれかのプレフィックスで注釈が付けられます。

  • 必須のルールとルートの場合、Microsoft.Sql-managedInstances_UseOnly_mi-
  • オプションのルールとルートの場合、Microsoft.Sql-managedInstances_UseOnly_mi-optional-

詳細については、「サービス支援サブネット構成」を確認してください。

接続アーキテクチャと管理トラフィックの詳細については、「接続アーキテクチャの概要」を参照してください。

ネットワークの制約

  • 送信接続には TLS 1.2 が適用されます: 2020 年 1 月以降、Microsoft はすべての Azure サービスのサービス内トラフィックに TLS 1.2 を適用しています。 その結果、SQL Managed Instance については、SQL Server へのレプリケーションとリンク サーバー接続に使われる送信接続に対して、TLS 1.2 が適用されることになりました。 SQL Managed Instance で 2016 より前のバージョンの SQL Server を使っている場合は、必ず TLS 1.2 固有の更新プログラムを適用してください。

現在、SQL Managed Instance では、次の仮想ネットワーク機能は "サポートされていません"。

  • プライベート サブネット: プライベート サブネットに Managed Instance を配置する (デフォルトの送信アクセスが無効になっている) は現在サポートされていません。
  • ポート 25 の外部 SMTP リレーへのデータベース メール: ポート 25 を介した外部電子メール サービスへのデータベース メールの送信は、Microsoft Azure の特定のサブスクリプションの種類でのみ使用できます。 他のサブスクリプションの種類のインスタンスは、外部 SMTP リレーに接続するために別のポート (587 など) を使用する必要があります。 そうしないと、インスタンスがデータベース メールの配信に失敗する可能性があります。 詳細については、Azure でのアウトバウンド SMTP 接続問題のトラブルシューティングに関するページを参照してください。
  • Microsoft ピアリング: SQL Managed Instance が存在する仮想ネットワークと直接または推移的にピアリングされた ExpressRoute 回線で Microsoft ピアリングを有効にすると、仮想ネットワーク内の SQL Managed Instance コンポーネント間のトラフィック フローと、それに依存するサービスに影響が及びます。 結果として可用性の問題が生じます。 Microsoft ピアリングが既に有効になっている仮想ネットワークへの SQL Managed Instance デプロイは、失敗することが予想されます。
  • 仮想ネットワーク ピアリング – グローバル: Azure リージョン間での仮想ネットワーク ピアリング接続は、2020 年 9 月 9 日より前に作成されてサブネットに配置された SQL Managed Instance のインスタンスでは機能しません。
  • 仮想ネットワーク ピアリング – 構成: SQL Managed Instance を含むサブネットを含む仮想ネットワーク間で仮想ネットワーク ピアリングを確立する場合、このようなサブネットでは、異なるルート テーブルとネットワーク セキュリティ グループ (NSG) を使用する必要があります。 仮想ネットワーク ピアリングに参加している 2 つ以上のサブネットでルート テーブルと NSG を再利用すると、それらのルート テーブルまたは NSG を使用するすべてのサブネットで接続の問題が発生し、SQL Managed Instance の管理操作が失敗します。
  • AzurePlatformDNS タグ: AzurePlatformDNS サービス タグを使用して、SQL Managed Instance を使用できなくする可能性があるプラットフォーム DNS 解決をブロックします。 SQL Managed Instance では、エンジン内部の DNS 解決にお客様による定義の DNS がサポートされていますが、プラットフォームの操作については、プラットフォーム DNS への依存性があります。
  • NAT ゲートウェイ: Azure Virtual Network NAT を使って、特定のパブリック IP アドレスでの送信接続を制御すると、SQL Managed Instance をレンダリングできなくなります。 現時点では、SQL Managed Instance サービスは基本的なロード バランサーの使用に制限されており、Azure Virtual Network NAT を使った受信フローと送信フローを同時に実行することができません。
  • Azure Virtual Network の IPv6:SQL Managed Instance はデュアル スタックの IPv4 または IPv6 仮想ネットワークにデプロイできないことが予想されています。 ネットワーク セキュリティ グループまたはルート テーブルを、SQL Managed Instance サブネットへの IPv6 アドレス プレフィックスを含むユーザー定義ルート (UDR) に関連付けると、SQL Managed Instance は利用不可と表示されます。 また、Managed Instance サブネットに関連付けられているネットワーク セキュリティ グループまたは UDR に IPv6 アドレス プレフィックスを追加すると、SQL Managed Instance は利用不可と表示されます。 既に IPv6 プレフィックスが与えられているネットワーク セキュリティ グループと UDR を含むサブネットに SQL Managed Instance はデプロイできないことが想定されます。
  • 予約済み Microsoft サービスの DNS レコード: 次に示すドメイン名は予約されており、その解決は Azure DNS で定義されています。Managed Instance をホストする Virtual Network 内でオーバーライドすることはできません。windows.net、database.windows.net、core.windows.net、blob.core.windows.net、table.core.windows.net、management.core.windows.net、monitoring.core.windows.net、queue.core.windows.net、graph.windows.net、login.microsoftonline.com、login.windows.net、servicebus.windows.net、vault.azure.net 1 つ以上のドメイン名がオーバーライドされる Virtual Network に SQL Managed Instance をデプロイすると、Azure DNS Private Zones またはカスタム DNS サーバーによって失敗します。 Managed Instance を含む Virtual Network 内のこれらのドメインの解決をオーバーライドすると、その Managed Instance は使用できなくなります。 Managed Instance を含む Virtual Network 内で Private Link DNS レコードを構成する方法については、「Azure プライベート エンドポイント DNS 構成」を参照してください。

関連するコンテンツ