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