High Availability
High availability (HA) je obecně vlastnost sytému udávaná v procentech, kolik času je systém schopný normálně fungovat. Pro nás to bude znamenat seznámení se s technologiemi a strategiemi, které nám pomohou zajistit, aby služby zůstaly dostupné i v případě selhání některých částí systému.
Cílem je zajistit, aby nedostupnost jednoho prvku infrastruktury nepřerušila poskytování služby. Důvodem výpadku může být údržba, selhání hardware, selhání třetí strany (Cloudflare, AWS…(more to come))
Redundance služeb
Redundance znamená, že stejná služba je dostupná na více serverech současně.
Typy redundance:
- Aktivní–pasivní (active–standby): Jeden uzel pracuje, druhý čeká. Při selhání se aktivní role přepne. (webový server)
- Aktivní–aktivní (active–active): Oba uzly pracují současně a sdílí zátěž. (PostgreSQL se sekundárním hot standby)
- N+1 nebo N+M: Jeden nebo více záložních systémů pro skupinu primárních uzlů. (Microservices)
Redundance se používá pro webové servery, databáze, souborové systémy, SaaS platformy, které můžeme dále rozdělit na:
Bezstavové (stateless)
Neuchovávají vlastní stav.
Příklad: Nezáleží na pořadí dotazů,
pokaždé může být dotaz přesměrován na jiný worker.
Stavové (stateful)
Uchovávají stav (sessions, data, připojení).
Příklad: databáze,
NFS…
Redundance stavových služeb často vyžaduje:
- replikační protokoly
- sdílené úložiště
- clusterové FS
Kvórum, fencing, STONITH a split brain
Nový problém - split brain
Split brain nastává, když se cluster rozdělí na dvě nebo více částí, které si každá myslí, že je „hlavní“. Každá část může samostatně obsluhovat klienty a měnit data, což vede k nekonzistenci a riziku ztráty dat. Kvórum a fencing jsou klíčové mechanismy, jak těmto situacím předcházet.
Kvórum
Kvórum určuje minimální počet aktivních uzlů v
clusteru potřebných k rozhodování a správnému fungování služeb. Všimněme
si, že při počtu dvou uzlů tato strategie fungovat.
- 5 uzlů - kvórum 3 uzly
- 4 uzly - po rozdělení na 2 + 2 se rozhodne například pomocí zámku na
sdíleném disku, kdo bude hlavní.
- 2 uzly - opět nějaký sdílený zámek, nebo fencing
Fencing
Fencing je mechanismus pro izolaci vadného nebo nedostupného uzlu od sdílených zdrojů clusteru. Cílem je zabránit tomu, aby poškozený uzel ovlivnil ostatní uzly nebo data.
STONITH – Shoot The Other Node In The Head
STONITH je nejbezpečnější forma fencingu, která zaručuje, že vadný uzel bude úplně izolován – například tvrdým restartem nebo odpojením napájení přes IPMI či PDU. Je obzvlášť důležitý v dvouuzlových clusterech, kde kvórum není možné, nebo jako záložní řešení, když selže například zámek
Virtuální DNS jméno, IP adresa a MAC adresa
V HA se často používá virtuální identita, kterou reprezentuje:
- virtuální DNS jméno (např.
service.example.com) - virtuální IP adresa (VIP), kterou lze přesouvat mezi uzly
- virtuální MAC adresa, používaná protokoly jako VRRP
Virtuální adresa se po selhání přesouvá na jiný uzel.
VRRP
Virtual Router Redundancy Protocol umožňuje více uzlům sdílet jednu virtuální IP. Používá se především u síťových zařízení, ale také v Linuxu (Keepalived).
Funguje na principu:
- primární uzel → MASTER
- ostatní uzly → BACKUP
- při výpadku MASTER uzel změní VRRP prioritu a převezme VIP
VRRP využívá i virtuální MAC adresu, kterou převezme náhradní uzel.
Keepalived, Heartbeat, Corosync, Pacemaker, Resource Agents
Keepalived
- Implementace VRRP
- Jednoduchý failover VIP adres
- Možnost L4 health checků
Heartbeat
Starší systém pro komunikaci mezi uzly clusteru. Dnes ho nahrazuje Corosync.
Corosync
Moderní messaging vrstva pro clusterové systémy.
Zajišťuje:
- komunikaci uzlů
- membership
- quorum mechanizmy
- distribuované udržování stavu
Pacemaker
Clusterový orchestrátor. Řídí:
- start/stop služeb
- závislosti mezi službami
- migraci prostředků
- fencing / STONITH
Resource Agents
Skriptové moduly pro Pacemaker, které mu říkají:
- jak spustit službu
- jak zjistit stav
- jak provést stop/restart Existují RA pro databáze, web servery, IP adresy, FS, virtuální stroje atd.
Proxy vs. Reverse Proxy
Hlavní rozdíl je ten, že za forward proxy jsou schovaní klienti, za reverse proxy servery.
Proxy (Forward Proxy)
- Stojí mezi klientem a internetem.
- Klient posílá požadavky na proxy, ta komunikuje s internetem.
- Slouží k anonymizaci klienta, cache, kontrole přístupu.
- v praxi známe hlavně jako VPN, tunelování ssh…
Reverse Proxy
- Stojí mezi internetem a servery (backendy).
- Klienti komunikují s proxy, která požadavky směruje na interní servery. (Podobně jako u pNAT jsou stroje za jedním routerem, zde jsou servery přístupné pouze přes proxy)
- Používá se pro load balancing, autentizaci, HTTPS, routing, cache, odfiltrování robotů
- Cloudflare tunnels
Load Balancery
Load balancer (LB) je komponenta, která rozděluje zátěž mezi více
workerů.
Možné režimy:
L4 LB (transportní vrstva – TCP/UDP)
Provoz je směrován podle IP/portu. Rychlé a efektivní. Příklad: Linux IPVS. Rychlé, efektivní, pracuje v kernelu.
Výhody:
- vysoký výkon
- nízká režie
- nezávislé na aplikaci
Nevýhoda: neumí pracovat s L7 vrstvou
L7 LB (aplikační vrstva – HTTP, TLS, gRPC, REST)
Distribuce provozu podle URL, cookie, hlaviček atd. Příklad: HAProxy,
Traefik, Envoy.
Výhody:
- TLS terminace
- health-checky na úrovni protokolu
Nevýhoda: vyšší overhead.
LB může rovněž provádět kontrolu backendů nebo session persistence.
TLS terminace
load balancer nebo reverse proxy ukončí šifrované spojení (HTTPS) ještě dříve, než se data dostanou k backend serveru. má to řadu výhod, může směrovat podle url, správa certifikátu na jednom místě, odlehčení a zjednodušení backendu
Worker
Backend server, na který LB distribuuje provoz.
LB sleduje, zda
je worker dostupný — pokud není, vyřadí ho.
Linux IPVS (IP Virtual Server)
IPVS je kernelový modul poskytující velmi rychlý L4 load balancing. Používá se v LVS (Linux Virtual Server) a také v kontejnerech (Kubernetes kube-proxy v IPVS módu).
Výhody:
- extrémně rychlé – v kernelu
- ideální pro velké toky
- jednoduché řízení
Nevýhoda: žádná L7 logika.
L7 Load Balancery: HAProxy, Traefik, Envoy Proxy
HAProxy
- nejrozšířenější open-source L7 LB
- velmi výkonné
- detailní health-checky
- L4 i L7 mód
- široké použití (banky, ISP, cloud)
Traefik
- moderní, dynamická konfigurace
- ideální pro kontejnery
- integrace s Dockerem a Kubernetes
- dále viz Appendix
Škálování workerů pomocí load balanceru
Moderní Load balancer není jen o distribuci provozu, ale také o škálování backendů.
- přidat nový worker za běhu,
- odebrat worker během údržby,
- automaticky deaktivovat nedostupné servery,
- dynamicky měnit váhy serverů podle výkonu.
Automatické škálování
- CPU/Memory zátěži
- latenci odpovědí
- health-checku backendů
Appendix - Můj homelab setup
- nákup domény u Active24.cz - první rok je zlevněný
- transfer k DigitalOcean, který je podporován přímo v traefiku pomocí acme challenge
- nastavení traefiku na automatické vystavení certifikátu
*.example.comod Let’s encrypt - nové kontejnery opatřené příslušnými labely a přidané do stejné sítě jako je traefik se přidají automaticky do konfigurace
Ukázka jednoduchého webového serveru
services:
nginx:
image: nginx
container_name: nginx
volumes:
- ./content:/usr/share/nginx/html:ro
labels:
- traefik.enable=true
- traefik.http.routers.nginx.rule=Host(`help.example.com`)
- traefik.http.routers.nginx.entrypoints=https
- traefik.http.routers.nginx.tls=true
- traefik.http.services.nginx.loadbalancer.server.port=80
networks:
- proxy
networks:
proxy:
external: true
Ukázka složitější konfigurace pro giteu
labels:
- traefik.enable=true
- traefik.http.routers.gitea.rule=Host(`gitea.example.com`)
- traefik.http.routers.gitea.service=gitea
- traefik.http.routers.gitea.entrypoints=https
- traefik.http.services.gitea.loadbalancer.server.port=3000
- traefik.http.routers.gitea.tls=true
- traefik.http.routers.gitea.middlewares=compresstraefik
- traefik.http.middlewares.compresstraefik.compress=true
- traefik.tcp.routers.gitea-ssh.rule=HostSNI(`*`)
- traefik.tcp.routers.gitea-ssh.service=gitea-ssh
- traefik.tcp.routers.gitea-ssh.entrypoints=ssh
- traefik.tcp.services.gitea-ssh.loadbalancer.server.port=22
- traefik.docker.network=traefik-network
Zbývá tedy jediný manuální krok, přidat DNS záznam (já používal CNAME), ale to už taky umíme automatizovat.
Moje zkušenost Nginx vs. Traefik
Nginx je pracné konfigurovat, ovšem bez komplikovaných abstrakcí. Služby je pracné i přidávat. Traefik je taky pracné nakonfigurovat a nových abstrakcí je hodně. Když se to ale podaří, nové služby se přidávají jednoduše a elegantně.
- Referát relevantní k úkolu: Ján Václav
- Traefik proxy dokumentace
- PostgreSQL HA docs
- ClusterLabs Pacemaker
- Wikipedia HA
- HAProxy
- Privátní git repozitář