匿名
未登录
登录
Linux78|wiki
搜索
查看“双活数据中心方案”的源代码
来自Linux78|wiki
名字空间
页面
讨论
更多
更多
页面选项
查看
查看源代码
历史
←
双活数据中心方案
因为以下原因,您没有权限编辑本页:
您所请求的操作仅限于该用户组的用户使用:
wiki:用户|用户
您可以查看与复制此页面的源代码。
=== 全局站点方案综述 === 全局站点的高可靠性规划主要目的是当主站点或某一个站点的某个环节或全部发生故障后,可以智能或手工进行故障切换,保证线业务的高可靠; 针对多站点之间和站点内多链路之间的高可靠性保证和负载均衡,我们建议在主站点和备站点分别部署专业的GSLB设备和多链路负载均衡LLB设备以实现站点级别的智能故障切换和站点内链路级别的智能故障切换; 另外在B中心双活数据中心架构下的业务引导和业务智能切换,GSLB设备起到关键性的作用; [[文件:Gslb-1.png|700px|有框|居中]] 我们建议在两个数据中心采用全局负载均衡、链路负载均衡和本地负载均衡整体解决方案,实现B中心双活数据中心建设; GSLB设备实现站点级负载均衡, LLB设备实现多链路负载均衡 SLB设备实现站点内Web服务器负载均衡; 在双活数据中心设计时,在业务访问层面主要考虑两个重点: 第一:如何选择最佳站点,将外部用户的访问同时引导至两个数据中心; 第二:业务的连续性,即如何保障业务的故障切换; 灾备切换需要考虑以下两点: 业务层面的切换:当某一数据中心故障后,所有得业务需要手动或自动切换到另一个数据中心,保证业务能够继续运行。针对业务层面的容灾切换,全局负载均衡技术是最佳的选择,全局负载均衡技术可以智能的将业务请求切换到正常的数据中心,保证数据中心的高可用性。 数据层面的切换:数据层面目前采用主中心单一数据库,无需考虑切换问题。 本环节主要讨论数据中心业务层面的故障切换,故障切换主要从一下几点分析: 数据中心内业务层系统瘫痪;主要是指主站内部某些系统全部瘫痪,此时主站点无法正常提供服——Web服务器层 整个站点瘫痪(由于天灾、掉电等因素或所有互联网链路故障) 整个站点故障主要是指站点接入链路故障或整个数据中心因自然灾难或掉电引起的故障;。 === 全局站点双活解决方案 === ==== 互联网区站点双活方案 ==== 访问方式:基于域名访问的B/S模式 实现技术:主域授权DNS配合GSLB设备的智能DNS 解析 业务模型设计:互联网WEB层基于域名访问设计; 工作原理:当用户在浏览器访问www.xxx.com时,首先要进行DNS 解析,即查找出www.xxx.com对应的A纪录IP 地址,然后用户与该IP地址建立TCP连接访问网站内容。在部署全局负载均衡设备后,具体的DNS解析过程交给GSLB全局负载均衡设备来完成,需要在域xxx.com的授权DNS服务器上增加多笔NS记录,即www.xxx.com的NS 纪录指向位于双站点的GSLB设备的接口IP地址,对www.xxx.com的解析将由该GSLB设备负责完成; 授权DNS服务器域名解析配置(以双站点双链路接入为例): www.xxx.com NS A中心 ISP1 IP(10.10.10.10) www.xxx.com NS A中心 ISP2 IP(11.11.11.11) www.xxx.com NS B中心 ISP1 IP(12.12.12.12) www.xxx.com NS B中心 ISP2 IP(13.13.13.13) 【备注:以下GSLB处理流程及DNS处理机制以阿里云DNS为例】 假定A中心站点作为万网DNS的首选NS查询记录,DNS解析的整个过程分析如下: [[文件:Gslb-2.png|700px|有框|居中]] 用户访问www.xxx.com时,其DNS请求发到其LocalDNS 服务器; 步骤1 LocalDNS查看本地是否有该域名的缓存记录,如果有,LocalDNS直接回应对应的A记录;步骤2 若LocalDNS服务器没有缓存,LocalDNS请求将域名注册商的授权DNS服务器;步骤3 授权DNS服务器收到LocalDNS的请求后,授权DNS服务器将按照配置的NS记录策略,将4笔NS记录对应的IP地址全部返回给LocalDNS;步骤4 LocalDNS同时发起对四笔NS记录地址的查询,直到请求到查询结果;LocalDNS查询请求到达两个站点的GSLB设备 (LocalDNS查询NS的机制取决与运营商DNS的设置,这里按照向所有NS记录同时发查询请求的机制介绍) 步骤5 两个站点的GSLB设备收到LocalDNS的查询请求后,做全局站点优选判断,将最佳站点的IP地址作为A记录返回给LocalDNS。步骤6 LocalDNS收到A记录响应后,将解析结果返回给客户端,并缓存到本地;(注:LocalDNS缓存DNS的TTL时间会学习授权域名DNS服务器的TTL时间值) 步骤7 假设GSLB设备返回的A记录为A中心站点ISP1链路对应的地址,用户将通过A中心站点的ISP1线路访问;步骤8 请求进入站点后,会先到达互联网区的WEB SLB本地负载均衡设备;步骤9 SLB设备将请求负载分发至Web层服务器群;步骤10 Web服务器请求内网业务区的数据库服务器;步骤11 请求响应按原路径返回,完成完整的业务访问; 【备注:客户端被GSLB设备解析到B中心站点的访问与上述业务流程相同;】 ==== 互联网区站点故障切换 ==== 2.2.1 站点级故障切换 站点级故障切换包括的因素: ISP链路全部故障 GSLB设备全部故障 WEB层或SLB设备全部故障 出口交换机或路由器全部故障 自然灾害因素 以上各环节,其中任何一个环节出现问题都会导致整个站点无法提供服务; 站点级故障的业务切换主要是靠LocalDNS查询授权DNS响应的NS记录实现,如下图中第5步LocalDNS请求同时查询两个站点的GSLB的NS地址,假设A中心为故障站点,对NS查询请求无法响应,自然由B中心站点GSLB设备回应A记录实现所有用户到B中心 站点的访问; [[文件:Gslb-3.png|700px|有框|居中]] 用户访问www.xxx.com时,其DNS请求发到其LocalDNS 服务器; 步骤1 LocalDNS查看本地是否有该域名的缓存记录,如果有,LocalDNS直接回应对应的A记录;步骤2 若LocalDNS服务器没有缓存,LocalDNS请求将域名注册商的授权DNS服务器;步骤3 授权DNS服务器收到LocalDNS的请求后,授权DNS服务器将按照配置的NS记录策略,将4笔NS记录对应的IP地址全部返回给LocalDNS;步骤4 LocalDNS同时发起对四笔NS记录地址的查询,直到请求到查询结果;LocalDNS查询请求到达两个站点的GSLB设备 (LocalDNS查询NS的机制取决与运营商DNS的设置,这里按照向所有NS记录同时发查询请求的机制介绍)步骤5 【故障分析】 假设LocalDNS在查询时A中心站点瘫痪,B中心 站点工作正常,继续解析A记录; 假设A中心站点故障后,B中心 站点的GSLB设备收到DNS查询请求后会进行多链路层面的静态或动态的就近性判断,为客户端解析最佳的运营商线路;并将该链路对应的业务地址作为A记录返回给LocalDNS。 此时,只有B中心站点的GSLB设备收到LocalDNS的查询请求,GSLB设备做完链路优选后,将本站点最佳链路的IP地址作为A记录返回给LocalDNS。步骤6 LocalDNS收到A记录响应后,将解析结果返回给客户端,并缓存到本地;(注:LocalDNS缓存DNS的TTL时间会学习授权域名DNS服务器的TTL时间值) 步骤7 假设GSLB设备返回的A记录为B中心 站点ISP1链路对应的地址,用户将通过B中心 站点的ISP1线路访问,请求到达互联网区的LLB链路负载均衡设备;步骤8 WEB请求到达互联网区的WEB SLB负载均衡设备;步骤9 WEB层SLB设备将请求负载分发至Web层服务器群;步骤10 Web服务器请求内网业务区的数据库服务器;步骤11 请求响应按原路径返回,完成完整的业务访问;
返回至
双活数据中心方案
。
导航
导航
首页
最近更改
随机页面
栏目
Nginx
Kubernetes
Spring Cloud
Wiki工具
Wiki工具
特殊页面
页面工具
页面工具
用户页面工具
更多
链入页面
相关更改
页面信息
页面日志