Chmury obliczeniowe, devops, programowanie ...

... moje doświadczenia w poszukiwaniu rozwiązań - Marcin Frątczak

e24Cloud Struktura skalowalnego serwisu WWW

Przy okazji konkursu chmurowisko (https://chmurowisko.pl/e/) postanowiłem stworzyć przykładowy serwis WWW na chmurze e24cloud.com.

Tworząc złożone serwisy WWW myślimy, że nasz projekt będzie stać zawsze. Nikt ani nic nam nie zagraża. Okazuje się, że serwis może bardzo szybko zniknąć z internetu, i ciężko szybko go przywrócić do działania.

Powody, kiedy serwis może zniknąć z sieci:

  • atak na serwer (np DDOS)
  • nagły wzrost liczby użytkowników (np z 1000 do 100 000 dziennie)
  • złe wdrożenie poprawek na serwerze (czynnik ludzki)
  • awaria serwera
    • administrator coś nabroił, lub…
    • w serwerze popsuły się elementy, które są ważne
  • awaria całego regionu (całej firmy hostingowej)
    • serwer może działać, ale błąd w serwerowni nie pozwala dostać się do niego dostać
    • problemy z łączem do serwerowni (ile to się razy zdarzało, że pan w koparce przerwał światłowód)

Powyżej znajduje się kilka propozycji co może się stać. Powodów, może być mnóstwo. Jak zwiększyć szanse, że nasza strona będzie widoczna zawsze?

Założenia architektury o wysokiej dostępności / Korzyści

  • stworzenie serwisu znajdującego się na różnych serwerach / w różnych regionach
  • stworzenie backupu danych (zabezpieczenie przed zniszczeniem serwera lub błędu programisty)
  • możliwość łatwego podnoszenia parametrów serwera lub dokładanie nowych serwerów aby rozproszyć obciążenie

Rozwiązanie?

  • wykorzystanie dwóch regionów w serwerowni e24cloud (warszawa, poznań)
  • load balancer z wykorzystaniem docker swarm
  • replikacja bazy danych mysql (master-master)
  • synchronizacja plików między serwerami, aby dane zawsze były najbardziej aktualne

Jak wyżej wskazałem, postanowiłem postawić testowego bloga z wykorzystaniem docker swarm. 

Co to jest docker? jest to narzędzie umożliwiające nam odpalenie izolowanych kontenerów z całym środowiskiem / narzędziami, które potrzebujemy. Założeniem jest aby 1 oferował 1 usługę (baza danych, serwer www, itp).

Docker Swarm to jedno z nowych rozwiązań klastrowych, które pozwala umieszczać kopie kontenerów na różnych hostach. Swarm zapewnia również load balancer, a więc rozdziela ruch na x hostów, oraz jakich host jest nie dostępny, to jest on wykluczany i nie jest kierowany na niego ruch.

Opłacalność / Automatyzacja / Skalowalność

Przyjmijmy, że jeden serwer obsługuje cały serwis WWW. Dążymy do ochrony danych, i wysokiej dostępności serwisu. Czyli dostawiamy kolejne serwery.

Koszt testowego serwera odpalonego w e24cloud (1 rdzeń, 1gb ram, 40gb dysk) to 6.72 zł netto na tydzień.

Zakładając minimum 2 hosty, po 1 na region, to koszt tygodniowy wynosi 13,44 zł netto.

Transfer 100GB kosztuje 0.45 zł netto

Backup danych to za 1GB 0.0015 zł . A więc warto robić backup! 

Możemy konfiguracje mocno zoptymalizować. np:

  • posiadamy 4 hosty
  • na 2 hostach znajduje się baza danych
  • na 4 hostach znajduje się serwer www
  • na 1 hoście znajduje się cron z zadaniami

Gdy host pada, tworzony jest nowy kontener bazodanowy na innym dostępnym hoście. Tak aby nadal się znajdowały się 2 bazy danych.

E24cloud umożliwia automatyczne skalowanie serwera w górę. Dla ustawionych parametrów obciążenia ustawiamy zwiększenie Ilości procesorów / Ramu. To samo możemy zrobić jak obciążenie spada i chcemy słabszą maszynę. Jeden minus? Host jest niedostępny na 3-5 minut. Plus? Cena. Serwer o wyższych parametrach jest tańszy niż 2 gorsze.

Innym rozwiązaniem dzięki dockerowi, jest możliwość skalowania wszerz. Czyli dostawiamy kolejne maszyny i obciążenie jest rozpraszane na inne hosty. Plusy? Ciągłość dostępności serwisu jest zachowana. Minusy? Trzeba to zautomatyzować samodzielnie dla większego ruchu.

Co daje połączenie skalowania w górę i wszerz? Połączenie plusów z obu metod. Tańsze koszty + zmniejszone ryzyko niedostępności serwisu.

Tworzenie środowiska

Całkowity opis tworzenia środowiska z wykorzystaniem swarm wrzuce w kolejnych postach. Teraz skupię się na najbardziej głównych elementach.

Tworzenie hostów w dwóch regionach oraz powiązania docker swarm

Tworzymy dwa hosty, w regionie warszawa, oraz w regionie poznań. E24cloud obsługuje tworzenie obrazów serwera.Wcześniej stworzyłem serwer, zainstalowałem dockera (+ narzędzia do dockera) na serwerze, a następnie stworzyłem obraz instalacyjny. Teraz jak tworze nowy serwer, to wybieram obraz „docker+compose”. Nie tracimy czasu na instalacje oprogramowania w każdym serwerze.

 

Pod dodaniu hosta 1 dodajemy host 2 do drugiego regionu.

Teraz jak juz mamy działające 2 serwery, musimy je połączyć. Logujemy się na [host1], i tworzymy 1 węzeł główny.

 

Po wywołaniu polecenia pojawi się nam polecenie do skopiowania, aby połączyć drugą maszyne do pierwszej.Odpalamy to polecenie na [host2].

Wyjaśniając, 1 maszyna jest tzw „Manager”, a co za tym idzie, może kontrolować wszystko co znajduje się na wszystkich maszynach.

Druga maszyna jest „Gość”, i przyjmuje tylko polecenia.

Można tak zrobić, że każdy serwer jest managerem. Jednak teraz pominę tą opcje.

Tworzymy sieć, gdzie łączyć będziemy wszystkie kontenery ze sobą

Wgrywanie bazy danych i serwisu www

Tworzymy bazę klucz-wartość gdzie będą przechowywane informacje o istniejących kontenerach bazodanowych (w celu automatycznej replikacji danych nowo tworzonych instancji)

Wykorzystujemy percona-xtradb-cluster, która zostanie wgrana na dwa hosty po 1 instancji (replicas 2)

Mamy bazę danych z replikowaniem danych, pozostaje nam jeszcze stworzenie czystej instancji wordpress, która łączy się z klastrem bazodanowym

I… KONIEC :) 

Kilku poleceń nie dałem. Jednak przeglądając notatki, całe środowisko swarm zostało skonfigurowane w 10 poleceniach. Najważniejsze jednak to połączenie wszystkich hostów i kontenerów ze sobą co pokazałem powyżej.

Co jeszcze? Mogę dodać?

Automatyczny backup danych hosta

 

Automatyczne skalowanie hosta w górę lub dół

Podsumowanie

Każde rozwiązanie posiada plusy i minusy. Jak można zauważyć, bardzo łatwo utworzyć środowisko sprzętowe, oraz wrzucić oprogramowanie. Co jest najtrudniejsze? Zachowanie integracji danych. Czy będziemy używać docker swarm, czystych serwerów, lub innych rozwiązań, zawsze musimy zadbać o synchronizacje danych między hostami. O replikacje bazy danych. O miejsce gdzie wspólne rzeczy są zapisywane razem dla wszystkich hostów. Nie możemy pozwolić aby użytkownicy zobaczyli różnice między hostami.

Jest sporo rozwiązań używających docker swarm. Ja użyłem najprostszej. Domyślnie działa jak należy. Jednak jak wszystko z domyślnymi ustawieniami należy jeszcze to dobrze skonfigurować, aby nic nas nie zaskoczyło w przyszłości.

 

 

 

Dodaj komentarz

Your email address will not be published.

*

© 2017 Marcin Frątczak

Theme by Anders NorenUp ↑

Google Analytics Alternative