Szybkie odcinanie kopii

W każdej serwerowni jest również zainstalowana biblioteka taśmowa IBM Ultrium 3583, wyposażona w 5 napędów i 72 taśmy o pojemności 100 GB każda (biblioteka może zapisać łącznie ok. 7 TB danych). Jest ona podłączona bezpośrednio do przełącznika FC, dzięki czemu serwer pośredniczy jedynie w nadzorowaniu procesu archiwizacji danych, a transmisja danych odbywa się bezpośrednio między macierzą Shark a biblioteką Ultrium.

Jednym z atutów zastosowania macierzy IBM Shark jest znaczące skrócenie czasu przestojów niezbędnych do wykonania kopii bezpieczeństwa danych. "Obecnie wykorzystujemy mechanizm Flash Copy dostępny w macierzy IBM. Umożliwia on wykonanie na wolnej powierzchni macierzy dokładnej kopii produkcyjnych danych z koniecznością tylko kilkuminutowego przerwania pracy aplikacji Zorba. Chociaż każda z instancji zajmuje średnio 60 GB, to wykonanie pełnej kopii tych danych w ramach macierzy trwa zaledwie około dwóch minut. Dopiero tak wykonane kopie są kopiowane na taśmy" - mówi Michał Rudek. Wcześniej proces wykonywania kopii bezpieczeństwa wymagał zatrzymania pracy aplikacji Zorba na kilka godzin. Obecnie, dzięki możliwości wykorzystania mechanizmu FlashCopy, procesy przetwarzania zamknięcia dnia księgowego i wykonywania kopii mogą być wykonane równolegle.

A w przypadku awarii...

Możliwości zbudowanego w PKO BP systemu wysokiej dostępności ujawniają się dopiero w razie wystąpienia awarii jednego lub kilku elementów ośrodków przetwarzania. W najprostszym przypadku, gdy awarii ulega jeden z serwerów pracujących w klastrze, jego zadania przejmuje serwer zapasowy. "Na tym jednak nie kończą się możliwości pojedynczego klastra. Każdy serwer jest bowiem skonfigurowany w taki sposób, że może obsługiwać dwie instancje Zorby 3000" - twierdzi Michał Rudek. Oznacza to, że nawet gdy padnie drugi i trzeci serwer w ramach tego samego klastra, nadal możliwa jest obsługa w trybie awaryjnym pięciu instancji aplikacji Zorba (po dwie na dwóch serwerach i jedna na serwerze zapasowym). Ze względu na to, że wszystkie dane niezbędne do pracy aplikacji są przechowywane na macierzy - dostęp do nich odbywa się w niezakłócony sposób bez względu na to, który serwer ulega awarii i który przejmuje jego obowiązki.

Klaster jest całkowicie niezdolny do pracy dopiero wtedy, gdy uszkodzeniu ulegną cztery z sześciu wchodzących w jego skład serwerów. W takim przypadku pięć instancji aplikacji Zorba jest przenoszonych na serwery drugiego klastra, gdzie działają one równolegle z podstawowymi instancjami systemu bankowego (po dwie na jednym serwerze). Za przełączanie aplikacji między serwerami odpowiedzialne jest oprogramowanie HACMP (High Availability Cluster Multi-Processing), które automatycznie podejmuje decyzję o przeniesieniu funkcjonalności aplikacji wg przygotowanych wcześniej przez administratorów scenariuszy. Nie wszystkie rodzaje awarii są jednak obsługiwane automatycznie. "Decyzję o całkowitym przełączeniu przetwarzania do drugiego z ośrodków w przypadku stwierdzenia awarii całego klastra każdorazowo podejmuje administrator. Po naprawieniu klastra przywrócenie pierwotnego sposobu pracy również jest realizowane ręcznie - podczas nocnej obsługi systemu, aby nie powodować kolejnych przerw w pracy oddziałów" - mówi Michał Rudek.

Nie każda awaria sprzętowa wymaga przełączenia serwerów. Uszkodzenie karty sieciowej lub karty Fibre Channel powoduje jedynie automatyczną rekonfigurację serwera - oprogramowanie HACMP przełącza adresy IP między kartami, a w razie konieczności również między serwerami (dotyczy to również adresu MAC karty).

Nieprzewidziane komplikacje

Wdrożenie scentralizowanego systemu wysokiej dostępności trwało pół roku. "Narzuciliśmy sobie i dostawcom bardzo rygorystyczny harmonogram. Do czerwca 2001 r. zakończyliś-my fazę projektową, w połowie lipca rozpoczęło się wdrożenie, a pod koniec września z nowego rozwiązania korzystał pierwszy oddział banku" - wyjaśnia Michał Rudek.

Mimo szczegółowego rozpisania terminarza poszczególnych etapów projektu, nie udało się uniknąć komplikacji. Chociaż na przeprowadzenie testów zaplanowano tydzień, to nie przewidziano, że trzeba zarezerwować czas na usuwanie wykrytych usterek. "Pracownicy IBM dosyć wiernie symulowali rzeczywiste awarie wyrywając kable z maszyn, dyski twarde z macierzy i analizując, w jaki sposób wpływa to na pracę systemu" - mówi Michał Rudek.

Problemy spowodowała również podstawowa aplikacja wykorzystywana w banku. "Zorba nie jest aplikacją transakcyjną i nie daje się łatwo przenieść do środowiska klastrowe-go. Chociaż zasoby Zorby mogą być przełączane z wykorzystaniem HACMP, to konieczne jest ręczne przywrócenie integralności danych" - stwierdza Michał Rudek. Mimo trudności, udało się zrealizować podstawowe wymagania stawiane systemowi: skrócić czas przetwarzania i uprościć administrowanie. Obecnie za zarządzanie serwerami odpowiedzialnych jest kilku informatyków.