踩坑记，记一次同城灾备项目规划与实施

这次需要规划实施的项目是一个同城灾备项目，客户在同一个城市相距约十公里有两个数据中心，客户要求在备中心完成主中心关键业务系统的容灾功能。

一、背景

数据中心：两个位于同一城市的数据中心，直线距离约10公里，光纤距离约为20公里。

环境：主中心业务系统运行在虚拟化平台，虚拟机数量在100台左右

存储：主中心两台存储（A，B）为双活结构，备中心部署单台（C）存储。

网络：主备中心采用波峰利用设备，通过裸光纤连接，从波峰设备上划分了一个以太网，一个存储网。主备中心的以太网和存储网都能互相访问。

容灾方式：客户要求使用存储的跨站点复制技术来实现底层数据同步，在虚拟化平台上通过脚本和API来调度虚拟机，简单来说，就是存储负责全部数据的复制和同步，虚拟化平台在主中心故障之后，自动在备中心拉起虚拟机接管业务。

二、规划

所有的规划工作都按照预定的计划进行得比较顺利，从分析业务、依赖关系、统计资源到后期的实施细节都一一做完了，唯一的问题就是客户是先采购的设备，再做的规划和设计（正常应该是先规划设计，再根据规划设计采购设备），导至整个方案有诸多地方是为了满足现有条件，不算完美。另一个问题就是在规划前的测试验证工作做得不是很完整，因为在做验证测试的时候，客户在备中心的存储还未到货，所以就在主中心模拟以了备中心环境进行测试。

三、实施

主中心的两台存储（A，B）为双活构，备中心的存储（C）为单台设备，所有数据由B同步给C，在做正常测试的时候没有问题，AB存储在故障的时候，备站点的虚拟机可以自动启动并承接业务，问题是当虚拟机在备中心运行，数据存入C存储里，如果AB存储恢复正常之后，C的数据无法同步回B中，原因存储厂家不支持多活结构，A与B为双活结构，C如果要将数据同步回B，需要有3秒的数据延迟，虽然只是理论上的3秒数据不同步，但对于关键业务来说是非常致命的。

四、解决

最后存储厂商紧急上线一个固件版本来解决这个问题，通过这个问题提醒一下各位同仁，一是在做规划的时候一定要多了解客户的现状，认真做好验证测试，要尽可能的使用真实环境进行测试，有时候模拟环境并不可靠，会与实施情况差别很大。二是尽量提醒客户要先做规划和设计再买设备，否则最后做出来的东西跟想要的东西是完全不一样的啊。