Global VNet Peeringを理解するための前提
Global VNet Peeringは異なるregionのVNet間private connectivityをMicrosoft backbone上で提供する。 local peeringと同様にpeeringはnontransitiveで、hubを跨ぐspoke transitは別設計が必要。
cross-region pathはapplication latencyとdata transfer costの両方へ影響する。 multi-region hubではregional firewall/gateway/DNS等のfailure domainを明示し、どのregionでinspectionするかを決める。
gateway transit等のsupported combinationはlocal peeringと同じ用語でもregion/sku/architecture条件をcurrent docsで確認する。 DRではpeering stateだけでなくDNS failover、route convergence、stateful firewall sessionをapplication testで確認する。
Control plane と data plane
仕組み
source regionのVNetからdestination prefixへpeering routeが選択され、trafficはAzure backboneでremote regionへ運ばれる。
cross-region central NVAへ迂回させる場合、application path lengthとreturn symmetryが変わる。
active-active regionでは両regionのshared-service reachabilityを持たせつつ、正常時のpreferred pathとfailure時のalternate pathを明示する。
Packet path
routing問題は「どのresourceがあるか」ではなく、packetが各hopで何を選ぶかを順に追う。
- source workloadがremote VNet IPを宛先に送信。
- effective routeでVirtualNetworkPeering next hopを選択。
- Microsoft backboneでregion間転送。
- remote VNet security/routingでdestinationへ配送。
- responseはremote側のroute selectionに従って戻るため、inspectionを挟む場合はsymmetry確認。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Regional autonomy | 可能ならregion内でingress/egress/shared serviceを完結。 | cross-region dependencyのblast radiusを減らす。 |
| DR path | normalとfailure pathをroute matrixにする。 | peeringだけではapplication failoverを保証しない。 |
| Cost/latency | chatty workloadはtraffic volumeとRTTを実測。 | network cost/performanceがarchitecture選択に直結。 |
| Inspection | stateful NVAを跨ぐ場合return pathを固定。 | asymmetric routingによるsilent dropを防ぐ。 |
確認手順
Azure Portal
- 両regionのPeering statusとaddress spaceを確認。
- representative VMでeffective routesを取得。
- Connection Monitor等でcross-region latency/reachabilityを継続監視。
Verification discipline
- subscription / resource group / resource IDを記録する。
- 同じsource・destinationでbefore/afterを比較する。
- read-only evidenceを保存してから変更する。
- control-plane successとapplication successを別々に判定する。
az network vnet peering list -g <rg> --vnet-name <vnet> -o table
az network nic show-effective-route-table -g <rg> -n <nic> -o tableGet-AzVirtualNetworkPeering -ResourceGroupName <rg> -VirtualNetworkName <vnet>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| remote regionだけ遅い | cross-region RTT/inspection detour | Connection Monitor + effective route | pathをregion内へ寄せる/architecture再検討 |
| failover時のみ不達 | DNS/route/firewall policy同期不足 | failure test evidence | regional dependencyを個別検証 |
| spoke間が通らない | nontransitive | effective routes | transit service/UDR設計 |
| 新prefixだけ不達 | peering sync漏れ | peering/effective route | address space sync |
変更時の確認と rollback
- change前にnormal path/backup pathのRTTとroute snapshotを保存。
- region間route変更はapplication ownerとfailure testを合意。
- rollback後にDNS/cacheとstateful sessionを含めend-to-end再試験。