Восстановление AIX-систем после аварий

Разрешение ресурсных конфликтов

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

Дэна Френч, Президент, Mt Xia Inc.

Карьера мистера Френча в IT индустрии охватывает три десятилетия и множество отраслей. Он работает в областях непрерывности бизнеса, аварийного восстановления и повышения отказоустойчивости. Он спроектировал и разработал множество программ для автоматизации процессов автоматического восстановления и повышения отказоустойчивости. Он известен своим подходом к системному администрированию как к автоматическому, ориентированному на бизнес процессу, а не как к системно-ориентированному, интерактивному процессу. Вы можете связаться с ним по адресу dfrench@mtxia.com.



16.06.2010

Введение

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

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

Можно выделить несколько типичных проблем, возникающих во время аварийного восстановления систем AIX:

  • Резервные системы по своим характеристикам (тип, число процессоров и емкость) отличаются от продукционных систем; обычно это более новые системы с обновленными ОС
  • Проблемы прав доступа пользователей и групп
  • Множество экземпляров одного приложения (каждое приложение развертывается на отдельной продукционной системе, но в резервной системе может быть установлено несколько приложений)
  • Проблемы с сетевыми именами и проблемы адресации
  • Продукционные приложения (привязанные к конкретному сетевому адресу или сетевому имени во время установки)
  • Конфликты между именами узлов и именами хостов в сети (конфликты между системами, установленными в ЦОДе, и новыми системами, которые запускаются при аварии)
  • Многочисленные стандарты реализации для разной функциональности (автономность, отказоустойчивость и восстановление после катастроф)

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

Сетевые конфликты

Наилучший способ избежать сетевых конфликтов при осуществлении аварийного восстановления – это обеспечить уникальность каждого сетевого адреса (TCP/IP) или имени в пределах предприятия. В организациях с несколькими ЦОДами сетевые адреса (TCP/IP) основных центров не должны переключаться на резервные, поскольку для этого требуется перенастройка маршрутизаторов и коммутаторов, что может нарушить работу продукционных систем, на которых запускаются приложения в случае аварии. Следовательно, продукционные приложения производства нельзя «привязывать» к уникальным сетевым адресам TCP/IP, так как при сбоях эти адреса будут заменены на другие. Приложения и пользователи никогда не должны использовать или определять сетевые службы по их TCP/IP адресу, они должны обращаться по символьному имени. Более того, символьное имя, используемое приложениями и пользователями, должно быть только псевдонимом (алиасом), указывающим на имя хоста.

В этом контексте под термином узел понимается любая система в целом, независимо от того, является ли она частью кластера или автономной системой, а имя узла— это составная часть имени хоста. Имя узла может состоять только из буквенно-цифровых символов. Одно или несколько имён хоста могут быть получены на основе имени узла системы. В Таблице 1 рассматривается узел с именем abcdefgh00 и пятью хостами.

Таблица 1. Имена узлов и хостов
Имя узлаИмя хостаОписание
abcdefgh00abcdefgh00-bootЭти имена узла и хоста обращаются к IP-адресу, присвоенному сетевому адаптеру во время загрузки.
abcdefgh00abcdefgh00-persЭти имена узла и хоста обращаются к постоянному IP-адресу, присвоенному сетевому адаптеру, который будет присутствовать всегда.
abcdefgh00abcdefgh00-rg01Эти имена узла и хоста обращаются к IP-адресу службы, назначенному сетевому адаптеру, который доступен во время работы служб приложений.
abcdefgh00abcdefgh00-mgmtЭти имена узла и хоста обращаются к IP-адресу управления системой, присвоенному сетевому адаптеру, который всегда присутствует.
abcdefgh00abcdefgh00Эти имена узла и хоста обращаются к IP-адресу службы, назначенному сетевому адаптеру, который доступен, когда система готова обеспечить сервисы приложений.

В Таблице 1 имя хоста abcdefgh00 случайно совпадает с именем узла системы, однако несмотря на совпадение имен их назначения различны.

Символьные имена, используемые приложениями и пользователями, не должны являться какими-либо именами хостов, указанными в таблице 1. Они должны использовать только псевдонимы для этих имен хостов, как показано в таблице 2.

Таблица 2. Имена хостов и псевдонимы
Имя хостаПсевдоним
abcdefgh00-rg01 myappl5
ijklmnop02-rg22db2sys
qrstuvwx17-rg05mqseries5

Обратите внимание, что в таблице 2 все имена хостов имеют расширение -rg##. Эти расширения представляют собой ссылку на адрес службы группы ресурсов. Этот подход, принятый в HACMP (High Availability Clustered Multi Processing), можно применить в любой кластерной или автономной системе для ссылок на сетевую службу, предоставляемую системой. Любые приложения или пользователи, требующие доступа к системным сетевым службам, должны ссылаться только на псевдонимы, которые перенаправляют их на имя хоста группы ресурсов, который, в свою очередь, перенаправляет на IP-адрес службы группы ресурсов.

В случае сбоя продукционные приложения перезапускаются в резервном ЦОДе на системах с другими TCP/IP-адресами, именами узлов и хостов. Для доступа к приложениям, перезапущенным в резервном центре нужно только перенастроить псевдонимы в DNS на новое имя группы хостов в резервном центре. Приложения и пользователи не нуждаются в каких-либо изменениях — все приложения автоматически перенаправляются на правильное местоположение и сервер приложений.

Имена пользователей

Каждому сотруднику организации должен быть назначен уникальный идентификатор, который удаляется в случае его увольнения. Это гарантирует возможность отслеживания операций персонала при расследовании проблем, спорных вопросов и действий. Имя пользователя должно состоять из буквенно-цифровых символов и быть действительным для всех систем в пределах организации так, чтобы у каждого человека было только одно имя пользователя. Определение структуры имени пользователя, работающей на всех системах и обеспечивающей достаточную гибкость, может быть очень сложной задачей. Причиной этого является то, что многие организации сегодня работают с различными операционными системами, каждая из которых предъявляет свои требования к структуре имени пользователя. Чтобы разработать общую структуру имени пользователя, нужно учесть требования Microsoft® Windows®, множества вариантов UNIX®, Linux®, OS/400®, RACF®, и других операционных систем.

Рассмотрим несколько структур имени пользователя, которые работают во всех этих окружениях:

  • от четырех до семи строчных буквенно-цифровых символов, начинающихся с буквы;
  • семь строчных буквенно-цифровых символов, первые три символа из которых — буквенные, последние четыре — цифровые;
  • семь строчных буквенно-цифровых символов, первые четыре символа из которых — буквенные, последние три — цифры.

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

Идентификаторы пользователей и номера идентификаторов групп

При планировании сценариев аварийного восстановления, во избежание конфликтов или нарушений правил безопасности, нужно помнить, что пользовательские идентификаторы (UID) и номера идентификаторов групп (GID) должны быть уникальны и назначены для пользователей и групп в пределах всего предприятия.

Для поддержки и эксплуатации базы данных значений UID и GID и связанных с ними имён пользователя и названия группы, для вычисления значений UID и GID должен использоваться воспроизводимый алгоритм. Простым алгоритмом для произведения расчёта значений UID и GID является команда sum в сочетании с опцией -r для генерирования значений Berkeley cksum. Вот пример использования этого алгоритма:

$ print "abc1234" | sum -r
  29247  1

Все команды, показанные в этой серии статей, написаны в синтаксисе Korn Shell.

Вариант приведённой выше команды — с применением синтаксиса Korn Shell 93:

/usr/bin/ksh93
  UID=$( print "abc1234" | sum -r )
  UID=${UID//[!0-9]/}
  print "UID=${UID}"

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

Названия группы ресурсов

Понятие группы ресурсов используется в этой статье в более широком смысле, чем просто отказоустойчивый объект. Здесь термин "группа ресурса" используется для определения любого логического объединения ресурсов, которое может содержать диск, ресурсы ввода/вывода, пользователей, приложения и т.д., независимо от того, участвует ли узел в отказоустойчивом кластере или в схеме, обеспечивающей аварийное восстановление. В данном контексте группа ресурсов должна рассматриваться независимо от любой машины, сервера или ЦОДа.

Следующее определение даёт стандарт, определяющий имя группы ресурса (таблица 3).

Таблица 3. Определение структуры названия группы
Код приложения+Среда+Функция+ID покупателя или клиента+Итоговый ID
Три символа+Один символ+Один символ+Два символа+Одна цифра

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

Таблица 4. Структура определения названия группы ресурса
Компонент названия группы ресурсаКоличество символовЗначения
Код приложения3db2 = DB2®
nim = NIM
mqm = MQSeries®
tsm = Tivoli® Storage Manager
vio = Virtual I/O
Среда1a = принятие
g = pre-production/Gold
d = тестирование/разработка
p = производство
t = тестирование
x = аварийное восстановление
Функция1a = приложение
c = сочетание/универсальность
d = база данных
m = управление
u = обслуживание
Компания или другой идентификатор 2ac = Acme
mx = Mt Xia
ib = IBM
Итоговый идентификатор10-9,A-Z,a-z
Таблица 5. Примеры названий группы ресурса
Код приложенияСредаФункцияID покупателя или клиентаИтоговый IDПример названия группы ресурса
db2apmx0db2apmx0
nimddmx1nimddmx1
mqmtamx2mqmtamx2

Названия группы разделов

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

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

При использовании этого стандарта название группы разделов состоит из 12 символов и содержит следующую структуру (таблица 6).

Таблица 6. Структура определения названия группы разделов
Компонент названия группы ресурсаИдентификатор последовательности группы разделов Буквенные символыНазвание группы разделов
db2apmx000vgdb2apmx000vg
db2apmx001vgdb2apmx001vg
db2apmx002vgdb2apmx002vg

Названия логических разделов

Распределение уникальных названий логических разделов в пределах предприятия гарантирует отсутствие конфликтов названий при восстановлении системы в случае запланированной или незапланированной остановки. Названия логических разделов должны основываться на ранее определенных названиях групп ресурсов. Каждый логический раздел связан с группой разделов, а каждая группа разделов, как правило, содержит несколько логических разделов.

Затем добавляется идентификатор из четырех буквенно-цифровых символов, предшествующий символам lv, который однозначно идентифицирует логический раздел (таблица 7).

Таблица 7. Определение структуры названия логического раздела
Компонент имени группы ресурсаИдентификатор логического раздела в последовательностиИдентификатор логического разделаНазвание логического раздела
db2apmx0db20lvdb2apmx0db20lv
db2apmx0db21lvdb2apmx0db21lv
db2apmx0db22lvdb2apmx0db22lv

Названия логического раздела журнала

Файловым системам JFS и JFS2 необходим дополнительный логический раздел для журнала. Также необходимо, чтобы имена логических разделов в пределах предприятия были уникальными. Структура имен логических разделов журналов должна быть такой же, как и описанная ранее для обычного логического тома. Однако идентификатор последовательности логического раздела должен состоять из буквенных символов jfs и последующей единственной цифры, однозначно идентифицирующей его имя. Логический раздел будет определяться одним журналом на группу раздела; тем не менее возможно определение нескольких журналов. Например, группа ресурсов с именем db2apmx0 может иметь группу разделов db2apmx00vg. Эта группа разделов имеет множество связанных с ней логических томов журнала JFS (таблица 8).

Таблица 8. Определение структуры имени логического раздела журнала
Компонент имени группы ресурсаИдентификатор последовательности логического тома журнала JFSИдентификатор логического тома журналаИмя логического раздела журнала JFS
db2apmx0jfs0lvdb2apmx0jfs0lv
db2apmx0jfs1lvdb2apmx0jfs1lv
db2apmx0jfs2lvdb2apmx0jfs2lv

Названия каталогов точек монтирования файловой системы

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

Например, группа ресурсов с названием db2apmx0 может иметь множество ассоциированных с ней файловых систем (таблица 9).

Таблица 9. Определение имени каталога точки монтирования файловой системы
Компонент имени группы ресурсаНеобязательный идентификатор последовательности логического томаНеобязательные подкаталогиТочка монтирования файловой системы
db2apmx0db2_08_01/bin/db2apmx0/db2_08_01/bin
db2apmx0db2_08_01/data/db2apmx0/db2_08_01/data
db2apmx1mq01/db2apmx1mq01
db2apmx1mq02/db2apmx1mq02
db2apmx1mq03/db2apmx1mq03

Выводы

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

  • названия скриптов, запускающих и останавливающих приложения;
  • Workload Manager классов и подклассов;
  • контроль производительности;
  • планирование заданий;
  • очереди печати;
  • Tivoli Storage Manager
  • MQSeries

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

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

Ресурсы

Научиться

Получить продукты и технологии

  • Ознакомительные версии ПО IBM: используйте в вашем следующем проекте программное обеспечение, которое можно загрузить непосредственно с сайта developerWorks.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=496555
ArticleTitle=Восстановление AIX-систем после аварий
publish-date=06162010