Saltar al contenutoSaltar alla navigazione delle pagine: pagina precedente [chiave d’accesso p]/pagina successiva [chiave d’accesso n]
Si applica a SUSE Enterprise Storage 6

25 Suggerimenti

In questo capito sono fornite le informazioni necessarie per migliorare le prestazioni del cluster Ceph e vengono forniti i suggerimenti su come impostare il cluster.

25.1 Identificazione delle partizioni orfane

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 utilizzando il proprio comando preferito (ad esempio, fdisk, parted o sgdisk).

25.2 Regolazione della pulitura

Per default, Ceph esegue la pulitura leggera giornaliera (ulteriori dettagli sono disponibili nella Sezione 9.6, «Pulitura») e la pulitura approfondita settimanale. Con la pulitura leggera vengono verificati le dimensioni e i checksum degli oggetti per assicurare che i gruppi di posizionamento memorizzino gli stessi dati oggetto. Con la pulitura approfondita viene verificato il contenuto di un oggetto con quello delle rispettive repliche per assicurare che i contenuti effettivi siano gli stessi. Il prezzo per la verifica dell'integrità dei dati è un carico I/O maggiore sul cluster durante la procedura di pulitura.

Le impostazioni di default consentono ai Ceph OSD di iniziare la pulitura in momenti inappropriati, ad esempio durante i periodi di carichi pesanti. I clienti possono riscontrare latenza e prestazioni scarse quando le operazioni di pulitura sono in conflitto con le rispettive operazioni. In Ceph sono disponibili diverse impostazioni di pulitura che possono limitare la pulitura a periodi con carichi inferiori o durante le ore non di punta.

Se il cluster riscontra carichi elevati durante il giorno e carichi bassi durante la notte, considerare di limitare la pulitura alle ore notturne, ad esempio dalle 23.00 alle 06.00:

[osd]
osd_scrub_begin_hour = 23
osd_scrub_end_hour = 6

Se la restrizione dell'orario non è un metodo efficace per determinare la pianificazione di una pulitura, considerare di utilizzare l'opzione osd_scrub_load_threshold. Il valore di default è 0,5, ma è possibile modificarlo per condizioni di carico inferiore:

[osd]
osd_scrub_load_threshold = 0.25

25.3 Interruzione degli OSD senza ribilanciamento

Potrebbe essere necessario interrompere gli OSD per la manutenzione periodica. Se non si desidera che CRUSH esegua automaticamente il ribilanciamento del cluster in modo da evitare il trasferimento di grandi quantità di dati, prima impostare il cluster su noout:

root@minion > ceph osd set noout

Quando il cluster è impostato su noout, è possibile iniziare a interrompere gli OSD nel dominio di errore per il quale è richiesta la manutenzione:

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

Per ulteriori informazioni, vedere Sezione 5.1.2, «Avvio, interruzione e riavvio di servizi individuali».

Una volta completata la manutenzione, avviare di nuovo gli OSD:

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

Dopo l'avvio dei servizi OSD, annullare l'impostazione noout:

cephadm@adm > ceph osd unset noout

25.4 Sincronizzazione dell'orario dei nodi

Ceph richiede la sincronizzazione precisa dell'orario tra tutti i nodi.

Si consiglia di sincronizzare tutti i nodi del cluster Ceph con almeno tre origini dell'orario attendibili ubicate nella rete interna. Le origini dell'orario interne possono puntare a un server dell'orario pubblico o disporre di una propria origine dell'orario.

Importante
Importante: server dell'orario pubblici

Non sincronizzare tutti i nodi del cluster Ceph direttamente con i server dell'orario pubblici. Con tale configurazione, ciascun nodo del cluster dispone di un daemon NTP proprio che comunica continuamente su Internet con un set di tre o quattro server dell'orario che possono fornire orari leggermente diversi. Questa soluzione comporta un alto grado di variabilità della latenza, per cui è difficile, se non impossibile, mantenere l'orologio in moto al di sotto di 0,05 secondi (che è il valore richiesto dai Ceph Monitor).

Per informazioni dettagliate su come configurare il server NTP, fare riferimento a SUSE Linux Enterprise Server Administration Guide (in lingua inglese).

Quindi, per modificare l'orario sul cluster, eseguire quanto riportato di seguito:

Importante
Importante: impostazione dell'orario

Talvolta potrebbe essere necessario impostare indietro l'ora, ad esempio nel passaggio dall'ora legale all'ora solare. Non è consigliato spostare indietro l'ora per un periodo più lungo di quello di inattività del cluster. Lo spostamento dell'ora in avanti non causa alcun problema.

Procedura 25.1: Sincronizzazione dell'orario sul cluster
  1. Interrompere tutti i client che accedono al cluster Ceph, soprattutto quelli che utilizzano iSCSI.

  2. Spegnere il cluster Ceph. Su ciascun nodo eseguire:

    root # systemctl stop ceph.target
    Nota
    Nota

    Se si utilizzano Ceph e SUSE OpenStack Cloud, interrompere anche SUSE OpenStack Cloud.

  3. Verificare che il server NTP sia configurato correttamente: l'ora di tutti i daemon chronyd è ricavata da una o più origini nella rete locale.

  4. Impostare l'ora corretta sul server NTP.

  5. Verificare che NTP sia in esecuzione e funzioni correttamente, quindi eseguire su tutti i nodi:

    root # systemctl status chronyd.service
  6. Avviare tutti i nodi di monitoraggio e verificare che non vi siano sfasamenti di orario:

    root # systemctl start target
  7. Avviare tutti i nodi OSD.

  8. Avviare altri servizi Ceph.

  9. Avviare SUSE OpenStack Cloud se disponibile.

25.5 Verifica della scrittura dati non bilanciata

Quando i dati vengono scritti negli OSD in modo uniforme, il cluster è considerato bilanciato. A ciascun OSD in un cluster viene assegnato il rispettivo peso. Il peso è un numero relativo e indica a Ceph la quantità di dati da scrivere nell'OSD correlato. Più alto è il peso, maggiore sarà la quantità di dati che vengono scritti. Se il peso di un OSD è pari a zero, non verranno scritti dati al suo interno. Se il peso di un OSD è relativamente alto rispetto ad altri OSD, in esso verrà scritta una grande porzione di dati causando uno sbilanciamento del cluster.

I cluster non bilanciati hanno prestazioni scarse e nel caso in cui un OSD dal peso elevato si blocchi improvvisamente, è necessario spostare una gran quantità di dati in altri OSD, con un conseguente rallentamento del cluster.

Per evitare tale problema, è necessario verificare regolarmente la quantità di dati scritti negli OSD. Se la quantità è compresa tra il 30 e il 50% della capacità di un gruppo di OSD specificato da un determinato set di regole, è necessario pesare di nuovo gli OSD. Verificare la presenta di dischi individuali e scoprire quali si riempiono più velocemente degli altri (o generalmente sono più lenti) e ridurne il peso. La stessa cosa vale per gli OSD in cui la quantità di dati scritti è insufficiente: è possibile aumentarne il peso in modo che Ceph scriva in essi una quantità maggiore di dati. Nell'esempio seguente, si individuerà il peso di un OSD con ID 13, che verrà modificato da 3 a 3,05:

$ ceph osd tree | grep osd.13
 13  3                   osd.13  up  1

 $ ceph osd crush reweight osd.13 3.05
 reweighted item id 13 name 'osd.13' to 3.05 in crush map

 $ ceph osd tree | grep osd.13
 13  3.05                osd.13  up  1
Suggerimento
Suggerimento: nuovo peso dell'OSD in base all'utilizzo

Il comando ceph osd reweight-by-utilization threshold consente di automatizzare il processo di riduzione del peso degli OSD utilizzati eccessivamente. Per default i pesi saranno arrotondati per difetto negli OSD che raggiungono il 120% di utilizzo medio, ma se si include la soglia verrà utilizzata invece tale percentuale.

25.6 Sottovolume Btrfs per /var/lib/ceph sui nodi Ceph Monitor

Per default SUSE Linux Enterprise è installato in una partizione Btrfs. I Ceph Monitor memorizzano stato e database nella directory /var/lib/ceph. Per impedire che i Ceph Monitor vengano danneggiati da un rollback di sistema di una snapshot precedente, creare un sottovolume Btrfs per /var/lib/ceph. Un sottovolume dedicato esclude i dati dei monitor dalle snapshot del sottovolume radice.

Suggerimento
Suggerimento

Creare il sottovolume /var/lib/ceph prima di eseguire la fase 0 di DeepSea, poiché quest'ultima prevede l'installazione dei pacchetti relativi a Ceph e la creazione della directory /var/lib/ceph.

A questo punto, la fase 3 di DeepSea verifica se @/var/lib/ceph è un sottovolume Btrfs e non riesce se è una directory normale.

25.6.1 Requisiti

25.6.1.1 Distribuzione di nuovi elementi

Salt e DeepSea devono essere correttamente installati e in funzione.

25.6.1.2 Distribuzione di elementi esistenti

Se il cluster è già installato, occorre soddisfare i seguenti requisiti:

  • È stato eseguito l'upgrade dei nodi a SUSE Enterprise Storage 6 e il cluster è controllato da DeepSea.

  • Il cluster Ceph è attivo e integro.

  • Il processo di upgrade ha sincronizzato i moduli Salt e DeepSea in tutti i nodi minion.

25.6.2 Passaggi obbligatori per la distribuzione di un nuovo cluster

25.6.2.1 Prima di eseguire la fase 0 di DeepSea

Prima di eseguire la fase 0 di DeepSea, applicare i comandi seguenti a ciascuno dei Salt minion che diventeranno Ceph Monitor:

root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

Il comando ceph.subvolume consente di effettuare le operazioni seguenti:

  • Creare /var/lib/ceph come sottovolume Btrfs @/var/lib/ceph.

  • Montare il nuovo sottovolume e aggiornare /etc/fstab di conseguenza.

25.6.2.2 Errore di convalida della fase 3 di DeepSea

Se si dimentica di eseguire i comandi di cui alla Sezione 25.6.2.1, «Prima di eseguire la fase 0 di DeepSea» prima di eseguire la fase 0, la sottodirectory /var/lib/ceph è già esistente e causa un errore di convalida della fase 3 di DeepSea. Per trasformare la directory in un sottovolume, procedere come indicato di seguito:

  1. Modificare la directory in /ver/lib:

    cephadm@mon > cd /var/lib
  2. Effettuare il backup del contenuto della sottodirectory ceph:

    cephadm@mon > sudo mv ceph ceph-
  3. Creare il sottovolume, montarlo e aggiornare /etc/fstab:

    root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
  4. Andare alla sottodirectory di backup, sincronizzarne il contenuto con il nuovo sottovolume e rimuoverla:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-

25.6.3 Passaggi obbligatori per l'upgrade del cluster

In SUSE Enterprise Storage 5.5, la directory /var non si trova in un sottovolume Btrfs, ma le relative sottocartelle (come /var/log o /var/cache) sono sottovolumi Btrfs in "@". Per creare dei sottovolumi @/var/lib/ceph è necessario montare innanzitutto il sottovolume "@" (non montato per default) e crearvi all'interno il sottovolume @/var/lib/ceph.

Di seguito sono riportati dei comandi di esempio che illustrano la procedura:

root # mkdir -p /mnt/btrfs
root # mount -o subvol=@ ROOT_DEVICE /mnt/btrfs
root # btrfs subvolume create /mnt/btrfs/var/lib/ceph
root # umount /mnt/btrfs

A questo punto viene creato il sottovolume @/var/lib/ceph ed è possibile procedere come descritto nella Sezione 25.6.2, «Passaggi obbligatori per la distribuzione di un nuovo cluster».

25.6.4 Installazione manuale

La configurazione automatica del sottovolume Btrfs @/var/lib/ceph nei nodi di Ceph Monitor potrebbe non essere adatta a tutti gli scenari. Per eseguire la migrazione della directory /var/lib/ceph in un sottovolume @/var/lib/ceph, seguire i passaggi indicati di seguito:

  1. Terminare i processi Ceph in esecuzione.

  2. Smontare gli OSD sul nodo.

  3. Andare alla sottodirectory di backup, sincronizzarne il contenuto con il nuovo sottovolume e rimuoverla:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-
  4. Rimontare gli OSD.

  5. Riavviare i daemon Ceph.

25.6.5 Per ulteriori informazioni

Nel file /srv/salt/ceph/subvolume/README.md sul nodo Salt master, sono disponibili altri dettagli sulla configurazione manuale.

25.7 Aumento dei descrittori di file

Per i daemon OSD, le operazioni di lettura/scrittura sono critiche per mantenere bilanciato il cluster Ceph. Spesso sono richiesti numerosi file aperti per eseguire operazioni di lettura e scrittura contemporaneamente. A livello di sistema operativo, il numero massimo di file aperti simultaneamente è denominato "numero massimo di descrittori di file".

Per impedire che gli OSD esauriscano i descrittori di file, è possibile ignorare il valore di default del sistema operativo e specificare il numero in /etc/ceph/ceph.conf, ad esempio:

max_open_files = 131072

Dopo che si modifica max_open_files, è necessario riavviare il servizio OSD sul nodo Ceph pertinente.

25.8 Integrazione con il software di virtualizzazione

25.8.1 Memorizzazione dei dischi KVM nel cluster Ceph

È possibile creare un'immagine disco per la macchina virtuale basata su KVM, memorizzarla in un pool Ceph, convertire facoltativamente il contenuto di un'immagine esistente in tale immagine disco ed eseguire quindi la macchina virtuale con qemu-kvm utilizzando l'immagine disco memorizzata nel cluster. Per informazioni dettagliate, vedere Capitolo 24, Ceph come back-end per l'istanza QEMU KVM.

25.8.2 Memorizzazione dei dischi libvirt nel cluster Ceph

Analogamente a KVM (vedere Sezione 25.8.1, «Memorizzazione dei dischi KVM nel cluster Ceph»), è possibile utilizzare Ceph per memorizzare macchine virtuali basate su libvirt. Il vantaggio è dato dalla possibilità di eseguire qualsiasi soluzione di virtualizzazione supportata da libvirt, come KVM, Xen o LXC. Per ulteriori informazioni, consultare Capitolo 23, Utilizzo di libvirt con Ceph.

25.8.3 Memorizzazione dei dischi Xen nel cluster Ceph

Un modo per utilizzare Ceph per memorizzare i dischi Xen consiste nell'utilizzare libvirt come descritto in Capitolo 23, Utilizzo di libvirt con Ceph.

Un'altra opzione è di fare in modo che Xen comunichi direttamente con il driver del dispositivo di blocco rbd:

  1. Se non si dispone di alcuna immagine disco preparata per Xen, crearne una nuova:

    cephadm@adm > rbd create myimage --size 8000 --pool mypool
  2. Elencare le immagini nel pool mypool e verificare la presenza dell'immagine nuova al suo interno:

    cephadm@adm > rbd list mypool
  3. Creare un nuovo dispositivo di blocco mappando myimage al modulo kernel rbd:

    cephadm@adm > rbd map --pool mypool myimage
    Suggerimento
    Suggerimento: nome e autenticazione utente

    Per specificare un nome utente, utilizzare --id user-name. Inoltre, se si utilizza l'autenticazione cephx, è necessario specificare anche un segreto. Quest'ultimo potrebbe essere ricavato da un portachiavi o da un file contenente il segreto:

    cephadm@adm > rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    oppure

    cephadmrbd map --pool rbd myimage --id admin --keyfile /path/to/file
  4. Elencare tutti i dispositivi mappati:

    rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0
  5. Adesso è possibile configurare Xen per l'uso del dispositivo come disco per eseguire una macchina virtuale. Ad esempio, è possibile aggiungere la riga seguente al file di configurazione del dominio di stile xl:

    disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

25.9 Impostazioni firewall per Ceph

Avviso
Avviso: le fasi DeepSea si concludono con esito negativo 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 # systemctl stop SuSEfirewall2.service

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

FAIL_ON_WARNING: False

Si consiglia di proteggere le comunicazioni del cluster di rete con SUSE Firewall. È possibile modificarne la configurazione selezionando YaST › Security and Users (Sicurezza e utenti) › Firewall › Allowed Services (Servizi consentiti).

Di seguito è riportato un elenco di servizi correlati a Ceph e dei numeri di porte normalmente utilizzati da tali servizi:

Ceph Monitor

Abilitare il servizio Ceph MON o la porta 6789 (TCP).

Ceph OSD o Metadata Server

Abilitare il servizio Ceph OSD/MDS o le porte 6800-7300 (TCP).

iSCSI Gateway

Aprire la porta 3260 (TCP).

Object Gateway

Aprire la porta di comunicazione di Object Gateway. È impostato in /etc/ceph.conf alla riga che inizia con rgw frontends =. Il valore di default è 80 per HTTP e 443 per HTTPS (TCP).

NFS Ganesha

Per default, NFS Ganesha utilizza le porte 2049 (servizio NFS, TCP) e 875 (supporto rquota, TCP). Fare rifermento a Sezione 21.2.1.4, «Modifica delle porte NFS Ganesha di default» per ulteriori informazioni su come modificare le porte NFS Ganesha di default.

Servizi basati su Apache, come SMT o SUSE Manager

Aprire le porte 80 per HTTP e 443 per HTTPS (TCP).

SSH

Aprire la porta 22 (TCP).

NTP

Aprire la porta 123 (UDP).

Salt

Aprire le porte 4505 e 4506 (TCP).

Grafana

Aprire la porta 3000 (TCP).

Prometheus

Aprire la porta 9100 (TCP).

25.10 Test delle prestazioni della rete

Per testare le prestazioni della rete, nello strumento di esecuzione DeepSea net sono disponibili i seguenti comandi:

  • Ping semplice a tutti i nodi:

    root@master # salt-run net.ping
    Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
  • Ping enorme a tutti i nodi:

    root@master # salt-run net.jumbo_ping
    Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
  • Test della larghezza di banda:

    root@master # salt-run net.iperf
    Fastest 2 hosts:
        |_
          - 192.168.58.106
          - 2981 Mbits/sec
        |_
          - 192.168.58.107
          - 2967 Mbits/sec
    Slowest 2 hosts:
        |_
          - 192.168.58.102
          - 2857 Mbits/sec
        |_
          - 192.168.58.103
          - 2842 Mbits/sec
    Suggerimento
    Suggerimento: interruzione manuale dei processi "iperf3"

    Durante l'esecuzione di un test con lo strumento di esecuzione net.iperf, i processi del server "iperf3" già avviati non vengono interrotti automaticamente al completamento del test. Per interromperli, utilizzare lo strumento di esecuzione seguente:

    root@master # salt '*' multi.kill_iperf_cmd

25.11 Come individuare i dischi fisici tramite gli indicatori LED

Questa sezione descrive come utilizzare libstoragemgmt e/o gli strumenti di terze parti per regolare gli indicatori LED sui dischi fisici. Questa funzionalità potrebbe non essere disponibile per tutte le piattaforme hardware.

Creare delle corrispondenze tra un disco OSD e un disco fisico può essere complicato, specialmente sui nodi con un'elevata densità di dischi. In alcuni ambienti hardware sono presenti degli indicatori LED che è possibile regolare tramite software per fare in modo che lampeggino o si accendano in colori diversi per agevolare l'identificazione. SUSE Enterprise Storage supporta questa funzionalità tramite Salt, libstoragemgmt e strumenti di terze parti specifici dell'hardware in uso. La configurazione di tale funzionalità è definita in salt pillar /srv/pillar/ceph/disk_led.sls:

root #  cat /srv/pillar/ceph/disk_led.sls
# This is the default configuration for the storage enclosure LED blinking.
# The placeholder {device_file} will be replaced with the device file of
# the disk when the command is executed.
#
# Have a look into the /srv/pillar/ceph/README file to find out how to
# customize this configuration per minion/host.

disk_led:
  cmd:
    ident:
      'on': lsmcli local-disk-ident-led-on --path '{device_file}'
      'off': lsmcli local-disk-ident-led-off --path '{device_file}'
    fault:
      'on': lsmcli local-disk-fault-led-on --path '{device_file}'
      'off': lsmcli local-disk-fault-led-off --path '{device_file}'

La configurazione di default per disk_led.sls offre il supporto degli indicatori LED del disco tramite il livello libstoragemgmt. Tuttavia, libstoragemgmt supporta tale funzionalità tramite un plug-in specifico dell'hardware e strumenti di terze parti. Se il plug-in libstoragemgmt e gli strumenti di terze parti appropriati per l'hardware non sono stati installati, libstoragemgmt non sarà in grado di regolare gli indicatori LED.

Indipendentemente dalla presenza di libstoragemgmt, potrebbero essere necessari degli strumenti di terze parti per regolare gli indicatori LED. Tali strumenti di terze parti sono disponibili presso diversi fornitori hardware. Alcuni dei fornitori e strumenti più comuni sono:

Tabella 25.1: Strumenti di storage di terze parti
Fornitore/controller del discoStrumento
HPE SmartArrayhpssacli
LSI MegaRAIDstorcli

SUSE Linux Enterprise Server fornisce inoltre il pacchetto ledmon e lo strumento ledctl. Questo strumento può essere utile anche per gli ambienti hardware in cui sono utilizzati alloggiamenti di storage Intel. La sintassi corretta durante l'uso di questo strumento è la seguente:

root #  cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'
    fault:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'

Se si utilizza un hardware supportato, con tutti gli strumenti di terze parti richiesti, è possibile abilitare o disabilitare gli indicatori LED tramite la sintassi di comando seguente dal nodo Salt master:

root # salt-run disk_led.device NODE DISK fault|ident on|off

Ad esempio, per abilitare o disabilitare gli indicatori LED di identificazione o errore su /dev/sdd sul nodo OSDsrv16.ceph, eseguire quanto riportato di seguito:

root # salt-run disk_led.device srv16.ceph sdd ident on
root # salt-run disk_led.device srv16.ceph sdd ident off
root # salt-run disk_led.device srv16.ceph sdd fault on
root # salt-run disk_led.device srv16.ceph sdd fault off
Nota
Nota: denominazione dei dispositivi

Il nome del dispositivo utilizzato nel comando salt-run deve corrispondere al nome riconosciuto da Salt. È possibile utilizzare il comando seguente per visualizzare questi nomi:

root@master # salt 'minion_name' grains.get disks

In molti ambienti, la configurazione /srv/pillar/ceph/disk_led.sls richiederà delle modifiche per regolare gli indicatori LED in base alle esigenze hardware specifiche. È possibile apportare modifiche semplici sostituendo lsmcli con un altro strumento o modificando i parametri della riga di comando. È possibile apportare modifiche complesse richiamando uno script esterno al posto del comando lsmcli. Quando si apportano modifiche a /srv/pillar/ceph/disk_led.sls, seguire la procedura indicata di seguito:

  1. Apportare le modifiche richieste a /srv/pillar/ceph/disk_led.sls sul nodo Salt master.

  2. Verificare che le modifiche siano state applicate correttamente nei dati del Pillar:

    root # salt 'SALT MASTER*' pillar.get disk_led
  3. Aggiornare i dati del Pillar su tutti i nodi utilizzando:

    root # salt '*' saltutil.pillar_refresh

Tramite uno script esterno, è possibile utilizzare direttamente gli strumenti di terze parti per regolare gli indicatori LED. Gli esempi seguenti illustrano come regolare /srv/pillar/ceph/disk_led.sls per supportare uno script esterno e due script di esempio per gli ambienti HP e LSI.

/srv/pillar/ceph/disk_led.sls modificato che richiama uno script esterno:

root # cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off
    fault:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off

Script di esempio per indicatori LED lampeggianti su hardware HP tramite le utility hpssacli:

root # cat /usr/local/bin/flash_led_hp.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

FOUND=0
MAX_CTRLS=10
MAX_DISKS=50

for i in $(seq 0 $MAX_CTRLS); do
  # Search for valid controllers
  if hpssacli ctrl slot=$i show summary >/dev/null; then
    # Search all disks on the current controller
    for j in $(seq 0 $MAX_DISKS); do
      if hpssacli ctrl slot=$i ld $j show | grep -q $1; then
        FOUND=1
        echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2."
        hpssacli ctrl slot=$i ld $j modify led=$2
        break;
      fi
    done
    [[ "$FOUND" = "1" ]] && break
  fi
done

Script di esempio per indicatori LED lampeggianti su hardware LSI tramite le utility storcli:

root # cat /usr/local/bin/flash_led_lsi.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"

# Determine serial number for the disk
SERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')
if [ ! -z "$SERIAL" ]; then
  # Search for disk serial number across all controllers and enclosures
  DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}')
  if [ ! -z "$DEVICE" ]; then
    echo "Found $1 on device $DEVICE. Turning LED $2."
    /opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate
  else
    echo "Device not found!"
    exit -1
  fi
else
  echo "Disk serial number not found!"
  exit -1
fi
Stampa pagina