Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Enterprise Storage 7 / Guida alla distribuzione / Presentazione di SUSE Enterprise Storage (SES) / Requisiti hardware e raccomandazioni
Si applica a SUSE Enterprise Storage 7

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 Panoramica sulla rete

Ceph dispone di diverse reti logiche:

  • Una rete di front-end, la rete pubblica.

  • Una rete interna affidabile, ovvero la rete di back-end o rete di cluster. Si tratta di una procedura opzionale.

  • Una o più reti client per i gateway. Si tratta di reti facoltative che non rientrano nell'ambito del presente capitolo.

La rete pubblica è la rete su cui i daemon Ceph comunicano tra di loro e con i client, ciò significa che tutto il traffico del cluster Ceph passa su questa rete, tranne nel caso in cui sia configurata una rete di cluster.

La rete di cluster è la rete di back-end tra i nodi OSD per la replica, il ribilanciamento e il recupero. Se adeguatamente configurata, questa rete facoltativa può fornire fino al doppio della larghezza di banda della rete pubblica con la replica a tre vie di default, dal momento che viene utilizzata dall'OSD primario per inviare due copie agli altri OSD. La rete pubblica consente a client e gateway di comunicare con monitor, manager, nodi MDS e nodi OSD. È inoltre utilizzata da monitor, manager e nodi MDS per la comunicazione con i nodi OSD.

Panoramica sulla rete
Figura 2.1: Panoramica sulla rete

2.1.1 Raccomandazioni di rete

Si consiglia di utilizzare una singola rete a tolleranza di errore con larghezza di banda sufficiente per soddisfare i propri requisiti. Per l'ambiente di rete pubblica Ceph, si consigliano due interfacce di rete associate da 25 GbE (o più veloci) associate tramite 802.3ad (LACP). Questa è considerata come la configurazione di base di Ceph. Se si utilizza anche una rete di cluster, si consigliano quattro interfacce di rete associate da 25 GbE. L'associazione di due o più interfacce di rete offre migliore velocità effettiva tramite l'aggregazione dei collegamenti e, in caso di collegamenti e switch ridondanti, maggiore tolleranza agli errori e gestibilità.

È possibile inoltre creare VLAN per isolare diversi tipi di traffico su un'associazione. Ad esempio, è possibile creare un'associazione per fornire due interfacce VLAN, una per la rete pubblica e una per la rete di cluster. Tuttavia, ciò non è necessario durante la configurazione delle reti Ceph. All'indirizzo https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-iface-bonding sono disponibili ulteriori dettagli sull'associazione delle interfacce.

Isolando i componenti nei domini di errore, si aumenta la tolleranza agli errori. Per ottenere una maggiore tolleranza agli errori della rete, è possibile associare un'interfaccia a due NIC (Network Interface Card) separate, qualora si verificasse un errore su una. Analogamente, associare due switch diversi fornisce maggiore protezione, nel caso si verificasse un errore su uno. Rivolgersi al fornitore delle apparecchiature di rete per impostare il livello adeguato di tolleranza agli errori.

Importante
Importante: rete di amministrazione non supportata

La configurazione della rete di amministrazione aggiuntiva, che consente ad esempio la separazione delle reti SSH, Salt o DNS, non è né testata né supportata.

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. Se ciò avviene, i Ceph MON e OSD non si avvieranno in modo corretto (l'esecuzione di systemctl status ceph\* genererà errori di associazione). Per evitare questo problema, si consiglia di aumentare il timeout del client DHCP ad almeno 30 secondi su ciascun nodo nel cluster di memorizzazione. È 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.1.1.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. Impostare la rete di cluster utilizzando il comando seguente:

    root # ceph config set global cluster_network MY_NETWORK

    Riavviare gli OSD per eseguire l'associazione alla rete di cluster specificata:

    root # systemctl restart ceph-*@osd.*.service
  2. Verificare che la rete di cluster privata funzioni come previsto al livello del SO.

2.1.1.2 Nodi di monitoraggio su sottoreti diverse

Se i nodi monitor sono su sottoreti diverse, ad esempio si trovano in stanze diverse e sono serviti da switch differenti, occorre specificare l'indirizzo di rete pubblica nella notazione CIDR:

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Esempio:

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
Avvertimento
Avvertimento

Se si specifica più di un segmento di rete per la rete pubblica (o di cluster) come descritto in questa sezione, ciascuna di queste sottoreti deve essere in grado di eseguire l'instradamento a tutte le altre, altrimenti i MON e gli altri daemon Ceph su segmenti di rete diversi non potranno comunicare e verrà generato un cluster suddiviso. Inoltre, se si utilizza un firewall, assicurarsi di includere ogni indirizzo IP o sottorete nelle iptables e aprire le porte per questi ultimi su tutti i nodi in base alle esigenze.

2.2 Configurazioni ad architettura multipla

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.

Nota
Nota

Nella documentazione, SYSTEM-ARCH è utilizzato al posto di x86 o Arm.

2.3 Configurazione hardware

La configurazione del cluster consigliata garantisce la migliore esperienza utente con il prodotto. Per i cluster di test o con requisiti di prestazioni inferiori, è descritta la configurazione minima supportata.

2.3.1 Configurazione minima del cluster

La configurazione minima del cluster è costituita da:

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

La configurazione dettagliata prevede:

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

Configurazione minima del cluster
Figura 2.2: Configurazione minima del cluster

2.3.2 Configurazione del cluster di produzione consigliata

Con la crescita del cluster, si consiglia di ricollocare i Ceph Monitor, i Metadata Server e i gateway per separare i nodi e ottenere una maggiore tolleranza agli errori.

  • Sette nodi Storage oggetto

    • Nessun singolo nodo eccede ~15% dello storage totale.

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

    • Ethernet da 25 Gb o superiore, con associazione per la rete pubblica esterna e di cluster interna.

    • 56+ OSD per cluster di storage.

    • Vedere la Sezione 2.4.1, «Requisiti minimi» per ulteriori raccomandazioni.

  • Nodi infrastruttura fisica dedicata.

    • Tre nodi Ceph Monitor: 4 GB RAM, processore a 4 core, SSD RAID 1 per disco.

      Vedere la Sezione 2.5, «Nodi monitor» per ulteriori raccomandazioni.

    • Nodi Object Gateway: 32 GB RAM, processore 8 core, SSD RAID 1 per disco.

      Vedere la Sezione 2.6, «Nodi Object Gateway» per ulteriori raccomandazioni.

    • Nodi iSCSI Gateway: 16 GB RAM, processore 8 core, SSD RAID 1 per disco.

      Vedere la Sezione 2.9, «Nodi iSCSI Gateway» per ulteriori raccomandazioni.

    • Nodi Metadata Server (uno attivo/uno hot standby): 32 GB RAM, processore 8 core, SSD RAID 1 per disco.

      Vedere la Sezione 2.7, «Nodi Metadata Server» per ulteriori raccomandazioni.

    • Un nodo admin SES: 4 GB di RAM, processore 4 core, SSD RAID 1 per disco.

2.3.3 Configurazione multipath

Se si desidera utilizzare l'hardware multipath, assicurarsi che LVM visualizzi multipath_component_detection = 1 nella sezione devices del file di configurazione. È possibile verificare questa istruzione tramite il comando lvm config.

In alternativa, assicurarsi che LVM filtri i componenti mpath di un dispositivo tramite la configurazione di filtro LVM. Si tratta di un'impostazione specifica per l'host.

Nota
Nota

Questa procedura non è consigliata e deve essere presa in considerazione soltanto se non è possibile impostare multipath_component_detection = 1.

Per ulteriori informazioni sulla configurazione multipath, vedere https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

2.4 Nodi storage oggetto

2.4.1 Requisiti minimi

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

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

Nota
Nota

Assicurarsi che i nodi OSD non dispongano di dispositivi di blocco di rete mappati, come immagini iSCSI o dispositivi di blocco RADOS (RADOS Block Device, RBD).

2.4.2 Dimensioni minime del disco

Vi sono due tipi di spazi su disco necessari per l'esecuzione su OSD: lo spazio per il dispositivo WAL/DB e lo spazio primario per i dati memorizzati. Il valore minimo (e di default) per il dispositivo 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.4.3 Dimensioni consigliate per il 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.

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

2.4.4 SSD per partizioni WAL/DB

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 grazie alla memorizzazione delle relative partizioni WAL/DB su un disco SSD e dei dati oggetto su un disco rigido separato.

Suggerimento
Suggerimento: condivisione di un disco SSD con più partizioni WAL/DB

Dal momento che le partizioni WAL/DB occupano relativamente poco spazio, è possibile condividere un disco SSD con più partizioni WAL/DB. Tenere presente che con ogni partizione WAL/DB, le prestazioni del disco SSD diminuiscono. Si consiglia di non condividere più di sei partizioni WAL/DB sullo stesso disco SSD e 12 sui dischi NVMe.

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

2.5 Nodi monitor

  • Sono richiesti almeno tre nodi MON. 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.

  • È possibile combinare nodi OSD, MON oppure Object Gateway 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.6 Nodi Object Gateway

I nodi Object Gateway devono disporre di almeno sei core CPU e 32 GB di RAM. Se nello stesso computer sono co-ubicati altri processi, occorre sommare i loro requisiti.

2.7 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:

  • 4 GB di RAM per ogni daemon del server di metadati.

  • Interfaccia di rete vincolata.

  • CPU da 2,5 GHz con almeno 2 core.

2.8 Nodo admin

Richiesti almeno 4 GB di RAM e una CPU quad-core. Ciò include l'esecuzione del Salt Master sul nodo admin. Per i grandi cluster con centinaia di nodi, consigliati 6 GB di RAM.

2.9 Nodi iSCSI Gateway

I nodi iSCSI Gateway devono disporre di almeno sei core CPU e 16 GB di RAM.

2.10 SES e altri prodotti SUSE

Questa sezione contiene informazioni importanti sull'integrazione di SES con altri prodotti SUSE.

2.10.1 SUSE Manager

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

2.11 Limitazioni di denominazione

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.12 Condivisione di un server da parte di OSD e monitor

Sebbene sia tecnicamente possibile eseguire OSD e MON 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 si trovano nel cluster, più operazioni di I/O devono essere eseguite dai nodi MON. Quando un server è condiviso tra un nodo MON 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 MON 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 MON e OSD sullo stesso server, eseguire il MON su un disco separato montando il disco sulla directory /var/lib/ceph/mon per prestazioni leggermente migliori.