Zdążyć z kopią

Wydajność wykonywania kopii danych jest pochodną celu takiej operacji oraz dobrego przemyślenia architektury pamięci masowych i całej firmowej infrastruktury IT.

Wydajność wykonywania kopii danych jest pochodną celu takiej operacji oraz dobrego przemyślenia architektury pamięci masowych i całej firmowej infrastruktury IT.

Wydajny backup to hasło, pod którym chętnie podpiszą się wszyscy. Jak to jednak w życiu bywa, każdy ma na myśli własną definicję tego, czym jest backup, jaki jest jego cel oraz co to właściwie znaczy "wydajnie". Problemem, który prowadzi do zaistnienia tego "tematu", jest zwykle kurczące się okno backupowe, zmniejszające możliwości wykonania kopii danych bez jednoczesnego utrudniania pracy użytkownikom aplikacji. Drugim ważnym powodem jest zmiana wymagań biznesowych, dotycząca skrócenia czasu przywracania dostępności aplikacji po ewentualnej awarii. Zamiast więc mówić o wydajnym backupie, lepiej skupić się właśnie na tych dwóch zagadnieniach.

Sieciowe dylematy

Zdążyć z kopią

Nowe generacje pamięci masowych oferują coraz wyższą pojemność i szybkość zapisu, ale nie podołają przyrostowi danych, jeśli architektura systemu nie jest dobrze zaplanowana, a cenne dane mieszają się z tymi o niskiej wartości. Na zdjęciu Tandberg Data StorageLoader LTO3 - pamięć taśmowa o wysokości 1U, pojemności 6,4 TB i szybkości zapisu 432 GB/h.

Skracające się okno backupowe nie jest niczym nowym. Do tej pory sobie radziliśmy - danych przybywało, ale wydajność urządzeń backupowych wzrastała i dla każdego można było opracować spójną architekturę, zdolną do skalowania w jakimś zakresie. W międzyczasie nastąpiło jednak coś, czego wiele firm się nie spodziewało - wzrost liczby aplikacji. Sporo firm nie widzi powodu, by każdy nowy pomysł biznesowy od razu obsługiwać w systemie zintegrowanym (jeśli go posiada). Praktyka jest więc taka, że obok siebie działa coraz więcej aplikacji wspomagających kolejne inicjatywy biznesowe.

Jeśli jest tak, że aplikacje te działają na oddzielnych serwerach podłączonych do firmowej sieci SAN, problem z oknem backupowym staje się bardzo realny. W sieci SAN, która działa w architekturze punkt-punkt, backup powinien odbywać się możliwie równolegle, tymczasem ruch z serwerów aplikacyjnych jest wysyłany do biblioteki taśmowej. Ile portów ma biblioteka? Dwa? Cztery? Tyle właśnie serwerów może jednocześnie oddawać dane. To zresztą teoria, bo przecież trzeba jeszcze zachować zapasowe interfejsy na wypadek awarii łącza.

Problemem w tym wypadku nie jest wydajność technologii taśmowej, lecz liczba jednoczesnych strumieni danych, które biblioteka może przyjąć. W konsekwencji z punktu widzenia długości trwania backupu w sieciach SAN zastępowanie taśm dyskami w formie bibliotek VTL (Virtual Tape Library) nie ma wielkiego znaczenia. Problemem jest liczba dostępnych interfejsów, a nie nośnik. Nawet jeśli zdefiniowane zostanie 100 wirtualnych napędów, nic się nie zmieni, chyba że…

Chyba że oprogramowanie VTL zostanie połączone z macierzą dyskową umożliwiającą wirtualizację portów na urządzeniu docelowym. W takim wypadku każdy port fizyczny macierzy będzie mógł być widziany w sieci SAN jako wiele portów i dopóki pasmo nie zostanie wysycone, na ten jeden port będzie można wysyłać jednocześnie ruch z wielu serwerów aplikacyjnych. Oczywiście, wszystko trzeba przeliczyć, nawet przy portach o wydajności 2 Gb/s może się bowiem okazać, że to wydajność dysków jest ograniczeniem.

W sieci SAN opartej na standardzie Ethernet sprawy wyglądają znacznie prościej. Wprawdzie wydajność sieci Gigabit Ethernet nie może równać się z Fibre Channel, ale jeśli sieć zostanie dobrze zaprojektowana, jej użyteczność nie musi być wcale mniejsza. W tym wypadku bowiem nie ma problemu z liczbą portów, agregacją łączy i strumieni danych z wielu serwerów. Jeśli ktoś dojdzie do wniosku, że Gigabit Ethernet to za mało, może spróbować instalacji małej podsieci 10 Gb/s, choć trzeba mieć świadomość, że nie wszystkie macierze/biblioteki są w stanie efektywnie odebrać taki ruch.

Zapewnić bezpieczny powrót

Odtwarzanie danych po awarii może trwać znacznie dłużej niż backup, choćby z tego powodu, że czasu awarii nie można przewidzieć i może się zdarzyć, że nastąpi ona w czasie wzmożonego ruchu w sieci. Dane z kopii trzeba wtedy będzie odtwarzać dość długo. Na tę okoliczność powstały architektury gorącego backupu (near-line backup), które opierają się na przechowywaniu spójnej kopii danych na tej samej macierzy, która obsługuje normalną pracę aplikacji. Dla zwiększonego bezpieczeństwa (na wypadek awarii macierzy podstawowej) może to być inna, fizycznie odseparowana macierz dyskowa.

Jeśli mamy do czynienia z oddzielną macierzą na kopie zapasowe, trzeba doprowadzić do tego, by dane na macierzy głównej i dodatkowej można było łatwo synchronizować (koniecznie w obie strony!). Wyższej klasy macierze są najczęściej wyposażone w oprogramowanie replikacyjne, pozwalające kopiować spójny obraz danych zapisany w postaci kopii migawkowej (snapshot) do innej macierzy. W procesie tym z reguły nie bierze udziału serwer aplikacyjny, a więc jego wydajność nie jest zmniejszana. Jeśli oprogramowanie replikacyjne dla posiadanych macierzy jest zbyt kosztowne, można w tym celu wykorzystać dedykowany serwer replikacyjny - dostawców tego typu rozwiązań jest już sporo i wciąż ich przybywa.

Te same firmy oferują także rozwiązania klasy CDP - Continuous Data Protection. Ich rola polega na tym, aby w czasie zbliżonym do rzeczywistego przenosić zmiany zapisane na macierzy podstawowej do niezależnej kopii danych na tej samej macierzy lub do macierzy zapasowej, lokalnej lub zdalnej - w zależności od tego, czy rozwiązanie ma służyć backupowi, czy też zabezpieczeniu na wypadek poważniejszej katastrofy. Dzięki CDP, w przypadku awarii dotyczącej jedynie serwera aplikacyjnego lub aplikacji (co najczęściej się zdarza), dane są dostępne niemal natychmiast.

Można też wyobrazić sobie scenariusz, w którym dane są od razu zapisywane na dwie niezależne macierze, z których każda tworzy własne kopie migawkowe (snapshot) w określonym cyklu, np. co 15 min. Mamy wtedy zwiększone bezpieczeństwo, możliwość szybkiego odtworzenia danych, a jednocześnie możliwość łatwego wykorzystania danych na potrzeby systemów analitycznych lub raportujących. Oczywiście, w architekturze wykorzystującej replikację lub mechanizmy CDP też jest to możliwe, ale musimy mieć świadomość, że kopia, z której pobieramy dane (macierz zapasowa), może nagle stać się jedyną spójną kopią danych i wówczas trzeba się z nią obchodzić bardzo ostrożnie.

Najpierw gruntowne porządki

Jeśli aplikacji niecierpiących przerw w pracy będzie przybywać, a na to się zanosi, architektury backupowe będą dążyć w kierunku wielowarstwowych kopii danych. To nieuniknione. W związku z tym danych będzie przybywać, ale taka jest cena ich wysokiej dostępności i bezpieczeństwa. Jedyne, co można zrobić, to próbować optymalizować ilość danych podlegających bieżącemu zabezpieczaniu. W ten sposób będzie można zrealizować kilka celów jednocześnie: powiększyć okno backupowe, skrócić czas odtwarzania danych, zarówno lokalnie, jak i zdalnie, a także zmniejszyć łączne wydatki na infrastrukturę.

Najważniejsze jest dokładne przejrzenie tego, co podlega zabezpieczaniu, z jakim priorytetem i z jaką częstotliwością, a także ile kopii danych efektywnie powstaje. To powinno być źródłem pomysłów na ograniczenie ilości danych. Jeśli oddzielne kopie danych powstają bez kontroli (brak świadomości użytkowników oraz istnienie technicznej możliwości wykonania kopii w dowolnym celu powoduje, że wiele takich samych kopii danych powstaje równocześnie, ale w różnych celach), trzeba stworzyć procedury i wymusić - najlepiej środkami technicznymi - ich stosowanie. W przeciwnym razie mamy do czynienia z kopiami kopii pomnożonymi przez dwa, trzy i więcej. Zabezpieczanie i odtwarzanie tego wszystkiego nie ma sensu, a oprócz tego nie służy bezpieczeństwu, ponieważ zmniejsza przejrzystość systemu.

Również w przypadku danych użytkowników z systemów plików ważne jest zapewnienie odpowiednich procedur i ograniczeń technicznych. Jeśli użytkownicy zorientują się, że automatyczny backup akceptuje dowolną ilość danych lub pliki dowolnego typu, mamy co najmniej dwa problemy. Po pierwsze urządzenia służące do wykonywania kopii są zajęte kopiowaniem danych o małym znaczeniu. Po drugie, czas odtworzenia całości danych, przesłania ich do zdalnej lokalizacji wydłuża się. Na co dzień może to nikomu nie przeszkadzać, ale pewnego dnia może się okazać, że właśnie z tego powodu firma straciła ważne i cenne dane.

I jeszcze jedno. Nawet jeśli liczba kopii głównych baz danych jest ściśle kontrolowana, nie oznacza to, że wszystko jest w porządku. Raporty sprzed dwóch lat można spokojnie zarchiwizować lub przechować jedynie w hurtowni danych lub bazie raportowej. Nieużywane indeksy można - i powinno się - usuwać. Jeśli backup bieżących danych można wykonać w godzinę, a nie w dwie, warto zainteresować się bieżącym zarządzaniem danymi. Gdy danych będzie mniej, można je szybciej odtworzyć w sieci.


TOP 200