Studii de caz/Platforma de aplicații web frontend
Sectorul public·Platformă de containere, cloud privat și stocare·România
Platforma de aplicații web frontend
O platformă completă de containere, cloud privat și stocare pentru centrul de date secundar — construită ca pereche a locației principale, cu clustere separate pentru dezvoltare, test și producție, fiecare împărțit în front-end și back-end.
01Provocarea
O a doua locație care poate susține aceeași platformă
Platforma de containere, cloudul privat și stocarea rulau dintr-un singur centru de date principal. Serviciile folosite de cetățeni și de companii nu puteau rămâne dependente de o singură clădire, o singură alimentare cu energie, o singură cale de rețea.
Mandatul a fost implementarea aceleiași platforme într-un al doilea centru de date, centrul de date secundar: o platformă capabilă să funcționeze singură sau alături de cea din primul centru, fără modificarea aplicațiilor care rulează pe ea.
02Dimensiune
Dimensionată pentru platformă,
construită să reziste la pierderea componentelor.
Per locație: un cluster de management cu patru noduri pe bare metal, zece noduri hiperconvergente care rulează împreună calculul și stocarea, o platformă de obiecte cu cinci noduri și două perechi de switch-uri redundante, conectate dual la nucleul de rețea existent.
03Platforma
Opt straturi, o singură platformă
Platforma de containere este centrul acestei implementări. Tot restul — cloudul privat, stocarea, fabric-ul de rețea — există pentru a servi sarcinile de lucru care rulează pe ea.
Trei noduri care combină planul de control cu rolul de worker, plus un worker dedicat. Nodurile de plan de control găzduiesc etcd, serverul API, schedulerul, controller managerul și cluster version operatorul; al patrulea nod rulează doar sarcini de lucru. Cele trei noduri de plan de control asigură cvorumul etcd, astfel încât clusterul supraviețuiește pierderii unuia dintre ele.
Clusterul de management găzduiește serviciile de care depinde restul infrastructurii: management avansat al clusterelor din întreaga flotă, un registru de imagini, o platformă de automatizare, managementul mașinilor, managementul ciclului de viață și un serviciu de director — plus rețelistica definită prin software, DNS-ul și rutarea pe care rulează clusterele înseși.
Sarcinile de lucru ale aplicațiilor rulează pe clustere proprii, separate pe medii, nu doar pe namespace-uri, iar fiecare mediu este împărțit într-un cluster front-end și un cluster back-end. Promovarea între medii este un act deliberat; o modificare în back-end nu poate antrena după ea și front-end-ul.
Planul de control al cloudului privat — identitate, API-ul de calcul și schedulerul, API-ul de rețea, imagini, orchestrare, plasare, panou de administrare, servicii de stocare bloc și de fișiere partajate, telemetrie — rulează ca poduri distribuite pe clusterul de management, nu pe controllere proprii, astfel încât moștenește aceeași înaltă disponibilitate și același ciclu de viață.
Zece noduri mixte per locație rulează împreună calculul și stocarea: instanțe de hipervizor, agenți de rețea virtuală și servicii de volume, alături de daemonii stocării distribuite. Capacitatea pentru mașini virtuale, funcții de rețea și volume persistente crește prin adăugarea de noduri.
Stocare bloc, fișier și obiect pe aceleași noduri care rulează sarcinile de lucru, expusă platformei de containere prin operatorul său de stocare — astfel încât un pod care cere un volum persistent și o mașină virtuală care cere un disc sunt deservite din același pool, replicat între noduri.
O platformă de obiecte separată, cu cinci noduri și interfață S3 standard, păstrează pe termen lung logurile și copiile de backup, cu datele replicate pe toate nodurile, astfel încât pierderea unui nod nu înseamnă pierdere de informație. Este folosită în principal de platforma de containere pentru arhivare.
Două perechi de switch-uri per locație — una pentru conectivitatea serverelor la 10/25G, una pentru 40/100G — fiecare configurată ca pereche virtual port-channel și conectată dual la nucleul de rețea existent la 40 Gbps.
04Arhitectură
Clusterul de management deasupra, stocarea dedesubt
Diagrama prezintă modelul arhitecturii de referință — nu implementarea internă efectivă. Fiecare locație rulează propriul cluster de management, care creează și guvernează clusterele de aplicații de sub el; cloudul privat și stratul de stocare se află dedesubt, iar cele două locații împart același model operațional, cu replicare între ele.
05Modelul de clustere
De ce sunt clusterele separate
Separarea este cel mai ieftin mecanism de siguranță al unei platforme. Mediile nu împart un cluster, iar în interiorul fiecărui mediu nici nivelurile front-end și back-end nu împart unul.
06Stocare
Un singur strat de stocare, toate modurile de acces
Hiperconvergența înseamnă că nodurile care rulează sarcinile de lucru păstrează și datele. Astfel dispare un întreg nivel de hardware — iar capacitatea devine un singur exercițiu de planificare, nu două.
07Reziliență
Ce rezistă la o defecțiune
08Notă de confidențialitate
Nu dezvăluim schema de adresare, denumirile gazdelor, dispunerea rackurilor sau arhitectura tehnologică internă efectivă a proiectului.
Diagrama și cifrele de pe această pagină descriu modelul arhitecturii de referință și dimensiunea proiectului care poate fi comunicată public.