分享企业数据中心虚拟化那些年踩过的坑和整合心得

这个分享主要来自我过去十年在一家大型制造业公司负责IT基础设施工作的亲身经历,那时候，公司快速发展，收购了好几家工厂，每个工厂都有自己的小机房，里面几台服务器跑着各自的业务系统，比如ERP、MES什么的，管理起来特别乱，服务器老了也没钱及时换，一出问题就得派人往工厂跑，费时费力，公司决定要搞数据中心虚拟化整合，把各工厂的服务器都集中到总部的大机房里来，我就是这个项目的主要负责人之一，可以说是一路踩着坑过来的。

第一个大坑，就是低估了迁移的复杂性。 我们一开始想得太简单了，觉得不就是把物理服务器上的系统，用虚拟化软件“复制”一份到总部的虚拟化平台上来嘛，我们最早尝试的是那种“在线迁移”，就是希望业务系统不停机，在服务器还运行的时候就把数据搬过去，结果有一次，迁移一个用了快十年的老财务系统，这个系统连当初的开发商都找不到了，迁移过程中，数据同步总是出问题，最后导致系统卡死，不得不回退，业务中断了好几个小时，财务部的人急得直跳脚，从那以后我们学乖了，对于这种老旧、不熟悉的系统，宁可安排业务停机时间，采用更稳妥的离线迁移方式，虽然业务要停一下，但风险可控，这个教训是（来源：2015年迁移XX工厂老旧财务系统事故）。

第二个坑，是关于性能的“想当然”。 我们总觉得新的服务器性能强劲，一台物理服务器虚拟化成十几二十台虚拟机肯定没问题，刚开始确实挺顺利，但后来问题慢慢暴露了，最典型的是有一个做大数据分析的虚拟机，平时没事，但一到月底它就会跑批处理任务，CPU和内存占用会突然飙升到很高，因为它和数据库服务器等其他重要虚拟机在同一台物理主机上，结果好几次导致整台主机上的所有虚拟机都变慢，其他业务也受到牵连，这让我们意识到，虚拟化不是简单的“拼积木”，必须考虑每台虚拟机的资源使用特性，要把资源需求高峰时间错开的、或者有竞争关系的虚拟机分开安排，后来我们引入了更细致的资源监控和调度策略，这个问题才解决（来源：2017年月度报表任务引发的连锁性能故障）。

第三个坑，是存储网络成了瓶颈。 服务器是集中了，但所有虚拟机的数据都要通过网络读写后端的集中存储，项目初期为了省钱，用的还是千兆网络，结果当几十台虚拟机同时繁忙工作时，存储网络就堵死了，虚拟机反应非常慢，感觉就像电脑卡住了一样，用户抱怨连连，我们查了半天才发现是网络带宽不够，后来咬牙把所有链路升级到了万兆，瓶颈才消除，这个经历告诉我们，计算虚拟化了，存储和网络这些底层基础设施一定要跟上，否则就会拖后腿（来源：2016年虚拟化平台整体性能瓶颈排查经历）。

第四个坑，说起来有点后怕，就是备份和容灾的疏忽。 虚拟化之后，我们觉得有虚拟机的快照功能，备份恢复很方便，就对传统的备份手段有些放松，有一次，一台很重要的应用服务器因为软件bug导致数据逻辑错误，这种错误快照是没办法的，因为快照里保存的也是错误的数据，我们不得不从磁带库里找回几天前的备份数据，恢复过程花了将近一天时间，损失了一部分新数据，这件事给我们敲响了警钟：虚拟化环境的便捷不能替代扎实的、多层次的备份容灾体系，我们后来建立了更完善的策略，结合快照、基于虚拟机的备份和传统备份等多种方式（来源：2018年XX应用系统数据逻辑错误恢复事件）。

踩了这么多坑，我们也积累了一些整合心得：

第一,规划一定要走在前面，不能为了虚拟化而虚拟化，要先摸清家底，了解每个业务系统的特性、资源需求、关联性，做好详细的迁移和资源分配方案，对于老旧的、不重要的系统，有时候重构或者直接替换掉可能是比迁移更好的选择。

第二,团队技能要转型，搞虚拟化之后，我们运维人员不能只懂Windows、Linux这些操作系统了，还必须深入学习虚拟化平台本身、存储和网络的知识，成了一个需要掌握多种技能的“全栈”型运维，我们当时就组织了多次培训。

第三,监控是关键中的关键，虚拟化环境比物理服务器更复杂，问题更隐蔽，必须有一套强大的监控系统，能实时看到整个虚拟化集群的健康状态，从CPU、内存、存储IO到网络流量，这样才能提前发现问题，快速定位故障。

第四,要有成本平衡的观念，虚拟化能节省硬件成本，但软件许可（比如VMware的授权）、更高级别的存储和网络设备、运维人力的投入都会增加，要算总账，找到性价比最高的那个平衡点，而不是一味追求技术的先进性。

数据中心虚拟化整合是一个系统工程,技术只是其中一环，项目管理、风险控制、人员能力提升同样重要，虽然过程磕磕绊绊，但最终完成后，服务器的利用率从原来的不到15%提升到了60%以上，管理效率大大提高，运维成本也降了下来，觉得所有的辛苦和踩过的坑都是值得的，这些经验也为我们后来向私有云演进打下了很好的基础。