Лекция 18: Понятия и конфигурирование GLVM

Миграция – переход от 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.

1. Остановка удаленного сайта и создание RPV-серверов на удаленном сайте. Цель миграции состоит в том, чтобы настроить использование GLVM при репликации данных без дополнительного оборудования. Недостаток этого процесса состоит в том, что необходимо отключать удаленную копию GMD, а затем перезаписывать в качестве устройства GLVM, оставляя заказчика без резервной копии данных. Если это представляет проблему, то потребуется использование дополнительного оборудования. В нашем примере происходит остановка реплицируемой копии группы ресурсов на резервном сайте (основное устройство GMD больше не выполняет синхронизацию данных), после чего происходит создание RPV-сервера, указывающего на физический том ( рис. 18.14).
   

   
   Рис. 18.14. Создание RPV-сервера
2. Создание локального RPV-клиента и зеркального отображения. Следующим этапом является создание локального RPV-клиента и добавление физического тома в группу томов GMD. Для всех логических томов данных и логических томов jfslog требуется установить политику размещения "super strict", после чего расширить путем добавления копии RPV-клиента. Мы рекомендуем не выполнять зеркальное отображение логических томов statemap, так как после отключения GMD они будут не нужны. После определения зеркальной копии логических томов можно осуществлять синхронизацию данных. При этом происходит репликация всех данных с основной копии даных на резервный сайт, что влияет на производительность обоих узлов и создает большую нагрузку на сеть ( рис. 18.15).
   

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

   
   Рис. 18.16. Приложение использует устройства GLVM