从业20多年了，有个诡异的体会刻骨铭心，运维工作平时啥事没有，应用正常，流量正常，db正常，存储正常。一到放假过年或每逢重要日子必出故障，而且一出问题，接二连三，暴风骤雨，应接不暇。不知大家有没有同样的遭遇？
这不，虎年春节，朋友小公司的vsan集群崩溃了。朋友有两套vsan：
a) 4节点vsan是全新的全闪服务器，版本7.0.2，才上线2个多月；
b) 3节点vsan是老服务器缩容后保留的过度集群，版本6.7u3g。
2套vsan由同一个vcenter管理。这次崩溃的是4节点新集群，承担着日均2000w的访问量。
在放假前，我先发现了集群中某节点vsan网络有问题，导致可用性冗余度下降为0，空间占用率超过警戒线，表示如果此时再挂一个节点，将会导致服务中断，但数据不会丢。问题产生的原因不太明确，个人倾向于vcenter积劳成疾。
它是从5.5->6.0->6.5->6.7->7.0一路升级过来的，一年来各种小问题不断（比如vsan组件常出问题，vsan相关选项经常消失不见）。由于朋友有计划近期淘汰掉vmware，一直就凑合着用，不想为他花太多精力。新爆出的网络分区问题，经过简单排障没有解决，而年前归心似箭，朋友说，不出大问题就将就用吧。于是，这套集群就带病运行着了。
祸不单行，就那么倒霉，墨菲定律发威了。春节期间又一台新服务器内存故障了，导致一批虚拟机不可访问。
发现问题时已经正月初六，翻看日志，正月初二深夜内存就已经崩了，而初二早上为响应重保要求，刚刚挂出“系统维护”页面。如果不在冬奥期间，很多业务会中断的。幸运的是nginx所在的物理机是正常运行的，冬奥维护页面一直可以打开，还算庆幸。
花了些时间，利用冗余数据把挂掉的那1/3虚拟机恢复出来，此时理论上可以对外服务了，但这时安全冗余度为0，表示此时如果再有意外，是会导致数据丢失且无法恢复的。数据安全是底线，这个险不敢冒。
这批新服务器上线3个月内，已经出过两次问题，之前出过硬盘故障，因为两节点vsan是数据安全最后的底线，如果此时再坏一台，后果无法承受。
不能再拖了，远程紧急抢修迅速展开。
先联系戴*售后，售后工程师看到故障日志爽快答应硬件换新，但强调不负责数据安全。这台服务器不能用了。最先报vsan网络分区那台服务器，先把它恢复为初始设置，与另外倒腾出的一台同配置新服务器，在远程安装esxi后，组成双机vsan集群，该集群要强制接受raid1作为默认存储策略，准备接受迁移过来的数据。
所有esxi主机，将聚合端口中的一个网口，从聚合组中踢出，分配给标准虚拟交换机，并在物理交换机上，做相应配置，把物理端口从trunk改为access，然后将vm-kernel虚拟网卡迁入标准虚拟交换机。这是在远程进行复杂网络运维的基本操作。远程抢修时最怕断网，要为后续一系列复杂的网络调整，留有回滚空间。
然后处理vcenter，修复或继续升级都各种报错，最终重装了一台，导入旧vcenter的分布式交换机后，问题就转化为跨vcenter安全迁移虚拟机的问题。在有限的资源下，要保证新旧集群都有最低的安全冗余度，以防在迁移过程中，再爆出某台服务器硬盘或内存故障。一开始想用xvm批量迁移，
可是安装不起，时间紧迫，就用自带的跨vcenter迁移工具，手工迁吧。
迁移100多台虚拟机，50T数据，大概花了30来个小时，旧集群清空后，还要回收物理机，加入新集群，重建2个节点4个vsan磁盘组，再平衡数据，建立可用性冗余。
至于3节点的老vsan集群，主机状态都是正常的，可以快速热迁移，在旧vcenter中断开连接，
在新vcenter中直接添加主机，配置好相应的网络，跑在上面的开发环境不会中断。
事情回头看，似乎没什么难度。但在实施过程中，每走一步，都如履薄冰，时刻绷紧数据安全这根弦，不能让任何数据，在任何过程中，存在孤本副本。这是一项包含抢修组织与管理、抢修准备与实施、步骤控制与协调、资源的配置与使用等，全面性的分布式存储技术、工期统筹、数据安全保障的综合性考验。
汗滴禾下土，不知运维苦！抢修期间，每天睡眠时间不到5小时，运维人员要有一颗大心脏，去面对各式各样的问题：数据丢失，网站挂马，误删文件，网络攻击。同时，还要填坑、背锅、救火。之所以用“犀牛”这个网名，就是看上了“大自然的消防员”，天天救火这个梗。
最终，在发现问题80个小时后，愣是没去机房，全部远程处理，系统终于恢复了。
