Wrota Nieskończoności W Twoim Data Center (Czyli Jak Stworzyć Petabajty Na Twojej Gigabajtowej Macierzy)

Dla każdego z nas przychodzi taki moment w którym kończy nam się przestrzeń dyskowa czy to na fotki, czy też na dane produkcyjne naszej wielomilionowej korporacji.
Chciałbym przedstawić Tobie jak w prosty sposób zapomnieć o sprzęcie, utrzymaniu, konfiguracji SAN, planowaniu pojemności. Chciałbym otworzyć przed Tobą wrota nieskończoności.
Jeżeli tylko jesteś skłonny poświęcić kilka chwil, przedstawię Ci rozwiązanie chmurowe, AWS Storage Gateway. Pozwoli on oszczędzić pieniądze i czas dając poczucie komfortu i bezpieczeństwa.

AWS Storage Gateway jest niczym innym jak maszyną wirtualną którą możemy uruchomić w środowiskach vSphere/HyperV.
Posiada dosyć małe wymagania oraz może śmiało zostać umieszczony w sieci prywatnej posiadającej jedynie wyjście do Internetu (działa także gdy jedynie mamy SOCKS proxy). W istocie jest bramą łączącą Twoje data center z zasobami AWS tworzącą “tunel” protokołem HTTPS, zapewniając szyfrowanie komunikacji.

Co w takim razie może dla Ciebie zrobić AWS Storage Gateway?
Jest to magazyn danych (a’la NAS) działający w dwóch trybach (Gateway-Cached lub Gateway-Stored) lub biblioteka taśmowa (Gateway-VTL), podłączany do infrastruktury przy pomocy iSCSI. Pomyśl że możesz od ręki zaprezentować aż 150TB przestrzeni dyskowej (z pojedynczego Gateway’a) dla swoich serwerów, przechowywać kopie zapasowe w formie wirtualnych taśm wykorzystując swoje dotychczasowe oprogramowanie, płacąc jedynie za wykorzystaną przez siebie pojemność!
Pomyśl że pod spodem znajdują się rozwiązania AWS (S3, Glacier) którym zaufało tak wiele wielkich światowych przedsiębiorstw.
Pamiętaj…
Korzystając z dobrodziejstwa Amazon Web Services dostajesz w pełni darmowy 60-dniowy okres na testy AWS Storage Gateway. Możesz w tym czasie wielokrotnie go powołać, kasować, uruchamiać pod różnymi hypervisorami i w różnych trybach. Naprawdę zachęcam do eksperymentów, w szczególności że spektakularne efekty są w zasięgu kilkunastu kliknięć.

Gateway-Cached

To mój ulubiony tryb działania – najprostszy ale i najbardziej efektowny.
Daje ci możliwość wykorzystania zasobów S3 w AWS poprzez Internet, tak jakby były to zasoby bezpośrednio dostępne w twojej lokalnej infrastrukturze. Przestrzeń dyskowa jest widoczna w formie zasobu dostępnego po iSCSI, który możesz wykorzystać bezpośrednio w systemach operacyjnych np. jako Datastore w vSphere, czy dysk twardy w systemach Windows.
Po prostu podłączasz i korzystasz, a płacisz jedynie za zajętą przestrzeń dyskową która trafiła do AWS. Tworząc maszynę wirtualną AWS Storage Gateway w swoim środowisku decydujesz jaką pojemność przeznaczasz na pamięć podręczną (Cache Storage) dla danych najczęściej zmienianych oraz dedykujesz bufor (Upload Buffer) na dane przygotowane do wysłania do AWS. W tym trybie najlepszą wydaje mi się właśnie pamięć podręczna, gdyż w wielu przypadkach tak naprawdę wrzucamy do chmury dane “zimne” czyli rzadko zmieniane, ale te z których korzystamy względnie często nie będą pobierane za każdym razem przez Internet, tylko serwowane z lokalnej pamięci podręcznej.
Ta szczypta magii powoduje że użytkownik w wielu przypadkach nie odczuje że jego dane znajdują się gdzieś daleko.

Z ciekawych funkcjonalności jakie daje nam ten tryb to pełny dostęp do funkcjonalności snapshotów, co w dużej mierze może przekładać się na funkcjonalność zbliżoną do kopii zapasowych, pozwalając nam wrócić w czasie do danego punktu lub wystawyć nowy wolumin do serwera bazując na wybranym snapshocie. Innym ciekawym faktem jest możliwość podłączenia takiego snapshotu do instancji EC2 lub w drugą stronę, podłączenie dysku z instancji EC2 bezpośrednio do twojego środowiska lokalnego!
W kilku krokach pokażę Tobie jak prosto się to wszystko odbywa. Z konsoli zarządzania, zakładki AWS Storage Gateway klikamy “Set up and Activate a New Gateway”. Wybieramy tryb działania który nas interesuje i klikamy “Continue”.

W kilku kolejnych ekranach jesteśmy informowani o minimalnych wymaganiach od strony Hypervisora, dostajemy opcję jego wyboru (ESXi, Hyper-V 2008R2 oraz Hyper-V 2012), ostatecznie dostając możliwość pobrania obrazu maszyny wirtualnej która docelowo ląduje w Twojej lokalnej infrastrukturze.

W zależności od wirtualizatora jaki wybrałeś, AWS przedstawia dokładny opis jak konfigurować obraz Storage Gateway pod ESXi czy Hyper-V. 
Po twojej stronie jest w tej chwili deployment maszyny wirtualnej w lokalnym środowisku. W skrócie można to streścić do wgrania obrazu, dodania dwóch dysków twardych – jeden pod Cache Storage, drugi pod Upload Buffer, ustawienie adresacji IP i weryfikacji dostępu do Internetu oraz zasobów AWS. Specjalnie dla Ciebie przygotowałem szybką wklejkę jak wykonać to w interfejsie vSphere Web Client, ponieważ AWS nie miał okazji zaktualizować dokumentacji :D.
Lecimy zatem – najpierw deploy template który pobraliśmy z portalu AWS Storage Gateway.

Wybieramy obraz OVA (ważne żeby zaznaczyć sobie w filtrze widok plików *.ova).

Dalej pozostaje przeklikanie odpowiedniego datacenter, datastore oraz wybór sieci, w której znajdzie się nasz zasób iSCSI, czyli sieci NAS. Nie należy na tym etapie zaznaczać automatycznego uruchomienia, ani uruchamiać obrazu ręcznie, gdyż czeka nas jeszcze procedura dodania dwóch dysków twardych na Cache Storage i Upload Buffer, a także synchronizacja czasu.
Dodajmy zatem 2 dyski twarde w trybie “VMware Paravirtualized”.

Dodajemy 2 dyski 10 i 30 GB i zmieniamy typ kontrolera.

Pozostaje włączenie synchronizacji czasu z hostem. Klikamy OK, a po zakończeniu rekonfiguracji uruchamiamy maszynę wirtualną, otwierając następnie okienko konsoli.

Po zakończeniu uruchamiania logujemy się do konsoli użytkownikiem “sguser”, hasło “sgpassword”. Będziemy teraz konfigurować interfejs sieciowy aby móc skomunikować się z zasobami w AWS.

Z menu głównego wybieramy konfigurację statycznego IP (tak zostało przyjęte w tym przykładzie, w twoim środowisku będziesz musiał dostosować te parametry)

Uzupełniamy adresy IP/Maski/DNSy i dajemy “Apply config” – YES! Wracamy do menu głównego (7).

Z menu głównego wybieramy opcję (3) “Test Network Connectivity” i jeżeli nasza maszyna wirtualna ma wyjście do Internetu, połączy się i zgłosi do AWS Storage Gateway.

Wybieramy region który nas interesuje i czekamy na zakończenie testów.

Po potwierdzeniu możliwości dostępu naszej maszyny wirtualnej do zasobów AWS, pozostaje nam aktywowanie naszego AWS Storage Gateway w ostatnim kroku “Activate Gateway”. Wpisujemy adres lokalny naszej maszyny wirtualnej (co ciekawe – AWS będzie wiedział o co chodzi :D).

Następnie zostajemy poinformowani i kosztach wykorzystania oraz 60-dniowym okresie próbnym. Ustalamy strefę czasową, wybieramy nazwę naszego AWS Storage Gateway którym będzie się przedstawiał w konsoli zarządzania.

Nasz AWS Storage Gateway został aktywowany. Pozostało jedynie skonfigurować Cache Storage i Upload Buffer. Z widoku naszego Gateway’a klikamy z zakładki “Gateway” przycisk “Configure Local Storage”.

Przyporządkujemy naszym utworzonym dyskom odpowiednie funkcje. Po zakończeniu ustalamy sobie powiadamianie mailowe w przypadku przekroczenia progów zajętości tych dwóch dysków – szczególnie przydatne w środowiskach produkcyjnych gdzie warto monitorować czy przestrzeń się kończy, sprawdzać dlaczego oraz dostrajać swoje środowisko.

Teraz pozostaje tylko decyzja jak wielki wolumin danych chcemy udostępnić dla swoich serwerów oraz nazwę roboczą. Na zakończenie klikamy Create Volume. Omijamy konfigurację CHAP ponieważ robimy sobie tylko testy, na środowisku produkcyjnym warto jednak zadbać o jej konfigurację.

Uzyskaliśmy właśnie wolumin o pojemności 2 TB, który możemy dowolnie wykorzystać, płacąc jedynie za przestrzeń która zostanie wykorzystana, także w tym momencie nie płacimy zupełnie nic. Dopiero podłączenie do systemu i wykonanie partycjonowania/formatowania powoduje pierwsze zapisy danych.

Przechodzimy teraz do naszego ulubionego systemu operacyjnego, na przykład Windows 2012R2 i dodajemy konfigurację zasobu iSCSI wpisując adres naszego lokalnie zainstalowanego AWS Storage Gateway i klikając “Quick Connect”.

Jeśli wszystko dobrze skonfigurowaliśmy po chwili powinniśmy zastać status “Connected” przy rozpoznanym IQN.

W zakładce “Volumes and Devices” dodajemy jeszcze urządzenie do systemu klikając “Auto Configure” i powinniśmy mieć do niego pełny dostęp z menedżera dysków.

Z menedżera dysków wykonujemy “Rescan”, pojawia się nasz nowy dysk, który najpierw przełączamy w tryb online, następnie wykonujemy inicjalizację i formatowanie w trybie “Quick”.

W efekcie końcowym mamy przygotowany dysk, gotowy do zapisu danych. Reszta odbywa się dokładnie tak samo jak z każdym innym dyskiem twardym.


AWS ze swojej strony udostępnia nam szczegółowe parametry wydajnościowe oraz pojemnościowe poprzez Cloud Watch. Możemy tam śledzić obecne oraz historyczne wartości dla naszego AWS Storage Gateway.

Gateway-Stored

W tym trybie podstawowa różnica polega na przechowywaniu wszystkich danych lokalnie na AWS Storage Gateway umożliwiając wykonywanie jego kopii asynchronicznie do środowiska AWS.
W pozostałych aspektach tryb ten zupełnie się nie różni, jednak warto zauważyć że całą wykorzystywaną przestrzeń alokujemy lokalnie, zatem nie jest to klasyczne rozszerzenie pojemności naszego środowiska ale wykorzystanie możliwości jakie daje AWS w kwestii trzymania kopii zapasowej na zasobach S3. Jednym z podstawowych zastosowań jest zabezpieczenie danych w razie awarii, dając prosty sposób odzyskiwania bezpośrednio z S3 do maszyn wirtualnych AWS EC2.

Gateway-VTL (Virtual Tape Library)

W tym trybie otrzymujemy fantastyczne rozwiązanie w postaci wirtualnej biblioteki taśmowej.
kMożemy w bardzo prosty sposób podpiąć ją do naszego istniejącego systemu kopii zapasowych i powolutku i stopniowo rekonfigurować polityki aby dane nie były składowane lokalnie na taśmach LTO tylko bezpośrednio w chmurze AWS!
Co więcej, składowanie wirtualnych taśm odbywa się na zasobach S3, jeśli jednak mamy pewność że taka taśma powinna zostać zarchiwizowana – jest do tego automatyczny mechanizm przeniesienia do wirtualnego sejfu “Tape-Shelf”. Taśma taka ląduje wtedy na Glacier, jej składowanie jest dużo tańsze, ale rządzi się także zasadami takimi jak Glacier czyli dłuższym czasem dostępu do taśmy (tak jakby przysłowiowy pan Henio leciał do sejfu po tasiemki LTO).
Rozwiązanie dodatkowo fantastyczne, gdyż wysyłając dane do chmury poprzez AWS Storage Gateway, nie płacimy kosztów transferu.
Inaczej jest w drugą stronę, bo już pobranie danych z backupami zostanie policzone jako transfer wychodzący z AWS i wymagać będzie opłaty. Z doświadczenia można stwierdzić że pobieranych danych będzie raczej mało, rzadko będziemy przeprowadzać odzyskania a jeszcze rzadziej weryfikować zawartość wirtualnych taśm. Jest to idealna opcja na start gdy potrzebujemy nasze backupy wynieść Off-Site.

Od strony konsoli zarządzania w zasadzie proces tworzenia AWS Storage Gateway wygląda tak samo do momentu aktywacji, więc jeżeli czytasz od tego miejsca – możesz śmiało przeskoczyć na chwilę do konfiguracji maszyny wirtualnej w części opisującej tryb “Gateway-Cached”. Cała konfiguracja włącznie z dodawaniemy dysków twardych, synchronizacją czasu i testowaniem połączenia do AWS wygląda tak samo. Aktywując mamy do wyboru inne opcje w postaci rodzaju wirtualnego “Media Changer” oraz rodzaju wirtualnych napędów taśmowych.

Dalej podobnie jak w poprzednich rozdziałach konfigurujemy Cache-Storage oraz Upload Buffer. W kolejnym kroku klikamy “Create Tapes” aby utworzyć wirtualne nośniki danych które składowane będą w pierwszej kolejności w Cache-Storage naszego AWS Storage Gateway, następnie przygotowane do wysłania w Upload-Buffer a docelowo trafią na zasoby S3, a w późniejszym terminie mogą trafić na Glacier.

Po zakończeniu dostajemy wesoły komunikat że wirtualne napędy taśmowe wraz ze zmieniarką są już gotowe pod wskazanymi adresami IQN.

W widoku ogólnym naszego AWS Storage Gateway widzimy 4 taśmy w stanie “Active”. W tym momencie konfiguracja po stronie konsoli AWS kończy się.

Podłączanie naszego VTLa należy rozpocząć od konfiguracji targetu iSCSI w naszym ulubionym systemie operacyjnym, na przykład Windows 2012R2.

Jeżeli wszystko poszło dobrze, proces autodiscovery powinien znaleźć IQN name. Dusimy dalej przycisk OK.

Stan oczekiwany to Media Changer oraz napędy taśmowe w stanie “Connected”.

W kolejnej zakładce “Volumes and Devices” dusimy już tylko “Auto Configure”.

W tym momencie konfiguracja systemu operacyjnego kończy się, a rozpoczynamy zabawę z naszym ulubionym systemem kopii zapasowych, jako że nie mam ulubionego – pokażę na przykładzie HP Data Protector’a. Dodajemy zatem nowe urządzenie.

Nazywamy sobie nasze urządzenie, wybieramy rodzaj jako “SCSI Library”, interfejs “SCSI”.

Klikamy “Next” do momentu wyboru rodzaju medium. Wybieramy LTO-Ultrium.

Zapytani o chęć dodania napędów, oczywiście zgadzamy się i przechodzimy do dosyć żmudnego procesu dodawania napędów VTL.

Wybieramy jeden z napędów iSCSI wystawiany przez AWS Storage Gateway. Klikamy Finish… i tak dla kolejnych 9 napędów VTL.

Ponieważ w procesie tworzenia, utworzyliśmy 4 wirtualne taśmy, musimy je teraz wirtualnie “włożyć” do naszego urządzenia VTL. Wybieramy pierwsze 4 sloty i klikamy “Enter”. Spowoduje to załadowanie do tych slotów naszych wirtualnych taśm.

Załadowane taśmy należy w kolejnym kroku sformatować.

Jeżeli wszystko poszło dobrze, taśmy zostaną sformatowane, przy okazji weryfikując poprawne działanie zmieniarki wirtualnych taśm oraz wirtualnych napędów LTO.

W nasz ulubiony sposób tworzymy sobie politykę kopii zapasowej, wybierając jako miejsce docelowe naszą wirtualną bibliotekę taśmową wraz z wszystkimi tapędami które skonfigurowaliśmy na AWS Storage Gateway.

Startujemy backup.

Podczas procesu kopii zapasowych możemy podglądać stan “Upload Buffer” aby upewnić się że dane faktycznie są przesyłane do AWS.

Cieszymy oko w czasie gdy nasze dane powoli ruszają w chmury…

Po zakończonym backupie mamy możliwość wirtualnie wyjąć taśmę z wirtualnej biblioteki taśmowej (wirtualny pan Henio znów rusza w drogę w celu przełożenia wirtualnej tasmy do wirtualnego sejfu). Trafia ona wtedy z zasobów S3 do zasobów Glacier.

Taśma ta pojawia się w zakładce “Virtual Tape Shelf” oznaczona jako zarchiwizowana.

Dokładnie tak jak w poprzednich trybach pracy, statystyki CloudWatch możemy podglądać w czasie rzeczywistym.

Wrota Nieskończoności? AWS Storage Gateway!

Myślę że można tak to poetycko ująć, bo zasobów w AWS mamy bardzo dużo, chmura zawsze dawała nam wrażenie nieskończoności. Jednak należy pamiętać że na koniec miesiąca zawsze przychodzi rachunek.
Warto wesprzeć się specjalistą w sytuacji gdy potrzebujesz podjąć strategiczną decyzję o rozbudowie istniejącego systemu składowania danych czy systemu kopii zapasowych. Nie zawsze warto inwestować w nowy sprzęt, support itp.
Warto patrzeć w stronę rozwiązań chmurowych ale przede wszystkim na opłacalność naszych decyzji. Jeżeli drogi czytelniku dotarłeś do końca, artykuł także wyglądał jakby dążył do nieskończoności, ale liczę że pomoże Tobie w testach i wdrożeniach rozwiązań AWS Storage Gateway w swojej infrastrukturze.