[Archiwum] (R)ewolucja Architektury Exchange Server

    Artykuł (R)ewolucja Architektury Exchange Server został opublikowany 13.06.2016 r. na portalu wss.geekclub.pl. Niestety portal został wygaszony, w związku pojawiającymi się pytaniami gdzie moje artykuły można przeczytać postanowiłem je przenieść na niniejszego bloga.

(R)ewolucja Architektury Exchange Server. 

     Artykuł przedstawia przegląd oraz główne zmiany systemu pocztowego Exchange Server przechodząc przez wszystkie edycje systemu (od 4.0 do 2013)

Łyk historii: od 4.0 do 2003

    W 1996 roku pojawił się pierwszy produkt z rodziny Microsoft Exchange Server, który stał się przełomem w historii systemów pocztowych. Exchange Server 4.0, który wówczas pracował na systemie Windows NT Server 3.51 był zupełnie nowym produktem, który zastąpił MS-Mail 3.0 (starszy produkt Microsoft, niemający nic wspólnego z Exchange). System ten działał niestabilnie praktycznie wszystkie wprowadzone zmiany, aktualizacje bardzo często powodowały zawieszenie systemu – popularny Blue Screen. Głównym powodem migracji / zakupu do Exchange 4.0 była możliwość podłączenia Exchange 4.0 do sieci Internet oraz wysyłki i odbioru wiadomości e-mail.


    W 1997 roku pojawiła się druga edycja systemu Exchange, która oznaczona była symbolem 5.0. Exchange 5.0 w tamtym czasie pracował na systemie Windows NT 4.0. Była to pierwsza wersja systemu, która współpracowała z klientem pocztowym Outlook 97 w którym po raz pierwszy znalazły się katalogi: Inbox, Sent Items, Calendar, Contacts i inne. W SP1 do Exchange 4.0 pojawiła się pierwsza wersja Outlook Web Access, za pomocą której użytkownicy mogli łączyć się zdalnie z serwerem pocztowym z poza organizacji.
    W Exchange 5.5 (Rys. 1) – została rozszerzona wielkość pliku bazy danych, gdzie we wcześniejszym wersjach wynosiła ona 16 GB. OWA została w znacznym stopniu rozbudowana i poprawiona

 

Rys. 1. Konsola Exchange 5.5.

    Exchange 2000/2003 posiadał bardzo prostą architekturę, jeden serwer posiadał wszystkie wymagane funkcjonalności do poprawnego działania systemu pocztowego w obrębie jednej organizacji. Zapewnienie wysokiej dostępności dla serwerów Exchange było trudnym i złożonym rozwiązaniem. Zarządzanie kontami użytkowników odbywało się z poziomu przystawki Active Directory Users and Computers.

Nowa epoka: 2007–2010

    Na początku marca 2007 roku pojawiła się finalna wersja Exchange Server 2007, która posiadała bardziej rozbudowaną architekturę w porównaniu do starszych wersji produktu. Zmiana ta wprowadzała sporo nowych rozwiązań i udoskonaleń. Stare wersje nie do końca radziły sobie z nowymi szybszymi procesorami, nie obsługiwały dużej ilości pamięci operacyjnej. Dodatkowo Exchange Server 2007 oraz jego następcy nie aktualizował przystawki Active Directory Users and Computers przy pomocy, której zarządzano kontami. Administracja odbywała się z poziomu konsoli Exchange Server. 

    W Exchange Server 2007 zmieniła się zupełnie Architektura systemu, która składała się z pięciu ról, odpowiedzialnych za:

• Mailbox – rola odpowiedzialna za przechowywanie skrzynek pocztowych użytkowników;
• Hub Transport – rola odpowiedzialna za routing wiadomości wewnątrz i na zewnątrz organizacji, polisy;
• Client Access – rola odpowiedzialna za dostęp do skrzynek pocztowych użytkowników;
• Edge Transport – rola odpowiedzialna za routing i anty-spam, instalowana w DMZ;
• Unified Messaging – rola odpowiedzialna za połączenia głosowe;

    Wysoką dostępność dla serwerów Mailbox można było zapewnić za pomocą kilku rozwiązań:

• Local Continuous Replication (LCR) – rozwiązanie jednoserwerowe, wykonuje asynchronicznie kopie bazy danych na innym wolumenie podłączonym do serwera, na który można się przełączyć w przypadku awarii wolumenu podstawowego. Pozwala na redundancję danych, brak redundancji usług Exchange 2007
• Single Copy Cluster (SCC) – rozwiązanie oparte o klasyczny klaster typu Failover, gdzie dane przechowywane są na jednym wolumenie podłączonym do kilku serwerów. Brak redundancji danych, redundancja usług Exchange 2007
• Cluster Continuous Replication (CCR) – rozwiązanie korzystające z funkcjonalności Failover Cluster, korzystające najczęściej z lokalnych wolumenów, dane przesyłane są asynchronicznie na drugi serwer. Pozwala na pełną redundancję danych i usług Exchange.
• Standby Continuous Replication (SCR) – asynchroniczna replikacja danych do serwera standby 1:1. Rozwiązanie wprowadzone z SP1.

Od wersji Exchange Server 2007 wszystkie edycje produkcyjne były 64 bitowe.

    Exchange Server 2010  (Rys. 2.) wprowadził nowy model wysokiej dostępności dla serwerów Mailbox –  Database Availability Group oraz dla serwerów Client Access – Client Access Array.
Wdrożenie Exchange 2010 w dużej organizacji było skomplikowane. Zapewnienie wysokiej dostępności dla CAS przy pomocy sprzętowego Load Balancera było dużą inwestycją. W związku z tym był to kolejny problem napotkany podczas instalacji Exchange 2010. Oczywiście Microsoft zaproponował inne alternatywne metody, które są wspierane, ale mało wygodne lub nierekomendowane np. NLB, DNS Round Robin.

    Dla zapewnienia wysokiej dostępności skrzynek pocztowych użytkowników firma Microsoft zaprojektowała Database Availability Group, które było połączeniem i rozbudowaniem dwóch mechanizmów CCR i SCR. DAG pozwalał na utrzymanie maksymalnie do 16 kopii dla jednej bazy skrzynek pocztowych. 

 Rys. 2. Konsola Exchange 2010.

    Exchange Server 2010 używa mechanizmu ciągłej replikacji (Continuous Replication) baz skrzynek pocztowych pomiędzy serwerami należącymi do Database Availability Group w celu zapewnienia aktualnej kopi bazy danych na wszystkich serwerach. Aktywny log transakcyjny aktywnej bazy danych jest zapisywany i zamykany. Następnie replikowany do pasywnej kopii bazy. Zreplikowany log jest weryfikowany i odtwarzany do pasywnej kopii. Dzięki temu każda kopia bazy danych jest identyczna i aktualna.

    DAG nie wymaga utworzenia klastra typu Failover oraz nie korzysta z infrastruktury sieci iSCSI/FC. W związku z tym jest bardziej elastyczny i pozwala na łatwą rozbudowę. Dodanie kolejnego serwera do DAG ogranicza się do instalacji serwera Mailbox i dodania go do Database Availability Group.

    Zarządzanie uprawnieniami odbywało się za pomocą nadania szczegółowych uprawnień dla użytkownika przypisując mu odpowiednie uprawnienia (RBAC – Role Based Access Control). Dzięki temu można było nadawać szczegółowe uprawnienia w Exchange. Główna zasada: Co, Kto i Gdzie tzn. Co może wykonywać dana osoba w jakim zakresie.

    W wersji 2010 po raz pierwszy pojawiła się możliwość wdrożenia systemu pocztowego Exchange poza organizacją w „chmurze publicznej” tzn. Hybrid Deployment.

    Dodatkowo wersje 2007, 2010, 2013 pozwalały na zarządzanie systemem pocztowym z poziomu powłoki Exchange Management Shell, w której administrator mógł w pełni zarządzać systemem pocztowym: tworzyć konta, zarządzać bazami danych, tworzyć edytować connectory, polisy itd.

Exchange Server 2013

     Architektura systemu pocztowego Exchange Server 2013 została w dużym stopniu przebudowana. Natomiast sam Exchange 2013 stał się jeszcze bardziej niezawodny i wydajny.

    Microsoft zrezygnował z roli Hub Transport i Unified Messaging. W obecnej chwili serwisy odpowiedzialne za wyżej wymieniowe komponenty zostały przeniesione do Client Access i Mailbox. Client Access Server nie udostępnia już bezpośrednio danych, bierze on udział w procesie autentykacji i przekierowuje do odpowiednich serwerów Mailbox (wyjątek – połączenia głosowe przekierowywane są bezpośrednio do serwerów Mailbox z pominięciem serwera Client Access). Do Mailbox Serwera zostały przeniesione serwisy, które znajdowały się wcześniej w Client Access Server, Hub Transport Server i Unified Messaging Server.

    Rola Client Access została drastycznie przebudowana i uproszczona. CAS udostępnia protokoły HTTP, HTTPS, IMAP i POP w związku z tym nie ma wymagań by była trzymana sesja na serwerze Client Access. Dzięki temu zapewnienie wysokiej dostępności za pomocą równoważenia obciążenia sieciowego stało się łatwiejsze, bez problemu można je zapewnić na poziomie warstwy 4. W związku z tym nie ma wymagań co do stosowania sprzętowego Load Balancera.

    Wprowadzono nową ciekawą funkcjonalność Data Loss Prevention, która ma za zadanie „pilnowania” przepływu wiadomości w obrębie systemu pocztowego Exchange Server 2013 Dzięki funkcjonalności DLP administrator może zablokować wysyłkę maili w których znajdują się poufne informacje takie jak numery kart kredytowych czy inne, automatycznie informując o incydencie odpowiednie osoby w firmie. Niestety w obecnej chwili nie ma szablonu dla polskich fraz takich jak numer ewidencyjny PESEL czy numer Dowodu Osobistego.

    Za pomocą Client Access Serwera użytkownicy dostają się do swoich skrzynek pocztowych oraz korzystają z dodatkowych usług świadczonych przez Exchange Server takich jak:

• OWA – Outlook Web App
• ECP
• Exchange Active Sync
• Outlook Anywhere
• POP 3
• IMAP 4
• Exchange Administration Center
• Autodiscover – automatyczna konfiguracja klientów
• Availability Service – serwis udostępnia innym użytkownikom kalendarze oraz informacje na temat danego użytkownika wolny / zajęty

     Dodatkowo warto wspomnieć, że do Exchange Server 2013 klient MAPI (Outlook) łączy się z serwerem Mailbox przy pomocy Client Access Servera używając protokołu RCP over HTTP. W odróżnieniu od starszych wersji produktu producent zrezygnował z protokołu RCP over TCP. W związku z tym połączenie takie jest znacznie bezpieczniejsze, a konfiguracja firewalla sprowadza się jedynie do przepuszczenia portu 443.
    Microsoft zrezygnował z tradycyjnej konsoli zarządzania opartej o konsolę mmc w wersji 2013 pojawił się zupełnie nowy interfejs– Exchange Administration Center (Rys. 3.), który dostępny jest z poziomu przeglądarki internetowej pod adresem https://nazwa_serwera/ecp. Zmiana taka najprawdopodobniej była podyktowana coraz większą popularnością Office 365 co wiązało się z rozwojem równolegle dwóch konsol do zarządzania dla produktu Exchange (On-Permise) oraz Office 365. Producent wybrał jedną ścieżkę i w związku z tym rozwija konsolę, która jest oparta o interfejs web. Czy był to dobry kierunek zobaczymy w przyszłości... Na pewno interfejs stał się prostszy, a samym systemem Administrator może zarządzać z dowolnej stacji nie jest już wymagana instalacja dodatkowych komponentów do konsoli.

 

 Rys. 3. – Exchange Management Center - Exchange Server 2013.

     W Mailbox Serwerze przechowywane są aktualne bazy danych skrzynek pocztowych użytkowników oraz foldery publiczne.

        Dodatkowo Client Access Server i Mailbox Server nie są już tak zależne od siebie jak w starszych wersjach Exchange. Wcześniej wymagane było by w jednej podsieci / lokalizacji znajdował się co najmniej jeden CAS i MBX. W obecnej chwili można skonfigurować Exchange 2013 tak by rola Client Access Server została scentralizowana, a Mailbox Serwery rozproszone geograficznie.

Podsumowanie

    W przeciągu kilkunastu lat architektura systemu pocztowego Exchange Server ewaluowała. W obecnych czasach produkt ten nie tylko służy do wysyłania poczty drogą elektroniczną, ale jest również kluczowym systemem pod kątem innych elementów biznesu. Nie wiadomo w którym kierunku firma Microsoft pójdzie i jak zmieni się architektura systemu. Czy znowu powrócą do wersji gdzie jeden serwer świadczy wszystkie usługi i dostawia się kolejny? A może „Hybrid Deployment” będzie bardziej popularny i utrzymywanie środowiska Exchange lokalnie stanie się małoopłacalne? Z pewnością na te pytania będziemy mogli odpowiedzieć sobie za kilka lat.