Кластеры

Кластерные конфигурации бывают двух основных типов: Статическая или Динамическая.

Каждый Пользователь в Общем Домене, обслуживаемом в Статическом Кластере, создан (размещается) на определённом Сервере, и только этот Сервер может получать доступ непосредственно к данным пользователя. Если Серверу в Статическом Кластере необходимо выполнить операцию с пользователем другого Сервера, то он устанавливает TCP/IP соединения с Сервером пользователя и получает доступ к данным пользователя через этот Сервер. Такая архитектура позволяет вам использовать локальные (не общие) устройства хранения данных пользователя.

Обратите внимание: у некоторых производителей имеются решения типа "Мультиплексоры Почты". В таких решениях обычно реализовано подмножество функций Фронтенд-Серверов Статического Кластера.

Данные Пользователей Общих Доменов, обслуживаемых Динамическим Кластером, хранятся на общих устройствах хранения, так что каждый Сервер Кластера (кроме Фронтенд-Серверов, о них смотрите ниже) может получать доступ непосредственно к данным пользователя. В любой конкретно взятый момент времени один из Серверов Кластера действует как Контроллер Кластера, синхронизирующий доступ к Пользователям Общих Доменов. Если Серверу в Динамическом Кластере необходимо выполнить операцию с пользователем, с данными которого сейчас работает другой Сервер, то он устанавливает TCP/IP соединения с этим "текущим Сервером" пользователя и получает доступ к данным пользователя через этот Сервер. Такая архитектура обеспечивает высочайшую надёжность (все пользователи могут получать доступ к своим данным до тех пор, пока работает хотя бы один Сервер в Кластере) и не требует операций блокировки файлов на устройстве хранения.

Кластерная конфигурация CommuniGate Pro предоставляет следующие возможности:

• Получение почты по SMTP
• Отправка почты по SMTP
• Работа с SIP сигналами
• XIMSS доступ
• Доступ через Веб Интерфейс Пользователя
• Работа с XMPP сигналами
• Доступ по POP3
• Доступ по IMAP
• FTP
• RADIUS
• TFTP
• Доступ к Хранилищу Файлов по HTTP (включая загрузку на сервер)
• ACAP доступ
• PWD доступ и удалённое администрирование
• Взаимодействие между задачами CG/PL
• Запросы HTTP к внешним серверам
• Опрос внешних POP3 серверов через RPOP
• Регистрация SIP на удалённых серверах
• Общекластерные Тома Хранения Справочника

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

Фронтенд-Серверы принимают TCP/IP соединения от клиентских компьютеров (обычно - из Интернета). В чистой Фронтенд-Бэкенд конфигурации на Фронтенд-Серверах Пользователи не создаются, хотя ничто не мешает вам обслуживать некоторые Домены (с пользователями и списками рассылки) непосредственно на Фронтенд-Серверах.

Когда клиент устанавливает соединения с одним из Фронтенд-Серверов и отправляет информацию с данными аутентификации (имя Пользователя), Фронтенд-Сервер определяет, на каком из Бэкенд-Серверов могут быть открыты данные Пользователя и устанавливает соединения с этим Бэкенд-Сервером.

Фронтенд-Серверы:

• обслуживают SSL/TLS операции шифрования/расшифрования
• реализуют функциональность SIP фермы и большую часть возможностей SIP протокола, включая Прохождение NAT
• самостоятельно обслуживают большинство операций SMTP релеинга
• запускают CG/PL приложения и Каналы Медиа Сервера
• фактически убирают внутрикластерное взаимодействие между Backend Серверами и (в Динамическом Кластере) обеспечивают балансировку нагрузки второго уровня
• играют роль дополнительного уровня защиты от атак из Интернет и позволяют вам закрыть Backend Сервера от прямого доступа из Интернет
• сглаживают внешний трафик (смягчают пики в загрузке сайта) и защищают Backend Сервера от атак на Отказ в Обслуживании
• выполняют исходящие запросы HTTP.
• регистрация SIP на удалённых серверах.
• выполняют сессии опроса внешних серверов POP3 (RPOP).

Фронтенд-Серверы непосредственно доступны из Интернет и, если при взломе системы безопасности операционной системы Фронтенд-Сервера кто-либо получает несанкционированный доступ к ОС Сервера, то безопасность сайта в целом страдает в намного меньшей степени. Фронтенд-Серверы на своих дисках не хранят никакую информацию Пользователя (папки, пароли). Для того, чтобы получить доступ к какой-либо информации Пользователей, "взломщик" должен будет пройти далее через межсетевой экран и взломать систему безопасности ОС Бэкенд-Сервера. Так как всё сетевое взаимодействие между компьютерами с Фронтенд и Бэкенд-Серверами может быть ограничено только взаимодействием между серверами CommuniGate Pro, то взломать ОС Бэкенд-Сервера становится фактически невозможно.

И Статические, и Динамические Кластеры могут работать без специально назначенных Фронтенд-Серверов. Это называется симметричной конфигурацией, при которой каждый Сервер Кластера выполняет функции как Фронтенд, так и Бэкенд.

В примере ниже domain1.dom и domain2.dom являются доменами, чьи Пользователи распределены между тремя Серверами Статического Кластера, и каждый Сервер принимает для этих доменов входящие соединения. Если Сервер SV1 получает соединение на пользователя kate@domain1.dom, находящемся на сервере SV2, то Сервер SV1 начинает работать как Фронтенд-Сервер, соединяясь с Сервером SV2 как с Бэкенд-Сервером, обслуживающим требуемого Пользователя.
В это же самое время внешнему соединению, установленному сервером SV2 может потребоваться доступ к пользователю ada@domain1.dom, находящемуся на Сервере SV1. Сервер SV2, действуя как Frontend Сервер, откроет соединение с Сервером SV1 и будет работать с ним как с Backend Сервером, обслуживающим требуемого пользователя.

В симметричной конфигурации число межсерверных взаимодействий может достигать числа внешних (пользовательских) соединений с типом доступа POP, IMAP, HTTP. Для симметричного Статического Кластера среднее число межсерверных соединений будет равно M*(N-1)/N, где M - число внешних (пользовательских) соединений, а N - число Серверов в Статическом Кластере. Для симметричного Динамического Кластера среднее число межсерверных соединений будет равно M*(N-1)/N * A/T, где T - общее количество пользователей в Общих Доменах, а A - среднее число Пользователей, открытых на каждом Сервере. Для крупных сайтов Интернет-провайдеров и для порталов число A/T относительно невелико (обычно не больше чем 1:100).

В чистой Фронтенд-Бэкенд конфигурации число межсерверных соединений обычно совпадает с числом внешних (пользовательских) соединений: для каждого внешнего соединения Фронтенд Сервер открывает соединение с Бэкенд Сервером. В дополнение к этому может быть открыто небольшое число межсерверных соединений между Бэкенд Серверами.

Удаление Фронтенд Сервера из Кластера

Для того, чтобы убрать из Кластера Фронтенд Сервер (для проведения техобслуживания, модернизации аппаратного обеспечения и т.д.), перенастройте ваш балансировщик нагрузок или циклический DNS сервер таким образом, чтобы они прекратили перенаправлять входящие запросы на адрес этого Фронтенд Сервера. После того, как будут закрыты все текущие POP, IMAP, SMTP сессии, Фронтенд Сервер может быть выключен. Так как в сессиях Веб Почты не используются постоянные HTTP соединения, то Фронтенд Сервера в Кластере, обслуживающем только Веб Почту, могут быть выключены почти сразу же.

Доступ ко всем Пользователям Общих Доменов обеспечивается бесперебойно до тех пор, пока будет работать хотя бы один Фронтенд Сервер.

Если Фронтенд сервер прекращает свою работу, то никакие из пользователей не станут недоступными и потери почты не произойдёт. Хотя POP и IMAP сессии, проходившие через остановившийся Фронтенд сервер прервутся, все сессии Веб Интерфейса Пользователя останутся активными и клиенты, работающие через Веб Интерфейс Пользователя, смогут продолжить работу на оставшихся Фронтенд Серверах. POP и IMAP пользователи могут сразу же переустановить свои соединения через оставшиеся Фронтенд-Сервера.

Если проблемный Фронтенд сервер не может быть быстро отремонтирован, его Очередь может быть обработана другим сервером как Чужая Очередь.

В этом разделе описывается, как должен быть настроен каждый из Серверов CommuniGate Pro для того, чтобы войти в Статический или Динамический Кластер. Эти настройки управляют межсерверным взаимодействием в вашем Кластере.

Во-первых, установите программное обеспечение CommuniGate Pro на всех Серверах, которые должны войти в ваш Кластер. Укажите на всех Серверах Кластера Имя Главного Домена. Эти имена должны отличаться только в первом элементе имени домена:

back1.isp.dom, back2.isp.dom, front1.isp.dom, front2.isp.dom и т.д.

Помните, что Главный Домен никогда не является общим, так что все эти имена должны быть различными. В Главных Доменах достаточно создать только пользователей - Администраторов Сервера; эти пользователи могут использоваться для соединения с конкретным Сервером и задания его локальных, специфических для этого Сервера, настроек.

Кластерная Сеть

Используйте Веб Интерфейс Администратора и откройте страницу Установки->Общее->Кластер на каждом Бэкенд Сервере и введите все IP адреса Фронтенд и Бэкенд Серверов. Бэкенд Сервера CommuniGate Pro будут принимать кластерные соединения только с указанных IP адресов. Если Фронтенд Сервера используют для взаимодействия с Бэкенд Серверами отдельные Сетевые Карты (NICs), то указывайте те IP адреса, которые Фронтенд Сервера имеют в этой внутренней сети:

Кластерная Сеть
Адрес Этого Сервера в Кластере:	После Перезапуска Текущий [192.168.0.5][10.0.0.5][127.0.0.1] [192.168.0.5]
Адреса Backend Серверов:	192.168.0.4-192.168.0.8; это комментарий
Адреса Frontend Серверов:	192.168.0.1-192.168.0.3
Журнал Локера Динамического Кластера:	КатастрофыСбоиОсновноеПроблемыПодробностиВсё	Балансировщик Нагрузки DSR:	ABCD

Адрес Этого Сервера в Кластере

Эта настройка задаёт локальный сетевой адрес этого Сервера, используемый для взаимодействия с другими Серверами в Кластере. Соединения с другими членами кластера будут устанавливаться с этого IP адреса. Этот адрес используется как "имя" этого Сервера, идентифицирующее Сервер в Кластере.

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

Внутри-кластерное Взаимодействие

В любых типах Кластеров CommuniGate Pro соединения с Backend Серверами могут быть установлены с Frontend Серверов и с других Backend серверов.

Если ваши Backend Сервера используют нестандартные номера портов для почтовых услуг, измените значения номеров портов Backend Серверов.

Например, если ваш Backend Сервер принимает соединения с Веб-Интерфейсом Пользователя не на порт номер 8100, а на стандартный HTTP порт 80, то установите значение 80 в поле HTTPU и нажмите на кнопку Модифицировать.

Внутри-кластерное Взаимодействие
Backend Порт		Кэш	Backend Порт		Кэш
Доставка:		0135103050100150200250	Отправление:		0135103050100150200250
POP:			IMAP:
HTTPU:			HTTPA:
XIMSS:			XMPP:
PWD:			LDAP
Уровень Журнала		Кэш	Уровень Журнала		Кэш
Администрация Объектов:	КатастрофыСбоиОсновноеПроблемыПодробностиВсё	0135103050100150200250	Папки:	КатастрофыСбоиОсновноеПроблемыПодробностиВсё	0135103050100150200250
Администрация Кластера:	КатастрофыСбоиОсновноеПроблемыПодробностиВсё

Некоторые межсерверные соединения для некоторых услуг CommuniGate Pro может использовать повторно. Вместо того, чтобы закрывать соединение по выполнению операции, соединение помещается по внутренний Кэш и используется впоследствии, когда серверу потребуется соединиться с этим же сервером. Параметр Кэш задаёт количество таких зарезервированных соединений. Если в Кэше содержится слишком много соединений, то более старые соединения закрываются и выбрасываются из Кэша.

Члены Кластера используют PWD протокол для удалённого выполнения операций администрирования на других членах кластера. Номер порта, используемый ими для соединения с другими членами Кластера, совпадает с номером порта, заданным для соединений по PWD протоколу. Эти удалённые операции администрирования имеют свои собственные настройки Уровня Журнала.

Сервера в Динамическом Кластере используют SMTP модули других Backend членов Кластера для удалённой доставки сообщений (хотя протокол между серверами не является протоколом SMTP). Используйте настройку Доставка для указания номера порта, используемого SMTP модулями на других членах кластера.

Сервера в Динамическом Кластере используют SMTP модули других членов Кластера для удалённой отправки сообщений (хотя протокол между серверами не является протоколом SMTP). Используйте настройку Отправление для указания номера порта, используемого SMTP модулями на других членах кластера.

Когда сессия пользователя, запущенная на одном члене Кластера, нуждается в доступе к чужой папке, а пользователь, которому принадлежит папка, не может быть открыт этим же членом Кластера (уже открыт на другом члене Кластера), то для удалённого доступа к папке используется менеджер Папок Кластера. Менеджер Папок Кластера использует порт IMAP для соединения с членами кластера. Менеджер Папок Кластера использует независимые настройки Уровня Журнала.

Обработка Услуг
Исходящие HTTP Соединения:	АвтоматическиУдалённоЛокальноЛокально для Других	Исходящие RPOP Соединения:	АвтоматическиУдалённоЛокальноЛокально для Других

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

Исходящие HTTP Соединения

Эта настройка определяет, как будут выполняться исходящие запросы HTTP (запущенные сессиями XIMSS, приложениями CG/PL, Автоматическими правилами и так далее).

Локально

запросы HTTP выполняются на том же Сервере (это обычный, односерверный режим обработки).

Локально для Других

Запросы HTTP выполняются на этом же Сервере.
Контроллер Динамического Кластера информируется о том, что этот Сервер может выполнять исходящие запросы HTTP, сформированные другими членами Кластера.
Контроллер Динамического Кластера собирает и распространяет информацию обо всех активных членах Кластера, у которых выбрана эта опция.

Удалённо

запросы HTTP передаются для выполнения тому члену Кластера, у которого эта настройка имеет значение Локально для Других.

Автоматически

• если этот Сервер не входит в Динамический Кластер, то так же, как Локально
• если этот Сервер является фронтендом Динамического Кластера, то так же, как Локально для других
• если этот Сервер является бэкендом Динамического Кластера, то так же, как Удалённо если есть другие члены Динамического кластера настроенные как Локально для других, если нет - так же, как Локально

Исходящие RPOP Соединения

Эта настройка определяет, как будут выполняться задания RPOP. Значения настроек имеют тот же смысл, что и настройки в разделе Исходящие HTTP Запросы.

Кластер CommuniGate Pro может обслуживать несколько Общих Доменов. Если вы планируете предоставлять Пользователям в этом Домене доступ по IMAP, то, возможно, для упрощения настройки почтовых клиентов, вы захотите назначить выделенные IP адреса этому Домену. Дополнительную информацию смотрите в разделе Доступ.

Если вы используете Фронтенд Сервера, то только у них должен быть задан выделенный IP адрес для Общих Доменов. При внутрикластерном взаимодействии всегда используются полные имена пользователей (accountname@domainname), так что нет необходимости назначать выделенные IP адреса Общим Доменам на Бэкенд Серверах.

Если вы используете циклические механизмы в DNS для распределения загрузки сайта, то вам необходимо назначить N IP адресов каждому Общему Домену, которому нужен выделенный IP адрес, где N - число ваших Фронтенд Серверов. Настройте ваш DNS Сервер так, чтобы он возвращал эти адреса по кругу:

В этом примере Кластер имеет три Фронтенд Сервера и обслуживает два Общих Домена: domain1.dom и domain2.dom. В таблице DNS сервера каждому имени домена назначено три IP адреса и DNS сервер возвращает все три адреса в ответ на запрос клиента об A-записи для одного из этих имён домена. Каждый раз DNS сервер "проворачивает" порядок IP адресов в своих ответах, выполняя роль "циклического" балансировщика нагрузки DNS (клиентские приложения обычно используют первый адрес из ответа DNS, а другие адреса используются только в том случае, если попытка установить TCP/IP соединение с первым адресом не удалась).

При настройке этих Общих Доменов на ваших Серверах CommuniGate Pro, назначьте три IP адреса каждому Домену.

Если вы используете Балансировщик Нагрузки для распределения нагрузки на сайт, то вам необходимо поместить только один "внешний" IP адрес в запись DNS, описывающую каждый Общий Домен. Назначьте один "виртуальный" IP адрес каждому Общему Домену на каждом Фронтенд Сервере:

В этом примере Кластер имеет три Фронтенд Сервера и обслуживает два Общих Домена: domain1.dom и domain2.dom. В таблице DNS сервера каждому Общему Домену назначен один IP Адрес и этот адрес является внешним (Интернет) адресом вашего Балансировщика Нагрузки. Вы должны настроить Балансировщик Нагрузки таким образом, чтобы он распределял соединения, полученные на каждый из его внешних IP адресов, на три внутренних IP адреса - это адреса, назначенные для ваших Фронтенд-Серверов.

При настройке Общих Доменов на ваших Серверах CommuniGate Pro, назначьте три эти IP адреса каждому из Доменов.

MX-записи DNS для Общих Доменов при этому могут указывать на их A-записи.

Параметры Запуска

Наилучшим способом добавления параметров запуска будет создание файла Startup.sh в Базовой Директории.

Для создания Статического Кластера используйте параметр запуска --staticBackend на бэкенд-серверах, и параметр --staticFrontend на фронтенд-серверах.

Для создания Динамического Кластера используйте параметр запуска --clusterBackend на бэкенд-серверах, и параметр --clusterFrontend на фронтенд-серверах.

Приёмник

Для защиты вашего сайта от атак на Отказ в Обслуживании (DoS), вы можете открыть SMTP, POP, IMAP и другие Приёмники и ограничить число соединений, принимаемых с одного IP адреса. Устанавливайте эти ограничения только на Фронтенд-Серверах, так как Backend Сервера получают все соединения только от Фронтенд-Серверов, а каждый Фронтенд-Сервер может открывать множество соединений с одного IP адреса.

Веб Интерфейс Администратора

Обычно Бэкенд Сервера не доступны прямо из Интернет. Если вам необходимо изменить настройки или наблюдать за Бэкенд Сервером "снаружи", вы можете использовать Веб Интерфейс Администратора одного из Фронтенд Серверов и следующий URL:
http://Frontendaddress:8010/Cluster/12.34.56.78/
где 12.34.56.78 [внутренний] IP адрес Бэкенд сервера, к которому необходимо получить доступ.

SMTP

Исходящий почтовый трафик, генерируемый обычными (POP/IMAP) клиентами, поступает на сайт с использованием A-записей Доменов сайта. В результате, поступающие сообщения попадают на Фронтенд Сервера и распространятся оттуда.

Сообщения, созданные в Веб Интерфейсе Пользователя и сообщения, создаваемые автоматически (используя Автоматические Правила) генерируются на Бэкенд Серверах. Так как обычно Бэкенд-Сервера находятся за межсетевым экраном и так как скорее всего вы не хотите, чтобы Бэкенд-Сервера тратили свои ресурсы на обслуживание SMTP очередей, то рекомендуется использовать возможности релеинга модуля SMTP CommuniGate Pro.

Выберите опцию Посылать через и укажите символ звёздочку (*). В этом случае все сообщения, созданные на Бэкенд Серверах, будут быстро отправляться на Фронтенд Сервера и распространяться далее уже оттуда. Если вы не хотите использовать все Фронтенд Сервера для релеинга почты с Бэкенд серверов, то измените значение настройки Посылать через, включив в неё только IP адреса необходимых Фронтенд Серверов, разделённых запятой (,).

RPOLL

В Статическом Кластере все задачи RPOLL выполняются на Бэкенд Серверах. Как следствие, важно, чтобы эти сервера могли инициировать исходящие TCP соединения с удалёнными серверами. Если Бэкенд сервера подключены к частной локальной сети за межсетевым экраном, то вы должны установить в этой сети какой-нибудь NAT сервер и настроить Бэкенд сервера (используя TCP/IP установки ОС) на маршрутизацию всех не локальных пакетов через NAT сервер. NAT сервисы могут быть запущены на Фронтенды серверах.
В Динамическом Кластере задачи RPOLL выполняются на серверах, у которых настройка Исходящий RPOLL установлена в Локально для других. Как следствие, важно, чтобы эти сервера могли инициировать исходящие TCP соединения с удалёнными серверами. Задания RPOLL инициируются текущим Контроллером Кластера, и поскольку Бэкенды могут не иметь прямого доступа в публичные сети, их настройка исходящий RPOLL должна быть установлена в Удалённо.

FTP

FTP модуль не "проксирует" соединения на Бэкенд сервера. Вместо этого, для доступа к Хранилищам Файлов Пользователя на Бэкенд Серверах он использует CLI. Это снимает проблему необходимости открытия на Бэкенд Серверах прямых FTP соединений с клиентами. Если все FTP соединения попадают на Фронтенд Сервера, то Модуль FTP на Бэкенд серверах вообще может быть выключен.

FTP модуль, запущенный на Фронтенд Серверах кластера за балансировщиком нагрузки и/или позади NAT, сталкивается с такими же проблемами, как любой одиночный FTP сервер, запущенный в такой же конфигурации. Для поддержки работы в активном режиме убедитесь, что Фронтенд сервера могут открывать исходящие соединения при запуске через NAT, а также убедитесь, что проблема "address in use" успешно разрешается программным обеспечением NAT. Для поддержки работы в пассивном режиме, убедитесь, что ваш балансировщик нагрузки позволяет клиентами соединяться напрямую с портами модуля FTP, открытыми на Фронтенд сервере.

LDAP

LDAP модуль не "проксирует" соединения на сервера Бэкенд. Вместо этого, для аутентификации пользователей и, возможно, для Управления Пользователями через LDAP, он использует CLI. Если все соединения LDAP попадают на Фронтенд Сервера, то Модуль LDAP на Бэкенд серверах вообще может быть выключен, если только не используются общекластерные Тома Хранения Справочника (смотрите ниже).

Справочник

Общекластерные Тома Хранения Справочника обслуживаются на текущем Контроллере Кластера. Другие члены Кластера получают доступ к Общекластерным Справочникам по протоколу LDAP с Контроллера.
Если вы используете Общекластерные Тома Хранения Справочника, Модуль LDAP на серверах Бэкенд должен быть включён.

RADIUS

Модуль RADIUS не "проксирует" соединения с Бэкенд серверами. Вместо этого, для аутентификации пользователей и для изменения их статистических данных он использует CLI. Если все RADIUS соединения попадают на Фронтенд Сервера, то Модуль RADIUS на Бэкенд серверах вообще может быть выключен.

SIP

Смотрите раздел Сигналы в Кластере.

RSIP

Обработка задач RSIP выполняется полностью аналогично обработке задач RPOLL. Регистрации через RSIP реализованы с помощью Задач Реального Времени и потому могут выполняться на тех узлах кластера, которые настроены для выполнения Задач Звонков. Смотрите раздел Сигналы в Кластере.

Пользователь Postmaster

Не удаляйте пользователя "postmaster" из Главных Доменов ваших Бэкенд Серверов. Этот Пользователь открывается "по имени" (минуя Маршрутизатор), когда другие члены Кластера соединяются с этим Бэкенд Сервером. Вы также должны установить Права Доступа "Может менять установки Всех Доменов и Пользователей" (как минимум) для Пользователя postmaster.

Для очень больших сайтов (более чем 5,000,000 активных пользователей) вы можете развернуть Статический Кластер, состоящий из Динамических Кластеров. В общих чертах это тот же самый обычный Статический кластер с Фронтенд Серверами, но в качестве Бэкенд Серверов вы подключаете Динамические Кластера. Это решает проблему резервирования для Статических Кластеров, но не требует огромных Общих устройств Хранения и уменьшает сетевой трафик сверхбольших Динамических Кластеров:

Фронтенд-Серверам в Кластере Кластеров необходимо иметь доступ к Справочнику для того, чтобы реализовать функции Статического Кластера. Фронтенд-Серверам необходимо только читать информацию из Справочника, а Бэкенд-Серверам при добавлении, переименовании или удалении пользователей необходимо изменять Справочник. Атрибут hostServer записи Пользователя в справочнике содержит имя Бэкенда - Динамического Кластера, обслуживающего Пользователя (имя Бэкенда - Динамического Кластера без первого элемента имени домена).

Фронтенд-Сервера могут быть объединены в группы для сегментации трафика. Каждая группа может иметь свой собственный балансировщик(и) нагрузки и коммутатор, который соединяет эту Группу Фронтендов с каждым Бэкендом - Динамическим Кластером.

Если вы планируете развернуть много (50 и более) Фронтенд Серверов, то самым узким местом системы станет Сервер со Справочником. Для того, чтобы снять проблемы с производительностью и обеспечить резервирование на уровне Справочника, вы можете развернуть несколько Серверов со Справочником (каждый Сервер будет обслуживать одну или несколько Групп Фронтендов). Бэкенд - Динамический Кластер может быть настроен на изменение только "Главного" Сервера Справочника, а другие Сервера Справочника для синхронизации данных с Главным Сервером Справочника могут использовать механизмы репликации данных, или же Бэкенды - Кластеры могут быть настроены на одновременное изменение данных на всех Серверах Справочника.