TRANSKRYPCJA WEBINARU

Google Cloud: Co to jest Disaster Recovery Plan?

 

Prowadzący: Piotr Gocłowski

Data: 05.09.2024

 

Dzień dobry, witam wszystkich na webinarze. Nazywam się Piotr Gocłowski i dzisiaj opowiem o Disaster Recovery. Na początek garść informacji organizacyjnych, czyli: webinar będzie nagrywany i udostępnimy go w ciągu 3 dni; pytania poproszę o zadawanie na czacie – postaram się na nie odpowiedzieć w sesji Q&A na koniec.

Tutaj mamy krótką agendę, czyli nasz plan prezentacji dzisiejszej:

• Kim jesteśmy?
• Podstawy Disaster Recovery Plan (DRP): 
  • Definicja i znaczenie DRP, 
  • Kluczowe elementy skutecznego planu DR,
  • Wzorce DRP
  • Usługi Google Cloud, których można użyć do zbudowania Disaster Recovery 
• Scenariusze DR dla:
  • Danych
  • Baz danych
  • Aplikacji
• Najlepsze praktyki
• Sesja Q&A

Dzisiaj opowiem o Disaster Recovery Plan, o scenariuszach, jakie są dostępne, jakich można użyć, najlepszych praktykach. No i oczywiście na koniec sesja Q&A.

Na początek trochę liczb na temat FOTC. Jesteśmy partnerem Google’a w Google Cloudzie, a także Google Workspace. W zeszłym roku otrzymaliśmy tytuł Partnera Roku i pomagamy naszym klientom, wspieramy ich. A jak pomagamy, to właśnie mamy na slajdzie: wspieramy w przygotowaniu migracji, pomagamy tworzyć narzędzia, jesteśmy w stanie zoptymalizować koszty chmurowe. Prowadzimy też szkolenia, warsztaty i oczywiście oferujemy naszym klientom wsparcie techniczne w języku polskim 24/7.

 

Co to jest Disaster Recovery i czym różni się od High Availability?

Przejdźmy więc do podstaw Disaster Recovery. Przykładowe zdarzenia, jakie mogą zakłócić nasze usługi, możemy podzielić z grubsza na dwie kategorie: klęski żywiołowe i katastrofy spowodowane przez człowieka, przez błąd ludzki. Wiadomo, że w naszej szerokości geograficznej znacznie częściej będą to właśnie błędy spowodowane przez człowieka wewnątrz lub na zewnątrz naszej organizacji.

 

 

I właściwie dlaczego warto zastanowić się nad Disaster Recovery Plan i nad takim planem awaryjnym dla naszej infrastruktury czy aplikacji? Otóż małe firmy – to właściwie jest na podstawie badań – małe firmy potrafią stracić na jednominutowej przerwie w świadczeniu usługi nawet do 400 dolarów, średnie przedsiębiorstwa od 5 do 9 tysięcy dolarów, a takie korporacje jak Amazon – no to nawet może dochodzić do setek tysięcy dolarów na minutę. Więc jest, moim zdaniem, po co się schylić.

Ale czym właściwie różni się DRP od HA? Czym właściwie jest HA? Pewnie wielu z nas zada tutaj pytanie. HA to skrót od High Availability, a konkretnie to jest charakterystyka systemu, jego odporność na awarię. Czyli na przykład wyższą dostępność (wyższe HA) będzie miała infrastruktura/system, w którym niektóre komponenty są zdublowane – na przykład dwa serwery, dwie ścieżki, dwa routery. A DRP to tak naprawdę jest takie HA, ale dla szerszej perspektywy, biorąc pod uwagę większe komponenty niż bierze HA – bardziej już całe systemy. A Disaster Recovery Plan to oczywiście plan, jak to wdrożyć, jak to ma zostać przeprowadzone.

 

RPO i RTO – podstawowe parametry Disaster Recovery

Jednym z takich podstawowych aspektów Disaster Recovery są dwa parametry: RPO (Recovery Point Objective) i RTO (Recovery Time Objective). RPO to okres czasu, z jakiego tracimy dane – to wynika z częstotliwości wykonywania kopii zapasowych. Jeśli wykonujemy je bardzo często, no to to RPO będzie krótkie. Przy replikacji baz danych to będzie rzędu nawet sekund, czasami milisekund. Po prostu im częściej ta kopia, tym RPO jest niższe, czyli lepiej dla nas. RTO z kolei to czas przywrócenia naszego systemu do działania po wystąpieniu awarii. Zależy on od tego, z jakich komponentów i usług skorzystamy do budowy DR, bo na przykład z typowej kopii zapasowej, takiej nieprzygotowanej, to RTO będzie bardzo długie, znacznie dłuższe i czasami może nie spełnić naszych celów biznesowych. A z kolei serwer pracujący 24/7 jako taki backup w razie awarii będzie miał najniższe RTO.

 

 

Trzeba pamiętać o ważnej rzeczy, że dobre RTO i dobre RPO równa się niestety duży koszt. Trzeba sobie wyważyć, które aplikacje są najbardziej krytyczne, jaki jest ich priorytet i na podstawie tego ustalić, jakie powinny być te czasy. Bo to nie musi być tak, że dla wszystkich naszych komponentów, serwerów czy aplikacji ustalamy jedno RTO i RPO. Możemy zrobić tak, że sobie podzielimy to, że część workloadów będzie szybciej przywracana i będzie miała częstsze kopie, a część będzie miała trochę mniejszy priorytet.

 

Wzorce Disaster Recovery

Przechodzimy do wzorców Disaster Recovery. Mamy tak ogólnie przyjęte trzy – oczywiście w zależności od literatury, od źródeł, różne firmy różnie to nazywają – ale w zasadzie Google wyróżnia trzy: 

• cold, 
• warm
• oraz hot. 

W przypadku wzorca cold można sobie wyobrazić: podróżujemy, łapiemy gumę, ale nie mamy koła zapasowego i niestety nasza podróż jest przerwana do czasu przybycia pomocy, na przykład serwisu wulkanizacji. Wzorzec warm z kolei – mamy koło zapasowe, nasza podróż jest przerwana tylko na chwilę i możemy ją kontynuować, jak tylko wymienimy zapas. Wzorzec hot – to sytuacja, w której mamy opony typu run-flat i po przebiciu można dalej kontynuować podróż przez jakiś czas, powiedzmy z mniejszą prędkością.

 

Co wziąć pod uwagę, tworząc plan DR? 

Przede wszystkim musimy projektować zgodnie z celami biznesowymi, czyli na początku określamy priorytety aplikacji, workloadów, serwerów i ustalamy na tej podstawie RTO i RPO. Możemy wtedy wybrać odpowiednie usługi i strategię. 

Musimy zbudować ten plan w taki sposób, aby on określał wszystkie kroki – od A do Z – żeby nie pominąć żadnego kroku, bo w sytuacji krytycznej jest to bardzo ważne i nie ma miejsca na błędy. Konkretne, jasne określenie zadań i instrukcji jest również istotne, bo w sytuacji krytycznej nawet jakieś małe niejasności potrafią utrudnić działanie. 

Zdecydowanie warto, aby częścią planu były działania kontrolne i zaradcze. Chodzi o opomiarowanie naszej aplikacji, workloadu czy serwera w taki sposób, abyśmy byli w stanie wcześniej widzieć, co się tam dzieje – jakie są czasy odpowiedzi, czy występują jakieś błędy. Możemy ustalić krytyczne metryki i logi, i na ich podstawie zbudować na przykład alerty. Pozwoli to trzymać rękę na pulsie, ale też po prostu czasami pozwoli uniknąć jakiejkolwiek awarii i przełączania.

 

Przygotowanie oprogramowania

Przygotowanie oprogramowania to jest dosyć często pomijany aspekt. Zdarza się, że gdy korzystamy na przykład on-premise z jakichś licencji, na przykład systemów operacyjnych, to licencja nie pozwala na uruchomienie takich workloadów w środowisku innym niż on-premise. No i to właśnie trzeba sprawdzić, żeby się upewnić. 

Kolejny aspekt, który zdecydowanie warto uwzględnić w planowaniu, to aktualne pipeline’y CI/CD. Warto po prostu trzymać artefakty aplikacji, takie jak obrazy systemów operacyjnych czy obrazy aplikacji skonteneryzowanych, w miejscu, gdzie nasze środowisko DR ma dostęp. W przypadku Google’a jest to na przykład Artifact Registry.

 

Wdrażanie kontroli bezpieczeństwa i zgodności

Bezpieczeństwo i zgodność – należy pamiętać, aby dostęp do środowiska DR był taki sam jak dla środowiska produkcyjnego. Jest to bardzo istotne, aby nasi deweloperzy, programiści, DevOpsi czy administratorzy mieli tam dostęp. 

Weryfikacja bezpieczeństwa – musimy się upewnić, czy te osoby mają dostęp oraz czy nasza aplikacja jest tak samo skonfigurowana jak w środowisku produkcyjnym pod kątem bezpieczeństwa. 

Szkolenie użytkowników – jest to środek zaradczy, żeby w razie wystąpienia zdarzenia przerywającego łatwiej poszło wdrożenie planu. 

Oczywiście, jeśli organizacja musi spełnić jakieś wymogi compliance w odniesieniu do frameworków czy standardów bezpieczeństwa, no to też trzeba to uwzględnić, wybierając odpowiednie usługi i odpowiednio je konfigurując.

Traktujmy dane odzyskane w środowisku DR tak samo, jak gdyby były danymi produkcyjnymi, czyli musimy stosować wszelką ochronę danych poufnych czy wrażliwych.

 

Transfer danych do i z Google Cloud

Kolejnym elementem budowania planu jest rozważenie sposobu komunikacji pomiędzy naszym środowiskiem produkcyjnym a środowiskiem w DR. 

Warto odpowiedzieć sobie na kilka pytań: 

• W jaki sposób łączymy się z Google Cloudem? 
• Jaka jest przepustowość aktualna, a jaka wymagana? 
• Jaka jest przepustowość dostarczana przez dostawcę? 
• Czy dane mają być szyfrowane? 
• Czy wszystkie dane będą przesyłane tym łączem? 

Generalnie może się okazać, że nie potrzebujemy połączenia bezpośredniego sieciowego, takiego jak VPN albo Interconnect, ponieważ w przypadku Google Cloud wszystkie API są dostępne publicznie i jest tam kontrola dostępu, więc korzystanie z nich jest niemal tak samo bezpieczne.

 

Implementacja wielopoziomowego storage

 

Jeśli chodzi o storage, warto zapisać sobie w głowie, jak to mniej więcej wygląda. Jeśli tworzymy kopie zapasowe, to idąc od lewej strony do prawej, widzimy, że koszt maleje, ale niestety wydłuża się czas odzyskiwania danych. W przypadku gdy trzymamy kopie zapasowe na dyskach wirtualnych podpiętych pod maszynę wirtualną pracującą, no to powrót do działania będzie najszybszy, ale koszt utrzymania tego dzień po dniu będzie najwyższy. Idąc w prawo, ten koszt spada – na przykład Cloud Storage klasy Standard będzie już sporo tańszy, ale trzeba doliczyć czas – dłużej będzie trwało odzyskiwanie danych.

 

 

Usługi Google Cloud, których można użyć do budowania Disaster Recovery

Tutaj wymieniłem najważniejsze komponenty i usługi Google Cloud, których można użyć do budowania Disaster Recovery: Compute Engine, GKE, Cloud Storage, Cloud DNS, Cloud VPN. Są to usługi, w których możemy uruchamiać własne aplikacje i systemy.

 

 

Weryfikacja planu DR

Jak już mamy nasz plan zrobiony zgodnie z najlepszymi praktykami, niestety trzeba go przetestować i zweryfikować. Musimy sprawdzić, co się stanie, jeśli nasza podstawowa ścieżka dostępu do środowiska DR zostanie przerwana – na przykład z naszego biura podstawowy dostęp zostanie wycięty.

Automatyzujmy jak najwięcej – my zalecamy skorzystanie z narzędzi Infrastructure as Code, takich jak Terraform. Umożliwi to automatyzację i dzięki temu zmniejszy ryzyko błędu ludzkiego oraz pozwoli łatwiej testować, bo możemy takie środowiska stawiać za pomocą jednej komendy. 

Monitorujmy środowisko za pomocą usług/produktów własnych lub Cloud Operations Google’a. No i testujmy regularnie – sprawdzajmy, czy wszystkie wymagane osoby mają odpowiednie uprawnienia i dostęp, wykonujmy testy penetracyjne, miejmy jakąś zapasową ścieżkę łączności z chmurą, na przykład przez sieć komórkową bądź zapasowe łącze fizyczne/optyczne, żeby móc obsługiwać środowisko zapasowe.

 

Scenariusze Disaster Recovery dla danych

 

Tworzenie kopii zapasowych w Google Cloud. 

Możemy do tego użyć narzędzia gcloud (CLI). Odbywa się to w ten sposób, że najpierw instalujemy to narzędzie, uwierzytelniamy się, nadajemy uprawnienia i wykonujemy komendę gcloud storage cp itd. Miejsce źródłowe to nasz lokalny dysk/zasób, a miejsce docelowe to zasobnik Cloud Storage. 

 

 

Oczywiście musimy to przetestować. Warto skorzystać z narzędzi do wykonywania zgodnie z harmonogramem – na Linuxie możemy użyć crona do wykonywania takiej komendy; na Windowsie będzie to na przykład harmonogram zadań. Odzyskiwanie danych odbywa się tak samo. Nie musimy robić jakiegoś harmonogramu – wystarczy mieć to udokumentowane, że w danym buckecie taką a taką komendą można pobrać te kopie zapasowe.

 

Usługa Storage Transfer Service

To jest usługa zarządzana, gotowa; umożliwia tworzenie kopii zapasowych za pomocą agenta zainstalowanego na naszych maszynach. Obsługujemy to z poziomu konsoli Google Cloud, więc jest to dość wygodne i intuicyjne. 

 

 

Wspierane źródła i miejsca przeznaczenia widać po lewej stronie – mamy nasz system plików POSIX i po drugiej stronie Google Cloud Storage. Możemy to wykonywać w interwałach czasowych (batch) albo na podstawie zdarzeń (event) – na przykład zmieniły się jakieś pliki i wtedy dane będą się kopiowały.

 

 

Scenariusze DR dla baz danych

 

Kopia zapasowa Google Cloud (wzorzec cold)

Rozwiązanie numer jeden nawiązuje do wzorca cold. W skrócie: tworzymy kopię zapasową bazy danych, możemy połączyć on-premise z Google Cloud przez VPN lub nie – zależy jakie są potrzeby i wymagania bezpieczeństwa. Tworzymy zasobnik Cloud Storage i przesyłamy kopię bazy danych do Cloud Storage za pomocą tych samych narzędzi, które zostały omówione na poprzednich slajdach. To samo robimy z transakcyjnym logiem danych (kopiujemy do Cloud Storage). 

 

 

Poniżej mamy pokazane, w jaki sposób możemy uruchomić zapasowy serwer bazy danych w środowisku Google Cloud: 

 

 

Zaczynamy od utworzenia customowego obrazu maszyny wirtualnej, tak aby była ona zgodna z maszyną produkcyjną, przesyłamy kopię do Cloud Storage, uruchamiamy VM na podstawie tego obrazu, wykonujemy kopię logu transakcyjnego i aplikujemy ją do bazy danych. Na koniec przełączamy klientów poprzez zmianę rekordu DNS albo w inny własny sposób, na przykład poprzez zmianę adresu IP w konfiguracji aplikacji. 

Tutaj mamy z kolei wzorzec cold i powrót na produkcję:

 

 

Podobnie jak przy wszelkich takich pracach serwisowych, mamy kolejność po prostu odwrotną. Teraz musimy wykonać kopię zapasową bazy, która pracuje w środowisku Disaster Recovery, musimy odtworzyć tę kopię w środowisku produkcyjnym, zablokować ruch do Disaster Recovery (do środowiska DR), wyeksportować log transakcyjny, przesłać do bazy produkcyjnej i na koniec przekierować klientów z powrotem na produkcję. Czyli tak samo, tylko odwrócone te kroki.

 

Replikacja do czuwającego serwera w Google Cloud (wzorzec warm)

 

Tutaj już powoli wchodzimy w środowisko już na poziomie bardziej cieplejszym – wzorzec warm. A konkretnie w tym scenariuszu korzystamy z replikacji baz danych. Możemy zastanowić się, czy potrzebujemy mieć połączenie typu VPN/Interconnect. Nie jest to wymagane, ale jeśli są jakieś wymagania zgodności i tak dalej, no to to wymusza wybranie VPN-u albo Interconnectu. 

 

 

Tworzymy obraz serwera bazy danych (też musi być zgodny z tym serwerem produkcyjnym). Uruchamiamy instancję maszyny wirtualnej na podstawie tego obrazu i konfigurujemy replikację. 

W standardowym trybie działania klienci serwowani są do naszego on-premisu bądź innego dostawcy takich usług, a w razie wystąpienia awarii przekierowujemy się na serwer bazy danych dostępny w środowisku DR. No i oczywiście musimy pamiętać, aby ta baza danych została przekształcona na mastera (tryb pracy z możliwością zapisu), ponieważ zwykle read repliki baz danych pracują tylko do odczytu.

 

Scenariusze Disaster Recovery dla aplikacji 

 

Wzorzec cold

Pierwszy scenariusz to wzorzec cold. Mamy aplikację i bazę danych. Możemy mieć połączenie hybrydowe, ale to wszystko może też iść po publicznych API, w zależności od wymagań. Możemy utworzyć customowy skrypt, który będzie wysyłał dane do zasobnika Cloud Storage. Podobnie z bazą danych – możemy te dane wysyłać do zasobnika. I tak to wygląda. 

Potem na podstawie tych danych możemy postawić serwer aplikacyjny i oczywiście musi być tak skonfigurowany, aby pobierał sobie z tego bucketu dane odzyskane. Dotyczy to zarówno maszyny aplikacyjnej, jak i bazodanowej. No i oczywiście wcześniej warto sobie przygotować obraz systemu, tak żeby można było szybciej uruchomić maszynę wirtualną w razie awarii.

 

 

Tak, tutaj mamy ten sam wzorzec cold, ale tu jest pokazane, jak to wygląda w sytuacji awarii. Wrócę do poprzedniego jeszcze slajdu, żeby pokazać różnice. Tutaj jest ruch serwowany na on-premise, ale nie ma z kolei żadnych serwerów postawionych. Tu z kolei jest awaria i ruch jest przekierowany na środowisko DR w chmurze. Widzimy, że te serwery (web serwer, serwer aplikacyjny, serwer bazodanowy) zostały odtworzone na podstawie kopii zapasowych trzymanych w Cloud Storage. 

 

 

No i my tutaj zalecamy mocno, żeby skorzystać z Terraform lub innych narzędzi Infrastructure as a Service, żeby można było łatwo zautomatyzować to. Czyli na przykład wydarza się awaria i albo automatycznie, albo ręcznie wdrażamy to środowisko DR. Wiadomo, że automatycznie jest zawsze przyjemniej, no ale wywołanie jednej komendy też nie jest jakimś wielkim wielką pracą. Tak, no i tutaj oczywiście Cloud DNS musi podmienić rekord A bądź rekord 4A, w zależności od tego, jaki adres IP będzie docelowy, żeby ten ruch przekierować.

 

Wzorzec warm

Tak, tutaj dalej mamy już wzorzec warm czyli idziemy krok dalej. Aplikacja tworzy kopie zapasowe w Cloud Storage (nie ma go akurat pokazanego), ale jednocześnie mamy rozkręcone dwie maszyny wirtualne, które odzwierciedlają systemy operacyjne on-premisowe. Mamy też tutaj skonfigurowaną replikację bazy danych – może być przez VPN, Interconnect albo bezpośrednio po publicznym adresie IP. W tym wzorcu będzie szybciej, dlatego że te obrazy są już gotowe. 

 

 

W razie awarii (czy to skryptem terraformowym, czy w jakiś inny sposób, czy nawet narzędziami gcloud) możemy automatycznie wyzwalać tworzenie docelowych maszyn wirtualnych o docelowym rozmiarze, które byłyby w stanie obsłużyć ruch. To też wynika z optymalizacji kosztów, bo tutaj możemy trzymać maszyny wirtualne mniejsze, które na co dzień nie pochłoną bardzo dużo środków, a tutaj możemy na podstawie tych maszyn utworzyć większe maszyny obsługujące ruch. I tak samo należy pamiętać o bazie danych, o tym, żeby baza danych została awansowana na mastera i była w stanie po prostu zapisywać dane.

 

Wzorzec hot

Ostatni wzorzec to hot dla aplikacji. Polega on na tym, że na stałe mamy uruchomioną infrastrukturę zapasową w DR, która pracuje cały czas. Wiąże się to z wyższymi kosztami, ale w razie sytuacji awaryjnej wystarczy zmiana wag w DNS-ach, aby przekierować ruch do naszej aplikacji w czasie propagacji DNS. Cloud DNS Google’a jest w stanie dosyć szybko zmienić te wagi. Domyślnie, z wyższą wagą mamy dostęp do web serwera do aplikacji na on-premise, a do środowiska zapasowego z mniejszą wagą. W tym scenariuszu baza danych może być w Google Cloud, ale nie musi – to zależy od połączenia i dostępności bazy w pierwotnym środowisku.

 

Podsumowanie

No i na koniec takie ogólne wskazówki, podsumowanie tych rzeczy, które dzisiaj powiedziałem. Robiąc taki plan DR musimy określić RTO i RPO per system. Nie musi być tak, że wszystko ma jednakowo duży priorytet, bo to będzie drogie i nieefektywne. Możemy sobie wybrać najważniejsze aplikacje, które będą miały najlepsze czasy RTO i RPO. Musimy określić odpowiednio zależności systemu i aplikacji, tak żeby to co trafi do środowiska DR było kompletne i umożliwiało pracę wszystkich komponentów. Musimy dobrze poznać, jakie są wzorce DR, aby być w stanie wybrać odpowiednie usługi, no bo od tego zależą te czasy RTO i RPO. Musimy wykonywać regularne testy, bo testy są niezbędne. Tak samo jak przy produkcji oprogramowania – jeśli czegoś nie przetestujemy, no to tak naprawdę nie wiemy, jak i czy to działa. Dostęp i bezpieczeństwo, czyli uprawnienia do środowiska dla wszystkich interesantów, którzy muszą mieć, no i oczywiście bezpieczeństwo, czyli ochrona firewallami i tak dalej. No i oczywiście na koniec niemniej ważne: zdefiniowanie sposobu wdrażania środowiska DR w GC. Czy to będzie Terraform, czy to będą skrypty gclouda, czy po API, czy jakoś inaczej – my oczywiście rekomendujemy automatyzację tego kroku.

Jako FOTC polecamy się przy takich zadaniach. Mamy usługę Disaster Recovery i możemy pomóc w dopasowaniu odpowiednich rozwiązań. Możemy administrować taką infrastrukturą, pomóc w utworzeniu Disaster Recovery Plan, a także pomóc we wdrożeniu tego planu w praktyce.

I to wszystko, co dzisiaj przygotowaliśmy. Także teraz przejrzę sobie pytania na czacie i zobaczę, czy jestem w stanie na coś odpowiedzieć. Przy okazji, gdyby ktoś miał pytania lub cokolwiek, chciałby się z nami skontaktować, no to mamy tutaj dwa adresy podane na tym slajdzie: sales@fotc.com i cs@fotc.com. 

 

Sesja Q&A

P: Czy dobra praktyka mówi jak często testować taki plan?

Odpowiedź prowadzącego: Tak, jak najbardziej warto to robić regularnie, czyli raz w miesiącu albo tak często, jak coś się zmienia w naszej infrastrukturze. To jest moim zdaniem minimalna częstotliwość testów. Czyli gdy coś się zmienia w środowisku produkcyjnym, to wtedy warto przeprowadzić testy. A jeśli nic się nie zmienia, no to warto też mieć stały interwał, może trochę rzadszy, tak żeby ta wiedza w zespole, który jest za to odpowiedzialny nie uciekła, nie skorodowała. 

P: Jak to wszystko ma się do NIS2? Widzę tu dużą zgodność z politykami normy ISO 27001…

Odpowiedź prowadzącego: Sam Google Cloud jest zgodny z ISO 27001, z NIS2 też. Ale zgodność Google’a, a zgodność tego, co my mamy w Google’u – to są dwie różne rzeczy. I to trzeba po prostu sprawdzić. Trzeba mniej więcej znać jaki jest framework, jakie tam są wymagania względem infrastruktury i po prostu wtedy trzeba o to dbać. My niebawem będziemy mieli taką usługę, która pozwoli monitorować zgodność z frameworkiem, ale to na razie jeszcze jest w takiej fazie powiedzmy mocno beta, więc za jakiś czas coś się pojawi, ale jeszcze nie teraz. Po prostu trzeba znać te frameworki, żeby po prostu być w stanie sprawdzać zgodność z nimi naszej infrastruktury. 

 

P: Czy wiesz może, czy usługi Google Cloud pokrywają się w miarę z AWS-em, aby można było zrobić DR Multi-Cloud z podobną logiką?

Odpowiedź prowadzącego: Tak, jak najbardziej. Praktycznie da się użyć wszystkich tych scenariuszy w chmurze AWS. Oczywiście my rekomendujemy Google Cloud, ale jak najbardziej są to usługi działające niemal identycznie. Mało tego, można mieć nawet dwa środowiska DR – zarówno w Google Cloud, AWS, i w Azure pewnie też. Ponieważ mamy tam EC2 (odpowiednik Compute Engine), mamy VPN-y, mamy S3 (odpowiednik Cloud Storage), więc jak najbardziej można. 

Czas nam tutaj już doszedł do końca, więc będziemy powoli kończyć. Jeśli by się pojawiły jakieś pytania, to zapraszam do kontaktu na te dwa maile: sales@fotc.com i cs@fotc.com. Koledzy na pewno przekierują to do nas, gdyby to były pytania techniczne. Jeszcze raz bardzo dziękuję za przybycie, za wysłuchanie i życzę dobrego dnia, dobrego weekendu, cześć.