Nutanix User Group Russia 2017

Друзья, рад объявить о проведении Nutanix User Group Russia (sponsored by Intel).

Уже зарегистрировалось более 100 человек.

Будет проходить в Москве 20-го декабря. С 14-00 и до упора.
Место проведения - HopHead, Москва.

Будет много интересного - покажем Nutanix 5.5 (включая микросегментацию), будут доклады партнеров, заливное море крафтового пива, вкусная еда и прочие приятности.

Выступления партнеров:
Intel - Новинки Intel для гиперконвергентных сред (Xeon Scalable, Optane, 3D Nand, Ethernet)
Citrix - "Как размножаются ёжики - MCS vs PVS для VDI"
BitDefender - Защита данных в виртуальных средах
Arista - Сеть в эпоху гиперконвергентности

Восстанавливаем файловую систему загрузочного диска ESXi

Столкнулся с проблемой установки/обновления VMware Tools на машинах, работающих на одном из хостов в кластере:



С машинами, работающими на других хостах кластера такой проблемы нет, можно без ошибок установить/обновить VMware Tools.
После прочтения, предложенного в сообщении об ошибке KB Installing and upgrading the latest version of VMware Tools on existing hosts, подключился по SSH к проблемному хосту и обнаружил следующую картину:



Файловая система раздела, содержащего VMware Tools разрушена.
Первая мысль переустанавливать ESXi с нуля, но подумав пару минут, пришло осознание, ESXi все-таки Linux и должен быть путь «починить» файловую систему раздела без полной переустановки ESXi.

Возможно, данная проблема связана с KB High frequency of read operations on VMware Tools image may cause SD card corruption.
Начиная с ESXi 6.0 U3 появился дополнительный параметр, который позволяет при загрузке ESXi создать RAM диск, содержащий образы VMware Tools. Это снизит нагрузку на загрузочный диск при многократной установке VMware Tools.

Итак, первым делом выводим хост в Maintenance Mode.
Далее, нужно понять какой раздел смонтирован в папку /store (locker – это ссылка на store). Для это этого выполним команду:

vmkfstools -P /store

Обычно это 8 раздел загрузочного устройства (почему 8 раздел можно прочитать в статье Загрузка ESXi c USB/SD и что меняется, когда появляется vSAN):



Запускаем проверку диска для 8 раздела загрузочного диска:

dosfsck -a -w /dev/disks/mpx.vmhba32:C0:T0:L0:8

Бывает, что требуется ручное исправление ошибок на диске, тогда:

dosfsck -v -w -r /dev/disks/mpx.vmhba32:C0:T0:L0:8

Далее, удаляем содержимое папки /store и перезагружаем проблемный хост:

rm -r /store/*

При загрузке ESXi восстановит необходимые файлы и папки в store, но vib пакет с VMware Tools нам придется восстановить руками, можно это сделать, например, через Update Manager:




К сожалению, я сталкивался с ситуациями, когда USB/SD карты выходили из строя или «ломались» партиции на них. Вообщем, разбираться и «чинить» точно бы заняло кучу времени.
На этот случай есть возможность создания резервной копии конфигурации ESXi и последующего восстановления из нее. Все это описано в KB How to back up ESXi host configuration. Данная процедура работает и для хостов с VMware vSAN без необходимости эвакуировать данные с проблемного хоста.

Делаем резервную копию конфигурации, например, через PowerCLI:

Connect-VIServer -Server host_ip
Get-VMHostFirmware -VMHost host_ip -BackupConfiguration -DestinationPath C:\Temp

Переустанавливаем ESXi с нуля. И восстанавливаем настройки из резервной копии:

Connect-VIServer -Server host_ip
Set-VMHost -VMHost -State 'Maintenance'
Set-VMHostFirmware -VMHost host_ip -Restore -SourcePath C:\Temp\configBundle host_ip.tgz -HostUser root -HostPassword Password

Перезапуск Management agents в ESXi и терпение

Бывает такое, что ESXi отключается от vCenter, но виртуальные машины, запущенные на нем, продолжают работать, это означает, что проблема в сервисах гипервизора, отвечающих за коммуникацию с vCenter'ом (Troubleshooting an ESXi/ESX host in non responding state).



Самое очевидное решение, просто их перезапустить, но как раз в этом то может и крыться проблема.
Перезапустить hostd и vpxa (а именно эти сервисы отвечают за связь ESXi и vCenter), согласно Restarting the Management agents in ESXi, можно через Host Client (https://<esxihost>/ui/), подключившись к хосту через SSH или DCUI.
Как все легко, но обычно, когда есть проблемы с hostd и vpxa, то и Host Client перестает работать и выглядит вот так:



При этом по умолчанию SSH на ESXi хостах выключен. И соответственно остается только DCUI - радуемся, что у нас есть iDRAC, iLO, etc. или бежим к серверу.

Ну и здесь все не без проблем. Нажав F2 в DCUI и введя пароль нас ожидает новая проблема, ничего дальше не происходит, окошко логина висит, а в меню мы попасть не можем. Тут нам поможет только терпение, в таком состоянии логин может идти несколько минут, а бывает, что и 15-20 минут. Ждем.
Дождавшись входа на нужно найти пункт меню Troubleshooting Options и выбрать Restart Management Agents:



К сожалению, это не всегда помогает, иногда нужно подключится по SSH, почитать логи и выполнить какие-нибудь команды. Проще простого.
Для это нам нужно включить SSH через DCUI, выбираем пункт меню Troubleshooting Options и Enable SSH. Вот здесь нас снова ожидает большой сюрприз, DCUI перестает реагировать на клавиатуру. Это может продолжаться полчаса, а может и несколько часов. Терпение, ждем и SSH включен. Дело за малым, подключиться по SSH и выполнить команды:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

Загрузка 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 года. "Департамент ИТ против частного облака"

OpenStack как религиозная секта

После 14 лет работы с виртуальными машинами, и 10 лет работы с промышленными платформами виртуализации я решил разобраться в OpenStack. Вокруг только и разговоров о нем. VMware больше не нужна, VMware скоро умрет и останется только OpenStack. Но по мере знакомства со всем стеком и с сообществом все больше у меня появлялась убежденность, что я имею дело с сектой.

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

В рамках OpenStack существует свой, отдельный язык. Забудьте про сеть - это Neutron. Забудьте про систему хранения - это Cinder. Вся индустрия уже многие годы использует примерно устоявшиеся термины, и после VMware начать изучать Hyper-V не составит значительного труда. В случае с OpenStack надо начать с изучения нового языка, что еще раз подчеркивает раскол между "обычными" и "просветленными".

В рамках проектов по OpenStack приверженцы технологии неспособны к самокритике и здравой оценке ситуации. Провальные проекты - это всегда вина недостаточно веровавших в них заказчиков. Пропало несколько тысяч виртуальных машин - OpenStack не может быть виноват. Всегда виноват конечный потребитель.

При разговоре речь идет не о технологиях, она ведет о вере. "Ты должен верить" - прямая цитата одного из известных на рынке деятелей.

HP увольняет команду разработки OpenStack, Мирантис сокращает треть сотрудников. Ну и что, это же не имеет отношения к вере в.

Встречая любителя OpenStack на любом форуме, задумайтесь о его аргументации. Она сбивчивая, постоянная апелляция к неведомому "прогрессивному" человечеству и полное игнорирование реалий индустрии. TCO? Риски? Стоимость поддержки? Из всех аргументов можно услышать только "бесплатно" и "зато я могу допилить под себя". Ему не нужны успешные проекты, ему не нужны реальные результаты, это просто вербовка новых адептов в новую, измененную реальность.

Основа сообщества OpenStack - преимущественно "техногики", люди, которые слабо разбираются в глубоких технических моментах, но очень любят модную технологическую шумиху и обожают рассуждать/вариться в ней. Техногики сейчас практически везде и именно им надо сказать спасибо за проталкивание маркетинговых идей, которые не выдерживают никаких технических аргументов. Собственную техническую неграмотность техногики прикрывают лозунгом о мифической силе «сообщества» и миллионами глаз, которые теоретически найдут ошибку в открытых кодах.

К вниманию также предлагаются перлы докладчиков с OpenStack Day в 2015.

Highload 2016. Что уже умеют промышленные СХД. Видео

Друзья, по многочисленным просьбам выкладываю видеозапись доклада, скажем спасибо за нее организаторам!