Network Controller 是微软软件定义网络体系中的核心管理平面，构建在 Service Fabric 集群之上，北向提供 REST API，南向通过 OData 通道持续控制 Hyper-V 虚拟交换机、软件负载均衡器以及 RAS 网关。在租户虚拟网络场景中，Network Controller 负责把逻辑网络映射到物理 Hyper-V 主机，并维护 NVGRE 或 VXLAN 封装所需的全部策略。如果控制器本身部署不当，租户之间的隔离就会出现随机性失效，而且故障往往难以复盘。
部署之前必须明确一个原则：Network Controller 保存的是期望状态，而 Hyper-V 主机上的虚拟交换机保存的是当前状态。控制器通过周期性同步和事件通知来消除两者之间的偏差。因此部署时不能只关注控制器是否在线，还要确认每台主机都能稳定接收并应用策略。
部署前的架构选择与前提准备
生产环境中，Network Controller 至少需要三个 Service Fabric 节点组成集群。三个节点通过复制状态来保证控制器应用的高可用，任意一个节点故障不会影响租户网络策略的下发。单节点部署只能用于实验，一旦宕机，整个逻辑网络配置将无法变更。
节点可以运行在虚拟机或物理服务器上，建议与管理网络分离，避免策略下发流量和日常管理流量互相抢占。所有 Hyper-V 主机需要加入同一个 Active Directory 域，且必须与 Network Controller 节点之间保证 Kerberos 认证和 HTTPS 连通。如果主机无法通过 443 端口访问控制器节点，后续注册操作会直接失败。
准备内容大致包括以下列表：
- 三台加入域的服务器用于承载 Network Controller 集群；
- 一个用于 REST API 的服务器身份验证证书；
- 具有本地管理员权限的部署账户；
- 防火墙放行 443 端口以及 Service Fabric 内部通信端口；
- DNS 正向和反向解析记录完整。
部署前可以先在任意一台 Hyper-V 主机上执行连通性检查，确认到三个控制器节点的 HTTPS 端口可达：
$NCNodes = @("nc-node01.contoso.com","nc-node02.contoso.com","nc-node03.contoso.com")
foreach ($node in $NCNodes) {
$result = Test-NetConnection -ComputerName $node -Port 443
Write-Host "$node -> $($result.TcpTestSucceeded)"
}
Network Controller 部署步骤与主机注册
创建 Service Fabric 集群时，需要在三个节点上分别安装 Service Fabric 运行时，然后使用微软提供的部署脚本或通过 Windows Admin Center 完成集群初始化。集群创建成功后，才能安装 Network Controller 应用程序。PowerShell 方式部署更可控，尤其是需要批量操作多个环境时。
下面是一个部署 Network Controller 应用的示意命令，实际参数需要根据证书指纹和节点名称调整：
$nodes = @("nc-node01.contoso.com","nc-node02.contoso.com","nc-node03.contoso.com")
$certThumbprint = "1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8F9A0B"
Install-NetworkController -Node $nodes -ClusterAuthentication Kerberos -RestCertificateThumbprint $certThumbprint -RestName "ncrest.contoso.com"
部署完成后，需要把 Hyper-V 主机注册到 Network Controller。注册过程本质上是让主机信任控制器的 REST 端点，并建立双向认证通道。主机注册成功后，控制器才能读取虚拟交换机信息并下发逻辑网络策略。
注册主机可以使用 Add-NetworkControllerHost 或通过 SCVMM 统一接入。注册前要确认主机名与证书中的标识一致，否则会出现“服务器身份无法验证”的错误。
随后需要创建逻辑网络，逻辑网络是物理网络的抽象，供后续虚拟子网引用。一个逻辑网络可以包含多个虚拟子网，每个虚拟子网对应一类租户二层网络。
租户虚拟网络的隔离模型与配置
租户隔离通常使用网络虚拟化技术，常见封装为 NVGRE 或 VXLAN。每个租户虚拟网络拥有独立的路由域 ID，即使两个租户的虚拟机配置了完全相同的 IP 地址，封装头也会让物理网络把它们看作不同的流量。物理网络只负责转发封装后的数据包，完全不需要感知租户内部的 IP 规划。
配置上，逻辑网络与虚拟子网的关系就像物理 VLAN 与逻辑网段的关系，但网络虚拟化没有 4096 个 VLAN 的数量限制。每个虚拟子网可以由租户自主定义地址空间，Network Controller 会把虚拟子网映射到具体的 Hyper-V 虚拟交换机端口上。
下面创建一个逻辑网络和一个虚拟子网，并把租户 VM 的网络接口连接到该虚拟子网：
$uri = "https://ncrest.contoso.com" $logicalNetwork = New-NetworkControllerLogicalNetwork -ConnectionUri $uri -Name "TenantLogicalNetwork" -VirtualSubnets @() $virtualSubnet = New-NetworkControllerVirtualSubnet -ConnectionUri $uri -LogicalNetworkId $logicalNetwork.InstanceId -Name "TenantSubnet1" -AddressPrefix "10.10.10.0/24" -NetworkVirtualizationProtocol "VXLAN" Add-NetworkControllerNetworkInterface -ConnectionUri $uri -Name "TenantVM01-NIC" -VirtualSubnetId $virtualSubnet.InstanceId -MacAddress "00-15-5D-11-22-33"
如果租户规模较小且对隔离要求不高，也可以使用传统 VLAN 隔离。但 VLAN 需要物理交换机全程配合，跨数据中心时配置复杂，而网络虚拟化完全由 Hyper-V 主机完成封装，交换机只看到普通 IP 流量，因此更适合多租户云环境。
还需要注意封装类型的一致性。如果一台主机使用 VXLAN 而另一台主机配置为 NVGRE，即使策略下发成功，租户虚拟机的二层通信也会中断。因此在创建虚拟子网时，务必统一指定 NetworkVirtualizationProtocol 参数。
常见部署问题与排查思路
Network Controller 集群状态异常是比较常见的问题。可以通过 Service Fabric 健康查询命令查看应用状态：
Connect-ServiceFabricCluster -ConnectionEndpoint "nc-node01.contoso.com:19000" Get-ServiceFabricClusterHealth
如果发现 Network Controller 应用分区副本长时间处于 InBuild 或 Warning 状态，需要检查三个节点之间的网络延迟和时钟偏差。Service Fabric 对节点间通信延迟非常敏感，延迟过高会导致状态同步失败。
Hyper-V 主机注册失败时，优先检查证书信任链和防火墙。主机与控制器之间的 443 端口不仅要通，还要保证主机信任控制器 REST 证书的根 CA。可以使用浏览器或 PowerShell 的 Invoke-WebRequest 访问 REST 端点验证证书。
租户 VM 无法通信时，先在 Network Controller 上查看虚拟网络和虚拟子网是否存在，再检查 Hyper-V 主机是否收到了对应策略。使用 Get-NetworkControllerVirtualNetwork 和 Get-NetworkControllerVirtualSubnet 可以确认控制器侧配置，再在主机上使用 Get-VMNetworkAdapterIsolation 查看封装信息。
物理网络如果启用了访问控制列表，需要放行 VXLAN 使用的 UDP 4789 端口。如果使用 NVGRE，则需要允许 GRE 协议通过。很多环境只放行了 TCP 和 UDP，容易遗漏 GRE 协议，导致封装后的流量被丢弃。
最后，Network Controller 的日志和 Service Fabric 事件日志是排查深度问题的重要依据。遇到策略下发延迟，不要只看控制器界面状态，还应检查主机上的 Hyper-V Network 事件日志，确认策略应用时间与控制器下发时间是否匹配。
Network Controller租户虚拟网络SDN部署修改时间：2026-10-02 17:37:41