понедельник, 26 июня 2017 г.

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

суббота, 24 июня 2017 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

четверг, 9 февраля 2017 г.

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.

четверг, 2 февраля 2017 г.

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


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



среда, 7 декабря 2016 г.

nBeers Engineers 2016-1

Коллеги, мы решили сделать маленькое теплое и ламповое мероприятие в неформальном стиле.

nBeers Engineers - чтобы ИТ-инженеры, архитекторы и мастера на все руки могли пообщаться за кружечкой пива.
А мы в процессе заодно расскажем и даже покажем нашу новую версию Nutanix OS 5.0 Asterix.

13 декабря с 18-30 в баре "Пес Борода" (метро Трубная, ул. Трубная 15)

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

Регистрация закрыта.

вторник, 18 октября 2016 г.

VMworld EU 2016

STO8165, John Nicholson (@Lost_Signal)
VSAN Networking Deepdive

* Используйте мультикаст флад только для выделенных под VSAN VLANов
* Если у вас несколько кластеров VSAN в одном VLAN - поменяйте им мультикаст адреса, чтобы каждый кластер имел свой уникальный. Или разнесите по разным VLAN
* Не делайте VSAN поверх L3 если не уверены зачем это делаете
* Для больших и нагруженных кластеров VSAN очень чувствителен к степени переподписки аплинков. В качестве средней температуры можно взять 4 к 1, но для каждого случая надо смотреть конкретнее
* Идеальный вариант коммутаторов для VSAN - со связями запад-восток. Осторожнее с Cisco FEX - там все через аплинк
* Jumbo frames не имеют большого значения для VSAN
* Локализация ввода-вывода (data locality) не имеет большого смысла для VSAN, ведь каждая запись должна все равно идти через сеть. /* Nutanix смотрит на это утверждение с удивлением.
* Начиная с 6.5 поддерживаются микрокластеры из двух узлов с прямым подключением между узлами (кросс-кабелем).
* Растянутый кластер требует VSAN Enterprise и поддерживается с сетями 10G 5ms RTT. 1 Гбит в целом поддерживается, но не рекомендуется.
* Для растянутого кластера требуется cluster witness. Он может быть виртуальной машиной или ESXi хостом (для него не требуется лицензия). Сетевое подключение - не менее 100 мегабит. /* Nutanix снова смотрит с удивлением, обходясь 2 мегабитами.
* Дедупликация идет фиксированными блоками 4 кб для All-Flash. Гибридный VSAN не поддерживает дедупликацию. /* Nutanix махнул рукой, ушел

INF8701, Brett Guarino
vSphere Core 4 Performance Troubleshooting and Root Cause Analysis, Part 2: Disk and Network

* VMXNET драйвер работает в ring 1, E1000 - ring 2
* Почти все сводится к esxtop
* Хотите при помощи esxtop анализировать сеть? Купите БОЛЬШОЙ монитор
* Ключевые показатели при анализе сети в vSphere
- используемые физические аплинки для каждого vmnic
- фактическая скорость на vmnic
- счетчик пакетов и средний размер пакета на vmnic
- отброшенные пакеты на vmnic
- фактическая скорость на физическом интерфейсе
- счетчик пакетов и средний размер пакета на физическом интерфейсе
- отброшенные пакеты на физическом интерфейсе
* Исследование дисковой системы - это куда больше веселья, чем сети :)
* Ключевые показатели - IOPS, задержки и фактическая скорость в мегабайтах в секунду
* Ситуации с DAVG/KAVG:
- низкий/низкий - идеально
- низкий/высокий - перегруженный хост
- высокий/низкий - перегруженная СХД
- высокий/высокий - проблема и там, и там. Но иногда слишком перегруженная СХД ведем к перегрузке дискового стека хоста.
** остаток доклада по дисковой системе фактически повторяет мою презентацию на VMUG 2014 в упрощенном виде. (http://blog.vadmin.ru/2014/06/vmug-2014.html)


VIRT8530, Rob Girard, Shawn Meyers
Deep Dive on pNUMA and vNUMA - Save Your SQL VMs from Certain DoomA!

* SQL не очень работает на AMD NUMA. Ставьте Intel. /* речь, разумеется, о широких SQL
* Неправильная конфигурация NUMA может вести к падению производительности до 40%
* По умолчанию vNUMA включается только при 9+ vCPU ВМ.
- Если у вас 4 или 6-ядерные процессоры и ВМ с большим количеством vCPU, чем ядер на процессоре - у вас будут проблемы с NUMA
- Можно исправить при помощи numa.min.vcpu для ВМ
* Лучший сайзинг ВМ - это много сокетов по 1 ядру. В этом случае автоматика отработает и ситуация будет близка к идеальной
- как только вы измените количество ядер на отличное от 1, конфигурация vNUMA зафиксируется
- vSphere определит топологию NUMA на первой загрузке. Это фиксируется в .vmx
- Используйте более одного ядра на сокет только для приложений с лицензированием по сокетам
- Если вы уверены в том, что делаете - сделайте сайзинг по границам узлов
* Идеальный сайзинг ВМ по vCPU - число, кратное одному узлу NUMA. Т.е. для 12-ядерного узла это 1, 2, 3, 4, 6, 12. На практике 3 vCPU ВМ работает на 6-ядерном процессоре лучше, чем 4vCPU.
* vSphere 6.5 позволяет сделать двойной финт - обмануть приложение по лицензированию, и при этом технически использовать автосайзинг NUMA
- numa.vcpu.followcorespersocket = 0 (по умолчанию)
- если установить в 1, то вернется старое поведение
* Расширенные настройки. !!! Опасно !!! Только если вы действительно понимаете что делаете
- numa.vcpu.maxPerVirtualNode = 8 (по умолчанию) - для расширения ВМ на дополнительные NUMA узлы
- numa.vcpu.preferHT = False (по умолчанию) - использовать потоки HT вместо дополнительных узлов NUMA. Для некоторых нагрузок важнее остаться в пределах одного узла.
- numa.vcpu.min = 9 (по умолчанию) - когда vNUMA начинает использоваться
- numa.autosize = False (по умолчанию) - пересчитывать топологию NUMA каждый раз при загрузке ВМ. Рекомендуется в True.
- numa.autosize.once = True (по умолчанию) - рассчитывать топологию NUMA при первой загрузке ВМ. Рекомендуется в False.
- numa.autosize.cookie = [автогенерируемое] - автоконфигурация vNUMA. 160001 = 16 сокетов, 1 ядро
- numa.autosize.vcpu.maxPerVirtualNode = [автогенерируемое] - сколько ядер на каждый узел NUMA при автосайзинге.
* Если в .vmx присутствуют numa.autosize.vcpu.maxPerVirtualNode или cpuid.coresPerSocket - автосайзинг не используется
* CPU HotAdd для виртуальной машины отключает vNUMA
* Memory HotAdd работает по разному
- HW ver 8-10 добавляет память в vNUMA node 0, что приводит к дисбалансу
- HW ver 11 балансирует память между vNUMA узлами
* Настройки vNUMA на уровне хоста в абсолютном большинстве случаев НЕ НАДО трогать.
* Перед тем как винить vNUMA проверьте все остальное.
* Не делайте 4-сокетную ВМ на 2-сокетном сервере.