Добрый день!Есть 2 филиала Ф1 и Ф2. К Ф1 подведены 2 провайдера П1 и П2, к Ф2 подведены П1 и П3.
В нормальном режиме работы оба филиала работают через П1, т.к. Ф2 работает через тунель и поднятый vpn П1 до Ф1. При его падении оба филиала переключаются на П2 и П3 соответственно.
Основной почтовый сервер C1 на CentOS находится в Ф1, резервный C2 в Ф2 также на CentOS.
Задача - при каких либо перебоях у провайдера П1, прозрачно перейти на провайдеры П2 и П3 как для внешних клиентов почтового сервера, так и для внутренних (доменных) клиентов.
При падении П1 работаем с С1 через П2, при падении П1 и П2, а такое тоже возможно, когда нет напряжения в Ф1, работам с С2 через П3.
Получается несколько этапов:
1) когда падает провайдер П1 (один или совместно с П2), нужно понять, что он(и) упал(и)
2) изменение в dns - глобальном и локальном
3) при поднятии канала П1 и vpn автоматически вернуть основные настройки сети.
На почтовых серверах CentOS, dns на контроллерах (основном в Ф1 и резервном в Ф2) домена MS Server2012 + Cisco ASA 5505 в филиалах Ф1 и Ф2.По почтовым серверам
Один является полнофункциональным почтовым сервером, на второй дублируются письма через механизм репликации Cyrus-imap для бэкапа.
Задача так же сделать чтобы при выходе из строя основного сервера можно было подключиться ко второму из почтового клиента для приёма и отправки почты.
На основном установлен postfix+cyrus-imapd+amavis+spamassassin(с базой фильтров в MySQL)+postgrey+opendkim+opendmarc+mailman+roundcube и всё это дело нужно как-то синхронизировать на резервный сервер. Задача в основном в том чтобы синхронизировать именно настройки, т.к. сами письма реплицируются и по идее сам cyrus может отслеживать изменения между мастером и репликой.
> При падении П1 работаем с С1 через П2, при падении П1 и
> П2, а такое тоже возможно, когда нет напряжения в Ф1, работам
> с С2 через П3.простите, не совсем понял как вы на Ф1 будете работать с С2, когда у вас все ПХ на Ф1 лежать ...
>> При падении П1 работаем с С1 через П2, при падении П1 и
>> П2, а такое тоже возможно, когда нет напряжения в Ф1, работам
>> с С2 через П3.
> простите, не совсем понял как вы на Ф1 будете работать с С2,
> когда у вас все ПХ на Ф1 лежать ...Уважаемый Pahanivo
это вариант
>>когда нет напряжения в Ф1т.е. Ф1 сидит без работы вообще, такое, к сожалению, тоже возможно - промышленная зона!
Надо чтоб Ф3, Ф4 и т.д. могли работать через Интернет с корпоративной почтой с Ф2, т.е. сервера С2 (резервного) через П3. А Ф1 в это время пока будет чаи гонять и бамбук курить )))))))
ну тогда единственно рассово верный вариант это вынос обоих серваком для начала во вне в надежный датацентр как пишуть нижее
>[оверквотинг удален]
> Задача - при каких либо перебоях у провайдера П1, прозрачно перейти на
> провайдеры П2 и П3 как для внешних клиентов почтового сервера, так
> и для внутренних (доменных) клиентов.
> При падении П1 работаем с С1 через П2, при падении П1 и
> П2, а такое тоже возможно, когда нет напряжения в Ф1, работам
> с С2 через П3.
> Получается несколько этапов:
> 1) когда падает провайдер П1 (один или совместно с П2), нужно понять,
> что он(и) упал(и)
> 2) изменение в dns - глобальном и локальномЗачем? Пока что я не вижу проблемы, которая бы не решалась статичными приоритетами в MX и статичными настройками почтового сервера:
В DNS-зоне:
MX 20 prov1.f1.mail.domain.ru
MX 19 prov2.f1.mail.domain.ru
MX 10 prov1.f2.mail.domain.ru
MX 10 prov3.f2.mail.domain.ruВообще динамически менять DNS — идея не очень хорошая, как минимум из-за кеширования записей. Представьте, что DNS — это публичный API вашей инфраструктуры, если вы его меняете так или иначе — его пользователям надо под это подстраиваться, а, значит, будут (обоснованные) жалобы пользователей. Лучше изменять вашу внутреннюю кухню — маршрутизацию, внутренние IP-адреса и т.д.
Насчёт репликации настроек — Ansible, или что-либо аналогичное в руки. Да, несколько дней понадобится на плотное «въезжание», зато потом все преимущества шаблонизации и централизации будут вам доступны, экономя время и страхуя от ряда ошибок в критических ситуациях («не там не так поправил не тот файл»).
С репликацией в cyrus не работал, да и в целом опыта с ним мало, так что даже ничего пытаться советовать не буду, чтобы не ляпнуть глупость. :)
>>[оверквотинг удален]
>> Задача - при каких либо перебоях у провайдера П1, прозрачно перейти на
>> провайдеры П2 и П3 как для внешних клиентов почтового сервера, так
>> и для внутренних (доменных) клиентов.
>> При падении П1 работаем с С1 через П2, при падении П1 и
>> П2, а такое тоже возможно, когда нет напряжения в Ф1, работам
>> с С2 через П3.
>> Получается несколько этапов:
>> 1) когда падает провайдер П1 (один или совместно с П2), нужно понять,
>> что он(и) упал(и)Настройте правильно PBR на глюзах этих филиалов.
> Настройте правильно PBR на глюзах этих филиалов.Можно подробнее и как это может помочь ?
Есть еще филиалы Ф3, Ф4, т.д. и сотрудники в любой точке страны - им необходимо, чтоб у них был доступ к корпоративному почтовому серверу всегда (imap, https).
MSOutlook MX записи не смотрит
> Есть еще филиалы Ф3, Ф4, т.д. и сотрудники в любой точке страны
> - им необходимо, чтоб у них был доступ к корпоративному почтовому
> серверу всегда (imap, https).
> MSOutlook MX записи не смотритOutlook на них и не должен смотреть, да.
Как мне видится, вам надо скорее в каждом филиале иметь полностью автономный почтовый сервер, но чтобы между всеми почтовыми серверами происходила быстрая репликация. В принципе, если письма хранятся в maildir, то репликацию можно настроить даже без участия почтового сервера, на уровне файловой системы — я имею в виду решения вроде lsyncd. Что там с cyrus'ом — не знаю.
То есть, у каждого филиала своя веб-морда, свой cyrus и что там у вас ещё, и даже если все кабели в округе переедут экскаваторами, ваши пользователи доступ к почте в целом не потеряют.
> 3) при поднятии канала П1 и vpn автоматически вернуть основные настройки сети.Для OpenVPN есть возможность указать старт-стоп скрипты.
[...]
Купите VPS в надёжном DC, установите там почтарь и перестаньте занимаццо ... ну как раз вот этим всем :)
> Купите VPS в надёжном DCНе можем выносить почтовый сервер во вне по политическим (для кого-то религиозным) причинам ...
> Не можем выносить почтовый сервер во вне по политическим (для кого-то религиозным)
> причинам ...разделяйте мух и котлеты - веру и технологию.
>> Не можем выносить почтовый сервер во вне по политическим (для кого-то религиозным) причинам ...
> разделяйте мух и котлеты - веру и технологию.Вот всеми девятью щупальцами - ДА!
Мыло - оно открытая система (почти всегда) :) И даже если ты всё насквозь защитил и зашифровал у _себя_ - все твои письма аккуратно лежат у твоих адресатов на gmail\yandex и прочих :)
To: IgorKH2000
Я _вдоволь_ напрыгался по этим граблям. Так вот - если нет денег\желания выносить инвариант в ДЦ и взвалить проблемы по обеспечению доступности _на_них_ то _единственно_работающий_ в промышленном грэйде вариант это:... барабанная дробь ...
готовить _БАБЛО_ для:
- найма _команды_ опытных и мотивированных сетевиков (сколько эта банда будет вам стоить ...);
- закупки оборудования, выбранного этой бандой (а не самого чипового что сможете найти);
- закупки _симметричных_ каналов до эджа провайдеров, в дополнение к дслям;
- закупка своей AS (или AS-es) и настройка BGP всех поторохов на эдже и внутри тоже;
- найм толковой команды электриков, которые шурупят в _современном_ оборудовании, а не в шитовых времён паровых генераторов (тоже будет стоить);
- закупка электрооборудования выбранного этой командой (так же как у сетевиков :) Сразу хочу вас спросить - вы видели UPS пром уровня? А дизеля?;
- О!!! Забыл! Дизелисты вам тоже будут нужны :-)))
- найм толковой команды кондиционерщиков (то же не за руппь\пучок :);
- закупка хладо- и фильтро- оборудования и выбранного этой командой ( :-))) );Ну что мы дошли до середины списка :-))))))))))
А вы мля думали в сказку попали?!?!Покажи мой пост руководству.
Если не проймёт - БЕГИ ОТ ТУДА! Я серьёзно.как то так,
Не Ваш,
_