Kopia z rozmysłem

Wybór dobrego rozwiązania archiwizacyjnego wiąże się przede wszystkim z dobraniem systemu o odpowiedniej architekturze dostosowanej do potrzeb i możliwości firmy.

Wybór dobrego rozwiązania archiwizacyjnego wiąże się przede wszystkim z dobraniem systemu o odpowiedniej architekturze dostosowanej do potrzeb i możliwości firmy.

Czasy, gdy komputery stanowiły jedynie uzupełnienie biznesu prowadzonego "na papierze", bezpowrotnie odchodzą w przeszłość. Jeżeli ważnych informacji nie można znaleźć w komputerze, to najczęściej nie ma ich nigdzie indziej. Aby awaria komputera nie przeistoczyła się w paraliż firmy, dane trzeba zabezpieczyć. Najprostszą drogą do tego celu jest wykonywanie zapasowych kopii danych. W teorii wszystko jest proste - kopia to kopia. W praktyce liczba koncepcji, architektur, standardów, formatów może przyprawić o zawrót głowy. Wybór jest tym trudniejszy, że musi odpowiadać nie tylko potrzebom bieżącym, ale też uwzględniać te, które mogą się pojawić w przyszłości.

Dobrym kierunkowskazem przy wyborze rozwiązania do archiwizacji danych jest unikanie skrajności - nie warto sztywno trzymać się najniższej ceny ani też ślepo ufać znanej marce. W pierwszym rzędzie, jeszcze przed rozesłaniem zapytań ofertowych, wypada zastanowić się nad rzeczywistymi potrzebami biznesowymi. Ich określenie wskaże właściwą architekturę, a ta - cechy potencjalnego rozwiązania.

Porządek rozproszony

Architektura rozwiązania archiwizacyjnego jest pochodną architektury firmowych systemów informatycznych. Jeżeli aplikacje i dane są scentralizowane, sprawa jest prosta: kopiowanie danych odbywa się lokalnie, po łączach o dużej przepustowości. Jeśli firma będzie rozrastać się w ramach pojedynczej lokalizacji, wykonywanie kopii również nie będzie nastręczało problemów.

Kłopoty i dodatkowe koszty mogą się pojawić, gdy firma zdecyduje się na ekspansję terytorialną. Jeżeli oddziały korzystają z aplikacji działających w centrali, np. w trybie terminalowym (znakowym lub graficznym), przez przeglądarkę lub tzw. cienkiego klienta, wówczas centralne rozwiązanie archiwizacyjne będzie wystarczające. Nie każda firma ma jednak możliwość centralizacji informatyki - nawet jeżeli część aplikacji zostanie scentralizowana, to część może po prostu się do tego nie nadawać. W tej sytuacji w oddziałach będą potrzebne nie tylko serwery plików i wydruków dla aplikacji biurowych, ale także kopie lokalne centralnych baz danych.

Organizacja archiwizacji danych w środowisku rozproszonym będzie wynikać z uwarunkowań lokalnych. Firma może zdecydować się na wykonywanie kopii danych lokalnie, będzie to jednak równoznaczne z zakupieniem dodatkowego rozwiązania, np. napędu taśmowego wraz z odpowiednim oprogramowaniem, a także z przeszkoleniem i zdalnym nadzorowaniem przez co najmniej dwóch pracowników.

Alternatywą pozwalającą zachować w pełni scentralizowane zarządzanie archiwizacją danych może być wdrożenie oprogramowania, które co jakiś czas, np. na koniec każdego dnia, będzie replikować dokonane w plikach zmiany do serwera backupowego w centrali (patrz: ramka). Oczywiście, będzie to mieć sens w sytuacji, gdy zmian w danych jest relatywnie mało i gdy łącze WAN będzie w stanie taką komunikację obsłużyć. Nade wszystko jednak ważne będzie to, czy rozwiązanie umożliwi odtworzenie danych po ewentualnej awarii w czasie akceptowalnym z punktu widzenia biznesu.

Wzrost bez niespodzianek

Kolejnym obszarem rozważań w dziedzinie architektury jest wewnętrzna organizacja podsystemu archiwizacji. Najczęściej spotykana architektura przewiduje pobieranie danych z serwerów źródłowych przez serwer backupowy i przesyłanie ich do systemów archiwizujących - napędów czy bibliotek taśmowych albo, co zdarza się ostatnio coraz częściej, na wydzielone systemy dyskowe, skąd dopiero trafiają na taśmy lub inne nośniki. Zaletą tej architektury, zwanej in-band, jest bezpośrednia kontrola strumieni danych płynących przez serwer backupowy, a w szczególności możliwość wykonywania na nich dodatkowych operacji, np. sprawdzania spójności, kompresji, szyfrowania itp.

To, co jest zaletą, jest jednocześnie wadą techniki in-band. Ponieważ wszystkie dane płyną przez jeden serwer, jego moc obliczeniowa i wydajność kanałów I/O wyznaczają granicę wydajności całego rozwiązania archiwizacyjnego. Nic zatem dziwnego, że jest to zazwyczaj urządzenie co najmniej średniej klasy (np. 2- lub 4-procesorowy serwer z dużą ilością pamięci RAM) i przez to relatywnie drogie. Ponieważ w takiej architekturze serwer backupowy jest elementem krytycznym systemu archiwizacji, jego awaria uniemożliwia wykonanie jakiejkolwiek kopii.

Z tego względu aplikacje backupowe działają zwykle nie na pojedynczych systemach, lecz w klastrach, co dodatkowo podwyższa cenę rozwiązania.

Architektura in-band wywodzi się jednak z rozwiązań niewielkiej skali. Najlepiej sprawdza się w środowiskach, w których serwer backupowy jest zintegrowany z jednym ewentualnie dwoma napędami taśmowymi, lub też w takich, w których każdy serwer jest równocześnie wyposażony we własne dyski (DAS - Direct Attached Storage) i własny napęd taśmowy. W bardziej skomplikowanych, z założenia usieciowionych środowiskach, architektura in-band raczej słabo się skaluje. Można oczywiście zbudować instalację z dwoma lub więcej serwerami backupowymi, ale będzie ona trudna w zarządzaniu i raczej powinna być traktowana jako rozwiązanie tymczasowe.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200