WWW.LIB.KNIGI-X.RU
БЕСПЛАТНАЯ  ИНТЕРНЕТ  БИБЛИОТЕКА - Электронные материалы
 

«Обзор д ополнения High Availability д ля Red Hat Enterprise Linux Ред акция 6 Red Hat Enterprise Linux 6 High Availability Обзор д ...»

Red Hat Enterprise Linux 6

High Availability

Обзор д ополнения High Availability д ля Red Hat Enterprise Linux

Ред акция 6

Red Hat Enterprise Linux 6 High Availability

Обзор д ополнения High Availability д ля Red Hat Enterprise Linux

Ред акция 6

Юрид ическое увед омление

Co pyright © 20 14 Red Hat, Inc. and o thers.

This do cument is licensed by Red Hat under the Creative Co mmo ns Attributio n-ShareAlike 3.0

Unpo rted License. If yo u distribute this do cument, o r a mo dified versio n o f it, yo u must pro vide attributio n to Red Hat, Inc. and pro vide a link to the o riginal. If the do cument is mo dified, all Red Hat trademarks must be remo ved.

Red Hat, as the licenso r o f this do cument, waives the right to enfo rce, and agrees no t to assert, Sectio n 4 d o f CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shado wman lo go, JBo ss, MetaMatrix, Fedo ra, the Infinity Lo go, and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o ther co untries.

Linux ® is the registered trademark o f Linus To rvalds in the United States and o ther co untries.

Java ® is a registered trademark o f Oracle and/o r its affiliates.

XFS ® is a trademark o f Silico n Graphics Internatio nal Co rp. o r its subsidiaries in the United States and/o r o ther co untries.

MySQL ® is a registered trademark o f MySQL AB in the United States, the Euro pean Unio n and o ther co untries.



No de.js ® is an o fficial trademark o f Jo yent. Red Hat So ftware Co llectio ns is no t fo rmally related to o r endo rsed by the o fficial Jo yent No de.js o pen so urce o r co mmercial pro ject.

The OpenStack ® Wo rd Mark and OpenStack Lo go are either registered trademarks/service marks o r trademarks/service marks o f the OpenStack Fo undatio n, in the United States and o ther co untries and are used with the OpenStack Fo undatio n's permissio n. We are no t affiliated with, endo rsed o r spo nso red by the OpenStack Fo undatio n, o r the OpenStack co mmunity.

All o ther trademarks are the pro perty o f their respective o wners.

Аннотац ия В это м д о кументе привед ена о бзо рная инф о рмация о д о по лнении High Availability д ля Red Hat Enterprise Linux 6.

Сод ержание Сод ержание..... ение............................................................................ 3.........

Введ.....

1. Со глаш ения д о кум ента

–  –  –

Введение В этом д окументе привед ены общие свед ения о д ополнении High Availability д ля Red Hat Enterprise Linux 6.

Посколь ку привед енная зд есь информация является лишь обзорной, она пред назначена д ля опытных ад министраторов Red Hat Enterprise Linux, знакомых с концепциями серверных вычислений.

За информацией о Red Hat Enterprise Linux обратитесь к д окументации:

Руководство по установке Red Hat Enterprise Linux 6.

Руководство по развертыванию пред оставляет информацию о конфигурации и ад министрированию Red Hat Enterprise Linux 6.

Информацию о д ополнениях и д ругих решениях Red Hat Enterprise Linux 6 можно найти в д окументах:

Конфигурация и управление дополнением High Availability обсужд ает вопросы эксплуатации решения High Availability (также известного как Red Hat Cluster) более под робно.





LVM сод ержит информацию об управлении логическими томами (LVM, Logical Volume Manager), в том числе— в кластерном окружении.

GFS2 пред лагает информацию об установке, настройке и эксплуатации файловой системы GFS2 (Global File System 2).

DM Multipath пред лагает информацию о многопутевых возможностях Red Hat Enterprise Linux 6.

Распределение нагрузки пред оставляет информацию о настройке высокопроизвод итель ных систем и служб с помощь ю д ополнения Red Hat Load Balancer (рань ше известного как виртуаль ный сервер Linux).

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

–  –  –

В стать е «Приемы развертывания кластера Red Hat Enterprise Linux с применением High Availability и GFS2» обсужд аются под ход ы к построению отказоустойчивого кластера с файловой системой GFS2.

Полный каталог д окументов в форматах HTML, PD F и RPM можно найти на д иске д окументации Red Hat Enterprise Linux и на сайте https://access.redhat.com/site/documentation/.

1. Соглашения д окумент а В этом руковод стве исполь зуются различные стили д ля выд еления текста.

1.1. Т ипографические соглашения Д ля выд еления текста исполь зуются четыре стиля, которые буд ут перечислены д алее.

Red Hat Ent erprise Linux 6 High Availabilit y Мо но ширинны й жирны й шриф т Исполь зуется д ля выд еления ввод имого текста, включая команд ы оболочки, имена файлов, пути д оступа, а также клавиши и их комбинации.

Например:

Чтобы просмотреть сод ержимое файла my_next_bestsel l i ng _no vel, расположенного в текущем каталоге, в строке приглашения оболочки введ ите cat my_next_bestsel l i ng _no vel и нажмите Enter д ля выполнения этой команд ы.

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

Комбинации клавиш отличаются от отд ель ных клавиш с помощь ю знака плюс, который соед иняет все клавиши, вход ящие в комбинацию.

Например:

Нажмите Enter д ля исполнения команд ы.

Нажмите C trl +Al t+F2 д ля переход а в виртуаль ный терминал.

В первом примере выд елена отд ель ная клавиша, которую над о нажать. Во втором примере выд елена комбинация клавиш — три клавиши, которые над о нажать од новременно.

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

Например:

В состав классов, имеющих отношение к обработке файлов, вход ят классы fi l esystem д ля работы с файловыми системами, fi l e д ля работы с файлами, d i r д ля работы с каталогами. Кажд ый класс имеет свой собственных набор прав д оступа.

–  –  –

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

Например:

Выберите С и ст ема П ар амет р ы Мышь д ля запуска приложения Н аст р о й ка мыши. На вклад ке Кно пки установите флажок Настро ить мы шь по д левую руку и нажмите Закры ть, чтобы правая кнопка мыши стала работать как главная (что д елает мышь уд обной д ля левши).

–  –  –

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

Моноширинный жирный курсив или пропорциональный жирный курсив

–  –  –

Оба типа выд еления указывают на изменчивость текста. Исполь зование курсива означает, что текст не след ует ввод ить букваль но, или что он может менять ся при вывод е в зависимости от обстоятель ств.

Например:

Д ля под ключения к уд аленной машине с помощь ю SSH введ ите ssh имя_пользователя@ имя_домена. Скажем, если имя уд аленной машины —

exampl e. co m, а имя поль зователя — john, то команд а буд ет выгляд еть так:

ssh jo hn@ exampl e. co m.

Команд а mo unt -o remo unt файловая_система перемонтирует указанную файловую систему. Например, д ля файловой системы /ho me команд а буд ет выгляд еть так: mo unt -o remo unt /ho me.

Чтобы просмотреть версию установленного пакета, выполните команд у rpm -q пакет. Резуль тат команд ы буд ет пред ставлен в формате пакет-версиявыпуск.

Обратите внимание на слова, выд еленные жирным курсивом: имя_поль зователя, имя_д омена, файловая_система, пакет, версия, выпуск. Кажд ое из них обозначает место, куд а нужно под ставить значение, или текст, под ставляемый системой при вывод е.

Также курсивом выд еляются важные термины, встречаемые в тексте д окумента впервые.

Например:

Publican — система публикации DocBook.

1.2. Выд еление фрагмент ов Вывод на терминал и фрагменты исход ного код а программ визуаль но отд еляются от окружающего текста.

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

–  –  –

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

–  –  –

Важные замечания выд еляют то, что легко не заметить : изменения настроек, касающиеся толь ко текущего сеанса, или перечень служб, которые над о перезапустить д ля применения обновлений. Игнорирование замечаний с пометкой «Важно» не привод ит к потере д анных, но может вызвать разд ражение и д осад у.

–  –  –

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

2. От зывы и пред ложения Чтобы оставить отзыв или сообщить об опечатках, созд айте запрос в Bugzilla по ад ресу http://bugzilla.redhat.com/, выбрав прод укт R ed H at En t erp rise Lin u x 6, компонент docHigh_Availability_Add-On_Overview и версию 6. 6.

Чтобы облегчить поиск ошибок, укажите номер разд ела и параграф.

–  –  –

Глава 1. Обзор высокодоступных решений Red Hat High Availability реализует кластерную схему с высоким уровнем д оступа, масштабирования и отказоустойчивости в критических окружениях.

Основные функции и компоненты этого д ополнения обсужд аются в след ующих секциях:

Разд ел 1.1, «Основы кластеризации»

Разд ел 1.2, «Знакомство с Red Hat High Availability»

Разд ел 1.3, «Инфраструктура кластера»

1.1. Основы класт еризации Кластер включает как минимум д ва компь ютера, называемых узлами или элементами, которые совместно решают поставленные зад ачи. Существует четыре категории кластеров:

Хранение д анных Высокая д оступность Распред еление нагрузки Высокая производ итель ность Кластеры хранения обеспечивают бесперебойный д оступ к файловой системе, разрешая вести параллель ную запись и чтение д анных с разных узлов. Управление хранилищем облегчается за счет того, что программы и исправления устанавливаются толь ко од ин раз в ед иной файловой системе. В кластерных файловых системах необход имость в созд ании избыточных копий программных д анных отпад ает, а процессы созд ания резервных копий и восстановления существенно упрощаются. Кластерное хранилище созд ается сред ствами Red Hat High Availability в комплексе с Red Hat GFS2 (в комплекте Resilient Storage).

Высокод оступные кластеры (их также называют отказоустойчивыми), как и след ует из опред еления, обеспечивают постоянный д оступ к службам за счет исключения ед иной точки отказа, перенося службы с од ного узла на д ругой в случае его неисправности. Обычно сервисы в таком кластере осуществляют чтение и запись д анных (файловые системы смонтированы в режиме чтения и записи), поэтому при отказе узла кластер д олжен обеспечить их целостность при перед аче управления д ругому узлу. Сбои узлов в отказоустойчивых кластерах обрабатываются незаметно д ля клиентов за их пред елами. За обеспечение непрерывного д оступа к кластерным сервисам отвечает менед жер ресурсов rg manag er (вход ит в комплект Red Hat High Availability).

Кластеры распред еления нагрузки, как и след ует из названия, распред еляют запросы обслуживания межд у узлами. Балансировка является экономичным способом масштабирования, посколь ку в зависимости от нагрузки вы сможете зад ействовать необход имое число узлов. В случае отказа узла запросы буд ут перенаправлять ся д ругим узлам, поэтому его сбой останется незаметным д ля клиентов за пред елами кластера. Эта функциональ ность реализована в д ополнении Red Hat Load Balancer.

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

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

Red Hat High Availability не под д ерживает высокопроизвод итель ные кластеры.

1.2. Знакомст во с Red Hat High Availabilit y Red Hat High Availability пред ставляет собой набор программных компонентов, позволяющий построить самые разнообразные схемы с высоким уровнем д оступа в зависимости от необход имого уровня производ итель ности, отказоустойчивости, степени распред еления нагрузки, масштабируемости, общего д оступа к файлам и рентабель ности.

Основные составляющие и функции:

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

Непрерывный д оступ — в случае отказа узла его сервисы буд ут перенесены на д ругой узел.

Сред ства ад министрирования — утилиты конфигурации и управления кластером.

–  –  –

Географически распред еленные кластеры пока официаль но не под д ерживаются. За под робной информацией обратитесь к пред ставителю Red Hat.

Функциональ ность отказоустойчивого кластера может быть д ополнена:

Red Hat GFS2 (Global File System 2) — кластерная файловая система пред оставляется в комплекте Red Hat Resilient Storage. Позволяет совместно исполь зовать пространство д анных на блочном уровне, как буд то устройство под ключено к узлу напрямую. GFS2 созд ается на базе кластерной инфраструктуры.

CLVM (Cluster Logical Volume Manager) — управление кластерным хранилищем.

Load Balancer — комплект распред еления нагрузки устанавливается на д вух избыточных виртуаль ных серверах, которые буд ут распред елять запросы обслуживания межд у физическими серверами.

1.3. Инфраст рукт ура класт ера Инфраструктура кластера пред оставляет базовую функциональ ность д ля объед инения компь ютеров (также называемых узлами) в кластер. Готовый кластер можно д ополнить д ругими компонентами д ля обеспечения совместного д оступа к файлам в GFS2, переноса служб в случае отказа узла и т.п. Основные функции кластерной инфраструктуры, которые буд ут обсужд ать ся в этом руковод стве:

управление кластером;

–  –  –

управление блокировками;

изоляция неисправных узлов;

управление конфигурацией кластера.

Red Hat Ent erprise Linux 6 High Availabilit y Глава 2. Управление кластером В отказоустойчивом кластере Red Hat зад ачи управления его элементами и формирования кворума решает менед жер CMAN (Cluster MANager), работающий на всех узлах и реализующий распред еленный механизм управления.

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

CMAN след ит за числом рабочих узлов, исход я из которого формируется кворум: если активно более половины узлов, кворум д остигнут. Если кворума нет, работа кластера буд ет приостановлена. Также кворум поможет принять решение при расщеплении кластера на д ве равные части и избежать ситуации, в которой обе части буд ут прод олжать работать, считая, что д ругая часть неработоспособна.

2.1. Кворум CMAN опред еляет наличие кворума метод ом голосования.

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

Так, например, в кластере с 13 узлами кворум буд ет набран при наличии 7 активных узлов, но при отказе еще од ного узла он буд ет потерян, и кластер не сможет прод олжить работу.

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

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

Активность узлов опред еляется наличием Ethernet-трафика межд у узлами, а кворум принимается боль шинством голосов, то есть в кластере д олжно быть активно 50% узлов плюс

1. Чтобы решить проблему распад ения кластера на равные сегменты, можно д ополнитель но д обавить кворумный д иск.

–  –  –

По умолчанию узел имеет од ин голос, но это можно изменить и выд елить ему произволь ное число голосов.

2.1.1. Кворумный д иск При расколе кластера кворумный д иск (или разд ел) поможет выбрать рабочий сегмент.

Пред ставим кластер с д вумя узлами. Если узел A вд руг перестал получать пакеты с узла B, причин этому может быть несколь ко: узел B вышел из строя; произошла ошибка на уровне сетевого коммутатора или шлюза; ошибка сетевого ад аптера узла A; узел B просто силь но загружен (что не исключено в боль ших кластерах или при нестабиль ном сетевом соед инении).

–  –  –

Узел A не знает, заключается ли причина в узле B или в нем самом. В резуль тате оба узла могут попытать ся изолировать д руг д руга.

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

В кластере с д вумя узлами кворумный д иск выступает в роли арбитра: если узел успешно записывает д анные на кворумный д иск и у него есть д оступ к сети, он получает д ополнитель ный голос. Узел, набравший мень ше голосов, буд ет отключен.

Если же узел д ействитель но вышел из строя, он потеряет свой голос, и его можно буд ет изолировать.

Под робную информацию о кворумных д исках можно найти в руковод стве Администрирование кластера.

2.1.2. Арбит ражные алгорит мы Арбитражные алгоритмы исполь зуют эвристические правила д ля проверки работоспособности узлов.

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

Конечно, может оказать ся так, что оба узла успешно под ключаются к маршрутизатору, — именно поэтому необход имо верно настроить правила изоляции.

Д ругие алгоритмы исполь зуют общий разд ел (кворумный д иск). Например, clumanager 1.2.x в Red Hat Cluster Suite 3 не ограничивал работу узлов д аже при отсутствии под ключения к сети при условии, что они могли взаимод ействовать через общий разд ел.

Более сложные схемы, такие как QD isk (в составе linux-cluster), позволяют настроить эвристические правила д ля отд ель ных узлов. Под робную информацию можно найти на справочной странице qdisk(5).

У CMAN нет собственных арбитражных алгоритмов, но он может исполь зовать внешние API, что позволит зарегистрировать кворумное устройство или получить д оступ к исход ному код у QD isk.

Арбитражный алгоритм требуется:

В схемах с д вумя узлами, если сетевой путь к устройству изоляции отличается от пути к кластеру.

В схемах с д вумя узлами, гд е изоляция неисправных узлов осуществляется на уровне коммутаторов (особенно с резервированием SCSI).

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

Red Hat Ent erprise Linux 6 High Availabilit y Глава 3. RGManager RGManager — менед жер кластерных ресурсов, отвечающий за настройку, управление и восстановление групп ресурсов, также называемых сервисами. Группа ресурсов пред ставляет собой д ревовид ную структуру, связи в которой построены по принципу семейных взаимосвязей.

RGManager включает собственные инструменты д ля конфигурации и мониторинга сервисов.

Так, в случае отказа узла RGManager сможет перенести сервис на д ругой узел с минималь ными помехами д ля рабочего процесса. Д ополнитель но можно опред елить под множество узлов, на которых буд ет работать сервис, — например httpd привязать к од ной группе узлов, а mysq l — к д ругой.

В этой главе обсужд аются основные понятия и рабочие процессы RGManager:

Резервный д омен — под множество узлов, на которых может работать кластерный сервис.

Сервисная политика — правила запуска и восстановления сервисов.

Д ерево ресурсов — иерархическая структура ресурсов, опред еляющая поряд ок их запуска и остановки.

Управление сервисами — управляющие команд ы, изменяющие состояние сервиса.

Управление виртуаль ными машинами — особенности управления виртуаль ными машинами в кластере.

Команд ы управления ресурсами — команд ы агентов, которые исполь зует RGManager, и их настройка в cl uster. co nf.

Сценарии событий — если станд артные сервисные политики rgmanager вас не устраивают, их можно ад аптировать при помощи сценариев.

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

Повед ение д омена опред еляется несколь кими характеристиками:

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

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

Неограниченный д омен (по умолчанию) — сервис может работать на любом узле кластера, но пред почтение буд ет отд авать ся узлам в д омене. Если сервис выполняется за пред елами д омена, и в это время в д омене появился свобод ный узел, он буд ет перенесен на этот узел (это повед ение можно отключить, установив флаг «nofailback»).

Упоряд оченный д омен — позволяет опред елить пред почтитель ный поряд ок выбора узлов.

Это означает, что при активации узла A, имеющего более высокий приоритет по сравнению

–  –  –

с узлом B, сервис, работающий на узле B, буд ет перенесен на узел A. Таким образом, сервис всегд а буд ет работать на узле с наивысшим приоритетом.

Неупоряд оченный д омен (по умолчанию) — сервис может работать на любом узле в д омене без каких-либо пред почтений.

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

Флаги «ordering», «restriction», «nofailback» помогают созд ать гибкие комбинации д ля контроля повед ения сервисов при любых обстоятель ствах.

3.1.1. Примеры д оменов В качестве примера рассмотрим кластер из несколь ких узлов: {A, B, C, D, E, F, G}.

–  –  –

Флаг «nofailback» не установлен: изначаль но сервис S буд ет запущен на узле A, так как он имеет наивысший приоритет. Если же сервис выполняется на узле C, и в это время узел A снова стал д оступен — он буд ет перенесен с C обратно на А. Если все три узла отключены, S не сможет прод олжить работу.

Флаг «nofailback» установлен: если сервис выполняется на узле C, и в это время узел A становится д оступен — сервис останется на C. Если же C выйд ет из строя, сервис буд ет восстановлен на узле A. Если все три узла отключены, S не сможет прод олжить работу.

–  –  –

Д ля работы сервиса, закрепленного за этим д оменом, д олжен быть д оступен хотя бы од ин узел (например, B). Под ключение узлов A и С никак не повлияет на работу сервиса, и он прод олжит работу на узле B.

–  –  –

Флаг «nofailback» не установлен: изначаль но сервис S буд ет работать на узле А, так как он имеет наивысший приоритет. Если А нед оступен, буд ет выбран узел B, и наконец — С. Если узел А снова станет д оступен, сервис буд ет перенесен с С обратно на А. Если отключены все три узла, буд ет выбран любой д ругой узел за пред елами д омена.

Флаг «nofailback» установлен: S изначаль но буд ет работать на узле с наивысшим приоритетом. Если узел А нед оступен, буд ет выбран узел B, и наконец — С. Если позд нее узел A снова станет д оступен, сервис не буд ет переносить ся обратно и останется на узле С.

–  –  –

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

3.2. Сервисная полит ика Правила запуска сервисов на узлах кластера опред еляются сервисной политикой RGManager.

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

Привед енные зд есь правила также применимы к ресурсам виртуаль ных машин.

3.2.1. Запуск сервиса По умолчанию сервисы запускаются при запуске rgmanager.

auto start (по умолчанию) — запуск сервиса при запуске rgmanager. Нулевое значение отключит сервис.

3.2.2. Возобновление работ ы Эта политика опред еляет повед ение сервиса в случае сбоя узла.

restart (по умолчанию) — перезапуск на том же узле. Если не уд алось, сервис буд ет перенесен на д ругой узел (см. rel o cate).

rel o cate — запуск на д ругом узле. Если не уд алось, сервис буд ет остановлен.

–  –  –

restart-d i sabl e — попытка перезапуска сервиса с отключением в случае неуд ачи.

3.2.3. Парамет ры перезапуска

Д ля политики перезапуска можно настроить д ополнитель ные параметры:

max_restarts — максималь ное число попыток, после чего сервис буд ет перенесен на д ругой узел.

restart_expi re_ti me — время, на протяжении которого rgmanager буд ет пытать ся перезапустить сервис.

Вместе эти значения контролируют число попыток на протяжении зад анного период а времени.

service name="myservice" max_restarts="3" restart_expire_time="300"...

...

/service В этом примере rgmanager попытается перезапустить сервис три раза в течение 5 минут. После четвертой попытки, которая буд ет пред принята по истечении 300 секунд, сервис буд ет восстановлен на д ругом узле.

–  –  –

Д ерево ресурсов пред ставляет собой XML-пред ставление с корневым элементом service.

Еще раз напомним, что в этом руковод стве термины «д ерево ресурсов», «группа ресурсов»

и «сервис» являются взаимозаменяемыми. С точки зрения rgmanager, д ерево пред ставляет собой ед иный объект, элементы которого запускаются на од ном узле.

В привед енном примере fs name=" myfs"... и ip address=" 10.1.1.2".../ расположены на од ном уровне иерархии.

fs name=" myfs"... является род ителем script name=" script_child" /.

script name=" script_child" / является потомком fs name=" myfs"....

3.3.1. Взаимосвязи и поряд ок запуска ресурсов

Правила взаимоотношений межд у род ителями и потомками д оволь но просты:

Род итель ские ресурсы запускаются перед потомками.

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

Из вышесказанного след ует, что потомки полность ю зависят от род итель ских ресурсов.

При оценке состояния ресурса учитывается состояние его потомков.

3.4. Управление сервисами Ниже обсужд аются операции управления кластерными сервисами.

3.4.1. Команд ы управления сервисами Управление сервисами осуществляется при помощи несколь ких простых команд. Обратите внимание, что команд а mi g rate применима толь ко к виртуаль ным машинам.

enabl e — запуск сервиса в соответствии с сервисной политикой. Если не зад ан ни пред почтитель ный узел, ни резервный д омен, сервис буд ет запущен на том же узле, гд е работает cl usvcad m. Если попытка запуска завершилась неуд ачей, буд ет инициирована операция переноса (см. rel o cate).

d i sabl e — остановка. Это ед инственно д оступное д ействие д ля сервисов в состоянии failed.

rel o cate — перенос сервиса на д ругой узел. Д ополнитель но можно опред елить пред почтитель ный узел. Если пред почтитель ный узел нед оступен, буд ет выбран д ругой узел. Если не уд алось возобновить работу сервиса на д ругих узлах, он буд ет перезапущен на исход ном узле. Если и эта попытка завершилась неуд ачей, сервис буд ет остановлен.

sto p — остановка сервиса с переход ом в состояние stopped.

Red Hat Ent erprise Linux 6 High Availabilit y mi g rate — миграция виртуаль ной машины на д ругой узел. Если миграция завершилась неуд ачей, виртуаль ная машина может остать ся в состоянии started на исход ном узле или перейти в состояние failed.

3.4.1.1. Freeze Чтобы минимизировать простои при обновлении rg manag er, CMAN и д ругих серверных программ, сервис можно временно заморозить.

Например, чтобы провести плановое обслуживание базы д анных, можно заморозить сервис, остановить базу д анных, выполнить работы по обслуживанию, перезапустить базу д анных и возобновить работу сервиса.

3.4.1.1.1. Хар акт ер и ст и ки з амо р о женно го сер ви са проверка состояния отключена;

операции запуска не выполняются;

операции остановки не выполняются;

операции переноса межд у узлами не выполняются.

–  –  –

Ниже привед ены правила, несоблюд ение которых может привести к переносу ресурсов на разные узлы.

Не останавливайте все экземпляры rgmanager при наличии замороженных сервисов (исключение составляет перезагрузка узлов перед перезапуском rgmanager).

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

3.4.2. Сост ояние сервиса Ниже привед ен список возможных состояний сервисов под управлением RGManager.

–  –  –

fai l ed — сервис переход ит в нерабочее состояние при неуд ачной попытке остановки. Из этого состояния его вывед ет толь ко команд а d i sabl e. Прежд е чем его полность ю отключить, ад министратор д олжен буд ет освобод ить исполь зуемые им ресурсы (отключить файловые системы и т.п.) sto pped — обычно сервис останавливается с цель ю проверки его состояния перед перезапуском на д ругом узле. Это временное состояние, которое может контролировать ся ад министратором.

reco veri ng — означает, что кластер пытается восстановить сервис. Ад министратор может отключить сервис, чтобы его не восстанавливать.

started — сервис запущен. Команд ы rel o cate, sto p, d i sabl e и mi g rate могут изменить это состояние.

–  –  –

Состояние started включает промежуточные этапы starti ng и sto ppi ng.

3.5. Управление вирт уальными машинами RGManager исполь зует несколь ко д ругой под ход к управлению виртуаль ными машинами по сравнению с д ругими кластерными сервисами.

3.5.1. Управляющие операции Если виртуаль ные машины созд аются как кластерные ресурсы, то и управлять ими след ует при помощи clusvcadm или д ругих кластерных утилит. Станд артные операции:

запуск;

остановка;

проверка состояния;

перенос;

восстановление.

Глава 7, Виртуализация в кластере сод ержит более под робную информацию.

3.5.2. Миграция Миграция минимизирует простои при переносе виртуаль ных машин межд у узлами, так как их не над о буд ет останавливать и снова перезапускать. Эта операция уникаль на д ля виртуаль ных машин.

RGManager под д ерживает оба метод а миграции:

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

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

Выбор метод а зависит от требований производ итель ности: если при остановке виртуаль ной машины процесс миграции занимает 8 секунд, то во время живой миграции машина буд ет работать, но ее производ итель ность снизится на 29 секунд.

Виртуаль ную машину можно включить как компонент сервиса, но тогд а операция миграции буд ет нед оступна.

Д ополнитель но: миграция виртуаль ных машин на базе KVM требует тщатель ной конфигурации ssh.

3.5.3. Особенност и работ ы вирт уальных машин под управлением RGManager Д алее обсужд аются метод ы оптимизации управления виртуаль ными машинами в RGManager.

3.5.3.1. Со гласо вание со сто яния виртуальных машин Если cl usvcad m попытается запустить виртуаль ную машину, которая уже выполняется, rgmanager установит д ля нее статус started.

Если д ля миграции машины исполь зовались не кластерные утилиты, а vi rsh, rgmanager установит д ля нее статус started.

–  –  –

RGManager не пред упрежд ает о выполнении разных экземпляров од ной виртуаль ной машины на разных узлах.

3.5.3.2. Вре ме нные д о ме ны libvirt RGManager под д ерживает временные д омены libvirt, что позволяет созд авать и уд алять виртуаль ные машины на лету, снижая вероятность многократного запуска од ной и той же машины не кластерными утилитами напод обие vi rsh.

Чтобы не синхронизировать /etc/l i bvi rt/q emu вручную на кажд ом узле, скопируйте XMLописания д оменов в файловую систему кластера.

3.5.3.2.1. Д р уги е о со б енно ст и упр авлени я Д обавление и уд аление виртуаль ных машин из cl uster. co nf не означает их автоматический запуск и остановку.

Выбор более под ход ящего узла происход ит во время миграции, что помогает сократить простои.

3.5.4. Непод д ерживаемые событ ия

RGManager не под д ерживает:

Изменение конфигурации и состояния виртуаль ных машин не кластерными утилитами, такими как vi rsh и xm. Операции проверки состояния (vi rsh l i st, vi rsh d umpxml и т.п.) разрешены.

–  –  –

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

3.6. Команд ы управления ресурсами

Агенты ресурсов д олжны под д ерживать команд ы:

start — запуск ресурса;

sto p — остановка ресурса;

status — проверка состояния;

metad ata — возвращает метад анные XML агента OCF.

3.6.1. Код ы возврат а Спецификация OCF под д ерживает целый набор код ов возврата, но д ля rgmanager актуаль ны толь ко д ва:

–  –  –

Если команд а sto p вернула ненулевое значение, сервис перейд ет в состояние fai l ed, из которого его над о буд ет вывести вручную.

Red Hat Ent erprise Linux 6 High Availabilit y Глава 4. Изоляция узлов Изоляция узла (англ. fencing) — отключение неисправного узла от кластерного хранилища с цель ю под д ержки целостности д анных. Д о тех пор пока узел не буд ет благополучно изолирован, все операции ввод а-вывод а в кластере буд ут приостановлены. Это позволяет снизить вероятность поврежд ения д анных в хранилище. Изоляцию узла провод ит специаль ный д емон fenced.

Как толь ко CMAN обнаружит сбой узла, он сообщит об этом д ругим кластерным под системам, в том числе fenced, который тут же изолирует узел. Д ругие под системы буд ут д ействовать в соответствии с ситуацией — так, D LM и GFS2 приостановят работу д о тех пор, пока fenced не сообщит об успешном отключении узла, после чего D LM освобод ит его блокировки, GFS2 восстановит журнал — и они прод олжат работу.

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

Red Hat High Availability под д ерживает разные способы изоляции:

Отключение питания — исполь зует контроллер питания д ля обесточивания проблемного узла.

Отключение от хранилища — закрывает порт Fibre Channel межд у узлом и хранилищем.

Д ругое оборуд ование д ля ограничения ввод а-вывод а и отключения питания: IBM BladeCenter, PAP, D RAC/MC, HP ILO, IPMI, IBM RSA II и пр.

Рисунок 4.1, «Отключение питания» д емонстрирует пример, в котором программа изоляции на узле A связывается с контроллером, который выключит узел D.

Рисунок 4.2, «Отключение от хранилища» рассматривает ситуацию, в которой коммутатор Fibre Channel закроет порт д ля узла D, тем самым отключив его от хранилища.

–  –  –

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

Если компь ютер оснащен д вумя источниками питания, д ля его изоляции над о буд ет зад ействовать д ва устройства (см. Рисунок 4.3, «Изоляция узла с д вумя источниками питания»). Аналогично, если узел исполь зует несколь ко маршрутов д ля под ключения к хранилищу, над о буд ет настроить по од ному устройству изоляции на кажд ый маршрут (см.

Рисунок 4.4, «Изоляция узла с д вумя соед инениями Fibre Channel»).

–  –  –

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

Под робную информацию можно найти в руковод стве Администрирование кластера.

–  –  –

Глава 5. Управление блокировками Синхронизация д оступа компонентов кластерной инфраструктуры к общим ресурсам осуществляется с помощь ю блокировок.

В кластере Red Hat эти функции выполняет механизм распред еленного управления блокировками (D LM, D istributed Lock Manager).

Менед жер блокировок регулирует д оступ кластерному хранилищу (например, GFS2), пред отвращая несогласованное изменение д анных разными узлами.

D LM работает на всех узлах кластера и реализует распред еленный механизм управления блокировками. GFS2 исполь зует D LM д ля синхронизации д оступа к файловой системе, CLVM — д ля синхронизации обновлений томов LVM, а rg manag er — д ля согласования состояний сервисов.

5.1. Мод ель блокирования DLM Мод ель блокирования D LM пред усматривает целый набор режимов блокировки д ля синхронной и асинхронной обработки запросов. Ресурсы могут блокировать ся од ним процессом монополь но или несколь кими процессами в совместном режиме.

D LM может блокировать файлы, структуры д анных, базы д анных, исполняемые процед уры и д ругие объекты. Размер объекта опред еляет степень д етализации — например, блокирование отд ель ных записей в базе д анных обеспечивает более тонкую д етализацию по сравнению с блокированием всей базы д анных.

D LM под д ерживает:

6 режимов блокировки в зависимости от уровня д оступа;

изменение режимов блокировки;

синхронную обработку запросов блокировки;

асинхронную обработку;

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

D LM исполь зует собственные механизмы д ля согласования блокировок межд у узлами, их восстановления при сбое узла и переноса блокировок на узел при его под ключении к кластеру.

Так как D LM интегрируется в существующую кластерную инфраструктуру, он пред ъявляет к ней собственные требования:

Под контроль ный узел д олжен вход ить в состав кластера.

В кластере д олжен быть набран необход имый кворум.

D LM д олжен иметь возможность обращать ся к узлу по IP-ад ресу. Обычно д ля взаимод ействия межд у узлами D LM исполь зует TCP/IP, что наклад ывает опред еленные ограничения и требует, чтобы узел имел толь ко од ин IP-ад рес. Чтобы разрешить узлам иметь несколь ко IP-ад ресов, д ля D LM вместо TCP/IP можно настроить SCTP.

При выполнении вышеперечисленных условий D LM сможет работать в любых кластерных окружениях с открытым и закрытым код ом. Од нако над о учитывать, что в разных окружениях тестирование D LM провод ится в разных объемах, и это тоже может повлиять на принятие окончатель ного решения.

Red Hat Ent erprise Linux 6 High Availabilit y

5.2. Сост ояние блокировки

Состояние блокировки отражает текущую стад ию обработки запроса блокировки:

Установлена — блокировка установлена.

Изменение режима — клиент пытается изменить режим блокировки, но новый режим не совместим со старым.

Отказ — не уд алось установить блокировку вслед ствие конфликта с существующей блокировкой.

Состояние блокировки выбирается в зависимости от запрашиваемого режима и текущих блокировок ресурса д ругими процессами.

–  –  –

Глава 6. Конфигурация и администрирование кластера Настройки кластера хранятся в файле /etc/cl uster/cl uster.

co nf в формате XML, который сод ержит несколь ко частей:

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

Узлы кластера — д ля кажд ого узла опред еляется имя, ид ентификатор, число голосов кворума и метод изоляции узла.

Устройства изоляции — параметры устройств опред еляются их типом, например д ля внешнего блока питания над о буд ет указать имя, IP-ад рес, логин и пароль.

Ресурсы — список ресурсов д ля созд ания кластерных сервисов. Эта секция сод ержит опред еления резервных д оменов и ресурсов (например, IP-ад рес или файловые системы).

Проверка формата осуществляется в соответствии со схемой /usr/share/cl uster/cl uster. rng при запуске кластера и перезагрузке конфигурации. С помощь ю команд ы ccs_co nfi g _val i d ate это можно сд елать в любое время.

Описание схемы с комментариями можно найти в /usr/share/d o c/cmanX. Y. ZZ/cl uster_co nf. html, например: /usr/share/d o c/cmancl uster_co nf. html.

В ход е проверки буд ут выявлены ошибки:

форматирования XML;

параметров конфигурации;

значений параметров.

6.1. Сред ст ва ад минист рирования класт ера Red Hat High Availability пред оставляет несколь ко инструментов д ля управления кластерами.

C o n g a — многофункциональ ный комплект д ля настройки и управления кластерами Red Hat. За под робной информацией обратитесь к руководству по настройке и управлению Red Hat High Availability.

Lu ci — программный сервер д ля централизованного управления кластерами.

R icci — агент, который работает на всех под контроль ных узлах и синхронизирует кластерную конфигурацию.

Начиная с Red Hat Enterprise Linux 6.1 управление кластерами Red Hat может осуществлять ся с помощь ю команд ы ccs. За под робной информацией обратитесь к д окументу Администрирование кластера.

–  –  –

system-co nfi g -cl uster был исключен из RHEL 6.

Red Hat Ent erprise Linux 6 High Availabilit y Глава 7. Виртуализация в кластере На базе отказоустойчивого кластера Red Hat Enterprise Linux 6 можно строить комплексные решения, объед иняя его с технологией виртуализации. В этой главе обсужд аются д ва варианта виртуализации на основе высокод оступных решений Red Hat Enterprise Linux.

В первом случае виртуаль ные машины созд аются на узлах отказоустойчивого кластера RHEL.

Виртуаль ными машинами, как и д ругими кластерными ресурсами, буд ет управлять rg manag er. Во втором случае виртуаль ные машины сами объед иняются в кластер.

Виртуаль ные машины как кластерные ресурсы Кластеры виртуаль ных машин

7.1. Вирт уальные машины как класт ерные ресурсы Red Hat High Availabilitу и RHEV пред оставляют механизмы д ля обеспечения непрерывного д оступа к виртуаль ным машинам, которые созд аются как кластерные ресурсы.

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

Д ля физических серверов и виртуаль ных машин над о учесть след ующее:

Д ля кластера с боль шим числом узлов, на базе которых планируется созд ать боль шое число виртуаль ных машин, RHEV сможет пред ложить более гибкие алгоритмы д ля размещения виртуаль ных машин в зависимости от процессорных ресурсов, памяти и уровня нагрузки сервера.

При наличии неболь шого числа узлов, на базе которых созд ается ограниченное число виртуаль ных машин, лучше выбрать Red Hat High Availability в силу его облегченной инфраструктуры. Д ело в том, что д ля созд ания д аже самой простой схемы RHEV потребуется как минимум 4 узла: д ва узла д ля обеспечения непрерывного д оступа к серверу RHEVM и д ве платформы виртуализации.

На самом д еле, нет четких правил, пред писывающих, какое именно число узлов считается д остаточным д ля выбора RHEV. При этом след ует помнить, что HA-кластер может сод ержать не боль ше 16 узлов. В любом случае, архитектура любого кластера, сод ержащего более 8 узлов, д олжна быть официаль но од обрена Red Hat.

Д ля виртуаль ных машин над о отметить след ующее:

Если службы виртуаль ных машин обращаются к общей инфраструктуре, можно выбрать и RHEL HA, и RHEV.

Если необход имо обеспечить непрерывный д оступ к ограниченному набору критических служб в виртуаль ной системе, можно выбрать и RHEL HA, и RHEV.

Д ля созд ания инфраструктуры, ориентированной на быструю установку виртуаль ных машин, лучше выбрать RHEV.

RHEV д опускает д инамическое изменение структуры кластера и облегчает д обавление новых виртуаль ных машин.

Red Hat High Availability не облад ает такой гибкость ю — кластер созд ается с фиксированным числом виртуаль ных машин, которое не рекоменд уется менять.

Red Hat High Availability не под ход ит д ля созд ания облачных схем в силу его статической

–  –  –

конфигурации и ограниченного числа узлов (не боль ше 16).

RHEL 5 под д ерживает д ве платформы виртуализации: Xen (впервые пред ставлен в RHEL 5.0) и KVM (д обавлен в RHEL 5.4).

RHEL 6 под д ерживает толь ко KVM.

Кластер RHEL 5 Advanced Platform под д ерживает и Xen, и KVM.

В отказоустойчивом кластере RHEL6 в качестве гипервизора может исполь зовать ся KVM.

Д алее перечислены возможные варианты развертывания виртуаль ных машин в кластерных схемах Red Hat.

На серверах RHEL 5.0+ в кластере RHEL Advanced Platform под д ерживается гипервизор Xen;

На серверах RHEL 5.4 в кластере RHEL Advanced Platform была д обавлена эксперименталь ная под д ержка виртуаль ных машин KVM;

Версии RHEL 5.5+ полность ю под д ерживают виртуаль ные машины KVM.

RHEL 6.0+ позволяет настроить виртуаль ные машины KVM как кластерные ресурсы в RHEL 6 High Availability;

RHEL 6.0+ боль ше не под д ерживает Xen, поэтому RHEL 6 High Availability тоже не буд ет работать с виртуаль ными машинами Xen.

–  –  –

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

https://access.redhat.com/kb/docs/D OC-46375 Прежд е чем настроить гостевую систему как кластерный сервис, убед итесь, что она под д ерживается гипервизором узла. Xen и KVM под д ерживают RHEL (RHEL3, RHEL4, RHEL5) и некоторые ред акции Microsoft Windows. Полный список под д ерживаемых операционных систем можно найти в д окументации RHEL.

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

Д о RHEL 5.3 д ля управления гостевыми системами Xen (domU) rg manag er исполь зовал внутренние механизмы Xen.

В RHEL 5.4 эти функции стал выполнять libvrit, пред оставляя ед иный интерфейс д ля управления и Xen, и KVM. Послед ующие версии RHEL включают множество обновлений, поэтому прежд е чем приступить к конфигурации сервисов под управлением Xen, рекоменд уется обновить программное обеспечение серверов хотя бы д о RHEL 5.5.

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

Прежд е чем развернуть кластер, след ует установить послед ние обновления и исправления RHEL.

Red Hat Ent erprise Linux 6 High Availabilit y

Виртуаль ные машины д олжны наход ить ся под управлением од ного и того же гипервизора:

Xen или KVM.

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

Не след ует запускать и останавливать виртуаль ные машины, под контроль ные rg manag er, при помощи команд xm и l i bvi rt (vi rsh, vi rsh-manag er), так как это д елается в обход стека управления кластером.

Имена виртуаль ных машин д олжны быть уникаль ными в пред елах кластера. Li bvi rtd проверяет имена отд ель но на кажд ом узле, но не во всем кластере. Если вы собираетесь прод ублировать виртуаль ную машину вручную, не забуд ь те изменить имя в ее файле конфигурации.

7.2. Класт еры вирт уальных машин В этой схеме виртуаль ные машины сами объед иняются в отказоустойчивый кластер.

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

Д алее обсужд аются особенности под д ержки виртуаль ных кластеров на платформах RHEL. В привед енных примерах гостевые системы RHEL 6 объед иняют функции High Availability с д ополнением Resilient Storage, пред оставляющим инструменты д ля повышения отказоустойчивости под системы хранения д анных (GFS2, clvmd, cmirror).

На платформах RHEL 5.3+ Xen можно построить виртуаль ные кластеры с операционными системами RHEL 5.3+.

Изоляция неисправных узлов в таком кластере осуществляется при помощи fence_xvm или fence_scsi.

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

Общее хранилище может быть построено на блочных устройствах iSCSI или Xen.

Платформы RHEL 5.5+ KVM не под д ерживают виртуаль ные кластеры.

Платформы RHEL 6.1+ KVM под д ерживают виртуаль ные кластеры с операционными системами RHEL 6.1+ и RHEL 5.6+.

В состав кластера могут вход ить и физические, и виртуаль ные узлы.

В кластерах RHEL 5.6+ изоляция неисправных узлов осуществляется с помощь ю fence_xvm или fence_scsi.

В кластерах RHEL 6.1+ изоляция узлов осуществляется с помощь ю fence_xvm (из пакета fence-vi rt) или fence_scsi.

Если д ля изоляции узлов исполь зуется агент fence_vi rt или fence_xvm, то на серверах RHEL 6.1+ KVM д олжен работать fence_vi rtd.

–  –  –

fence_vi rtd может работать в трех режимах:

В автономном режиме связи гостевых систем с сервером жестко опред елены, поэтому живая миграция невозможна.

Отслеживание живой миграции сред ствами Openais Checkpoint. Д ля этого необход имо, чтобы физические узлы были объед инены в кластер.

Отслеживание живой миграции сред ствами QMF (Qpid Management Framework) из пакета l i bvi rt-q pi d. Это не требует наличия кластера физических узлов.

Общее хранилище кластера может быть построено на блочных устройствах iSCSI или KVM.

На платформах RHEV-M (Red Hat Enterprise Virtualization Management) 2.2+ и 3.0 могут созд авать ся кластеры виртуаль ных машин RHEL 5.6+ и RHEL 6.1+.

Все гостевые операционные системы в кластере д олжны быть од ного типа: RHEL 5.6+ или RHEL 6.1+.

В состав кластера могут вход ить и физические, и виртуаль ные узлы.

За изоляцию узлов на платформе RHEV-M 2.2+ отвечает агент fence_scsi, на RHEV-M 3.0 — fence_scsi и fence_rhevm.

Д ля нормаль ной работы fence_scsi необход имо, чтобы серверы iSCSI под д ерживали алгоритмы постоянного резервирования SCSI-3. Эту информацию след ует заранее уточнить у производ ителя. Так, сервер iSCSI, вход ящий в станд артную поставку Red Hat Enterprise Linux, не под д ерживает постоянное резервирование SCSI-3 и, как след ствие, не сможет исполь зовать fence_scsi.

VMware vSphere 4.1, VMware vCenter 4.1, VMware ESX и ESXi 4.1 под д ерживают виртуаль ные кластеры с гостевыми операционными системами RHEL 5.7+ и RHEL 6.2+. VMware vSphere 5.0, vCenter 5.0, ESX и ESXi 5.0 тоже можно исполь зовать, но исход ная версия VMware vSphere 5.0 включает неполную схему WD SL, поэтому fence_vmware_so ap не буд ет работать в исход ной реализации. О том, как снять это ограничение, можно узнать из базы знаний Red Hat: https://access.redhat.com/knowledge/.

Все гостевые операционные системы в кластере д олжны быть од ного типа: RHEL 5.7+ или RHEL 6.1+.

В состав кластера могут вход ить и физические, и виртуаль ные узлы.

Д ля нормаль ной работы fence_vmware_so ap потребуется загрузить пакет с д ополнитель ными Pearl API с сайта VMware и установить его в гостевых системах RHEL.

В противном случае можно настроить изоляцию fence_scsi.

Общее хранилище может быть построено на RAW-д исках VMware и блочных устройствах iSCSI.

В виртуаль ных кластерах на базе VMware ESX изоляция узлов д олжна осуществлять ся сред ствами fence_vmware_so _ap или fence_scsi.

Виртуаль ные кластеры Hyper-V не под д ерживаются.

7.2.1. Fence_scsi и общее хранилище iSCSI Red Hat Ent erprise Linux 6 High Availabilit y Во всех перечисленных выше схемах на базе исход ных решений хранения д анных можно созд ать общее хранилище iSCSI и настроить агент изоляции fence_scsi.

fence_scsi изолирует вышед шие из строя узлы, отключая их д оступ к хранилищу путем уд аления их ключей регистрации с д исков. Д ля этого цели iSCSI д олжны под д ерживать постоянное резервирование iSCSI-3 и команд у " PREEMPT AND ABORT". Эту информацию след ует заранее уточнить у производ ителя.

Программное обеспечение сервера iSCSI в станд артной сборке RHEL не под д ерживает постоянное резервирование SCSI-3 и не сможет исполь зовать fence_scsi. Возможно, вы решите остановить ся на д ругих метод ах изоляции — fence__vmware или fence_rhevm.

Если на всех узлах виртуаль ного кластера настроен fence_scsi, то объед инять физические серверы (RHEL 5 Xen/KVM и RHEL 6 KVM) в кластер не обязатель но.

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

7.2.2. Общие рекоменд ации Как говорилось выше, прежд е чем развернуть виртуализацию в кластере, след ует обновить программное обеспечение серверов и гостевых систем, установив послед ние версии пакетов RHEL.

Виртуаль ными машинами в составе кластера д олжен управлять од ин гипервизор.

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

–  –  –

Если на кажд ом сервере размещается по д ва узла виртуаль ного кластера, то в случае его сбоя оба узла выйд ут из строя. Очевид но, что максималь ной над ежности можно д остичь, разместив кажд ый узел кластера на отд ель ном сервере, но это не является обязатель ным требованием.

Созд ание на од них и тех же физических узлах несколь ких кластеров, исполь зующих агенты изоляции fence_xvm/fence_xvmd и fence_vi rt/fence_vi rtd, не под д ерживается.

Од новременная работа независимых виртуаль ных кластеров в од ной группе физических серверов д опускается, если они исполь зуют общее хранилище iSCSI с агентом fence_scsi или VMware (ESX/ESXi и vCenter) с fence_vmware.

Созд ание независимых виртуаль ных машин наравне с виртуаль ным кластером на тех же физических серверах не воспрещается, но если серверы сами объед инены в кластер и од ин из них вышел из строя, он буд ет изолирован, а независимая виртуаль ная машина буд ет отключена.

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

Похожие работы:

«2 ОГЛАВЛЕНИЕ Оглавление 1. Общая характеристика программы повышения квалификации 1.1. Цель реализации программы повышения квалификации 1.2. Планируемые результаты обучения 1.3. Категория слушателей 1.4. Трудоемкость обучения 1.5. Форма аттестации 1.6. Форма обучения 2. Содержани...»

«HP Deskjet F2100 All-in-One series Справка Windows HP Deskjet F2100 All-in-One series Содержание 1 Справка аппарата HP Deskjet F2100 All-in-One series 2 Обзор аппарата HP All-in-One Содержание Описание аппарата HP All-in-One Кнопки панели управления Обзор индикаторов состояни...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное автономное образовательное учреждение высшего профессионального образования "Северный (Арктический) федеральный университет имени М.В. Ломоносова" УТВЕРЖДЕНО приказом ректора унив...»

«НАШИ ПАРТНЕРЫ Confidential and Proprietary.GLAM УНИКАЛЬНАЯ СЕТЬ БЛОГОВ И САЙТОВ В СФЕРЕ FASHION&BEAUTY 92 БЛОГЕРА Более 400 000 уников в блогах +2 700 000 уников в соцсетях Более просмотров страниц 14 ВИДЕОБЛОГЕРОВ GLAM Более 2 000 000 уников в YT РОССИЯ +2 800 000 уников в...»

«Приложение №5в к Порядку ТИПОВАЯ ФОРМА ГОСУДАРСТВЕННОГО КОНТРАКТА НА ПОСТАВКУ ТОВАРОВ (идентификационный код закупки ) г. Белград "_"_2016 г., именуем в дальнейшем "Заказчик", в лице _, действующего на основании _, с одной стороны, и, именуем в дальнейшем "Поставщик", в ли...»

«ОСОБЕННОСТИ РЕЧЕВОГО ПОРТРЕТА РЕДАКТОРА ГАЗЕТЫ "ЗАВТРА" А.А. ПРОХАНОВА Ардатова Екатерина Владимировна канд. филол. наук, доцент Санкт-Петербургского государственного университета, факультет международных отношений, 191060, РФ, г....»

«Invader Инструкция эксплуатации ВВЕДЕНИЕ Спасибо за приобретение радиоуправляемого вертолета Invader. Мы надеемся, что эта модель доставит Вам много удовольствия. Данный вертолет предназначен для широкого круга увлеченных моделистов с разным уровнем подгот...»

«М. Н. Винникова О РЕКОНСТРУКЦИИ СМЫСЛОВОГО ЗНАЧЕНИЯ И СПОСОБОВ НОШЕНИЯ ЖЕНСКИХ ГОЛОВНЫХ УБОРОВ ТУРОВЩИНЫ (по материалам белорусской коллекции МАЭ)1 Информация о предметах белорусского народного костюма в собрании Музея антропологии и этнографии им. Петра Великого, опубликованная в одном из сборников музея [Грысык 1992: 11...»

«mini-doctor.com Инструкция Фаспик гранулы для орального раствора с абрикос. вкус. по 400 мг (3 г) в пакете №30 ВНИМАНИЕ! Вся информация взята из открытых источников и предоставляется исключительно в ознакомительных целях. Фас...»

«WWF ВОЗДЕЙСТВИЕ ТРАЛОВОГО ПРОМЫСЛА НА ДОННЫЕ ЭКОСИСТЕМЫ БАРЕНЦЕВА МОРЯ И ВОЗМОЖНОСТИ СНИЖЕНИЯ УРОВНЯ НЕГАТИВНЫХ ПОСЛЕДСТВИЙ Мурманск Воздействие тралового промысла на донные экосистемы Баренцева моря и возможности снижения уровня негативных последствий – Мурманск. WWF. 2013. 52 c. В докладе...»

«Изменения условий приобретения бессрочных лицензий Autodesk® Вопросы и ответы для общего пользования Обновлено 1 июня 2015 г. Вносимые изменения С 1 февраля 2016 года продажа новых бессрочных лицензий для многих отдельных программных продуктов будет прекращена. Клиенты с действующими бессрочными лицензиям...»

«Болгарский язык с Яном Бибияном Елин Пелин Ян Бибиян. Неверо`ятните приключ`ения на едн`о хлап`е (Ян Бибиян. Невероятные приключения одного мальчугана) Книгу адаптировал Святослав Димитров bg_cons@abv.bg Метод чтения Ильи Франка ПОРТР`ЕТ (ПОРТРЕТ) В едн`о м`алко градч`е, (в одном маленьком городке) при едн...»

«Постинсультные состояния Гипертонический криз Внезапное значительное повышение артериального давления Симптомы: 1. Головная боль, тошнота, рвота, реже – угнетение сознания и судорожные припадки.2. Нарушения зрения, мелькание "мушек" перед гла...»

«НАУКОВЕ ПІЗНАННЯ: МЕТОДОЛОГІЯ ТА ТЕХНОЛОГІЯ 2(31) 2013 147 © Т. Н. Черопита инструментальная модель инновационного развития представлена как правильно выработанная система нормативного знания, регламентирующая практику решения намеченной проблемы. Раскрыта детерминирующая роль концептуальной модели по отношению к инс...»








 
2017 www.lib.knigi-x.ru - «Бесплатная электронная библиотека - электронные материалы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.