NSX-T Multisite灾备与双活数据中心解决方案PPT资料.pptx

NSX-T Multisite灾备与双活数据中心解决方案PPT资料.pptx

《NSX-T Multisite灾备与双活数据中心解决方案PPT资料.pptx》由会员分享，可在线阅读，更多相关《NSX-T Multisite灾备与双活数据中心解决方案PPT资料.pptx（31页珍藏版）》请在冰豆网上搜索。

图中的client是internet用户，还是内网用户；

作为用户，他们以什么样的方式来访问web层（例如电信用户走电信，联通用户走联通线路，复杂的商业要求）；

内网用户希望如何访问等B/S应用，通常分为web、app、DB三层架构B/S应用需要domainname（DNS）来相互访问，name的访问存在在各层互访中，例如web以name来访问appserver每一个层次的访问，都有选择DCA和DCB的可能；

IT系统运维必须对每一个应用做出明确的指示，在每一层该如何选择由于访问路径的复杂和多样，我们需要有一定的限制，但又要保持一定的灵活性；

同时DC间的距离和DC间互访，可能会导致的通讯成本和应用性能下降。

这些因素综合考量，达到一个较好的平衡假设这些服务器除DB外，都以VMwareVM的形式存在,每层都有ADCLB帮助均衡负载,ADC,WEB,WEB,WEB,ADC,APP,APP,APP,ADC,可能的情况Intranet/Internet数据中心

（一）,Router,GTMRouter,GTM,ADC,WEB,WEB,ADC,APP,APP,APP,ADC,数据中心

（二）,流量引导,ORACLERAC,ORACLERAC,iSession/EoIP/OTV/IPSEC,展示层,WEB,iSession/EoIP/OTV/IPSEC,应用层,WOM/EoIP/OTV/IPSEC,数据库,9,C/S应用的访问路径与关系,特点：

图中的client是internet用户，还是内网用户C/S应用，通常分为app、DB两层架构C/S应用直接使用IP来相互访问，如果appserver是一组机器（cluster），也需要SLB来分配请求同样appserver，会去调用一些依赖接口，以及DB,假设这些服务器除DB外，都以VMwareVM的形式存在,10,汇总以上各方面问题的答案，是设计双活数据中心的基础以下以VMware产品和解决方案，来探讨一下网络部分（包括LB）用户情况和用户期望的汇总（举例）：

双中心路程距离10KM，网络设备已有，VM有300台，DB为物理机IBMDB2使用IBMAIX的HA（主备模式）用户client端全在内网中，用户希望各个院区的client都尽量访问本院区的应用资源（相同的业务会在两个DC同时存在）。

DB层只有主院区为active，其他为standby应用间调用尽量不要跨DC间（DCI）线路业务系统C/S和B/S均有,11,用户情况的汇总,找出1-2个CS和BS应用进行研究，做POC或其他技术跟进等,网络角度的常用三种DR方法LB和网络系统要相互合作,12,LB流量引导的模式GTM根据地理位置或网络距离智能选择优点：

可以灵活分配，用户体验好缺点：

故障切换有一定延迟，应用必须支持DNS访问RHI静态路由注入+动态路由模式优点：

使用路由调整方式，切换速度快，应用无需支持DNS缺点：

只能支持主备模式，不能同时使用N+M冗余模式（F5和AVI支持）（跨站点的cluster），FW也有类似方式优点：

切换迅速，应用无需支持DNS缺点：

对外有两个或者两个以上入口，需要人工分配，必须要有二层打通支持双活方案就是灵活运用这几种模型，来满足用户现实场景和需要,NSX-TMultisite,13,方式1-NSX-T2.5Multisite法NSX-T系统图,vCenterCompute,vCenterCompute,S,S,BGP,T0GW,S,S,S,S,1ArmLB,LBServerPool,T1GW,DataplaneBluetraffic,ComputecanbeextendedbetweenSitesANDPrimarySiteActiveforNorth/SouthBlueApps,S,S,LBServerPool,NSX-TManagerCluster,蓝色系统网络和网段上的VM，以DC1为主，DC2为备,14,方式1-NSX-T2.5Multisite法Active/ActiveUseCase,vCenterCompute,NSX-TManagerCluster,vCenterCompute15,PrimarySite,S,S,S,S,S,S,LBServerSecPooolndarySite,T0GW,BGP,T1GW,1ArmLB,DataplaneGreentraffic,ComputecanbeextendedbetweenSitesANDSecondarySiteActiveforNorth/SouthGreenApps,S,S,LBServerPool,绿色系统网络和网段上的VM，以DC2为主，DC1为备,方式1-故障切换示意动画,T1-ServiRT,T1-DistRT,VM3,VM2,VM1,VM3,VM2,VM1,LS210.1.2.0/24,LS110.1.1.0/24,T1-stdalone-LB,LS-VLAN999-10.1.2.0/24,VM4,LS-VLAN999,VM4,LS-VLAN99810.1.3.0/24,VM5,LS-VLAN998,VM5,L2Bridge,DataPlaneRecovery-LabT1-CSP,T0-Lab3,网络切换后，SRM进行VM恢复,16,深蓝色的T0/T1，seg网段，和网段上的VM，可以提供所有应用服务，主要用于院区1用户的业务处理绿色的T0/T1，seg网段，和网段上的VM，可以提供所有应用服务，主要用于院区2用户的业务处理两套系统从VM的角度是完全一样的，独立的两套（不包括物理机DB）当NSX-TT0/T1系统发生故障，会向并外的DC自动迁移（或者说当故障后，对端的各种网络router，service会激活为active）接下来，利用SRM，进行VM的恢复用户访问流量由于BGP路由更新，会从切换后的DC进入（紫色箭头）,17,NSX-T2.5Multisite解释,灾备与双活数据中心NSX-TMultisite,第二部分,19,T1GW,T1GW,20.1.1.0/24,20.1.2.0/24,VM.11,VM.12,VM.13,VM.14,VM.15,VM.16,SLB,SLB,user1170.1.1.0/24,gslb,gslb,L3,L3,L3,L3,Coresw,集团骨干网,user2,Layer2DCI,BackupDB,T0GW,NSXT系activeDB统,T0GW,整体拓扑,VM,VM,110.1.1.0/24,正常状态分析,20,C/S和B/SL3router与集团骨干动态路由，ospf/bgp/eigrpSLB应发RHIhostroute（VS）NSXT与coresw建立BGPSLB，FW可以使用N+M或crossDCcluster特性DB为物理机，直连在coresw上Coresw之间有DCI互联链路，详细见P25-26B/SUser1=院区一用户，user2=院区二用户DNS阶段：

GSLB通过LDNS判断从哪个院区来的用户，返回相应DC的VIP用户1访问DC1的SLBweb-app-db；

用户2访问DC2的SLB-web-app-db,db在DC1，需要DCI支持C/S应用（经过SLB或不经过SLB）User1的C/S应用主用指向DC1的IP地址；

User2主用指向DC2的IP地址（人工分配的过程）用户1访问DC1的SLBweb-app-db；

用户2访问DC2的SLB-web-app-db,db在DC1，需要DCI支持,故障分析,21,1.出口线路sw（图中未画出），L3router，SLB，FW单机故障或相关linkfault，会导致路由，STP重收敛（速度很快1s以下）硬件设备的主备切换，一般3秒即可完成。

SLB和FW等session都有保持，前端用户无任何感知双机均故障的情况B/S应用（noN+M）：

出口L3router全故障，DC2gslb会判断DC1的slb的VS全部失效，更改dns条目，新连接会到DC2的VIP处理；

老的连接（dnscache）会timeout，重连，内网用户会60秒或几分钟中断；

SLB双故障，同样C/S应用和B/S（在SLBN+M模式，或者是SLBRHI模式）：

实际就是一个动态路由切换过程。

当双L3或双SLB故障，DC1的路由全消失，DC2的SLB的highcostRHIforVIPs会生效，相关的subnet网段的highcostroutes也会生效，结果就是用户的流量会吸到DC2去。

（详请看NOTE）因此SLB是应用发布和切换的比较关键的点,22,DC出口部分故障分析,Coresw故障，sw有VSS，VPC，istack等二虚一的技术，当一台设备发生故障，无影响，请分别参考相关文档对各种故障的讨论。

对于esxi服务器和其他物理服务器来说，物理连线一般为双上联，无影响。

VLANGW一般配置为FHRP（hsrp，vrrp）,也不会有影响。

DBserver故障，由于DBcluster的相关VLAN是通过DCI直接连接起来的，因此DB可切换到DC2，其他不变。

两台core-sw同时故障，会比较复杂，一方面要引导流量到DC2，通过GSLB，SLB，RHI动态路由等，并外要求SLB的VS尽快指向绿色的serverpool；

同时DB会出现splitbrain故障情况。

请参考DCI中断故障分析页DCI的设计请参考backupslides，方法有很多种，选择适合自己的,23,DCcoresw故障分析,NSXT系统故障，单独T0、T1故障会切换到DC2，会有DCI流量，如果同时故障，如前图所示，会全部切换到DC2.此时流量为coresw-DC2core-sw-T0-T1-（DCI）-VMs，也就是迂回了两次。

用户业务无影响。

（NSXTmanager故障，请参考恢复过程，不影响业务流量）如果一个VS的serverpool的所有VM全down，SLB会检查到，会使用lowpriorityserverpool去继续处理业务，例如这个pool可以为DC2的绿颜色的sererpool。

24,Core-sw以下NSX-T系统内故障,如一个DC整体故障，蓝颜色serverpool消失，如使用N+M模式SLB，SLB的VIP会切换对应到备用机组（绿色serverpool）；

如非N+M，可以使用RHI发布相同VIP的VS，但是是highcostroute，平时这个VIP的VS没有流量；

故障后，才接受流量。

所有流量，都会被发到DC2去。

接下来的行动为SRM恢复蓝色的VM，恢复后，会重新编组在SLBserverpool内B/S业务，可以使用gslb来切换，但需要dnscachetimeout（60秒到几分钟内网用户）,25,DC整体故障,DCI故障，是最复杂的故障（可能需要仲裁点）DB会走splitbrain流程，假如流程最终会lock住一边，那么也就是50