新闻资讯

大咖博闻荟 | NSX-T的 Multisite 灾备策略讨论
2020/5/20 18:33:43

目前 NSX-T Data Center 的运作方式仍着重在单一数据中心之内的网络虚拟化与微分段方案。但当我们将企业的核心业务转移到 NSX 的环境内,势必需要讨论下面的问题:如果主数据中心出现状况,我们要如何在灾备中心内回复业务?NSX-T 所建置出来的逻辑交换器、T0/T1 路由器、微分段策略、负载平衡器、NAT 等等,能否无缝、或是在短时间内就可重建在灾备中心内,用户可再透过 SRM 等方案来迁移底层的虚机呢?

 

答案当然是可以的本篇文章将简要与大家讨论 NSX-T 的灾备策略,包含自动化回复以及手动回复的架构及条件。而同样的方案大家也可扩充为 Active-Active 双中心的配置方式。





在讨论不同灾备机制时,我们要先说明 NSX-T 的回复过程分为下列几个面向:


  • 控制层的 NSX Management Cluster 的还原。所有 NSX 内的配置都是储存于 NSX Management Cluster 内


  • 运算层的 NSX Edge (VM or Bare-Metal) 的切换。NSX Edge 上有提供实体接取、以及具备不同上层网络功能的 Tier-0 / Tier-1 路由器。这些路由器及上层的服务如何在主中心及灾备中心间切换


  • 运算层的 vSphere Cluster。这边是我们真实放置虚机的资源池。


在上图内是后续相关讨论的说明,虚线左侧为主中心,NSX-T 的 Management Cluster 均位于主中心运作。右侧则为灾备中心。乘载网络实体接取与上层服务功能的 NSX-T Edge (VM or Bare-Metal) 需要在两个中心均有配置。同样的,实际乘载虚机的 vSphere 资源也需要在两侧均有配置。两个中心各自有本身的 vCenter,也都有 SRM 的构件配置。


上图内,正常状况时所有运算虚机都是在主中心运作,网络进出南北向也均在主中心。但在灾备演练或实际要进行切换时,透过 SRM 可将运算虚机的备份机器于灾备中心启用。但在后面我们也会和大家说明 Active-Active 的架构。


以下我们分成 NSX-T 配置于灾备中心自动化回复以及手动回复的两种架构分别进行讨论:



NSX-T 的自动化灾备回复机制




当我们希望主中心与灾备中心间的 NSX-T 可以做到自动回复时,在 NSX 各层构件的架构与切换流程说明如下:


  • 控制层的 NSX Management Cluster 内的各台 Manager VM,必须位在一个跨双中心的 vSphere Stretch Cluster上,且 NSX-T 的管理网段(连接 Managers / Edge / vSphere 的管理网段)必须要跨双中心 L2 连接。


  • 当主中心完全失效时,原本主中心这边位于 vSphere Stretch Cluster 内的 x86 服务器失联,同时代表各台 Manager VM 也停止服务。此时,Stretch Cluster 会将三台 Manager VM 在灾备中心以 vSphere HA 机制自动重新开启,并重新组成 NSX Management Cluster。在灾备中心这边的 Edge / vSphere 可继续与 NSX Management Cluster 维持通讯。


  • 各个 NSX Edge Cluster 在规划时,需要在主中心及备援中心均具备 Edge VM / Bare-Metal Edge 的资源。各台 Tier-0 / Tier-1 路由器在建立时,均采用 Active-Standby 架构。透过 Edge 内 Active-Standby 的 Preemptive 选择机制,Active T0 配置于主中心的 Edge 资源,而 Standby T0 位于备援中心。此时,所有的 T0/T1 南北向实体连接与上层网络服务,均是透过主中心的 Edge 资源来提供。


  • 当主中心完全失效时,各台 T0/T1 路由器上的 Active 构件均失效。此时灾备中心的 Standby 构件接手,因此原有与上层实体网络接取以及网络服务透过 NSX 内 HA 切换机制,可持续维持服务。


  • 当然在此架构内,T0 路由器与上层实体网络的 BGP 联机需要同时与主中心及灾备中心的路由器建立 neighbor 关系。此时在主中心失效时,灾备中心的 T0 仍可透过此处的实体路由器维持对外连通。


  • 于灾备中心在运算层的 vSphere 资源池,本来的网络配置仍可运作,且在 NSX Management Cluster 回复后可恢复与控制层通讯。当主中心失效时,用户仅需启用 SRM 机制,将原本主中心的虚机在灾备中心的资源池重新部署,且网络配置完全不需改变。


自动回复的配置机制示意如下图:



上述机制的好处是当主中心失效,灾备中心可在短时间,且管理人员无须手动介入下,NSX-T 的配置与运作环境即可自动在灾备端恢复。当然,要达成上述的机制,除了前述的配置要求外,底层的环境需要满足下列条件:


  • 管理资源池 (vSphere Management Cluster) 必须配置为 Stretch Cluster。这代表两地间的网络等待时间必须要低于 10 ms、有可直接 L2 打通的底层网络、管理资源池内的外接或内接储存可支持 Stretch Cluster。


  • 如果是对外服务,此对外服务的 Public IP 必须可由企业或同一家电信服务商在灾备时进行切换。


  • 由于要进行 SRM 切换,且两边的 vSphere / Edge 均可能需要透过 Overlay 进行连接,运算资源底层的实体线路必须要支持大于 1 Gbps 的带宽,以及至少 1700  的  IP MTU。


但极有可能,企业在两座数据中心间的延迟时间会超过 10 ms,或因为不同的因素,无法建立两中心间的 Stretch Cluster。此时有另一个机制可以考虑,也就是接下来我们讨论的手动回复机制。



NSX-T 的手动灾备回复机制




在手动回复机制内,因为不像自动回复机制的管理丛集可以跨双中心建立 vSphere stretch cluster,因此当主中心失效时,我们需要手动在灾备中心回复 NSX Management Cluster。此时的流程与需要讨论的细节如下:


  • 此机制内,我们需要持续透过 NSX Backup 机制,定时将主中心 NSX Management Cluster 内的配置送往备援中心


  • 在主中心与灾备中心的管理网络如果有二层打通,那控制层的回复机制就会变得单纯。灾备需求发生时,在灾备中心将现有的备份透过 NSX Restore 机制,管理者在同样的管理网段上可以回复原本三台 NSX Managers,且使用一模一样的 IP。当 NSX Management Cluster 在灾备中心重新建立完成后,原本于灾备中心这边的 Edge / vSphere Transport Nodes 就可以与控制层重新建立联机


  • 一个变量是如果主中心与灾备中心的管理网络无法二层打通,两组管理网段仅有三层连通,此时 NSX Managers 的回复就无法以同样IP在灾备中心建立。若架构如此,则:


  1. 在NSX Management Cluster我们需以API修改"publish_fqdn"参数,要求Edge / vSphere Nodes要以DNS FQDN的方式与NSX Manager连接


  2. 灾备启用时,在灾备中心以新的网段IP搭配NSX Restore机制回复NSX Management Cluster


  3. 修改DNS设定,将各台NSX Manager的DNS纪录修改为灾备中心的IP。此时,灾备中心这边的Edge / vSphere Transport Nodes就可与控制层重新建立联机


  • NSX Edge Cluster 这边的配置方式可以与自动化的配置大致相同。但如果两个中心之间距离较远,而且网络跨三层,此时 T0 路由器设计上较不会与自动化配置环境一般,同时与两个中心的实体路由器做 BGP 路由连接,并在主中心失效时以 Active-Standby 机制切换。在手动架构内,通常建议是先在灾备中心预先建立好另一组独立的 T0 路由器,并预先建立灾备端的 BGP 路由配置。


  • 当主中心失效时,首先完成 NSX Management Cluster 的回复。接着,管理者手动将现有的T1路由器改接到灾备中心的现有 T0 路由器。此时,所有 T1 下的业务网段就可透过灾备区的 T0 / 实体路由器,取得对外连通了。


  • 与自动机制相同,于灾备中心在运算层的 vSphere 资源池,本来的网络配置仍可运作,且在 NSX Management Cluster 回复 / T0 路由器改接后可恢复通讯。当主中心失效时,用户仅需启用 SRM 机制,将原本主中心的虚机在灾备中心的资源池重新部署,且网络配置完全不需改变。


手动回复的配置机制示意如下图:



手动回复机制仍有部分底层环境条件需要满足:


  • 两中心间的网络等待时间必须要低于 150 ms。两边的管理网络可以 L2 打通在同一个网段最好,如果不行的话,两边的管理网段必须要路由连通。


  • 如果是对外服务,此对外服务的 Public IP 必须可由企业或同一家电信服务商在灾备时进行切换。


  • 由于要进行 SRM 切换,且两边的 vSphere / Edge 均可能需要透过 Overlay 进行连接,运算资源底层的实体线路必须要支持大于 1 Gbps 的带宽,以及至少 1700 的 IP MTU。


上面是针对两种回复机制的简单说明。而接下来,我想就几个在讨论 NSX-T Multisite 架构时,常被询问的问题进行说明:


问题:在上述的自动回复架构内,我们可否把 NSX Manager 一开始就配置在两个中心内,这样单中心失效时,不会三个 NSX Manager 一起失效,控制层仍然可以运作 


答案是可以,但是没有效益。自动复原架构内的 Stretch Cluster 跨两个中心。假设主中心有两台Managers,灾备中心一台。当主中心失效,两台 Manager 同时死掉,此时 NSX Management Cluster的Quorum 2+1 备援架构仍然会因为只剩一台 Manager 进入 Read-Only 锁定模式。此时,仍然要管理者将三台 Manager 重新启动后才能恢复服务。

 

如果企业可以有三中心建 Stretch Cluster,每个中心内各放一台 NSX Manager,Site 失效时只会有单台 Manager 失效,此时才可以确保不会有控制层重启的需求。


问题:在上述的架构都是讨论 Active-Standby。我们可否在 Active-Active 的环境内实作上述 NSX-T 的回复机制 


没有问题,NSX 环境内的 Multisite Active-Active 架构请先参考下图。



首先,由于两个站点间有 Overlay 网络,因此以单一应用来说,虚机要同时跨两个站点同时运作是没有问题的,没有规定只能在单一站点上运作,而有问题时再透过 SRM 在另一端重启。因此虽然以单一应用来说我们仅会在单一站点上提供南北向的进出(NSX-T没有支持Local Egress),但是在运算层,应用可以同时使用到两边的 vSphere 资源。

 

此外,上图内的蓝色 / 绿色大家可视为是两个不同的应用,蓝色应用主要在左边的站点运作,备援在右边站点。而绿色应用则相反,主要在右边站点运作,备援在左边站点。NSX 也可分别对应蓝色、绿色应用需求的 T0 / T1 等网络及安全配置,以前述的自动或手动方式进行灾备。


问题:前述架构内,要求两中心间底层网络开启至少 1700 MTU。如果实际环境内,线路服务商无法提供企业 1700 MTU 的线路呢?


此时我们不会采用上述的自动 / 手动灾备架构。在此状况下:

 

  • 最传统的灾备方式仍然可以做,也就是说主中心 / 灾备中心分别建置独立的 vSphere / NSX 环境,配置各自的网络与安全配置。当灾备发生时,以 SRM 将主中心失效的虚机在灾备中心重新开启,并透过灾备剧本进行必要的 IP 与其他虚机配置修改

     

  • 在 NSX-T 3.0 与后续的版本会开始支持 Federation 功能,也就是说我们可以部署多组 NSX 环境,但透过 Federation 机制同时将我们需求的网络 / 安全政策同时配置到多个环境上。当此机制可实现后,我们在 Multisite 的支持方式就能有更多弹性、更加简易了。

上一篇:Nutanix 助力华南师范大学,以技术   下一篇:科士达模块化UPS助力新基建数据中心建设  

新闻资讯

 
 广州云冠信息科技有限公司 版权所有
地址:广州市天河区天河北路892号803房  电话:020-38217262 传真:020-38219309
Copyright © 2015-2019 www.cloudcap.com.cn. All Rights Reserved.