История одной миграции SAP системы или Век живи, век учись! - III

Данный пост продолжает серию кратких записей о моих открытиях в мире SAP систем и около них. Согласно первой части пословицы: "Век живи, век учись..." такие открытия периодически случаются и в тех областях, где казалось бы всё изучено вдоль и поперёк. 

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

Исходная ситуация - мрак

У заказчика старенькие системы SAP R/3 4.6C работали на уже давно морально устаревшем оборудовании. Когда-то очень хорошее оборудование HP на платформе PA-RISC давно выработало свой ресурс и требовало замены. Ситуация осложнялась тем, что компания HP прекратила разработку и поставку серверов не только на платформе PA-RISC, но и даже на когда-то перспективных процессорах Itanium (всю печальную историю этого процессора можно прочитать тут). Используя сервера на платформе Itanium можно было бы остаться в рамках операционной системы HP-UX и почти бинарной совместимости со старыми серверами. Но поезд ушёл, оборудование полностью морально и физически устарело и ситуация была катастрофическая. SAP системы, как вы поняли, работали на платформе с операционной системой HP-UX, а в качестве базы данных использовалась Oracle 8i. Поддержки со стороны ни одного из производителей программного обеспечения таких старых версий, как вы догадываетесь, тоже уже не было. 

Свет в конце туннеля 

Апгрейд версии SAP системы в рамках данного проекта не планировался. Поэтому анализ Product Availability Matrix для текущей версии системы показал, что, если выбрать платформу x86_64, на которую сейчас переходит большинство вендоров серверного оборудования, то перенос на неё  системы возможен. Правда придётся в качестве целевой операционной системы использовать SUSE Linux Enterprise Server версии 11 с последним SP4, а базу данных обновить до Oracle 10g. Ну и ядро SAP системы необходимо подтянуть до максимального уровня - 46D_EX2 (рис. 1).

Рис. 1. Матрица совместимости для исходной версии системы.

Подготовка - тяжело в учении...

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

В связи с тем, что в данном случае планировалось полностью изменить платформу, было принято решение проводить процедуру миграции по схеме Heterogeneous System Copy.
Напомню, что процедура состоит из 3 крупных этапов:

1. EXPORT - выгрузка базы данных исходной системы в файлы универсального экспортного формата SAP.
2. MOVE - перенос экспортных файлов на новый сервер.
3. IMPORT - установка новой версии системы с последующим импортом данных из полученных экспортных файлов.

Сначала я разбирался с экспортом. Оборудование, как я уже говорил, морально устарело, производительность для текущей системы была очень низкая. Но стоит отметить - было и 2 положительных момента:
- относительно небольшой объём базы данных - 2,4 Тб;
- хорошая производительность дискового массива (HP EVA8400).

При экспорте базы данных SAP системы строго рекомендуется останавливать сервер приложений, не останавливая при этом СУБД. Экспериментов в данном случае требовалось много, а тестовой среды у заказчика на момент старта этого проекта не было. Поэтому приходилось всё делать на продуктивной системе. С одной стороны это большой плюс: я проводил тестовые выгрузки на реальном сервере, который будет участвовать в финальной выгрузке. С другой стороны, останавливать продуктивную систему постоянно никто не даст.
В процессе работы в голову пришло решение - делать выгрузки на работающей системе. В выходные дни у заказчика нагрузка со стороны пользователей минимальна, поэтому я по-тихому проводил тестовые выгрузки, нащупывая оптимальные параметры Oracle и количество параллельных потоков. А проблемы возникали. Например, когда при использовании ряда рекомендуемых в SAP notes параметрах Oracle, выгрузка некоторых таблиц зависала, как будто происходили какие-то блокировки на уровне базы данных. Поэтому оптимальные параметры пришлось нащупывать экспериментально. Выгрузки при работающей системе получались не 100% консистентными, но цель была не в этом. За подготовительный период удалось провести 2 или 3 продуктивные выгрузки с остановом сервера приложений SAP и полной загрузкой существующего оборудования.

В итоге, я добился отлаженного процесса экспорта базы данных, который занимал в общей сложности 21 час. Процесс шёл в 7 потоков при 8 процессорных ядрах. Больше потоков запускать не было смысла. Дело в том, что используя старые версии утилит выгрузки можно полу-скриптовыми методами выделить крупные таблицы в отдельные потоки. Но утилиты не позволяют разбивать таблицы на части при выгрузке, как, например, более свежие версии инсталляторов SAP. Ну вы догадались, что выгрузка пары самых крупных таблиц как раз и длилась эти самые 21 час. Дисковый массив был загружен в среднем на 65%, а потоки упирались в производительность по процессорам.

Экспортные файлы заняли около 500 Гб. Это 1/5 от объёма исходной базы данных. При экспорте данных используется сжатие и стоит учесть тот факт, что при этой процедуре не происходит выгрузки табличных пространств PSAPTEMP и PSAPROLL/PSAPUNDO, а также индексов. Индексы генерируются заново на этапе IMPORT. Поэтому объём файлов в экспорте меньше объёма исходной базы данных.

С этапом переноса файлов больших проблем не было. SAP не рекомендует использовать для переноса файлов по сети NFS, поэтому была отработана процедура переноса по протоколу FTP. Старые сервера имели на борту сетевые адаптеры на 1 Гбит/сек, поэтому перенос на новое оборудование 500 Гб требовал 2,5 часа времени. При копировании использовалась утилита wget, которая позволяет одной командой легко инициировать копирование структуры директорий с файлами. Информацию про неё нашёл тут.

Дополнительные затраты по времени занял процесс проверки контрольных сумм (CRC) файлов после переноса. На исходном сервере процесс сбора контрольных сумм утилитой cksum, работая в один поток, занимал 2 часа. Благо этот процесс можно было совместить с этапом самого копирования файлов по сети. А на новом оборудовании утилита cksum отрабатывала за 30 минут. Для сравнения файлов с контрольными суммами использовалась утилита diff. В итоге, расчётное время для данного этапа составило - 3 - 3,5 часа. 

Для тестирования третьего шага миграции (IMPORT) компанией HP был предоставлен во временное пользование сервер с целевой архитектурой. Это был сервер начального уровня HPE ProLiant DL380 Gen10 с процессорами Intel Xeon Gold 6136 и внутренним RAID контроллером, где 12 SAS дисков, объединённые в RAID уровня 6, образовывали единое дисковое пространство. И до поставки и настройки основного аппаратного комплекса я использовал данный сервер.

Разговор про процесс установки очень старой системы SAP R/3 4.6C на относительно современную платформу из SLES 11 и Oracle 10g я даже начинать не буду. Установочные файлы и сам процесс пришлось буквально собирать по крупицам из десятков SAP notes и других источников. Версия системы старая, вряд ли кому-то сейчас это будет интересно.

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

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

Рис. 2. Затраты времени на этап IMPORT на тестовом сервере DL380.

Помимо разного количества потоков прогоны отличались еще последовательностью загружаемых таблиц (процесс не контролируемый, как я писал выше) и параметрами Oracle. По процессорам ресурсов было достаточно, но всё упиралось в дисковую подсистему. Я пробовал и больше потоков (16), но процесс только растягивался во времени. Задержки (latency) на дисковом массиве подсказывали, что больше выдавать он не может. Я смирился с данными временными параметрами для этого этапа. Была надежда (даже уверенность) что дисковый массив продуктивного комплекса уровня Enterprise, да ещё и полностью на SSD дисках, даст процессу импорта развернуться и покажет сокращение временных затрат. 

И вот настал тот день, когда целевой аппаратный комплекс был инсталлирован, настроен и передан в мои руки. Ну сейчас я развернусь, подумал я. :)

Знаете сколько импортировались данные на сервере, расположенном на новом комплексе? С учётом больших объёмов физической памяти и щедро настроенных буферов Oracle. С учётом дискового массива HPE 3PAR StoreServ 8440 полностью на SSD дисках. С учётом RAID 1 массива, собранного для максимального быстродействия не только по чтению, но и по записи. 12 потоков импорта данных и итоговое время 38 часов! Сказать, что я был разочарован, ошарашен или взволнован, это совсем никак не выразить гамму моих чувств. Я не был совершенно похож на довольных инженеров со страницы с описанием дискового массива. Я был просто раздавлен этими цифрами. Время на тестирование процесса еще оставалось, поэтому я перепроверил цифры, перезапустив процесс копирования системы ещё пару раз. Результат с учётом погрешности был примерно один и тот же. Даже 16 потоков дали 33,5 часа общего времени на этап IMPORT.

К задаче были подключены инженеры HP, отвечающие за подготовку железа, дискового массива и оптической сети. Было перечитаны ещё раз все Best Practics. Переведены виртуальные диски, созданные на 3PAR, с "тонких" на "толстые". Включена балансировка на всех уровнях оптической сети и коммутаторов, перепроверены параметры на всех уровнях системы. Но результат был всё тот же. 

Инженеры по оборудованию даже организовали мне показательное выступление с синтетическими тестами максимальной скорости по Мб/сек и IOPS, которые может максимально выдавать дисковый массив при сохранении низких значений latency и Service Time со стороны 3PAR. Таким образом, доказав мне, что на уровне оборудования всё прекрасно. Но почему процесс импорта не укладывался в меньший интервал? Процессорных ресурсов достаточно. Дисковый массив явно одной левой отрабатывает запросы от систем. Кто же тогда виноват?

Немало часов и дней я провёл в размышлениях и экспериментах. И неожиданно нащупал "узкое место". Если вы спросите меня "Как?", то могу только предположить. Однажды, отчаявшись, я просматривал журнал Oracle и увидел ошибку "Chekpoint not complete", в которой, в принципе, нет чего-то удивительного при массовых операциях загрузки в базу данных. Но это меня зацепило. Нашёл и перечитал SAP note 79341 - Checkpoint not complete. Одна из причин в журнальных файлах, говорилось в ней. Я вспомнил, что что-то про это было в, много раз перечитанной вдоль и поперёк, SAP note 806554 - FAQ: I/O-intensive database operations. Потом посмотрел SAP note 936441 - Oracle settings for R3load based system copy. И начал эксперименты. Результаты вы можете видеть в таблице (рис. 3).

Рис. 3. Затраты времени на этап IMPORT на целевом оборудовании.

Вы уже догадались, что проблема была в журнальных файлах (Redo Logs)! Инсталлятор  R3SETUP для системы SAP R/3 4.6C был спроектирован для установки системы на базу данных Oracle версии 8i. При установке системы автоматически создаются журнальные файлы в 4 группах, в каждой по 2 копии, размером 20 Мб! Для пустой начальной базы системы SAP R/3 в 20 Гб это нормальный размер. Но для загрузки продуктивных данных, накопленных за много лет (2 Тб), этого размера явно недостаточно. В SAP notes упоминали, что надо бы отключить зеркалирование журналов, оставив только одну копию в группе. Но я решил, что заодно, можно сразу поиграться и с размером. Всё равно его после разворачивания системы надо было увеличивать. Сконфигурировал останов скрипта установки системы R3SETUP и пересоздал группы журналов с одной копией нужного мне размера. Результатом стал взрывной рост скорости загрузки и уменьшение итогового времени. Изначально, понадеявшись, на производительность оборудования, я не подумал, что частое переключение между маленькими файлами журналов будет тормозить весь процесс. Век живи, век учись! В результате дальнейших экспериментов остановился на журналах по 1024 Мб (без копии) и 12 потоках. При этом процесс импорта ощутимо сильнее нагрузил процессоры и дисковую подсистему. А то до этого момента складывалась парадоксальная ситуация: ресурсов много, а процесс импорта их не использует.

Любопытства ради, я увеличил размер журналов и прогнал импорт и на тестовом сервере DL380. Выжал в итоге всё из внутреннего дискового массива, получив 12,5 часов итогового времени! 

Процесс переезда - легко в бою

Ну а сам процесс переезда прошёл легко и скучно. :) Перед последним прыжком был создан финальный план, куда я включил все полученные временные интервалы с запасом 15-20%. Были выделены выходные. И за два дня, в спокойном режиме, уложившись во все предыдущие измерения, был выполнен перенос системы на новое оборудование.
Итоговое время получилось: 21 + 3 + 6 = 30 часов. Плюс время на донастройку системы, подключение дополнительных инстанций SAP, тестирование.
Начальная цель выполнить переезд за выходные была достигнута.

А у меня от этого проекта осталась борода и стало может быть чуть-чуть побольше опыта. :)

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

Век живи, век учись!

Предыдущие выпуски:

• Век живи, век учись! - I
• Век живи, век учись! - II

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

Оперативная память в Linux: особенности управления и мониторинг

Те, кто читает мой блог на постоянной основе, знают, что я очень люблю операционные системы Unix за их изящность, простоту и надёжность. В начале моей карьеры судьба свела меня с коммерческой реализацией операционной системы Unix от компании Hewlett Packard - HP-UX. Очень долго и плотно я работал с данной операционной системой. Но время не стоит на месте и надо признать, что HP-UX на данный момент утратила свои позиции и всё больше и больше серверов (причём не только HP) передают под управление операционной системы Linux. 

Если вернуться к моей скромной персоне, то у меня тенденция идентичная - HP-UX уходит, а Linux в моей работе становится всё больше. Не смотря на то, что операционная система Linux основана на Unix концепции и, по большому счёту, удовлетворяет стандарту POSIX, она, как и любая другая реализация Unix, имеет свои особенности. Сегодня попробуем разобраться с управлением памятью в Linux.

Основную мысль, которую я усвоил, разбираясь в этом вопросе - Linux всегда использует всю оперативную память, которая есть у сервера. Поэтому не так просто ответить на вопрос: хватает ли серверу памяти и каким запасом по ней он обладает? Но обо всём по порядку.

На уровне командной строки существует три команды, которые помогут нам посмотреть информацию по оперативной памяти сервера:

• top
• free
• cat /proc/meminfo

Команда top служит для вывода информации по текущей загрузке сервера, отображая работающие процессы, использование ими ресурсов процессора и памяти сервера. Нас в контексте использования оперативной памяти интересуют 2 строки в шапке вывода команды (рис. 1).

Рис. 1. Пример вывода команды top на сервере с Linux.

Из вывода мы видим, что всего операционная система видит 193 711 Мб физической памяти, из них только 833 Мб свободно. При этом настроено 131 068 Мб в области подкачки (swap) и почти вся она свободна. По информации от одной этой команды можно сделать преждевременные выводы:

- процессы сервера используют почти всю память, 

- но при этом (и это хорошая новость) область подкачки не используется,

- значит оперативной памяти хватает, но запаса нет. 

Выводы верны и не верны одновременно. Если увеличить общий объём физической памяти на сервере, то запустив систему, в команде top опять увидим похожую картину.

Если смотреть по отдельным процессам, то в этой команде для нас представляют интерес следующие столбцы:

• VIRT (virtual size of a process) - общий объем используемой памяти: индивидуальная память процесса плюс память, разделяемая с другими процессами, плюс файлы на диске, которые отображаются в память, плюс библиотеки и так далее. Можно сказать, что это максимально доступный процессу объём памяти, 
• RES (resident size) - указывает точно сколько в действительности потребляет процесс реальной физической памяти (совпадает со значением в колонке %MEM),
• SHR (shared) - определяет размер разделяемой памяти.

В случае с процессами Oracle в моём примере (рис. 1) в поле VIRT отображается вся память, выделенная на буферы СУБД (SGA) (рис. 2).

Рис. 2. Размер SGA области текущего экземпляра Oracle.

Двигаемся дальше. Следующая команда free - служит для вывода информации об использовании оперативной памяти сервера, опять же, с областью подкачки (swap) (рис. 3).

Рис. 3. Пример вывода команды free на сервере с Linux.

По умолчанию, команда выводит информацию в килобайтах, для вывода в байтах или мегабайтах можно использовать соответствующие ключи -b и -m (рис. 4). 

Рис. 4. Пример вывода команды free в мегабайтах на сервере с Linux.

Теперь значения полностью совпадают с выводом команды top, но мы получили немного больше информации. Во-первых, появился ещё один столбец "cached", в котором отображается 179 187 Мб памяти. А во-вторых, поле "-/+ buffers/cache" указывает сколько реально памяти сейчас используют приложения (11 068 Мб) и сколько им ещё может быть выделено системой (182 642 Мб).

Обе вышеописанные команды используют информацию из файла meminfo, который хранится в псевдо (dummy) файловой системе /proc. Данная файловая система не существует на самом деле, а предоставляет интерфейс к структурам данных в ядре Linux. Найти её можно в выводе команды df -a (рис. 5).

Рис. 5. Файловая система proc.

Для просмотра информации из ядра Linux по использованию памяти можно прочитать содержимое файла напрямую, выполнив команду cat /proc/meminfo (рис. 6).

Рис. 6. Пример содержимого файла meminfo.

Вот теперь мы добрались до максимальной глубины картины по использованию оперативной памяти операционной системой Linux. Давайте разбираться. 

В приведённом примере на сервере всего доступно 192 Гб оперативной памяти (MemTotal), никак не используется приложениями и операционной системой - 741 Мб (MemFree). Для буферов операционной системы выделено 2 833 480 Кб памяти. Буферы используются для кэширования, например, таблиц файловых дескрипторов (i-node table) или записей директорий (dentry), то есть мета-данных файловых систем. А самым большим потребителем "не используемой" памяти является страничный кэш (Cached). Как я уже говорил выше, Linux не будет просто так держать большой объём оперативной памяти свободной. Каждый раз, когда выполняется операция чтения из файла (read ()), расположенного на диске, данные считываются в эту область памяти страничного кэша. Как только операция чтения завершается, ядро Linux не выбрасывает страницу памяти, а использует её при повторном чтении той же самой части файла. Этот механизм здорово сокращает количество обращений к диску. Но при этом эта память может быть быстро освобождена и передана ядру операционной системы или приложениям в случае такого запроса. Это как раз и указано в выводе команды free  в строке "-/+ buffers/cache" в поле free). 

Ещё один момент, который стоит учитывать при мониторинге. Linux никогда не съедает всю память до конца, то есть вы не увидите 0 Кб в поле MemFree. Операционная система всегда оставляет часть памяти для маневров по освобождению памяти.

Если физической памяти явно не хватает, то начинается активное использование области подкачки (swap). Немного swap области может использоваться и при большом количестве свободной оперативной памяти Например, в моём примере этим занято 21 Мб (рис. 4). Ядро операционной системы может скинуть часть страниц памяти, к которым очень-очень редко происходит обращение. Главное, чтобы не было активного использования области подкачки. Для обнаружения этого в системе можно обратиться к команде vmstat (рис. 7).

Рис. 7. Пример вывода команды vmstat в Linux.

Используемые в данном варианте параметры:
- "-S M" - отображать результаты в мегабайтах,
- "2 5" - вывести 5 слепков состояния с интервалом в 2 секунды.

В выводе можно увидеть статистику использования оперативной памяти - поля swpd, free, buff, cache. А также активность области подкачки - поля swap:si и swap:so, которые показывают ввод-вывод из данной области. В данном примере мы видим, что swap активно не используется.

Так же хочу напомнить, что в SAP системе информацию по использованию оперативной памяти на сервере в виде мгновенного снимка или статистики за предыдущие часы можно получить в транзакции ST06, выбрав пункт "Память" (рис. 8). В принципе, там тоже можно найти основные показатели, о которых я только что рассказал. Это может быть полезно, если у вас нет доступа на уровень операционной системы сервера, где работает SAP система.

Рис. 8. Пример вывода транзакции ST06 для мониторинга использования памяти.

Дополнительную информацию можно найти в этой статье (или прочитать перевод). 

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

SAP системы в виртуальной среде VMware - II

В первой части статьи я вкратце описал что собой представляет типовая архитектура виртуального кластера VMware.

Теперь поговорим об отношениях между SAP и VMware.

Тот проект, в котором я участвовал, представлял собой перенос систем SAP на платформу Linux/Oracle. В качестве дистрибутива Linux использовался SUSE Linux Enterprise Server for SAP Applications. Так что учитывайте, что следующая информация и перечень рекомендаций, который я привожу, были собраны для выбранной платформы. Хотя, конечно же, большая часть знаний носит универсальный характер и пригодится всем кто разворачивает SAP в виртуальной среде.

Для начала, источники информации, которые я использовал:

• Performance Best Practices for VMware vSphere 6.7,
• SAP Solutions on VMware Best Practices Guide,
• SAP note # 2161991 – VMware vSphere configuration guidelines,
• SAP note # 1612283 – Hardware ConfigurationStandards and Guidance,
• SAP note # 989963 – Linux: VMware timing problem,
• SAP note # 2015392 – VMware recommendations forlatency-sensitive SAP applications,
• SAP note # 1158363 – VMware Performance Snapshot,
• SAP note # 2538919 – VMware upgrade to version 6,
• SAP note # 2490017 – Performance problem with VMwareon Linux,
• SAP note # 1173954 – Support of Oracle for VMWare,
• SAP note # 793113 – FAQ: Oracle I/O configuration.

Рассмотрим рекомендации по настройке BIOS.

1. Включить все возможные опции поддержки аппаратной виртуализации - VT-x, AMD-V, EPT, RVI, VT-d , AMD-Vi.
2. Выключить опцию "Node Interleaving" для включения поддержки NUMA. NUMA это фишка современных мультипроцессорных систем, которая заключается в разной скорости доступа к разным банкам памяти от разных процессоров. Проще говоря, у каждого процессора есть свои банки памяти, к которым доступ осуществляется гораздо быстрее, чем к банкам памяти соседнего процессора. И программное обеспечение с поддержкой NUMA понимает это и старается работать только с банками памяти текущего процессора, не обращаясь к "дорогой" памяти.
3. Включить опции ускорения "Turbo Mode" и "Hyper-Threading". C Hyper-Threading ситуация такая: активировать его надо, но при распределении виртуальных ядер между виртуальными машинами на них рассчитывать не стоит.
4. Выключить опции "Power-Saving", "C1E Halt State", а "Power Management" включить в режим "OS Controlled Mode".
5. Использовать профиль "Max performance" и/или "Max virtualization". У некоторых вендоров (например, HPE) есть отдельные профили при использовании серверов в составе VMware кластера.
6. Максимально отключить ненужные устройства.

Второй пункт нашей программы - рекомендации по настройке ESXi и виртуальных машин.

1. Технология VMware DRS не поддерживается SAP. DRS (Distributed Resource Scheduler) это технология автоматического выравнивания нагрузки на узлах в виртуальном кластере за счёт переноса работающих виртуальных машин между узлами. Технология позволяет выравнивать нагрузку, что положительно влияет на питание и охлаждение стоек в серверной. 
2. Рекомендуется использовать специальную файловую систему VMFS и хранить виртуальную машину в виде отдельных файлов, а не использовать VMware RDM. RDM (Raw Device Mapping) это тип хранения файлов виртуальных машин на сырых дисках специального формата. Аналог RAW-дисков для хранения файлов базы данных ORACLE.
3. При распределении ресурсов процессора считать, что 1 vCPU = 1 physical core (не учитывать логические ядра Hyper-Threading). ESXi сам распределяет ядра виртуальных машин по физическим ядрам. Стараться конфигурировать виртуальные машины по CPU и RAM внутри одной NUMA ноды. Поэтому я считаю очень важным понимание топологии NUMA на этапе сайзинга физических серверов. Рассчитывайте так, чтобы самая большая ваша виртуальная машина влезла в одну NUMA ноду, как по памяти, так и по процессорным ядрам. Функцию добавления процессорных ядер "на горячую" не использовать, то есть переключить "HotAddCPU" = disable.
4. При конфигурации сети: использовать VMXNET3 адаптер и, желательно, включить NIC teaming. Дело в том, что ESXi имеет в своём составе специальные виртуальные адаптеры для основных устройств, которые оказывают наибольшее влияние на производительность. К ним можно отнести сетевые адаптеры и SCSI-контроллеры. Желательно выбирать самые последние "модели", но обязательно смотреть таблицы совместимости на отдельной странице сайта VMware для гостевой операционной системы. VMXNET3 это самый быстрый и обладающий минимальным overhead сетевой адаптер для виртуальных машин VMware. NIC teaming это технология объединения нескольких физических адаптеров в один, что повышает скорость и отказоустойчивость.
   Также стоить иметь в виду, что обычная практика это разделение всей сети комплекса на управляющую сеть, сеть для переноса виртуальных машин с помощью технологии vMotion и минимум 2 адаптера с NIC teaming для пользовательского доступа. Если используется High-Availability, то тоже надо заложить дублирование сетевых каналов. То есть количество сетевых адаптеров физических узлов надо закладывать с учётом этой информации на этапе сайзинга комплекса.
   В VMware есть функциональность по организации виртуальных коммутаторов - vSwitch, которые позволяют объединить все физические сетевые адаптеры и рулить ими на уровне абстракции VMware, разделяя на подсети.
5. Memory reservation = размер сконфигурированной памяти VM (опция "Reserve all guest memory (All locked)"). То есть виртуальная машина сразу забирает всю память и не играет с выделением, swapping и другими фишечками VMware. А их там много. Например, balooning. Для SAP это всё увеличивает вероятность получения дополнительных проблем с производительностью, поэтому упрощаем процедуру выделения оперативной памяти виртуальной машине по максимуму.
6. В качестве типа SCSI адаптера лучше всего использовать PVSCSI. Объяснение аналогично сетевому адаптеру (см. пункт 4). 
7. Виртуальные диски типа "eager-zeroed thick provisioned". То есть никаких динамических дисков. В этом случае виртуальный диск занимает всё место, да еще и заполняет пустые блоки нулями. Данный вариант обладает самой высокой производительностью.
8. Распределить файлы базы данных по нескольким виртуальным хранилищам (они  в VMware называются Datastores) и нескольким PVSCSI контроллерам. Например, я сделал так: отдельный диск и контроллер для OS + swap; отдельный для redo logs файлов; и несколько для data-files Oracle.
9. На уровне ESXi обязательно активировать multipathing с политикой Round-Robin, но снизить лимит с "1000" (значение по-умолчанию) на меньшее значение (где-то встречал рекомендации установить в "1"). Multipathing это использование всех путей до СХД для повышения производительности и отказоустойчивости.
10. Использование snapshots на постоянной основе не рекомендуется. При удалении snapshot могут отваливаться фоновые задания в SAP системе. Но snapshot можно использовать при выполнении резервного копирования. Про это будет отдельный пост.
11. Использовать фиксированный MAC адрес. Для этого в настройках виртуальной машины необходимо выбрать тип "Manual". В Linux на MAC адрес завязан HardwareKey, на основании которого генерируется SAP License Key. Если VMware при смене узла, на котором работает виртуальная машина, изменит MAC адрес сетевого адаптера, то лицензионный ключ слетит. Подробности в SAP note 2161991 - VMware vSphere configuration guidelines.
12. Возможно использование больших страниц (Large Pages) для виртуальных машин с большим объемом памяти. Смотреть на поддержку операционной системы и версии базы данных, которые будут использоваться в виртуальных машинах.

Ну и напоследок, рекомендации по настройке гостевой операционной системы. В моём случае это была SUSE Linux Enterprise Server.

1. Отключить screen saver и анимацию.
2. Обязательно устанавливать VMware Tools. Инструкции по установке можно найти на этой странице. Для Linux есть альтернатива - open-vm-tools, SLES поддерживает её с версии 12. Данная версия также поддерживается со стороны VMware (пруф). 
3. Обязательная синхронизация времени. Лучше использовать NTP-сервер, а не опции VMware Tools (параметр tools.syncTime = "FALSE"). По опции VMware Tools происходит синхронизация времени гостевой операционной системы со временем ESXi узла. Это, как вы поняли, не рекомендуется. 
4. Настройки swap-области внутри виртуальной машины такие же, как SAP рекомендует и для физических машин. Про эти рекомендации я писал в этом посте.
5. Допускается использование LVM. Моё личное мнение, что с ним в Linux жить гораздо проще.
6. Настроить автоматический запуск сервера приложений SAP и DB при старте операционной системы. Чтобы при рестарте виртуальной машины ваша система поднималась сама. Об этом тоже будет отдельный пост.
7. ORACLE 10g и новее поддерживает NUMA по умолчанию (параметр _enable_numa_optimization), изменять параметр самостоятельно не рекомендуется.
8. Выключить iptables командой /etc/init.d/iptables stop. Отключить SELinux выставив параметр SELINUX = disabled в файле /etc/selinux/config. Ну или деактивировать это на этапе установки операционной системы.

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

Более подробную подборку SAP notes по VMware можно найти на этой странице SAP Wiki.

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

Опрос: а как вы ходите в отпуск

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

Всё конечно же зависит от конкретной ситуации и должности, но у меня складывается ощущение, что чем дольше я работаю, тем больше смазывается разница между отпуском и рабочими днями. Берёшь с собой ноутбук, думаешь о том, чтобы всегда был доступ к сети Интернет. Ну и чтобы перестать думать о работе надо, чтобы прошёл "пустой" буфер в течении дней 7-10. Только после 7-10 дней настоящего отдыха перестаёшь в фоне думать о рабочих задачах. А там обычно уже и отпуск заканчивается. :)

А самый большой отпуск у меня был в начале карьеры и это был целый месяц! После него я реально неделю входил в рабочий ритм и вспоминал логины/пароли. Даже на свой рабочий компьютер не помнил. :)

Ну а теперь собственно опрос. Выберете на что больше похожи ваши отношения с работой в отпуске.

В голосовании участвовал 21 человек. Результаты получились следующие:

Рис. 1. Результаты опроса.

Картина получилась 50 на 50. Мне кажется, что поведение человека в отпуске зависит в большей степени не от его характера или степени ответственности, а от конкретной ситуации в которой он работает. Если человек один отвечает за более или менее большой объем работы или набор сервисов, то ему приходится в той или иной степени в отпуске отвлекаться на работу. А если есть команда сотрудников, которым можно легко доверить свои задачи на период отпуска, то и отдохнуть можно так, что "забудешь логины/пароли". :)

Спасибо всем за участие!
Желаю всем, кто собирается в отпуск, хорошо отдохнуть! 

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

SAP системы в виртуальной среде VMware - I

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

Под средой виртуализации я имею ввиду продукты компании VMware. Для корпоративных систем, наверное, это самое распространённое решение по виртуализации. 

Начнём с того, что SAP поддерживает виртуализацию для своих продуктов. Конечно, официально поддерживаются далеко не все продукты существующие на рынке, а в большей части только корпоративные и имеющие поддержку на уровне Enterprise. Список поддерживаемых и не поддерживаемых продуктов можно найти в SAP note 1122387 - Linux: SAP Support in virtualized environments. 

Если кратко, то в продуктивной среде можно использовать:

• основанные на Xen, но в рамках корпоративных версий Linux и Citrix,
• основанные на KVM, но опять же в рамках Enterprise продуктов (SUSE, Red Hat, IBM и т.п.),
• линейку продуктов VMware от версии 5.x и выше,
• виртуализацию типа LPAR (логическое разбиение физического сервера на отдельные машины) от разных вендоров. 

Точно не поддерживаются Microsoft Hyper-V, Virtual PC, Virtual Server, Oracle VirtualBox, Parallels Virtuozzo Containers, а также контейнеры от Linux (LXC, Docker). Отмечу, что в целях разворачивания обучающих систем, это всё можно смело использовать. И 80% их будет работать. Официальная поддержка относится к продуктивному использованию на боевых системах.

Теперь рассмотрим VMware. За одним этим словом скрывается огромный зоопарк различных систем и решений, который за более чем 20 лет существования компании разрастался, видоизменялся и переименовывался. Типичная конфигурация (рис. 1) представляет собой несколько физических машин, на которых устанавливается как операционная система специальное программное обеспечение - гипервизор. Гипервизор управляет ресурсами физической машины, распределяя их между работающими виртуальными машинами. У VMware гипервизор это продукт под названием ESXi сервер. В целом ESXi представляет собой узкоспециализированный дистрибутив Linux, который умеет рулить оборудованием и виртуальными машинами. VMware ESXi имеет очень небольшие требования к дисковому пространству, поэтому в качестве носителя может быть использована даже SD карта. После старта весь образ этой специфичной ОС хранится в оперативной памяти.

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

Рис. 1. Типовая схема виртуализации VMware.

К серверам подключается один или несколько дисковых массивов. Причём, современные решения от разных вендоров имеют хорошую интеграцию с VMware, поддерживая различные фишки через общий API. Например, "тонкие виртуальные диски" на уровне СХД.

Стоит также отметить, что многие вендоры оборудования тесно работают с VMware и в плане серверного оборудования тоже. В результате на свои сервера поставляют собственные сборки VMware ESXi, куда интегрированы специфичные драйвера и патчи.

Сам по себе ESXi не имеет графического интерфейса: на экране консоли сервера после загрузки появляется минималистичная заставка, отображающая только IP адрес и hostname, по которому можно войти через http-интерфейс для управления средой виртуализации (рис. 2).

Рис. 2. Пример начального экрана консоли сервера с VMware ESXi.

В консоли есть возможность перейти в настройки конфигурации по клавише F2 (в основном,  доступны только настройки сети) и выключить/перезагрузить сервер (клавиша F12). Все остальные функции по управлению виртуальной средой осуществляются через web-интерфейс сервера ESXi. Для очень тонкой настройки есть возможность активировать доступ через ssh (по-умолчанию, доступ закрыт) и войти на сервер через удалённую консоль.

Компания VMware умеет прекрасно продавать свои продукты. За это перед ними снимаю шляпу. Наверное, поэтому web-интерфейс VMware ESXi имеет лишь базовый набор функций. Для получения полного функционала рекомендуется приобрести продукт под названием VMware vCenter Server, который разворачивается в виде отдельной виртуальной машины (внутри представляет собой опять же Linux). И вот уже его web-интерфейс (VMware vSphere Client) имеет больше возможностей. Например, можно делать шаблоны виртуальных машин, клонировать их или осуществлять глубокий мониторинг производительности. На ESXi мониторинг ресурсов ограничивается только текущим состоянием (последний час). 

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

Другой продукт от компании VMware - vMotion позволяет переносить виртуальные машины между физическими узлами одного кластера. В случае ручного переезда останова гостевых операционных систем и приложений не происходит, пользователи процесса даже не замечают.  То есть происходит, так называемая "живая" миграция (live migration). 

В случае автоматического переезда, как в High-Availability решении, возможно два варианта:

• рестарт виртуальной машины на резервной ноде в случае падения на основной,
• "бесшовный" рестарт, который достигается за счёт использования решения VMware Fault Tolerance. 

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

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

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

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

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

Еще можно отметить возможность использования дополнительного уровня резервного копирования через сохранение всей виртуальной машины. Причем можно использовать функцию VMware - snapshot, которая позволит минимизировать время простоя приложения во время создания резервной копии.

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

На русском языке есть очень хорошая книга "Администрирование VMware vSphere 5" от Михаила Михеева. Самая последняя версия - 3-издание от 2012 года. Более свежей версии нет,  так как автора взяли работать в VMware и он книгу обновлять перестал. :) Но для понимая всех продуктов книга подходит отлично. Поищите, в сети её найти можно. 

Продолжение в этом посте.

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

Рассказ про работу системного администратора в Yandex

Хочу поделиться своей находкой - прекрасным рассказом про работу системного администратора от Дмитрия Куликовского из компании Yandex.

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

Я считаю, что мы можем смело отнести себя к системным администраторам, поэтому всё, что говорит автор, относится и к нам.

Я смотрел на скорости 1,5х, вполне реальная скорость для этого видео.

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

Пятничный юмор

Сделал фото объявления. Может быть кому-то пригодится, проект горит. :-)

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