Client Load Balancing in RAC 11.2 (Update 1 - LOAD_BALANCE=YES нужен!)

Возникает много вопросов по поводу балансировки на стороне клиента в Real Application Cluster 11.2. Ведь с использованием Single Client Access Name ее как-бы нет, поскольку в tnsnames.ora на клиенте указывается лишь один адрес.

Небольшой экскурс в историю. До версии 11.2 в описании алиса в файле tnsadmin.ora на клиентской машине, то есть на компьютере c установленным ПО Oracle Client, и на котором работает приложение, перечислялись все узлы кластера, а также указывался параметр LOAD_BALANCE=TRUE|ON|YES. Например (для 4-х узлового кластера):

OLTP = 
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.us.oracle.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.us.oracle.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac3-vip.us.oracle.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac4-vip.us.oracle.com)(PORT = 1521))
    (LOAD_BALANCE = YES)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oltp.us.oracle.com)
    )
  )

При подключении, Oracle Client случайным образом выбирает один из адресов (в вышеописанном примере - один из четырех) и делает по нему попытку подключения.
В случае сбоя, например если выбранный узел кластера в настоящий момент неработоспособен, процесс подключения повторяется среди оставшихся узлов.
Стоить отметить, что этот алгоритм полностью прозрачен для приложения, то есть оно не подозревает, что работает балансировка, а получает соединение так, как если бы это был обычный некластерный сервер БД (Single Instance).

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

Так было до версии 11.2, теперь же нужно указывать всего лишь один, так называемый scan-адрес

OLTP=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan.cluster.us.oracle.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oltp.us.oracle.com)
    )
  )

Обратите внимание, что в имени появился новый поддомен (subdomain) кластера, но об этом в следующей серии ...

Получается, что теперь серверной балансировки нет, и мы сразу попадаем на scan-листенер ?
Нет - это не так, поскольку имени scan-адреса в DNS соответствует три IP-адреса. В Grid Infrastructure имеется три scan-листенера с своими виртуальными IP-адресами (Virtual IP address), и в DNS-сервере этому имени должны быть поставлены в соответствие эти три VIP-адреса.

На Рисунке 1 вы видите, что вывод команды dig scan.cluster.us.oracle.com показывает, что это имя в DNS соответствует трем адресам.

Рис. 1 Имени scan-адреса соответствует три адреса в DNS

Дальше все очень просто: Oracle Client извдекает из DNS адреса scan-листенеров и далее процесс повторяется так, как если бы вы указали в tnsnames.ora три адреса. Использование технологии SCAN позволяет избавиться от необходимости изменения файлов tnsnames.ora на всех клиентских машинах при удалении/добавлении узлов кластера.

На Рис. 2 приведен вывод трассировочного файла Oracle Client, на котором виден процесс разыменовывания scan-имени в три адреса.

Рис. 2 Извлечение адресов scan-листенеров в Oracle Client

Таким образом, клиентская балансировка в 11.2 есть, но работает только между тремя scan-листенерами. Это, как и в предыдущих версиях, позволяет защитить scan-листенеры от "шторма" сессий. Ведь задача этих прослушивающих процессов состоит лишь в осуществлении серверной балансировки, то есть в перенаправлении запросов на соединение на локальный листенер наименее загруженного узла.
Поэтому трех листенеров в большинство случаев вполне достаточно, чтобы защититься от "шторма" сессий. Если же в кластере много узлов и scan-листенеры страдают от шторма сессиий то есть возможность их добавить, то есть создать новые с помощью команды srvctl add scan_listener.

Для того, чтобы прозрачно использовать SCAN, рекомендуется при переходе на RAC 11.2 так же обновить и версию Oracle Client, поскольку старые версии клиента Oracle не "понимают" такое составное разыменование. В этом случае можно порекомендовать использовать балансировку через DNS, то есть чтобы сам DNS-сервер возвращал один из трех адресов случайным образом. Разумеется DNS-сервер должен поддерживать такую возможность.

Литература:
    OTN: Single Client Access Name

Update 1
Исследования показали, что даже в случае использования scan-имени параметр LOAD_BALANCE=YES все-таки нужен!
Oracle Client всего-лишь производит разыменование в адреса scan-листенеров, но автоматически НЕ производит балансировку.
В случае если не указать параметр LOAD_BALANCE, то соединение всегда будет происходить на первый scan-листенер в списке.

Рис. 3 Oracle Client делает соединение по первому scan-листенеру в списке

Если же задать параметр LOAD_BALANCE=YES|TRUE|ON в описании соединения, то все работает как надо: scan-листенер выбирается случайным образом.

OLTP=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan.cluster.us.oracle.com)(PORT = 1521))
    (LOAD_BALANCE=YES)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = oltp.us.oracle.com)
    )
  )

Рис. 4 Oracle Client выбирает scan-листенер случайным образом

Итак, не забудьте указать LOAD_BALANCE=YES, даже если Вы используете scan-имя!

P.S. Согласно документации значение по умолчания ON для параметра LOAD_BALANCE устанавливается только если он указан для тэга DESCRIPTION_LIST.