Что имеется
Что требуется
Обеспечение отказоустойчивости почтового сервера при выходе из строя одного из серверов почты или падении канала одного из провайдеров. Возможность проводить тех. работы, тестирование новых модулей и т.д. на одном из почтовых серверов. Организация подобия кластера.
Схема
Почему так
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:
Создаем папку для хранения почты
Создаем пользователя vmail c UID 1001 (если ставили iRedMail на почтовике на чистую систему он будет именно с таким UID) с домашней папкой /var/vmail-str и шелом /sbin/nologin.
Правим exports
Тут будут храниться наши письма, ее мы открываем по NFS.
2.2 SMB (на данный момент не работает — ошибка с доступом/правами)
3. На клиенте (вернее на одном из серверов с iRedMail) подключаем папку по NFS
Устанавливаем клиента NFS
Правим /etc/fstab
добавляя строчку
4. Установка самого iRedMAIL достаточно хорошо описана на оф. сайте производителя.
www.iredmail.org/doc.html
Установка производилась на Ubuntu server 12.04 LTS
Далее все как в стандартном руководстве
и далее по мануалу.
После установки хотя бы одного сервера необходимо проверить права в директории /var/vmail (помните, она у нас подключается с сервера MAIL-STORAGE)
должно быть так:
При необходимости меняем, зайдя на наш MAIL-STORAGE:
5. Установка iRedAdmin-Pro (мы купили)
распаковываем архив
переписываем права
меняем симлинк
копируем настройки
Можно заходить в админку
6. Повторяем п.п. 3, 4 и 5
для второго и N-ого серверов. В итоге мы получим N серверов с iRedMail имеющих в качестве хранилища пользователей — свои LDAP-ы и хранилища почты один массив — MAIL-STORAGE.
7. Настройка синхронизации LDAP
Выбираем способ репликации — зеркало (при отключении любого сервера все остальные продолжают работать и обслуживать клиентов)
С оф. сайта выдержка.
7.1 Первым делом добавляем строчку в /etc/ldap/slapd.conf
ибо без этого вообще никакой синхронизации не будет а добавление этого параметра описано не явно.
Далее настраиваем поставщика/потребителя 192.168.1.10
В основных директивах (в начало файла /etc/ldap/slapd.conf) добавим ID сервера
В конец файла добавляем:
Сразу настраиваем как потребителя
Самое сложное не ошибиться и найти binddn credentials
А ищем из в файле: iRedMail.tips в том каталоге откуда устанавливали почтовик или в письме пришедшем админу к которому будем подключаться (192.168.1.20) Ищем строчку
Вот это и будет наши логин и пароль.
Еще надо дописать функции поставщика в /etc/ldap/slapd.conf:
7.2 Далее настраиваем поставщика/потребителя 192.168.1.20
В основных директивах (в начало файла /etc/ldap/slapd.conf) добавим ID сервера
В конец файла добавляем:
Сразу настраиваем как потребителя
Ищем в файле: iRedMail.tips в том каталоге откуда устанавливали почтовик или в письме пришедшем админу к которому будем подключаться (192.168.1.10) Ищем строчку
Вот это и будет наши логин и пароль.
Еще надо дописать функции поставщика в /etc/ldap/slapd.conf:
8. Перепускаем LDAP на обоих серверах и смотрим лог:
Если выскачело что то подобное
Значит что то не так и надо внимательно править slapd.conf
10. Проверяем
Заходим в админку одного и другого сервера.
Добавляем пользователя, домен, и т. д. И смотрим его появление на втором сервере.
Проделываем действия по удалению, изменению, добавлению данных на один сервер и проверяем из появление на другом.
11. Заключение
Мы получили почтовый кластер работающий на двух интернет каналах по двум белым IP.
При условии что в DNS у нас прописаны два IP для одного доменного имени
mail.domen.my — 1.1.1.1
mail.domen.my — 2.2.2.2
и доступности двух DNS под разным каналам имеем:
При отказе одного из каналов или выходе из стоя (отключение на обслуживание) одного из почтовых серверов клиенты будут иметь доступ и обслуживание на втором почтовом сервере.
Также достигается некоторая разгрузка каналов и серверов при рандомной выдачи IP почтовиков DNS серверами.
12. Источники
- Два канала в Интернет от разных провадеров
- Два разных пула 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
Что требуется
Обеспечение отказоустойчивости почтового сервера при выходе из строя одного из серверов почты или падении канала одного из провайдеров. Возможность проводить тех. работы, тестирование новых модулей и т.д. на одном из почтовых серверов. Организация подобия кластера.
Схема
Почему так
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
— хранилище почты, сюда примонтируем шару.
В /etc/fstab добавляем строчку
Существует нерешенная проблема: почтовик не может получить доступ к папке хранилища почты на сервере SMB, хотя права стоят 0777 root:root на все папки в директории /var/vmail/. Надо копать в сторону прав на стороне SMB сервера
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 всё ещё не поддерживается.
Режим зеркала — это гибридная конфигурация, предоставляющая все гарантии целостности данных, как при репликации с одним главным сервером, одновременно предоставляя высокую доступность, как при репликации с несколькими главными серверами. В режиме зеркала два поставщика настраиваются на репликацию друг от друга (как в случае с несколькими главными серверами), однако используется некий внешний интерфейс, который направляет все запросы на обновление только на один из двух серверов. В случае отказа первого поставщика, указанный выше интерфейс переключит все запросы на обновление на второго поставщика, и он, в свою очередь будет принимать и обрабатывать их. При восстановлении и перезапуске отказавшего поставщика он автоматически запросит все изменения с функционирующего поставщика и пересинхронизируется.
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. Источники
