Guida all'amministrazione. SUSE Enterprise Storage 5

Guida all'amministrazione

SUSE Enterprise Storage 5

Guida all'amministrazione

di Tomáš Bažant, Jana Haláčková, e Sven Seeberg

Data di pubblicazione: 02.09.2019 SUSE LLC

10 Canal Park Drive Suite 200

Cambridge MA 02141 USA

https://www.suse.com/documentation

Copyright © 2019 SUSE LLC

Copyright © 2016, RedHat, Inc, and contributors.

Il testo e le illustrazioni di questo documento sono forniti con licenza Creative Commons Attribution-Share Ali- ke 4.0 International ("CC-BY-SA"). Una spiegazione di CC-BY-SA è disponibile all'indirizzo http://creativecom- mons.org/licenses/by-sa/4.0/legalcode . In conformità a CC-BY-SA, se si distribuisce questo documento o un suo adattamento, occorre fornire l'URL della versione originale.

Red Hat, Red Hat Enterprise Linux, il logo Shadowman, JBoss, MetaMatrix, Fedora, il Logo Infinity e RHCE sono marchi di Red Hat, Inc., registrati negli Stati Uniti e in altri paesi. Linux® è un marchio registrato di Linus Torvalds negli Stati Uniti e in altri paesi. Java® è un marchio registrato di Oracle e/o affiliate. XFS® è un marchio di Silicon Graphics International Corp. o sussidiarie negli Stati Uniti e/o in altri paesi. MySQL® è un marchio registrato di MySQL AB negli Stati Uniti, nell'Unione Europea e in altri paesi. Tutti gli altri marchi di fabbrica appartengono ai rispettivi proprietari.

Per i marchi di fabbrica SUSE vedere http://www.suse.com/company/legal/ . Tutti gli altri marchi di fabbrica di terze parti sono proprietà dei rispettivi titolari. I simboli di marchio di fabbrica (®, ™ e così via) indicano i marchi di fabbrica appartenenti a SUSE e alle rispettive affiliate. Gli asterischi (*) indicano i marchi di fabbrica di terze parti.

Tutte le informazioni nella presente pubblicazione sono state compilate con la massima attenzione ai dettagli.

Ciò, tuttavia, non garantisce una precisione assoluta. SUSE LLC, le rispettive affiliate, gli autori e i traduttori non potranno essere ritenuti responsabili di eventuali errori o delle relative conseguenze.

Indice

Informazioni sulla Guida _xv

I GESTIONE DEL CLUSTER ₁

1 Amministrazione di Salt Cluster ₂

1.1 Aggiunta di nuovi nodi cluster 2 1.2 Aggiunta di nuovi ruoli ai nodi 3

1.3 Rimozione e reinstallazione dei nodi del cluster 5 1.4 Ridistribuzione dei nodi di monitoraggio ₇

1.5 Aggiunta di un OSD a un nodo 8 1.6 Rimozione di un OSD 8

Rimozione forzata degli OSD interrotti ₉ 1.7 Recupero di un nodo OSD reinstallato ₁₀ 1.8 Installazione automatizzata tramite Salt 10 1.9 Aggiornamento dei nodi cluster 11

1.10 Interruzione o riavvio del cluster ₁₃ 1.11 File _ceph.conf personalizzato 14

Sostituzione delle impostazioni di default ₁₅ • Inclusione di file di configurazione ₁₅

1.12 Configurazione Ceph di runtime ₁₆

iv Guida all'amministrazione

II FUNZIONAMENTO DI UN CLUSTER 18

2 Introduzione ₁₉

3 Attivazione dei servizi Ceph ₂₀

3.1 Attivazione dei servizi Ceph con _systemd 20 Avvio, interruzione e riavvio dei servizi mediante l'uso di destinazioni ₂₀ • Avvio, interruzione e riavvio di servizi

individuali ₂₁ • Identificazione di servizi individuali ₂₁ • Stato dei servizi ₂₁

3.2 Riavvio dei servizi Ceph mediante l'uso di DeepSea 22 Riavvio di tutti i servizi ₂₂ • Riavvio di servizi specifici ₂₃

4 Determinazione dello stato del cluster ₂₄

4.1 Verifica dello stato di integrità del cluster 24 4.2 Osservazione di un cluster 33

4.3 Verifica delle statistiche sull'utilizzo di un cluster 35 4.4 Verifica dello stato di un cluster 36

4.5 Verifica dello stato degli OSD ₃₇ 4.6 Verifica degli OSD pieni 38

4.7 Verifica dello stato del monitoraggio 39

4.8 Verifica degli stati dei gruppi di posizionamento ₄₀ 4.9 Utilizzo del socket amministrativo 40

5 Autenticazione con cephx 42

5.1 Architettura di autenticazione 42 5.2 Gestione delle chiavi 45

Informazioni di background ₄₆ • Gestione degli utenti ₄₉ • Gestione dei portachiavi ₅₃ • Utilizzo della riga di comando ₅₆

v Guida all'amministrazione

6 Gestione dei dati memorizzati ₅₇

6.1 Dispositivi 58 6.2 Compartimenti 58 6.3 Set di regole ₆₁

Iterazione nell'albero di nodi ₆₃ • firstn e indep ₆₅ 6.4 Modifica della mappa CRUSH 66

Modifica di una mappa CRUSH ₆₆ • Aggiunta/Spostamento di un

OSD ₆₇ • Regolazione del peso CRUSH di un OSD ₆₈ • Rimozione di un OSD ₆₈ • Spostamento di un compartimento ₆₉

6.5 Pulitura ₆₉

6.6 Combinazione di SSD e HDD sullo stesso nodo 71

7 Gestione di pool di memorizzazione ₇₄

7.1 Associazione di pool a un'applicazione 75 7.2 Pool operativi 75

Elenco di pool ₇₅ • Creazione di un pool ₇₆ • Impostazione delle quote del pool ₇₇ • Eliminazione di un pool ₇₈ • Ridenominazione di un pool ₇₉ • Visualizzazione delle statistiche del

pool ₇₉ • Impostazione dei valori del pool ₇₉ • Ottenimento dei valori del pool ₈₃ • Impostazione del numero di

repliche di oggetti ₈₃ • Ottenimento del numero di repliche di oggetti ₈₄ • Aumento del numero di gruppi di posizionamento ₈₅ • Aggiunta di un pool ₈₆

7.3 Migrazione del pool 86

Migrazione con il livello di cache ₈₆ 7.4 Snapshot del pool 88

Creazione dello snapshot di un pool ₈₈ • Rimozione dello snapshot di un pool ₈₉

7.5 Compressione dei dati 89

Abilitazione della compressione ₈₉ • Opzioni di compressione del pool ₈₉ • Opzioni di compressione globali ₉₁

vi Guida all'amministrazione

8 RADOS Block Device (dispositivo di blocco RADOS) ₉₃

8.1 Comandi dei dispositivi di blocco 93

Creazione di un'immagine del dispositivo di blocco ₉₄ • Creazione di un'immagine del dispositivo di blocco in un pool con

codice di cancellazione ₉₄ • Elenco delle immagini dei dispositivi di blocco ₉₅ • Recupero delle informazioni

sull'immagine ₉₅ • Ridimensionamento di un'immagine del dispositivo di blocco ₉₆ • Rimozione di un'immagine del dispositivo di blocco ₉₆ 8.2 Montaggio e smontaggio di immagini RBD ₉₆

8.3 Snapshot dei dispositivi di blocco 98

Note su Cephx ₉₉ • Nozioni di base sugli snapshot ₉₉ • Layering ₁₀₁ 8.4 rbdmap: mappatura dei dispositivi RBD all'avvio 105

8.5 Copia speculare di RADOS Block Device (dispositivo di blocco RADOS) 107

daemon rbd-mirror ₁₀₇ • Configurazione del pool ₁₀₈ • Configurazione dell'immagine ₁₀₉ • Stato della copia speculare ₁₁₂

9 Pool con codice di cancellazione ₁₁₄

9.1 Creazione di un pool con codice di cancellazione di esempio 114 9.2 Profili dei codici di cancellazione ₁₁₅

9.3 Pool con codice di cancellazione e suddivisione in livelli di cache 118 9.4 Pool con codice di cancellazione con RADOS Block Device (dispositivo di

blocco RADOS) ₁₁₈

10 Suddivisione in livelli di cache ₁₂₀

10.1 Terminologia della memorizzazione in livelli ₁₂₀ 10.2 Aspetti da considerare 121

10.3 Quando utilizzare la suddivisione in livelli di cache 122 10.4 Modalità cache ₁₂₂

vii Guida all'amministrazione

10.5 Set di accessi 123

Panoramica ₁₂₃ • Esempi ₁₂₅

10.6 Configurazione di un esempio di spazio di memorizzazione suddiviso in livelli 125

Configurazione di un livello di cache ₁₂₈

III ACCESSO AI DATI DEL CLUSTER 133

11 Ceph Object Gateway ₁₃₄

11.1 Restrizioni e limiti di denominazione di Object Gateway 134 Limiti dei compartimenti ₁₃₄ • Limiti degli oggetti

memorizzati ₁₃₄ • Limiti dell'intestazione HTTP ₁₃₅ 11.2 Distribuzione di Object Gateway ₁₃₅

11.3 Funzionamento del servizio Object Gateway 135 11.4 Parametri di configurazione 136

Note aggiuntive ₁₃₇

11.5 Gestione dell'accesso a Object Gateway ₁₃₇

Accesso a Object Gateway ₁₃₇ • Gestione degli account S3 e Swift ₁₃₉ 11.6 Abilitazione di HTTPS/SSL per gli Object Gateway 143

Creazione di un certificato firmato da se stessi ₁₄₃ • Configurazione HTTPS semplice ₁₄₄ • Configurazione HTTPS avanzata ₁₄₄

11.7 Moduli di sincronizzazione 145

Sincronizzazione delle zone ₁₄₅ • Memorizzazione dei metadati in Elasticsearch ₁₄₇

11.8 Autenticazione LDAP 150

Meccanismo di autenticazione ₁₅₀ • Requisiti ₁₅₁ • Configurazione di Object Gateway per utilizzare l'autenticazione LDAP ₁₅₁ • Utilizzo di un filtro di ricerca personalizzato per limitare l'accesso degli utenti ₁₅₂ • Generazione di un token di accesso per l'autenticazione LDAP ₁₅₃

viii Guida all'amministrazione

11.9 Partizionamento dell'indice del compartimento 154

Ripartizionamento dell'indice del compartimento ₁₅₄ • Partizionamento dell'indice del compartimento per nuovi compartimenti ₁₅₇

11.10 Integrazione di OpenStack Keystone 159

Configurazione di OpenStack ₁₅₉ • Configurazione di Ceph Object Gateway ₁₆₀

11.11 Object Gateway multisito 162

Terminologia ₁₆₃ • Esempio di configurazione cluster ₁₆₃ • Chiavi di sistema ₁₆₄ • Convenzioni di denominazione ₁₆₅ • Pool di default ₁₆₅ • Creazione di un dominio ₁₆₆ • Eliminazione del gruppo di zone di default ₁₆₆ • Creazione di un gruppo di zone master ₁₆₆ • Creazione di una zona master ₁₆₇ • Creazione di una zona secondaria ₁₇₁ • Aggiunta di Object Gateway al secondo cluster ₁₇₄ • Failover e disaster recovery ₁₇₈

11.12 Bilanciamento del carico dei server Object Gateway con HAProxy 180

12 Ceph iSCSI Gateway ₁₈₁

12.1 Connessione a destinazioni gestite con lrbd 181

Linux (open-iscsi) ₁₈₁ • Microsoft Windows (iniziatore iSCSI Microsoft) ₁₈₅ • VMware ₁₉₂

12.2 Conclusioni 198

13 File system in cluster ₁₉₉

13.1 Montaggio di CephFS 199

Preparazione del client ₁₉₉ • Creazione di un file segreto ₁₉₉ • Montaggio di CephFS ₂₀₀

13.2 Smontaggio di CephFS 201 13.3 CephFS in /etc/fstab 202

13.4 Più daemon MDS attivi (MDS attivo-attivo) ₂₀₂

Quando utilizzare MDS attivo-attivo ₂₀₂ • Aumento delle dimensioni del cluster attivo MDS ₂₀₂ • Riduzione del numero di livelli ₂₀₃ • Aggiunta manuale di un albero della Directory a un livello ₂₀₅

ix Guida all'amministrazione

13.5 Gestione del failover 205

Configurazione dei daemon in standby ₂₀₆ • Esempi ₂₀₇

14 NFS Ganesha: esportazione dei dati Ceph tramite NFS ₂₀₈

14.1 Installazione 208 14.2 Configurazione 208

Sezione di esportazione ₂₀₉ • Sezione RGW ₂₁₀ • Modifica delle porte NFS Ganesha di default ₂₁₁

14.3 Ruoli NFS Ganesha personalizzati ₂₁₁

Utenti Object Gateway diversi per NFS Ganesha ₂₁₁ • Separazione di FSAL CephFS e Object Gateway ₂₁₃

14.4 Avvio o riavvio di NFS Ganesha 214 14.5 Impostazione del livello di log ₂₁₅

14.6 Verifica della condivisione NFS esportata 215 14.7 Montaggio della condivisione NFS esportata 215 14.8 Risorse aggiuntive ₂₁₆

IV GESTIONE DEL CLUSTER CON GLI STRUMENTI GUI 217

15 openATTIC ₂₁₈

15.1 Distribuzione e configurazione di openATTIC 218 Abilitazione dell'accesso sicuro a openATTIC utilizzando

SSL ₂₁₈ • Distribuzione di openATTIC ₂₁₉ • Configurazione iniziale di openATTIC ₂₂₀ • Integrazione di DeepSea in openATTIC ₂₂₀ • Gestione di Object Gateway ₂₂₁ • Gestione di iSCSI Gateway ₂₂₁

15.2 Interfaccia utente Web openATTIC 221 15.3 Dashboard ₂₂₃

15.4 Task correlati a Ceph 225

Funzioni interfaccia utente Web comuni ₂₂₅ • Elenchi di nodi

OSD ₂₂₆ • Gestione dei RADOS Block Device RADOS (RBD, dispostivi di blocco

x Guida all'amministrazione

RADOS) ₂₂₆ • Gestione dei pool ₂₃₀ • Elenco di nodi ₂₃₂ • Gestione di NFS Ganesha ₂₃₃ • Gestione di iSCSI Gateway ₂₃₇ • Visualizzazione della mappa CRUSH del cluster ₂₃₉ • Gestione di utenti e compartimenti Object Gateway ₂₄₀

V INTEGRAZIONE CON GLI STRUMENTI DI VIRTUALIZZAZIONE 248

16 Utilizzo di libvirt con Ceph 249

16.1 Configurazione di Ceph 249

16.2 Preparazione del programma di gestione VM 250 16.3 Creazione di una macchina virtuale (VM) 251 16.4 Configurazione della macchina virtuale (VM) 251 16.5 Riepilogo 254

17 Ceph come back-end per l'istanza QEMU KVM ₂₅₅

17.1 Installazione 255 17.2 Utilizzo 255

17.3 Creazione di immagini con QEMU 256

17.4 Ridimensionamento delle immagini con QEMU 256

17.5 Recupero delle informazioni sull'immagine con QEMU 257 17.6 Esecuzione di QEMU con RBD 257

17.7 Abilitazione dell'opzione di scarto/TRIM 258 17.8 Opzioni cache QEMU ₂₅₈

VI DOMANDE FREQUENTI, SUGGERIMENTI E RISOLUZIONE DEI PROBLEMI ₂₆₀

18 Suggerimenti ₂₆₁

18.1 Regolazione della pulitura 261

18.2 Interruzione degli ODS senza ribilanciamento 262

xi Guida all'amministrazione

18.3 Sincronizzazione dell'orario dei nodi 262 18.4 Verifica della scrittura dati non bilanciata ₂₆₄ 18.5 Sottovolume Btrfs per /var/lib/ceph 265

Requisiti per una nuova installazione ₂₆₅ • Requisiti per un'installazione esistente ₂₆₅ • Installazione automatica ₂₆₆ • Installazione

manuale ₂₆₆

18.6 Aumento dei descrittori di file 267

18.7 Come utilizzare partizioni esistenti per gli OSD, tra cui i journal OSD 267

18.8 Integrazione con il software di virtualizzazione 269

Memorizzazione dei dischi KVM nel cluster Ceph ₂₆₉ • Memorizzazione dei dischi libvirt nel cluster Ceph ₂₆₉ • Memorizzazione dei dischi Xen nel cluster Ceph ₂₆₉

18.9 Impostazioni firewall per Ceph ₂₇₀ 18.10 Test delle prestazioni della rete 272

18.11 Sostituzione del disco di memorizzazione 273

19 Domande frequenti ₂₇₄

19.1 In che modo il numero dei gruppi di posizionamento influisce sulle prestazioni del cluster? 274

19.2 È possibile utilizzare SSD e dischi rigidi sullo stesso cluster? ₂₇₄

19.3 Quali sono i vantaggi e gli svantaggi che comporta l'utilizzo di un journal su un disco SSD? 275

19.4 Che cosa succede in caso di errore di un disco? ₂₇₆

19.5 Che cosa succede in caso di errore di un disco del journal? 276

20 Risoluzione dei problemi ₂₇₇

20.1 Segnalazione di problemi correlati al software 277

xii Guida all'amministrazione

20.2 L'invio di oggetti di grandi dimensioni con rados ha esito negativo con un OSD pieno ₂₇₇

20.3 File system XFS corrotto 278

20.4 Messaggio di stato "Too Many PGs per OSD" (Troppi gruppi di posizionamento per OSD) ₂₇₈

20.5 Messaggio di stato "nn pg stuck inactive" (nn gruppi di posizionamento bloccati inattivi) 279

20.6 Il peso dell'OSD è 0 ₂₈₀ 20.7 OSD inattivo 280

20.8 Rilevamento di OSD lenti 281

20.9 Correzione degli avvisi di sfasamento di orario ₂₈₁

20.10 Prestazioni del cluster scarse a causa di problemi di rete 282 20.11 Spazio quasi esaurito di /var 284

Glossario ₂₈₆

A Procedura di esempio per l'installazione manuale di Ceph ₂₈₈

B Aggiornamenti della documentazione ₂₉₂

B.1 Settembre 2018 (release di SUSE Enterprise Storage 5.5) ₂₉₂ B.2 Novembre 2017 (Aggiornamento di manutenzione della

documentazione) 295

B.3 Ottobre 2017 (release di SUSE Enterprise Storage 5) ₂₉₅

B.4 Febbraio 2017 (release di SUSE Enterprise Storage 4 - Aggiornamento di manutenzione 1) 301

B.5 Dicembre 2016 (release di SUSE Enterprise Storage 4) 302 B.6 Giugno 2016 (release di SUSE Enterprise Storage 3) 303

xiii Guida all'amministrazione

B.7 Gennaio 2016 (release di SUSE Enterprise Storage 2.1) 306 B.8 Ottobre 2015 (release di SUSE Enterprise Storage 2) ₃₀₇

xiv Guida all'amministrazione

Informazioni sulla Guida

SUSE Enterprise Storage è un'estensione di SUSE Linux Enterprise che combina le capacità del progetto di storage Ceph (http://ceph.com/ ) con il supporto e l'ingegneria aziendale di SUSE.

SUSE Enterprise Storage fornisce alle organizzazioni IT la capacità di distribuire un'architettura di storage distribuita che può supportare numerosi casi d'uso che utilizzano piattaforme hard- ware disponibili.

Questa guida consente di comprendere il concetto di SUSE Enterprise Storage con un'attenzione particolare a gestione e amministrazione dell'infrastruttura Ceph. Dimostra inoltre come utiliz- zare Ceph con altre soluzioni correlate, come OpenStack o KVM.

Numerosi capitoli della presente guida contengono collegamenti a risorse di documentazione aggiuntive, inclusa documentazione aggiuntiva disponibile sul sistema o via Internet.

Per una panoramica sulla documentazione disponibile per il prodotto in uso e sugli aggiornamen- ti più recenti della documentazione, fare riferimento a http://www.suse.com/documentation .

1 Documentazione disponibile

Per questo prodotto sono disponibili i seguenti manuali:

Guida all'amministrazione

La guida descrive vari task amministrativi che vengono generalmente eseguiti dopo l'in- stallazione. La guida presenta inoltre le procedure per integrare Ceph con soluzioni di vir- tualizzazione come libvirt, Xen o KVM e i modi per accedere agli oggetti memorizzati nel cluster tramite i gateway iSCSI e RADOS.

Libro «Guida alla distribuzione»

Guida l'utente attraverso la procedura di installazione del cluster Ceph e di tutti i servizi correlati a Ceph. La guida illustra inoltre una struttura del cluster Ceph di base e fornisce all'utente la terminologia relativa.

Le versioni HTML dei manuali del prodotto sono disponibili nel sistema installato in /usr/

share/doc/manual. Gli aggiornamenti più recenti alla documentazione sono disponibili all'in- dirizzo http://www.suse.com/documentation , da cui è possibile effettuare il download dei ma- nuali del prodotto in vari formati.

xv Documentazione disponibile SES 5

2 Feedback

Sono disponibili vari canali di feedback:

Bug e richieste di miglioramento

Per verificare i servizi e le opzioni di supporto disponibili per il proprio prodotto, fare riferimento a http://www.suse.com/support/ .

Per segnalare bug relativi al componente di un prodotto, eseguire il login in Novell Cu- stomer Center da http://www.suse.com/support/ e selezionare Il mio supporto Richiesta di servizio.

Commenti degli utenti

È possibile inviare i propri commenti e suggerimenti relativi a questo manuale e agli altri documenti forniti con il prodotto. Per inserire commenti, utilizzare l'apposita funzionalità disponibile in ogni pagina della documentazione online oppure visitare la pagina ^http://

www.suse.com/documentation/feedback.html . Posta

Per un feedback sulla documentazione del prodotto, è inoltre possibile inviare un'e-mail a doc-team@suse.de. Accertarsi di includere il titolo del documento, la versione del pro- dotto e la data di pubblicazione della documentazione. Per segnalare errori o suggerire miglioramenti, fornire una breve descrizione del problema e fare riferimento ai rispettivi numero di sezione e pagina (o URL).

3 Convenzioni della documentazione

Nel presente manuale vengono utilizzate le convenzioni tipografiche riportate di seguito.

/etc/passwd: nomi di directory e file

segnaposto: sostituire segnaposto con il valore reale PERCORSO: PERCORSO della variabile d'ambiente ls, --help: comandi, opzioni e parametri utente: utenti o gruppi

Alt , ^Alt –^F1 : un tasto o una combinazione di tasti da premere. I tasti vengono rappre- sentati in maiuscolo come su una tastiera

xvi Feedback SES 5

File, File Salva con nome : voci di menu, pulsanti

Pinguini danzanti (Capitolo Pinguini, ↑altro manuale): riferimento a un capitolo di un altro manuale.

4 Informazioni sulla realizzazione di questo manuale

Questo libro è stato scritto in GeekoDoc, un elemento di DocBook (vedere http://www.doc- book.org ). I file sorgente XML sono stati convalidati con xmllint, elaborati con xsltproc e convertiti in XSL-FO utilizzando una versione personalizzata dei fogli di stile di Norman Walsh.

Il PDF finale può essere formattato attraverso FOP da Apache o attraverso XEP da RenderX. Gli strumenti di creazione e pubblicazione utilizzati per produrre questo manuale sono disponibi- li nel pacchetto daps. La DocBook Authoring and Publishing Suite (DAPS) è sviluppata come software open source. Per ulteriori informazioni, consultare http://daps.sf.net/ .

5 Ceph Contributors

The Ceph project and its documentation is a result of hundreds of contributors and organizations.

See https://ceph.com/contributors/ for more details.

xvii Informazioni sulla realizzazione di questo manuale SES 5

I Gestione del cluster

1 Amministrazione di Salt Cluster 2

1 Amministrazione di Salt Cluster

Dopo aver distribuito il cluster Ceph, occasionalmente potrà essere necessario apportare alcune modifiche. Tra queste sono incluse l'aggiunta o la rimozione di nuovi nodi, dischi o servizi. In questo capitolo è descritto come compiere tali task amministrativi.

1.1 Aggiunta di nuovi nodi cluster

La procedura per aggiungere nuovi nodi al cluster è pressoché identica alla distribuzione dei nodi cluster iniziale descritta in Libro «Guida alla distribuzione», Capitolo 4 «Installazione con Dee- pSea/Salt»:

1. Installare SUSE Linux Enterprise Server 12 SP3 sul nuovo nodo, configurarne le imposta- zioni di rete in modo che il nome host del Salt master venga risolto correttamente e in- stallare il pacchetto salt-minion:

root@minion > zypper in salt-minion

Se il nome host del Salt master è diverso da salt, modificare /etc/salt/minion e aggiungere quanto segue:

master: DNS_name_of_your_salt_master

Se sono state apportate modifiche ai file di configurazione di cui sopra, riavviare il servizio salt.minion:

root@minion > systemctl restart salt-minion.service

2. Accettare tutte le chiavi salt sul Salt master:

root@master # salt-key --accept-all

3. Verificare che anche la destinazione di /srv/pillar/ceph/deepsea_minions.sls sia il nuovo Salt minion. Per ulteriori dettagli, fare riferimento a Libro «Guida alla distribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.2.2.1 «Corrispondenza del nome del minion»

di Libro «Guida alla distribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Di- stribuzione del cluster», Esecuzione delle fasi di distribuzione.

2 Aggiunta di nuovi nodi cluster SES 5

4. Eseguire la fase di preparazione. Moduli e grain (piccoli elementi di dati) vengono sincro- nizzati in modo che il nuovo minion possa fornire tutte le informazioni che DeepSea si aspetta:

root@master # salt-run state.orch ceph.stage.0

5. Eseguire la fase di rilevazione. Verranno scritte nuove voci di file nella directory /srv/

pillar/ceph/proposals in cui è possibile modificare i file .yml pertinenti:

root@master # salt-run state.orch ceph.stage.1

6. Se lo si desidera, modificare /srv/pillar/ceph/proposals/policy.cfg se l'host appe- na aggiunto non corrisponde allo schema di denominazione esistente. Per ulteriori infor- mazioni, fare riferimento a Libro «Guida alla distribuzione», Capitolo 4 «Installazione con Dee- pSea/Salt», Sezione 4.5.1 «Il file _policy.cfg».

7. Eseguire la fase di configurazione. Viene letto tutto ciò che risiede in /srv/pillar/ceph e Pillar viene aggiornato di conseguenza:

root@master # salt-run state.orch ceph.stage.2

Pillar memorizza i dati cui è possibile accedere con il seguente comando:

root@master # salt target pillar.items

8. Le fasi di configurazione e distribuzione includono i nodi aggiunti di recente:

root@master # salt-run state.orch ceph.stage.3 root@master # salt-run state.orch ceph.stage.4

1.2 Aggiunta di nuovi ruoli ai nodi

È possibile distribuire tutti i tipi di ruoli supportati con DeepSea. Vedere Libro «Guida alla distri- buzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.5.1.2 «Assegnazione ruolo» per ulteriori informazioni sui tipi di ruoli supportati ed esempi della rispettiva corrispondenza.

3 Aggiunta di nuovi ruoli ai nodi SES 5

Suggerimento: ruoli e fasi obbligatori e opzionali

In genere si consiglia di eseguire tutte le fasi di distribuzione comprese tra 0 e 5 quando si aggiunte aggiunge un nuovo ruolo a un nodo cluster. Per risparmiare tempo, è possibile ignorare le fasi 3 o 4, a seconda del tipo di ruolo che si intende distribuire. Mentre i ruoli OSD e MON includono servizi di base e sono richiesti da Ceph, altri ruoli, come Object Gateway, sono opzionali. Le fasi di distribuzione DeepSea sono gerarchiche: mentre nella fase 3 vengono distribuiti servizi di base, nella fase 4 vengono distribuiti quelli opzionali.

Pertanto, è necessario eseguire la fase 3 quando si distribuiscono ruoli di base, come MON su un nodo OSD esistente, ed è possibile ignorare la fase 4.

In modo analogo, è possibile ignorare la fase 3 quando si distribuiscono servizi opzionali come Object Gateway, ma in tal caso è necessario eseguire la fase 4.

Per aggiungere un nuovo servizio a un nodo esistente, seguire la procedura indicata di seguito:

1. Adattare /srv/pillar/ceph/proposals/policy.cfg in modo che corrisponda all'host esistente con il nuovo ruolo. Per ulteriori informazioni, fare riferimento a Libro «Guida alla distribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.5.1 «Il file _policy.cfg». Ad esempio, se è necessario eseguire un Object Gateway su un nodo MON, la riga è simile a:

role-rgw/xx/x/example.mon-1.sls

2. Eseguire la fase 2 per aggiornare Pillar:

root@master # salt-run state.orch ceph.stage.2

3. Eseguire la fase 3 per distribuire i servizi di base o la fase 4 per eseguire quelli opzionali.

È anche possibile eseguire entrambe le fasi.

Suggerimento

Tenere presente che quando si aggiunge un OSD al cluster esistente, successivamente questo ne eseguirà il ribilanciamento per un periodo di tempo. Per ridurre al minimo i periodi di ribilanciamento, si consiglia di aggiungere contemporaneamente tutti gli OSD previsti.

4 Aggiunta di nuovi ruoli ai nodi SES 5

1.3 Rimozione e reinstallazione dei nodi del cluster

Per rimuovere un ruolo da un cluster, modificare /srv/pillar/ceph/proposals/policy.cfg e rimuovere le righe di corrispondenti. Eseguire quindi le fasi 2 e 5 come descritto in Libro «Guida alla distribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster».

Nota: rimozione degli ODS dal cluster

Qualora fosse necessario rimuovere un determinato nodo OSD dal cluster, assicurarsi che questo disponga di uno spazio libero su disco maggiore rispetto al disco che si inten- de rimuovere. Tenere presente che la rimozione di un OSD comporta il ribilanciamento dell'intero cluster.

Quando si rimuove un ruolo da un minion, l'obiettivo è annullare tutte le modifiche correlate a tale ruolo. Per la maggior parte dei ruoli, il task è semplice, ma potrebbero verificarsi problemi con le dipendenze del pacchetto. Se un pacchetto è disinstallato, le dipendenze non lo sono.

Gli OSD rimossi figurano come unità vuote. I task correlati sovrascrivono la parte iniziale dei file system e rimuovono le partizioni di backup oltre a cancellare le tabelle delle partizioni.

Nota: conservazione delle partizioni create mediante altri metodi

È possibile che le unità disco configurate precedentemente mediante altri metodi, come ceph-deploy, contengano comunque partizioni che non verranno distrutte automatica- mente da DeepSea. L'amministratore deve recuperare tali unità.

ESEMPIO 1.1: RIMOZIONE DI UN SALT MINION DAL CLUSTER

Se si assegna un nome ai minion di memorizzazione, ad esempio, "data1.ceph", "data2.ce- ph" ... "data6.ceph" e le righe correlate nel file policy.cfg sono simili a quanto segue:

[...]

# Hardware Profile

profile-default/cluster/data*.sls

profile-default/stack/default/ceph/minions/data*.yml [...]

Per rimuovere il Salt minion "data2.ceph", modificare le righe come indicato di seguito:

[...]

5 Rimozione e reinstallazione dei nodi del cluster SES 5

# Hardware Profile

profile-default/cluster/data[1,3-6]*.sls

profile-default/stack/default/ceph/minions/data[1,3-6]*.yml [...]

Quindi, eseguire le fasi 2 e 5:

root@master # salt-run state.orch ceph.stage.2 root@master # salt-run state.orch ceph.stage.5

ESEMPIO 1.2: MIGRAZIONE DEI NODI

Presupporre la seguente situazione: durante la nuova installazione del cluster, l'ammini- stratore ha allocato uno dei nodi di memorizzazione come Object Gateway autonomo du- rante l'attesa dell'arrivo dell'hardware del gateway. Adesso l'hardware permanente è di- sponibile per il gateway e finalmente è possibile assegnare il ruolo desiderato al nodo di memorizzazione di backup e rimuovere il ruolo gateway.

Dopo aver eseguito le fasi 0 e 1 (vedere Libro «Guida alla distribuzione», Capitolo 4 «Installazio- ne con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster», Esecuzione delle fasi di distribuzione) per il nuovo hardware, il nuovo gateway viene denominato rgw1. Se per il nodo data8 è necessario che venga rimosso il ruolo Object Gateway, che venga aggiunto il ruolo di memorizzazione e policy.cfg presenta il seguente aspetto:

# Hardware Profile

profile-default/cluster/data[1-7]*.sls

profile-default/stack/default/ceph/minions/data[1-7]*.sls

# Roles

role-rgw/cluster/data8*.sls

Modificarlo in:

# Hardware Profile

profile-default/cluster/data[1-8]*.sls

profile-default/stack/default/ceph/minions/data[1-8]*.sls

# Roles

role-rgw/cluster/rgw1*.sls

Eseguire le fasi da 2 a 5. Nella fase 3 verrà aggiunto data8 come nodo di memorizzazione.

Per un breve periodo, data8 avrà entrambi i ruoli. Nella fase 4 verrà aggiunto il ruolo Object Gateway a rgw1 e nella fase 5 verrà rimosso il ruolo Object Gateway da data8.

6 Rimozione e reinstallazione dei nodi del cluster SES 5

1.4 Ridistribuzione dei nodi di monitoraggio

Quando uno o più nodi di monitoraggio vengono meno e non rispondono, è necessario rimuo- verli dal cluster e possibilmente aggiungerli nuovamente.

Importante: il numero minimo di nodi di monitoraggio è tre

Il numero di nodi di monitoraggio non deve essere inferiore a tre. Se un nodo di monito- raggio viene meno e di conseguenza nel cluster ne rimangono solo uno o due, è necessa- rio assegnare temporaneamente il ruolo di monitoraggio agli altri nodi cluster prima di ridistribuire i nodi di monitoraggio con errore. Dopo la distribuzione dei nodi di monito- raggio con errore, è possibile disinstallare temporaneamente ruoli di monitoraggio.

Per ulteriori informazioni sull'aggiunta di nuovi nodi/ruoli al cluster Ceph, vedere ^Sezio- ne 1.1, «Aggiunta di nuovi nodi cluster» e Sezione 1.2, «Aggiunta di nuovi ruoli ai nodi».

Per ulteriori informazioni sulla rimozione dei nodi cluster, fare riferimento a Sezione 1.3,

«Rimozione e reinstallazione dei nodi del cluster».

Un nodo Ceph ha due gradi di errore di base:

L'host Salt minion è interrotto fisicamente o a livello di sistema operativo e non rispon- de alla chiamata salt 'minion_name' test.ping. In tal caso è necessario ridistribuire completamente il server seguendo le istruzioni pertinenti incluse in Libro «Guida alla distri- buzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster». I servizi correlati al monitoraggio vengono meno e il recupero è impossibile, ma l'host risponde alla chiamata salt 'minion_name' test.ping. In tal caso, seguire la procedura indicata di seguito:

1. Modificare /srv/pillar/ceph/proposals/policy.cfg sul Salt master e rimuovere o aggiornare le righe che corrispondono ai nodi di monitoraggio con errore in modo che questi puntino ai nodi di monitoraggio in funzione.

2. Eseguire le fasi da 2 a 5 di DeepSea per applicare le modifiche:

root@master # deepsea stage run ceph.stage.2 root@master # deepsea stage run ceph.stage.3 root@master # deepsea stage run ceph.stage.4 root@master # deepsea stage run ceph.stage.5

7 Ridistribuzione dei nodi di monitoraggio SES 5

1.5 Aggiunta di un OSD a un nodo

Per aggiungere un disco a un nodo OSD esistente, verificare che sul disco siano state rimos- se e cancellate tutte le partizioni. Per ulteriori dettagli, fare riferimento a ^{Passo 13} in ^Libro

«Guida alla distribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster». Una volta che il disco è vuoto, aggiungerlo al file YAML del nodo. Il percorso del file è /srv/pillar/ceph/proposals/profile-default/stack/default/ceph/minions/no- de_name.yml. Dopo aver salvato il file, eseguire le fasi 2 e 3 di DeepSea:

root@master # deepsea stage run ceph.stage.2 root@master # deepsea stage run ceph.stage.3

Suggerimento: profili aggiornati automaticamente

Invece di modificare manualmente il file YAML, DeepSea può creare nuovi profili. Per consentire a DeepSea di creare nuovi profili, è necessario spostare quelli esistenti:

root@master # old /srv/pillar/ceph/proposals/profile-default/

root@master # deepsea stage run ceph.stage.1 root@master # deepsea stage run ceph.stage.2 root@master # deepsea stage run ceph.stage.3

1.6 Rimozione di un OSD

È possibile rimuovere un Ceph OSD dal cluster eseguendo il seguente comando:

root@master # salt-run disengage.safety root@master # salt-run remove.osd OSD_ID

OSD_ID deve essere un numero dell'OSD senza il termine osd. Ad esempio, da osd.3 utilizzare solo la cifra 3.

Suggerimento: rimozione di più ODS

Non è possibile in alcun modo rimuovere più OSD contemporaneamente con il comando salt-run remove.osd. Per automatizzare la rimozione di più OSD, è possibile utilizzare il ciclo seguente (5, 21, 33, 19 sono numeri ID degli OSD da rimuovere):

for i in 5 21 33 19

8 Aggiunta di un OSD a un nodo SES 5

do echo $i

salt-run disengage.safety salt-run remove.osd $i done

1.6.1 Rimozione forzata degli OSD interrotti

In alcuni casi la rimozione di un OSD si conclude con un errore non grave (vedere Sezione 1.6,

«Rimozione di un OSD»). Ciò può verificarsi se, ad esempio, l'OSD o la rispettiva cache vengono interrotti, a causa di operazioni I/O in sospeso, o quando è impossibile smontare il disco OSD.

In tal caso, è necessario forzare la rimozione dell'OSD:

root@master # target osd.remove OSD_ID force=True

Con questo comando si rimuovono le partizioni dei dati e le partizioni del journal o WAL/DB.

Per identificare possibili dispositivi journal/WAL/DB orfani, seguire la procedura indicata di seguito:

1. Selezionare il dispositivo che potrebbe contenere partizioni orfane e salvare l'elenco delle partizioni in un file:

root@minion > ls /dev/sdd?* > /tmp/partitions

2. Eseguire readlink a fronte di tutti i dispositivi block.wal, block.db e journal, quindi confrontare l'output con l'elenco delle partizioni salvato precedentemente:

root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \ | sort | comm -23 /tmp/partitions -

L'output è l'elenco delle partizioni che non vengono utilizzate da Ceph.

3. Rimuovere le partizioni orfane che non appartengono a Ceph con il comando (ad esempio fdisk, parted o sgdisk).

9 Rimozione forzata degli OSD interrotti SES 5

1.7 Recupero di un nodo OSD reinstallato

Se il sistema operativo si interrompe ed è impossibile recuperarlo su uno dei nodi OSD nodes, seguire la procedura indicata di seguito per recuperarlo e ridistribuirne il ruolo OSD con dati del cluster invariati:

1. Reinstallare il sistema operativo sul nodo.

2. Installare i pacchetti salt-minion sul nodo OSD, eliminare la chiave del Salt minion precedente sul Salt master e registrare la nuova chiave del Salt minion con il Salt master.

Per ulteriori informazioni sulla distribuzione del Salt minion, vedere Libro «Guida alla di- stribuzione», Capitolo 4 «Installazione con DeepSea/Salt», Sezione 4.3 «Distribuzione del cluster». 3. Eseguire le seguenti parti invece dell'intera fase 0:

root@master # salt 'osd_node' state.apply ceph.sync

root@master # salt 'osd_node' state.apply ceph.packages.common root@master # salt 'osd_node' state.apply ceph.mines

root@master # salt 'osd_node' state.apply ceph.updates

4. Eseguire le fasi da 1 a 5 di DeepSea:

root@master # salt-run state.orch ceph.stage.1 root@master # salt-run state.orch ceph.stage.2 root@master # salt-run state.orch ceph.stage.3 root@master # salt-run state.orch ceph.stage.4 root@master # salt-run state.orch ceph.stage.5

5. Eseguire la fase 0 di DeepSea:

root@master # salt-run state.orch ceph.stage.0

6. Riavviare il nodo OSD pertinente. Tutti i dischi OSD verranno rilevati e riutilizzati.

1.8 Installazione automatizzata tramite Salt

È possibile automatizzare l'installazione mediante l'uso di Salt Reactor. Per gli ambienti virtuali o di hardware coerenti, questa configurazione consentirà di creare un cluster Ceph con il com- portamento specificato.

10 Recupero di un nodo OSD reinstallato SES 5

Avviso

Salt non è in grado di effettuare verifiche della dipendenza in base agli eventi del reattore.

Vi è il rischio effettivo di sovraccarico del Salt master o che questo non risponda più.

Per l'installazione automatizzata è richiesto quanto segue:

Un file /srv/pillar/ceph/proposals/policy.cfg creato in modo appropriato.

La preparazione di configurazione personalizzata posizionata nella directory /srv/pil- lar/ceph/stack.

Nella configurazione del reattore di default verranno eseguite solo le fasi 0 e 1. In tal modo è possibile testare il reattore senza dover attendere il completamento delle fasi successive.

All'avvio del primo salt-minion avrà inizio la fase 0. Un blocco impedisce più istanze. Quando tutti i minion completano la fase 0, avrà inizio la fase 1.

Se l'operazione viene eseguita correttamente, modificare l'ultima riga nel file /etc/salt/ma- ster.d/reactor.conf:

- /srv/salt/ceph/reactor/discovery.sls

come segue

- /srv/salt/ceph/reactor/all_stages.sls

1.9 Aggiornamento dei nodi cluster

È una buona idea applicare regolarmente aggiornamenti in sequenza ai nodi cluster. Per appli- care gli aggiornamenti, eseguire la fase 0:

root@master # salt-run state.orch ceph.stage.0

11 Aggiornamento dei nodi cluster SES 5

Se DeepSea rileva un cluster Ceph in esecuzione, vengono applicati gli aggiornamenti e i nodi vengono avviati in sequenza. DeepSea segue il consiglio ufficiale di Ceph secondo il quale è opportuno aggiornare prima i monitoraggi, successivamente gli OSD e infine i servizi aggiuntivi, come MDS, Object Gateway, iSCSI Gateway o NFS Ganesha. DeepSea interrompe il processo di aggiornamento se rileva un problema nel cluster. Un trigger può essere:

Ceph segnala "HEALTH_ERR" per più di 300 secondi.

Dopo un aggiornamento i Salt minion vengono interrogati per verificare se i servizi loro assegnati sono ancora attivi e in esecuzione. L'aggiornamento ha esito negativo se i servizi sono inattivi per più di 900 secondi.

Queste disposizioni assicurano il funzionamento del cluster Ceph nonostante aggiornamenti cor- rotti o con errore.

La fase 0 di DeepSea aggiorna il sistema tramite zypper update e lo riavvia se il kernel viene aggiornato. Se si desidera eliminare l'eventualità di un riavvio forzato di tutti i potenziali nodi, assicurarsi che sia installato e in esecuzione l'ultimo kernel, prima di iniziare la fase 0 di DeepSea.

Suggerimento: zypper patch

Se si preferisce aggiornare il sistema utilizzando il comando zypper patch, modificare /srv/pillar/ceph/stack/global.yml e aggiungere la riga seguente:

update_method_init: zypper-patch

È possibile modificare il comportamento di avvio di default della fase 0 di DeepSea aggiungendo le righe seguenti a /srv/pillar/ceph/stack/global.yml:

stage_prep_master: default-update-no-reboot stage_prep_minion: default-update-no-reboot

Con stage_prep_master si imposta il comportamento della fase 0 del Salt master e con sta- ge_prep_minion quello di tutti i minion. Tutti i parametri disponibili sono:

default

Installa gli aggiornamenti e successivamente esegue il riavvio.

default-update-no-reboot

Installa gli aggiornamenti senza il riavvio.

12 Aggiornamento dei nodi cluster SES 5

default-no-update-reboot

Riavvia senza installare gli aggiornamenti.

default-no-update-no-reboot

Non installa gli aggiornamenti né il riavvio.

1.10 Interruzione o riavvio del cluster

In alcuni casi può essere necessario interrompere o riavviare l'intero cluster. Si consiglia di ve- rificare attentamente le dipendenze dei servizi in esecuzione. Nei passaggi successivi è descritto come interrompere e avviare il cluster:

1. Indicare al cluster Ceph di impostare il ag noout:

root # ceph osd set noout

2. Interrompere daemon e nodi nel seguente ordine:

1. Client di memorizzazione

2. Gateway, ad esempio NFS Ganesha o Object Gateway 3. Metadata Server

4. Ceph OSD 5. Ceph Manager 6. Ceph Monitor

3. Se necessario, eseguire task di manutenzione.

4. Avviare nodi e server in ordine inverso rispetto al processo di spegnimento:

1. Ceph Monitor 2. Ceph Manager 3. Ceph OSD 4. Metadata Server

13 Interruzione o riavvio del cluster SES 5

5. Gateway, ad esempio NFS Ganesha o Object Gateway 6. Client di memorizzazione

5. Rimuovere il ag noout:

root # ceph osd unset noout

1.11 File _ceph.conf personalizzato

Se è necessario inserire impostazioni personalizzate nel file ceph.conf, è possibile farlo mo- dificando i file di configurazione nella directory /srv/salt/ceph/configuration/files/ce- ph.conf.d:

global.conf mon.conf mgr.conf mds.conf osd.conf client.conf rgw.conf

Nota: _rgw.conf univoco

Object Gateway offre molta flessibilità ed è univoco rispetto alle altre sezioni di ce- ph.conf. Tutti gli altri componenti Ceph presentano intestazioni statiche, come [mon]

o [osd]. Object Gateway ha intestazioni univoche, come [client.rgw.rgw1]. Vale a dire che per il file rgw.conf è necessaria una voce intestazione. Per un esempio, vedere

/srv/salt/ceph/configuration/files/rgw.conf.

14 File ceph.conf personalizzato SES 5

Importante: esecuzione della fase 3

Dopo aver apportato modifiche personalizzate ai file di configurazione di cui sopra, ese- guire la fase 3 per applicarle ai nodi cluster:

root@master # salt-run state.orch ceph.stage.3

Questi file vengono inclusi dal file modello /srv/salt/ceph/configuration/files/ce- ph.conf.j2 e corrispondono alle diverse sezioni accettate dal file di configurazione Ceph. L'in- serimento di un frammento di configurazione nel file corretto consente a DeepSea di posizio- narlo nella sezione esatta. Non è necessario aggiungere alcuna intestazione di sezione.

Suggerimento

Per applicare un'opzione di configurazione a istanze specifiche di un daemon, aggiungere un'intestazione come [osd.1]. Le opzioni di configurazione seguenti verranno applicate solo al daemon OSD con ID 1.

1.11.1 Sostituzione delle impostazioni di default

Le istruzioni più recenti in una sezione sostituiscono quelle precedenti. Pertanto, è possibile sostituire la configurazione di default come specificato nel modello /srv/salt/ceph/confi- guration/files/ceph.conf.j2. Ad esempio, per disattivare l'autenticazione cephx, aggiun- gere le tre righe seguenti al file /srv/salt/ceph/configuration/files/ceph.conf.d/glo- bal.conf:

auth cluster required = none auth service required = none auth client required = none

1.11.2 Inclusione di file di configurazione

Se è necessario applicare numerose configurazioni personalizzate, utilizzare le istruzioni di in- clusione seguenti nei file di configurazione per rendere più semplice la gestione dei file. Di se- guito è riportato un esempio di file osd.conf:

[osd.1]

15 Sostituzione delle impostazioni di default SES 5

{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}

[osd.2]

{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}

[osd.3]

{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}

[osd.4]

{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

Nell'esempio precedente, i file osd1.conf, osd2.conf, osd3.conf e osd4.conf contengono le opzioni di configurazione specifiche per l'OSD correlato.

Suggerimento: configurazione di runtime

Le modifiche apportate ai file di configurazione Ceph vengono applicate dopo il riavvio dei daemon Ceph correlati. Per ulteriori informazioni sulla modifica della configurazione di runtime Ceph, vedere Sezione 1.12, «Configurazione Ceph di runtime».

1.12 Configurazione Ceph di runtime

Nella Sezione 1.11, «File ceph.conf personalizzato» è illustrato come modificare il file di configu- razione Ceph ceph.conf. Il comportamento effettivo del cluster non è tuttavia determinato dallo stato attuale del file ceph.conf, bensì dalla configurazione dei daemon Ceph in esecu- zione, che è memorizzata.

È possibile interrogare un daemon Ceph daemon individuale per una determinata impostazio- ne di configurazione utilizzando il socket amministrativo sul nodo in cui è in esecuzione il dae- mon. Ad esempio, con il seguente comando si ottiene il valore del parametro di configurazione

osd_max_write_size dal daemon denominato osd.0:

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \ config get osd_max_write_size

{

"osd_max_write_size": "90"

}

È inoltre possibile modificare le impostazioni dei daemon in fase di runtime. Tenere presente che questa modifica è temporanea e al riavvio successivo del daemon andrà persa. Ad esempio, con il seguente comando si modifica il parametro osd_max_write_size a "50" per tutti gli OSD nel cluster:

root # ceph tell osd.* injectargs --osd_max_write_size 50

16 Configurazione Ceph di runtime SES 5

Avviso: _injectargs non è affidabile

Sfortunatamente, se si modificano le impostazioni del cluster con il comando injec- targs, l'operazione non è affidabile al 100%. Se è necessario avere la certezza che il parametro modificato sia attivo, modificarlo nel file di configurazione e riavviare tutti i daemon nel cluster.

17 Configurazione Ceph di runtime SES 5

II Funzionamento di un cluster

2 Introduzione 19

3 Attivazione dei servizi Ceph 20

4 Determinazione dello stato del cluster 24 5 Autenticazione con cephx 42

6 Gestione dei dati memorizzati 57 7 Gestione di pool di memorizzazione 74

8 RADOS Block Device (dispositivo di blocco RADOS) 93 9 Pool con codice di cancellazione 114

10 Suddivisione in livelli di cache 120

2 Introduzione

In questa parte del manuale verrà spiegato come avviare o interrompere servizi Ceph, monitorare lo stato di un cluster, utilizzare e modificare mappe CRUSH o gestire pool di memorizzazione.

Sono inoltre inclusi argomenti avanzati, ad esempio su come gestire snapshot di pool e dispositivi RADOS, configurare pool con codice di cancellazione o su come migliorare le prestazioni del cluster con la suddivisione in livelli di cache.

19 SES 5

3 Attivazione dei servizi Ceph

È possibile attivare servizi Ceph utilizzando sia systemd sia DeepSea.

3.1 Attivazione dei servizi Ceph con _systemd

Utilizzare il comando systemctl per attivare tutti i servizi correlati a Ceph. Tali servizi vengono messi in funzione nel nodo al quale si è attualmente eseguito il login. Per poter operare sui servizi Ceph è necessario disporre dei privilegi radice.

3.1.1 Avvio, interruzione e riavvio dei servizi mediante l'uso di destinazioni

Per semplificare l'avvio, l'interruzione e il riavvio di tutti i servizi di un determinato tipo (ad esempio tutti i servizi Ceph o tutti i MON o OSD) in un nodo, in Ceph sono disponibili i seguenti file di unità systemd:

root # ls /usr/lib/systemd/system/ceph*.target ceph.target

ceph-osd.target ceph-mon.target ceph-mgr.target ceph-mds.target ceph-radosgw.target ceph-rbd-mirror.target

Per avviare/interrompere/riavviare tutti i servizi Ceph sul nodo, eseguire:

root # systemctl stop ceph.target root # systemctl start ceph.target root # systemctl restart ceph.target

Per avviare/interrompere/riavviare tutti gli OSD sul nodo, eseguire:

root # systemctl stop ceph-osd.target root # systemctl start ceph-osd.target root # systemctl restart ceph-osd.target

I comandi per le altre destinazioni sono analoghi.

20 Attivazione dei servizi Ceph con systemd SES 5

3.1.2 Avvio, interruzione e riavvio di servizi individuali

È possibile attivare servizi individuali utilizzando i seguenti file di unità systemd on parametri:

ceph-osd@.service ceph-mon@.service ceph-mds@.service ceph-radosgw@.service ceph-rbd-mirror@.service

Per utilizzare questi comandi, è prima necessario identificare il nome del servizio da attivare.

Per ulteriori informazioni sull'identificazione dei servizi, vedere Sezione 3.1.3, «Identificazione di servizi individuali».

Per avviare/interrompere/riavviare il servizio osd.1, eseguire:

root # systemctl stop ceph-osd@1.service root # systemctl start ceph-osd@1.service root # systemctl restart ceph-osd@1.service

I comandi per gli altri tipi di servizi sono analoghi.

3.1.3 Identificazione di servizi individuali

È possibile individuare i nomi/numeri di un determinato tipo di servizio eseguendo systemctl e filtrando i risultati con il comando grep. Ad esempio:

root # systemctl | grep -i 'ceph-osd.*service' root # systemctl | grep -i 'ceph-mon.*service' [...]

3.1.4 Stato dei servizi

È possibile interrogare ^systemd per lo stato dei servizi. Ad esempio:

root # systemctl status ceph-osd@1.service

root # systemctl status ceph-mon@HOSTNAME.service

Sostituire HOSTNAME con il nome host sul quale è in esecuzione il daemon.

Se non si conosce il nome/numero esatto del servizio, vedere Sezione 3.1.3, «Identificazione di servizi individuali».

21 Avvio, interruzione e riavvio di servizi individuali SES 5

3.2 Riavvio dei servizi Ceph mediante l'uso di DeepSea

Dopo aver applicato gli aggiornamenti ai nodi del cluster, è necessario riavviare i servizi asse- gnati per poter utilizzare la versione installata di recente.

Nota: osservazione del riavvio

Il processo di riavvio del cluster può richiedere tempo. È possibile osservare gli eventi utilizzando il bus di eventi Salt eseguendo:

root@master # salt-run state.event pretty=True

3.2.1 Riavvio di tutti i servizi

Per riavviare tutti i servizi sul cluster, eseguire il seguente comando:

root@master # salt-run state.orch ceph.restart

L'ordine di riavvio dei ruoli individuali è diverso a seconda della versione DeepSea (rpm -q deepsea):

Per le versioni precedenti a DeepSea 0.8.4, i servizi Metadata Server, iSCSI Gateway, Object Gateway e NFS Ganesha vengono riavviati parallelamente.

Per DeepSea 0.8.4 e versioni successive, tutti i ruoli configurati vengono riavviati nel se- guente ordine: Ceph Monitor, Ceph Manager, Ceph OSD, Metadata Server, Object Gateway, iSCSI Gateway, NFS Ganesha. Per mantenere basso il tempo di inattività e trovare poten- ziali problemi il prima possibile, i nodi vengono riavviati in ordine sequenziale. Ad esem- pio, viene avviato un solo nodo di monitoraggio alla volta.

Il comando attende il recupero del cluster se questo si trova in uno stato danneggiato o non integro.

22 Riavvio dei servizi Ceph mediante l'uso di DeepSea SES 5

3.2.2 Riavvio di servizi specifici

Per riavviare un servizio specifico sul cluster, eseguire:

root@master # salt-run state.orch ceph.restart.service_name

Ad esempio, per riavviare tutti gli Object Gateway, eseguire:

root@master # salt-run state.orch ceph.restart.rgw

È possibile utilizzare le destinazioni seguenti:

root@master # salt-run state.orch ceph.restart.mon root@master # salt-run state.orch ceph.restart.mgr root@master # salt-run state.orch ceph.restart.osd root@master # salt-run state.orch ceph.restart.mds root@master # salt-run state.orch ceph.restart.rgw root@master # salt-run state.orch ceph.restart.igw root@master # salt-run state.orch ceph.restart.ganesha

23 Riavvio di servizi specifici SES 5

4 Determinazione dello stato del cluster

Quando un cluster è in esecuzione, è possibile utilizzare lo strumento ceph per monitorare il cluster. Di norma, per determinare lo stato del cluster è necessario verificare lo stato di OSD, monitoraggio, gruppo di posizionamento e server dei metadati.

Suggerimento: modalità interattiva

Per eseguire lo strumento ceph in modalità interattiva, digitare ceph nella riga di co- mando senza argomenti. La modalità interattiva è più pratica se si devono immettere più comandi ceph in una riga. Ad esempio:

cephadm > ceph ceph> health ceph> status

ceph> quorum_status ceph> mon_status

4.1 Verifica dello stato di integrità del cluster

Dopo l'avvio del cluster e prima della lettura e/o scrittura dei dati, verificare lo stato di integrità del cluster:

root # ceph health

HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \ node-1,node-2,node-3

Il cluster Ceph restituisce uno dei seguenti codici di stato di integrità:

OSD_DOWN

Uno o più OSD sono contrassegnati. È possibile che il deamon OSD sia stato interrotto o gli OSD peer potrebbero non essere in grado di raggiungere l'OSD nella rete. Tra le cause comuni sono inclusi un'interruzione o crash del daemon, un host inattivo o un'interruzione della rete.

Verificare che l'host sia integro, il daemon avviato e la rete funzionante. Se ha avuto luo- go un crash del daemon, è possibile che il file di log del daemon (/var/log/ceph/ce- ph-osd.*) contenga informazioni di debug.

24 Verifica dello stato di integrità del cluster SES 5

OSD__{crush type}_DOWN, ad esempio OSD_HOST_DOWN

Tutti gli OSD in un determinato sottoalbero CRUSH vengono contrassegnati, ad esempio tutti gli OSD in un host.

OSD_ORPHAN

Un OSD è un riferimento nella gerarchia della mappa CRUSH, ma non esiste. È possibile rimuovere l'OSD dalla gerarchia CRUSH con:

root # ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Le soglie di utilizzo per backfillfull, nearfull, full e/o failsafe_full non sono in ordine crescente.

In particolare, ci si aspetta backfillfull < nearfull, nearfull < full e full < failsafe_full. È possibile regolare le soglie con:

root # ceph osd set-backfillfull-ratio ratio root # ceph osd set-nearfull-ratio ratio root # ceph osd set-full-ratio ratio

OSD_FULL

Uno o più OSD hanno superato la soglia full e impediscono al cluster di fornire servizi di scrittura. È possibile verificare l'utilizzo da parte del pool con:

root # ceph df

È possibile visualizzare il rapporto full attualmente definito con:

root # ceph osd dump | grep full_ratio

Una soluzione immediata per ripristinare la disponibilità di scrittura consiste nell'aumen- tare leggermente la soglia completa (full):

root # ceph osd set-full-ratio ratio

Aggiungere un nuovo spazio di memorizzazione al cluster installando più OSD, o eliminare i dati esistenti per liberare spazio.

OSD_BACKFILLFULL

Uno o più OSD hanno superato la soglia backfillfull, impedendo il ribilanciamento dei dati nel dispositivo. Questo è un avviso preliminare che informa l'utente sull'impossibilità di completare il ribilanciamento e che il cluster è quasi pieno. È possibile verificare l'utilizzo da parte del pool con:

root # ceph df

25 Verifica dello stato di integrità del cluster SES 5

OSD_NEARFULL

Uno o più OSD hanno superato la soglia nearfull. Questo è un avviso preliminare che infor- ma l'utente che il cluster è quasi pieno. È possibile verificare l'utilizzo da parte del pool con:

root # ceph df

OSDMAP_FLAGS

Sono stati impostati uno o più ag del cluster interessato. Ad eccezione di full, è possibile impostare o eliminare i ag con:

root # ceph osd set flag root # ceph osd unset flag

Tali ag includono:

full

Il cluster è contrassegnato come full (pieno) e non può fornire servizi di scrittura.

pauserd, pausewr

Letture o scritture in pausa noup

Viene impedito l'avvio degli OSD.

nodown

I rapporti sugli errori degli OSD vengono ignorati, ad esempio quando i monitoraggi non contrassegnano gli OSD come down (inattivi).

noin

Gli OSD contrassegnati precedentemente come out non verranno contrassegnati di nuovo come in all'avvio.

noout

Gli ODS down (inattivi) non verranno contrassegnati automaticamente come out dopo l'intervallo configurato.

nobackfill, norecover, norebalance

Il recupero o il ribilanciamento dei dati è sospeso.

noscrub, nodeep_scrub

La pulitura (vedere Sezione 6.5, «Pulitura») è disabilitata.

notieragent

L'attività di suddivisione in livelli di cache è sospesa.

26 Verifica dello stato di integrità del cluster SES 5