SysAdminDay - 2021

Всех причастных с профессиональным праздником!

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

Не забывайте развиваться профессионально и лично! 

И обязательно получайте удовольствие от работы и достаточную финансовую компенсацию за ваш труд! ;-)

Автор: Шиболов Вячеслав Анатольевич

VMware и NUMA: результаты оптимизации конфигурации памяти VM

В прошлый раз в посте "VMware и NUMA: выбор правильного размера памяти VM" я рассказал о NUMA архитектуре, NUMA узлах (NUMA nodes) и о том, как оптимально сконфигурировать размер памяти виртуальной машины с учётом этих особенностей. Показал на своём примере, что можно создать не оптимально работающую виртуальную машину. При работе такой виртуальной машины процессор, обращаясь к оперативной памяти, не всегда может попадать в локальный NUMA узел. Это увеличивает задержки при обращении к памяти и снижает производительность виртуальной машины и приложений, работающих на ней.

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

Итак, я говорю про виртуальную машину из прошлого поста с 8 vCPU и 96 Гб памяти, которая работает на сервере с NUMA узлом = 16 ядер (с учётом HT) + 96 Гб. Как вы помните, по статистике из команды esxtop при работе данной виртуальной машины только в 92% случаях процессор попадал в локальный NUMA узел (рис. 1).

Рис. 1. Статистика по NUMA виртуальной машины 8 vCPU + 96 Гб до оптимизации.

Проанализировав требования к оперативной памяти со стороны приложений, я понял, что спокойно могу снизить количество оперативной памяти виртуальной машины. Изменил настройки, уменьшив оперативную память VM с 96 Гб до 80 Гб (рис. 2). 

Рис. 2. Количество оперативной памяти сервера после изменения конфигурации.

И картина тут же поменялась (рис. 3). Скриншот сделан на системе, проработавшей 2 недели.

Рис. 3. Статистика по NUMA виртуальной машины 8 vCPU + 96 Гб после оптимизации.

Во-первых, процент попадания в локальный NUMA узел стал 100% (параметр N%L, а NRMEM = 0), что не может не радовать. Во-вторых, теперь все процессы виртуальной машины выполняются на одном узле: параметр GST_ND0 = 81 582, а остальные GST_ND* = 0. Таким образом, на данный момент производительность процессов данной виртуальной машины в плане NUMA архитектуры оптимальна.

Изменить настройки памяти второй большой виртуальной машины пока не представляется возможным. Там по статистике, как и прежде, процент попадания в локальный NUMA узел - 92-93%. А ведь случай с этой машиной интереснее. Виртуальная машина большая и в один NUMA узел, даже после изменения конфигурации, не поместится.

Пишите в комментариях, какая статистика у вас и занимались ли вы NUMA оптимизацией на своих проектах.

Автор: Шиболов Вячеслав Анатольевич

Пятница, танцуем

I got that Chameleon in my pocket, Got that Penguin at my feet...

Автор: Шиболов Вячеслав Анатольевич

VMware и NUMA: выбор правильного размера памяти VM

Современные серверные решения на базе архитектуры x86, которые сейчас используются почти во всех программно-аппаратных комплексах, имеют некоторые нюансы. Многопроцессорные сервера, имеющие на материнской плате 2, 4 или даже 8 процессорных сокетов, являются по сути NUMA-архитектурой. NUMA (Non-Uniform Memory Architecture) означает, что каждый процессорный сокет имеет свой пул локальных модулей оперативной памяти и такая связка называется узлом NUMA (рис. 1).

Рис. 1. UMA и NUMA архитектуры.

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

Все современные операционные системы и программные решения более высокого уровня (например, виртуальный гипервизор или СУБД) понимают особенности этой архитектуры. В идеале, это понимание позволяет большинство операций выполнять с памятью локального процессора, не ходя в "дальние края" за памятью соседа. 

vSphere от VMware тоже прекрасно разбирается в NUMA. При конфигурировании виртуальной машины (если вы не активируете опцию "Enable CPU Hot Add") и при её работе гипервизор будет размещать виртуальные процессорные ядра (vCPU) и память виртуальной машины в один узел NUMA. Причём, эта функция работает по умолчанию, ничего отдельно настраивать не надо.

Это всё прекрасно работает для небольших виртуальных машин, которые занимают гораздо меньше памяти, чем имеется в одном узле NUMA. Для работы большого количества таких относительно небольших виртуальных машин на одном сервере решения виртуализации и были прежде всего разработаны. Но у нас немного другой профиль - SAP системы, которые обычно требуют много ресурсов процессора и памяти. 

Хочу на своём примере показать недостаточно корректную настройку размера виртуальных машин, с учётом NUMA архитектуры. На проекте, про который хочу рассказать, были сервера двух типов:

• 4-х сокетный сервер (8 ядер/16 потоков в каждом процессоре) и 384 Гб оперативной памяти,
• 2-х сокетный сервер (8 ядер/16 потоков в каждом процессоре) и 256 Гб оперативной памяти.

Таким образом, в сервере первого типа узел NUMA = 16 ядер (с учётом HT) + 96 Гб. 

А в серверах второго типа узел NUMA = 16 ядер (с учётом HT) + 128 Гб памяти. 

Понимая, всю ситуацию с NUMA архитектурой я разместил на серверах первого типа виртуальные машины с характеристиками:

• 16 vCPU + 192 Гб памяти,
• 8 vCPU + 96 Гб памяти.

А на серверах второго типа работают виртуальные машины с максимальным размером:

• 8 vCPU + 96 Гб памяти.

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

Но после прокачки своих знаний по VMware, мне открылось, что я совершил ошибку при конфигурации объёмов памяти. 

Для мониторинга работы виртуальных машин на узлах ESXi есть команда esxtop (аналог команды top в Linux) (рис. 2). Так вот, для мониторинга работы с памятью и NUMA диагностики, необходимо запустить команду esxtop, нажать "m", перейдя в мониторинг памяти. После этого нажать "f" и добавить к формату вывод статистику по NUMA (рис. 3).

Рис. 2. Основной экран утилиты esxtop.

Рис. 3. Активация просмотра статистики по NUMA узлам.

После этого на экране появится несколько важных полей:

• NHN - текущий домашний узел для виртуальной машины,
• NMIG - количество NUMA миграций с узла на узел,
• NRMEM (MB) - текущее количество "дальней памяти" (из соседней NUMA), используемой виртуальной машиной,
• NLMEM (MB) - текущее количество локальной памяти, используемой виртуальной машиной,
• N%L - текущий процент запрошенной виртуальной машиной памяти, являющейся локальной.

Последний параметр помогает проанализировать итог работы виртуальной машины на NUMA узлах. Если он равен 100%, значит производительность оптимальна. Если же ниже 100%, значит не всегда в процессе работы на реальных процессорных ядрах для текущей виртуальной машины идёт попадание в память локального узла NUMA.

По моей ситуации. Первые две большие виртуальные машины не всегда попадают в память локального NUMA узла (рис. 4 и 5). Напомню, что обе машины работают на серверах с размером узла NUMA = 16 ядер (с учётом HT) + 96 Гб.

Рис. 4. Статистика по NUMA виртуальной машины 8 vCPU + 96 Гб.

Рис. 5. Статистика по NUMA виртуальной машины 16 vCPU + 192 Гб.

Процент попадания в локальный NUMA узел 93% и 92% соответственно. Причём, если посмотреть по другим параметрам статистики: виртуальной машине при работе не хватает всего 6-7 Гб памяти на локальном узле. 

"Небольшие" виртуальные машины, работающие на серверах второго типа (с размером узла NUMA = 16 ядер (с учётом HT) + 128 Гб памяти), отлично умещаются в локальных NUMA узлах (рис. 6). Забора "чужой" памяти нет, всё работает оптимально.

Рис. 6. Статистика по NUMA виртуальной машины, работающей на сервере второго типа.

Моя ошибка при конфигурировании размера оперативной памяти больших виртуальных машин в данном случае была в том, что я не учёл накладные расходы гипервизора. Точнее я решил, что накладные расходы общие на весь сервер. А оказалось, что надо учитывать их на каждый узел NUMA. И более оптимально было бы взять не всю память NUMA узла для виртуальной машины, а максимум 90%. Оставив 10% на накладные расходы гипервизора и инфраструктуры VMware.

Максим Мошков рекомендует пользоваться правилом при конфигурировании любых ресурсов в среде VMware - 80% ресурсов можно использовать, а 20% всегда оставлять на запас, накладные расходы и тому подобное.

Если у меня будет возможность, то я переконфигурирую данные виртуальные машины, которые не оптимально попадают в узлы NUMA. И потом поделюсь с вами результатами статистики.

Update: результаты оптимизации можно найти в этом посте.

Автор: Шиболов Вячеслав Анатольевич

 

Сдача экзамена на сертификат VMware VCP-DCV 2021

Спешу поделиться с вами новостью, что в понедельник, 5 июля 2021 года, я сдал сертификационный экзамен по администрированию VMware. 

Как вы помните, в конце мая 2021 года я проходил интенсивный курс по администрированию VMware vSphere в учебном центре HPE у Максима Мошкова. В рассказе об этом курсе я упоминал, что по окончанию всем дают бесплатный ваучер на одну попытку сдачи сертификационного экзамена. Экзамен называется VMware Certified Professional - Data Center Virtualization 2021 (код 2V0-21.20 - VCP-DCV 2021). В изначальном письме после курса была информация, что ваучер будет действовать всего лишь пару месяцев. А когда мне его прислали, то оказалось, что срок действия у него до мая следующего года. Но это не важно. Всё равно запросил ваучер я уже в тот момент, когда полностью подготовился. Помимо присутствия на вышеупомянутом обучающем курсе я ещё раз перечитал выданные там материалы, сделал свои заметки-записи. На прочтение 1000 страниц у меня ушло больше 10 дней. Затем нашёл в сети Интернет парочку записей специалистов по VMware по администрированию последней версии vSphere (кому интересно, то вот ссылка 1 и ссылка 2). Документы очень похожи. Прочитал в рамках подготовки их тоже. Потом получил ваучер и запланировал экзамен. Ожидая сдачи, повторял свои заметки-записи.

По стоимости экзамена. На официальном сайте указана цена в $250, но при регистрации на экзамен цена стала $200 и скидка по ваучеру равна этой же сумме. Может быть цена для России ниже, не знаю. 

С прошлого года сдача (как и у SAP сертификатов) онлайн с англоговорящим проктором. Необходимо подготовить место - отдельная комната, пустой стол, ноутбук с камерой-микрофоном. За полчаса до начала с помощью телефона необходимо сфотографировать документ, удостоверяющий личность (у меня это были водительские права), сфотографировать комнату и сделать своё селфи. Потом телефон необходимо отложить, а всё последующее обращение идёт через ноутбук. Условия немного строже, чем при сдаче сертификатов в SAP: 

• необходимо закрыть все приложения, кроме защищённого и открытого на весь экран приложения для сдачи, 
• потребовали снять простые часы, 
• проктор во время сдачи просил убрать руки от лица и так далее. 

В общем, заставил меня понервничать. :) 

На экзамен даётся 130 минут. За это время надо ответить на 70 вопросов. Схема стандартная: есть вопросы с одним ответом, есть с несколькими (указано сколько правильных ответов). Проходим по всем вопросам, нажимаем завершить экзамен и сразу получаем результат на экране. За все вопросы максимум можно получить 500 балов. Для успешной сдачи надо набрать 300. То есть 60%. Я набрал 324 балла! То есть почти 65%. Причём, я бы не сказал, что вопросы были сложные. Может быть на вопросов 5-6 я не знал ответа, а остальные казались простыми. Но набрал-то всего 324 балла. По времени, кстати, у меня вышло 40-45 минут. 

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

Ещё стоит отметить, что планировал сдавать экзамен немного раньше, в середине или во второй половине июня, но повстречался с ковидом. Неприятно проболел 2 недели, на которые подготовку к экзамену пришлось прервать. Но рад, что это всё не помешало мне успешно сдать экзамен.

После сдачи экзамена указано, что результаты по сертификации появляются в течении 10 рабочих дней. Но мне уже на второй день пришло письмо со ссылкой на значок (электронный бейдж). А на сайте сертификационного центра VMware стал доступен для скачивания pdf-скан сертификата (рис. 1).

Рис. 1. Сертификат VCP-DCV 2021.

В общем, принимаю поздравления. :) Кто хочет тоже сертифицироваться по данному профилю, пишите на почту, всегда готов помочь советом.

Автор: Шиболов Вячеслав Анатольевич

В помощь системному администратору: MTPuTTY

На обучении по VMware, которое я проходил в конце мая, открыл для себя новую программу.  Наверное, многие из вас знают и пользуются программой для доступа к Unix операционным системам - Putty? Это небольшая, компактная программа позволяет открывать терминалы по протоколам SSH и Telnet и выполнять административные задачи на серверах. Я упоминал о ней в своём посте "Программное обеспечение для администратора". Программа имеет аскетичный интерфейс: у программы одно основное окно, где можно выполнять настройки и вести список сохранённых сессий. Терминалы открываются в отдельных окнах (рис. 1). 

Рис. 1. Основное окно программы Putty и открытый терминал.

Сохранённые сессии никак не организуются, хранятся в едином списке. Если хотите их сохранить и/или перенести на другой компьютер, то найти их можно в системном реестре Windows (рис. 2).

Рис. 2. Ветка системного реестра с сохранёнными сессиями Putty.

Программа, о которой я упоминал в начале поста - это MTPuTTY. Устанавливаются совместно с Putty и представляет собой надстройку над ней. То есть для работы терминалов используется стандартная, проверенная Putty. А данная утилита позволяет открывать все сессии во вкладках одного окна. Дополнительно возможна организация списка сохранённых сессий в древовидной структуре. Плюс есть возможность отправки скрипта (списка из команд) нескольким открытым сессиям. Утилита поддерживает сохранённые сессии из оригинального Putty, но переносить их в список этой программы и редактировать нельзя (рис. 3 - 1). Списки же самой MTPuTTY могут быть организованы гораздо удобнее (рис. 3 - 2).

Рис. 3. Основное окно программы MTPuTTY.

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

Сайт программы, откуда её можно скачать - тут. Так же там есть небольшая онлайн-справка в виде FAQ. 

Мне программа понравилась, добавил её к своим инструментам администратора.

У кого есть свои открытия в плане программ-утилит в помощь системным администраторам, прошу делиться в комментариях.

Автор: Шиболов Вячеслав Анатольевич