Кластерная организация сервера баз данных

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

В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc -
SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).

5.1.1. Аппаратная организация SPARCcluster PDB Server

В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000,
двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы-
компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые
подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо
SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно
достигать 32 (до 1 Тб дискового пространства). Каждый узел кластера - это многопроцессорный

компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или
автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами
продублированы.

Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

Рис. 1. Аппаратная организация SPARCcluster PDB Server (на
рисунке не показаны связи кластера с внешним миром)

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

Вся аппаратура устроена так, что допускает замену в горячем режиме, без остановки других

компонентов кластера.

5.1.2. Программная организация SPARCcluster PDB Server

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

Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.

Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock
Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая
блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки,
установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для
поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в
таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с
параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым
подсистемам.

Рис. 2. Программная организация SPARCcluster PDB Server
(узлы кластера работают под управлением ОС Solaris версии 2.4 или
выше)

Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой
экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе
узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не
означает краха всего сервера баз данных - сервер жив, пока работает хотя бы один менеджер
блокировок.

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

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

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

Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом:
консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает
централизованное оперативное управление всеми ресурсами кластера.

5.1.3. Нейтрализация отказа узла

Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из
отказов - отказа узла. Программное обеспечение предпринимает при этом следующие
действия:

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

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

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

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

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

Содержание раздела