Za razliku od dosadašnjeg pristupa koji je Microsoft imao vezano za logičku organizaciju i distribuciju servisa u jednom Exchange (2000 ili 2003) okruženju, a koja je podrazumijevala koncepte Front-end servera (koji su opsluživali vanjske klijentske zahtjeve) i Back-end servera (koji su hostirali korisničke mailboxe,public foldere i adresare, te radili sa korisnicima iz interne mreže) Exchange Server 2007 donosi brojne razlike i poboljšanja u ovom smislu, što samo po sebi donosi i drugačije koncepte kada je u pitanju obezbjeđivanje visoke dostupnosti.
Exchange 2007 server roles
Umjesto dosadašnje dvije uloge (front-end i back-end), novi Exchange Server 2007 funkcioniše na principu 5 različitih uloga (eng.roles) koje hostiraju različite funkcionalnosti, koje učestvuju u procesu primanja i slanja poruka.
Da se podsjetimo, to su redom :
- Mailbox Server role, koji hostira korisničke mailboxe, public foldere, adresare, sistemske i mailbox polise, te prihvata MAPI (Outlook based) konekcije klijenata isključivo iz interne mreže. Ovaj role nikada ne komunicira direktno sa klijentima preko Interneta, i jedini je koji na sebi drži korisničke podatke. U Exchange 2003 terminologiji, najsličniji je onome što se nekad zvalo back-end ;
- Hub Transport Server role, koji je odgovoran za rutiranje poruka unutar jedne Exchange organizacije, kategorizaciju poruka, primjenu transportnih polisa i forwarding prema SMTP gateway-u, kao i prihvat poruka sa njega, te rutiranje na odgovarajući mailbox server koji locira kroz AD. Ova serverska funkcionalnost u cijelosti je oslonjena na AD replikacijsku topologiju, te stoga više ne postoji zaseban message routing kao kod Exchange-a 2003. Većina same konfiguracije Hub Transport servera stoji u AD-u. Kao koncept, do sada nije postojao, a izdvajanjem ove funkcionalnosti u zaseban role, omogućio se čitav niz novih opcija za tretiranje poruka u transportu ;
- Client Access Server role, koji služi za prihvat svih non-MAPI, eksternih konekcija, poput Outlook Web Access pristupa, ActiveSync pristupa, POP3, IMAP4, te za hostiranje Autodiscover i Exchange Web servisa. Komunicira direktno sa Mailbox serverom, te sa Hub Transport serverom. Ovaj role je najsličniji onome što se u Exchange 2003 terminologiji zvalo front-end.
- Edge Transport server role, koji služi za slanje poruka na Internet i prihvat poruka sa Internet-a, antispam i antivirus zaštitu, te primjenu polisa koje se odnose na address rewriting i sl. Ovaj server ne može biti član domene, niti instaliran zajedno sa bilo kojom od ostalih uloga. Za svoju konfiguraciju koristi ADAM (Active Directory Application Mode), odnosno AD LDS (ako se instalira na Windows 2008), koji se pomoću EdgeSync procesa jednosmjerno sinhronizira sa odgovarajućim dijelova internog AD-a, putem Hub Transport servera, koji je ujedno i jedini sa kojim Edge Transport komunicira;
- Unified Messaging server role koji omogućava integraciju svih vidova komunikacije (fax,mail,telefon) u jedan korisnički mailbox. Ovaj role predstavlja sasvim novu funkcionalnost, koja do sada nije postojala kao dio Exchange-a. Ovdje ga nećemo posebno detaljno tretirati, budući da visoka dostupnost ove komponente zahtijeva i dostupnost drugih sistema (telefonskog, fax) o kojima ovdje nećemo govoriti.
Za funkcionisanje jednog Exchange 2007 rješenje neophodno je instalirati sljedeće uloge : Mailbox server role, Hub Transport server role i Client Access Server (CAS) role. Edge Transport server je vrlo preporučena uloga, ali nije neophodna za funkcionisanje sistema (obzirom da Hub Transport može preuzeti većinu funkcionalnosti Edge Transport servera), dok Unified messaging predstavlja rješenje koje zahtijeva integraciju sa postojećim sistemom telefona, faxova i sl.
Tehnički, Exchange Server 2007 može se locirati na jednom fizičkom serveru uz instaliranje samo Mailbox,Hub i CAS uloga, mada to iz više razloga nije preporučljivo.
Da bi se još bolje razumio koncept serverskih uloga (a samim tim i zahtjeva za njihovu dostupnost), možda je najbolje pogledati kako izgleda tipični tok putovanja poruke, od trenutka kada je jedan korisnik pošalje do trenutka kada je drugi primi :
Pretpostavimo da korisnik sa Outlook-om (dakle MAPI klijent) želi poslati poruku nekom drugom korisniku unutar ili izvan svoje organizacije. Kada klikne Send u prozoru za slanje poruke, ta poruka ide na Mailbox Server pošiljaoca. Tada Mailbox Server šalje obavještenje Hub Transport Serveru da postoji poruka koju treba distribuirati. Hub Transport preuzima poruku, te na osnovu adrese primaoca procijenjuje šta treba da se uradi sa porukom, vrši kategorizaciju, te primijenjuje transportne polise na poruku (ako su postavljene). Ako je primalac unutar iste organizacije, Hub Transport server će pronaći, upitom na AD, odgovarajući Mailbox server primaoca, te će mu proslijediti poruku, koju će ovaj dalje distribuirati u korisnički mailbox. Ako je primalac van organizacije, Hub Transport server će poruku proslijediti Edge Transport serveru. On će na osnovu adrese primaoca, napraviti upit prema javnom DNS-u, pronaći odredišnu domenu, i zatim u domeni odgovarajući SMTP (mail) server kojem će predati poruku, i tu se proces završava. Kod prijema poruke, stvari idu istim tokom, ali u obrnutom smjeru. Ukoliko korisnik pristupa svom mailboxu izvana, odnosno korištenjem Outlook Web Access-a, Active Sync-a ili pak Outlook Anywhere funkcionalnosti, u cijelu ovu priču se upliće još i Client Access Server koji služi kao proxy između korisnika i njegovog mailboxa.
Iz ovoga je očito da visoka dostupnost mail sistema baziranog na Exchange Serveru 2007 podrazumijeva visoku dostupnost svake od ključnih komponenti. Sistem će biti dostupan onoliko koliko je dostupna njegova najslabije obezbjeđena uloga. Pogledajmo sada svaku ulogu posebno sa aspekta obezbjeđivanja visoke dostupnosti.
Serverske uloge i zahtjevi za dostupnost
Svaka od pobrojanih serverskih uloga ima drugačije koncipirane sisteme koji obezbjeđuju visoku dostupnost. Takođe, disfunkcionalnost svake pojedine uloge različito se odražava na potpunu ili djelomičnu (ne)funkcionalnost cijelog sistema. Prema svakoj pojedinoj ulozi to izgleda ovako :
- Mailbox server role
Posljedice nefunkcionalnosti : Prestanak rada Mailbox server role-a, rezultira u nefunkcionalnosti cjelokupnog mail sistema u organizaciji. Prijem poruka bit će onemogućen (uz formiranje reda čekanja na Hub Transportu ili Edge transportu), kao i njihovo slanje, te pristup korisničkim mailboxovima. Posebno treba obratiti pažnju na činjenicu da disfunkcionalnost ili otkazivanje bilo koje ključne hardverske komponente na serveru koji hostira Mailbox server role (CPU, memorija, HDD, napajanje, hlađenje) posredno, ali trenutno, onesposobljava cijeli mail sistem, te je stoga ključno obezbijediti neki vid visoke dostupnosti na ovom serverskoj ulozi, koji će uključivati i hardversku redudanciju.
Kompleksnost vraćanja u punu funkcionalnost (disaster recovery/restore) : Ponekad je potrebno izrazito mnogo vremena za restore, koje raste proporcionalno broju mailboxa. Postoji mogućnost gubljenja podataka u količini koja zavisi od vremena koje je prošlo od zadnjeg backup-a, te od ispravnosti transaction logova.
Opcije za visoku dostupnost : Visoka dostupnost za mailbox server role se obezbjeđuje kroz implementaciju jednog od tipova klastera koje Exchange 2007 podržava.
Local Continuous Replication(LCR) se ne može u pravom smislu riječi okarakterisati kao opcija za visoku dostupnost, jer tretira samo dio cijelog problema.Radi se o mogućnosti da na jednom serveru, ali na dva različita diska, imamo po jednu kopiju iste mailbox baze. Jedna kopija je aktivna, i uz nju je vezan trenutno otvoreni transaction log, dok se druga sinhronizuje po zatvaranju transaction loga i otvaranju novog. Ovo naravno ne predstavlja redudanciju u pravom smislu riječi, jer imamo samo jedan server, ali za manja okruženja nije loše jer se može implementirati i na Standard verziji, a i nakon kreiranja samih baza, te ne iziskuje dodatni server, već samo dodatni disk. LCR se uključuje na storage grupi, u kojoj može biti maksimalno jedan store. Nema automatski failover, ali je drugu kopiju moguće aktivirati vrlo brzo, doduše ručno.
Skica arhitekture za LCR :
Cluster Continuous replikacija (CCR) podrazumijeva implementaciju dva fizička Mailbox servera. Jedan drži aktivnu kopiju baze, drugi pasivnu, a treći je host (koji ne mora biti Exchange Server), sa ulogom File Share Witness, odnosno koji nosi podatak o tome koji je čvor (node) trenutno aktivan, u slučaju da oni izgube međusobnu komunikaciju. Kod ove izvedbe podržan je automatski failover, odnosno preuzimanje funkcionalnosti u slučaju otkazivanja jednog servera.
Skica arhitekture za CCR :
Treći tip visoke dostupnosti obezbjeđuje se kroz Single Copy Cluster (SCC) koji podrazumijeva dva Exchange Servera, ali sa zajedničkim storage-om baza na nekom SAN uređaju. Automatski failover i ovdje postoji, ali je kopija baze jedna, za razliku od CCR-a gdje postoje dvije kopije. Kod SCC-a, storage predstavlja single-point-of-failure.
Skica arhitekture za SCC :
Ograničenje kod korištenja bilo koje verzije clusteringa na Mailbox serveru (izuzev LCR) je u tome što u tom slučaju taj server ne može hostirati niti jedan drugi role.
Standby Continuous Replication (SCR) je novi vid za osiguravanje visoke dostupnosti, koji je implementiran u SP1 verziji Exchange-a 2007. Zamišljena je kao funkcionalnost koja omogućava korištenje stand-by servera. Koristi se isti log-shipping i replay tehnologija transaction logova kao i kod LCR i CCR metoda, ali uz mogućnost lociranja recovery servera na različitim fizičkim lokacijama (sajtovima). Često se koristi u kombinaciji sa CCR-om, tako da se na centralnoj lokaciji koristi CCR kao metoda za clustering, dok se SCR implementira tako da na drugoj lokaciji držimo servere koji se vrlo brzo mogu dovesti u stanje clustered servera (tzv. Provisioned serveri, standby cluster).
Iako je SCR dosta komplikovan za implementaciju, te zahtijeva dosta hardverskih resursa, može se reći da ovo zaista predstavlja redudanciju u pravom smislu riječi, obzirom da tretira čak i situacije poput požara, poplava i sl. kada cijela centralna lokacija može biti uništena.
Skica arhitekture za SCR :
- Client Access server role
Posljedice nefunkcionalnosti : Ako CAS otkaže, nefunkcionalni će biti servisi koji opslužuju vanjske korisnike (Outlook Web Access, Active Sync, POP3, IMAP4 i sl). Pristup korisnika svojim mailboxima neće biti zaustavljen, a protok samih poruka može biti djelomično umanjene funkcionalnosti. Autodiscover servis neće biti u funkciji što može uzrokovati umanjenu funkcionalnost Outlook 2007 klijenata.
Kompleksnost vraćanja u punu funkcionalnost (disaster recovery/restore) : Restore ovog servisa je brz. Nema opasnosti od gubljenja korisničkih podataka jer server ne hostira podatke osim onoga što se nalazi u IIS-u.
Opcije za visoku dostupnost : Visoka dostupnost ovog servisa postiže se implementacijom Network Load Balancinga na IIS, sa ubacivanje još jednog (ili više) CAS servera.
- Hub Transport server role
Posljedice nefunkcionalnosti : Ukoliko ovaj role nije dostupan, transport i routing poruka će prestati raditi. Poruke se neće moći niti slati niti primati, ali će korisnici imati pristup svojim mailboxovima.
Kompleksnost vraćanja u punu funkcionalnost (disaster recovery/restore) : Jednostavan restore obzirom da se konfiguracija za Hub drži u AD-u, pa je dovoljno pokrenuti restore mode setup za Exchange Server. Nema gubljenja korisničkih podataka, eventualno su ugrožene neke custom polise za message transport.
Opcije za visoku dostupnost : Visoka dostupnost postiže se implementacijom više od jednog Hub Transport servera. Lociranje alternativnog Hub Transport servera obavlja se kroz Active Directory. Nije potrebno konfigurisati nikakve dodatne funkcije.
- Edge Transport server role
Posljedice nefunkcionalnosti : Ukoliko je Edge implementiran, njegova nefunkcionalnost rezultirat će nemogućnošću slanja i primanja vanjskih poruka. Interna razmjena poruka bit će funkcionalna, kao i pristup korisničkim mailboxovima.
Kompleksnost vraćanja u punu funkcionalnost (disaster recovery/restore) : Jednostavan restore samog Edge servera, uz potrebu ponovnog instaliranja ADAM-a, te uspostavu sinhronizacije sa Hub Transport serverom
Opcije za visoku dostupnost : Visoka dostupnost postiže se implementacijom više od jednog Edge Transport servera, te implementacijom DNS round-robin funkcionalnosti na vanjskom DNS-u.
Zaključak
Iako bi se iz prethodno rečenog dalo zaključiti da je za potpunu redudanciju i visoku dostupnost potrebno osigurati bar 8 fizičkih servera, to ipak nije tako. Uzme li se u obzir vrijeme koje je potrebno za restore svake od rola, te podatke koje oni hostiraju, nameće se zaključak da je redudancija Mailbox server rola ipak najbitnija. Implementacija CCR ili SCC tehnolgija će u najvećem broju slučajeva biti dovoljna, a i ne zahtijeva prevelike hardverske resurse. Što se tiče ostalih uloga, njihova redudancija će se uskoro moći postići i virtualizacijom, budući da će nova virtualizacijska platforma Hyper-V podržavati virtualizaciju Exchange servera. Ipak treba reći da je za Mailbox server role još uvijek preporučljivo koristiti fizičke mašine.