Skąd się bierze wysoka dostępność (HA) w chmurze?

Jak oni to robią i czym to się różni od tradycyjnej infrastruktury?

Gdybyśmy chcieli zbudować tradycyjną wysoką dostępność to weźmiemy serwer i dostawimy drugi. Ruch na niego skierujemy poprzez load balancer. No dobrze, ale gdzie są pliki? No tak, jeśli ma być pełne HA, to system pików musi być redundantny – bierzemy więc DRBD, a może GlusterFS i stawiamy dwa. Ok jakieś HA da się zapewnić, nie zawsze samo się przełączy, ale realnie w 10 minut to poskładamy w razie czego. Mamy więc dwa serwery i wspólny system plików z HA. A baza danych? Replikacja w Mysqlu da radę w miarę wygodnie, Postgres będzie trudniejszy ale też damy radę, MongoDB bajka (ale trzeba trzeci serwerek, nawet malutki na arbitra). Czyli co, komplet? No nie, sesje? Cluster memcache albo redisa (przecież nie zapiszemy ich w bazie albo na dysku). No, a jak padnie load balancer? Tu HA będzie już kosztowne, ale da się zrealizować. Zrobione. Chwila, ale to stoi w jednym pomieszczeniu… a sieć, a pożar? A DNSy?

Jeśli Cię to przeraża, albo nic nie rozumiesz, to nawet dobrze – bo od tego jest chmura i nasza pomoc, aby nie myśleć o wielu z tych elementów.

Regiony i strefy dostępności w AWS dają wysoką dostępność

AWS (Amazon Web Services), czyli chmura Amazona składa się z regionów, w ramach których wydzielone są strefy dostępności. Taka strefa to odrębny budynek, odrębna sieć, zasilanie i wszystko. Między strefami oczywiście jest niesamowicie szybka sieć z wieloma trasami przebiegu.

Load balancing w AWS

Load balancer czyli Amazonowy ELB (Elastic Load Balancer) jest nad tym wszystkim. Konfigurując go, możemy być pewni, że ma wysokie HA – kierujemy ruch nie na adres IP, lecz na nazwę domenową. Nawet w czasie normalnej pracy serwisu w ramach ELB wielokrotnie może zmienić się urządzenie, które steruje ruchem i nikt tego nie zauważy – load balancer też się skaluje ze zmianami naszego ruchu, aczkolwiek za to nie płacimy bezpośrednio.

S3 – czyli super miejsce na pliki

O wspólnej przestrzeni dyskowej w nowoczesnej aplikacji musisz zapomnieć. Nie, że się nie da, ale to jak kupić auto z silnikiem V8 i odpiąć 4 cylindry. Amazon stworzył niesamowite S3, czyli miejsce na pliki. To usługa, od której powstała cała chmura w czasach, kiedy nikt nie mówił jeszcze, że to chmura. Niezliczone usługi wykorzystują S3 jako przestrzeń dyskową – może nawet jakaś aplikacja, której używasz właśnie łączy się z S3. Ze swoim modelem płatności usługa stała się hitem. Płacisz za przestrzeń zajętą – nic nie planujesz, zajmujesz zero – płacisz zero, zajmujesz 10MB, 100GB, 5TB – to za tyle płacisz. Płacisz za ilość odwołań do plików i transfer (tak ten w AWS może być istotną pozycją kosztową, ale na to mamy swoje sposoby). W razie gdybyś dużo się odwoływał do S3, są jeszcze takie usługi, jak CDN (AWS Cloudfront lub konkurencyjny i przez nas polecany CloudFlare, którego także jesteśmy partnerem).
S3 ze swoją dostępnością 99,99% i pewnością poprawnego zapisu 99,999999999% naprawdę zwalniają nas z myślenia, że to się może popsuć.

Jak Amazon to robi? Nie wiemy dokładnie, ale Twoje dane są zapisane w tylu miejscach w odrębnych lokalizacjach, że w zasadzie nie da się ich popsuć. Wysoka dostępność jest tu wpisana w usługę.

RDS – baza danych z wysoką dostępnością

Baza danych w AWS występuje jako usługa – RDS. Nie trzeba nic instalować, po prostu wybierasz z jaką bazą ma być kompatybilna i zakładasz bazę. Określasz dla niej wielkość i moc obliczeniową i za to płacisz. Dodatkowo baza może pracować w dwóch strefach dostępności i już AWS dba o to, żeby wszystko działało jak należy, gdy pojawią się jakieś problemy. Nie trzeba konfigurować żadnej replikacji, po prostu działa. Tu również wysoka dostępność jest wpisana w usługę.

Sesje – redis i memcache

Tak samo jak baza danych osobna usługa odpowiada m.in. za przechowywanie sesji – Amazon ElastiCache i tak samo występuje w opcji multi-AZ, czyli redundancji poprzez ulokowanie usługi w dwóch różnych środowiskach. Na sesje sprytnie można wykorzystać DynamoDB i prawie za to nie płacić.

Podział na strefy dostępności

Same instancje (czyli takie jakby VPSy) mają już małe znaczenie, ale także możemy sami wybrać dla nich strefy dostępności. Jeśli połowę z nich ulokujemy w jednej, a drugą w drugiej, to w razie awarii jednej strefy mamy nadal połowę działających serwerów. W Irlandii Amazon ma 3 strefy dostępności, więc można je podzielić jeszcze bardziej. A że dzięki chmurze, S3, RDS, ElastiCache i innych dane mamy kompletnie „odmiejscowione”, to nie mamy ich na instancjach – dlatego z każdą możemy się bez żalu rozstać. To tworzy podstawę do automatyzacji w dodawaniu i odejmowaniu zasobów. Z naszą pomocą możesz zaprojektować infrastrukturę, która zmienia się płynnie za pomocą przysłowiowego guziczka, albo wogóle nie wymaga guziczka, bo sama się zmienia jeśli dobrze zaprojektujemy AutoScaling – integralną funkcję chmurowego środowiska.

Pomożemy Ci to wszystko wykorzystać

To tylko ułamek usług, jakie oferuje chmura. Budując aplikacje możemy znaczne jej części przenieść do usług, które mają zapewnione zasoby i wysoką dostępność, niemal eliminując serwery. Nad całością musi jednak ktoś czuwać, monitorować i nadzorować, a także wyciągać wnioski z zachowania się infrastruktury i proponować zmiany. Tylko wtedy będziesz mógł skupić się na swoim biznesie, nie martwiąc się o to, że coś może nie działać. Zapraszamy do kontaktu – pomożemy Ci zaprojektować Twoją infrastrukturę tak, aby była niezawodna!

Zobacz również:

Chmura AWS na czas sprzedaży biletów na koncert Justina Biebera
Migracja do Amazon Web Services aplikacji Landingi.com
Hosting WordPress w chmurze AWS z pełną redundancją
Skąd się bierze wysoka dostępność (HA) w chmurze?
Amazon Web Services ma już 10 lat