2 Requisiti hardware e raccomandazioni #

Almeno quattro nodi fisici (nodi OSD) con la co-location dei servizi;

Ethernet Dual-10 Gb come rete associata;

Un nodo admin separato (può essere virtualizzato su un nodo esterno).

Nodo admin separato con 4 GB di RAM, quattro core, capacità di memorizzazione di 1 TB. In genere questo è il nodo Salt Master. I servizi e i gateway Ceph, come Ceph Monitor, Metadata Server, Ceph OSD, Object Gateway o NFS Ganesha non sono supportati sul nodo admin poiché quest'ultimo deve coordinare i processi di upgrade e aggiornamento del cluster in modo indipendente.

Almeno quattro nodi OSD fisici, con otto dischi OSD ciascuno; vedere la Sezione 2.4.1, «Requisiti minimi» per i requisiti.

La capacità complessiva del cluster deve essere ridimensionata per fare in modo che, anche nel caso di mancata disponibilità di un nodo, la capacità complessiva in uso (inclusa la ridondanza) non superi l'80%.

Tre istanze di Ceph Monitor. Per ragioni di latenza, i monitor devono essere eseguiti dallo storage SSD/NVMe e non da HDD.

Monitor, Metadata Server e gateway possono trovarsi in co-location sui nodi OSD; vedere la Sezione 2.12, «Condivisione di un server da parte di OSD e monitor» per informazioni sulla co-location dei monitor. In caso di co-location dei servizi, occorre aggiungere i requisiti di memoria e CPU.

iSCSI Gateway, Object Gateway e Metadata Server richiedono almeno 4 GB di RAM incrementale e quattro core.

Se si utilizzano CephFS, S3/Swift e iSCSI, per garantire ridondanza e disponibilità sono necessarie almeno due istanze dei rispettivi ruoli (Metadata Server, Object Gateway, iSCSI).

I nodi devono essere dedicati a SUSE Enterprise Storage e non devono essere utilizzati per altri workload fisici, in container o virtualizzati.

Se i gateway (iSCSI, Object Gateway, NFS Ganesha, Metadata Server ecc.) sono distribuiti all'interno di macchine virtuali, queste ultime non devono essere ospitate sulle macchine fisiche che servono altri ruoli del cluster (ciò non è necessario, poiché sono supportati come servizi in co-location).

Se si esegue la distribuzione dei servizi come macchine virtuali su Hypervisor all'esterno del cluster fisico principale, occorre rispettare i domini di errore per assicurare la ridondanza.

Ad esempio, non distribuire più ruoli dello stesso tipo sullo stesso Hypervisor (come più istanze MDS o MON).

Se si esegue la distribuzione all'interno delle macchine virtuali, è particolarmente importante verificare che la connettività di rete dei nodi sia ottimale e che l'orario venga sincronizzato correttamente.

I nodi dell'Hypervisor devono avere dimensioni adeguate per evitare interferenze provenienti da altri workload che consumano risorse di CPU, RAM, rete e storage.

Sette nodi Storage oggetto

Nodi infrastruttura fisica dedicata.

Le seguenti raccomandazioni sulla CPU si applicano ai dispositivi indipendentemente dall'utilizzo di Ceph:

Reti 10 GbE (pubbliche/client e interne) 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 28.4.1, «Configurazione del 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 e disco dedicato per il sistema operativo, preferibilmente in una configurazione RAID 1.

Allocare almeno altri 4 GB di RAM se questo host OSD ospiterà parte di un pool di cache utilizzato per la suddivisione in livelli della cache.

Monitor Ceph, gateway e Metadata Server possono risiedere sui nodi storage oggetto.

Per motivi legati alle prestazioni del disco, i nodi OSD sono nodi bare metal. Nessun altro workload deve essere eseguito su un nodo OSD a meno che non si tratti di una configurazione minima di Ceph Monitor e Ceph Manager.

SSD per giornale di registrazione con rapporto 6:1 tra giornale SSD e OSD.

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.

Importante

Per le distribuzioni a carico elevato, soprattutto in caso di elevato utilizzo di RGW o CephFS, si consigliano volumi di database maggiori. Riservare una parte di capacità (slot) per l'installazione di altro hardware per disporre di ulteriore spazio sul database, se necessario.

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.

Nel Sezione 13.4.3, «Aggiunta di OSD tramite la specifica dei DriveGroups» è possibile trovare ulteriori informazioni su come specificare un layout OSD.

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 agli errori. 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.