» Kerio Connect (ex Kerio MailServer)

Народ,подскажите, не кто не сталкивался с задачей построить 2-а почтовика 1-го домена, аля Кластера.
Задача в чем состоит:
Есть 2-а сервера на Керио Коннект, есть 2-а офиса, нужно разместить в обоих офисах сервера, облуживают они 1-н домен contora.com. При отказе инета в офисе №1, по запесям МХ начинает принемать 2-й сервер в офисе №2 всю почту, когда инет в офисе №1 востанавливаеться, сервер офиса №1, синхрониться с 2-м и заберает то что ему надо, и на оборот...
(Керио что на 1-м, что на 2-м стоит на OpenSUSE 11.2 x32).

ArtCont
Кластеризация немного описания:
[more=Кластер в kerio взято с kerio-rus]

Цитата:

Могу процитировать коллегу из американского офиса, который написал мне подробно про эту настройку:

"....Существует 4 площадки (США, Чехия, Великобритания, Россия), на каждой из которых установлен почтовый сервер. Почта во внешний мир отправляется через главный сервер в штаб-квартире. Проверить это решение Вы можете в тестовой сети. Для этого Вы можете установить бесплатную, полнофункциональную версию с нашего сайта. Мы также можем предоставить вам ключи NFR (not for resale) для дополнительных тестов.

Распределение одного домена между несколькими инстанциями Kerio MailServer
Данная статья описывает шаги по настройке распределения почтовых ящиков в рамках единого почтового домена среди многочисленных инстанцией Kerio MailServer.
Похожая статья, в которой используется альтернативный подход к решению поставленной задачи описан на английском в статье Базы Знаний Kerio: <http://www.kerio.com/manual/kms/en/sect-example4.html> .

Когда применим описываемый ниже сценарий?
• Если организация с единым именем почтового домена имеет распределенную географическую структуру, может понадобиться установка отдельного почтового сервера на каждой площадке.
• В крупных организациях со структурой удаленных офисов может потребоваться установка отдельного почтового сервера в каждом офисе для распределения нагрузки почтовой переписки и для достижения лучшей маштабируемости.

Принцип подхода

Поскольку все почтовые сервера в топологической системе «звезда» используют тот же самый почтовый домен, требуется, чтобы каждый почтовый сервер знал месторасположение каждого почтового ящика. Это не позволит почтовым серверам получать почту от неправильных отправителей или слепо посылать почту через несколько серверов до тех пор, пока нужный сервер-получатель наконец будет найден. Принцип настройки подобного внедрения включает в себя три основных момента: для каждого почтового сервера внутри системы «звезда» должно быть заведено уникальное имя, должен быть также создан список, содержащий уникальные имена почтовых серверов системы и информацию об их расположении в Интернет, и, наконец нужно, чтобы в свойствах каждого почтового ящика было указано, к какому уникальному имени почтового сервера он относится.

Лицензирование

Распределенная структура подразумевает, что на каждом почтовом сервере системы должен быть установлен лицензионный ключ на общее количество пользователей, даже несмотря на то, что пользователи распределены по всей системе. Это означает, что лицензионный ключ, установленный на каждом площадке, должен включать в себя общее количество пользователей почтового домена. Более подробная информация может быть получена у представителя отдела продаж вашего региона. Мы согласны предоставить Вам ключ на общее количество пользователей, который Вы установите на каждую инстанцию почтового сервера Kerio. Это изначально противоречит нашему лицензионному соглашению, но поскольку Ваш случай внедрения представляется не совсем стандартным для Kerio, мы готовы сделать исключение.
Прочие условия
Если будет использоваться архивация писем, то в архив будут включаться почтовые сообщения, маршрутизируемые на другие инстанции Kerio MailServer в структуре домена.
Настройка DNS для входящей почты может подразумевать несколько записей MX. Каждый почтовый сервер в распределенной доменной системе может быть настроен с отдельной записью MX. Добавление нескольких записей MX предоставит дополнительную отказоустойчивость обработки входящего потока писем. Поскольку все пользователи должны быть созданы на каждом сервере в распределенной доменной системе, будет довольно сложно развернуть подобную систему, поскольку каждый сервер должен содержать одинаковую пользовательскую базу. По этой причине рекомендуется использовать Active Directory, ибо в таком случае пользовательская база будет управляться централизованно и каждая инстанция Kerio MailServer будет получать информацию о своих пользователях напрямую из Активного Каталога.
Ограничения данного сценария внедрения
Чтобы воспользоваться преимуществом работы с объектами сотрудничества (groupware objects) , пользователи совместно работающие с объектами (календари, задачи и пр.) должны быть зарегистрированы на одном и том же почтовом сервере. Поэтому если пользователи распределены между несколькими физическими серверами, то таким пользователям будет невозможно использовать совместно папки или просматривать информацию о доступности/занятости пользователя (free/busy service) между собой. Вдобавок, каждый почтовый сервер будет иметь собственный набор публичных папок.
________________________________________


Определение имени для каждого почтового сервера

Как было сказано выше, каждый почтовый сервер распределенной доменной системы должен иметь уникальное в системе имя, которое должно быть известно всем остальным серверам распределенной системы. Данное значение устанавливается в конфигурационном файле mailserver.cfg (“%systemdrive%/program files/Kerio/mailserver”).
Cледует найти группу настроек под заголовком 'Cluster'. Обратите внимание, что перед внесением изменений в конфиг, необходимо остановить работу почтового сервера. Следующие параметры должны быть модифицированы:

• BackendModeEnabled – Установить значение '1'
• FrontendModeEnabled - Установить значение '1'
• BackendName - укажите уникальное имя данного сервера
• BackendMasterPassword – Данное значение опционально. Можете воспользоваться нижеприведенным примером.


<table name="Cluster">

<variable name="BackendModeEnabled">1</variable>

<variable name="FrontendModeEnabled">1</variable>

<variable name="BackendName">tampa</variable>

<variable name="BackendMasterPassword">NUL:some_password</variable>

<variable name="BackendAcl"></variable>

<variable name="SimpleUserLookup">0</variable>

<variable name="MaxFreeBusyBackendRedirects">1</variable>

</table>


Создание сводной таблицы уникальных имен серверов

Каждый почтовый сервер распределенной доменной системы должен иметь таблицу имен других серверов, с указанием их имен в Интернет или IP адресом. Данная таблица настраивается в списке под заголовком 'BackendServer' в том же конфигурационном файле mailserver.cfg.
Следущие значения должны быть изменены: не упомянутые значения списка 'BackendServer' менять не следует.
• Name – Уникальное имя почтового сервера
• Hostname – IP адрес или имя почтового сервера (в зависимости от настройки DNS)
• Password - Данное значение опционально. Можете воспользоваться нижеприведенным примером


<list name="BackendServer">

<listitem>

<variable name="Name">tampa</variable>

<variable name="Hostname">10.0.0.142</variable>

<variable name="Password">NUL:some_password</variable>

<variable name="Default">0</variable>

<variable name="Description"></variable>

</listitem>

<listitem>

<variable name="Name">san_diego</variable>

<variable name="Hostname">10.0.1.14</variable>

<variable name="Password">NUL:some_password</variable>

<variable name="Default">0</variable>

<variable name="Description"></variable>

</listitem>

<variable name="Name">boston</variable>

<variable name="Hostname">10.0.2.13</variable>

<variable name="Password">NUL:some_password</variable>

<variable name="Default">0</variable>

<variable name="Description"></variable>

</listitem>

</list>


Приведенный пример включает в себя три почтовых сервера – членов распределенной доменной структуры. Для каждого нового сервера требуется создавать запись, заключенную в тэги <list> </list>.
Обратите внимание, что сам локальный сервер тоже должен быть упомянут в данном списке. Другими словами, данная таблица должна быть одинаковой на всех почтовых серверах распределенной системы.

Определения уникальных имен для почтовых ящиков
Каждый почтовый ящик в распределенной системе должен относится к указанному серверу, определяемому по уникальному имени. Данная привязка ящика к серверу указывается в настройках свойств пользователя, название опции 'HomeServer'. Для того, чтобы задать данное значение, нужно зажать клавиши shift+сtrl, щелкнуть правой клавишей мыши на пользователе и выбрать в контекстном меню пункт “редактировать” (см. приатаченный файл).
У вас должна появиться возможность указать значение в пункте “Данные почтового ящика хранятся на сервере с идентификатором узла” ('node ID' или 'Home Server' в английской версии)."

[/more]

Ну и конечно справка по распределённым доменам.

Ruza
По поводу кластера Я читал, вопрос по справке, если не сложно, пните в ее сторону..
И вопрос в том, будет ли один сервер принемать инфу назначеную другому серверу, если тот в офлайне на данный момент. А не давать отлуп...

ArtCont
Задачу свою опиши подробнее? Тебе нужно что бы письма не пропали или что бы сервис 24\7 колашматил?


Добавлено:
Ruza
здаётся мне что по ссылке доступно описание включение распределённых доменов на старых версиях керио (не Connect) когда я тестировал - это выглядело именно как текущие распределённые домены, но не как ни система failover cluster.

faust72rus

Цитата:

здаётся мне что по ссылке доступно описание включение распределённых доменов на старых версиях керио (не Connect) когда я тестировал - это выглядело именно как текущие распределённые домены, но не как ни система failover cluster.

Приведенное описание с kerio-rus даёт картинку как это работает, а не коротенькое описание справки типа нажмите тут и там...

Как у тебя распределение настроено в плане топологии?

Ruza
Всё стандартно. Звезда. А там можно как то по другому распределённость настроить?

Добрый день. Kerio Connect 7.0.1 build 1249
На рабочих станциях стоят Outlook 2007 + koff. У пользователей есть стандартные адреса типа логин@домен (из AD). Но некоторые пользователи, естественно, заказывают себе другие адреса типа ххх@домен. Подскажите плиз, как сделать, чтобы по умолчанию письма отправлялись от ххх@домен?

Vasiliskk
В настройках koc на последней закладке можно нарисовать нужного тебе отправителя.

brassnet
А можно чуть поподробнее плиз? Что имеется ввиду под koc? Админка коннектора или что?

Vasiliskk
В консоли Kerio в свойствах пользователя на вкладке Адреса эл. почты вбиваешь нужный адрес. В консоли KOC устанавливаешь этот адрес как адрес отправителя.

faust72rus

Цитата:

Всё стандартно. Звезда. А там можно как то по другому распределённость настроить?

Я не о том... Мне по барабану рисунки и геометрия.
Меня интересует количество записей МХ в ДНСах и являются ли эти МХы членами одного распределённого домена?

Vasiliskk
В вебинтерфейсе под юзером тоже можно настрить адреса отправителя по умолчанию.

Никто не подскажет, можно ли ставить KMS вместе с KWF на одну машину, являющуюся роутером? При этом обе программы нужно подсоединять к LDAP. Боюсь, что совместно работать с LDAP не будут.

Заранее спасибо!

Доброго времени суток!

Поставлена такая задача, необходимо настроить почту так чтобы письма не сохранялись на локальных рабочих станциях, а были только на сервере. В exchange вроде такое возможно сделать, а возможно ли такое в в KMS или Kerio Connect. У пользователей установлен MS Outlook 2007. Сеть: Домен Windows. Никак не удается найти информацию по этой теме.

VoyZA


Цитата:

можно ли ставить KMS вместе с KWF на одну машину, являющуюся роутером

Да можно, правда KWF стоял давно. решил поставить KMS...почтовиком нормально пользователи подхватились...если на обоих продуктах будешь использовать антивирусы то появиться второй avserver.exe отжирающий не менее 150 метров...а так вполне нормально

Добавлено:
INoskov

В сторону IMAP смотрите

INoskov

Цитата:

Никак не удается найти информацию по этой теме.

Где то так...
Для соединения с сервером использовать KOC (Kerio OutLook Connector) тот что не offline. И ещё можно всех загнать на вебинтерфейс.

VoyZA

Цитата:

Никто не подскажет, можно ли ставить KMS вместе с KWF на одну машину, являющуюся роутером? При этом обе программы нужно подсоединять к LDAP. Боюсь, что совместно работать с LDAP не будут.

Можно однозначно. Как раз с LDAP при правильной настройке проблем меньше всего.
А вот с включенными антивирусами и protocol inspector'ами на SMTP/POP3 проблем намного больше. Так что рекомендую заранее отключить проверку почтового трафика в KWF.

у меня юзеры на веб-интерфейсе сидят, даже говорят, что так удобнее...

Народ, подскажите какие службы Керио Коннект использует для хранения локальных пользователей и для Ксластерной синхронизации.. Серв не очь мощьный... хочу по выключать все лишнее...
Зарание Спасибо!!!

ArtCont
Если Ты о службах в административной консоли, то отключай все, кроме тех по которым у Тебя коннектятся юзвери. (поп и смтп).

Ruza
В MX только основной сервер. Остальные серверы есть только как A записи (для того что бы центральный узел их видел). Вся исходящая и входящая почта домена отправляется и приходит через центральный узел.

faust72rus

чтобы всё ровно работало надо несколько MX указать на все сервера которые входят в распределённый домен, с различным приоритетом, наименьший приоритет будет иметь центральный сервер.

Tihon_one

Цитата:

чтобы всё ровно работало надо несколько MX указать на все сервера которые входят в распределённый домен, с различным приоритетом, наименьший приоритет будет иметь центральный сервер.

Это из разряда рекомендаций желательных к выполнению. А так, кто как хочет так и настраивает...

Я вообще к чему спрашивал - хотел предложить faust72rus, если бы у него было настроено несколько МХ в распределённом домене, выключить мин на 10 первичный МХ для теста. Но видать не судьба, а самому лепить распределёнку с нуля времени нету . А надо проверить отказоустойчивость в кластерах/распределнном домене, а то действительно мало инфы по этой теме.

Ruza
Предлагай.

Только если речь идёт о создании режима работы в котором письма не теряются (то о чём я спрашивал ArtCont) то у меня есть две MX записи одна идёт на второй сервер в котором нет пользователей, а просто есть пустой домен и в свойствах домена стоит переадресация на другой домен - вызываемая удалённым серовером, он держит все письма у себя пока лежит основной сервер. Основной сервер после восстановления получает все письма с резервного сервера по протоколу ETRN.

Добавлено:
решение не из разряда 24/7, но для такого сервиса вполне подходит.

lehazmei, Ruza
Спасибо огромное за ответы!

faust72rus

Цитата:

Предлагай.

Так смысла нет.
Это придётся перестраивать ДНСы и изменять иаршрутизацию почтового трафика...
Хотя если готов, то давай проверим.

Ruza
Опиши что хочешь проверить. Просто много разных конфигурации работы я уже попробовал. А ДНС провайдерские я могу через веб форму в течении 15 минут поправить.

faust72rus
Я думаю если МХы в одном домене и знают о распределённых пользователях, то должны удерживать почту по умолчанию (???).

Смысл эксперимента:
Записи:
МХ 10 = firstserver.firma.com
MX 20 = secondserver.firma.com
MX 30 = mail.leftdomain.com (ETRN)

Выключаем МХ 10 и отправляем письмо юзеру у которого основной сервер именно МХ 10. По всем канонам письмо должно уйти на МХ 20 который знает о юзере но не может отфорвардить сразу.
Вопрос удержит ли МХ 20 письмо или пошлёт отправителя?
По логам соединений можно посмотреть что ответит МХ 20.

МХ 30 - для того что бы не потерялись письма во время выключения.

Ruza
Ок. В выходные протестирую о результатах сообщу. Мысль мне нравится

faust72rus
Cool! Если что пиши в профильную аську... Мож чего ещё придумаю, раз есть возможность

Помимо кластеризации кстати можно таки открыть документацию и посмотреть такое вот:
http://manuals.kerio.com/kms/en/sect-example5.html

Минус такого решения естественно будет в том что если на этот бекап мх валить почту для тех кого в нём незаведено, то принимать он будет для всех юзеров в домене @какойтовашдомен а когда первый сервер наконец прососётся начнёт сливание почты на него.

Зато никаких ковыряний в конфигах и лишних мыслей.

Ruza

Цитата:

Это из разряда рекомендаций желательных к выполнению. А так, кто как хочет так и настраивает...

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

Цитата:

просто всегда казалось. что документация ограждает нас, пользователей, от изобретения велосипеда.

Всё это верно, бумага написана правильно...
Но "жестокая правда жизни", особенно в "постсовке", иногда отличается от того что написано в документации. И у небольшой фирмы попросту нет возможности получить 2-3 IP адреса, для поддержки вторичных МХов, по тем или иным причинам.