Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN

Я уверен, что каждый из вас устанавливал ESXi тысячи раз, установка настолько простая, что, я думаю, вы даже не успевали задуматься, а что же на самом деле происходит в этот момент.

В этой статье я предлагаю разобраться подробнее, что же происходит во время установки ESXi. Начнем с того, что согласно документации ESXi Hardware Requirements ESXi можно установить на устройство размером минимум 1GB, это может быть USB stick, SD card, локальный диск, SAN/iSCSI LUN и набирающий популярность, но еще достаточно дрогой вариант – SATADOM, возможно применение vSphere Auto Deploy.

Лично мне варианты загрузки SAN/iSCSI LUN и vSphere Auto Deploy не нравятся. При проблемах с сетью хост даже не сможет загрузится, что еще сильнее усложнит поиск проблемы. Я не буду рассматривать эти варианты.

Как было сказано выше для установки ESXi достаточно накопителя объемом 1GB и если мы выберем такой накопитель и посмотрим на разделы, созданные при установке ESXi, то мы увидим следующую картину. Пять обязательных раздела (Начиная с ESXi 4.x MBR был заменен на GPT).

• Раздел #1. Самый маленький раздел, в нем находится загрузчик.
• Раздел #5. Содержит образ операционной системы гипервизора.
• Раздел #6. Содержит альтернативный образ операционной системы гипервизора.
• Раздел #7. Предназначен для сохранения coredump в случае PSOD (Pink Screen of Death).
• Раздел #8. Содержит образы VMware Tools и Floppy Images.

Все, вроде, очевидно кроме раздела #5 и раздела #6.

Основное отличие от традиционной операционной системы в ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi). При обновлении ESXi не перезаписывает предыдущую версию, а создает новый образ операционной системы гипервизора и сохраняет возможность «откатиться» в случае неудачного обновления.

Нажав «SHIFT+R» при загрузке гипервизора мы можем выбрать версию для загрузки.

Что же хранится в этих разделах? Образ гипервизора – это файл сжатый файл s.v00, который разжимается при загрузке и содержит операционную систему гипервизора. Корневой раздел (/etc, /lib и т.д.) появляется в результате распаковки образа, таким образом, корневой раздел располагается только в оперативной памяти хоста. Возникает резонный вопрос, а как сохраняются настройки? При плановом выключении все конфиги запаковываются в файл state.tgz, который сохраняется рядом с образом гипервизора. При каждой загрузке настройки читаются из этого файла. Если завершить работу гипервизора некорректно, то все несохраненные изменения в настройках гипервизора будут утеряны. (UPD. не совсем так, см. комментарий).

Что же изменится, если мы возьмем для установки диск объемом более 1GB (~5.2GB)?

Мы увидим, что появятся два дополнительных раздела:

• Раздел #2. Раздел Scratch, содержащий разнообразные log файлы vmkernel и других компонент гипервизора.
• Раздел #3. Весь оставшийся объем будет выделен под VMFS раздел. Он будет виден как Local Storage в vSphere Client и на нем можно будет размещать файлы виртуальных машин.

И последнее про разделы. Начиная с ESXi 5.5 был добавлен второй раздел для coredump. Самое интересное, что, если вы обновлялись до версии 5.5, то вы не найдете этот раздел, он не будет существовать. Он будет создан только при чистой установке ESXi (Two coredump partitions in ESXi 5.5?).

Связано это с тем, что объем оперативной памяти, установленный в сервера растет, и раздел объемом 110MB уже не способен уместить coredump современного сервера.

Все это мы можем увидеть и подключившись к гипервизору по SSH. Мы видим все 8 разделов на диске, размеры этих разделов соответствуют написанному выше.

Так же мы можем увидеть, что разделы altbootbank, bootbank, scratch и store смонтированы в соответствующие папки файловой системы.

Все вышесказанное справедливо для установки на локальный диск или SATADOM достаточного объема. Подключившись по SSH к ESXi серверу, мы можем увидеть, что ID разделов соответствуют ID смонтированных томов.

Если мы установили ESXi на USB stick или SD card поведение гипервизора меняется. Связано это с тем, что «живучесть» (endurance) USB stick или SD card очень низкая и,, если гипервизор начнет писать свои логи на них, то он выведет их из строя очень быстро.

При установке ESXi определяет тип загрузочного устройства и, если это USB stick или SD card, установщик не будет создавать Раздел #2 (Scratch), а папка Scratch будет ссылаться на /tmp/scratch. Подключившись к хосту через vSphere Client, мы увидим предупреждения, что логи сервера сохраняются на non-persistent хранилище и будут потеряны при перезагрузке.

Если в системе появится локальный Storage, то при очередной перезагрузке гипервизор увидит, что логи можно писать на него. В раздел scratch будет смонтирована папка .locker, находящаяся на этом локальном Storage, а предупреждение пропадет.

Как я уже писал выше, гипервизор при загрузке «живет» в памяти. Для этого используются RAM диски. RAM диск – это раздел или хранилище, находящиеся в оперативной памяти сервера, важно помнить, что при перезагрузке, все данные из RAM диска будет потеряны. Примером использования RAM диска является монтирование scratch в /tmp/scratch. С помощью команды esxcli system visorfs ramdisk list можно увидеть список всех RAM дисков.

Что же такое scratch и почему я уделил так много времени ему?

Это раздел, в который гипервизор пишет все свои логи, а в случае проблем и обращении в техническую поддержку VMware, логи очень важны!

Я настоятельно рекомендую разобраться с хранение логов в вашей системе и принять меры для надежного и понятного их хранения. Для этого можно ознакомиться с KB Creating a persistent scratch location for ESXi. Приведу здесь только скриншот алгоритма выбора гипервизором места хранения логов.

Отличным вариантом является использование Syslog сервера для сбора логов. Возможно у вас уже есть Syslog сервер для другого оборудования, если нет, то это хороший повод начать его использовать Configuring syslog on ESXi. Например, можно использовать VMware Log Insight. Если у вас куплен vCenter, то для небольшой инфраструктуры его можно использовать бесплатно.

С логами мы разобрались. Перейдем к coredump

Coredump как и логи является очень важным источником информации, необходимым для работы технической поддержки при расследовании инцидентов. В coredump записывается состояние системы при PSOD (при «падении» системы).

Как я писал выше, начиная с ESXi 5.5 таких раздела два, мы можем увидеть это на скриншоте ниже. 

Настоятель рекомендую проверить coredump разделы на ваших гипервизорах и в случае необходимости внести изменения Configuring a diagnostic coredump partition on an ESXi 5.x/6.x host и Configuring ESXi coredump to file instead of partition.

Важно заметить, что если вы используете в своей инфраструктуре ESXi хосты с объемом RAM памяти больше 512GB (и vSAN), то вам следует ознакомится с еще одной статьей из KB Extending an ESXi diagnostic coredump partition on a vSAN node. Дело в том, что стандартный раздел для coredump (2.5GB) может не вместить дамп и этот раздел нужно будет увеличить.

Появляется vSAN

vSAN приносит в нашу систему еще один набор логов - vSAN traces:

• vSAN traces help VMware support and engineering to understand what is going on internally with vSAN.
• It should be noted that these traces are *not* part of syslog.
• So if you setup a syslog server to capture VMkernel logs, you will not capture vSAN traces.
• vSAN trace files are not persisted with syslog because the bandwidth requirements are too high.  (Although with vSAN 6.2, we now persist just the “most important” traces along with syslog https://kb.vmware.com/kb/2145556).

И теперь необходимо заботиться о сохранности еще одного набора логов.

Что важно для нас, что vSAN traces ведут сябя аналогично scratch и если мы установили гипервизор на USB stick или SD card, то traces будут писаться в RAM диск и пропадут при перезагрузке.

Так как vSAN traces очень важны для восстановления данных при сбое, то при штатной перезагрузки наиболее важные из них записываются на персистентное хранилище:

Здесь должны быть выводы

1. У вас должен (обязан) быть syslog сервер и чем больше на него будет перенаправлено логов, тем легче будет увидеть корреляцию при сбоях. Отличной практикой является перенаправлять логи и серверов и сетевого оборудования и СХД на один syslog сервер. Это позволит вам сразу увидеть, что, например, сбой коммутатора повлек проблемы на виртуальной платформе.
2. Нужно быть внимательным с выбором загрузочного устройства для ESXi и помнить, что не все устройства одинаково полезны.
3. Еще раз перепроверить, что логи записываются на какое-то постоянное хранилище и к ним можно получить доступ.
4. Аналогично про coredump, перепроверить, что раздел для записи дампа существует, и он подходящего для хоста объема.
5. И раз я писал про vSAN, не могу не упомянуть, что все оборудование хоста должно быть в VMware Compatibility Guide, включая версии firmware и версии драйверов.