Exchange: DNS балансировка VS HNLB (Скорость переключения клиента)

[@splintorjke2009]

Спасибо! При использовании RRDNS, смотреть, к какому конкретно MBX серверу подключен клиент удобно через Resourse Monitor -> Network и выбрать OUTLOOK.exe. ARP тоже вариант, но только если и клиент и сервер находятся в одной сети.

[@IlyaMCT]

Вах, красавчик. Не знал такой способ.

[@bugunov]

"раз пошла такая пьянка .." и зная Вашу любовь к Powershell, был удивлён использованию "arp-метода" :-) Проще так: Get-NetTCPConnection -OwningProcess (Get-Process -Name OUTLOOK).Id , как мне кажется ;-)

[@andy89pro]

ну и nestat подойдет, например netstat -nb : TCP 10.183.48.173:50909 10.183.36.59:5061 ESTABLISHED [lync.exe] TCP 10.183.48.173:50915 10.183.36.53:60000 ESTABLISHED [OUTLOOK.EXE] TCP 10.183.48.173:50924 10.183.36.53:60001 ESTABLISHED [lync.exe] TCP 10.183.48.173:50984 10.183.36.53:60001 ESTABLISHED [OUTLOOK.EXE] TCP 10.183.48.173:50995 10.183.36.53:60000 ESTABLISHED [UcMapi.exe] TCP 10.183.48.173:51190 10.183.36.52:60001 ESTABLISHED [UcMapi.exe] TCP 10.183.48.173:51479 192.168.66.213:1745 ESTABLISHED [firefox.exe]

[@АлексейАксёнов-м5з]

Извините, у Вас failover в чистом виде. Балансировать некого. В Вашем тесте с HNLB: большая часть времени уходит на подключение баз внутри Exchange. Когда подключённых клиентов много: При использовании RRDNS: для двух серверов, записи в DNS у которых имеют ttl равный 1 минуте - примерно 50% клиентов которые потеряют связь, через 1 минуту смогут подключиться. Остальные позже. В случае с HNLB: после заданных в мониторе периодов проверки доступности сервиса и повторов, подключены будут все, кто потерял связь.

[@IlyaMCT]

На базы уходит до 30 секунд. Вторую часть читал трижды, но так и не понял, что вы хотели сказать.

[@АлексейАксёнов-м5з]

Представьте что клиентских подключений 100 или 1000. Сколько времени понадобится на получение всеми нужного IP адреса?

[@IlyaMCT]

Хоть миллион, их количество никак не влияет на скорость переключения между серверами.

[@ПавелПронин-у8м]

@@IlyaMCT Эксперимент некорректен. Узкое место - DAG. Все ждут его. Чтобы увидеть разницу между RR и NLB надо балансировать подключения к фронтенду. Раньше это был CAS. Собственно, все виды NLB как раз и предназначены именно для защиты уровня фронтенда. Т.е. NLB спасает от падения фронтедов, а не бэкендов. И делает это незаметно для юзера (менее, чем таймаут TCP). В отличие от RR, который по сравнению со всеми NLB - целая вечность... Короче, суп надо есть ложкой, а котлету - вилкой.

[@olegvlasov2252]

А в Exch2010 RRDNS можно настроить, или только в 2013 и выше? Знаю что в 2010 Есть команда Set-ClientAccessArray и вместе с ней обычно используют NLB, для чего разносят отдельно Client Access (NLB) и Mailbox Role (DAG) кластера. Но я решил именно с RRDNS поэксперементировать, может конечно путь к какой-то виртуальной директории забыл поменять, но не заработало.

[@IlyaMCT]

в 2010 обновленном уже давно работает.

[@olegvlasov2252]

Всё, разобрался. Set-MailboxDatabase -RpcClientAccessServer “mail.contoso.com” потерял))

[@IlyaMCT]

:) Да это обязательно в 2010-м

[@MrPelengator]

Спасибо за вебинар. А как корректно обновлять сервера при DNS балансировке? Понятно, что перевести сервер в режим обслуживания, но пользователи же остаются к нему подключены? А сервер остается доступен по сети...

[@IlyaMCT]

Самый простой способ убить временно одну из записей в DNS. И через небольшое время все сами переедут на оставшийся сервер.

[@mcolegon]

Допустим Kemp хотим вывести в кластер. Каким образом к нему будут цепляться клиенты? То есть он будет работать по принципу WNLB, один IP адрес, и MAC который не светится на свиче? Или dns round robin ? Или там своя метода ?

[@IlyaMCT]

Да у двух Kemp будет общий IP.

[@DarthGrooper]

А если пользователи подключаются снаружи сети? DNS Round Robin отпадает уже

[@IlyaMCT]

Нет, работать будет так же. Просто каналов нужно пару.

[@Fullydownable]

А теперь ещё можно и DNS policy прикрутить