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