Usługi kopii zapasowych
Dla pracowników działu IT nie ma nic straszniejszego niż utrata danych. Najbardziej skuteczną strategią zapobiegania utracie danych jest wykonywanie kopii zapasowych woluminów magazynu, maszyn wirtualnych, baz danych i innych systemów, w których są przechowywane dane, aby można było przywrócić te dane. Dostawcy usług w chmurze oferują usługi kopii zapasowych tylko w tym celu. Ogólnie rzecz biorąc, te usługi mogą służyć zarówno do tworzenia kopii zapasowych danych przechowywanych lokalnie, jak i danych przechowywanych w chmurze, a kopie zapasowe mogą być geograficznie replikowane i rozpraszane w celu ochrony przed zdarzeniami powodującymi utratę danych w całym centrum danych lub regionie świata.
Chmura publiczna jest dostawcą dużej ilości płynnych zasobów — nie tylko dużych fragmentów magazynów, ale także wysoce skalowalnych pul magazynów. Są one przynajmniej tak samo uniwersalne, jak zastępowane przez nie systemy magazynów kopii zapasowych i stacje taśm, a w niektórych przypadkach nawet bardziej. Dają również organizacjom nowe możliwości implementacji nadmiarowości, pracy w trybie failover i sieci bezpieczeństwa, na które wiele firm nie mogło sobie pozwolić w czasach, gdy wszystkie zasoby były kupowane z kapitału roboczego. Opcje magazynu w chmurze publicznej pełnią rolę, której zawsze desperacko potrzebowały centra danych, a którą do niedawna trudno było uzyskać.
Usługi tworzenia kopii zapasowych oparte na chmurze
Tym, co charakteryzuje nowoczesne usługi tworzenia kopii zapasowych oferowane przez dostawców usług w chmurze publicznej (CSP), jest sposób, w jaki rozszerzają one infrastrukturę swoich klientów. Przed pojawieniem się tych usług typowa strategia tworzenia kopii zapasowych w organizacji obejmowała dwie warstwy: tworzenie kopii zapasowych woluminów danych hostujących bazy danych oraz tworzenie kopii zapasowych obrazów maszyn wirtualnych hostujących obciążenia krytyczne. Założenie tego rodzaju postępowania było takie, że gdy błąd systemu prowadzi do awarii, to zdarzenie powoduje wyłączenie serwera. Trzeba wtedy natychmiast przywrócić stan tego serwera na podstawie obrazu kopii zapasowej.
Dzięki infrastrukturze opartej na chmurze stara teoria tworzenia kopii zapasowych przechodzi do historii. W nowoczesnych systemach to oprogramowanie, a nie sprzęt, tworzy serwery. Serwery wirtualne są hostowane przez infrastrukturę wirtualną opartą na funkcji Hypervisor, na przykład NSX w systemie VMware, lub składają się z kontenerów i są hostowane przez zwirtualizowane systemy operacyjne. W obu przypadkach obrazy oprogramowania obciążeń aplikacji i usług są nieustannie zarządzane, aktualizowane i zabezpieczane. Aktywne składniki oprogramowania to tak naprawdę repliki tych bezpiecznych serwerów głównych lub (w przypadku kontenerów) produkty oryginalnych serwerów głównych przechowywane w repozytoriach kontenerów i automatycznie składane według potrzeb. Gdy podczas awarii sprzętowej następuje wyłączenie węzła serwera, serwery hostowane przez ten węzeł są po prostu przez jakiś czas niedostępne. Infrastruktura przekierowuje ruch, pomijając ten węzeł, i pracuje nad zastąpieniem go. Menedżer infrastruktury nie robi nic, czego nie robiłby w toku zwykłej administracji systemem.
Jednak nawet pobieżne zapoznanie się ze współczesnymi centrami danych wystarczy, aby wiedzieć, że nie każda współczesna infrastruktura jest oparta na chmurze. Usługi są nadal hostowane na komputerach w lokalnych centrach danych. Nadal często można znaleźć sieci typu klient/serwer z oprogramowaniem pośredniczącym. W systemie hybrydowym, gdzie jeden element zaprojektowany kilka lat temu jest połączony z innym zaprojektowanym jeszcze w poprzednim stuleciu, konieczne jest przechowywanie tylu informacji o składnikach systemu, żeby w sytuacji awarii można było ponownie zrekonstruować go w dowolny możliwy, lecz szybki sposób, w nowej lokalizacji z minimalnym wpływem na poziomy usługi. Dzięki nowoczesnym strategiom tworzenia kopii zapasowych tą lokalizacją może być chmura publiczna, nawet jeśli systemy, których migawki są tworzone, znajdują się poza chmurą.
AWS Backup
Na początku 2019 r. na platformie Amazon Web Services przeprojektowano usługę tworzenia kopii zapasowych opartą na chmurze dla środowisk chmury hybrydowej klientów. W centrum nowej usługi AWS Backup, której konsola oparta na przeglądarce jest przedstawiona na rysunku 2, znajduje się aparat zasad, podobny do sędziego wyznaczającego reguły dla zapory. Dzięki temu aparatowi administrator kopii zapasowej pisze reguły, które określają następujące kwestie:
Które zasoby w systemie wymagają tworzenia kopii zapasowych.
W jaki sposób i jak często należy przeprowadzać tworzenie kopii zapasowych.
Gdzie należy przechowywać obrazy kopii zapasowych.
W jaki sposób oraz jak często należy monitorować integralność obrazów kopii zapasowych.
Jak długo należy przechowywać obrazy kopii zapasowych.
W jakich sytuacjach przeprowadzać procesy odzyskiwania i przywracania.
Pełną trasą obejmującą wszystkie aktywne zasady jest plan tworzenia kopii zapasowych. W tym planie każda reguła odwołuje się do zasobów w chmurze platformy AWS wymagających tworzenia kopii zapasowych przy użyciu wartości tagu, czyli dowolnej nazwy nadanej przez administratora. Aby dołączyć zasób, na przykład wolumin usługi Elastic Block Storage (EBS), do planu tworzenia kopii zapasowej, administrator musi tylko nadać temu zasobowi nazwę tagu rozpoznawalną przez usługę AWS Backup. W ten sposób administrator lub opiekun odpowiedzialny za zasób na platformie AWS nie musi używać konsoli usługi AWS Backup, aby sprawdzić, czy ten zasób jest częścią istniejącego planu tworzenia kopii zapasowej.
![Rysunek 2. Konsola usługi AWS Backup. [Dzięki uprzejmości Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Rysunek 2. Konsola usługi AWS Backup. [Dzięki uprzejmości Amazon]
Zasoby lokalne można dołączyć do planu tworzenia kopii zapasowych dzięki usłudze AWS Storage Gateway. Na potrzeby usługi AWS Backup usługa Storage Gateway działa jako otoka interfejsu API wokół fizycznych woluminów magazynu i urządzeń, dzięki czemu są one dostępne dla usług platformy AWS.
Pierwotnie usługa Storage Gateway umożliwiała zastąpienie istniejących fizycznych zasobów magazynu ich odpowiednikami chmurowymi używającymi tego samego interfejsu. Lokalny wolumin iSCSI można było na przykład otoczyć w coś, co na platformie AWS nazywa się woluminem buforowanym. Ta otoka sprawia, że magazyn w chmurze jest dostępny dla istniejących aplikacji lokalnych, a klienci nie muszą ponownie tworzyć tych aplikacji. Często używane dane powinny być nadal przechowywane w woluminie iSCSI jako pamięć podręczna, co zmniejszy występujące opóźnienia. Ostatnio wprowadzane zmiany w zawartości woluminów bramy mogą być też przechowywane lokalnie jako migawki. Usługa Storage Gateway obsługuje również woluminy przechowywane, w przypadku których na urządzeniu lokalnym nadal jest przechowywana kompletna lokalna kopia woluminu, duplikowana w chmurze przez usługę Storage Gateway. Nowa usługa AWS Backup wykorzystuje funkcję usługi Storage Gateway umożliwiającą zamianę ról z fizycznymi woluminami, dzięki czemu kopia lokalna staje się kopią zapasową woluminu opartego na chmurze, a jednocześnie dodaje scentralizowaną konsolę zarządzania zasadami, które określają, w jaki sposób mają być przechowywane obie repliki.
W przypadku odzyskiwania po awarii jedną z głównych zalet dostawcy rozwiązań w chmurze jest możliwość szybkiego archiwizowania krytycznych danych organizacji w odległych lokalizacjach w celu osiągnięcia nadmiarowości geograficznej. Platforma AWS obsługuje centra danych w chmurze w większej liczbie stref dostępności niż jakikolwiek inny dostawca rozwiązań w chmurze. Oferuje natywną zdolność hostowanych na niej aplikacji do automatycznego przechodzenia w tryb failover do alternatywnych stref oraz nadmiarowość kopii zapasowych danych. Jednak wiadomo, że strefy trybu failover znajdują się w tym samym regionie platformy AWS. W skrajnych sytuacjach awaryjnych (które firmy ubezpieczeniowe, a więc również osoby zarządzające ryzykiem, biorą pod uwagę), takich jak awaria sieci energetycznej, w sąsiednich strefach dostępności również mogą wystąpić awarie.
Deweloper oprogramowania lub operator IT z doświadczeniem w programowaniu może napisać niestandardowe zasady routingu na potrzeby nadmiarowości geograficznej organizacji, korzystając z usługi Route 53, czyli routingu na niskim poziomie platformy AWS. Zastosowanie tej techniki jest jednak dość trudne. Niedawno platforma AWS zaoferowała bardziej przystępną usługę o nazwie AWS Global Accelerator, czyli kolejny aparat zasad, który kieruje ruchem i wskazuje usłudze Route 53, gdzie powinny być hostowane usługi i magazyn.1 Usługę Global Accelerator można też wykorzystać jako „nadrzędny moduł równoważenia”, umożliwiający dystrybucję wielu lokacji hostowanych aplikacji (a wraz z nimi — danych krytycznych) w rozproszonych strefach dostępności.
Innym sposobem na zagwarantowanie, że dane kopii zapasowej są przechowywane w odpowiednio odległym regionie (według zaleceń techników firmy Amazon), jest ustanowienie zasobnika (kontenera kopii zapasowej ogólnego przeznaczenia platformy AWS) jako początkowej lokalizacji docelowej kopii zapasowej, a następnie zreplikowanie tego zasobnika do nadmiarowej lokalizacji w dowolnie wyznaczonej strefie dostępności. Platforma AWS oferuje usługę replikacji międzystrefowej (Cross-Region Replication, CRR) jako odrębną usługę.2 Platforma AWS wycenia usługę tworzenia kopii zapasowej na podstawie ilości danych — zarówno gigabajtów danych przechowywanych, jak i przywracanych.
Z punktu widzenia architektury usługa AWS Backup została zaprojektowana tak, aby pełnić rolę duplikatu dla zasobów platformy AWS. Dołączenie zasobów lokalnych do planu wymaga zastosowania swoistego podwójnego obejścia. Najpierw należy przekonwertować te lokalne zasoby na odległe woluminy platformy AWS (odległe z perspektywy firmy Amazon), a następnie połączyć usługę Backup z otoką wokół tych lokalnych zasobów.
Azure Backup
Usługa Azure Backup również jest w stanie tworzyć kopie zapasowe zasobów lokalnych (serwerów i maszyn wirtualnych) oraz zasobów hostowanych na platformie Azure. Jej celem nie jest zmiana istniejących zasad tworzenia kopii zapasowych w centrum danych, ale zastąpienie dysków lokalnych i stacji taśm magazynem w chmurze. Na platformie Azure miejscem w chmurze, gdzie przechowywane są kopie zapasowe plików i woluminów, jest magazyn usług Recovery Services, którego konsola oparta na przeglądarce jest przedstawiona na rysunku 3. Podczas procesu instalacji tego magazynu za pośrednictwem witryny Azure Portal administrator pobiera i instaluje agenta po stronie klienta znanego jako agent usługi Microsoft Azure Recovery Services lub "MARS". W systemie Windows Server usługa MARS działa jako aplikacja, wyglądając bardzo podobnie jak dodatek programu System Center. (Alternatywnie administrator może preferować korzystanie z programu System Center Data Protection Manager, gdzie funkcja MARS jest już wbudowana). Administrator lokalizuje woluminy i usługi w sieci, których dane wymagają kopii zapasowej, a usługa MARS dystrybuuje swoich agentów do adresów serwerów odpowiedzialnych za te składniki.
![Rysunek 3. Konsola magazynu usługi Azure Recovery Services. [Dzięki uprzejmości Firmy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Rysunek 3. Konsola magazynu usługi Azure Recovery Services. [Dzięki uprzejmości Firmy Microsoft]
Model dostarczania usługi Azure Backup jest oparty na celach poziomu usług dla odzyskiwania po awarii, które zapewniają odpowiednie metryki umożliwiające określenie, ile czasu organizacja może przetrwać bez dostępu do swoich zasobów i ile danych może utracić w sytuacji awarii. Te konkretne cele (cel punktu odzyskiwania, cel czasu odzyskiwania i przechowywanie) są omówione w kolejnej lekcji dotyczącej odzyskiwania po awarii.
Rodzaj odzyskiwania stosowany w usłudze Azure Backup (w przeciwieństwie do usługi Azure Site Recovery, czyli usługi odzyskiwania po awarii firmy Microsoft) ma na celu replikację danych, a nie przywrócenie usługi. Klient może na przykład użyć usługi Azure Backup, aby utworzyć repliki plików obrazów maszyn wirtualnych (plików VHD). Jednak przywrócenie pliku VHD powoduje po prostu ponowne utworzenie zarchiwizowanego pliku obrazu w magazynie lokalnym, a nie ponowne uruchomienie serwera wirtualnego wykorzystującego ten plik VHD.
W usłudze Azure Backup opłaty naliczane są wyłącznie za używaną w ciągu miesiąca przestrzeń dyskową, bez dodatkowych opłat za przywracanie. Model cennika magazynu łączy się z opcjami nadmiarowości. Obecnie platforma Azure oferuje dwie takie opcje: Magazyn lokalnie nadmiarowy (LRS), który jest najtańszy i replikuje dane trzy razy w centrum danych platformy Azure oraz magazyn geograficznie nadmiarowy (GRS), który replikuje dane do regionu pomocniczego geograficznie odległego od regionu podstawowego.
Kopia zapasowa usługi Google Cloud Storage
Platforma Google oferuje szereg warstw magazynu w chmurze w zależności od klasy przechowywanych danych — mogą to być na przykład trwale dostępne pliki, magazyn blokowy dla obrazów maszyn wirtualnych, czy magazyn obiektów dla plików video. Mimo że własne usługi tworzenia kopii zapasowych dla żadnej z tych warstw nie są wprost oferowane, usługi magazynu z całą pewnością mogą być i są używane do celów tworzenia kopii zapasowych i odzyskiwania. Firma Google zakłada, że tworzenie kopii zapasowych będzie jednym z głównych powodów, dla których firmy inwestują w duże magazyny w chmurze.
![Rysunek 4. Zawartość zasobnika usługi Google Cloud Storage. [Dzięki uprzejmości Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Rysunek 4. Zawartość zasobnika usługi Google Cloud Storage. [Dzięki uprzejmości Google]
Podobnie jak w przypadku platformy AWS firma Google nazywa swój kontener magazynu ogólnego przeznaczenia zasobnikiem. Na rysunku 4. przedstawiono jeden krok w procesie importowania danych z magazynu lokalnego do zasobnika usługi Google Cloud Storage. Podobnie jak w przypadku platformy Azure firma Google opiera swój model dostarczania na trzech kluczowych parametrach. Są to:
Wydajność, która w tym kontekście jest tożsama z dostępnością (jak szybko serwery odpowiedzą na żądania klientów dotyczące odczytu danych).
Przechowywanie, które również w tym przypadku oznacza to, jak długo klient zamierza przechowywać dane w chmurze.
Wzorce dostępu, które odnoszą do dostępności (jak często klient zamierza odczytywać lub odwoływać przechowywane dane).
Podczas inicjowania zasobnika klient usługi GCS wybiera klasę magazynu, która określa zasady replikacji. Ten wybór decyduje o tym, jak bardzo rozproszone będą przechowywane dane po rozpoczęciu korzystania z zasobnika do tworzenia kopii zapasowych. Usługa GCS oferuje obecnie trzy opcje geolokalizacji:
Jeden region — przechowywanie wyłącznie w jednym wybranym regionie świadczenia usługi Google.
Dwa regiony — replikacja w dwóch wybranych terytoriach świadczenia usługi.
Wiele regionów — nadmiarowe rozmieszczenie w wielu regionach świadczenia usługi.
Następnie usługa GCS dzieli klasy magazynu zasobnika na podstawie częstotliwości uzyskiwania do nich dostępu:
Standardowa/wysoka dostępność — dane mają być natychmiast dostępne dla aplikacji i użytkowników.
Magazyn zimny (Coldline) — umożliwia klientowi zastąpienie części miesięcznej opłaty za magazyn opłatami za dostęp i transfer w przypadku danych, do których dostęp ma być uzyskiwany nie częściej niż kilka razy w roku.
Magazyn bliski (Nearline) — jest to warstwa pośrednia używana w przypadku danych, do których dostęp ma być uzyskiwany mniej więcej raz w miesiącu.
Podejście firmy Google do oferowania firmom swojej infrastruktury w chmurze polega na zaprezentowaniu jej usług jako swego rodzaju niewidocznego urządzenia. W tym kontekście oferowanie przez firmę Google zarówno urządzenia, jak i sposobu jego użycia jako odrębnej usługi, może być postrzegane jako dublowanie tej samej pracy — to tak, jakby sprzedać komuś piekarnik, a następnie subskrypcję umożliwiającą pieczenie potraw jako usługę o wartości dodanej.
W ten sposób organizacja będąca klientem usługi GCS wybiera infrastrukturę, która jest potrzebna do realizacji określonych zadań, i dostosowuje ustawienia dla tej infrastruktury tak, jak funkcje urządzenia. (Podobnie jak AWS i Azure, firma Google oferuje urządzenie montowane w stojaku dla centrów danych w ekspresowym celu szybkiego transferu między magazynem lokalnym i chmurowym). Te funkcje mogą być następnie modyfikowane w czasie w zależności od tego, jak zmienia się użycie tego magazynu. Załóżmy, że firma zajmująca się produkcją filmową potrzebuje dużej ilości miejsca w magazynie kopii zapasowych do przechowywania różnych wersji filmu w czasie montażu. W procesie produkcyjnym te kopie mogą być pobierane dość często, a więc klient może wybrać dla zasobnika standardową klasę dostępności i jeden region przechowywania. Gdy film wideo zostanie ukończony i rozpowszechniony publicznie, nadal może być konieczne przechowywanie kopii na kolejny rok, mimo że mogą być one niezbyt często używane. W takim przypadku zasobnik standardowy można przenieść do zasobnika zimnego z terytorium z dwoma regionami na potrzeby archiwizacji i zabezpieczeń.
Informacje
Amazon Web Services, Inc. Zarządzanie ruchem za pomocą akceleratorahttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/ globalnego platformy AWS.
Amazon Web Services, Inc. Omówienie konfigurowania replikacjihttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.