Tocmai am instalat un cluster de 6 servere Proxmox, folosind 3 noduri ca stocare Ceph și 3 noduri ca noduri de calcul.
Ne confruntăm cu probleme ciudate și critice cu performanța și stabilitatea cluster-ului nostru.
Accesul la VM și la Proxmox web tinde să se blocheze fără un motiv evident, de la câteva secunde la câteva minute - atunci când accesați direct prin consola SSH, RDP sau VNC.
Chiar și gazdele Proxmox par să fie la îndemână, așa cum se poate vedea în această captură de monitorizare. Acest lucru creează, de asemenea, probleme cu clusterul Proxmox, unele servere care nu se sincronizează.
De exemplu, atunci când testați ping-ul între nodurile gazdă, ar funcționa perfect câteva ping-uri, s-ar bloca, ar continua (fără nicio creștere a timpului de ping-back - încă <1ms), ar fi blocat din nou etc.
Am avut câteva probleme de performanță inițial, dar acestea au fost rezolvate prin ajustarea MTU-urilor NIC-urilor la 9000 (+1300% îmbunătățire citire/scriere). Acum trebuie să stabilim toate acestea, pentru că acum nu este gata de producție.
Configurare hardware
Avem o arhitectură de rețea similară cu cea descrisă în documentul oficial al lui Ceph, cu o rețea publică de 1 Gbps și o rețea de cluster de 10 Gbps.
Acestea sunt conectate la două plăci de rețea fizice pentru fiecare dintre cele 6 servere.
Noduri de server de stocare:
- CPU: Xeon E-2136 (6 nuclee, 12 fire), 3,3 GHz, Turbo 4,5 GHz
- RAM: 16 GB
- Depozitare:
- 2x RAID 1 256 GB NVMe, LVM
- volum logic rădăcină de sistem: 15 GB (~55% gratuit)
- schimb: 7,4 GB
- WAL pentru OSD2: 80 GB
- SSD SATA de 4 TB (OSD1)
- HDD SATA de 12 TB (OSD2)
- Controller de interfață de rețea:
- Intel Corporation I350 Gigabit: conectat la o rețea publică de 1 Gbps
- Intel Corporation 82599 10 Gigabit: conectat la o rețea de cluster (internă) de 10 Gbps
Noduri de server de calcul:
- CPU: Xeon E-2136 (6 nuclee, 12 fire), 3,3 GHz, Turbo 4,5 GHz
- RAM: 64 GB
- Depozitare:
- 2x RAID 1 256 GB SSD SATA
- volum logic rădăcină de sistem: 15 GB (~65% gratuit)
Software: (pe toate cele 6 noduri)
- Proxmox 7.0-13, instalat pe Debian 11
- Ceph v16.2.6, instalat cu GUI Proxmox
- Ceph Monitor pe fiecare nod de stocare
- Manager Ceph pe nodul de stocare 1 + 3
Configurația Ceph
ceph.conf al clusterului:
[global]
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx
cluster_network = 192.168.0.100/30
fsid = 97637047-5283-4ae7-96f2-7009a4cfbcb1
mon_allow_pool_delete = adevărat
mon_host = 1.2.3.100 1.2.3.101 1.2.3.102
ms_bind_ipv4 = adevărat
ms_bind_ipv6 = fals
osd_pool_default_min_size = 2
osd_pool_default_size = 3
public_network = 1.2.3.100/30
[client]
keyring = /etc/pve/priv/$cluster.$name.keyring
[mds]
keyring = /var/lib/ceph/mds/ceph-$id/keyring
[mds.asrv-pxdn-402]
gazdă = asrv-pxdn-402
mds standby pentru nume = pve
[mds.asrv-pxdn-403]
gazdă = asrv-pxdn-403
mds_standby_for_name = pve
[mon.asrv-pxdn-401]
public_addr = 1.2.3.100
[mon.asrv-pxdn-402]
public_addr = 1.2.3.101
[mon.asrv-pxdn-403]
public_addr = 1.2.3.102
Întrebări:
- Este arhitectura noastră corectă?
- Monitorii și Managerii Ceph ar trebui să fie accesați prin intermediul rețelei publice? (Ceea ce ne-a oferit configurația implicită a Proxmox)
- Știe cineva de unde vin aceste tulburări/instabilități și cum să le rezolvi?
[Editați | ×]
- Este corect să utilizați o dimensiune implicită a pool-ului de 3, când aveți 3 noduri de stocare? Inițial am fost tentat să folosesc 2, dar nu am putut găsi exemple similare și am decis să folosesc configurația implicită.
Probleme observate
- Am observat că arping-ul returnează cumva ping-uri de la două adrese MAC (NIC publică și NIC privată), ceea ce nu are niciun sens, deoarece acestea sunt NIC-uri separate, legate printr-un comutator separat.
Aceasta poate face parte din problema rețelei.
- În timpul unei sarcini de backup pe una dintre VM (backup pe un server de backup Proxmox, la distanță fizică), pare să afecteze cumva clusterul. VM-ul rămâne blocat în modul de rezervă/blocat, chiar dacă backupul pare să se fi terminat corect (vizibil și accesibil pe serverul de rezervă).
- De la prima problemă de rezervă, Ceph a încercat să se reconstruiască singur, dar nu a reușit să facă acest lucru. Este într-o stare degradată, ceea ce indică faptul că îi lipsește un daemon MDS. Cu toate acestea, verific din nou și există demoni MDS care funcționează pe nodul de stocare 2 și 3.
A lucrat la reconstruirea ei înșiși până când a rămas blocat în această stare.
Iată starea:
root@storage-node-2:~# ceph -s
cluster:
ID: 97637047-5283-4ae7-96f2-7009a4cfbcb1
sănătate: HEALTH_WARN
demoni MDS de așteptare insuficiente disponibile
Bătăi lente ale inimii OSD pe spate (cea mai lungă 10055,902 ms)
Bătăi lente ale inimii OSD în față (cea mai lungă 10360,184 ms)
Redundanță de date degradată: 141397/1524759 obiecte degradate (9,273%), 156 pgs degradate, 288 pgs subdimensionate
Servicii:
luni: 3 demoni, cvorum asrv-pxdn-402, asrv-pxdn-401, asrv-pxdn-403 (vârsta 4 m)
mgr: asrv-pxdn-401(activ, de la 16m)
mds: 1/1 demoni în sus
osd: 6 osds: 4 în sus (din 22h), 4 in (din 21h)
date:
volume: 1/1 sănătos
piscine: 5 piscine, 480 pg
obiecte: 691,68k obiecte, 2,6 TiB
utilizare: 5,2 TiB utilizat, 24 TiB / 29 TiB disponibil
pgs: 141397/1524759 obiecte degradate (9,273%)
192 activ+curat
156 active+subdimensionate+degradate
132 active+subdimensionate
[editare 2]
root@storage-node-2:~# arbore ceph osd
ID CLASA GREUTATE TIP NUME STARE REGREINTARE PRI-AFF
-1 43.65834 rădăcină implicită
-3 14.55278 gazdă asrv-pxdn-401
0 hdd 10.91409 osd.0 up 1.00000 1.00000
3 ssd 3.63869 osd.3 up 1.00000 1.00000
-5 14.55278 gazdă asrv-pxdn-402
1 hdd 10.91409 osd.1 up 1.00000 1.00000
4 ssd 3.63869 osd.4 up 1.00000 1.00000
-7 14.55278 gazdă asrv-pxdn-403
2 hdd 10.91409 osd.2 jos 0 1.00000
5 ssd 3,63869 osd.5 jos 0 1,00000
