Особенности работы с сервисами в серверных пулах

Начиная с версии Oracle Database 11.2 появилась новая концепция – серверные пулы (server pools). Работа с сервисами в серверном пуле имеет свои особенности, которые нужно учитывать.
Итак, серверный пул представляет собой группу серверов в кластере, объединенных в некоторое логическое понятие (пул). В кластере могут быть определены несколько серверных пулов. При создании пула указывается набор серверов, минимальное количество серверов в пуле, максимальное количество серверов в пуле и важность (приоритет) пула. Альтернативно, при создании пула можно указать перечень входящих в него узлов.

[oracle@rac2 ~]$ srvctl add srvpool -h

Adds a server pool to the Oracle Clusterware.

Usage: srvctl add srvpool -g  [-l ] [-u ] [-i ] [-n ""] [-f]
    -g      Server pool name
    -l      Minimum size of the server pool (Default value is 0)
    -u      Maximum size of the server pool (Default value is -1 for unlimited maximum size)
    -i      Importance of the server pool (Default value is 0)
    -n ""   Comma separated list of candidate server names
    -f      Force the operation even though some resource(s) will be stopped
    -h      Print usage

При необходимости в серверный пул можно добавлять серверы или же, наоборот, удалять серверы из пула. При создании БД с помощью Database Configuration Assistant [DBCA] определяется тип конфигурации этой БД:

• Admin-Management (экземпляры создаваемой БД будут жестко привязаны к узлам заданным при создании БД);
  
• Policy-Management (экземпляры создаваемой БД НЕ будут привязаны к конкретным узлам кластера, а будут выполняются на любом из серверов пула).

Рис. 1 Создание БД в серверном пуле
Идея серверных пулов состоит в отсутствии привязки ресурсов предоставляемых пользователю в кластере (приложения и базы данных) от конкретных физических серверов. Теперь при создании БД, в ней можно указывать не конкретные серверы, как это было раньше до версии 11.2, а серверный пул. При этом, в случае отсутствия серверного пула, можно сразу же его создать в DBCA. Также при этом задается количество экземпляров БД в пуле (cardinality). Если посмотреть экземпляры БД созданной в серверном пуле, можно увидеть ннтересную картину:

[oracle@rac2 ~]$ srvctl status database -d racdb
Instance racdb_1 is running on node rac2
Instance racdb_2 is running on node rac3
Instance racdb_3 is running on node rac4

Хорошо видно, что любой экземпляр может быть запущен на любом из узлов входящем в пул, и жестко не привязан к определенному узлу, как это было до версии 11.2. Как видите, теперь в локальном каталоге ORACLE_HOME узла не хранится информация об экземпляре. Информация о пулах и о конфигурац2ии БД теперь централизованно храниться в OCR. Управление серверными пулами и ресурсами в нем осуществляется Clusterware. Попробуем добавить сервер в пул, увеличив максимальное число узлов в пуле до 4-х (эксперимент проводился на 4-х узловом кластере):

[oracle@rac2 ~]$ srvctl modify serverpool -g main -u 4 -f
[oracle@rac2 ~]$ srvctl status database -d racdb
Instance racdb_4 is running on node rac1
Instance racdb_1 is running on node rac2
Instance racdb_2 is running on node rac3
Instance racdb_3 is running on node rac4

Автоматически на новом сервере был запущен новый экземпляр, при этом для него “на лету” были созданы undo-табличное пространство и redo-поток ! Понятно, что при использовании пулов для доступа к БД мы обязаны использовать Single Access Client Name [SCAN], поскольку заранее не знаем: на каких конкретно узлах будет выполняться тот или иной экземпляр БД. Данная технология в сочетании c делегированием DNS в домен кластера (Grid Naming Service) называется Grid Plug In Play [GPnP], и позволяет изменять состав серверного пула без необходимости изменения клиентских (файл tnsnames.ora) и сетевых (DNS-сервер) настроек.

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

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

• Uniform
• Singleton

Сервисы типа iniform одновременно могут выполняться на всех узлах серверного пула, типа singleton – в каждый момент времени выполняются только на одном экземпляре внутри пула. При создании сервиса с помощью утилиты srvctl, его тип задается с помощью ключа “–c” который может иметь значения UNIFORM для сервиса одновременно работающих на всех узлах пула :

[oracle@rac2 ~]$ srvctl add service -d racdb -s dss -c uniform
[oracle@rac2 ~]$ srvctl start service -d racdb -s dss
[oracle@rac2 ~]$ srvctl status service -d racdb -s dss
Service dss is running on nodes: rac1,rac2,rac3,rac4

Очевидно, что тип сервиса можно указывать только для Policy-Management БД. Если нужно гарантировать, чтобы сервис всегда работал только одном узле, то в значении ключа указывается SINGLETON:

[oracle@rac2 ~]$ srvctl add service -d racdb -s oltp -c singleton
[oracle@rac2 ~]$ srvctl start service -d racdb -s oltp
[oracle@rac2 ~]$ srvctl status service -d racdb -s oltp
Service oltp is running on nodes: rac1

В случае, если необходимо принудительно переместить сервис с одного узла на другой, точно также применяется команда relocate service утилиты srvctl, только вместо экземпляров указывается имена серверов (hostname):

[oracle@rac2 ~]$ srvctl relocate service -s oltp -d racdb -c rac1 -n rac2 -f
[oracle@rac2 ~]$ srvctl status service -d racdb -s oltp
Service oltp is running on nodes: rac2

Где:
- параметр –c определяет сервер, на котором нужно остановить сервис;
- параметр –t определяет сервер, на котором нужно запустить сервис.
- опциональный параметр –f определяет необходимость принудительно завершить все текущие сессии на узле заданном параметром -c, в случае его отсутствия все активные сессии продолжают свою работу, а новые будут создаваться только на узле заданном параметром –n.