Загрузка 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 и версии драйверов.

Ограничивать ли пользователей по ресурсам?

Сколько я занимаюсь ИТ - столько я слышу от админов "больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу". И ровно столько же у меня возникает вопрос: какое ваше дело?
Давайте забудем, что мы ИТ-шники и управляем клевыми СХД, фермами серверов, поточвыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.

1. Чем занимается ваша компания?

Забудьте про производство туалетной бумаги, штанов или даже авиадвигателей.
Правильный ответ: она производит деньги. Причем так, чтобы произведенных денег получалось больше, ченм потраченных.

2. Кто производит деньги?

А их производят те самые "тупые юзвери", которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.

3. При помощи чего они производят деньги?

Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы - сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.

4. Кому принадлежит ИТ инфраструктура и ресурсы?

Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы "своими". Даже немного, и начинают относиться к ним соответственным образом.

Правильный ответ: они принадлежат компании (владельцу компании) и должны исполнять свою задачу по генерации денег.

5. И теперь - кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?

Как мне кажется, это абсолютно точно не должен быть ИТ админ. Просто потому что он понятия не имеет о том, как эти ресурсы приносят деньги.
Потребление ресурсов должно быть неограниченным со стороны ИТ, с практически нулевым весом ИТ в принятии решения о выделении ресурсов на ИТ инфраструктуре. Кроме разве что моментов, когда внезапный рост потребления может положить всю инфраструктуру целиком.

Необходима система внутреннего биллинга, которая вместо ограничения потребления попросту присылает в конце месяца счет начальнику отдела и фин. директору о том, кто сколько и каких ресурсов потребил. В рублях. Просто потому что именно эти два человека понимают какую доли прибыли генерирует данный сотрудник и сколько ему надо ресурсов для генерации этой прибыли.

Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.

1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.

Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям - но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.

2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.

Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки - и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.

3. У нас в ИТ ограниченный бюджет и мы не можем позволить им есть ресурсов сколько они хотят.

Позвольте, но это классический пример "административная проблема техническими средствами не решается". Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели - это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.
Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем "теневого ИТ".

И да, это все я рассказываю с 2014 года. "Департамент ИТ против частного облака"