NVA High Availability

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。

NVA High Availabilityを理解するための前提

MicrosoftのHA guidanceではLoad Balancer、Route Server、Gateway Load Balancer、Dynamic Public IP+UDR等のpatternを比較している。 stateful firewallではtraffic symmetryとsession synchronizationが設計の中心。

availability zone対応regionではNVA instanceを複数zoneへ分散する。 Load Balancer patternはhealth probeでinstance failureを検出し、active/active/standby構成を支援する。

Route Server patternはNVAがBGP対応ならroute injectionを自動化できるが、BGP convergenceとsymmetryを検証する。 Gateway Load Balancerはservice chainingでsymmetryを提供するが、east-west traffic用途には制約がある。

通信や判断の流れを追う

Platform policyShared servicesSpoke / Workload運用・変更

Control plane と data plane

Control planeVM/VMSS NVA、LB/GWLB、Route Server/BGP、UDR、zone配置、health probeがcontrol plane。

Data planepacketはsteering方式に応じてhealthy NVAへ入り、stateful inspection/NAT後にdestinationへ進み、return flowも同一state contextへ戻す必要がある。

仕組みと設計上の意味

HAはinstanceを2台置くだけでは成立せず、failure detection、route convergence、state/symmetry、scale、managementを含む。

vendor cluster機能とAzure-side routing mechanismの責務を分ける。

SNATでsymmetryを作るpatternはclient IP preservationとのtrade-offがある。

NVA upgrade時にsingle-instance状態へ落ちる時間とflow drainをrunbook化する。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

normal時forward/return pathを図示。
1 instance停止時のhealth/convergenceを測定。
stateful session継続/再接続behaviorを確認。
zone failure想定でremaining capacityを確認。
upgrade/rollback時のroute and session impactを確認。

設計判断

判断点	推奨	理由
Load Balancer	probe可能・LB steeringが合うNVA	高速failure detection
Route Server	BGP対応NVA	route automation/scale
GWLB	north-south service chaining	symmetryを確保
Active/passive UDR	vendor制約時の最後の手段	convergence/automation overheadが大きい

確認手順

Azure Portal

NVA instance/zone/power stateを確認。
LB health probe/backend healthまたはRoute Server peer stateを確認。
spoke NIC effective routesでhealthy next hopが選ばれることを確認。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。

Before / After同じsource・destination・protocol・portで比較。

Effective state設定値だけでなくeffective route/security/health/logを取得。

Runtimecontrol-plane Succeededとapplication successを分けて判定。

Azure CLI — read-only first

az network lb show -g <rg> -n <lb> -o jsonc
az network routeserver show -g <rg> -n <route-server> -o jsonc
az network nic show-effective-route-table -g <rg> -n <nic> -o table

PowerShell — read-only first

Get-AzLoadBalancer -ResourceGroupName <rg> -Name <lb>
Get-AzRouteServer -ResourceGroupName <rg> -RouteServerName <route-server>

障害切り分け

症状	疑う点	証拠	次の確認
片系停止で全断	health/route failover不成立	probe/BGP/effective route	steering mechanism修正
sessionだけ切断	state sync/symmetry不足	NVA session table/log	vendor HA設計確認
zone failureでcapacity不足	両instance同zone/overcommit	zone placement/metrics	multi-zone + capacity
spokeごと挙動差	UDR/peering association drift	effective route per spoke	policyを標準化

変更・rollback

failure drillを本番前に実施しRTOを測る。
upgradeは1台ずつdrainし、remaining capacityを監視。
route automationのrollbackはknown-good advertisement/UDRへ戻す。
vendor support matrixとAzure HA patternの両方を満たす。