Настройка синхронизации двух почтовиков iRedMail на двух каналах

от автора

Что имеется

  • Два канала в Интернет от разных провадеров
  • Два разных пула IP адресов (1.1.1.1/28, 2.2.2.1/28)
  • Два DNS сервера на собственных площадках поддерживающих зону doman.my с MX записями mail.domen.my — 1.1.1.1; mail.domen.my — 2.2.2.2
  • Две записи PTR у двух провайдеров (1.1.1.1 — mail.domen.my, 2.2.2.2 — mail.domen.my)
  • сертификат SSL на домен *.doman.my
  • Внутри DMZ почтовики будут иметь IP 192.168.1.10 и 192.168.1.20

Что требуется
Обеспечение отказоустойчивости почтового сервера при выходе из строя одного из серверов почты или падении канала одного из провайдеров. Возможность проводить тех. работы, тестирование новых модулей и т.д. на одном из почтовых серверов. Организация подобия кластера.
Схема
image

Почему так
iRedMail — OpenSoures почтовик, основа postfix, dovecot, openldap, антивирус, антиспам (смотрим на оф. сайте). Все пакеты нативные, поддерживают системные обновления apt-get update, upgrade, поддержка русского языка и в админке тоже. Предвижу высказывания что все эти конструкторы не есть хорошо — «я все поставлю и настрою», спорить не буду… это просто мой опыт — делюсь чем есть.

1. Устанавливаем Ubuntu 12.04 LTS x64 (на забываем про SSH, ибо как рулить удаленно… 🙂 )
переходим к станице руководства по инсталляции iRedMail. Используем все как прописано — ubuntu 12.04 LTS, RAM — 250Mb, HDD — 10G (для почтовика маловато, но мы ящики будет хранить на отдельном сервере)
2. Проведем подготовительные мероприятия
Для хранения почты мы будем использовать примонтированую папку на другом сервере, что даст нам возможность отключать или перегружать любой из кластерных почтовых серверов без боязни потерять доступ к ящикам пользователей.

Есть два варианта монтирования SAMBA и NFS, лучшее решение, думаю NFS ибо нативно, говорят скорость побольше и меньше нагружает процессор. Опишу оба варианта, Вам решать что использовать.

2.1 NFS
На сервере-хранилище почты устанавливаем поддержку NFS:

$sudo apt-get install nfs-kernel-server nfs-common 

Создаем папку для хранения почты

$sudo mkdir /var/vmail-str 

Создаем пользователя vmail c UID 1001 (если ставили iRedMail на почтовике на чистую систему он будет именно с таким UID) с домашней папкой /var/vmail-str и шелом /sbin/nologin.
Правим exports

$sudo vim /etc/exports /var/vmail-str 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check) 

Тут будут храниться наши письма, ее мы открываем по NFS.

2.2 SMB (на данный момент не работает — ошибка с доступом/правами)

Устанавливаем пакет SMBFS

sudo apt-get install smbfs  mkdir /var/vmail 

— хранилище почты, сюда примонтируем шару.

В /etc/fstab добавляем строчку

//192.168.1.3/vmail /var/vmail smbfs user=pochta,pass=pismo,rw,utf8,dir_mode=0777,file_mode=0777 0     0 

Существует нерешенная проблема: почтовик не может получить доступ к папке хранилища почты на сервере SMB, хотя права стоят 0777 root:root на все папки в директории /var/vmail/. Надо копать в сторону прав на стороне SMB сервера

3. На клиенте (вернее на одном из серверов с iRedMail) подключаем папку по NFS
Устанавливаем клиента NFS

$sudo apt-get install nfs-common 

Правим /etc/fstab
добавляя строчку

192.168.1.3:/var/vmail-str /var/vmail nfs user,rw	0	0 

4. Установка самого iRedMAIL достаточно хорошо описана на оф. сайте производителя.
www.iredmail.org/doc.html

Установка производилась на Ubuntu server 12.04 LTS
Далее все как в стандартном руководстве

	hostname -f... 	post-t1.domen.my 

и далее по мануалу.
После установки хотя бы одного сервера необходимо проверить права в директории /var/vmail (помните, она у нас подключается с сервера MAIL-STORAGE)
должно быть так:

	$sudo ls -l /var/vmail 	drwxr-xr-x 4 root  root  4096 июля   5 03:30 backup 	drwx------ 2 vmail vmail 4096 июня  18 16:03 sieve 	drwx------ 6 vmail vmail 4096 сент. 10 13:23 vmail1 

При необходимости меняем, зайдя на наш MAIL-STORAGE:

	$sudo chown -R vmail:vmail /var/vmail/vmail1 	$sudo chown -R vmail:vmail /var/vmail/sieve 

5. Установка iRedAdmin-Pro (мы купили)
распаковываем архив

$tar xfz iRedAdmin-Pro-LDAP-1.7.2.tar.bz2 /usr/share/apache2 

переписываем права

$sudo chown -R iredadmin:iredadmin iRedAdmin-Pro-LDAP-1.7.2/ 

меняем симлинк

$sudo ln -s /usr/share/apache2/iRedAdmin-Pro-LDAP-1.7.2/ /usr/share/apache2/iredadmin 

копируем настройки

$sudo cp /usr/share/apache2/iRedAdmin-0.1.8/settings.ini /usr/share/apache2/iRedAdmin-Pro-LDAP-1.7.2/ 

Можно заходить в админку

https://ip_server/iredadmin/

login:postmaster@domen.my pass: %который% вводили при установке

6. Повторяем п.п. 3, 4 и 5
для второго и N-ого серверов. В итоге мы получим N серверов с iRedMail имеющих в качестве хранилища пользователей — свои LDAP-ы и хранилища почты один массив — MAIL-STORAGE.

7. Настройка синхронизации LDAP
Выбираем способ репликации — зеркало (при отключении любого сервера все остальные продолжают работать и обслуживать клиентов)
С оф. сайта выдержка.

Читать

18.2.3. Репликация в режиме зеркала (MirrorMode)
Режим зеркала — это гибридная конфигурация, предоставляющая все гарантии целостности данных, как при репликации с одним главным сервером, одновременно предоставляя высокую доступность, как при репликации с несколькими главными серверами. В режиме зеркала два поставщика настраиваются на репликацию друг от друга (как в случае с несколькими главными серверами), однако используется некий внешний интерфейс, который направляет все запросы на обновление только на один из двух серверов. В случае отказа первого поставщика, указанный выше интерфейс переключит все запросы на обновление на второго поставщика, и он, в свою очередь будет принимать и обрабатывать их. При восстановлении и перезапуске отказавшего поставщика он автоматически запросит все изменения с функционирующего поставщика и пересинхронизируется.
18.2.3.1. Положительные моменты репликации в режиме зеркала
Решение с высокой доступностью (high-availability, HA) как для операций обновления каталога, так и для последующих получений синхронизаций репликами потребителей.
До тех пор, пока хотя бы один поставщик работоспособен, можно безопасно принимать операции обновления.
Серверы-поставщики реплицируются друг от друга, таким образом они постоянно находятся в актуальном состоянии и постоянно готовы заменить друг друга (горячая замена).
Syncrepl также позволяет северам-поставщикам пересихронизироваться после простоя любой продолжительности.
18.2.3.2. Отрицательные моменты репликации в режиме зеркала
Репликация в режиме зеркала — это не то, что принято называть решением с несколькими главными серверами, поскольку операции обновления в определённый момент времени принимаются только одним из зеркальных серверов.
Режим зеркала можно обозначить как два активных сервера с горячей заменой друг друга (Active-Active Hot-Standby), поэтому для принятия решения, какой из серверов-поставщиков сейчас является активным, требуется внешний сервер (slapd в режиме прокси) или устройство (аппаратный балансировщик нагрузки).
Несколько иное управление резервным копированием:
Если создаётся резервная копия самой базы данных Berkeley и периодически создаются резервные копии файлов журнала транзакций, то, пока не будет сделана следующая резервная копия базы данных, требуется снимать копии с файлов журнала одного и того же сервера из пары зеркальных серверов.
Дельта-Syncrepl всё ещё не поддерживается.

7.1 Первым делом добавляем строчку в /etc/ldap/slapd.conf

# Modules.  moduleload  syncprov.la  

ибо без этого вообще никакой синхронизации не будет а добавление этого параметра описано не явно.

Далее настраиваем поставщика/потребителя 192.168.1.10
В основных директивах (в начало файла /etc/ldap/slapd.conf) добавим ID сервера

serverID 1		# у каждого сервера свой 

В конец файла добавляем:

index objectClass,entryCSN,entryUUID                eq,pres 

Сразу настраиваем как потребителя

syncrepl      rid=001               provider=ldap://192.168.1.20               bindmethod=simple               interval=00:00:10:00               binddn="cn=vmail,dc=domen,dc=my"               credentials=yzjiFdasfkoZSDbladfjoweotHgWiNxFHcb               searchbase="dc=domen,dc=my"               schemachecking=off               type=refreshAndPersist               retry="60 +" 

Самое сложное не ошибиться и найти binddn credentials
А ищем из в файле: iRedMail.tips в том каталоге откуда устанавливали почтовик или в письме пришедшем админу к которому будем подключаться (192.168.1.20) Ищем строчку

 * LDAP bind dn (read-only): cn=vmail,dc=domen,dc=my, password: yzjiFdasfkoZSDbladfjoweotHgWiNxFHcb 

Вот это и будет наши логин и пароль.
Еще надо дописать функции поставщика в /etc/ldap/slapd.conf:

mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 

7.2 Далее настраиваем поставщика/потребителя 192.168.1.20

В основных директивах (в начало файла /etc/ldap/slapd.conf) добавим ID сервера

serverID 2 

В конец файла добавляем:

index objectClass,entryCSN,entryUUID                eq,pres 

Сразу настраиваем как потребителя

syncrepl      rid=001               provider=ldap://192.168.1.10               bindmethod=simple               interval=00:00:10:00               binddn="cn=vmail,dc=domen,dc=my"               credentials=lkfjalfkoZSDbladfjoweotHSDFasjfASfj               searchbase="dc=domen,dc=my"               schemachecking=off               type=refreshAndPersist               retry="60 +" 

Ищем в файле: iRedMail.tips в том каталоге откуда устанавливали почтовик или в письме пришедшем админу к которому будем подключаться (192.168.1.10) Ищем строчку

 * LDAP bind dn (read-only): cn=vmail,dc=domen,dc=my, password: lkfjalfkoZSDbladfjoweotHSDFasjfASfj 

Вот это и будет наши логин и пароль.
Еще надо дописать функции поставщика в /etc/ldap/slapd.conf:

mirrormode on overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 

8. Перепускаем LDAP на обоих серверах и смотрим лог:

$ sudo service slapd restart && sudo tail -f /var/log/syslog | grep slpad $ sudo service slapd restart && sudo tail -f /var/log/syslog | grep slpad 

Если выскачело что то подобное

Oct 24 11:35:03 server slapd[6992]: slap_client_connect: URI=ldap://192.168.1.10 DN="cn=vmail,dc=domen,dc=my" ldap_sasl_bind_s failed (-1) Oct 24 11:35:03 server slapd[6992]: do_syncrepl: rid=001 rc -1 retrying 

Значит что то не так и надо внимательно править slapd.conf

10. Проверяем
Заходим в админку одного и другого сервера.

https://192.168.1.10/iredadmin/  https://192.168.1.20/iredadmin/ 

Добавляем пользователя, домен, и т. д. И смотрим его появление на втором сервере.
Проделываем действия по удалению, изменению, добавлению данных на один сервер и проверяем из появление на другом.

11. Заключение
Мы получили почтовый кластер работающий на двух интернет каналах по двум белым IP.
При условии что в DNS у нас прописаны два IP для одного доменного имени
mail.domen.my — 1.1.1.1
mail.domen.my — 2.2.2.2
и доступности двух DNS под разным каналам имеем:
При отказе одного из каналов или выходе из стоя (отключение на обслуживание) одного из почтовых серверов клиенты будут иметь доступ и обслуживание на втором почтовом сервере.
Также достигается некоторая разгрузка каналов и серверов при рандомной выдачи IP почтовиков DNS серверами.

12. Источники

ссылка на оригинал статьи http://habrahabr.ru/post/156059/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *