I requisiti hardware di Ceph dipendono strettamente dal carico di lavoro degli IO. Tenere presente i seguenti requisiti hardware e raccomandazioni come base di partenza per una pianificazione dettagliata.
In generale, le raccomandazioni date sono riferite a un processo. Se sullo stesso computer sono ubicati più processi, occorre sommare i requisiti di CPU, RAM, disco e rete.
SUSE Enterprise Storage supporta le architetture x86 e Arm. Durante la valutazione di ciascuna architettura, è importante osservare che dalla prospettiva dei core per OSD, frequenza e RAM, non esistono reali differenze tra le architetture CPU in termini di ridimensionamento.
Come per i processori x86 (non-server) di dimensioni più piccole, i core basati su Arm a prestazioni ridotte potrebbero non fornire un'esperienza ottimale, soprattutto se utilizzati per i pool con codice di cancellazione.
Sono richiesti almeno quattro nodi OSD, con otto dischi OSD ciascuno.
Tre nodi Monitor Ceph (richiede SSD per unità SO dedicata).
Per iSCSI Gateway, Object Gateway e server di metadati sono richiesti ulteriori 4 GB di RAM e quattro core.
I nodi di Ceph Monitor, Object Gateway e del server di metadati richiedono una distribuzione ridondante.
Nodo admin separato con 4 GB di RAM, quattro core, capacità di 1 TB. In genere questo è il nodo Salt master. I servizi e i gateway Ceph, come Ceph Monitor, Ceph Manager, server di metadati, Ceph OSD, Object Gateway o NFS Ganesha, non sono supportati sul nodo admin.
Raccomandazioni sulla CPU:
1 thread CPU da 2 GHz per unità a rotazione
2 thread CPU da 2 GHz per SSD
4 thread CPU da 2 GHz per NVMe
Reti 10 GbE (pubbliche/client e di back-end) separate: 4 da 10 GbE obbligatorie, 2 da 25 GbE consigliate.
RAM totale richiesta = numero di OSD x (1 GB + osd_memory_target
) + 16 GB
Per ulteriori dettagli su osd_memory_target
, consultare questo riferimento: Sezione 16.2.1, «Ridimensionamento automatico della cache».
Dischi OSD nelle configurazioni JBOD o configurazioni RAID-0 individuali.
Il giornale di registrazione OSD può risiedere sul disco OSD.
I dischi OSD devono essere utilizzati esclusivamente da SUSE Enterprise Storage.
SSD/disco dedicato per il sistema operativo, preferibilmente in una configurazione RAID 1.
Se questo host OSD conterrà parte di un pool di cache utilizzato per tiering della cache, allocare almeno ulteriori 4 GB di RAM.
Monitor Ceph, gateway e Metadata Server possono risiedere sui nodi storage oggetto.
Per ragioni di prestazioni del disco, per i nodi OSD si consiglia di utilizzare computer bare metal e non macchine virtuali.
Vi sono due tipi di spazi su disco necessari da eseguire su OSD: lo spazio per il giornale di registrazione del disco (per FileStore) o dispositivo WAL/DB (per BlueStore) e lo spazio primario per i dati memorizzati. Il valore minimo (e di default) per il giornale di registrazione/WAL/DB è 6 GB. Lo spazio minimo per i dati è pari a 5 GB, in quanto a partizioni più piccole di 5 GB viene assegnato automaticamente il peso di 0.
Perciò, sebbene lo spazio minimo su disco per un OSD sia 11 GB, si sconsigliano dischi inferiori a 20 GB, anche per scopi di test.
Per ulteriori informazioni su BlueStore, consultare Sezione 1.4, «BlueStore».
Si consiglia di prenotare 4 GB per il dispositivo WAL. Le dimensioni consigliate per il dispositivo DB sono 64 GB per la maggior parte dei workload.
Se si intende mettere il dispositivo WAL e DB sullo stesso disco, si consiglia di utilizzare una singola partizione per entrambi i dispositivi, invece di avere una partizione separata per ciascuno. Ciò consente a Ceph di utilizzare il dispositivo DB anche per il funzionamento di WAL. La gestione dello spazio del disco è quindi più efficace in quanto Ceph utilizza la partizione DB per WAL solo se serve. Un altro vantaggio è che le probabilità che la partizione WAL si riempia sono molto basse e, quando questa non è utilizzata completamente, il suo spazio non viene sprecato ma utilizzato per le operazioni del dispositivo DB.
Per condividere il dispositivo DB con WAL, non specificare il dispositivo WAL e specificare solo il dispositivo DB.
Nella Sezione 5.5.2, «DriveGroups» è possibile trovare ulteriori informazioni su come specificare un layout OSD.
Il server può contenere tutti i dischi consentiti. Quando si pianifica il numero di dischi per server, vi sono alcuni elementi da tenere presente:
Ampiezza della banda di rete. Più dischi sono presenti in un server, più dati occorre trasferire tramite scheda di rete per le operazioni di scrittura sul disco.
Memoria. Viene utilizzata una RAM superiore a 2 GB per la cache BlueStore. Con l'opzione osd_memory_target
di default di 4 GB, il sistema dispone di dimensioni iniziali della cache ragionevoli per i supporti a rotazione. Se si utilizzano SSD o NVME, prendere in considerazione di aumentare le dimensioni della cache e l'allocazione della RAM per ogni OSD per ottimizzare le prestazioni.
Tolleranza di errore. In caso di guasto del server completo, più dischi sono presenti, più OSD vengono persi temporaneamente dal cluster. Inoltre, per mantenere in esecuzione le regole di replicazione, occorre copiare tutti i dati dal server guasto negli altri nodi nel cluster.
Sono richiesti almeno tre nodi Monitor Ceph. Il numero di monitor deve sempre essere dispari (1+2n).
4 GB di RAM.
Processore con quattro core logici.
Si consiglia un'unità SSD o altro tipo di storage sufficientemente veloce per i monitor, in particolare per il percorso /var/lib/ceph
su ogni nodo monitor, in quanto il quorum potrebbe essere instabile con alte latenze del disco. Si consigliano due dischi in configurazione RAID 1 per ridondanza. Si consiglia di utilizzare dischi separati o almeno partizioni del disco separate per i processi monitor per proteggere lo spazio su disco disponibile del monitor da elementi come file di registro che diventano troppo grandi.
Deve essere presente solo un processo monitor per nodo.
Mischiare nodi OSD, monitor o Object Gateway è possibile solo se sono disponibili sufficienti risorse hardware. Ciò significa che si devono sommare i requisiti per tutti i servizi.
Due interfacce di rete associate a più switch.
I nodi Object Gateway devono avere CPU con sei - otto core e 32 GB di RAM (consigliati 64 GB). Se nello stesso computer sono co-ubicati altri processi, occorre sommare i loro requisiti.
Il corretto dimensionamento dei nodi Metadata Server dipende dal caso d'uso specifico. In genere, il numero di file aperti che deve gestire il Metadata Server è proporzionale alla quantità di CPU e RAM richiesta. Di seguito sono riportati i requisiti minimi:
3 GB di RAM per ogni daemon del server di metadati.
Interfaccia di rete vincolata.
CPU da 2,5 GHz con almeno 2 core.
Richiesti almeno 4 GB di RAM e una CPU quad-core. Ciò include l'esecuzione del Ceph Dashboard sul nodo admin. Per i grandi cluster con centinaia di nodi, consigliati 6 GB di RAM.
I nodi iSCSI devono avere CPU con sei/otto core e 16 GB di RAM.
L'ambiente di rete in cui si intende eseguire Ceph deve essere idealmente un insieme vincolato di almeno due interfacce di rete suddiviso logicamente in una parte pubblica e una parte interna affidabile che utilizza VLAN. Si consiglia la modalità di vincolo 802.3ad se possibile per fornire una resilienza e un'ampiezza di banda massima.
La VLAN pubblica fornisce il servizio ai clienti, mentre la parte interna fornisce la comunicazione di rete Ceph autenticata. Il motivo principale è che sebbene Ceph fornisca automazione e protezione dagli attacchi dopo aver istituito le chiavi segrete, i messaggi utilizzati per configurare tali chiavi possono essere trasferiti solo in modo aperto e vulnerabile.
Se i nodi di storage sono configurati tramite DHCP, i timeout default possono non essere sufficienti per configurare correttamente la rete prima dell'avvio dei vari daemon Ceph. In questo caso, gli OSD e MON Ceph non si avviano correttamente (l'esecuzione di systemctl status ceph\*
determina errori del tipo "unable to bind"). Per evitare questo problema, si consiglia di aumentare il timeout del client DHCP ad almeno 30 secondi su ogni nodo nel cluster di storage. È possibile fare questo modificando le impostazioni seguenti su ogni nodo:
In /etc/sysconfig/network/dhcp
, impostare
DHCLIENT_WAIT_AT_BOOT="30"
In /etc/sysconfig/network/config
, impostare
WAIT_FOR_INTERFACES="60"
Se non si specifica una rete di cluster durante la distribuzione, Ceph presume un ambiente di rete pubblica singola. Mentre Ceph funziona bene con una rete pubblica, le sue prestazioni e sicurezza aumentano quando si imposta una seconda rete di cluster privata. Per supportare due reti, ogni nodo Ceph deve avere almeno due schede di rete.
Occorre applicare le seguenti modifiche a ogni nodo Ceph. È relativamente rapido farlo con un piccolo cluster, ma può essere necessario molto tempo in caso di cluster contenente centinaia o migliaia di nodi.
Arrestare i servizi correlati a Ceph su ogni nodo del cluster.
Aggiungere una riga a /etc/ceph/ceph.conf
per definire la rete di cluster, ad esempio:
cluster network = 10.0.0.0/24
Se occorre specificamente assegnare indirizzi IP statici o ignorare le impostazioni della rete cluster
, è possibile farlo con cluster addr
opzionale.
Verificare che la rete di cluster privata funzioni come previsto al livello del SO.
Avviare i servizi correlati a Ceph su ogni nodo del cluster.
root #
systemctl start ceph.target
Se i nodi monitor sono su diverse sottoreti, ad esempio si trovano in stanze diverse e serviti da switch differenti, occorre regolare di conseguenza il file ceph.conf
. Ad esempio, se i nodi hanno gli indirizzi IP 192.168.123.12, 1.2.3.4 e 242.12.33.12, aggiungere le righe seguenti alla relativa sezione global
:
[global] [...] mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12 mon initial members = MON1, MON2, MON3 [...]
Inoltre, se occorre specificare una rete o un indirizzo pubblico per monitor, occorre aggiungere una sezione [mon.X]
per ogni monitor:
[mon.MON1] public network = 192.168.123.0/24 [mon.MON2] public network = 1.2.3.0/24 [mon.MON3] public network = 242.12.33.12/0
Ceph non supporta in genere i caratteri non ASCII nei file di configurazione, nei nomi di pool, nomi utente e così via. Quando si configura un cluster Ceph, si consiglia di utilizzare solo caratteri alfanumerici semplici (A-Z, a-z, 0-9) e punteggiatura minima (".", "-", "_") in tutti i nomi di configurazione/oggetto Ceph.
Sette nodi Storage oggetto
Nessun singolo nodo eccede ~15% dello storage totale
Ethernet 10 Gb (quattro reti fisiche vincolate a più switch).
56+ OSD per cluster di storage
Dischi SO RAID 1 per ogni nodo di storage OSD
SSD per giornale di registrazione con rapporto 6:1 tra giornale SSD e OSD
1,5 GB di RAM per TB di capacità OSD nominale per ogni nodo storage oggetto
2 GHz per OSD per ogni nodo storage oggetto
Nodi infrastruttura fisica dedicata
Tre nodi Ceph Monitor: 4 GB RAM, processore a 4 core, SSD RAID 1 per disco
Un nodo gestione SES: 4 GB RAM, processore 4 core, SSD RAID 1 per disco
Distribuzione fisica ridondante di nodi gateway o Metadata Server:
Nodi Object Gateway: 32 GB RAM, processore 8 core, SSD RAID 1 per disco
Nodi iSCSI Gateway: 16 GB RAM, processore 4 core, SSD RAID 1 per disco
Nodi Metadata Server (uno attivo/uno hot standby): 32 GB RAM, processore 8 core, SSD RAID 1 per disco
Questa sezione contiene informazioni importanti sull'integrazione di SUSE Enterprise Storage 6 con altri prodotti SUSE.
SUSE Manager e SUSE Enterprise Storage non sono integrati, perciò SUSE Manager non è in grado attualmente di gestire un cluster SUSE Enterprise Storage.