Назад | Перейти на главную страницу

Сосуществование Exchange 2016 - OWA не входит в систему, когда находится за балансировщиком нагрузки

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

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

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

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

Симптомы

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

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

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

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

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

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

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

Дополнительная информация об окружающей среде

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

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

    # 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

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

Я сопротивлялся этому «потому что мне не следовало этого делать», во всех технических статьях Microsoft говорится, что в этом больше нет необходимости, да и вообще не рекомендуется.

Но я уступил и в итоге добавил настойчивости и для OWA, и для ECP. В результате проблема не была решена полностью, но стала едва заметной. Единственный раз, когда у меня возникают проблемы, я выхожу из OWA в одном почтовом ящике, а затем сразу же вхожу в другой. Даже в этом случае он выгоняет вас один раз, но если вы попытаетесь войти снова, он будет работать нормально.

После этого проблемы не возникает. Кроме того, я заметил остающуюся проблему только при переходе с почтового ящика 2013 на 2016 год.

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

Поскольку мы используем прокси-сервер HA, было несложно добавить в конфигурацию постоянство на основе файлов cookie уровня 7. Фактически, на то, чтобы выяснить, потребовалось всего около 5 минут:

# HTTPS Outlook Web App (OWA)
backend bk_EXCHANGE_https_owa
  cookie LB01 insert indirect nocache # <-- Added this
  balance roundrobin
  mode http

  ...

  # Added the "cookie <name>" at the end of each CAS node definition
  # These names must be unique to each node.
  server n1_exch16_syd_01 172.16.10.2:80 maxconn 1000 weight 10 check cookie EXCH16-SYD-01
  server n1_exch16_syd_02 172.16.10.3:80 maxconn 1000 weight 10 check cookie EXCH16-SYD-02
  server n1_exch13 172.16.10.1:80 maxconn 1000 weight 10 check cookie EXCH13-SYD