このエントリは2021/08/30現在の情報に基づいています。将来の機能追加や変更に伴い、記載内容との乖離が発生する可能性があります。
問い合わせ
例によって以下のような問い合わせを受けた。
現在ロードバランサーで負荷分散しているシステムがあり、そのロードバランサーの背後には仮想マシン (VM) が2台ある。事業継続および災害対策 (BCDR / business continuity & disaster recovery) のために、Azure Site Recovery (ASR) を使ってこのシステムを別リージョンに移動させたいのだが、構成してみたところ、「Site Recovery の構成に失敗しました (151196) 」のエラーが出てうまくいかない。原因は何か？解決方法があるか？
なんとも漠とした問い合わせだったので、さらに突っ込んで聞いてみた。
- ロードバランサーはAzure Load BalancerのStandard SKUを利用
- オンプレミスからのAzureへの接続はExpressRouteを利用、強制トンネリングを構成済み
- VMではTable Storageをデータソースとして使う、とあるアプリケーションが動作している。Table Storageとの間はService Endpointを既に構成済みである。
- 両VMノード間でステートを共有することはないので、単純にVMをリージョン移行できればよい。
図にすると、以下のような感じらしい。
なお、オンプレミスから最初に接続できるVNetはHubネットワークではないため、以下のドキュメントにあるようなExpressRouteとSite Recoveryの統合は利用しない。
ExpressRoute を Azure VM のディザスター リカバリーと統合する / Integrate ExpressRoute with disaster recovery for Azure VMs
https://docs.microsoft.com/azure/site-recovery/azure-vm-disaster-recovery-with-expressroute
原因
勘のいい方、慣れてらっしゃる方はすぐにわかったかもしれない。直接の原因は以下。
- Standard Load Balancerの背後からは、VNet外のサービスにアクセスできないが、VNet外に出るための構成がされていなかった（強制トンネリングはStandard Load Balancerの背後では効果がない）。
ドキュメントにも以下のように記載がある。
VM が Standard 内部ロード バランサーの背後にある場合、既定では、
login.microsoftonline.comなどの Microsoft 365 IP にアクセスすることはできません。 記事「Azure CLI を使用して Standard Load Balancer の負荷分散規則とアウトバウンド規則を構成する」の説明に従って、内部ロード バランサーの種類を Basic に変更するか、発信アクセスを作成します。If the VMs are behind a Standard internal load balancer, by default, it wouldn’t have access to the Microsoft 365 IPs such as
問題 2:Site Recovery の構成に失敗しました (151196) / Issue 2: Site Recovery configuration failed (151196)login.microsoftonline.com. Either change it to Basic internal load balancer type or create outbound access as mentioned in the article Configure load balancing and outbound rules in Standard Load Balancer using Azure CLI.
ASRでは login.microsoftonline.com などのAzure Active Direcoryのサービスなどにアクセスできる必要があるが、この通信ができていなかったために、エラーが発生していた。強制トンネリングは、デフォルトゲートウェイがオンプレミスを向くように構成（今回の場合、オンプレミス側から0.0.0.0/0のルートが広報されている）することであるが、これはStandard Load Balancerの背後にあるVMには効果がない。
必要な送信接続
以下のドキュメントにある通り、Site Recovery レプリケーションを動作させるには、VM から特定の URL または IP 範囲への送信接続が必要である（下表は商用環境のFQDN）。
Azure 間の VM ネットワーク接続の問題のトラブルシューティング / Troubleshoot Azure-to-Azure VM network connectivity issues
https://docs.microsoft.com/azure/site-recovery/azure-to-azure-troubleshoot-network-connectivity
| Storage | *.blob.core.windows.net |
| Azure Active Directory | login.microsoftonline.com |
| Replication | *.hypervrecoverymanager.windowsazure.com |
| Service Bus | *.servicebus.windows.net |
対策
原因を取り除き、送信接続を許可して、所望の動作をさせるには、以下のような選択肢がある。
- Standard Load BalancerをBasic Load Balancerに変更する
- Standard Load Balancerの背後のVMにPublic IPを割り当てる
- Standard Load Balancerの背後のVMが属するSubnetにNAT Gatewayを割り付ける
- Public Load Balancerを追加し、VMからのアウトバウンドルールを構成する
- Azure Firewallを立てて、VMが属するSubnetに対し、インターネットへのルートを全てAzure Firewallに向けたUDRを設定する
- Standard Load Balancerの背後のVMが属するSubnetにService EndpointやPrivate Endpointを配置して、アクセスが必要なサービスへの経路を開く
外向けの通信を実現するためにいろいろな手段があるので、それぞれの特長を確認しておく。
1. Standard Load BalancerをBasic Load Balancerに変更する
Standard Load Balancerを、Load Balancer背後のVMからもVNet外のサービスにアクセスできる、という特性を持つBasic Load Balancerに置き換えるというもの。
強制トンネリングを使っているこの条件では、この方法には以下のような問題がある。
- Azure VNetからの通信すら一度インターネットに出て、再度Azureネットワークに入るため、Outbound trafficの費用がかかる（お財布に優しくない）。
- ストレージのレプリケーショントラフィックもAzureネットワークの外に出てしまうが、これは推奨されない。
強制トンネリング / Forced tunneling
https://docs.microsoft.com/azure/site-recovery/azure-to-azure-about-networking#forced-tunneling
VNetからMicrosoftネットワークに直接出ることができる条件下であれば、トラフィックは全てMicrosoftネットワーク内を通過するが、今回は強制トンネリングを使っているため、必ずインターネットに出てしまう。そのため、ストレージレプリケーションの推奨事項に反するためおすすめできない。
2. Standard Load Balancerの背後のVMにPublic IPを割り当てる
VMにそれぞれPublic IPを割り当てて、直接外に出られるようにしてあげよう、というもの。
この方法をとる場合、以下の構成を確実にしなければならない。
- Public IPを各VMノードに割り当てるため、NSG (Network Security Group) を適切に構成し、Inbound、Outboundの通信を適切に管理する必要がある。
- NSGはNICでもSubnetでも構成できるが、この例の場合はSubnetでまとめて管理するほうが管理性がよい。
なお、Azureサービスとの通信は全てMicrosoftネットワーク内での通信なので、インターネットに出ることはない。
3. Standard Load Balancerの背後のVMが属するSubnetにNAT Gatewayを割り付ける
VMにPublic IPをそれぞれ割り当てるのではなく、SubnetにNAT Gatewayを構成し、外向けの通信をNAT Gatewayからアクセスできるようにしよう、というもの。
NAT Gatewayの場合、Inbound通信は受け付けないので、構成の面ではVMへのPublic IP割り当てに比べると簡単ではある。また、Azureサービスとの通信は全てMicrosoftネットワーク内での通信なので、インターネットに出ることはない。
4. Public Load Balancerを追加し、VMからのアウトバウンドルールを構成する
Public Load Balancerを別途立て、Outboundルールを構成してVMノードからのOutbound通信を許可しよう、というもの。
2、3とやっていることは同じではあるが、構成コンポーネントトータルで見ると、ここまででいちばんお財布に優しくはない。これも、Azureサービスとの通信は全てMicrosoftネットワーク内での通信なので、インターネットに出ることはない。
5. Azure Firewallを立てて、インターネットへのルートを全てAzure Firewallに向けたUDRをVMが属するSubnetに設定する
VM Subnetにて、0.0.0.0/0へのルートをUDR (User Defined Route) を使ってFirewallに向け、FirewallではInbound/Outboundの通信を管理する、というもの。
NSGでもサービスタグを利用してInbound/Outbound通信の管理が可能ではあるが、Firewallを使うと、NSGでは不可能なFQDNでのアクセス管理が可能なので、管理性は向上する。 これも、Azureサービスとの通信は全てMicrosoftネットワーク内での通信なので、インターネットに出ることはない。
ただ、今回例示した選択肢の中で一番お高いコースであり、お財布に最も優しくない。。。
6. Standard Load Balancerの背後のVMが属するSubnetにService EndpointやPrivate Endpointを配置して、アクセスが必要なサービスへの経路を開く
VMやSubnetにPublic IPを割り当てるのではなく、Azureのサービスを使って、ASRで必要なサービスにセキュアにアクセスできる経路を付けよう、というもの。
Private Endpoint/Linkを使う構成は以下のドキュメントに記載がある。
プライベート エンドポイントを使用してマシンをレプリケートする / Replicate machines with private endpoints
https://docs.microsoft.com/azure/site-recovery/azure-to-azure-how-to-enable-replication-private-endpoints
今回Private Endpoint/LinkやService Endpointを構成する必要があるのは以下の通り。
- Service Endpointのみ可
- Azure Active Directory
- Service EndpointとPrivate Endpointいずれも可
- Storage Service
- Service Bus （とはいえ宛先が決まっていないので実質Service Endpointのみ）
- Private Endpointのみ可
- Recovery Service Container
Microsoftネットワーク内を通過してインターネットには出ないこと、Public IPを付ける必要がないこと、トラフィックはセキュアに保たれること、そしてFirewallを立てるよりはずっとお財布に優しいことを考慮すると、ある意味「安心できる構成」である。
構成上の注意点は以下。
- 構成時にリカバリーコンテナーのManaged Identityに対して権限を付与する際に、Cache Storageとして使うストレージアカウントの種類（StandardかPremiumか）によって、付与すべき権限が違う
- 上記ドキュメントでは、Cache Storageへの通信はインターネットアクセスやPrivate Endpointを構成する前提であるが、今回の場合、Standard Load Balancerの背後からのアクセスになるので、Private Endpointを構成するか、もしくはSubnetにStorageへのService Endpointを構成しておく必要がある（この例ではすでにService Endpointが構成済みなのでそれを利用）。
前者については、Resource Managerベースの環境では以下のような違いがある。
| ストレージのSKU | 付与すべき権限（ロール） |
|---|---|
| Standard | Contributor ストレージ BLOB データ共同作成者 / Storage BLOB Data Contributor |
| Premium | Contributor ストレージ BLOB データ所有者 / Storage BLOB Data Owner |
まとめ
それぞれの方法の特長をまとめると以下のよう。
| 方法 | トラフィックがMicrosoftネットワークで | Azure側でPublic IPは | コスト | 構成のポイント | 備考 |
|---|---|---|---|---|---|
| 1 | 完結しない場合がある | 不要 | 通信コストが高くなる場合がある | オンプレミスのFirewallルール (管理部署が違う場合は要請しなければならない) | 強制トンネリング時、ストレージのレプリケーショントラフィックがインターネットに出てしまう |
| 2 | 完結する | 必要 | NSGの構成 (Inbound/Outbound) | ||
| 3 | 完結する | 必要 | NSGの構成 (Outbound) | ||
| 4 | 完結する | 必要 | Public Load Balancer (Outboundルール) | ||
| 5 | 完結する | 必要 | 高（Firewall） | UDR Firewallルール | |
| 6 | 完結する | 不要 | リカバリーコンテナーのManaged Identityへの権限付与 |
この問い合わせ主に上記の内容を説明し、それぞれのコスト感を伝えて選択を任せた結果、6のPrivate Endpoint/Link + Service Endpointの案でASRを構成したようである。
Logico Inside 