Exchange 2013 wprowadza fundamentalne zmiany w sposobie, w jaki Outlook łączy się ze skrzynką pocztową, które ma wpływ na rozwiązania używane do dystrybucji połączeń i zapewniania wysokiej dostępności dla serwerów Client Access. W pierwszej części, dwuczęściowej serii artykułów, chciałbym opisać zmiany w Load Balancingu połączeń inicjowanych przez Outlooka. W drugiej części skupię się na tym jak działa automatyczne przełączenie na ośrodek zapasowy przy zastosowaniu wspólnej nazwy dla obu lokalizacji.

Koniec RPC over TCP

W Exchange 2013 zamiast protokołu RPC (over TCP), Outlook wykorzystuje protokół RPC over HTTPS znany z poprzednich wersji Exchange, jako Outlook Anywhere. Zmiana nastąpiła również, jeśli chodzi wartość RPC Endpoint, czyli docelowego miejsca połączenia RPC. Ten parametr połączenia, nie zawiera wartości CAS Array, tak jak było to w Exchange 2010. W Exchange 2013 RPC Endpoint konstruowany jest na podstawie GUID skrzynki pocztowej oraz domeny SMTP użytkownika. RPC Endpoint może wyglądać np. tak:

Affinity – co się z nim stało?

W środowisku Exchange 2010 klient Outlook nawiązywał połączenie RPC over TCP z usługą RPCClientAccessService znajdującą się na serwerze z zainstalowaną rolą Client Access Server. W celu zapewnienia wysokiej dostępności dla tych połączeń, konieczne było stworzenie wspólnej przestrzeni nazw dla serwerów CAS w postaci obiektu CAS Array. Oprócz tego, potrzebny był load-balancer, który zapewniałby tzw. „Affinity”, czyli nawiązywania połączeń RCP over TCP przez danego klienta Outlook, zawsze z tym samym serwerem CAS.

W środowisku Exchange 2013 na serwerach CAS nie znajdziemy usługi RPCClientAccessService. Zamiast tego, połączenie RPC over HTTP nawiązywane przez klienta Outlook jest odbierane przez usługę World Wide Web Publishing Service na serwerze CAS. Następnie, żądanie RPC jest wyodrębnianie z pakietu HTTP i odczytywany jest z niego RPC Endpoint. Ten parametr zawiera Mailbox GUID, łączącego się użytkownika. GUID zostaje użyty do wyszukania w Active Directory informacji o bazie skrzynkowej, w której znajduje się skrzynka użytkownika. Następnie serwer CAS kontaktuje się z Active Managerem, znajdującym się na serwerze Mailbox, w celu ustalenia serwera z aktywną kopią bazy. Po odnalezieniu tej informacji, połączenie RPC over HTTP jest PROXOWANE przez serwer CAS do serwera Mailbox.

W związku z tym nie jest istotne, do którego serwera CAS trafi nasze połączenie RPC over HTTP, czyli nie jest konieczne zapewnienie „Affinity”. Nasze pakiety RPC over HTTP mogą trafiać do różnych serwerów CAS, a nasze połączenie ze skrzynką wciąż będzie zestawione. Jest to spowodowane tym, że pakiety zawsze trafiają do tego samego serwera Mailbox, na którym znajduje się aktywna kopia bazy skrzynkowej z naszą skrzynką pocztową. Serwery CAS, które pośredniczą w połączeniu pełnią tylko rolę bezstanowych serwerów „proxujących”
połączenia

Jakiego Load Balancera użyć?

Powyższe zmiany powodują, że możemy skorzystać z load-balancera warstwy 4, aby dystrybuować połączenia i zapewnić wysoką dostępność dla serwerów CAS. Urządzenie tego typu, decyzję o tym, do którego serwera przekazać połączenie, podejmuje na podstawie portu TCP, na którym zostało nawiązane połączenie. Nie musimy korzystać z load balancerów warstwy 7, analizujących ruch na poziomie warstwy aplikacyjnej modelu ISO sieci. Istotnym faktem jest, aby load balancer potrafił sprawdzać dostępność usług na serwerach, do których przekazuje ruch. W związku z tym Windows Network Load Balancer, podobnie jak w wersji Exchange 2010, nie jest rekomendowanym rozwiązaniem, ponieważ weryfikuje tylko dostępność interfejsu sieciowego – sprawdza, czy serwer odpowiada na pakiety ICMP.

Podsumowanie

Podsumowując powyższe spostrzeżenia, Affinity nie jest wymagane dla połączeń Outlook – Client Access Server. W związku z tym Load Balancer warstwy 4, skonfigurowany bez Affinity, może być stosowany, w środowisku Exchange 2013.

Jaki wpływ na zmiany w działaniu serwerów CAS mają na Outlook Web App, co jeśli rola CAS jest kolokowana z rolą Mailbox i nastąpi awaria serwera z aktywną kopią bazy? Aby się tego dowiedzieć zapraszamy na szkolenia Exchange 2013 Ignite, podczas, którego omawiamy także inne interesujące nowości w najnowszej wersji serwera Exchange.