LVM в операционной системе Linux. Дополнение

В дополнение к моему посту про LVM в операционной системе Linux добавлю полезное видео:

Собственно про LVM начинается с 26-й минуты, начало можно пропустить.

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

Linux: оперативная память и swap. Дополнение

В дополнение к статьям "Оперативная память в Linux: особенности управления и мониторинг" и "Размер области подкачки в Linux: рекомендации" сегодня натолкнулся на интересную лекцию. Рекомендую посмотреть для понимания механизмов работы операционной системы с памятью и областью подкачки.

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

С наступающим Новым 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 - Стоимость: 16 000 рублей, 
• SAPADM 2.1. Пакет 2 - Стоимость: 16 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 по аналогии с существующим, подкорректировав пороги срабатывания. 

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

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