Отказоустойчивый кластер + балансировка Exchange и Lync

[Fess88]

Здравствуйте, друзья!
Назрела передо мной задача организовать отказоустойчивость двух Microsoft - сервисов - Exchange 2016 (несколько серверов с контроллером домена) и Lync (мессенджер) в пределах большой ЛВС, с несколькими филиалами, и с использованием VLAN.
Нужно чтобы в случае недоступности одного почтового сервера, балансировщик автоматически перекидывал на использование другого. На первом место стоит отказоустойчивость, балансировка будет плюсом.
Посоветуйте бесплатные OpenSource -решения для данной ситуации. Сам я посматриваю в сторону связки двух прокси с nginx + keepalived.
Если есть хорошие платные решения, то тоже буду рад услышать советы/отзывы. Заранее спасибо!

[Уваров А.С.]

Зачем городить огород? Начиная с Exchange 2010 есть штатные DAG + NLB.

https://technet.microsoft.com/ru-ru/library/dd979799(v=exchg.150).aspx
https://technet.microsoft.com/ru-ru/library/cc725691(v=ws.11).aspx

[Fess88]

NLB в 2016 Exchange не поддерживается, вроде как. И Microsoft рекомендуют использовать сторонние балансеры.
https://social.technet.microsoft.com/Forums/office/en-US/1a3f5657-e3e5-41a5-b20e-dae10440c1e0/exchange-2016-no-nlb-what-are-the-alternatives?forum=Exch2016HADR
http://loadbalancerblog.com/blog/2016/02/top-15-questions-exchange-2016
https://kemptechnologies.com/ru/microsoft-load-balancing/load-balancing-microsoft-exchange-2016/

Since Exchange 2016 uses the Windows Failover Clustering feature for creating a DAG, you can no longer use Windows NLB as a load balancing solution and you have to use a 3rd party (hardware) load balancer.


Если я не  прав, прошу сильно не ругать, т.к я Linux-админ, и одна из задача на данный момент - достичь отказоустойчивости и балансировки между серверами Exchange. По Винде знаний не очень много, поэтому буду рад любым советам/ссылкам.
Спасибо!

[Fess88]

Как вариант, можно использовать HaProxy,  ибо через nginx не работает авторизация в AD.

[Уваров А.С.]

NLB в 2016 Exchange не поддерживается, вроде как.

Да вы сказочно смелый человек, если сразу хотите разворачивать Exchange 2016 в такой конфигурации.

Как вариант, можно использовать HaProxy,  ибо через nginx не работает авторизация в AD.

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

[Fess88]

Еще такой вопрос, уважаемые коллеги.

Остановился примерно на таком варианте:

- отказоустойчивый балансировщик (2 сервера с keepalived), которые в случае падения одного из них подхватывают IP второго.

Задача - балансить траффик на 443 порт (SSL), веб -порты, и почтовые - smtp и imap.

Думал сделать так: На каждом узле keepalived (обеспечивает отказоустойчивость балансировщиков), и haproxy - балансит траффик на уровне TCP.


Haproxy в плане балансировщика пофункциональнее, да и веб-морда к ней есть, для просмотра минимальной статистики, и обширные возможности при балансе http.

Данная схема в целом хорошая, или проще балансить тем же keepalived?


Заранее спасибо за ваши советы!

[Const]

Заранее спасибо за ваши советы!

Вот читаю я вас и дивлюсь с вас. Если у вас не самопальные серванты ака десктопы, и не принято заматывать синей изолентой. сколько-либо вменяемая интеграция подразумевает бюрократический процесс и формирование технического задания, а это документирование и описание системы. После чего внедрением и интеграцией занимаются ответственные люди и не на основе форумных советов "я не доктор, но посмотреть могу"
Я к тому, что сталкивался с таким, когда два независимых ввода каналов связи или электричества на самом деле были якобы независимые, т к физически были проложены вместе и отказоустойчивость была во многом бумажной. Подходящие в одних случаях инструменты могут не подходить в других или являться суть иллюзией

Флуд, +45 Администрация.

[Fess88]

Вот читаю я вас и дивлюсь с вас. Если у вас не самопальные серванты ака десктопы, и не принято заматывать синей изолентой. сколько-либо вменяемая интеграция подразумевает бюрократический процесс и формирование технического задания, а это документирование и описание системы. После чего внедрением и интеграцией занимаются ответственные люди и не на основе форумных советов "я не доктор, но посмотреть могу"
Я к тому, что сталкивался с таким, когда два независимых ввода каналов связи или электричества на самом деле были якобы независимые, т к физически были проложены вместе и отказоустойчивость была во многом бумажной. Подходящие в одних случаях инструменты могут не подходить в других или являться суть иллюзией

Все уже внедрено до меня, иначе бы я не стал спрашивать. Лучше бы по дель отписались.