Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 615 / 22 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры

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

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

Рекомендуется отключить кворум для групп томов 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.4. Активный узел основного сайта при неработающем резервном сайте
Активный резервный сайт и репликация данных

Рис. 18.5. Активный резервный сайт и репликация данных
Активный резервный узел при неработающем основном сайте

Рис. 18.6. Активный резервный узел при неработающем основном сайте

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

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

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

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

Интеграция основного узла в кластер и запуск репликации

Рис. 18.7. Интеграция основного узла в кластер и запуск репликации
Приложение активно на основном сайте с двумя физическими томами и с одним RPV-клиентом

Рис. 18.8. Приложение активно на основном сайте с двумя физическими томами и с одним RPV-клиентом
Отключение основного сайта и приложение, использующее одну локальную копию группы томов

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

Рис. 18.10. Приложение не выполнило перемещения при интеграции основного сайта
Перемещение приложения при интеграции основного сайта

Рис. 18.11. Перемещение приложения при интеграции основного сайта

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

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

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

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

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

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

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