Echilibrarea sarcinii și failover

Încărcare echilibrare și failover

1) Obiective și termeni

Echilibrarea distribuie traficul între instanțe/zone/regiuni pentru performanță și reziliență.
Failover - failover controlat.
RTO/RPO - Obiectiv de timp de recuperare și pierderi de date acceptabile.
SLO: nivelul țintă de disponibilitate/latență; servește ca o „poartă” pentru feilover automat și rollback.

2) Echilibrarea straturilor

2. 1 L4 (TCP/UDP)

Pro: performanță, simplitate, TLS passthrough. Contra: Nicio înțelegere a traseului/cookie-uri.
Exemple: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Pro: traseu/anteturi, greutăți canare, lipicios. Contra: mai scump în procesor/latență.
Exemple: NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 Global

DNS/GSLB: controale de sănătate + răspuns geo/ponderat.
Anycast/BGP: un IP la nivel mondial, cel mai apropiat punct de anunțare.
CDN/Edge: Cache/Feilover pe perimetru.

3) Algoritmi de distribuție

Robin rotund/ponderat - de bază.
Cele mai puține conexiuni/latență - pentru cereri „grele”.
Hashing consecvent - stickiness utilizator/chiriaș fără o sesiune de centru.
Localitate bazată pe hash - pentru cache-uri și servicii statale.

4) Sesiuni și lipicios

Cookie-lipicios: L7 LB setează un cookie pentru a reveni la instanță.
Src-IP lipicios: pe L4, mai rău cu NAT/CGNAT.
Hashing consecvent: mai bine pentru cache-uri orizontale/chat-uri.
Scopul: dacă este posibil, face serviciul apatrizilor, în caz contrar - scoate statul (sesiuni în Redis/DB) pentru a simplifica failover.

5) Fiabilitate: controale de sănătate și eliminarea din rotație

Verificări active: sonde HTTP 200/profunde (de ex. „/healthz/retrage ”cu dependențe).
Pasivă (detectare exterioară): ejecție backend la 5xx/timeout.
Warm-up: includerea fără probleme a unor noi cazuri (lent-start).
Scurgere grațioasă - Scoateți din piscină → așteptați cererile pentru a finaliza.

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Managementul defecțiunilor: timeout/retry/circuit-breaking

Timeouts: mai scurt decât timeout client; specificați pe traseu.
Retries: 1-2 cu jitter și idempotență; interzicerea retroactivelor pe POST fără chei de idempotență.
Întrerupător de circuit: limitarea cererilor/erorilor simultane; recuperare „semi-deschisă”.
Bugete: Limite de retrasare/fuziune a exploziilor pentru a nu aranja auto-DDOS.

7) Modele de kubernete

ClusterIP/NodePort/LoadBalancer/Ingress - primitive de bază.
Pregătire/Liveness: trafic numai pe plăci gata făcute.
PodDisruptionBudget nu poate cădea N replici în același timp.
HPA/VPA: scalare prin metrici CPU/RED, legătură către LB.
ServiceTopologie/Topologie Conștient Sugestii: localitate după zonă.
Tip de serviciu = LoadBalancer (zonal): cel puțin 2 replici în fiecare AZ.

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Cross-zone și trafic transregional

Multi-AZ (în interiorul regiunii): distribuiți uniform (LB zonală), stocare - replici sincrone.

• Activ-Activ: ambele regiuni deservesc traficul; mai complex - aveți nevoie de replicarea datelor, consistență și rutare geografică.
• Activ-pasiv: regiunea principală servește, rezervă - "cald/cald/rece. "Comutare mai ușoară, mai rapidă, dar RPO mai mare.

• Geo-DNS (cea mai apropiată regiune).
• DNS ponderat (canari/redistribuire).
• Pe bază de latență (măsurători RTT).
• Failover = prin semnale de sănătate/disponibilitate (sonde din mai multe puncte de vedere).

9) Date și failover

Cache/stat: dacă este posibil - regional local; pentru Active-Active - CRDT/hash-uri consistente.

• Replicare sincronă = RPO scăzut, latență mai mare.
• Asincron = latență mai mică, dar RPO> 0.
• Cozi: oglindire/topicuri multicluster; deduplicarea evenimentelor.
• Proiectați idempotența operațiunilor și mecanica reluării.

10) Perimetru: DNS/Anycast/BGP/CDN

DNS: scurt TTL (30-60) + controale de sănătate din rețea.
Anycast: mai multe POP-uri cu un singur IP - cel mai apropiat primește trafic, feilover-ul este la nivelul de rutare.
CDN/Edge: memoria cache și „gateway” pentru protecție, static/media sunt deservite atunci când originea cade; originea-scut + пер -POP sănătate.

11) Configurații de probă

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Failover automat: semnale și porți

Tech-SLI: 5xx-rate, p95/p99, saturație, strângeri de mână TLS, resetări TCP.
Business SLI: succesul depozitelor/plăților, fără erori de plată la PSP.
Porți: dacă pragurile sunt depășite, opriți zona/instanța, ridicați greutățile bazinului stabil, comutați GSLB.
Runbook: instrucțiuni pas cu pas.

13) Teste și inspecții (haos și zile de joc)

Teste de haos: dezactivarea AZ/regiuni, degradarea DB/cache, simularea pierderilor de pachete.
Game-day: Antrenament Faylover cu echipe de gardă.
Diagnosticare: urmărirea de la perimetru la backends, adnotări de eliberare potrivite și metrici.

14) Siguranță și conformitate

mTLS între limitele LB↔servisy, WAF/Rate pe perimetru.
Zone de eșec/segmentare: izolarea razei explozive.
Politici: interzicerea punctului unic de eșec (SPOF), cerințe pentru „replici minime N/AZ”.

15) Anti-modele

O LB/o zonă pentru tot traficul (SPOF).
Nici o verificare profundă „/healthz ”(verde - dar DB/coadă indisponibil).
Retrăiți fără idempotență → tranzacții/plăți duble.
Lipicios pe IP cu dezechilibru → NAT în masă.
Feilover DNS cu TTL ridicat (ore înainte de comutare).
Nici o scurgere graţios atunci când epuizat - cerere pauză.

16) Lista de verificare a implementării (0-45 zile)

0-10 zile

Postați instanțe la ≥2 AZ; permite pregătirea/liveness, controale de sănătate.
Configurați L7-timeouts/retries (1 încercare), detectarea exteriorului.
Activați scurgerea grațioasă și pornirea lentă.

11-25 zile

Introduceți GSLB (geo/ponderat) sau Anycast pentru perimetru.
Greutăți canare/politici de traseu; lipicios prin cookie/hash consistent.
Porti SLO pentru auto-feilover (p95/5xx + SLI de afaceri).

26-45 zile

DR regional: Active-Active sau Active-Pasive cu test de traducere.
Zile de haos cu AZ/regiuni oprite, rapoarte RTO/RPO.
Runbook automate "și (pauză/shift/rollback script-uri).

17) Valorile maturității

Acoperirea multi-AZ ≥ 99% din căile critice.
DNS/GSLB/Anycast sunt implementate pentru punctele finale publice.
MTTR atunci când un AZ cade <5 minute (p95).
RPO pentru datele critice ≤ țintă (de exemplu, ≤ 30 de secunde).
Zile de joc trimestriale și feilover programat cu succes.

18) Concluzie

Echilibrarea și failover-ul fiabil este o arhitectură stratificată: L7-policies locală (timeout-uri/retries/CB, controale de sănătate), lipiciozitate corectă și hashing, stabilitate transversală și pe perimetru - GSLB/DNS/Anycast. Adăugați porți SLO, idempotență, scurgere grațioasă și teste de haos regulate - iar orice pierdere a unui nod, a unei zone sau chiar a unei regiuni va deveni un eveniment ușor de gestionat cu RTO/RPO previzibil.