Budowa odpornych na awarie systemów w oparciu o Consul a
Współczesne wyzwania, to więcej wszystkiego i... więcej problemów.
Zarządzanie serwisami nie jest łatwe: Gdzie i jak przechowywać ich konfiguracje? Jak sobie radzić z nadmiarowością? Jak postępować w przypadku awarii?...
Gdzie znajduje się nasz serwis? DC1 Jaka jest konfiguracja naszego serwisu? Czy szukany serwis jest zdrowy i dostępny? Gdzie znajduje się lider naszego serwisu?
Rozwiązania ale zanim pojawił się Consul
Zarządzanie ręczne lub zawarte w kodzie serwisu Nieskalowalne razem z serwisami/węzłami Zupełnie nieodporne na awarie Ograniczona widoczność Ręczne lokowanie serwisu
Zarządzanie poprzez konfigurację Wolna reakcja na zmiany Nieodporne na awarie Niezbyt konfigurowalne przez deweloperów Umiejscowienie, monitoring
Consul
Rejestracja serwisów i jak to właściwie działa?
Rejestracja serwisów Architektura - klient: Na każdym węźle klastra zainstalowany jest agent Consul a pracujący w trybie klient. odpowiada za rejestrację i sprawdzanie stanu serwisów, bierze aktywny udział w procesie wymiany informacji (Gossip), przekazuje wszystkie żądania do dowolnego serwera.
Rejestracja serwisów Architektura - serwer: Od 3 do 5 agentów pracujących w trybie serwer. Działają jak zwykli agenci ale mają dodatkowe funkcje. Zarządzają tablicami K/V, sesjami, kluczami ACL, Przekazują żądania od klientów do lidera (może być tylko jeden).
Rejestracja serwisów Topologia sieci
Rejestracja serwisów Consula działający w trybie serwer zainstalowany na 3 do 5 węzłów.
Rejestracja serwisów Komunikacja pomiędzy węzłami w klastrze X
Rejestracja serwisów Komunikacja pomiędzy serwerami (lider) Przekazanie RPC Replikacja X ma coś nowego! RPC
Rejestracja serwisów Serwis wysyła żądanie do lokalnego agenta: http://localhost:8500/v1/agent/service/register nawiązuje komunikację z dowolnym serwerem. sprawdza status serwisu. Jeśli serwis jest dostępny lub nie to oznacza go jako zdrowy lub chory ; rezultat przekazywany jest do serwera. Kiedy żądamy serwisu to tylko te zdrowe są zwracane w odpowiedzi na pytania DNS.
Rejestracja serwisów Przykład definicji serwisu: { } "ID": "redis", "Name": "redis", "Address": "127.0.0.1", "Port": 6789, "Check": { "DeregisterCriticalServiceAfter": "60m", "Script": "/usr/local/bin/check_redis.py", "Interval": "10s" } Dostępne od wersji 0.7 Przesyłana kiedy pojawia się serwis Typy: Script, HTTP, TCP, TTL
Rejestracja serwisów Przykład odpowiedzi DNS: ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @127.0.0.1 -p 8600 redis.service.consul. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54121 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;redis.service.consul. IN A ;; ANSWER SECTION: redis.service.consul. 0 IN A 172.17.0.5 redis.service.consul. 0 IN A 172.17.0.6 redis.service.consul. 0 IN A 172.17.0.7
Rejestracja serwisów Przykład odpowiedzi DNS z SRV: ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @127.0.0.1 -p 8600 redis.service.consul. SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54458 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;redis.service.consul. IN SRV ;; ANSWER SECTION: redis.service.consul. 0 IN SRV 1 1 6379 gdansk-node-04.node.gdansk.consul. redis.service.consul. 0 IN SRV 1 1 6379 gdansk-node-06.node.gdansk.consul. redis.service.consul. 0 IN SRV 1 1 6379 gdansk-node-05.node.gdansk.consul.
Rejestracja serwisów Lokalny agent odpowiada za rejestrację serwisów oraz sprawdzanie ich stanu; synchronizuje te dane z serwerem. y Consul a przechowują wszystkie inne informacje (K/V, sesje, ACL). Lokalny agent ma dostęp do tych informacji za pomocą RPC. może wymusić używanie kluczy ACL do zapisu i odczytu.
Tablice asocjacyjne (K/V)
Tablice asocjacyjne Consul udostępnia praktycznie nie limitowaną przestrzeń do przechowywania konfiguracji serwisów w postaci klucz = wartość. Wielkość klucza/wartości ograniczona jest z góry i wynosi 512kB. Tablice z 10.000 wpisów nie są niczym wyjątkowym. Dowolne wykorzystanie przez deweloperów.
Tablice asocjacyjne W przypadku pracy w wieloma centrami danych, każde z nich ma własną tablicę. Mechanizm monitorowania i powiadamiania o zmianach we wpisach w tablicy. Aktywna zmiana zmiennych środowiskowych w przypadku wykrycia zmian we wpisach (envconsul).
Tablice asocjacyjne Dodanie nowego wpisu: curl -X PUT -d @- localhost:8500/v1/kv/klucz <<< wartosc Odczyt z tablicy: curl -s localhost:8500/v1/kv/klucz jq.[] curl -s localhost:8500/v1/kv/klucz?raw w \n
ACL - lista kontoli dostępu
Lista kontroli dostępu Consul udostępnia tzw. listę kontroli dostępu (ACL) służącą do definiowania dokładnych reguł dostępu do tablic asocjacyjnych (K/V), serwisów i API. Każdy token posiada własne ID, nazwę, typ oraz zestaw reguł. Token przekazywany jest razem z każdym żądaniem do serwerów. Możliwe reguły: read, write, deny.
Praca z wieloma centrami danych
Praca z wieloma centrami danych Konfiguracja lokalnych agentów pozostaje zawsze niezmienna. Tylko agenci pracujący w trybie serwer tworzą klaster: używają tych samych pingów jak sieć w której działają; tylko serwery biorą udział w komunikacji między dwoma lub więcej klastrami (połączenia WAN); przekazywanie zapytań lokalnych agentów do innych klastrów.
Praca z wieloma centrami danych (lider) (lider) Gdańsk Kopenhaga
Praca z wieloma centrami danych (lider) WAN Gossip (lider) Gdańsk Kopenhaga
Praca z wieloma centrami danych Replikacja (lider) (lider) LAN RPC Replikacja Zmień wpis w K/V Kopenhaga RPC WAN RPC Gdańsk Kopenhaga
Praca z wieloma centrami danych Zdalne żądania przekazywane są do odpowiednich klastrów: obejmuje to także wpisy w tablicach asocjacyjnych; każdy klaster posiada własny kontener na wpisy; Consul nie posiada wbudowanego mechanizmu replikacji aczkolwiek istnieją narzędzia do jej przeprowadzenia (consul-replicate); Tylko na jednym z klastrów przechowywane są wpisy ACL.
Predefiniowane zapytania
Predefiniowane zapytania Założenia wstępne: ten sam serwis uruchomiony jest wielokrotnie w dwóch klastrach, możemy kontaktować się z każdym z serwisów lecz zawsze preferujemy ten który ma najmniejsze opóźnienia w transmisji, jeśli zmieni się polityka dostępu do serwisów, nie chcemy znać szczegółów w jaki sposób zlokalizować dostępne serwisy.
Predefiniowane zapytania Nowa przestrzeń nazw stworzona dla przygotowanych wcześniej zapytań; podobna do tej z serwisów. Rejestracja zapytań do pracy w obrębie tej przestrzeni. Praca z zapytaniami odbywa się za pomocą API lub przy użyciu DNS w domenie.query.consul.
Predefiniowane zapytania Formatka dla serwera Apache { } "Name": "apache-primary", "Service": { "Service": "apache", "Failover": { "NearestN": 3 }, "Tags": ["primary"] } Pytanie do DNS: apache-primary.query.consul
Predefiniowane zapytania Uniwersalna formatka dobra na wszystko { } "Name": "", "Template": { "Type": "name_prefix_match" }, "Service": { "Service": "${name.full}", "Failover": { "NearestN": 3 } } *.query.consul Taką pozornie prostą formatką możemy sprawić, że w przypadku awarii naszych lokalnych serwisów zostaną udostępnione nam ich odpowiedniki ale zlokalizowane w innym klastrze!
Tomografia sieci
Tomografia sieci Służy do określenia współrzędnych położenia poszczególnych serwisów dzięki czemu zawsze wybierany jest ten serwis który charakteryzuje się najkrótszym czasem dostępu. Do wyznaczenia czasu potrzebnego na pokonanie odległości pomiędzy dwoma węzłami klastra używana jest komenda consul rtt.
Tomografia sieci # Pobierz współrzędne dla klastrów: curl -s http://127.0.0.1:8500/v1/coordinate/datacenters jq.[] { } "Datacenter": "gdansk", "Coordinates": [ { "Node": "gdansk-server", "Coord": { "Vec": [ 0.0034986561715802684, -0.003981283643042122, -0.0032856845929926685, 0.0005611250379103966, 0.0028290202235891296, -0.00043407207333237823, -0.0026897349317014, -0.001033689771998338 ], "Error": 0.03648816431363068, "Adjustment": -0.00019007221284578186, "Height": 3.9357711906514895e-05 } } ]
Tomografia sieci # Pobierz listę węzłów w klastrze consul members Node Address Status Type Build Protocol DC ap-gdansk-client-1p 10.48.10.127:8301 alive client 0.6.4 2 gdansk ap-gdansk-client-2p 10.48.10.128:8301 alive client 0.6.4 2 gdansk ap-gdansk-client-3p 10.48.10.129:8301 alive client 0.6.4 2 gdansk gdansk-server 10.152.84.121:8301 alive server 0.6.4 2 gdansk # Pobierz orientacyjny czas RTT z aktualnego węzła do innego: consul rtt ap-gdansk-client-2p Estimated ap-gdansk-client-2p <-> gdansk-server rtt: 1.053 ms (using LAN coordinates) # Pobierz orientacyjny czas RTT pomiędzy dwoma węzłami: consul rtt ap-gdansk-client-2p ap-gdansk-client-3p Estimated ap-gdansk-client-2p <-> ap-gdansk-client-3p rtt: 0.588 ms (using LAN coordinates)
Consul Podsumowanie: Rejestracja serwisów (REST, API). Wyszukiwanie lokalne serwisów lub w innych centrach danych (API, DNS). Dynamiczne zarządzanie konfiguracjami (tablice K/V). Łatwa skalowalność z minimalnymi zmianami w konfiguracji. Zarządzanie, nawet bardzo skomplikowaną polityką dostępności, za pomocą wcześniej predefiniowanych zapytań.
Demo