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

Планирование

Устранение единых точек отказа

В табл. 3.1 приведен обзор возможных единых точек отказа в инфраструктуре кластера и способов защиты от них. Эти аспекты следует учитывать во время разработки подробной схемы кластера.

Таблица 3.1. Единые точки отказа
Объекты кластера Способ устранения единой точки отказа Поддержка в HACMP/AIX
Узлы Использование нескольких узлов До 32
Источники питания Использование нескольких электросетей или источников бесперебойного питания (ИБП) Столько, сколько нужно
Сети Использование нескольких сетей для соединения узлов До 48
Сетевые интерфейсы, устройства и IP-адреса Использование резервных сетевых адаптеров До 256
Подсистема TCP/IP Использование сетей "точка-точка" для соединения соседних узлов и клиентов Столько, сколько нужно
Дисковые адаптеры Использование резервных дисковых адаптеров Столько, сколько нужно
Дисковые контроллеры Использование резервных дисковых контроллеров Столько, сколько нужно (ограничение на аппаратном уровне)
Диски Использование резервного оборудования, а также технологий зеркального отображения, чередования или их сочетания Столько, сколько нужно
Приложения Назначение узла для перехвата приложения, конфигурирование мониторов приложений, конфигурирование кластеров с узлами на нескольких сайтах Столько, сколько нужно
Сайты Использование нескольких сайтов для аварийного восстановления (disaster recovery) 2
Группы ресурсов Использование групп ресурсов с указанием, каким образом должен работать набор ресурсов До 64 в кластере
Ресурсы кластера Использование нескольких ресурсов кластера До 128 в Clinfo (кластер может включать больше)

Первоначальная схема кластера

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

На этом этапе следует создать схему кластера HACMP. Рекомендуется начать с простого и постепенно увеличивать степень детализации по мере продвижения процесса планирования. Схема позволяет выявить единые точки отказа, требования приложений и поможет направлять процесс планирования.

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

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

Первоначальная схема кластера

увеличить изображение
Рис. 3.3. Первоначальная схема кластера

Мы начинаем принимать решения относительно схемы топологии и режима работы кластера на основании своих требований. Например, в соответствии с требованиями первоначальная схема кластера включает следующее:

  • Кластер представляет собой кластер из двух узлов со взаимным перехватом.
  • В качестве имен узлов кластера можно использовать имена хостов, однако мы решили задавать имена узлов кластера.
  • Каждый узел содержит одно приложение, но способен выполнять оба (нужно рассмотреть сеть, хранилище, память, процессор, программное обеспечение).
  • Каждый узел имеет два Ethernet-адаптера, подключенные к одной физической сети Ethernet, каждый к отдельному коммутатору (или какой-либо тип резервного коммутатора).
  • Используется перехват IP-адреса посредством синонимом (а не посредством замены).
  • Каждый узел имеет постоянный IP-адрес (IP-синоним, всегда доступный при работе узла) и один сервисный IP-адрес (IP-синоним на одном из адаптеров, находящихся под управлением HACMP). Базовые адреса адаптера Ethernet относятся к разным подсетям. Так как используется мониторинг пульса через синонимы, это условие не является обязательным, при необходимости оба адаптера могут находится в одной подсети.
  • Общие диски находятся в SAN и доступны на обоих узлах.
  • Все группы томов на общих дисках создаются в режиме расширенного одновременного доступа (Enhanced Concurrent Mode, ECM), что позволяет обеспечить мониторинг пульса через диски и быстрый перехват дисков.
  • Последовательное подключение RS232 показано, однако в связи с использованием мониторинга пульса через диски можно опустить этот элемент схемы. Он показан как необязательный.
  • Используется мониторинг пульса через IP-синонимы (не показано).
  • Каждый узел имеет достаточно ресурсов процессора и памяти для выполнения обоих приложений.
  • Каждый узел имеет резервное оборудование и внутренние диски с зеркальным отображением.
  • Установлен AIX 5.3 ML02.
  • Используется HACMP 5.3.
Примечание. Если вы планируете использовать динамические разделы (DLPAR), имя хоста AIX, имя узла кластера и имя HMC LPAR (отображаемое в интерфейсе HMC) должны совпадать.

Этот список кратко описывает основные компоненты схемы кластера. Каждый элемент будет более подробно рассмотрен в процессе планирования.

Заполнение обзорной таблицы планирования кластера

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

Таблица 3.2. Обзор кластера
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 1 из 11 ОБЗОР КЛАСТЕРА ДАТА: июль 2005
ИМЯ КЛАСТЕРА cluster10
ОРГАНИЗАЦИЯ IBM ITSO
ИМЯ ХОСТА УЗЛА 1 ha53node1
ИМЯ ХОСТА УЗЛА 2 ha53node2
ИМЯ HACMP УЗЛА 1 node01
ИМЯ HACMP УЗЛА 2 node02
КОММЕНТАРИИ Это набор таблиц планирования для простого 2-узлового кластера HACMP 5.3 со взаимным перехватом с использованием перехвата IP-адреса посредством синонимов.

Планирование оборудования кластера

Схема кластера начинается с определения требуемого количества и типа узлов. Эти аспекты в значительной степени зависят от двух факторов:

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

При выборе узлов основное условие заключается в том, чтобы в случае перемещения при сбое оставшийся узел или узлы были способны выполнять приложения с отказавшего узла. Другими словами, если у вас есть кластер из двух узлов и при этом отказывает один узел, оставшийся узел должен иметь ресурсы, требуемые для выполнения приложений с отказавшего узла (помимо собственных приложений). Если это невозможно, можно рассмотреть вариант внедрения дополнительного узла в качестве дежурного или вариант использования динамических разделов (DLPAR, в системах POWER4™ или POWER5™). Как вы сможете заметить, HACMP допускает широкий выбор конфигураций кластера в зависимости от ваших требований.

HACMP работает практически с любым узлом, поддерживаемым AIX, от настольных систем до высокопроизводительных серверов. При выборе типа узла следует учитывать следующее:

  • Убедитесь, что все узлы имеют достаточно ресурсов процессора и памяти, чтобы система могла вести себя требуемым образом в случае перемещения при сбое. Ресурсы процессора и памяти должны быть способны поддерживать требуемые приложения в случае перемещения при сбое, иначе у клиентов могут возникнуть проблемы с производительностью. Если вы используете разделы LPAR, вам может быть полезно использовать возможности DLPAR для увеличения ресурсов в случае перемещения при сбое. При использовании автономных серверов такая возможность отсутствует, так что вам, возможно, придется рассмотреть вариант применения дежурного (резервного, standby) сервера.
  • На каждом сервере используйте оборудование высокой доступности и резервные компоненты там, где это возможно. Например, применяйте резервные источники питания и подключите их в отдельным электросетям.
  • На каждом узле обеспечьте защиту rootvg (копии локальной операционной системы) с использованием зеркального отображения или технологии RAID.
  • Установите как минимум два Ethernet-адаптера на каждом узле и подключите их к отдельным коммутаторам, чтобы защитить их от отказа одного из адаптеров или коммутаторов.
  • Установите два SAN-адаптера на каждом узле, чтобы защитить их от отказа одного из SAN-адаптеров.

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

Заполнение таблицы планирования оборудования кластера

Табл. 3.3 содержит сведения об оборудовании для нашего примера. Там, где это возможно, мы использовали избыточное оборудование, дополнительные коммутаторы Ethernet и SAN, а также убедились в достаточности ресурсов для поддержки одновременной работы приложений на каждом узле.

Таблица 3.3. Оборудование кластера
ТАБЛИЦА КЛАСТЕРА HACMP – ЧАСТЬ 2 из 11 ДАТА: июль 2005
ОБОРУДОВАНИЕ КЛАСТЕРА
КОМПОНЕНТ ОБОРУДОВАНИЯ СПЕЦИФИКАЦИИ КОММЕНТАРИИ
p520 Сервер pSeries Количество – 2
2 процессора и 4 Гб памяти *Последняя версия микрокода
4 внутренних SCSI-диска Резервные источники питания.
Достаточно ресурсов для выполнения обоих приложений на одном сервере
Ethernet-адаптеры 10/100/1000 Ethernet 2 NIC на узел (минимум)
Сетевые коммутаторы Название производителя Модель 2 коммутатора.
Каждый NIC на узле подключен к отдельному коммутатору.
Все порты сконфигурированы в одной VLAN.
Коммутаторы поддерживают gratuitous ARP-запросы и отключенный алгоритм Spanning Tree.
Установлено оптимальное значение скорости порта коммутатора
Адаптеры SAN 6239 2GB Fibre Channel 2 HBA на узел
Коммутаторы SAN IBM 2109 2 коммутатора.
Каждый HBA на узле подключен к отдельному коммутатору.
Общий диск разделен на зоны для всех узлов, требующих доступа
Хранилище SAN IBM ESS Модель 800
КОММЕНТАРИИ Совместимость оборудования проверена.

Планирование программного обеспечения кластера

Для обеспечения совместимости требуется провести анализ всех программных компонентов, которые планируется использовать в кластере. Необходимо рассмотреть программное обеспечение AIX, RSCT, HACMP, приложения и хранилища. В этом разделе обсуждаются различные уровни программного обеспечения, а также вопросы совместимости.

Уровни AIX и RSCT

HACMP 5.3 поддерживается в AIX версий 5.2 и 5.3. Использовавшиеся в нашей среде уровни сочетания AIX и RSCT приведены в табл. 3.4.

Таблица 3.4. Уровни AIX и RSCT
Версия AIX Версия RSCT Минимальные наборы файлов (filesets) RSCT
AIX 5.3 ML02 (5300-02) или выше, с APARS 2.4.2 rsct.compat.basic.hacmp.2.4.2.0, rsct.compat.clients.hacmp.2.4.2.0, rsct.core.sec.2.4.2.1,
AIX 5.2 ML06 (5200-06) или выше, с APARS IYXXXXX 2.3.6 rsct.compat.basic.hacmp.2.3.6.0, rsct.compat.clients.hacmp.2.3.6.0, rsct.core.sec.2.3.6.1, rsct.core.rmc.2.3.6.1

Поддержка Virtual LAN и Virtual SCSI

Для поддержки функций Virtual LAN (виртуальная локальная сеть) и Virtual SCSI, реализованных в IBM P5 Virtual I/O Server, необходимы следующие уровни программного обеспечения:

  • AIX 5.3 ML02 (5300-02) с APARs IY70082 и iFIX IY72974;
  • VIO Server V1.1 с Fixpack 6.2 и iFIX IY71303.062905.epkg.Z;
  • минимальные уровни RSCT:
    • rsct.basic.hacmp 2.4.2.1,
    • rsct.basic.rte 2.4.2.2,
    • rsct.compat.basic.hacmp 2.4.2.0.

Обязательные наборы файлов

Следующие наборы файлов являются обязательными для работы HACMP. Они должны быть установлены вместе с последней версией исправлений к соответствующему уровню AIX перед установкой HACMP.

  • bos.adt.lib;
  • bos.adt.libm;
  • bos.adt.syscalls;
  • bos.net.tcp.client;
  • bos.net.tcp.server;
  • bos.rte.SRC;
  • bos.rte.libc;
  • bos.rte.libcfg;
  • bos.rte.libcur;
  • bos.rte.libpthreads;
  • bos.rte.odm;
  • bos.rte.lvm.rte (необходим только при использовании существующего или унаследованного 32-разрядного диспетчера Concurrent Logical Volume Manager для одновременного доступа);
  • bos.clvm.enh (необходим для логических томов с расширенным одновременным доступом; используется при мониторинге пульса через диски).