VMware vSAN 6.7-雷声大作

2018年即将结束...

在一个晴朗的12月一日,我们公司决定购买新硬件。不,当然,这不是一朝一夕的事。该决定是较早做出的。早得多。但是,和往常一样,我们的愿望并非总是与股东的能力相吻合。没有钱了,我们坚持了下来。但最后,当收购获得各级批准时,那欢乐的时刻到来了。一切都很好,白领们为他们鼓掌鼓掌,他们厌倦了在使用7年的旧服务器上每月处理25个小时的文档的烦恼,他们非常坚持地要求IT部门提出一些建议,让他们有更多的时间来处理其他同样重要的事情。

我们承诺将文件处理时间减少3倍,最多8个小时。为此,从大炮发射了一只麻雀。该选项似乎是唯一的选择,因为我们的团队没有,也没有数据库管理员来应用各种查询优化(DBA)。

所选设备的配置当然很高。这是HPE公司的三台服务器-DL560 Gen10。他们每个人都拥有4个具有26个内核,256个DDR4 RAM的Intel Xeon Platinum 8164 2.0Ghz处理器以及8个SSD 800Gb SAS(800Gb WD Ultrastar DC SS530 WUSTR6480ASS204 SSD)+ 8个1.92Tb SSD(Western Digital Ultrastar DC SS530 )

这些“铁杆”旨在用于VMware群集(HA + DRS + vSAN)。在第7代和第8代的类似服务器(也来自HPE)上,与我们合作了近3年。顺便说一句,直到HPE拒绝支持它们并将ESXi从6.0版本升级到6.5,并且没有铃鼓的情况下,它才出现问题。好吧,因此,有可能进行更新。通过更改安装映像,从安装映像中删除不兼容的问题模块等。这也增加了我们渴望匹配所有新事物的热情。当然,如果不是要使用新的vSAN“技巧”,那么在棺材中,我们看到了整个系统从6.0版更新到较新版本的情况,因此无需撰写文章,但是我们并没有在寻找简单的方法...

因此,我们购买了该设备,并决定更换已过时的设备。我们将最后一个SPP应用于每台新服务器,在每台新服务器中均安装了两个以太网10G网卡(一个用于用户网络,第二个用于SAN,656596-B21 HP以太网10Gb 2端口530T)。是的,每台新服务器都附带一个不带模块的SFP +网卡,但是我们的网络基础结构暗示了以太网(两叠用于LAN和SAN网络的DELL 4032N交换机),莫斯科的HP分销商没有HPE 813874-B21模块,我们他们没有等待。

当需要安装ESXi并将新节点合并到通用VMware数据中心时,发生了“奇迹”。事实证明,HPE ESXi Custom ISO版本6.5及以下版本不适合安装在新的Gen10服务器上。仅铁杆,只有6.7。而且,我们不得不不经意地遵循“虚拟公司”的戒律。

创建了一个新的HA + DRS群集,创建了一个vSAN群集,所有这些都严格遵守VMware HCL和本文档。一切都是根据风水配置的,只有定期的``警报''可疑地监视vSAN中有关非零参数值的这一部分:

图片

我们安心地将所有虚拟机(约50个)移至新服务器和基于SSD磁盘构建的新vSAN存储器,我们检查了新环境中文档处理的性能(顺便说一句,事实证明,这比计划节省了更多时间) 。在将最繁重的基地转移到新集群之前,本文开头提到的操作大约需要4个小时,而不是25个小时!这是该过程中所有参与者的新年心情的重要贡献。有些人可能开始梦想获得奖品。然后每个人都快乐地离开了新年假期。

当新年2019的工作日开始时,没有什么预示着灾难。毫不夸张地将所有服务转移到新的容量上,一切都开始了!只有对象的重新同步部分中的事件才更多。几周后发生了麻烦。在清晨,公司的几乎所有关键服务(1s,MSSQL,SMB,Exchange等)都停止响应,或开始响应很长时间。整个基础设施陷入混乱,没人知道发生了什么事和做什么。 vCenter中的所有虚拟机均显示为“绿色”,其监控没有错误。重新启动没有帮助。此外,重新引导后,某些计算机甚至无法引导,从而在控制台中显示各种处理错误。地狱似乎来了,魔鬼正在期待他的双手。

在严重的压力下,有可能确定灾难的根源。原来,此问题是vSAN分布式存储。乍一看,虚拟机磁盘上发生了不受控制的数据损坏-这是没有原因的。当时,唯一合理的解决方案是大声疾呼地联系VMware技术支持:SOS,保存帮助!

随后,该决定使公司免于丢失相关数据,包括员工邮箱,数据库和共享文件。我们在一起谈论的是30 TB以上的信息。

他有义务向未与基本技术支持订阅者“踢足球”的VMware支持人员致敬,但此案例包括在Enterpise细分中,并且流程日以继夜地进行。

接下来发生了什么:

  1. VMware技术支持提出了两个主要问题:如何恢复数据以及如何解决“ vSAN”战斗集群中虚拟机磁盘中的“虚拟”数据损坏问题。顺便说一下,数据无处可寻,因为额外的存储空间已被备份副本占用,并且根本没有地方可以部署“战斗”服务。
  2. 当我与VMware一起试图将vSAN群集中的“损坏”对象放在一起时,我的同事们紧急地挖掘了一个新的存储,该存储可以容纳公司所有30 TB以上的数据。
  3. , , VMware , , «» - - . , ?
  4. .
  5. , « » .
  6. , , «» .
  7. 我不得不暂时(几天)牺牲邮件的效率,以便在商店中再增加6 TB的可用空间,以启动公司收入所依赖的关键服务。
  8. 与来自VMware的讲英语的同事成千上万的聊天热线被“保存下来”,这是我们对话的简短摘录:

I understood that you are now migrating all the VMs out of vSAN datastore.
May I know, how the migration task is going on.? How many VMs left and how much time is expected to migrate the remaining VMs. ?
There are 6 vms still need to be migrated. 1 of them is fail so far.
How much time is expected to complete the migration for the working VMs..?
I think atleast 2-3 hours
ok
Can you please SSH to vCenter server ?
you on it
/localhost/Datacenter ###CLUB/computers/###Cluster> vsan.check_state .
2019-02-02 05:22:34 +0300: Step 1: Check for inaccessible vSAN objects
Detected 3 objects to be inaccessible
Detected 7aa2265c-6e46-2f49-df40-20677c0084e0 on esxi-dl560-gen10-2.####.lan to be inaccessible
Detected 99c3515c-bee0-9faa-1f13-20677c038dd8 on esxi-dl560-gen10-3.####.lan to be inaccessible
Detected f1ca455c-d47e-11f7-7e90-20677c038de0 on esxi-dl560-gen10-1.####.lan to be inaccessible
2019-02-02 05:22:34 +0300: Step 2: Check for invalid/inaccessible VMs
Detected VM 'i.#####.ru' as being 'inaccessible'
2019-02-02 05:22:34 +0300: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync
/localhost/Datacenter ###CLUB/computers/###Cluster>
Thank you
second vm with issues: sd.####.ru

这个问题是如何表现的(除了坚定不移的组织服务之外)。

在HBA模式下与磁盘进行数据交换期间,校验和错误(CRC)呈指数增长。如何检查这一点-在每个ESXi节点的控制台中输入以下命令:

while true; do clear; for disk in $(localcli vsan storage list | grep -B10 'ity Tier: tr' |grep "VSAN UUID"|awk '{print $3}'|sort -u);do echo ==DISK==$disk====;vsish -e get /vmkModules/lsom/disks/$disk/checksumErrors | grep -v ':0';done; sleep 3; done

作为执行的结果,您可以看到此节点的vSAN群集中每个磁盘的CRC错误(不会显示零值)。如果您拥有正值,而且它们在不断增长,那么在集群的Monitor-> vSAN-> Resincing objects部分中有一个不断出现任务的原因。

如何恢复未通过标准方式克隆或迁移的虚拟机的磁盘?

谁会想到使用功能强大的cat命令:

1. cd      vSAN
[root@esxi-dl560-gen10-1:~] cd /vmfs/volumes/vsanDatastore/estaff

2. grep vmdk     uuid

[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0] grep vsan *vmdk
estaff.vmdk:RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0"
estaff_1.vmdk:RW 41943040 VMFS "vsan://3736a75c-e412-a6c8-6ce4-20677c0084e0"
[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0]

3.    VM  ,  :

mkdir /vmfs/volumes/POWERVAULT/estaff

4.   vmx  

cp *vmx *vmdk /vmfs/volumes/POWERVAULT/estaff

5.      ,      ^_^

/usr/lib/vmware/osfs/bin/objtool open -u 3836a75c-d2dc-5f5d-879c-20677c0084e0; sleep 1; cat /vmfs/devices/vsan/3836a75c-d2dc-5f5d-879c-20677c0084e0 >> /vmfs/volumes/POWERVAULT/estaff/estaff-flat.vmdk

6. cd   :

 cd /vmfs/volumes/POWERVAULT/estaff

7.    - estaff.vmdk     

[root@esxi-dl560-gen10-1:/tmp] cat estaff.vmdk
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=a7bb7cdc
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0"      <<<<<     "estaff-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "ide"
ddb.deletable = "true"
ddb.geometry.cylinders = "10402"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "6379fa7fdf6009c344bd9a64a7bb7cdc"
ddb.thinProvisioned = "1"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "10252"
ddb.uuid = "60 00 C2 92 c7 97 ca ae-8d da 1c e2 3c df cf a5"
ddb.virtualHWVersion = "8"
[root@esxi-dl560-gen10-1:/tmp]

如何识别磁盘组中的naa.xxxx ...磁盘:

[root@esxi-dl560-gen10-1:/vmfs/volumes] vdq -Hi
Mappings:
   DiskMapping[0]:
           SSD:  naa.5000c5003024eb43
            MD:  naa.5000cca0aa0025f4
            MD:  naa.5000cca0aa00253c
            MD:  naa.5000cca0aa0022a8
            MD:  naa.5000cca0aa002500

   DiskMapping[2]:
           SSD:  naa.5000c5003024eb47
            MD:  naa.5000cca0aa002698
            MD:  naa.5000cca0aa0029c4
            MD:  naa.5000cca0aa002950
            MD:  naa.5000cca0aa0028cc

   DiskMapping[4]:
           SSD:  naa.5000c5003024eb4f
            MD:  naa.5000c50030287137
            MD:  naa.5000c50030287093
            MD:  naa.5000c50030287027
            MD:  naa.5000c5003024eb5b
            MD:  naa.5000c50030287187

如何找出每个naa的vUAN UUID ....:

[root@esxi-dl560-gen10-1:/vmfs/volumes] localcli vsan storage list | grep -B15 'ity Tier: tr' | grep -E '^naa|VSAN UUID'

naa.5000cca0aa002698:
   VSAN UUID: 52247b7d-fed5-a2f2-a2e8-5371fa7ef8ed
naa.5000cca0aa0029c4:
   VSAN UUID: 52309c55-3ecc-3fe8-f6ec-208701d83813
naa.5000c50030287027:
   VSAN UUID: 523d7ea5-a926-3acd-2d58-0c1d5889a401
naa.5000cca0aa0022a8:
   VSAN UUID: 524431a2-4291-cb49-7070-8fa1d5fe608d
naa.5000c50030287187:
   VSAN UUID: 5255739f-286c-8808-1ab9-812454968734
naa.5000cca0aa0025f4: <<<<<<<
   VSAN UUID: 52b1d17e-02cc-164b-17fa-9892df0c1726
naa.5000cca0aa00253c:
   VSAN UUID: 52bd28f3-d84e-e1d5-b4dc-54b75456b53f
naa.5000cca0aa002950:
   VSAN UUID: 52d6e04f-e1af-cfb2-3230-dd941fd8a032
naa.5000c50030287137:
   VSAN UUID: 52df506a-36ea-f113-137d-41866c923901
naa.5000cca0aa002500:
   VSAN UUID: 52e2ce99-1836-c825-6600-653e8142e10f
naa.5000cca0aa0028cc:
   VSAN UUID: 52e89346-fd30-e96f-3bd6-8dbc9e9b4436
naa.5000c50030287093:
   VSAN UUID: 52ecacbe-ef3b-aa6e-eba3-6e713a0eb3b2
naa.5000c5003024eb5b:
   VSAN UUID: 52f1eecb-befa-12d6-8457-a031eacc1cab

最重要的是

原来,问题是RAID控制器的固件和带有vSAN的HPE驱动程序的操作不正确。
以前,在VMware 6.7 U1中,用于vSAN HCL中的HPE Smart Array P816i-a SR Gen10控制器的兼容固件是1.98版(这对我们的组织来说是致命的),现在是1.65版
此外,当时(2019年1月31日)已解决该问题的1.99版已经包含在HPE垃圾箱中,但尽管我们否认了所有声明,但由于缺乏认证,他们没有将其传递给VMware或我们,他们说,对我们而言,最主要的是解决存储问题,仅此而已。

结果,仅在三个月后发布了磁盘控制器的固件版本1.99,该问题终于得到解决!

我得出了什么结论?

  1. ( ), .
  2. ! .
  3. «» , «» «» , 30% «».
  4. HPE, , .
  5. , :

    • HPE - . , Enterprise . , , ).
    • 我没有预见到在紧急情况下可能需要额外的磁盘空间来放置公司所有服务器副本的情况。
  6. 此外,鉴于发生的情况,对于VMware我将不再为大型公司(除DELL以外的任何供应商)购买硬件。为什么,因为据我所知,DELL收购了VMware,而现在在这个方向上的硬件和软件集成有望尽可能地紧密。

正如他们所说,将牛奶烧入水中。

伙计们。希望您永远不要陷入这种可怕的境地。

我记得,我已经惊呆了!

Source: https://habr.com/ru/post/undefined/


All Articles