Ingite 2020 でアナウンスが行われましたが、「新しく作成した」Azure SQL Managed Instance (MI) に関してはグローバル VNET ピアリングがサポートされるようになります。
- Global virtual network peering support for Azure SQL Managed Instance now available
- What’s new in Azure SQL Managed Instance at Ignite 2020
MI でグローバル VNET ピアリングが必須となる機能としては、フェールオーバーグループがあり、マネージド インスタンスとその VNet の間の geo レプリケーションを有効にする に、次のように記載されています。
SQL Managed Instance のインスタンスによって使用される仮想ネットワークは、VPN Gateway または Express Route 経由で接続されている必要があります。 2 つの仮想ネットワークがオンプレミスのネットワーク経由で接続されている場合、ポート 5022 および 11000-11999 をブロックするファイアウォール規則がないことを確認します。 グローバル VNet ピアリングはサポートされません。
別の VNet 内での接続 / グローバル VNet ピアリングとロード バランサーに関連する制約は何ですか? にも、グローバル VNET ピアリングについての注記があり、こちらについても、本投稿を書いている時点では、グローバル VNET ピアリングの情報の追記が行われていないようですので、これらのドキュメントについては、後日更新されるのではないでしょうか。
フェールオーバーグループは異なるリージョンに作成をする必要があります。
(Geo レプリケーションについては同一のリージョンに作成を行うことができますが、MI は Geo レプリケーションが使えません)
そのため、リージョン間の VNET を接続させる必要があり、Managed Instance でフェールオーバーグループを使用する場合、従来までは、グローバル VNET ピアリングが使用できなかったため、Azure 内のリソース間のデータ同期であっても、VPN 接続をする必要がありました。
しかし、今回のアップデートで、MI でグローバル VNET ピアリングが使用できるようになりましたので、VPN の仮想ネットワークゲートウェイのリソースを作成しなくても、MI のリソースのみで、グローバル VNET ピアリングを設定することができ、フェールオーバーグループを作成することができるようになりました。
次の画像は、「東日本」と「東アジア」で実際にグローバル VNET ピアリングを使用して、フェールオーバーグループを設定したものになります。
仮想ネットワークゲートウェイのリソースを作成しなくても、フェールオーバーグループが設定できていますね。 
MI のグローバル VNET ピアリングはフェールオーバーグループとセットで記載されている情報が、現時点では多そうですが、フェールオバーグループ以外でも活用することができるようで、グローバル VNET ピアリング経由で他のリージョンの VM を MI に接続するということも可能でしたので、今回のアップデートで、リージョンをまたいだ MI への接続性が向上するかと思います。
グローバル VNET ピアリングを使用する際の注意点
グローバル VNET ピアリングを使用する際のポイントとなるのは次の画像です。
MI は ネットワークの要件 が厳しく、本投稿を書いている時点では、「専用のサブネット」に作成する必要があります。
そのため、MI で利用するサブネットは基本的に「空のサブネット」ではあるのですが、上記の画像に書かれているように「Supported in newly created subnets onlly」という条件があります。
「新しく作成した」空のサブネットに対して展開を行った場合に、グローバル VNET ピアリングのサポートが行われ、アナウンス以前に作成していた MI に関してはグローバル VNET ピアリングのサポートは行われません。
SR で問い合わせをしてみたところ、アナウンス以前の環境に構築した環境で試していただくことができ、実環境で、以前に構築した環境ではグローバル VNET ピアリングを使用することができなかったとをご確認いただけました。
なぜ、以前に作成した MI ではグローバル VNET ピアリングが使用できないのか
新しく作成した MI では、グローバル VNET ピアリングが使用できて、以前から作成している MI ではグローバル VNET ピアリングが使用できないのかなぜなのかが気になったので調べてみました。
ポイントとなるのは次のフィードバックのようです。
MI の接続のアーキテクチャは、仮想クラスターの接続アーキテクチャ で解説されている構成となっています。MI をサブネットに展開すると「仮想クラスター」というリソースが作成されます。
同一のサブネットに展開した Managed Instance であれば、同一の仮想クラスター内に作成が行われます。
Azure SQL Managed Instance の管理操作の概要 に記載されていますが、仮想クラスターはサブネットにハードウェア世代単位に構築されますので、同一のハードウェア世代であれば、同一の仮想クラスターに作成され、2 台目以降の MI はデプロイ時間が短縮されるようになっています。
ポイントとなるのは接続アーキテクチャの次の画像です。
仮想クラスターには、Azure のロードバランサーがついており、ロードバランサー経由でインスタンスに接続が行われています。
このロードバランサーが今回のアップデート前までは「Basic Load Balancer 」を使用していたようです。
2019 年に グローバル VNet ピアリングでの Standard Load Balancer のサポート開始 でアナウンスされていますが、現状、Standard Load Balancer であれば、グローバル VNET ピアリングはサポートされていますが、Basic Load Balancer では、現時点でもグローバル VNET ピアリングはサポートされていません。
今回のアップデートでグローバル VNET ピアリングがサポートされたということは、おそらく仮想クラスターで使用している LB が Basic から Standard に変更されたのではないでしょうか。
LB は仮想クラスターに組み込まれていますので、「既存の MI」については初期の構成通り「Basic Load Balancer」が使用され、「空のサブネットに作成して、新規に構築された MI の仮想クラスター」については「Standard Load Balancer」が使用され、VNET ピアリングがサポートされている環境になるのかと思います。
現状、仮想クラスターを再作成するというオプションはないようですので、「グロバール VNET ピアリングをサポートする仮想クラスター」に変更した場合は、新規に作成した MI に対してバックアップをリストアするというような方法で移行を行う必要があるのではないでしょうか。
微妙な時期に MI を作成し、自分が作成した MI がグローバル VNET ピアリングをサポートしているかを確認したい場合は、他のリージョンに VNET を作成し、グローバル VNET ピアリングで接続を行って、他リージョンの VM 等からリージョンをまたいだ MI へのアクセスができるかを確認してみるとよいかと。
接続できなければ、MI の仮想クラスターが、グローバル VNET ピアリングをサポートしていない LB で動作していることになるかと思います。