Балансировка рабочей нагрузки членов кластера
Материал данного и последующих разделов предполагает знакомство с серверными задачами и компонентами, входящими в состав программного обеспечения сервера-члена кластера, что было рассмотрено в 3.2.19. Поэтому рекомендуем обратиться по этой ссылке, прежде чем продолжать чтение.
Администратор имеет возможность осуществлять балансировку рабочей нагрузки членов кластера. Для этого в файле NOTES.INI предусмотрены следующие переменные.
Server_Availability_Threshold = значение
Каждый член кластера регулярно вычисляет текущее значение "своего" индекса доступности
(availability index). Это целое число в диапазоне от 0 до 100, при вычислении которого использована информация о степени загрузки сервера на "последних" пяти 15-секундных интервалах времени. Значение 100 трактуется как "полная доступность" сервера, значение 0 - как "полная недоступность".
Узнать текущее значение индекса доступности сервера можно командой консоли Show Cluster.
> show cluster
Cluster name: IntTrustCluster, Server name: NotesSrv400/InterTrustCorp/SU
Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 186
Server availability threshold: 0
Server availability index: 100 (state: AVAILABLE)
Cluster members (2)...
server: NotesSrv400/InterTrustCorp/SU, availability index: 100
server: InterTrust/InterTrustCorp/SU, availability index: 96
Переменная Server_Availability_Threshold задает пороговое значение индекса доступности сервера. Когда текущее значение индекса доступности становится ниже заданного переменной Server_Availability_Threshold значения, некоторые из очередных запросов пользователей Notes версий 4.х к этому члену кластера станут переназначаться другим членам кластера, имеющим в данное время более высокий индекс доступности. Для этого задача Cluster Manager модифицирует в своем кэше состояние сервера как BUSY ("занят"), а через короткое время это состояние становится известным другим членам кластера. В то же время маршрутизация почты и репликации (как внутрикластерные, так и "обычные") продолжают осуществляться этим сервером независимо его индекса доступности. Сервер, находящийся в состоянии BUSY, продолжает вычислять текущее значение индекса доступности. Как только оно становится выше порогового значения, сервер возвращается в нормальное состояние (AVAILABLE), а через короткое время это состояние становится известным другим членам кластера.
Допустимые значения для Server_Availability_Threshold лежат в диапазоне от 0 до 100. Значение по умолчанию - 0. Выбор Server_Availabililty_Threshold=100 "переводит" сервер в состояние BUSY, при этом любые запросы пользователей к этому серверу будут переназначаться "более доступному" члену кластера, если только это возможно. Если же перенаправление запроса невозможно, доступ будет предоставляться. Выбор Server_Availabililty_Threshold=0 "переводит" сервер "в полностью доступное состояние", при этом функция Load balancing заблокирована (событие load balance не возникает).
Итак, ваша первая задача по балансировке рабочей нагрузки членов кластера состоит в том, чтобы экспериментально подобрать для каждого сервера-члена кластера приемлемое значение порога индекса доступности, которое позволяет эффективно использовать ресурсы кластера и обеспечивает быстрое время ответа для пользователя.
Server_Restricted = значение
Позволяет ограничивать доступ к серверу:
сервер переходит в состояние RESTRICTED ("использование ограничено") и не принимает новых запросов на открытие баз данных, но продолжает обслуживать пользователей, которые уже открыли базы данных на этом сервере.
Значение по умолчанию - 0. Чтобы ограничивать доступ к серверу, обычно используют команду консоли Set Config "Server_Restricted=1". В результате в файл NOTES.INI сервера будет внесено Server_Restricted=1. Задача Cluster Manager, обнаружив это изменение, изменяет состояние данного сервера на RESTRICTED в "своем" кэше кластера. Когда сервер находится в состоянии RESTRICTED, новые запросы на обращение к его базам данных по возможности перенаправляются в реплики на других серверах-членах кластера. Информация о текущем состоянии этого сервера через очень непродолжительное время становится известна другим членам кластера, и они перестают перенаправлять запросы на этот сервер. Сервер находится в состоянии RESTRICTED до перезапуска или "сброса" состояния, что обычно выполняется командой консоли Set Config "Server_Restricted=0". Для того чтобы сервер после перезапуска сразу же входил в состояние RESTRICTED, следует использовать значение Server_Restricted=2.
Обратите внимание, что переменная Server_Restricted подобным образом интерпретируется и серверами, не являющимися членами кластера. Следовательно, этим можно пользоваться при остановке сервера: сначала ограничить доступ к серверу командой Set Config "Server_Restricted=1", не прерывая "разрушительным" образом работу пользователей с открытыми базами данных, а по завершении текущей работы пользователей остановить сервер.
Server_MaxUsers = значение
Позволяет ограничивать количество активных пользователей, одновременно имеющих доступ к серверу. Если текущее количество активных пользователей на сервере достигло этого порогового значения, сервер переходит в состояние MAXUSERS и перестает принимать новые запросы на открытие баз, но продолжает обслуживать пользователей, которые уже открыли базы данных на этом сервере.
Активный пользователь рассматривается как пользователь, имеющий активную сессию с сервером и открывший на сервере одну или более баз данных. Когда количество активных пользователей на сервере достигает значения, указанного в Server_MaxUsers, сервер переходит в состояние MAXUSERS. В этом состоянии сервер не будет создавать дополнительные сессий для пользователей. Пользователи Notes версий 4.х, пытающиеся обращаться к серверу в состоянии MAXUSERS, будут или перенаправлены к реплике запрошенной базы на другом сервере-члене кластера, или получат сообщение "Access to the server is restricted due to maximum number of users" или "Access to this server has been restricted by the administrator". Пользователи Notes версий 3.х получат немного обескураживающее сообщение "You are not authorized to use the server".
Внутрикластерный репликатор на сервере в состоянии MAXUSERS будет продолжать свою работу, и внутрикластерные репликаторы других серверов тоже будут продолжать "заталкивать изменения" на данный сервер.
Очевидно, ваша вторая задача по балансировке рабочей нагрузки членов кластера состоит в том, чтобы экспериментально подобрать для каждого сервера-члена приемлемое значение порога количества активных пользователей на сервере, которое позволяло бы эффективно использовать ресурсы кластера и обеспечивало быстрое время ответа для пользователя.
Обратите внимание, что переменная Server_MaxUsers подобным образом интерпретируется и серверами, не являющимися членами кластера.
