Installare e registrare SUSE Linux Enterprise Server 12 SP3 insieme con SUSE Enterprise Storage extension su ciascun nodo del cluster.

Verificare che i prodotti corretti siano installati e registrati elencando i repository software esistenti. L'elenco sarà simile a questo:

 root@minion > zypper lr -E
#  | Alias   | Name                              | Enabled | GPG Check | Refresh
---+---------+-----------------------------------+---------+-----------+--------
 4 | [...]   | SUSE-Enterprise-Storage-5-Pool    | Yes     | (r ) Yes  | No
 6 | [...]   | SUSE-Enterprise-Storage-5-Updates | Yes     | (r ) Yes  | Yes
 9 | [...]   | SLES12-SP3-Pool                   | Yes     | (r ) Yes  | No
11 | [...]   | SLES12-SP3-Updates                | Yes     | (r ) Yes  | Yes

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.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_yast.html. Per ulteriori informazioni sulla configurazione di un server DNS, vedere https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_dns.html.

Configurare, attivare e avviare il server di sincronizzazione dell'ora NTP:

root@master # systemctl enable ntpd.service
root@master # systemctl start ntpd.service

Ulteriori informazioni sulla configurazione di NTP sono disponibili in https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_netz_xntp_yast.html.

Verificare che il servizio AppArmor sia in esecuzione e disattivarlo su ciascun nodo cluster. Avviare il modulo YaST AppArmor e selezionare Settings (Impostazioni) quindi deselezionare la casella di controllo Enable Apparmor (Abilita Apparmor). Confermare con Done (Fine).

Tenere presente che SUSE Enterprise Storage non funziona con AppArmor attivato.

Installare i pacchetti salt-master e salt-minion sul nodo Salt master:

root@master # zypper in salt-master salt-minion

Verificare che il servizio salt-master sia abilitato e avviato, se necessario abilitarlo e avviarlo:

root@master # systemctl enable salt-master.service
root@master # systemctl start salt-master.service

Se si intende utilizzare il firewall, verificare che il nodo master abbia le porte 4505 e 4506 aperte per tutti i nodi Salt minion. Se le porte sono chiuse, è possibile aprirle con il comando yast2 firewall consentendo il servizio SaltStack.

Avviso: le fasi di DeepSea non riescono con il firewall

Le fasi di installazione di DeepSea non riescono se il firewall è attivo (e anche configurato). Per eseguire le fasi correttamente, occorre disattivare il firewall eseguendo

root@master # systemctl stop SuSEfirewall2.service

oppure impostare l'opzione FAIL_ON_WARNING su "False" in /srv/pillar/ceph/stack/global.yml:

FAIL_ON_WARNING: False

Installare il pacchetto salt-minion su tutti i nodi minion.

root@minion > zypper in salt-minion

Accertare che il nome di dominio qualificato completo di ciascun nodo possa essere risolto sull'indirizzo IP della rete pubblica da tutti gli altri nodi.

Configurare tutti i minion (compreso il minion master) per il collegamento al master. Se il Salt master non è raggiungibile dal nome host salt, modificare il file /etc/salt/minion oppure creare un nuovo file /etc/salt/minion.d/master.conf con il seguente contenuto:

master: host_name_of_salt_master

Se sono state apportate modifiche ai file di configurazione menzionati sopra, riavviare il servizio Salt su tutti i Salt minion:

root@minion > systemctl restart salt-minion.service

Verificare che il servizio salt-minion sia abilitato e avviato su tutti i nodi. Abilitarlo e avviarlo se necessario:

root@minion > systemctl enable salt-minion.service
root@minion > systemctl start salt-minion.service

Verificare ogni impronta del Salt minion e accettare tutte le chiavi salt sul Salt master se le impronte corrispondono.

Visualizzare l'impronta di ogni minion:

root@minion > salt-call --local key.finger
local:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Dopo aver raccolto le impronte di tutti i Salt minion, elencare le impronte di tutte le chiavi minion non accettate sul Salt master:

root@master # salt-key -F
[...]
Unaccepted Keys:
minion1:
3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Se le impronte dei minion corrispondono, accettarle:

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

Verificare che le chiavi siano state accettate:

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

Prima di distribuire SUSE Enterprise Storage, accertare che tutti i dischi utilizzati come OSD dai cluster precedenti siano vuoti senza partizioni. Per accertarlo, occorre cancellare manualmente tutti i dischi. Ricordare di sostituire "X" con la lettera corretta del disco:

1. Interrompere tutti i processi che utilizzano il disco specifico.

2. Verificare se eventuali partizioni sul disco sono montate e smontare se necessario.

3. Se il disco è gestito da LVM, disattivare ed eliminare l'intera infrastruttura LVM. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-12/stor_admin/data/cha_lvm.html.

4. Se il disco fa parte di MD RAID, disattivare RAID. Per ulteriori dettagli, fare riferimento a https://www.suse.com/documentation/sles-12/stor_admin/data/part_software_raid.html.

5. 

   Suggerimento: riavvio del server

   Se si ricevono messaggi di errore come "partition in use" o "kernel can not be updated with the new partition table" nelle fasi seguenti, riavviare il server.

   Cancellare l'inizio di ogni partizione:

   for partition in /dev/sdX[0-9]*
   do
     dd if=/dev/zero of=$partition bs=4096 count=1 oflag=direct
   done

6. Cancellare la tabella di partizione:

   sgdisk -Z --clear -g /dev/sdX

7. Cancellare le tabelle di partizione di backup:

   size=`blockdev --getsz /dev/sdX`
   position=$((size/4096 - 33))
   dd if=/dev/zero of=/dev/sdX bs=4M count=33 seek=$position oflag=direct

Installare DeepSea sul nodo Salt master:

root@master # zypper in deepsea

Verificare che il file /srv/pillar/ceph/master_minion.sls sul Salt master punti al Salt master. Se il Salt master è raggiungibile tramite più nomi host, utilizzare quello idoneo per il cluster di storage. Se è stato utilizzato il nome host predefinito per il Salt master, salt, nel dominio ses, l'aspetto del file è:

master_minion: salt.ses

Includere i Salt minion appartenenti al cluster Ceph in corso di installazione. Per ulteriori informazioni sull'indirizzamento dei minion, consultare Sezione 4.2.2.1, «Corrispondenza del nome del minion».

Preparare il cluster. Per ulteriori dettagli, fare riferimento a Descrizione delle fasi di DeepSea.

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

oppure

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

Nota: eseguire o monitorare le fasi con DeepSea CLI

Con DeepSea CLI, è possibile seguire l'avanzamento dell'esecuzione delle fasi in tempo reale, eseguendo DeepSea CLI nella modalità di monitoraggio o eseguendo la fase direttamente tramite DeepSea CLI. Per ulteriori informazioni, vedere la Sezione 4.4, «DeepSea CLI».

Facoltativo: creare sotto volumi Btrfs per /var/lib/ceph/. Questa fase deve essere eseguita solo prima di eseguire le fasi successive di DeepSea. Per la migrazione delle directory esistenti o per ulteriori informazioni, vedere Sezione 18.5, «Sottovolume Btrfs per /var/lib/ceph».

root@master # salt-run state.orch ceph.migrate.subvolume

La fase di rilevamento raccoglie i dati da tutti i minion e crea frammenti di configurazione memorizzati nella directory /srv/pillar/ceph/proposals. I dati sono memorizzati nel formato YAML nei file *.sls o *.yml.

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

oppure

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

Dopo il corretto completamento di un comando, creare un file policy.cfg in /srv/pillar/ceph/proposals. Per ulteriori informazioni, vedere la Sezione 4.5.1, «Il file policy.cfg».

Suggerimento

Se occorre modificare l'impostazione di rete del cluster, modificare /srv/pillar/ceph/stack/ceph/cluster.yml e modificare le righe che iniziano con cluster_network: e public_network:.

La fase di configurazione analizza il file policy.cfg e unisce i file inclusi nella forma finale. Il contenuto relativo a cluster e ruolo viene posto in /srv/pillar/ceph/cluster, mentre il contenuto specifico di Ceph in /srv/pillar/ceph/stack/default.

Per attivare la fase di configurazione, eseguire il comando seguente:

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

oppure

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

La fase di configurazione può richiedere diversi secondi. Al completamento del comando, è possibile visualizzare i dati di Pillar per i minion specificati (ad esempio, denominati ceph_minion1, ceph_minion2, ecc.) eseguendo:

root@master # salt 'ceph_minion*' pillar.items

Nota: sovrascrittura dei default

Non appena il comando viene completato, è possibile visualizzare la configurazione di default e modificarla in base alle esigenze. Per ulteriori informazioni, vedere la Capitolo 7, Personalizzazione della configurazione di default.

Ora è possibile eseguire la fase di installazione. In questa fase, il Pillar viene convalidato e i monitor e daemon ODS vengono avviati sui nodi di storage. Per avviare la fase, eseguire il comando di seguito:

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

oppure

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

Il comando può richiedere alcuni minuti. In caso di errore, risolvere il problema ed eseguire di nuovo le fasi precedenti. Al corretto completamento del comando, eseguire questo comando per verificare lo stato:

root@master # ceph -s

L'ultima fase dell'installazione del cluster Ceph è quella dei servizi. Qui è possibile istanziare uno dei servizi correntemente supportati: iSCSI Gateway, CephFS, Object Gateway, openATTIC e NFS Ganesha. In questa fase, vengono creati i pool necessari, i portachiavi di autorizzazione e i servizi di avvio. Per avviare la fase, eseguire il comando:

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

oppure

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

In base alla configurazione, l'esecuzione del comando può richiedere vari minuti.