Automatyczne przełączenie na ośrodek zapasowy w Exchange 2013

W moim poprzednim wpisie przedstawiłem zmiany w dystrybucji połączeń do serwerów Exchange 2013. W drugiej części artykułu chciałbym zaprezentować, jak modyfikacje w działaniu roli Client Access wpływają na przełączanie się na zapasowy ośrodek przetwarzania
danych. Postaram się odpowiedzieć na pytanie: czy możemy osiągnąć w pełni automatyczne przełączenie na ośrodek zapasowy, w przypadku awarii jednej z lokalizacji.

Wspólna nazwa staje się faktem!

W poprzedniej części artykułu stwierdziłem, że przy połączeniach do serwerów CAS nie jest wymagane Affinity. Każdy serwer Client Access (nawet ten, znajdujący się w innym Site’cie AD niż serwer Mailbox) może proxować połączenie HTTPS do serwera Mailbox, na którym znajduje się nasza skrzynka pocztowa. Połączenia pomiędzy lokalizacjami (cross-site) odbywają z wykorzystaniem protokołu HTTPS. To, do której lokalizacji trafi nasze połączenia nie ma zasadniczego znaczenia, na jakość połączenia do skrzynki. Oznacza to, że możemy skorzystać z wspólnej nazwy dla wielu lokalizacji z serwerami Exchange 2013, ponieważ nie jest istotne, do którego serwera CAS trafi nasze połączenie HTTPS.

DNS Round Robin

W mechanizmie DNS Round Robin wiele adresów IP jest powiązanych z jedną nazwą. Brak Affinity oraz możliwość użycia wspólnej nazwy dla kilku lokalizacji powodują, że w konfiguracji Site Resilient musimy skorzystać z mechanizmu DNS Round Robin. Trzeba pamiętać, że DNS Round Robin nie dystrybuuje połączeń w sposób równomierny, ani nie potrafi w sposób skuteczny reagować na wszystkie możliwe scenariusze awarii. Rozwiązaniem drugiego problemu jest mechanizm IP Failover wbudowany w system operacyjny. Zarówno Outlook jak i przeglądarki
internetowe, potrafią skorzystać z tego mechanizmu. Proces IP failover powoduje, że jeśli dla danej nazwy, serwer DNS zwraca więcej niż 1 adres IP, to klient będzie próbował połączyć się po kolei z każdym z nich dotąd aż połączenie się powiedzie.

Jak wygląda konfiguracja środowiska ze wspólną nazwa?

W schemacie poniżej pokazano środowisko z dwoma lokalizacjami, zapewniające automatyczne przełączenie w przypadku awarii jednej z lokalizacji. Składa się ono z dwóch load balancerów, czterech serwerów Exchange będących członkami DAG (po dwa w każdym datacenter) oraz File Share Witness umieszczonego w trzecim datacenter. Niezbędne jest rozmieszczenie serwerów Exchange symetrycznie w dwóch ośrodkach przetwarzania danych. W przeciwnym wypadku awaria datacenter, w którym znajduje się więcej niż połowa serwerów będących członkiem DAG, oznaczać będzie utratę większości w klastrze.

W DNSie utworzono rekordy dla wspólnej nazwy, które rozwiązują się na adresy IP obydwu load balancerów. Urządzenia dystrybuujące połączenia są niezbędne, do równomiernego kierowania połączeń do działających serwerów CAS.


Ważnym elementem projektu jest dobre zaplanowanie połączeń sieciowych między lokalizacjami. Każdy ośrodek powinien mieć bezpośrednie i niezależne połączenia z pozostałymi ośrodkami.

Przełączenie na ośrodek zapasowy

Przeanalizujmy, co się stanie w przypadku awarii łącza internetowego w datacenter Warszawa. Otóż, użytkownicy, którzy byli podłączeni do Load Balancera w Warszawie, utracą połączenie. Jednakże klienci spróbują połączyć się z drugim adresem IP (10.48.23.52) dla nazwy outlook lab.net, dzięki mechanizmowi IP Failover.  Po zestawieniu połączenia z tym adresem połączenia, będą proxowane przez serwery CAS w datacenter Piaseczno do serwerów z rolą mailbox w Piasecznie i Warszawie. Komunikacja będzie wyglądała jak na schemacie poniżej:

 

Wykonanie zmian w DNSie nie jest konieczne, jak to miało miejsce w przypadku Exchange 2010. Jednakże, jeśli naprawa lub wymiana load balancera zajmie dłuższy czas, zalecane jest usunięcie adresu IP load balancera z DNS. Dzięki temu nowe połączenia będą nawiązywane szybciej, ponieważ klient nie będzie próbował dokonać połączenia z load balancerem, który uległ awarii.

 

W przypadku całkowitej awarii jednego z ośrodków przetwarzania danych, mechanizm IP Failover sprawi, że połączenia HTTPS klientów zostaną przekierowane do load balancera w drugim ośrodku. Po awarii ośrodka, DAG wciąż będzie miał quorum, ponieważ serwery w działającym datacenter, będą mogły skomunikować się z File Share Witness. Serwer Exchange z działającego ośrodka, który jako pierwszy skomunikuje się z serwerem FSW otrzyma dodatkowy głos do formowania quorum. Zapewni to dalsze funkcjonowania klastra. Bazy skrzynkowe przełączą się automatycznie do działającego datacenter.

Jak to działa w praktyce?

Zobaczmy jak w praktyce będzie wyglądało przełączenie. Poniżej znajduje się schemat mojego środowiska laboratoryjnego z dwoma load balancerami, w dwóch różnych lokalizacjach.

 

Dla połączeń RPC over HTTP używana jest wspólna nazwa outlook.lab.net, która w DNSie rozwiązuje się na adresy IP Load Balancerów z obu lokalizacji.

Po nawiązaniu połączenia z serwerem Exchange sprawdźmy, jakie informacje dotyczące nazwy outlook.lab.net znajdują się w lokalnym cache’u DNS. W tym celu wykonuję polecenie ipconfig /displayDNS w wierszu poleceń.

Serwer DNS zwrócił dwa adresy IP dla nazwy outlook.lab.net:10.48.22.22 i 10.48.23.22. Sprawdźmy, z którym Load Balancerem Outlook nawiązał połączenie. W tym celu wykonuję polecenie netstat –ab w wierszu poleceń.

 

Widzimy, że połączenie zostało nawiązane z Load Balancerem LAB-E2K13CAS1.

Zasymulujmy awarię serwerów CAS, poprzez zatrzymanie Default Web Site na obu serwerach CAS w Site’cie PLWAR. Sprawdźmy, co stanie się z połączeniem Outlooka.

Po zatrzymaniu Default Web Site, Outlook traci połączenie:


Po chwili jednak Outlook ponownie nawiązuje połączenie.

Sprawdźmy, jak wyglądają połączenia TCP na naszym komputerze. Wykonuję polecenie netstat –ab z wiersza poleceń:


Widzimy, że tym razem połączenie jest nawiązane z load balancerem LAB-E2K13CAS2

Test został wykonany z wykorzystaniem Outlook 2013. To samo zjawisko zaobserwujemy, gdy będziemy korzystać z Outlook 2007 lub 2010.

Podsumowanie

Exchange 2013 znacząco upraszcza mechanizm przełączenia pomiędzy dwoma ośrodkami.

Pamiętajmy, że DNS Round Robin nie jest rozwiązaniem zapewniającym wysoką dostępność. Pozwala on klientom reagować na określone problemy z połączeniem, ale nie zapewnia poziomów dostępności, jakie wymagane są w ramach pojedynczego ośrodka. Dlatego wysoką dostępność w ramach pojedynczej lokalizacji zapewniamy za pomocą load balancera, który jest w stanie reagować na dużo bardziej złożone problemy po stronie infrastruktury Exchange.

Ponadto, aby zapewnić automatyczne przełączanie baz skrzynkowych, musimy

  • Umieścić serwer File Share Witness w trzeciej lokalizacji.
  • Zapewnić niezależne połączeń między ośrodkami, aby awaria jednego z datacenter nie powodowała utraty połączenia z File Share Witness.
  • Symetrycznie rozłożyć serwery Exchange pomiędzy ośrodkami. W obydwu ośrodkach umieścić taką samą ilość serwerów Exchange będących członkiem DAG