IX Konferencja PLOUG Koœcielisko PaŸdziernik 2003 Disaster: Backup & Recovery Wykonanie kopii DR Jaros³aw agowski IBM Polska W ramach projektów Disaster Recovery przeprowadzana jest analiza wp³ywu katastrofy Systemu Informatycznego na dzia³anie przedsiêbiorstwa. Jednym z wyników takiej analizy jest Katalog Procesów realizowanych w ca³oœci, lub przynajmniej w powi¹zaniu z Systemem Informatycznym. W Katalogu Procesów, okreœlana jest istotnoœæ procesu dla przedsiêbiorstwa i - w rezultacie - maksymalny czas przestoju procesu oraz aktualnoœæ odtworzonych danych w przypadku katastrofy. Od strony technicznej, przygotowywany jest na podstawie Katalogu Procesów, Katalog Aplikacji. Katalog Aplikacji jest decyduj¹cym dla strategii backupu i odtwarzania Systemu Informatycznego. Co zrobiæ, je eli nasza Krytyczna Aplikacja musi podj¹æ pracê najpóÿniej 2 godziny po katastrofie systemu Informatycznego z maksymalnie aktualnymi danymi które zajmuj¹ ponad 5 Terabajtów? Pierwszy warunek to istnienie Oœrodka Zapasowego, przygotowanego odpowiednio od strony infrastruktury (sprzêt, sieæ, oprogramowanie systemowo - narzêdziowe) do przejêcia przetwarzania w tak krótkim czasie. Drugi warunek to maksymalnie aktualne dane w Oœrodku Zapasowym. Przy niewielkiej wolumetrii danych mo na polegaæ na mechanizmach bazodanowych (stand-by, zwielokrotnione pliki dziennika itp.). Aby obs³u yæ wiêksze zbiory danych oraz uniezale niæ siê od typu przenoszonych danych (np. pliki p³askie) nale y siêgn¹æ do mechanizmów na nieco ni szym poziomie. W referacie omówiony zostanie sposób wykonywania kopii DR metod¹ Split Mirror w ujêciu 2 i 3 poziomowej struktury dyskowej. Wskazane zostan¹ zalety i wady obydwu rozwi¹zañ oraz technologie pozwalaj¹ce na realizacjê takiego rozwi¹zana kopii DR. Informacja o autorze: Absolwent Wydzia³u Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego (1992). Od lipca 1992 zatrudniony w firmie UNIDATAX (VAR Oracle) jako programista, póÿniej jako administrator baz danych. Od grudnia 1994 w IFS Poland (VAR Oracle) jako programista nastêpnie na stanowisku specjalisty ds. Oracle. Od maja 2000 w IBM Polska jako Kierownik Asysty Technicznej. Od marca 2002 w IBM Polska jako Large Scale Systems Engineer.
"Disaster: Backup & Recovery" Wykonanie kopii DR 229 1. Kopia DR Rozwiązanie Disaster Recovery obejmuje wiele aspektów, np. fizyczne zabezpieczenia Ośrodka Obliczeniowego, procedury dostępu do pomieszczeń, organizację pracy codziennej, czy organizację odtwarzania w przypadku katastrofy. Oczywiście, nas najbardziej interesują aspekty technologiczne. Proces wykonania kopii DR jest centralnym punktem rozwiązania Disaster Recovery z punktu widzenia technologii IT. 1.1. Wymagania Wymagania stawiane przed kopią DR wynikają z analizy przeprowadzanej na wstępie projektu Disaster Recover. Podstawowe parametry to: RTO (Recovery Time Objective) czas, który upływa od katastrofy do odtworzenia przetwarzania RPO (Recovery Point Objective) aktualność danych odtworzonych po katastrofie, np. dane odtworzone z backupu wykonywanego co noc mają RPO równe 24godziny. Availability dostępność systemu produkcyjnego, inaczej mówiąc, jak długa i jak częsta przerwa w przetwarzaniu (jeśli w ogóle) jest potrzebna aby wykonać kopię DR Bezpieczeństwo IT ogólna odporność na awarie infrastruktury IT oraz pewność i łatwość odtworzenia z kopii DR Rys. 1. Parametry Disaster Recovery Poniżej przedstawimy kilka prostych wariantów architektury dla kopii DR z oszacowaniem ww. parametrów. 1.2. Konfiguracje Pojęcie katastrofy jest pojęciem względnym. Patrząc od strony IT, katastrofa następuje wtedy, kiedy z powodu awarii, przerwa pracy systemu przekracza dopuszczalny czas. Dlatego, istotna jest minimalizacja ryzyka. Popatrzmy na minimalną konfigurację sprzętową w Ośrodku Obliczeniowym: Rys. 2. Konfiguracja minimalna
230 Jarosław Łagowski Żaden z elementów, nie jest redundantny. Kopia wykonywana jest na taśmy. Taśmy powinny być przechowywane w sejfie, lub jeszcze lepiej, wywiezione do innej lokalizacji. Awaria, któregokolwiek z elementów (serwer, dyski) jest tożsama z katastrofą przetwarzanie nie może być kontynuowane. Odtworzenie jest możliwe, ale trzeba najpierw odtworzyć (zakupić) uszkodzony element a potem skorzystać z kopii taśmowej (czasochłonna operacja). Parametry takiej konfiguracji są następujące: RPO równe cyklowi wykonania kopii taśmowej (np. 24 godziny), RTO bardzo duże, równe czasowi sprowadzenia części (lub odbudowy Ośrodka w przypadku np. pożaru) oraz odtworzenia kopii z taśm Avaliability jeżeli możliwa jest kopia na gorąco to nie ma potrzeby przerwy w pracy systemu, ale wydłuża się RTO Bezpieczeństwo IT niskie Częściej spotykaną konfiguracją w zastosowaniach produkcyjnych jest konfiguracja redundantna: Rys. 3. Konfiguracja redundantna Serwer nie jest pojedynczy mamy do dyspozycji klaster (w konfiguracji on-line czy standby). Dyski (najczęściej macierz dyskowa) są redundantne. Kopia nadal wykonywana jest na taśmy. Awaria, jednego z elementów (serwer, dyski) nie jest tożsama z katastrofą przetwarzanie może być kontynuowane z wykorzystaniem elementów zdublowanych. Tym niemniej, w przypadku katastrofy takiej jak uszkodzenie budowlane, odtwarzanie jest równie długie i żmudne jak w przypadku konfiguracji minimalnej. RPO równe cyklowi wykonania kopii taśmowej (np. 24 godziny), RTO bardzo duże, równe czasowi sprowadzenia części (lub odbudowy Ośrodka w przypadku np. pożaru) oraz odtworzenia kopii z taśm Avaliability jeżeli możliwa jest kopia na gorąco to nie ma potrzeby przerwy w pracy systemu, ale wydłuża się RTO Bezpieczeństwo IT średnie Kiedy mówimy o poważnym rozwiązaniu Disaster Recovery, to oznacza to istnienie Ośrodka Zapasowego. Ośrodek taki jest przygotowany do przejęcia przetwarzania w przypadku kłopotów w Ośrodku Podstawowym. Stopień przygotowania Ośrodka Zapasowego może być różny, np. moc obliczeniowa może być obliczona tylko dla przetwarzania krytycznego a w przypadku katastrofy zasoby Ośrodka Zapasowego są stopniowo rozbudowywane. Również sposób przenoszenia kopii danych produkcyjnych do Ośrodka Zapasowego może być różny. Poniższy rysunek przedstawia
"Disaster: Backup & Recovery" Wykonanie kopii DR 231 najprostszą z metod: kopia taśmowa wykonana w Ośrodku Podstawowym przewożona jest do Ośrodka Zapasowego i tam cyklicznie odtwarzana: Rys. 4. Konfiguracja z Ośrodkiem Zapasowym, dane przenoszone na taśmach Przy zachowaniu redundancji w Ośrodku Podstawowym, mamy przygotowaną infrastrukturę IT w innej lokalizacji. Czyni to konfigurację odporną na katastrofy budowlane, czy pożar w Ośrodku Podstawowym. Kopia nadal wykonywana jest na taśmy. Taśmy muszą być przewiezione do Ośrodka Zapasowego. Tam następuje cykliczne odtwarzanie. W przypadku przejęcia przetwarzania przez Ośrodek Zapasowy, można skorzystać z aktualnie odtworzonej kopii (jeżeli katastrofa wypadnie w dobrym momencie cyklu) zyskując znacznie na RTO ale tracąc na RPO. RPO równe cyklowi wykonania kopii taśmowej (np. 24 godziny), RTO zależy od momentu cyklu i kompromisu odnośnie RPO Avaliability jeżeli możliwa jest kopia na gorąco to nie ma potrzeby przerwy w pracy systemu, ale wydłuża się RTO Bezpieczeństwo IT wysokie Posiadając Ośrodek Zapasowy, pozostaje tylko krok do wykonywania kopii DR wprost na zdalne dyski, bez pośrednictwa taśm. Warunkiem jest posiadanie odpowiedniego połączenia między Ośrodkami. Jeżeli istnieje takie połączenie, to znacznie skraca się czas odkładania kopii oraz zwiększa się pewność jej wykonania (w porównaniu z zapisem na taśmy). Eliminujemy również długotrwały proces przewożenia i odtwarzania kopii taśmowej. Tym niemniej, ze względów archiwalnych (możliwości powrotu do kopii starszej niż ostatnia) zaleca się wykonanie kopii taśmowej w Ośrodku Zapasowym.
232 Jarosław Łagowski Rys. 5. Konfiguracja z Ośrodkiem Zapasowym, dane bezpośrednio RPO równe cyklowi wykonania kopii zdalnej (np. 24 godziny), RTO zależy od momentu cyklu i kompromisu odnośnie RPO Avaliability jeżeli możliwa jest kopia na gorąco to nie ma potrzeby przerwy w pracy systemu, ale wydłuża się RTO Bezpieczeństwo IT bardzo wysokie 2. Metoda Split Mirror Metoda Split Mirror Backup jest rozwinięciem konfiguracji kopii zdalnej. Zamiast wykonywać pełną kopię zdalną w określonym cyklu, decydujemy się na utrzymywanie zdalnej kopii lustrzanej dysków produkcyjnych w Ośrodku Zapasowym. Tym samym, po stronie Ośrodka Zapasowego mamy cały czas (prawie) aktualną kopię danych z Ośrodka Podstawowego. Wskazane jest jednak przerywanie połączenia (Split Mirror) w celu cyklicznego odłożenia kopii spójnego obrazu danych. Konieczne jest to co najmniej z dwóch powodów: jeżeli wystąpi błąd logiczny w danych produkcyjnych (bład programisty, sabotaż, itp.) to natychmiast propaguje się poprzez kopię lustrzaną do Ośrodka Zapasowego, jeżeli wystąpi tzw. rolling disaster, np. stopniowe uleganie awarii kolejnych dysków produkcyjnych, to kopia lustrzana po drugiej stronie (w Ośrodku Zapasowym) będzie niespójna i być może nie będzie możliwe przywrócenie jej konsystencji Zdalna kopia lustrzana ma następujące cechy: z reguły jest wspierana sprzętowo, wyodrębniamy w niej fazę inicjalnego kopiowania (w tym czasie przetwarzanie powinno być wstrzymane), dostępna jest funkcja zamrożenia zdalna kopia przestaje być aktualizowana, uzyskujemy spójny obraz na dany moment, po zamrożeniu następuje resynchronizacja delta zmian z Ośrodka Podstawowego jest doganiana przez Ośrodek Zapasowy
"Disaster: Backup & Recovery" Wykonanie kopii DR 233 2.1. Struktura 2 poziomowa Najprostszym wariantem wykonania kopii Split Mirror Backup jest struktura 2 poziomowa: Rys. 6. Split Mirror Backup, struktura 2 - poziomowa Dyski w Ośrodku Podstawowym nazywamy dyskami źródłowymi (primary volumes) Dyski w Ośrodku Zapasowym nazywamy dyskami docelowymi (secondary volumes) Kopia na dyskach secondary jest nieodporna na błąd logiczny, dlatego kopia lustrzana musi być zamrożona (Split Mirror) na czas wykonania kopii archiwalnej na taśmy Po zakończeniu kopii archiwalnej na taśmy, następuje resynchronizacja kopii lustrzanej Taka konfiguracja pozwala osiągnąć bardzo dobre parametry Disaster Recovery: RPO bliskie zero w przypadku wykorzystania wolumenów secondary, RTO w przypadku korzystania z kopii secondary bardzo niskie (ale duże w przypadku złej kopii secondary i odtwarzania z taśm), Availability: wpływ na produkcję bliski zeru, Bezpieczeństwo IT bardzo wysokie. 2.2. Struktura 3 - poziomowa Bardziej zaawansowanym wariantem metody SMB jest struktura 3 poziomowa. Uważa się, że dopiero taka konfiguracja może być uznana za bezpieczną. A to dlatego, że zapewnia szybkie odtworzenie w przypadku rolling disaster oraz błędu logicznego w danych. Zauważmy, że struktura 2 poziomowa, w przypadku każdego z dwóch wymienionych wyżej zagrożeń, skazuje nas tak czy inaczej na odtwarzanie z taśm, czyli proces długotrwały i niepewny. Smutna prawda jest taka, że w przypadku katastrofy typu pożar, powódź, czy zawalenie się budynku w 99% mamy do czynienia z rolling disaster. To znaczy, że kolejne dyski przestają działać nie jednym momencie. W efekcie, kopia secondary może być niespójna. W niektórych instalacjach można spotkać strukturę SMB o większej niż 3 liczbie poziomów. Na poniższym rysunku, dla przejrzystości, zaprezentujemy jednak rozwiązanie 3 poziomowe:
234 Jarosław Łagowski Rys. 7. Split Mirror Backup, struktura 3 - poziomowa Kolejny zestaw dysków o Ośrodku Zapasowym tertiary (kopia błyskawiczna PiT Point in Time) Kopia na dyskach secondary jest nieodporna na błąd logiczny, dlatego kopia lustrzana musi być zamrożona (Split Mirror) na czas inicjalizacji kopii błyskawicznej na dyski tertiary Po zakończeniu inicjalizacji kopii błyskawicznej, następuje resynchronizacja kopii lustrzanej Kopia archiwalna na taśmy, wykonywana jest z wolumenów tertiary Parametry Disaster Recovery: RPO bliskie zero zarówno w przypadku wykorzystania wolumenów secondary jak i wolumenów tertiary (rolling disaster, błąd logiczny), RTO w przypadku korzystania z kopii secondary lub w przypadku rolling disaster czy też błędu logicznego wolumenów tertiary, bardzo niskie, Availability: wpływ na produkcję bliski zeru, Bezpieczeństwo IT najwyższe. Warto wspomnieć, że kopia tertiary może być używana również jako prawie aktualny zestaw danych produkcyjnych. Taki zestaw danych, może doskonale służyć do operacji typu read only, odciążając Ośrodek Podstawowy. 3. Technologie wspierające Metoda Split Mirror Backup jest wspierana przez wiodących dostawców pamięci masowych. Trzeba zaznaczyć, że nie jest to wsparcie bezinteresowne. Zdalne kopie lustrzane i kopie PiT są realizowane zwykle jako dodatkowo płatna funkcja macierzy dyskowej. Zwykle, też narzucone są określone wymagania na typ i rodzaj połączenia zdalnego między macierzami. Dodając do tego cenę za dodatkowe zestawy dyskowe (dla struktury 3 poziomowej musimy zapewnić dodatkowo 2 razy tyle przestrzeni dyskowej ile wynika z wymagań samego przetwarzania), oczywistym staje się fakt, iż rozwiązanie nie jest tanie. Zastosowanie tej czy innej technologii w kontekście Disaster Recovery zależy zatem od oceny ryzyka i potencjalnych kosztów katastrofy. Z reguły rozwiązanie SMB stosowane jest dla instalacji terabajtowych, które musza być dostępne 24/7. Po prostu, przy
"Disaster: Backup & Recovery" Wykonanie kopii DR 235 dużych wolumenach danych, trudno znaleźć inny sposób uzyskania aktualnej, nie zaburzającej przetwarzania i łatwej do odtworzenia kopii. 3.1. Zdalne kopie lustrzane Zdalne kopie lustrzane, tworzące kopię secondary można podzielić na trzy podstawowe grupy: kopie synchroniczne, kopie semi-synchroniczne, kopie asynchroniczne. Kopie synchroniczne Rys. 7. Synchroniczna, zdalna kopia lustrzana (Synchronous Remote Mirror Copy) Realizowane w 100% sprzętowo na poziomie macierzy (ale są też rozwiązania software owe, np. Storage Tek). Zapis na dysk jest uznany za zakończony po stronie produkcji dopiero, kiedy uda się zapis po stronie Ośrodka Zapasowego. Dystans pomiędzy Ośrodkami ograniczony do kilkudziesięciu kilometrów. Przy intensywnych zapisach na dysk, utrzymywanie kopii synchronicznej może mieć negatywny wpływ na wydajność przetwarzania. Mała odporność na rolling disaster Przykłady: IBM ESS: Peer-to-Peer Copy (PPRC) Hitachi Data Systems: TrueCopy EMC: SRDF Synchronous
236 Jarosław Łagowski Kopie semi-synchroniczne Rys. 7. Semi-synchroniczna, zdalna kopia lustrzana (Semi-synchronous Remote Mirror Copy) Różnica w stosunku do kopii synchronicznych polega na tym, że zapis na produkcji jest uznany za zakończony bez oczekiwania na potwierdzenie z Ośrodka Zapasowego, ale kolejne zapisy muszą czekać na potwierdzenie. Przykłady: EMC: SRDF Semi-synchronous Kopie Asynchroniczne Rys. 8. Asynchroniczna, zdalna kopia lustrzana (Asynchronous Remote Mirror Copy) Wspomagane sprzętowo na poziomie macierzy, realizowane programowo na dedykowanym serwerze (partycji) System Data Mover Zapisy na dyski secondary grupowane są w paczki (Consistency Groups) według Time Stamp Spójność zapisów na secondary jest wspomagana dziennikami zmian utrzymywanymi na serwerze SDM Dystans pomiędzy Ośrodkami nie jest formalnie ograniczony. Kopia asynchroniczna ma minimalny wpływ na produkcję Rozwiązanie odporne na rolling disaster Dane na dyskach secondary opóźnione od kilku sekund do kilku minut. Przykłady: IBM ESS: Extended Remote Copy (XRC)
"Disaster: Backup & Recovery" Wykonanie kopii DR 237 Hitachi Data Systems: HXRC 3.2. Lokalne kopie błyskawiczne Kopie błyskawiczne (Point in Time) mają na celu uchwycenie spójnego obrazu danych na zadany moment w czasie. Oczywiście, również zamrożenie zdalnej kopii lustrzanej można uważać za kopię PiT. Jednak dla uzyskania jaśniejszego podziału technologii, chciałbym ograniczyć się w tym punkcie tylko do kopii lokalnych, które wykonywane są od początku do końca na żądanie (kopia lustrzana jest inicjowana wcześniej, działa, i tylko jest zamrażana na żądanie). Koncepcja kopii błyskawicznej opiera się na dwóch, podstawowych obserwacjach: kopia danych nie jest z reguły potrzebna na natychmiast i w całości, dane źródłowe nie ulegają zmianom natychmiast i w całości. Oczywiście jest to pewne uogólnienie, jednak świetnie sprawdza się w praktyce. Tym samym, kopia błyskawiczna bazuje na pewnym oszustwie. Logicznie, czas wykonania takiej kopii jest bardzo krótki tyle ile potrzeba na zestawienie pary wolumenów: źródło cel. Fizycznie zaś, kopia wykonywana jest w tle, często z opóźnieniem, lub w ogóle. Rys. 9. Lokalna kopia błyskawiczna (Local Point in Time Copy) Realizowane w 100% sprzętowo na poziomie i wewnątrz pojedynczej macierzy (ale są też rozwiązania software owe, np. StorageTek) Faza inicjalizacji kopii polega na zestawieniu par: źródło cel. W zależności od rozwiązania lub wybranej opcji, po fazie inicjalizacji następuje: kopiowanie w tle całego obrazu źródła, kopiowanie w tle tylko zaalokowanych fragmentów dysku, kopiowanie tylko w razie potrzeby (zmiana na wolumenie źródłowym) kopiowanie przyrostowe od poprzedniego zestawienia
238 Jarosław Łagowski Po fazie inicjalizacji, można już korzystać z logicznie pełnej kopii. Jeżeli odwołanie do kopii trafia we fragment nie skopiowany fizycznie to jest skierowane na źródło. Zmiany na wolumenie źródłowym, muszą czekać na zapis starego obrazu na kopii. Przykłady: IBM ESS: Flash Copy Hitachi Data Systems: NanoCopy EMC: Adaptive Copy 4. Podsumowanie Wykonanie kopii Disaster Recovery metodą Split Mirror jest jednym z najsprawniejszych sposobów zabezpieczenia przed katastrofą w przypadku terabajtowych instalacji z wymaganą dostępnością 7/24. Rynek dostarcza wielu produktów wspierających takie rozwiązanie od strony technologicznej. Niestety koszt finansowy, ale również organizacyjny (wyszkolenie personelu, wdrożenie i przestrzeganie procedur) jest wysoki. Każda organizacja, której los zależy od możliwości przetwarzania danych, musi przeprowadzić analizę, która wskaże, czy warto inwestować w rozwiązanie SMB, czy po prostu przygotować środki (rezerwa finansowa, ubezpieczenia, umowy z dostawcami), które uruchomione po katastrofie pozwolą odtworzyć przetwarzanie w zadowalającym czasie. Bibliografia 1. Fire in the Computer Room - What Now?, SG24-4211-01 2. Disaster Recovery Library S/390 Technology Guide, GG24-4210-01 3. Disaster Recovery Library Data Recovery, GG24-3994 4. Point-in-Time Copy: Yesterday, Today and Tomorrow, Alain Azagury, Michael E.Factor and Julian Satra, IBM Research Lab in Haifa, Israel 5. Disaster Recovery Issues and Solution, A White Paper by Roselinda R.Schulman, Hitachi Data Systems International Technical Support Organization Bibliography of Redbooks, GG24-3070. (www.redbooks.ibm.com)