Správa dat a skupin dostupnosti databáze

Transkript

1 KAPITOLA 9 Správa dat a skupin dostupnosti databáze Procházení úložiště informací Vytváření a správa skupin dostupnosti databáze Indexování obsahu Jedním z nejdůležitějších úkolů administrátora Exchange 2010 je správa úložiště informací. Každý Mailbox server nasazený v organizaci má úložiště informací, které může obsahovat databáze a informace o skupinách dostupnosti databáze (Database Availability Groups zkratka DAG). Tato kapitola je úvodem do databází a zaměřuje se na správu skupin dostupnosti databáze. Naučíte se následující: Jak zapnout, vytvořit a použít skupiny dostupnosti databází Jak spravovat databáze a jejich příslušné transakční protokoly Jak zlepšit dostupnost Mailbox serveru Jak spravovat fulltextové indexování databází Exchange Chcete-li se naučit spravovat databáze, podívejte se do kapitoly 10 na část Správa databáze poštovních schránek a veřejných složek. Procházení úložištěm informací Exchange 2010 pomocí klíčové architektury a její jednoduché, sjednocené struktury spojuje vysokou dostupnost a odolnost zpráv a schopnost obnovení po havárii. To umožňuje v Exchange 2010 zlepšit nepřetržitou replikaci a nahradit funkce clusteringu z Exchange 2007 robustnějším řešením, které nevyžaduje drahý hardware a má menší nároky na údržbu. Použití databází Primárním typem databáze použitým v Exchange Serveru je i nadále databáze poštovních schránek. Exchange Server 2010 také podporuje databáze veřejných složek. V Exchange Serveru 2010 však veřejné složky nejsou povinné, protože Microsoft Office

2 312 Kapitola 9 Správa dat a skupin dostupnosti databáze Outlook 2007 a pozdější nepoužívají veřejné složky pro přístup k informacím o stavu zaneprázdněnosti (free/busy) ani k offline adresáři (Offline address book zkratka OAB). Místo toho Outlook 2007 a pozdější verze k těmto informacím přistupují pomocí Client Access serveru v organizaci. Jak to funguje? Client Access servery nabízejí webové služby umožňující klientům přístup k poště, k informacím o stavu zaneprázdněnosti, k datům OAB a k jiným datům Exchange pomocí protokolu Hypertext Transfer Protocol (HTTP). Klienti Outlooku 2003 a dřívějších verzí požadují databázi veřejných složek pro připojení k Exchange Serveru. Tito klienti používají veřejné složky pro přístup k informacím o stavu zaneprázdněnosti a OAB. Pokud máte klienty Outlook 2003 nebo dřívější a také pokud máte klienty s jiným prostředím Messaging Application Programming Interface (MAPI), tito klienti mohou pokračovat v přístupu k veřejným složkám na serverech poštovních schránek pomocí Exchange Konfiguraci veřejných složek můžete spravovat pomocí konzoly Public Folder Management Console a pomocí Exchange Management Shell. Poznámka: Exchange Server 2010 nepodporuje přístup k veřejným složkám pomocí protokolu Network News Transfer Protocol (NNTP) ani pomocí protokolu Internet Message Access Protocol version 4 (IMAP4). Exchange Server 2010 také nepodporuje nadřazené složky pro ne-mapi klienty v databázích veřejných složek. Jediný způsob, jak tuto funkcionalitu v Exchange Serveru 2010 zachovat, je udržovat v organizaci Exchange Server Když instalujete první Mailbox server v organizaci, tento server má v úložišti informací samostatnou výchozí databázi poštovních schránek a samostatnou výchozí databázi veřejných složek. Konkrétní konfigurace ovšem závisí na vašich odpovědích během instalace. Když instalujete první Mailbox server, instalační program vás vyzve k zadání: Zda chcete vytvořit výchozí databázi poštovních schránek. Pokud se rozhodnete ji vytvořit, pak můžete zadat také její název a umístění. Zda některý klientský počítač má Outlook 2003 nebo dřívější verzi, případně Entourage. Pokud ano, výchozí databáze veřejných složek se vytvoří. Pokud odpovíte, že ne, výchozí databáze veřejných složek se nevytvoří. Poznámka: Pokud organizace Exchange již obsahuje Exchange Servery 2003, pak se při instalaci tyto výzvy, týkající se klientů s Outlookem 2003 nebo dřívější verze nebo Entourage, neobjeví. Ve smíšené instalaci, jako je tato, instalační program Setup vytvoří databáze veřejných složek automaticky, aby zajistil zpětnou kompatibilitu. Když v organizaci instalujete další Mailbox servery, tyto servery mají na začátku pouze jednu databázi, a to výchozí databázi poštovních schránek (pokud se ji rozhodnete vytvořit). Důvodem této výchozí konfigurace je skutečnost, že rozhodnutí, zda je databáze

3 Procházení úložištěm informací 313 veřejných složek v organizaci potřebná, závisí na tom, jestli instalujete první Mailbox server. Pokud instalujete další servery poštovních schránek, pak se při instalaci neobjeví výzvy týkající se klientů s Outlookem 2003 nebo dřívější verze nebo Entourage. Hlavním důvodem je, že v organizaci Exchange je vyžadována pouze jedna databáze veřejných složek a jakákoli další databáze veřejných složek je nepovinná. Mějte na paměti, že bez ohledu na vaše odpovědi během instalace můžete výchozí databázi veřejných složek a také další databáze veřejných složek (vytvořit kdykoli) pomocí nástrojů správy Exchange. Principy databázových struktur Na rozdíl od dřívějších verzí Exchange nepoužívá Exchange Server 2010 skupiny úložišť (Storage Groups) a funkcionalita spojená se skupinami úložišť byla přesunuta na úroveň databáze. S ohledem na tyto změny mají databáze Exchange oddělený, samostatný svazek protokolů (Transaction Logs), který obsahuje série sekvenčně pojmenovaných souborů protokolů. Každý soubor protokolu má velikost 1MB. Kromě protokolů mají databáze několik dalších typů souborů, které jsou s nimi asociovány. Jak ukazuje tabulka 9.1, tyto soubory obsahují jeden nebo více souborů s kontrolními body, dočasný pracovní soubor a jeden nebo více souborů transakčních protokolů. V závislosti na stavu Exchange Serveru můžete vidět také další pracovní soubory. Když vytváříte databázi, můžete určit oddělená umístění složek pro použití souborů databáze a transakčních protokolů. Každá databáze má soubory indexování obsahu, které jsou s ní také asociovány. Tyto soubory se generují službami fulltextového vyhledávání, které běží na serverech poštovních schránek. Tabulka 9.1: Data a soubory protokolů používané databázemi Typ souboru Název souboru Popis Datové soubory Databázové soubory NazevDatabaze.edb Primární soubor databáze, který obsahuje data poštovních schránek. Dočasná data Tmp.edb Dočasná databáze probíhajících transakcí. Soubor kontrolních bodů (checkpoint) E##.chk Soubor kontrolních bodů, který sleduje, které transakce v souboru protokolu proběhly. Soubory protokolů transakcí Soubor primárního protokolu E##.log Primární soubor protokolů, který obsahuje záznamy o všech změnách, které ještě musí proběhnout. Sekundární soubory protokolů E## log, E## log, Dodatečné soubory protokolů použité podle potřeby. Rezervační soubory protokolů E##Res00001.jrs, Soubory použité k rezervaci prostoru pro E##Res00002.jrs, dodatečné soubory protokolů, když primární soubor protokolu začíná být plný. Fulltextové indexovací soubory Indexové soubory obsahu.ci,.wid,.dir,.000,.001,.002 Soubory sloužící pro fulltextové indexování dat v poštovních schránkách.

4 314 Kapitola 9 Správa dat a skupin dostupnosti databáze Databázi Exchange můžete použít ke snížení administrátorské námahy, která je značná zvláště při správě velkých instalací. Například místo jedné databáze o velikosti 10 Terabytů (TB) pro celou organizaci můžete vytvořit deset databází o velikosti 1 TB, které se spravují mnohem snáze. Tip: Pokud máte dvě nebo více kopií databází poštovních schránek, pak největší doporučená velikost databáze Exchange Serveru 2010 je 2 TB. Tato velikost je možná díky značným vylepšením jádra Exchange Serveru Dále zjistíte, že velké databáze lépe podporují velké poštovní schránky, které mohou požadovat pracovníci vedení firmy. Nicméně velikost většiny poštovních schránek by měla být limitována na 2 až 10 GB. Když vytvoříte databázi poštovní schránky nebo veřejných složek, určíte jméno databáze a toto jméno určuje také jméno primárního souboru databáze. Například když vytvoříte databázi poštovních schránek nazvanou MarketingDept, soubor primární databáze se bude jmenovat MarketingDept.edb. Výchozí umístění souborů databáze Exchange Serveru 2010 je stejné jako umístění souborů protokolů. Jestliže si přejete databázi umístit jinam, můžete určit jiné umístění. Oddělení souborů databáze od souborů protokolů a jejich umístění na jiné jednotky uložené na jiných discích může pomoci zvládnout organizaci při zachování vysokého výkonu a obnovitelnosti. Tip: Hlavním důvodem pro oddělení souborů databáze od souborů protokolů je obnovitelnost. Například v případě havárie disku, na kterém byla uložena databáze, protokoly transakcí potřebné ke kompletní obnově budou pravděpodobně umístěny na jiném (a pravděpodobně fungujícím) disku. Použitelnost tohoto přístupu závisí na velikosti a konfiguraci serverů poštovních schránek Exchange a také na požadavcích služeb, kterým musíte vyhovět. Množství souborů asociovaných s databázemi umožňuje postupnou kontrolu Exchange Serveru, a pokud konfigurujete datové soubory správně, mohou vám pomoci zvládnout organizaci Exchange efektivně a přitom zajistit optimální výkon. Při malé implementaci Exchange možná budete chtít umístit všechna data na stejný disk. Pokud se však organizace rozvine a zvětší, budete chtít organizovat data podle databází a rozmístit data pro každou databázi na samostatné disky. To pochopitelně není vždy možné, zvláště u malých až středních organizací s omezenými zdroji. Například pokud máte deset databází o velikosti 1 TB a pouze pět datových disků, můžete disky nakonfigurovat následovně: Disk 1 obsahuje databáze 1 a 2 a příslušné datové soubory. Disk 2 obsahuje databáze 3 a 4 a příslušné datové soubory. Disk 3 obsahuje databáze 5 a 6 a příslušné datové soubory. Disk 4 obsahuje databáze 7 a 8 a příslušné datové soubory. Disk 5 obsahuje databáze 9 a 10 a příslušné datové soubory.

5 Procházení úložištěm informací 315 Při implementaci sítě SAN (Storage Area Network), kde používáte čísla logických jednotek (Logical Unit Numbers zkratka LUN) a nevidíte strukturu disků za čísly, by mělo stačit umístit databáze na oddělené LUN. Chcete-li data chránit, měli byste zvážit použití RAID (Redundant Array Of Inexpensive Disks), který je pravděpodobně implementován, pokud používáte SAN. Pokud však konfigurujete skupinu dostupnosti databáze s více členskými servery, z nichž každý má kopii databází poštovních schránek, pak pravděpodobně nepotřebujete žádný typ technologie RAID a možná ani denní zálohování. Prostě si pamatujte, že Microsoft doporučuje mít kromě aktivní databáze ještě nejméně tři její kopie. Z praxe: Jestliže se myšlenka nepotřebnosti technologie RAID zdá být radikálním konceptem, pak návrh na ukončení každodenního zálohování dat Exchange může vypadat jako revoluční. Pokud však máte vícenásobné denní kopie svých dat na samostatných serverech, pak opravdu nemusíte vytvářet každodenní zálohy svých dat Exchange. To neznamená, že nemusíte zálohovat vůbec. Znamená to, že nemusíte data Exchange zálohovat každý den. Pravidelné záložní kopie svých Exchange serverů budete pravděpodobně vytvářet i nadále. Také budete nadále vytvářet periodické plné zálohy všech dat Exchange s rotací záložního úložiště, mimo jiné jako zabezpečení proti katastrofám. Skupiny dostupnosti databáze vás možná znovu přivedou k myšlence použít SAN. Než mít jedno masivní (a zřejmě velmi drahé) ukládací zařízení, bylo by možná lépe spolehnout se na interní disky serverů nebo více menších (a zřejmě lacinějších) ukládacích zařízení. Jeden z důvodů pro použití interních disků je, že spolehlivé harddisky o velikosti více TB začínají být dobře dostupné. Několik serverů s vícenásobnými, velkými interními harddisky lze pořídit za zlomek ceny jedné masivní SAN. Pokud používáte SAN, pak možná zjistíte, že množství menších ukládacích zařízení je lepší než jedno masivní, protože tím se zbavíte jediného zdroje možné havárie (ukládacího zařízení), která by mohla způsobit výpadek všech vašich serverů poštovních schránek. Já vím, já vím SAN nikdy nespadne. Ale může se to stát. (A stává se to.) Zlepšení dostupnosti Exchange Server 2010 umožňuje chránit databáze a jejich data pomocí konfigurace databází poštovních schránek pro vysokou dostupnost. Provádí to automaticky, když používáte skupiny dostupnosti databáze. Skupiny dostupnosti databáze vám umožňují logicky seskupit databáze podle serverů, které databáze hostují. Každý Mailbox server může mít více databází a každá databáze může mít až 16 kopií. Jedna skupina dostupnosti databáze může mít až 16 Mailbox serverů s databázemi. To nabízí automatické obnovení dat na úrovni databáze pro případ havárie, která by postihla jednotlivé databáze. Jakýkoli server ve skupině dostupnosti databáze může hostovat kopii databáze poštovních schránek z jakéhokoli jiného serveru ve skupině dostupnosti databáze. Servery ve skupině dostupnosti databáze mohou hostovat i jiné role Exchange. Členské servery musí být ve stejné doméně Active Directory.

6 316 Kapitola 9 Správa dat a skupin dostupnosti databáze Na rozdíl od Exchange Serveru 2007, kde by dosažení tak vysoké úrovně dostupnosti vyžadovalo zásahy administrátora, Exchange 2010 integruje vysokou dostupnost a odolnost přenosu zpráv do klíčové architektury. Tím nabízí jednotnou architekturu jak pro vysokou dostupnost, tak pro obnovitelnost po haváriích. Tento nový přístup redukuje cenu a komplexnost nasazení vysoce dostupného řešení. Jak to funguje? Exchange 2010 má rozšířenou průběžnou replikaci a funkce clusteringu Exchange 2007 byly nahrazeny robustnějším řešením, které nevyžaduje drahý hardware a zároveň vyžaduje méně údržby. Předchozí verze Exchange byly clustrované aplikace, které pro vysokou dostupnost používaly model správy clustrovaných zdrojů. Exchange 2010 není clustrovaná aplikace a nepoužívá model clustrovaných zdrojů pro vysokou dostupnost. Místo toho používá Exchange 2010 svůj vlastní interní model vysoké dostupnosti. Ačkoli dosud používá některé komponenty Windows Failover Clusteringu (clustering s podporou převzetí služeb při selhání), tyto komponenty nyní spravuje exkluzivně Exchange Pro podporu průběžné replikace nabízel Exchange 2007 několik přístupů, včetně Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) a Standby Continuous Replication (SCR). LCR bylo řešení s jedním serverem pro asynchronní posílání protokolů, přehrání a obnovení. CCR kombinovalo funkce pro asynchronní posílání protokolů, přehrání a obnovení s převzetím služeb při selhání a funkcemi správy clusterových služeb. Bylo navrženo pro konfiguraci clusterovaných serverů poštovních schránek s dedikovanými aktivními a pasivními uzly. SCR bylo rozšíření LCR a CCR, které používalo stejné funkce pro posílání protokolů, přehrání a obnovení jako LCR a CCR. Bylo však navrženo pro použití pohotovostních serverů pro obnovení. Exchange 2010 obsahuje některé aspekty technologie průběžné replikace, které se dříve používaly v CCR a SCR. Tato technologie se však podstatně změnila. Protože z Exchange 2010 byly odstraněny skupiny úložišť, průběžná replikace operuje na úrovni databáze. Exchange 2010 stále používá databáze Extensible Storage Engine (ESE). Tyto databáze vytvářejí protokoly transakcí, jež se replikují a přehrávají do kopií databází poštovních schránek. Protože každá databáze poštovních schránek má až 16 kopií, můžete mít jednu nebo více kopií databáze až na 16 různých serverech. Technologie průběžné replikace v Exchange 2010 již pro přenos a ukládání protokolů nepoužívá Server Message Block (SMB), nýbrž samostatný TCP port definovaný administrátorem. Tato funkce obsahuje také vestavěné volby pro šifrování na síti a pro kompresi datového toku. V Exchange 2007 prováděla přehrávání protokolů do pasivních kopií databáze služba Microsoft Exchange Replication. Když byla pasivní kopie aktivována, potom se připojením databáze službou Microsoft Exchange Information Store vymazala databázová mezipaměť. Exchange 2010 službu Microsoft Exchange Replication pro tento účel nepoužívá. Místo toho služba Exchange Replication periodicky monitoruje stavy všech připojených databází a ESE. Když služba detekuje selhání, upozorní Active Manager, který potom selhání ošetří. (Více informací o funkci Active Manager najdete dále v této kapitole.)

7 Procházení úložištěm informací 317 Microsoft přesunul funkci přehrávání pasivních kopií do služby Microsoft Exchange Information Store. Protože pasivní i aktivní kopie databáze spravuje stejná služba, databázová mezipaměť je dostupná pro použití i po havárii nebo přepnutí a žádná data se neztratí. Použití jediné služby pro správu pasivních i aktivních databází má také další výhody. Například: zatímco převzetí služeb po selhání v clustrovaných serverech poštovních schránek v prostředí CCR pro Exchange 2007 trvalo kolem 2 minut, převzetí služeb po selhání databáze poštovních schránek v Exchange 2010 většinou netrvá déle než 30 sekund. Tak jako v prostředí SCR koncepty prodlevy přehrávání a prodlevy zkrácení platí pro kopie databází. Kopie databází lze zálohovat pomocí zálohovacích aplikací pro Exchange založených na službě Volume Shadow Copy Service (VSS). V Exchange 2010 se databáze definují na úrovni organizace, a nikoli na úrovni serveru. Když administrátor stanoví kopii databáze jako aktivní databázi poštovních schránek, tento proces se nazývá přepnutí. Když databázi postihne havárie a aktivní kopií se stane jiná databáze, tento proces se nazývá převzetí služeb při selhání (failover). Přepnutí a převzetí služeb při selhání se pro jednotlivé databáze děje na úrovni databáze a pro všechny databáze hostované serverem na úrovni serveru. Když nastane přepnutí nebo převzetí služeb, pak se jiné role Exchange Serveru 2010 přizpůsobí tomuto přepnutí většinou ihned a automaticky přesměrují klienty a přenos zpráv podle potřeby. Většinu administrátorských úkolů pro skupiny dostupnosti můžete sice provádět v Exchange management Console, ale pokud použijete Exchange Management Shell, pak máte k dispozci více možností. Tabulka 9.2. ukazuje přehled příkazů, které můžete použít pro správu skupin dostupnosti, a jejich vlastnosti. Tabulka 9.2: Příkazy pro práci se skupinami dostupnosti databáze. Oblast správy Správa skupin dostupnosti databáze Správa kopií databáze Příkazy Get DatabaseAvailabilityGroup New DatabaseAvailabilityGroup Remove DatabaseAvailabilityGroup Set DatabaseAvailabilityGroup Add MailboxDatabaseCopy Get MailboxDatabaseCopyStatus Remov boxDatabaseCopy Resum boxDatabaseCopy Set MailboxDatabaseCopy Suspend MailboxDatabaseCopy Updat boxDatabaseCopy

8 318 Kapitola 9 Správa dat a skupin dostupnosti databáze Oblast správy Správa databáze Konfigurace sítě Správa přepínání Členství serverů Příkazy Clean MailboxDatabase Dismount Database Get MailboxDatabase Move DatabasePath New MailboxDatabase Remov boxDatabase Set MailboxDatabase Get DatabaseAvailabilityGroupNetwork New DatabaseAvailabilityGroupNetwork Remove DatabaseAvailabilityGroupNetwork Set DatabaseAvailabilityGroupNetwork Move Activ boxDatabase Start DatabaseAvailabilityGroup Stop DatabaseAvailabilityGroup Restore DatabaseAvailabilityGroup Add DatabaseAvailabilityGroupServer Remove DatabaseAvailabilityGroupServer Při plánování skupin dostupnosti databáze mějte na paměti, že kopie databází můžete vytvářet pouze na těch serverech poštovních schránek, které jsou ve stejné skupině dostupnosti databáze a nehostují aktivní kopie databáze. Aktivní kopie se liší od pasivní kopie tím, že se používá a že uživatelé, kteří nejsou offline, k ní přistupují. Nemůžete vytvořit dvě kopie stejné databáze na stejném serveru. Kromě toho byste při práci s kopiemi databází neměli zapomenou na další věci: Databáze poštovních schránek Exchange 2010 se mohou replikovat pouze na servery poštovních schránek Exchange 2010 ve stejné skupině dostupnosti databáze. Databázi nemůžete replikovat mimo skupinu dostupnosti databáze ani nemůžete replikovat databázi poštovních schránek 2010 na Exchange Server Všechny kopie databáze na všech serverech s kopiemi používají stejnou cestu. Cesty k databázím a jejich protokolům na žádném serveru poštovních schránek nesmí být v konfliktu s jinými cestami k databázím. Mailbox servery ve skupině dostupnosti databáze musí být ve stejné doméně Active Directory. Kopie databáze lze vytvářet ve stejných nebo různých lokalitách Active Directory a na stejných nebo různých podsítích. Kopie databází však nepodporují Mailbox severy s větší latencí odezvy sítě než 250 ms (výchozí nastavení). Poznámka: Kopie databází jsou pouze pro databáze poštovních schránek. Pro redundanci a vysokou dostupnost databází veřejných složek byste měli použít replikaci veřejných složek. Na rozdíl od prostředí CCR v Exchange 2007 můžete replikaci veřejných složek použít k replikaci více databází veřejných složek mezi servery ve skupině dostupnosti databáze. Vzhledem k tomu, že skupiny dostupnosti databáze mohou být roztaženy napříč lokalitami, je možno databáze poštovních schránek přesouvat mezi lokalitami.

9 Procházení úložištěm informací 319 Seznámení s Active Managerem V Exchange 2010 Active Manager zajišťuje model zdrojů a funkce správy převzetí služeb při selhání, které dříve zajišťovala služba Cluster. Když vytvoříte svou první skupinu dostupnosti databáze v organizaci Exchange, pak Exchange vytvoří Windows Failover Cluster, ale neexistují žádné skupiny clusteru pro Exchange a žádné zdroje úložiště v clusteru. Proto, jak vidíte na obrázku 9.1, Failover Cluster Manager ukazuje pouze základní informace o clusteru, které obsahují název clusteru, sítě clusteru a konfiguraci kvora. Uzly clusteru a sítě existují také a jejich stav můžete zkontrolovat ve Failover Cluster Manageru, ale všechny zdroje clusteru, včetně uzlů a sítí, za vás spravuje Exchange. Dále Exchange zajišťuje funkce správy využití uzlu clusteru a správy sítě a vy si můžete stav uzlu a sítě zkontrolovat v Exchange Management Console. Obrázek 9.1: Ve Failover Cluster Manageru můžete zkontrolovat stav clusteringu Z praxe: Failover Cluster Manager je primární administrátorský nástroj pro práci se službou Cluster. Ačkoli k prohlížení a správě skupin dostupnosti databáze musíte používat administrátorské nástroje Exchange a jejich funkce, Failover Cluster Manager vám ukazuje stav clusteringu. Když v levém panelu vyberete název clusteru, získáte rychlý přehled konfigurace clusteru, včetně aktuální konfigurace kvora, která může být buď Node Majority nebo Node and File Share Majority, podle počtu uzlů ve skupině dostupnosti databáze. Když v levém panelu vyberete položky uzlů, můžete rychle zkontrolovat stav všech uzlů ve skupině dostupnosti databáze. Rozbalením položky Networks v levém panelu a následným vybráním dostupných sítí clusteru můžete zkontrolovat stav sítě a také jednotlivých síťových spojení. Když v levém panelu vyberete název clusteru a potom klepnete na odkaz Recent Cluster Events, můžete zkontrolovat chyby a upozornění v protokolech událostí na všech uzlech clusteru Active Manager běží na Mailbox serverech, které jsou členy skupiny dostupnosti databáze. Active Manager operuje buď jako držitel primární role, nebo jako držitel poho-

10 320 Kapitola 9 Správa dat a skupin dostupnosti databáze tovostní sekundární role, podle databáze. Pokud pracuje jako primární, nazývá se Primary Active Manager a rozhoduje, která kopie databáze bude aktivní a které kopie lze aktivovat. Získává upozornění o změnách topologie a reaguje na selhání serverů. Aktivní může být v jednom okamžiku pouze jedna kopie databáze a tato kopie může být připojena nebo odpojena. Člen skupiny, který drží primární roli, je vždy aktuálním vlastníkem zdroje kvora clusteru a výchozí skupiny clusteru. Jestliže server, který vlastní zdroj kvora clusteru, selže, primární roli automaticky přebere jiný server ve skupině a tento server přebere také vlastnictví výchozí skupiny clusteru. Pokud chcete kvůli údržbě nebo upgradu vypnout server, který hostuje zdroj kvora clusteru, musíte nejdříve přesunout primární roli na jiný server ve skupině. Držitelé sekundárních rolí nazývaní Standby Active managers zajišťují informace o tom, který server hostuje aktivní kopii databáze poštovních schránek, a předávají je jiným komponentám Exchange, například službě RPC Client Access nebo službě Hub Transport. Držitel sekundární role detekuje selhání replikovaných lokálních databází a lokálního úložiště informací a předává upozornění na selhání držiteli primární role. Požaduje také od držitele primární role inicializaci převzetí služeb při selhání. Držitel sekundární role neurčuje, který server provede převzetí, ani neaktualizuje stav umístění databáze držitele primární role. V rámci lokálního systému držitel primární role provádí také funkce sekundární role tím, že detekuje selhání lokální databáze a lokálního úložiště informací a vydává příslušná upozornění. Active Manager určuje, která kopie databáze by měla být aktivována, a to tak, že se pokouší najít databázi poštovních schránek, která má následující charakteristické znaky: Databáze má status Healthy, DisconnectedAndHealthy nebo DisconnectedAndResynchronizing. Databáze má index obsahu se statusem Healthy. Databáze má délku fronty kopírování menší než 10 souborů protokolů. Databáze má délku fronty přehrávání menší než 50 souborů protokolů Pokud žádná kopie databáze nesplňuje všechna tato kritéria, Active Manager pokračuje v hledání nejlepší volby snižováním výběrových požadavků až k úspěšné iteraci. Vytváření a správa skupin dostupnosti databáze Skupiny dostupnosti databáze jsou kontejner v Active Directory a představují horní logickou hladinu clusteringu Windows. Skupiny dostupnosti databáze můžete vytvářet různými způsoby. Vytvoření skupiny dostupnosti databáze a její uvedení do provozu vyžaduje následující minimum: 1. Vytvořit skupinu dostupnosti databáze 2. Přidat do skupiny členské servery

11 Vytváření a správa skupin dostupnosti databáze Vytvořit monitorovací server 4. Vytvořit síť skupin dostupnosti Tyto úkoly a obecné administrátorské úkoly pro skupiny dostupnosti databáze proberu v následujících částech. Vytváření skupin dostupnosti databáze Skupina dostupnosti databáze definuje sadu serverů, které zajišťují automatické obnovení na úrovni databáze v případě selhání databáze. Vytvářet skupiny dostupnosti databáze mohou pouze členové skupiny Organization Management. Když vytváříte skupinu dostupnosti databáze, můžete určit monitorovací server sami nebo nechat Exchange, aby jej vybral za vás. Úkolem role monitorovacího serveru je pomáhat udržovat stav skupiny, a to tak, že když je ve skupině sudý počet členů, monitorovací server udržuje kvorum. Na monitorovacím serveru můžete vyznačit takzvanou monitorovací složku, aby ji skupina dostupnosti databáze mohla použít, nebo můžete nechat Exchange, aby vytvořil výchozí monitorovací složku za vás. Exchange vytvoří a zabezpečí složku automaticky, jako součást konfigurace monitorovacího serveru. Tato složka by neměla být používána pro jiné účely než pro monitorovací server skupiny dostupnosti databáze. Požadavky pro monitorovací server jsou následující: Monitorovací server nesmí být členem skupiny dostupnosti databáze. Monitorovací server musí být ve stejné doménové struktuře jako skupina dostupnosti databáze. Monitorovací server musí běžet na Windows Server 2003, na Windows Server 2008 nebo na pozdější verzi. Chcete-li se ujistit, že administrátoři Exchange vědí o dostupnosti monitorovacího serveru a že server zůstává pod kontrolou administrátora Exchange, Microsoft doporučuje použít Exchange Server 2010 k hostování monitorovací složky. Použití Exchange Serveru 2010 také zajistí, aby Exchange měl dostatečná oprávnění pro vzdálené vytváření a sdílení monitorovací složky. Preferovaným monitorovacím serverem je Hub Transport Server ve stejné lokalitě Active Directory jako většina členů skupiny dostupnosti databáze. Jeden server může sloužit jako monitorovací server pro více skupin dostupnosti databáze. Každá skupina dostupnosti databáze však musí mít svou vlastní oddělenou monitorovací složku. Při vytváření skupiny dostupnosti databáze Exchange vytvoří v Active Directory objekt msexchmdbavailabilitygroup a související objekty. Tyto objekty reprezentují skupinu dostupnosti databáze, její členy, sítě a atributy. Adresářový objekt msexchmdbavailabilitygroup se používá k ukládání informací o skupině dostupnosti databáze, například informací o členství serveru. Informace o zahrnutých databázích je uložena v databázi clusteru. Když do skupiny dostupnosti databáze přidáte první server, automaticky se

12 322 Kapitola 9 Správa dat a skupin dostupnosti databáze pro tuto skupinu dostupnosti databáze vytvoří cluster s podporou převzetí služeb při selhání a začne monitorování pro převzetí služeb v případě selhání. Mechanizmus clusteru s podporou převzetí služeb při selhání a také databáze clusteru se pak použijí pro sledování a údržbu informací o skupině dostupnosti databáze. Když máte vytvořenu skupinu dostupnosti databáze, můžete přidávat servery do skupiny nebo naopak servery ze skupiny odebírat. Když do skupiny dostupnosti databáze přidáte první Mailbox server, stane se následující: Nainstaluje se komponenta Windows Failover Clustering a příslušné nástroje. (Pokud ještě nejsou nainstalovány.) Tip: Windows Failover Clustering je dostupný pouze na Mailbox serverech Exchange 2010 Enterprise Edition, které běží na verzi Windows Server 2008 SP2 Enterprise nebo pozdější nebo na Windows Server 2008 R2 nebo pozdější. Kromě toho každý Mailbox server ve skupině dostupnosti databáze musí mít nejméně dvě síťové karty, aby mohl zajistit samostatnou oddělenou replikaci a síť pro přenos zpráv. Cluster s podporou převzetí služeb při selhání se vytvoří použitím jména skupiny dostupnosti databáze. Pro účely ověřování a přístupová oprávnění je cluster reprezentován účtem počítače, který je vytvořen ve výchozím kontejneru pro počítače. Tento účet počítače odkazuje na účet názvu virtuální sítě clusteru nebo na objekt sítě clusteru. Server se přidá do objektu msexchmdbavailabilitygroup v Active Directory. Když vytvoříte skupiny dostupnosti databáze, přiřadí se skupině IP adresa. Když do skupiny přidáte první server, pak se název a IP adresa skupiny dostupnosti databáze pomocí zápisu Host (A) registrují v systému Domain Name System (DNS) pomocí zápisu Host (A). Název nesmí být delší než 15 znaků a musí být jedinečný v doménové struktuře Active Directory. Poznámka: Skupina dostupnosti databáze může mít více IP adres. Pokud tomu tak je, pak pouze jedna z nich je registrována v DNS. Databáze clusteru se aktualizuje informacemi o databázích připojených k serveru. Exchange kontroluje aktuální konfiguraci sítě, jak je prezentována clusterem. Pokud má server správně konfigurovanou síťovou kartu, potom se konfigurace této síťové karty použije pro vytvoření replikační sítě. Jestliže má server dvě síťové karty, potom se konfigurace těchto dvou síťových karet použijí pro vytváření samostatných sítí pro replikaci a přenos zpráv. Vytvoří se monitorovací složka a monitorovací sdílení. Oprávnění se nastaví tak, že účet názvu sítě reprezentující cluster má plný přístup. Když do skupiny dostupnosti databáze přidáte druhý server a další servery, stane se následující:

13 Vytváření a správa skupin dostupnosti databáze 323 Server se připojí ke clusteru s podporou převzetí služeb při selhání pro skupinu dostupnosti databáze (Database Availability Group zkratka DAG). Server se přidá do objektu msexchmdbavailabilitygroup v Active Directory. Databáze clusteru se aktualizuje informacemi o databázích připojených na server. Pokud má skupina dostupnosti databáze jeden členský server, potom cluster s podporou převzetí služeb při selhání zpočátku použije režim kvora Node Majority. Když do skupiny dostupnosti databáze přidáte druhý Mailbox server, Exchange změní kvorum clusteru na model kvora Node and File Share Majority a začne pro kvorum clusteru používat složku a UNC cestu (Universal Naming Convention zkratka UNC). Jestliže monitorovací složka neexistuje, Exchange ji automaticky vytvoří a nakonfiguruje její bezpečnost s plným přístupem pro lokální administrátory a pro účet počítače sítě clusteru skupiny dostupnosti databáze. Z praxe: Každý cluster s podporou převzetí služeb při selhání má zdroj, který zajišťuje údržbu monitorovacích protokolů. Tento zdroj se nazývá kvorum neboli monitorovací zdroj. Zdroj kvora zapisuje informace o všech změnách databáze clusteru do monitorovacích protokolů. Tím je zajištěno, že informace clusteru a data o stavu mohou být obnoveny. Když vytvoříte skupinu dostupnosti databáze, Exchange automaticky určí vhodnou konfiguraci kvora pro váš cluster založenou na počtu členských serverů. Pokud má skupina dostupnosti databáze (DAG) lichý počet členů, Exchange použije režim kvora Node Majority. Jestliže má DAG sudý počet členů, Exchange použije model kvora Node and File Share Majority. Při konfiguraci clusteru Node Majority mají servery lokální zařízení kvora. Toto zařízení ukládá informace o konfiguraci clusteru. Při konfiguraci clusteru Node and File Share Majority nepoužívají servery monitorovací zařízení kvora, ale monitorovací soubor. Jinak řečeno konfigurace Node and File Share Majority pracuje podobně jako konfigurace Node Majority. Skupinu dostupnosti databáze můžete vytvořit následujícím postupem: 1. V Exchange Management Console rozbalte uzel Organization Configuration. Potom vyberte příslušný uzel Mailbox a klepněte na něj pravým tlačítkem. V místní nabídce vyberte New Database Availability Group. Nyní byste měli vidět průvodce New Database Availability Group Wizard, jak ukazuje obrázek V textovém poli Database Availability Group Name napište název skupiny dostupnosti databáze o délce až 15 znaků. Název musí být jedinečný v doménové struktuře Active Directory a nesmí obsahovat mezery ani jiné speciální znaky. 3. Tento krok je nepovinný. Vyberte políčko Witness Server a potom zadejte jméno serveru ve stejné doménové struktuře Active Directory jako skupina dostupnosti databáze, aby fungoval jako monitorovací server. Klepněte na tlačítko OK. Protože tento server nemůže být členem skupiny dostupnosti databáze, ujistěte se, že jste nevybrali servery, které mají být členy skupiny dostupnosti databáze, kterou právě konfigurujete.

14 324 Kapitola 9 Správa dat a skupin dostupnosti databáze Obrázek 9.2: Zadejte název skupiny dostupnosti databáze a umístění souboru Poznámka: Server, který vyberete jako monitorovací server, může být členem jiné skupiny dostupnosti databáze. Všimněte si také, že pokud necháte volbu Witness Server vypnutou, Exchange se pokusí vybrat monitorovací server automaticky. Pokusí se najít Hub Transport Server bez instalované role Mailbox, a to ve stejné lokalitě Active Directory jako většina členů DAG. 4. Vyberte zaškrtávací políčko Witness Directory a potom zadejte lokální cestu pro složku, která se bude používat k ukládání monitorovacích dat, například C:\WitnessDir. Jestliže složka neexistuje, Exchange se ji pokusí vytvořit za vás na monitorovacím serveru. Pokud nezadáte monitorovací složku, Exchange se pokusí vytvořit složku pojmenovanou relativně ke skupině dostupnosti databáze na systémovém disku monitorovacího serveru. Poznámka: Aby Exchange mohl vytvořit a sdílet monitorovací složku na serveru, potřebuje mít na serveru vhodné oprávnění. Můžete sice nastavit lokální cestu ke složce, ale název sdílení se nastaví automaticky ve formátu NazevDAG.NazevDomeny, například takto: WestCampusDag1.CpANDL.COM. Toto sdílení se nakonfiguruje tak, že účet virtuálního názvu clusteru s podporou převzetí služeb při selhání má plný přístup.

15 Vytváření a správa skupin dostupnosti databáze 325 Tip: Jestliže monitorovací server je Exchange Server ve stejné doménové struktuře, potom Exchange bude schopen vytvořit a sdílet složku. Pokud Exchange nemůže vytvořit a sdílet složku, uvidíte chybové hlášení a musíte problém vyřešit. Pomocí příkazu Set- DatabaseAvailabilityGroup s parametrem WitnessDirectory můžete kdykoli určit novou monitorovací složku. Novou monitorovací složku můžete nastavit také v Exchange Management Console. Poklepejte na DAG, v poli Witness Directory napište novou cestu ke složce a potom klepněte na tlačítko OK. Jestliže monitorovací server není Exchange Server 2010, musíte přidat skupinu zabezpečení Exchange Trusted Subsystem do skupiny Local Administrators na monitorovacím serveru. 5. Klepnutím na tlačítko New vytvořte novou skupinu dostupnosti databáze a potom klepněte na tlačítko Finish. Na stránce Completion uvidíte shrnutí úspěšné operace. Pokud nastala chyba, musíte problém vyřešit. Jinak můžete ke skupině dostupnosti databáze přidávat databáze podle potřeby. Skupiny dostupnosti databáze můžete vytvářet v Exchange management Shellu pomocí rutiny New-DatabaseAvailabilityGroup. Příklad 9.1 ukazuje syntaxi a použití. V Exchange Management Console můžete zadat název skupiny o délce až 15 znaků, protože stejné jméno se použije jako název počítače pro objekt sítě clusteru, který reprezentuje skupinu. Poznámka: Nepleťte si lokální monitorovací složku se souborovým sdílením. Lokální monitorovací složka má lokální cestu na monitorovacím serveru, například C:\WitnessShare. Když určíte monitorovací složku, pak Exchange vytvoří složku a pak souborové sdílení podle potřeby. Příklad 9.1: Syntaxe a použití rutiny New-DatabaseAvailabilityGroup Syntaxe New DatabaseAvailabilityGroup Name NazevDAG [ DatabaseAvailabilityGroupIp Adresy] [ WitnessServer NázevServeru] [ WitnessDirectory MístníAdresářNaMonitorovacímServeru] [ DomainController PlněKvalifikovanýNázev] [ ThirdPartyReplication <Disabled Enabled>] Použití New DatabaseAvailabilityGroup Name EastCampusDAG1 WitnessServer MailServer25 WitnessDirectory C:\EastCampusDAG1 New DatabaseAvailabilityGroup Name WestCampusDAG1

16 326 Kapitola 9 Správa dat a skupin dostupnosti databáze WitnessServer MailServer25 WitnessDirectory C:\WestCampusDAG1 DatabaseAvailabilityGroupIp , Správa členství skupin dostupnosti Když do skupiny dostupnosti databáze přidáte server, pak tento server pracuje ve skupině s ostatními servery a zajišťuje automatické obnovení na úrovni databáze při selhání databáze, sítě nebo serveru. Aby mohl být server přidán do skupiny dostupnosti databáze, musí běžet na Windows Serveru 2008 SP2 Enterprise nebo na pozdější verzi nebo na Windows Serveru 2008 R2 nebo pozdější verzi. Dále musí mít nejméně dvě síťové karty. Každá síťová karta musí být na jiné podsíti. Poznámka: Každý server, který chcete přidat do skupiny dostupnosti databáze, musí mít dvě síťové karty. První síťová karta, nazývaná replikační karta, řídí provoz replikace, a druhá síťová karta, nazývaná karta pro přenos zpráv, řídí síťový provoz MAPI a jiný provoz vycházející ven ze sítě. Když plánujete členství ve skupině dostupnosti databáze, mějte na paměti následující: Jestliže jste pomocí Exchange Management Console vytvořili skupinu dostupnosti databáze a chcete do skupiny pomocí Exchange Management Console přidat servery, pak nejméně jednu ze síťových karet serveru musíte nakonfigurovat pro použití Dynamic Host Confi guration Protocol (DHCP). Když do skupiny dostupnosti databáze přidáte první Mailbox server, musí být skupině přiřazena IP adresa. Ve výchozím nastavení získá Exchange IP adresu skupiny od DHCP. Tato IP adresa bude IP adresou skupiny. Skupiny můžete vytvářet také pomocí Exchange Management Shellu. IP adresu můžete nastavit pomocí příkazu New-DatabaseAvailabilityGroup s parametrem DatabaseAvailabilityGroupIp. Jestliže již nechcete, aby byl server členem skupiny, můžete jej ze skupiny odebrat. Potom tento server již nebude automaticky chráněn před selháním. Mějte na paměti, že když chcete server odstranit ze skupiny dostupnosti databáze, musíte ze serveru nejdříve odstranit všechny replikované kopie databáze. Jestliže jste vytvoření skupiny a nastavení IP adresy neprovedli pomocí Exchange Management Shellu a DHCP ve vaší organizaci není dostupné nebo jestliže pro skupinu dostupnosti databáze chcete použít statickou IP adresu, proveďte následující postup: Pomocí příkazu Set-DatabaseAvailabilityGroup s parametrem DatabaseAvailablityGroupIpAddresses určete statiskou IP adresu ještě před přidáním serverů poštovních schránek do skupiny dostupnosti databáze. IP adresu musíte určit dříve, než do skupiny dostupnosti databáze přidáte první Mailbox server. Chcete-li přidat do skupiny nebo odebrat ze skupiny dostupnosti databáze Mailbox server, proveďte následující postup:

17 Vytváření a správa skupin dostupnosti databáze V Exchange Management Console rozbalte položku Organization Configuration. Potom vyberte položku Mailbox. V panelu výsledků vyberte kartu Database Availability Group. Zobrazí se existující skupiny dostupnosti databáze, jak vidíte na obrázku 9.3. Obrázek 9.3: Pohled na konfi gurované skupiny dostupnosti databáze 2. Klepněte pravým tlačítkem na skupinu dostupnosti databáze, se kterou chcete pracovat, a potom vyberte volbu Manage Database Availability Group Membership. Na stránce Manage Database Availability Group Membership, kterou vidíte na obrázku 9.4, můžete následující: Přidat server do skupiny dostupnosti databáze klepnutím na tlačítko Add. V dialogu SelectMailbox Server vyberte jeden nebo více serverů a potom klepněte na tlačítko OK. Odebrat server ze skupiny dostupnosti databáze. Vyberte server ze seznamu aktuálních členů a potom klepnutím na červené X server odstraňte ze skupiny dostupnosti databáze. 3. Klepnutím na tlačítko Manage změny potvrďte. Na stránce Completion uvidíte shrnutí úspěšné operace. Pokud nastala chyba, musíte ji opravit. Jinak klepněte na tlačítko Finish.

18 328 Kapitola 9 Správa dat a skupin dostupnosti databáze Obrázek 9.4: Přidání nebo odstranění členů skupiny V Exchange Management Shellu můžete pomocí příkazu Get-DatabaseAvailability- Group vypsat skupiny dostupnosti databáze. Pokud napíšete Get-DatabaseAvailabilityGroup bez dalších parametrů, uvidíte seznam všech skupin dostupnosti databáze v aktuální doménové struktuře Active Directory a také členské a funkční servery této skupiny. V následujícím příkladu vidíte ukázku výstupu: Get DatabaseAvailabilityGroup Name Member Servers Operational Servers EastCampusDAG1 MailServer25, CorpServer27 MailServer25, CorpServer27 WestCampusDAG1 MailServer44, MailServer18 MailServer44, MailServer18 Parametr Identity slouží k určení názvu skupiny dostupnosti databáze pro dotaz. Pokud do dotazu přidáte parametr Status, získáte informaci o stavu v reálném čase. Členy skupiny můžete přidávat nebo odstraňovat pomocí příkazů Add-DatabaseAvailabilityGroupServer a Remove-DatabaseAvailabilityGroupServer. Příklady 9.2 a 9.3 ukazují syntaxi a použití.

19 Vytváření a správa skupin dostupnosti databáze 329 Příklad 9.2: Syntaxe a použití příkazu Add-DatabaseAvailabilityGroupServer Syntaxe Add DatabaseAvailabilityGroupServer Identity NazevDAG MailboxServer PřidávanýServer [ DomainController PlněKvalifikovanýNázev] Použití Add DatabaseAvailabilityGroupServer Identity EastCampusDAG1 MailboxServer MailServer62 Příklad 9.3: Syntaxe a použití rutiny Remove-DatabaseAvailabilityGroupServer Syntaxe Remove DatabaseAvailabilityGroupServer Identity NazevDAG MailboxServer PřidávanýServer [ ConfigurationOnly <$true $false>] [ DomainController PlněKvalifikovanýNázev] Použití Remove DatabaseAvailabilityGroupServer Identity EastCampusDAG1 MailboxServer MailServer62 Jestliže Mailbox server selže a nemůže být opraven, můžete provést obnovení operací dvěma způsoby: Pomocí rutiny Remove-DatabaseAvailabilityGroupServer můžete odstranit konfigurační nastavení serveru poštovních schránek ze skupiny dostupnosti databáze. Odstraněním těchto nastavení jste odstranili všechna nastavení asociovaná se serverem poštovních schránek. Můžete nainstalovat Exchange na server, který má stejné jméno a členství v doméně jako starý server, a použít instalační program Exchange Server 2010 Setup s parametrem /m:recoverserver. Spuštění Setupu s parametrem /m:recoverserver způsobí, že Setup načte informace o konfiguraci starého serveru z Active Directory. Jakmile Setup získá informace o konfiguraci z Active Directory, nainstaluje na server originální soubory Exchange a služby a tím obnoví roli a nastavení, která byla uložena v Active Directory. Správa sítí skupin dostupnosti databáze Každá skupina dostupnosti databáze musí mít nejméně dvě sítě. Jednu pro replikaci, nazývanou replikační síť skupiny, a druhou, určenou pro přenosy MAPI a jiné přenosy, nazývanou také síť skupiny pro přenos zpráv. Pokud máte jen jednu síť pro přenos zpráv, můžete ve skupině dostupnosti databáze vytvořit další, replikační sítě a nakonfigurovat je pomocí nástrojů Exchange Management.

20 330 Kapitola 9 Správa dat a skupin dostupnosti databáze Přidávání nebo odebírání sítí skupiny dostupnosti databáze Každá síť skupin dostupnosti databáze musí mít jedinečný název o délce až 128 znaků, jednu nebo více asociovaných podsítí a nepovinný popis o délce až 256 znaků. Když konfigurujete síť, můžete ji vyčlenit pro replikaci nebo provoz MAPI. Poznámka: Vypnutí replikace nezaručuje, že Exchange nebude používat síť pro replikaci. Jestliže síť replikace selhala, je offline nebo je z jiného důvodu nedostupná a zbývají pouze sítě pro přenosy MAPI, Exchange tyto sítě bude používat pro replikaci do té doby, než bude síť pro replikaci dostupná. Z praxe: Každá síťová adresa má síťový identifikátor, který určuje síť, a identifikátor hostitele, který určuje individuálního hostitele v síti. Síťový ID je vidět jako předpona adresy IPv4 nebo IPv6, zatímco ID hostitele tvoří příponu. Když definujete síť skupiny dostupnosti databáze, musíte určit síť a potom zadat počet bitů v čísle sítě, které jsou součástí síťového ID. (Zbývající bity se považují za součást ID hostitele.) Chcete-li zapsat blok IP adres verze IPv4 a určit, které bity se používají pro ID sítě, napište číslo sítě a lomítko a potom počet bitů v ID sítě, například takto: NetworkNumber/# of bits in the network ID Lomítko a počet bitů v síťovém ID se nazývají předpona sítě. Ve výchozím nastavení má třída sítí A ve verzi IPv4 v ID sítě 8 bitů, třída sítí B ve verzi IPv4 má v ID sítě 16 bitů a třída sítí C ve verzi IPv4 má v ID sítě 24 bitů. Verze IPv6 k identifikaci bitů, jež jsou částí síťového ID, nepoužívá masku podsítě. Místo toho má každá IP adresa verze IPv6 přiřazenou délku přípony podsítě, která určuje, jak se mají bity v ID sítě používat. Délka přípony podsítě se udává v desítkové soustavě. Jestliže ID sítě obsahuje 48 bitů, pak se délka přípony podsítě píše jako FEC0:1234:5678::/48 a reprezentuje adresy IPv6 od FEC0:1234:5678:: do FEC0:1234:5678::FFFF:FFFF:FFFF:FFFF. Síť pro skupinu dostupnosti databáze můžete vytvořit následujícím postupem: 1. V Exchange Management Console rozbalte položku Organization Configuration a potom vyberte položku Mailbox. Na kartě Database Availability Group oba panely ukazují sítě aktuálně asociované s vybranou skupinou dostupnosti databáze. 2. Klepněte pravým tlačítkem na skupinu dostupnosti databáze, se kterou chcete pracovat, a potom vyberte New Database Availability Group Network. 3. Na stránce New Database Availability Group Network, kterou vidíte na obrázku 9.5, napište jedinečný název sítě skupiny dostupnosti databáze s maximální délkou 128 znaků a potom můžete zadat nepovinný popis pro síť skupiny dostupnosti databáze o délce až 256 znaků.