Zamiast wstępu

Ponieważ bardzo rzadko mam okazję odpowiedzieć na to pytanie postanowiłem na przykładzie mojej aktualnej pracy w Onecie streścić zakres i może przypomnieć senes roli backup’owca w firmie.

Potocznie nazwanie Nas backup’owcami oddaje tylko część prawdy, co w temacie wykonywania kopii bezpieczeństwa można zdziałać. Mieści się w tym zarówno zwykłe przekładanie taśm, a właściwie kaset z taśmami w mikro skali, a także zarządzanie dużym i skomplikowanym systemem wykonywania, magazynowania i udostępniania danych w postaci kopii bezpieczeństwa i kopii archiwalnej. Tak, archiwalnej, ponieważ archiwum znacznie różni się funkcją i parametrami od backup’u i mylnie jedno z drugim bywa utożsamiane. Można wreszcie w oparciu o stworzone plany i możliwości testować przywracanie całych systemów do działania po awarii, bo bez planów nie ma pewności i sprawności takich działań.  Stąd już krok do wspomagania w realizacji planów ciągłości działania całej firmy. Jak łatwo dostrzec zakres odpowiedzialności może być całkiem szeroki. Wszystko to dzieje się u nas.

Backup

Zacznijmy od niego i od banalnego, ale zawsze prawdziwego stwierdzenia – trzeba robić. Daję gotową odpowiedź na niezadane pytanie i stanowczo podkreślam – robić i to regularnie oraz okresowo sprawdzać możliwość skorzystania z niego. W przeciwnym wypadku przytaczane bywa znane w gronie powiedzenie: administratorów systemów dzieli się na: (a) tych, którzy mają kopię zapasową; (b) tych, którzy będą ją robić i (c);tych, którzy szukają pracy.

Rysunek 1: Schemat działania

Oczywiście posiadanie, czy poprawnie robienie kopii bezpieczeństwa to tylko jedna strona medalu. Jednak nawet najprostszy i najtańszy sposób zabezpieczenia danych polegający na okresowym tworzeniu ich kopii na innych, zewnętrznych nośnikach jest lepszy niż żaden. Każdy to teraz robi i niejednokrotnie coraz trudniej nam to przychodzi  – zarządzać indywidualnie niejednokrotnie kilkuterowym domowym archiwum. Najbardziej zaawansowany znany mi system, to już nie tylko backup, ale bezpieczeństwo oparte o centrum zapasowe, albo wręcz rozciągnięcie przetwarzania na wiele lokalizacji. Budowanie w różnej skali, autonomicznych obiektów gotowych podjąć pracę w ciągu kilku lub kilkunastu minut od momentu stwierdzenia niedostępności ośrodka podstawowego (Centrum Zapasowe z ang. Disaster Recovery Center), zarządzanie nimi i utrzymywanie gotowości warstwy aplikacyjnej do zmieniających się wymogów pracy to wyzwanie także dla pracującego gdzieś tam w tyle backup’owca. I tu pojawia się kolejna prawda, że nie jest sztuką zabezpieczać dane, ale jest nią możliwość, granicząca z pewnością, szybkiego skorzystania z zabezpieczenia w potrzebie, czyli na czas i w danym miejscu. Bo przecież nie po to firma wydaje duże ilości pieniędzy na sprzęt, oprogramowanie, testy i ludzi, żeby później nie mieć dostępu do swoich danych w żądanym czasie. Dotykamy tu parametrów biznesowo-technicznych warunkujących działanie, ale i wielkość każdego systemu backup’owego – Recovery Time Objective (RTO) i Recovery Point Objective (RPO). Pierwszy określa minimalny czas powrotu do działania. Drugi określa możliwą stratę w danych. Oczywiście im oba czasy są krótsze, tym system bezpieczniejszy, ale i droższy. Tak także jest w Onet. Nie jest ten backup ani mały, ani tym bardziej tani.

Portal

No to jak ten system backupowy wygląda i działa w Portalu? Czym się różni od innego przedsiębiorstwa?  Prościej dopowiedzieć na drugie pytanie – niczym specjalnym się nie wyróżnia. Dane z punktu widzenia działania systemu backupowego są takimi samymi danym jak np. w banku czy zakładzie produkcyjnym. Mogę to spokojnie stwierdzić po ponad 12. latach zajmowania się tą sprawą w różnym kontekście. A jak wygląda? Przedstawiam go oto w wielkim skrócie, nie zagłębiając się szczegóły (ze zrozumiałych względów).

Mamy dwie lokalizacje (Rysunek 1) dlatego mogliśmy wdrożyć rozwiązanie zabezpieczenia danych i aplikacji w oparciu o dobrze zdefiniowaną zasadę działania ośrodka podstawowego i zapasowego, z pewnymi jej modyfikacjami uwzględniającymi naszą specyfikę.  Ośrodkiem podstawowym jest Onet Data Center – nasza piękna nowa serwerownia. Zapasowym ośrodkiem jest natomiast poprzednia serwerownia. W obu lokalizacjach działają serwery kopiowania gromadzące podstawowe, nazwijmy je – pierwszoplanowe dane backup’owe. Są to identyczne sprzętowo i programowo serwery tak, aby w razie potrzeby mogły podjąć działania utraconego sprzętu. Nie jest to konfiguracja klastrowa, co więcej nie jest nawet w pełni zautomatyzowana (oskryptawana). Nie ma takiej potrzeby. Czynności do wykonania w razie konieczności przełączenia opisuje prosta procedura – oczywiście też okresowo testowana. Ponieważ dane (najważniejsze dane, a nie całe taśmy) kopiowane są na bieżąco do drugiej lokalizacji już w stosunkowo krótkim czasie można odtwarzać awaryjnie dane najważniejszych systemów. Dla danych, które nie muszą mieć dodatkowej kopii w obrębie samego backupu stosujemy zasadę, że wystarczającym zabezpieczeniem danych jest backup do zdalnej lokalizacji. Robimy to krzyżowo. Mamy w obu lokalizacjach biblioteki pojemne na tyle, aby minimalizować konieczność wyciągania taśm z urządzenia. Ograniczone jest to tylko do taśm klonów typu offsite, a więc nie wymaga codziennej działalności operatorskiej. Na Rysunku 2 przedstawiłem schematycznie tylko jedno ramię przepływu danych oraz nie zaznaczyłem wstecznego kopiowania danych z lokalizacji zapasowej do pierwszoplanowej. Robię to na wypadek utraty dostępu do danych gromadzonych na w pulach pierwszoplanowych w zdalnej lokalizacji. Jak widać nie wozimy nośników między serwerowniami – w 7 stopniowej skali SHARE jesteśmy z rozwiązaniem backup’owym znacznie poza PATM (pickup track access method).

Rysunek 2: Przepływ danych

Uważny czytelnik zauważy to: tak, dla znakomitej większości duplikujemy dane także w backup’ie. Jest to koszt takiego rozwiązania podyktowany wymogami biznesowymi. Ciekawskim podam, że są to dobre terabajty dziennie przerzucane między lokalizacjami. Jak można wnioskować z opisu wszystkie systemy i dane mamy sklasyfikowane: od krytycznych do nieistotnych, choć możliwych do ochrony kopią bezpieczeństwa i archiwalną. Działanie i wytyczne szczegółowo określa wewnętrzna Polityka Bezpieczeństwa Firmy. Powielanie danych między lokalizacjami nie tylko zabezpiecza dane na wypadek awarii, ale chroni je także przed lokalnymi uszkodzeniami nośnika. Taśmy niestety ulegają uszkodzeniom, więcej, mają swój czas życia i chociaż u nas żadna z nich nie dobiegła końca swojej użyteczności (np. ilość całkowitych przewinięć, ilość załadowań i wyładowań) to wymieniałem już ich ok. 50 w ciągu ostatnich 5 lat ze względu na zgłaszane błędy zapisu czy odczytu. A jak wymieniamy taśmy to co z nimi robimy? To też określa Polityka i procedura. Nie wdając się w szczegóły niszczymy zawartość. Wewnętrze kopiowanie zapewnia więc dodatkową, okresową weryfikację niemal każdej taśmy, tak samo jak okresowe odzyskiwanie zwolnionych przestrzeni na taśmach po usuniętych danych. Weryfikację spójności danych zapewniają okresowe testy odtworzeniowe poszczególnych systemów czy pojedynczych maszyn. Dane w systemie kopiowania są rozdzielone na backup i archiwizację – to znaczy dane backupowe nie mieszają się z danymi archiwalnymi. Ponadto dla większości systemów podlegają grupowaniu tak, aby nie miksować ze sobą danych podlegających ochronie prawnej (GIODO) z danymi, które takiego specjalnego traktowania nie wymagają.

Wszystko to podporządkowane jest Polityce Bezpieczeństwa firmy i w ramach tej polityki – polityce wykonywania kopii bezpieczeństwa i archiwizacji. Wytyczne obu polityk określają zasadnicze metody i sposoby ochrony danych w Grupa Onet.pl.

Jak widać nic wielkiego, ani nadzwyczajnego – ot taki samograj, bo wszystko niemal dzieje się samo. Ale nie do końca. Przy dużej dynamice zmian i dużej ilości klientów systemu (ok. 800 zdarzeń związanych z backupem i archiwizacją dziennie oraz do ok. 5000 takich zdarzeń tygodniowo i przy ponad 40TB tygodniowego i ok. 5-6TB dziennego backupu) pracy z zarządzaniem jest sporo. Aby to wszystko mogło się zrzucać równocześnie stosujemy dyskowe pule pierwszoplanowe, z możliwym kilkudniowym okresem przebywania danych w cache’u, w celu szybkiego ewentualnego odtworzenia. Cóż: z dysku, w zdecydowanej większości przypadków odtwarzanie jest szybsze i wielowątkowe. Do planowanych odzysków także staram się najpierw przenieść dane z taśmy na cache dyskowy. Odtworzenie z niego klienta z kilkoma milionami obiektów jest znacznie szybsze, doliczając nawet czas dodatkowej migracji danych z taśmy na dysk. Ale są też przypadki odwrotne – odtworzenie całych wolumenów (tera czy dwa) bezpośrednio z taśmy idzie znacznie szybciej.

Jak jesteśmy przy odtwarzaniu to pojawia się pytanie jakich metod backupu używamy. Odpowiedź na to pytanie też jest prosta i oczywista jak przy tak dużym i wielośrodowiskowym systemie – stosujemy wszystkie dostępne i adekwatne do potrzeb metody: klasyczny plikowy, przyrostowy i pełny, api backup, snapshoty, całe wolumeny, lan, san, ndmp.

Wyzwania

Tak jak środowiska wirtualne na początku były ciekawym zagadnieniem backup’owym, tak teraz jest nim kopia bezpieczeństwa w chmurze. Myślę jednak, że podobnie jak z wirtualizacją można ją w prosty sposób wykonać. Analogiczne narzędzia i metody tylko intensywniej wykorzystywane. Myślę tutaj o wszelkich kopiach migawkowych (sprzętowych i programowych) oraz szybkich sieciach konwergentnych, ponieważ wyzwaniem jest i będzie szybkość kopiowania i odtwarzania, szczególnie odtwarzania. Jak się to rozwinie już najbliższy czas pokaże.

Zamiast podsumowania

Dlaczego lubię to co robię? Roboty taśmowe wprowadzają „życie” do serwerowni.  Poza monotonnym szumem klimatyzacji i świstem wentylatorów, choinką kontrolnych diod i wyświetlaczy serwerów coś się porusza. Choć ruchy ta są ograniczone niczym na więziennym wybiegu: obrót prawo-lewo, góra-dół to przynajmniej widać, że się coś dzieje, że pracuje. Tak, jest to może relikt czasów mechaniki, która kiedyś w znacznym zakresie gościła w IT. Teraz ta mechanika, a właściwie robotyka, zanika w IT i choć ewoluowała znacznie jest w chwilowym regresie. Pamiętam, już takie załamanie, gdy kończył się żywot poczciwych napędów DLT czy DDS. Jestem jednak pewien, że długoterminowe składowanie danych nieprędko znajdzie rozwiązanie tańsze i bezpieczniejsze niż taśma. Trwają prace na zapisem 35TB bez kompresji na kasecie wielkość zwykłej LTO. Roadmap LTO Ultrium sięgnął generacji 8 tj. 12,8TB bez kompresji. Dawny StorageTek wprowadził napędy T10kC – 5TB. Czeka nas piękne długie życie, długie jak co najmniej trwałość zapisu na LTO – 30 lat. Sprzedaż systemów taśmowych rośnie.

Poza fascynującym mnie trwałym związkiem robotyki i elektroniki z informatyką w zarządzaniu nośnikami offline praca bakupowca wymaga wszechstronności w stosunku do niemal wszystkich systemów operacyjnych i aplikacji. Takie trywialne, ale backup czy archiwizacja z natury rzeczy dotyka każdego systemu – a u nas także komputerów przenośnych. Musisz się znać na wielu sprawach, od sprzętu po aplikacje użytkowe – sieci. A najlepszym testerem sieci jest właśnie backup.

Największą satysfakcję mam, gdy widzę uśmiechniętą twarz uszczęśliwionego odzyskaniem dni pracy zamkniętych w skoroszycie czy doc’u.

Filmik

Słowo wyjaśnienia co zawiera załączony filmik. Są to krótkie fragmenty testów poprawności działania naszej głównej biblioteki taśmowej po relokacji (anakonda, bo taka szybka, co widać). Odbyło się to już dobry rok temu. Operacja demontażu, transportu i montażu z weryfikacją zajęła cały dzień – niestety, w tym czasie backupy, a co gorsza odtworzenia, nie mogły być realizowane. Wydarzenie na tyle niepowtarzalne, że warto było sfilmować. W pierwszych ujęciach pierwsze ruchy weryfikacyjne po uruchomieniu biblioteki – jeszcze bez ścianek bocznych. Widać cały accessor i dual-gripper. Biblioteka jeszcze pusta. W dalszej części operacja wkładania kaset przez I/O Slot już z poziomu aplikacji backupowej. Tutaj już pełna obsada taśm. Znamienne dla anakondy są też ułamki sekundy wyciągania kasety z napędu – nic nie przyspieszałem.

Polecam

  1. IBM Tape Library TS3500 – High Density Frame
  2. StorageTek SL8500
  3. Taśma 35TB

Leszek Kaptur
Starszy Administrator Systemu Backup’u