Kolejnym krokiem po utworzeniu Database Availability Group jest dodanie członkowskich serwerów Mailbox. W tym celu w zakładce Database Availability Groups należy zaznaczyć wcześniej utworzoną grupę DAG i przy pomocy prawego przycisku myszy wybrać opcję Manage Database Availability Group Memebership, następnie - klikając przycisk Add - dodać serwery Mailbox (w przypadku dodania serwera bez zainstalowanego dodatku Failover Cluster zostanie on automatycznie zaimplementowany).

Kolejną czynnością jest wykonanie kopii baz danych aktywnego serwera Mailbox. Będąc w gałęzi Mailbox należy przejść do zakładki Database Management i w oknie Database Copy prawym przyciskiem myszy wybrać opcję Add Mailbox Database Copy. W uruchomionym kreatorze wskazuje się serwer członkowski DAG, na którym zostanie wykonana kopia bazy. Potwierdzenie wybranych parametrów wykonuje kopię bazy. Po poprawnym utworzeniu kopii bazy w zakładce Database Management, w oknie Database Copy powinny się pojawić wszystkie wskazane kopie na serwerach Mailbox, z czego jedna powinna mieć status aktywny (kolumna IS Active - wartość: true), a reszta pasywny (wartość: false). Dla pewności można przeprowadzić testowe przepięcie pomiędzy replikowanymi bazami. Wykonuje się to zaznaczając pasywną kopię bazy i prawym przyciskiem wybierając opcję Activate Database Copy.

Zobacz również:

• Akcje Intel spadają - winna rosnąca konkurencja w AI
• Wielka inwestycja Atmana w przetwarzanie danych

Oczywiście wszystkie powyższe operacje można wykonać przy użyciu konsoli Exchange Management Shell. Sama konfiguracja Database Availability Group nie zapewnia wysokiej dostępności dla całego systemu pocztowego opartego na Microsoft Exchange, a jedynie dla serwerów Mailbox. Do zapewnienia High Availability infrastruktury z serwerem Exchange 2010 konieczne jest zapewnienie redundancji dla innych ról serwera pocztowego i wykorzystanie dodatkowych mechanizmów (np. load balancingu).

Client Access Array - niezawodność dostępu dla klientów pocztowych

W poprzednich wersjach serwera Exchange rola Client Access Server wykorzystywana była jedynie do łączenia się klientów zewnętrznych. W exchange 2010 ta jedna z podstawowych ról obsługuje w dostępie do skrzynek pocztowych zarówno klientów zewnętrznych, jak i wewnętrznych (wyjątek stanowi dostęp do folderów publicznych).

Gdy program kliencki próbuje połączyć się ze skrzynką pocztową kierowany jest bezpośrednio do serwera CAS. Po uwierzytelnieniu w Active Directory aplikacja uzyskuje bezpośredni dostęp do zasobów skrzynki lub - jeśli znajduje się ona w innej lokacji - następuje przekierowanie do innego serwera Client Access Server we właściwej lokacji, który zezwala na dostęp do skrzynki. Powyższy schemat działania wymusza instalację serwerów CAS w każdej lokacji, w której znajdują się serwery Mailbox.

Funkcjonalność serwerów CAS jest odpowiedzialna za dostęp użytkownika do poszczególnych usług. Są to między innymi Outlook Web App, dostęp do skrzynki za pomocą klienta MAPI - z wewnątrz i z zewnątrz organizacji (RPC Client Access i Outlook Anywhere), informacja o aktualnym statusie użytkownika (Availability Service). Realizują także automatyczną konfigurację profilu użytkownika (Autodiscover) oraz dostęp do Adress Book Service, POP3 i IMAP.

Z powyższego wynika, że pojedynczy serwer CAS jest słabym punktem w środowisku Exchange i należałoby zadbać o jego redundancję. Rozwiązaniem jest utworzenie Client Access Array, które eliminuje zagrożenie braku komunikacji w przypadku awarii pojedynczego serwera CAS. Client Access Array jest zbiorem serwerów Client Access, które do swojego działania wykorzystują usługę sieciowego load balancingu (sprzętowego lub programowego). Przy czym każdy z serwerów członkowskich Access Array musi znajdować się w tej samej lokacji.