0x01 前言

NSX除了结合VMware各个组件使用外，在裸金属环境中也能作为一个重要的角色存在。

在对内及对外服务繁多的环境中，适当使用NSX Edge可以极大地降低硬件成本和提升管理效率。而针对独立用户或不同部门的服务器部署需求，除了能实现快速部署外，最重要的是能提升安全性与可靠性。

0x02 需求

首先是VPS业务，这部分需求较为简单。VPS业务对外销售，首选KVM架构，因为业务级别不高，公网IP只需要配置在VPS实例中即可。高级点的可以使用NSX按各户划分分段，为VPS分配内网IP，最后调用API配置1:1 NAT，这部分不在本文内讨论。

服务器托管的自由度会高点，客户在一般情况下会订购DIA带宽及公网IP。在实践中是动态调整的，也就是客户会根据业务情况增加或减少带宽及公网IP。相较于VPS业务，服务器托管的业务管理要求会提升一点点难度，这主要体现在客户间及底层网络的隔离。

服务器托管还有一种情况，类似私有云，但又不完全是。主要的需求是：需要实现内网IP互联。本质还是裸金属服务器，需要和云上云下、跨机房或跨地域的其他网络互联，这种互联需要使用内网IP。在跨机房或跨地域的情况下使用公网IP互联也不是不可以，但前提是两端的网络设备都要有管理权，引入或写入路由即可。但在混合云的环境中会出现不可控的情况，存在一定风险。

无论是哪种业务，都不可避免ARP广播的问题，尤其在VPS业务，在遭受扫描的时候尤其明显。当VPS业务中的IP使用率较低时还可能引起泛洪问题，会直接影响底层设备。使用NSX就可以很好地处理这个问题，避免影响底层的核心设备，隔离影响。

0x03 NSX-V与NSX-T的特点

NSX-V需要依赖vcenter，而NSX-T具有更高自由度，可以独立部署在裸金属服务器中。可靠性方面，两者在正常使用的情况下一般不会有过多问题，在实践过程中都可以实现Edge故障快速转移。

我在实际使用中习惯在NSX-V中配置OSPF，因为这比较简单，但收敛时间较长。出现故障时，从NSX-V检测到故障到完成切换可能需要几秒钟时间。NSX-V的Edge只支持active-standby模式，所以在这种情况下配置BGP其实作用不大。NSX-V的一大优点是：可以在vNIC下按需增加subnet，但没法实现noSNAT或noDNAT。

在NSX-T中则习惯使用BGP和底层路由器互联，并打开BFD，可以实现毫秒级的故障转移，在实际使用中效果非常理想。NSX-T的Edge支持active-active和active-standby模式，使用前者的时候，可以手动调整或指定路由优先级；而使用后者时则无法调整，因为处于standby状态的Edge是不工作的，BGP路由会添加prepending。

NSX-T的缺点是没法在service interface下增加subnet，有且只能有1个，但可以实现noSNAT或noDNAT。

0x04 实际应用

从上面的简单说明可以看出，VPS业务及一般的服务器托管业务使用NSX-V较为合适，类私有云的服务器托管则需要使用NSX-T。

0x04.1 VPS及一般服务器托管

VPS业务依旧是最简单的，首先划分好vlan，需要准备host的管理及业务2个vlan，如果使用SAN存储，还需要增加一个。我这里使用solusvm作为管理软件，使用centos 8操作系统，所以网络部分配置如下：

# 物理口
[root@ngx-test network-scripts]# cat ifcfg-enp5s0f0
TYPE=Ethernet
NAME=enp5s0f0
DEVICE=enp5s0f0
ONBOOT=yes
MASTER=bond0
SLAVE=yes

BOOTPROTO=none
[root@ngx-test network-scripts]# cat ifcfg-enp5s0f1
TYPE=Ethernet
NAME=enp5s0f1
DEVICE=enp5s0f1
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

# LACP
[root@ngx-test network-scripts]# cat ifcfg-bond0
BONDING_OPTS="mode=802.3ad miimon=100"
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
DEFROUTE=yes
NAME=bond0
DEVICE=bond0
ONBOOT=yes

# VLAN
[root@ngx-test network-scripts]# cat ifcfg-bond0.901
VLAN=yes
NAME=bond0.901
DEVICE=bond0.901
BRIDGE=br901
BOOTPROTO=none
ONPARENT=yes

# br
[root@ngx-test network-scripts]# cat ifcfg-br901
TYPE=Bridge
IPADDR=172.16.0.1
PREFIX=24
GATEWAY=172.16.0.254
DEFROUTE=yes
NAME=br901
DEVICE=br901
ONBOOT=yes

 

这里使用LACP提高可用性，然后将vlan透传到NSX-V Edge中。这部分工作需要先在vCenter中新建DPG并透传VLAN：

然后到NSX-V Edge中添加一个internal vNIC：

在这个vNIC里可以按需添加多个subnet，并设置一个IP作为网关：

剩下的让solusvm这个管理软件分配即可：

还需要配置防火墙，规则如下：

  1. 默认any to any drop
  2. 放行 internal subnet to internal subnet，主要用于管理
  3. 放行any to vps subnet
  4. 放行vps subnet to !internal subnet，注意前面的感叹号，含义为”非“

一般服务器托管业务的配置和VPS业务类似，这里就不展开说明。因为客户可能非常多，需要提前划分好VLAN区段，方便快速分配。还有就是体量大的话，会产生很多DPG和Edge，所以这个架构不一定适用于所有情况。

因为NSX-v Edge的CPU需求非常低，有需要的话可以增加物理网卡，为esxi服务器创建多个vDS，可以充分压榨物理服务器的性能。

0x04.2 类混合云

如果独立开发了控制面板，可以极大提升客户的自由度，他们可以自行更换公网IP。否则只能提前安排好IP的对应关系，因为NSX-T manager较为敏感，不会开放给客户使用。

因为NSX-T manager的控制权不交付给客户，我们可以在同一个T0 Edge下创建多个T1 Edge，让客户的服务器将该T1 Edge的service interface作为网关，实现内网互通。剩下的就是公网的部分，需要在底层路由器按客户提前配置好路由策略，避免配置错误的情况发生。然后配置T0及T1 Edge，将NAT IP通过BGP重分发到下级：

公网部分的网关是不需要的，因为已经有相关路由。但为了让公网IP在广域网内传播，需要将它们配置路由器中。因为IP段较多，我习惯将它们划分编号，然后在路由器中创建LoopBack interface。这样配置的网段是Direct属性，需要使用route-policy进入BGP进程，然后再配置ISP的路由策略，按策略广播即可。

防火墙部分和0x04.1类似，而最重要的是noSNAT和noDNAT。其实noDNAT一般用不上，用得最多的是noSNAT，所有出站往内网的流量都配上noSNAT，配合精细化防火墙规则即可完成服务搭建：

0x05 结语

经过长时间的实践，在中小规模的环境中择优使用NSX-V/T确实可以极大程度地提升网络稳定性，而底层的硬件设备只需要负责路由和转发，各级隔离的程度非常理想。但也有一系列问题，首先是配置的复杂性，涉及诸多知识面；其次是防火墙的配置粒度，需要极其精细地配置，稍不留神就会出现内网被渗透的情况。

NSX在延迟方面控制得非常好，延迟增加在1ms左右，还有WEB GUI，方便一般运维人员使用，前提是做好路由策略。在实践中，底层只需要部署一个企业入门级路由器即可撑起3000个IP，10G左右的公网带宽压力，因为再大的流量我还没遇到。

相关文章多从作者