Budowa odpornych na awarie systemów w oparciu o Consul a

Transkrypt

1 Budowa odpornych na awarie systemów w oparciu o Consul a

2 Współczesne wyzwania, to więcej wszystkiego i... więcej problemów.

3 Zarządzanie serwisami nie jest łatwe: Gdzie i jak przechowywać ich konfiguracje? Jak sobie radzić z nadmiarowością? Jak postępować w przypadku awarii?...

4 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?

5 Rozwiązania ale zanim pojawił się Consul

6 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

7 Zarządzanie poprzez konfigurację Wolna reakcja na zmiany Nieodporne na awarie Niezbyt konfigurowalne przez deweloperów Umiejscowienie, monitoring

8 Consul

9 Rejestracja serwisów i jak to właściwie działa?

10 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.

11 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).

12 Rejestracja serwisów Topologia sieci

13 Rejestracja serwisów Consula działający w trybie serwer zainstalowany na 3 do 5 węzłów.

14 Rejestracja serwisów Komunikacja pomiędzy węzłami w klastrze X

15 Rejestracja serwisów Komunikacja pomiędzy serwerami (lider) Przekazanie RPC Replikacja X ma coś nowego! RPC

16 Rejestracja serwisów Serwis wysyła żądanie do lokalnego agenta: 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.

17 Rejestracja serwisów Przykład definicji serwisu: { } "ID": "redis", "Name": "redis", "Address": " ", "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

18 Rejestracja serwisów Przykład odpowiedzi DNS: ; <<>> DiG deb8u6-Debian -p 8600 redis.service.consul. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; 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 redis.service.consul. 0 IN A redis.service.consul. 0 IN A

19 Rejestracja serwisów Przykład odpowiedzi DNS z SRV: ; <<>> DiG deb8u6-Debian -p 8600 redis.service.consul. SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; 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 gdansk-node-04.node.gdansk.consul. redis.service.consul. 0 IN SRV gdansk-node-06.node.gdansk.consul. redis.service.consul. 0 IN SRV gdansk-node-05.node.gdansk.consul.

20 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.

21 Tablice asocjacyjne (K/V)

22 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 wpisów nie są niczym wyjątkowym. Dowolne wykorzystanie przez deweloperów.

23 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).

24 Tablice asocjacyjne Dodanie nowego wpisu: curl -X PUT 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

25 ACL - lista kontoli dostępu

26 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.

27 Praca z wieloma centrami danych

28 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.

29 Praca z wieloma centrami danych (lider) (lider) Gdańsk Kopenhaga

30 Praca z wieloma centrami danych (lider) WAN Gossip (lider) Gdańsk Kopenhaga

31 Praca z wieloma centrami danych Replikacja (lider) (lider) LAN RPC Replikacja Zmień wpis w K/V Kopenhaga RPC WAN RPC Gdańsk Kopenhaga

32 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.

33 Predefiniowane zapytania

34 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.

35 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.

36 Predefiniowane zapytania Formatka dla serwera Apache { } "Name": "apache-primary", "Service": { "Service": "apache", "Failover": { "NearestN": 3 }, "Tags": ["primary"] } Pytanie do DNS: apache-primary.query.consul

37 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!

38 Tomografia sieci

39 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.

40 Tomografia sieci # Pobierz współrzędne dla klastrów: curl -s jq.[] { } "Datacenter": "gdansk", "Coordinates": [ { "Node": "gdansk-server", "Coord": { "Vec": [ , , , , , , , ], "Error": , "Adjustment": , "Height": e-05 } } ]

41 Tomografia sieci # Pobierz listę węzłów w klastrze consul members Node Address Status Type Build Protocol DC ap-gdansk-client-1p :8301 alive client gdansk ap-gdansk-client-2p :8301 alive client gdansk ap-gdansk-client-3p :8301 alive client gdansk gdansk-server :8301 alive server 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: 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: ms (using LAN coordinates)

42 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ń.

43 Demo