Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 6

2 Requisiti hardware e raccomandazioni

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.

2.1 Configurazioni di architettura multiple

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.

2.2 Configurazione minima del cluster

  • 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.

2.3 Nodi storage oggetto

2.3.1 Requisiti minimi

  • 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.

2.3.2 Dimensioni minime del disco

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.

2.3.3 Dimensioni consigliate per dispositivo DB e WAL di BlueStore

Suggerimento
Suggerimento: ulteriori informazioni

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.

2.3.4 Utilizzo di SSD per giornali di registrazione OSD

Le unità a stato solido (SSD) non hanno parti in movimento. Ciò riduce il tempo di accesso casuale e la latenza di lettura accelerando il throughput dei dati. Poiché il loro prezzo per 1MB è sensibilmente maggiore rispetto al prezzo dei dischi rigidi classici, le SSD sono adatte solo per storage di piccole dimensioni.

Gli OSD possono avere un significativo miglioramento delle prestazioni memorizzando il loro giornale su una SSD e i dati oggetto su un disco rigido separato.

Suggerimento
Suggerimento: condivisione di una SSD per più giornali di registrazione

Poiché i dati del giornale di registrazione occupano relativamente poco spazio, è possibile montare diverse directory di giornale su un singolo disco SSD. Ricordare che con ogni giornale di registrazione condiviso, le prestazioni del disco SSD degradano. Si consiglia di non condividere più di sei giornali di registrazione sullo stesso disco SSD e 12 sui dischi NVMe.

2.3.5 Numero massimo di dischi consigliato

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.

2.4 Nodi monitor

  • 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.

2.5 Nodi Object Gateway

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.

2.6 Nodi Metadata Server

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.

2.7 Salt Master

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.

2.8 Nodi iSCSI

I nodi iSCSI devono avere CPU con sei/otto core e 16 GB di RAM.

2.9 Raccomandazioni di rete

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.

Suggerimento
Suggerimento: nodi configurati tramite DHCP

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"

2.9.1 Aggiunta di una rete privata a un cluster in esecuzione

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.

  1. 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.

  2. Verificare che la rete di cluster privata funzioni come previsto al livello del SO.

  3. Avviare i servizi correlati a Ceph su ogni nodo del cluster.

    root # systemctl start ceph.target

2.9.2 Nodi monitor su diverse sottoreti

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

2.10 Limitazioni dei nomi

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.

2.11 Condivisione di un server da parte di OSD e Monitor

Sebbene sia tecnicamente possibile eseguire Monitor e OSD Ceph sullo stesso server in ambienti di test, si consiglia la presenza di un server separato per ogni nodo monitor in produzione. Il motivo principale sono le prestazioni: più OSD sono nel cluster, più operazioni di I/O devono essere eseguite dai nodi monitor. Quando un server è condiviso tra un nodo monitor e OSD, le operazioni di I/O OSD sono un fattore limitante per il nodo monitor.

Un'altra considerazione è relativa alla condivisione dei dischi tra un OSD, un nodo monitor e il sistema operativo sul server. La risposta è semplice: se possibile, dedicare un disco separato all'OSD e un server separato a un nodo monitor.

Sebbene Ceph supporti OSD basati su directory, un OSD deve sempre avere un disco dedicato diverso da quello per il sistema operativo.

Suggerimento
Suggerimento

Se è davvero necessario eseguire il nodo monitor e OSD sullo stesso server, eseguire il monitor su un disco separato montando il disco sulla directory /var/lib/ceph/mon per prestazioni leggermente migliori.

2.12 Configurazione cluster di produzione consigliata

  • 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

2.13 SUSE Enterprise Storage 6 e altri prodotti SUSE

Questa sezione contiene informazioni importanti sull'integrazione di SUSE Enterprise Storage 6 con altri prodotti SUSE.

2.13.1 SUSE Manager

SUSE Manager e SUSE Enterprise Storage non sono integrati, perciò SUSE Manager non è in grado attualmente di gestire un cluster SUSE Enterprise Storage.

Stampa pagina