Wiele jest w Polsce firm, w których serwery pracują przez 24 godziny na dobę. Osoby korzystające z nich prawie zawsze wymagają, aby zasoby tych serwerów były dostępne bez przerwy, a ich awaryjność była minimalna. Jednak od przekonania użytkowników do rzeczywistej niezawodności wiedzie trudna droga usiana wydanymi pieniędzmi. W dzisiejszym artykule chciałbym przedstawić możliwości efektywnego podnoszenia niezawodności działania poprzez stosowanie serwerów klastrowych, pracujących pod kontrolą Windows 2000.
Można podać różne przykłady, kiedy niezawodność pracy serwera jest krytycznym parametrem określającym możliwości przedsiębiorstwa. Praca na trzy zmiany nie zawsze oznacza konieczność posiadania idealnie niezawodnego serwera. Jeśli jednak proces produkcyjny jest sterowany komputerowo, a zatrzymanie go spowoduje straty nieproporcjonalnie duże w porównaniu do czasu trwania przerwy, klaster staje się nieodzowny. Można też sobie wyobrazić przykłady firm nie pracujących przez 24 godziny, w których nawet krótka przerwa jest nie do zaakceptowania. Nikt nie wróci do banku, w którym są ciągłe problemy z wypłatą pieniędzy, ze względu na "awarię systemu komputerowego".
Prostym sposobem podnoszenia niezawodności funkcjonowania sprzętu jest stosowanie redundancji, czyli nadmiarowości elementów tworzących komputer. Dwa zasilacze, dwie karty sieciowe czy kontrolery dyskowe są powszechnie stosowane nawet w dość tanich serwerach. Jednak dwa procesory to już nie zawsze nadmiarowość procesorów (niewiele jest na świecie konstrukcji, w których można wymienić procesor bez zakłócenia pracy komputera). A dwie lub więcej płyt głównych w jednej obudowie to raczej kilka komputerów, a nie redundancja (konstrukcję taką nazywa się czasami mianem serwera blade).
W przypadku niektórych elementów, które nie są krytyczne dla pracy systemu stosuje się różne technologie, które umożliwiają wymianę uszkodzonych części w trakcie pracy. Hot-plug to technologia, która umożliwia jawne zatrzymanie pracy jakiegoś elementu i wymianę go w trakcie pracy komputera. Rozwiązenie takie może dotyczyć na przykład karty sieciowej. Oczywiście sens stosowania tej technologii istnieje tylko wtedy, gdy karta taka jest zdublowana i zatrzymanie jednej z nich nie powoduje utraty komunikacji serwera z siecią. Hot-swap to technologia umożliwiająca wymianę elementu w czasie pracy (pod napięciem). Rozwiązania takie stosuje się do zasilaczy czy dysków twardych. Często tecnologia ta jest pochodną stosowania innych konstrukcji, mających na celu podniesienie niezawodności komputera. Tak więc wymiana twardego dysku może odbyć się w przypadku, gdy dyski pracują w trybie mirror (lustrzane kopie), bądź tworzą macierz typu RAID.
Mimo tego, że większości awarii można w ten sposób zapobiec, może wystąpić sytuacja, gdy element mimo wymiany na sprawny nie podejmie stabilnej pracy. Poza tym istnieją w komputerach elementy, które nie posiadają żadnej nadmiarowości stwarzając przez to nadmierne zagrożenie przerwy w pracy.
Poszczególne rozwiązania stosowane w celu podniesienia bezawaryjności pracy komputera nie czynią z niego jeszcze serwera. W czasach zamierzchłej przeszłości informatycznej nikt nie myślał o używaniu komputerów typu PC w roli serwerów. Jednak od początku lat dziewiędziesiątych tendencja ta powoli się odwracała. Obecnie platforma intelowska (należy włączyć w to również procesory AMD) obfituje w podzespoły dedykowane do produkcji serwerów. Elementy te wyróżniają się, w stosunku do używanych w zwykłych PC-tach, zarówno niezawodnością pracy jak i szczegółami konstrukcyjnymi, lepiej predystynującymi je do pracy serwerowej (np. lepiej dopracowaną wielowątkowścią). Mimo tego, że elementy te są droższe od standardowych, zbudowane z nich serwery są znacznie tańsze, niż komputery bazujące na przykład na platformie RISC. W związku z tym każda poważna firma komputerowa ma w swojej ofercie serwery bazujące na platformie Intel.
Poza wykorzystaniem specjalizowanych elementów serwer, w stosunku do zwykłego PC-ta, wyróżnia się on kilkoma ważnymi cechami. Najważniejsze to stosowanie technologii, która umożliwia wewnętrzną kontrolę pracy poszczególnych podzespołów. Dobrym przykładem są macierzowe interfejsy obsługi dysków twardych, które nie tylko zapewniaja większą szybkość i bezpieczeństwo, ale same są w stanie wykryć ewentualna awarię jednego z nadmiarowych elementów macierzy i przekonfigurować się w czasie działania tak, że nie zmieni to warunków pracy serwera. Prawie zawsze serwery wyposażone sa też w zasilacze, umożliwiające jednoczesne zasilanie komputera z dwóch różnych źródeł zasilania. Regułą też jest, że zdublowane elementy pracują w technologii hot-swap bądź hot-plug, chodź nie zawsze jest to warunek spełniany w sposób jawny. Osobnym, niefizycznym aspektem serwera jest gwarancja udzielana przez producenta i czas reakcji na ewentualną awarię. Niczym wyrafinowanym nie jest tu 4 godzinny okres, który upływa od zgłoszenia awarii do pojawienia się serwisu firmowego w serwerowni.
Dalsze podnoszenie niezawodności i skracanie potencjalnego czasu przestoju może się odbywać wyłącznie poprzez zwielokratnianie całych komputerów i łączenie ich w hybrydy (klastry bądź farmy) widoczne z zewnątrz jako jedna maszyna. Generalnie istnieją trzy sposoby łączenia komputerów w celu podniesienia niezawodności całego układu. Klasyczny, znany z systemów UNIXowych i pochodnych, to farma komputerów, widziana jako jeden wielki zasób jednej instancji systemu operacyjnego. Dwa dwuprocesorowe komputery są widziane jako cztery procesory dostepne dla systemu. Awaria jednego z komputerów powoduje wyłącznie spadek mocy całego systemu, bez utraty wykonywanych zadań. Ostanimi czasy bardzo modne stało się wykorzystanie komputerów bazujących na platformie Intela do budowy serwerów typu blade (oczywiście można używać w tym celu również procesorów typu RISC, lecz zaletą procesorów intelowskich jest ich niska cena). Są to małe komputery, skonstruowane w postaci kart wpinanych do wspólnej, bardzo szybkiej magistrali sieciowej. Formalnie każda z kart jest pełnoprawym komputerem, przystosowanym do wykorzystania wewnętrznej sieci. Zestaw tych komputerów połączony jest programowo tak, aby zarówno z zewnątrz jak i wewnętrznie był traktowany jako jeden komputer. Cały serwer pracuje poprawnie bez względu na to, czy w obudowie wstawione jest 16, 128 czy 1024 karty. Jedyna różnicą jest szybkość wykonywania określonego zadania. System posiada mechanizmy, które umożliwiają wykrycie awarii i powierzenie pracy wykonywanej przez zepsuty fragment klastra innemu elementowi. W razie ewentualnej awarii system pamięta zadanie przydzielone zepsutej karcie i ponownie przydziela to zadanie innej.
Drugie, typowo sprzętowe rozwiązanie to fizyczne zdublowanie komputera (np. HITACHI-MARATON). Wszystkie elementy muszą być identyczne nie tylk z punktu widzenia statycznego (takie same procesory, pamięci czy karty rozszerzeń) ale i z punktu widzenia dynamiki pracy (taki sam czas wykonania poszczególnych zadań. Wszystkim zarządza fizyczny kontroler klastra. To on dubluje polecenia dla obu maszyn w sposób niewidoczny dla użytkownika. System operacyjny jest instalowany bliźniaczo na obu maszynach. Wszystkie polecenia użytkownika i działania systemowe są wykonywane niezależnie przez dwa identyczne komputery. Jednak na koniec fizyczny kontroler klastra odrzuca efekt działania jednego z nich (użytkownik końcowy widzi tylko jeden komputer). Awaria aktywnej maszyny powoduje rozpoczęcie wykorzystania efektów działania drugiej z nich, bez żadnego opóźnienia. Jest to klaster czysto sprzętowy, zupełnie niezależny od systemu operacyjnego (system operacyjny nawet nie wie, że nastąpiło przełączenie sprzetu). Rozwiązanie to ma wadę w postaci wysokiej ceny specjalizowanego sprzętu i jego nieefektywnym wykorzystaniu (pracują 2 komputery, a w praktyce tylko jeden jest używany). Jednak zaletą jest idealnie bezstratny model pracy (awaria komputera nie wymaga żadnych ponownych działań wynik "zastępczy" dostępny jest od razu). Ponadto awaria nie powoduje utraty mocy komputera.
Ostatni sposób, to dostępna w Windows usługa klastrowa, która umożliwia przełączanie zasobów pomiędzy kilkoma komputerami, widocznymi w sieci stale pod tą sama nazwą i adresem. Główną cechą tego typu rozwiązania jest zapewnienie maksymalnej dostępności zasobów serwera dla użytkowników końcowych. Jakkolwiek to samo zadanie nie może być wykonywane jednocześnie przez dwa różne komputery, istnieją proste sposoby na zwiększenie wydajności serwera, dzięki wykorzystaniu specyficznych cech tego typu klastra.
Klasyczny klaster pracujący pod kontrolą Windows 2000 składa się z 2 do 4 komputerów połączonych ze sobą wewnętrzną siecią heartbeat, która umożliwia kontrolę procesów sterujących zachowaniem całego klastra. Dodatkowo, specjalnie w celu wymiany i przechowywania ważnych informacji, klaster posiada wydzielony dysk zwany quorum, który poza bieżącymi informacjami zawiera historię działania maszyny. Informacje te są wykorzystywane w przypadku awarii jednego z komputerów (drugi jest w stanie na tej podstawie odtworzyć stan wyłączonej maszyny tuż przed wyłączeniem). Poszczególne fizyczne maszyny to węzły klastra, który z zewnątrz jest widziany jako jedna maszyna, posiadająca własną nazwę i adres IP, różny od poszczególnych wezłów. Każdy z węzłów jest też widoczny jako samoistny komputer. Jednak nie to stanowi o sile i możliwościach tej hybrydy.
Zanim przystąpię do opisu rozwiązania, które stanowi największą siłę w klastrach Microsoftu, skupię się na dość trudnej kwestii zasobów dyskowych. Klaster pracujący pod kontrolą Windows powinien być wyposażony we współdzielone zasoby pamięci zewnętrznej (jest to warunek konieczny możliwości utworzenia klastra). Zasoby takie (macierze dyskowe, choć nie widzę powodów, żeby ograniczać to tylko do dysków) należy skonfigurować w taki sposób, aby mogły być dostępne z obu maszyn, bez żadnych sprzętowych przełączeń (tą kwestią zajmuje się producent klastra). Cechy takie niesie ze sobą interfejs SCSI lub FiberChannel. Dyski (w praktyce ze względów bezpieczeństwa najczęściej są to macierze dyskowe problem ten rozwinę dalej) są udostępniane poszczególnym węzłom klastra na wyłączność, jednak z możliwością przewłaszczenia. To znaczy zarówno na żądanie jak i na skutek awarii dysk X: może przestać należeć do jednego węzła i stać się własnością innego. Jednoczesny dostęp dwóch różnych komputerów do tego samego zasobu w sposób niezależny jest niemożliwy. To znaczy dane zapisane przez jeden z węzłów są niewidoczne dla drugiego tak długo, dopóki jest on właścicielem dysku. Dopiero po przekazaniu dysku drugiemu węzłowi będzie on w stanie zobaczyć te dane. Oczywiście po oddzaniu praw własności drugiemu węzłowi, pierwszy przestaje widzieć dane zgromadzone na tym dysku.
Rozwiązanie bazujące na przełączaniu zasobów dyskowych zamiast współdzielenia ich wymusza sposób pracy klastra. Nie jest to rozwiązanie, które dzięki rozproszeniu pracy udostępnia zwiększenie wydajności (co jak dalej pokażę nie jest do końca prawdą), ale zapewnia maksymalną ciągłość pracy. W przypadku awarii, która wymusza wyłączenie komputera, czyli nie może być usunięta poprzez wykorzystanie nadmiarowości jego elementów, zadanie pierwszego węzła może przejąć drugi. Jeśli konfiguracja jest dokładnie taka sama (a zapewnia to usługa klastrowa) i zasoby danych są identyczne (a są, gdyż są to fizycznie te same dane przełączone do drugiego komputera), wtedy praca może być podjęta po niezwykle krótkiej (czasami niezauważalnej) przerwie, w tym samym miejscu, w którym została przerwana. Warto zwrócić uwagę, że zasoby dyskowe pozornie nie są redundantne, więc stanowią potencjalne zagrożenie dla stabilności systemu. Radą na to jest stosowanie sprzętowych macierzy RAID, które mają nadmiarową liczbę dysków i są zorganizowane w ten sposób, że awaria jednego z nich nie powoduje utraty żadnych informacji. Biorąc pod uwagę możliwość wymiany dysku w czasie pracy i podwójne kontrolery dyskowe wraz z podwójnymi magistralami od macierzy do komputera można uznać, że jest to rozwiązanie bezpieczne. Warto pamiętać, że macierze są konfigurowane najczęściej w trakcie budowy klastra, więc jego przeznaczenie powinno być przemyślane i przeanalizowane przed zakupem (do problemu tego powrócę dalej jeszcze raz).
Po ogólnym wyjaśnieniu jak działa sprzęt tworzący klaster przystąpię teraz do opisu środków wykorzystywanych w celu realizacji nieprzerwanej pracy klastra. Jak to już wcześniej zaznaczałem, klaster działający pod kontrolą Windows 2000 jest klastrem przełączeniowym, to znaczy w każdej chwili pracuje tylko część jego zasobów, a reszta nie jest wykorzystywana (ominięcie tego ograniczenia opisuję dalej). W przypadku awarii następuje wyłączenie zepsutej maszyny i podstawienie na jej miejsce drugiej. Aby po przełączeniu się maszyn były one z zewnątrz widziane dokładnie tak samo, należało zastosować rozwiązanie, które zapewniłoby utrzymywanie stałego adresu IP i nazwy komputera. Najprostszym rozwiązaniem było zastosowanie wirtualnych serwerów pracujących w systemie, w sposób niezależny od ustawień sprzętowych. Idea tego rozwiązania bazuje na wydzieleniu z systemu operacyjnego części jego zasobów i przydzieleniu tych zasobów na własność procesowi, który będzie traktowany z zewnątrz jak osobna instancja systemu operacyjnego. Oczywiście nie polega to na instalowaniu Windowsa w innym Windowsie. Jest to po prostu usługa klastrowa, która potrafi wydzielić kilkanaście typów zasobów i przyporządkować je do określonego serwera wirtualnego. Każdy taki wirtualny serwer ma swój adres i nazwę sieciową niezależne od maszyny na której pracuje i od całego klastra.
Podstawą istnienia każdego wirtualnego serwera są zasoby dyskowe. To znaczy serwery takie mogą istnieć nawet bez adresu sieciowego (co oczywiście nie ma większego sensu), ale nie mogą istnieć bez dysku. I nie może to być fragment dysku (partycja) tylko cały dysk (cały w sensie urządzenia SCSI). Tak więc projektując klaster, należy przewidzieć odpowiednią ilość zasobów dyskowych, tak by nie stanąć w pewnym momencie przed problemem niemożności utworzenia kolejnego serwera wirtualnego. W teorii liczba niezależnych dysków powinna być równa przewidywanej liczbie serwerów plus jeden na quorum. W praktyce liczba potrzebnych dysków może się okazać większa. Jeśli zamierzamy wykorzystywać wirtualny serwer jako podstawę pracy serwera SQL, wtedy warto zwiększyć liczbę dostępnych dysków. Klasyczna sugestia mówi, że dla każdego serwera SQL potrzeba przynajmniej jednego dysku typu RAID5 na dane i jednego typu RAID10 na logi. Jeśli serwer jest bardzo obciążony (a z reguły właśnie takie są instalowane na klastrach) wtedy dane możemy umieścić na większej liczbie dysków (logi mogą pozostać na jednym). Tak więc w zależności od planowanego przeznaczenia konfigaracja macierzy dyskowej może być bardzo rozbudowana.
Poza dyskami wszystkie pozostałe zasoby mogą być dzielone między wirtualnymi serwerami w sposób dynamiczny. To znaczy kilka serwerów może korzystać z tej samej karty sieciowej, procesora czy pamięci operacyjnej. Oczywiście zasoby te są odpowiednio dzielone, ale podział ten może następować poprzez zmianę parametrów w systemie operacyjnym (nie trzeba w tym celu zmieniać konfiguracji sprzętowej). Jeśli na przykład na jednej fizycznej maszynie pracują dwa serwery wirtualne, które służą za środowisko pracy różnych programów (o zmiennym obciążeniu procesora), wtedy w zależności od potrzeb procesor jest wykorzystywany naprzemiennie przez różne serwery (tak jak to się dzieje w przypadku zwykłych programów). Podobnie jest z zasobami pamięci czy dostępem do sieci, choć izolacja między serwerami wirtualnymi jest większa, niż pomiędzy zwykłymi programami pracującymi w obrębie standardowego systemu operacyjnego.
Wiemy już jakie elementy systemowe są używane do zapewnienia nieprzerwanej pracy. Teraz pozostaje wyjaśnić sposób działania, który zapewni jak największą dostępność zasobów serwera. Wyobraźmy sobie klaster, na którym posadowiono jeden serwer wirtualny, a na serwerze tym zainstalowano serwer SQL. Dopóki fizyczna maszyna, na której właśnie pracuje ten serwer (a przez to i SQL) sprawuje się dobrze, nic się nie dzieje. W przypadku jakiejś nieprzewidzianej awarii i przerwy w pracy następuje przerzucenie wirtualnego serwera z jednej maszyny na drugą. Jeśli przełączenie jest przez system przewidziane, wtedy następuje zatrzymanie pracy serwera na jednej maszynie i podjęcie jej na drugim węźle. Gdy pierwszy węzeł psuje się bez ostrzeżenia, wtedy przełączenie trwa trochę dłużej. Po pierwsze drugi węzeł klastra musi zauważyć, że ten pierwszy przestał pracować. Dopiero kiedy to się stanie, usiłuje odtworzyć ostatni stan serwera wirtualnego i ruszyć z pracą dokładnie w tym samym miejscu na drugiej maszynie. Wydłużenie czasu przełączania wynika z konieczności wykrycia fizycznej awarii maszyny i odtwarzania ostatniego stanu pracy. Wszystkie dane, zarówno w czasie planowanego jak i nieplanowanego przełączenia, są pamiętane na wydzielonym w tym celu dysku quorum. Nawet jeśli przełączenie wyniknęło z awarii, czas przez który serwer nie jest widoczny (przestał pracować na jednym komputerze, a nie zaczął jeszcze pracy na drugim) nie jest wiekszy niż kilka sekund. Uznaje się, że dobre serwery klastrowe mają zawodność znacznie poniżej 5 minut w roku, czyli pracują przez ponad 99.999% czasu.
Wróćmy jednak do przełączenia serwera z jednej maszyny na drugą. Jeśli aplikacje korzystające z serwera pracującego na klastrze są odpowiednio napisane, użytkownik końcowy nie jest w stanie zauważyć, że coś się stało. Dla aplikacji klienckiej różnica powinna być jedynie taka, że wynik, który standardowo pokazywał się na ekranie po sekundzie, teraz wyjątkowo pokazał się po kilku sekundach (jeśli pytanie było zadane akurat w chwili przełączania). Użytkownik tej aplikacji nie ma żadnej świadomości o tym, że nastąpiło przełączenie serwera (na przykład SQLowego) z jednej maszyny na drugą. Taka sytuacja jest bardzo korzystna w przypadku instytucji czy firm wymagających pracy bez żadnych przerw (zarówno banków jak i firm handlowych, czy stosujących zaawansowane aplikacje sterujące procesami produkcyjnymi).
Należy jednak zwrócić uwagę na kilka niebezpieczeństw czających się w Microsoftowym sposobie podejścia do niezawodności pracy. Otóż bazowanie niezawodności całego klastra na infrastrukturze sieciowej wymaga bardzo dużej niezawodności tej infrastruktury. Mowa tu zarówno o sprzęcie (trzy karty sieciowe w każdym węźle klastra nie są niczym dziwnym) jak i o serwerze domenowym. Utrata nazwy domenowej serwera wirtualnego może zakończyć się przeniesieniem tego serwera na drugi węzeł klastra, mimo tego, że żadna awaria sprzętu nie nastąpiła. Problemy mogą się też pojawić jako skutek działania programów, które nie do końca zostały przystosowane do pracy w trybie wirtualnym. Generalnie każdą aplikację można uruchomić na serwerze wirtualnym (chyba, że specjalnie została napisana w taki sposób, aby to uniemożliwić). Jednak niektóre zachowania mogą wprowadzać dodatkowe problemy. Na przykład MSSQL 2000, jakkolwiek w wersji Enterprise dość dobrze dostosowany do pracy klastrowej, w czasie przełączania przerywa wykonywanie procedur składowanych i już nie podejmuje ich dokańczania. Podobnie dzieje się z aplikacjami serwerowymi, które tracą połączenie w skutek przełączenia. Przykładem niech będą aplikacje, które ustanawiają komunikację klient-serwer korzystając z innego portu TCP/IP, niż później odbywaja standardową pracę. W takim przypadku po przełączeniu serwer czeka na nawiązanie nowych połączeń, a klienci oczekują, że serwer odpowie na wcześniej zainicjowane połączenia. Oczywiście problemy te nie są problemami dostępności serwera, lecz wynikają ze złej konstrukcji programów (nieprzystosowania ich do warunków pracy).
Opisując sposób działania klastra kilkukrotnie wpominałem, że rozwiązanie Microsoftu w założeniu nie służy do podziału obciążenia na większą liczbę komputerów. Jeśli pozostaniemy w obrębie przykładowego SQL serwera, nie występuje sytuacja, że część pracy wykonywana jest na jednym komputerze, a część na drugim. Jeśli uruchamiamy na przykład procedurę składowaną, wtedy wykona się ona na tylko jednym fizycznym komputerze. Mimo to można zaprojektować klaster, wraz z jego funkcjonalnością w taki sposób, aby w pewien sposób rozłożyć pracę na 2 komputery (lub więcej, jeśli klaster składa się z większej liczby węzłów). Wymaga to czasami zmian w podejściu do sposobu realizacji zaplanowanych celów. Najczęściej zmiany takie wpływaja pozytywnie na pracę firmy nie tylko ze względu na możliwość równoległego przetważania danych, ale i lepszą ich organizację. Dalsze rozważania na temat efektywnego wykorzystania zasobów klastrów będą dotyczyły rozwiązania z 2 maszynami, lecz bez trudu można je rozszerzyć do 4 węzłów.
Klasyczne rozwiązanie (naturalne przy pierwszym kontakcie z klastrem) przewiduje pracę serwera w trybie active-pasive. Oznacza to, że jeden z komputerów fizycznych obsługuje jeden serwer wirtualny. Drugi pracuje w stanie gotowości, bez żadnego obciążenia. Ma on za zadanie przejąć ewentualne obciążenie w przypadku awarii pierwszej maszyny. W takim układzie jedna z maszyn jest całkowicie niewykorzystana. Pozornie rozwiązanie takie jest bardzo dobre, gdyż praca na "biegu jałowym" zapewnia możliwość natychmiastowego przejęcia obciążenia. Oczywiście jest to tylko pozorne, gdyż całe obciążenie musi zostać przeniesione z jednej maszyny na drugą. Gdyby praca podzielona była na 2 komputery, wtedy ewentualna awaria dotyczyłaby tylko części zasobów. Ponadto w przypadku awarii przeniesienie obciążęnia na drugą maszynę nie musi dotyczyć wszystkich procesów (część z nich pracuje bezawaryjnie właśnie na tej drugiej maszynie). Opisane rozwiązanie legło u podstaw pracy w architekturze active-active. W trybie tym na klastrze instaluje się 2 niezależne serwery wirtualne. Jedną z cech wirtualnego serwera jest domyślna fizyczna maszyna, na której pracuje ten serwer (oczywiście, jeśli jest to możliwe, czyli maszyna ta jest sprawna). Parametry te ustawiamy tak, aby w trakcie standardowej pracy serwery wirtualne pracowały na różnych węzłach, co zapewni rozłożenie obciążenia. W przypadku awarii jednej z maszyn następuje przełączenie i krótkotrwała praca pod zdwojonym obciążeniem (dwa serwery na jednym węźle).
Rozwiązanie takie wymaga oczywiście modyfikacji ideii korzystania z klastra. Jeśli korzystamy z niego, jako z serwera baz danych, architektura taka doskonale się sprawdza w przypadku używania różnych typów danych: zarówno on-line jak i zagregowanych. Wiele analiz (roczna sprzedaż, rentowność, wiarygodność kredytowa, itp., itd.) może być wykonywana na danych nieznacznie nieaktualnych (sprzed godziny, a często nawet z wczorajszego dnia). Można więc zorganizować pracę w następujący sposób: jeden serwer obsługuje aktualną pracę firmy, a drugi zapytania dotyczące danych historycznych. W nocy (a dokładniej wtedy, gdy obciążenie obu serwerów jest najmniejsze) następuje uaktualnianie danych drugiego serwera, najczęściej z ich wstępnym przetwarzaniem. Aktualizacja z agreagacją wykonywana jest tak, aby ułatwić i przyspieczyć tworzenie przekrojowych analiz. Oczywiście rozwiązanie takie jest przydatne tylko wtedy, gdy jesteśmy w stanie oddzielić bieżące wykorzystanie danych od działań przekrojowych. W obrębie SQL servera można wykorzystać jego składowe instalując na jednym z komputerów sam serwer bazodanowy, a na drugim z nich serwer analiz OLAP (wymaga to jednak zastosowania pewnych sztuczek, gdyż z niewiadomych powodów Microsoft nie przewidział w swoim pakiecie takiego oczywistego rozwiązania). Można też próbować podzielić serwer ze względu na strukturę organizacyjną bądź lokalizacyjną. Jeden z serwerów przeznaczyć na przykład do obsługi centrali, a drugi na oddziały regionalne. Jeśli i taki podział jest niemożliwy należy wykorzystać drugi serwer do pracy z innym programem, na przykład do zarządzania pocztą, czy innym obciążającym zasoby procesem.
Wedłu moich doświadczeń trudno znaleźć firmę, w której nie da się zastosować podziału zasobów serwera w taki sposób, aby architektura active-active była niemożliwa do zastosowania. Zdarzają się jednak takie przypadki, gdy klaster jest instalowany w już istniejących warunkach, z trudno modyfikowalnym oprogramowaniem specjalizowanym bądź niszowym. Takie przypadki powinno się zauważyć na etapie projektowania klastra. Rozwiązaniem, które uchroni przyszłego użytkownika klastra przed nieefektywnym wydawaniem pieniędzy, jest niesymetryczna architektura active-passive. Jeśli zasobów nie da się podzielić na dwa jednocześnie pracujące serwery wirtualne, można się zdecydować na klaster niesymetryczny. Jeden węzeł, ten który będzie domyślnie komputerem aktywnym, powinien być maszyną znacznie silniejszą od komputera "zapasowego", który przez większość swojego życia będzie tylko czekał na krótkotrwałe obsłużenie ewentualnej awarii. Niesymetryczne rozwiązanie pozwoli nam zaoszczędzić przynajmniej 20 procent kosztów, co przy cenie klastra nie jest małą sumą. Alternatywnym efektem (jeśli firmie nie zależy tak bardzo na oszczędnościach) może być podniesienie wydajności głównej maszyny. Zamiast kupować 2 serwery czteroprocesorowe można kupić jeden ośmiorocesorowy i drugi czteroprocesorowy, ale o niższej wydajności (niższa szybkość, mniej pamięci).
Na niesymetrycznym klastrze active-passive instalujemy tylko jeden serwer wirtualny. W czasie standardowej pracy funkcjonuje on na silniejszej maszynie. Po awarii zostaje przeniesiony na słabszy węzeł i działa tam aż do usunięcia przyczyny wyłączenia komputera głównego. Przy takim rozwiązaniu, już na etapie zakupu serwera, należy zadbać o właściwą ochronę gwarancyjną. W przypadku serwerów symetrycznych przełączenie między poszczególnymi węzłami nie wiąże się z żadnym niebezpieczeństwem spowolnienia pracy. Klaster niesymetryczny po przełączeniu się na komputer zapasowy może spowolnić pracę firmy. Należy więc zadbać, aby spowolnienie takie trwało jak najkrócej.
Poza zaproponowanymi, najciekawszymi według mnie, rozwiązaniami można oczywiście stosować inne, bardziej lub mniej klasyczne. Najczęściej doświadczenie z klastrami rozpoczyna się od symetrycznej architektury active-passive, czyli symetryczny klaster z jednym serwerem wirtualnym. Rozwiązanie takie może być przejściowe do momentu przejścia na architekturę active-active. Należy jednak pamiętać, aby przewidzieć odpowiednią konfigurację macierzy dyskowej, umożliwiające w przyszłości taką migrację. Inne, bardziej zaawansowane rozwiązanie to niesymetryczna architektura active-active, czyli dwa serwery wirtualne domyślnie pracujące na różnych maszynach (ten bardziej obciążony na silniejszym węźle). Bardzo rzadko stosuje się też rozwiązanie passive-passive, w zasadzie tylko w przypadku budowy klastra z klastrów. Jest to jednak wyższa szkoła jazdy i pominę opis tego rozwiązania. Oficjalna literatura sugeruje też możliwość pracy hybrydowej. Klaster jest tam wykorzystywany na 2 sposoby. Standardowo pracują na nim serwery wirtualne. Dodatkowo węzły klastra są używane jako zwykłe pojedyncze serwery (pełniąc rolę na przykład print serwerów czy serwerów DNS). Jakkolwiek oficjalna literatura podaje takie rozwiązanie jako możliwe osobiście uważam je za nie najlepsze. Usługę klastrową można zastosować też dla pojedynczego komputera, wyłącznie w celu uruchomienia serwerów wirtualnych. Umożliwia to na przykład przeniesienie zasobów kilku rzeczywistych serwerów na kilka wirtualne, a jeden rzeczywisty. Rozwiązanie takie zapewnia w pewien sposób wzrost efektywności, który wynika z faktu, że obciążenie różnych komputerów niemal zawsze jest nierównoczesne. Zgromadzenie zasobów czterech jednakowych komputerów w jednym, który jest tylko 3 razy silniejszy niemal zawsze powoduje zwiększenie wydajności każdego z nich. Jest to rozwiązanie dość ciekawe ze względu na efektywność wykorzystania sprzętu, ale nie mające z niezawodnością nic wspólnego.
W dzisiejszym artykule starałem się przekazać czytelnikom podstawową wiedzę na temat podnoszenia niezawodności pracy z wykorzystaniem klastrów tworzonych z użyciem Windows 2000. Z konieczności jest to wiedza bardzo ogólna. Same materiały szkoleniowe Microsoftu na ten temat to kilkaset stron dokumentacji. Wiele też można dowiedzieć się z artykułów technicznych niezależnych ekspertów. Jednak prawdziwą wiedzę na temat możliwości i przydatności klastra można zdobyć najwcześniej po kilku miesiącach rzeczywistej pracy. Kupując klaster warto więc zostawić sobie furtkę w postaci możliwości wymiany bądź rozbudowy klastra w ciągu pewnego okresu od daty zakupu. Biorąc pod uwage cenę klastra warto też poświęcić trochą czasu i pieniędzy na analizę przeprowadzoną przez niezależnych ekspertów. Mimo trudnych początków warto jednak pamiętać, że efektem końcowym jest podniesienie niezawodności pracy firmy, co niemal zawsze przekłada się na finansowe zyski.