DLPAR (Dynamic Logical Partitioning)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 11:56, 3 декабря 2016.

Технология DLPAR (Шаблон:Lang=en) позволяет динамически без остановки системы изменять количество ресурсов (доли процессора, память, интерфейсы ввода/вывода), выделенные для LPAR. Это чрезвычайно полезная возможность, поскольку системы могут более эффективно управлять различными рабочими нагрузками. При пиковой загрузке системы к ней можно добавить дополнительные ресурсы. При низкой загрузке эти неиспользуемые ресурсы можно забрать и отдать другим приложениям.

В LPAR для каждого раздела необходимо выделить отдельный процессор, область памяти 256 Мбайт и слот для адаптера ввода-вывода. Одно из основных преимуществ LPAR состоит в более точном контроле за распределением ресурсов между разделами, который позволяет получить раздел с практически любой конфигурацией.

Динамические LPAR расширяют эти возможности и позволяют точно перераспределять ресурсы не только при активизации разделов, но и во время их работы. Отдельные процессоры, области памяти и слоты адаптеров ввода-вывода можно выводить в так называемый свободный пул и выделять из него ресурсы разделам либо переносить эти ресурсы непосредственно между разделами в любом количестве и комбинациях. Ресурсы, перераспределенные с помощью DLPAR, имеют тот же набор характеристик, что и ресурсы, выделенные разделам при загрузке.[1]

Определения

LPAR(Logical Partitioning) - это функция системы, обеспечивающая дополнительную гибкость за счет одновременного выполнения на одном сервере нескольких образов операционной системы.

IBM Server pSeries – мощные, производительные, надежные, технологически совершенные UNIX-серверы. IBM Server pSeries работают под управлением операционной системы AIX, самой современной ОС с точки зрения системного и сетевого управления.

Динамическое и автоматическое перераспределение ресурсов

Хотя первая версия динамических LPAR обеспечивает все возможности перемещения ресурсов между работающими разделами, такие перемещения не могут быть спонтанными и неожиданными. Перемещения ресурсов LPAR полностью динамичны (без нарушения работы разделов). Автоматизацию DLPAR можно реализовать на основе скриптов. Эта возможность позволяет в будущем расширить автоматизацию и управление нагрузками.[2]

Стоит отметить, что динамические LPAR обеспечивают большую гибкость в условиях изменяющихся нагрузок и при развертывании серверов. Вот некоторые примеры:

  • временное перемещение процессоров из раздела для тестирования в продукционный раздел в период пиковых нагрузок;
  • перемещение памяти в раздел, где слишком часто происходит подкачка страниц с диска;
  • перемещение между разделами редко используемых устройств ввода-вывода, например, CD-ROM для установки ПО или ленточного привода для резервного копирования;
  • объединение набора процессоров, памяти и ресурсов ввода-вывода в свободный пул и создание из них нового раздела;
  • выделение нескольких LPAR в минимальной конфигурации на одной машине в логический резервный сервер для основных серверов или в горячий резерв;
  • выделение свободных ресурсов при сбое основного сервера резервному LPAR, чтобы он смог взять на себя нагрузку.

Использование DLPAR

DLPAR не влияет на работу большинства приложений, но если добиться динамической настройки использования всех системных ресурсов всем программным стеком с учетом операций DLPAR, то можно получить определенное конкурентное преимущество. Для этого архитектура системы была расширена таким образом, чтобы приложения и промежуточное ПО могли также участвовать в событиях DLPAR и соответственно расширяться, и взаимодействовать с базовой ОС при добавлении и изъятии ресурсов.

ОС AIX 5.2 обеспечивает два механизма оповещения приложений и промежуточного ПО о том, что запрос DLPAR выполняется. Разработчики могут использовать скрипты DLPAR или API-интерфейсы для динамического изменения размеров подсистем. Первый из указанных способов могут также использовать системные администраторы для определения своих собственных политик работы с DLPAR. Например, системному администратору может потребоваться приостановить приложение, если известно, что из-за него не удается выполнить запрос DLPAR, а предоставляемый приложением сервис не критичен для работы системы.

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

Управление DLPAR

Рис.1. Перемещение ресурсов между разделами

Для операций с динамическими LPAR в pSeries нужны три основных компонента:

  • Системный микрокод, включая LPAR Hypervisor, обеспечивает добавление или изъятие ресурсов работающего раздела.
  • AIX 5L Version 5.2 предоставляет команды и сервисы ядра, позволяющие динамически занимать и освобождать ресурсы AIX.
  • IBM Hardware Management Console (HMC) для pSeries обеспечивает управление перемещением ресурсов с помощью графического интерфейса пользователя или командной строки.

Комбинация этих трех компонентов обеспечивает гибкое интегрированное управление перемещением ресурсов DLPAR.

Для перемещения ресурсов LPAR из одного раздела в другой нужно последовательно выполнить три операции, показанные на Риc.1.

  1. HMC посылает сетевой запрос к AIX в разделе A на освобождение ресурса и перевода его в пассивное состояние (quiesced state). Ресурс останавливается и переходит под контроль гипервизора.
  2. HMC посылает на гипервизор команду передать ресурс из раздела A в раздел B.
  3. HMC посылает сетевой запрос к AIX в разделе B на принятие ресурсов от гипервизора и конфигурирование его для использования.

Кроме перемещения ресурсов напрямую между разделами, HMC позволяет удалять ресурсы из раздела и помещать их в свободный пул или брать ресурсы из свободного пула и добавлять в раздел. Для такой автоматизации операций DLPAR требуется сетевое соединение между HMC и разделами. Операции DLPAR можно проводить и без сетевого соединения, но для этого потребуется выполнить три шага независимо и вручную. Поскольку HMC использует то же самое сетевое соединение для сбора сообщений о сбоях оборудования и учетных данных из приложения Service Focal Point, настоятельно рекомендуется все же обеспечить это соединение.

Мониторинг операций DLPAR

Имеется несколько способов мониторинга операций DLPAR. По умолчанию AIX представляет информацию о текущих запросах DLPAR на панели оператора в виде кодовых комбинаций светодиодов и коротких текстовых сообщений, которые выводятся в окне отображения раздела пользовательского интерфейса HMC. Пользователь также может запросить более подробный отчет, задав уровень детализации в диалоговом окне HMC при запросе DLPAR. Этот отчет включает информацию о работе базовой ОС, которую можно дополнить информацией о конкретных приложениях и промежуточном ПО. Эта информация выдается пользователю на HMC. По умолчанию подробный отчет не выдается.

Детальные отчеты можно также получить с помощью команды AIX syslog, обладающей большей гибкостью. Если предпочтителен этот метод, то администратор должен сконфигурировать саму функцию syslog. По умолчанию этот отчет отключен.

В случае ошибки при выполнении операции DLPAR пользователь должен выяснить ее причину из файла регистрации ошибок error log AIX. Обычно error log используется для перехвата условий возникновения ошибок, вызванных расширениями ядра и приложениями, которые в большинстве случаев может исправить сам пользователь. Например, если процессор назначен для выполнения какого-то задания и, соответственно, его нельзя вывести из работы, то делается запись в error log entry с указанием процесса, который следует переконфигурировать.

DLPAR и безопасность

Возможность перемещения ресурсов между разделами не означает ослабления основной безопасности среды LPAR. ОС раздела просто "не видит" другие разделы или ресурсы за пределами своего раздела, в том числе и те, которые находятся в свободном пуле. Она "видит" только набор так называемых коннекторов (connectors) для виртуальных ресурсов, в которых можно конфигурировать процессоры, память и ресурсы ввода-вывода. После того, как HMC добавляет ресурс в раздел, она посылает сообщение его ОС с запросом изменить один или несколько виртуальных коннекторов. Если ОС попытается сделать это до того, как HMC и гипервизор добавили ресурсы в ее раздел, она просто получит сообщение об ошибке выполнения операции, указывающей, что ресурсы отсутствуют.

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

Сетевое соединение HMC с разделами использует механизмы защищенной передачи данных на основе технологии IBM Reliable Scalable Cluster Technology (RSCT), поэтому только HMC может выдать запрос DLPAR. Каждому пользователю HMC присваивается конкретная роль, которая и определяет, разрешено ли ему выполнять такие действия.

Гибкое распределение памяти

Одной из ключевых целей реализации этой функции было значительное сокращение объема реальной памяти, необходимой для ОС. В версии AIX 5L Version 5.1 гипервизор должен был выделить начальный блок непрерывной физической памяти, который масштабировался до общего объема логической памяти, выделенной логическому разделу. В некоторых случаях это приводило к невозможности активизировать раздел, особенно крупный, из-за того, что ОС не хватало непрерывной памяти, хотя суммарный объем свободных ресурсов в системе был достаточен для раздела.

Из-за этой проблемы пользователю приходилось изменять размер раздела, выключать другие разделы и в некоторых случаях даже перезагружать систему. В AIX 5.2 эта проблема была устранена, так что свободные ресурсы можно брать из любого места в системе. Для активизации этой функции администратор должен выбрать новую опцию Small Real Mode Address Region при создании или редактировании профиля раздела на консоли HMC. Реконфигурирование процессоров и памяти полностью интегрировано с AIX, поэтому в большинстве случаев для выполнения этой операции от администратора не требуется никаких действий. Реконфигурирование PCI-слотов ввода-вывода несколько сложнее - администратор должен зарегистрироваться в разделе и выполнить процедуру AIX для горячей замены PCI с помощью GUI-интерфейса SMIT.

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

Влияние на производительность

Большинство операций DLPAR можно выполнить за пару минут, за исключением изъятия памяти, продолжительность которого зависит от заданного пользователем объема. Обычно изъятие 4 Гбайт памяти занимает 1-2 мин (в зависимости от состояния памяти в разделе).[3]

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

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

Таким образом, хотя ОС построена так, что она способна идентифицировать ресурсы и настроить их использование, для оптимального решения требуется системный подход, охватывающий также промежуточное ПО и приложения. В то же время в большинстве случаев система хорошо масштабируется, даже если приложения и промежуточное ПО не поддерживают DLPAR (за счет того, что в базовой ОС уже реализована существенная поддержка DLPAR). В частности, файловая система AIX JFS2 File System и сетевые подсистемы были усовершенствованы для работы с DLPAR, поэтому ОС хорошо сбалансирована по отношению к физическим конфигурациям более низкого уровня.

Источники

  1. habrahabr[Электронный ресурс] : Беглый обзор IBM Power Systems / Дата обращения: 22 ноября 2016 - Режим доступа: https://habrahabr.ru/post/116948/
  2. habrahabr[Электронный ресурс] : Lotus Domino и AIX DLPAR / Дата обращения: 22 ноября 2016 - Режим доступа: http://www.ibm.com/developerworks/ru/library/au-DominoandDLPARver1/index.html
  3. bytemag[Электронный ресурс] : Динамические разделы в серверах IBM eServer pSeries / Дата обращения: 22 ноября 2016 - Режим доступа: http://www.bytemag.ru/articles/detail.php?ID=8579

Ссылки

  1. http://www.intuit.ru/studies/courses/1147/223/lecture/5774
  2. http://ru.knowledgr.com/01510126/ДинамическоеЛогическоеРазделение
  3. http://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.aix.70.doc/user/aix_dlpar.html
  4. http://www.torontoaix.com/hmc-commands-and-features/dlpar
  5. http://lparbox.com/how-to/virtualization/29