Przywracanie po awarii przy użyciu AWS Storage Gateway i Amazon S3 Glacier

W XX wieku stalowa skrzynia zmieniła świat. Spawany stalowy kontener ładunkowy może być jednym z najnudniejszych wynalazków w historii, ale każdego dnia otaczają Cię jego zalety. Przed latami sześćdziesiątymi XX wieku przedmioty były indywidualnie ładowane na statek towarowy i usuwane, gdy statek dotarł do miejsca przeznaczenia. Była to pracochłonna operacja, która narażała towar na uszkodzenie lub kradzież.

Wprowadzenie kontenera ładunkowego o standardowych rozmiarach umożliwiło bezpieczne pakowanie zarówno ciężkich, jak i lekkich towarów. Zmniejszyło to ilość pracy wymaganej w całym procesie wysyłki, a tym samym radykalnie obniżyło koszty. Niższe koszty, wydajne opakowanie i szybsza wysyłka zwiększyły wybór produktów, które konsumenci mogliby kupić lokalnie.

Pierwotnym pojemnikiem transportowym na dane była szpula z taśmą magnetyczną, która została wprowadzona dekadę wcześniej niż kontener ładunkowy. Opracowany przez Eckert-Mauchly Computer Corporation i wprowadzony przez Remington Rand, napęd taśmowy UNISERVO I, działał jako urządzenie wejścia-wyjścia dla komputera UNIVAC I. Szpule taśmy zastąpiły papierowe karty dziurkowane jako nośniki informacji. Z biegiem czasu, wraz ze wzrostem gęstości magazynowania, szpula skurczyła się, tworząc mały plastikowy pojemnik. Wraz ze zmianą gęstości i formatu taśm zmieniła się również hierarchia wydajności pamięci masowej. Taśma na początku była podstawowym magazynem i z czasem stała się magazynem wybieranym jako ostatnia deska ratunku.

Chcielibyśmy omówić planowanie disaster recovery (DR) i trzy kluczowe pomiary, na podstawie których należy ocenić plan odzyskiwania po awarii. Następnie skupimy się na zaletach Tape Gateway z Amazon S3 Glacier i S3 Glacier Deep Archive. Po przeanalizowaniu długoterminowego przechowywania danych, archiwizacji i odzyskiwania wirtualnych taśm, skończymy badając przywracanie danych w Tape Gateway.

Przegląd

Ostateczna deska ratunku sprawia, że myślimy o okolicznościach, które planujesz, ale masz nadzieję, że nie będziesz musiał ich przeżywać. W kontekście DR oczekuje się, że na pewnym etapie utracisz całość lub część możliwości centrum danych. Planując tę utratę, powinieneś mieć dostęp do krytycznych zasobów obliczeniowych, pamięci masowej i oprogramowania w innym miejscu w celu obsługi przetwarzania danych i wznowienia operacji biznesowych. Proces odzyskiwania po awarii może wiązać się z przestojem, którego długość zależy od typu rozwiązania DR, które wdrożyłeś, aby zacząć działać.

W planowaniu DR istnieją trzy pomiary, na podstawie których należy ocenić plan DR. Pierwszym z nich jest Recovery Point Objective (RPO), czyli maksymalny dopuszczalny czas przed awarią, w której zmiany lub dane mogą zostać utracone w wyniku operacji odzyskiwania. W niektórych przypadkach można to zmierzyć w dniach lub tygodniach, w przypadku innych aplikacji im bliżej zera sekund utraty danych, tym lepiej. Drugi to Recovery Time Objective (RTO), czyli maksymalny dopuszczalny czas przywracania aplikacji, danych lub systemów do stanu operacyjnego. Wreszcie trzeci to koszt, a koszt wskazuje, że istnieją różne typy rozwiązań, które spełniają różne cele dotyczące Recovery Point i Recovery Time.

Rozwiązania AWS

AWS oferuje kilka rozwiązań do odzyskiwania danych po awarii centrum danych on-premises w chmurze. Rozwiązania te obejmują zarówno rozwiązania asynchronicznej replikacji disk-to-disk online, takie jak CloudEndure Disaster Recovery, jak i usługi, które umożliwiają odzyskiwanie długoterminowych danych przechowywanych w Amazon S3 Glacier i Amazon S3 Glacier Deep Archive. Systemy pamięci masowej oparte na dyskach i obiektach są wybieranymi celami odzyskiwania operacyjnego kopii zapasowych; to znaczy dane, które mogą wymagać przywrócenia kilka godzin lub dni po utworzeniu ich pierwszej kopii zapasowej. Nie wszystkie dane, których kopia zapasowa jest tworzona lub są zarchiwizowane, są wymagane do przywrócenia operacyjnego, ale znaczna ilość danych przechowywanych przez wiele lat jest nadal przechowywana w kasetach z taśmami.

Tape Gateway, część usługi AWS Storage Gateway, to wirtualna biblioteka taśm (VTL), która emuluje zmieniacz nośników taśm, napędy taśmowe i kasety z taśmami. Różnica między Tape Gateway a wcześniejszymi wirtualnymi bibliotekami taśm on-premises, polega na tym, że w przeciwieństwie do VTL od niektórych innych dostawców, większość pamięci dla Tape Gateway jest zapewniana przez Amazon S3.

Zalety Tape Gateway i Amazon S3 Glacier

Możesz wdrożyć Tape Gateway na maszynie wirtualnej (VM) lub urządzeniu sprzętowym i udostępnić swoim aplikacjom do tworzenia kopii zapasowych i/lub archiwizacji. Można to zrobić w trzech klasach pamięci Amazon S3 używanych przez Tape Gateway: S3 Standard, S3 Glacier i S3 Glacier Deep Archive.

S3 Standard jest obecnie szeroko obsługiwany przez aplikacje do tworzenia kopii zapasowych i archiwizacji danych. Niektórzy twórcy aplikacji dodali obsługę dodatkowych klas pamięci S3. W przypadku wersji aplikacji, które nie obsługują S3 Glacier i S3 Glacier Deep Archive, interfejs pamięci taśmowej jest najłatwiejszym sposobem uzyskania dostępu do tych klas pamięci długoterminowej.

Zgodnie ze standardową praktyką VTL on-premises, wirtualne taśmy mogą być tworzone automatycznie przez Tape Gateway, ale w tym przypadku opłaty są naliczane tylko za dane zapisane na tych wirtualnych taśmach. Kiedy taśma jest wysuwana z VTL, jest archiwizowana (przenoszona) do predefiniowanej puli długoterminowego przechowywania. Możesz archiwizować wirtualne taśmy w puli GLACIER dla danych lub w puli DEEP ARCHIVE. Pobieranie danych w S3 Glacier zajmuje zwykle od 3 do 5 godzin, a pobieranie danych do S3 Glacier Deep Archive zajmuje zwykle od 5 do 12 godzin.

Wybór między S3 Glacier a S3 Glacier Deep Archive to kwestia czasu dostępu i ekonomii. Im dłużej możesz czekać na dostęp do danych, tym niższy jest koszt ich przechowywania w przeliczeniu na gigabajt, za który płacisz. Docelowy czas przywracania (RTO) i wszelkie umowy organizacyjne dotyczące poziomu usług decydują o zastosowaniu jednego typu zamiast drugiego.

Korzystanie z S3 Glacier i S3 Glacier Deep Archive zamiast fizycznej infrastruktury taśmowej do długoterminowego przechowywania danych ma kilka zalet. Po pierwsze, kopie danych w AWS są przechowywane w wielu Availability Zones w regionie. Po drugie, kontrola bezpieczeństwa i szyfrowanie danych ograniczają dostęp do autoryzowanych użytkowników i aplikacji. Po trzecie, obsługa WORM wymusza polityki przechowywania danych.

Są to dodatkowe oszczędności wynikające z wyeliminowania ręcznej obsługi i magazynowania, związanych z zarządzaniem fizycznymi kasetami z taśmami. Ponadto, w przeciwieństwie do kasety z taśmą stojącej na półce w magazynie, AWS zapewnia 11 „dziewiątek" (99,999999999%) trwałości danych. Ponadto AWS sprawdza poprawność danych, aby upewnić się, że nie zostały wprowadzone żadne błędy.

Wirtualna archiwizacja na taśmach i przywracanie danych za pomocą Amazon S3

Po zarchiwizowaniu wirtualnej taśmy, aplikacja do tworzenia kopii zapasowych zakłada, że znajduje się ona na półce poza VTL. Jak wspomniano wcześniej, w rzeczywistości wirtualna taśma istnieje jako obiekt archiwum przechowywany w Amazon S3. Fakt, że ta wirtualna taśma jest dostępna do przywrócenia z pamięci masowej S3 Glacier lub S3 Glacier Deep Archive, oznacza, że wirtualna taśma może zostać przywrócona za pośrednictwem innej bramy Tape Gateway.

Jest to przydatna funkcja, ponieważ wykorzystuje dostępność pamięci masowej zarządzanej przez usługę, aby udostępniać dane przechowywane do długoterminowego przechowywania w różnych lokalizacjach. Jeśli wystąpi awaria on-premises, czy to sprzętu, czy łączności, możliwe jest przywrócenie danych zarchiwizowanych w S3 Glacier lub S3 Deep Archive za pośrednictwem innej bramy Tape Gateway. Może to uratować Twoją firmę podczas awarii, ale należy zauważyć, że może nie jest przeznaczona jako narzędzie do migracji danych między lokalizacjami podczas normalnych operacji biznesowych.

Aby udostępnić wirtualne taśmy innej bramie Tape Gateway, oryginalna brama musi być wyłączona. Jeśli doświadczyłeś krytycznego zdarzenia w centrum danych, wyłączenie bramy, która nie jest już uruchomiona lub połączona, nie będzie problemem. Jeśli jednak masz trwające zadania tworzenia kopii zapasowych i przywracania, które zależą od oryginalnej bramy, może to stanowić problem.

Niezależnie od niedostępności oryginalnej bramy podczas operacji przywracania, możliwe jest przy odpowiednim harmonogramie przywracanie danych z pamięci archiwalnej bramy do fizycznej lokalizacji, która różni się od miejsca ich pochodzenia. Należy się upewnić, że podczas przywracania danych długoterminowych do nowej lokalizacji nie są wymagane żadne operacje tworzenia kopii zapasowych ani przywracania.

Podsumowanie

W tym poście na blogu pokazano, jak można używać Tape Gateway do Disater Recovery, używając długoterminowych danych zarchiwizowanych w AWS. Omówiliśmy ważne kwestie dotyczące RTO, RPO i kosztów, jeśli chodzi o planowanie DR, a także przydatność Amazon S3 Glacier i S3 Glacier Deep Archive do długoterminowego przechowywania danych.

Awarie zdarzają się częściej, niż się spodziewamy, ale dzięki przetestowanemu planowi DR i odpowiednim zestawom usług, klienci mogą wznowić normalną działalność z pełną prędkością, gdy nastąpi awaria. Podstawy planu DR nabierają kształtu wewnątrz Twojej organizacji. Podstawy bezpiecznych, trwałych i dostępnych usług pamięci masowej to podstawowa kompetencja AWS.

Dzięki odpowiedniemu połączeniu sprawdzonego planu i niezawodnych usług, Twoja infrastruktura IT może przetrwać najgorszą burzę. Aby dowiedzieć się więcej na temat szerokiej gamy rozwiązań do przechowywania kopii zapasowych i archiwalnych oferowanych przez AWS, odwiedź stronę tworzenia kopii zapasowych i przywracania oraz stronę archiwum danych.

źródło: AWS

PYTANIA? SKONTAKTUJ SIĘ Z NAMI

Zobacz również:

Współdzielona odpowiedzialność w chmurze AWS

Narzędzi wspomagajace proces i strategię migracji do chmury AWS