Przy okazji jednego z ostatnich projektów musiałem zapoznać się z możliwościami publikacji Exchange 2013, jakie dają load balancery firmy Barracuda. Można do tego użyć appliance’ów sprzętowych, jednak od niedawna są dostępne również maszyny wirtualne na platformę zarówno VMware, Citrix, Oracle jak i Hyper-V. Do testów w labie użyłem najprostszego modelu 340Vx.
Na stronie pomocy technicznej Barracudy jest dostępna instrukcja konfiguracji urządzenia do publikacji Exchange 2013. Jest ona stosunkowo prosta i łatwa do realizacji, jednak po krótkiej analizie zauważyłem, że konfiguracja HealthCheck’ów nie jest dostosowana do możliwości Exchange 2013 (indywidualna weryfikacja poszczególnych usług). Jednak po dyskusji z europejskim serwisem Barracudy, okazało się, że w najnowszej wersji firmware 4.2.2.007 (wsparcie dla Exchange 2013 i instrukcja jest dla firmware od wersji 3.6.1.009) można skonfigurować Load Balancer tak, żeby każdy komponent był weryfikowany indywidualnie. Poniżej zamieszczam krótką instrukcję, jak to przeprowadzić.
Początek jest taki sam jak w instrukcji. Przechodzimy na zakładkę Services i po przełączeniu widoku na Advanced View, dodajemy nowy wirtualny serwis.
Po wpisaniu nazwy wybieramy typ serwisu (Layer 7 – HTTPS), certyfikat z listy zainstalowanych wcześniej na balancerze, a następnie podajemy adres IP, na jakim wirtualny serwis będzie nasłuchiwał. Bardzo ważne jest wybranie odpowiedniego interface. Nawet w konfiguracji z pojedynczym interfacem (taka jest wstępna konfiguracja maszyny wirtualnej) skonfigurowanym w ustawieniach są dostępne dwa – WAN i LAN, co oczywiście nie ma odbicia w lokalizacji urządzenia w naszej sieci.
W kolejnym kroku instukcja każe nam dodać adresy IP serwerów Exchange (Real Server) i utworzyć usługę, my jednak bez konfgurowania serwerów klikamy na przycisk Add Service. Po utworzeniu serwisu w pierwszej kolejności dodajemy reguły publikacji dla poszczególnych wirtualnych katalogów Exchange, dopiero do których będziemy dodawać real serwery (tak jak to jest opisane w instrukcji publikacji Exchange dla urządzeń Kempa). Najpierw dodajemy regułę klikając z prawej strony serwisu w słowo Rule.
Pojawia nam się w tym momencie okienko kreatora, w którym podajemy naszą nazwę dla reguły oraz wirtualny katalog (zakończony gwiazdką), który reguła ma pozwalać publikować w ramach serwisu. Możemy także zmienić domyślne ustawienia rozkładania ruchu i kierowania połączeń.
Teraz dodajemy serwer rzeczywisty, powiązany z regułą, po prostu wpisując jego adres IP.
Po dodaniu wchodzimy w edycję właściwości serwera, włączamy korzystanie z HTTPS i zmieniamy sposób monitorowania na Simple HTTPS.
Teraz podająmy odpowiedni URL (w przypadku usługi ActiveSync będzie to /Microsoft-Server-ActiveSync/healthcheck.htm), odpowiedź jaką powinniśmy dostać (STATUS OK), oraz kod odpowiedzi (200). Czy serwer zwraca poprawną odpowiedź możemy sprawdzić, naciskając przycisk Test, pod definicją monitora. Na koniec zapamiętujemy zmiany, co zamyka okno kreatora.
To samo robimy dla kolejnych serwerów w farmie, a później dla kolejnych usług – Autodiscovera, ECP, EWS, OAB, OWA i RPC.
Finalnie konfiguracja reguł dla naszego wirtualnego serwera Exchange powinna wyglądać jak na ostatnim rysunku. Możemy również dodać przekierowanie ruchu HTTP.
2 komentarze:
Dopiero rozpocząłem naukę na temat Exchange. Czy mógłbyś wytłumaczyć po co używa się takich rozwiązań? Tych rozwiązań używamy wyłącznie do publikacji dostępu do OWA?
W skrócie (bo pełny opis to naprawdę długi artykuł) wynika to z zaleceń Microsoftu do publikacji usług Exchange na kilku serwerach równolegle. 3 metody publikacji uwzględniają DNS Round Robin, wbudowany w Windows NLB albo sprzętowy Load Balancing (HLB) na urządzeniach takich jak Kemp, F5 czy też Barracuda. DNS i NLB nie pozwalają na sprawdzenie czy usługa webowa działa poprawnie na porcie 443, HLB tak, ale jak widać w poscie, czasem trzeba to nieco doszlifować, żeby wszystkie usługi były weryfikowane indywidualnie, tak jak umożliwia to Exchange 2013
Prześlij komentarz