Arquivo para julho, 2007

Contexto

Servidor contém por exemplo o módulo de uma controladora RAID (a320raid no exemplo prático). Este módulo não tem suporte no Kernel padrão do Red Hat Enterprise Linux (RHEL), desta forma ele não está incluso no initrd gerado pós instalação.

Essa documentação mostra uma forma simples de incluir este modulo no initrd.

Pré-requesistos

1. Instalar Kernel novo;
2. Instalar pacote devel do Kernel novo;
3. Fazer backup do initrd atual existente no /boot/.

Procedimento

1. Copiar o modulo do kernel atual (rodando) para o novo kernel (instalado);
2. Gerar novo initrd com o módulo;
3. Certificar que o modulo está no novo initrd.

Na prática:

Pré-requesistos

1. Instalar Kernel novo:

[root@kfaserver kairo]# rpm -ivh kernel-smp-2.6.9-55.0.2.EL.i686.rpm –test
Preparing… ########################################### [100%]
[root@kfaserver kairo]# rpm -ivh kernel-smp-2.6.9-55.0.2.EL.i686.rpm
Preparing… ########################################### [100%]
1:kernel-smp ########################################### [100%]
WARNING: No module a320raid found for kernel 2.6.9-55.0.2.ELsmp, continuing anyway
[root@kfaserver kairo]#

Veja que no WARNING acima o Sistema Operacional já informa que um modulo não foi encontrado.
Justamente este que estaremos incluindo.

2. Instalar pacote devel do Kernel novo:

Este pacote contem os sources necessários.
[root@kfaserver kairo]# rpm -ivh kernel-smp-devel-2.6.9-55.0.2.EL.i686.rpm –test
Preparing… ########################################### [100%]
[root@kfaserver kairo]# rpm -ivh kernel-smp-devel-2.6.9-55.0.2.EL.i686.rpm
Preparing… ########################################### [100%]
1:kernel-smp-devel ########################################### [100%]
[root@kfaserver kairo]#

Fazer backup do initrd atual existente no /boot/: Este backup nos garante um fallback.

[root@kfaserver kairo]# cp initrd-2.6.9-55.0.2.ELsmp.img initrd-2.6.9-55.0.2.ELsmp.img_bkp

Procedimento

1. Copiar o modulo do kernel atual (rodando) para o novo kernel (instalado):

Verificando a versão original, nesse caso 2.6.9-11.ELsmp

[root@kfaserver kairo]# uname -a
Linux kfaserver.kairo.eti.br 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 i686 i386 GNU/Linux

Acessando o diretório do novo Kernel instalado

[root@kfaserver kairo]# cd /lib/modules/2.6.9-55.0.2.ELsmp/

Localizando na versão original a localização default do módulo

[root@kfaserver 2.6.9-55.0.2.ELsmp]# find /lib/modules/2.6.9-11.ELsmp -name a320raid*
/lib/modules/2.6.9-11.ELsmp/updates/a320raid.ko

Criando os diretórios existentes e o módulo. O importante é deixar o mesmo path.

[root@kfaserver 2.6.9-55.0.2.ELsmp]# mkdir updates
[root@kfaserver 2.6.9-55.0.2.ELsmp]# cd updates
[root@kfaserver updates]# cp /lib/modules/2.6.9-11.ELsmp/updates/a320raid.ko

2. Gerar novo initrd com o módulo:

[root@kfaserver kairo]# mkinitrd -fv –with=a320raid /boot/initrd-2.6.9-55.0.2.ELsmp.img 2.6.9-55.0.2.ELsmp
[root@kfaserver kairo]# mkinitrd -v -f –with=a320raid /boot/initrd-2.6.9-55.0.2.ELsmp.img 2.6.9-55.0.2.ELsmp
Creating initramfs
Looking for deps of module scsi_mod
Looking for deps of module sd_mod scsi_mod
Looking for deps of module scsi_mod
Looking for deps of module unknown
Looking for deps of module a320raid
Looking for deps of module aic79xx scsi_mod
Looking for deps of module scsi_mod
Looking for deps of module ide-disk
Looking for deps of module ext3 jbd
Looking for deps of module jbd
Looking for deps of module a320raid
Using modules: ./kernel/drivers/scsi/scsi_mod.ko ./kernel/drivers/scsi/sd_mod.ko ./a320raid.ko ./kernel/drivers/scsi/aic7xxx/aic79xx.ko ./kernel/fs/jbd/jbd.ko ./kernel/fs/ext3/ext3.ko
/sbin/nash -> /tmp/initrd.EV1881/bin/nash
/sbin/insmod.static -> /tmp/initrd.EV1881/bin/insmod
/sbin/udev.static -> /tmp/initrd.EV1881/sbin/udev
/etc/udev/udev.conf -> /tmp/initrd.EV1881/etc/udev/udev.conf
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./kernel/drivers/scsi/scsi_mod.ko(elf32-i386) to /tmp/initrd.EV1881/lib/scsi_mod.ko(elf32-i386)
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./kernel/drivers/scsi/sd_mod.ko(elf32-i386) to /tmp/initrd.EV1881/lib/sd_mod.ko(elf32-i386)
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./a320raid.ko(elf32-i386) to /tmp/initrd.EV1881/lib/a320raid.ko(elf32-i386)
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./kernel/drivers/scsi/aic7xxx/aic79xx.ko(elf32-i386) to /tmp/initrd.EV1881/lib/aic79xx.ko(elf32-i386)
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./kernel/fs/jbd/jbd.ko(elf32-i386) to /tmp/initrd.EV1881/lib/jbd.ko(elf32-i386)
copy from /lib/modules/2.6.9-55.0.2.ELsmp/./kernel/fs/ext3/ext3.ko(elf32-i386) to /tmp/initrd.EV1881/lib/ext3.ko(elf32-i386)
Loading module scsi_mod
Loading module sd_mod
Loading module a320raid
Loading module aic79xx
Loading module jbd
Loading module ext3

3. Certificar que o modulo está no novo initrd:

Descompactar o novo initrd e verificar o conteúdo garantindo que o modulo esta interno

[root@kfaserver kairo]# cd /tmp
[root@kfaserver tmp]# mkdir initrd
[root@kfaserver tmp]# cd initrd
[root@kfaserver initrd]# mkdir src
[root@kfaserver initrd]# cp /boot/initrd-2.6.9-55.0.2.ELsmp.img .
[root@kfaserver initrd]# cd src
[root@kfaserver src]# gzip -dc ../initrd-2.6.9-55.0.2.ELsmp.img | cpio -idv
.
etc
etc/udev
etc/udev/udev.conf
init
dev
dev/console
dev/tty2
dev/tty4
dev/null
dev/ram
dev/systty
dev/tty1
dev/tty3
lib
lib/a320raid.ko
lib/jbd.ko
lib/scsi_mod.ko
lib/sd_mod.ko
lib/ext3.ko
lib/aic79xx.ko
sys
proc
bin
bin/nash
bin/modprobe
bin/udevstart
bin/udev
bin/hotplug
bin/insmod
loopfs
sysroot
sbin
3078 blocks

Backup PuTTY

Gerar no C:\ o arquivo de backup do registro com o nome putty-bkp.reg


regedit /e C:\putty-bkp.reg HKEY_CURRENT_USER\Software\SimonTatham

Conecte-se blade center manager via telnet


username: USERID
password: ********
system>

Chamado console da lâmina 3, que é uma lâmina RISC com AIX.


system> console -T system:blade[3]

AIX Version 5
(C) Copyrights by IBM and by others 1982, 2006.
Console login:

Para uma maior segurança ao rebootar um servidor que está um longo tempo sem boot adoto um checklist básico.
Ele consiste em:

  1. Verificar os discos que fazem parte do rootvg;
  2. Regravar o boot nos discos do rootvg;
  3. Verificar a ordem de boot;
  4. Setar a ordem verificada.

Na prática:

  1. Verificar os discos que fazem parte do rootvg:
    #lspv | grep rootvg
    hdisk0 002007902d1d5e22 rootvg active
    hdisk1 002007902d25a1d1 rootvg active
  2. Regravar o boot nos discos do rootvg:
    # bosboot -ad hdisk0
    bosboot: Boot image is 30434 512 byte blocks.
    # bosboot -ad hdisk1
    bosboot: Boot image is 30434 512 byte blocks.
  3. Verificar a ordem de boot;
    # bootlist -m normal -o
    hdisk1 blv=hd5
    hdisk0 blv=hd5
    É interessante neste ponto também verificar os discos usados pelos Logical Volumes do rootvg. Isso porque no exemplo acima o SO sobe pelo hdisk1 primeiramente, caso um ele falhe o boot vai dar inicio pelo hdisk0.
    Desta forma é importante verificar o disco utilizado pelos Volume Groups não espelhados.


    # lsvg -l rootvg
    rootvg:
    LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
    hd5 boot 1 2 2 closed/syncd N/A
    hd6 paging 80 160 2 open/syncd N/A
    paging00 paging 80 160 2 open/syncd N/A
    hd8 jfs2log 1 2 2 open/syncd N/A
    hd4 jfs2 1 2 2 open/syncd /
    hd2 jfs2 24 48 2 open/syncd /usr
    hd9var jfs2 1 2 2 open/syncd /var
    hd3 jfs2 4 8 2 open/syncd /tmp
    hd1 jfs2 1 2 2 open/syncd /home
    hd10opt jfs2 1 2 2 open/syncd /opt
    lg_dumplv sysdump 16 16 1 open/syncd N/A
    Veja que o lg_dumplv usa apenas um disco. Vamos verificar qual disco ele está usando:


    # lslv -l lg_dumplv
    lg_dumplv:N/A
    PV COPIES IN BAND DISTRIBUTION
    hdisk1 016:000:000 0% 016:000:000:000:000

    Sendo assim é importante que o SO inicialize pelo hdisk1
    (Veja no Item 4)
    Nota: O ideal é que todos os lvs estejam utilizando os dois discos.

  4. Setar a ordem verificada.
    # bootlist -m normal hdisk1 hdisk0
    # bootlist -m normal -o
    hdisk1 blv=hd5
    hdisk0 blv=hd5

Pré-requisitos:

  • Switch deve estar conectado à uma rede LAN e configurado;
  • Existência de um servidor FTP na mesma rede do Switch SAN;
  • Baixar a última versão disponível do firmware neste link;
  • Disponibilizar o arquivo descompactado em um diretório acessível do FTP.

Impactos:

  • Indisponiblidade do switch durante o reboot.

Procedimento:

  1. Realizar acesso ao SSH ou Telenet no switch SAN;
  2. Executar o comando firmwareDownload
    É importante colocar o caminho completo e ao final o nome release.plist.

    san001kairo:admin> firmwareDownload
    Server Name or IP Address: 10.10.0.3
    FTP User Name: kairo
    File Name: /home/kairo/san/v5.1.1a/release.plist
    FTP Password:
    You can run firmwaredownloadstatus to get the status
    of this command.This command will cause the switch to reset and will
    require that existing telnet, secure telnet or SSH
    sessions be restarted.
    Do you want to continue [Y]: y
    Firmware is being downloaded to the switch. This step may take up to 30 minutes.
    Checking system settings for firmwaredownload...
    Start to install packages...
    Pode-se acompanhar o status através do comando firmwareDownloadStatus


    san001kairo:admin> firmwareDownloadStatus
    [1]: Wed Jul 18 07:42:41 2007
    Firmware is being downloaded to the switch. This step may take up to 30 minutes.
    Após o update o switch será rebootado

  3. Verificando a versão do switch

    san001kairo:admin> version
    Kernel: 2.4.19
    Fabric OS: v5.1.1a
    Made on: Mon Nov 27 15:25:26 2006
    Flash: Wed Jul 18 07:45:23 2007
    BootProm: 4.5.3
    san001kairo:admin>