Главная » Статьи » Установка/конфигурирование/планиров | [ Добавить статью ] |
Это третья статья серии, в которой описывается процесс установки и настройки большого Linux-кластера. Целью данной серии является объединение в одном месте последней информации из разнообразных общедоступных источников о создании работающего Linux-кластера из множества отельных частей аппаратного и программного обеспечения. В этих статьях не описываются основы проектирования нового большого Linux-кластера, а лишь предоставляются ссылки на соответствующие справочные материалы и Redbooks™ по общей архитектуре. Данная серия статей предназначена для использования системными разработчиками и системными инженерами при планировании и внедрении Linux-кластера при помощи интегрированной среды IBM eServer Cluster 1350 (ссылки на дополнительную информацию по данной среде приведены в разделе "Ресурсы"). Некоторые статьи могут быть полезны администраторам как в качестве учебных материалов, так и при использовании в процессе эксплуатации кластера. Каждая часть данной серии статей ссылается на один и тот же пример установки. В первой части данной серии приведены подробные инструкции по установке аппаратного обеспечения кластера. Во второй части рассматриваются следующие после конфигурирования оборудования действия: установка программного обеспечения при помощи программы управления системами IBM Cluster Systems Management (CSM) и установка узлов. Третья часть является началом, описывающим систему хранения данных кластера. Третья и четвертая часть охватывают установку и настройку аппаратного обеспечения системы хранения данных и настройку файловой системы IBM с совместным доступом General Parallel File System (GPFS). В данной статье рассмотрена архитектура системы хранения данных, подготовка аппаратного обеспечения и подробная информация по установке Storage Area Network В четвертой и последней статье серии подробно рассматриваются специфические вопросы CSM, относящиеся к системе хранения данных нашего примера кластера, в частности, установка узлов для системы хранения данных и настройка GPFS-кластера. Сначала вернемся к разделу "Общая архитектура кластера" из первой статьи данной серии. На рисунке 1 показана конфигурация системы хранения данных примера кластера, описанного в данной серии статей. В настоящей статье эта конфигурация рассматривается более подробно. Здесь используется GPFS версии 2.3. В систему входит один большой GPFS-кластер, разделенный на две логические половины с единой большой файловой системой. Проект примера обеспечивает устойчивость к авариям, и если одна половина системы хранения данных перестает функционировать, другая половина остается в рабочем состоянии. Рисунок 1. Обзор архитектуры системы хранения данных На рисунке 1 показаны четыре сервера хранения данных, управляющих системой хранения из двух дисковых подсистем. В правом верхнем углу можно увидеть сервер разрешения конфликтов. Для наглядности показаны сетевые подключения и подключения по оптоволокну. Все это подробно описывается в следующих разделах. Остальная часть кластера показана в виде облака и не будет рассматриваться в данной статье. Она подробно описана в первой и второй частях данной серии статей. Большинство узлов данного GPFS-кластера работает под управлением Red Hat Enterprise Linux 3. В примере использована архитектура клиент/сервер, в которой небольшое подмножество серверов выступает как сервер, использующий оптоволоконный канал. Эти серверы выполняют роль NSD-серверов (network shared disk - сетевой диск с совместным доступом). Это означает, что большинство участников GPFS-кластера обращается к системе хранения данных по IP, используя NSD-серверы. Всего имеется четыре NSD-узла (известных также под названием узлов системы хранения данных): по два в каждой половине GPFS-кластера. Они сгруппированы по парам. Каждая пара управляет одной из подсистем хранения данных. Поскольку
каждая половина кластера содержит одинаковое количество узлов, при
повреждении одной из половин возникает проблема кворума. В GPFS для
сохранения доступности файловой системы должен поддерживаться кворум.
Он определяется так: В таких конфигурациях как эта, в которых кластер состоит из двух идентичных половин, файловая система становится недоступной при потере любой из них. Для преодоления подобной ситуации в системе реализован узел разрешения конфликтов (tie-breaker node). Данный узел физически расположен вне основного кластера. Это означает, что при недоступности одной из половин, другая половина cможет продолжать обращаться к файловой системе GPFS. Также это становится возможным при использовании трех аварийных групп, что рассматривается ниже в разделе "Репликация данных". Это означает доступность двух копий данных - по копии в каждой половине кластера. Как показано на рисунке 1, каждый узел подключен к двум сетям. Первая из них используется для передачи данных между компьютерами и общего взаимодействия кластера. Вторая сеть предназначена для GPFS и обеспечивает доступ к системе хранения данных по IP тем узлам, которые не видят напрямую систему хранения данных Storage Area Network (SAN). Эта вторая сеть использует пакеты увеличенного размера (jumbo frames) для повышения производительности. Более подробная информация по системе хранения данных приведена в разделе "Настройка GPFS-сети" четвертой статьи данной серии. Система хранения данных Storage Area Network Сервер системы хранения данных для рассматриваемого решения состоит из двух дисковых подсистем, представляющих собой дисковые системы IBM TotalStorage DS4500 (прежде называвшиеся FAStT 900s), к каждой из которых подключены полностью заполненные дисковые стойки расширения EXP710. Каждая система DS4500 настроена как массив RAID 5 4+P плюс несколько дисков горячего резервирования. Каждая система DS4500 принадлежит паре серверов хранения данных. Архитектура разделяет массивы 4+P между двумя серверами таким образом, что каждый сервер является первичным сервером для первой половины массивов и вторичным для второй половины массивов. Таким образом, при возникновении аварии на одном из серверов другой сервер может выступить первичным для дисков поврежденного сервера. В данном примере используется GPFS-репликация данных и метаданных файловой системы GPFS. Система хранения данных делится на три аварийные группы. Аварийная группа представляет собой набор логических дисков, разделяющих общую точку неисправности. (С точки зрения операционной системы это диск, соответствующий одной LUN, которая является одним дисковым массивом в DS4500.) Аварийные группы в данной системе составлены из:
При создании файловой системы GPFS вы должны указать количество копий данных и метаданных равным двум. То есть, с определенными выше аварийными группами каждая половина содержит одну копию файловой системы. Третья аварийная группа необходима для решения проблем с дисковым кворумом, для того чтобы при возникновении аварии на какой-либо половине системы хранения данных дисковый кворум сохранялся, и файловая система оставалась доступной. Подготовка аппаратного обеспечения Как уже упоминалось, данный кластер содержит два устройства IBM TotalStorage DS4500, которые формируют систему хранения данных. Ссылки на более подробную информацию по этому аппаратному обеспечению приведены в разделе "Ресурсы". IBM соединяет каждую систему DS4500 при помощи модулей расширения системы хранения данных IBM TotalStorage DS4000 EXP710 с оптоволоконным каналом (fiber channel - FC). Каждый из них является 14-секционным, монтируемым в стойку FC-корпусом со скоростью передачи 2 GBps. Ссылки на более подробную информацию по данному аппаратному обеспечению приведены в разделе "Ресурсы". В следующем разделе более подробно рассматривается настройка системы DS4500 и модулей EXP710 для примера решения. Порядок включения и отключения Обратите внимание на необходимость включения и отключения системы SAN в определенном порядке для корректного обнаружения всей системы хранения данных. Включение производите в следующем порядке:
Выключение производите в следующем порядке:
На рисунке 2 показан вид сзади модуля DS4500. С левой стороны находятся четыре порта мини-хабов для соединения с хост-компьютером. В данной статье они обозначаются как слоты с 1 по 4, понумерованные слева направо, как показано на рисунке 1. Слоты 1 и 3 соответствуют верхнему контроллеру (А). Слоты 2 и 4 соответствуют верхнему контроллеру (В). С правой стороны находятся четыре порта мини-хабов для соединения со стойкой расширения (EXP710). Рисунок 2. DS4500, вид сзади Каждая система DS4500 подключена в два кольца, как показано на рисунке 3. Рисунок 3. Пример монтажа DS4500 и стоек EXP Установка идентификаторов EXP-корпусов Каждая стойка EXP 710 должна иметь уникальный идентификатор. Он устанавливается на задней панели каждого корпуса. Настройка IP-адресов для контроллеров DS4500 Установите IP-адрес каждого контроллера, используя последовательный порт на задней панели каждого корпуса. Вы должны использовать приложение hyperterminal в Windows® или minicom в Linux. В примере используются следующие настройки:
Установите
соединение путем передачи сигнала break (Ctrl-Break в hyperterminal), а
затем нажмите клавишу "пробел" для установки скорости. Затем передайте
еще один сигнал break и используйте клавишу escape для входа в
командную оболочку. Пароль по умолчанию - Используйте команду Обнаружение DS4500 в Storage Manager С этого момента DS4500 управляется при помощи программы Storage Manager (SM). С новой аппаратурой используйте самую последнюю версию (9.1 или выше). Storage Manager можно использовать для:
Можно также выполнить работы по устранению неисправностей и регулированию, например, проверку состояния подсистемы TotalStorage и обновление встроенной микропрограммы RAID-контроллеров. Ссылки на последнюю версию Storage для вашего аппаратного обеспечения можно найти в разделе "Ресурсы". SM-клиент можно установить на различные операционные системы. В описанном в данной статье примере SM-клиент устанавливается на управляющий сервер. Найдите только что настроенную систему DS4500 в SM-клиенте, используя первую кнопку слева, на которой изображен щуп. Для выполнения операций с DS4500, видимой через этот интерфейс, выполните двойной щелчок кнопкой мыши на имени компьютера, чтобы открыть новое окно. Общие действия по настройке контроллера DS4500 Прежде всего, переименуйте DS4500, выбрав пункт меню Storage Subsystem > Rename… и введя новое имя. Затем проверьте синхронизацию времени в меню Storage Subsystem > Set Controller Clock. Если нужно, выполните синхронизацию. Установите системный пароль в меню Storage Subsystem > Change > Password. Обновление встроенной микропрограммы для DS4500 и стоек EXP 710 Для проверки версии системной микропрограммы в Storage Manager выберите пункт меню Advanced > Maintenance > Download > Firmware. Текущие версии отображаются в виде списка в верхней части окна. Отсюда вы можете загрузить в компьютер более новые версии, но обязательно используйте корректную микропрограмму для модели и выполняйте обновление в порядке, указанном во всех комментариях, поставляемых с кодом микропрограммы. В меню Download можно также проверить версии микропрограмм дисков и ESM. Сравнение ручной настройки и настройки с использованием сценариев В следующих разделах подробно рассматривается процедура ручной настройки DS4500. Выполните эти действия для первоначальной настройки одного из контроллеров DS4500 в данном решении и сохраните конфигурацию первого DS4500. При этом создастся сценарий, который вы можете использовать позднее для восстановления конфигурации этого же DS4500, если производился сброс или замена на новое аппаратное обеспечение. Вы можете скопировать этот сценарий и изменить его для использования на другой системе DS4500, чтобы легче и точнее воспроизвести аналогичную конфигурацию. Необходимо изменить поля, содержащие имя DS4500, месторасположения дисков, имена массивов и подробную информацию по отображению хостов (то есть, World Wide Port Numbers [WWPNs]). Обратите внимание на то, что эти сценарии сохраняют Access LUN в определении группы хостов. Эта информация удаляется вручную для каждого контроллера DS4500. Создание дисков горячего резервирования В данном примере несколько дисков каждой системы DS4500 выделяются для горячего резервирования. Они добавляются путем двойного щелчка правой кнопки мыши на диске, предназначенном для горячего резервирования, выбора ручного варианта и ввода пароля для DS4500 (установленного в разделе "Общая настройка контроллера DS4500").
При создании этого массива вы заметите зеленый цилиндр с часами. Вы можете проверить ход выполнения работы, щелкнув правой кнопкой мыши на имени логического диска и выбрав Properties. Обратите внимание на то, что выполняемые с этого момента действия требуют наличия настроенных SAN-коммутаторов и установленных и работающих серверов системы хранения данных с шинными адаптерами хостов (host bus adapters - HBA), настроенными так, чтобы WWPN адаптеров HBA были видимы SAN-коммутаторами и, следовательно, контроллером DS4500. Подробно эти действия рассматриваются в разделах по настройке SAN-инфраструктуры и HBA в четвертой части данной серии статей. Разбиение памяти и отображение дисков После создания LUN их необходимо назначить хостам. В данном примере используйте разбиение дисков (storage partitioning). Определите дисковые разделы путем создания отображения логический-диск-на-LUN. Это предоставит хосту или группе хостов доступ к конкретному логическому диску. При разбиении дисковой памяти выполните перечисленные ниже действия по порядку. Сначала определите топологию, а уже затем выполняйте реальное разбиение:
Как уже говорилось, в данном примере имеется только одна группа на DS4500, содержащая два узла хранения данных, между которыми все диски данного DS4500 распределяются поровну. Этой группе назначаются все LUN, за исключением Access LUN, который нельзя назначать этой группе. Access LUN используется для внутреннего управления контроллером DS4500. Однако он не поддерживается операционной системой Linux и должен быть удален из любой создаваемой группы узлов. Создайте новую группу хостов, щелкнув правой кнопкой мыши на разделе Default Group и выбрав Define New Host Group. Введите имя группы хостов. Создайте новый хост, щелкнув правой кнопкой мыши на созданной группе хостов и выбрав Define Host Port. В ниспадающем меню выберите WWPN, соответствующий добавляемому HBA. Обратите внимание на то, что для появления в данном меню WWPN хост должен быть корректно настроен и зонирован в SAN. Storage Manager увидит порт в Show All Host Port Information. Должен быть выбран Linux Host Type, а в последнем окне нужно ввести имя в поле Host port name. Повторите этот шаг для определения обоих портов на каждом хосте. Затем создайте дисковый раздел, щелкнув правой кнопкой мыши на только что созданной группе хостов и выбрав Define Storage Partition. При этом откроется мастер Storage Partitioning. Нажмите кнопку Next для запуска мастера. Выберите только что созданную вами Host Group и нажмите кнопку Next. Выберите определенные ранее LUN. Обратите внимание на то, что сюда нельзя включать Access LUN. Нажмите кнопку Finish, чтобы завершить выбор. В этом разделе рассматриваются действия по настройке SAN-инфраструктуры в кластере. В данном примере используются SAN-коммутаторы IBM TotalStorage SAN Switch H16 (2005-H16). Ссылки на более подробную информацию по данному оборудованию приведены в разделе "Ресурсы". В данном разделе статьи немного подробнее описываются действия по настройке SAN-коммутаторов с использованием в качестве примера команд и интерфейсов для коммутаторов H16. Настройка IP-адресов и имен хостов для SAN-коммутаторов H16 Чтобы выполнить первоначальную настройку IP-адресов SAN-коммутаторов H16, подключите их при помощи кабеля для последовательного порта, поставляемого с коммутатором (черные окончания, не нуль-модемный), к порту на задней панели компьютера. Используйте следующие настройки соединения:
Используйте параметры входа в систему по умолчанию: имя пользователя После настройки IP-адресов вы можете управлять SAN-коммутаторами при помощи Web-интерфейса. Подключитесь к SAN-коммутатору, используя IP-адрес в браузере с подключаемым модулем Java™. Для доступа к интерфейсу администратора нажмите кнопку Admin и введите имя пользователя и пароль. В данный момент вы можете ввести новое имя коммутатора в отображенное поле и сохранить изменения. Идентификатор домена должен быть уникальным для каждого домена структуры. В данном примере коммутаторы находятся в своей собственной структуре, но идентификаторы изменяются в случае последующих объединений. Обратите внимание на то, что коммутатор должен быть запрещен перед изменением идентификатора домена. Для дальнейшей работы, получив возможность обращаться к коммутатору по сети, вы можете изменить IP-адрес SAN-коммутатора через интерфейс администратора в закладке Network Config. Это альтернативный способ использованию последовательного соединения. В данном примере кластера используются следующие правила зонирования:
Зонирование SAN-коммутаторов выполняется при помощи Web-интерфейса для каждого коммутатора, как описано в предыдущем разделе. Страница зонирования может быть вызвана при помощи самой правой кнопки в группе в нижнем левом углу окна. Для упрощения управления зонированием назначьте псевдонимы каждому WWPN, чтобы идентифицировать подключенное к порту устройство. Ниже описан процесс создания псевдонимов и назначения их хостам. Прежде всего, добавьте псевдоним, нажав кнопку Create и введя имя псевдонима. Затем выберите WWPN для назначения этому псевдониму. Вы увидите три уровня детализации для каждого порта:
Добавьте второй уровень к псевдониму, выбрав second level и нажав кнопку Add member. После создания псевдонимов создайте зоны путем комбинирования групп псевдонимов. В данной конфигурации вы использовали зоны, в которых каждый HBA каждого хоста видит только один контроллер на соответствующем DS4500. Как было сказано в предыдущем разделе, в данном примере каждый DS4500 предоставляет свои диски только двум хостам. Каждый хост использует отдельное подключение к контроллеру для распределения нагрузки и максимизации пропускной способности. Такой тип зонирования известен под названием одинарного HBA-зонирования. Все хосты изолированы друг от друга на SAN-уровне. При этом устраняется нежелательная активность фреймов PLOGI между хостами, а также устраняется риск возникновения проблем, вызванных влиянием одного неисправного HBA на другие. В результате управление коммутатором становится надежнее, поскольку изменение каждой индивидуальной зоны не влияет на остальные хосты. При добавлении нового хоста создавайте также новую зону вместо добавления хоста к существующей зоне. Последним действием является добавление определенных зон в конфигурацию, которую можно сохранить и впоследствии активизировать. Полезно сгенерировать отчет по коммутатору, что можно сделать, нажав кнопку Admin и выбрав Switch Report. Этот отчет содержит в html-формате всю необходимую информацию для ручного воссоздания конфигурации коммутатора. Сохранение конфигурации на другом сервере После настройки SAN-коммутатора его конфигурацию можно передать на другой сервер по протоколу ftp. Вы можете сделать это снова, если необходимо автоматически перенастроить коммутатор. Ниже приведены действия по сохранению конфигурационного файла на сервере:
Обновление встроенной микропрограммы Вы можете обновить встроенную микропрограмму путем ее загрузки с FTP-сервера. Ниже описаны действия для выполнения этой процедуры:
Это только часть настройки сервера хранения данных нашего примера кластера. К последующим действиям относится использование CSM для завершения настройки, в частности, для выполнения установки узлов для системы хранения данных и настройки GPFS-кластера. Эти процедуры рассматриваются в четвертой и последней части данной серии статей. Об авторе
Источник: http://www.ibm.com/developerworks/ru/library/es-clusterseriespt3/index.html | |||||||||||||||||||
Просмотров: 1128 | |
Всего комментариев: 0 | |
Операционные Системы
[61]
ОС Open Source
|
Мобильный Linux [26] |
Сравнение ОС [7] |
Статьи о Linux [16] |
Свободное ПО [10] |
Програмирование [6] |
Не для нубов [5] |
Ядро [13] |
Хранилище данных [9] |
Устройства [1] |
Установка/конфигурирование/планиров [16] |
Файловые системы [3] |
Управление, основанное на политиках [1] |
Управление инфраструктурой [0] |
Серверы [5] |
Биографии [6] |
Прочее [25] |