null

Полезные агенты Veritas Cluster Server

Хотя установка Veritas Cluster Server (VCS) благодаря интерактивному инсталлятору не вызвала у меня особых затруднений, когда дело дошло до создания ресурсов и сервисных групп, я впал в некоторый ступор и смятение. Хотя здесь и нет непонятных HAStoragePlus, имена агентов в VCS тоже не блещут очевидностью. Поэтому, в этом how-to я расскажу о некоторых базовых агентах Veritas Cluster и их атрибутах.

Агенты

Сеть

Агент NIC

Этот тип агента, как можно догадаться, отвечает за мониторинг сетевых карточек, в частности посылку UDP-echo запросов. Действия online и offline в этом агенте ничего не делают.

Привязка осуществляется по имени сетевого интерфейса - оно опредаляется свойством Device - (в Unix-системах) или по MAC-адресу карточки - свойство MACAddress (в Windows). Замечу, что так как имена сетевых интерфейсов, а тем более MAC-адреса сетевых карточек различаются эти свойства надо назначать по-отдельности на систему. По-умолчанию VCS использует утилиту NICTest, чтобы проверить статус карточки (например, наличие линка), что регулируется атрибутом UseConnectionStatus. А вот задать список опрашиваемых хостов можно атрибутом PingHostList.

Агент IP

Этот агент, как нетрудно догадаться из названия, вешает IP-адрес на сетевую карточку. Из атрибутов три основных - это Address, SubNetMask и все те же MACAddress/Device, что и у NIC. Мониторинг агента проверяет поднятость адреса на сетевом адресе.

Агент LanMan

Этот агент ассоциирует установленный предыдущим агентом IP-адрес c именем хоста в WINS, AD и DNS. Основные два атрибута - это IPResName - имя IP-ресурса, созданного предыдущим агентом, и VirtualName, собвственно имя хоста.

Остальные атрибуты связаны с тюнингом работы агента с DNS и AD, и менее существенны.

Диски

Агент VMDg

Данный агент импортирует и экспортирует группы Veritas Volume Manager в систему. Следует отметить, что функциональные возможности самого агента минимальны и он опирается на сам Veritas Volume Manager как для выполнения запуска или остановки группы так и для его мониторинга. Основной атрибут - DiskGroupName, имя группы VxVM

Агент MountV

Как следует из названия (первый агент, который в названии содержит осмысленное слово!) - этот агент монтирует том из группы VMDg. Основные атрибуты - это VMDGResName - имя ресурса VMDg (не самой группы), VolumeName - имя тома в Veritas Volume Manager, и MountPath - точка монтирования. Последняя может задаваться как буква диска, причем варианты X, X: или X:\ - одинаково корректны, так и директория на NTFS-томе в форме X:\Directory или X:\Directory.

Сервисы

Агент FileShare

Данный агент создает публикует папку по протоколу SMB. Конечно, покупать продукт стоимостью $$$ ради отказоустойчивой шары - нелепо, но у этого агента немало вспомогательных сценариев использования: например при кластеризации SAP такие шары используются, чтобы предоставить унифицированный доступ к конфигурационным файлам.

Для ресурса этого агента следует указывать две зависимости: ресурс типа LanMan и ресурс типа MountV, а их имена соответственно задаются в атрибутах LanmanResName и MountResName. Собственно параметры шары - это PathName - путь до публикуемой папки и ShareName - то, как будут видеть его пользователи.

Агент GenericService

Данный агент запускает сервис Windows на одном из узлов кластера. В вопросах запуска, остановки и мониторинга он полностью полагается на средства операционной системы. Обязательный атрибут всего один - ServiceName, имя сервиса, заданное как показываемое в services.msc (DISPLAY_NAME) так и собственное имя (SERVICE_NAME). Это различие хорошо видно в выводе утилиты sc query:

> sc query 
...
SERVICE_NAME: VCSComm
DISPLAY_NAME: Veritas VCSComm Startup
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
        ...

Опционально, можно добавить аргументы, передаваемые сервису, через атрибут service_arg, указать пользователя, от которого должен запускаться сервис через троицу атрибутов Domain, UserAccount и Password, ну и привязать его к LanMan-ресурсу.

В силу того, что остановка сервиса выполняется банальным "net stop", иногда повисший сервис может не позволить сервисной группе переехать. Однако, VCS может убить процесс, если указать ключик реестра KillInClean, как сказано здесь: TECH190552

Собираем сервисную группу

Если вы создали все необходимые ресурсы, остается только создать связи (link), задав тем самым зависимости. Замечу, что последние задаются несколько неочевидно, так как родительский ресурс запускается после дочернего. Указанные в статье атрибуты ресурсов и их связи (стрелки указаны в направлении дочернего ресурса) можно найти в небольшой шпаргалке:


если нажать на картинку, скачается pdf-файл

К списку статей

 

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

Основная сфера моей деятельности связана с поддержкой Solaris и оборудования Sun/Oracle, хотя в последнее время к ним прибавились технологии виртуализации (линейка Citrix Xen) и всякое разное от IBM - от xSeries до Power. Учусь на кафедре Вычислительной Техники НИУ ИТМО.

See you...out there!

http://www.facebook.com/profile.php?id=100001947776045
https://twitter.com/AnnoyingBugs