Princip fungování HashiCorp Consul

[czechsys]

Ahoj,

chceme pro zabbix zkusit prechod na HA reseni, takze momentalne zkousim patroni/postgresqk cluster a k tomu potrebuji DCS. Cil je mit cluster pres datacentra, ale zabbix nepodporuje vice db serveru v konfiguraci. Zatim jsem misto etcd zvolil ke zkouseni consul pro dynamickou zmenu fqdn->ip, ale nepodarilo se mi dohledat odpovedi na par otazek z duvodu limitu v resolv.conf, pokud se nepouziva jakkakoli dns sluzba na kazdem klientovi:

1] pokud bude jen 1 consul cluster, je misto pouziti consul agenta na kazdem klientovi vyuziti forward zony consulu v infrastrukturnich rekurzorech nestandardni/nesmyslne reseni?
2] v pripade vice consul clusteru viz 1] by muselo byt vice consul domen, ze?
3] pokud se musi nasadit consul agent na kazdeho klienta, jak se to resi u uzivatelu? To ma kazda stanice taky consul agenta?
4] pokud je consul agent na kazdem klientovi, vzhledem k limitu poctu nameserveru v resolv.conf, je lepsi pouzit agenta jako rekurzor, nebo pouzit jinou sluzbu (dnsmasq etc), ktera bude delat rekurzor?
5] pokud je consul cluster rozlozen mezi 2 datacentra a jako 3. musim pouzit aws, je lepsi pouzit misto 1/1/1 rozlozeni 2/2/1 ci 3/3/1 pro zajisteni quora?

Nebo je lepsi to zahodit a bezet etcd? Ale virtualni IP mezi datacentry na stejne L2 fakt nemam rad a jeste bych do toho musel cpat balancery...

Zajimaji me hlavne body 1]3]5].

Diky

[Reklama]

[_Tomáš_]

1) za mě standardní, forward + cache, nechceš nikdy pouštět neomezené klienty přímo na consul cluster
2) ano, je to lepší, ale pokud o sobě nebudou consul clustery vědět a zajistíš nějaký balancing dotazů, tak jim to vlastně je jedno, ale osobně bych konflikt/překryv domén z principu nedělal
3) ano, ale ono se to takhle nepoužívá, consul se použije třeba v k8s clusteru, každý node má agenta a ten se stará o data pro všechny pody. Nikdy mě nenapadlo nasazovat a udělat přímý přístup pro consul pro koncové stanice či jednotlivé servery (už jen řešení upgradu musí být peklo)

Já bych to takhle asi neřešil. Nemusíš db připojovat přímo, můžeš použít nějakou sql proxy a uní dynamicky měnit kam se vlastně dívá. Překlad fqdn na ip je super, ale jak budeš řešit aktualizace, vždyť zabbix si spojení drží, v consule se změní, ale dokud bude držet spojení původní, nebude se o změnu zajímat. Já tyhle věci řeším notifikací o změnách, přegenerováním configu a restartem služby (hashicorp vault a polling hodnot). Zpravidla to tak stačí.

Někdy méně dynamický systém (zejména pro logy) se ti mnohrát odmění v budoucnu.

[czechsys]

No sefstvo chce zkusit automatickou cestu z principu (monitoring). Takze manualni pregenerovani neceho je zatim az posledni moznost.

Pokud se zmeni v consule fqdn->ip, tak to znamena, ze je jiny server primarni. Pokud puvodni primar spadne, tak se zabbix znovu pripoji k novemu pres fqdn. Pokud dojde k specificke situaci, ze puvodni primar i pres zasah patroni atd. bude dale dostupny k zapisu, tak to bude spatny. Pokud ke cteni, tak nevim jak to zabbix resi. Nektere hranicni use-case resi zabbix+postgresql na jednom serveru a jine use-case resi, kdyz je to rozdelene na 2 servery.

Problem proxy je prave ten, ze proxy stack musi mit virtualni ip, ktera musi pak byt  v obou datacentrech :/ Coz je prave reseni v ramci etcd z hlediska patroni clusteru...Bez patroni clusteru bych to udelal cely manualne, ale cenou je vzdy prace na obnove sekundaru/zaloh etc.

A varianta mit 2 nezavisle zabbixy mi pripada docela narocna na spravu.

[Vantomas]

Stěhovat VIP mezi datacentry se může přes OSPF/BGP, vůbec to nemusí být v jedné L2.

[_Tomáš_]

já o manuálním nemluvil, změnu konfigurace můžeš udělat na základě toho, že se změnila hodnota v consulu.

Proxy sql necháš běžet na localhostu, kde je zabbix, budeš mu generovat konfiguraci z třeba consulu a při změně ho překonfiguruješ (automaticky samozřejmě). Při failoveru může dojít k nějaké ztrátě či drobné nefunkčnosti, ale to se bavíme o desítkách vteřin, což může být přípustné. Žádnou virtuální ip nepotřebuješ.

Začni stack zjednodušovat a ne přidávat další a další komplexnost nebo budeš muset mít monitoring na monitoring.

[Reklama]

[czechsys]

Stěhovat VIP mezi datacentry se může přes OSPF/BGP, vůbec to nemusí být v jedné L2.

Nejsem sitar teto urovne, abych to umel, vcetne anycastu :-) takze tyhle veci resim "sysadmin" cestou.

[czechsys]

já o manuálním nemluvil, změnu konfigurace můžeš udělat na základě toho, že se změnila hodnota v consulu.

Proxy sql necháš běžet na localhostu, kde je zabbix, budeš mu generovat konfiguraci z třeba consulu a při změně ho překonfiguruješ (automaticky samozřejmě). Při failoveru může dojít k nějaké ztrátě či drobné nefunkčnosti, ale to se bavíme o desítkách vteřin, což může být přípustné. Žádnou virtuální ip nepotřebuješ.

Začni stack zjednodušovat a ne přidávat další a další komplexnost nebo budeš muset mít monitoring na monitoring.

Pro tenhle specificky use-case by to pouzit slo. Ale pokud bude mit patroni cluster "uspech", tak se to urcite zacne davat na dalsi projekty a tahle cesta bude nepouzitelne, takze se zatim snazim vyvarovat unikatnich reseni.

[LivingLegend]

Proxy sql necháš běžet na localhostu, kde je zabbix,

Pokud resis prostredi kde je nutne to mit takto oddelene, tak uz ses dost vlekej na to aby FE  Zabbixu bylo jinde nez je DB

[czechsys]

Asi jsem neco nepochopil. Takze mam:

1] 3x consul cluster

Kód: [Vybrat]

# consul members
Node            Address               Status  Type    Build   Protocol  DC   Partition  Segment
test-consul-01  192.168.200.205:8301  alive   server  1.19.1  2         dc1  default    <all>
test-consul-02  192.168.200.206:8301  alive   server  1.19.1  2         dc1  default    <all>
test-consul-03  192.168.200.207:8301  alive   server  1.19.1  2         dc1  default    <all>
2] 2x patroni + postgresql cluster (bez consul agenta), nasmerovano na jeden z consul serveru, priklad z jednoho patroni.yml:

Kód: [Vybrat]

scope: testcluster
name: test-patroni-01
namespace: /service

consul:
#  host: 127.0.0.1:8500
  host: 192.168.200.205:8500
  checks: []
  register_service: true


Kód: [Vybrat]

logy:
2024-08-02 13:36:46,391 INFO: Register service testcluster, params {'service_id': 'testcluster/test-patroni-01', 'address': 'test-patroni-01', 'port': 5432, 'check': {'http': 'http://test-patroni-01:8008/master', 'interval': '5s', 'DeregisterCriticalServiceAfter': '150.0s'}, 'tags': ['master', 'primary'], 'enable_tag_override': True}

2024-08-02 13:36:46,871 INFO: Register service testcluster, params {'service_id': 'testcluster/test-patroni-02', 'address': 'test-patroni-02', 'port': 5432, 'check': {'http': 'http://test-patroni-02:8008/replica', 'interval': '5s', 'DeregisterCriticalServiceAfter': '150.0s'}, 'tags': ['replica'], 'enable_tag_override': True}


Kód: [Vybrat]

# patronictl -c /etc/patroni/patroni.yml list
+ Cluster: testcluster (7398492059310470971) -+---------+----+-----------+
| Member          | Host            | Role    | State   | TL | Lag in MB |
+-----------------+-----------------+---------+---------+----+-----------+
| test-patroni-01 | test-patroni-01 | Leader  | running |  3 |           |
| test-patroni-02 | test-patroni-02 | Replica | running |  3 |         0 |
+-----------------+-----------------+---------+---------+----+-----------+
3] vypsani sluzeb consulu

Kód: [Vybrat]

# consul catalog services
consul


Kód: [Vybrat]

2024-08-02T13:48:36.561+0200 [DEBUG] agent.server.memberlist.lan: memberlist: Stream connection from=192.168.200.207:38158
2024-08-02T13:48:36.929+0200 [DEBUG] agent.http: Request finished: method=GET url="/v1/kv/service/testcluster/leader?index=106556&wait=9.415060997009277s" from=192.168.200.202:47640 latency=9.505591083s
2024-08-02T13:48:36.931+0200 [DEBUG] agent.http: Request finished: method=GET url=/v1/kv/service/testcluster/?recurse=1 from=192.168.200.202:47640 latency="518.553µs"
2024-08-02T13:48:36.934+0200 [DEBUG] agent.http: Request finished: method=PUT url=/v1/session/renew/02ee5a50-53e6-72cb-8643-211b7977d636 from=192.168.200.202:47640 latency="459.564µs"
2024-08-02T13:48:39.104+0200 [DEBUG] agent.server.memberlist.lan: memberlist: Initiating push/pull sync with: test-consul-03 192.168.200.207:8301
2024-08-02T13:48:46.332+0200 [DEBUG] agent.http: Request finished: method=GET url=/v1/kv/service/testcluster/?recurse=1 from=192.168.200.201:51780 latency="810.398µs"
2024-08-02T13:48:46.335+0200 [DEBUG] agent.http: Request finished: method=PUT url=/v1/session/renew/55775404-f52b-41f8-d2b6-a93cde35e36e from=192.168.200.201:51780 latency="549.728µs"
2024-08-02T13:48:46.928+0200 [DEBUG] agent.http: Request finished: method=GET url="/v1/kv/service/testcluster/leader?index=106556&wait=9.9032564163208s" from=192.168.200.202:47640 latency=9.992995419s
2024-08-02T13:48:46.930+0200 [DEBUG] agent.http: Request finished: method=GET url=/v1/kv/service/testcluster/?recurse=1 from=192.168.200.202:47640 latency="607.854µs"
2024-08-02T13:48:46.933+0200 [DEBUG] agent.http: Request finished: method=PUT url=/v1/session/renew/02ee5a50-53e6-72cb-8643-211b7977d636 from=192.168.200.202:47640 latency="421.627µs"
2024-08-02T13:48:51.233+0200 [DEBUG] agent.server.memberlist.lan: memberlist: Stream connection from=192.168.200.206:52730

I pres mohutne google-fu se nedokazi trefit do vypsani dns zaznamu primarniho patroni, ani vypsat, zda je to dns v consulu vubec registrovany. Je nutne, aby byl consul agent na patroni serveru pro tu registraci dns?

Kód: [Vybrat]

# dig master.testcluster.service.consul @localhost -p 8600

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> master.testcluster.service.consul @localhost -p 8600
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47068
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;master.testcluster.service.consul. IN A

;; AUTHORITY SECTION:
consul. 0 IN SOA ns.consul. hostmaster.consul. 1722600377 3600 600 86400 0

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(localhost) (UDP)


[czechsys]

Tak fajn, vyzaduje. Po instalaci consul agenta:

Kód: [Vybrat]

# dig master.testcluster.service.consul @localhost -p 8600

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> master.testcluster.service.consul @localhost -p 8600
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41290
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;master.testcluster.service.consul. IN A

;; ANSWER SECTION:
master.testcluster.service.consul. 0 IN CNAME test-patroni-02.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(localhost) (UDP)


Pro testovani to nemam v dns, takze ted zjistit, proc to nebere hodnoty z /etc/hosts, i kdyz podle https://github.com/hashicorp/docker-consul/issues/94 by to jiz davno melo byt vyresene. Jestli to nebude tim, ze v /etc/resolv.conf nepouzivam lokalni dnsmasq apod. a pak to neco resolvuje pres buhvico buhvijak.

[czechsys]

Ah, uz jsem ten vystup pochopil. Ma to vratit cname s jmenem hosta (fqdn), cemuz dig vystup odpovida. A nasledne kolecko pres nejakou sluzbu, ktera toho hosta (fqdn) prelozi na ip.

No fajn. Kdyz jsem rozbil consul chybami v konfiguraci, tak se mi pqsl replika dostala na timeline vyssi nez leader. I to jde, koukam...

[Standa Blábol]

Tohle se standardne resi pomoci etcd (jednoducha GO staticka binarka). Consul selmostroj ti v tomto kontextu nic neprinese.
Zabbix pripojuj na postgresa pomoci HAproxy, ktera te presmeruje na primarni node postgres clusteru.

Vsecko to nastavuj ansible (hlavne pro zamezeni konfiguracnich chyb) a taky doporucuju nastavit afinitu na primarni zabbix a postgres node (prosty cron script, ktery prepne na primar, pokud je dostupny), abys nehonil zabbixa na DC1 a postgresa na DC2.

Je na to hromada tutorialu na webu, netreba vymyslet kolo.

Potrebujes 3 etcd instance, v pripade dvou DC potrebujes treti "witness" lokalitu, treba prave v AWS.

[czechsys]

Tohle se standardne resi pomoci etcd (jednoducha GO staticka binarka). Consul selmostroj ti v tomto kontextu nic neprinese.
Zabbix pripojuj na postgresa pomoci HAproxy, ktera te presmeruje na primarni node postgres clusteru.

Vsecko to nastavuj ansible (hlavne pro zamezeni konfiguracnich chyb) a taky doporucuju nastavit afinitu na primarni zabbix a postgres node (prosty cron script, ktery prepne na primar, pokud je dostupny), abys nehonil zabbixa na DC1 a postgresa na DC2.

Je na to hromada tutorialu na webu, netreba vymyslet kolo.

Potrebujes 3 etcd instance, v pripade dvou DC potrebujes treti "witness" lokalitu, treba prave v AWS.

Consul mi prinese to, ze je mene narocny na vykon disku, ze nepotrebuje haproxy, ze nepotrebuje resit virtualni ip mezi lokalitama. To jsou dost vyznamne bonusy proti etcd. U etcd je jedina vyhoda, ze nejsou potreba etcd klienti na potrebnych mistech.