Mieszane środowisko chmurowe nie musi być przeszkodą w zapewnianiu ciągłości pracy. Warunkiem jest, że administratorzy stworzą odpowiednie plany awaryjne i będę wiedzieli, jak pod tym kątem optymalnie wykorzystać posiadane zasoby. Paradoksalnie, chmura hybrydowa może stać się sprzymierzeńcem działu IT w ochronie przed skutkami awarii. Ta architektura ma kilka istotnych zalet od strony wdrażania mechanizmów disaster recovery oraz zapewniania ciągłości pracy.

Po pierwsze, przywracanie po awarii staje się znacznie tańsze, a same procedury mogą być bardziej elastyczne i łatwiejsze do przeprowadzenia. Wiele firm widzi wręcz chmurę publiczną jako sposób na wdrożenie planów przywracania po awarii lub jako uzupełnienie czy udoskonalenie istniejących planów disaster recovery. Infrastruktura dostępna z chmury publicznej umożliwia potencjalnie ograniczenie sprzętu potrzebnego do uruchomienia nowych ośrodków obliczeniowych w rozproszonych geograficznie lokalizacjach. Zamiast budować od podstaw nowe centrum przetwarzania danych, można do tego celu wykorzystać dostawcę chmury publicznej. Idącym tym tokiem rozumowania, firmy mogą zrezygnować z duplikacji infrastruktury swojego centrum danych, jednocześnie zachowując wszelkie możliwości związane z przywracaniem po awarii. To przekłada się na znaczną redukcję kosztów.

Zobacz również:

• Wydatki na chmurę wzrosną w tym roku
• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24

Niestety rzadko zdarza się, żeby operator chmury publicznej wykorzystywał sprzęt i oprogramowanie w tej samej konfiguracji, co potencjalny klient. Tymczasem jest to bardzo istotny element, któremu należy się bliżej przyjrzeć. Potencjalny klient musi w pierwszej kolejności zmierzyć się właśnie z tym wyzwaniem. Nawet jeśli w obu podmiotach pracuje taki sam stos wirtualizacji, konfiguracje raczej będą różnić się od siebie. A przenoszenie aplikacji do odmiennego środowiska wymaga dokładnego przemyślenia.

Skoro chmury publiczne i prywatne różnią się od siebie, jak można je połączyć w jedno środowisko? Firmy radzą sobie z tym problemem na różne sposoby. Po pierwsze, używa się jednej serwerowni jako podstawowego, produkcyjnego ośrodka, a drugiej jako zapasowego. Inny sposób zakłada uruchomienie kilku lokalizacji, z których każda działa jako podstawowa dla obsługiwanego przez siebie regionu, a przechodzi w tryb zapasowy, gdy w danym regionie kończą się godziny pracy. Ta metodologia wymaga od korporacji myślenia o tym, który ośrodek staje się podstawowym, który zapasowym i jak następuje przełączanie pomiędzy nimi. Wymusza także bardziej skrupulatne podejście do efektywnego i spójnego przenoszenia obciążeń pomiędzy ośrodkami.

Przełączenie z chmury prywatnej do publicznej w momencie wystąpienia awarii wymaga dokładniejszego planowania, które uwzględnia nie tylko aplikacje, ale także powiązane z nimi zasoby plikowe (dane). Wymaga to, m.in. kompleksowych profili sieciowych wskazujących, co jest pamięcią masową, co jest punktami komunikacji dla ruchu wchodzącego i wychodzącego generowanego przez klientów oraz partnerów biznesowych. Nowoczesne aplikacje chmurowe mogą mieć odpowiednie mechanizmy już wbudowane. Starsze aplikacje i inne zasoby będą raczej wymagać stosowania dodatkowych rozwiązań, jak połączenia VPN lub frame relay, aby mogły działać po przeprowadzeniu procedury disaster recovery. W efekcie wdrożenie takich mechanizmów komplikuje się.

Zasoby, które łączą ze sobą chmurę prywatną i publiczną (m.in. łącza sieciowa) nie zawsze podlegają kontroli korporacyjnych działów IT. Gdy dojdzie do wydarzeń oddziałujących na duży obszar bądź infrastrukturę publiczną (powódź, silne wiatry), przełączenie między chmurą prywatną a publiczną może stwarzać dodatkowe wyzwania. Jednakże są sposoby, że poradzić sobie również z tym problemem. Pierwszym jest korzystanie z łączy o dużej przepustowości i stała replikacji danych oraz aplikacji. Dzięki temu aplikacje i dane są w każdej chwili aktualne również w lokalizacji zapasowej. Dodatkowo, jeżeli prognozuje się wystąpienie wspomnianych zjawisk, administrator może zawczasu przenieść dane, bez nadmiernego wykorzystania dostępnej przepustowości. Można nawet pokusić się o fizyczne przeniesienie danych do chmury publicznej, zamiast przesyłania ich przez sieć.

Zbiór dobry praktyk może pomóc administrator w jeszcze lepszym wykorzystaniu chmury hybrydowej w zakresie ochrony przed awarią. Pierwszą wskazówką jest: skupić się na danych. Aplikację można odtworzyć czy replikować ją między lokalizacjami. Jeśli jednak nie ma ona dostępu do danych, pozostanie bezużyteczna. Tu z pomocą przychodzą technologie wydajnej replikacji danych. Dodatkowo, warto przy okazji wdrażania nowych aplikacji wybierać te, których architektura jest przystosowana do działania w chmurze hybrydowej. Dla takich aplikacji znacznie łatwiej wdraża się mechanizmy disaster recovery.

Należy również pamiętać, że uruchomienie zapasowej lokalizacji nie sprowadza się do replikacji danych. Ważnym elementem jest zapewnienie identycznego sposobu działania aplikacji w obu ośrodkach: produkcyjnym i zapasowym. Aby to osiągnąć, trzeba dobrze zrozumieć, jaka jest architektura chmury publicznej. Nie można też zapomnieć, że chmura publiczna również może ulec awarii. Korzystając z niej, warto więc sprawdzić, jaki poziom niezawodności oferuje dany operator. Jednak kluczowym czynnikiem planów DR, który zapewnia ich udane działanie, są regularne testy. W ten sposób można ustalić, czy chronione są właściwe zasoby i czy procedury działają zgodnie z planem.