VMware vSphere虚拟化容灾那些零碎但关键的点，聊聊开头就得知道的事儿

聊到VMware vSphere的容灾，很多人一开始就容易陷进那些高大上的概念里，比如RTO、RPO，或者各种复杂的架构图，但其实在真正动手规划甚至只是理解这件事之前，有一些零碎的、看似基础但极其关键的点，如果开头没想明白，后面可能会走很多弯路，这些东西往往不在官方文档的第一章，却是老司机们踩过坑后总结出来的“常识”。

第一点，也是最根本的一点：容灾不是备份，备份也不是容灾。 这是两个完全不同的目标，但新手特别容易混淆，你得先把这个分清楚，才能决定后面要走哪条路，打个比方，备份就像是给你的重要文件拍一张照片，存到保险箱里，万一文件被误删或者损坏了，你可以从保险箱里把照片洗出来，恢复成原来的样子，它的核心是“数据恢复”，针对的是数据层面的逻辑错误，比如误操作、中毒、软件bug，这个过程通常比较慢，需要手动选择恢复点和文件。

而容灾呢,它更像是给你的整个办公室（包括电脑、桌子、电话、正在进行的业务）拍一段全息录像，当你的办公室因为火灾或者洪水没法用了，你可以在另一个地方，用这段录像瞬间把整个办公室“复活”，让业务几乎不间断地运行下去，它的核心是“业务连续性”，针对的是站点级别的物理灾难，比如断电、断网、自然灾害，它追求的是快，是自动化切换。

你首先要问自己的问题是：我到底怕什么？我是怕某个员工不小心删除了数据库里的几张表（这时候需要备份还原），还是怕整个机房被水淹了导致业务彻底停摆（这时候需要容灾）？答案很可能是“我都怕”，那你就需要同时做备份和容灾这两件事，它们是互补的，谁也替代不了谁。

第二点，容灾的核心指标RTO和RPO，不是技术指标，是业务指标。 你肯定会碰到RTO和RPO这两个词，RTO是恢复时间目标，意思是业务中断后，你允许最多花多长时间把它恢复起来，RPO是恢复点目标，意思是业务恢复后，你允许最多丢失多长时间的数据。

很多人一上来就问“vSphere的容灾方案RPO能到多少？”这是个技术问题，但更关键的问题是，“我的业务能承受多长的停机时间？我的业务能承受丢失多少数据？” 这才是源头，一个内部测试系统，RTO是8小时可能都无所谓；但一个核心交易系统，RTO超过5分钟可能就意味着巨额损失，一个文件共享服务，RPO是24小时可能没问题；但一个金融交易系统，RPO超过1秒都无法接受。

你必须拉着业务部门的人一起,把这些指标聊清楚，因为这两个数字直接决定了你要花多少钱，想要RPO接近0（也就是数据几乎不丢失），你可能就需要投入昂贵的同步复制技术；想要RTO接近0（也就是业务几乎不中断），你可能就需要建设一个时刻待机的容灾站点，并配置全自动的故障切换，这都是钱堆出来的，如果业务部门说“我们不允许丢数据也不允许停机”，那你就要把对应的成本账单拍给他们看，他们往往会重新思考“必要性”，开头就明确合理的RTO/RPO，是控制成本和设定正确技术路线的前提。

第三点，容灾的不是虚拟机，是虚拟机里跑的业务。 这是个非常关键的视角转换，新手容易把容灾想象成“把一台虚拟机的数据复制到另一边”就完事了，但一个业务系统往往不止一台虚拟机，比如一个典型的Web应用，可能包含前端Web服务器、中间件应用服务器、后端的数据库服务器，可能还有文件服务器。

容灾的时候,你必须把这些有依赖关系的虚拟机当成一个整体来看待，这就是所谓的“恢复计划”，你不能只把数据库复制过去，而不管Web服务器，更复杂的是，这些虚拟机在恢复时必须有正确的启动顺序：必须先启动数据库，再启动应用服务器，最后启动Web服务器，如果顺序乱了，整个业务还是起不来。

在规划之初,你就要画出你关键业务的“依赖关系图”，搞清楚哪些VM是一组的，它们应该按什么顺序开关机，vSphere本身提供了“vSphere Replication”和“Site Recovery Manager”这样的工具来帮你管理这种复杂的恢复计划，但前提是你自己得先理清业务逻辑。

第四点，网络是容灾中最容易出幺蛾子的地方。 服务器和存储的复制技术可能很成熟，但网络问题往往是最棘手的，容灾站点和主站点之间的网络连接（简称“复制链路”）的带宽和稳定性，直接决定了你的RPO能不能达到，如果链路带宽不够，数据复制的速度就赶不上数据变化的速度，就会产生积压，真出事时就会丢失大量数据，如果链路不稳定，频繁中断，复制关系可能都会出问题。

虚拟机在容灾站点恢复后,它的IP地址怎么办？如果容灾站点和主站点在同一个大网络里（比如同一个城市的不同区域），你可能可以保持IP地址不变，但如果容灾站点在另一个城市，网络段完全不同，虚拟机的IP就必须改变，这时候就需要和网络团队紧密配合，提前规划好IP地址切换方案（比如用DNS切换，或者用专门的网络设备做自动化IP映射），这个问题如果开头不考虑，灾难发生时就会手忙脚乱，就算虚拟机起来了，用户也访问不到。

第五点，别忽略了“人”和“流程”。 技术方案设计得再完美，如果执行的人不熟悉流程，也一样会失败，容灾演练至关重要，而且不能是“纸上谈兵”的演练，要定期做真实切换演练，通过演练，第一是验证技术方案是否真的有效，第二是让运维团队熟悉整个故障宣告、切换、回切的过程，形成肌肉记忆，演练还能帮你发现那些计划中没考虑到的细节，比如某个服务的授权许在容灾站点是否有效？某个配置文件里是否写死了主站点的IP地址？

开头聊vSphere容灾,先别急着钻技术的牛角尖，先把上面这些零碎但关键的点想透：明确备份和容灾的区别、从业务角度定义清晰的RTO/RPO、以业务系统为单位进行规划、高度重视网络和IP问题、并把演练当成一项必须执行的纪律，把这些“开头就得知道的事儿”理顺了，再去研究vSphere Replication、SRM或者其他第三方工具的具体配置，你的容灾之路才会走得更稳当。