Load Balancer HA Portsを理解するための前提
HA Portsはinternal Standard Load Balancer専用で、frontend/backend port 0・protocol Allのruleとしてall portsのTCP/UDP flowをload balanceする。 HA Ports有効時はICMPもサポートされる。
selectionはflow単位の5-tupleで、NVA scale-out/HAのように多数portを個別rule化したくない用途で使う。 stateful NVAではreturn path symmetryが重要。HA Portsだけで十分か、Gateway Load Balancerのsymmetry保証が必要かを比較する。
HA Portsと同じbackend IP configurationへ通常ruleを混在させる場合はFloating IP等の制約を確認する。 UDRでILBへtraffic steeringする構成では、route topologyとNVA IP forwarding、return routeを一緒に検証する。
Control plane / Data plane / Observability
UDR/consumer pathからILB frontendへtrafficを導く。
All/0でhealthy NVA群へflow単位に分散する。
同じNVAへ戻る必要がある場合はsymmetryを明示検証する。
Client-to-backend path
- workload flowがUDR等によりILB HA Ports frontendへ到達する。
- LBが5-tupleでhealthy NVA backendを選ぶ。
- 全port/protocol対象のため個別L4 ruleなしでNVAへ渡す。
- NVAがinspect/forwardし、宛先へtrafficを送る。
- return trafficが設計したpathで同じstateful NVAへ戻ることを確認する。
- NVA failure時はprobeによりnew flowを別healthy instanceへ配る。
仕組みを分解する
HA Portsは「NVAに全trafficを通す」だけではなく、routingとstate symmetryが成立して初めて機能します。UDRがforward pathだけILB/NVAへ向き、returnがsystem routeで直帰するとstateful firewall sessionが壊れます。Gateway Load Balancerはこのsymmetry問題を別方式で解決できるため、public endpoint service chainingではそちらも比較します。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| NVA用途か | web applicationの通常L4 load balanceならport-specific ruleの方が明確。HA PortsはNVA/多port用途。 |
| Symmetry | stateful inspectionが必須ならforward/return両方のrouteを図示し、Gateway LBも比較する。 |
| Floating IP | multiple frontends/同backend rule混在の必要性がある場合だけ有効化条件を精査する。 |
| Probe | NVA processだけでなくforwarding readinessを表すhealth checkを設計する。 |
確認手順
Read-only verification
- HA Ports ruleがprotocol All / frontendPort 0 / backendPort 0になっているか確認する。
- NVA NICでIP forwarding有効、guest OSでもforwarding enabledか確認する。
- forward/return双方のpacket captureで同じNVA instanceを通るか確認する。
- NVA 1台をunhealthyにしてnew flow failoverを確認する。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network lb rule list -g <rg> --lb-name <lb> -o jsonc
az network nic show -g <rg> -n <nva-nic> --query "{ipForwarding:enableIpForwarding,ip:ipConfigurations[0].privateIPAddress}" -o jsonc
az network nic show-effective-route-table -g <rg> -n <nva-nic> -o table(Get-AzLoadBalancer -ResourceGroupName <rg> -Name <lb>).LoadBalancingRules | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 片方向だけ通る | asymmetric routing | 両方向packet capture | return UDR/system route確認 |
| 一部protocolだけ失敗 | HA rule/NSG/NVA policy | rule protocol + NVA log | All/0とpolicy確認 |
| NVA bypass | UDR/route precedence | effective route | next hopを固定 |
| failure時session drop | stateful session非共有 | existing/new flow比較 | appliance HA design確認 |
| ICMPだけ失敗 | NSG/NVA policy | packet capture | HA Ports ICMP + firewall確認 |
変更時の確認と rollback
- UDRとHA ruleは別々にrollback可能なchange setにする。
- NVA backend removal前に既存session影響を確認する。
- Floating IP変更はbackend listener bindingへ影響するため事前確認する。
- rollback後はforward/return packet captureでsymmetryを再確認する。
Current notes — 2026-09-11
Microsoft Learnの2026-08更新ではHA Portsはinternal Standard Load Balancerのみ、ICMP supportあり、stateful symmetryが必要ならGateway Load Balancerを検討するよう明記されている。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。