Дисковая и сетевая подсистемы архитектуры HACMP

Показывать лекцию целиком

Частное и разделяемое дисковое пространство

Дисковое пространство в HACMP

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

Когда такое приложение устанавливается на кластер, все данные, которые могут меняться в процессе работы, должны быть помещены на диски, доступные всем узлам, потенциально способным поддерживать это приложение. Такое дисковое пространство называется "общим" (shared storage).

Дисковое пространство, доступное только одному узлу кластера, называется "частным" (private).

Место расположения информации в кластере

Место хранения информации

Операционная система

Всегда на частном дисковом пространстве

Динамически изменяющиеся данные приложений

Всегда на разделяемом дисковом пространстве

Статичные данные приложений

Конфигурационные файлы - обычно на разделяемом пространстве (для простоты синхронизации)

Лицензионные ключи - в зависимости от типа лицензии

Данные - по усмотрению администратора

Приложения

Для простоты синхронизации версий - на разделяемом пространстве

Для простоты обновлений версий - на частном пространстве.

Fibre Channel и HACMP

Планирование очень важно. В этом примере видно, что дисковая система и доступ к ней полностью продублированы для обеспечения высокой доступности.

Использование сетей кластером

Использование сетей в HACMP

Предоставление клиентам высоконадежного доступа к приложениям

Резервные адаптеры в сети и на узле

Резервные сети

Продуманный дизайн

Обнаружение и диагностика сбоев узла, сети и сетевого адаптера

Связь между подсистемами HACMP на разных узлах

С точки зрения пользователя, единственная причина, по которой кластер использует сеть – это обеспечение его (пользователя) доступа к приложению.

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

Сбои, детектируемые кластером

Сбой сетевого адаптера (Network Interface Card - NIC)

Сбой узла

Сбой сети

Как уже было сказано выше, HACMP обрабатывает только три типа сбоев:

network interface card (NIC) failures

node failures

network failures

Статусные пакеты (heartbeat)

HACMP должен производить мониторинг компонентов кластера для обнаружения их сбоев

HACMP посылает по сети статусные (heartbeat) пакеты

Статусные пакеты отсылаются и принимаются всеми сетевыми адаптерами

Это позволяет обнаружить все сбои сетей, узлов и адаптеров

Статусные пакеты не подтверждаются

Основной механизм мониторинга в HACMP - посылка статусных пакетов (heartbeat).

Кластер посылает их по всем сетевым адаптерам.

Обнаружение и диагностика сбоев

Обнаружение сбоя - "что-то не в порядке" – например, пакеты не пересылаются между alpha - en0 и beta - en0

Диагностика сбоя - "что не в порядке" – вышел из строя сетевой адаптер en0 на узле alpha

Статусных пакетов достаточно для обнаружения сбоя. Однако, их недостаточно для корректной диагностики - какой конкретно компонент вышел из строя.

Диагностика сбоев

При обнаружении сбоя HACMP использует специальную схему обмена пакетами для диагнростики реальной причины сбоя

Пример:

Alpha обнаруживает, что статусные пакеты не приходят по en0 и сообщает об этом узлу beta

Beta также обнаруживает это

Оба узла посылают диагностические пакеты между различными комбинациями сетевых адаптеров (включая обмен пакетами между разными адаптерами на одном узле)

Оба узла обнаруживают, что все пакеты, проходящие через адаптер en0 на alpha, пропадают, но пакеты, проходящие через адаптер en0 на beta, приходят

Диагностика: Вышел из строя адаптер en0 на узле alpha

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

Потеря всех статусных пакетов

При отсутствии статусных пакетов от другого узла невозможно отличить сбой сети от сбоя узла

Каждый узел считает, что другой узел вышел из строя!

Если узел обнаруживает, что он больше не получает статусных пакетов от второго узла, то он считает, что этот узел вышел из строя и инициирует fallover.

А что произойдет, если оба узла в кластере будут считать так???

Дополнительная сеть

Для обеспечения возможности диагностирования сбоев необходима резервная сеть.

Сеть должна быть независима от работоспособности подсистемы TCP/IP – Non-IP Network, Serial Network (Не-IP сеть)

HACMP должен иметь возможность корректной диагностики сбоя сети – все сетевые адаптеры в каждой физической IP-сети на любом узле должны иметь IP-адреса в разных логических подсетях

Для того, чтобы избежать такой систуации, что в результате сбоя IP- подсистемы кластер окажется "разделенным", в нем обязательно должна быть сеть, работающая без IP, например соединение по RS232.

Восстановление после сбоя

HACMP продолжает мониторинг сбойных компонентов для обнаружения их восстановления

Реинтеграция восстановленного компонента в кластер может быть причиной для событий в кластере

Даже после сбоя компонента топологии, кластер продолжает отсылку статусных пакетов. Это обеспечивает то, что после восстановления элемента, он будет автоматически реинтегрирован в кластер.

IP Address Takeover (IPAT)

Для каждого высоконадежного приложения, как правило, требуется собственный IP адрес (Service IP address - сервисный IP адрес)

Сервисный IP адрес обычно входит в ресурсную группу приложения

HACMP отвечает за обеспечение доступности сервисного IP адреса на узле, отвечающем за данную ресурсную группу

При сбое узла, отвечающего за приложение, HACMP переносит ресурсную группу на другой узел

При настройке IPAT для ресурсной группы сервисный IP адрес приложения также перейдет на другой узел

В случае сбоя узла кластер переводит ресурсную группу на резервный узел. Как часть ресурсной группы, сервисный IP адрес (тот адрес, на котором работает приложение), также переходит на резерв.