Reanimacja serwera Exchange

NSI Double-Take for Windows

Schemat działania DOUBLE-Take for Windows

Schemat działania DOUBLE-Take for Windows

Double-Take for Windows jest systemem replikacji na poziomie bajtów. Identyfikowane są źródła zestawów danych (dyski, wolumeny i foldery). Docelowe obszary pamięci masowej są obliczane pod względem rozmiarów i następnie przydzielane dla replikacji. Przy wielu instalacjach jeden obszar docelowy może odpowiadać różnym źródłom danych, ale dla Exchange firma NSI rekomenduje przydział "jeden do jednego", jeżeli obszary docelowe mają być używane dla kolejnych możliwych obejść uszkodzeń.

Program replikuje wybrane przez użytkownika pliki lub całe wolumeny poprzez standardowe połączenia sieciowe.

Tworzenie serwera lustrzanego zabiera ok. 530 min. potrzebnych na replikowanie testowej bazy danych, zawierającej moduły wykonawcze Exchange i pamięci wiadomości obu serwerów ośrodka pierwotnego.

Ta początkowa synchronizacja była prosta do ustawienia, ale wymagała wykonania dodatkowych kroków, takich jak konfigurowanie plików wsadowych i odnajdywanie plików Exchange.

W testowym systemie z 2 drzewami katalogowymi i 2 serwerami Exchange, na którym symulowano strukturę zarządu i działu produkcji, wymagane były 4 licencje Double-Task (przy jedynie 2 na serwery Exchange).

Po pojawieniu się konieczności wykonania procesu failover - wynikającej z przekroczenia progu uszkodzeń, który może być ustawiony dla komunikacji pomiędzy serwerami - oprogramowanie wyzwala operacje ustawione przez użytkownika w rekomendowanym pliku wsadowym, wywołującym komendę NSI ExchFailover. Komenda ta uruchamia Exchange na sprzęcie zastępczym i ustawia DNS na docelowy serwer.

Chociaż podczas testów nie stwierdzono żadnych błędów, NSI zaleca ścisłe monitorowanie procesów failover z powodu możliwości wystąpienia nieprzewidywalnych stanów przy starcie usług Exchange. Pomyślnie wykonano także próbę failback, czyli przywrócenie do pracy systemu pierwotnego, gdy stanie się ponownie dostępny.

Double-Take for Windows używa 32-bitowej aplikacji o nazwie Management Console, z pomocą której można kontrolować wszystkie aspekty produktu. Ikony pozwalają na wyświetlenie statusu serwera i jego właściwości (m.in.: zarządzane pozycje, informacje o logach itp.). Istnieje także interfejs linii komend dostępny dla ręcznego zatrzymywania, startowania, wykonania procedury failover i innych komend.

Jak testowano

Wykonano 2 cykle testów dla każdego produktu: jeden z Exchange 2000 pracującym na platformie Windows 2000 Advanced Server i jeden z Exchange 2003 pracującym na platformie Windows 2003 Enterprise Server.

Użyto instalacji Exchange dla 500 kont użytkowników usług katalogowych Active Directory, zawierających taką samą liczbę użytkowników i pamięci wiadomości o pojemności 30 GB. Serwery podzielono między wszystkich użytkowników w każdym z dwóch ośrodków - pierwszy 300 użytkowników, drugi 200. Utworzono także folder publiczny pamięci wiadomości o objętości 10 GB.

Ośrodek A zawierał 2 serwery Compaq DL360G3 (podwójne CPU 3 GHz, 1 GB DRAM) połączone przez sterowniki Emulex 2FC w pamięć sieciową SAN (2 niezależne niebuforowane dyski RAID 5 IMR Fortra) poprzez przełączniki Brocade Silkworm 3800 2FC. Sieć ta była połączona przez łącze 10Base-T (768 kb/s do symulowania szybkości połączenia WAN) z identyczną siecią w ośrodku B. Wyjątkiem były ustawienia testowe dla produktu LeftHand, który używa własnej pamięci. Drugi ośrodek "gorącej rezerwy" zawierał pierwotny i wtórny serwer dostępny dla każdego produktu. Oba ośrodki połączono przez PPTP VPN.

Jeden z serwerów był serwerem Active Directory Global Catalog Server z 300 użytkownikami, drugi zawierał 200 użytkowników w formie partycji lasu użytkowników. Ośrodek pierwotny miał więc 2 serwery odmienne pod względem pamięci i liczby użytkowników. Do symulowania 24 użytkowników generujących wzorcowe transakcje messagingu użyto VMWare GSX (EMC) pracującego na serwerach Micron (podwójne P4 3,2 GHz, 2GB DRAM). Po wystartowaniu wzorca transakcji dokładnie w tym samym czasie w każdym teście wyciągano pakiet z serwera. Proces ten miał wykazać, czy wiadomości są replikowane w czasie zbliżonym do rzeczywistego oraz czy metoda replikacji wiadomości i bloku używa migawek dostatecznie częstych, aby zapobiec utracie wiadomości będącej w toku transakcji.

SAN/iQ Remote IP Copy

Typowa architektura systemu z LeftHand SAN

Typowa architektura systemu z LeftHand SAN

LeftHand Networks zapewnia pełną funkcjonalność w sieci SAN (Storage Area Network), w której pracuje aplikacja SAN/iQ Remote IP Copy. Ponieważ firma nadzoruje instalacje swoich klientów, w laboratorium testowym inżynierowie tej firmy zainstalowali SAN i oprogramowanie. Taka kombinacja - o nazwie Network San Module (NSM) - jest lustrzanie powielana pomiędzy ośrodkami.

Remote IP Copy jest kombinacją funkcji: migawkowych obrazów dysków, dokładnego kopiowania w czasie i replikacji. Praca programu może być planowana, może on być uruchamiany bezpośrednio przez administratora lub doraźnie. Po zainicjowaniu kopiowania system pobiera migawki obrazu dysków woluminu pierwotnego i replikuje je w odległym klastrze. Po wstępnym wykonaniu migawki obrazu dysków replikowane są jedynie zmiany, co znacznie redukuje obciążenie pasma.

Konsola administracyjna Softec Replicator

Konsola administracyjna Softec Replicator

W konfiguracji testowej SAN zawierał 2 systemy RAID z 8 dyskami każdy. Dyski te - wraz z ich oprogramowaniem - były skonfigurowane jako RAID 10 (w nomenklaturze LeftHand, w rzeczywistości jest to kombinacja RAID 5/2). Instalacja sprzętu zabiera ok. godziny, wstępna instalacja oprogramowania ok. pół godziny.

Ustawiono 2 pamięci w każdym ośrodku dla każdego serwera Exchange pracującego na 1 NSM.

NSM przesyła migawkowy obraz danych ze źródła do celu. Jeżeli szybkość łącza danych pomiędzy NMS jest wystarczająca, migawki mogą być pobierane i wysyłane często. Ponieważ transakcje serwera poczty są z natury fluktuacyjne, aby zapewnić, że transakcje nie zostaną utracone, potrzebne są częste migawki. Produkt może być strojony do wykonywania dostatecznie częstych migawek.