【记一次vsan数据救援的经历】

原创

已于 2023-09-13 09:44:29 修改 · 1.8k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#vmware #vsphere #vsan #数据救援 #数据中心 #超融合

于 2023-09-11 18:02:54 首次发布

本文讲述了一个VSAN集群的数据救援过程。业主的VSAN集群因操作失误导致重要业务系统不可访问。作者团队先尝试恢复vCenter服务，后针对不可访问对象分阶段救援，最终通过模拟正确操作恢复了所有数据，而VMware售后在救援中未起到关键作用。

一个无心的进入运维模式，使30TB数据变成不可访问！记一次vsan数据救援的经历

1. 背景
2. 事情起因：
- - - 以下是他自述详细操作步骤：
事前盘点：
救援前分析与安排
第一阶段工作：
第二阶段工作：
针对不可访问对象分的救援阶段

1. 背景

数据中心拓补图

业主有三台相同型配置的服务器，组合成了一个最小节点数（>=3）要求的vsan集群.
vcenter 安装在1号机的本地硬盘上。2、3号主机上也复制了一份备用（旧数据）
整个vmware产品是7.0.3. vcetner 是vcsa安装方式。

数据中心原规划是做为研发实验环境的目标建立的，为缓解客户一次性投入费用过大，计划第三期才提交数据备份方案，系统已试用了一年，还在建设中，当时正在进行第二期的建设，给业主内网建设internal各项子系统, AD、DNS系统建立起来后，计划将各个已建设的子系统加入它们;
业主已经迁移了几个重要的业务系统进来，但备份系统还没有实施（这是个大问题);
我们团队第一次使用vsan产品，团队vsan的知识经验少，运行一年中又没有进入vsan运维。

2. 事情起因：

周六，同事原计划想将vcenter 由初始安装时使用https://ip方式，更改为https://dnsname 方式。
改了名字后，发现vcenter等服务无法启动，只有https://ip:5480方式还能用。
努力做了多次，无果，想改回来，但无法改（事后证明可以改回来，但服务仍无法启动）
他没多想，直接又在1号机上布署了新的vcenter,想将3台主机重新加入该新的vcenter，而重新将主机加入vcenter,
需要使主机进入维护模式。
而本来在正常vcenter里，操作使主机正常的维护模式，vsan默认的选项时”确保数据迁移安全“，但偏偏他是通过登录1号主机后，操作主机进入维护模式，而该操作时，vsan默认的选项是”不迁移数据“。
另外HA也没有关闭。

以下是他自述详细操作步骤：

上周四下午3点15分：
1、在vCenter管理界面修改vCenter主机名、DNS，配置后出现网络更新失败
2、配置后管理界面与vCenter Web client也无法启动
3、重启vCenter虚拟机，还是无法进入vCenter管理与vCenter Web client，进入vCenter虚拟机，发现vsphere服务没有启动，重置证书与还原主机名与DNS，vCenter管理界面可以登录，vCenter Web client还是无法进入
4、计划周六重新部署vCenter，并将vSAN迁移至新vCenter中
周六下午1点：
1、配置vsan3号主机进入维护模式“无数据迁移”
2、发现2号机有虚拟机在启动，把2号机启动的虚拟机关机，配置vsan2号主机进入维护模式“无数据迁移”
3、vsan集群有虚拟机自动启动，vsan1号主机无法配置维护模式，把vsan 2号主机恢复正常模式，把3号主机恢复正常模式
4、把1号机启动的虚拟机关机，再把3号主机配置维护模式；把2号主机配置维护模式；配置1号主机配置维护模式
5、发现vsan集群中虚拟机异常，把所有主机恢复正常模式
6、打电话给xx，等待xx到达，了解具体情况尝试配置故障vCenter
周六晚上：
1、与xx进行vCenter修复，到周日下午3点，vCenter无法恢复
周日下午3点：
1、启动备用vCenter，重连vsan主机
2、等待vCenter同步还原工作
3、手动点击vsan对象立即还原，等待还原
4、欲清除不可用对象，无法清除，遂保持原样，等待还原工作

业主几乎所有重要的业务系统均不可访问，损失惨重。

事前盘点：

这件事就是典型的缺乏安全生产而产生一连串低级错误、失误造成的人祸：
事前对vcenter、vsan等知识不主动学习
公司在项目还没采购备份系统前，对项目实施过程安全教育不够，检查力度不足。
项目部在实施过程中，未因地制宜，利用现有条件进行数据备份和快照操作。
具体员工安全素质不足，在操作前未进行充分论证方案可行性
。。。
但问题已发生，所以各事情其实并行在处理，但此文重点讲解后来数据是如何被恢复的（顺带讲一下vcenter的问题）。

救援前分析与安排

考虑到周一前业主的所有业务要运转正常，所以处理内容按时间点分两阶段，前面是尝试将vcenter恢复启来，后面才是不得已下，一边给业主重新搭建新的业务系统，人肉从外部找回数据并放入新的业务系统中。一边想办法恢复不可访问的数据。

第一阶段工作：

容量情况
恢复vcenter服务，待续
简要结论：
a) 想vcenter 通过把主机名从localhost改名为xx.yy后，再重新更新证书的方案是不能成功的（vcsa服务启动不了）;
b) 再改回来，也无法再让vcsa服务启动；
c) 必须重新安装一个新的vcenter,再安装时设置新配置信息
由于在2，3号机中均有旧的克隆备份，所以最终启用了2号机的vcenter备份vm机

第二阶段工作：

核心目标与工作：将26个不可访问对象中的vmdk数据恢复出来
26个不可访问的对象
同步显示有约5.8G数据需要同步，但一直没有任何进展（忘计截图了）
其中两个vm 虚机: SVN与 Edisk 关键业务系统均在不可访问对象中，所以明确了最小目标，将这两个数据恢复回来。

针对不可访问对象分的救援阶段

阶段一：学习vsan 知识，并检查当前情况

在vmware官网知识库上相同情况的文章：
vSAN—维护—主机同时重启/集群完全关闭—数据不可用风险(60424)
看完这篇文章内容提到，有个事前预防的办法(下面的文章），事后解决方案，只给的提示是联系vmware工程师解决 😃
使用内置工具同时重启vSAN集群中的所有主机(70650)
按这个文章操作，到第14步，重启主机，提示执行操时
经过快速学习后知道，vsphere6.7之后，要在vcenter中选中vsan集群后，右键选择 ”关闭vsan集群“ 的命令才是正确的进入维护模式

使用 vsan 的 rvc命令，可以查询到：

/172.31.24.24/xx数据中心/computers/VSAN集群> vsan.disks_stats ~/computers/VSAN集群
+----------------------+-------------+----------+------+------------+---------+----------+----------+----------+----------+----------+---------+----------+----------+
|                      |             |          | Num  | Capacity   |         |          | Physical | Physical | Physical | Logical  | Logical | Logical  | Status   |
| DisplayName          | Host        | DiskTier | Comp | Total      | Used    | Reserved | Capacity | Used     | Reserved | Capacity | Used    | Reserved | Health   |
+----------------------+-------------+----------+------+------------+---------+----------+----------+----------+----------+----------+---------+----------+----------+
| naa.50015ebe0260021f | 172.31.1.11 | Cache    | 0    | 447.13 GB  | 0.00 %  | 0.00 %   | N/A      | N/A      | N/A      | N/A      | N/A     | N/A      | OK (v15) |
| naa.5000c500e1b43f63 | 172.31.1.11 | Capacity | 36   | 5589.02 GB | 32.37 % | 0.20 %   | N/A      | N/A      | N/A      | N/A      | N/A     | N/A      | OK (v15) |
| naa.5000c500e1b43f2b | 172.31.1.11 | Capacity | 43   | 5589.02 GB | 27.66 % | 0.27 %   | N/A      | N/A      | N/A      | N/A      | N/A     | N/A      | OK (v15) |
| naa