Серверные кластеры

Объединение серверов в один ресурс происходит на уровне программных  протоколов.  
В отличие от аппаратного кластера, кластеры, организуемые программно: 
I) требуют наличия специального программного модуля (Cluster Manager), основной функцией которого является поддержание взаимодействия между всеми серверами — членами кластера: 

-   синхронизации данных между всеми серверами — членами кластера;

- распределение нагрузки (клиентских запросов) между серверами — членами кластера;

II)требуют от клиентского  программного обеспечения умения  распознавать сервер, представляющий  собой кластер серверов, и соответствующим  образом обрабатывать команды  от Cluster Manager; 

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

Классическая реализация самого простого кластера (если слово "простой" приемлемо к этим системам) изображена на рисунке.

Используется два абсолютно  идентичных сервера и общий дисковый RAID массив. Серверы и хранилище  должны удовлетворять определённым требованиям, а вся система должна пройти специальное многодневное тестирование, в ходе которого проверяются оба  сервера, RAID хранилище, и что самое  главное - наиболее редко возникаемые, но наиболее важные моменты работы кластера: отказ одной из нод и  переход выполняемых ею задач  на другую. Всё это происходит при  интенсивной нагрузке кластера, которую  обеспечивают не менее десяти компьютеров, эмулирующие запросы клиентов. Система  должна сохранять работоспособность  при выходе из строя одного любого компонента. Но на этом этапе часто  забывают о том, что UPS также может  выйти из строя. По этой причине следует  использовать как минимум два UPS-а (к каждому подключен один сервер и один блок питания дискового  хранилища).

Рассмотрим подробнее  как всё это работает на уровне ОС. Cluster service работает с ресурсами. Ресурсы  могут быть как физическими (сетевая  карта, жёсткий диск), так и логическими (IP адрес, сетевое имя, каталог с  общим доступом, приложение, экземпляр  базы данных). Каждым ресурсом кластера (сетевой интерфейс, общий жёсткий  диск, IP адрес, экземпляр базы данных) в любой момент времени владеет  и управляет только один сервер, остальные в это время не имеют доступа к этому ресурсу. Если какой-либо из серверов дал сбой, то ресурсы которыми он владел, перейдут другому серверу, и система (кластер) продолжит свою работу.

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

Для клиента работающего  с виртуальным сервером всё выглядет так, как будто он работает с отдельным "физическим" сервером, в то время  как виртуальный сервер работает на одной из нод кластера (и клиент не знает на какой именно).

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

Рассмотрим подробнее  процесс перехода ресурсов от одной  ноды к другой. Если провести аналогию с одиночным сервером, то ситуация будет примерно такая если бы сервер выключили, а затем он очень быстро загрузился (этот процесс может занять от нескольких секунд до нескольких минут).  
Приведём пример. На клиентской машине запущен Internet Explorer, Outlook и приложение работающее с MSSQL сервером. Нода, на которой работал Internet Information Server и MSExchange Server выходит из строя. С этого момента вы не можете обновлять данные в Internet Explorer, не можете получать и отправлять письма в Outlook-е, а с MSSQL сервером работаете как-будто ничего не произошло (он работает на другой ноде). Происходит переход ресурсов вышедшей из строя ноды на работающую. Как только этот процесс завершится, работоспособность Internet Explorer-а и Outlook-а восстанавливается.  
Рассмотрим другой пример, когда выходит из строя нода на которой работал MSSQL сервер. Как только произошел сбой, MSSQL сервер становится недоступным. После того как он восстановит своё функционирование на другой ноде, клиентское приложения может к нему обращаться. А дальше всё зависит от того как написано это приложение. Если оно устанавливает соединение с сервером в начале работы и в случае "обрыва" не пытается восстановить его, то прийдётся закрыть приложение и запустить его заново. Если же приложение не держит постоянной связи с базой или пытается установить связь заново в случае "обрыва", тогда, возможно, пользователь и вовсе не заметит, что что-либо произошло. Идеальным приложением в этом смысле является Internet Explorer: он устанавливает связь с сервером, делает запрос, получает данные и разрывает связь. Заметить, что с сервером что-либо случилось пользователь может только в том случае если сбой произойдёт в момент обработки запроса, или если он обратится к серверу до того как все ресурсы перешли на другую ноду.

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

Заключение

"Нужен ли нам кластер?". Если Вы когда либо зададите  себе этот вопрос, попробуйте  объективно ответить себе на  следующие вопросы: 

- Что будет если наш сервер вдруг выйдет из строя (речь идёт не о потере данных, а о временной неисправности)?

- Сколько нам стоит час простоя сервера?

- День простоя?

Здесь желательно учесть не только прямые потери, но и косвенные. После того как Вы ответите себе на эти вопросы, в 99% случаев решение  будет однозначным: "Это неоправданно дорого". И это правда. Девяноста  девяти процентам организаций кластеры не нужны. Затраты на IT должны облегчать  жизнь компании, а не разорять её. Использование кластера оправдано  только в том случае если стоимость  времени простоя системы соизмеримо с затратами на его построение.

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