В настоящее время я занимаюсь разработкой лабораторной среды для миграции нашей смешанной среды Exchange 2010 и 2013 на Exchange 2016.

Я запускал 1x 2013 и 2x 2016 одновременно в lab в течение нескольких недель, и она хорошо работает - я провел тестирование RPC, OWA, ActiveSync и EWS. Кажется, все работает нормально.

На этой неделе я ' Я попытался завершить развертывание, введя балансировщик нагрузки впереди, с планом обеспечения циклического перебора LB между моими узлами CAS 2013 и 2016 годов. Судя по всему, что я исследовал в 2013 и 2016 годах, CAS полностью совместимы для роли CAS в том, что они с радостью будут прокси-серверами друг друга. И чтобы быть уверенным, что мое ручное тестирование через каждый CAS (без балансировщика нагрузки), похоже, это показывает.

Но теперь, когда я представил HA Proxy впереди, OWA, похоже, не хочет работать должным образом.

Симптомы

Вот некоторые симптомы:

• Когда я вхожу в систему через OWA 2016 в почтовый ящик 2013 года, он выполняет вход правильно, перенаправляет меня и начинает загружать входящие. Но через секунду или две после загрузки почтового ящика меня перенаправляют обратно на страницу входа в OWA, как если бы я никогда не входил в систему.

• Я могу повторить это несколько раз, и, похоже, происходит то же самое, пока я вхожу в систему через CAS 2016.

• Иногда, когда я вхожу через 2016, он просто зависает с надписью «Все еще работаю над этим». Это гораздо реже, чем просто повторный выход из системы.

• Иногда он перенаправляет обратно на страницу входа так быстро, что я даже не могу сказать, что вошел в систему, и не имеет сообщения об ошибке. Это просто мгновенное возвращение на страницу входа.

• Я пробовал использовать достаточно свежие версии Chrome и Firefox на Mac и Windows 8.1. Так что это не проблема конечного устройства.

• Если я вхожу в почтовый ящик 2013 года через OWA на CAS 2013 года, даже через балансировщик нагрузки, кажется, что первый раз вход в систему выполняется правильно.

• У меня есть один IP-адрес. балансировщик нагрузки, который затем перенаправляет трафик на каждый узел CAS в циклическом режиме. Это то, что я использую для тестирования своего LB. Я' у меня есть другие IP-адреса, указывающие непосредственно на отдельные узлы CAS.

• Если я вхожу непосредственно на узел 2016 CAS в почтовый ящик 2013 года, это работает нормально. Это один из тех, в которых я вхожу в CAS 2016 через балансировщик нагрузки.

• Интересно, что я заметил точно такие же проблемы, возникающие даже при входе в почтовый ящик 2016. Поэтому, пока я вхожу в CAS 2016, он снова выходит из системы.

• После успешного входа в систему через CAS 2013 я могу обновить страницу несколько раз, и сеанс останется открытым. Для меня это означает, что проксирование должно в некоторой степени работать нормально после установления сеанса, потому что мой LB является циклическим, поэтому трафик должен перераспределяться по различным узлам CAS каждый раз, когда я обновляю страницу OWA.

Мне кажется довольно очевидным, что есть другие, которые испытывают аналогичные проблемы с Exchange 2010–2016, когда находятся за балансировщиком нагрузки. К сожалению, это наш первый раз, когда мы используем балансировщик нагрузки, так как мы переходим с одного CAS на 3 с этим обновлением до Exchange 2016.

Я нашел несколько сообщений с похожими симптомами:

• https: // devcentral.f5.com/questions/microsoft-exchange-2013-iapp-cant-login-to-owa-or-ecp-if-more-than-one-server-is-active-in-pool

• //www.360ict.nl/blog/owa-does-not-work-after-load-balancing-exchange-2016- while-using-kemp-loadbalancers/

• https://devcentral.f5.com/questions / exchange-2013-session-affinity-again-again

Что я пробовал

• Я подтвердил, что все наши сертификаты внешнего интерфейса SSL (стороннего центра сертификации) совпадают с одним и тем же отпечатком пальца и серийным номером на всех узлах CAS . Я' я читал, что это может повлиять на вещи. Я использую производственный сертификат, чтобы должным образом протестировать свою лабораторию.

• Внутренние сертификаты оставлены как сертификат Microsoft Exchange по умолчанию, и из того, что я прочитал , это нормально. На самом деле я все равно пробовал использовать наш сертификат с подстановочными знаками на бэкэнде, и, похоже, он все сломал.

• Я убедился, что при доступе к CAS 2016 без балансировщика нагрузки все работает нормально. Исходя из этого, я подумал, что если бы я включил полное сохранение сеанса на балансировщике нагрузки, чтобы конкретный пользователь имел дело только с одним CAS, это решило бы проблему. Но тогда мне не следовало этого делать . И это заставляет меня беспокоиться о более глубокой ошибке, которую необходимо решить.

• Я включил отслеживание неудачных запросов IIS. Я нашел несколько отчетов о 500 ошибках для запросов PowerShell. Но они, похоже, связаны с неудавшимися запросами на мониторинг работоспособности и не обязательно совпадают по времени с моими тестами OWA, которые снова регистрируют меня.

• Я провел базовую проверку с помощью Wireshark, чтобы найти что-нибудь странное. Я заметил, что загрузка одной страницы OWA определенно распределяется по крайней мере между несколькими узлами CAS. Иногда оба узла 2016, иногда узел 2016 и 2013.

• Я заметил в моем захвате (на балансировщике нагрузки), что во время одной неудачной попытки входа я продолжал получать повторяющиеся ответы 440 Login Timeout из узлов CAS. В данном случае у меня их несколько, по крайней мере, по одному от каждого узла CAS.

• После первоначального запроса входа в систему существует так много отдельных HTTP-запросов, что трудно определить причину проблемы, но похоже, что это множество Сервис OWA. Запросы svc начинают отправляться браузером, и в какой-то момент все они должны возвращать ту же ошибку 440 Login Timeout в качестве ответа от узла CAS. Затем, в конце концов, мы перенаправляемся обратно на страницу входа в систему.

• Я еще не нашел ничего в своих исследованиях, что на самом деле вызывает 440 таймаутов входа в систему, или ожидаемое поведение и т. Д.

• Я повторно- проверил все мои настройки виртуального каталога относительно нашей производственной установки. Они выглядят нормально.

РЕДАКТИРОВАТЬ: 2017-03-04

• Я пробовал несколько различных комбинаций внутренних и внешних URL-адресов VirtualDirectory. exchange.isp.com.au - это внутренний домен AD (соответствует действующей настройке). Внешний URL-адрес лаборатории - exchlab.isp.com.au.

• Я пробовал:

  • exchlab.isp.com.au как для внутреннего, так и для внешнего использования.
  • exchange.isp.com. au для внутреннего и внешнего.
  • Я придерживался exchlab для внешнего и exchange для внутреннего. Ни одна из этих комбинаций не имела никакого значения.

• С тех пор я также добавил персистентность сеанса на основе файлов cookie в HA Proxy, и, похоже, это изменило ситуацию. Я сделал только настойчивость для OWA и ECP, но остальные не работают. На заметку:

  • Я больше не выхожу из OWA повторно. Он стал намного стабильнее.
  • Это все еще происходит, когда я впервые выхожу из почтового ящика (например, в 2013 году) и вхожу в почтовый ящик другой версии. (например, 2016). Однако после того, как я выхожу из системы в первый раз, теперь я могу успешно снова войти в систему.
  • Если я выхожу из почтового ящика и снова захожу слишком быстро (в течение 10 секунд), то меня часто сразу же выгоняют обратно.

• Я также решил продолжить тестирование HA Proxy для других служб, кроме OWA. И я могу подтвердить:

  • Outlook Anywhere распределяет нагрузку по всем трем узлам CAS и работает нормально.
  • EWS также распределяет нагрузку по всем трем узлам и отлично работает.
  • Active Sync, похоже, хочет пройти только 2x 2016 CASes, но также и балансировка нагрузки в порядке.

Что мне нужно попробовать

• Сбросить все мои виртуальные каталоги
• Повторно синхронизировать учетные записи IIS IUSR: https://technet.microsoft.com/en-us/library/dd789741 (v = exchg. 80) .aspx
• Проверить уровень авторизации IUSR.

Я на самом деле еще этого не делал, так как чувствую, что есть реальная проблема конфигурации. Кроме того, поскольку кажется, что все работает без балансировщика нагрузки, я не вижу в этом помощи.

Дополнительная информация о среде

Еще несколько подробностей о лабораторной среде, в которой я тестирую.

• Конфигурация нашего балансировщика нагрузки взята отсюда: https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_exchange_2013.html#aloha-configuration - мы используем Конфигурация «Разгрузка SSL - Обратный прокси HTTP» (расширенная версия).

• Мы выполняем разгрузку SSL на основе этого руководства: https://serversforhackers.com/using-ssl-certificates-with-haproxy и это руководство: https://jaapwesselius.com/2014/02/28/exchange-2013-sp1-ssl-offloading/

• Наш сервер Exchange 2013 работает под управлением SP1 \ w CU11

• Наш Exchange 2016 ящики работают под управлением CU2. Я намеренно избегаю обновления до CU4, поскольку хочу протестировать и задокументировать плавную процедуру обновления с помощью балансировщиков нагрузки.
• Мы запускаем 2x дополнительных виртуальных машины в качестве выделенных AD. Нет AD на узлах Exchange.

• Все системы Windows (включая AD) работают под управлением Windows 2012 R2.

• Наш маршрутизатор представляет собой Linux-сервер, выполняющий NAT. Балансировщик нагрузки находится в той же подсети / 24, что и серверы Exchange и блоки AD.

• LB HTTP-интерфейс - 0,7, а блоки Exchange - .1, .2 и .3

• Мы также используем простой HTTP перенаправление на выделенные IP-адреса каждого сервера Exchange на .4, .5 и .6. Хотя я планирую перенести это простое перенаправление на балансировщик нагрузки, поскольку он может легко выполнять перенаправления HTTP.

Соответствующие части моей конфигурации балансировщика нагрузки:

    # This is the L7 HTTPS Front End
    # ------------------------------
    # We redirect to different backends depending on the URI
    # Each backend has its own separate health checks. So that each service can fail on an Exchange CAS node without affecting the other services.
    frontend ft_ISP_EXCHANGE_https
      bind 172.16.10.7:80 name INT_http
      bind 172.16.10.7:443 name INT_https ssl crt wildcard.isp.com.au.pem # Specify SSL Cert for offloading.
      mode http
      option http-keep-alive
      option prefer-last-server
      no option httpclose
      no option http-server-close
      no option forceclose
      no option http-tunnel
      timeout client 600s
      log global
      capture request header Host len 32
      capture request header User-Agent len 64
      capture response header Content-Length len 10
      # log-format directive must be written on a single line
      # it is splitted for documentation convnience
      log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ {%sslv/%sslc/%[ssl_fc_sni]/%[ssl_fc_session_id]}\"%[capture.req.method]\ %[capture.req.hdr(0)]%[capture.req.uri]\ HTTP/1.1
      maxconn 1000
      acl ssl_connection ssl_fc # Set ACL ssl_connection if ssl_fc returns TRUE

      # Route request to a different backend depending on the path:
      # http://serverfault.com/questions/127491/haproxy-forward-to-a-different-web-server-based-on-uri
      acl host_mail hdr(Host) -i exchange.isp.com.au
      acl path_slash path /
      acl path_autodiscover path_beg -i /Autodiscover/Autodiscover.xml
      acl path_activesync path_beg -i /Microsoft-Server-ActiveSync
      acl path_ews path_beg -i /ews/
      acl path_owa path_beg -i /owa/
      acl path_oa path_beg -i /rpc/rpcproxy.dll
      acl path_ecp path_beg -i /ecp/
      acl path_oab path_beg -i /oab/
      acl path_mapi path_beg -i /mapi/
      acl path_check path_end -i HealthCheck.htm
      # HTTP deny rules
      http-request deny if path_check
      # HTTP redirect rules
      http-request redirect scheme https code 302 unless ssl_connection # Force SSL
      http-request redirect location /owa/ code 302 if path_slash host_mail # Redirect / to /owa
      # HTTP routing rules -- This is where we decide where to send the request
      # Based on HTTP path.
      use_backend bk_ISP_EXCHANGE_https_autodiscover if path_autodiscover
      use_backend bk_ISP_EXCHANGE_https_ews if path_ews
      # other services go here
      default_backend bk_ISP_EXCHANGE_https_default



      # Backends
    # --------
    # Now we define each backend individually
    # Most of these backends will contain all the same Exchange CAS nodes, pointing to the same IPs
    # The reason we define each backend individually is because it allows us to do separate Health Checks
    # for each individual service running on each CAS node.

    # The failure of one service on a CAS node does not exclude that CAS node from participating in other
    # types of requests. This gives us better overall high-availability design.

    # HTTPS OWA
    # I have added additional comments on this definition, but the same applies to all Exchange HTTPS backends.
    backend bk_ISP_EXCHANGE_https_owa
      balance roundrobin # Use round-robin load balancing for requests
      option http-keep-alive # Enable HTTP Keepalives for session re-use and lowest latency for requests.
      option prefer-last-server # Prefer to keep related connections for a session on the same server.
      # This is not the same as persistence, and is mainly to try and take advantage of HTTP Keepalives.
      # See here for an example of why this is needed: http://stackoverflow.com/questions/35162527/haproxy-keep-alive-not-working-as-expected

      no option httpclose # Disable all options that are counter to keepalives
      no option http-server-close
      no option forceclose
      no option http-tunnel
      mode http # Operate in L7 HTTP Mode (vs TCP mode etc)
      log global
      option httplog
      option forwardfor # Enable insertion of the X_FORWARDED_FOR HTTP Header
      option httpchk GET /owa/HealthCheck.htm # Use L7 HTTP Health Check. This is recommended by Microsoft.
      http-check expect string 200\ OK
      default-server inter 3s rise 2 fall 3
      timeout server 60s
      # Define CAS Nodes for this service. We're using SSL offloading to allow L7 HTTP Checks
      # We've avoided SSL Bridging as that would halve our LB's throughput.
      server ISP_exch16_syd_01 172.16.10.2:80 maxconn 1000 weight 10 check
      server ISP_exch16_syd_02 172.16.10.3:80 maxconn 1000 weight 10 check
      server ISP_exch13 172.16.10.1:80 maxconn 1000 weight 10 check