Skip to main content
SAN hosts and cloud clients
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Use o Oracle Linux 6,4 com ONTAP

Colaboradores
PDFs

Você pode usar as configurações de host SAN ONTAP para configurar o Oracle Linux 6,4 com ONTAP como destino.

Instale os utilitários do host unificado do Linux

O pacote de software Utilitários de host unificado do NetApp Linux está disponível no "Site de suporte da NetApp"em um arquivo .rpm de 32 e 64 bits. Se não souber qual é o ficheiro adequado para a sua configuração, utilize o "Ferramenta de Matriz de interoperabilidade do NetApp" para verificar qual necessita.

O NetApp recomenda fortemente a instalação dos Utilitários de host unificado do Linux, mas não é obrigatório. Os utilitários não alteram nenhuma configuração em seu host Linux. Os utilitários melhoram o gerenciamento e auxiliam o suporte ao cliente da NetApp na coleta de informações sobre sua configuração.

Se você tiver o Linux Unified Host Utilities atualmente instalado, você deve atualizá-lo para a versão mais recente ou removê-lo e siga estas etapas para instalar a versão mais recente.

Passos

  1. Faça o download do pacote de software Linux Unified Host Utilities de 32 ou 64 bits do "Site de suporte da NetApp" para o seu host.

  2. Instale o pacote de software:

    rpm -ivh netapp_linux_unified_host_utilities-7-1.x86_64

Observação Pode utilizar as definições de configuração fornecidas neste documento para configurar os clientes em nuvem ligados a "Cloud Volumes ONTAP" e "Amazon FSX para ONTAP".

Kit de ferramentas SAN

O kit de ferramentas é instalado automaticamente quando você instala o pacote de utilitários de host do NetApp. Este kit fornece o sanlun utilitário, que ajuda você a gerenciar LUNs e HBAs. O sanlun comando retorna informações sobre os LUNs mapeados para o seu host, multipathing e informações necessárias para criar grupos de iniciadores.

Exemplo

No exemplo a seguir, o sanlun lun show comando retorna informações de LUN.

# sanlun lun show all

Exemplo de saída:

controller(7mode/E-Series)/            device     host               lun
vserver(cDOT/FlashRay)   lun-pathname  filename   adapter  protocol  size    Product
------------------------------------------------------------------------------------
data_vserver          /vol/vol1/lun1   /dev/sdb   host16   FCP       120.0g  cDOT
data_vserver          /vol/vol1/lun1   /dev/sdc   host15   FCP       120.0g  cDOT
data_vserver          /vol/vol2/lun2   /dev/sdd   host16   FCP       120.0g  cDOT
data_vserver          /vol/vol2/lun2   /dev/sde   host15   FCP       120.0g  cDOT

Inicialização de SAN

O que você vai precisar

Se você decidir usar a inicialização de SAN, ele deve ser suportado por sua configuração. Você pode usar o "Ferramenta de Matriz de interoperabilidade do NetApp" para verificar se o seu sistema operacional, HBA, HBA firmware e o BIOS de inicialização HBA e a versão ONTAP são suportados.

Passos

  1. Mapeie o LUN de inicialização SAN para o host.

  2. Verifique se há vários caminhos disponíveis.

    Observação Vários caminhos ficam disponíveis depois que o sistema operacional host estiver ativo e em execução nos caminhos.

  3. Ative a inicialização SAN no BIOS do servidor para as portas às quais o LUN de inicialização SAN está mapeado.

    Para obter informações sobre como ativar o BIOS HBA, consulte a documentação específica do fornecedor.

  4. Reinicie o host para verificar se a inicialização foi bem-sucedida.

Multipathing

Para o Oracle Linux 6,4 o arquivo /etc/multipath.conf deve existir, mas você não precisa fazer alterações específicas no arquivo. O Oracle Linux 6,4 é compilado com todas as configurações necessárias para reconhecer e gerenciar corretamente LUNs ONTAP. Para ativar o ALUA Handler, execute as seguintes etapas:

Passos

  1. Crie um backup da imagem initrd.

  2. Anexe o seguinte valor de parâmetro ao kernel para ALUA e non-ALUA funcionar:
    rdloaddriver=scsi_dh_alua

    kernel /vmlinuz-3.8.13-68.1.2.el6uek.x86_64 ro root=/dev/mapper/vg_ibmx3550m421096-lv_root rd_NO_LUKSrd_LVM_LV=vg_ibmx3550m421096/lv_root LANG=en_US.UTF-8 rd_NO_MDSYSFONT=latarcyrheb-sun16 crashkernel=256M KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg_ibmx3550m421096/lv_swap rd_NO_DM rhgb quiet rdloaddriver=scsi_dh_alua

  3. Use o mkinitrd comando para recriar a imagem initrd. O Oracle 6xi e versões posteriores usam: O comando mkinitrd -f /boot/ initrd-"uname -r".img uname -r: Ou o comando: dracut -f

  4. Reinicie o host.

  5. Verifique a saída do cat /proc/cmdline comando para garantir que a configuração esteja concluída. Você pode usar o multipath -ll comando para verificar as configurações dos LUNs do ONTAP. Deve haver dois grupos de caminhos com prioridades diferentes. Os caminhos com prioridades mais altas são Ativo/otimizado, o que significa que eles são atendidos pelo controlador onde o agregado está localizado. Os caminhos com prioridades mais baixas estão ativos, mas não são otimizados porque são servidos de um controlador diferente. Os caminhos não otimizados são usados somente quando caminhos otimizados não estão disponíveis.

Exemplo

O exemplo a seguir exibe a saída correta para um LUN ONTAP com dois caminhos ativos/otimizados e dois caminhos ativos/não otimizados:

# multipath -ll
3600a09803831347657244e527766394e dm-5 NETAPP,LUN C-Mode
size=80G features='4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='round-robin 0' prio=50 status=active
| |- 0:0:26:37 sdje 8:384   active ready running
| |- 0:0:25:37 sdik 135:64  active ready running
|-+- policy='round-robin 0' prio=10 status=enabled
  |- 0:0:18:37 sdda 70:128  active ready running
  |- 0:0:19:37 sddu 71:192  active ready running
Observação Um único LUN não deve exigir mais de quatro caminhos. Ter mais de quatro caminhos pode causar problemas de caminho durante falhas de storage.

Definições recomendadas

O sistema operacional Oracle Linux 6,4 é compilado para reconhecer LUNs ONTAP e definir automaticamente todos os parâmetros de configuração corretamente.

O multipath.conf arquivo deve existir para o daemon multipath iniciar. Se este arquivo não existir, você pode criar um arquivo vazio, zero-byte usando o touch /etc/multipath.conf comando.

Na primeira vez que você criar o multipath.conf arquivo, talvez seja necessário habilitar e iniciar os serviços multipath usando os seguintes comandos:

# chkconfig multipathd on
# /etc/init.d/multipathd start

Não há necessidade de adicionar dispositivos diretamente ao multipath.conf arquivo, a menos que você tenha dispositivos que não deseja que o multipath gerencie ou tenha configurações existentes que substituem os padrões. Para excluir os dispositivos indesejados, adicione a seguinte sintaxe ao multipath.conf arquivo, substituindo o <DevId> pela cadeia WWID do dispositivo que você deseja excluir:

blacklist {
        wwid <DevId>
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
        devnode "^cciss.*"
}
Exemplo

No exemplo a seguir sda, é o disco SCSI local que você deseja adicionar à lista negra.

Passos

  1. Execute o seguinte comando para determinar o WWID:

    # /lib/udev/scsi_id -gud /dev/sda
360030057024d0730239134810c0cb833

  2. Adicione este WWID à estrofe "blacklist" em /etc/multipath.conf:

    blacklist {
     wwid   360030057024d0730239134810c0cb833
     devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
     devnode "^hd[a-z]"
     devnode "^cciss.*"
}

Você deve sempre verificar seu /etc/multipath.conf arquivo, especialmente na seção padrões, para configurações herdadas que podem estar substituindo as configurações padrão.

A tabela a seguir demonstra os parâmetros críticos multipathd para LUNs ONTAP e os valores necessários. Se um host estiver conetado a LUNs de outros fornecedores e qualquer um desses parâmetros for substituído, ele precisará ser corrigido por estrofes posteriores multipath.conf no arquivo que se aplicam especificamente aos LUNs ONTAP. Sem essa correção, os LUNs ONTAP podem não funcionar como esperado. Você só deve substituir esses padrões em consulta com o NetApp, o fornecedor do sistema operacional ou ambos, e apenas quando o impactos for totalmente compreendido.

Parâmetro Definição

detectar_prio

sim

dev_loss_tmo

"infinito"

failback

imediato

fast_io_fail_tmo

5

caraterísticas

"3 queue_if_no_path pg_init_retries 50"

flush_on_last_del

"sim"

hardware_handler

"0"

no_path_retry

fila de espera

path_checker

"tur"

path_grouing_policy

"group_by_prio"

path_selector

"round-robin 0"

polling_interval

5

prio

"ONTAP"

produto

LUN.*

reter_anexado_hw_handler

sim

rr_peso

"uniforme"

user_friendly_names

não

fornecedor

NetApp
Exemplo

O exemplo a seguir mostra como corrigir um padrão substituído. Nesse caso, o multipath.conf arquivo define valores para path_checker e detect_prio que não são compatíveis com LUNs ONTAP. Se eles não puderem ser removidos devido a outros arrays SAN ainda conetados ao host, esses parâmetros podem ser corrigidos especificamente para LUNs ONTAP com uma estrofe de dispositivo.

defaults {
 path_checker readsector0
 detect_prio no
 }
devices {
 device {
 vendor "NETAPP "
 product "LUN.*"
 path_checker tur
 detect_prio yes
 }
}
Observação Para configurar o Oracle Linux 6,4 Red Hat Enterprise Kernel (RHCK), use o "definições recomendadas" para Red Hat Enterprise Linux (RHEL) 6,4.

Problemas conhecidos

O Oracle Linux 6,4 com ONTAP tem os seguintes problemas conhecidos:

ID de erro do NetApp Título Descrição

"713555"

As reinicializações do adaptador QLogic são vistas em OL6,4 e OL5,9 com UEK2 em falhas do controlador, como a aquisição/giveback e a reinicialização

As reinicializações do adaptador QLogic são vistas em OL6,4 hosts com UEK2 (kernel-uek-2,6.39-400.17.1.el6uek) ou OL5,9 hosts com UEK2 (kernel-uek-2.6.39 400.17.1.el5uek) quando as falhas do controlador acontecem (tais como a aquisição, giveback e reinicializações). Estas reinicializações são intermitentes. Quando essas reinicializações do adaptador acontecem, uma interrupção de e/S prolongada (às vezes, mais de 10 minutos) pode ocorrer até que o adaptador seja redefinido com êxito e o status dos caminhos seja atualizado pelo dm-multipath. Em /var/log/messages, mensagens semelhantes às seguintes são vistas quando este bug é atingido: Kernel: qla2xxx [0000:11:00,0]-8018:0: ADAPTER RESET ISSUED NEXUS:0:2:13. Isso é observado com a versão do kernel: Em OL6,4: Kernel-uek-2,6.39-400.17.1.el6uek em OL5,9: Kernel-uek-2,6.39-400.17.1.el5uek

"715217"

O atraso na recuperação do caminho em hosts OL6,4 ou OL5,9 com UEK2 pode resultar em retomada retardada de e/S em falhas no controlador ou na malha

Quando uma falha de controladora (failover de armazenamento ou giveback, reinicializa e assim por diante) ou uma falha de malha (desativação ou ativação da porta FC) ocorre com e/S em hosts Oracle Linux 6,4 ou Oracle Linux 5,9 com UEK2 Kernel, a recuperação de caminho pelo DM-Multipath leva muito tempo (4mins. A 10 minutos). Às vezes, durante os caminhos que se recuperam para o estado ativo, os seguintes erros de driver lpfc também são vistos: Kernel: sd 0:0:8:3: [sdlt] resultado: Versões OL 6,4: Device-mapper-1.02.77-9.el6 device-mapper-multipath-2,6.1-9.64,0.0,4 kernel-uek-9.39-400.17.1.el6uek OL 5,9 versões: Device-mapper-1.02.77-2,6.el5 device-mapper-multipath-el6.64,0-1.9.el5 kernel-uek-0,4.39-400.17.1.el5uek

"709911"

O DM Multipath no iSCSI OL6,4 e OL5,9 com kernel UEK2 demora muito tempo a atualizar o estado do caminho LUN após falhas de armazenamento

Em sistemas que executam Oracle Linux 6 Update4 e Oracle Linux 5 Update9 iSCSI com Enterprise Kernel inquebrável versão 2 (UEK2), um problema foi visto durante eventos de falha de armazenamento em que DM Multipath (DMMP) leva cerca de 15 minutos para atualizar o status do caminho dos dispositivos (LUNs) Mapper de dispositivos (DM). Se você executar o comando "multipath -ll" durante esse intervalo, o status do caminho é mostrado como "failed ready running" para esse dispositivo DM (LUN). O status do caminho é eventualmente atualizado como "ativo pronto em execução". Este problema é visto com a seguinte versão: Oracle Linux 6 39 0,4 1 64 16,0 x86 Atualização 4 400.17.1 9 el5 6,2 1 64: 5 2,6 el5uek 64,0 x86 0,872 el5 Kernel: x86.64-el6.2,0.1_0,873 Multipath: Device-mapper-multipath-64.6,2-64,0.1.el6.x86_0,4 iSCSI: ISCSI-inicializador-utils-9.64-el6uek.x86.400.17.1.2,6_39 Oracle Linux UEK2 Atualização 9: UEK2

"739909"

A chamada do sistema SG_io ioctl falha em dispositivos dm-multipath após uma falha FC em hosts OL6.x e OL5.x com UEK2

Um problema é visto em hosts Oracle Linux 6.x com kernel UEK2 e hosts Oracle Linux 5.x com kernel UEK2. Os comandos sg_* em um dispositivo multipath falham com o código de erro EAGAIN (errno) após uma falha de malha que faz todos os caminhos no grupo de caminho ativo diminuírem. Esse problema é visto somente quando não há e/S ocorrendo nos dispositivos multipath. O seguinte é um exemplo: sg_inq -v /dev/mapper/3600a098041764937303f436c75324370 inquérito cdb: 12 00 00 00 24 00 11 ioctl(SG_io v3) falhou com os_err (errno): 11 INQUÉRITO: Passe através de os erro: Resource temporariamente mapHDIO_GET_IDENTITY iocching_ioctl( O problema foi observado nas seguintes versões dos pacotes kernel-uek e device-mapper-multipath: OL6,4 versões: Kernel-uek-2,6 64,0.39-400.17.1.el6uek device-mapper-multipath-0,4.400.17.1-64,0.39.el6 OL5,9 versões: Kernel-uek-2,6.1-9.el5uek device-mapper-multipath-0,4.9.1.el5
Observação Para problemas conhecidos do Oracle Linux (kernel compatível com Red Hat), consulte o "problemas conhecidos" para Red Hat Enterprise Linux (RHEL) 6,4.