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左右的公网带宽压力,因为再大的流量我还没遇到。