Przechodzenie do AWS Autoscaling Cloud - gdzie hostować Redis i ElasticSearch?
Próbowałem zbadać ten temat, ale nie znalazłem żadnego miejsca, które zalecałoby instalowanie usług takich jak Redis i ElasticSearch podczas przenoszenia do chmury.
Obecnie używam aplikacji Symfony2 na dwóch statycznych serwerach - jednym z MySQL, a drugim z publicznym serwerem WWW, na którym działają również Redis i ElasticSearch. Oba te serwery są zwirtualizowane, ale są statyczne z punktu widzenia braku możliwości replikacji w tej chwili (różne aspekty nadal zależą od lokalnego systemu plików).
Celem jest przejście do AWS i użycie autoskalowania, aby móc w razie potrzeby uruchamiać i wyłączać serwery internetowe, ale nie rozumiem, co powinienem umieścić na każdej instancji EC2. Czy powinni mieć tylko jedną odpowiedzialność? te. skonfigurować oddzielne instancje dla serwerów WWW, Redis i ElasticSearch oraz najprawdopodobniej RDS dla instancji MySQL i ustawić automatyczne skalowanie tylko na serwerach WWW?
Nie przewiduję, że serwer ElasticSearch będzie musiał w każdej chwili skalować się w górę, gdy będzie zarządzał tylko funkcją wyszukiwania, ale jest możliwe, że Redis może w pewnym momencie potrzebować replikacji - ale czy powinienem to zrobić ręcznie? Nie jestem pewien, jak można to zrobić automatycznie, ponieważ o ile wiem, każda instancja musi być skonfigurowana, aby wiedzieć o swoim nadrzędnym/podrzędnym (-ych). Byłbym wdzięczny za radę w tej sprawie.
Kolejne krótkie pytanie, kiedy tu jestem, dotyczy tego, jak mogę wdrożyć zmiany w kodzie, jeśli X serwery sieciowe są obecnie aktywne? Używam skryptu wdrożeniowego Capifony (wersja Capistrano dla Symfony2), który, jak sądzę, może dość łatwo obsłużyć wiele serwerów, określając tablicę
:domainadresy ... ale jak sobie z tym radzić, jeśli liczba serwerów internetowych może się różnić?
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
1 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
Elastyczny system równoważenia obciążenia
, jasny.
Druga warstwa to
Grupa automatycznego skalowania
serwery WWW (strefa multi-dostępności). Ładują niestandardowy AMI, który po uruchomieniu jest w odpowiednim stanie gotowości do tego zadania. (Teraz, gdy nasze procesy są bardziej dojrzałe, w rzeczywistości ładujemy ogólny interfejs AMI, który można automatycznie skonfigurować podczas uruchamiania za pomocą programu Chef). Ale robimy też
najnowsze repozytorium kodu produkcyjnego podczas uruchamiania, więc nie musimy tworzyć nowego AMI za każdym razem, gdy wdrażamy kod. Pozwala nam również łatwiej modyfikować konfiguracje, takie jak hosty baz danych, hosty Redis itp.
Trzecia warstwa jest przeznaczona dla bazy danych i innych usług, takich jak ElasticSearch i Redis. Możesz hostować wszystkie trzy usługi na jednym urządzeniu, a następnie rozpocząć zarządzanie własnymi serwerami slave mysql lub możesz hostować Redis i ElasticSearch na oddzielnym serwerze i używać Amazon RDS do usług Mysql. Twój wybór zależy od tego, czy chcesz zarządzać własną replikacją/odpornością na błędy w MySQL.
Często najłatwiejszym sposobem jest użycie
Amazon RDS
w konfiguracji strefy wielodostępności. Zawsze się staramy
wdrażaj multi-AZ ze wszystkim
więc nadal pracujemy, nawet jeśli spadnie jeden AZ. Następnie uruchamiasz mniejszą instancję, aby hostować tylko Redis i ElasticSearch.
Z
ElasticSearch
, oto wskazówka, której używamy do instalacji za pośrednictwem szyn: zainstaluj i utrzymuj pełną instancję aplikacji wraz z ElasticSearch na pudełku. Następnie utwórz AMI dla tej roli (lub roli szefa kuchni). Powodem jest to, że możesz uruchamiać zadania narzędziowe podczas ładowania, aby tworzyć indeksy ElasticSearch od zera, jeśli załadujesz nowy AMI. Następnie umieść tę instancję w Multi-AZ ASG z minimum i maksimum dla jednego serwera. Jeśli to pudełko lub strefa dostępności ulegną awarii, ASG pobierze zamiennik, przywróci swoje indeksy podczas uruchamiania i będzie gotowy do obsługi klientów.
Dla
Redis
na horyzoncie pojawiają się dobre wieści.
Wkrótce obiecuje ułatwić zarządzanie skalowaniem pamięci masowej Redis. Do tego czasu możesz samodzielnie obsługiwać replikację lub
wypróbuj Garantia, hostowane, skalowalne rozwiązanie serwerowe Redis
https://garantiadata.com/
który obecnie korzysta z wersji beta klastra redis (obecnie ograniczony do regionu us-east-1). Ma to tę zaletę, że używa tych samych adresów IP w konfiguracjach, niezależnie od tego, co dzieje się z pulami instancji.
Na koniec, aby zabezpieczyć dane wchodzące i wychodzące z baz danych, zalecałbym zbudowanie tego wewnątrz prywatnej części sieci publicznej/prywatnej
Wirtualna chmura prywatna
... Tworzy to twoją własną prywatną sieć, odizolowaną od snifferów pakietów. Możesz także użyć szyfrowania SSL dla połączeń z bazą danych MySQL.