Exchange Pytania i odpowiedzi: Drugie spojrzenie na funkcje i ulepszenia wersji Exchange 2010

Autor: Henrik Walther

Opublikowano: 23 września 2008 | Zaktualizowano: 23 września 2008

Zawartość strony

	Działanie klastra Exchange 2007 SP1 z wieloma lokacjami a wiele bram domyślnych
	Szczegóły na temat nowej funkcji Database Availability Group (DAG)
	Więcej na temat optymalizacji mechanizmu magazynowania w wersji Exchange 2010
	Zalecenia odnośnie funkcji File and Printer Sharing for Microsoft Networks
	Zalecenia dotyczące powstrzymywania przepływu wiadomości do i z serwera Mailbox
	Archive Mailbox w Outlook 2003 lub 2007 oraz przenoszenie skrzynki Archive

Pyt. Działanie klastra Exchange 2007 SP1 z wieloma lokacjami a wiele bram domyślnych

Wdrażamy klaster Exchange 2007 SP1 z wieloma lokacjami z wykorzystaniem funkcji Cluster Continuous Replication (CCR). Dwa węzły klastra zostaną umieszczone w osobnych centrach danych. Exchange jest uruchomiony w systemie Windows Server 2008 SP2 i planujemy umieścić interfejsy publiczne i prywatne w osobnych podsieciach w każdym z centrów danych. Oczywiście oznacza to, że musimy zastosować routing między węzłami klastra.

Konfiguracja interfejsu publicznego zgodnie z instrukcjami przedstawionymi w artykule CCR Microsoft TechNet przebiegła pomyślnie. Natomiast gdy konfigurujemy domyślną bramę dla prywatnego interfejsu, otrzymujemy komunikat ostrzeżenia, jak pokazany na Rysunku 1.

Rysunek 1: Określanie wielu domyślnych bram w systemie Windows 2008 Server.

W związku z powyższym komunikatem ostrzeżenia obawiamy się, że system nie będzie działał prawidłowo, jeśli dla każdego węzła w klastrze CCR z wieloma lokacjami określimy wiele domyślnych bram. A zatem pojawia się pytanie, w jaki sposób należy skonfigurować interfejs sieci prywatnej w tego typu scenariuszu?

Odp.
Cieszę się, że zadaliście to pytanie, zamiast kontynuować wdrażanie wspomnianej infrastruktury, ponieważ zdefiniowanie wielu domyślnych bram w klastrze CCR z wieloma lokacjami prowadziłoby do poważnych komplikacji. Prawidłowa konfiguracja wymaga stałych, statycznych tras dla każdego interfejsu prywatnego.

Na początku należy upewnić się, że interfejs publiczny zajmuje pierwszą pozycję na liście połączeń w sekcji Advanced Settings w panelu Network Connections. Następnie należy upewnić się, że określona została domyślna brama w interfejsie sieci publicznej dla każdego węzła klastra.

Na zakończenie należy skonfigurować trasy dla interfejsów prywatnych, aby cały ruch, który nie odpowiada stworzonej trasie, był kierowany do domyślnej bramy interfejsu publicznego. Załóżmy, że interfejsem prywatnym węzła 1 jest podsieć 192.168.100.x/24 z bramą sieciową o adresie IP 192.168.100.1. Interfejs prywatny węzła 2 znajduje się w podsieci 192.168.200.x/24 z bramą sieciową o adresie IP 192.168.200.1. W tym przypadku trzeba byłoby stworzyć następującą trasę dla węzła 1: ROUTE ADD 192.168.200.0 MASK 255.255.255.0 192.168.100.1 –P, oraz następującą trasę dla węzła 2: ROUTE ADD 192.168.100.0 MASK 255.255.255.0 192.168.200.1 –P.

Parametr –P oznacza, że tworzone trasy są stałe i nie zostaną usunięte w wyniku ponownego uruchomienia systemu.

Taka konfiguracja zapewnia poprawne działanie sieci dla wszystkich interfejsów w węzłach klastra. Jeszcze dokładniejsze informacje dotyczące konfiguracji interfejsu prywatnego, gdy wykorzystywany jest mechanizm routingu między sieciami, znaleźć można w poście opublikowanym na blogu mojego kolegi Tima McMichael.

Dodatkowo zalecam skonfigurowanie sieci prywatnej jako sieci mieszanej, aby można było włączyć mechanizm replikacji w redundantnej sieci przy użyciu polecenia cmdlet Enable-ContinuousReplicationHostName. Dodatkowe informacje na temat tego polecenia cmdlet znaleźć można w artykule How to Enable Redundant Cluster Networks for Log Shipping and Seeding on Windows Server 2003.

Pyt. Szczegóły na temat nowej funkcji Database Availability Group (DAG)

Mam pytanie dotyczące nowej funkcji Database Availability Group (DAG) dostępnej w wersji Exchange Server 2010, a dokładnie mechanizmu kopiowania i inicjalizowania (ang. seeding) pliku dziennika między aktywnymi oraz pasywnymi bazami danych. Czy Exchange Server 2010 oferuje jakieś zmiany lub ulepszenia w tym zakresie podczas działania funkcji Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) oraz Standby Continuous Replication (SCR) w porównaniu z wersją Exchange Server 2007?

Odp.
To dobre pytanie. Chociaż technologia replikacji asynchronicznej wykorzystywana w wersji Exchange 2007 działa należycie, nie znaczy to wcale, że nie można jej poprawić, nieprawdaż? Mam przyjemność poinformować, że zespół Exchange Product Group dokonał kilku interesujących zmian i ulepszeń technologii replikacji w wersji Exchange 2010.

W wersji Exchange 2007 usługa Microsoft Exchange Replication Service kopiuje pliki dzienników do pasywnej kopii bazy danych (LCR), pasywnego węzła klastra (CCR) lub lokalizacji docelowej replikacji SCR za pośrednictwem protokołu Server Message Block (SMB), co oznacza, że musimy otworzyć port 445 na zaporach sieciowych między węzłami klastra CCR (zwykle w przypadku wdrażania klastrów CCR z wieloma lokacjami) oraz/lub lokalizacjami źródłowymi i docelowymi replikacji SCR. Osoby zatrudnione w dużych korporacjach wiedzą, jak trudno jest przekonać administratorów sieci do otwarcia portu 445/TCP między dwoma centrami danych. W funkcji DAG w wersji Exchange 2010 technologia replikacji asynchronicznej nie bazuje już na protokole SMB. Exchange 2010 wykorzystuje protokół TCP/IP do kopiowania i inicjalizowania pliku dziennika, a ponadto oferuje możliwość określenia, który port ma posłużyć do replikacji pliku dziennika. Domyślnie funkcja DAG korzysta z portu 64327, ale w razie potrzeby można określić inny port. Do tego celu służy następujące polecenie:

Set-DatabaseAvailabilityGroup -identity <DAG name> -ReplicationPort <port number>

Co więcej funkcja DAG w wersji Exchange 2010 wspiera szyfrowanie, natomiast pliki dzienników w wersji Exchange 2007 są kopiowane przy użyciu nieszyfrowanego kanału, o ile nie została skonfigurowana obsługa połączeń IPsec. A dokładniej, funkcja DAG wykorzystuje możliwości szyfrowania oferowane przez system Windows Server 2008, co oznacza, że funkcja DAG stosuje uwierzytelnianie Kerberos między poszczególnymi serwerami skrzynek pocztowych należącymi do grupy DAG. Szyfrowanie sieciowe stanowi właściwość samej grupy DAG, nie sieci DAG. Ustawienia właściwości szyfrowania sieciowego dla funkcji DAG są następujące: Disabled (szyfrowanie sieciowe nie jest wykorzystywane), Enabled (szyfrowanie sieciowe włączone na potrzeby inicjalizowania i replikacji we wszystkich sieciach w grupie DAG), InterSubnetOnly (domyślne ustawienie oznaczające, że szyfrowanie sieciowe jest stosowane w sieciach DAG w tej samej podsieci) oraz SeedOnly (szyfrowanie sieciowe wykorzystywane do inicjalizowania we wszystkich sieciach w grupie DAG). Do włączania szyfrowania sieciowego służy polecenie cmdlet Set-DatabaseAvailabilityGroup. Na przykład, aby włączyć szyfrowanie dla procesów kopiowania dziennika i inicjalizacji, można wykonać następujące polecenie:

Set-DatabaseAvailabilityGroup -identity <nazwa DAG> -NetworkEncryption Enabled.

Dodatkowo grupy DAG w wersji Exchange 2010 umożliwiają stosowanie kompresji podczas inicjalizowania oraz replikacji w jednej lub wielu sieciach w grupie DAG. Jest to właściwość samej grupy DAG, nie sieci DAG. Dostępne są takie same ustawienia, jakie odnoszą się do właściwości szyfrowania sieciowego, a domyślne ustawienie to InterSubnetOnly. Do włączenia kompresji sieciowej dla procesów kopiowania i inicjalizowania pliku dziennika dla wszystkich sieci w grupie DAG służy polecenie: Set-DatabaseAvailabilityGroup –Identity <nazwa grupy DAG> -NetworkCompression Enabled. Aby sprawdzić stan ustawień portu, szyfrowania oraz kompresji dla grupy DAG, można wykonać polecenie Get-DatabaseAvailabilityGroup –status, jak pokazano na Rysunku 2 .

Rysunek 2: Ustawienia szyfrowania sieci, kompresji oraz portu replikacji dla Database Availability Group.

Pyt. Więcej na temat optymalizacji mechanizmu magazynowania w wersji Exchange 2010

W poprzednim artykule z serii Exchange Pytania i odpowiedzi wspomniana została znacząca redukcja liczby operacji we/wy w wersji Exchange 2010 w porównaniu z wersjami Exchange 2003 oraz 2007. Czy mogę prosić o dokładniejsze objaśnienie zmian i ulepszeń wprowadzonych przez zespół Exchange Product Group, które pozwoliły osiągnąć taką optymalizację mechanizmu magazynowania w wersji Exchange 2010?

Odp.
Faktycznie zaobserwowaliśmy znaczną redukcję liczby operacji we/wy na sekundę w wyniku przejścia z wersji Exchange 2003 do Exchange 2007. W niektórych przypadkach poprawa efektywności wynosiła nawet do 70 procent. Zawdzięczamy to głównie zastosowaniu 64-bitowej architektury w wersji Exchange 2007. W związku z tym Exchange 2007 może uzyskiwać dostęp do większej ilości pamięci niż jego poprzednik i tym samym korzystać z większych buforów. Im więcej danych system Exchange może pobrać bezpośrednio z przestrzeni adresowej pamięci wirtualnej, tym mniej dyskowych operacji we/wy musi wykonać wewnętrzny system magazynowania.

To pozwala na dużo efektywniejsze wykorzystanie istniejącego systemu magazynowania (zwykle kosztownej sieci Storage Area Network) lub stanowi doskonały argument przemawiający za zastosowaniem tańszej bezpośrednio podłączanej pamięci. Zredukowane wymagania we/wy umożliwiają hosting dużo większej liczby skrzynek pocztowych (ponad 5000) na serwerze Mailbox Exchange 2007 niż było to możliwe w wersji Exchange 2003. Aby uniknąć fragmentacji pamięci wirtualnej, serwery Mailbox w wersji Exchange 2003 były zwykle ograniczane do 4000 skrzynek (choć oczywiście zależy to od typu serwera, profili użytkowników oraz infrastruktury Exchange).

Extensible Storage Engine (ESE) to technologia bazodanowa wykorzystywana w systemie Exchange począwszy od pierwszej wersji Exchange 4.0 opublikowanej w czerwcu 1996 roku. Aż do wersji Exchange 2007 SP1 zespół Exchange Product Group dostosowywał i optymalizował technologię ESE w celu poprawienia wydajności. Natomiast w wersji Exchange 2010 skoncentrował się na dostarczaniu dużych (ponad 10 GB), szybkich skrzynek pocztowych uzyskiwanych dzięki tanim rozwiązaniom magazynującym. Modyfikacje rozwiązania ESE wprowadzone w tej wersji pozwalają na zastosowanie dysków o niskiej wydajności, takich jak dyski SATA (nazywanych także dyskami przeznaczonymi dla Tier 2). Tak, mam na myśli takie same dyski 7200 SATA, jakie są stosowane na stacjach roboczych! W przypadku wykorzystywania funkcji Database Availability Group w celu zapewnienia wysokiej dostępności (trzech lub więcej kopii baz danych) można nawet użyć tego samego dysku 7200RPM do przechowywania zarówno bazy danych, jak i dzienników transakcji – zamiast stosować kosztowne konfiguracje RAID.

Aby możliwe było wprowadzenie takich ulepszeń, trzeba było znacznie zmodyfikować schemat magazynu. Zasadniczo zespół Exchange Product Group zrezygnował z wielu losowych, niewielkich operacji na rzecz mniejszej liczby sekwencyjnych, dużych operacji we/wy. Przejście z losowych do sekwencyjnych operacji we/wy wymagało dokonania istotnych zmian w architekturze tabel magazynu.

W wersji Exchange 2007 i wcześniejszych każda baza danych zawierała tabelę skrzynki pocztowej (przechowującą wszystkie skrzynki pocztowe w bazie danych), tabelę folderów (przechowującą foldery dla wszystkich skrzynek pocztowych w bazie danych), tabelę wiadomości (przechowującą wiadomości), tabelę załączników (przechowującą załączniki dla wszystkich skrzynek pocztowych w bazie danych) oraz tabelę wiadomość/folder (przechowującą widoki folderów dla wszystkich skrzynek pocztowych w bazie danych). W tej architekturze, która pozostała praktycznie niezmieniona od wersji Exchange 4.0, w bazie danych przeprowadzanych było wiele operacji we/wy. Jedną z głównych korzyści wynikających z zastosowania tej architektury był mechanizm Single-Instance Storage (SIS), który gwarantował przechowywanie tylko jednej kopii wiadomości. Kiedyś była to ogromna zaleta, ponieważ dyski miały zazwyczaj niewielkie rozmiary. Jednak obecnie, gdy dyski 500GB SAS oraz 2TB SATA są powszechnie dostępne, taka architektura przestaje mieć sens.

W wersji Exchange 2010 schemat magazynu został zmodyfikowany tak, aby wszystkie dane w skrzynce pocztowej były składowane w tabelach blisko siebie w bazie danych. W rzeczywistości każda skrzynka pocztowa ma swoją własną tabelę folderu, nagłówka wiadomości, treści oraz widoku. Ponieważ mechanizm SIS nie jest już stosowany w bazie danych Exchange, rozmiar bazy danych może wzrosnąć o około 20 procent. Aby rozwiązać ten problem, zespół Exchange Product Group skompresował bazy danych (a dokładniej nagłówki wiadomości oraz tekst lub treść HTML). Dzięki temu, że każda skrzynka pocztowa ma swój własny zestaw tabel, większość operacji we/wy realizowanych w bazie danych jest z natury sekwencyjna.

Do innych interesujących zmian zaliczają się: alokowanie miejsca dla bazy danych w sposób ciągły, ciągłość bazy danych utrzymywana w czasie, rozmiar stron baz danych zwiększony z 8 KB do 32KB, a także udoskonalona możliwość asynchronicznego odczytu. Zespół Exchange Product Group pracuje również nad zwiększeniem efektywności pamięci podręcznej poprzez zmianę tzw. głębokości punktów kontrolnych do 100 MB dla konfiguracji o wysokiej dostępności, przy użyciu kompresji pamięci podręcznej oraz priorytetów w buforze bazy danych.

Dzięki wprowadzeniu wspomnianych zmian w wersji Exchange 2010, możliwa jest nawet 70 procentowa redukcja liczby operacji we/wy w porównaniu z systemem Exchange 2007.

Omówione zostały jedynie podstawowe kwestie dotyczące optymalizacji mechanizmu magazynowania Exchange 2010. Osoby, które chcą zagłębić się w soczyste szczegóły, gorąco zachęcam do zaparzenia sobie kawy i obejrzenia nagrań z sesji Tech·Ed 2009 dotyczącej Exchange 2010 Storage zaprezentowanej przez Matta Gossage - członka zespołu Exchange Product Group odpowiedzialnego za bazę danych ESE. Matt przedstawił to zaawansowane i skomplikowane zagadnienie w dość przystępny sposób (w języku angielskim). Video jest dostępne online (nie tylko dla uczestników konferencji Tech·Ed).

Pyt. Zalecenia odnośnie funkcji File and Printer Sharing for Microsoft Networks

W naszej organizacji wdrożyliśmy kilka serwerów Mailbox Exchange 2007, stosując technologię Cluster Continuous Replication (CCR). We wszystkich węzłach sieci prywatnej wyłączona została funkcja File and Printer Sharing for Microsoft Networks (Udostępnianie plików i drukarek w sieciach Microsoft Network, patrz Rysunek 3). Jesteśmy przekonani, że w momencie wdrażania przez nas systemu Exchange 2007 było to rekomendowane podejście.

Rysunek 3: Wyłączona funkcja File and Printer Sharing for Microsoft Networks.

Jednak różni się ono od wskazówek zaprezentowanych w dokumentacji Exchange 2007 SP1. Obecnie zaleca się włączenie funkcji File and Printer Sharing for Microsoft Networks zarówno w interfejsie sieci publicznej, jak i w interfejsie sieci prywatnej. Dlaczego zalecenia zmieniły się po opublikowaniu wersji Exchange 2007 SP1?

Odp.
Macie rację. Przed opublikowaniem wersji Exchange Server 2007 SP1 zalecane było wyłączenie funkcji File and Printer Sharing for Microsoft Networks w interfejsie sieci prywatnej. Jednak w Exchange 2007 SP1 pojawiła się nowa funkcja, która umożliwia replikowanie plików dziennika z wykorzystaniem wielu interfejsów sieciowych, prowadząc do powstawiania sieci redundantnych oraz zredukowania ilości danych przesyłanych za pośrednictwem interfejsu sieci publicznej. W wersji RTM produktu Exchange 2007 wszystkie operacje kopiowania i inicjalizowania plików dziennika były realizowane z wykorzystaniem interfejsu sieci publicznej.

Warto również wspomnieć, że w przypadku stosowania maszyn bazujących na systemie Windows Server 2008 należy upewnić się, że obsługa protokołów NetBIOS została włączona dla wszystkich interfejsów sieciowych, które mają być wykorzystywane do kopiowania i inicjalizowania plików dziennika. Jeśli obsługa protokołu NetBIOS jest wyłączona, nie będzie można wykonać polecenia Enable-ContinuousReplicationHostNames.

Polecenie cmdlet Enable-ContinuousReplicationHostNames umożliwia określenie, które interfejsy sieciowe mają posłużyć do kopiowania i inicjalizowania plików dziennika. Należy jednak pamiętać, aby wcześniej przekształcić sieć prywatną w sieć mieszaną w konsoli Windows Failover Cluster.

Dodatkowe informacje znaleźć można w dokumentacji Exchange 2007 SP1.

Pyt. Zalecenia dotyczące powstrzymywania przepływu wiadomości do i z serwera Mailbox

Czy Microsoft opublikował zalecenia dotyczące powstrzymywania przepływu wiadomości do i z serwera Mailbox np. w przypadku ataku wirusów lub innej awarii w wersji Exchange 2007? Chcielibyśmy, aby w takiej sytuacji użytkownicy mogli łączyć się ze swoimi skrzynkami pocztowymi, ale nie mogli wysyłać ani odbierać wiadomości e-mail.

Odp.
Można osiągnąć ten efekt, zatrzymując usługę Microsoft Exchange Transport na serwerach Hub Transport w systemie Exchange 2007.

Aby umożliwić przesłanie wszystkich oczekujących wiadomości e-mail, bez możliwości dodawania do kolejki nowych wiadomości, wystarczy wstrzymać usługę Microsoft Exchange Transport.

Warto mieć świadomość, że w celu przeprowadzenia tej operacji na poziomie serwera Mailbox trzeba zatrzymać usługę Microsoft Exchange Mail Submission na odpowiednich serwerach Mailbox Exchange 2007.

Pyt. Archive Mailbox w Outlook 2003 lub 2007 oraz przenoszenie skrzynki Archive

Analizuję nową funkcję Archive Mailbox w systemie Exchange Server 2010 i mam kilka pytań. Zauważyłem, że po włączeniu tej funkcji dla skrzynki pocztowej użytkownika jest ona dostępna i działa zgodnie oczekiwaniami w programie Outlook Web Access 2010 oraz Outlook 2010, ale nie w programie Outlook 2003 lub 2007. Czy to oznacza, że nie będziemy mogli korzystać z nowej funkcji Archive Mailbox, dopóki nie dokonamy aktualizacji do wersji Outlook 2010?

Ponadto chcielibyśmy przenieść skrzynkę pocztową Archive wybranego użytkownika do innej bazy danych skrzynek pocztowych. Jednak wydaje nam się, że taka opcja nie istnieje. Jeśli nie można przenosić skrzynek pocztowych archiwum do innej bazy danych, jaki jest sens ich stosowania?

Odp.
W odniesieniu do pierwszego pytania: Twoje obserwacje są słuszne (nawet w odniesieniu do wersji Exchange 2010 RTM). Dostęp do skrzynki pocztowej archiwum (nazywanej także alternatywną skrzynką pocztową) można uzyskać jedynie za pośrednictwem programu Outlook Web Access 2010 lub Outlook 2010. Dostęp przy użyciu starszych aplikacji klienckich Outlook 2003 lub 2007 nie jest ani wspierany ani możliwy.

Odnośnie drugiego pytania: skrzynki pocztowe Archive muszą znajdować się w tej samej bazie danych, w której zlokalizowana jest podstawowa skrzynka pocztowa. Jednak ponieważ do przechowywania baz danych i dzienników skrzynek pocztowych w systemie Exchange 2010 można używać dysków Tier 2 (tzw. dysków SATA), przenoszenie skrzynki pocztowej Archive do innego podsystemu magazynowania nie ma większego sensu. Tym niemniej funkcja Archive Mailbox oferuje inne korzyści.

Pozwala zaoferować użytkownikom końcowym większe skrzynki pocztowe bez wpływania na wydajność folderów najważniejszych funkcji w podstawowej skrzynce pocztowej (podstawowa skrzynka pocztowa = najświeższe dane, skrzynka pocztowa archiwum = stare dane), pomimo iż bazy danych skrzynek pocztowych znajdują się na dyskach SATA/Tier 2. Można dostarczać duże skrzynki pocztowe (ponad 10 GB) bez konieczności synchronizowania wszystkich danych z plikiem .OST użytkownika w trybie buforowanym (skrzynka pocztowa Archive jest dostępna jedynie w trybie online).

Skrzynka pocztowa Archive zastępuje pliki .PST. Jak już wspomniano, skrzynka pocztowa Archive jest dostępna nie tylko w programie Outlook 2010, ale także Outlook Web Access 2010. A to oznacza, że nie trzeba już kłopotać się tworzeniem kopii zapasowych plików .PST.

Więcej informacji

Henrik Walther posiada tytuły Microsoft Certified Master: Exchange 2007 i Exchange MVP oraz ponad 15-letnie doświadczenie w branży IT. Pełni rolę architekta technologii w firmie Trifork Infrastructure Consulting (partnerze Microsoft Gold Certified Partner z siedzibą w Danii) oraz autora publikacji technicznych w firmie Biblioso Corp. (amerykańskiej firmie specjalizującej się w usługach zarządzania dokumentacją i lokalizacjami).