Tematický týden: Exchange Server 2010, díl 3.

…díl třetí, Transport Server a Edge Server

Předchozí díly seriálu o Exchange Server 2010 popisovaly novinky rolí Mailbox Server a Client Access Server. Nyní je čas na dvě další role, resp. servery, které mají „v popisu práce“ doručování a přijímání emailových zpráv. Jsou to Transport Server a Edge Server. Jejich koncept a nasazení zůstaly víceméně stejné jako v předchozí verzi Exchange Server 2007, k vylepšením došlo pod povrchem a změny nemusí být na první pohled patrné. Transport Server je rolí určenou primárně k routování zpráv uvnitř organizace, zatímco Edge Server řeší přijímání a komunikaci se servery na internetu. Díky jeho publikování do nebezpečných sítí je doporučeno, aby byl Edge Server instalován zcela mimo Active Directory jako Stand-Alone server. Nicméně některé informace z vaší interní Exchange organizace musí být dostupné i jemu, proto pomocí replikační služby EdgeSync synchronizujeme vše, co potřebuje Edge Server ke svému životu do jeho lokální databáze postavené na Lightweight Directory Server (LDS). Edge Serveru se někdy také říká Messaging Hygiene server – je přímo předurčen k odchytávání spamů, virů (pokud je na EDGE nainstalován antivirový software – např. Forefront Security for Exchange) a je schopen lépe odolávat aplikačním útokům z internetu, typicky na SMTP protokolu. Pojďme si tedy popsat, jaké novinky na nás se v těchto dvou rolích skrývají.

Transport Server

Stejně jako u Mailbox Serveru došlo i na Transport Serveru k zásadním vylepšením v oblasti Extensible Storage Engine (ESE). ESE databázi využívají transportní servery k ukládání zpráv ve frontě, tedy zpráv, které ještě nebyly doručeny. Změny v ESE jsou velmi významné – vylepšené využití databázové cache a použití komprese, které spolu s dalšími změnami v transport dumpster přinášejí snížení požadavků na IOPS o více než 50%. Díky tomu, i bez dalšího ladění Transport Serveru, jsou transportní servery nově schopny doručovat opravdu velké zprávy (např. 150MB) bez obav z „backpressure“ (komponenta Exchange Server 2007, která hlídá, zdali není server přetížen a pokud ano, odmítá doručovat nejprve externí a následně i interní zprávy).

Shadow redundancy

Stávající Exchange Servery trpí nepříjemnou vlastností – jakmile je jim jednou zpráva doručena, ukládá ji Exchange do fronty spolu s dalšími zprávami, kde jsou na serveru uloženy až do té doby, než se je podaří doručit. Tato fronta je fyzicky uložena v ESE databázi. Mohou tady nastat následující dva problémy:

• Zprávy uvíznou ve frontě na jednom serveru ve vaší organizaci, i když z jiných serverů existuje záložní komunikační cesta
• Pokud dojde k havárii disku, na kterém je fronta zpráv v ESE databázi uložena, jsou tyto emaily nenávratně ztraceny. Tím pádem je nutné používat pro tento logický svazek diskové pole a zajistit tak bezpečnost dat jiným způsobem

A co je tedy nového? Velmi zjednodušeně to, že zprávy nejsou po odeslání z databází na transportních serverech smazány, ale naopak je zde stále držena jejich kopie až do momentu, kdy server obdrží informaci o tom, že zpráva byla úspěšně doručena na místo určení.

Jak funguje Shadow Redundancy:

• HUB (shadow) doručuje zprávu na EDGE1 (primary)
  • HUB ověřuje, zdali EDGE1 podporuje Transport redundancy skrze příkaz XSHADOW
  • HUB přesouvá zprávu do shadow fronty a označuje EDGE1 jako aktuálního, primárního vlastníka
  • EDGE1 (primary) získává zprávu (stává se “primárním vlastníkem”)
• EDGE1 posílá zprávu na další server a aktualizuje stav zprávy jako doručený vzdálenému MTA
  • Úspěšný přenos:
    • HUB (shadow) dotazuje EDGE1 (primární server) o expirující status
    • HUB spuští XQDISCARD příkaz (v následujícím SMTP spojení), EDGE1 kontroluje lokální status vyřazených zpráv a zasílá seznam zpráv, které byly doručeny
    • HUB maže zprávy z vlastní shadow fronty
  • Nevydařený přenos:
    • HUB (shadow) dotazuje EDGE1 (primární server) o expirující status a znovu zprávu odesílá
    • HUB otevírá SMTP spojení, spouští příkaz XQDISCARD (heartbeat). Pokud HUB nemůže kontaktovat EDGE1, znovu odesílá zprávy z shadow fronty.
    • Tyto zprávy jsou doručeny EDGE2 a celý proces se znovu opakuje od začátku

Nově tak Transport Server nabízí redundanci zpráv během celé doby jejich přenosu. Jejich přenos se tak stává stateless a výrazně eliminuje nutnost použití RAID pole pro disk, na kterém je uložena ESE databáze.

Změny v rámci dumpsteru

Dumpster na Transport Serveru slouží k uchování informací, které jsou potřeba v momentě, kdy replikujete databáze v Exchange Cluster/DAG na více serverů a používáte k tomu replikaci na úrovni transakčních logů tak, jak to dělá Exchange Server 2007 a 2010. Teoreticky by totiž mohlo dojít ke ztrátě jedné, či více transakcí a proto Dumpster slouží jako místo, kde mohou Mailbox Servery tyto transakce zpětně získat. Díky lepší komunikaci s Mailbox Serverem, a spolu se zpětnou vazbou od replikace databází, je tato informace nyní využita k rozhodování, které transakce zůstanou ještě v Dumpster a které odtud budou smazány. Jinými slovy - jakmile je transakce zaznamenána/zreplikována do všech databázových replik, je odstraněna i z dumpsteru. Velikost dumpsteru je nyní závislá na latenci replikací frekvenci zpětné vazby.

Vylepšený Anti-spam

Díky vylepšené komunikaci a replikaci Transport Server s EDGE serverem se nám nyní z uživatelské schránky až do EDGE replikují seznamy „Bezpečných odesílatelů“ a „Blokovaných uživatelů“. Dnes jsme byli schopni toto dělat jen u „Bezpečných odesílatelů“ a pomocí Powershell CMDletu „update-safelist“, který jsme museli opakovaně spouštět (např. skriptem). Tedy pokud jsme chtěli zajistit aktuálnost informací sezbíraných u uživatelských schránek. Toto nyní může být prováděno zcela automaticky. Díky novému modelu replikace informací na EDGE jsou tyto seznamy adresátů EDGE serveru dostupné během několika minut. Nově máme jako správci možnost ovlivnit i to, kolik takových adresátů od klienta je možné automaticky replikovat do Active Directory. A to není vše – můžeme také ovlivňovat to, že uživatelé nebudou moci konkrétní doménu přidat na některý z listů.

Zcela nově Exchange Server 2010 umožňuje klientům vytvoření tzv. „Sign-Up E-Mail adresy“. Jedná se o speciální adresu, kterou budou používat uživatelé v momentě, kdy si nejsou zcela jisti zdali ten, komu emailovou adresu svěřují je důvěryhodný. Pokud tedy nevědí, použijí tuto adresu a následně, pokud je na ni něco doručeno, jsou uživatelé informováni o tom (MailTips), že zpráva přišla na tuto speciální emailovou adresu. Tuto adresu si uživatel spravuje zcela sám – není vidět v Address Book a nejedná se tedy o klasický SMTP alias.

Jsou tu ale i další novinky, hlavně v oblasti transportních pravidel:

• Možnost vyhledávání textových řetězců v přílohách emailů a na základě toho rozhodnout, zdali zprávu doručit, či odmítnout
• Vylepšená možnosti transportních pravidel a spolupráce s Active Directory umožňuje vytvořit firemní šablonu pro podpis, který se přidá do každé zprávy odesílané mimo organizaci, kde jednotlivé informace jsou dynamicky načítány přímo z atributů v Active Directory
• Automatic content based privacy – v tomto případě se Exchange snaží čelit situaci, v níž uživatel potřebuje poslat mimo vaši organizaci zašifrovaný email. Současně je zde ale nařízení, které říká, že každá zpráva musí být archivována v čitelném stavu. Cílového stavu je docíleno pomocí transportního pravidla, které zajistí šifrování až v momentě, kdy opouští vaši organizaci. Použity a plně podporovány jsou zde technologie Microsoft IRM
• Message Encryption Control – tato komponenta Transport serveru se postará o blokování zpráv, které jsou šifrovány a tím pádem zcela mimo vaši kontrolu. Podporovány jsou jen technologie S/MIME, PGP a Microsoft PGP. Pokud je zpráva schráněna heslem místo šifrování, měl by vás proti takové příloze chránit antivir.

EDGE Server

Mnoho novinek, které jsme si popsali v části o Transport Serveru se vztahuje i na EDGE server. Proto toho, co se dá napsat o EDGE už nezbývá mnoho...

Lepší výkon EdgeSync služby

Tato služba, která zajišťuje replikace nezbytných dat z interní Exchange Organizace do Lightweight Directory Serveru (LDS) instalovaném na lokálním EDGE serveru, prošla několika příjemnými změnami. Při replikaci jsou nyní nově podporovány replikace jen přírůstkových změn, čímž se významně snižuje zátěž EdgeSync služby.

Podpora pro uživatelské seznamy „Bezpečných odesílatelů“ a „Blokovaných odesílatelů“

Protože výhoda v oblasti antispamu již byla představena v předchozí části článku, pojďme si jen popsat celý proces, jak bude fungovat:

• Junk E-mail Options Assistant propaguje seznamy adresátů z uživatelské schránky do Active Directory
• Služby EdgeSync replikují tyto informace z Active Directory do LDS serveru na EDGE
• Na EDGE serveru Sender Filtering agent blokuje emaily od nechtěných adresátů
• Případně naopak je snížena antispamová známka u adresátů, kteří u uživatele patří do seznamu „Bezpečných adresátů“

Tolik tedy dnes k transportním serverům. Protože oblast Unified Messagingu přenecháme na zcela jiný seriál, tak se zítra můžete těšit na postup při instalaci Exchange Server 2010 do zcela nového prostředí, ale také jak postupovat při migraci z přechozích verzí, Exchange Server 2003 a Exchange Server 2007.

- Martin Pavlis – Microsoft Exchange MVP, IT Senior Consultant KPCS CZ, s.r.o.