reklama

Nasazujeme Exchange 2013 SP1 - díl 5.

Vítejte u pátého dílu seriálu, který se zabývá nasazením a optimalizací Microsoft Exchange Serveru 2013 SP1.

V dnešní části seriálu se budeme věnovat možnostem zprovoznění Exchange Serveru v režimu vysoké dostupnosti.

Pokud máte obavu, že při výpadku Exchange serverů dojde díky nedostupnosti poštovního systému k finančním ztrátám ve vaší společnosti, je jistě na čase začít přemýšlet o zajištění vysoké dostupnosti. Tato oblast se dá velmi jednoduše rozdělit do dvou oblastí – vysoká dostupnost dat, která jsou uložena v Exchange databázích a vysoká dostupnost na úrovni sítě, kdy je klientský přenos směřován na nejvýhodnější/nejdostupnější server. V obou případech platí, že serverů bude potřeba více – minimální scénář počítá se dvěma servery, v rozsáhlých sítích u větších společností se ale může jednat o desítky serverů.

Database Availability Group

Data v Exchange serveru jsou uložena v databázích, o které se starají servery s nainstalovanou Mailbox rolí. Tyto servery je možné včlenit do skupiny, v rámci které je možné zajistit repliku dat na všechny její členy. Této skupině se říká Database Availability Group (DAG). Abychom mohli Exchange servery do DAG přidat, je potřeba splnit následující:

  • Operační systém Windows 2008 R2 musí být ve verzi Enteprise, případně Datacenter – důvodem je spolupráce DAG se službou Windows Failover Cluster, která je součástí jen těchto edicí. Windows Server 2012 má službu Windows Failover Cluster již ve verzi Standard
  • Exchange Server může být ve verzi Standard, pokud vám stačí práce s pouze pěti databázemi
  • Dále je doporučeno, aby Exchange servery v DAG měly dvě síťová rozhraní – jednu kartu pro síť komunikující s klienty a druhou na synchronizaci dat mezi servery v clusteru

Založení DAG

Založení DAG je velmi jednoduché:

  • EAC: Servers -> Database Availability Groups -> Klikneme na ikonku + (newadd)
  • Jméno DAG – jedná se o jméno, které bude použito ke správě DAG, a proto musí být v rámci vaší sítě unikátní (podobně jako jméno Exchange serveru). Po založení DAG vzniká v Active Directory účet počítače s tímto jménem
  • Server (a složka), který bude použit jako svědek na síti – pokud máte v síti další CAS servery, bude jako svědek automaticky použit některý z nich a není nutné zde nic vyplňovat. Pokud takové servery v síti nemáte, je potřeba vybrat jakýkoli dostupný Windows server. Na tomto serveru je ale potřeba nejprve vytvořit a nasdílet patřičnou složku tak, aby ji DAG mohl používat

Přesný postup naleznete zde: http://technet.microsoft.com/en-us/library/dd298065.aspx

DAG ke svému fungování potřebuje nejen jméno, ale také IP adresu. IP adresu pro DNS jméno DAGu zadáváme při vytváření a můžeme ji později změnit přes EMS

  • Set-DatabaseAvailabilityGroup -Identity DAG -DatabaseAvailabilityGroupIPAddresses 10.0.0.1
Klepněte pro větší obrázek
Obr 1: Založení DAG

Tím je DAG a jeho konfigurace vytvořena v rámci Exchange organizace, ale fyzicky se stále nic neděje. Můžete se proto zamyslet nad tím, zdali nechcete měnit některé z dalších vlastností DAGu tak, aby plně vyhovoval vašim potřebám:

  • Standardně se data v rámci DAG mezi Exchange servery replikují protokolem využívajícím TCP na portu 64327
  • Tento port je při vkládání serverů do DAG automaticky povolen v rámci vestavěného Windows Firewallu. Pokud chcete, můžete tento port změnit, nicméně je potřeba následně tento port manuálně povolit i ve Windows Firewall

Změnu proveďte pomocí následujícího příkazu v EMS:

  • Set-DatabaseAvailabilityGroup -Identity DAG -ReplicationPort 12345

Přidávání Mailbox serverů do DAGu

  • EAC: Servers -> Database Availability Groups -> klikneme na DAG, který chceme změnit a pak na ikonku serveru s ozubeným kolem
  • Vybereme požadovaný Mailbox Server a přidáme jej do DAGu
Klepněte pro větší obrázek
Obr. 2: Přidávání serverů do DAGu
  • Teprve v momentě, kdy stiskneme tlačítko „Save“ dochází k fyzickému založení DAG a přidání jednotlivých serverů do DAG skupiny
  • Průvodce je velmi inteligentní a dokáže většinu nezbytných požadavků na straně Mailbox serveru zajistit sám. Např. zkontroluje, zdali se jedná o systém správné edice, zdali je na požadovaném Mailbox serveru nainstalována komponenta Windows Failover Cluster – tu si případně i sám doinstaluje – a celou řadu dalších kroků. Je normální, že dokončení tohoto kroku na každém Mailbox serveru trvá i několik desítek vteřin

Nyní máme DAG vytvořen a můžeme si zpětně prohlédnout jeho vlastnosti a to, které Mailbox servery jsou aktuálně členy DAG. V dolní části máme možnost provádět další změny, např. v oblasti sítí (např. to, po které síti se budou replikovat data mezi Mailbox servery a na které síti bude Exchange komunikovat s klienty).

Pokud si přejeme nastavit DAGu replikační sítě manuálně, můžeme zatrhnout příslušné zatržítko ve vlastnostech DAGu takto:

  • EAC: Servers -> Database Availability Groups -> rozklikneme DAG
  • Na záložce „General“ zatrhneme „Configure database availability group networks manually”

Nastavení replikačních sítí se zde věnovat nebudeme. Více se dozvíte zde:
http://technet.microsoft.com/en-us/library/dd298051(v=exchg.150).aspx

Klepněte pro větší obrázek
Obr. 3: Vlastnosti DAG

Přidávání databází a jejich kopií do DAGu

V tomto okamžiku můžeme v rámci DAG zajistit replikaci dat jednotlivých databází. Jedná se o vlastnost databáze, proto je potřeba postupovat následovně:

  • EAC: Servers –> Databases
  • Označíme databázi, kterou chceme replikovat na další Mailbox servery a klikneme na „…“ -> Add database Copy
  • Vybereme Mailbox Server, na který chceme přidat kopii databáze. Pokud se jedná o třetí a vyšší kopie, můžeme si vybrat také aktivační preference
Klepněte pro větší obrázek
Obr. 4: Přidání databázové kopie

Jakmile dokončíme průvodce pro přidání repliky databáze, můžeme začít sledovat, které servery aktuálně replikují danou databázi, který server drží aktivní repliku (mounted – tu se kterou se aktuálně pracuje), které servery mají další pasivní repliky a v jakém stavu tyto repliky jsou (healthy, initializing, failed, atd.).

Informace získáme v EMS pomocí příkazu:

  • Get-MailboxDatabaseCopyStatus –identity DAG
  • Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus
Klepněte pro větší obrázek
Obr. 5: Stav databází a jejich kopií

V rámci DAG je samozřejmě možné nastavit celou řadu dalších vlastností, které se vám mohou hodit v konkrétních situacích, pro další dokumentaci proto pokračujte zde:
http://technet.microsoft.com/en-us/library/dd298065(v=exchg.150).aspx

Síťový rozklad zátěže

V případě, že jste se rozhodli zajistit vysokou dostupnost Exchange na úrovni dat v databázích pomocí DAG, je pravděpodobné, že budete chtít zajistit také vysokou dostupnost na úrovni sítě. Připomínám, že v Exchange serveru 2013 klient nikdy nekomunikuje s databázovým serverem napřímo, ale vždy skrze Client Access Server (CAS). Je tedy nutné zajistit vysokou dostupnost této role instalací minimálně dvou CAS serverů a následně vyřešit rozklad protokolů, kterými budou klienti s CAS servery komunikovat. Tedy protokoly HTTP, IMAP, POP.

Pozor! Protokol MAPI je v Exchange 2013 použit pouze pro interní komunikaci Exchange serverů.

  • Hardware Load Balancer – pokud nechcete problematiku rozkladu síťových protokolů řešit softwarově, můžete sáhnout po partnerském řešení na úrovni hardware load balancerů. Existuje celá řada partnerských řešení, např. od společností KEMP technologies, F5 (BIGIP), nebo Barracuda. Hardwarový load balancing musíte (!) použít také v případě, že budou ve vaší organizaci pouze dva Exchange servery. Platí zde jednoduché pravidlo – v případě, že je server členem DAG, není možné na něm provozovat současně Network Load Balancing, který je obsažen přímo v systému Windows. Toto je důležité hlavně u menších řešení pouze o dvou Exchange serverech – zde je nutné počítat s nákupem dalšího zařízení, které hardwarový load balancing podporuje
  • Microsoft Network Load Balancing – technologie, která je součástí všech edicí Windows Serveru, může zajistit vytvoření síťového clusteru, tedy situace, kdy má více serverů společnou IP a MAC adresu. Toto řešení nelze použít na serverech, které jsou členy DAG (!)
  • Exchange 2013 nabízí i jednu novinku v rozkladu zátěže. Díky použití FrontEnd serveru (Role Client Access) je možné použít i DNS round robin technologii. V tomto případě je třeba pamatovat na TTL DNS záznamu a nastavit jej na přijatelný čas. Například 1 minuta. V tomto případě by v případě výpadku klienti byli přesměrováni na další server v pořadí po 1 minutě.

Ať již vyberete jakoukoli technologii síťové vysoké dostupnosti, je potřeba počítat s nastavením rozkladu patřičných protokolů (např. HTTP, IMAP, POP, atd.) na jednotlivé CAS servery. I zde existuje celá řada možností – např. směřovat vše na jeden CAS (pokud je dostupný), teprve v případě jeho nedostupnosti směřovat komunikaci na další CAS server; nebo je možné komunikaci rozkládat rovnoměrně. Toto již zcela záleží na vašich konkrétních požadavcích.

Závěrem

V tomto seriálu jsme se snažili sepsat vše nezbytné tak, aby každý správce Exchange Serveru 2013 měl hned po instalaci po ruce návod, pomocí kterého se může řídit a zajistit tak, že vše v jeho prostředí bude fungovat k jeho spokojenosti. I když nikdy není možné podchytit zcela vše, doufáme, že tento dokument pomůže ke správnému nastavení alespoň těch nejdůležitějších komponent Exchange.

Pro další zkoumání konfiguračních voleb Exchange serveru 2013 budete muset čerpat z oficiální Exchange dokumentace na Microsoft Technet stránkách:
http://technet.microsoft.com/en-us/library/bb124558

Tým KPCS CZ (www.kpcs.cz)
Martin Pavlis, Miroslav Knotek, Zbyněk Saloň
 

Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.

Témata článku: Microsoft, Ono, Jimi, Server, Exchange, Proto, Cluster, Robin

1 komentář

Nejnovější komentáře

  • Antonín Tesárek 7. 1. 2016 12:51:06
    Zdravím a díky za super článek. Lze jako witness použít VM na stejném...
reklama
Určitě si přečtěte

Vybíráte herní periferii nebo hardware? Pak zapomeňte na nálepku Gaming

Vybíráte herní periferii nebo hardware? Pak zapomeňte na nálepku Gaming

** Herní hardware se od toho běžného často liší jen vzhledem ** Při výběru stále nezapomínejte na základní parametry ** Poradíme jak vybrat herní hardware i periferie

20.  2.  2017 | Stanislav Janů | 35

10 nejhorších produktů v historii Microsoftu

10 nejhorších produktů v historii Microsoftu

20.  2.  2017 | Karel Javůrek | 132

Pojďme programovat elektroniku: Žádný bastlíř se neobejde bez armády švábů

Pojďme programovat elektroniku: Žádný bastlíř se neobejde bez armády švábů

** Každý bastlíř se po čase neobjede bez armády švábů ** Dnes si některé z nich vyzkoušíme ** Třeba zázračný posuvný registr

19.  2.  2017 | Jakub Čížek | 39

AMD oficiálně představilo procesory Ryzen. Známe i jejich české ceny

AMD oficiálně představilo procesory Ryzen. Známe i jejich české ceny

** AMD uvedlo první tři procesory Ryzen 7 ** Všechny budou pracovat s osmi jádry a šestnácti vlákny ** Na pulty obchodů se dostanou už za týden

22.  2.  2017 | Stanislav Janů | 123

Vyhledávání ve Windows není dokonalé, zkuste to 5× jinak

Vyhledávání ve Windows není dokonalé, zkuste to 5× jinak

** V macOS funguje vyhledávání Spotlight, ve Windows podobně propracovaná funkce chybí ** Alternativy se zaměřují na rychlé hledání souborů i externí zdroje ** Mnohé mohou vyhledávání ve Windows kompletně nahradit

18.  2.  2017 | Stanislav Janů | 58

EU se děsí Windows 10. Prý o nás vědí až příliš. Microsoft chystá změny

EU se děsí Windows 10. Prý o nás vědí až příliš. Microsoft chystá změny

** Evropští úředníci chtějí, aby byly Desítky transparentnější ** Microsoft od jara skutečně chystá změny ** Ochráncům soukromí to ale nestačí

21.  2.  2017 | Jakub Čížek | 217


reklama