性能文章>多机房灾备实践>

多机房灾备实践原创

2年前
75731136

2017年主导了公司新机房(100多台服务器规模)建设以及机房切换,前期工作主要是招标选供应商,服务器,网络设备等,定下来后就开始进行采购,2017年过年之前设备到位。年后开始规划实施。下面我就分享下机房建设以及迁移的经验。

一. 为何要做多机房

单一机房机房不可用时,业务停止,数据无法访问。不同地域的用户请求响应延时不同,CDN只能解决静态资源访问加速。多机房可以备份用户和系统数据,保证数据安全,一个机房出现故障可以切换到另外机房,提高系统可用性,按用户地域合理分配,访问就近的机房。

二. 理论依据

image.png

根据不同行业,以及CAP的三选二原则,支付、交易要求强一致(不允许出现脏数据),属于CA,互联网对强一致性要求不高,对可用性要求较高,一般都采用AP+弱一致性架构,也就是BSAE,BASE理论是eBay的架构师Dan Pritchett在ACM上发表文章提出的,BASE是指基本可用(Basically Available)、软状态(Soft State)、最终一致性(Eventual Consistency),允许窗口期数据不一致。

三 具体实践

1、新机房建设

  • IDC机房选购

      选型、招标、参观机房、评审、商务谈判、合同签署、开通宽带
    
  • 网络架构设计及评审

image.png

  • 服务器/网络设备选购

      设备选型、招标、商务谈判、合同签署、设备采购,资产管理
    
  • 模拟网络架构测试

      网络/VPN/标签等规划、双网卡绑定测试、模拟交换机/链路冗余测试、模拟VPN测试、防火墙冗余测试、负载均衡测试、专线网络测试
    
  • 基础设施部署
    IDC开通机柜带宽、设备验货、上架基础设施、部署基础设置

  • 应用服务部署

      自动装机系统、自动化运维系统、KVM虚拟化、账号管理系统、DNS系统、资产管理、监控系统、nginx、haproxy、keepalived、tomcat、redis、mq、zk、fastdfs、mysql、sqlserver、应用代码
    

2、切换数据中心方案设计

  • 数据中心测试方案设计

  • 数据中心切换方案设计

  • 部署架构

image.png

  • 整体的切换原则是平滑迁移,不停服务。

image.png

3、数据中心切换过程

迁移之前,确保新机房代码是最新的,测试人员进行回归测试,DBA部署亦庄到武清的数据库(sqlserver、mysql)、redis同步关系,文件系统,mq等都类似。

第一天凌晨进行第一波流量切换,切山东节点到武清机房,大约5%左右的流量,观察服务状况,没有异常情况,用户可正常下单。

第二天凌晨进行第二波流量切换, 上海、江苏、浙江、四川、河南、河北、福建大约50%左右的流量,继续观察服务状况,没有异常情况,用户可正常下单。

第三天凌晨进行全部切换,包括数据库等,切到武清做主,数据直接写武清的库。运维在DNSPOD上进行,把其他剩余流量切换到武清,切换后,网络工程师观察亦庄是否还有流量进入,因为DNS有缓存,所以需要观察一段时间,待到没有流量进入,开始进行存储层切换:

1、sqlserver,DBA利用手动故障转移,将vip从亦庄机房切换搭武清机房,停掉亦庄的sqlserver,sqlserver切换结束。

2、redis,DBA利用批处理脚本关掉亦庄所有redis主库实例,完成后,主库自动切换到武清,亦庄所有redis实例不提供任何服务, 不会有任何脏数据产生,运维切换DNS,DNS生效后,redis切换结束。

3、mysql,和redis切换方式类似,DBA利用批处理脚本杀掉主库,保证没有脏数据进来,运维切换DNS,生效后,mysql切换结束。

以上全部迁移OK后,所有流量、数据、存储都在新机房了,亦庄机房用于灾备。
image.png

四. 经验总结

系统比较多,大大小小的100多个系统,梳理过程中不够谨慎 ,遗漏了一些问题, 操作过程中,亦庄到武清做了很多调整,没有做好调研,整理了很多文档,做了很多工作,有不细致的地方,有些工作需要确认,没有落实到书面上,测试过程中有些不清楚的地方,欠缺沟通,信息不同步,准备工作没有准备好,还有历史遗漏原因。

迁移的过程中,有盲点,有测试不到的地方, 支付, 物流,小服务,全量push无法测试, 迁移后pay不可用, push不可用, dns解析问题导致部分缓存流量还在亦庄, 预案做的不充分,虽然有些问题,不过整体上来说,这次数据中心切换还算比较成功。

作者:白连东,北广视彩CTO,IT东方会联系会长,中商联产业互联发展处智库顾问,『IT令狐冲』公众号作者。

分类:
标签:
请先登录,再评论

老白威武,期待多分享

12年前
回复 童庭坚-PerfMa:

大佬带着飞

2年前回复

多向大佬学习,期待更多好内容😘

12年前
回复 LetUsJava:

我努力

2年前回复

飞机在飞行中换引擎,需要慎重,哈哈

2年前

大佬牛

2年前
回复 墨书:

一点点实践,你有机会也可以试试

2年前回复

👍👍👍

2年前

谢谢老板

2年前

给力👍👍👍,期待更多实战分享

2年前
回复 亚汉:

谢谢!

2年前回复

给力666👍

2年前

👍 灾备机制建立后,还需要做常态化演练,才能保证出问题时敢切换、切过去有效果。

2年前
回复 shihui:

老板是明白人哈,确实如此,不演练的话,出事故手忙脚乱

2年前回复

老白给力😃

2年前
回复 你假笨:

老板给机会

2年前回复

为你推荐

多机房灾备实践
2017年主导了公司新机房(100多台服务器规模)建设以及机房切换,前期工作主要是招标选供应商,服务器,网络设备等,定下来后就开始进行采购,2017年过年之前设备到位。年后开始规划实施。下面我就分享下
Kafka的生产者优秀架构设计
前言 Kafka 是一个高吞吐量的分布式的发布订阅消息系统,在全世界都很流行,在大数据项目里面使用尤其频繁。笔者看过多个大数据开源产品的源码,感觉 Kafka 的源码是其中质量比较上乘的一个,这得益于
微服务架构何去何从?
前言微服务架构模式经过5年多的发展,在各行各业如火如荼地应用和实践。如何在企业中优雅地设计微服务架构?是企业面对的一个重要问题。本文将讲述微服务架构1.0设计与实践以及面临问题和破局,最后讲述微服务架
PerfMa童庭坚:全链路压测体系建设方案的思考与实践
日前杭州笨马CTO童庭坚接受了软件质量效能社区的邀请,与行业同仁分享了关于全链路压测体系建设方案的思考与实践。以下为本场直播的核心内容: 系统性能测试的几个痛点在金融、零售快消、物流、新能源等传统行业
记一次存储故障的排查过程
高可用真是一丝细节都不得马虎。平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug。偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查。今天,笔
数学,离一个程序员有多近?
作者:小傅哥博客:[https://bugstack.cn](https://bugstack.cn) 沉淀、分享、成长,让自己和他人都能有所收获!😄 一、前言`数学离程序员有多近?`ifelse也
笔记整理:技术架构涵盖内容和演变过程总结
前言架构,说的是开发用的框架吗?对于刚接触编程的新人来说,可能并不能很清楚的知道架构是怎么来的,都包括什么内容。如果非得说什么架构,那么可能就是目前在 IDEA 中打开的工程就是架构。抛开技术圈内的架
高可用核心原理综述!
导读:天天评估系统可用性,每次说5个9 、6个9,那么,可用性到底该怎么评估,几个9又是怎么算出来的呢?而我们又可以做些什么,来保障系统的高可用呢?Part One 可用性概念一览永不停机总归是不现实的。那么,在可操作性的范围内,怎样把影响降到最小,而影响又该怎么衡量呢?概念一:MTBF