Версия 5.2
Кластеры |
|---|
| ||||||||
|
|
Версия 5.2 |
||||||||||||||||||||||||||||||
|
|
В случае, если ваш сайт обслуживает много Доменов, то, возможно, вы захотите установить несколько независимых Серверов CommuniGate Pro и распределить нагрузку между ними, разбив домены между серверами. В этом случае вам нет необходимости использовать специальные возможности по поддержке Кластеров. Однако, если у вас есть один или несколько Доменов со 100,000 или более пользователей в каждом и вы не можете гарантировать, что клиенты всегда будут соединяться с правильным сервером, или же вам необходимо динамически распределять нагрузку и одновременно обеспечить высокую надежность работы, то вы должны развернуть на вашем сайте CommuniGate Pro Кластер.
Множество производителей использует термин Кластер для решений, обеспечивающих простую обработку сбоев оборудования или горячий резерв. Сервер CommuniGate Pro может использоваться в конфигурациях для обработки сбоев, а также в конфигурациях с Распределёнными Доменами, однако такие конфигурации не считаются Кластерными конфигурациями.
Кластер CommuniGate Pro - это несколько Серверов, совместно обрабатывающих весь трафик сайта. Каждый Сервер в Кластере обслуживает набор обычных, не общих доменов (Главный Домен CommuniGate Pro никогда не является общим), и также он обслуживает (вместе с другими Серверами в Кластере) набор Общих Доменов.
Для того, что бы использовать сервера CommuniGate Pro в Кластере, вам необходима специальная Кластерная Лицензия.
Пожалуйста, прочитайте сначала раздел Масштабируемость для того, что бы узнать, как более точно оценить загрузку Сервера и как добиться наибольшей производительность от единичного или работающего в составе Кластера Сервера CommuniGate Pro.
Кластерные конфигурации бывают двух основных типов: Статическая или Динамическая.
Каждый Пользователь в Общем Домене, обслуживаемом в Статическом Кластере, создан (размещается) на определённом Сервере, и только этот Сервер может получать доступ непосредственно к данным пользователя. Если Серверу в Статическом Кластере необходимо выполнить операцию с пользователем другого Сервера, то он устанавливает TCP/IP соединения с Сервером пользователя и получает доступ к данным пользователя через этот Сервер. Такая архитектура позволяет вам использовать локальные (не общие) устройства хранения данных пользователя.
Обратите внимание: у некоторых производителей имеются решения типа "Мультиплексоры Почты". В таких решениях обычно реализовано подмножество функций Frontend Серверов Статического Кластера.
Данные Пользователей Общих Доменов, обслуживаемых Динамическим Кластером, хранятся на общих устройствах хранения, так что каждый Сервер Кластера (кроме Frontend Серверов, о них смотрите ниже) может получать доступ непосредственно к данным пользователя. В любой конкретно взятый момент времени один из Серверов Кластера действует как Контроллер Кластера, синхронизирующий доступ к Пользователям Общих Доменов. Если Серверу в Динамическом Кластере необходимо выполнить операцию с пользователем, с данными которого сейчас работает другой Сервер, то он устанавливает TCP/IP соединения с этим "текущим Сервером" пользователя и получает доступ к данным пользователя через этот Сервер. Такая архитектура обеспечивает высочайшую надёжность (все пользователи могут получать доступ к своим данным до тех пор, пока работает хотя бы один Сервер в Кластере) и не требует операций блокировки файлов на устройстве хранения.
В кластерах обоего типа обычно используются Frontend Сервера. Frontend Сервера не могут получать доступ к данным Пользователя напрямую - они всегда открывают соединения с другими (Backend) Серверами для выполнения любой операции с данными Пользователя.
Frontend Сервера принимают TCP/IP соединения от клиентских компьютеров (обычно - из Интернета). В чистой Frontend-Backend конфигурации на Frontend Серверах Пользователи не создаются, хотя ничто не мешает вам обслуживать некоторые Домены (с пользователями и списками рассылки) непосредственно на Frontend серверах.
Когда клиент устанавливает соединения с одним из Frontend Серверов и отправляет информацию с аутентификационными данными (имя Пользователя), Frontend сервер определяет, на каком из Backend серверов могут быть открыты данные Пользователя и устанавливает соединения с этим Backend Сервером.
Frontend Сервера:Frontend Сервера непосредственно доступны из Интернет и, если при взломе системы безопасности операционной системы Frontend Сервера кто-либо получает несанкционированный доступ к ОС Сервера, то безопасность сайта в целом страдает в намного меньшей степени. Frontend Сервера на своих дисках не хранят никакую информацию Пользователя (папки, пароли). Для того, что бы получить доступ к какой-либо информации Пользователей, "взломщик" должен будет пройти далее через межсетевой экран и взломать систему безопасности ОС Backend Сервера. Так как всё сетевое взаимодействие между компьютерами с Frontend и Backend Серверами может быть ограничено только взаимодействием между серверами CommuniGate Pro, то взломать ОС Backend Сервера становится фактически невозможно.
Как Статический, так и Динамический Кластер может работать и без выделенного Frontend Сервера. Это называется симметричной конфигурацией, при которой каждый Сервер Кластера выполняет как Frontend, так и Backend функции.
В примере ниже domain1.dom и domain2.dom являются доменами, распределёнными между тремя Серверами Статического Кластера, и каждый Сервер принимает для этих доменов входящие соединения. Если Сервер SV1 получает соединение на пользователя kate@domain1.dom, находящемся на сервере SV2, то Сервер SV1 начинает работать как Frontend Сервер, соединяясь с Сервером SV2 как с Backend Сервером, обслуживающим требуемого Пользователя.
В это же самое время внешнему соединению, установленному сервером 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).
В чистой Frontend-Backend конфигурации число межсерверных соединений обычно совпадает с числом внешних (пользовательских) соединений: для каждого внешнего соединения Frontend Сервер открывает соединение с Backend Сервером. В дополнение к этому может быть открыто небольшое число межсерверных соединений между Backend Серверами.
Доступ ко всем Пользователям Общих Доменов обеспечивается бесперебойно до тех пор, пока будет работать хотя бы один Frontend Сервер.
Если Frontend сервер прекращает свою работу, то никакие из пользователей не станут недоступными и потери почты не произойдёт. Хотя POP и IMAP сессии, проходившие через остановившийся Frontend сервер прервутся, все сессии Веб Интерфейса Пользователя останутся активными и клиенты, работающие через Веб Интерфейс Пользователя, смогут продолжить работу на оставшихся Frontend Серверах. POP и IMAP пользователи могут сразу же переустановить свои соединения через оставшиеся Frontend Сервера.
Если проблемный Frontend сервер не может быть быстро отремонтирован, его Очередь может быть обработана другим сервером как Чужая Очередь.
В этом разделе описывается, как должен быть настроен каждый из Серверов CommuniGate Pro для того, что бы войти в Статический или Динамический Кластер. Эти настройки управляют межсерверным взаимодействием в вашем Кластере.
Во-первых, установите программное обеспечение CommuniGate Pro на всех Серверах, которые должны войти в ваш Кластер. Укажите на всех Серверах Кластера Имя Главного Домена. Эти имена должны отличаться только в первом элементе имени домена:Используйте Веб Интерфейс Администратора и откройте страницу Установки->Общее->Кластер на каждом Backend Сервере и введите все IP адреса Frontend и Backend Серверов. Backend Сервера CommuniGate Pro будут принимать кластерные соединения только с указанных IP адресов. Если Frontend Сервера используют для взаимодействия с Backend Серверами отдельные Сетевые Карты (NICs), то указывайте те IP адреса, которые Frontend Сервера имеют в этой внутренней сети:
Если выбрано значение first IP, то Сервер выбирает первый адрес из списка локальных сетевых IP адресов.
Если вы изменяете значение этой настройки, то новое значение будет использоваться только после перезапуска Сервера.
В любых типах Кластеров CommuniGate Pro соединения с Backend Серверами могут быть установлены с Frontend Серверов и с других Backend серверов.
Если ваши Backend Сервера используют нестандартные номера портов для почтовых услуг, измените значения номеров портов Backend Серверов.
Например, если ваш Backend Сервер принимает соединения с Веб Интерфейсом Пользователя не на порт номер 8100, а на стандартный HTTP порт 80, то установите значение 80 в поле HTTPU и нажмите на кнопку Модифицировать.
Некоторые межсерверные соединения для некоторых услуг CommuniGate Pro может использовать повторно. Вместо того, что бы закрывать соединение по выполнению операции, соединение помещается по внутренний Кэш и используется впоследствии, когда серверу потребуется соединиться с этим же сервером. Параметр Кэш задаёт количество этих зарезервированных соединений. Если в Кэше содержится слишком много соединений, то более старые соединения закрываются и выбрасываются из Кэша.
Члены Кластера используют PWD протокол для удалённого выполнения операций администрирования на других членах кластера. Номер порта, используемый ими для соединения с другими членами Кластера, совпадает с номером порта, заданным для соединений по PWD протоколу. Эти удалённые операции администрирования имеют свои собственные настройки Уровня Журнала.
Сервера в Динамическом Кластере используют SMTP модули других Backend членов Кластера для удалённой доставки сообщений (хотя протокол между серверами не является протоколом SMTP). Используйте настройку Доставка для указания номера порта, используемого SMTP модулями на других членах кластера.
Сервера в Динамическом Кластере используют SMTP модули других членов Кластера для удалённой отправки сообщений (хотя протокол между серверами не является протоколом SMTP). Используйте настройку Отправление для указания номера порта, используемого SMTP модулями на других членах кластера.
Когда сессия пользователя, запущенная на одном члене Кластера, нуждается в доступе к чужой папке и пользователь, которому принадлежит папка, не может быть открыт этим же членом Кластера, то для удалённого доступа к папке используется менеджер Папок Кластера. Менеджер Папок Кластера использует порт IMAP для соединения с членами кластера. Менеджер Папок Кластера использует независимые настройки Уровня Журнала.
Кластер CommuniGate Pro может обслуживать несколько Общих Доменов. Если вы планируете предоставлять Пользователям в этом Домене доступ по IMAP, то, возможно, для упрощения настройки почтовых клиентов, вы захотите назначить выделенные IP адреса этому Домену. Дополнительную информацию смотрите в разделе Доступ.
Если вы используете Frontend Сервера, то только у них должен быть задан выделенный IP адрес для Общих Доменов. При внутрикластерном взаимодействии всегда используются полные имена пользователей (accountname@domainname), так что нет необходимости назначать выделенные IP адреса Общим Доменам на Backend Серверах.
Если вы используете циклические механизмы в DNS для распределения загрузки сайта, то вам необходимо назначить N IP адресов каждому Общему Домену, которому нужен выделенный IP адрес, где N - число ваших Frontend Серверов. Сконфигурируйте ваш DNS Сервер так, что бы он возвращал эти адреса по кругу:
В этом примере Кластер имеет три Frontend Сервера и обслуживает два Общих Домена: domain1.dom и domain2.dom. В таблице DNS сервера каждому имени домена назначено три IP адреса и DNS сервер возвращает все три адреса в ответ на запрос клиента об A-записи для одного из этих имён домена. Каждый раз DNS сервер "проворачивает" порядок IP адресов в своих ответах, выполняя роль "циклического" балансировщика нагрузки DNS (клиентские приложения обычно используют первый адрес из ответа DNS, а другие адреса используются только в том случае, если попытка установить TCP/IP соединение с первым адресом не удалась).
При настройки этих Общих Доменов на ваших Серверах CommuniGate, назначьте три IP адреса каждому Домену.
Если вы используете Балансировщик Нагрузки для распределения нагрузки на сайт, то вам необходимо поместить только один "внешний" IP адрес в запись DNS, описывающую каждый Общий Домен. Назначьте один "виртуальный" IP адрес каждому Общему Домену на каждом Frontend Сервере:
В этом примере Кластер имеет три Frontend Сервера и обслуживает два Общих Домена: domain1.dom и domain2.dom. В таблице DNS сервера каждому Общему Домену назначен один IP Адрес и этот адрес является внешним (Интернет) адресом вашего Балансировщика Нагрузки. Вы должны настроить Балансировщик Нагрузки таким образом, что бы он распределял соединения, полученные на каждый из его внешних IP адресов, на три внутренних IP адреса - это адреса, назначенные для ваших Frontend Серверов.
При настройке Общих Доменов на ваших Серверах CommuniGate Pro, назначьте три эти IP адреса каждому из Доменов.
MX-записи DNS для Общих Доменов при этому могут указывать на их A-записи.
Топология, в которой используются Frontend и Backend сервера позволяет вам защитить информацию и Backend Сервера не только когда Frontend Сервер аварийно прекращают работу из-за каких-либо сетевых атак, но также и в случаях, когда ОС Frontend Сервера "взломана" и нарушитель получил полные права доступа к ОС, используя какую-либо дыру в безопасности этой ОС.
Для защиты сайта от такого типа "взломов":Эти меры не причинят проблем вашим пользователям, имеющим права администратора домена и желающим администрировать свои Общие Домены (через Веб Интерфейс Администратора или Интерфейс Командной Строки CLI). Они также не причинят проблем обычным пользователям, использующим модуль PWD для изменения своих паролей.
Для защиты вашего сайта от атак на Отказ в Обслуживании (DoS), вы можете открыть SMTP, POP, IMAP и другие Приёмники и ограничить число соединений, принимаемых с одного IP адреса. Устанавливайте эти ограничения только на Frontend Серверах, так как Backend Сервера получают все соединения только от Frontend Серверов, а каждый Frontend Сервер может открывать множество соединений с одного IP адреса.
Обычно Backend Сервера не доступны прямо из Интернет. Если вам необходимо изменить настройки или наблюдать за Backend Сервером "снаружи", вы можете использовать Веб Интерфейс Администратора одного из Frontend Серверов и следующий URL:
http://Frontendaddress:8010/Cluster/12.34.56.78/
где 12.34.56.78 [внутренний] IP адрес Backend сервера, к которому необходимо получить доступ.
Исходящий почтовый трафик, генерируемый обычными (POP/IMAP) клиентами, поступает на сайт с использованием A-записей Доменов сайта. В результате, поступающие сообщения попадают на Frontend Сервера и распространятся оттуда.
Сообщения, созданные в Веб Интерфейсе Пользователя и сообщения, создаваемые автоматически (используя Автоматические Правила) генерируются на Backend Серверах. Так как обычно Backend Сервера находятся за межсетевым экраном и так как скорее всего вы не хотите, что бы Backend Сервера тратили свои ресурсы на обслуживание SMTP очередей, то рекомендуется использовать возможности релеинга SMTP модуля CommuniGate Pro.
Выберите опцию Посылать через и укажите символ звёздочку (*). В этом случае все сообщения, созданные на Backend Серверах, будут быстро отправляться на Frontend Сервера и распространяться далее уже оттуда. Если вы не хотите использовать все Frontend Сервера для релеинга почты с Backend серверов, то измените значение Посылать через, включив в неё только IP адреса необходимых Frontend Серверов, разделённых символом запятой (,).
В Статическом Кластере все RPOP деятельность осуществляется на Backend Серверах, а в Динамическом Кластере - на Контроллере Кластера. Как следствие, важно, что бы эти сервера могли инициировать исходящие TCP соединения с удалёнными серверами. Если Backend сервера подключены к частной локальной сети за межсетевым экраном, то вы должны установить в этой сети какой-нибудь NAT сервер и настроить Backend сервера (используя TCP/IP установки ОС) на маршрутизацию всех не локальных пакетов через NAT сервер(а). NAT сервисы могут быть запущены на Frontend серверах.
FTP модуль не "проксирует" соединения с Backend серверами. Вместо этого, для обслуживания Хранилища Файлов Пользователя на Backend Серверах он использует CLI. Эта снимает проблему необходимости открытия на Backend Серверах прямых FTP соединений с клиентами. Если все FTP соединения попадают на Frontend Сервера, то Услуга FTP на Backend серверах вообще может быть выключена.
FTP модуль, запущенный на кластере Frontend Серверов за балансировщиком нагрузки и/или позади NAT, сталкивается с такими же проблемами, как и FTP сервер запущенный в такой же конфигурации. Для поддержки работы в активном режиме, убедитесь что Frontend сервера могут открывать исходящие соединения при запуске через NAT, а также убедитесь, что проблема "address in use" успешно разрешается программным обеспечением NAT. Для поддержки работы в пассивном режиме, убедитесь, что ваш балансировщик нагрузки позволяет клиентами соединяться напрямую с портами FTP модуля, открытыми на Frontend сервере.
LDAP модуль не "проксирует" соединения с Backend серверами. Вместо этого, для аутентификации пользователей и, дополнительно, для Управления Пользователями через LDAP, он использует CLI. Если все LDAP соединения попадают на Frontend Сервера, то Услуга LDAP на Backend серверах вообще может быть выключена.
Модуль RADIUS не "проксирует" соединения с Backend серверами. Вместо этого, для аутентификации пользователей и для изменения их статистических данных он использует CLI. Если все RADIUS соединения попадают на Frontend Сервера, то Услуга RADIUS на Backend серверах вообще может быть выключена.
Смотрите раздел Кластер Сигналов.
Не удаляйте пользователя "postmaster" из Главных Доменов ваших Backend Серверов. Этот Пользователь открывается "по имени" (минуя Маршрутизатор), когда другие члены Кластера соединяются с этим Backend Сервером. Вы также должны установить Права Доступа "Может менять установки Всех Доменов и Пользователей" (как минимум) для Пользователя postmaster.
Для очень больших сайтов (более чем 5,000,000 активных пользователей) вы можете развернуть Статический Кластер, состоящий из Динамических Кластеров. В общих чертах это тот же самый обычный Статический кластер с Frontend Серверами, но в качестве Backend Серверов вы подключаете Динамические Кластера. Это решает проблему резервирования для Статических Кластеров, но не требует огромных Общих устройств Хранения и уменьшает сетевой трафик сверхбольших Динамических Кластеров:
Frontend Серверам в Кластере Кластеров необходимо иметь доступ к Справочнику для того, что бы реализовать функции Статического Кластера. Frontend Серверам необходимо только читать информацию из Справочника, а Backend Серверам при добавлении, переименовании или удалении пользователей необходимо изменять Справочник. Атрибут hostServer записи Пользователя в справочнике содержит имя Backend - Динамического Кластера, обслуживающего Пользователя (имя Backend - Динамического Кластера без первого элемента имени домена).
Frontend Сервера могут быть объединены в группы для сегментации трафика. Каждая группа может иметь свой собственный балансировщик(и) нагрузки и коммутатор, который соединяет эту Frontend Группу с каждым Backend - Динамическим Кластером.
Если вы планируете развернуть много (50 и более) Frontend Серверов, то самым узким местом системы станет Сервер со Справочником. Для того, что бы снять проблемы с производительностью и обеспечить резервирование на уровне Справочника, вы можете развернуть несколько Серверов со Справочником (каждый Сервер будет обслуживать одну или несколько Frontend Групп). Backend - Динамический Кластер может быть настроен на изменение только "Главного" Сервера Справочника, а другие Сервера Справочника для синхронизации данных с Главным Сервером Справочника могут использовать механизмы репликации данных, или же Backend - Кластеры могут быть настроены на одновременное изменение данных на всех Серверах Справочника.