BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











Parę słów o architekturze Exchange Server 2010 SP1 dla kilkuset użytkowników (cz. 1)

31-10-2011 06:00 | Ziemek Borowski
Jedynym z typowych na polskim rynku wyzwań jest zaplanowanie wdrożenia dla relatywnie małych organizacji (np. kilkaset stanowisk). Pierwsza część tekstu ma posłużyć jako przewodnik co do tego jakie kwestie być może warto wziąć pod uwagę przy planowaniu architektury środowiska Exchange Server dla tego typu organizacji.

Jedynym z typowych na polskim rynku wyzwań jest zaplanowanie wdrożenia dla relatywnie małych organizacji (np. kilkaset stanowisk). Zwykle nie kwalifikują się one do rozwiązań przewidywanych dla małych środowisk (takich jak Windows Small Business Server) a jednocześnie nie są w stanie skorzystać z doradztwa dostępnego dla wielkich organizacji (np. w formie Microsoft Software Assurance Planning Services). Niniejszym tekst ma posłużyć jako przewodnik jakie kwestie być może warto wziąć pod uwagę przy planowaniu architektury środowiska Exchange Server dla tego typu organizacji. Nie jest on gotową specyfikacją ani dokumentem projektowym dostosowanym do potrzeb konkretnego wdrożenia i nie należy go traktować jako uniwersalnej i gotowej recepty na wszystkie problemy.

Nie będę w opisie stosował klasycznych metody rozwoju nowych usług (takich jak MSF) czy utrzymywania już istniejących (np. ITIL lub MOF). Będę także szedł czasem w poprzek zaleceniom producenta (np. w wypadku Exchange Server zawartych w dokumencie Exchange Server 2010 / Planning for Exchange 2010 / Planning Roadmap for New Deployments). Nie wynika to z ich braków: tu raczej chcę przedstawić kluczowe kwestie w ograniczonej objętościowo, ale użytecznej formie. Przy przeprowadzaniu projektu warto powrócić do tych metodyk i którąś z nich zaadaptować do konkretnych warunków organizacyjnych i technicznych.

Ustalenie podstawowych wymagań dla środowiska Exchange Server

Pierwszym i podstawowym krokiem  jest przeprowadzenie analizy tego jakie są realne i spełnialne oczekiwania wobec planowanego wdrożenia. Z jednej strony należy zastanowić się nad wymaganiami biznesowymi, uwarunkowaniami licencyjnymi i finansowymi, ale także nad tym jak w efektywny sposób przeprowadzić wdrożenie.

Pomocnym w tym (poza lekturą wspomnianego rozdziału dokumentacji Exchange Server: Planning for Exchange 2010) może okazać się wykorzystanie Infrastructure Planning and Design (IPD) Guide for Microsoft Exchange Server 2010 with Service Pack 1 - dokumentu z Solution Accelerators. Na tym etapie warto także rozważyć alternatywne ścieżki budowy usługi (np. oparcie się o usługę hostowaną - tu pomocny może być inny dokument z tej serii IPD Guide for Exchange Online—Evaluating Software-plus-Services.

Dobre i szczegółowe omówienie tematów planowania wymagań zawierają także dwie pozycje książkowe dotyczące Exchange Server:

Dobranie architektury sprzętowej

Po ustaleniu wymagań stawianych środowisku możemy rozpocząć etap szacowania wymagań sprzętowych nowego środowiska. Podstawowym narzędziem jakie udostępnia nam grupa produktowa Exchange jest Exchange 2010 Mailbox Server Role Requirements Calculator (istnieje także wersja dla Exchange 2007). Jest to arkusz programu Excel z wyskalowanymi kluczowymi parametrami dotyczącymi wpływu środowiska na wymagania dotyczące serwerów skrzynkowych a zwłaszcza ich podsystemu dyskowego.

Po starannym (i nie ma co ukrywać wymagającym skupienia i pewnego doświadczenia) wypełnieniu zakładko Input w pozostałych pojawią się nam sugestie co do sposobu zaplanowania środowiska skrzynkowego: rekomendowane wymogi dla podsystemu dyskowego, stosowanych dostępnych LUN-ów, wymogów procesora, sposobów wykonywania kopii zapasowych.

Poza kalkulatorem od dotyczącym obliczania wymogów co do składowania danych Microsoft wraz partnerami przygotował w ramach programu Exchange Solution Reviewed Program (ESRP) Storage 3.0 przykłady (zebrane przez Michel de Rooij na jego blogu) przykłady referencyjnych rozwiązań wyskalowanych pod konkretne potrzeby.

Dodatkowo wielu dostawców przygotowało własne kalkulatory:

HP ActiveAnswers Sizers:

Dell Exchange 2010 Advisor (choć mi osobiście bardziej odpowiadały porady zawarte na DellTechCenter)

Warto z nich skorzystać, po to by upewnić się, że wybrana architektura jest słuszna i że zadaliśmy sobie wszystkie kluczowe pytania.

Podział ról na serwery

Standardowo Exchange Server 2010 SP1 udostępnia następujące role:

  • Mailbox - MBX - odpowiedzialny za przechowywania informacji pocztowych,
  • Client Access Service - CAS - usługi dla klientów MAPI (choć tylko Mailbox, foldery publiczne nadal udostępniane są przez rolę Mailbox,
  • Hub Transport - HT - odpowiedzialny za obsługę ruchu SMTP oraz przekazywanie wiadomości, w tym obsługę wysyłania przez klientów SMTP (Mail Submission),
  • Edge (czyli Hub Transport, tyle, że mogący pracować poza domeną oraz posiadający klika dodatkowych opcji filtrowania, 
  • Unified Messagging - UM - odpowiada za fragmenty Exchange dostarczające funkcji głosowych.

Dla działania podstawowych funkcji niezbędne jest równoległe działanie ról Mailbox, CAS oraz HT. Role te (oraz UM) mogą być łączone ze sobą (choć nie zawsze jest to celowe).

Rola Edge jest mocno rekomendowana, aczkolwiek jej podstawowe funkcje (obsługa publicznych łączników (connectorów) odbierających oraz wysyłających, w tym filtrowanie spamu) dają się zrealizować w oparciu o Hub Transport.

Warto zwrócić uwagę, na to, że w wypadku Exchange (we właściwie wszystkich wersjach) nie przewiduje się umieszczenia jakiegokolwiek z ról poza Edge w klasycznie rozumianym środowisku DMZ. Klasyczny DMZ (polecam tu prezentację Daniela Stefaniaka na ten temat) to środowisko dostępne ze świata publicznego i mające bardzo ograniczony dostęp do środowiska wewnętrznego. Wszystkie role Exchange Server (z wyjątkiem Edge) potrzebują pełnego dostępu do Active Directory. Dlatego też wydaje się, że w wypadku gdy trzeba jak najstaranniej kontrolować dostęp do sieci wewnętrznej a zarazem udostępnić pocztę elektroniczną z zewnątrz sieci należy albo zastosować oddzielną domenę dla Exchange Server albo przynajmniej wydzielić lokację (site) Active Directory dla środowiska Exchange (w ten sposób da się ograniczyć komunikację z resztą sieci).

Wysoka dostępności i Exchange Server

W wypadku Exchange Server 2010 jedną z kluczowych decyzji będzie to czy potrzebujemy mechanizmów wysokiej dostępności i w jakim zakresie. Będziemy o to pytani przy niemal wszystkich szczegółowych kwestiach podczas skalowania sytemu.

Warto zwrócić uwagę na to, że wraz z pojawieniem się Exchange Server 2007 a potem i 2010 (lub w wypadku transakcyjnych baz danych wraz z Database Mirroring w SQL Server 2005) zmieniło się podejście do zapewniania wysokiej dostępności baz danych. Do tej pory dominował model który w Exchange Server 2007 nazwano Single Copy Cluster - wspólnych zasobów dyskowych dla wszystkich węzłów klastra. Zapewniane były powiększone zasoby dla wszystkich elementów, tylko nie dla przestrzeni dyskowej (czyli czegoś co ze swej natury jest chyba najbardziej zawodnym elementem współczesnych systemów komputerowych). W wersji 2007 pojawiła się opcja podobna do SQL Serverowego Log Shippingu (CCR - Continiues Cluster Replication - gdzie bazy danych dostępne były na serwerze aktywnym i pasywnym, w ramach pary). W Exchange Server 2010 pojawiło się pojęcie Database Availability Group (czyli rozwiązania gdzie aktywny jest nie serwer a pojedyncza kopia bazy - a każda z baz może się znaleźć na wielu serwerach w ramach grupy klastrowej - do 16). 

Niestety: ponieważ DAG wykorzystuje Windows Failover Clustering nie można zastosować dostępnych mechanizmów zwiększania dla  innych ról potrzebnych do zapewnienia kompletnej usługi pocztowej czyli Windows Load Balancingu dla roli CAS (Client Access Service).

Należy rozważyć które z ról w rzeczywistości wymagają wysokiej dostępności, a następnie dostosować układ serwerów do uzgodnionych wymagań. Przykłady konfiguracji znajdą się w drugiej części tekstu.

Lista dokumentów i książek istotnych w planowaniu wdrożenia

Microsoft TechNet

Książki

Komentarze 1

Marcin Milewski
Marcin Milewski
1257 pkt.
Senior
08-11-2011
oceń pozytywnie 0
swietny wstep, bardzo milo sie czyta i z niecierpliwoscia czekam na kolejna czesc...
pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.