Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 6

25 Dicas e truques

O capítulo apresenta informações para ajudar você a melhorar o desempenho do cluster do Ceph e inclui dicas de como configurá-lo.

25.1 Identificando partições órfãs

Para identificar dispositivos de diário/WAL/BD possivelmente órfãos, siga estas etapas:

  1. Selecione o dispositivo que pode ter partições órfãs e grave a lista de suas partições em um arquivo:

    root@minion > ls /dev/sdd?* > /tmp/partitions
  2. Execute readlink em todos os dispositivos block.wal, block.db e de diário e compare a saída com a lista de partições que foi gravada:

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

    A saída é a lista de partições que não são usadas pelo Ceph.

  3. Remova as partições órfãs que não pertencem ao Ceph usando o comando de sua preferência (por exemplo, fdisk, parted ou sgdisk).

25.2 Ajustando a depuração

Por padrão, o Ceph executa uma depuração diária simples (encontre mais detalhes na Seção 9.6, “Depuração”) e uma depuração semanal em detalhes. A depuração simples verifica os tamanhos e os checksums dos objetos para garantir que os grupos de posicionamento estejam armazenando os mesmos dados dos objetos. A depuração em detalhes compara o conteúdo de um objeto com o de suas réplicas para garantir que o conteúdo real seja o mesmo. O ponto negativo da verificação de integridade de dados é uma carga de E/S maior no cluster durante o procedimento de depuração.

As configurações padrão permitem que os Ceph OSDs iniciem a depuração em horários inadequados. Por exemplo, durante os períodos de cargas elevadas. Os clientes podem enfrentar latência e baixo desempenho quando as operações de depuração entram em conflito com as operações deles. O Ceph dispõe de várias configurações de depuração que podem limitá-la a períodos com cargas menores ou fora dos horários de pico.

Se o cluster tem carga alta durante o dia e carga baixa à noite, considere restringir a depuração a horários noturnos, como das 23h às 6h:

[osd]
osd_scrub_begin_hour = 23
osd_scrub_end_hour = 6

Se a restrição de horário não for um método eficaz para determinar uma programação de depuração, considere usar a opção osd_scrub_load_threshold. O valor padrão é 0,5, mas ele pode ser modificado para condições de carga baixa:

[osd]
osd_scrub_load_threshold = 0.25

25.3 Parando os OSDs sem redistribuição

Você precisa parar os OSDs para manutenção periódica. Se você não deseja que o CRUSH redistribua automaticamente o cluster para evitar transferências grandes de dados, defina o cluster primeiro como noout:

root@minion > ceph osd set noout

Se o cluster estiver definido como noout, você poderá iniciar a interrupção dos OSDs no domínio de falha que requer o trabalho de manutenção:

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

Mais informações podem ser encontradas na Seção 5.1.2, “Iniciando, parando e reiniciando serviços individuais”.

Após concluir a manutenção, reinicie os OSDs:

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

Depois que os serviços do OSD forem iniciados, cancele a definição do cluster como noout:

cephadm@adm > ceph osd unset noout

25.4 Sincronização de horário dos nós

O Ceph requer uma sincronização de horário precisa entre todos os nós.

Recomendamos sincronizar todos os nós do cluster do Ceph com pelo menos três fontes de horário confiáveis localizadas na rede interna. As fontes de horário internas podem apontar para um servidor de horário público ou ter uma fonte de horário própria.

Importante
Importante: Servidores de Horário Públicos

Não sincronize todos os nós do cluster do Ceph diretamente com servidores de horário públicos remotos. Com essa configuração, cada nó no cluster tem seu próprio daemon NTP que se comunica continuamente pela Internet com um conjunto de três ou quatro servidores de horário que podem fornecer horários um pouco diferentes. Essa solução apresenta um alto grau de variação de latência que torna difícil ou impossível manter a diferença do relógio abaixo de 0,05 segundo, que é o valor exigido pelos Ceph Monitors.

Para obter detalhes sobre como configurar o servidor NTP, consulte o Guia de Administração do SUSE Linux Enterprise Server.

Em seguida, para mudar o horário no cluster, faça o seguinte:

Importante
Importante: Definição do Horário

Em algum momento, é provável que você tenha que reverter o horário. Por exemplo, em caso de mudança do horário de verão para o padrão. Não é recomendável retroceder o horário por um período maior do que o de inatividade do cluster. Avançar o horário não causa nenhum problema.

Procedimento 25.1: Sincronização de horário no cluster
  1. Pare todos os clientes que acessam o cluster do Ceph, principalmente aqueles que usam o iSCSI.

  2. Encerre o cluster do Ceph. Em cada nó, execute:

    root # systemctl stop ceph.target
    Nota
    Nota

    Se você usa o Ceph e o SUSE OpenStack Cloud, pare também o SUSE OpenStack Cloud.

  3. Verifique se o servidor NTP foi configurado corretamente: todos os daemons chronyd obtêm o horário de uma ou mais fontes na rede local.

  4. Defina o horário correto no servidor NTP.

  5. Verifique se o NTP está em execução e funcionando apropriadamente. Execute em todos os nós:

    root # systemctl status chronyd.service
  6. Inicie todos os nós de monitoramento e verifique se não há nenhum desvio de relógio:

    root # systemctl start target
  7. Inicie todos os nós OSD.

  8. Inicie os outros serviços do Ceph.

  9. Se você tiver, inicie o SUSE OpenStack Cloud.

25.5 Verificando a gravação de dados sem equilíbrio

Quando os dados são gravados nos OSDs igualmente, o cluster é considerado equilibrado. Cada OSD em um cluster recebe um peso. O peso é um número relativo que informa ao Ceph a quantidade de dados que devem ser gravados no OSD relacionado. Quanto maior o peso, mais dados serão gravados. Se um OSD tiver peso zero, não serão gravados dados nele. Se o peso de um OSD for relativamente alto em comparação com outros OSDs, uma grande parte dos dados será gravada nele, o que torna o cluster desequilibrado.

Os clusters desequilibrados apresentam baixo desempenho e, em caso de falha repentina de um OSD com peso elevado, muitos dados precisam ser movidos para outros OSDs, o que também torna o cluster mais lento.

Para evitar isso, você deve verificar regularmente a quantidade de dados gravados nos OSDs. Se o valor estiver entre 30% e 50% da capacidade de um grupo de OSDs especificada por determinado conjunto de regras, você precisará redefinir o peso dos OSDs. Verifique cada disco e descubra qual deles é preenchido mais rapidamente do que os outros (ou está mais lento no geral) e reduza o peso dele. O mesmo é válido para os OSDs em que não há dados suficientes gravados. Você pode aumentar o peso deles para o Ceph gravar mais dados neles. No exemplo a seguir, você descobrirá o peso de um OSD com ID 13 e redefinirá o peso de 3 para 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
Dica
Dica: Redefinição de Peso do OSD por Utilização

O comando ceph osd reweight-by-utilization threshold automatiza o processo de redução de peso dos OSDs que estão com excesso de uso. Por padrão, ele diminuirá os pesos dos OSDs que atingiram 120% de uso médio. Porém, se você incluir o comando threshold, ele usará essa porcentagem no lugar.

25.6 Subvolume Btrfs para /var/lib/ceph em nós do Ceph Monitor

Por padrão, o SUSE Linux Enterprise é instalado em uma partição Btrfs. Os Ceph Monitors armazenam o estado e o banco de dados deles no diretório /var/lib/ceph. Para evitar que um Ceph Monitor seja corrompido após o rollback de um sistema de um instantâneo anterior, crie um subvolume Btrfs para /var/lib/ceph. Um subvolume dedicado exclui os dados do monitor dos instantâneos do subvolume raiz.

Dica
Dica

Crie o subvolume /var/lib/ceph antes de executar a fase 0 do DeepSea, porque essa fase instala os pacotes relacionados do Ceph e cria o diretório /var/lib/ceph.

Em seguida, a fase 3 do DeepSea verifica se o @/var/lib/ceph é um subvolume Btrfs e falhará se for um diretório normal.

25.6.1 Requisitos

25.6.1.1 Novas implantações

O Salt e o DeepSea precisam estar instalados e funcionando apropriadamente.

25.6.1.2 Implantações existentes

Se o seu cluster já estiver instalado, os seguintes requisitos deverão ter sido atendidos:

  • O upgrade dos nós foi feito para o SUSE Enterprise Storage 6 e o cluster está sob controle do DeepSea.

  • O cluster do Ceph está funcionando e saudável.

  • O processo de upgrade sincronizou os módulos do Salt e do DeepSea com todos os nós do minion.

25.6.2 Etapas necessárias durante uma nova implantação de cluster

25.6.2.1 Antes de executar a fase 0 do DeepSea

Antes de executar a fase 0 do DeepSea, aplique os seguintes comandos a cada um dos minions Salt que se tornarão Ceph Monitors:

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

O comando ceph.subvolume faz o seguinte:

  • Cria o /var/lib/ceph como um subvolume Btrfs @/var/lib/ceph.

  • Monta o novo subvolume e atualiza o /etc/fstab apropriadamente.

25.6.2.2 Falha na validação da fase 3 do DeepSea

Se você se esqueceu de executar os comandos mencionados na Seção 25.6.2.1, “Antes de executar a fase 0 do DeepSea” antes de executar a fase 0, o subdiretório /var/lib/ceph já existe, o que causa uma falha na validação da fase 3 do DeepSea. Para convertê-lo em um subvolume, faça o seguinte:

  1. Mude o diretório para /var/lib:

    cephadm@mon > cd /var/lib
  2. Faça backup do conteúdo atual do subdiretório ceph:

    cephadm@mon > sudo mv ceph ceph-
  3. Crie o subvolume, monte-o e atualize o /etc/fstab:

    root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume
  4. Mude para o subdiretório de backup, sincronize o conteúdo dele com o novo subvolume e, em seguida, remova-o:

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

25.6.3 Etapas necessárias durante o upgrade do cluster

No SUSE Enterprise Storage 5.5, o diretório /var não está em um subvolume Btrfs, mas suas subpastas (como /var/log ou /var/cache) são subvolumes Btrfs abaixo de “@”. A criação dos subvolumes @/var/lib/ceph exige primeiro a montagem do subvolume “@” (ele não é montado por padrão) e a criação do subvolume @/var/lib/ceph abaixo dele.

Veja a seguir exemplos de comandos que ilustram o processo:

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

Neste ponto, o subvolume @/var/lib/ceph foi criado, e você pode continuar conforme descrito na Seção 25.6.2, “Etapas necessárias durante uma nova implantação de cluster”.

25.6.4 Configuração manual

A configuração automática do subvolume Btrfs @/var/lib/ceph nos nós do Ceph Monitor talvez não seja adequada para todos os cenários. É possível migrar o diretório /var/lib/ceph para um subvolume @/var/lib/ceph seguindo estas etapas:

  1. Termine os processos do Ceph em execução.

  2. Desmonte os OSDs no nó.

  3. Mude para o subdiretório de backup, sincronize o conteúdo dele com o novo subvolume e, em seguida, remova-o:

    cephadm@mon > cd /var/lib/ceph-
    cephadm@mon > rsync -av . ../ceph
    cephadm@mon > cd ..
    cephadm@mon > rm -rf ./ceph-
  4. Remonte os OSDs.

  5. Reinicie os daemons do Ceph.

25.6.5 Para obter mais informações

Encontre informações mais detalhadas sobre a configuração manual no arquivo /srv/salt/ceph/subvolume/README.md no nó master Salt.

25.7 Aumentando os descritores de arquivos

Para os daemons OSD, as operações de leitura/gravação são essenciais para manter o equilíbrio do cluster do Ceph. Geralmente, eles precisam ter muitos arquivos abertos para leitura e gravação ao mesmo tempo. No nível do OS, o número máximo de arquivos abertos ao mesmo tempo é chamado de “número máximo de descritores de arquivos”.

Para evitar que os OSDs fiquem sem descritores de arquivos, você pode anular o valor padrão do OS e especificar o número em /etc/ceph/ceph.conf. Por exemplo:

max_open_files = 131072

Após mudar o max_open_files, você precisará reiniciar o serviço do OSD no nó do Ceph relevante.

25.8 Integração com software de virtualização

25.8.1 Armazenando discos da KVM no cluster do Ceph

Você pode criar uma imagem de disco da máquina virtual controlada pela KVM, armazená-la em um pool do Ceph, opcionalmente, converter o conteúdo de uma imagem existente nela e, em seguida, executar a máquina virtual com qemu-kvm usando a imagem de disco armazenada no cluster. Para obter informações mais detalhadas, consulte o Capítulo 24, Ceph como back end para instância de KVM QEMU.

25.8.2 Armazenando discos da libvirt no cluster do Ceph

Similar à KVM (consulte a Seção 25.8.1, “Armazenando discos da KVM no cluster do Ceph”), você pode usar o Ceph para armazenar máquinas virtuais controladas pela libvirt. A vantagem é que você pode executar qualquer solução de virtualização compatível com libvirt, como KVM, Xen ou LXC. Para obter mais informações, consulte o Capítulo 23, Usando a libvirt com o Ceph.

25.8.3 Armazenando discos do Xen no cluster do Ceph

Uma forma de usar o Ceph para armazenar discos do Xen é usar a libvirt conforme descrito no Capítulo 23, Usando a libvirt com o Ceph.

Outra opção é fazer com que o Xen se comunique diretamente com o driver de dispositivo de blocos rbd:

  1. Se você não tem uma imagem de disco preparada para Xen, crie uma nova:

    cephadm@adm > rbd create myimage --size 8000 --pool mypool
  2. Liste as imagens no pool mypool e verifique se a nova imagem está lá:

    cephadm@adm > rbd list mypool
  3. Crie um novo dispositivo de blocos mapeando a imagem myimage para o módulo rbd do kernel:

    cephadm@adm > rbd map --pool mypool myimage
    Dica
    Dica: Nome e Autenticação de Usuário

    Para especificar um nome de usuário, utilize --id user-name. Além disso, se você usar a autenticação cephx, deverá também especificar um segredo. Ele pode vir de um chaveiro ou de um arquivo que contém o segredo:

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

    ou

    cephadmrbd map --pool rbd myimage --id admin --keyfile /path/to/file
  4. Liste todos os dispositivos mapeados:

    rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0
  5. Agora, você pode configurar o Xen para usar esse dispositivo como disco para executar uma máquina virtual. Por exemplo, você pode adicionar a seguinte linha ao arquivo de configuração de domínio no estilo xl:

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

25.9 Configurações de firewall para o Ceph

Atenção
Atenção: Falha nas Fases do DeepSea com Firewall

Há falha nas fases de implantação do DeepSea quando o firewall está ativo (e até configurado). Para percorrer as fases corretamente, você precisa desativar o firewall executando

root # systemctl stop SuSEfirewall2.service

ou definir a opção FAIL_ON_WARNING como “False” em /srv/pillar/ceph/stack/global.yml:

FAIL_ON_WARNING: False

É recomendável proteger a comunicação do cluster de rede com o SUSE Firewall. Você pode editar sua configuração selecionando YaST › Security and Users (Segurança e Usuários) › Firewall › Allowed Services (Serviços Permitidos).

Veja a seguir uma lista de serviços relacionados do Ceph e os números de porta que eles costumam usar:

Ceph Monitor

Habilitar o serviço Ceph MON ou a porta 6789 (TCP).

Ceph OSD ou Servidor de Metadados

Habilite o serviço Ceph OSD/MDS ou as portas 6800-7300 (TCP).

iSCSI Gateway

Porta 3260 aberta (TCP).

Object Gateway

Abrir a porta de comunicação do Object Gateway. Isso é definido no /etc/ceph.conf na linha que começa com rgw frontends =. O padrão é 80 para HTTP e 443 para HTTPS (TCP).

NFS Ganesha

Por padrão, o NFS Ganesha usa as portas 2049 (serviço NFS, TCP) e 875 (suporte a rquota, TCP). Consulte a Seção 21.2.1.4, “Mudando as portas padrão do NFS Ganesha” para obter mais informações sobre como mudar as portas padrão do NFS Ganesha.

Serviços com base no Apache, como SMT ou SUSE Manager

Portas abertas 80 para HTTP e 443 para HTTPS (TCP).

SSH

Porta 22 aberta (TCP).

NTP

Porta 123 aberta (UDP).

Salt

Portas 4505 e 4506 abertas (TCP).

Grafana

Porta 3000 aberta (TCP).

Prometheus

Porta 9100 aberta (TCP).

25.10 Testando o desempenho da rede

Para testar o desempenho da rede, o executor net do DeepSea oferece os comandos a seguir:

  • Um ping simples para todos os nós:

    root@master # salt-run net.ping
    Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
  • Um ping jumbo para todos os nós:

    root@master # salt-run net.jumbo_ping
    Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
  • Um teste de largura de 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
    Dica
    Dica: Interromper os Processos do “iperf3” Manualmente

    Ao executar um teste usando o executor net.iperf, os processos do servidor “iperf3” iniciados não são automaticamente interrompidos quando um teste é concluído. Para interromper os processos, use o seguinte executor:

    root@master # salt '*' multi.kill_iperf_cmd

25.11 Como localizar discos físicos que usam luzes de LED

Esta seção descreve como usar o libstoragemgmt e/ou ferramentas de terceiros para ajustar as luzes de LED nos discos físicos. Esse recurso pode não estar disponível para todas as plataformas de hardware.

Pode ser complexo corresponder um disco OSD a um disco físico, principalmente em nós com alta densidade de discos. Alguns ambientes de hardware incluem luzes de LED que podem ser ajustadas por meio de software para piscar ou acender uma cor diferente com a finalidade de identificação. O SUSE Enterprise Storage oferece suporte a esse recurso por meio do Salt, do libstoragemgmt e de ferramentas de terceiros específicas ao hardware em uso. A configuração para esse recurso está definida no pillar Salt /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}'

A configuração padrão para o disk_led.sls oferece suporte a LED de disco por meio da camada libstoragemgmt. No entanto, o libstoragemgmt fornece esse suporte por meio de um plug-in específico do hardware e de ferramentas de terceiros. Exceto se o plug-in libstoragemgmt e as ferramentas de terceiros apropriadas ao hardware estiverem instalados, o libstoragemgmt não poderá ajustar os LEDs.

Com ou sem o libstoragemgmt, as ferramentas de terceiros podem ser necessárias para ajustar as luzes de LED. Vários fornecedores de hardware disponibilizam essas ferramentas de terceiros. Alguns dos fornecedores e ferramentas comuns são:

Tabela 25.1: Ferramentas de Armazenamento de Terceiros
Fornecedor/Controladora de DiscoFerramenta
HPE SmartArrayhpssacli
LSI MegaRAIDstorcli

O SUSE Linux Enterprise Server também oferece o pacote ledmon e a ferramenta ledctl. Essa ferramenta também pode funcionar para ambientes de hardware que utilizam compartimentos de armazenamento da Intel. A sintaxe apropriada ao usar essa ferramenta é a seguinte:

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 você estiver em um hardware suportado, com todas as ferramentas de terceiros necessárias, os LEDs poderão ser habilitados ou desabilitados usando a seguinte sintaxe de comando do nó master Salt:

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

Por exemplo, para habilitar ou desabilitar a identificação por LED ou luzes com falha em /dev/sdd no nó OSD srv16.ceph, execute o seguinte:

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: Nomeação de Dispositivos

O nome do dispositivo usado no comando salt-run precisa corresponder ao nome que o Salt reconhece. É possível usar o seguinte comando para exibir esses nomes:

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

Em muitos ambientes, a configuração /srv/pillar/ceph/disk_led.sls exigirá mudanças para ajustar as luzes de LED de acordo com as necessidades específicas do hardware. É possível fazer mudanças simples substituindo lsmcli por outra ferramenta ou ajustando os parâmetros da linha de comando. É possível fazer mudanças complexas chamando um script externo no lugar do comando lsmcli. Ao fazer qualquer mudança no /srv/pillar/ceph/disk_led.sls, siga estas etapas:

  1. Faça as mudanças necessárias no /srv/pillar/ceph/disk_led.sls no nó master Salt.

  2. Verifique se as mudanças estão refletidas corretamente nos dados do pillar:

    root # salt 'SALT MASTER*' pillar.get disk_led
  3. Atualize os dados do pillar em todos os nós usando:

    root # salt '*' saltutil.pillar_refresh

É possível usar um script externo para usar diretamente as ferramentas de terceiros para ajustar as luzes de LED. Os seguintes exemplos mostram como ajustar o /srv/pillar/ceph/disk_led.sls para suportar um script externo e dois scripts de amostra para ambientes HP e LSI.

/srv/pillar/ceph/disk_led.sls modificado, que chama um script externo:

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 de amostra para piscar luzes de LED no hardware HP usando os utilitários 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 de amostra para piscar luzes de LED no hardware LSI usando os utilitários 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
Imprimir esta página