Exchange — pytania i odpowiedzi: macierze serwera dostępu klienta — role serwera, tworzenie klientów, równoważenie obciążenia i inne

Opublikowano: 27 maja 2010

Zawartość strony

	Poznawanie ról serwera
	Projektowanie dostępu klienta
	Tworzenie klientów
	Macierze CAS — równoważenie obciążenia
	Połączenia z programem Outlook
	Równoważenie obciążenia za pomocą rozwiązania Windows NLB

Poznawanie ról serwera

Pyt.: Zamierzam uaktualnić środowisko z oprogramowania Microsoft Exchange 2007 do Exchange 2010. Implementacja musi być w pełni nadmiarowa na wszystkich poziomach. W naszej organizacji pracuje 3000 użytkowników, więc początkowo planuję zainstalowanie serwera Exchange na dwóch komputerach. Na każdym z nich będą dostępne role serwera: transport centralny (HT), dostęp klienta (CAS) i skrzynka pocztowa (MB). Obydwa komputery będą członkami grupy dostępność bazy danych (DAG), więc serwery będą replikować bazy danych między sobą.

Dzięki doświadczeniu związanemu ze środowiskiem Exchange wiem, że jeśli role HT i MB są na tym samym komputerze, to usługę wymiany poczty Microsoft Exchange Mail Submission raczej należy umieścić na lokalnym serwerze HT. W lokacji usługi Active Directory nie są używane inne serwery HT w działaniu okrężnym w przeciwieństwie do serwerów MB niezawierających roli serwera HT.

Jeśli podobna sytuacja występuje w przypadku oprogramowania Exchange 2010, to pojawia się problem. Zachowanie kontenera transportowego na odpadki w członku DAG nie ma sensu. Jeśli serwer członkowski będzie niedostępny i bazy danych skrzynki pocztowej zostaną awaryjnie przeniesione do innego członka DAG, to wiadomości z kontenera transportowego na odpadki nie będzie można przesłać ponownie.

Odp.: rozumiem te obawy. Po pierwsze należy pamiętać, że przewidziano taki scenariusz w grupie produktów Exchange. W początkowej fazie opracowywania produktu Exchange 2010 wprowadzono odpowiednie zmiany. Jeśli usługa wymiany poczty wykryje, że jest uruchomiona na serwerze skrzynek pocztowych będącym częścią DAG, lokalny serwer HT nie będzie serwerem preferowanym. Obciążenie zostanie rozłożone na inne serwery HT w tej samej lokacji usługi Active Directory. W przypadku niezalezienia żadnego serwera wybrany zostanie lokalny serwer HT.

Zmiana położenia usługi wymiany poczty w roli MB nie była jedyną zmianą wprowadzoną przez programistów. Zmiany dotyczyły również roli HT i przekierowania wiadomości do innego serwera HT w lokacji usługi Active Directory, jeśli rola HT jest zainstalowana na serwerze zawierającym również rolę MB i stanowiącego część DAG. Obydwie zmiany zostały wprowadzone w celu zapewnienia wysokiego poziomu dostępności, w sytuacji gdy role HT i MB współistnieją na serwerze będącym członkiem DAG.

 Do początku strony

Projektowanie dostępu klienta

Pyt.: projektujemy rozwiązanie Exchange 2010 i musimy określić liczbę tworzonych macierzy serwera dostępu klienta (CAS). Będziemy dysponować dwoma centrami danych, każde z własną lokacją usługi Active Directory. Czy lepiej utworzyć jedną macierz w lokacji, czy też wiele macierzy?

Będziemy również stosować wiele grup DAG chroniących bazy danych skrzynek pocztowych, a kopie każdej bazy danych będą rozmieszczane w dwóch lokacjach. Czy przełączenie awaryjne do kopii w innej lokacji, do której podłączeni są użytkownicy, wymaga ręcznej zmiany konfiguracji DNS, aby przełączyć klientów do macierzy serwera dostępu klienta w innej lokacji?

Odp.: określenie liczby macierzy CAS nie powinno być trudne: nie można utworzyć więcej niż jednej w każdej lokacji usługi Active Directory. W przypadku próby utworzenia wielu macierzy zostanie wyświetlony błąd pokazany na Rys. 1.

Rys. 1 Komunikat o błędzie wyświetlany podczas próby utworzenia drugiej macierzy CAS w lokacji usługi Active Directory.

Dostęp do bazy danych skrzynki pocztowej można uzyskać za pomocą dowolnej macierzy CAS w środowisku, więc nie trzeba tworzyć wielu macierzy. A nawet jeśli możliwe byłoby utworzenie wielu macierzy, to i tak używana byłaby pierwsza z nich.

Odnośnie do drugiego pytania: dopóki co najmniej jeden serwer CAS w macierzy CAS w lokacji 1 jest dostępny, nie trzeba konfigurować DNS, więc po przełączeniu awaryjnym klienci są kierowani do macierzy w innej lokacji. Serwery CAS dostępne w lokacji 1 będą się komunikować bezpośrednio z serwerami skrzynki pocztowej (przechowującymi aktywne bazy danych dla użytkowników w lokacji 1) za pomocą usługi RPC.

 Do początku strony

Tworzenie klientów

Pyt.: czy istnieją jakieś zalecane rozwiązania dotyczące tworzenia macierzy CAS Exchange 2010 w lokacji usługi Active Directory?

Odp.: zaleca się utworzenie macierzy CAS przed utworzeniem baz danych skrzynki pocztowej lub przeniesieniem skrzynek pocztowych do serwera skrzynek pocztowych Exchange 2010 w lokacji. Bazy danych skrzynek pocztowych Exchange 2010 opatrzone są atrybutem RpcClientAccessServer. W przypadku braku macierzy CAS w lokacji usługi Active Directory podczas tworzenia bazy danych, zostaną one zapełnione nazwą FQDN serwera CAS Exchange 2010 w lokacji usługi Active Directory. Jeśli macierz CAS zostanie utworzona przed utworzeniem baz danych skrzynki pocztowej, ten atrybut zostanie nadany FQDN w macierzy CAS, patrz Rys. 2.

Rys. 2 Atrybut RpcClientAccessServer w bazie danych skrzynek pocztowych.

Dlaczego jest to dobre rozwiązanie? Klient programu Outlook (Outlook 2003, 2007 lub 2010) automatycznie nie rozpozna zmiany. W przypadku programów Outlook 2007 lub 2010 profil można zaktualizować uniemożliwiając dostęp do punktu końcowego RPC lub naprawiając profil. Ale w programie Outlook 2003 nie można zmienić punktu końcowego ani użyć funkcji naprawy profilu. To zmusza użytkownika do ręcznego wprowadzenia zmian profilu, poprzez usunięcie nazwy użytkownika, ponowne dodanie i kliknięcie przycisku „Sprawdź nazwę”. Nie jest to idealne rozwiązane i dotyczy również użytkowników końcowych, więc zdecydowanie zaleca się wcześniejsze utworzenie macierzy CAS.

 Do początku strony

Macierze CAS — równoważenie obciążenia

Pyt.: planujemy sprzętowe równoważenie obciążenia zamiast stosowania rozwiązania Windows NLB i zastanawiamy się, czy można w takiej sytuacji używać portów statycznych w nowej usłudze dostępu klienta Exchange 2010 RPC. Dostawca urządzenia umożliwiającego równoważenie obciążenia nie zaleca stosowania portów dynamicznych. Jeśli można ustawić porty statyczne, czy zalecane jest wybranie określonych portów?

Odp.: podobnie jak w przypadku poprzednich wersji, w programie Exchange 2010 dla usługi urzędu certyfikacji RPC można ustawić statyczne porty. Należy to zrobić również dla usługi książki adresowej programu Exchange, ponieważ program Outlook komunikuje się z obydwoma elementami za pomocą interfejsu MAPI. Z serwerem skrzynki pocztowej nawiązywane są również połączenia z folderów publicznych.

Aby ustawić port statyczny dla usługi urzędu certyfikacji RPC na serwerze CAS, należy otworzyć na każdym serwerze CAS w macierzy CAS otworzyć rejestr i przejść do klucza: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. Utworzyć nowy klucz o nazwie ParametersSystem, a pod tym kluczem utworzyć ciąg REG_DWORD o nazwie TCP/IP Port. Jako wartość DWORD należy wprowadzić żądany numer portu (zobacz Rys. 3).

W odniesieniu do statycznych portów RPC nie istnieje polecane rozwiązanie inne niż: w sieci korporacyjnych należy używać nieprzypisanych i nieużywanych portów. W sieci korporacyjnej firmy Microsoft używany jest port TCP/IP 7575. Należy używać najwygodniejszego rozwiązania.

Aby ustawić port statyczny usługi książki adresowej programu Exchange, w programie Notatnik należy otworzyć plik microsoft.exchange.addressbook.service.exe.config dostępny w położeniu C:\Program Files\Microsoft\Exchange Server\V14\Bin. Następnie należy wybrać żądaną wartość portu TCP/IP. W przypadku usługi książki adresowej programu Exchange i urzędu certyfikacji RPC nie można stosować tego samego portu TCP/IP.

Rys. 3 Konfiguracja portu statycznego dla usługi urzędu certyfikacji RPC na serwerze CAS.

Po skonfigurowaniu portu należy ponownie uruchomić usługę książki adresowej programu microsoft Exchange i dostępu klienta RPC Microsoft Exchange. Aby ustawić port statyczny połączeń z folderów publicznych, należy wykonać te same czynności co w przypadku portu TCP/IP używanego dla usługi urzędu certyfikacji RPC. Jedyna różnica to wymóg wykonania tej samej czynności w przypadku serwerów skrzynki pocztowej programu Exchange 2010, ponieważ połączenia z folderów publicznych odbywają się za pomocą usługi urzędu certyfikacji RPC w roli serwera skrzynki pocztowej. Po ustawieniu portu połączeń z folderów publicznych należy ponownie uruchomić usługę dostępu klienta RPC programu Microsoft Exchange na każdym serwerze skrzynki pocztowej.

 Do początku strony

Połączenia z programem Outlook

Pyt.: słyszałem, że z usługą urzędu certyfikacji RPC lub macierzą CAS mogą łączyć się tylko programy Outlook 2007 i 2010. Czy to prawda?

Odp.: w poprzednich wersjach dokumentacji programu Exchange 2010 podano błędne informacje, że nie można ustanawiać połączeń za pomocą programu Outlook 2003. Nie jest to prawdą. Program Outlook 2003 jest w pełni obsługiwany. Należy się tylko upewnić, że w profilu programu Outlook włączono szyfrowanie RPC lub wyłączono wymóg szyfrowania RPC na serwerach CAS. Z punktu widzenia zabezpieczeń firma Microsoft zaleca włączenie szyfrowania RPC w profilu programu Outlook. Szyfrowanie można włączyć za pomocą zasad grupy. W tym celu należy zapoznać się z artykułem dostępnym w bazie wiedzy: „Problemy dotyczące połączeń programu Outlook ze skrzynkami pocztowymi programu Exchange 2010 spowodowane wymogiem szyfrowania RPC (j. ang.)”.

 Do początku strony

Równoważenie obciążenia za pomocą rozwiązania Windows NLB

Pyt.: czy podczas używania rozwiązania Windows Network Load Balancing (WNLB) umożliwiającego równoważenie ruchu przychodzącego do tablicy CAS Exchange 2010 nazwa FQDN rozwiązania WNLB musi być zgodna z tablicą CAS?

Odp.: nie ma takiego wymogu. Przykładowo: podczas stosowania rozwiązania Windows NLB w celu równoważenia ruchu przychodzącego do tablicy CAS można określić nazwę FQDN rozwiązania Windows NLB jako np. casarray01.contoso.com i przydzielić macierz CAS outlook.contoso.com. Takie rozwiązanie będzie działać bezproblemowo i jest w pełni obsługiwane. O ile wewnętrzny rekord DNS macierzy CAS wskazuje wirtualne IP rozwiązania WNLB, to wszystko powinno działać prawidłowo.

Do początku strony