Реализация мультипроцессорных кластеров высокой доступности (HACMP)

Понятия и конфигурирование GLVM

Разбить на страницы
Показывать лекцию целиком

HACMP/XD GLVM

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

HACMP/XD GLVM обеспечивает две основные функции:

  • удаленное зеркальное отображение данных;
  • удаленное перемещение при сбое и возврат после восстановления.
    •

    Совместно эти функции обеспечивают поддержку высокой доступности приложений и данных через стандартную сеть TCP/IP к удаленному сайту.

    HACMP/XD GLVM обеспечивает следующие возможности аварийного восстановления:

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

    HACMP/XD:GLVM представляет HACMP Extended Distance с использованием географических логических томов для зеркального отображения данных на удаленном сайте, при этом:

  • поддерживает кластеры с несколькими узлами на двух сайтах;
  • осуществляет зеркальное отображение данных, обеспечивая локальное представление удаленного физического тома в LVM;
  • локальная и удаленная системы хранения не обязательно должны иметь оборудование одинакового типа;
  • цель состоит в том, чтобы упростить работу HACMP/XD:GeoRM и обеспечить зеркальное отображение на уровне LVM;
  • в сравнении с HAGEO GLVM содержит меньше кода, поэтому он более эффективен и надежен;
  • код был упрощен, поэтому GLVM более прост в поддержке и использовании;
  • план разработчиков в том, чтобы GLVM в конечном итоге заменил GMD.
    •

    Определения и понятия

  • Удаленный физический том (remote physical volume, RPV). Псевдоустройство, обеспечивающее доступ к удаленным дискам, как если бы они имели локальное подключение. Удаленная система должна быть подключена через сеть TCP/IP, и на ней должен быть запущен HACMP. Расстояние между сайтами ограничено задержкой связующей сети. RPV состоит из двух частей:
  • RPV-клиент. Представляет собой драйвер псевдоустройства, выполняющийся на локальном компьютере и позволяющий AIX LVM осуществлять доступ к удаленным физическим томам, как если бы они были локальными. RPV1-клиенты видимы в системе как устройства hdisk, которые являются логическим представлением удаленных физических томов. Драйвер RPV-клиента представляется как обычный драйвер дискового устройства, например устройства RPV-клиента, hdisk8, и весь его ввод-вывод направляется на удаленный RPV-сервер. Он не имеет представления об узлах, сетях и т. п. HACMP/XD 5.3 не поддерживает одновременный доступ для GLVM, так что при доступе к RPV-клиентам локальные аналоги RPV-серверов и удаленные RPV-клиенты должны быть определены. При конфигурировании RPV-клиента определяются следующие параметры:
  • Адрес RPV-сервера.
  • Локальный адрес (определяет используемую сеть).
  • Тайм-аут. Этот параметр используется главным образом при автономной установке GLVM, так как HACMP перезаписывает этот параметр значением config_too_long для кластера. В кластере HACMP это значение указывает на наихудший вариант развития событий, так как HACMP обнаруживает проблемы с удаленным узлом намного раньше.
    •  В SMIT есть меню конфигурирования RPV-клиентов, smitty rpvclient.
  • RPV-сервер. Выполняется на удаленном компьютере; каждому реплицируемому физическому тому соответствует один RPV-сервер. RPV-сервер может прослушивать множество удаленных RPV-клиентов на различных хостах, обеспечивая перемещение при сбое. RPV-сервер представляет собой экземпляр расширения ядра драйвера RPV с именем, подобным rpserver0, и не является действительным псевдоустройством. При конфигурировании RPV-сервера определяются следующие параметры:
  • PVID локального физического тома;
  • адреса RPV-клиентов (с разделяющими запятыми).
  • Группа томов с географическим зеркальным отображением (geographically mirrored volume group, GMVG). Группа томов, состоящая из локального и удаленного физических томов. В GMVG применяются строгие правила, что значительно снижает вероятность отсутствия полной копии зеркального отображения на каждом сайте. По этой причине требуется использование политики размещения "super strict" для каждого логического тома в GMVG. В HACMP/XD также ожидается зеркальное отображение каждого логического тома в GMVG. В HACMP/XD осуществляется управление GMVG, где они распознаются как отдельный класс реплицируемых ресурсов и имеют собственные события. Верификация в HACMP/XD также выдает предупреждение при обнаружении групп ресурсов, содержащих ресурсы GMLV, для которых не установлен флаг принудительной активизации (forced varyon) и не отключен кворум. В SMIT есть меню конфигурирования RPV-серверов, smitty rpvserver.Важно! HACMP/XD требует, чтобы для каждого физического тома, входящего в группу томов с RPV-клиентами, было определена обратная связь. Как минимум каждая GMVG содержит два физических тома на каждом сайте – один локальный диск и логическое представление удаленного физического тома.
  • Утилиты GLVM. GLVM содержит меню SMIT для создания GMVG и логических томов. Они управляют расположением логических томов, чтобы обеспечить правильное размещение зеркальных копий (аналогичные меню SMIT выполняют эту же функцию неявным образом). При использовании стандартных команд для конфигурирования GMVG рекомендуется использовать утилиту верификации GLVM.Важно! Команды LVM и меню SMIT не имеют точного представления о схеме RPV, поэтому можно создавать группы томов GMVG, не имеющие полной копии данных на одном из сайтов.
  • В HACMP/XD GLVM добавлены новые определения:
  • XD_data Сеть, которую можно использовать только для репликации данных. Представляет аналог сети Geo_Primary. Эта сеть поддерживает переключение адаптера, но не поддерживает перемещение при сбое на другой узел. Пакеты пульса RSCT пересылаются через эту сеть.Примечание. HACMP/XD 5.3 поддерживает только одну сеть XD_data. Также поддерживается Etherchannel.
  • XD_ip Сеть, которую можно использовать для мониторинга пульса RSCT через IP. Обычно имеет низкую пропускную способность и используется только для того, чтобы не допустить разделения кластера. Аналогична сетям Ethernet с тем исключением, что параметры пульса были настроены для работы на больших расстояниях. Не поддерживает перехват IP-адреса (IPAT) и не может использоваться для зеркального отображения данных.
  • XD_rs232 Сеть, которую можно использовать для последовательных коммуникаций. Аналогична сетям RS232 с тем исключением, что параметры пульса были настроены для работы на больших расстояниях. Подобна сетям Geo_Secondary в HACMP/XD:HAGeo. Может представлять выделенную линию или последовательную линию с драйвером линии. Пакеты пульса RSCT пересылаются по всем сетям.Примечание. HACMP/XD:GLVM требует использования одной сети XD_data для репликации данных и одной сети XD_rs232 или XD_ip, чтобы иметь возможность отличить отказ удаленного узла от отказа сети XD_datа. Рис. 18.1 представляет пример конфигурации из двух сайтов с одним узлом на каждом сайте. Рассматривая репликацию с точки зрения узла Node1, мы видим, что целевой физический том hdisk3 узла Node2 на узле Node1 представлен как hdisk8.(рис 18.1) RPV-клиент с точки зрения узла Node1На узле Node2 имеются RPV-серверы для каждого физического тома. На узле Node1 имеются соответствующие RPV-клиенты для каждого RPV-сервера, которые представляются в LVM как локальные физические тома. Теперь на узле Node1 можно построить группу томов glvm_vg, представляющую зеркальное отображение локального физического тома (hdisk4) для локального RPV-клиента (hdisk8). RPV-клиент и RPV-сервер обеспечивают передачу всего ввода-вывода через сеть XD_data на физические тома на узле Node2. Когда Node2 становится активным узлом, действие приобретает обратный характер, как видно на рис. 18.2. Удаленные физические тома на узле Node1 представляются через RPV-клиент как локальные физические тома на узле Node2.Примечание. Как и в случае физических томов, совместно используемых разными системами, нумерация hdisk может быть несогласованной, однако PVID в разных системах будет одинаковым. (рис 18.3) Обратная конфигурация при перемещении на удаленный сайт(рис 18.2) Конфигурация RPV-клиента и сервера на обоих сайтах Рис. 18.3 представляет конфигурацию обоих узлов с определением RPV-серверов и клиентов. Группа томов glvm_vg определена на обоих узлах и содержит два локальных физических тома и два локальных представления физических томов удаленного узла.
  • Конфигурирование GLVM под управлением HACMP. RPV-клиенты, RPV-серверы и GLVG должны быть сконфигурированы на всех узлах, прежде чем они могут быть определены в составе группы ресурсов HACMP. Каждому локальному диску должен соответствовать RPV-сервер, и каждому удаленному диску, входящему в GMVG, должен соответствовать RPV-клиент.

    • Табл. 18.1 содержит метки для конфигурации, представленной на рис 18.3.

    Имена RPV, используемые в нашей среде
    Локальные диски RPV-серверы RPV-клиенты
    New York/Node1 hdisk4 rpvserver0 hdisk7 на сайте Munchen
    hdisk5 rpvserver1 hdisk8 на сайте Munchen
    Munchen/Node2 hdisk3 rpvserver0 hdisk8 на сайте New York
    hdisk4 rpvserver1 hdisk9 на сайте New York

    Можно получить доступ к GMVG с любого сайта, если доступны соответствующие серверы и клиенты. Другими словами, для конфигурирования GMVG на узле Node1 должны быть доступны RPV-клиенты на узле Node1 и RPV-серверы на удаленном узле.

    Группы томов GMVG нельзя конфигурировать через CSPOC; их нужно создать на одном узле, затем деактивизировать и импортировать на другом узле. Повторите, пока они не станут определены на всех узлах в кластере.

    После конфигурирования групп томов GMVG их нужно добавить в группу ресурсов, после чего HACMP/XD распознает их и вызовет соответствующие события для их обработки.

    Общие рекомендации

    Рекомендуется отключить кворум для групп томов GMVG. Если оставить кворум включенным, это позволит выполнять дальнейшую проверку, однако при этом HACMP/XD будет пытаться выполнить перемещение группы ресурсов при потере половины дисков, т. е. при отказе удаленного сайта. Часто такое поведение является нежелательным.

    Рекомендуется установить флаг принудительной активизации (forced varyon) в атрибутах группы ресурсов. Это нужно для того, чтобы любой из сайтов мог подключить группу ресурсов, если недоступен удаленный сайт. При этом возможно использование устаревших данных, если в HACMP/XD не используется флаг "may be stale".

    Сценарий использования устаревших данных

    Если основной сайт работает, а сеть XD_data не работает, то данные на физических томах основного сайта более актуальны, чем данные на резервном сайте. Основной сайт знает, что резервный сайт работает и что данные не реплицируются, поэтому для групп томов GMVG на удаленном сайте устанавливается флаг "may be stale".

    Если выполнить перемещение приложения на резервный сайт без установленного флага "may be stale", группа томов GMVG активизируется (принудительно) и при запуске приложения используются устаревшие данные. Флаг "may be stale" останавливает активизацию группы томов на данном этапе, позволяя администратору принять решение, что делать дальше.

    Запуск кластера

    После конфигурирования и синхронизации кластера следует запустить службы кластера HACMP на основном узле. При недоступном удаленном сервере локальные RPV-клиенты также не будут доступны, поэтому HACMP придется выполнять принудительную активизацию группы томов и всего ввода-вывода для локальных физических томов, что вызывает устаревание разделов на томах RPV-клиентов при обновлении локальных физических разделов ( рис. 18.4).

    Когда узел на удаленном сайте становится активным, HACMP активирует на этом узле RPV-серверы и запускает RPV-клиенты на основном сайте. HACMP/XD запускает событие, информирующее LVM о доступности RPV-клиентов, так что устаревшие разделы на RPV-клиентах обновляются путем копирования данных с локальных физических томов на удаленные физические тома ( рис. 18.5).

    Если имеет место перемещение приложения на резервный сайт или отключение основного сайта, возникает обратный процесс. Те физические тома на удаленном узле, которые контролировали RPV-серверы, теперь представляют собой локальные физические тома для группы томов, тогда как RPV-клиенты (указывающие на физические тома на основном сайте) будут отключены до тех пор, пока не станет активным основной узел. Группу томов опять необходимо активизировать в принудительном режиме. См. Рисунок 18.6

    (рис 18.5) Активный узел основного сайта при неработающем резервном сайте(рис 18.4) Активный резервный сайт и репликация данных(рис 18.6) Активный резервный узел при неработающем основном сайте

    Когда основной сайт становится активным, HACMP/XD оставляет группу ресурсов на резервном сайте, где запускаются RPV-серверы, подключая RPV-клиентов на резервном сайте. LVM опять же обрабатывает репликацию данных на физических томах резервного сайта, для которых установлен флаг "stale", выполняя синхронизацию через RPV с физическими томами основного узла ( рис. 18.7).

    Однако если для группы ресурсов сконфигурирована политика Prefer Primary Site (Предпочтительное использование основного сайта), остановится работа резервного сайта и ресурсы перейдут на основной сайт. Это означает, что на основном сайте будет работать приложение, тогда как устаревшие данные будут синхронизированы обратно (с резервного сайта). Любая попытка чтения устаревшего раздела приложением приведет к чтению с RPV-сервера ( рис. 18.5).

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

    Например, при настройке для локальной группы томов GMVG зеркального отображения на двух физических томах и одном RPV-клиенте ( рис. 18.8) увеличивается вероятность локальной доступности данных.

    (рис 18.8) Интеграция основного узла в кластер и запуск репликации(рис 18.7) Приложение активно на основном сайте с двумя физическими томами и с одним RPV-клиентом(рис 18.10) Отключение основного сайта и приложение, использующее одну локальную копию группы томов(рис 18.9) Приложение не выполнило перемещения при интеграции основного сайта(рис 18.11) Перемещение приложения при интеграции основного сайта

    Однако в случае отключения основного сайта резервный сайт будет работать с группой томов, состоящей из одного локального физического тома и двух RPV-клиентов ( рис. 18.9).

    При таком сценарии политика предпочтительного использования сайта группой ресурсов оказывает большое влияние на производительность ресинхронизации данных. Если группа ресурсов не имеет политики предпочтительного использования сайта, она будет подключена на резервном сайте и две копии устаревших данных будут пересланы через сеть XD_data – по одной для каждого RPV-сервера ( рис. 18.10).

    Однако при включенной политике предпочтительного использования основного сайта группой ресурсов группа томов будет активизирована на основном сайте с одним актуальным физическим томом (RPV-клиентом) и с двумя локальными физическими томами с устаревшими разделами. Таким образом, через сеть будет пересылаться только одна копия каждого раздела для перевода физических томов в синхронизированное состояние. Операции чтения с устаревших разделов выполняются дольше, так как они включают задержку сети, связанную с тем, что чтение выполняется с удаленных физических томов ( рис.18.11).

    Путь ввода-вывода

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

    При использовании GLVM приложение передает запрос ввода-вывода в LVM, который передает запрос на драйвер RPV-клиента, который пересылает запрос через TCP/IP-сеть на удаленный RPV-сервер. Удаленный RPV-сервер передает запрос через драйвер дискового устройства на удаленный узел, через драйвер адаптера на удаленный физический том. Ответ возвращается таким же образом.

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

    Миграция – переход от HAGeo к GLVM

    Не существует автоматического механизма миграции с HACMP/XD:HAGeo на HACMP/XD: GLVM, однако HAGeo и GLVM могут совместно существовать в одном кластере. Поэтому можно выполнить пошаговую миграцию ресурсов GeoMirror с некоторым простоем.

    Так как HACMP/XD:HAGeo не поддерживает динамическую реконфигурацию, весь кластер необходимо будет остановить для внесения изменений в топологию и ресурсы. Однако миграцию данных с GMD в GLVM можно выполнить при работающем приложении. Такая миграция требует повторного зеркального отображения всех данных на удаленном сайте.

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

    В нашем примере миграции мы рассматриваем кластер с двумя узлами и двумя приложениями на основном сайте и с одним узлом на резервном сайте. Миграция состоит из следующих этапов:

  • установка наборов файлов GLVM;
  • остановка удаленного сайта и создание RPV-серверов на удаленном сайте;
  • создание локального RPV-клиента и зеркального отображения;
  • зеркальное отображение логических томов с локальными данными;
  • создание локальных RPV-серверов и удаленных RPV-клиентов;
  • изменение файла /etc/filesystems таким образом, чтобы он указывал на логические
  • тома, а не на GMD (при использовании файловых систем);
  • остановка кластера и изменение определений топологии и групп ресурсов;
  • верификация и синхронизация кластера;
  • запуск кластера.
    •  (рис 18.12) Пример кластера HACMP/XD для миграции с GLVM

    Рис. 18.12 изображает кластер с запущенным HACMP/XD:HAGeo. Узлы thor и odin находятся на сайте Boston; на каждом из узлов выполняется приложение. Каждое приложение использует один fleshiest с зеркальным отображением GeoMirror (зеркальное отображение выполняется и для базового логического тома, и для jfslog), который реплицируется на узел frigg сайта Munchen.

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

    Мы подробно рассмотрим миграцию группы ресурсов только на узле thor, так как на всех узлах алгоритм работы одинаковый. Рис. 18.13 подробно изображает один реплицируемый ресурс.

    (рис 18.13) Пример с одним ресурсом GMD

    Установка наборов файлов GLVM и конфигурирование GLVM

    Устанавливаем наборы файлов GLVM на каждом узле в кластере. Создаем снимок HACMP и HAGeo.

  • Остановка удаленного сайта и создание RPV-серверов на удаленном сайте. Цель миграции состоит в том, чтобы настроить использование GLVM при репликации данных без дополнительного оборудования. Недостаток этого процесса состоит в том, что необходимо отключать удаленную копию GMD, а затем перезаписывать в качестве устройства GLVM, оставляя заказчика без резервной копии данных. Если это представляет проблему, то потребуется использование дополнительного оборудования. В нашем примере происходит остановка реплицируемой копии группы ресурсов на резервном сайте (основное устройство GMD больше не выполняет синхронизацию данных), после чего происходит создание RPV-сервера, указывающего на физический том (рис 18.14(рис 18.14) Создание RPV-сервера
  • Создание локального RPV-клиента и зеркального отображения. Следующим этапом является создание локального RPV-клиента и добавление физического тома в группу томов GMD. Для всех логических томов данных и логических томов jfslog требуется установить политику размещения "super strict", после чего расширить путем добавления копии RPV-клиента. Мы рекомендуем не выполнять зеркальное отображение логических томов statemap, так как после отключения GMD они будут не нужны. После определения зеркальной копии логических томов можно осуществлять синхронизацию данных. При этом происходит репликация всех данных с основной копии даных на резервный сайт, что влияет на производительность обоих узлов и создает большую нагрузку на сеть (рис 18.15(рис 18.15) Зеркальное отображение логических томов данных на RPV-клиенте
  • Создание локальных RPV-серверов и удаленных RPV-клиентов. Хотя они и не понадобятся до перемещения приложений при сбое, RPV-серверы и клиенты должны быть созданы на всех узлах, иначе верификация HACMP будет неуспешной.
  • Изменение файла /etc/filesystems таким образом, чтобы он указывал на логические тома, а не на GMD. Файловые системы теперь указывают на логический том, а не на GMD, поэтому на каждом узле необходимо внести изменения в файл /etc/filesystems. Все statemap или зеркальные логические тома следует удалить из GMVG, так как HACMP/XD выдаст ошибку при наличии нереплицируемых логических томов на любом физическом томе в GMVG.
  • Остановка кластера и изменение определений топологии и групп ресурсов. Так как HACMP/XD:HAGeo не поддерживает динамическую реконфигурацию, необходимо остановить кластер на всех узлах:
  • для конфигурирования сети XD_Data;
  • для удаления определений GMD из группы ресурсов;
  • для настройки принудительной активизации для групп томов GLVM.
    •
  • Верификация и синхронизация кластера. Необходимо провести верификацию и синхронизацию изменений в GLVM на каждом узле в кластере.
  • Запуск кластера. Теперь можно запустить кластер с измененной группой ресурсов, использующей устройства GLVM (рис. 18.16), а также остальными группами ресурсов, использующими GMD. Неиспользуемые определения GMD теперь можно удалить. Еще один вариант, который можно рассмотреть, заключается в том, чтобы остановить только группу ресурсов, содержащую устройства GMD, подлежащие замене, выполнить принудительное отключение кластера на всех узлах, внести изменения в конфигурации топологии и группы ресурсов, после чего перезапустить кластер. В этом случае простой возникнет только для изменяемой группы ресурсов.(рис 18.16) Приложение использует устройства GLVM

    • Аспекты производительности

    Хотя это и не относится к теме данной книги, при планировании конфигурации GMVG необходимо учитывать следующее:

  • Согласование операций записи зеркальных отображений. Можно отключить согласование операций чтения-записи зеркальных отображений для повышения производительности, однако при перезагрузке после отказа необходимо выполнить команду syncvg -f, прежде чем можно будет получить доступ к логическому тому. Логический том может быть установлен:
  • Как активный. Используется по умолчанию для зеркального логического тома. Обеспечивает быстрое восстановление после отказа системы (не требует выполнения команды syncvg -f после перезагрузки). Это может вызвать проблемы с производительностью при выполнении операций записи.
  • Как пассивный. Отсутствуют проблемы с производительностью при выполнении операций записи и не требуется выполнение команды syncvg -f после перезагрузки. При этом выполняется фоновая ресинхронизация всех разделов, если обнаруживается, что система не была остановлена постепенно (gracefully).
    •
  • Политики планирования LVM. Для зеркальных логических томов определено четыре политики чтения-записи:
  • Параллельная. Выполняется балансировка операций чтения по физическим томам (они направляются на устройство с самой короткой очередью), операции записи направляются на физические устройства параллельно (т. е. одновременно).
  • Последовательная. Операции чтения выполняются с основной копии, и операции записи выполняются последовательно (т. е. одна копия за другой).
  • Параллельная запись, последовательное чтение. Операции чтения осуществляются с основной копии, а операции записи направляются на все физические тома параллельно.
  • Параллельная запись, циклическое чтение. Операции чтения выполняются с каждой копии по очереди, а операции записи направляются на все физические тома параллельно.
  • Проверка записи. Возможны два варианта:
  • Yes (Да). После всех операций записи на логический том выполняются операции чтения.
  • No (Нет). Проверка операций записи не выполняется.

    • Для групп томов GMVG нужно учитывать следующее:

  • Согласование операций записи зеркальных отображений. Мы рекомендуем оставить согласование операций записи зеркальных отображений в активном состоянии, так как отказ узла вызовет синхронизацию всего логического тома. Однако если пропускная способность сети и размеры логических томов позволяют, следует рассмотреть вариант использования пассивного режима.
  • Политики планирования LVM. Рекомендуется использовать заданную по умолчанию параллельную политику, так как разработчики LVM сделали небольшое изменение для групп томов GMVG. Изменение состоит в том, что, если доступны физические тома, LVM пытается выполнить чтение с локальной копии, а не с RPV.
  • Проверку записи. Настоятельно рекомендуется оставить выключенной, как и задано по умолчанию.
    •

    Устранение неполадок

  • В отличие от HAGEO журнал syslog содержит очень мало данных – одно трассируемое событие (trace hook 4A6).
  • Снимок HACMP содержит выходные данные команд lsrpvserver -H и lsrpvclient -H в файле .info.
  • snap -g содержит конфигурации RPV-сервера и клиента.
  • general.snap – наборы файлов; атрибуты RPV-сервера и RPV-клиентов.
  • CuAt – содержит информацию об имени удаленного сайта.
    •

    Пример 18.1 содержит свойства RPV-сервера.

    frigg:/# Isattr -El   rpvserverO
auto_online rt	Configure at System Boot     True
client_addr 192.168.101.74	Client IP Address	True
client_addr 192.168.101.73	Client IP Address	True
rpvs_pvid      0022be2aal3f292e0000000000000000 Physical  Volume Identifier True
frigg:/# Isattr -El   hdisk7
io_timeout    180	I/O Timeout  Interval	True
local_addr    10.1.101.192	Local   IP Address	True
pvid	0022be2aal3dc0720000000000000000 Physical  Volume Identifier True
server_addr none	Server IP Address	True

    Ниже также представлен пример фрагмента информации об ошибках RPV (пример 18.2).

    odin:/# lsrpvserver -H
#	RPV Server   Physical Volume Identifier     Physical Volume
#							
rpvserverO   O022be2aal3dcO72	hdiskZ
odin:/# lsrpvclient -H
#	RPV Client   Physical Volume Identifier    Remote Site
#			
hdisk6      0022be2aal3f292e	Munchen
LABEL:        RPVC_10_TIMEOJT IDENTIFIER:    D034B795
Date/Time:	Thu Jul 14 15:48:03 2005
Sequence Number:	16314
Machine Id:	OO2574O04C0O
Node Id:	frigg
Class:	U
Type:	PERM
Resource Name:	hdisk7
Resource Class:	disk
Resource Type:	rpvclient
Location:
VPD:
Description
No response from RPV server within I/O timeout interval.
Probable Causes
RPV server is down or not reachable.
Failure Causes
There is a problem with the data mirroring network. The node or site which hosts the RPV server is down. RPV server is not configured in the Available state.
Recommended Actions
Correct the problem which has caused the RPV server to be down or not reachable. Then, tell the RPV client to resume communication with the RPV server by running the coirenand:
chdev -1 <device> -a resume=yes where <device> is the name of this RPV client device.

    Этапы миграции с HAGEO на GLVM

    Установка пакета для GLVM. Выберите следующие пакеты с установочного носителя:

  • cluster.doc.en_US.glvm.html,
  • cluster.doc.en_US.glvm.pdf,
  • cluster.xd.glvm,
  • glvm.rpv.client,
  • glvm.rpv.server,
  • glvm.rpv.util.
    •
  • Начинаем с постепенной остановки служб кластера на узле frigg. Это остановит устройства GeoMirror на удаленном сайте Munchen:
    smitty clstop
    Подождите, пока службы кластера не будут остановлены на удаленном узле. Устройства GeoMirror будут находиться в состоянии "Defined". Экспортируйте определение группы томов GMD на узле frigg:
    exportvg vg01
    Эта операция удаляет определение группы томов из ODM и удаляет разделы файловых систем из /etc/filesystems. Сконфигурируйте среду RPV-сервера. Выполните следующие действия с RPV-сервера.
  • Назначение имени сайта удаленного зеркального отображения. На узле frigg выберите smitty rpvserver -> Remote Physical Volume Server Site Name Configuration (Настройка имени сайта сервера удаленных физических томов) -> Define / Change / Show Remote Physical Volume Server Site Name (Определение / Изменение / Вывод имени сайта сервера удаленных физических томов). Определите имя сайта, как в определении сайта в HACMP. Для определения сайта можно использовать команду rpvsitename:
    /usr/sbin/rpvsitename -a 'Munchen'
  • В меню Remote Physical Volume Servers (Серверы удаленных физических томов) выберите Add Remote Physical Volume Servers (Добавление серверов удаленных физических томов), чтобы определить RPV-серверы, связанные с целевыми дисками для зеркального отображения. После выбора целевых дисков укажите IP-адрес RPV-клиента, как в примере 18.3.
    Add Remote Physical Volume Servers
Type or select values in entry fields.
Press Enter AFTER making all   desired changes.
[Entry Fiel ds]
Physical  Volume Identifiers	0022be2aal3f292e
* Remote PV Client Internet Address	
  [192.l01.101.73, 192.101.101.74]
+
Configure Automatieally at System Restart?	[no] +
Start Hew Devices Immediately?	[yes] +
Fl=Help	F2=Riefresh	F3=Cance1	F4=List
F5= Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do

    При использовании командной строки используйте команду mkdev, как в примере 18.4:

    frigg;/# /(usr/sMn/mlrdev -с rpvserver -s rpvserver 
-t rpvstype \ >-a гpYS_pvid='0022Ьe2aalЗf292e' 
 -a client addr='192.168.101.73,\ 192.16a.101.741'   
 -a auto_online-V
rpvserverO Available
    Повторите действия пп. 1 и 2 для второго RPV. Используйте lsrpvserver для вывода списка определенных RPV-серверов, как показано в примере 18.5.
    friggt/K lsrpvserver _ц
#  RPV Server   Physical Volume Identifier    Physical Volume
  	
#rpv serverO	0022beЈddl3fЈ9Јe	hdiskl
frigg:/# lsattr -El  rpvserverO
auto_onl1ne n	Configure at System Boot     True
client_addr 192.168.101.73	Client JP Address	True
cHent_addr 192.168.101.74	Client IP Address	True
rpvs_pvid     0022be2eel3f292eO00OO000O000O000	Physical Volume Identifier True
    Сконфигурируйте RPV-клиенты. Выполните следующие действия на каждом клиенте.
  • Выберите smitty rpvclient -> Add Remote Physical Volume Clients (Добавление клиентов удаленных физических томов). Укажите IP-адрес RPV-сервера и локальный IP-адрес, используемые для репликации данных. Затем выберите удаленный диск из списка, как показано в примере 18.6.
    Add Remote Physical   Volume Clients
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Remote  Physical  Volume Server  Internet Address	10.1.101.192
Remote Physical Volume Local   Internet Address	192.168.101.74
PV Identifiers	0022be2aal3f292e0000000000000000
I/O Timeout Interval   (Seconds)	[180] i
Start New Devices Immediately?	[yes] +
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    При использовании командной строки см. пример 18.7:
    thor:/# /usr/sbin/mkdev -с disk -s remotedisk -t rpvclient \ >-a pvid='0022be2aal3f292e' -a server_addr='10.1.101.192' \
>-a local_addr='192.168.101.73' -a io_timeout='180' hdisk6 Available
thor:/# lsattr -El hdisk6
io_timeout 180	I/O Timeout Interval     True
local_addr 192,168.101,73	Local IP Address       True
pvid     0022be2aal3f292e0000000000000000	Physical Volume Identifier True
server_addr 10.1.1.192	Server IP Address       True
    К этому моменту на клиенте созданы дисковые устройства, которые можно использовать для интеграции в группу томов и определения зеркальных отображений логических томов. Используйте команду lsrpvclient для вывода списка определенных клиентских RPV. На уровне операционной системы они определяются как обычные жесткие диски. Команды LVM, употребляемые для локальных томов, применяются и к RPV. Пример 18.8 содержит выходные данные команды lsdev.
    thor:/# lspv
hdiskO	0022be2a80b97feb	rootvg      active
hdiskl	none	None
hdisk2	0022be2aal3dc072	vgOl        concurrent
hdisk3	0022be2aal3ea83e	vg02        concurrent
hdisk4	none	None
hdiskS	none	None
hdisk6	0022be2aal3f292e	None
    Примечание. PVID RPV-клиента соответствует PVID удаленного диска. Повторите действия пп. 1–3 для создания обратной пары RPV, связывающей RPVсервер для локального диска на узле thor с RPV-клиентом на узле frigg. Повторите те же действия на узле odin, используя odin_geo1 в качестве локального адреса связи. Определение зеркального отображения LVM
  • Выполните расширение группы томов, содержащей основные данные с определенными RPV. Используйте меню GLVM в SMIT для расширения группы томов. Выполните smitty glvm_vg -> Add Remote Physical Volumes to a Volume Group (Добавление удаленных физических томов в группу томов) или используйте команду extendvg:
    extendvg vg01 hdisk6
  • Создайте зеркальное отображение группы томов, содержащей RPV.Примечание. Перед миграцией логического тома необходимо установить политику размещения "super strict". Используйте команду chlv -s s < lv_name> -u <upper_ bound>, чтобы изменить политику размещения на "super strict". Дополнительные сведения см. в документации по команде chlv. В примере 18.9 представлено изменение логических томов ulv11_log и ulv11:
    thor:/# chlv -s	s -u 2  ulvll_1og
thor:/# lslv ulvlllog
LOGICAL VOLUME:	ulvlljog	VOLUME GROUP:	vgOl
LV IDENTIFIER:	O022be2aO0OO4cO0O0000104d52d0c6d.l PERMISSION:
read/write
VG STATE:	active/complete	LV STATE:	opened/syncd
TYPE:	jfs21og	WRITE VERIFY:	off
MAX LPs:	512	PP SIZE:	16 megabyte(s)
COPIES:	1	SCHED POLICY:	parallel
LPs:	1	PPs:	1
STALE PPs:	О	БВ POLICY:	relocatable
INTER-POLICY:	minimum	RELOCATABLE:   yes
INTRA-POLICY;	middle	UPPER BOUND:   2
MOUNT POINT:	N/A	LABEL:       None
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON	A SEPARATE PV ?: yes (superstrict)
Serialize 10 ?:	NO
thor:/# chlv -s	s -u 2 ulvll
thor:/# 1 siv ulvll
LOGICAL VOLUME:	ulvll	VOLUME GROUP:  vgOl
LV IDENTIFIER:	0022be2a00004c0000000104d52d0c6d.2 PERMISSION:
read/write
VG STATE:	active/complete	LV STATE:     opened/syncd
TYPE:	jfs2	WRITE VERIFY:  off
MAX LPs:	512	PP SIZE:      16 megabyte(s)
COPIES:	1	SCHED POLICY:  parallel
LPs:	10	PPs:         10
STALE PPs:	О	ВВ POLICY:            relocatable
INTER-POLICY:	minimum	RELOCATABLE:        yes
INTRA-POLICY:	middle	UPPER BOUND:        2
MOUNT POINT:	N/A	LABEL:                     /appOl
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON	A SEPARATE PV ?: yes  (superstrict)
Serialize 10 ?:	NO
thor:/#
    Выполните зеркальное отображение группы томов, выбрав smitty glvm_vg -> Add a Remote Site Mirror Copy to a Logical Volume (Добавление зеркальной копии удаленного сайта в логический том). Можно использовать команду mirrorvg для зеркального отображения группы томов или команду mklvcopy для зеркального отображения логических томов, например:
    /usr/sbin/mklvcopy -s's' ulv11_log 2 hdisk6
    Проверьте состояние группы томов и логических томов с использованием команды lsvg, как показано в примере 18.10:
    thor;/#   lsvg	-p vgOl
vgOl:
PV_HAME	PY STATE	TOTAL PPs      FREE PP5        FREE DISTRIBUTION
hd1sk2	active	639	476	128..00..92..128..US
hdiste	active	639	478	138..02..92..126..120
thor:/* livg	-1 vgOl
vgOl:
LV NAME	TYPE	LPs      PPs	PVs    LV STATE	HOJNT РОШ
ulvlljog	jfsZlag	1	2	2        Dpen/syncd        H/A
ulvll-	Jfs2	160     320	2       open/stale       N/A
ulvll_sm	statemap	1	1	1       ореп/tyned       NM
ulvll log sm	statemap	111        open/syncd        N/A
  • Выполните постепенную остановку служб кластера на локальном узле через меню smitty clstop. Проверьте корректность остановки обработки ресурсов кластера. Используйте команду lsgmd, чтобы убедиться в том, что GMD находятся в состоянии "Defined".
  • На каждом узле в кластере измените определение файловой системы в файле /etc/ filesystems, чтобы использовать обычные логические тома, а не GMD (пример 18.11).
    /appOl:
dev	=	/dev/ulvll
vfs	=	jfs2
log	=	/dev/ulvll_log
mount	=	false
check	=	false
account	=	false
    Важно! Если изначально файловые системы создавались с использованием команды crfs, происходит обновление контрольного блока логического тома (logical volume control block, LVCB) информацией файловой системы, так что каждая команда importvg обновляет файл /etc/filesystems. Проверку данных LVCB можно выполнить с применением команды getlvcb -AT <lv_name>. Если был создан fleshiest over GMD с использованием команды mkfs, команда importvg не обнов-ляет информацию fleshiest в файле /etc/filesystem.
  • Изменение определений топологии и ресурсов HACMP для использования GLVM.Примечание. HACMP/XD HAGEO не поддерживает динамическую конфигурацию. Для изменения конфигурации кластера необходимо остановить службы кластера. HACMP/XD GLVM поддерживает динамическую реконфигурацию, если только не установлен HAGEO. Для интеграции групп томов GLVM в HACMP требуется убедиться в том, что осуществляется репликация каждого логического тома. Если группы томов с географическим зеркальным отображением содержат нереплицируемые логические тома, HACMP выдает сообщение об ошибке.
  • Реконфигурация топологии кластера.
  • Измените тип сети с Geo_Primary на XD_data. На момент публикации этой книги использование двух сетей XD_data не поддерживалось. В кластере могут быть одновременно сконфигурированы GMD и RPV. Однако ресурсы GMD и RPV не могут входить в одну группу ресурсов. Если у вас имеется две сети Geo_Primary, можно оставить вторую сеть для непреобразованных GMD. Пример 18.12 показывает преобразование первой сети Geo_Primary в тип XD_data.
    Change/Show an IP-Based Network in the HACMP Cluster
Type or select values in entry fields.
Press Enter AFTER making all   desired changes.
[Entry Fields]
*	Network Name	net_Geo_Primary_01 New Network Name	[XD_data_net_01]
*	Network Type	[XD_data]+
*	Netmask	[255.255.255.0]+
*	Enable IP Address	Takeover via IP Aliases                   N0+ IP Address Offset	for Heartbeating over IP Aliases            П
*	Network attribute	public*
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Comnand	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    Примечание. При изменении атрибута сети Geo_Primary с private на public, необходимо удалить и заново создать сеть.
  • Синхронизация топологии кластера.
  • Изменение групп ресурсов для интеграции RPV. Не требуется конфигурировать специальные ресурсы для использования RPV в кластере. На данном этапе следует удалить определения GMD из групп ресурсов (пример 18.13).
    Change/Shaw All fiesouгее* and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group Name	"pp01_r9
tnter-site Management Policy	Prefer Primary Site
Participating Nodes from Primary Site	thDr Ddin
Participating Nodes from Secondary Site	frigg
Startup Policy	Online On Hume Node Only
Fa4over Policy	Fa 11 over To Next Priority
Node In The List
Fan bade Policy	Fallback то Higher
Priority Node In The Li>
Fallback Timer Policy (empty is immediate)	[]	+
Service IP Labels /Addresses	[]	+
Application Servers                                                      [ai:uOI_srv]	+
Volume Groups                                                                            [vgOl ]	+
Use forced varyon of volume groups,  if necessary       true	+
Automatically  Import Volume Groups                                    false	+
Filesystems (empty is ALL for VGs specified)              f/appOl  ]	+
Filesystems Consistency Check                                         fsck	+
Filesystems Recovery Method                                          sequential	+
Fllesystems mounted before IP configured                    false	+
Filesystems/Directories to Export                                	+
F11 esystems/01rectories to NFS Mount                          []
Network For NFS Mount                                                         []	+
Tape Resources                                                               []	+
Raw Disk PVIDs                                                                              []	+
Fast Connect Services                                                            []	+
Communic.ition Links                                                                []	+
Primary Workload Manager Class                                          []	+
Secondary workload Manager Class                                	+
Miscellaneous Data                                                           []
GeoMirror Devices	+
Fl=nelp	FZ=Refresh	F3=cancel	F4=Llst
F5=Reset	F6=coinmaria	F7=Edit	F3= image
F9-snell	F10=Exit	Enter=Do
  • Синхронизация определения кластера по узлам.
  • Запуск кластера на узлах.
    •
    Страницы:

    HACMP/XD GLVM

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

    HACMP/XD GLVM обеспечивает две основные функции:

  • удаленное зеркальное отображение данных;
  • удаленное перемещение при сбое и возврат после восстановления.
    •

    Совместно эти функции обеспечивают поддержку высокой доступности приложений и данных через стандартную сеть TCP/IP к удаленному сайту.

    HACMP/XD GLVM обеспечивает следующие возможности аварийного восстановления:

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

    HACMP/XD:GLVM представляет HACMP Extended Distance с использованием географических логических томов для зеркального отображения данных на удаленном сайте, при этом:

  • поддерживает кластеры с несколькими узлами на двух сайтах;
  • осуществляет зеркальное отображение данных, обеспечивая локальное представление удаленного физического тома в LVM;
  • локальная и удаленная системы хранения не обязательно должны иметь оборудование одинакового типа;
  • цель состоит в том, чтобы упростить работу HACMP/XD:GeoRM и обеспечить зеркальное отображение на уровне LVM;
  • в сравнении с HAGEO GLVM содержит меньше кода, поэтому он более эффективен и надежен;
  • код был упрощен, поэтому GLVM более прост в поддержке и использовании;
  • план разработчиков в том, чтобы GLVM в конечном итоге заменил GMD.
    •

    Определения и понятия

  • Удаленный физический том (remote physical volume, RPV). Псевдоустройство, обеспечивающее доступ к удаленным дискам, как если бы они имели локальное подключение. Удаленная система должна быть подключена через сеть TCP/IP, и на ней должен быть запущен HACMP. Расстояние между сайтами ограничено задержкой связующей сети. RPV состоит из двух частей:
  • RPV-клиент. Представляет собой драйвер псевдоустройства, выполняющийся на локальном компьютере и позволяющий AIX LVM осуществлять доступ к удаленным физическим томам, как если бы они были локальными. RPV1-клиенты видимы в системе как устройства hdisk, которые являются логическим представлением удаленных физических томов. Драйвер RPV-клиента представляется как обычный драйвер дискового устройства, например устройства RPV-клиента, hdisk8, и весь его ввод-вывод направляется на удаленный RPV-сервер. Он не имеет представления об узлах, сетях и т. п. HACMP/XD 5.3 не поддерживает одновременный доступ для GLVM, так что при доступе к RPV-клиентам локальные аналоги RPV-серверов и удаленные RPV-клиенты должны быть определены. При конфигурировании RPV-клиента определяются следующие параметры:
  • Адрес RPV-сервера.
  • Локальный адрес (определяет используемую сеть).
  • Тайм-аут. Этот параметр используется главным образом при автономной установке GLVM, так как HACMP перезаписывает этот параметр значением config_too_long для кластера. В кластере HACMP это значение указывает на наихудший вариант развития событий, так как HACMP обнаруживает проблемы с удаленным узлом намного раньше.
    •  В SMIT есть меню конфигурирования RPV-клиентов, smitty rpvclient.
  • RPV-сервер. Выполняется на удаленном компьютере; каждому реплицируемому физическому тому соответствует один RPV-сервер. RPV-сервер может прослушивать множество удаленных RPV-клиентов на различных хостах, обеспечивая перемещение при сбое. RPV-сервер представляет собой экземпляр расширения ядра драйвера RPV с именем, подобным rpserver0, и не является действительным псевдоустройством. При конфигурировании RPV-сервера определяются следующие параметры:
  • PVID локального физического тома;
  • адреса RPV-клиентов (с разделяющими запятыми).
  • Группа томов с географическим зеркальным отображением (geographically mirrored volume group, GMVG). Группа томов, состоящая из локального и удаленного физических томов. В GMVG применяются строгие правила, что значительно снижает вероятность отсутствия полной копии зеркального отображения на каждом сайте. По этой причине требуется использование политики размещения "super strict" для каждого логического тома в GMVG. В HACMP/XD также ожидается зеркальное отображение каждого логического тома в GMVG. В HACMP/XD осуществляется управление GMVG, где они распознаются как отдельный класс реплицируемых ресурсов и имеют собственные события. Верификация в HACMP/XD также выдает предупреждение при обнаружении групп ресурсов, содержащих ресурсы GMLV, для которых не установлен флаг принудительной активизации (forced varyon) и не отключен кворум. В SMIT есть меню конфигурирования RPV-серверов, smitty rpvserver.Важно! HACMP/XD требует, чтобы для каждого физического тома, входящего в группу томов с RPV-клиентами, было определена обратная связь. Как минимум каждая GMVG содержит два физических тома на каждом сайте – один локальный диск и логическое представление удаленного физического тома.
  • Утилиты GLVM. GLVM содержит меню SMIT для создания GMVG и логических томов. Они управляют расположением логических томов, чтобы обеспечить правильное размещение зеркальных копий (аналогичные меню SMIT выполняют эту же функцию неявным образом). При использовании стандартных команд для конфигурирования GMVG рекомендуется использовать утилиту верификации GLVM.Важно! Команды LVM и меню SMIT не имеют точного представления о схеме RPV, поэтому можно создавать группы томов GMVG, не имеющие полной копии данных на одном из сайтов.
  • В HACMP/XD GLVM добавлены новые определения:
  • XD_data Сеть, которую можно использовать только для репликации данных. Представляет аналог сети Geo_Primary. Эта сеть поддерживает переключение адаптера, но не поддерживает перемещение при сбое на другой узел. Пакеты пульса RSCT пересылаются через эту сеть.Примечание. HACMP/XD 5.3 поддерживает только одну сеть XD_data. Также поддерживается Etherchannel.
  • XD_ip Сеть, которую можно использовать для мониторинга пульса RSCT через IP. Обычно имеет низкую пропускную способность и используется только для того, чтобы не допустить разделения кластера. Аналогична сетям Ethernet с тем исключением, что параметры пульса были настроены для работы на больших расстояниях. Не поддерживает перехват IP-адреса (IPAT) и не может использоваться для зеркального отображения данных.
  • XD_rs232 Сеть, которую можно использовать для последовательных коммуникаций. Аналогична сетям RS232 с тем исключением, что параметры пульса были настроены для работы на больших расстояниях. Подобна сетям Geo_Secondary в HACMP/XD:HAGeo. Может представлять выделенную линию или последовательную линию с драйвером линии. Пакеты пульса RSCT пересылаются по всем сетям.Примечание. HACMP/XD:GLVM требует использования одной сети XD_data для репликации данных и одной сети XD_rs232 или XD_ip, чтобы иметь возможность отличить отказ удаленного узла от отказа сети XD_datа. Рис. 18.1 представляет пример конфигурации из двух сайтов с одним узлом на каждом сайте. Рассматривая репликацию с точки зрения узла Node1, мы видим, что целевой физический том hdisk3 узла Node2 на узле Node1 представлен как hdisk8.(рис 18.1) RPV-клиент с точки зрения узла Node1На узле Node2 имеются RPV-серверы для каждого физического тома. На узле Node1 имеются соответствующие RPV-клиенты для каждого RPV-сервера, которые представляются в LVM как локальные физические тома. Теперь на узле Node1 можно построить группу томов glvm_vg, представляющую зеркальное отображение локального физического тома (hdisk4) для локального RPV-клиента (hdisk8). RPV-клиент и RPV-сервер обеспечивают передачу всего ввода-вывода через сеть XD_data на физические тома на узле Node2. Когда Node2 становится активным узлом, действие приобретает обратный характер, как видно на рис. 18.2. Удаленные физические тома на узле Node1 представляются через RPV-клиент как локальные физические тома на узле Node2.Примечание. Как и в случае физических томов, совместно используемых разными системами, нумерация hdisk может быть несогласованной, однако PVID в разных системах будет одинаковым. (рис 18.3) Обратная конфигурация при перемещении на удаленный сайт(рис 18.2) Конфигурация RPV-клиента и сервера на обоих сайтах Рис. 18.3 представляет конфигурацию обоих узлов с определением RPV-серверов и клиентов. Группа томов glvm_vg определена на обоих узлах и содержит два локальных физических тома и два локальных представления физических томов удаленного узла.
  • Конфигурирование GLVM под управлением HACMP. RPV-клиенты, RPV-серверы и GLVG должны быть сконфигурированы на всех узлах, прежде чем они могут быть определены в составе группы ресурсов HACMP. Каждому локальному диску должен соответствовать RPV-сервер, и каждому удаленному диску, входящему в GMVG, должен соответствовать RPV-клиент.

    • Табл. 18.1 содержит метки для конфигурации, представленной на рис 18.3.

    Имена RPV, используемые в нашей среде
    Локальные диски RPV-серверы RPV-клиенты
    New York/Node1 hdisk4 rpvserver0 hdisk7 на сайте Munchen
    hdisk5 rpvserver1 hdisk8 на сайте Munchen
    Munchen/Node2 hdisk3 rpvserver0 hdisk8 на сайте New York
    hdisk4 rpvserver1 hdisk9 на сайте New York

    Можно получить доступ к GMVG с любого сайта, если доступны соответствующие серверы и клиенты. Другими словами, для конфигурирования GMVG на узле Node1 должны быть доступны RPV-клиенты на узле Node1 и RPV-серверы на удаленном узле.

    Группы томов GMVG нельзя конфигурировать через CSPOC; их нужно создать на одном узле, затем деактивизировать и импортировать на другом узле. Повторите, пока они не станут определены на всех узлах в кластере.

    После конфигурирования групп томов GMVG их нужно добавить в группу ресурсов, после чего HACMP/XD распознает их и вызовет соответствующие события для их обработки.

    Общие рекомендации

    Рекомендуется отключить кворум для групп томов GMVG. Если оставить кворум включенным, это позволит выполнять дальнейшую проверку, однако при этом HACMP/XD будет пытаться выполнить перемещение группы ресурсов при потере половины дисков, т. е. при отказе удаленного сайта. Часто такое поведение является нежелательным.

    Рекомендуется установить флаг принудительной активизации (forced varyon) в атрибутах группы ресурсов. Это нужно для того, чтобы любой из сайтов мог подключить группу ресурсов, если недоступен удаленный сайт. При этом возможно использование устаревших данных, если в HACMP/XD не используется флаг "may be stale".

    Сценарий использования устаревших данных

    Если основной сайт работает, а сеть XD_data не работает, то данные на физических томах основного сайта более актуальны, чем данные на резервном сайте. Основной сайт знает, что резервный сайт работает и что данные не реплицируются, поэтому для групп томов GMVG на удаленном сайте устанавливается флаг "may be stale".

    Если выполнить перемещение приложения на резервный сайт без установленного флага "may be stale", группа томов GMVG активизируется (принудительно) и при запуске приложения используются устаревшие данные. Флаг "may be stale" останавливает активизацию группы томов на данном этапе, позволяя администратору принять решение, что делать дальше.

    Запуск кластера

    После конфигурирования и синхронизации кластера следует запустить службы кластера HACMP на основном узле. При недоступном удаленном сервере локальные RPV-клиенты также не будут доступны, поэтому HACMP придется выполнять принудительную активизацию группы томов и всего ввода-вывода для локальных физических томов, что вызывает устаревание разделов на томах RPV-клиентов при обновлении локальных физических разделов ( рис. 18.4).

    Когда узел на удаленном сайте становится активным, HACMP активирует на этом узле RPV-серверы и запускает RPV-клиенты на основном сайте. HACMP/XD запускает событие, информирующее LVM о доступности RPV-клиентов, так что устаревшие разделы на RPV-клиентах обновляются путем копирования данных с локальных физических томов на удаленные физические тома ( рис. 18.5).

    Если имеет место перемещение приложения на резервный сайт или отключение основного сайта, возникает обратный процесс. Те физические тома на удаленном узле, которые контролировали RPV-серверы, теперь представляют собой локальные физические тома для группы томов, тогда как RPV-клиенты (указывающие на физические тома на основном сайте) будут отключены до тех пор, пока не станет активным основной узел. Группу томов опять необходимо активизировать в принудительном режиме. См. Рисунок 18.6

    (рис 18.5) Активный узел основного сайта при неработающем резервном сайте(рис 18.4) Активный резервный сайт и репликация данных(рис 18.6) Активный резервный узел при неработающем основном сайте

    Когда основной сайт становится активным, HACMP/XD оставляет группу ресурсов на резервном сайте, где запускаются RPV-серверы, подключая RPV-клиентов на резервном сайте. LVM опять же обрабатывает репликацию данных на физических томах резервного сайта, для которых установлен флаг "stale", выполняя синхронизацию через RPV с физическими томами основного узла ( рис. 18.7).

    Однако если для группы ресурсов сконфигурирована политика Prefer Primary Site (Предпочтительное использование основного сайта), остановится работа резервного сайта и ресурсы перейдут на основной сайт. Это означает, что на основном сайте будет работать приложение, тогда как устаревшие данные будут синхронизированы обратно (с резервного сайта). Любая попытка чтения устаревшего раздела приложением приведет к чтению с RPV-сервера ( рис. 18.5).

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

    Например, при настройке для локальной группы томов GMVG зеркального отображения на двух физических томах и одном RPV-клиенте ( рис. 18.8) увеличивается вероятность локальной доступности данных.

    (рис 18.8) Интеграция основного узла в кластер и запуск репликации(рис 18.7) Приложение активно на основном сайте с двумя физическими томами и с одним RPV-клиентом(рис 18.10) Отключение основного сайта и приложение, использующее одну локальную копию группы томов(рис 18.9) Приложение не выполнило перемещения при интеграции основного сайта(рис 18.11) Перемещение приложения при интеграции основного сайта

    Однако в случае отключения основного сайта резервный сайт будет работать с группой томов, состоящей из одного локального физического тома и двух RPV-клиентов ( рис. 18.9).

    При таком сценарии политика предпочтительного использования сайта группой ресурсов оказывает большое влияние на производительность ресинхронизации данных. Если группа ресурсов не имеет политики предпочтительного использования сайта, она будет подключена на резервном сайте и две копии устаревших данных будут пересланы через сеть XD_data – по одной для каждого RPV-сервера ( рис. 18.10).

    Однако при включенной политике предпочтительного использования основного сайта группой ресурсов группа томов будет активизирована на основном сайте с одним актуальным физическим томом (RPV-клиентом) и с двумя локальными физическими томами с устаревшими разделами. Таким образом, через сеть будет пересылаться только одна копия каждого раздела для перевода физических томов в синхронизированное состояние. Операции чтения с устаревших разделов выполняются дольше, так как они включают задержку сети, связанную с тем, что чтение выполняется с удаленных физических томов ( рис.18.11).

    Путь ввода-вывода

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

    При использовании GLVM приложение передает запрос ввода-вывода в LVM, который передает запрос на драйвер RPV-клиента, который пересылает запрос через TCP/IP-сеть на удаленный RPV-сервер. Удаленный RPV-сервер передает запрос через драйвер дискового устройства на удаленный узел, через драйвер адаптера на удаленный физический том. Ответ возвращается таким же образом.

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

    Миграция – переход от HAGeo к GLVM

    Не существует автоматического механизма миграции с HACMP/XD:HAGeo на HACMP/XD: GLVM, однако HAGeo и GLVM могут совместно существовать в одном кластере. Поэтому можно выполнить пошаговую миграцию ресурсов GeoMirror с некоторым простоем.

    Так как HACMP/XD:HAGeo не поддерживает динамическую реконфигурацию, весь кластер необходимо будет остановить для внесения изменений в топологию и ресурсы. Однако миграцию данных с GMD в GLVM можно выполнить при работающем приложении. Такая миграция требует повторного зеркального отображения всех данных на удаленном сайте.

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

    В нашем примере миграции мы рассматриваем кластер с двумя узлами и двумя приложениями на основном сайте и с одним узлом на резервном сайте. Миграция состоит из следующих этапов:

  • установка наборов файлов GLVM;
  • остановка удаленного сайта и создание RPV-серверов на удаленном сайте;
  • создание локального RPV-клиента и зеркального отображения;
  • зеркальное отображение логических томов с локальными данными;
  • создание локальных RPV-серверов и удаленных RPV-клиентов;
  • изменение файла /etc/filesystems таким образом, чтобы он указывал на логические
  • тома, а не на GMD (при использовании файловых систем);
  • остановка кластера и изменение определений топологии и групп ресурсов;
  • верификация и синхронизация кластера;
  • запуск кластера.
    •  (рис 18.12) Пример кластера HACMP/XD для миграции с GLVM

    Рис. 18.12 изображает кластер с запущенным HACMP/XD:HAGeo. Узлы thor и odin находятся на сайте Boston; на каждом из узлов выполняется приложение. Каждое приложение использует один fleshiest с зеркальным отображением GeoMirror (зеркальное отображение выполняется и для базового логического тома, и для jfslog), который реплицируется на узел frigg сайта Munchen.

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

    Мы подробно рассмотрим миграцию группы ресурсов только на узле thor, так как на всех узлах алгоритм работы одинаковый. Рис. 18.13 подробно изображает один реплицируемый ресурс.

    (рис 18.13) Пример с одним ресурсом GMD

    Установка наборов файлов GLVM и конфигурирование GLVM

    Устанавливаем наборы файлов GLVM на каждом узле в кластере. Создаем снимок HACMP и HAGeo.

  • Остановка удаленного сайта и создание RPV-серверов на удаленном сайте. Цель миграции состоит в том, чтобы настроить использование GLVM при репликации данных без дополнительного оборудования. Недостаток этого процесса состоит в том, что необходимо отключать удаленную копию GMD, а затем перезаписывать в качестве устройства GLVM, оставляя заказчика без резервной копии данных. Если это представляет проблему, то потребуется использование дополнительного оборудования. В нашем примере происходит остановка реплицируемой копии группы ресурсов на резервном сайте (основное устройство GMD больше не выполняет синхронизацию данных), после чего происходит создание RPV-сервера, указывающего на физический том (рис 18.14(рис 18.14) Создание RPV-сервера
  • Создание локального RPV-клиента и зеркального отображения. Следующим этапом является создание локального RPV-клиента и добавление физического тома в группу томов GMD. Для всех логических томов данных и логических томов jfslog требуется установить политику размещения "super strict", после чего расширить путем добавления копии RPV-клиента. Мы рекомендуем не выполнять зеркальное отображение логических томов statemap, так как после отключения GMD они будут не нужны. После определения зеркальной копии логических томов можно осуществлять синхронизацию данных. При этом происходит репликация всех данных с основной копии даных на резервный сайт, что влияет на производительность обоих узлов и создает большую нагрузку на сеть (рис 18.15(рис 18.15) Зеркальное отображение логических томов данных на RPV-клиенте
  • Создание локальных RPV-серверов и удаленных RPV-клиентов. Хотя они и не понадобятся до перемещения приложений при сбое, RPV-серверы и клиенты должны быть созданы на всех узлах, иначе верификация HACMP будет неуспешной.
  • Изменение файла /etc/filesystems таким образом, чтобы он указывал на логические тома, а не на GMD. Файловые системы теперь указывают на логический том, а не на GMD, поэтому на каждом узле необходимо внести изменения в файл /etc/filesystems. Все statemap или зеркальные логические тома следует удалить из GMVG, так как HACMP/XD выдаст ошибку при наличии нереплицируемых логических томов на любом физическом томе в GMVG.
  • Остановка кластера и изменение определений топологии и групп ресурсов. Так как HACMP/XD:HAGeo не поддерживает динамическую реконфигурацию, необходимо остановить кластер на всех узлах:
  • для конфигурирования сети XD_Data;
  • для удаления определений GMD из группы ресурсов;
  • для настройки принудительной активизации для групп томов GLVM.
    •
  • Верификация и синхронизация кластера. Необходимо провести верификацию и синхронизацию изменений в GLVM на каждом узле в кластере.
  • Запуск кластера. Теперь можно запустить кластер с измененной группой ресурсов, использующей устройства GLVM (рис. 18.16), а также остальными группами ресурсов, использующими GMD. Неиспользуемые определения GMD теперь можно удалить. Еще один вариант, который можно рассмотреть, заключается в том, чтобы остановить только группу ресурсов, содержащую устройства GMD, подлежащие замене, выполнить принудительное отключение кластера на всех узлах, внести изменения в конфигурации топологии и группы ресурсов, после чего перезапустить кластер. В этом случае простой возникнет только для изменяемой группы ресурсов.(рис 18.16) Приложение использует устройства GLVM

    • Аспекты производительности

    Хотя это и не относится к теме данной книги, при планировании конфигурации GMVG необходимо учитывать следующее:

  • Согласование операций записи зеркальных отображений. Можно отключить согласование операций чтения-записи зеркальных отображений для повышения производительности, однако при перезагрузке после отказа необходимо выполнить команду syncvg -f, прежде чем можно будет получить доступ к логическому тому. Логический том может быть установлен:
  • Как активный. Используется по умолчанию для зеркального логического тома. Обеспечивает быстрое восстановление после отказа системы (не требует выполнения команды syncvg -f после перезагрузки). Это может вызвать проблемы с производительностью при выполнении операций записи.
  • Как пассивный. Отсутствуют проблемы с производительностью при выполнении операций записи и не требуется выполнение команды syncvg -f после перезагрузки. При этом выполняется фоновая ресинхронизация всех разделов, если обнаруживается, что система не была остановлена постепенно (gracefully).
    •
  • Политики планирования LVM. Для зеркальных логических томов определено четыре политики чтения-записи:
  • Параллельная. Выполняется балансировка операций чтения по физическим томам (они направляются на устройство с самой короткой очередью), операции записи направляются на физические устройства параллельно (т. е. одновременно).
  • Последовательная. Операции чтения выполняются с основной копии, и операции записи выполняются последовательно (т. е. одна копия за другой).
  • Параллельная запись, последовательное чтение. Операции чтения осуществляются с основной копии, а операции записи направляются на все физические тома параллельно.
  • Параллельная запись, циклическое чтение. Операции чтения выполняются с каждой копии по очереди, а операции записи направляются на все физические тома параллельно.
  • Проверка записи. Возможны два варианта:
  • Yes (Да). После всех операций записи на логический том выполняются операции чтения.
  • No (Нет). Проверка операций записи не выполняется.

    • Для групп томов GMVG нужно учитывать следующее:

  • Согласование операций записи зеркальных отображений. Мы рекомендуем оставить согласование операций записи зеркальных отображений в активном состоянии, так как отказ узла вызовет синхронизацию всего логического тома. Однако если пропускная способность сети и размеры логических томов позволяют, следует рассмотреть вариант использования пассивного режима.
  • Политики планирования LVM. Рекомендуется использовать заданную по умолчанию параллельную политику, так как разработчики LVM сделали небольшое изменение для групп томов GMVG. Изменение состоит в том, что, если доступны физические тома, LVM пытается выполнить чтение с локальной копии, а не с RPV.
  • Проверку записи. Настоятельно рекомендуется оставить выключенной, как и задано по умолчанию.
    •

    Устранение неполадок

  • В отличие от HAGEO журнал syslog содержит очень мало данных – одно трассируемое событие (trace hook 4A6).
  • Снимок HACMP содержит выходные данные команд lsrpvserver -H и lsrpvclient -H в файле .info.
  • snap -g содержит конфигурации RPV-сервера и клиента.
  • general.snap – наборы файлов; атрибуты RPV-сервера и RPV-клиентов.
  • CuAt – содержит информацию об имени удаленного сайта.
    •

    Пример 18.1 содержит свойства RPV-сервера.

    frigg:/# Isattr -El   rpvserverO
auto_online rt	Configure at System Boot     True
client_addr 192.168.101.74	Client IP Address	True
client_addr 192.168.101.73	Client IP Address	True
rpvs_pvid      0022be2aal3f292e0000000000000000 Physical  Volume Identifier True
frigg:/# Isattr -El   hdisk7
io_timeout    180	I/O Timeout  Interval	True
local_addr    10.1.101.192	Local   IP Address	True
pvid	0022be2aal3dc0720000000000000000 Physical  Volume Identifier True
server_addr none	Server IP Address	True

    Ниже также представлен пример фрагмента информации об ошибках RPV (пример 18.2).

    odin:/# lsrpvserver -H
#	RPV Server   Physical Volume Identifier     Physical Volume
#							
rpvserverO   O022be2aal3dcO72	hdiskZ
odin:/# lsrpvclient -H
#	RPV Client   Physical Volume Identifier    Remote Site
#			
hdisk6      0022be2aal3f292e	Munchen
LABEL:        RPVC_10_TIMEOJT IDENTIFIER:    D034B795
Date/Time:	Thu Jul 14 15:48:03 2005
Sequence Number:	16314
Machine Id:	OO2574O04C0O
Node Id:	frigg
Class:	U
Type:	PERM
Resource Name:	hdisk7
Resource Class:	disk
Resource Type:	rpvclient
Location:
VPD:
Description
No response from RPV server within I/O timeout interval.
Probable Causes
RPV server is down or not reachable.
Failure Causes
There is a problem with the data mirroring network. The node or site which hosts the RPV server is down. RPV server is not configured in the Available state.
Recommended Actions
Correct the problem which has caused the RPV server to be down or not reachable. Then, tell the RPV client to resume communication with the RPV server by running the coirenand:
chdev -1 <device> -a resume=yes where <device> is the name of this RPV client device.

    Этапы миграции с HAGEO на GLVM

    Установка пакета для GLVM. Выберите следующие пакеты с установочного носителя:

  • cluster.doc.en_US.glvm.html,
  • cluster.doc.en_US.glvm.pdf,
  • cluster.xd.glvm,
  • glvm.rpv.client,
  • glvm.rpv.server,
  • glvm.rpv.util.
    •
  • Начинаем с постепенной остановки служб кластера на узле frigg. Это остановит устройства GeoMirror на удаленном сайте Munchen:
    smitty clstop
    Подождите, пока службы кластера не будут остановлены на удаленном узле. Устройства GeoMirror будут находиться в состоянии "Defined". Экспортируйте определение группы томов GMD на узле frigg:
    exportvg vg01
    Эта операция удаляет определение группы томов из ODM и удаляет разделы файловых систем из /etc/filesystems. Сконфигурируйте среду RPV-сервера. Выполните следующие действия с RPV-сервера.
  • Назначение имени сайта удаленного зеркального отображения. На узле frigg выберите smitty rpvserver -> Remote Physical Volume Server Site Name Configuration (Настройка имени сайта сервера удаленных физических томов) -> Define / Change / Show Remote Physical Volume Server Site Name (Определение / Изменение / Вывод имени сайта сервера удаленных физических томов). Определите имя сайта, как в определении сайта в HACMP. Для определения сайта можно использовать команду rpvsitename:
    /usr/sbin/rpvsitename -a 'Munchen'
  • В меню Remote Physical Volume Servers (Серверы удаленных физических томов) выберите Add Remote Physical Volume Servers (Добавление серверов удаленных физических томов), чтобы определить RPV-серверы, связанные с целевыми дисками для зеркального отображения. После выбора целевых дисков укажите IP-адрес RPV-клиента, как в примере 18.3.
    Add Remote Physical Volume Servers
Type or select values in entry fields.
Press Enter AFTER making all   desired changes.
[Entry Fiel ds]
Physical  Volume Identifiers	0022be2aal3f292e
* Remote PV Client Internet Address	
  [192.l01.101.73, 192.101.101.74]
+
Configure Automatieally at System Restart?	[no] +
Start Hew Devices Immediately?	[yes] +
Fl=Help	F2=Riefresh	F3=Cance1	F4=List
F5= Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do

    При использовании командной строки используйте команду mkdev, как в примере 18.4:

    frigg;/# /(usr/sMn/mlrdev -с rpvserver -s rpvserver 
-t rpvstype \ >-a гpYS_pvid='0022Ьe2aalЗf292e' 
 -a client addr='192.168.101.73,\ 192.16a.101.741'   
 -a auto_online-V
rpvserverO Available
    Повторите действия пп. 1 и 2 для второго RPV. Используйте lsrpvserver для вывода списка определенных RPV-серверов, как показано в примере 18.5.
    friggt/K lsrpvserver _ц
#  RPV Server   Physical Volume Identifier    Physical Volume
  	
#rpv serverO	0022beЈddl3fЈ9Јe	hdiskl
frigg:/# lsattr -El  rpvserverO
auto_onl1ne n	Configure at System Boot     True
client_addr 192.168.101.73	Client JP Address	True
cHent_addr 192.168.101.74	Client IP Address	True
rpvs_pvid     0022be2eel3f292eO00OO000O000O000	Physical Volume Identifier True
    Сконфигурируйте RPV-клиенты. Выполните следующие действия на каждом клиенте.
  • Выберите smitty rpvclient -> Add Remote Physical Volume Clients (Добавление клиентов удаленных физических томов). Укажите IP-адрес RPV-сервера и локальный IP-адрес, используемые для репликации данных. Затем выберите удаленный диск из списка, как показано в примере 18.6.
    Add Remote Physical   Volume Clients
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Remote  Physical  Volume Server  Internet Address	10.1.101.192
Remote Physical Volume Local   Internet Address	192.168.101.74
PV Identifiers	0022be2aal3f292e0000000000000000
I/O Timeout Interval   (Seconds)	[180] i
Start New Devices Immediately?	[yes] +
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    При использовании командной строки см. пример 18.7:
    thor:/# /usr/sbin/mkdev -с disk -s remotedisk -t rpvclient \ >-a pvid='0022be2aal3f292e' -a server_addr='10.1.101.192' \
>-a local_addr='192.168.101.73' -a io_timeout='180' hdisk6 Available
thor:/# lsattr -El hdisk6
io_timeout 180	I/O Timeout Interval     True
local_addr 192,168.101,73	Local IP Address       True
pvid     0022be2aal3f292e0000000000000000	Physical Volume Identifier True
server_addr 10.1.1.192	Server IP Address       True
    К этому моменту на клиенте созданы дисковые устройства, которые можно использовать для интеграции в группу томов и определения зеркальных отображений логических томов. Используйте команду lsrpvclient для вывода списка определенных клиентских RPV. На уровне операционной системы они определяются как обычные жесткие диски. Команды LVM, употребляемые для локальных томов, применяются и к RPV. Пример 18.8 содержит выходные данные команды lsdev.
    thor:/# lspv
hdiskO	0022be2a80b97feb	rootvg      active
hdiskl	none	None
hdisk2	0022be2aal3dc072	vgOl        concurrent
hdisk3	0022be2aal3ea83e	vg02        concurrent
hdisk4	none	None
hdiskS	none	None
hdisk6	0022be2aal3f292e	None
    Примечание. PVID RPV-клиента соответствует PVID удаленного диска. Повторите действия пп. 1–3 для создания обратной пары RPV, связывающей RPVсервер для локального диска на узле thor с RPV-клиентом на узле frigg. Повторите те же действия на узле odin, используя odin_geo1 в качестве локального адреса связи. Определение зеркального отображения LVM
  • Выполните расширение группы томов, содержащей основные данные с определенными RPV. Используйте меню GLVM в SMIT для расширения группы томов. Выполните smitty glvm_vg -> Add Remote Physical Volumes to a Volume Group (Добавление удаленных физических томов в группу томов) или используйте команду extendvg:
    extendvg vg01 hdisk6
  • Создайте зеркальное отображение группы томов, содержащей RPV.Примечание. Перед миграцией логического тома необходимо установить политику размещения "super strict". Используйте команду chlv -s s < lv_name> -u <upper_ bound>, чтобы изменить политику размещения на "super strict". Дополнительные сведения см. в документации по команде chlv. В примере 18.9 представлено изменение логических томов ulv11_log и ulv11:
    thor:/# chlv -s	s -u 2  ulvll_1og
thor:/# lslv ulvlllog
LOGICAL VOLUME:	ulvlljog	VOLUME GROUP:	vgOl
LV IDENTIFIER:	O022be2aO0OO4cO0O0000104d52d0c6d.l PERMISSION:
read/write
VG STATE:	active/complete	LV STATE:	opened/syncd
TYPE:	jfs21og	WRITE VERIFY:	off
MAX LPs:	512	PP SIZE:	16 megabyte(s)
COPIES:	1	SCHED POLICY:	parallel
LPs:	1	PPs:	1
STALE PPs:	О	БВ POLICY:	relocatable
INTER-POLICY:	minimum	RELOCATABLE:   yes
INTRA-POLICY;	middle	UPPER BOUND:   2
MOUNT POINT:	N/A	LABEL:       None
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON	A SEPARATE PV ?: yes (superstrict)
Serialize 10 ?:	NO
thor:/# chlv -s	s -u 2 ulvll
thor:/# 1 siv ulvll
LOGICAL VOLUME:	ulvll	VOLUME GROUP:  vgOl
LV IDENTIFIER:	0022be2a00004c0000000104d52d0c6d.2 PERMISSION:
read/write
VG STATE:	active/complete	LV STATE:     opened/syncd
TYPE:	jfs2	WRITE VERIFY:  off
MAX LPs:	512	PP SIZE:      16 megabyte(s)
COPIES:	1	SCHED POLICY:  parallel
LPs:	10	PPs:         10
STALE PPs:	О	ВВ POLICY:            relocatable
INTER-POLICY:	minimum	RELOCATABLE:        yes
INTRA-POLICY:	middle	UPPER BOUND:        2
MOUNT POINT:	N/A	LABEL:                     /appOl
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON	A SEPARATE PV ?: yes  (superstrict)
Serialize 10 ?:	NO
thor:/#
    Выполните зеркальное отображение группы томов, выбрав smitty glvm_vg -> Add a Remote Site Mirror Copy to a Logical Volume (Добавление зеркальной копии удаленного сайта в логический том). Можно использовать команду mirrorvg для зеркального отображения группы томов или команду mklvcopy для зеркального отображения логических томов, например:
    /usr/sbin/mklvcopy -s's' ulv11_log 2 hdisk6
    Проверьте состояние группы томов и логических томов с использованием команды lsvg, как показано в примере 18.10:
    thor;/#   lsvg	-p vgOl
vgOl:
PV_HAME	PY STATE	TOTAL PPs      FREE PP5        FREE DISTRIBUTION
hd1sk2	active	639	476	128..00..92..128..US
hdiste	active	639	478	138..02..92..126..120
thor:/* livg	-1 vgOl
vgOl:
LV NAME	TYPE	LPs      PPs	PVs    LV STATE	HOJNT РОШ
ulvlljog	jfsZlag	1	2	2        Dpen/syncd        H/A
ulvll-	Jfs2	160     320	2       open/stale       N/A
ulvll_sm	statemap	1	1	1       ореп/tyned       NM
ulvll log sm	statemap	111        open/syncd        N/A
  • Выполните постепенную остановку служб кластера на локальном узле через меню smitty clstop. Проверьте корректность остановки обработки ресурсов кластера. Используйте команду lsgmd, чтобы убедиться в том, что GMD находятся в состоянии "Defined".
  • На каждом узле в кластере измените определение файловой системы в файле /etc/ filesystems, чтобы использовать обычные логические тома, а не GMD (пример 18.11).
    /appOl:
dev	=	/dev/ulvll
vfs	=	jfs2
log	=	/dev/ulvll_log
mount	=	false
check	=	false
account	=	false
    Важно! Если изначально файловые системы создавались с использованием команды crfs, происходит обновление контрольного блока логического тома (logical volume control block, LVCB) информацией файловой системы, так что каждая команда importvg обновляет файл /etc/filesystems. Проверку данных LVCB можно выполнить с применением команды getlvcb -AT <lv_name>. Если был создан fleshiest over GMD с использованием команды mkfs, команда importvg не обнов-ляет информацию fleshiest в файле /etc/filesystem.
  • Изменение определений топологии и ресурсов HACMP для использования GLVM.Примечание. HACMP/XD HAGEO не поддерживает динамическую конфигурацию. Для изменения конфигурации кластера необходимо остановить службы кластера. HACMP/XD GLVM поддерживает динамическую реконфигурацию, если только не установлен HAGEO. Для интеграции групп томов GLVM в HACMP требуется убедиться в том, что осуществляется репликация каждого логического тома. Если группы томов с географическим зеркальным отображением содержат нереплицируемые логические тома, HACMP выдает сообщение об ошибке.
  • Реконфигурация топологии кластера.
  • Измените тип сети с Geo_Primary на XD_data. На момент публикации этой книги использование двух сетей XD_data не поддерживалось. В кластере могут быть одновременно сконфигурированы GMD и RPV. Однако ресурсы GMD и RPV не могут входить в одну группу ресурсов. Если у вас имеется две сети Geo_Primary, можно оставить вторую сеть для непреобразованных GMD. Пример 18.12 показывает преобразование первой сети Geo_Primary в тип XD_data.
    Change/Show an IP-Based Network in the HACMP Cluster
Type or select values in entry fields.
Press Enter AFTER making all   desired changes.
[Entry Fields]
*	Network Name	net_Geo_Primary_01 New Network Name	[XD_data_net_01]
*	Network Type	[XD_data]+
*	Netmask	[255.255.255.0]+
*	Enable IP Address	Takeover via IP Aliases                   N0+ IP Address Offset	for Heartbeating over IP Aliases            П
*	Network attribute	public*
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Comnand	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    Примечание. При изменении атрибута сети Geo_Primary с private на public, необходимо удалить и заново создать сеть.
  • Синхронизация топологии кластера.
  • Изменение групп ресурсов для интеграции RPV. Не требуется конфигурировать специальные ресурсы для использования RPV в кластере. На данном этапе следует удалить определения GMD из групп ресурсов (пример 18.13).
    Change/Shaw All fiesouгее* and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group Name	"pp01_r9
tnter-site Management Policy	Prefer Primary Site
Participating Nodes from Primary Site	thDr Ddin
Participating Nodes from Secondary Site	frigg
Startup Policy	Online On Hume Node Only
Fa4over Policy	Fa 11 over To Next Priority
Node In The List
Fan bade Policy	Fallback то Higher
Priority Node In The Li>
Fallback Timer Policy (empty is immediate)	[]	+
Service IP Labels /Addresses	[]	+
Application Servers                                                      [ai:uOI_srv]	+
Volume Groups                                                                            [vgOl ]	+
Use forced varyon of volume groups,  if necessary       true	+
Automatically  Import Volume Groups                                    false	+
Filesystems (empty is ALL for VGs specified)              f/appOl  ]	+
Filesystems Consistency Check                                         fsck	+
Filesystems Recovery Method                                          sequential	+
Fllesystems mounted before IP configured                    false	+
Filesystems/Directories to Export                                	+
F11 esystems/01rectories to NFS Mount                          []
Network For NFS Mount                                                         []	+
Tape Resources                                                               []	+
Raw Disk PVIDs                                                                              []	+
Fast Connect Services                                                            []	+
Communic.ition Links                                                                []	+
Primary Workload Manager Class                                          []	+
Secondary workload Manager Class                                	+
Miscellaneous Data                                                           []
GeoMirror Devices	+
Fl=nelp	FZ=Refresh	F3=cancel	F4=Llst
F5=Reset	F6=coinmaria	F7=Edit	F3= image
F9-snell	F10=Exit	Enter=Do
  • Синхронизация определения кластера по узлам.
  • Запуск кластера на узлах.
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^