С наступающим Новым 2022 Годом!

Всех, кто читает мой блог постоянно или заглянул сюда случайно, хочу поздравить с наступающим Новым Годом!

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

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

Оглядываясь назад, могу сказать, что в этот год (как и в год предыдущий) было достаточно много обучения и сертификации. В начале 2021 года я сертифицировался, как администратор базы данных SAP HANA, прочитав книгу для подготовки от Denys van Kempen и сдав экзамен со второй попытки. А летом я прошёл обучающий курс по администрированию VMware vSphere и сдал сертификационный экзамен VMware VCP-DCV 2021. 

При этом между обучением и сертификацией по VMware я переболел ковидом, потерял во время болезни 6 кг, после чего в течении 2-3 месяцев благополучно восстановился.

Весной и осенью я два раза прочитал свой мастер-класс по основам транспортной системы. Отзывы посетивших положительные. Поэтому, если у кого-то есть пробелы в этой теме, добро пожаловать на следующие сессии SAPLand. :)

Ещё в этом году я обновил свой обучающий курс, выпустив версию SAPADM 2.1. Подробности в недавнем посте.

В сентябре жизнь нашей семьи резко изменилась - у нас родился сынишка. Конечно, теперь иногда тяжело. Добавились новые хлопоты, хронически хочется спать. :) Но рождение и взросление маленького человека это огромное, интересное приключение похожее на чудо.

Что касается свободного времени, то на чтение книг в этом году катастрофически не хватало времени. Раньше я тратил на это всё время, что проводил в общественном транспорте по пути на работу и обратно. Сейчас, с удалённой работой, почему-то сэкономленное время на дорогу съедает та же работа. Прочитал за год только 12 книг. Ничего интересного посоветовать не могу. По фильмам картина немного лучше. Минимум 40 фильмов и сериалов, но посоветовать тоже нечего. Просмотр чаще всего был просто приятным времяпрепровождением.

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

Надеюсь, что этот год для вас также не прошёл впустую. Уверен, что каждый из вас найдёт то, что он сделал в этом году и чем он может хоть немного гордиться или даже похвастаться. :) 

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

До встречи в следующем году! 

Без вас не было бы смысла писать в этот блог. Спасибо, что читаете.

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

Обновление курса обучения SAP Basis: версия SAPADM 2.1

Друзья, перед Новым Годом хочу поделиться новостью для тех, кто планирует освоить новую профессию SAP BASIS администратора. Или просто хочет упорядочить свои знания, заполнить пробелы, поэкспериментировать на учебной системе. Я решил обновить свой обучающий курс и выпустить версию SAPADM 2.1.

Данная версия - это скорее не революция, а эволюция. Курс 2.0 был ещё раз вычитан. Досадные ошибки и опечатки были исправлены, обновлено большинство снимков экранов. Я постарался учесть замечания и пожелания. А некоторые фразы были переписаны для улучшения понимания предмета или темы. Ну и добавлены новые ссылки на полезные статьи и материалы по темам.

Основа осталась прежней (как и в курсе SAPADM 2.0):

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

А что же нового:

• переход на свежую версию openSUSE Linux: с 42.3 перешли на версию 15.3 (как я уже писал, она максимально близка к корпоративной версии SLES 15 SP3, следовательно процесс установки/подготовки тоже максимально приближен к реальным условиям),
• переход на свежую версию SAP системы - SAP NetWeaver AS for ABAP 7.52 (используется в S/4HANA 1709),
• переход на новейшую версию Oracle 19с (предыдущий пакет был на Oracle 12g),
• переход на самую последнюю версию клиентского программного обеспечения - SAP GUI 7.70 (про первый взгляд на эту версию можно почитать тут),
• для установки системы используется последняя версия утилиты SWPM 1.0 SP33,
• переход на среду виртуализации от VMware (никто не запрещает использовать и VirtualBox).

Остальные плюшки остались таким же, как в версии SAPADM 2.0.

На данный момент обновлено 2 первых пакета заданий (базовую стоимость повышать не стал):

• SAPADM 2.1. Пакет 1 - Стоимость: 24 000 рублей, 
• SAPADM 2.1. Пакет 2 - Стоимость: 24 000 рублей.

Описание пакетов:

Количество страниц в пакетах немного выросло, каждый прибавил примерно по 20 страниц. Но в целом объём остался сопоставимым с предыдущей версией.

В планах переписать третий пакет заданий под Oracle 19c. Ну и будущие пакеты будут основаны на этой версии системы.

Постоянные страницы (ссылка1, ссылка2) с обучением также были обновлены. 

Теперь небольшие подарки на Новый Год. :) Cкидка в честь релиза: 18,75% (-3000 рублей с пакета) тем, кто купит курс (1 или 2 пакета) до 09 января 2022 года.

Кто заинтересовался, пишите на мой адрес - shibolov@gmail.com с указанием в заголовке письма названия обучающего курса - SAPADM 2.1.

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

Опрос: удалённая работа vs работа в офисе

Что-то давно я не проводил опросов в своём блоге. 

Давайте посмотрим как много из нас работает удалённо, а сколько коллег ездит в офис в наше непростое время. :)

Я лично работаю удалённо с апреля 2020 года. Уже полтора года. Сначала было очень непривычно, но сейчас вроде бы втянулся. Плюсы и минусы есть в любом режиме.

Минусом удалёнки является наличие многих отвлекающих факторов. И это часто не близкие, а вся обстановка в целом. Поэтому отвлекаются и те, кто работает дома один и те, у кого размер жилплощади позволяет рассредоточиться по комнатам. Дома обстановка всё равно домашняя. Чтобы настроиться на рабочий лад (и не смотреть в сторону дивана или кухни) приходится приложить определённые усилия. А поход на работу - это как поход в спортзал. Если уж пришёл, то работай. :) 

Хотя и в офисе не у всех отдельный кабинет и идеальные условия. Но всё равно с походом в офис удобнее разделять день на рабочие и личные часы. Это разделение вторая проблема удалённой работы.

Идеальным, наверное, был бы гибридный режим. Но он пока трудно достижим.

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

Итак, опрос. Выберете свой вариант ответа, а после праздников подведём итоги. А своим опытом по вашему любимому варианту работы можете поделиться в комментариях.

В опросе приняло участие 39 человек. В результате удалённая или гибридная работа в большинстве.

Спасибо всем за участие.

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

Сброс буферов SAP инстанции

В 2015-2016 годах я публиковал цикл из 5 статей про буферизацию на уровне сервера приложений SAP. Если вы ещё не читали, то рекомендую ознакомиться. Финальный пост и ссылки на предыдущие статьи серии можно найти тут. 

Буферы на уровне сервера приложений SAP (его AS ABAP части) играют важную роль в производительности системы (рис. 1). Буферы недостаточного размера могут существенно замедлять скорость выполнения транзакций и считывания данных, а также увеличивать время отклика при работе в системе. Не так давно, в постах (ссылка 1, ссылка 2) на реальном примере я показал как можно проанализировать и внести корректировки в настройки областей памяти и буферов SAP инстанции. В результатах невооружённым взглядом видно, что правильно настроенные области могут ускорить работу системы.

Рис. 1. Пример списка буферов SAP инстанции, отображаемых в транзакции ST02.

Сегодня хотел бы поговорить про ошибки в работе буферов. Любая программа, особенная такая сложная как SAP система, в некоторых ситуациях может давать сбои. И работа с буферами не исключение. Иногда, в буферах могут "застревать" некорректные данные. И система по какой-то причине, вместо обновления из таблиц, будет пытаться использовать некорректные данные из буферов. Например, старую версию программы (программный буфер), данные из таблиц, экранов и так далее. 

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

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

Данные команды я уже упоминал в этом посте, но решил вынести их в отдельный пост. Так будет легче найти их в блоге. Вот эти команды:

• /$SYNC - сброс всех буферов, кроме Program Buffer,
• /$CUA - сброс CUA buffer,
• /$TAB - сброс TABLE buffer (в зависимости от версии системы: двух или одного),
• /$TAB <table_name> - сброс буферов только для таблицы <table_name>,
• /$NAM - сброс Nametab buffer,
• /$DYN - сброс Screen buffer,
• /$ESM - сброс Exp./ Imp. Shared Memory Buffer,
• /$PXA - сброс Program Buffer (PXA),
• /$OBJ - сброс Shared Buffer.

Команды сброса надо набирать в поле ручного ввода транзакции в SAP GUI (рис. 2). Действуют они только на текущую инстанцию. 

Рис. 2. Ввод команды для сброса табличных буферов SAP инстанции.

Про последнюю команду (/$OBJ) в прошлый раз я не упоминал. Она добавилась. Дополнительное упоминание про сброс этого буфера можно найти в SAP note # 100923 - Problems during displacement in the shared buffer.

При принятии решения о сбросе буферов инстанции помните, что: 

• Сброс буферов резко снижает производительность работы данной инстанции.
• Сброс буферов (также как и рестарт инстанции) может помочь привести систему в порядок, но первопричину сбоя таким способом вы не решите. 
• Делайте сброс только понимая что вы делаете. 
• Постарайтесь выявить конкретный буфер и сбросить только его, а не все буферы сразу (/$SYNC). 

Дополнительно существует возможность сбросить буфер полномочий для пользователя. Вот в этом посте я рассказывал про то, как с помощью транзакции SU53 проанализировать каких полномочий не хватает пользователю в SAP системе. А вот тут рассказывал про буфер полномочий, который хранится в контексте пользователя. В SU53 можно сбросить этот буфер: выберете пункт меню "Значения полномочий (Authorization values) -> Сбросить буфер пользователя (Reset User Buffer)" и буфер текущего пользователя сбросится (рис. 3).

Рис. 3. Сброс буфера полномочий для пользователя.

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

P.S. Я понимаю, что я могу знать далеко не всё. Если у вас есть дополнения по этой теме, то напишите в комментарии. Спасибо.

Особенности мониторинга ресурсов виртуальных машин в VMware vSphere

В прошлый раз я писал о том, как настроить виртуальные машины, работающие в среде VMware Workstation, для обеспечения их максимальной производительности. Сегодня же хотел поговорить про решения Enterprise уровня от компании VMware. А в частности про мониторинг использования ресурсов виртуальных машин в VMware vSphere.

Если кто-то не сильно разбирается в маркетинговых названиях, поясню. У компании VMware есть гипервизор, который устанавливается на физическую машину, называется он - VMware ESXi. Для управления и мониторинга у ESXi имеется встроенная графическая web-консоль. Но, если виртуализированных хостов в дата-центре много, то управлять этим хозяйством становится сложнее. Так как для мониторинга или изменения конфигурации гипервизоров необходимо входить на web-консоль каждого ESXi. Для упрощения данной задачи (конечно, за отдельные деньги) компания предлагает решение VMware vCenter. В этом случае выделенный виртуальный сервер  предоставляет единую точку входа для мониторинга, управления и конфигурации ESXi хостов вашей организации. Помимо общей точки входа вы получаете дополнительные функции, например, vMotion (перенос работающих виртуальных машин между ESXi хостами) или HA кластер. Комплексное решение "ESXi + vCenter" и называется VMware vSphere. Достаточно подробно про эти решения я рассказывал в этом посте. 

Раз с названиями разобрались, двигаемся дальше, ближе к теме сегодняшнего поста. 

На хосте под управлением гипервизора ESXi работают виртуальные машины. Мониторинг ресурсов сервера (процессор, память, сеть и т.д.) в случае виртуализации рекомендуется выполнять не на уровне операционной системы виртуальной машины, а (если вам это доступно) на уровне гипервизора VMware.

Web-консоль VMware ESXi позволяет выполнять мониторинг виртуальных машин лишь в реальном времени: статистика по загрузке процессоров, памяти, дисков и сети собирается и хранится только за последний час (рис. 1).

Рис. 1. Пример панели мониторинга процессора виртуальной машины в ESXi.

Согласитесь, что для промышленных систем это несерьёзно. Мониторинга фактически нет. Можно отметить, что на уровне операционной системы ESXi сервера (помните, что в основе это Linux) есть утилита esxtop (я упоминал про неё тут), но она тоже показывает только текущую нагрузку в системе. 

В свою очередь VMware vCenter имеет гораздо больше возможностей по мониторингу. В его консоли отображается не только текущая картина потребления ресурсов, но и собирается база статистики за прошедшие периоды. Можно выбрать различные метрики: процессорные ресурсы (загрузка в % или в MHz), оперативная память, swap-область, дисковая подсистема (несколько метрик), сеть и так далее. Данные для каждой метрики можно выбрать из стандартного набора интервалов:

• real-time,
• last day,
• last week,
• last month,
• last year,
• или задать свой интервал через custom interval.

Режим отображения real-time похож на то, что можно найти в консоли ESXi и обладает самой высокой точностью данных. Достигается это за счёт частоты сбора. Мне кажется, данные собираются раз в секунд 15-30. А вот дальше есть интересный нюанс, ради которого я и начал писать этот пост. Все остальные интервалы отображают менее детализированные данные, так как vCenter автоматически выполняет агрегацию данных. Если войти в раздел "Configure -> Settings -> General" вашего виртуального Datacenter, то можно увидеть параметры для сбора статистики. Значения по умолчанию выглядят так (рис. 2).

Рис. 2. Настройки сбора и агрегации статистики производительности.

Обратите внимание, что для статистики сохранённой за последний день (last day) данные собираются раз в 5 минут, для последней недели (last week) раз в 30 минут, для месяца (last month) раз в 2 часа, а для года (last year) раз в день. Вы можете попробовать поменять настройки, но обнаружите, что самые глубокие доступные значения параметров для хранения статистики выглядят так (рис. 3).

Рис. 3. Максимально глубокие значения для хранимой статистики.

Подкрутить можно только первый уровень: для последних 5 дней хранить данные с частотой 1 минута. Глубину данных за более длительные периоды изменить нельзя. 

Кстати, хочу обратить внимание, что при изменении этих настроек VMware дополнительно рассчитывает требования к дисковому пространству для хранения статистики (рис. 3). Причём, вы можете подкорректировать количество хостов и виртуальных машин в вашем Datacenter для отображения более реальных значений для текущей инфраструктуры. 

Снижение глубины статистики для прошедших периодов было бы не такой большой бедой, если бы не логика работы vCenter в этой части. Снижая частоту хранимых исторических данных, он не просто отбрасывает лишние значения, а автоматически агрегирует данные, усредняя значения. То есть для статистики, хранимой за последнюю неделю, берётся среднее значение с параметров за каждый 30 минутный интервал. А для интервалов старше недели, вообще за каждые 2 часа. Такая логика работы, как я понял, жёстко зашита в vCenter и приводит к сглаживанию показателей нагрузки в зависимости от запрашиваемого интервала. 

Давайте я продемонстрирую это наглядно на одной из систем. Рассмотрим статистику по загрузке процессора виртуальной машины последовательно за разные периоды (рис. 4 - 8).

Рис. 4. Просмотр статистики загрузки CPU в реальном времени.

Рис. 5. Просмотр статистики загрузки CPU за последние сутки.

Рис. 6. Просмотр статистики загрузки CPU за последнюю неделю.

Рис. 7. Просмотр статистики загрузки CPU за последний месяц.

Рис. 8. Просмотр статистики загрузки CPU за год.

Замечаете как показатели утилизации процессора из 50-75% постепенно превращаются в 40-60%, потом опускаются ниже 50%, а в годовом разрезе вообще не поднимаются выше 15%? :) 

Рассмотрим ещё один пример. График загрузки процессора виртуальной машины за неделю показывает пиковые значения не выше 60%, и то только один раз. В остальные дни не выше 50%. Можно сделать преждевременные выводы, что процессорных ресурсов данной системе хватает.

Рис. 9. Пример статистики загрузки процессора виртуальной машины за неделю.

А при этом на интервалах real-time для данной виртуальной машины фиксировались пики до 100% (рис. 10-12).

Рис. 10. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 11. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Рис. 12. Мониторинг загрузки процессора виртуальной машины в реальном времени.

Если же обратиться к статистике за месяц, то опять видим ту же картину: пики едва превышают 40%. Сравните последние дни на разных графиках, где мы точно знаем, что были значения и по 100%. На графике с большим периодом отображения таких значений просто нет: они сглажены агрегацией (рис. 13). 

Рис. 13. Пример статистики загрузки процессора виртуальной машины за месяц.

Какие выводы из всего этого можно сделать? 

Во-первых, нужно учитывать эту особенность сбора и отображения статистики по загрузке ресурсов виртуальной машины в VMware. Годовой график смотреть смысла нет, статистика гораздо ниже реальной. И даже в помесячном разрезе сглаженный график ниже реального где-то на 50%. 

Во-вторых, периодически смотрите график в реальном времени, сравнивая его значения с недельной или месячной статистикой. Только в этом разрезе можно увидеть реальные значения нагрузки на систему. 

Для некоторых приложений могут быть критичны, например, процессорные ресурсы сервера. И при их нехватке (достижении утилизации в 100%), даже на короткий период, происходят события в виде отказа в обслуживании или резкого снижения производительности приложений. 

Виртуализация позволяет оптимизировать утилизацию ваших ресурсов за счёт размещения на одном физическом сервере нескольких виртуальных серверов. Но при проектировании виртуальных машин мы должны обеспечить достаточность процессорных ресурсов. Мы же используем виртуализацию для оптимизации, полагая что процессорные ресурсы в полном объёме физического сервера приложениям в этой виртуальной машине не нужны. А, если приложения утилизируют все ресурсы виртуальной машины, упираясь в ограничения, наложенные гипервизором, то значит ресурсы были распределены некорректно. Или за время в пути собачка могла подрасти. 

В любом случае, эти ситуации надо отслеживать и, если есть возможность, вносить корректировки в настройки виртуальных машин. С другой стороны, сразу давать виртуальным машинам очень много процессорных ресурсов тоже не рекомендуется. Это приводит к снижению производительности виртуальной машины. Наша цель: найти баланс по ресурсам. Чтобы их было не много, но и недостатка тоже не наблюдалось. 

В отслеживании пиков в потреблении процессорных ресурсов может помочь настройка Alarms в vCenter. По умолчанию существует Alarm с именем "Virtual machine CPU usage", который срабатывает при потреблении больше 75% процессорных ресурсов в течении 5 минут (рис. 14).

Рис. 14. Настройки Alarm "Virtual machine CPU usage".

Возникновение этих событий для виртуальной машины в прошлом можно найти в разделе Events (рис. 15).

Рис. 15. История возникновения событий превышения утилизации процессора виртуальной машиной.

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

Все эти рассуждения справедливы так же для распределения и мониторинга других ресурсов виртуальных машин: оперативной памяти, сети, дисков.

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

Настройка максимальной производительности в VMware Workstation

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

Вы наверное знаете, что среды виртуализации можно разделить на 2 типа:

• тип 1 - физический гипервизор (bare metal hypervisor), который устанавливается на физический сервер.
• тип 2 - гипервизор, устанавливаемый поверх операционной системы (hosted hypervisor). 

Примером гипервизора первого типа является VMware ESXi. Эта среда виртуализации, включающая в себя гипервизор со своей операционной системой, устанавливается напрямую на физический сервер. SAP системы в той или иной степени поддерживают это решение от VMware и про это у меня уже была пара постов (ссылка 1 и ссылка 2). 

Ко второму типу гипервизоров относятся решения Oracle VirtualBox и VMware Workstation. Для их разворачивания требуется операционная система, предварительно установленная на целевой сервер или компьютер (host server). Поддерживаются распространённые операционные системы: MS Windows, Linux или MacOS. Данный тип гипервизора выбирают для небольших проектов. Обычно разработчики программного обеспечения используют их для тестирования своих разработок в разных операционных системах. 

VMware Workstation поставляется в двух версиях: 

• VMware Workstation Pro (требует приобретения платной лицензии),
• VMware Workstation Player (распространяется бесплатно для личного пользования).

В бесплатной версии нет шифрования виртуальных машин и нельзя для них создавать снимки состояния (snapshots). А в остальном это полноценное решение, где можно как создавать, так и запускать виртуальные машины. 

Перейдя на VMware Workstation, как взрослый администратор :), я поставил себе задачу получить максимальную производительность виртуальных машин, работающих на моём рабочем ноутбуке. Собранной в процессе решения задачи информацией решил поделиться с вами. 

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

• процессорные ресурсы,
• оперативная память,
• жесткий диск,
• другое оборудование,
• программное обеспечение,
• другое (всё остальное).

Процессорные ресурсы

Во-первых, необходимо проверить, что ваш процессор имеет аппаратную поддержку виртуализации и в BIOS основной машины включены опции поддержки: Intel VT-x или AMD AMD-V. Если система поддерживает "Hardware-Assisted MMU Virtualization": опции Intel EPT (extended page tables) или AMD RVI (rapid virtualization indexing) или AMD NPT (nested page tables), то тоже обязательно включаем. Первый механизм в условиях виртуализации позволяет эффективнее (с меньшими накладными расходами) распределять процессор между виртуальными машинами, а второй - память.

Во-вторых, если процессор поддерживает Hyper-threading, то рекомендуется активировать  поддержку этого механизма в BIOS. Hyper-threading, когда один процессорный юнит (ядро) обрабатывает 2 очереди команд, даёт скорее большую утилизацию процессорных ресурсов, так как процессор меньше простаивает. Но при правильном использовании этой технологии можно добиться и повышения производительности всей системы. Гипервизор от VMware умеет использовать Hyper-threading.

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

При конфигурировании количества ядер для виртуальных машин, можно руководствоваться правилом: общее количество ядер всех виртуальных машин плюс запас для основной машины не должно превышать двойного количества физических ядер процессора (без учёта Hyper-threading). Например, если ваш процессор имеет 4 физических ядра, то можно создать максимум 3 виртуальные машины, каждой отдав по 2 ядра, а 2 ядра оставить основному компьютеру. В идеале, конечно, вы должны распределять только имеющиеся ядра, не допуская overhead. Но так как мы говорим про персональные компьютеры (или даже ноутбуки), а не про сервера, то ядер у нас обычно не так много. Исходим из того, что имеем, поэтому максимум двойной overhead.

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

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

Ещё одно важное замечание: при создании виртуальной машины всегда корректно выбирайте тип гостевой операционной системы и её версию. Гипервизор, зная особенности работы разных операционных систем, для создаваемой вами виртуальной машины применит оптимальные настройки и для процессора, выбирая поддерживаемые операционной системой механизмы  виртуализации. А это напрямую влияет на производительность. После создания виртуальной машины изменить эти настройки тоже можно. Выключив виртуальную машину, войдите в пункт меню "VM -> Settings" (или нажмите Ctrl+D), а там выберите раздел "General". Справа будут нужные вам параметры (рис. 1).

Рис. 1. Настройки типа и версии гостевой операционной системы.

Вот по этой ссылке на официальном сайте можно посмотреть список поддерживаемых гостевых операционных систем. 

Оперативная память

Первое правило виртуализации: оперативной памяти много не бывает. Оперативная память, для гипервизора, как и для БД SAP HANA, основной ресурс. 

Память виртуальной машине (как и в любой операционной системе) выдаётся по требованию. При этом, как и в Enterprise решении VMware ESXi, гипервизор в VMware Workstation умеет выполнять разные финты при управлении памятью: page sharing, balooning, swapping. Все эти механизмы направлены прежде всего не на повышение производительности виртуальных машин, а на максимальную утилизацию ресурсов.  Задача механизмов оптимизации  уменьшить потребление памяти виртуальными машинами. Например, забрав свободные страницы памяти у виртуальной машины, как только они ей больше не нужны, и отдать их той виртуальной машине, которая в текущей момент требует больше памяти для своей работы. Стоит отметить, что благодаря такому подходу удаётся разместить на одной машине большее количество виртуальных машин. Гипервизор жонглирует количеством памяти меньшего объёма, чем сумма сконфигурированной памяти всех виртуальных машин, но при этом обеспечивает их одновременную работу. Существует даже термин для этого - "memory overcommitment".

У нас же стоит обратная задача: получить максимальную производительность при работе виртуальных машин. Обеспечить это можно, как ни странно, отключив по максимуму механизмы оптимизации. :)

Для этого необходимо, во-первых, перейти в пункт меню "Edit -> Preferences" (или нажать Ctrl+P). Здесь в разделе "Memory" содержатся общие настройки для всех виртуальных машин (рис. 2). Для начала укажите сколько оперативной памяти сервера может быть отдано виртуальным машинам. Так как VMware Workstation относится ко второму типу гипервизоров, то мы должны подумать и об основной машине, не оставив её без памяти. Иначе, если она начнёт уходить в swap, то работать плохо начнёт всё, включая виртуальные машины. В моём примере из 32 Гб оперативной памяти 24 Гб отдано виртуальным машинам, а 8 Гб всегда будут за операционной системой хоста.
Далее обязательно выбрать пункт "Fit all virtual machine memory into reserved host RAM". Гипервизор, работая в таком режиме, запускает виртуальные машины только при условии, если сумма сконфигурированной для них оперативной памяти умещается в выделенный для них пул основного хоста.

Рис. 2. Опции памяти для всех виртуальных машин.

Во-вторых, для каждой виртуальной машины перейти в индивидуальные настройки через пункт меню "VM -> Settings" (или нажать Ctrl+D), перейти во вкладку "Options", а там выбрать пункт "Advanced" (рис. 3). В этом окне поставить галочку напротив пункта "Disable memory page trimming". В этом случае гипервизор не будет пытаться отнять у виртуальной машины оперативную память, используя свои механизмы оптимизации.

Рис. 3. Настройка памяти для отдельной виртуальной машины.

Жёсткий диск

Во-первых, постарайтесь разместить виртуальные машины на дисках с хорошей скоростью чтения-записи. Раньше рекомендовалось использовать RAID массив на достаточном количестве дисков. Сейчас прекрасным вариантом будет SSD диск. К примеру в VMware Workstation для гостевой операционной системы MS Windows 10 рекомендуется использовать тип диска "NVMe" (рис. 4).

Рис. 4. Рекомендуемый тип диска виртуальной машины.

Драйвер такого типа виртуального диска (из пакета VMware Tools) показывает хорошую скорость в тестах (рис. 5). Но только если на нижнем уровне находится быстрый SSD диск. В данном примере это даже не NVMe диск, а SSD через интерфейс SATA. 

Рис. 5. Тестирование скорости диска в виртуальной машине.

Стоит отметить, что размещение файлов виртуальной машины на внешнем USB-носителе плохая идея. Практика показывает, что работает такая виртуальная машина очень медленно. Работать практически невозможно. Так что, если у вас возникла такая идея, лучше откажитесь от неё сразу. :)

Во-вторых, выбирайте правильные опции при создании жесткого диска виртуальной машины. VMware предлагает выбрать из следующих вариантов: 

• тонкий диск (thin provisioned) - место выделяется по мере необходимости,
• толстый диск (thick provisioned) - место выделяется сразу на весь объём виртуального диска,
• хранить виртуальный диск в одном файле,
• разбить виртуальный диск на несколько файлов.

Вариант с максимальной производительностью это толстый диск, хранящийся в одном большом файле (рис. 6). 

Рис. 6. Параметры виртуального жесткого диска для максимальной 
производительности.

В третьих, для максимальной производительности рекомендуется выбирать тип диска "Independent" и "Persistent". Запись на такой диск осуществляется сразу после команды ввода-вывода (рис. 7).

Рис. 7. Расширенные настройки диска виртуальной машины.

Хочу обратить внимание, что в этом окне настроек можно посмотреть информацию о диске, реальный и максимальный размеры файла образа, свободное место в файловой системе. А также здесь можно найти дополнительные утилиты для работы с виртуальными дисками. 

Существует рекомендация дефрагментировать диск внутри виртуальной машины, как и на обычном физическом компьютере. Но в наш век SSD лишние операции записи на SSD-диск не рекомендуются: снижается ресурс диска. Поэтому, наверное, этот совет уже не актуален. Но, если вы используете динамически расширяемый виртуальный диск (thin provisioned), то можно воспользоваться утилитой дефрагментации на уровне VMware Workstation (рис. 8). В данном случае VMware использует свои внутрение алгоритмы и с минимальным количеством операций записи оптимизирует виртуальный диск.

Рис. 8. Информация о виртуальном диске и дополнительные утилиты для работы с ним.

После дефрагментации, можно выполнить операцию сжатия файла, нажав соседнюю кнопку "Compact". VMware сожмёт образ диска до реального объёма данных. 

Дополнительно после полной подготовки виртуальной машины (установки операционной системы, программ и т.п.) можно перезалить файл-образ виртуального диска (vmdk-файл) на файловую систему, предварительно его удалив. На данном подходе я не настаиваю, может быть это и лишнее. Но мне кажется, что эта операция переложит файл образ одним непрерывным куском, что улучшит обращение к нему. Хотя опять же в век SSD это может быть уже не актуально. Но опции дефрагментации и сжатия есть, имейте это ввиду. Могут быть полезны перед перезаливкой образа-диска, если решитесь.

Дополнительно можно найти утилиты по подключению диска из виртуальной машины, как сетевого диска на основном компьютере (кнопка "Map") и увеличения размера диска (кнопка "Expand") (рис. 8). Имейте ввиду, что изменение настроек виртуального диска производится только при выключенной виртуальной машине.

Все согласятся, что в swap (paging) область уходить в виртуальной машине крайне не желательно. Но на случай использования swap области, рекомендуется вынести её на отдельный виртуальный диск, файл образ которого необходимо положить на отдельный физический диск. Опять же рекомендация со времен жестких дисков, а не SSD. А в swap лучше вообще никогда не уходить.

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

Рис. 9. Включение кэширования записей на диск в MS Windows.

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

Другое оборудование

Отключайте ненужное оборудование. Например, если у вас в виртуальной среде работает серверная операционная система, то звуковая карта вам вряд ли понадобится. Для отключения выберите пункт меню "VM -> Settings" (или нажмите Ctrl+D), слева выберите пункт "Sound Card", а справа уберите галочки напротив пунктов "Connected" и "Connected at power on". Или удалите целиком виртуальное устройство через кнопку "Remove" (рис. 10).

Рис. 10. Отключение виртуальной звуковой карты.

Также настоятельно рекомендуется отключать автозапуск для CD/DVD-устройств. Если вы устанавливали гостевую операционную систему через ISO-файл, то он будет постоянно контролироваться и читаться виртуальной машиной. А этот образ вам скорее всего уже не нужен. Поэтому для отключения в тех же настройках виртуальной машины установите курсор мыши на пункт с CD/DVD и уберите галочки напротив пунктов "Connected" и "Connected at power on" (рис. 11).

Рис. 11. Отключения автозапуска CD/DVD устройства в виртуальной машине.

Ну и так как 3D-графику в виртуальной машине мы тоже обычно не используем, то рекомендуется отключить и её. Читал сообщения, что в предыдущих релизах VMware Workstation включение её очень сильно тормозило интерфейс гостевой операционной системы. Для отключения в настройках виртуальной машины установите курсор мыши на пункт "Display" и снимите галочку напротив пункта "Accelerate 3D graphics" (рис. 12).

Рис. 12. Отключение 3D графики в виртуальной машине.

Программное обеспечение

Во-первых, обязательно устанавливайте пакет расширений VMware Tools. Данный пакет представляет собой набор драйверов для виртуального оборудования плюс ряд программных механизмов, которые напрямую влияют на производительность виртуальной машины. Помимо этого после установки VMware Tools можно будет настроить нормальное разрешение экрана, интеграцию мыши и выполнять копирование через буфер обмена между основной и виртуальной машинами. Для установки выберете пункт меню "VM -> Install VMware Tools". Для гостевой операционной системы Linux поддерживаемой альтернативой является пакет Open VM Tools. Подробности можно найти тут и тут.

Во-вторых, рекомендуется на основной машине отключить антивирус на директории с файлами виртуальных машин. Дополнительно можно включить основные типы файлов виртуальных машин (*.vmdk, *.vmx, *.vmem, *.nvram) в исключения антивируса. При работе виртуальной машины эти файлы часто меняются, так как виртуальная машина постоянно читает и пишет в них. Антивирус может вызывать излишнюю нагрузку на систему, постоянно проверяя эти файлы (особенно большие файлы образов виртуальных дисков). Тем самым будет оказываться влияние на производительность и виртуальных машин.

Другое

Во-первых, встречал рекомендацию работать в виртуальной машине в полноэкранном режиме (Full-screen). То есть когда вы находитесь в виртуальной машине в окне VMware Management Interface, то лучше работать не в оконном режиме. Иначе производительность работы интерфейса операционной системы внутри виртуальной машины будет не максимальной. Для перехода в полноэкранный режим необходимо нажать комбинацию клавиш Ctrl+Alt+Enter. Выйти можно через комбинацию клавиш Ctrl+Alt или вызвав сверху панель VMware Management Interface и свернув окно виртуальной машины.

Говорят, что в свежих релизах VMware Workstation производительность что в оконном режиме, что в полноэкранном одинакова, но "осадочек" остался. :)

Во-вторых, если ваша виртуальная машина работает без ошибок и сбоев, то для максимальной производительности можно полностью выключить Debbuging. Для этого необходимо перейти в настройки виртуальной машины через пункт меню "VM -> Settings" (или нажать Ctrl+D), открыть вкладку "Options", а там выбрать пункт "Advanced". Справа для пункта "Gather debugging information" выбрать уровень "None" (рис. 13).

Рис. 13. Выключение сбора трассировочной информации для виртуальной машины.

В виртуальных машинах с операционной системой MS Windows рекомендуется по максимум отключить визуальные эффекты. Обычно эти настройки можно найти в "Панель управления -> Система и безопасность -> Система -> Дополнительные параметры системы -> Быстродействие -> Параметры". Я на всех своих рабочих местах выбираю "Обеспечить наилучшее быстродействие", включая только некоторые настройки визуализации (рис. 14).

Рис. 14. Настройки быстродействия интерфейса MS Windows.

Дополнительно отключите Screen Saver. В виртуальной машине он ни к чему, а ресурсы может расходовать прилично.

B Linux можно обойтись совсем без графической среды. Это так же положительно повлияет на скорость работы виртуальной машины. Например, в этом посте я рассказывал как установить Developer Edition систему на Linux без графического окружения.

В третьих, рекомендуется в гостевых операционных системах включать синхронизацию времени. Лучше всего для этого использовать NTP-сервер. Нет локального? Всегда можно использовать свободные для доступа из Интернет. В крайнем случае, можно использовать встроенную функцию синхронизации из VMware Tools. Но следите, чтобы не были активированы оба механизма.

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

Рис. 15. Настройка типа сетевого соединения виртуальной машины.

На официальном сайте VMware можно найти документ "Performance Best Practices for VMware Workstation". К сожалению, самый свежий вариант написан для версии 7.0. Но судя по содержанию, большая часть информации актуальна и для текущих версий программы. Скачать/прочитать документ можно по этой ссылке. 

Надеюсь мои изыскания, будут кому-то полезны. Если есть дополнения, пишите в комментариях.

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

Мастер-класс "SAP ландшафт и основы транспортной системы"

Коллеги, друзья и просто сочувствующие, хочу поделиться новостью. Во вторник, 9 ноября 2021 года, я буду проводить мастер-класс на площадке портала "SAPLAND". Мастер-классом назвать, наверное, это событие было бы слишком громко. Скорее это будет лекция "сборная солянка" на тему "SAP ландшафт и транспортная система". 

Попытаюсь за 4 часа рассказать всё, что знаю про транспортную систему в ABAP инстанции SAP системы, собрав в одном материале все нюансы и хитрости. Глубоко вглубь настройки и конфигурации не полезем, но в ширину постараюсь охватить всё. Будем говорить про базовые вещи, которые существуют в SAP системах с версии SAP R/3 3.0 и по сей день. При подготовке я постарался сделать материал максимально интересным для широкого круга специалистов. Ведь с транспортной системой сталкиваются и консультанты по модулям SAP системы, и ABAP-программисты, и SAP BASIS-консультанты/администраторы.

Если интересно, то регистрируйтесь и приходите. 

Формат мероприятия - онлайн. 

Физическим лицам скидка 30%.

Расписание всех мастер-классов этой осенней сессии можно найти по ссылке.

Обучение лучшее лекарство от осенней хандры! :)

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

Повышенная нагрузка на систему от процессов rslgsend и rslgcoll

В 2012 году я опубликовал пост, где подробно описал процедуру перехода на новое SAP ядро 7.20 для систем на базе SAP NetWeaver 7.00 - 7.11. На текущий момент SAP ядро 7.20 не поддерживается, а для систем на базе SAP NetWeaver 7.00 - 7.31 рекомендуется перейти на версию ядра 7.22 EX2. Скорее всего данная ветка SAP kernel последняя (для этих версий систем) и будет поддерживаться до конца 2025 года (рис. 1).

Рис. 1. Окончание поддержки SAP kernel 7.22_EX2.

Если кто-то не знает про EX2, поясню. Для финальных версий SAP ядер, выше которых системы переводить не планируется, выпускают дополнительные ядра. Сначала с приставкой EXT, а потом EX2. В эти версии добавляют только самые критичные изменения для поддержки нового оборудования, безопасности или важных функций.

Для перевода систем на SAP ядро 7.22 EX2 следует руководствоваться SAP note # 2115344 - Installation of Kernel 722 (EXT/EX2). Помимо описания вполне стандартной процедуры обновления SAP ядра, там указано несколько нюансов, которые следует учитывать при переводе систем на это ядро. 

Во-первых, системы на базе SAP NetWeaver 7.00/7.01 не поддерживают механизм динамических рабочих процессов, который уже реализован в версиях SAP kernel 7.20 и выше. Про данный механизм я подробно писал в этом посте. Для корректной совместной работы ядра с такой системой эту функцию надо отключить через выставление следующих параметров инстанции:

rdisp/wp_no_restricted = 0
rdisp/configurable_wp_no = 0
rdisp/dynamic_wp_check = FALSE
rdisp/wp_max_no = <сумма всех сконфигурированных рабочих процессов инстанции>

Второй момент, на который стоит обратить внимание, это новый формат центрального системного журнала SAP системы. Если у вас версия системы, основанная на SAP NetWeaver 7.00/7.01 (рис. 2) и работают процессы, отвечающие за центральный системный журнал (rslgsend и rslgcoll), то могут возникнуть проблемы с производительностью. Я с таким  столкнулся и хочу об этом рассказать.

Рис. 2. Пример версии системы на базе SAP NetWeaver 7.01.

Для начала пару слов о том для чего нужны эти процессы. В SAP системе, установленной на операционную систему Unix (любую её реализацию), в транзакции SM21 можно включить центральный системный журнал, который будет отображать журналы всех инстанций системы. Доступен он через пункт меню "System log -> Choose -> Central System logs". При этом в системах, работающих на операционной системе MS Windows центральный журнал не поддерживается. 

Принцип работы заключается в следующем. SAP ядро в специальной общей области памяти каждой SAP инстанции сохраняет локальный системный журнал (записи об ошибках и событиях инстанции). Выделенный процесс-демон с именем rslgsend пересылает эти записи центральному журналу выделенной инстанции (обычно это центральная инстанция системы). А на этой инстанции в свою очередь другой выделенный процесс коллектор (rslgcoll) собирает все записи вместе. Передача данных осуществляется по протоколу TCP, а процесс коллектор добавляет записи логов в файл центрального журнала, расположение которого задаётся через параметр rslg/central/file.  Вот на этой странице документации можно найти описание этого механизма.

Подробности же настройки упоминаются в SAP note # 25526 - Central system log not available. Стоит отметить, что часто функция центрального журнала активируется автоматически при установке SAP системы. Для старта вышеупомянутых процессов-демонов в стартовые профайлы инстанций добавляются строки для запуска вида:

#---------------------------------------------------------------------
# start rslgcoll
#---------------------------------------------------------------------
_CO =co.sap<SID>_DVEBMGS00
Execute_05 =local ln -s -f $(DIR_EXECUTABLE)/rslgcoll $(_CO)
Start_Program_05 =local $(_CO) -F pf=$(DIR_PROFILE)/<SID>_DVEBMGS00

#---------------------------------------------------------------------
# start rslgsend
#---------------------------------------------------------------------
_SE =se.sap<SID>_DVEBMGS00
Execute_06 =local ln -s -f $(DIR_EXECUTABLE)/rslgsend $(_SE)
Start_Program_06 =local $(_SE) -F pf=$(DIR_PROFILE)/<SID>_DVEBMGS00

Учтите, что здесь "Execute_XX" и "Start_Program_XX" должны иметь свой уникальный порядковый номер в зависимости от остальных аналогичных записей в профайле. 

Всё было бы хорошо, но начиная с версии SAP ядра 7.20 функции центрального журнала перекочевали в Web Services (процесс sapstartsrv), а процессы демоны (rslgsend и rslgcoll) больше не используются. Но системы с SAP_BASIS 7.00 или 7.01 новую версию центрального журнала использовать не могут, а для работы старой версии журнала при переходе на SAP ядро 7.20 процессы демоны передачи и сбора записей должны продолжать свою работу. И в этом случае, при их работе могут возникать коллизии с производительностью.

Процессы демоны начинают потреблять излишнее количество ресурсов: как процессорных (рис. 3), так и генерируя повышенный ввода-вывод на дисковую подсистему. Причем, ввод-вывод идёт на файловую систему, где хранится файл центрального системного журнала. В Unix системах  это директория /sapmnt/<SID>/global/. Ощущение, что процессы вхолостую постоянно пересоздают файл центрального системного журнала.

Рис. 3. Процессы-демоны в топе по потреблению процессорных ресурсов.

Решением данной коллизии является:

1. Установка через транзакцию RZ10 параметра инстанции rslg/new_layout = 9.
2. Остановка SAP инстанций.
3. Удаление файла центрального журнала с уровня файловой системы.
4. Старт SAP инстанций.

После этого процессы-демоны сразу успокаиваются и больше не тратят ресурсы системы впустую (рис. 4-8).

Рис. 4. Количество процессорного времени, съеденного демонами за неделю
без установки параметра.

Рис. 5. Количество процессорного времени, съеденного демонами за 3 дня
после установки параметра.

Рис. 6. График потребления процессорных ресурсов сервера.

Рис. 7. График нагрузки на СХД по SAN.

Рис. 8. График операций записи в файловую систему /sapmnt сервера.

На графиках разница видна невооружённым взглядом.

Проблема описана в SAP note # 1517379 - Which system log format does the 720 kernel write? Будьте внимательны и выполняйте все рекомендации компании SAP. 

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