Co najmniej kilka setek dużych podmiotów w Polsce wciąż korzysta ze starych wersji Tivoli Storage Manager, flagowego systemu backupowego IBM. Klienci trwają przy nich pomimo tego, że dawno już utraciły wsparcie techniczne producenta. Powód jest prosty: w dziedzinie ochrony danych stare znaczy sprawdzone, niezawodne. Istnieje jednak cały szereg innych powodów, dla których korzyści z trwania przy starszych wersjach schodzą na dalszy plan. Najważniejszy z nich to ten, że systemy backupu przestały już być wyspami funkcjonującymi w odrębnej czasoprzestrzeni techniczno-inżynierskiej, stając się elementem procesów biznesowych. To nie systemy backupowe mają być niezawodne, jeśli można tak powiedzieć, a przede wszystkim procesy, które systemy te zabezpieczają. Nowe wersje TSM adresują te potrzeby w sposób, który dla poprzednich wersji jest nieosiągalny, umożliwiając także redukcję kosztów operacyjnych w obszarze backupu, oraz w kilku innych obszarach IT. Niezależnie od tego, ochrona danych i ciągłość procesów jest obecnie przedmiotem żywego zainteresowania regulatorów branżowych, co nadaje sprawie migracji starszych wersji TSM zupełnie nowego wymiaru.

W świadomości młodego pokolenia Tivoli Storage Manager, w skrócie TSM, to produkt istniejący od zawsze. Tak naprawdę, TSM jest ich rówieśnikiem. Jak wielu z nich, TSM ma dopiero 27 lat i wszystko co najlepsze dopiero przed nim. TSM jest dziś jednym z najbardziej dojrzałych rozwiązań backupowych o bardzo bogatych możliwościach, ale zaczęło się to wszystko całkiem skromnie. W 1988 r. w centrum badawczym IBM w San Jose rozpoczął się projekt, którego celem było stworzenie rozwiązania do ochrony danych dla platform mainframe VM/CMS TSM. Efektem pracy był system kopiujący dane ze stacji roboczych działających pod kontrolą systemów DOS, OS/2 i AIX na serwery VM/CMS, a później VMS, znany jako WSDF – Workstation Data Save Facility. Z biegiem czasu nazwę zmieniono na ADSTAR Distributed Storage Manager. Obecna nazwa obowiązuje od 1999 r.

Zmiana lubi boleć

Ponieważ IBM był w Polsce obecny zanim jeszcze zaczęła się zmiana ustrojowa, w kraju działa obecnie bardzo wiele środowisk Tivoli Storage Manager. TSM jest szczególnie popularny w sektorze publicznym, dużym przemyśle, oraz w bankowości, a więc tam, gdzie utrata danych na dużą skalę po prostu nie wchodzi w grę. Przez lata TSM dał się poznać jako produkt bardzo solidny, niezawodny, potrafiący dużo więcej, niż produkty konkurencyjne, w tym zwłaszcza jeśli szło o wydajność i obsługę wielu platform. Przyzwyczajenie jest drugą naturą człowieka i wielu administratorów zrosło się ze swoim TSM-em do tego stopnia, że nie wyobrażają sobie wykonywania swoich codziennych obowiązków bez niego.

Jedną z ulubionych przez administratorów funkcji starszych wersji TSM jest wbudowane środowisko gromadzące dane o zdarzeniach i generujące raporty. IBM już dawno temu dopracował swój produkt do tego stopnia, że predefiniowane raporty były przez TSM automatycznie wysyłane na skrzynki pocztowe administratorów. Dzięki temu, podczas czas porannej kawy administrator może uruchomić lub naprawić to, czego nie udało się wykonać w nocy w trybie automatycznym. Pełny przegląd stanu procesów backupowych i środowiska w dowolnym przekroju, dokładnie tak, jak trzeba. Ta idylla trwała do wersji 5.5. W kolejnej „dużej” wersji TSM, czyli 6.1, pojawiło się bardzo wiele zmian, a jedna z nich polegała na zastąpieniu dotychczasowego mechanizmu raportowego platformą Tivoli Monitoring for TSM.

Część klientów zdecydowała się odłożyć migrację z powodu przyzwyczajeń. Inni uznali, że zmiany są na tyle duże, że warto być może poczekać, aż nowa wersja ustabilizuje się. Jeszcze inni stwierdzili, że ponieważ nowa wersja jest z ich perspektywy rewolucją, być może będą poszukiwać innych opcji. Z mojego rozeznania wynika, że w znakomitej większości przypadków skończyło się na słowach, kto bowiem posiada duże środowisko IBM i zna możliwości TSM, nie będzie rezygnował z tego systemu dla zasady. To prawda, że zmiany technologiczne w stosunku do wersji 5.x są w wersjach 6.x duże, i że w związku z tym migracja jestprzedsięwzięciem większego kalibru. Wypada jednak zauważyć, że oprócz wyzwań i kosztów, migracja do 6.x niesie także długą listę usprawnień i oszczędności w różnych obszarach IT, a nawet biznesowych.

„Część klientów zdecydowała się odłożyć migrację z powodu przyzwyczajeń. Inni uznali, że zmiany są na tyle duże, że warto być może poczekać, aż nowa wersja ustabilizuje się. Jeszcze inni stwierdzili, że ponieważ nowa wersja jest z ich perspektywy rewolucją, być może będą poszukiwać innych opcji. (…) To prawda, że zmiany technologiczne w stosunku do wersji 5.x są w wersjach 6.x duże, i że w związku z tym migracja jest przedsięwzięciem większego kalibru. Wypada jednak zauważyć, że oprócz wyzwań i kosztów, migracja do 6.x niesie także długą listę usprawnień i oszczędności w różnych obszarach IT, a nawet biznesowych”

Kluczowa zmiana: baza

Z technologicznego punktu widzenia, główną zmianą w TSM 6.x wcale nie jest Tivoli Monitoring, a zastąpienie oryginalnej, specyficznej dla TSM bazy danych serwera backupowego w pełni standardową bazą danych DB2. Oprócz otwartości oznacza to dużo większą skalowalność całego środowiska backupowego. Aby to zilustrować, wystarczy jedna liczba: baza metadanych TSM w wersji 5.x może mieć pojemność do 530 GB – i ani bajta więcej. TSM 6.x i wyższe nie mają pod tym względem ograniczeń. Gdyby jednak tylko to chodziło…

Dużo poważniejszy problem to fakt, że wszelkie poważniejsze operacje na „starej” bazie wymagają częstego sprawdzania jej spójności wewnętrznej, co nie trwa dwie minuty i wymaga wyłączenia serwera backupowego z normalnej pracy. Być może 10 lat temu można było pójść na taki kompromis, ale dzisiaj? DB2 w TSM 6.x i wyższych zarządza się sama, (spójność, wydajność), a audyty można wykonywać w dowolnym momencie, bez wpływu na normalne działanie systemu. Dodać wypada jeszcze, choć to może i oczywiste, że DB2 daje pełną przejrzystość i łatwość zarządzania dzięki temu, że wspiera SQL. Większa łatwość zarządzania? Niższe koszty utrzymania? Tak, zdecydowanie tak.

„Z technologicznego punktu widzenia, główną zmianą w TSM 6.x wcale nie jest Tivoli Monitoring, a zastąpienie oryginalnej, specyficznej dla TSM bazy danych serwera backupowego w pełni standardową bazą danych DB2. Oprócz otwartości oznacza to dużo większą skalowalność całego środowiska backupowego. (…) wszelkie poważniejsze operacje na „starej” bazie wymagają częstego sprawdzania jej spójności wewnętrznej, co nie trwa dwie minuty i wymaga wyłączenia serwera backupowego z normalnej pracy. Być może 10 lat temu można było pójść na taki kompromis, ale dzisiaj?”

Proces migracji danych i metadanych systemu TSM z wersji 5.x do 6.x wymaga planowania i ścisłego trzymania się wytycznych dla poszczególnych platform. Czym jednak różni się to od każdej innej migracji? Trzeba przy okazji oddać IBM-owi, że umożliwia migrację w sposób cywilizowany, tj. istnieje możliwość migracji samej bazy TSM, bez migracji klientów z 5.x do 6.x. Takie etapowe podejście pozwala ograniczyć ryzyko całej operacji i zdecydowanie ułatwia jej przeprowadzenie. Podniesienie wersji z 5.x do 7.x, nawet samej bazy, nie jest jednak możliwe. Po drodze trzeba „przejść” przez pełną migrację do 6.x, ponieważ klienci 7.x nie „dogadają się” już z bazą 5.x.

Backup to nie wszystko

Dla tych, którzy wątek Tivoli Monitoring for TSM uważają za pierwszoplanowy mam dobrą wiadomość: można tę platformę skonfigurować tak, by raporty, jak w wersji 5.x, trafiały co rano do skrzynki pocztowej. Wymaga to może nieco więcej pracy, ale efekt ostateczny jest bardzo zbliżony. TM for TSM potrafi być przyjacielem administratora na wiele więcej sposobów, niż narzędzia raportowe TSM 5.x. Przede wszystkim dlatego, że Tivoli Monitoring można łatwo rozszerzyć w taki sposób, by objąć nim nie tylko system backupowy, ale całe środowisko IBM, a nawet całe środowisko informatyczne. Z takiej perspektywy cała zmiana i związany z nią wysiłek zaczyna nabierać głębszego sensu. Już pierwsza z brzegu awaria pokaże, że warto.

Od backupu do monitorowania całego środowiska

Migracja Tivoli Storage Manager z wersji 5.x do wersji 6.x i wyższych pozwala wykorzystać dostarczany wraz z systemem backupowym system monitorowania Tivoli Monitoring for TSM do budowy kompleksowego środowiska monitorującego już nie tylko backup, ale wszystkie składniki środowiska aplikacyjnego. Oto przykładowe rozszerzenia Tivoli Monitoring (lista nie jest wyczerpująca):

Monitoring Agent for DB2
Monitoring Agent for HTTP Server
Monitoring Agent for JBoss
Monitoring Agent for Linux KVM
Monitoring Agent for Linux OS
Monitoring Agent for Microsoft Exchange Server
Monitoring Agent for Microsoft Hyper-V Server
Monitoring Agent for Microsoft Internet Information Services
Monitoring Agent for Microsoft .NET
Monitoring Agent for Microsoft SQL Server
Monitoring Agent for MongoDB
Monitoring Agent for MySQL
Monitoring Agent for Node.js
Monitoring Agent for Oracle Database
Monitoring Agent for PHP
Monitoring Agent for PostgreSQL
Monitoring Agent for Python
Monitoring Agent for Ruby
Monitoring Agent for Tomcat
Monitoring Agent for UNIX OS
Monitoring Agent for VMware VI
Monitoring Agent for WebSphere Applications
Monitoring Agent for WebSphere Infrastructure Manager
Monitoring Agent for Windows OS
Response Time Monitoring Agent

Należy do nich dodać wtyczki umożliwiające zarządzanie serwerami, sieciami Ethernet i SAN oraz wieloma innymi platformami.

Większość rozwiązań IBM dostarczanych jest z licencją na oprogramowanie klienckie systemu Tivoli Monitoring. Nie tylko zresztą IBM – wtyczki dostępne są dla wielu technologii i platform aplikacyjnych, platform bazodanowych, systemów operacyjnych, środowisk wirtualnych, systemów sieciowych, macierzy dyskowych, bibliotek taśmowych praz serwerów wielu producentów (patrz ramka). Nie ma potrzeby zastanawiać się, gdzie wystąpił problem – raport z Tivoli Monitoring pokaże to czarno na białym. Mając do dyspozycji narzędzie, które „widzi” całą infrastrukturę, administratorzy mogą skupić się na rozwiązywaniu problemów, a nie na próbach ich diagnozowania. To zupełnie inny komfort pracy dla IT, a korzysta cała firma – szybsze i pewniejsze rozwiązywanie problemów jednoznacznie przekłada się na pieniądze. Uzasadnienie takiego projektu i wykazanie zwrotu z niego nie stanowi problemu.

„Dla tych, którzy wątek Tivoli Monitoring for TSM uważają za pierwszoplanowy mam dobrą wiadomość: można tę platformę skonfigurować tak, by raporty, jak w wersji 5.x, trafiały co rano do skrzynki pocztowej. Wymaga to może nieco więcej pracy, ale efekt ostateczny jest bardzo zbliżony. TM for TSM potrafi być przyjacielem administratora na wiele więcej sposobów, niż narzędzia raportowe TSM 5.x. Przede wszystkim dlatego, że Tivoli Monitoring można łatwo rozszerzyć w taki sposób, by objąć nim nie tylko system backupowy, ale całe środowisko IBM, a nawet całe środowisko informatyczne. Z takiej perspektywy cała zmiana i związany z nią wysiłek zaczyna nabierać głębszego sensu”

Od wersji 6.3 Tivoli Monitoring for TSM może znacznie więcej, ponieważ jako standardowe środowisko do projektowania i generowania raportów wykorzystuje narzędzia Cognos w miejsce dotychczasowych narzędzi Eclipse BIRT. Wizualnie Cognos nie jest atrakcyjniejszy niż BIRT, ale jego „wnętrzności” potrafią znacznie więcej. Cognos pozwala na przykład łatwo tworzyć analizy typu „a co by było, gdyby”, jak również prognozować i szacować. Odpowiednio nakarmiony danymi źródłowymi i podłączony do podsystemu alertów Tivoli Monitoring Cognos pomaga w porę zapobiec zapełnieniu woluminów w macierzy, wskazuje potrzebę przyjrzenia się interfejsowi Fibre Channel, albo przekonfigurowania klienta TSM w celu poprawy wydajności. Doświadczenie administratora w połączeniu z możliwościami Cognos’a przynosi bardzo dobre rezultaty – nie tylko dla IT, ale także dla biznesu.

Szersze spojrzenie

Migracja starej wersji TSM do nowszej może wyglądać jak poważny projekt, ale da się to zrobić całkiem grzecznie i bezpiecznie, małymi krokami. Chciałabym jeszcze raz podkreślić, że taki projekt wykracza daleko poza samo IT, choćby z tego względu, że znacznie skraca czas diagnozowania i usuwania problemów mających bezpośredni wpływ na ciągłość biznesu, a także na koszty operacyjne w wielu wymiarach. Po co bowiem płacić za kilka rozwiązań wykonujących odrębnie od siebie te same czynności, skoro można mieć jedno rozwiązanie obejmujące większość istotnych biznesowo systemów? Objęcie monitorowaniem całej infrastruktury IBM to już nie tylko oszczędności, ale zmiana modelu funkcjonowania IT.

„Migracja starej wersji TSM do nowszej może wyglądać jak poważny projekt, ale da się to zrobić całkiem grzecznie i bezpiecznie, małymi krokami. Chciałabym jeszcze raz podkreślić, że taki projekt wykracza daleko poza samo IT, choćby z tego względu, że znacznie skraca czas diagnozowania i usuwania problemów mających bezpośredni wpływ na ciągłość biznesu, a także na koszty operacyjne w wielu wymiarach. Po co bowiem płacić za kilka rozwiązań wykonujących odrębnie od siebie te same czynności, skoro można mieć jedno rozwiązanie obejmujące większość istotnych biznesowo systemów? Objęcie monitorowaniem całej infrastruktury IBM to już nie tylko oszczędności, ale zmiana modelu funkcjonowania IT”

Scentralizowane monitorowanie całej infrastruktury środowisk aplikacyjnych wiąże się także bezpośrednio z zaostrzeniem regulacji dotyczących ryzyka w sektorze bankowym, a ostatnio także ubezpieczeniowym. Komisja Nadzoru Finansowego oczekuje od podmiotów działających w tych branżach, że ryzyko operacyjne w obszarach informatycznych będzie traktowane poważnie, nie tylko w sensie proceduralnym, ale także operacyjnym i technologicznym. Posiadanie procedur a ich sprawne wykonywanie to dwie różne rzeczy. Chodzi oczywiście o znowelizowaną Rekomendację D w bankowości oraz wytyczne dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w zakładach ubezpieczeń i zakładach reasekuracji.

Równolegle znaczenia nabierają formalne i nieformalne inicjatywy mające na celu podniesienie niezawodności infrastruktury krytycznej państwa. Współczesna gospodarka jest coraz silniej zależna od sprawnego przepływu informacji. Lista podmiotów, które zarządzają infrastrukturą fizyczną bądź informatyczną, którą można uznać za infrastrukturę o krytycznym znaczeniu dla państwa, stale się wydłuża. Wiele z nich użytkuje duże środowiska informatyczne oparte na systemach IBM, którym backup zapewnia Tivoli Storage Manager w starej lub bardzo starej wersji. Zamiast patrzyć na migrację jako na problem, być może czas dostrzec w niej szanse na pozbycie się problemów znacznie poważniejszych, niż backup.

Całe środowisko backupowe w jednym serwerze IBM POWER

Migracja starej wersji TSM do nowej to dobra okazja do przemyślenia architektury środowiska sprzętowego systemu backupowego pod kątem wydajności. Całe środowisko backupowe, tj. serwer backupowy, jego bazę danych, portal Tivoli Monitoring for TSM oraz dodatkowe narzędzia można obecnie umieścić w jednym serwerze fizycznym, dla każdego z nich wydzielając partycję logiczną (LPAR) na platformie serwerowej z procesorami IBM POWER. Taka architektura ma kilka zalet. Umieszczenie wszystkich elementów systemu w jednym serwerze znacznie przyspiesza jego działanie – poszczególne elementy środowiska komunikują się w pamięci RAM tego samego urządzenia, co zmniejsza opóźnienia operacji I/O i zapewnia zasadniczo większe pasmo dla danych. Po drugie, oznacza to szybsze przygotowanie danych do zapisania na taśmach dzięki wydajniejszemu procesowi deduplikacji, po trzecie zaś – z tych samych powodów – skraca czas odtwarzania danych po awarii. Oprócz tego, takie podejście pozwala zmniejszyć koszty wsparcia technicznego, oraz koszty wysokiej dostępności systemu backupowego. Nawet w przypadku niezbyt dużego środowiska TSM oznacza to sumarycznie bardzo konkretne oszczędności. Nie mogę posłużyć się konkretnymi danymi z uwagi na porozumienia o poufności. Mogę powiedzieć jedynie, że klientom podoba się koncepcja konsolidacji backupu na jednym serwerze. Moc obliczeniowa najnowszych serwerów z procesorami POWER jest tak duża, że do budowy skonsolidowanego środowiska backupowego wystarczy relatywnie prosty serwer, np. zaprezentowany powyżej IBM S824L z jednym 12-rdzeniowym procesorem POWER8 z zegarem 3.02 GHz i 64 GB pamięci RAM.

Anna Stelmaszczyk

Autorka jest architektem systemowym w firmie Advatech. Można się z nią skontaktować pod adresem: astelmaszczyk w domenie advatech kropka pl.