Czy korzystanie z modułu równoważenia obciążenia w ElasticSearch jest niepotrzebne?

Question

Mam klaster 3 węzłów ElasticSearch działających na AWS EC2. Te węzły są konfigurowane za pomocą OpsWorks/Chef. Moim zamiarem jest zaprojektowanie tego zestawu jako bardzo elastycznego i elastycznego (węzły mogą wchodzić i wychodzić, gdy jest to potrzebne).

Wszystko, co czytałem na temat ElasticSearch, wydaje się, że nikt nie zaleca stosowania systemu równoważenia obciążenia przed klastrem; Zamiast tego wydaje się, że zalecenie to zrobić jedną z dwóch rzeczy:

1. swojego klienta pod adresem URL/IP z jednego węzła, niech ES zrobić równoważenia obciążenia dla Ciebie i mamy nadzieję, że węzeł nie idzie w dół.

2. Twarde kodowanie adresów URL/adresów WSZYSTKICH twoich węzłów w aplikacji klienckiej i umożliwienie aplikacji obsługi logiki przełączania awaryjnego.

Moje tła jest głównie w gospodarstwach internetowych, gdzie jest to tylko zdrowy rozsądek, aby stworzyć ogromny basen autonomicznych serwerów WWW, rzucić ELB przed nimi i niech równoważenia obciążenia zdecydować, jakie węzły są żywe lub martwe. Dlaczego ES nie obsługuje tej samej architektury?

Answer 1

Nie potrzebujesz systemu równoważenia obciążenia - ES już zapewnia tę funkcjonalność. Byłbyś po prostu kolejnym komponentem, który mógłby źle działać i który powodowałby niepotrzebny skok sieciowy.

ES odrzuci Twoje dane (domyślnie do 5 shardów), które spróbuje równomiernie rozdzielić między twoje instancje. W twoim przypadku 2 instancje powinny mieć 2 odłamki i 1 tylko jedną, ale możesz chcieć zmienić odłamki na 6 dla równej dystrybucji.

Domyślnie replikacja jest ustawiona na "number_of_replicas":1, więc jedna replika każdego odłamka. Zakładając, że za pomocą 6 odłamki, może wyglądać następująco (R jest replikacją odłamek)

• node0: 1, 4, R3, R6
• node1: 2, 6, R 1, R 5
• Node2: 3, 5, R2, R4

Zakładając node1 umiera klaster zmieni się do poniższych:

• node0: 1, 4, 6, R3 + nowe repliki R5, R2
• NODE2: 3, 5, 2, R4 + nowe repliki R1, R6

zależności od ustawienia połączenia, można połączyć z jednym przypadku (klient transportu) lub można dołączyć do klastra (klient węzła). Z klientem węzła unikniesz podwójnego przeskoku, ponieważ zawsze będziesz łączyć się z odpowiednim fragmentem/indeksem. Za pomocą klienta transportu twoje żądania będą kierowane do właściwej instancji.

Nie ma więc nic do załadowania salda, wystarczy dodać obciążenie. Automatyczne grupowanie jest prawdopodobnie największą siłą ES.

Answer 2

Masz całkowitą rację, że chcesz zaprojektować opcję "przełączania awaryjnego", aw AWS, oto jak polecam Ci to zrobić.

1) Ogranicz węzły w klastrze, które mogą zostać wybrane jako wzorce. Dla pozostałych ustaw node.client: true.Oprzyj swój wybór, ile masz węzłów, które masz do dyspozycji, o ile chcesz mieć dostęp do przełączania awaryjnego.

2) Utwórz ELB, który zawiera tylko główne węzły, które można odebrać.

3) W Route 53 utwórz CNAME dla swojego klastra, z wartością ustawioną na nazwę DNS swojego ELB.

Answer 3

wierzę równoważenia obciążenia klastra Elasticsearch jest dobrym pomysłem

architekta klaster będziesz potrzebować tła na dwóch podstawowych funkcji Elasticsearch (projektując system tolerancyjny na błędy, odporne na uszkodzenia pojedynczego węzła.): 1. Pisanie i aktualizowanie dokumentów oraz 2. Zapytanie o dokumenty.

dokumenty Pisanie/indeksujące w elasticsearch:

1. Kiedy nowy dokument wchodzi w Elasticsearch mają być indeksowane, Elasticsearch określa „podstawową odłamek” Dokument powinien być przypisany do korzystania z „Shard Routing Algorithm”
2. Proces Lucene powiązany z odłamkiem "mapuje" pola w dokumencie;
3. Proces Lucene dodaje dokument do "odwróconego indeksu" odłamka "Lucene"
4. Wszelkie "odłamki repliki" otrzymują dokument; Shard replika „mapy” dokument i dodaje dokument do Shard repliki Lucene „odwróconego indeksu”

odpytywanie dokumentów w Elasticsearch:

1. Domyślnie, gdy zapytanie jest wysyłane do Elasticsearch kwerenda uderza węzeł - to staje się „węzeł zapytanie” lub „brama węzeł zapytania” dla tego zapytania
2. węzeł rozgłasza zapytanie do każdego fragmencie w indeksie (pierwotne & replik)
3. każdy odłamek wykonuje kwerendę na lokalnym indeksie odwróconym Lucene odłamka.
4. każdy fragment zwraca Top 10 - 20 wyników z „węzła bramy zapytania”
5. „bramy węzła zapytanie”, a następnie wykonuje scalania posortowanie na podstawie otrzymanych wyników zwróconych z pozostałych fragmentów,
6. po scaleniu -sort jest zakończona, „query node brama” i zwraca wyniki do klienta
   • scalanie sortowania jest procesora i zasobów pamięci ciężki

Architect a Load Balancer do zapisu/indeksowania/aktualizacji

Elasticsearch samodzielnie zarządza lokalizacją odłamków na węzłach. "Węzeł główny" przechowuje i aktualizuje "tabelę routingu odłamków". "Węzeł główny" dostarcza kopię tabeli routingu fragmentów do innych węzłów w klastrze.

Zasadniczo nie chcesz, aby twój węzeł główny robił znacznie więcej niż sprawdzanie kondycji klastra i aktualizowanie tabel routingu oraz zarządzanie odłamkami.

Najprawdopodobniej najlepiej wskazać system równoważenia obciążenia dla zapisów w "węzłach danych" (węzły danych to węzły zawierające dane = shards) i pozwolić węzłom danych na użycie tabel routingu shard, aby uzyskać zapisy do właściwych odłamków.

Tworzenie architektury zapytań

Elasticsearch stworzył specjalny typ węzła: „węzeł klienta”, który zawiera „NO DATA”, i nie może stać się „węzeł master”. Funkcja węzła klienta polega na wykonaniu końcowego sortowania ciężkiego zasobu na końcu zapytania.

Dla AWS byłoby prawdopodobnie użyć C3 lub C4 typ instancji jako „węzła klienckiego”

Najlepszym rozwiązaniem jest, aby wskazać równoważenia obciążenia dla zapytań do węzłów klienckich.

Pozdrawiam!

Odniesienia:

1. Elasticsearch Node Types
2. Elasticsearch: Shard Routing Algorithm
3. Elasticsearch: Replica Shards
4. Elasticsearch: Cluster State i.e. the Shard Routing Table
5. ElasticHQ - Introduction to Elasticsearch Video
6. Elasticsearch: Shard numbers and Cluster Scaling