Кластерные системы

Под кластерами традиционно понимается объединение не­скольких вычислительных систем (узлов), которые используются как единое целое для обеспечения доступа пользователей к прило­жениям, системным ресурсам и данным. В качестве узлов могут использоваться однопроцессорные, симметричные многопроцес­сорные машины и машины с массовым параллелизмом. Кластер­ные решения обеспечивают высокий уровень готовности: при вы­ходе из строя одного или даже нескольких узлов работа приложе­ний может быть продолжена на любых других узлах, входящих в состав кластера. При этом дополнительная нагрузка может быть равномерно распределена среди работающих узлов кластера. Вто­рой важной задачей, традиционно решаемой при помощи клас­терных технологий, является увеличение производительности сис­темы путем добавления в кластер новых узлов (процессоров, па­мяти, дисковых подсистем и т.д.). Для объединения узлов в клас­тер используются различные соединения. При этом линии связи, используемые для обслуживания внутренних потребностей клас­тера, называются частными, а соединения для подключения потре­бителей — общими. Очевидно, что кластерные решения идеально подходят для обеспечения высокой готовности. Первый — базовый уровень го­товности системы — может быть обеспечен при использовании от­дельных вычислительных систем, два других — готовность дан­ных и готовность приложений — только при кластерных решени­ях высокой готовности. При правильной организации такой тип кластера обеспечивает резервирование всех соединений между ком­понентами кластера: системами, дисковыми массивами и внешни­ми сетями. Кроме того, каждый компонент (процессорные моду­ли, карты памяти, блоки питания, диски и дисковые массивы, сете­вые интерфейсы и т.д.) дублируется или обеспечивает ту или иную степень резервирования. Выход любого компонента кластера ни­как не сказывается на работе кластера в целом. Сервисы данных, связанные с вышедшим из строя узлом, автоматически мигрируют на работоспособный узел, после чего происходит рестарт прило­жений. Все процессы по восстановлению работы приложений вы­полняются автоматически.

3.3.4.1. Концепция миграции приложений и ресурсов в кластере высокой готовности

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

Миграция приложения с основного сервера на резервный внут­ри кластера может занимать достаточно продолжительное время, в зависимости от самого приложения. Для сокращения этого вре­мени программное обеспечение настроено таким образом, чтобы локализовать сбой внутри сервера и предотвратить миграцию при­ложения на другой сервер в кластере. В качестве примера таких настроек, можно привести программное обеспечение Network Adapter Fail Over, которое обеспечивает автоматическое переклю­чение сетевых интерфейсов сервера в случае выхода из строя одно­го из сетевых адаптеров; возможности динамического реконфигу-рирования и замены компонентов (процессоров, оперативной па­мяти, контроллеров ввода-вывода) без остановки сервера и без пре­кращения работы и/или миграции приложения; использование альтернативных путей доступа к устройствам.

Помимо мониторинга состояния сервера и хранилищ данных, кластерное ПО осуществляет постоянный контроль состояния само­го приложения, предотвращая ситуации прекращения работы в слу­чае внутренней ошибки, «зависания» и пр. Для этого существуют спе­циальные программные средства, разработанные для стандартных приложений: Oracle, Informix, Sybase, Netscape, NFS, SAP и др.

3.3.4.2. Типы кластеров

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

1. Пассивный резервный сервер. В данной конфигурации (рис. 3.13, а) все сервисы файлов, печати и приложений выполняются на основ­ ном сервере, в то время как резервный сервер не несет никакой нагрузки и находится в режиме ожидания. Связь между серверами поддерживается при помощи специального соединения, по кото­
рому каждый из серверов обменивается служебной информацией и определяет работоспособность остальных узлов кластера (как в целом, так и отдельных подсистем и компонентов). В случае неис­правности на первом сервере резервный сервер запускает у себя все неисправные приложения и начинает предоставлять пользова­телям те сервисы, которые недоступны на основном сервере.

2. Активный резервный сервер. Основное отличие данной конфигурации от предыдущей в том, что вычислительные ресурсы ре­зервного сервера используются в повседневной работе. Преиму- щество такого подхода состоит в том, что пользователь имеет в своем распоряжении высокодоступную систему (сервер продубли­рован) и в то же время может использовать все вычислительные ресурсы кластера. Это позволяет уменьшить общую стоимость системы, отнесенную к единице вычислительной мощности Можно выделить три основных подхода при построении кла­стеров с активным резервным сервером:

—полное дублирование серверов;

—без разделяемых ресурсов;

—полностью разделяемые ресурсы.

Один из подходов заключается в полном дублировании серве­ров (рис. 3.13, б) с их собственными отдельными дисками. При этом возникает необходимость постоянно копировать данные с основ­ного сервера на резервный.

Несмотря на то что данный подход обеспечивает высокодос­тупное решение, он имеет ряд недостатков:

—необходимость постоянно копировать данные означает, что часть вычислительных и сетевых ресурсов будет непрерывно ис­пользоваться на синхронизацию;

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

Конфигурация с двумя дублированными серверами имеет так­же некоторые преимущества:

—в подобном кластере обеспечена балансировка нагрузки;

—благодаря возможности географически разнести узлы клас­тера структура устойчива к катастрофам.

При подходе без разделения ресурсов (рис. 3.13, в), два серве­ра соединены с одним дисковым массивом, но каждый сервер уп­равляет своим набором дисков. В случае возникновения неисправ­ности на одном из серверов, оставшийся сервер берет на себя уп­равление его дисками. Такой метод устраняет необходимость в по­стоянной синхронизации данных между серверами и тем самым высвобождает дополнительные вычислительные и сетевые ресур­сы. В такой конфигурации обычно используются накопители с применением технологии RAID.

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