Exchange Pytania i Odpowiedzi: Odporność lokacji wykorzystujących replikację SCR, zalecana wielkość woluminu głównego i inne problemy

Autor: Henrik Walther

Opublikowano: 3 sierpnia 2008 | Zaktualizowano: 3 sierpnia 2008

Zawartość strony

	Wdrażanie serwerów skrzynek pocztowych opartych o replikację CCR w środowisku z wieloma podsieciami
	Maksymalna wielkość opóźnienia dla klientów z programem Outlook 2003/2007, pracujących w trybie buforowanym
	Magazyn folderów publicznych w środowisku z dwoma lokalizacjami
	Minimalna pojemność dysku zakotwiczającego na którym tworzone będą punkty montowania
	Replikacja typu SCR pomiędzy źródłem składającym się z serwerów skrzynek pocztowych opartych na replikacji CCR a miejscem docelowym złożonym z pojedynczego, autonomicznego serwera skrzynek pocztowych

Wdrażanie serwerów skrzynek pocztowych opartych o replikację CCR w środowisku z wieloma podsieciami

Aktualnie jestem w trakcie tworzenia infrastruktury komunikacyjnej opartej na oprogramowaniu Exchange Server 2007. Infrastruktura ta przeznaczona jest dla dużego przedsiębiorstwa, które wymaga, by przedstawione rozwiązanie oferowało odporność poszczególnych lokacji na awarie. Z tego powodu rozważam wdrożenie serwerów skrzynek pocztowych opartych na ciągłej replikacji klastra (CCR - Cluster Continuous Replication) i zainstalowanych na awaryjnym klastrze systemu Windows Server 2008, z aktywnym węzłem w podstawowym (aktywnym) centrum danych oraz z węzłem pasywnym, znajdującym się w drugim (zapasowym) centrum danych.

Obydwa centra danych należą do różnych podsieci oraz do tej samej lokacji w kartotece usługi Active Directory (która jest tzw. lokacją rozciągniętą), co oznacza, że jest to jeden z obsługiwanych scenariuszy instalowania w systemie Windows Server 2008 serwerów skrzynek pocztowych opartych na replikacji CCR. Czy zalecałby Pan wdrażanie serwerów skrzynek pocztowych opartych na replikacji CCR w środowisku z wieloma podsieciami?

Odp.
Ma Pan rację, że ten scenariusz jest obsługiwany, jeśli obydwa centra danych będą należeć do tej samej lokacji usługi Active Directory, ponieważ system Exchange 2007 nie obsługuje możliwości wdrażania aktywnych i pasywnych węzłów replikacji CCR w różnych lokacjach usługi Active Directory. Mimo to należy pamiętać, że replikacja typu CCR została zaprojektowana z myślą o zapewnianiu wysokiej dostępności w obrębie centrum danych, a nie dla zapewnienia odporności całej lokacji na awarie (co ma więcej wspólnego ze scenariuszem odtwarzania po całkowitej awarii, niż z wysoką dostępnością).

Z tego konkretnego powodu począwszy od wersji Exchange 2007 SP1 do grupy produktów z rodziny Exchange został wprowadzony mechanizm ciągłej replikacji zapasowej (SCR - Standby Continuous Replication). Replikacja typu SCR wykorzystuje te same technologie ekspediowania dzienników i ponownego wykonywania zapisanych w nich operacji, co replikacja typu CCR, ale działanie replikacji typu SCR nie jest uzależnione od funkcjonalności oferowanej przez klaster awaryjny systemu Windows, a działanie replikacji typu CCR jest. Oznacza to, że replikację typu SCR można włączyć zarówno dla docelowych serwerów skrzynek pocztowych, które są częścią pewnego klastra, jak i dla tych, które nie należą do żadnego klastra. Miejscem docelowym tego typu replikacji może być niesklastrowany serwer skrzynek pocztowych lub zapasowy klaster, na którym została zainstalowana rola serwera skrzynek pocztowych.

Zostało to pokazane na rysunku 1, który został zaczerpnięty z dokumentacji systemu Exchange 2007, z części poświęconej replikacji SCR.

Osobiście nie zalecam tworzenia geograficznie rozproszonego klastra opartego na replikacji typu CCR, choć jak już wcześniej wspomniano, możliwość taka jest w pełni obsługiwana przez firmę Microsoft. Należy jednak mieć świadomość wad tego podejścia.

Rysunek 1: Model z ciągłą replikacją zapasową.

Po pierwsze wymaga to zastosowania tzw. rozciągniętej lokacji usługi Active Directory. Wygląda na to, że w Pańskim przypadku ta opcja została już wybrana, ale warto o niej wspomnieć dla pozostałych Czytelników, którzy mogą tego nie wiedzieć. Należy również mieć świadomość faktu, że ponieważ węzły replikacji CCR znajdują się w różnych podsieciach, więc po wykonaniu awaryjnego przełączenia do drugiej lokacji adres IP sklastrowanego serwera skrzynek pocztowych (CMS - clustered Mailbox server) ulegnie zmianie. Zmiana ta będzie musiała zostać odzwierciedlona na wszystkich serwerach DNS używanych przez klientów Microsoft Outlook, a także, co jest równie ważne, wszystkie komputery klienckie łączące się z serwerami CMS będą musiały opróżnić swoją pamięć podręczną klienta DNS.

Na czas trwania operacji przełączania awaryjnego klienci programu Outlook zostaną odłączeni od swoich skrzynek pocztowych, znajdujących się na serwerach CMS. Z tego względu należy zmienić wartość TTL (Time-to-live) dla rekordów DNS z nazwami sieciowymi serwerów CMS na 5 minut (300 sekund) lub mniej. Więcej informacji na temat sposobu przeprowadzenia tej zmiany znaleźć można pod adresem technet.microsoft.com/library/bb676687.aspx.

Należy także zastanowić się, gdzie umieścić serwer FSW (File Share Witness - Świadek udziału sieciowego). Zaleca się, aby serwer FSW instalować na serwerze roli Hub Transport, ale w której lokacji? Jeśli zainstalujemy go na serwerze roli Hub Transport z podstawowego centrum danych, to czy w przypadku utraty podstawowego centrum danych zostanie on automatycznie przeniesiony do centrum zapasowego? Nie, to jest niemożliwe, jeśli jednocześnie niedostępny jest jeden z węzłów replikacji CCR oraz serwer FSW. Z drugiej strony, w przypadku rozproszonej geograficznie replikacji CCR, preferowane może być rozwiązanie, w którym proces przełączania awaryjnego nie będzie wykonywany automatycznie. Dlatego należy koniecznie zapoznać się ze wskazówkami dotyczącymi rozmieszczania serwerów FSW w scenariuszu z rozproszoną geograficznie replikacją typu CCR.

Na koniec należy również pamiętać, że po awaryjnym przełączeniu się na pasywny węzeł z zapasowego centrum danych wszelkie zapisy wykonane w magazynie Transport Dumpster (Kosz transportu) na serwerach roli Hub Transport z podstawowego centrum danych nie zostaną odtworzone, ponieważ serwery te najprawdopodobniej będą niedostępne. W konsekwencji prowadzi to do utraty części wiadomości e-mail.

Jak zatem widać, istnieje wiele problemów, które należy wziąć pod uwagę decydując się na wdrożenie w posiadanym środowisku rozproszonej geograficznie replikacji typu CCR, o wiele więcej niż w przypadku wykorzystania replikacji typu SCR.

Maksymalna wielkość opóźnienia dla klientów z programem Outlook 2003/2007, pracujących w trybie buforowanym

Nasza organizacja składa się z wielu fizycznych lokacji, rozproszonych po całych Stanach Zjednoczonych, a także w Europie, na Bliskim Wschodzie i w Afryce. Obecnie skrzynki pocztowe wszystkich użytkowników znajdują się na serwerach ról Mailbox, wdrożonych lokalnie w każdej fizycznej lokalizacji, ale zamierzamy skonsolidować te serwery w jednym centrum danych, położonym w USA. Czy biorąc pod uwagę opisany plan może Pan określić maksymalną wielkość opóźnienia dla klientów z programem Outlook 2003/2007, pracujących w trybie buforowanym?

Odp.
To dobrze, że wszyscy klienci w Pańskiej firmie korzystają z programu Outlook 2003 lub 2007 i że programy te pracują w trybie bufowanym, ponieważ w opisanym przez Pana przykładzie konsolidacji tryb buforowany jest zwykle prawdziwym wybawieniem.

W przeszłości firma Microsoft zalecała, by całkowita wielkość opóźnienia pomiędzy serwerem skrzynek pocztowych a działającymi w trybie buforowanym klientami z programem Outlook 2003 wynosiła 1000 ms lub mniej. Dla klientów z programem Outlook 2003, niekorzystających z trybu buforowanego, zalecana wielkość opóźnienia wynosiła 200 ms lub mniej.

Na podstawie moich własnych doświadczeń muszę jednak przyznać, że 1000 ms to trochę zbyt duża wielkość opóźnienia, nawet dla klientów z programem Outlook 2007, pracujących w trybie buforowanym. Gdy wielkość opóźnienia zaczyna przekraczać 500 ms, program Outlook zaczyna się wieszać i generalnie staje się nieco ospały. Zalecałbym, aby opóźnienie pomiędzy klientem programu Outlook a macierzystym serwerem skrzynek pocztowych nie przekraczało 500 ms. Na rysunku 2 pokazane zostały średnie czasy odpowiedzi uzyskiwane dla mojego klienta Outlook 2007, połączonego ze skrzynką pocztową w Redmond.

Podam teraz wskazówkę: aby otworzyć pokazane na rysunku 2 okno Connection Status (Stan połączenia), należy kliknąć prawym klawiszem myszy ikonę programu Outlook wyświetlaną w zasobniku systemu, trzymając jednocześnie wciśnięty klawisz CTRL. Alternatywną możliwością uzyskania tego okna dialogowego jest uruchomienie programu Outlook poprzez wybranie z menu Start polecenia Uruchom i wpisanie polecenia Outlook.exe /RPCDIAG.

Rysunek 2: Średnie czasy odpowiedzi w programie 2007.

Biorąc pod uwagę fakt, że ja znajduję się w Danii, pokazane na tym rysunku średnie czasy odpowiedzi są akceptowalne. Z rysunku tego widać również, że w przypadku serwera katalogu globalnego uzyskiwane średnie czasy odpowiedzi są znacznie większe, ale ponieważ serwery te są używane znacznie rzadziej (podczas operacji wyszukiwania w książce adresowej itp.), nie ma to tak dużego znaczenia.

Magazyn folderów publicznych w środowisku z dwoma lokalizacjami

W naszej organizacji właśnie wdrożyliśmy oprogramowanie Exchange 2007 SP1. Nasza topologia kartoteki usługi Active Directory składa się z dwóch lokacji. W pierwszej z nich został wdrożony serwer skrzynek pocztowych oparty na replikacji CCR oraz dwa serwery, na których zainstalowane zostały role Hub Transport i Client Access. W drugiej lokacji wdrożony został serwer skrzynek pocztowych oparty na klastrze SCC (Single Copy Cluster) oraz dwa serwery z zainstalowanymi rolami Hub Transport i Client Access, tak jak w pierwszej lokacji usługi Active Directory.

W każdej z tych dwóch lokacji usługi Active Directory większość klientów nadal używa programu Outlook 2003, co oznacza, że magazyn folderów publicznych jest potrzebny do przechowywania informacji typu wolny/zajęty oraz książki adresowej trybu offline (foldery publiczne będą używane wyłącznie do tego celu, a nie jako repozytorium danych). Początkowo chcieliśmy zamontować magazyn folderów publicznych zarówno na serwerach skrzynek pocztowych opartych na replikacji CCR, jak i na serwerach opartych na klastrze SCC, co pozwoliłoby na replikowanie pomiędzy lokacjami usługi Active Directory zmian wykonywanych w folderach publicznych. Jednak wówczas dowiedzieliśmy się, że firma Microsoft nie zaleca posiadania w jednej organizacji Exchange więcej niż jednego magazynu folderów publicznych, jeśli jeden z nich miałby znajdować się na serwerze skrzynek pocztowych opartych na replikacji CCR, ponieważ replikacja folderów publicznych i replikacja CCR nie współpracują dobrze ze sobą.

Tak więc mając na uwadze wszystkie podane tu informacje, co radziłby Pan nam zrobić? Nie chcemy podążać ścieżką, która nie jest zalecana przez firmę Microsoft. Jednak nie chcemy również, aby klienci z programem Outlook 2003, znajdujący się w jednej lokacji Active Directory, kontaktowali się z magazynem folderów publicznych znajdującym się w drugiej lokacji.

Odp.
To bardzo dobre pytanie. Ma Pan rację, że w przypadku magazynu folderów publicznych należy unikać łączenia funkcji replikacji folderów publicznych oraz replikacji typu CCR (szczegółowe wyjaśnienie, dlaczego należy unikać takiej konfiguracji, można znaleźć w moim artykule ze stycznia 2009, zamieszczonym w dziale Exchange Queue & A). Ponieważ w Pańskim przypadku funkcjonalność folderów publicznych będzie wykorzystywana do tego, by umożliwić starszym klientom programu Outlook do wyszukiwania informacji typu wolny/zajęty oraz do pobierania książki adresowej trybu offline (OAB - Offline Address Book), zalecałbym zainstalowanie roli serwera skrzynek pocztowych na jednym z serwerów łączących role Hub Transport i Client Access w tej samej lokacji usługi Active Directory, w której znajduje się serwer skrzynek pocztowych oparty na replikacji CCR. Następnie należy przenieść na ten serwer magazyn skrzynek pocztowych z serwera roli Mailbox opartego na replikacji CCR.

Należy jednak pamiętać, że poprawne działanie replikacji folderów publicznych wymaga zainstalowania na tym serwerze także bazy danych skrzynek pocztowych. Wykorzystywanie serwerów pełniących jednocześnie rolę Hub Transport i Client Access, do wyszukiwania informacji typu wolny/zajęty oraz do pobierania książki adresowej trybu offline, nie będzie stwarzać zbyt wielkiego obciążenia dla tego serwera i większość architektów rozwiązań Exchange tak właśnie postępuje w podobnych sytuacjach.

Minimalna pojemność dysku zakotwiczającego na którym tworzone będą punkty montowania

Nasza firma aktualnie planuje rozkład magazynów danych dla serwerów skrzynek pocztowych, które będą częścią nowego środowiska Exchange 2007, do którego planujemy przejść w ciągu najbliższych 6 miesięcy. Ponieważ nasze przedsiębiorstwo składa się z kilku tysięcy użytkowników, planujemy utworzenie na każdym serwerze roli Mailbox, 48 grup magazynowania, z których wszystkie oparte będą na technologii replikacji CCR.

Ze względu na planową liczbę grup magazynowania będziemy oczywiście korzystać z punktów montowania. Ponieważ na każdym z serwerów skrzynek pocztowych opartych na replikacji CCR zamierzamy tworzyć punkty montowania dla każdego urządzenia LUN, chcielibyśmy dowiedzieć się, jaka jest zalecana minimalna pojemność dysku zakotwiczającego, na którym tworzone będą te punkty montowania.

Odp.
Sposób konfigurowania punktów montowania na klastrze serwerów z systemem Windows Server 2008 został opisany w artykule z bazy wiedzy firmy Microsoft, zatytułowanym „How to Configure Volume Mount Points on a Server Cluster in Windows Server 2008” (Jak skonfigurować punkty montowania na klastrze serwerów w systemie Windows Server 2008). Według informacji podanych w tym artykule, jeśli wolumin główny (host), nazywany również zakotwiczającym urządzeniem LUN, będzie intensywnie używany do tworzenia punktów montowania, to jego pojemność powinna wynosić przynajmniej 5 MB. Jednak w przypadku oprogramowania Exchange zalecenia dotyczące woluminów głównych są inne.

W wersji Exchange 2007, a także w poprzednich wersjach oprogramowania Exchange Server, zaleca się, aby pojemność woluminu głównego mieściła się w przedziale pomiędzy 100 MB a 500 MB. W przypadku oprogramowania Exchange 2007, zainstalowanego na komputerze z systemem Windows Server 2003, posiadanie na woluminie głównym mniej niż 20 MB wolnego miejsca może być przyczyną problemów podczas tworzenia nowej bazy danych. Więcej informacji na temat tego konkretnego problemu znaleźć można w artykule " Event 104 is logged after you create a new database in Exchange Server 2007 ” (Po utworzeniu nowej bazy danych w systemie Exchange 2007 rejestrowane jest zdarzenie numer 104).

Replikacja typu SCR pomiędzy źródłem składającym się z serwerów skrzynek pocztowych opartych na replikacji CCR a miejscem docelowym złożonym z pojedynczego, autonomicznego serwera skrzynek pocztowych

Nasza infrastruktura poczty elektronicznej opiera się na oprogramowaniu Exchange 2007 SP1. Wszystkie serwery Exchange 2007 zlokalizowane są w tym samym centrum danych i oparte są technologii klastrowania z replikacją typu CCR, co zapewnia nam lokalną nadmiarowość. Ostatnio przygotowaliśmy jednak drugie centrum danych, które ma służyć jako centrum zapasowe na wypadek awarii centrum podstawowego.

W przypadku serwerów Exchange chcemy osiągnąć odporność lokacji na awarie, wdrażając w zapasowym centrum danych po jednym serwerze roli Hub Transport, Client Access oraz Mailbox. Następnie chcemy skonfigurować replikację typu SCR przenoszącą dane z naszych serwerów skrzynek pocztowych opartych na replikacji CCR i znajdujących się w podstawowym centrum danych na serwer skrzynek pocztowych z zapasowego centrum danych. Zanim jednak przystąpimy do instalowania serwerów Exchange 2007 w zapasowym centrum danych, mamy jedno pytanie, na które, mam nadzieję, będzie mógł Pan odpowiedzieć. Chcielibyśmy wiedzieć, czy obsługiwana jest możliwość włączenia replikacji typu SCR pomiędzy źródłem składającym się z serwerów skrzynek pocztowych opartych na replikacji CCR a miejscem docelowym złożonym z pojedynczego, autonomicznego serwera skrzynek pocztowych. A jeśli tak, to czy Pańskim zdaniem powinniśmy zastosować to rozwiązanie?

Odp.
Krótka odpowiedź brzmi, tak, taki scenariusz jest w pełni obsługiwany. Dłuższa odpowiedź również brzmi, tak, ale powinni Państwo pamiętać, że opcja /RecoverCMS nie umożliwia odtworzenia serwera CMS położonego na źródłowym (lub źródłowych) serwerze replikacji SCR. Serwery CMS można odtworzyć za pomocą opcji /RecoverCMS tylko wtedy, gdy miejscem docelowym replikacji SCR jest klaster awaryjny złożony z serwerów pracujących z systemem Windows Server 2003/2008, na których zainstalowano jedynie rolę pasywnego serwera skrzynek pocztowych.

Jeśli miejscem docelowym replikacji SCR będzie autonomiczny serwer skrzynek pocztowych, operację odtwarzania bazy danych trzeba będzie wykonać przy użyciu funkcji przenośności bazy danych, a procedura ta jest znacznie bardziej kłopotliwa niż metoda oparta na opcji RecoverCMS. Opis koniecznych do wykonania kroków można znaleźć w dokumentacji oprogramowania Exchange 2007, w części zatytułowanej „ Standby Continuous Replication: Database Portability ” (Ciągła replikacja zapasowa: Przenośność bazy danych). Jeśli na serwerze będącym docelowym miejscem replikacji SCR zainstalowany jest system Windows Server 2003/2007 w edycji Enterprise, to możliwe jest również usunięcie z niego roli serwera skrzynek pocztowych, uformowanie klastra awaryjnego i zainstalowanie na węzłach tego klastra pasywnej roli serwera skrzynek pocztowych, a następnie przeprowadzenie odtwarzania serwera CMS za mocą opcji RecoverCMS. Jeśli obecnie dostępny jest tylko jeden fizyczny serwer (a także dodatkowa licencja dla systemu Windows Server 2003/2008 w edycji Enterprise oraz dla oprogramowania Exchange Server 2007, również w edycji Enterprise), ale w niedalekiej przyszłości liczba dostępnych serwerów może się zwiększyć, można zacząć od utworzenia awaryjnego klastra systemu Windows Server 2003/2008 złożonego tylko z jednego węzła, a następnie zainstalować na tym węźle pasywny serwer skrzynek pocztowych. Po zakupieniu dodatkowych serwerów można będzie zainstalować na nich system Windows Server 2003/2008, skonfigurować odpowiednio ich ustawienia sieciowe i inne, a na koniec dodać je do istniejącego klastra awaryjnego z systemem Windows.

Więcej informacji

Henrik Walther jest posiadaczem certyfikatu Microsoft Certified Master w dziedzinie Exchange 2007 oraz certyfikatu Exchange MVP i ma ponad 15-letnie doświadczenie w pracy w branży informatycznej. Pracuje jako architekt technologii (Technology Architect) dla firmy Trifork Infrastructure Consulting (złoty partner firmy Microsoft z Danii) oraz jako autor tekstów technicznych dla firmy Biblioso Corporation (amerykańskiej firmy specjalizującej się w zarządzaniu dokumentacją oraz w usługach lokalizowania oprogramowania).