Лучший отвечающий
Перенос роли CAS

Вопрос
-
Добрый день!
Достался в наследство почтовый сервере MS Exchange 2010 с ролями "всё на одном" на базе Windows 2008R2.
Есть задача - развернуть DAG.
Первым этапом хочу разнести роли: на существующем оставить только Mailbox, а CAS/HUB перекинуть на другой сервер, который в будущем будет "балансировщиком" DAG.
Поднял второй сервер MS Exchange в организации в теми же обновлениями что и существующий. Поставил на него роли CAS/HUB. Роль HUB переносится на новый сервер без проблем: поднял на новом, добавил во все коннекторы, удалил на старом.
Не понял как перенести роль CAS при условии, что используется Auodiscover, ActiveSync и немного OWA . Надо чтобы без downtime ибо почта нужна 24/7/365. Подскажите как сделать? А то все пишут, что надо со старого удалять роль, а на новом ставить и настраивать всё заново.
Заранее спасибо
26 сентября 2016 г. 5:59
Ответы
-
Да все просто ведь, выше уже написано. Ставите 2 сервера с полным набором ролей CAS+HT+MBX. Собираете на них DAG, делаете Round Robin на них в DNS, а в качестве сервера свидетеля используете какой нибудь файловый или другой сервер, от него кроме шареной папки ничего не требуется.
- Изменено Ivan.Basov 29 сентября 2016 г. 13:50
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 9 ноября 2016 г. 12:40
29 сентября 2016 г. 13:47
Все ответы
-
думаю небольшой простой по времени будет в любом случае.
Я бы поставил роль CAS сразу и на новый сервер (одновременно со старым), спокойно все настроил (в том числе пересоздал бы сертификат) и уже потом проводил мероприятия по удалению роли с первого сервера.
- Предложено в качестве ответа Alexander RusinovModerator 26 сентября 2016 г. 7:45
26 сентября 2016 г. 6:35 -
Дополню,
Ставьте уже тогда оба новых CASa, настраивайте балансировку, переносите на новые сервера autodiscover и т.д., а уже затем удаляйте CAS со старого сервера.
26 сентября 2016 г. 8:10 -
Добрый день!
Достался в наследство почтовый сервере MS Exchange 2010 с ролями "всё на одном" на базе Windows 2008R2.
Есть задача - развернуть DAG.
Первым этапом хочу разнести роли: на существующем оставить только Mailbox, а CAS/HUB перекинуть на другой сервер, который в будущем будет "балансировщиком" DAG.
Поднял второй сервер MS Exchange в организации в теми же обновлениями что и существующий. Поставил на него роли CAS/HUB. Роль HUB переносится на новый сервер без проблем: поднял на новом, добавил во все коннекторы, удалил на старом.
Не понял как перенести роль CAS при условии, что используется Auodiscover, ActiveSync и немного OWA . Надо чтобы без downtime ибо почта нужна 24/7/365. Подскажите как сделать? А то все пишут, что надо со старого удалять роль, а на новом ставить и настраивать всё заново.
Заранее спасибо
а что значит балансировщиком DAG?
У вас каким методом будет балансировка?
Зачем разносить роли, если все равно нет полной отказоустойчивости либо более подробно опишите архитектуру.
Да и не нужно удалять роль со старого, пусть будет два с полным набором ролей.
scientia potentia est
My blog26 сентября 2016 г. 8:44 -
"Балансировщиком" я назвал сервер-свидетель.
Решил в итоге сделать NLB из CAS между старым и новым сервером.
Интересно, а если сломается свидетель, DAG развалится? Или свидетель тоже можно сделать отказоустойчивым?
- Изменено GoodwiN 27 сентября 2016 г. 8:59
27 сентября 2016 г. 8:57 -
Windows nlb вместе с dag на одних серверах не поддерживается. Вы как реализовали?
scientia potentia est
My blog27 сентября 2016 г. 9:20 -
Тут дается неплохое объяснение: https://technet.microsoft.com/ru-ru/library/cc731739(v=ws.11).aspx
Как показано в предыдущем примере, в кластере с конфигурацией «Большинство узлов» при расчете большинства учитываются только узлы.
Как показано в предыдущем примере, в кластере с конфигурацией «Большинство узлов и дисков» при расчете большинства учитываются узлы и диск-свидетель.
Конфигурация кворума «Большинство узлов и общих файловых ресурсов»
В кластере с конфигурацией «Большинство узлов и общих файловых ресурсов» при расчете большинства учитываются узлы и файловый ресурс-свидетель. Эта конфигурация аналогична конфигурации кворума «Большинство узлов и дисков», показанной в предыдущем примере, за исключением того, что свидетелем является общая папка, доступная всем узлам кластера, а не диск хранилища кластера.
В кластере с конфигурацией «Только диск» число узлов не влияет на достижение кворума. Кворумом является диск. Но при потере связи с диском кластер становится недоступным.
27 сентября 2016 г. 9:24 -
Еще никак. Это была идея. И я не знал, что NLB и DAG на одном сервере не работают.
Видимо всё-таки придётся переносить роли CAS/HUB
27 сентября 2016 г. 10:02 -
Большинство современных клиентов умеют переключаться при Днс раунд робин. Поэтому если нет железки, можно реализовать просто днс балансировкой. С точки зрения МС они одинаково поддерживаемые, но нерекомендуемые(wnlb,dns round robin). Рекомендована железная балансировка.
scientia potentia est
My blog- Изменено Mikhail SartaevMVP 27 сентября 2016 г. 10:46
27 сентября 2016 г. 10:45 -
Тем не менее, вариант 2CAS/HT (wnlb) + 2MBX(dag) вариант работоспособный на 2010 и поддерживаемый, хотя и не рекомендуемый. Основные минусы пожалуй лицензии на Win и Exch в количестве 4х штук на каждый продукт и необоснованная утилизация процессоров, памяти, больше точек отказа и т.д. Надо ли оно вам?
- Изменено Ivan.Basov 27 сентября 2016 г. 11:01
27 сентября 2016 г. 11:00 -
Изначально идея была такая: 2 сервера DAG (диски с разных хранилищ, роли только Mailbox) + 1 сервер-свидетель (с ролями CAS/HUB)
Исходя из комментариев и прочитанного будем придерживаться этого плана. Придется договариваться о выключении почты, чтобы удалить роли CAS/HUB с существующего Mailbox и настроить CAS на новом сервере.
28 сентября 2016 г. 9:09 -
Это хреновое решение. Сделайте либо два сервера с полным набором и между ними Днс раунд робин. Или 2 dag +2cas с wnlb. И не надо ничего выключать при обоих вариантах. Вы ж dag поднимите.
scientia potentia est
My blog28 сентября 2016 г. 9:46 -
Поддержу коллегу, решение с одним CASом выглядит странным...28 сентября 2016 г. 10:51
-
может быть тс хотел что-то типа такого реализовать: поднять виртуализованный CAS+HUB на отдельном сервере и настроить гиперви-реплику с другим аналогичным сервером виртуализации. Если бы один из хостов падал, Exchange cas+hub поднимался бы на другом. Пусть был бы небольшой рассинхрон по данным (гиперви-реплика вроде бы восстанавливает на некоторое время назад, а не точную копию на момент падения)
суть в том, что cas+hub не хранит данные локально, а значит не нуждается в сложных планах резервного копирования и восстановления. По сути на нем надо бэкапить только конфиги.
Также не знаю как такая схема будет работать на Exchange 2010, но для 2013 она выглядит в некоторой степени разумно, поскольку в 2013 вся сложная логика с CAS была снята в пользу роли MBX, а HUB по сути стал частью MBX. Поправьте меня, если я где-то ошибаюсь, очень интересно услышать ваше мнение.
- Изменено Egor Vasilev 28 сентября 2016 г. 10:58
28 сентября 2016 г. 10:58 -
Это 2013 не хранит локально, а в 2010 все локально хранится.
scientia potentia est
My blog28 сентября 2016 г. 11:19 -
Идея может быть хреновая, но дешевая.
CAS/HUB - виртуалка на VMWare, которая каждый день полностью бекапится на ленту. Время восстановления с ленты меньше 15 минут. Поэтому нет смысла делать NLB из CAS - экономим кучу денег на лицензии. В случае аварии просто восстановим сервак с ленты.
29 сентября 2016 г. 9:08 -
т.е. 3 сервера и 15 минут простоя минимум лучше чем 2 сервера без простоя?
При том что снапшоты виртуалки Exchange не поддерживаются и могут нормально не восстановиться?
scientia potentia est
My blog- Изменено Mikhail SartaevMVP 29 сентября 2016 г. 9:30
29 сентября 2016 г. 9:29 -
Два сервера это как? Кто сервер-свидетель?
Опишите, как обойтись двумя серверами.
29 сентября 2016 г. 13:41 -
Да все просто ведь, выше уже написано. Ставите 2 сервера с полным набором ролей CAS+HT+MBX. Собираете на них DAG, делаете Round Robin на них в DNS, а в качестве сервера свидетеля используете какой нибудь файловый или другой сервер, от него кроме шареной папки ничего не требуется.
- Изменено Ivan.Basov 29 сентября 2016 г. 13:50
- Помечено в качестве ответа Vasilev VasilMicrosoft contingent staff 9 ноября 2016 г. 12:40
29 сентября 2016 г. 13:47