Введение

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

Принципы стандартизации компьютерных имён

Стандарты именований должны удовлетворять следующим требованиям:

• постоянство и эффективность в повторяемых операциях
• совместимость с автономными, отказоустойчивыми, непрерывно функционирующими разделёнными и виртуализированными средами
• возможность использования с средствами обеспечения высокой доступности для предотвращения конфликтов ресурсов.
• возможность использования с отказоустойчивыми средствами для предотвращения конфликтов ресурсов.
• возможность использования с системой приоритетов для балансировки сетевого трафика.
• возможность использования с конфигурацией сетевых адаптеров Ethernet для балансировки сетевого трафика.
• возможность использования c HBA-адаптером сервера для балансировки сетевого трафика.
• возможность использования для координации и балансировки сетевой нагрузки через сервера виртуального ввода-вывода (VIO).
• возможность использования для распознавания и определения имён раздела, профиля, узла и хоста.

Чтобы объяснить значимость стандартов компьютерных имён для бесперебойности бизнеса, необходимо определить сам термин "бесперебойность бизнеса" в том смысле, в каком он используется в этой статье. Также мы даем определение " восстановление после аварий" в том смысле, в котором оно используется в данной статье, чтобы отличать его от бесперебойности бизнеса. Оба следующие определения были взяты дословно со страницы определений Mt Xia: Technical Consulting Group.

Бесперебойность бизнеса (Business Continuity, BC)

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

Аварийное восстановление (АВ, Disaster Recovery DR)

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

Обычно отдельная система выделяет для каждого приложения или экземпляра приложения, такого как база данных, web-приложение или финансовый пакет. В прошлом компьютерная система находилась в пределах одного системного блока и состояла из корпуса, центрального процессора, памяти, плат, адаптеров, дисков и т.д. В настоящее время аппаратные платформы IBM позволяют системному администратору разделять физическую систему на множество логических разделов (LPAR). В эти логические разделы могут быть выделены аппаратные ресурсы, имеющиеся в системе, такие как процессор, память и адаптеры ввода/вывода. В логическом разделе можно развертывать любые приложения, которые обычно выполняются на физическом сервере, кластере высокой доступности или в резервном ЦОДе.

В начало

Стандарты в назначении имён для обеспечения бесперебойности бизнеса

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

Имена управляемых систем

Термин "управляемая система" относится к физическому фрагменту оборудования, содержащему такие компоненты как процессоры, память, адаптеры ввода/вывода, жесткие диски и другое. Такую систему иногда также называют "фрейм" или "система", и она может быть логически поделена на множество разделов. В мире IBM® System p® управляемая система или фрейм не имеют доступного пользователю сетевого адреса, хотя логические разделы (LPAR) практически всегда имеют один или больше сетевых адресов. Имя управляемой системы используется консолью (Hardware Management Console, HMC) для идентификации физического хранилища аппаратного обеспечения, и оно должно быть уникальным в пределах всего предприятия. По умолчанию, когда HMC обнаруживает вновь установленное оборудование, она автоматически генерирует и назначает имя управляемой системы. Созданное имя включает в себя номер модели устройства, тип модели и серийный номер. Данное имя гарантированно является уникальным, так как содержит серийный номер физического оборудования. Ниже в таблице 1, приведено несколько примеров автоматически созданных имён.

Такие автоматически созданные имена целесообразно применять в качестве стандарта поскольку они поддерживаются программным обеспечением автоматизации ЦОДов, но если вы все-таки решили изменить эти имена, то следуйте таким рекомендуется:

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

В начало

Логические разделы или имена LPAR.

В пределах управляемой системы имеется возможность распределять физические ресурсы по "логическим разделам" (Logical Partitions, LPAR). Физические ресурсы состоят из процессоров, памяти, адаптеров ввода/вывода и так далее. Каждая управляемая система может быть поделена на один или большее количество логических разделов, каждый из которых необходимо поименовать. Опыт работы с автоматизированным оборудованием компьютерных центров показывает, что имена логических разделов должны соответствовать имени узла, использованного для каждого экземпляра операционной системы и в пределах предприятия имя LPAR должно быть уникальным. Это более подробно рассмотрено в разделе "Имена узлов" .

Имена профилей разделов

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

В начало

Имена узлов

Имя узла назначается экземпляру операционной системы. Его не следует путать с именем хоста в сети TCP/IP. Имя хоста связано с сетевым адаптером. Экземпляр операционной системы может иметь множество различных имён хоста, но только одно имя узла. Также имя узла назначается данному экземпляру операционной системы, в отличие от имени хоста, которое может передаваться другим сетевым адаптерам в пределах экземпляра системы или другим узлам и компьютерным центрам. Все имена разделов, хостов и узлов должны быть уникальными в пределах предприятия во избежание конфликтов в случае отказов, независимо от того, являются ли отказы запланированными, незапланированными, осуществлёнными вручную или автоматически, или в рамках послеаварийного восстановления. Пример стандарта назначения имён ЦОДа для приложений, программного обеспечения и оборудования предоставлен в таблице 2. Стандартные имена различных категорий программного обеспечения лежит за пределами данной статье.

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

В качестве примера приведено имя узла под управлением AIX®, расположенного в Бостоне, являющимся продукционной системой, на которой запущена БД Oracle, и являющимся первым узлом в последовательности. Пример имени узла состоит из компонент, показанных в таблице 4.

В начало

Имена хостов

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

Для любого одиночного узла могут быть созданы одно или большее количество имён хостов для идентификации различных сетевых интерфейсов. Обычно каждый узел имеет имя хоста, такое же как имя узла. Например в таблице 4 "bosapora01" используется как имя узла, также возможно его одновременное использование как имени хоста с назначенным ему IP-адресом. Особенность состоит в том, что имя узла и имя хоста являются различными сущностями и это должно учитываться при разработке автономных, виртуализированных или кластерных систем.

Дополнительные имена хостов

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

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

В таблице 5 также присутствует имя хоста "bosapora00", которое соответствует имени узла системы. Следует помнить, что даже если имена одинаковы, их назначение различно. Это пример случая, когда имя узла не будет уникальным в пределах предприятия. Каждое имя узла будет соответствовать имени хоста с таким же значением.

В начало

Алиасы

Сетевое имя, к которому обращаются приложения и простые пользователи, не должно соответствовать ни одному из имён хоста, перечисленных в таблице 5. Для этих целей следует использовать алиасы к этим именам, как показано в таблице 6.

Следует отметить, что все имена хостов, перечисленных в таблице 6, заканчиваются на -rg##. Они являются ссылками на так называемые "имя адреса группы ресурсов" или "имя адреса сервиса". Хотя такие имена обычно применяются для кластеров, они должны использоваться ко всем узлам: автономным, виртуализированным или кластерным. Для обращения ко всем сетевым приложениям или сервисам используется имя адреса сервиса. Все приложения и обычные пользователи, использующие доступ к сервису, предоставляемому сетевым приложением, должны применять для этой цели только алиас, перенаправляющий их на имя хоста сервиса, с которым сопоставлен IP-адрес.

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

Правила для определения имён алиасов значительно менее строги чем правила для имён хостов, однако имена по-прежнему должны быть уникальными в пределах предприятия. Алиасом может быть любое имя, уникальное в пределах домена. Это позволяет получать доступ к приложению при помощи имени, имеющего для пользователя логическое значение. Например, производственный сервер приложений Oracle в бостонском ЦОДе может иметь имя хоста "bosapora01", однако алиас, по которому обращается пользователь, может быть "myappl5". Использование алиасов позволяет сочетать структурированность, необходимую для имён хостов, и лёгкость использования.

В начало

Распределение трафика в сети.

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

В качестве примера этой концепции в таблице 7 показаны основные пути связи для дисков, имеющих чётные номера на чётных логических разделах чётного сервера VIO (в действительности являющегося виртуальным SCSI-адаптером. С этого момента будем предполагать, что чётные виртуальные SCSI-адаптеры поставлены в соответствие чётным серверам VIO). Вспомогательный путь для имеющих чётные номера дисков на чётных логических разделах проходит через нечётный сервер VIO. Эта логика, разумеется, изменится на обратную для нечётных дисков.

Используя скрипты определения приоритетов путей и расширяя стандарты назначения имён узлов на десятки логических разделов управляемей системы p590, можно явственно видеть, что основной путь связи к логическим разделам с чётными именами узлов "hdisk0" всегда будет пролегать через чётный сервер VIO. Так как "hdisk0" обычно содержит группу тома "rootvg", нежелательно, чтобы тот же основной путь к "hdisk0" для всех логических разделов управляемей системы пролегал через один и тот же сервер VIO. В связи с этим рекомендуется при конфигурации логических разделов двух управляемых систем (таких как HACMP, High Availability Clustered Multi Processing), не использовать все чётные имена узлов для логических разделов одной и все нечётные имена узлов другой управляемей системы. В противном случае использование скриптов определения приоритета путей приведёт к тому, что все нечётные логические разделы будут использовать сервер VIO с чётным именем узла в качестве основного для "hdisk0". Вдобавок все логические разделы с нечётными номерами имени узла будут использовать сервер VIO с чётным именем узла в качестве основного для "hdisk0", что, как видно из таблицы 7, нежелательно.

Более предпочтительна конфигурация, обеспечивающая равное распределение сетевой нагрузки при обращении к "hdisk0" двух серверов VIO, которая может быть легко автоматизирована если и чётные и нечётные имена узлов имеются на каждой управляемей системе в равном количестве. Таблица 8 демонстрирует предпочтительную конфигурацию имён узлов для группы из восьми серверов Oracle, развёрнутых на двух управляемых системах p590 и распределение сетевой нагрузки между двумя серверами VIO. Основной и вспомогательный пути всех последовательно нумерованных дисков также распределены поровну, как только что рассматривалось.

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

В начало

Заключение

Пользователи и приложения должны обращаться к сетевым службам приложений исключительно при помощи алиасов и никогда не должны напрямую использовать имена хостов или сетевые адреса TCP/IP. Алиасы, используемые для доступа к сетевым приложениям и выполняющие роль служебных имён для приложений, должны указывать только на имена хостов. Каждый сетевой адаптер должен быть сконфигурирован таким образом, чтобы у него был загрузочный IP-адрес и сопоставленное с ним имя хоста. Дополнительные адреса TCP/IP могут быть добавлены к любому сетевому адаптеру по мере необходимости и им должны быть назначены соответствующие имена хостов. Каждому экземпляру операционной системы назначается имя узла. Это же имя также используется для именования раздела и профиля по умолчанию. При использовании имени узла в качестве имени раздела и профиля по умолчанию становится возможной простая идентификация скриптом логического раздела и профиля для работы с ними и их изменения. Получение списка имён узлов на управляемей системе становится таким же простым делом, как создание списка логических разделов при помощи консоли управления оборудованием. И поскольку каждый узел должен иметь имя хоста, соответствующее имени узла, то сетевой доступ также упрощается.

Ресурсы

Научиться

• Оригинал статьи: Naming standards for business continuity(EN)
  
  
• Определения терминов, использованных в данной статье, обращайтесь к странице определений Mt Xia: Technical Consulting Group.(EN)
  
  
• Path Prioritization Script присваивает приоритеты путям vscsi на основе чередования чётных и нечётных чисел, ассоциированных с каждым диском и с каждым путём до диска.
  
  
• Enterprise Wide Unique identifier generator генерирует идентификатор, уникальный в пределах всего предприятия (Enterprise Wide Unique UID), для каждого назначенного имени пользователя.(EN)
  
  
• Раздел по AIX и UNIX от developerWorks предоставляет различную информацию по всем аспектам администрирования систем AIX и навыков в UNIX.(EN)
  
  
• Технические мероприятия и Web-трансляции developerWorks: будьте в курсе новостей
  
  
• Podcasts: подкасты технических экспертов IBM.(EN)
  
  

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

• Используйте в вашем проекте разработки для Linux ознакомительные версии ПО IBM, которые можно скачать непосредственно с developerWorks.(EN)
  
  

Обсудить

• Форумы по тематике AIX и UNIX:
  • AIX 5L — технический форум
  • AIX для разработчиков
  • Управление кластерными системами
  • IBM Support Assistant
  • Инструменты повышения производительности — технический форум
  • Виртуализация — технический форум
  • More Другие форумы по AIX и UNIX
  • Сети в AIX
  
  

Об авторе

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

Комментарии

В начало

Содержание

• Введение
• Стандарты в назначении имён для обеспечения бесперебойности бизнеса
• Логические разделы или имена LPAR.
• Имена узлов
• Имена хостов
• Алиасы
• Распределение трафика в сети.
• Заключение
• Ресурсы
• Об авторе
• Комментарии