Содержание


Реализация мультисистемного управления и развертывания на платформе IBM PureApplication System

Comments

В IBM PureApplication System версии 2.0 появилась поддержка мультисистемного управления и развертывания. Добавив несколько систем PureApplication System к домену управления, можно выполнять управление каталогом и пользователями для всех систем в этом домене. В рамках домена управления можно создать один или несколько поддоменов развертывания. Поддомен развертывания позволяет развертывать шаблоны и общие сервисы на двух системах. Все это обеспечивает дополнительную гибкость, что упрощает реализацию высокой готовности для таких продуктов, как IBM WebSphere Application Server, IBM DB2® и IBM Business Process Manager.

Это учебное пособие помогает настроить домен управления и поддомен развертывания с использованием средств IBM PureApplication System. Вы также изучите требования к настройке домена управления и поддомена развертывания. Наконец, вы поймете ограничения, которые применяются при развертывании шаблонов с использованием поддомена развертывания. Эта информация существенно поможет вам при планировании мультисистемной реализации IBM PureApplication System.

Перед настройкой своего домена убедитесь в том, что на всех системах IBM PureApplication System установлен пакет исправлений 2.1.0.0 Interim Fix 1 (или его следующая версия).

Правила определения домена управления и поддомена развертывания

Мультисистемное развертывание обеспечивает очевидные преимущества при развертывании определенных продуктов IBM с помощью шаблонов. Конечно, для начала вам потребуется, как минимум, две системы PureApplication System. Чтобы можно было выполнить первое мультисистемное развертывание, необходимо наличие следующих элементов.

  • Домен управления
  • Поддомен развертывания
  • Управляемые извне облачные группы и профиль среды

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

На рис. 1 показан пример домена управления с двумя поддоменами развертывания.

Рисунок 1. Домен управления и поддомены развертывания
Management domain and deployment subdomains
Management domain and deployment subdomains

При настройке домена управления и поддоменов развертывания применяются следующие правила.

  • Ваша система (PureApplication System) или ваш экземпляр (PureApplication Software) может принадлежать не более чем одному домену.
  • Экземпляры PureApplication Software могут принадлежать домену, но не поддомену (мультисистемное развертывание PureApplication Software не поддерживается).
  • Можно создать один или несколько поддоменов, полностью содержащихся в пределах домена. Системы PureApplication System могут принадлежать не более чем одному поддомену в пределах домена.
  • Поддомен может содержать только две системы, однако в домене можно создать неограниченное количество поддоменов.
  • Задержка при коммуницировании между поддоменами ограничивает допустимое расстояние между системами в поддомене – не более 300 км.
  • Внутри каждого домена управления должны использоваться платформы одного типа. Модели IBM PureApplication System W1500 и W2500 (а также PureApplication Software) могут сосуществовать в одном и том же домене. Аналогично, в одном и том же домене могут сосуществовать модели IBM PureApplication System W1700 и W2700. Однако в одном и том же домене управления нельзя одновременно иметь систему на базе Intel® (W1500/W2500) и систему на базе POWER® (W1700/W2700).

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

Требования к сети и к защите домена управления

Прежде, чем приступать к созданию домена управления PureApplication, рассмотрим требования к сети и к защите.

Дополнительные IP-адреса

Прежде, чем добавлять системы PureApplication System к домену, их необходимо сконфигурировать с одним или двумя дополнительными IP-адресами системного управления. Эти адреса используются для управления рабочими нагрузками развернутых виртуальных машин; использование этих адресов будет более подробно объяснено позднее при рассмотрении конфигурации внешней облачной группы. Задание этих дополнительных IP-адресов производится на панели System > Network Configuration, в разделе Additional IPs for Cloud Management by way of External Networks.

Для моделей PureApplication System 1500 и 2500 необходимо сконфигурировать один дополнительный IP-адрес(см. рис. 2); для моделей PureApplication System 1700 и 2700 необходимо сконфигурировать по два дополнительных IP-адреса. В обоих случаях новые адреса должны быть заданы в той же подсети, что существующие IP-адреса системного управления. В качестве дополнительных адресов управления разрешается использовать только адреса версии IPv4.

Рисунок 2. Конфигурирование дополнительного IP-адреса управления доступом к консоли рабочей нагрузки на моделях PureApplication System W1500/W2500
Configuring additional workload console access management IP address on PureApplication System models W1500/W2500
Configuring additional workload console access management IP address on PureApplication System models W1500/W2500

Организация сети

Необходимо убедиться в том, что системы PureApplication System (или установки PureApplication Software) в домене управления делят IP-соединения между всеми своими IP-адресами системного управления. Если между VLAN-сетями системного управления обеих систем имеется брандмауэр, необходимо убедиться в том, что на портах 22, 443, 1191 и 49300–49320 разрешен ICMP-трафик, а также TCP-трафик.

На рис. 3 показано все необходимое для планирования домена с двумя системами PureApplication System.

Рисунок 3. Организация сети для двух систем PureApplication System в одном домене управления
Networking for two PureApplication Systems within a management domain
Networking for two PureApplication Systems within a management domain

Установление доверительных отношений между системами внутри домена управления

По умолчанию системы PureApplication System сконфигурированы так, чтобы доверять заранее установленному специалистами IBM самоподписанному SSL-сертификату от IBM для консоли. Если вы сконфигурировали для консоли свой собственный SSL-сертификат, вам необходимо импортировать этот сертификат в хранилище доверенных сертификатов для всех остальных систем в этом домене. На рис. 3 показан домен с двумя системами PureApplication System.

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

  1. Сохраните сертификат для системы, которая добавляется к домену, или у которой обновляется сертификат консоли. Если у вас есть копия сертификата, используйте этот crt-файл. В качестве альтернативного варианта можно получить текущий сертификат из системы (перейдите к системе в своем браузере, нажмите на пиктограмму безопасности браузера и экспортируйте сертификат в виде crt-файла).
  2. С помощью интерфейса командной строки найдите имя местоположения для системы, которая добавляется к домену, или у которой заменяется сертификат консоли:
    $ bin/pure -h hostnameA -u user -p password -c "print admin.racks[0].location_name" 
    1000056
  3. Используя имя местоположения, полученное на шаге 2, с помощью интерфейса командной строки импортируйте сертификат этой системы на все остальные системы в домене. Для выполнения следующей команды вы должны иметь роль администратора аппаратных средств с разрешением Manage hardware resources (Управление аппаратными ресурсами) или роль администратора безопасности с разрешением Manage security (Управление безопасностью).
    $ bin/pure -a -h hostnameB -u user -p password -c 
    "deployer.peercertificate._import({'certfilepath':'systemA.crt','peername':'1000056'})"
    $ bin/pure -a -h hostnameC -u user -p password -c
    "deployer.peercertificate._import({'certfilepath':'systemA.crt','peername':'1000056'})"
  4. Повторяйте этот процесс по мере необходимости для импорта сертификатов остальных систем на другие системы в домене.

Безопасность систем

Все системы в домене управления должны быть настроены на использование LDAP и на использование одной и той же конфигурации LDAP. Для настройки выберите System > System Security (рис. 4).

Рисунок 4. Раздел System Security в веб-консоли PureApplication
System Security in PureApplication web console
System Security in PureApplication web console

Фактически это позволяет системам иметь совместно используемую функциональность доверительного управления для аутентификации пользователей. Для выполнения большинства действий в поддомене, таких как копирование артефактов или развертывание шаблонов, требуется LDAP-пользователь (рис. 5).

Рисунок 5. Пример LDAP-пользователя в веб-консоли PureApplication
Example of an LDAP user in PureApplication web console
Example of an LDAP user in PureApplication web console

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

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

Необходимые полномочия

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

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

Рисунок 6. Создание домена управления в веб-консоли PureApplication
Example of an LDAP user in PureApplication web console
Example of an LDAP user in PureApplication web console

Синхронизация каталога

Содержимое каталога можно передавать и синхронизировать между системами внутри одного и того же домена управления. Управление этими операциями можно осуществлять из веб-консоли или через интерфейс командной строки. Однако в версии PureApplication System V2.1 эта функциональность ограничена виртуальными образами, пакетами скриптов и дополнительными модулями. Например, экспорт и импорт шаблона виртуальной системы необходимо осуществлять вручную.

Соображения относительно модернизации и сочетания разных выпусков

Вплоть до завершения процесса модернизации систем в домене и поддомене могут иметься системы с версиями разного уровня. Платформа PureApplication System поддерживает эту конфигурацию с некоторыми ограничениями.

Дополнительные соображения для конкретных версий PureApplication System содержатся в соответствующей документации, например, в информация о выпуске. Версия PureApplication V2.1.0.0 имеет специфические требования по сосуществованию.

Поддомен развертывания

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

Настройка внешней iSCSI-цели

Между двумя системами PureApplication System в поддомене существуют отношения зеркалирования: эти системы в режиме реального времени делятся информацией о развернутых экземплярах. Эти данные хранятся в новом LUN-устройстве (logical unit number) с именем SubdomainData, которое создается на главном узле хранения каждой системы в тот момент, когда создание поддомена завершено. Чтобы систему можно было добавить к поддомену, на ней должно быть доступно не менее 512 ГБ. Чтобы проверить объем свободных ресурсов хранения, выберите Hardware > Storage Devices. Соответствующий пример показан на рис. 7.

Рисунок 7. Подтверждение свободной емкости хранилища на главном узле хранения PureApplication System
Confirming free storage capacity on master storage node in PureApplication System
Confirming free storage capacity on master storage node in PureApplication System

Задержка при коммуницировании между поддоменами ограничивает допустимое расстояние между системами в поддомене – не более 300 км. Кроме того, для отношений зеркалирования требуется предоставление внешней iSCSI-цели для использования в качестве схемы разрешения конфликтов. Это позволяет системам определить кворум в случае, если они потеряют связь друг с другом. ISCSI-цель должна иметь минимальный размер 1 ГБ; на нее распространяются такие же ограничения по расстоянию и задержке, как и для систем.

Поскольку схема разрешения конфликтов используется для определения кворума, если системы в поддомене имеют отдельные источники питания и подсети, мы рекомендуем разместить схему разрешения конфликтов на третьей сетевой системе с отдельным источником питания. Кроме того, брандмауэр должен разрешать iSCSI-трафик (порты TCP 860 и 3260) между первичными, вторичными и плавающими IP-адресами управления на ваших системах PureApplication System и, как минимум, одним IP-адресом iSCSI-цели. На рис. 8 показаны связи между системами и схемой разрешения конфликтов.

Рисунок 8. Связи систем со iSCSI-целью в качестве схемы разрешения конфликтов
System communications with iSCSI tiebreaker
System communications with iSCSI tiebreaker

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

Данные развертывания, хранящиеся и совместно используемые на этом внутреннем зеркале, не подвергаются шифрованию: ни в покое на контроллерах системы хранения, ни в процессе перемещения между IP-адресами системного управления в рамках зеркалирования между системами. Эти данные содержат защищенные ключи, которые система использует при управлении развернутыми экземплярами. Вам следует запланировать надлежащую физическую защиту систем и надлежащую защиту сети для перемещаемых данных.

Создание поддомена развертывания

Конфигурирование домена управления и его поддоменов развертывания осуществляется через веб-консоль PureApplication. Перейдите к пункту System > Management Domain Configuration и нажмите Create Deployment Subdomain (рис. 9).

Рисунок 9. Конфигурация поддомена развертывания в веб-консоли PureApplication
Deployment subdomain configuration in PureApplication web console
Deployment subdomain configuration in PureApplication web console

Чтобы после создания поддомена добавить в него свои системы PureApplication System, нужно "перетащить" их в поддомен или нажать кнопку Add a Location в поддомене. Когда вы добавите вторую систему в поддомен, вам будет предложено сконфигурировать iSCSI-схему разрешения конфликтов (рис. 10). Обратите внимание, что параметры user (пользователь) и password (пароль) в данном случае являются опциональными.

Рисунок 10. Диалоговое окно конфигурирования iSCSI-схемы разрешения конфликтов
iSCSI tiebreaker configuration dialog
iSCSI tiebreaker configuration dialog

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

Рисунок 11. Сконфигурированный поддомен развертывания в веб-консоли PureApplication
Configured deployment subdomain in PureApplication web console
Configured deployment subdomain in PureApplication web console

Управляемые извне облачные группы и профили среды

До появления версии PureApplication V2.0 внутренняя VLAN-сеть управления на базе IPv6 автоматически конфигурировалась для каждой облачной группы. Эта VLAN-сеть используется для связи между PSM-узлами (PureSystem Management Node) и виртуальными машинами (ВМ), а также для связи между общими сервисами и виртуальными машинами.

Чтобы поддерживать мультисистемное развертывание, в версии V2.0 были реализованы так называемые "управляемые извне облачные группы". Вместо того чтобы использовать для управляющего коммуницирования внутреннюю VLAN-сеть на базе IPv6, эти облачные группы используют внешнюю управляющую VLAN-сеть. Это требуется для управляющего коммуницирования между этими двумя системами внутри поддомена развертывания.

Платформа PureApplication System по-прежнему полностью поддерживает облачные группы с внутренним управлением. Управляемые извне облачные группы требуются для мультиоблачного и мультисистемного развертывания; они имеют определенные ограничения по сравнению с облачными группами с внутренним управлением, которые будут описаны позднее. По этой причине вам следует оценить свои потребности развертывания и тщательно спланировать выделение вычислительных узлов облачным группам с внутренним и/или внешним управлением. Вы не сможете изменить тип управления у существующих облачных групп.

Управляющая VLAN-сеть для управляемой извне облачной группы

Прежде чем можно будет создать управляемую извне облачную группу, вам нужно настроить внешнюю VLAN-сеть внутри вашей сети и сконфигурировать соединение этой VLAN-сети с системой PureApplication. Позднее вы увидите, что вам также нужно создать IP-группу для этой внешней VLAN-сети управления, а также специальный профиль среды.

Дополнительные IP-адреса управления

При использовании управляемых извне облачных групп диспетчеры PureSystems Manager должен быть способны обращаться к развернутым виртуальным машинам через внешнюю управляющую VLAN-сеть облачной группы. Для этого требуется, чтобы дополнительные сервисы управления были видны сети управления PureApplication. Из этой внешней сети они должны быть в состоянии получить доступ к внешней сети управления облачной группы. Как правило, для этого требуется настройка маршрутизации между этими VLAN-сетями внутри сети центра обработки данных.

В дополнение к (плавающему) IP-адресу системной консоли консоль рабочей нагрузки должна быть сконфигурирована с IP-адресом версии IPv4 внутри сети управления PureApplication. При работе с моделью PureApplication System 1700 или 2700 еще один IP-адрес версии IPv4 должен быть назначен для управления функциональностью DLPAR. Новые IP-адреса версии IPv4 должны быть определены внутри существующей сети управления PureApplication; то есть с использованием той же сети и той же подсети, как у исходного (плавающего) IP-адреса версии IPv4 системной консоли.

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

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

Рисунок 12. Конфигурирование дополнительных IP-адресов управления на моделях PureApplication System W1500/W2500
Configuring additional management IP addresses on PureApplication System models W1500/W2500
Configuring additional management IP addresses on PureApplication System models W1500/W2500

IP-группа для управляющей VLAN-сети

Прежде, чем вы сможете создать новую управляемую извне облачную группу, у вас должна быть, как минимум, одна IP-группа, у которой параметр Used For (используется для) имеет значение Cloud Management (управление облаком). Определение такой IP-группы не отличается от определения IP-группы, у которой параметр Used For имеет значение Data (данные); это нормальная IP-группа. На рис. 13 показано, как определить эту IP-группу, используемую для управления облаком. Не забудьте приписать ее к VLAN-сети управления облачной группой, которую вы задали и сконфигурировали ранее.

Рисунок 13. Конфигурирование IP-группы, используемой для управления облаком
Configuring an IP group used for Cloud Management
Configuring an IP group used for Cloud Management

В веб-консоли можно видеть, что эта новая IP-группа действительно используется для управления облаком. Соответствующий пример показан на рис. 14.

Рисунок 14. Конфигурирование IP-группы управления облаком
Configuring a Cloud Management IP group
Configuring a Cloud Management IP group

Маршрут по умолчанию для виртуальных машин обычно присваивается первому интерфейсу данных (eth1 или en1). Вследствие этого теперь вам нужно сконфигурировать дополнительные маршруты для интерфейса управления eth0 или en0, чтобы гарантировать, что трафик управления не маршрутизируется через интерфейс eth1 или en1. Дополнительные маршруты можно задать как часть определения IP-группы.

Для каждой IP-группы управления облаком необходимо сконфигурировать следующие маршруты.

  • Маршрут подсети через адрес шлюза IP-группы к VLAN-сети управления локальной системы.
  • Маршрут подсети через адрес шлюза IP-группы к каждой сети, используемой любой другой IP-группой управления облаком, с которой эта IP-группа делит профиль среды (это требуется только в том случае, когда различные IP-группы управления облаком не используют совместно одну и ту же VLAN-сеть).

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

Как уже говорилось, в сети центра обработки данных должен присутствовать уровень 3 сетевой маршрутизации между различными VLAN-сетями. На рис. 15 показано, как все это будет выглядеть для двух систем PureApplication System. Маршрутизация имеет место для следующих VLAN-сетей.

  • VLAN-сеть управления облачной группой "C1" и VLAN-сеть системного управления "S1"
  • VLAN-сеть управления облачной группой "C2" и VLAN-сеть системного управления "S2"
  • VLAN-сеть управления облачной группой "C1" и VLAN-сеть управления облачной группой "C2"
  • VLAN-сеть системного управления "S1" и VLAN-сеть системного управления "S2"
  • VLAN-сеть данных "D1" и VLAN-сеть данных "D2".
Рисунок 15. Управляющее коммуницирование для управляемых извне развертываний
Management communications for externally managed deployments
Management communications for externally managed deployments

Как показано на рис. 15, необходимо также гарантировать, что между этими VLAN-сетями разрешены определенные сетевые коммуникации. Это подразумевает открытие портов в брандмауэрах, если таковые имеются между VLAN-сетями. Это может усложнить реализацию, поэтому здесь конкретно указаны необходимые протоколы, порты и направления. Связь между двумя VLAN-сетями данных ("D1" и "D2") здесь не упоминается; она в значительной степени зависит от конкретного шаблона, который развертывается в поддомене развертывания.

С учетом вышеизложенного мы настоятельно рекомендуем использовать расширенные VLAN-сети в обеих системах PureApplication System, где это возможно. Сетевые специалисты часто предлагают расширенные VLAN-сети для центров обработки данных. Использование расширенных VLAN-сетей для управления облаком и передачи данных значительно упрощает мультисистемную реализацию; соответственно, использование расширенной управляющей VLAN-сети рекомендуется с точки зрения единообразия.

Вы можете использовать прилагаемый демонстрационный Python-скрипт validateRouting.py, чтобы проверить конфигурацию маршрутизации у всех IP-групп управления, на которые ссылаются управляемые извне профили среды. Этот скрипт можно исполнить на любой системе, при условии, что он способен получить доступ к плавающему адресу диспетчера PureSystems Manager. Этот скрипт использует профили среды для определения того, какие IP-группы должны иметь маршруты друг к другу, поэтому до исполнения этого скрипта вам нужно создать и сконфигурировать профили среды. Запустите этот скрипт с использованием идентификатора LDAP-пользователя, имеющего минимальные полномочия "view all workload resources" (просматривать все ресурсы рабочей нагрузки" и "view all hardware resources" (просматривать все аппаратные ресурсы). С помощью этого скрипта можно протестировать конфигурацию внешнего управления на одиночной системе, а также в мультисистемном поддомене; если вы тестируете мультисистемный поддомен, вам следует проверить обе стойки поодиночке.

Для простоты используйте интерфейс командной строки PureApplication. В листинге 1 показано, как запустить Python-скрипт на исполнение. Скрипт выдаст предупреждения, если ожидаемые маршруты не будут найдены, или сообщение об успехе, если все ожидаемые маршруты были сконфигурированы правильно.

Листинг 1.
 C:\Tools\pure.cli\bin>pure -h intel-system-2 -u admin -p ******** 15 -f C:\Temp\validateRouting.py Checking profile ExtMgdTest Checking profile RedBook HADR External Checking profile RedBook-External-R1R4 Checking profile Redbook-External-R1R4 w10.x.x.x SUCCESS

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

Создание управляемых извне облачных групп

Рисунок 16. Создание управляемых извне облачных групп
Creating an externally managed cloud group
Creating an externally managed cloud group

Создавая управляемую извне облачную группу, вы не выбираете идентификатор (ID) VLAN-сети. Вместо этого вы создаете одну или несколько IP-групп, у которых параметр Used For имеет значение Cloud Management, а не Data. Эти IP-группы используются для присвоения адресов версии IPv4 интерфейсам управления виртуальных машин, развернутых в этих облачных группах. Как и у IP-групп, используемых для передачи данных, для адресов в IP-группах управления облаком в DNS должно быть задано прямое и обратное преобразование имен.

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

Создание профилей управляемой извне среды

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

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

Работа с мультисистемным развертыванием

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

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

    CWZKS0417E: Failed to deploy because one or more virtual images do not support multi-target deployment.

  • Виртуальные аппаратно-программные комплексы (appliance) невозможно развернуть в профилях управляемой извне среды.
  • Шаблоны, опирающиеся на плагины, и шаблоны таких типов, которые зависят (прямо или косвенно) от шаблонов типа Foundation версии ниже 2.1.0.0, невозможно развернуты в профилях управляемой извне среды. Все плагины должны требовать использования версии Foundation 2.1 или выше – это является признаком их совместимости с управляемыми извне сетями и с мультисистемными ссылками.

Развертывание в профиле управляемой извне среды

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

Общие сервисы

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

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

Рисунок 17. Различие в области действия общих сервисов для профилей сред с внутренним и внешним управлением
Difference in scope of shared services for internally and externally managed environment profiles
Difference in scope of shared services for internally and externally managed environment profiles

Соображения относительно безопасности

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

Соображения относительно готовности, масштабирования и восстановления

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

Если отказавшая виртуальная машина не рассматривается как персистентная, то во многих случаях система попытается восстановить ее путем создания новой виртуальной машины методом клонирования. В случае мультисистемного развертывания попытка такого восстановления предпринимается только на такой же системе, как исходная отказавшая виртуальная машина. Дополнительные сведения о персистентных и неперсистентных виртуальных машинах можно получить в справочной системе PureApplication Knowledge Center.

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

Сущность под названием shared service provider (поставщик общего сервиса) имеется для каждого общего сервиса, но только в системе, из которой было инициировано развертывание общего сервиса. Это означает, что если эта развертываемая система временно недоступна поддомену, новые клиенты общего сервиса не могут подключиться к общему сервису даже если виртуальные машины общего сервиса на оставшейся системе по-прежнему способны обслуживать клиентов и даже если все клиентские виртуальные машины находятся на выжившей системе.

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere, Облачные вычисления
ArticleID=1031850
ArticleTitle=Реализация мультисистемного управления и развертывания на платформе IBM PureApplication System
publish-date=05192016