none
Клиентские подключения DAG RRS feed

  • Вопрос

  •  Доброго времени суток.

    Собственно интересует мнение коллег, так как никогда не встречался с таким подходом.

    Обычно для высокой доступности либо рекомендуют ставить аппаратное решение для Exchange 2016, либо бюджетный Round Robin.

    Но вот чтобы клиентам отдавали IP адрес кластера DAG - никогда.

    Интересует мнение коллег на сколько такое решение правильное и имеет ли место быть?

    P.S.

    Говорят что ранее переключение, в случае падения, работало. Сейчас нет, поэтому думаю сделать на Round Robin.

    3 июля 2018 г. 12:26

Ответы

  • Во-первых, DAG ip может находиться только на одном сервере, а это сразу же означает, что ВСЕ клиенты будут долбиться именно на этот адрес. Это не будет проблемой, если у вас пара серверов в DAG в одной локации. Ну а если локаций много и серверов DAG с десяток, да ещё и каждый из них нагружен более чем на 50%?

    Угадайте что будет с тем единственным обладателем DAG ip, которому посчастливится словить весь клиентский трафик.

    Это ещё пол проблемы. Самый сложно прогнозируемый момент случится тогда, когда по какой-то причине этот ip переедет на другой сервер и поток клиентов хлынет на него. 

    • Помечено в качестве ответа dmz_m 3 июля 2018 г. 13:31
    3 июля 2018 г. 12:49
  • На самом деле IP DAG для клиентских подключений в некоторых конторах работает ещё с Exchange 2010, технически оно работает, отказоустойчивость обеспечивает, балансировку - не обеспечивает.

    Правильно написали, что MS это не поддерживает.

    Еще вот тут по пунктам написано http://no-one-uses-email-anymore.com/why-cant-i-point-my-clients-to-the-dag-cluster-ip/

    и у Ильи Рудя видео про балансировку https://www.youtube.com/watch?v=WBHusvx7hKE


    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    • Помечено в качестве ответа dmz_m 3 июля 2018 г. 13:31
    3 июля 2018 г. 13:04

Все ответы

  • Решение это полностью неправильное по одной причине - DAG ip не предназначен для этого. Это если коротко.

    А так попытайтесь подумать логически почему это плохо.

    p.s. RR не бюджетный, он полностью бесплатный)) 


    3 июля 2018 г. 12:46
  • Во-первых, DAG ip может находиться только на одном сервере, а это сразу же означает, что ВСЕ клиенты будут долбиться именно на этот адрес. Это не будет проблемой, если у вас пара серверов в DAG в одной локации. Ну а если локаций много и серверов DAG с десяток, да ещё и каждый из них нагружен более чем на 50%?

    Угадайте что будет с тем единственным обладателем DAG ip, которому посчастливится словить весь клиентский трафик.

    Это ещё пол проблемы. Самый сложно прогнозируемый момент случится тогда, когда по какой-то причине этот ip переедет на другой сервер и поток клиентов хлынет на него. 

    • Помечено в качестве ответа dmz_m 3 июля 2018 г. 13:31
    3 июля 2018 г. 12:49
  • А так попытайтесь подумать логически почему это плохо.

            В моём случае это не работает, что тут думать.

            Я изучал BP и рекомендации Microsoft, и о IP DAG я не помню. Вот и решил поинтересоваться...

    3 июля 2018 г. 12:55
  • Это ещё пол проблемы. Самый сложно прогнозируемый момент случится тогда, когда по какой-то причине этот ip переедет на другой сервер и поток клиентов хлынет на него. 
            В данном случае меня больше не устраивает что пользователи либо не переезжают, либо это происходит очень очень долго.
    3 июля 2018 г. 13:00
  • На самом деле IP DAG для клиентских подключений в некоторых конторах работает ещё с Exchange 2010, технически оно работает, отказоустойчивость обеспечивает, балансировку - не обеспечивает.

    Правильно написали, что MS это не поддерживает.

    Еще вот тут по пунктам написано http://no-one-uses-email-anymore.com/why-cant-i-point-my-clients-to-the-dag-cluster-ip/

    и у Ильи Рудя видео про балансировку https://www.youtube.com/watch?v=WBHusvx7hKE


    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    • Помечено в качестве ответа dmz_m 3 июля 2018 г. 13:31
    3 июля 2018 г. 13:04
  •   Большое спасибо коллеги!

     Собственно что хотел то и услышал. Значит мой взгляд в сторону RR - верный.

     

      

    3 июля 2018 г. 13:12
  • Если нет возможности купить нормальный балансировщик, то да.

    Относительно бюджетные https://kemptechnologies.com/loadmaster-family-virtual-server-load-balancers-application-delivery-controllers/

    народ ещё колдовал с HAPROXY на линуксе, даже вроде готовые конфигурации были. 


    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    3 июля 2018 г. 13:18
  •   Большое спасибо коллеги!

     Собственно что хотел то и услышал. Значит мой взгляд в сторону RR - верный.

     

      

    Конечно верный.

    Если смотреть в сторону haproxy, то опять же тут имеет смысл балансировать только внешние подключения, когда внешние юзеры долбятся на один внешний ip, за которым уже стоит балансер, раскидывающий запросы по разным серверам (которые могут располагаться и в разных сайтах).

    Тут вопрос только как сделать отказоустойчивым сам балансер. Либо это виртуалка в отказоустойчивом кластере, либо это две разных виртуалки на разном железе и плавающий ip между ними. Последний вариант я разобрал в статье на своем блоге: https://blog.bissquit.com/unix/debian/prostejshij-otkazoustojchivyj-balansirovshhik-layer-4/

    3 июля 2018 г. 13:31
  • Но у вас получается скорее не балансировка, а отказоустойчивость, когда только одна нода обрабатывает подключения?

    Тот же NLB имеет один IP на всех узлах, и все узлы принимают пакет, но обрабатывает его только один узел. Вот только это никто уже не использует для новых Exch.

    3 июля 2018 г. 13:47
  • Но у вас получается скорее не балансировка, а отказоустойчивость, когда только одна нода обрабатывает подключения?

    Тот же NLB имеет один IP на всех узлах, и все узлы принимают пакет, но обрабатывает его только один узел. Вот только это никто уже не использует для новых Exch.

            Насчёт NLB в Exchange 2016 Тут говорят что нельзя

    • Изменено dmz_m 3 июля 2018 г. 14:01
    3 июля 2018 г. 13:58
  • p.s. RR не бюджетный, он полностью бесплатный)) 

          Это я так шутил, видимо удалось...
    3 июля 2018 г. 13:59
  • Но у вас получается скорее не балансировка, а отказоустойчивость, когда только одна нода обрабатывает подключения?

    Тот же NLB имеет один IP на всех узлах, и все узлы принимают пакет, но обрабатывает его только один узел. Вот только это никто уже не использует для новых Exch.

            Насчёт NLB в Exchange 2016 Тут говорят что нельзя

          Ну да, это и имею в виду. Видимо только для шарика это ещё актуально.
    3 июля 2018 г. 14:46
  • Проблема NLB в том, что он работает на уровне сервера, а не сервиса. Если остановить IIS или SMTP, то NLB будет принимать клиентские соединения, как будто ничего не было. Поэтому MS его не рекомендует.


    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    4 июля 2018 г. 10:00
  • Если нет возможности купить нормальный балансировщик, то да.

    Относительно бюджетные https://kemptechnologies.com/loadmaster-family-virtual-server-load-balancers-application-delivery-controllers/

    народ ещё колдовал с HAPROXY на линуксе, даже вроде готовые конфигурации были. 


    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    Его не всегда даже требуется покупать :-)

    К примеру, нынешняя бесплатная версия Citrix Netscaler (чисто софтовая - поставляется в формате VM под основные гипервизоры) в качестве балансировщика имеет ограничение только по скорости (20мбит/с, чего для сотни-другой пользователей с Outlook в режиме кеширования должно хватить), поддерживает High Availability по схеме Active-Passive, имеет включенными многие фичи, свойственые платным балансировщикам (собственно - все, входящие в версию Standard): и мониторинг служб на серверах, и балансировку по L4, а не только по L7(как NLB), и возможность использования в рахнообразных схемах хоть 1-arm, хоть 2-arm, хоть Direct Server Return и т.д., и т.п. (фич в Netscaler'е - их много).

    Единственная возможная засада: лицензию нужно обновлять каждый год, и халява может внезапно кончиться.


    Слава России!

    4 июля 2018 г. 10:32
  • А ещё, поскольку нынешние версии Exchange требует балансировать только HTTP(S), и не имеют никаких особых требований по Affinity (ну, кроме RPC over HTTP, который есть вещь вымирающая), то можно попробовать балансировку на базе обратного прокси, к примеру - ARR+IIS (будет время - обязательно попробую).

    Слава России!

    4 июля 2018 г. 10:35
  • А ещё, поскольку нынешние версии Exchange требует балансировать только HTTP(S), и не имеют никаких особых требований по Affinity (ну, кроме RPC over HTTP, который есть вещь вымирающая), то можно попробовать балансировку на базе обратного прокси, к примеру - ARR+IIS (будет время - обязательно попробую).

    Слава России!

    Если поднимать сервер только ради IIS+ARR, то зачем платить за винду, когда можно поднять аналог (nginx, haproxy) на линуксах полностью бесплатно? К тому же более надежный и производительный (речь о haproxy к примеру). 
    4 июля 2018 г. 10:50
  • А ещё, поскольку нынешние версии Exchange требует балансировать только HTTP(S), и не имеют никаких особых требований по Affinity (ну, кроме RPC over HTTP, который есть вещь вымирающая), то можно попробовать балансировку на базе обратного прокси, к примеру - ARR+IIS (будет время - обязательно попробую).


    Слава России!

    Если поднимать сервер только ради IIS+ARR, то зачем платить за винду, когда можно поднять аналог (nginx, haproxy) на линуксах полностью бесплатно? К тому же более надежный и производительный (речь о haproxy к примеру). 

    Зачем платить за винду - это, с одной стороны, вообще вопрос философский, а с другой, если вы захотите для Linux поддержку от вендора, то это будет уже совсем не бесплатно. А если ещё учесть более высокий порог вхождения в администрирование Linux, то у Windows таки преимущества есть. Впрочем, к настройке ARR на IIS эти преимущества отношения уже не имеют - там всё совсем не user-friendly.

    Но я тут вообще не об этом, а имел в виду несколько другое - попробовать собрать решение из компонентов, которые MS не позиционирует как части решения, и посмотреть что будет - чисто из любопытства.


    Слава России!

    4 июля 2018 г. 11:03

  • Но я тут вообще не об этом, а имел в виду несколько другое - попробовать собрать решение из компонентов, которые MS не позиционирует как части решения, и посмотреть что будет - чисто из любопытства.


    Слава России!

    Нормально все будет))

    Что nginx, что haproxy работают отлично. А вот IIS+ARR тоже не проверял

    4 июля 2018 г. 11:45
  • У KEMP тоже такое есть, там правда HA между нодами не сделать и обновлять лицензию раз в три месяца или вообще месяц.

    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    4 июля 2018 г. 13:39
  • тут вопрос квалификации, согласитесь, что аналог на linux еще настроить надо правильно, что не так просто, как винду.

    Youtube канал о Exchange Server
    Группа Facebook по Exchange Server
    Чат в Telegram по Exchange Server
    Группа Facebook по PowerShell

    4 июля 2018 г. 13:40