In questo capito sono fornite le informazioni necessarie per migliorare le prestazioni del cluster Ceph e vengono forniti i suggerimenti su come impostare il cluster.
Per default, Ceph esegue la pulitura leggera (ulteriori dettagli sono disponibili nella Sezione 6.5, «Pulitura») giornaliera e la pulitura approfondita settimanale. Con la pulitura leggera vengono verificati le dimensioni e i checksum degli oggetti per assicurare che i gruppi di posizionamento memorizzino gli stessi dati oggetto. Con la pulitura approfondita viene verificato il contenuto di un oggetto con quello delle rispettive repliche per assicurare che i contenuti effettivi siano gli stessi. Il prezzo per la verifica dell'integrità dei dati è un carico I/O maggiore sul cluster durante la procedura di pulitura.
Le impostazioni di default consentono ai Ceph OSD di iniziare la pulitura in momenti inappropriati, ad esempio durante i periodi di carichi pesanti. I clienti possono riscontrare latenza e prestazioni scarse quando le operazioni di pulitura sono in conflitto con le rispettive operazioni. In Ceph sono disponibili diverse impostazioni di pulitura che possono limitare la pulitura a periodi con carichi inferiori o durante le ore non di punta.
Se il cluster riscontra carichi elevati durante il giorno e carichi bassi durante la notte, considerare di limitare la pulitura alle ore notturne, ad esempio dalle 23.00 alle 06.00:
[osd] osd_scrub_begin_hour = 23 osd_scrub_end_hour = 6
Se la restrizione dell'orario non è un metodo efficace per determinare la pianificazione di una pulitura, considerare di utilizzare l'opzione osd_scrub_load_threshold
. Il valore di default è 0,5, ma è possibile modificarlo per condizioni di carico inferiore:
[osd] osd_scrub_load_threshold = 0.25
Potrebbe essere necessario interrompere gli ODS per la manutenzione periodica. Se non si desidera che CRUSH esegua automaticamente il ribilanciamento del cluster in modo da evitare il trasferimento di grandi quantità di dati, prima impostare il cluster su noout
:
root@minion >
ceph osd set noout
Quando il cluster è impostato su noout
, è possibile iniziare a interrompere gli OSD nel dominio di errore per il quale è richiesta la manutenzione:
root@minion >
systemctl stop ceph-osd@OSD_NUMBER.service
Per ulteriori informazioni, vedere Sezione 3.1.2, «Avvio, interruzione e riavvio di servizi individuali».
Una volta completata la manutenzione, avviare di nuovo gli OSD:
root@minion >
systemctl start ceph-osd@OSD_NUMBER.service
Dopo l'avvio dei servizi OSD, annullare l'impostazione noout
:
root@minion >
ceph osd unset noout
Ceph richiede la sincronizzazione precisa dell'orario tra nodi particolari. Si deve configurare un nodo con il proprio server NTP. Anche se è possibile puntare tutte le istanze ntpd a un server dell'orario pubblico remoto, si sconsiglia di farlo con Ceph. Con tale configurazione, ciascun nodo del cluster dispone di un deamon NTP proprio che comunica continuamente su Internet con un set di tre o quattro server dell'orario, tutti abbastanza distanziati. Questa soluzione comporta un alto grado di variabilità della latenza, per cui è difficile, se non impossibile, mantenere l'orologio in moto al di sotto di 0,05 secondi (che è il valore richiesto dai Ceph monitor).
Utilizzare quindi un computer singolo come server NTP per l'intero cluster. L'istanza ntpd del server NTP può quindi puntare al server NTP (pubblico) remoto o può disporre di una propria origine dell'orario. Le istanze ntpd su tutti i nodi vengono quindi puntate a tale server locale. Tale soluzione presenta diversi vantaggi, come l'eliminazione del traffico di rete inutile e gli sfasamenti di orario, nonché la riduzione del carico sui server NTP pubblici. Per informazioni dettagliate su come configurare il server NTP, fare riferimento a SUSE Linux Enterprise Server Administration Guide (in lingua inglese).
Quindi, per modificare l'orario sul cluster, eseguire quanto riportato di seguito:
Talvolta potrebbe essere necessario impostare indietro l'ora, ad esempio nel passaggio dall'ora legale all'ora solare. Non è consigliato spostare indietro l'ora per un periodo più lungo di quello di inattività del cluster. Lo spostamento dell'ora in avanti non causa alcun problema.
Interrompere tutti i client che accedono al cluster Ceph, soprattutto quelli che utilizzano iSCSI.
Spegnere il cluster Ceph. Su ciascun nodo eseguire:
systemctl stop ceph.target
Se si utilizzano Ceph e SUSE OpenStack Cloud, interrompere anche SUSE OpenStack Cloud.
Verificare che il server NTP sia configurato correttamente, dove l'ora di tutti daemon ntpd è ricavata da una o più origini nella rete locale.
Impostare l'ora corretta sul server NTP.
Verificare che NTP sia in esecuzione e funzioni correttamente, quindi eseguire su tutti i nodi:
status ntpd.service
oppure
ntpq -p
Avviare tutti i nodi di monitoraggio e verificare che non vi siano sfasamenti di orario:
systemctl start target
Avviare tutti i nodi OSD.
Avviare altri servizi Ceph.
Avviare SUSE OpenStack Cloud se disponibile.
Quando i dati vengono scritti negli OSD in modo uniforme, il cluster è considerato bilanciato. A ciascun OSD in un cluster viene assegnato il rispettivo peso. Il peso è un numero relativo e indica a Ceph la quantità di dati da scrivere nell'OSD correlato. Più alto è il peso, maggiore sarà la quantità di dati che vengono scritti. Se il peso di un OSD è pari a zero, non verranno scritti dati al suo interno. Se il peso di un OSD è relativamente alto rispetto ad altri OSD, in esso verrà scritta una grande porzione di dati causando uno sbilanciamento del cluster.
I cluster non bilanciati hanno prestazioni scarse e nel caso in cui un OSD dal peso elevato si blocchi improvvisamente, è necessario spostare una gran quantità di dati in altri OSD, con un conseguente rallentamento del cluster.
Per evitare tale problema, è necessario verificare regolarmente la quantità di dati scritti negli ODS. Se la quantità è compresa tra 30% e 50% della capacità di un gruppo di OSD specificato da un determinato set di regole, è necessario pesare di nuovo gli OSD. Verificare la presenta di dischi individuali e scoprire quali si riempiono più velocemente degli altri (o generalmente sono più lenti) e ridurne il peso. La stessa cosa vale per gli OSD in cui la quantità di dati scritti è insufficiente: è possibile aumentarne il peso in modo che Ceph scriva in essi una quantità maggiore di dati. Nell'esempio seguente, si individuerà il peso di un OSD con ID 13, che verrà modificato da 3 a 3,05:
$ ceph osd tree | grep osd.13 13 3 osd.13 up 1 $ ceph osd crush reweight osd.13 3.05 reweighted item id 13 name 'osd.13' to 3.05 in crush map $ ceph osd tree | grep osd.13 13 3.05 osd.13 up 1
Il comando ceph osd reweight-by-utilization
threshold consente di automatizzare il processo di riduzione del peso degli OSD utilizzati eccessivamente. Per default i pesi saranno arrotondati per difetto negli OSD che raggiungono il 120% di utilizzo medio, ma se si include la soglia verrà utilizzata invece tale percentuale.
Per default SUSE Linux Enterprise è installato su una partizione Btrfs. La directory /var/lib/ceph
deve essere esclusa dagli snapshot e dai rollback Btrfs, soprattutto quando sul nodo è in esecuzione un MON. In DeepSea viene fornito lo strumento di esecuzione fs
che è in grado di configurare un sottovolume per questo percorso.
Se si configura il cluster per la prima volta, è necessario soddisfare i requisiti seguenti prima di poter utilizzare lo strumento di esecuzione DeepSea:
Salt e DeepSea sono installati correttamente e funzionano come descritto nella presente documentazione.
salt-run state.orch ceph.stage.0
è stato richiamato per sincronizzare tutti i moduli Salt e DeepSea nei minion.
Ceph non è ancora installato, pertanto ceph.stage.3 non è stato ancora eseguito e /var/lib/ceph
non esiste.
Se il cluster è già installato, è necessario soddisfare i requisiti seguenti prima di poter utilizzare lo strumento di esecuzione DeepSea:
È stato eseguito l'upgrade a SUSE Enterprise Storage e il cluster è controllato da DeepSea.
Il cluster Ceph è attivo e integro.
Il processo di upgrade ha sincronizzato i moduli Salt e DeepSea in tutti i nodi minion.
Su Salt Master eseguire:
root@master #
salt-run
state.orch ceph.migrate.subvolume
Nei nodi senza una directory /var/lib/ceph
esistente, in un nodo alla volta sarà possibile:
Creare /var/lib/ceph
come sottovolume Btrfs @/var/lib/ceph
.
Montare il nuovo sottovolume e aggiornare /etc/fstab
in modo appropriato.
Disabilitare la copia su scrittura per /var/lib/ceph
.
Nei nodi con un'installazione Ceph esistente, in un nodo alla volta sarà possibile:
Terminare l'esecuzione dei processi Ceph.
Smontare gli OSD sul nodo.
Creare il sottovolume Btrfs @/var/lib/ceph
ed eseguire la migrazione dei dati /var/lib/ceph
esistenti.
Montare il nuovo sottovolume e aggiornare /etc/fstab
in modo appropriato.
Disabilitare la copia su scrittura per /var/lib/ceph/*
, omettendo /var/lib/ceph/osd/*
.
Montare di nuovo gli OSD.
Riavviare i daemon Ceph.
Per questa installazione viene utilizzato il nuovo strumento di esecuzione fs
.
Esaminare lo stato di /var/lib/ceph
su tutti i nodi e stampare i suggerimenti su come procedere:
root@master #
salt-run
fs.inspect_var
In tal modo verrà restituito uno dei seguenti comandi:
salt-run fs.create_var salt-run fs.migrate_var salt-run fs.correct_var_attrs
Eseguire il comando restituito al passaggio precedente.
Se si verifica un errore su uno dei nodi, verrà interrotta anche l'esecuzione per tutto gli altri nodi e lo strumento di esecuzione tenterà di ripristinare le modifiche apportate. Consultare i file di log sui minion problematici per determinare la natura del problema. È possibile eseguire di nuovo lo strumento di esecuzione una volta risolto il problema.
Il comando salt-run fs.help
fornisce un elenco di tutti i comandi dello strumento di esecuzione e del modulo per il modulo fs
.
Per i daemon OSD, le operazioni di lettura/scrittura sono critiche per mantenere bilanciato il cluster Ceph. Spesso sono richiesti numerosi file aperti per eseguire operazioni di lettura e scrittura contemporaneamente. A livello di sistema operativo, il numero massimo di file aperti simultaneamente è denominato "numero massimo di descrittori di file".
Per impedire che gli OSD esauriscano i descrittori di file, è possibile ignorare il valore di default del sistema operativo e specificare il numero in /etc/ceph/ceph.conf
, ad esempio:
max_open_files = 131072
Dopo che si modifica max_open_files
, è necessario riavviare il servizio OSD sul nodo Ceph pertinente.
In questa sezione è descritto un argomento avanzato riservato solo agli esperti di memorizzazione e agli sviluppatori. Si tratta di una procedura necessaria soprattutto quando si utilizzano dimensioni del journal ODS non standard. Se le dimensioni della partizione OSD sono inferiori a 10 GB, il rispettivo peso iniziale viene arrotondato a 0 e poiché in essa non vengono collocati dati, è necessario aumentarne il peso. La società non si assume alcuna responsabilità per l'eventuale sovrariempimento dei journal.
Se è necessario utilizzare partizioni del disco come nodo OSD, il journal OSD e le partizioni dei dati devono essere inclusi in una tabella delle partizioni GPT.
È necessario impostare i tipi di partizioni corretti nelle partizioni OSD in modo che vengano riconosciute correttamente da udev
e ne venga impostata la proprietà a ceph:ceph
.
Ad esempio, per impostare il tipo di partizione per la partizione del journal /dev/vdb1
e la partizione dei dati /dev/vdb2
, eseguire quanto riportato di seguito:
sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdb sudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb
I tipi di tabelle delle partizioni Ceph sono elencati in /usr/lib/udev/rules.d/95-ceph-osd.rules
:
cat /usr/lib/udev/rules.d/95-ceph-osd.rules # OSD_UUID ACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name" ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER="ceph", GROUP="ceph", MODE="660" # JOURNAL_UUID ACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name" ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER="ceph", GROUP="ceph", MODE="660" [...]
È possibile creare un'immagine disco per la macchina virtuale basata su KVM, memorizzarla in un pool Ceph, convertire facoltativamente il contenuto di un'immagine esistente in tale immagine disco ed eseguire quindi la macchina virtuale con qemu-kvm
utilizzando l'immagine disco memorizzata nel cluster. Per informazioni dettagliate, vedere Capitolo 17, Ceph come back-end per l'istanza QEMU KVM.
libvirt
nel cluster Ceph #
Analogamente a KVM (vedere Sezione 18.8.1, «Memorizzazione dei dischi KVM nel cluster Ceph»), è possibile utilizzare Ceph per memorizzare macchine virtuali basate su libvirt
. Il vantaggio è dato dalla possibilità di eseguire qualsiasi soluzione di virtualizzazione supportata da libvirt
, come KVM, Xen o LXC. Per ulteriori informazioni, consultare Capitolo 16, Utilizzo di libvirt
con Ceph.
Un modo per utilizzare Ceph per memorizzare i dischi Xen consiste nell'utilizzare libvirt
come descritto in Capitolo 16, Utilizzo di libvirt
con Ceph.
Un'altra opzione è di fare in modo che Xen comunichi direttamente con il driver del dispositivo di blocco rbd
:
Se non si dispone di alcuna immagine disco preparata per Xen, crearne una nuova:
rbd create myimage --size 8000 --pool mypool
Elencare le immagini nel pool mypool
e verificare la presenza dell'immagine nuova al suo interno:
rbd list mypool
Creare un nuovo dispositivo di blocco mappando myimage
al modulo kernel rbd
:
sudo rbd map --pool mypool myimage
Per specificare un nome utente, utilizzare --id user-name
. Inoltre, se si utilizza l'autenticazione cephx
, è necessario specificare anche un segreto. Quest'ultimo potrebbe essere ricavato da un portachiavi o da un file contenente il segreto:
sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring
oppure
sudo rbd map --pool rbd myimage --id admin --keyfile /path/to/file
Elencare tutti i dispositivi mappati:
rbd showmapped
id pool image snap device
0 mypool myimage - /dev/rbd0
Adesso è possibile configurare Xen per l'uso del dispositivo come disco per eseguire una macchina virtuale. Ad esempio, è possibile aggiungere la riga seguente al file di configurazione del dominio di stile xl
:
disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]
Le fasi di distribuzione DeepSea si concludono con esito negativo quando il firewall è attivo (e anche configurato). Per superare le fasi correttamente, è necessario disattivare il firewall eseguendo
root@master #
systemctl stop SuSEfirewall2.service
o impostare l'opzione FAIL_ON_WARNING
su "False" in /srv/pillar/ceph/stack/global.yml
:
FAIL_ON_WARNING: False
Si consiglia di proteggere le comunicazioni del cluster di rete con SUSE Firewall. È possibile modificarne la configurazione selezionando
› › › .Di seguito è riportato un elenco di servizi correlati a Ceph e dei numeri di porte normalmente utilizzati da tali servizi:
Abilitare il servizio
o la porta 6789 (TCP).Abilitare il servizio
o le porte 6800-7300 (TCP).Aprire la porta 3260 (TCP).
Aprire la porta di comunicazione di Object Gateway. È impostato in /etc/ceph.conf
alla riga che inizia con rgw frontends =
. Il valore di default è 80 per HTTP e 443 per HTTPS (TCP).
Per default, NFS Ganesha utilizza le porte 2049 (servizio NFS, TCP) e 875 (supporto rquota, TCP). Fare rifermento a Sezione 14.2.3, «Modifica delle porte NFS Ganesha di default» per ulteriori informazioni su come modificare le porte NFS Ganesha di default.
Aprire le porte 80 per HTTP e 443 per HTTPS (TCP).
Aprire la porta 22 (TCP).
Aprire la porta 123 (UDP).
Aprire le porte 4505 e 4506 (TCP).
Aprire la porta 3000 (TCP).
Aprire la porta 9100 (TCP).
Per testare le prestazioni della rete, nello strumento di esecuzione DeepSea net
sono disponibili i seguenti comandi.
Ping semplice a tutti i nodi:
root@master #
salt-run
net.ping Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
Ping enorme a tutti i nodi:
root@master #
salt-run
net.jumbo_ping Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
Test della larghezza di banda:
root@master #
salt-run
net.iperf Fastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/sec Slowest 2 hosts: |_ - 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec
Se è necessario sostituire un disco di memorizzazione in un cluster Ceph, è possibile farlo durante il pieno funzionamento del cluster. La sostituzione causerà un aumento temporaneo nel trasferimento dei dati.
Se il disco risulta completamente impossibile da eseguire, Ceph deve riscrivere almeno la stessa quantità di dati della capacità del disco in errore. Se il disco viene rimosso e quindi aggiunto di nuovo per evitare la ridondanza durante il processo, la quantità di dati riscritti raddoppierà. Se le dimensioni del disco nuovo sono diverse da quello sostituito, alcuni dati aggiuntivi verranno ridistribuiti per livellare l'utilizzo di tutti gli OSD.