本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance (MI) について色々と情報を発信していきたいと思います。
最初のポイントとしては MI を配置する仮想ネットワークについて、まとめてみたいかと。
MI は SQL Database と異なり、完全に仮想ネットワーク (VNET) に統合された形で、リソースの作成が行われます。
(SQL Database の VNET 対応は、サービスエンドポイントでの対応となっているため、厳密に VNET と統合されているタイプの環境ではありません)
そのため、MI を作成する際には、配置先の VNET のサブネットを事前に作成しておく必要があります。
VNET はどのようなネットワーク構成でもよいというわけではなく、いくつかの条件があります。
で詳細は解説されているのですが、MI を配置する仮想ネットワークについては、次のような要件があります。
- サブネット内で 16 ～ 256 個の IP アドレスが必要となるため、サブネットは /28 ～ /24 を使用する
- 最大 256 個の IP アドレスを使用する場合がある
- 5 個の IP アドレスについては、Azure が使用する
- 汎用インスタンスでは、インスタンス単位に 2 個の IP アドレスが必要
- 5 + (2 ×インスタンス数) = 必要となる IP アドレス
- サブネットは MI 専用とし、MI 以外のリソースの作成は行わない
- MI のサブネットのサービスエンドポイントは「無効」となっている
- MI サブネットには、「0.0.0.0/0」の Next Hop を「Internet」にするルートテーブルが唯一のルートとして設定されている
- Azure Management Service との通信を行うために必要となるが、Public Preview の要件であり今後変更される予定がある。
- MI のサブネットに、NSG は設定されていない
この要件を満たしているサブネットに MI のデプロイを行います。
MI を配置するサブネットについては、MI 専用とし、他のリソースの配置は行わないことと、次の画像のような 0.0.0.0/0 , Next Hop : Internet のルートテーブルを MI のサブネットに割り当てるのがポイントでしょうか。
MI のサブネットについては最低でも、7 個の IP が必要となりますので、サブネット内に展開する MI のインスタンス数に合わせてサブネットのアドレス範囲を調整する必要があります。
MI を単体で構築して済むということはなく、DB にアクセスするアプリケーションについても考量する必要があります。
先ほど書きましたが、「MI を配置するサブネットは、MI 専用にする」必要があります。
そのため、DB に接続を行うアプリケーションについては、次のようなネットワークの配置となります。
- MI が配置されているサブネットの VNET 内の、他のサブネット
- MI が配置されたサブネットの VNET と VNET ピアリングされた、他の VNET
- MI が配置されたサブネットの VNET と、VPN 接続された、他の VNET またはオンプレミスのネットワーク
- グローバル VNET ピアリングが提供されている地域の場合は、こちらで代替可能
- MI が配置された配置されたサブネットの VNET と、Express Route で接続されたオンプレミスのネットワーク
MI は、SQL Database や、SQL Server on Azure VM と異なり、「パブリック IP を持たず、VNET のプライベート IP のみを持つ」インスタンスとなります。
SQL DB / SQL Server on Azure VM では、パブリック IP 経由での接続ができますので、アプリケーションはインターネットに出れる環境であれば、DB を利用することができていました。
しかし、MI の場合は、プライベート IP のみ設定することができ、Azure 標準のロードバランサーの配下に置くということもできませんので、接続するアプリケーションについてもこれを意識したネットワーク構成とする必要があります。
一番シンプルなのが、MI を配置している仮想ネットワーク内に、アプリケーションを配置するサブネットを作成し、そこから接続するパターンでしょうか。
仮想マシンや、Web Apps での接続については次のドキュメントに記載されていますので、配置パターンについてはこれらのドキュメントを確認しておくとよいかと。