Введение

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что в таблице 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Ресурсы

Научиться

• Оригинал статьи AIX disaster recovery (EN).
  
  
• IBM Redbooks: прочитайте Disaster recovery strategies with Tivoli Storage Management в которой дается дополнительная информация о планировании сценариев аварийного восстановления. (EN)
  
  
• Просмотрите следующие темы на сайте Mt Xia:
  • Политики, принципы, стандарты, и процедуры.
  • Статьи по тематике аварийного восстановления и непрерывности бизнеса.
  • Планирование аварийного восстановления.
  (EN)
  
• AIX and UNIX: раздел "AIX и UNIX" сайта developerWorks содержит огромное количество информации по всем аспектам администрирования систем AIX и укреплению навыков работы с UNIX.
  
  
• Новое в AIX и UNIX: посетите страницу "Новое в AIX и UNIX", чтобы узнать больше об AIX и UNIX. (EN)
  
  
• Вики AIX 5L: среда коллективного общения для получения технической информации, относящейся к AIX. (EN)
  
  
• Ищите материалы по данной теме в библиотеках AIX и UNIX: (EN)
  • Системное администрирование
  • Разработка приложений
  • Производительность
  • Портирование
  • Безопасность
  • Подсказки
  • Инструментальные средства и утилиты
  • Java™-технология-
  • Linux®
  • Открытый код
  
  
• Онлайновый книжный магазин Safari: здесь можно найти техническую документацию по конкретным вопросам.
  
  
• Технические мероприятия и Web-трансляции developerWorks: будьте в курсе новостей. (EN)
  
  
• Podcasts: слушайте трансляции и знакомьтесь с мнениями технических экспертов IBM.
  
  

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

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

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Присоединяйтесь к сообществу developerWorks через блоги (EN)
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Сетевые конфликты
• Имена пользователей
• Идентификаторы пользователей и номера идентификаторов групп
• Названия группы ресурсов
• Названия группы разделов
• Названия логических разделов
• Названия логического раздела журнала
• Названия каталогов точек монтирования файловой системы
• Выводы
• Ресурсы
• Об авторе
• Комментарии