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.
Sono richiesti almeno 4 nodi OSD, con 8 dischi OSD ciascuno.
Per gli OSD che non utilizzano BlueStore, è richiesto almeno 1 GB di RAM per terabyte di capacità OSD nominale per ogni nodo di storage OSD. Consigliati 1,5 GB di RAM per terabyte di capacità OSD nominale. Durante il ripristino, 2 GB di RAM per terabyte di capacità OSD nominale possono risultare ottimali.
Per gli OSD che utilizzano BlueStore, calcolare prima la dimensione della RAM consigliata per gli OSD che non utilizzano BlueStore, quindi calcolare 2 GB oltre la dimensione della cache BlueStore di RAM consigliati per ogni processo OSD e scegliere il valore maggiore di RAM dei due risultati. Tenere presente che la cache BlueStore di default è 1 GB per unità HDD e 3 GB per unità SSD di default. Riepilogando, prendere il maggiore tra:
[1GB * OSD count * OSD size]
oppure
[(2 + BS cache) * OSD count]
sono richiesti 1,5 GHz di un core CPU logica per OSD almeno per ogni processo del daemon OSD. Consigliati 2 GHz per processo del daemon OSD. Tenere presente che Ceph esegue un processo del daemon OSD per disco di storage; non contare i dischi riservati esclusivamente per l'uso come giornali di registrazione OSD, giornali di registrazione WAL, metadati omap o qualsiasi combinazione di questi tre casi.
Ethernet 10 Gb (due interfacce di rete vincolate a più switch).
Dischi OSD in configurazioni JBOD.
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.
I nodi OSD devono essere concreti, non virtualizzati, per motivi di prestazioni dei dischi.
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».
Di seguito sono indicate diverse regole per il dimensionamento del dispositivo WAL/DB. Quando si utilizza DeepSea per distribuire gli OSD con BlueStore, si applicano le regole raccomandate automaticamente con notifica pertinente all'amministratore.
10 GB del dispositivo DB per ogni Terabyte della capacità OSD (1/100° dell'OSD).
Tra 500 MB e 2 GB per il dispositivo WAL. La dimensione di WAL dipende dal traffico dati e dal carico di lavoro, non dalla dimensione dell'OSD. Se si sa che un OSD è fisicamente in grado di gestire ridotte scritture e sovrascritture con un throughput molto elevato, sono preferibili più WAL che meno WAL. 1 GB per dispositivo WAL è un buon compromesso che soddisfa molte distribuzioni.
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 la probabilità di riempimento della partizione WAL è molto bassa e quando non è completamente utilizzata lo spazio non viene sprecato ma utilizzato per il funzionamento del DB.
Per condividere il dispositivo DB con WAL, non specificare il dispositivo WAL e specificare solo il dispositivo DB:
bluestore_block_db_path = "/path/to/db/device" bluestore_block_db_size = 10737418240 bluestore_block_wal_path = "" bluestore_block_wal_size = 0
In alternativa, è possibile mettere il WAL sul relativo dispositivo separato. In tale caso, per il funzionamento di WAL si consiglia il dispositivo più veloce.
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. Per le prestazioni ottimali, riservare almeno 2 GB di RAM per terabyte di spazio su disco installato.
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 indicati i requisiti minimi:
3 G di RAM per un daemon del Metadata Server.
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ò comprende l'esecuzione di openATTIC sul Salt master. 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.
sudo 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 242.12.33.12, aggiungere le righe seguenti alla sezione globale:
[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.
Quattro nodi Storage oggetto
Ethernet 10 Gb (due reti vincolate a più switch).
32 OSD per cluster di storage
Il giornale di registrazione OSD può risiedere sul disco OSD
Disco del sistema operativo dedicato per ogni nodo storage oggetto
1 GB di RAM per TB di capacità OSD nominale per ogni nodo storage oggetto
1,5 GHz per OSD per ogni nodo storage oggetto
Monitor Ceph, gateway e Metadata Server possono risiedere sui nodi storage oggetto
Tre nodi Monitor Ceph (richiede SSD per unità SO dedicata)
I nodi Monitor Ceph, Object Gateway e Metadata Server richiedono distribuzione ridondante
iSCSI Gateway, Object Gateway e Metadata Server richiedono ulteriori 4 GB RAM e quattro core
Nodo di gestione separato con 4 GB RAM, quattro core, capacità 1 TB
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 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.