Wednesday, September 19, 2012

Replicación de LUNs con RHEL – Replicated LUNs with RHEL


Replicación de LUNs con RHEL – Replicated LUNs with RHEL


Autor: Pedro Flor
Edición: 0
Última actualización: 19/09/2012

Para mayor referencia, revisar los siguientes recursos:

WWID (World Wide Name)

LVM (Logical Volume Manager)

How can I boot a server from a replicated SAN LUN using device-mapper-multipath in Red Hat Enterprise Linux 5?”

Red Hat Linux boot on SAN & multipath”

Storage area network

Initrd (Initial ramdisk)


Escenario:
Se tiene un sitio “primario” y un sitio de “contingencia” con las siguientes características:





Sitio Primario
1 cuchilla sobre un Blace Center IBM
1 Storage IBM Storwize

Sitio Secundario
1 cuchilla sobre un Blace Center IBM
1 Storage IBM Storwize

Objetivo
Disponder de un servidor RHEL 5 con ORACLE funcionado en el sitio primario y que este se replique en el sitio de contingencia mediante el producto “Storwize”.

La réplica de datos se hace con el total de LUNs asignados al servidor RHEL.

Problema
El problema de este escenario es que RHEL trabaja con WWID para acceder a los diferentes LUNs que se le presenta (por ejemplo el LUN del directorio raíz). Cuando el software de replica de LUNs (en este caso “storwize”) hace la réplica de las LUNs del sitio primario con el sitio de contengencia, los WWID también son replicados (en realidad todos los datos son replicados del sitio primaro al sitio de contingencia), de forma que cuando RHEL hace “boot on SAN” del sitio de contingencia, este no sabe como acceder a las LUNs de este sitio (contingencia) puesto que los WWID no corresponden.

Esto aplica a “boot on SAN” y a cualquier LUN que se presente a RHEL y sea replicado.

Solución
La solución a este problema es indicar a RHEL (que hace “boot on SAN” desde el sitio de conteingcia) los WWID correspondientes a los LUNs del sitio de contingia y que no use las referencias a los WWID del sitio princial.
Para resolver este problema se creará un nuevo “initrd” y una nueva entrada en GRUB que haga refencia al nuevo initrd con los WWIDs correspondientes a cada sitio:



Procedimiento
1) Instalar REHL con la opción “linux mpath
2) Cuando la instalación se haya concluido, verificar que “multipath” esté configurado con “friendly names” para el apropiado mapeo de “/dev/mapper/mpath*
3) Crear los nuevos volúmenes lógicos (LVM) para Oracle (usar “system-config-lvm”)
4) Modificar GRUB de manera que este tenga una nueva entrada de boot y permita cargar un nuevo “initrd”, el cual tendrá los WWID de ambos sitios.

Descomprimir y desempaquetar el “initrd” actuál

# mkdir /root/boot
# cp /boot/initrd-2.6.img /root/boot
# cd /root/boot
# gunzip initrd-2.6.img | cpio -i –make-directories
# rm initrd-2.6.img


Notas:
a) El archivo “/root/boot/etc/multipath.conf” debe tener TODOS los WWID de los LUNs que se vayan a usar en ambos sitios.

b) El archivo “/root/boot/etc/multipath/bindings” debe tener las referencias en formato “friendly names” con los WWID del sitio de contingencia UNICAMENTE para que LVM los gestione correctamente.

c) El archivo “/root/boot/etc/multipath/wwids” debe tener los WWID del sitio de contingencia.

Creación/modificación del nuevo initrd

# cd /root/boot/
# find ./ | cpio -H newc -o > initrd-nuevo-2.6.cpio
# gzip -9 initrd-nuevo-2.6.cpio
# mv initrd-nuevo-2.6.cpio.gz initrd-nuevo-2.6.img


Crear nueva entrada en GRUB
Crear nueva entrada con el nuevo initrd-nuevo.

Sincronizar los LUNs mediante el software de gestión de los storage
Con el GUI de Storwize, sincronizar los LUNs del sitio primario con el sitio de contingencia y cambiar los roles de cada sitio.

Networking
Otro problema que surge en este escenario es que cada servidor (cuchilla Blade IBM) tiene sus propias direcciones “MAC Address”, información que se replica en ambos sitios.

Solución
En el archivo “/etc/sysconfig/network-scripts/ifcfg-eth0” se deberá quitar la directiva HWADDR para que quede así:

DEVICE="eth0"
BOOTPROTO="dhcp"
ONBOOT="yes"
TYPE=Ethernet
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=DHCP


Fin de documento.

Friday, July 6, 2012

systemctl: mejorar el “boot time” de Fedora 16

systemctl: mejorar el “boot time” de Fedora 16

Fedora en sus versiones recientes (creo que 15 en adelante) incorpora un nuevo sistema de gestión de servicios: ”systemctl”.

A continuación cómo mejorar el tiempo de inicio del SO (boot time) de Fedora 16 mediante “systemctl”.

1) Analizar los servicios que más demoran en iniciarse y que afectan el “boot time”

# systemd-analyze blame

En mi caso, el resultado del anterior comando  proporciona el siguiente resultado:

# systemd-analyze blame
66510ms sm-client.service
61395ms sendmail.service
11169ms udev-settle.service
10845ms fedora-loadmodules.service
6480ms var-lib-nfs-rpc_pipefs.mount
4058ms systemd-vconsole-setup.service
3826ms media.mount
3794ms dev-hugepages.mount
3779ms dev-mqueue.mount
3763ms sys-kernel-security.mount
3751ms sys-kernel-debug.mount
3346ms udev-trigger.service
3333ms udev.service

Como se puede apreciar (en rojo) los servicios que toman un tiempo considerable en iniciarse son “sendmail”.

2) Deshabilitar servicios innecesarios

# systemctl disable sm-client.service
# systemctl disable sendmail.service
# systemctl disable vmware-workstation-server.service
# systemctl disable vmware.service


3) Ahora es necesario reiniciar el SO y verificar la reducción del boot time.

Fuentes:



Friday, May 18, 2012

RHEL "linux rescue" & LVM

Problema: El filesystem LVM "root" ( / ) está con problemas y por tanto es necesario su reparación.

1) Iniciar con el DVD de instalación de Red Hat en modo rescate "linux rescue"
2) Una vez iniciado el sistema de rescate, escoger "Read Only" de montaje de filesystems.
3) Ejecutar los siguientes comandos:


# umount /mnt/sysimage/*
# umount /mnt/sysimage/dev/pts
# umount /mnt/sysimage/dev
# umount /mnt/sysimage/*
# fsck.ext3 -c -v -p /dev/VolGroup00/LogVol00

Nota: la dirección “/dev/VolGroup00/LogVol00” puede cambiar.

Fuentes: Google

Friday, April 20, 2012

Open Source

Closed source programs piss me off. Resistance is futile. You will be Open Sourced.

No conozco su autor, sin embargo comparto su sentir...
PD: Esta frase no la inventé yo, pertenece a alguien más...

Thursday, March 15, 2012

Red Hat Linux boot on SAN & multipath

Escenerio:
Cuchilla conectada a un Storage "Storewize v7000" con múltiples PATHS.

Requerimiento:
Instalar Red Hat Linux en una cuchilla y que haga Boot on SAN gestionando apropiadamente las múltiples rutas al LUN del storage

Actividades:
Instalar RHEL 5.5 o superior con la opción "linux mpath".
Una vez iniciado el instalador de RHEL (anaconda) proceder como una instalación normal.
Esta opción indica a RHEL que haga la instalación en el "LUN 0" de forma que el SO gestione apropiadamente las múltiples rutas y las vea como una (1) sola.

Comandos usados: 

# multipath -ll
Muestra la topología multipath actual

# fdisk -l
Muestra un listado de todos los dispositivos actuales del SO

# echo "- - -" > /sys/class/scsi_host/host#/scan
Reconoce nuevos discos en caliente

# scsi_id -g -u -s /block/sda
Determina el WWID SCSCI de /dev/sda


# system-config-lvm
Herramienta gráfica para gestionar LVM



Otras referencias:

Wednesday, March 14, 2012

btrfs sucks!!!

btrfs sucks!!!

Si, una expresión fuerte pero acertada.
No soy un experto en FS, sin embargo llevo unos cuantos meses con Fedora 15 y btrfs (gran error mio al escoger este FS) y solo tengo lapsus mientras mi portatil "vuelve en sí" para seguir trabajando...

En la gran red leí que btrfs está en sus etapas iniciales, motivo por el que está tan malo... malísimo diría yo.

En fin, mi recomendación: NO lo usen en ambientes en producción, ni siquiera en sus casas.

-End of message-