Guida alla distribuzione. SUSE Enterprise Storage 6

Guida alla distribuzione

SUSE Enterprise Storage 6

Guida alla distribuzione

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

Data di pubblicazione: 22.05.2020 SUSE LLC

1800 South Novell Place Provo, UT 84606 USA

https://documentation.suse.com

Copyright © 2020 SUSE LLC

Copyright © 2016, RedHat, Inc, e collaboratori.

Il testo e le illustrazioni di questo documento sono forniti con licenza Creative Commons Attribution-Share Alike 4.0 International ("CC-BY-SA"). Una spiegazione di CC-BY-SA è disponibile all'indirizzo http://crea- tivecommons.org/licenses/by-sa/4.0/legalcode . In conformità a CC-BY-SA, se si distribuisce questo docu- mento 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. 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 fab-

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 det- tagli. 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 x

I SUSE ENTERPRISE STORAGE ₁

1 SUSE Enterprise Storage 6 e Ceph ₂

1.1 Caratteristiche di Ceph 2 1.2 Componenti core 3

RADOS ₃ • CRUSH ₄ • Daemon e nodi Ceph ₅ 1.3 Struttura di storage 6

Pool ₆ • Gruppo di posizionamento ₇ • Esempio ₇ 1.4 BlueStore 8

1.5 Informazioni aggiuntive ₁₀

2 Requisiti hardware e raccomandazioni 11

2.1 Configurazioni di architettura multiple ₁₁ 2.2 Configurazione minima del cluster 11 2.3 Nodi storage oggetto 12

Requisiti minimi ₁₂ • Dimensioni minime del disco ₁₃ • Dimensioni consigliate per dispositivo DB e WAL di BlueStore ₁₃ • Utilizzo di SSD per giornali di registrazione OSD ₁₄ • Numero massimo di dischi consigliato ₁₄

2.4 Nodi monitor 15

2.5 Nodi Object Gateway ₁₅ 2.6 Nodi Metadata Server 15 2.7 Salt Master 16

2.9 Raccomandazioni di rete 16

Aggiunta di una rete privata a un cluster in esecuzione ₁₇ • Nodi monitor su diverse sottoreti ₁₇

2.10 Limitazioni dei nomi 18

2.11 Condivisione di un server da parte di OSD e Monitor 18 2.12 Configurazione cluster di produzione consigliata ₁₉ 2.13 SUSE Enterprise Storage 6 e altri prodotti SUSE 20

SUSE Manager ₂₀

3 Configurazione nodo admin HA ₂₁

3.1 Profilo del cluster HA per il nodo admin 21 3.2 Costruzione del cluster HA con il nodo admin ₂₂

4 Privilegi utente e prompt dei comandi 24

4.1 Comandi correlati a Salt/DeepSea 24 4.2 Comandi correlati a Ceph 24

4.3 Comandi Linux generali 25 4.4 Informazioni aggiuntive ₂₅

II DISTRIBUZIONE E UPGRADE DEL CLUSTER 26

5 Installazione con DeepSea/Salt 27

5.1 Lettura delle note di rilascio 27 5.2 Introduzione a DeepSea ₂₈

Organizzazione e ubicazioni importanti ₂₉ • Indirizzamento dei minion ₃₀

5.3 Distribuzione del cluster 32 5.4 DeepSea CLI 42

DeepSea CLI: nodo monitor ₄₂ • DeepSea CLI: modalità stand-alone ₄₃

5.5 Configurazione e personalizzazione 45

Il file policy.cfg 45 • DriveGroups ₅₀ • Regolazione di ceph.conf tramite le impostazioni personalizzate ₆₀

6 Upgrade dalle release precedenti ₆₁

6.1 Punti da tenere presente prima dell'upgrade 61 6.2 Backup dei dati del cluster 65

6.3 Esecuzione della migrazione da _ntpd a _{chronyd 65} 6.4 Applicazione di patch al cluster prima dell'upgrade 67

Archivi software obbligatori ₆₇ • Sistemi di gestione provvisoria

dell'archivio ₆₈ • Applicazione delle patch più recenti a tutto il cluster ₆₈ 6.5 Verifica dell'ambiente corrente ₆₉

6.6 Verifica dello stato del cluster 70 6.7 Upgrade oine dei cluster CTDB 71 6.8 Upgrade per nodo - Procedura di base ₇₁

Esecuzione dell'upgrade manuale dei nodi tramite il DVD del programma di installazione ₇₂ • Esecuzione dell'upgrade del nodo tramite il Distribution Migration System di SUSE ₇₄

6.9 Esecuzione dell'upgrade del nodo admin 75

6.10 Esecuzione dell'upgrade dei nodi Ceph Monitor/Ceph Manager ₇₆ 6.11 Esecuzione dell'upgrade dei server di metadati 77

6.12 Esecuzione dell'upgrade dei Ceph OSD 78 6.13 Migrazione OSD a BlueStore 82

6.14 Esecuzione dell'upgrade dei nodi dell'applicazione 83

6.15 Aggiornamento di _policy.cfg e distribuzione del Ceph Dashboard tramite DeepSea 84

6.16 Migrazione da distribuzioni basate sul profilo ai DriveGroups 86 Analisi del layout corrente ₈₇ • Creazione di DriveGroups corrispondenti al layout corrente ₈₇ • Distribuzione OSD ₈₈ • Configurazioni più complesse ₈₉

7 Personalizzazione della configurazione di default ₉₀

7.1 Uso dei file di configurazione personalizzati 90

Disabilitazione di una fase di installazione ₉₀ • Sostituzione di una fase di installazione ₉₁ • Modifica di una fase di installazione ₉₃ • Modifica di una fase di installazione ₉₄ • Aggiornamenti e riavvii durante la fase 0 ₉₅ 7.2 Modifica della configurazione rilevata 96

Abilitazione di IPv6 per la distribuzione del cluster Ceph ₉₈

III INSTALLAZIONE DI SERVIZI AGGIUNTIVI 100

8 Installazione di servizi per l'accesso ai dati 101 9 Ceph Object Gateway 102

9.1 Installazione minima di Object Gateway ₁₀₂ Configurazione di Object Gateway ₁₀₃

10 Installazione di iSCSI Gateway ₁₀₉

10.1 Storage di blocco iSCSI 109

La destinazione iSCSI Kernel Linux ₁₁₀ • Iniziatori iSCSI ₁₁₀ 10.2 Informazioni generali su ceph-iscsi 111

10.3 Considerazioni sull'installazione ₁₁₂ 10.4 Installazione e configurazione 113

Distribuire iSCSI Gateway in un cluster Ceph ₁₁₃ • Creare immagini RBD ₁₁₄ • Esportare immagini RBD tramite iSCSI ₁₁₄ • Autenticazione e controllo dell'accesso ₁₁₅ • Impostazioni avanzate ₁₁₇

10.5 Esportazione delle immagini del dispositivo di blocco RADOS con _tcmu- runner 121

11 Installazione di CephFS ₁₂₂

11.1 Scenari e guida CephFS supportati 122 11.2 Metadata Server Ceph 123

Aggiunta di un Metadata Server ₁₂₃ • Configurazione di un Metadata Server ₁₂₃

11.3 CephFS 129

Creazione di CephFS ₁₃₀ • Dimensione cluster MDS ₁₃₁ • Aggiornamenti e cluster MDS ₁₃₂ • Layout di file ₁₃₃

12 Installazione di NFS Ganesha ₁₃₈

12.1 Preparazione 138

Informazioni generali ₁₃₈ • Riepilogo dei requisiti ₁₃₉ 12.2 Installazione di esempio ₁₃₉

12.3 Configurazione attiva-passiva ad alta disponibilità 140 Installazione di base ₁₄₀ • Eettuare la pulizia delle

risorse ₁₄₃ • Impostazione della risorsa di ping ₁₄₃ • DeepSea e HA di NFS Ganesha ₁₄₄

12.4 Configurazione attiva-attiva 144

Prerequisiti ₁₄₅ • Configurazione di NFS Ganesha ₁₄₅ • Popolamento del database extra del cluster ₁₄₇ • Riavvio dei servizi NFS

Ganesha ₁₄₇ • Conclusioni ₁₄₈ 12.5 ulteriori informazioni ₁₄₈

IV DISTRIBUZIONE DEL CLUSTER SOPRA SUSE CAAS PLATFORM 4 (TECNOLOGIA IN ANTEPRIMA) ₁₄₉

13 Cluster Kubernetes SUSE Enterprise Storage 6 sopra SUSE CaaS Platform 4 ₁₅₀

13.1 Considerazioni ₁₅₀ 13.2 Prerequisiti 150

13.3 Ottenimento dei manifesti di Rook 151

13.4 Installazione 151

Configurazione ₁₅₁ • Creazione dell'operatore Rook ₁₅₃ • Creazione del cluster Ceph ₁₅₃

13.5 Utilizzo di Rook come storage per i workload di Kubernetes 154 13.6 Disinstallazione di Rook 155

A Aggiornamenti alla manutenzione di Ceph basati sulle release intermedie upstream "Nautilus" ₁₅₆

Glossario ₁₅₉

B Aggiornamenti della documentazione ₁₆₂

B.1 Aggiornamento di manutenzione della documentazione relativa a SUSE Enterprise Storage 6 162

B.2 Giugno 2019 (release di SUSE Enterprise Storage 6) ₁₆₃

Informazioni sulla Guida

SUSE Enterprise Storage 6 è un'estensione di SUSE Linux Enterprise Server 15 SP1 che combi- na le capacità del progetto di storage Ceph (http://ceph.com/ ) con il supporto e l'ingegneria aziendale di SUSE. SUSE Enterprise Storage 6 fornisce alle organizzazioni IT la possibilità di installare un'architettura di storage distribuita in grado di supportare numerosi casi di utilizzo mediante piattaforme hardware commodity.

Questa guida aiuta a comprendere il concetto di SUSE Enterprise Storage 6 ed è incentrata sulla gestione e sull'amministrazione dell'infrastruttura Ceph. Dimostra inoltre come utilizzare 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:

Libro «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.

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.

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

File, File Save As (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 Collaboratori di Ceph

Il progetto Ceph e la relativa documentazione sono il risultato del lavoro di centinaia di col- laboratori e organizzazioni. Per ulteriori dettagli, consultare la pagina all'indirizzo https://ce- ph.com/contributors/ .

I SUSE Enterprise Storage

1 SUSE Enterprise Storage 6 e Ceph 2 2 Requisiti hardware e raccomandazioni ₁₁ 3 Configurazione nodo admin HA ₂₁

4 Privilegi utente e prompt dei comandi ₂₄

1 SUSE Enterprise Storage 6 e Ceph

SUSE Enterprise Storage 6 è un sistema di storage distribuito progettato per scalabilità, affida- bilità e prestazioni basato sulla tecnologia Ceph. È possibile eseguire un cluster Ceph su server generici in una rete comune come Ethernet. Il cluster può scalare inoltre fino a migliaia di ser- ver (più avanti denominati nodi) e nel campo dei petabyte. Rispetto ai sistemi convenzionali che dispongono di tabelle di allocazione per memorizzare e recuperare i dati, Ceph utilizza un algoritmo deterministico per allocare lo storage per i dati e non dispone di alcuna struttura informativa centralizzata. Ceph suppone che nei cluster di storage l'aggiunta o la rimozione dell'hardware sia la normalità, non l'eccezione. Il cluster Ceph automatizza i task di gestione come distribuzione e ridistribuzione dei dati, replica dei dati, rilevamento e ripristino degli er- rori. Ceph sfrutta capacità di autoregolazione e autogestione, determinando la riduzione delle spese amministrative e sforamenti di bilancio.

Questo capitolo contiene una panoramica di alto livello di SUSE Enterprise Storage 6 e una breve descrizione dei componenti più importanti.

Suggerimento

Da SUSE Enterprise Storage 5, il solo metodo di distribuzione dei cluster è DeepSea. Per informazioni sul processo distributivo, consultare Capitolo 5, Installazione con DeepSea/Salt.

1.1 Caratteristiche di Ceph

L'ambiente Ceph presenta le seguenti caratteristiche:

Scalabilità

Ceph è in grado di scalare a migliaia di nodi e gestire lo storage nel campo dei petabyte.

Hardware

Per eseguire il cluster Ceph, non sono richiesti hardware speciali. Per informazioni, vedere Capitolo 2, Requisiti hardware e raccomandazioni

Autogestione

Il cluster Ceph è in grado di autogestirsi. Quando si aggiungono o rimuovono nodi o in caso di guasto, il cluster ridistribuisce automaticamente i dati. È inoltre in grado di riconoscere

Nessun Single point of failure

Nessun nodo in un cluster memorizza da solo dati importanti. È possibile configurare il numero di ridondanze.

Software open source

Ceph è una soluzione software open source e indipendente da hardware o fornitori speci- fici.

1.2 Componenti core

Per utilizzare pienamente la potenza di Ceph, è necessario comprendere alcuni dei componenti e concetti di base. Questa sezione presenta alcune parti di Ceph a cui si fa spesso riferimento in altri capitoli.

1.2.1 RADOS

Il componente base di Ceph è denominato RADOS (Reliable Autonomic Distributed Object Store), responsabile per la gestione dei dati memorizzati nel cluster. I dati in Ceph vengono in genere memorizzati come oggetti. Ciascun oggetto consiste di un identificativo e dai dati.

RADOS fornisce i seguenti metodi di accesso agli oggetti memorizzati che riguardano molti casi d'uso:

Object Gateway

Object Gateway è un gateway HTTP REST per lo store di oggetti RADOS che consente l'accesso diretto agli oggetti memorizzati nel cluster Ceph.

RADOS Block Device

È possibile accedere ai RADOS Block Device (RBD) analogamente ad altri dispositivi di blocco e utilizzarli ad esempio insieme con libvirt per scopi di virtualizzazione.

CephFS

Il file system di Ceph è di tipo POSIX-compatibile.

librados

librados è una libreria utilizzabile con molti linguaggi di programmazione per creare un'applicazione in grado di interagire direttamente con il cluster di storage.

librados è utilizzata da Object Gateway e RBD mentre CephFS si interfaccia direttamente con RADOS Figura 1.1, «Interfacce con lo store oggetti Ceph».

RADOS

FIGURA 1.1: INTERFACCE CON LO STORE OGGETTI CEPH

1.2.2 CRUSH

Il core del cluster Ceph è l'algoritmo CRUSH. CRUSH è l'acronimo di Controlled Replication Un- der Scalable Hashing. CRUSH è una funzione che gestisce l'allocazione dello storage e richiede comparabilmente pochi parametri. Ciò significa che è necessaria solo una piccola quantità di dati per calcolare la posizione di storage di un oggetto. I parametri sono una mappa corrente del cluster comprendente lo stato, alcune regole di posizionamento definite dall'amministratore e il nome dell'oggetto che deve essere memorizzato o recuperato. Con questi dati, tutti i nodi nel cluster Ceph sono in grado di calcolare dove si trova un oggetto e le sue repliche. Ciò rende la scrittura o la lettura dei dati molto efficace. CRUSH tenta di distribuire in modo uniforme i dati tra tutti i nodi nel cluster.

La mappa CRUSH contiene tutti i nodi di storage e le regole di posizionamento definite dall'am- ministratore per la memorizzazione degli oggetti nel cluster e definisce una struttura gerarchica che di solito corrisponde alla struttura fisica del cluster. Ad esempio, i dischi contenenti i dati sono negli host, gli host sono nei rack, i rack in righe e le righe nei data center. È possibile utilizzare questa struttura per definire i domini di guasto. Ceph quindi garantisce che le repliche vengano memorizzate su diverse diramazioni di uno specifico dominio di guasto.

Se il dominio di guasto è configurato su un rack, le repliche degli oggetti sono distribuite su diversi rack. Ciò può ridurre le perdite provocate da un errore di commutazione in un rack.

Se un'unità di distribuzione alimentazione alimenta una riga di rack, il dominio di guasto può essere configurato su una riga. In caso di errore dell'unità di distribuzione di alimentazione, i

1.2.3 Daemon e nodi Ceph

In Ceph, i nodi sono server che lavorano per il cluster e possono eseguire diversi tipi di daemon.

Si consiglia di eseguire solo un tipo di daemon in ogni nodo, tranne per i Ceph Manager Daemon che possono essere collocati con i Ceph Monitor. Per ogni cluster sono necessari almeno i daemon Ceph Monitor, Ceph Manager e Ceph OSD:

Nodo admin

Il nodo admin è un nodo del cluster Ceph dove è in esecuzione il servizio Salt master. Il nodo admin è un punto centrale del cluster Ceph perché gestisce i nodi residui del cluster tramite interrogazione e istruendo i relativi servizi Salt minion. Comprende in genere anche altri servizi, ad esempio l'interfaccia utente Web di Ceph Dashboard con il dashboard Grafana supportato dal kit di strumenti di monitoraggio Prometheus.

Ceph Monitor

I nodi Ceph Monitor (spesso abbreviato con MON) mantengono le informazioni sullo stato del cluster, una mappa di tutti i nodi e regole di distribuzione dati (vedere Sezione 1.2.2,

«CRUSH»).

Se si verificano errori o conflitti, i nodi Ceph Monitor nel cluster decidono a maggioranza quali dati sono corretti. Per formare una maggioranza qualificata, si consiglia un numero dispari di nodi Ceph Monitor e almeno tre.

Se si utilizzano più siti, i nodi Ceph Monitor devono essere distribuiti su un numero dispari di siti. Il numero di nodi Ceph Monitor per sito deve essere tale che oltre il 50% dei nodi Ceph Monitor resti funzionale in caso di errore di un sito.

Ceph Manager

Ceph manager (MGR) raccoglie le informazioni di stato dall'intero cluster. Il daemon Ceph manager viene eseguito insieme con i daemon monitor, fornisce ulteriore monitoraggio e si interfaccia con i sistemi di gestione e monitoraggio esterni.

Ceph manager non richiede configurazione aggiuntiva, oltre ad accertarne l'esecuzione. È possibile distribuirlo come ruolo separato mediante DeepSea.

Ceph OSD

Ceph OSD è un daemon che gestisce gli Object Storage Device che sono unità di storage logiche o fisiche (dischi rigidi o partizioni). Gli Object Storage Device possono essere dischi fisici/partizioni o volumi logici. Il daemon si occupa inoltre della replica dei dati e del ribilanciamento in caso di nodi aggiunti o rimossi.

I daemon Ceph OSD comunicano con i daemon monitor e forniscono loro lo stato degli altri daemon OSD.

Per utilizzare CephFS, Object Gateway, NFS Ganesha o iSCSI Gateway, sono richiesti nodi ag- giuntivi:

Metadata Server (MDS)

I server di metadati memorizzano i metadati relativi a CephFS. Mediante un MDS, è pos- sibile eseguire comandi di base del file system come ls senza sovraccaricare il cluster.

Object Gateway

Object Gateway è un gateway HTTP REST per l'archivio dati RADOS. È compatibile con OpenStack Swift e Amazon S3 e dispone di propria gestione utente.

NFS Ganesha

NFS Ganesha fornisce un accesso NFS all'Object Gateway o a CephFS. Viene eseguito nell'u- tente invece che nello spazio kernel e interagisce direttamente con l'Object Gateway o CephFS.

iSCSI Gateway

iSCSI è un protocollo di rete di storage che consente ai client di inviare comandi SCSI ai dispositivi di storage SCSI (destinazioni) su server remoti.

Gateway Samba

Il gateway Samba fornisce accesso SAMBA ai dati memorizzati su CephFS.

1.3 Struttura di storage

1.3.1 Pool

Gli oggetti memorizzati in un cluster Ceph vengono posti nei pool. I pool rappresentano le par- tizioni logiche del cluster per l'esterno. Per ogni pool è possibile definire un set di regole, ad esempio quante repliche di ogni oggetto devono esistere. La configurazione standard dei pool è denominata pool replicato.

I pool in genere contengono oggetti, ma è possibile configurarli anche per funzionare come RAID 5. In questa configurazione, gli oggetti vengono memorizzati in chunk insieme con i chunk di codifica aggiuntivi. I chunk di codifica contengono i dati ridondanti. Il numero di dati e chunk di codifica può essere definito dall'amministratore. In questa configurazione, i pool sono

1.3.2 Gruppo di posizionamento

I gruppi di posizionamento (PG) sono utilizzati per la distribuzione dei dati in un pool. Quando si crea un pool, viene impostato un determinato numero di gruppi di posizionamento. I gruppi di posizionamento sono utilizzati internamente per raggruppare gli oggetti e sono un fattore importante per le prestazioni di un cluster Ceph. Il PG di un oggetto è determinato dal nome dell'oggetto.

1.3.3 Esempio

Questa sezione fornisce un esempio semplificato della gestione dati di Ceph (vedere Figura 1.2,

«Esempio Ceph su piccola scala»). Questo esempio non rappresenta una configurazione consigliata per un cluster Ceph. La configurazione hardware consiste di tre nodi di storage Ceph OSD (Host 1, Host 2, Host 3). Ogni nodo ha tre dischi rigidi utilizzati come OSD (da osd.1 a osd.9).

In questo esempio, vengono tralasciati i nodi Ceph Monitor.

Nota: dierenza tra Ceph OSD e OSD

Mentre Ceph OSD o daemon Ceph OSD si riferisce a un daemon eseguito su un nodo, il termine OSD si riferisce al disco logico con cui interagisce il daemon.

Il cluster ha due pool, Pool A e Pool B. Mentre il Pool A replica gli oggetti solo due volte, la resilienza per Pool B è più importante e ha tre repliche per ogni oggetto.

Quando un'applicazione mette un oggetto in un pool, ad esempio tramite la API REST, un Grup- po di posizionamento (da PG1 a PG4) viene selezionato in base a pool e nome oggetto. L'algo- ritmo CRUSH calcola quindi su quali OSD viene memorizzato l'oggetto, in base al Gruppo di posizionamento contenente l'oggetto.

In questo esempio, il dominio di guasto è impostato sull'host. Ciò garantisce che le repliche degli oggetti siano memorizzate su diversi host. In base al livello di replica impostato per un pool, l'oggetto viene memorizzato su due o tre OSD utilizzati dal Gruppo di posizionamento.

Un'applicazione che scrive un oggetto interagisce solo con un Ceph OSD, il Ceph OSD primario. Il Ceph OSD primario si occupa della replica e conferma il completamento del processo di scrittura dopo che tutti gli altri OSD hanno memorizzato l'oggetto.

In caso di errore di osd.5, tutti gli oggetti in PG1 sono ancora disponibili su osd.1. Non appena il cluster riconosce l'errore di un OSD, un altro OSD lo sostituisce. In questo esempio osd.4 viene utilizzato come sostituzione per osd.5. Gli oggetti memorizzati su osd.1 vengono quindi replicati su osd.4 per ripristinare il livello di replica.

FIGURA 1.2: ESEMPIO CEPH SU PICCOLA SCALA

Se si aggiunge al cluster un nuovo nodo con nuovi OSD, la mappa del cluster cambia. La funzio- ne CRUSH restituisce quindi diverse ubicazioni per gli oggetti. Gli oggetti che ricevono nuove ubicazioni vengono riposizionati. Questo processo determina un uso bilanciato di tutti gli OSD.

1.4 BlueStore

BlueStore è un nuovo back-end di storage di default per Ceph di SUSE Enterprise Storage 5.

Offre migliori prestazioni di FileStore, check-sum dei dati completo e compressione integrata.

BlueStore gestisce uno, due o tre dispositivi di storage. Nel caso più semplice, BlueStore consuma un singolo dispositivo di storage primario. Il dispositivo di storage è di solito partizionato in due parti:

1. Una piccola partizione denominata BlueFS che implementa funzionalità di tipo file system richieste da RocksDB.

2. Il resto del dispositivo è in genere una grande partizione che occupa tutto lo spazio residuo del dispositivo. È gestito direttamente da BlueStore e contiene tutti i dati effettivi. Tale dispositivo primario è in genere identificato da un collegamento simbolico di blocco nella directory dei dati.

È inoltre possibile distribuire BlueStore su due dispositivi aggiuntivi:

Un dispositivo WAL può essere utilizzato per il giornale di registrazione interno di BlueStore o il log di scrittura. È identificato dal collegamento simbolico block.wal nella directory dei dati e serve solo per utilizzare un dispositivo WAL separato se il dispositivo è più veloce del dispositivo primario o del dispositivo DB, ad esempio quando:

il dispositivo WAL è un NVMe e il dispositivo DB è una SSD e il dispositivo dati è un'unità SSD o HDD.

Entrambi i dispositivi WAL e DB sono SSD separate e il dispositivo dati è un'unità SSD o HDD.

È possibile utilizzare un dispositivo DB per memorizzare i metadati interni di BlueStore. BlueStore (o piuttosto il RocksDB integrato) trasferisce tutti i metadati possibili sul dispositivo DB per migliorare le prestazioni. Di nuovo, è utile solo per il provisioning di un dispositivo DB condiviso se è più veloce del dispositivo primario.

Suggerimento: pianificare la dimensione del DB

Pianificarla attentamente per assicurarsi che il dispositivo DB sia delle dimensioni suffi- cienti. Se il dispositivo DB è pieno, i metadati si riverseranno sul dispositivo primario che degraderà notevolmente le prestazioni dell'OSD.

È possibile verificare se una partizione WAL/DB si sta riempiendo e trasferendo i dati con il comando ceph daemon osd.ID perf dump. Il valore slow_used_bytes mostra la quantità di dati in uscita:

"db_total_bytes": 1073741824,

"db_used_bytes": 33554432,

"wal_total_bytes": 0,

"wal_used_bytes": 0,

"slow_total_bytes": 554432,

"slow_used_bytes": 554432,

1.5 Informazioni aggiuntive

Ceph è un progetto di community che dispone di una propria documentazione com- pleta online. Per argomenti non trovati nel presente manuale, consultare http://docs.ce- ph.com/docs/master/ .

La pubblicazione originale CRUSH: Controlled, Scalable, Decentralized Placement of Replica- ted Data di S.A. Weil, S.A. Brandt, E.L. Miller, C. Maltzahn fornisce spunti utili nelle opere interne di Ceph. Se ne consiglia la lettura soprattutto per la distribuzione di cluster in grande scala. La pubblicazione è disponibile al seguente collegamento http://www.ssrc.uc- sc.edu/papers/weil-sc06.pdf .

SUSE Enterprise Storage può essere utilizzato con le distribuzioni OpenStack non SUSE. I client Ceph devono trovarsi a un livello compatibile con SUSE Enterprise Storage.

Nota

SUSE supporta il componente server della distribuzione Ceph, mentre il client è supportato dal fornitore della distribuzione OpenStack.

2 Requisiti hardware e raccomandazioni

I requisiti hardware di Ceph dipendono strettamente dal carico di lavoro degli IO. Tenere pre- sente i seguenti requisiti hardware e raccomandazioni come base di partenza per una pianifica- zione dettagliata.

In generale, le raccomandazioni date sono riferite a un processo. Se sullo stesso computer sono ubicati più processi, occorre sommare i requisiti di CPU, RAM, disco e rete.

2.1 Configurazioni di architettura multiple

SUSE Enterprise Storage supporta le architetture x86 e Arm. Durante la valutazione di ciascuna architettura, è importante osservare che dalla prospettiva dei core per OSD, frequenza e RAM, non esistono reali differenze tra le architetture CPU in termini di ridimensionamento.

Come per i processori x86 (non-server) di dimensioni più piccole, i core basati su Arm a presta- zioni ridotte potrebbero non fornire un'esperienza ottimale, soprattutto se utilizzati per i pool con codice di cancellazione.

2.2 Configurazione minima del cluster

Sono richiesti almeno quattro nodi OSD, con otto dischi OSD ciascuno.

Tre nodi Monitor Ceph (richiede SSD per unità SO dedicata).

Per iSCSI Gateway, Object Gateway e server di metadati sono richiesti ulteriori 4 GB di RAM e quattro core.

I nodi di Ceph Monitor, Object Gateway e del server di metadati richiedono una distribu- zione ridondante.

Nodo admin separato con 4 GB di RAM, quattro core, capacità di 1 TB. In genere questo è il nodo Salt master. I servizi e i gateway Ceph, come Ceph Monitor, Ceph Manager, server di metadati, Ceph OSD, Object Gateway o NFS Ganesha, non sono supportati sul nodo admin.

2.3 Nodi storage oggetto

2.3.1 Requisiti minimi

Raccomandazioni sulla CPU:

1 thread CPU da 2 GHz per unità a rotazione 2 thread CPU da 2 GHz per SSD

4 thread CPU da 2 GHz per NVMe

Reti 10 GbE (pubbliche/client e di back-end) separate: 4 da 10 GbE obbligatorie, 2 da 25 GbE consigliate.

RAM totale richiesta = numero di OSD x (1 GB + osd_memory_target) + 16 GB Per ulteriori dettagli su osd_memory_target, consultare questo riferimento: Libro «Guida all'amministrazione», Capitolo 16 «Configurazione del cluster Ceph», Sezione 16.2.1 «Ridimensiona- mento automatico della cache».

Dischi OSD nelle configurazioni JBOD o configurazioni RAID-0 individuali.

Il giornale di registrazione OSD può risiedere sul disco OSD.

I dischi OSD devono essere utilizzati esclusivamente da SUSE Enterprise Storage.

SSD/disco dedicato per il sistema operativo, preferibilmente in una configurazione RAID 1.

Se questo host OSD conterrà parte di un pool di cache utilizzato per tiering della cache, allocare almeno ulteriori 4 GB di RAM.

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

Per ragioni di prestazioni del disco, per i nodi OSD si consiglia di utilizzare computer bare metal e non macchine virtuali.

2.3.2 Dimensioni minime del disco

Vi sono due tipi di spazi su disco necessari da eseguire su OSD: lo spazio per il giornale di registrazione del disco (per FileStore) o dispositivo WAL/DB (per BlueStore) e lo spazio primario per i dati memorizzati. Il valore minimo (e di default) per il giornale di registrazione/WAL/DB è 6 GB. Lo spazio minimo per i dati è pari a 5 GB, in quanto a partizioni più piccole di 5 GB viene assegnato automaticamente il peso di 0.

Perciò, sebbene lo spazio minimo su disco per un OSD sia 11 GB, si sconsigliano dischi inferiori a 20 GB, anche per scopi di test.

2.3.3 Dimensioni consigliate per dispositivo DB e WAL di BlueStore

Suggerimento: ulteriori informazioni

Per ulteriori informazioni su BlueStore, consultare Sezione 1.4, «BlueStore».

Si consiglia di prenotare 4 GB per il dispositivo WAL. Le dimensioni consigliate per il dispositivo DB sono 64 GB per la maggior parte dei workload.

Se si intende mettere il dispositivo WAL e DB sullo stesso disco, si consiglia di utilizzare una singola partizione per entrambi i dispositivi, invece di avere una partizione separata per ciascuno. Ciò consente a Ceph di utilizzare il dispositivo DB anche per il funzionamento di WAL. La gestione dello spazio del disco è quindi più efficace in quanto Ceph utilizza la partizione DB per WAL solo se serve. Un altro vantaggio è che le probabilità che la parti- zione WAL si riempia sono molto basse e, quando questa non è utilizzata completamente, il suo spazio non viene sprecato ma utilizzato per le operazioni del dispositivo DB.

Per condividere il dispositivo DB con WAL, non specificare il dispositivo WAL e specificare solo il dispositivo DB.

Nella Sezione 5.5.2, «DriveGroups» è possibile trovare ulteriori informazioni su come speci- ficare un layout OSD.

2.3.4 Utilizzo di SSD per giornali di registrazione OSD

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

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

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

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

2.3.5 Numero massimo di dischi consigliato

Il server può contenere tutti i dischi consentiti. Quando si pianifica il numero di dischi per server, vi sono alcuni elementi da tenere presente:

Ampiezza della banda di rete. Più dischi sono presenti in un server, più dati occorre trasferire tramite scheda di rete per le operazioni di scrittura sul disco.

Memoria. Viene utilizzata una RAM superiore a 2 GB per la cache BlueStore. Con l'opzione osd_memory_target di default di 4 GB, il sistema dispone di dimensioni iniziali della cache ragionevoli per i supporti a rotazione. Se si utilizzano SSD o NVME, prendere in considerazione di aumentare le dimensioni della cache e l'allocazione della RAM per ogni OSD per ottimizzare le prestazioni.

Tolleranza di errore. In caso di guasto del server completo, più dischi sono presenti, più OSD vengono persi temporaneamente dal cluster. Inoltre, per mantenere in esecuzione le regole di replicazione, occorre copiare tutti i dati dal server guasto negli altri nodi nel cluster.

2.4 Nodi monitor

Sono richiesti almeno tre nodi Monitor Ceph. Il numero di monitor deve sempre essere dispari (1+2n).

4 GB di RAM.

Processore con quattro core logici.

Si consiglia un'unità SSD o altro tipo di storage sufficientemente veloce per i monitor, in particolare per il percorso /var/lib/ceph su ogni nodo monitor, in quanto il quorum potrebbe essere instabile con alte latenze del disco. Si consigliano due dischi in configura- zione RAID 1 per ridondanza. Si consiglia di utilizzare dischi separati o almeno partizioni del disco separate per i processi monitor per proteggere lo spazio su disco disponibile del monitor da elementi come file di registro che diventano troppo grandi.

Deve essere presente solo un processo monitor per nodo.

Mischiare nodi OSD, monitor o Object Gateway è possibile solo se sono disponibili suffi- cienti risorse hardware. Ciò significa che si devono sommare i requisiti per tutti i servizi.

Due interfacce di rete associate a più switch.

2.5 Nodi Object Gateway

I nodi Object Gateway devono avere CPU con sei - otto core e 32 GB di RAM (consigliati 64 GB).

Se nello stesso computer sono co-ubicati altri processi, occorre sommare i loro requisiti.

2.6 Nodi Metadata Server

Il corretto dimensionamento dei nodi Metadata Server dipende dal caso d'uso specifico. In ge- nere, il numero di file aperti che deve gestire il Metadata Server è proporzionale alla quantità di CPU e RAM richiesta. Di seguito sono riportati i requisiti minimi:

3 GB di RAM per ogni daemon del server di metadati.

Interfaccia di rete vincolata.

CPU da 2,5 GHz con almeno 2 core.

2.7 Salt Master

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

2.8 Nodi iSCSI

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

2.9 Raccomandazioni di rete

L'ambiente di rete in cui si intende eseguire Ceph deve essere idealmente un insieme vincolato di almeno due interfacce di rete suddiviso logicamente in una parte pubblica e una parte interna affidabile che utilizza VLAN. Si consiglia la modalità di vincolo 802.3ad se possibile per fornire una resilienza e un'ampiezza di banda massima.

La VLAN pubblica fornisce il servizio ai clienti, mentre la parte interna fornisce la comunica- zione di rete Ceph autenticata. Il motivo principale è che sebbene Ceph fornisca automazione e protezione dagli attacchi dopo aver istituito le chiavi segrete, i messaggi utilizzati per configu- rare tali chiavi possono essere trasferiti solo in modo aperto e vulnerabile.

Suggerimento: nodi configurati tramite DHCP

Se i nodi di storage sono configurati tramite DHCP, i timeout default possono non essere sufficienti per configurare correttamente la rete prima dell'avvio dei vari daemon Ceph.

In questo caso, gli OSD e MON Ceph non si avviano correttamente (l'esecuzione di sy- stemctl status ceph\* determina errori del tipo "unable to bind"). Per evitare questo problema, si consiglia di aumentare il timeout del client DHCP ad almeno 30 secondi su ogni nodo nel cluster di storage. È possibile fare questo modificando le impostazioni seguenti su ogni nodo:

In /etc/sysconfig/network/dhcp, impostare

DHCLIENT_WAIT_AT_BOOT="30"

In /etc/sysconfig/network/config, impostare

WAIT_FOR_INTERFACES="60"

2.9.1 Aggiunta di una rete privata a un cluster in esecuzione

Se non si specifica una rete di cluster durante la distribuzione, Ceph presume un ambiente di rete pubblica singola. Mentre Ceph funziona bene con una rete pubblica, le sue prestazioni e sicurezza aumentano quando si imposta una seconda rete di cluster privata. Per supportare due reti, ogni nodo Ceph deve avere almeno due schede di rete.

Occorre applicare le seguenti modifiche a ogni nodo Ceph. È relativamente rapido farlo con un piccolo cluster, ma può essere necessario molto tempo in caso di cluster contenente centinaia o migliaia di nodi.

1. Arrestare i servizi correlati a Ceph su ogni nodo del cluster.

Aggiungere una riga a /etc/ceph/ceph.conf per definire la rete di cluster, ad esempio:

cluster network = 10.0.0.0/24

Se occorre specificamente assegnare indirizzi IP statici o ignorare le impostazioni della rete cluster, è possibile farlo con cluster addr opzionale.

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

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

root # systemctl start ceph.target

2.9.2 Nodi monitor su diverse sottoreti

Se i nodi monitor sono su diverse sottoreti, ad esempio si trovano in stanze diverse e serviti da switch differenti, occorre regolare di conseguenza il file ceph.conf. Ad esempio, se i nodi hanno gli indirizzi IP 192.168.123.12, 1.2.3.4 e 242.12.33.12, aggiungere le righe seguenti alla relativa sezione global:

[global]

[...]

mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12

mon initial members = MON1, MON2, MON3 [...]

Inoltre, se occorre specificare una rete o un indirizzo pubblico per monitor, occorre aggiungere una sezione [mon.X] per ogni monitor:

[mon.MON1]

public network = 192.168.123.0/24

[mon.MON2]

public network = 1.2.3.0/24 [mon.MON3]

public network = 242.12.33.12/0

2.10 Limitazioni dei nomi

Ceph non supporta in genere i caratteri non ASCII nei file di configurazione, nei nomi di pool, nomi utente e così via. Quando si configura un cluster Ceph, si consiglia di utilizzare solo ca- ratteri alfanumerici semplici (A-Z, a-z, 0-9) e punteggiatura minima (".", "-", "_") in tutti i nomi di configurazione/oggetto Ceph.

2.11 Condivisione di un server da parte di OSD e Monitor

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

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

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

Suggerimento

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

2.12 Configurazione cluster di produzione consigliata

Sette nodi Storage oggetto

Nessun singolo nodo eccede ~15% dello storage totale Ethernet 10 Gb (quattro reti fisiche vincolate a più switch).

56+ OSD per cluster di storage

Dischi SO RAID 1 per ogni nodo di storage OSD

SSD per giornale di registrazione con rapporto 6:1 tra giornale SSD e OSD 1,5 GB di RAM per TB di capacità OSD nominale per ogni nodo storage oggetto 2 GHz per OSD per ogni nodo storage oggetto

Nodi infrastruttura fisica dedicata

Tre nodi Ceph Monitor: 4 GB RAM, processore a 4 core, SSD RAID 1 per disco Un nodo gestione SES: 4 GB RAM, processore 4 core, SSD RAID 1 per disco Distribuzione fisica ridondante di nodi gateway o Metadata Server:

Nodi Object Gateway: 32 GB RAM, processore 8 core, SSD RAID 1 per disco Nodi iSCSI Gateway: 16 GB RAM, processore 4 core, SSD RAID 1 per disco Nodi Metadata Server (uno attivo/uno hot standby): 32 GB RAM, processore 8 core, SSD RAID 1 per disco

2.13 SUSE Enterprise Storage 6 e altri prodotti SUSE

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

2.13.1 SUSE Manager

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

3 Configurazione nodo admin HA

Il nodo admin è un nodo del cluster Ceph dove è in esecuzione il servizio Salt master. Il nodo admin è un punto centrale del cluster Ceph perché gestisce i nodi residui del cluster tramite interrogazione e istruendo i relativi servizi Salt minion. Comprende in genere anche altri servizi, ad esempio l'interfaccia utente Web di Ceph Dashboard con il dashboard Grafana supportato dal kit di strumenti di monitoraggio Prometheus.

In caso di errore del nodo admin, occorre di solito fornire un nuovo hardware funzionante per il nodo e ripristinare lo stack di configurazione cluster completo da un backup recente. Tale metodo richiede tempo e determina l'indisponibilità del cluster.

Per evitare il tempo di fermo delle prestazioni del cluster Ceph provocati dall'errore del nodo admin, si consiglia di utilizzare il cluster ad elevata disponibilità (High Availability, HA) per il nodo admin Ceph.

3.1 Profilo del cluster HA per il nodo admin

Il concetto di un cluster HA prevede che in caso di errore di un nodo del cluster, l'altro nodo subentri automaticamente nel ruolo, compreso il nodo admin virtualizzato. In questo modo, gli altri nodi del cluster Ceph non avvertono l'errore del nodo admin Ceph.

La soluzione HA minima per il nodo admin richiede il seguente hardware:

Due server bare metal in grado di eseguire SUSE Linux Enterprise con l'estensione High Availability e virtualizzare il nodo admin.

Due o più percorsi di comunicazione di rete ridondanti, ad esempio tramite Network Device Bonding.

Storage condiviso per ospitare le immagini dei dischi della macchina virtuale del nodo admin. Lo storage condiviso deve essere accessibile da entrambi i server. Può essere ad esempio un'esportazione NFS, una condivisione Samba o una destinazione iSCSI.

Ulteriori dettagli sui requisiti del cluster sono disponibili all'indirizzo https://www.suse.com/do- cumentation/sle-ha-15/book_sleha_quickstarts/data/sec_ha_inst_quick_req.html .

FIGURA 3.1: CLUSTER HA A 2 NODI PER IL NODO ADMIN

3.2 Costruzione del cluster HA con il nodo admin

La procedura seguente riepiloga i passaggi più importanti di costruzione del cluster HA per virtualizzare il nodo admin. Per i dettagli, consultare i collegamenti indicati.

1. Configurare un cluster HA di base a 2 nodi con storage condiviso come descrit- to in https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/art_sle- ha_install_quick.html .

2. Su entrambi i nodi cluster, installare tutti i pacchetti richiesti per eseguire l'ipervisore KVM e il toolkit libvirt come descritto in https://www.suse.com/documentation/sles-15/

book_virt/data/sec_vt_installation_kvm.html .

3. Sul primo nodo del cluster, creare una nuova macchina virtuale (VM) KVM utilizzan- do libvirt come descritto in https://www.suse.com/documentation/sles-15/book_virt/da- ta/sec_libvirt_inst_vmm.html . Utilizzare lo storage condiviso preconfigurato per memo- rizzare le immagini del disco della VM.

4. Al termine della configurazione della VM, esportarne la configurazione su un file XML sullo storage condiviso. Usare la seguente sintassi:

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

5. Creare una risorsa per la VM del nodo admin. Per informazioni generali sulla crea- zione di risorse HA, consultare https://www.suse.com/documentation/sle-ha-15/book_sle- ha_guide/data/cha_conf_hawk2.html . All'indirizzo http://www.linux-ha.org/wiki/VirtualDo- main_%28resource_agent%29 sono disponibili informazioni dettagliate sulla creazione di risorse per una macchina virtuale KVM.

6. Sul guest VM appena creato, distribuire il nodo admin compresi i servizi aggiuntivi neces- sari. Seguire la procedura pertinente indicata nella Sezione 5.3, «Distribuzione del cluster». Contemporaneamente, distribuire i restanti nodi del cluster Ceph sui server del cluster non HA.

4 Privilegi utente e prompt dei comandi

Gli amministratori del cluster Ceph si occupano della configurazione e della modifica del com- portamento del cluster tramite l'esecuzione di comandi specifici. Saranno necessari diversi tipi di comandi:

4.1 Comandi correlati a Salt/DeepSea

Questi comandi consentono di distribuire o sottoporre ad upgrade il cluster Ceph, di eseguire comandi in contemporanea su più (o su tutti i) nodi del cluster e semplificano l'aggiunta o la rimozione dei nodi del cluster. I comandi più utilizzati sono salt, salt-run e deepsea. È necessario eseguire i comandi Salt sul nodo del Salt master (consultare questo riferimento:

Sezione 5.2, «Introduzione a DeepSea» per i dettagli) come root. Questi comandi sono introdotti dal prompt seguente:

root@master #

Ad esempio:

root@master # salt '*.example.net' test.ping

4.2 Comandi correlati a Ceph

Di seguito sono riportati i comandi di livello inferiore utilizzati per configurare e ottimizzare tutti gli aspetti del cluster e i relativi gateway sulla riga di comando. Alcuni di questi sono ceph,

rbd, radosgw-admin o crushtool.

Per eseguire i comandi correlati a Ceph, è necessario disporre dell'accesso in lettura a una chiave Ceph. Le capacità della chiave definiscono i privilegi dell'utente all'interno dell'ambiente Ceph.

Un'opzione consiste nell'eseguire i comandi di Ceph come root (o tramite sudo) e utilizzare il portachiavi di default senza restrizioni "ceph.client.admin.key".

L'opzione consigliata e più sicura consiste nel creare una chiave individuale più restrittiva per ogni utente amministratore e inserirla in una directory in cui gli utenti possano leggerla, ad esempio:

Suggerimento: percorso delle chiavi Ceph

Per utilizzare un utente amministratore e un portachiavi personalizzati, è necessario spe- cificare il nome utente e il percorso della chiave ogni volta che si esegue il comando ceph tramite le opzioni -n client.USER_NAME e --keyring PATH/TO/KEYRING.

Per evitare questa procedura, includere queste opzioni nella variabile CEPH_ARGS nei file

~/.bashrc dei singoli utenti.

I comandi correlati a Ceph possono essere eseguiti su qualsiasi nodo del cluster, ma è consiglia- bile eseguirli sul nodo admin. In questa documentazione, l'utente cephadm esegue i comandi, pertanto questi vengono introdotti dal prompt seguente:

cephadm@adm >

Ad esempio:

cephadm@adm > ceph auth list

Suggerimento: comandi per nodi specifici

Se nella documentazione è indicato di eseguire un comando su un nodo del cluster con un ruolo specifico, questo verrà indirizzato dal prompt. Ad esempio:

cephadm@mon >

4.3 Comandi Linux generali

I comandi Linux non correlati a Ceph o DeepSea, come mount, cat o openssl, sono introdotti dai prompt cephadm@adm > oppure root # a seconda dei privilegi richiesti dal comando correlato.

4.4 Informazioni aggiuntive

Per ulteriori informazioni sulla gestione della chiave Ceph, fare riferimento alla Libro «Guida all'amministrazione», Capitolo 8 «Autenticazione con _cephx», Sezione 8.2 «Gestione delle chiavi».

II Distribuzione e upgrade del cluster

5 Installazione con DeepSea/Salt 27 6 Upgrade dalle release precedenti ₆₁

7 Personalizzazione della configurazione di default ₉₀

5 Installazione con DeepSea/Salt

Salt insieme con DeepSea è uno stack di componenti che consentono di installare e gestire l'in- frastruttura del server, risultando scalabile, veloce e relativamente semplice da eseguire. Prima di avviare l'installazione del cluster con Salt, leggere le seguenti considerazioni:

I Salt minion sono i nodi controllati da un nodo dedicato denominato Salt master. I Salt minion hanno ruoli, ad esempio Ceph OSD, Ceph Monitor, Ceph Manager, Object Gateway, iSCSI Gateway o NFS Ganesha.

Un Salt master esegue il proprio Salt minion, richiesto per eseguire task privilegiati, ad esempio creazione, autorizzazione e copia di chiavi sui minion, in modo che i minion remoti non debbano mai eseguire task privilegiati.

Suggerimento: condivisione di più ruoli per server

È possibile ottenere le prestazioni migliori dal cluster Ceph quando ogni ruolo viene distribuito su un nodo separato. Le installazioni reali, tuttavia, a volte richiedono la condivisione di un nodo per più ruoli. Per evitare problemi di prestazioni e con la procedura di upgrade, non distribuire il ruolo Ceph OSD, del server di metadati o Ceph Monitor sul nodo admin.

I Salt minion devono risolvere correttamente il nome host del Salt master in rete. Per im- postazione predefinita, viene cercato il nome host salt, ma è possibile specificare altri nomi host individuabili in rete nel file /etc/salt/minion, vedere Sezione 5.3, «Distribu- zione del cluster».

5.1 Lettura delle note di rilascio

Nelle note di rilascio è possibile trovare informazioni aggiuntive sulle modifiche apportate ri- spetto alla release precedente di SUSE Enterprise Storage. Controllare le note di rilascio per vedere se:

l'hardware necessita di considerazioni speciali;

i pacchetti software utilizzati hanno subito modifiche significative;

è necessario adottare precauzioni speciali per l'installazione.

Le note di rilascio forniscono inoltre informazioni che non si è fatto in tempo a riportare nel manuale. Contengono anche alcune note su problemi noti.

Dopo aver installato il pacchetto release-notes-ses, individuare localmente le note di ri- lascio nella directory /usr/share/doc/release-notes o online all'indirizzo https://www.su- se.com/releasenotes/ .

5.2 Introduzione a DeepSea

DeepSea consente di far risparmiare tempo all'amministratore ed eseguire in sicurezza opera- zioni complesse su un cluster Ceph.

Ceph è una soluzione software altamente configurabile che aumenta la libertà e la responsabilità degli amministratori di sistema.

La configurazione minima di Ceph è ottima per scopi dimostrativi, ma non mostra le funzionalità interessanti di Ceph visibili con un alto numero di nodi.

DeepSea raccoglie e memorizza i dati sui singoli server, ad esempio indirizzi e nomi dei dispo- sitivi. Per un sistema di storage distribuito come Ceph, possono esistere centinaia di tali voci da raccogliere e memorizzare. La raccolta delle informazioni e l'immissione manuale dei dati in uno strumento di gestione della configurazione è un'operazione complessa in cui è facile fare degli errori.

I passaggi necessari per preparare i server, raccogliere la configurazione, configurare e distri- buire Ceph sono quasi uguali. Tuttavia, ciò non riguarda la gestione di funzioni separate. Per le operazioni giornaliere, è richiesta la capacità di aggiungere hardware a una data funzione e rimuoverlo senza problemi.

DeepSea gestisce queste osservazioni con la seguente strategia: DeepSea consolida le decisioni dell'amministratore in un singolo file. Le decisioni comprendono assegnazione del cluster, asse- gnazione del ruolo e assegnazione del profilo, mentre DeepSea raccoglie ciascun insieme di task in un semplice obiettivo. Ogni obiettivo è una fase:

DESCRIZIONE DELLE FASI DI DEEPSEA

Fase 0, la preparazione, durante questa fase, vengono applicati tutti gli aggiornamenti richiesti e il sistema potrebbe riavviarsi.

Importante: nuova esecuzione della fase 0 dopo il riavvio del nodo admin

Se, durante la fase 0, il nodo admin si riavvia per caricare la nuova versione del kernel, occorre eseguire di nuovo la fase 0, in caso contrario i minion non vengono indirizzati.

Fase 1, la rilevazione, viene rilevato tutto l'hardware nel cluster e vengono raccolte le informazioni necessarie per la configurazione Ceph. Per informazioni sulla configurazione, consultare Sezione 5.5, «Configurazione e personalizzazione».

Fase 2, la configurazione, è necessario preparare i dati di configurazione in un formato particolare.

Fase 3, l'installazione, crea un cluster Ceph di base con i servizi Ceph obbligatori. Per l'elenco, vedere Sezione 1.2.3, «Daemon e nodi Ceph».

Fase 4, i servizi, in questa fase è possibile installare funzionalità aggiuntive di Ceph come iSCSI, Object Gateway e CephFS. Sono tutte opzionali.

Fase 5, la fase di rimozione. Questa fase non è obbligatoria e durante la configurazione iniziale non è in genere necessaria. In questa fase vengono rimossi i ruoli dei minion e anche la configurazione del cluster. È necessario eseguire questa fase quando occorre ri- muovere un nodo di storage dal cluster. Per ulteriori informazioni, vedere la Libro «Guida all'amministrazione», Capitolo 2 «Amministrazione di Salt Cluster», Sezione 2.3 «Rimozione e rein- stallazione dei nodi del cluster».

5.2.1 Organizzazione e ubicazioni importanti

Salt dispone di diverse ubicazioni standard e diverse convenzioni di assegnazione del nome utilizzate sul nodo master:

/srv/pillar

La directory memorizza i dati di configurazione per i minion del cluster. Pillar è un'inter- faccia che fornisce valori di configurazione globali a tutti i minion del cluster.

/srv/salt/

La directory memorizza i file di stato di Salt (denominati anche file sls). I file di stato sono descrizioni formattate di stati in cui deve trovarsi il cluster.

/srv/module/runners

La directory memorizza script Python noti come runner. I runner vengono eseguiti sul nodo master.

/srv/salt/_modules

La directory memorizza gli script Python denominati moduli. I moduli vengono applicati a tutti i minion nel cluster.

/srv/pillar/ceph

La directory è utilizzata da DeepSea. I dati della configurazione raccolti vengono memo- rizzati qui.

/srv/salt/ceph

Una directory utilizzata da DeepSea. Memorizza i file sls che possono essere in formati diversi, ma ogni sottodirectory contiene file sls. Ciascuna sottodirectory contiene solo un tipo di file sls. Ad esempio, /srv/salt/ceph/stage contiene i file di orchestrazione ese- guiti da salt-run state.orchestrate.

5.2.2 Indirizzamento dei minion

I comandi DeepSea vengono eseguiti tramite l'infrastruttura Salt. Quando si utilizza il comando salt, occorre specificare un insieme di Salt minion interessati dal comando. L'insieme dei mi- nion viene descritto come destinazione per il comando salt. Le sezioni seguenti descrivono i possibili metodi di individuare i minion.

5.2.2.1 Corrispondenza del nome del minion

È possibile individuare un minion o un gruppo di minion tramite corrispondenza dei nomi. Il nome di un minion è in genere il nome host breve del nodo in cui viene eseguito il minion.

Questo è in genere un metodo di indirizzamento Salt, non correlato a DeepSea. Per limitare il campo dei nomi di minion, è possibile utilizzare caratteri jolly, espressioni regolari o elenchi.

Segue la sintassi generica:

Suggerimento: cluster solo Ceph

Se tutti i Salt minion nell'ambiente appartengono al cluster Ceph, è possibile sostituire in sicurezza target con "*" per includere tutti i minion registrati.

Far corrispondere tutti i minion nel dominio example.net (supponendo che i nomi dei minion siano identici ai loro nomi host "completi"):

root@master # salt '*.example.net' test.ping

Far corrispondere i minion da "web1" a "web5":

root@master # salt 'web[1-5]' test.ping

Far corrispondere i minion "web1-prod" e "web1-devel" utilizzando un'espressione regolare:

root@master # salt -E 'web1-(prod|devel)' test.ping

Far corrispondere un semplice elenco di minion:

root@master # salt -L 'web1,web2,web3' test.ping

Far corrispondere tutti i minion nel cluster:

root@master # salt '*' test.ping

5.2.2.2 Indirizzamento con un grain DeepSea

In un ambiente eterogeneo gestito da Salt in cui SUSE Enterprise Storage 6 è distribuito su un sottoinsieme di nodi insieme ad altre soluzioni cluster, è necessario contrassegnare i minion pertinenti applicandovi un grain "deepsea" prima di eseguire la fase 0 di DeepSea. In questo modo è possibile indirizzare con facilità i minion DeepSea negli ambienti dove è problematica la corrispondenza del nome.

Per applicare il grain "deepsea" a un gruppo di minion, eseguire:

root@master # salt target grains.append deepsea default

Per rimuovere il grain "deepsea" da un gruppo di minion, eseguire:

root@master # salt target grains.delval deepsea destructive=True

Dopo aver applicato il grain "deepsea" ai minion pertinenti, è possibile individuarli come segue:

root@master # salt -G 'deepsea:*' test.ping

Il comando seguente è un equivalente:

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 Impostare l'opzione

L'impostazione della destinazione dell'opzione deepsea_minions è un requisito per le distribu- zioni di DeepSea. DeepSea la utilizza per istruire i minion durante l'esecuzione delle fasi (per i dettagli, fare riferimento a Descrizione delle fasi di DeepSea).

Per impostare o modificare l'opzione deepsea_minions, modificare il file /srv/pillar/ce- ph/deepsea_minions.sls sul Salt master e aggiungere o sostituire la riga seguente:

deepsea_minions: target

Suggerimento: destinazione deepsea_minions

Come target per l'opzione deepsea_minions, è possibile utilizzare uno dei metodi di indirizzamento: Corrispondenza del nome del minion e Indirizzamento con un grain DeepSea. Far corrispondere tutti i minion Salt nel cluster:

deepsea_minions: '*'

Far corrispondere tutti i minion con il grain "deepsea":

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Ulteriori informazioni

È possibile utilizzare metodi più avanzati per l'indirizzamento dei minion mediante l'infrastrut- tura Salt. La pagina della documentazione "deepsea-minions" fornisce ulteriori dettagli sull'in- dirizzamento di DeepSea (man 7 deepsea_minions).

5.3 Distribuzione del cluster

Il processo di distribuzione del cluster comprende fasi diverse. Primo, occorre preparare tutti i nodi del cluster configurando Salt, quindi distribuire e configurare Ceph.

Suggerimento: distribuzione dei nodi monitor senza definire profili OSD

Se occorre ignorare la definizione dei ruoli di storage per OSD come descritto nella ^Sezio- ne 5.5.1.2, «Assegnazione ruolo» e distribuire prima i nodi Ceph Monitor, è possibile farlo impostando la variabile DEV_ENV

che consente di distribuire i monitor senza la presenza della directory role-storage/, oltre a distribuire un cluster Ceph con almeno un ruolo storage, monitor e manager.

Per impostare la variabile ambientale, abilitarla globalmente nel file /srv/pillar/ce- ph/stack/global.yml, oppure impostarla solo per la sessione di shell corrente:

root@master # export DEV_ENV=true

Ad esempio, è possibile creare /srv/pillar/ceph/stack/global.yml con i contenuti seguenti:

DEV_ENV: True

La procedura seguente descrive la preparazione del cluster in modo dettagliato.

1. Installare e registrare SUSE Linux Enterprise Server 15 SP1 insieme con l'estensione SUSE Enterprise Storage 6 in ciascun nodo del cluster.

2. Verificare che i prodotti corretti siano installati e registrati elencando i repository software esistenti. Eseguire zypper lr -E e confrontare l'output con l'elenco seguente:

SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates

SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool

SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates

3. Configurare le impostazioni di rete compresa la risoluzione del nome DNS corretto su ogni nodo. Il Salt master e tutti i Salt minion devono risolvere ciascuno mediante i loro nomi host. Per ulteriori informazioni sulla configurazione di una rete, vedere https://www.su-