Chmura hybrydowa obrosła legendami… bardzo… za bardzo.
Każdy ma swoją definicję chmury hybrydowej.
Niestety…
Niestety…. najwięcej o chmurze hybrydowej mówią duzi producenci sprzętu i rozwiązań dla Data Center.
Niestety to od nich rodzi się najwięcej zamieszania. Chmura hybrydowa jest dla nich kolejną możliwością do sprzedaży kolejnych serwerów, macierzy, przełączników.
W dzisiejszym artykule wyjaśnię Ci wszystko co chciałbyś wiedzieć o chmurze hybrydowej. No może prawie wszystko.
Zaczynamy.

Czym Jest Chmura Hybrydowa?

Definicji jest wiele. Całkiem dobra jest definicja NIST. Pozwól, że przedstawię Ci moją.

Chmura hybrydowa, to środowisko, które jest uruchomione częściowo na zasobach przynajmniej jednej chmury publicznej.

To tyle.
Koniec artykułu….
Ale czym jest to środowisko? Właśnie tu pojawia się najwięcej wątpliwości.
Ważne: Dla uproszczenia używać będę opisów, gdzie rozważamy środowisko zbudowane z chmury publicznej i Twojego własnego Data Center. Możesz to zastąpić kombinacjami:

• Data Center – chmura publiczna
• Kolokacja – Chmura Publiczna
• Chmura Publiczna – Chmura Publiczna

Środowisko – Czyli Jedna Aplikacja

Nirvana.
Coś o czym mówią prawie wszyscy. Coś niemalże niespotykanego w rzeczywistości. Posiadamy aplikację A. Część środowiska uruchomione jest w Twoim Data Center, cześć w chmurze publicznej.
W Polsce bardzo popularne jest wdrożenie Onet, na świecie wdrożenie Auth0.
Mamy dwa główne sposoby rozrzucania ruchu na środowisko A i B:

1. DNS
2. Load Balancer

DNS

W tym modelu utrzymujemy dwie kopie środowiska. Posiadamy też inteligenty serwer DNS (Amazon Route 53, Azure Traffic Manager). Dbamy o to, aby bazy danych były zsynchronizowane. Dbamy, aby serwer aplikacyjny miał tą samą wersję aplikacji.
Użytkownicy w zależności od X (położenie geograficzne, ustawienia, pora dnia, polityka ruchu) trafiają do chmury publicznej lub Twojego Data Center.

Brzmi i wygląda pięknie, jednak synchronizacja baz danych jest wyzwaniem. Szczególnie baz relacyjnych. Prościej mają firmy, które wykorzystują rozwiązania ala Casandra. Firmy, które posiadają formę uniezależnienia się od warstwy serwerowej, np. używając Mesos, mają jeszcze prościej.
Takich firm jest jednak bardzo mało. Do synchronizacji często używane są rozwiązania firm trzecich:

• DoubleTake
• CloudEndure
• Zerto
• Racemi
• RiverMeadow
• AppZero

Load Balancer

Padnijcie na kolana, oto BURSTING.
Ruch wpada do głównego Data Center nad Load Balancer. Załóżmy, że w DC mamy 30 serwerów aplikacyjnych. Nagle pojawia się reklama w telewizji i więcej osób pragnie użyć Twojej aplikacji.
30 serwerów okazuje się za mało. Odpowiednia polityka load balancera przekierowuje nadmiar ruchu do chmury. W chmurze serwery skalują się od 0 do setek, aby obsłużyć Twój ruch. Korzystamy z głównej bazy danych, albo dokonujemy replikacji bazy do chmury.

Spotkałem się raz z takim rozwiązaniem na produkcji. Raz go też rekomendowałem do pewnego wdrożenia. Niestety nie wiem, czy projekt dobiegł końca, czy też nie.
Rozwiązanie jest trudne do wdrożenia. Wymaga panowania nad synchronizacją, panowania nad łączem, panowanie nad opóźnieniami, panowanie nad konfiguracją load balancera.
Dostawcy systemów zarządzania i orkiestracji oferują narzędzia, które w prosty sposób pomagają w migracji maszyn pomiędzy środowiskiem lokalnym a chmurą publiczną. Metoda ta dobrze się spradza jeżeli przygotowujemy się do większej ilości ruchu. Znane narzędzia, które mają połączenia z chmurą publiczną to między innymi:

• VMware vCenter
• VMware vRealize Automation
• Microsoft System Center Operations Manager
• Microsoft System Center Orchestrator

Środowisko – Czyli Środowisko Test/Dev

Programiści powołują serwery na żądanie w chmurze. Standardowo, albo np. przy użyciu Vagrant. Budują, testują, naprawiają. Gotowy kod jest wrzucany na produkcję w lokalnym Data Center.
Posiadamy dwa niezależne środowiska. Jedno służy do produkcji, drugie służy do wszystkiego przed produkcją.

Często spotykane rozwiązanie. Coraz częściej spotykane z wykorzystaniem kontenerów. Kontenery w prosty sposób uniezależniają nas od tego co niżej (nie ma znaczenia czy Linux stoi na VMware, Bare Metal czy też Xen Server).
Nadal często używane w standardowym modelu wirtualnych maszyn. Środowisko test i development powoływane jest w chmurze w ramach potrzeb. Produkcja trzymana jest nadal w DC (z różnych niezrozumiałych przyczyn). W momencie, gdy programiści pracują przez 40 godzin tygodniowo, środowisko może być wyłączane na noce i weekendy, dodając oszczędności.

Środowisko – Czyli Aplikacje z Poprzedniej Epoki

Sytuacja podobna jak przy środowisku Test/Dev. Część aplikacji, których nikt nie chce ruszyć, zostają w lokalnym Data Center lub kolokacji. Czekają na młodych i odważnych.
W tym czasie budowane są nowe środowiska w chmurze, często łączące się do aplikacji z poprzedniej epoki przez różnego rodzaju szyny i gumo-klejo-zapałki.

Aplikacje-z-poprzedniej-epoki mają różne definicje u różnych dyrektorów IT. Dla części z nich jest to aplikacja, o której krążą legendy i każdy w firmie zapomniał hasła dostępu (nikt nie chce być z nią kojarzony) Dla części z nich jest to każda aplikacja, która powstała przed 2015 rokiem (“soły batoły, ale nie poświęcę swojej kałieły”). Dla części z nich jest to aplikacja wymagająca sprzętu/systemu, który nie jest wspierany przez żadnego z dostawcy chmury (np. Oracle RAC). Dla części z nich jest to system, który z przyczyn politycznych, bezpieczeństwa (nie wierz w to), integracji, nie mogą być w prosty sposób przeniesione.

Środowisko – Czyli Disaster Recovery Center

Disaster Recovery Center. Główny ośrodek przestaje odpowiadać. Po określonej decyzji następuje manualne lub automatyczne przełączenie na ośrodek zapasowy.
Chmura nadaje się do tego perfekcyjnie i w Polsce można znaleźć przynajmniej kilkanaście wdrożeń tego typu. Dlaczego chmura jest tak popularna?
Nie płacimy za przestrzeń, prąd, serwery, przełączniki, macierze, a jedynie za miejsce na dyskach i (ewentualnie) uruchomione zasoby w momencie przełączenia. Opłacalne nawet dla niedowiarków.

DRC – Zapałka

W modelu zapałki robimy backup serwerów i danych np. raz na dobę. Dane są umieszczane w chmurze. W momencie awarii, backup jest odtwarzany w chmurze.
RPO (Recovery Point Objective) w naszym wypadku wynosi maksymalnie 24 godziny. RTO (Recovery Time Objective) zależy od czasu w jakim uruchomimy dane z backupu, zmienimy ewentualne procesy biznesowe i przekierujemy ruch na zapasowe Data Center w chmurze. Mogą to być godziny, a nawet dni.

BARDZO popularna, prosta i opłacalna kosztowo metoda. Jeżeli RPO i RTO nie jest krytyczne, możemy skorzystać z tej metody, zapewnić określoną formę bezpieczeństwa biznesowego i mieć zabezpieczenie w razie awarii.

DRC – Iskra

W modelu iskry posiadamy krytyczną część środowiska zsynchronizowaną z produkcją. Najczęściej jest to baza danych, ewentualnie ważne pliki. Serwer aplikacyjny może być nadal backup-owany. W momencie awarii, odtwarzany jest tylko serwer aplikacyjny.
RPO może kilkuminutowe lub kilkugodzinne, w zależności jak często zmieniamy dane aplikacyjne. RPO zależy też od rodzaju synchronizacji danych. RTO może trwać kilka godzin lub nawet kilka dni.

Również popularna metoda. Często oprócz bazy danych, synchronizowane są serwery Active Directory. Pozostałe maszyny są kopiowane, np. przy użyciu rozwiązań firmy Veeam lub wspomnianego już rozwiązania Double Take. Czas odtwarzania środowiska zależy od wielkości tegoż środowiska oraz procedur technicznych i biznesowych.

DRC – Mały Ogień

Moja ulubiona forma DRC. Można ją łatwo pomylić ze środowiskiem – Jedna Aplikacja (DNS). Jest to faktycznie coś podobnego, z tym wyjątkiem, że w DRC uruchamiamy minimalne środowisko.
Jeżeli posiadamy w DC 30 serwerów, w DRC możemy mieć uruchomiony np. 1 serwer. Bazy, pliki, kod są synchronizowane. W momencie awarii uruchamiane są skrypty, które powiększają środowisko w chmurze. Część dostawców chmur pozwala w prosty sposób zwiększyć ilość instancji oraz zwiększyć wydajność baz danych.
RPO i RTO może osiągać pojedyncze minuty i w głównej mierze zależy od szybkości przełączania DNS oraz od szybkości skalowania środowiska w DRC.

Metoda ta ma jeden ukryty plus. Możemy na bieżąco sprawdzać poprawność działania środowiska DRC. W modelu zapałki i iskry, firmy często nie decydują się na regularne testy DRC. W tym modelu środowisko w DRC jest non-stop dostępne. Możemy więc je sprawdzać manualnie lub automatycznie na bieżąco i być gotowym na awarię.
Możesz znaleźć wiele narzędzi do synchrnonizacji danych pomiedzy DC a DRC w chmurze. Oprócz wspomnianych wcześniej (Dobulbe Take jest moim ulubionym), używa się sprawdzonych metod synchronizacji.

• Windows Server Failover Cluster i Log Shipping (MSSQL)
• Active Data Guard (Oracle DB)
• Mysqlreplicate (MySQL)
• Postgre-R/BRD (PosgreSQL)
• NetApp SnapMirror (MSSQL, Oracle DB)
• Attunity Cloudbeam (MSSQL, Oracle DB, MySQL)
• Informatica (MSSQL, Oracle DB, MySQL)
• Oracle GoldenGate (Oracle DB)
• Dbvisit (Oracle DB)
• SymmetricDS (PosgreSQL)
• Mammoth Replicator (PosgreSQL)

Środowisko – Czyli Przestrzeń Dyskowa

Zamiast inwestować w kolejne terabajty i petabajty macierzy dyskowych oraz przestrzeni plikowych, wybieramy chmurę. Łączymy się bezpośrednio przez API dostawcy lub korzystamy z narzędzi zwanych Storage Gateway.

AWS ma swój Storage Gateway, Azure ma swój StorSimple. Istnieją też rozwiązania firm trzecich – NetApp, Panzura, EMC. Istnieją też popularne rozwiązania wspomagające proces archiwizacji danych – CommVault, Symantec – wykorzystujące chmurę jako wirtualne biblioteki taśmowe.
Część z tych rozwiązań wspiera szyfrowanie, de-duplikację oraz akcelerację przesyłania danych.
W zależności od rozwiązania i konfiguracji dane mogą znajdywać się w różnych miejscach. Często używane dane są trzymane w lokalnym cache, a mniej używane mogą być transferowane do chmury. Możemy też 100% danych przesyłać do chmury i odwoływać się do nich w miarę potrzeb. Opcji jest wiele. Dużo o tym napisał Macie Stopa w artykule Backup Do Chmury.

Chmura Hybrydowa – Rzeczywistość

Zdradzę Ci największy sekret chmury hybrydowej. Pewnie już się domyśliłeś.

Chmura hybrydowa, to wykorzystanie chmury publicznej w mniej niż 100%.

Najczęściej spotykam firmy, które uruchomiły jedną aplikację w chmurze publicznej. Posmakowali chmury i myślą o przeniesieniu kolejnej aplikacji, wyniesieniu środowiska test/dev, wyniesieniu backup/archiwum, zrobienia DRC.
Jeżeli spytasz dyrektora IT w takiej firmie, to usłyszysz:

Panie, jaka chmura hybrydowa? Przenieśliśmy po prostu kilka aplikacji do AWS/Azure/SoftLayer/Oktawave/e24cloud. Planujemy przenieść kolejne.

Dla nich chmura hybrydowa jest to tylko przejściowa droga do środowiska 100% cloud. Czy to nastąpi za 1 rok, czy za 10 lat, to już całkowicie inna historia. Stan pośredni jest chmurą hybrydową z definicji.
Znajdą się jednak firmy, które w chmurze hybrydowej widzą swoją strategię. Czasami przez innowacyjne myślenie, czasami przez brak wiedzy, czasami przez mocny nacisk dostawców sprzętu lub określone lobby w firmie, wybierają drogę hybrid first.
O jedno Cię proszę. Jeżeli usłyszysz gdzieś od kogoś słowa “Chmura Hybrydowa”, po prostu spytaj go o co mu dokładnie chodzi. Może macie to samo na myśli, tylko słownictwo (tak bardzo narzucane przez producentów) zabija waszą komunikację.

Kilka Dobrych Rad Na Zakończenie

Jeżeli planujesz wdrożyć u siebie chmurę hybrydową zwróć uwagę na:

• DNS – upewnij się, że w prosty sposób będziesz mógł przełączać środowiska
• Wynalazki – wszystkie dziwne systemy operacyjne z dziwnymi wymaganiami
• Łącza Internetowe – zadbaj o połączenie z chmurą przez Internet lub WAN
• Automatyzacja – łatwo popełnić błąd, szczególnie w dwóch środowiskach
• Licencje – sprawdzaj warunki licencyjne, gdyż czasami zapłacisz podwójnie

Pytanie do Ciebie: Jakie znasz inne model chmury hybrydowej?