VMware vSAN 6.7 — И грянул гром

Заканчивался 2018-й год…

Однажды, ясным декабрьским днём, решила наша Компания приобрести новое «железо». Нет, конечно, это не случилось в одночасье. Решение было принято раньше. Намного раньше. Но, как водится, не всегда наши желания совпадают с возможностями акционеров. И денег не было, и мы держались. Но наконец-то наступил тот радостный момент, когда приобретение было одобрено на всех уровнях. Всё было хорошо, «белые воротнички» радостно аплодировали, надоело им на серверах 7-ми летней давности ежемесячно обрабатывать документы по 25 часов и они очень настойчиво просили Департамент ИТ придумать что-нибудь, чтобы подарить им больше времени для других, не менее важных дел.

Мы пообещали сокращение времени обработки документов в 3 раза, до 8 часов. Для этого выстрелили из пушки по воробьям. Этот вариант казался единственным, поскольку в нашей команде нет, и никогда не было, администратора баз данных для применения всевозможных оптимизаций запросов (DBA).

Конфигурация выбранного оборудования была, конечно, заоблачной. Это были три сервера от компании HPE — DL560 Gen10. Каждый из них мог похвастаться 4-я процессорами Intel Xeon Platinum 8164 2.0Ghz по 26 ядер, 256 DDR4 ОЗУ, а также 8 SSD 800Gb SAS (SSD 800Gb WD Ultrastar DC SS530 WUSTR6480ASS204) + 8 SSD 1,92Tb (Western Digital Ultrastar DC SS530).

Эти «железки» предназначались для кластера VMware (HA+DRS+vSAN). Который уже работал у нас почти 3 года на аналогичных серверах 7-го и 8-го поколений, тоже от компании HPE. К слову, никаких проблем не было до тех пор, пока компания HPE не отказалась от их поддержки и обновить ESXi с версии 6.0, хотя бы до 6.5, без бубна не получилось. Ну да ладно, обновить в итоге удалось. Путем изменения установочного образа, удаления из установочного образа несовместимых проблемных модулей и т.д. Это тоже подлило масла в огонь нашего желания соответствовать всему новому. Конечно, если бы не новые «фишки» vSAN, в гробу мы видели обновление всей системы с версии 6.0 до более новой, и статью писать было бы незачем, но мы легких путей не ищем же…

Значит, приобрели мы данное оборудование и решили заменить давно устаревшее. Применили последний SPP к каждому новому серверу, установили в каждый из них по две сетевые карты Ethernet 10G (одну для пользовательских сетей, а вторую — для SAN, 656596-B21 HP Ethernet 10Gb 2-port 530T). Да, в комплекте с каждым новым сервером шла сетевая карта SFP+ без модулей, но у нас сетевая инфраструктура подразумевала Ethernet (два стэка коммутаторов DELL 4032N для сетей LAN и SAN), а модулей HPE 813874-B21 у дистрибьютора HP в Москве не оказалось и мы их так и не дождались.

Когда наступила пора установки ESXi и включения новых узлов в общий датацентр VMware, случилось «чудо». Как оказалось, HPE ESXi Custom ISO версии 6.5 и ниже не предназначен для установки на новые серверы Gen10. Только «хардкор», только 6.7. И пришлось нам невольно следовать заветам «виртуальной компании».

Был создан новый кластер HA+DRS, создан кластер vSAN, всё в непреклонном соответствии с VMware HCL и данным документом. Все было настроено по «феншую» и вызывали подозрение лишь периодические «тревоги» в мониторинге vSAN о ненулевых значениях параметров в данном разделе:



Мы, со спокойной душой, переместили все виртуальные машины (около 50 штук) на новые серверы и в новое хранилище vSAN, построенное уже на SSD дисках, проверили производительность обработки документов в новой среде (к слову, получилось сэкономить намного больше времени, чем планировали). Пока не перенесли самую тяжелую базу в новый кластер, операция, о которой упоминалось в начале статьи, заняла примерно 4 часа вместо 25-и! Это был весомый вклад в предновогоднее настроение всех участников процесса. Некоторые, наверное, начали мечтать о премии. Потом все радостно ушли на новогодние праздники.

Когда начались будни нового, 2019 года, ничто не предвещало катастрофы. Все сервисы, перенесенные на новые мощности, без преувеличения, взлетели! Только событий в разделе повторной синхронизации объектов стало намного больше. А через пару недель произошла беда. Ранним утром, практически все ключевые сервисы Компании (1с, MSSQL, SMB, Exchange и т.д.) перестали отвечать, либо начали отвечать с большой задержкой. Вся инфраструктура погрузилась в полный хаос, и никто не знал что произошло и что делать. Все виртуальные машины в vCenter выглядели «зелеными», никаких ошибок в их мониторинге не было. Перезагрузка не помогала. Более того, после перезагрузки, некоторые машины даже не смогли загрузиться, выдавая различные ошибки процесса в консоли. Казалось, Ад пришел к нам и дьявол потирал руки в предвкушении.

Находясь под давлением серьезного стресса, удалось определить источник беды. Этой проблемой оказалось распределенное хранилище vSAN. Случилось неконтролируемое повреждение данных на дисках виртуальных машин, на первый взгляд — безо всяких на то причин. На тот момент единственным решением, которое казалось рациональным, было обратиться в техническую поддержку VMware с криками: SOS, спасите-помогите!

И это решение, в последствии, и спасло Компанию от потери актуальных данных, включая почтовые ящики сотрудников, базы данных и общие файлы. В совокупности, речь идет о 30+ терабайтах информации.

Обязан отдать должное сотрудникам поддержки VMware, которые не стали «футболить» обладателя базовой подписки на техническую поддержку, а включили данный кейс в Enterpise сегмент, и процесс закрутился в круглосуточном режиме.

Что произошло дальше:

1. Технической поддержке VMware были поставлены два главных вопроса: как восстановить данные и как решить проблему «фантомного» повреждения данных в дисках виртуальных машин в «боевом» кластере vSAN. Кстати, данные некуда было восстанавливать, поскольку дополнительное хранилище было занято резервными копиями и разворачивать «боевые» службы было просто некуда.
2. Пока я, совместными усилиями с VMware, пытался собрать воедино «поврежденные» объекты в кластере vSAN, мои коллеги в срочном порядке добывали новое хранилище, способное вместить все 30+ терабайт данных Компании.
3. Меня ждали пять, почти бессонных ночей, когда сотрудники круглосуточной поддержки VMware из трех часовых поясов спрашивали меня, почему их встречаю лишь я и беспокоились насчет эффективности такого подхода, мол можно еще больше «накосячить» и совершить много лишних ошибок из-за сверх-сверх нормативного рабочего дня. Но ведь наши реалии вряд ли соответствуют западному пониманию, да?
4. Я обзавелся готовыми инструкциями в случае повторения данной ситуации.
5. Пришло понимание, где «собака зарыта» в данной проблеме.
6. Были восстановлены все виртуальные машины на появившееся благодаря подвигу коллег хранилище, кроме пары несущественных, которые были «воскрешены» из резервных копий на теперь доступное дисковое пространство.
7. Пришлось временно (на пару дней) пожертвовать работоспособностью почты, ради дополнительных 6 терабайт свободного пространства в хранилище, чтобы запустить ключевые сервисы, от которых зависел доход Компании.
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

Как эта проблема проявлялась (помимо наглухо упавших сервисов организации).

Экспоненциальный рост ошибок контрольной суммы (CRC) «на ровном месте» в процессе обмена данными с дисками в режиме HBA. Как это можно проверить — в консоли каждого узла 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

В результате выполнения, вы сможете увидеть ошибки CRC по каждому диску в vSAN кластере данного узла (нулевые значения не будут отображаться). Если у вас имеются положительные значения, и более того, они постоянно растут, значит появилась причина постоянно возникающих задач в разделе 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.хххх… дисков в дисковых группах:

[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

Как узнать UUIDы vSAN по каждому naa....:

[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 контроллера и драйвера HPE с vSAN.
Ранее, в VMware 6.7 U1, совместимая прошивка для контроллера HPE Smart Array P816i-a SR Gen10 в vSAN HCL значилась версии 1.98 (которая оказалась фатальной для нашей организации), а теперь там указана 1.65.
Более того, версия 1.99, которая решала проблему на тот момент (31 января 2019 года) уже была в закромах HPE, но они ее не передавали ни VMware ни нам, ссылаясь на отсутствие сертификации, несмотря на наши увещевания об отказе от ответственности и всё такое, мол нам главное решить проблему с хранилищем и всё.

В итоге, проблему удалось окончательно решить лишь через три месяца, когда вышла версия прошивки 1.99 для контроллера дисков!

Какие выводы я сделал?

1. У нас есть дополнительное хранилище (помимо обязательных резервных копий), на которое в случае чего можно мигрировать всем колхозом.
2. Не буду покупать самое свежее железо! Лучше годик подождать.
3. Не буду использовать всё доступное пространство ради «хотелок» бизнеса, буду начинать «ныть» о покупке новых «хранилок» сразу после того, как останется менее 30% свободного пространства на всех доступных «железках».
4. HPE, в лице местного представителя, так и не признала свою ошибку и ничем нам не помогла.
5. Я считаю, что вина в случившемся лежит полностью на:
   
   
   • HPE -эта компания показала во всей красе качество своей поддержки в критической ситуации. И в целом, количество багов в оборудовании Enterprise сегмента заставляет меня тревожиться за наше будущее. Конечно, это лишь моё мнение, и оно ни к чему не подталкивает).
   • Мне — не предусмотрел ситуацию, когда может понадобиться дополнительное дисковое пространство для размещения копий всех серверов Компании в случае нештатных ситуаций.
6. Дополнительно, в свете всего произошедшего, для VMware я больше не буду покупать железки для крупных компаний, каких-либо вендоров, отличных от DELL. Почему, потому что DELL, насколько мне известно, приобрела VMware, и теперь интеграция железа и софта в данном направлении ожидается максимально тесная.

Как говорится, обжегся на молоке, дуй на воду.

Вот и всё, ребята. Желаю вам никогда не попадать в такие жуткие ситуации.

Как вспомню, аж вздрогну!