Klaster nad klastrami

Novell Business Continuance Cluster ma umożliwiać zdalne odtwarzanie środowisk klastrowych po awarii.

Novell Business Continuance Cluster ma umożliwiać zdalne odtwarzanie środowisk klastrowych po awarii.

Klastry geograficzne - tak zwykło się mówić o rozwiązaniach wysokiej dostępności, których zadaniem jest uruchomienie aplikacji w zapasowym ośrodku przetwarzania w razie poważniejszej awarii ośrodka głównego. Rozwiązania tego typu oferuje niewiele firm - głównie dostawcy dużych serwerów IBM, HP i Sun Microsystems oraz najwyższej klasy systemów pamięci masowych - EMC i Hitachi Data Systems.

Do tego elitarnego grona wkrótce zamierza dołączyć . Na zbliżającej się konferencji Brainshare 2004 firma po raz pierwszy zaprezentuje Novell Business Continuance Cluster (BC Cluster) - oprogramowanie mające umożliwiać zabezpieczanie instalacji klastrowych NetWare działających pod kontrolą oprogramowania Novell Cluster Services (NCS) 1.6 przez ich replikację i odtwarzanie na zdalnych klastrach. BC Cluster ma zapewniać czas pełnego przejęcia obciążenia przez zapasowy ośrodek w czasie krótszym niż 5 min.

Klaster stawia wymagania

Novell BC Cluster zakłada istnienie co najmniej dwóch odległych ośrodków przetwarzania.

W każdym z nich muszą działać co najmniej dwa serwery NetWare 6.5 w konfiguracji klastrowej (maksymalnie 32, choć to oczywiście teoria) współdzielące dyski logiczne w lokalnych sieciach SAN. Sieci SAN muszą być połączone szybką magistralą o dużej przepustowości, bardzo niskim wskaźniku błędów i niewielkich opóźnieniach (np. Fibre Channel, Gigabit Ethernet, Sonet, ATM, DWDM).

W kwestii sieci Novell wymaga, by serwery NetWare pracujące w ramach lokalnego klastra NCS były przypisane tej samej podsieci (ale innej niż ta, w ramach której są wymieniane komunikaty heartbeat klastra NCS). Adresy IP w ramach podsieci mogą być przydzielane nie z puli adresów fizycznych (konfiguracja domyślna), ale i wirtualnych (technologia VIPA - Virtual IP Address). W tym drugim przypadku, jakkolwiek budowa i utrzymanie klastra NCS są ułatwione, istnieje ograniczenie w postaci wsparcia jedynie dla dwóch protokołów routingu: RIP-1 lub RIP-2, za pośrednictwem których routery są informowane o aktualnej liczbie węzłów, ich adresach itp. Protokół OSPF na razie nie jest wspierany.

Na potrzeby replikacji metadanych pomiędzy działającymi w odległych ośrodkach serwerami eDirectory/DirXML musi istnieć (najlepiej dedykowane i o wysokich parametrach) łącze IP. Do tego celu jest wymagany także mechanizm replikacji metadanych - bądź to na poziomie serwera, bądź na poziomie podsystemu pamięci masowych (transfer blokowy).

Novell zaleca, aby w sieciach SAN działał dowolny mechanizm ograniczający dostęp do woluminów logicznych. Chodzi o to, aby uniemożliwić niepowołany zapis woluminów zapasowych (secondary volume). Można tu zastosować proste oznaczenia jako primary/secondary, mechanizm LUN zoning albo np. listy dostępowe. Wszystkie serwery w ramach pojedynczego klastra NCS muszą ponadto należeć do tego samego drzewa eDirectory. Novell sugeruje, by drzewo NDS było replikowane co najmniej w ramach dwóch serwerów klastra NCS, jednak nie więcej niż sześciu, ponieważ większa liczba replik obniża wydajność eDirectory.

Dowolnie, byle bezpiecznie

Przykładowa architektura Novell Business Continuance Cluster

Przykładowa architektura Novell Business Continuance Cluster

W trakcie normalnej pracy klastra NCS w ośrodku podstawowym dane i metadane (szerzej: wskazane przez administratora obiekty drzew systemu katalogowego eDirectory) są replikowane do klastra NCS działającego w ośrodku zapasowym. Replikacją zarządza serwer DirXML. Początkowo automatyczna replikacja będzie dotyczyć tylko tych usług, które są standardowo wspierane przez Novell Cluster Services 1.6. Aby replikować dane i metadane innych usług/aplikacji, administrator będzie musiał samodzielnie skonfigurować odpowiednie sterowniki DirXML.

BC Cluster pozwala na replikację zarówno synchroniczną, jak i asynchroniczną. Rozwiązanie może współpracować z istniejącym mechanizmem replikacyjnym działającym na poziomie serwera lub systemu pamięci masowych. Stosując transfer synchroniczny, trzeba liczyć się z niezależnymi od klastra ograniczeniami co do odległości - w zależności od technologii jest to 10 lub co najwyżej 200 km.

W przypadku replikacji asynchronicznej pomiędzy dwoma odległymi sieciami SAN przesyłane są różnicowe kopie danych typu snapshot. Tu nie ma ograniczeń co do odległości, jednak w razie awarii modyfikacje dokonane od ostatniej synchronizacji są tracone. Ta opcja może być przydatna w sytuacji, gdy firma ma obciążone serwery (zapis synchroniczny na większe odległości nieuchronnie wprowadza opóźnienie) lub gdy możliwości skalowania łącza WAN są ograniczone.

BC Cluster może działać w dwóch trybach. Tryb Active/Active oznacza, że klastry NCS w obu lokalizacjach pracują równolegle - każdy z nich przetwarza własne aplikacje, dopóki w drugim klastrze nie zdarzy się awaria. W takim przypadku klaster przerywa dotychczasowe zadania (wszystkie lub tylko niektóre) i przejmuje wskazane przez administratora usługi klastra, który uległ awarii. Klastry Active/Passive to takie, w których wszystkie usługi i aplikacje działają w ramach jednej lokalizacji, a klaster w drugiej lokalizacji oczekuje w pogotowiu na ewentualną awarię klastra podstawowego.

W tę i z powrotem

W pierwszej edycji BC Cluster przeniesienie obciążenia z klastra podstawowego do zapasowego nie będzie automatyczne, lecz będzie wymagać ręcznej zmiany ustawień przez administratora.

Novell argumentuje, że pełna automatyzacja procesu zdalnego odtwarzania klastra jest ryzykowna, choćby ze względu na możliwość wystąpienia fałszywych alarmów. Raz rozpoczęty proces zdalnego odtwarzania środowiska nie może być łatwo, a w każdym razie natychmiast, odwrócony. Przykładowo, woluminu, którego atrybut zmienił się z secondary na primary, nie da się z powrotem zadeklarować jako primary. Konieczne jest zatrzymanie aplikacji.