Configurar Powerpath en Oracle VM en vez de usar Multipath

Hola amigos! Como algunos ya sabéis estoy probando Oracle VM para backends de bases de datos. Y aquí va primer post, para configurar powerpath en vez de multipath para todos los que tengáis cabinas EMC.

Para luego verificar que vemos las mismas LUNS y mismos UUIDs, podemos guardar la salida de:

#  ls -l /dev/mapper/
total 0
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce2027004ed03e645919e311
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700a2ffea74fe15e311
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700ec38369a364be111

Primeramente desactivamos multipath y reniciamos el servidor

# chkconfig multipathd off
# /etc/init.d/multipathd stop

Una vez UP, miramos que no tengamos ningún device en el /dev/mapper

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 sep  9 15:48 control

Nos descargamos el nuevo udev del repositorio de Oracle y lo instalamos

# wget http://public-yum.oracle.com/repo/OracleVM/OVM3/latest/x86_64/udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm
# rpm -Uvh udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm
warning: udev-095-14.27.100.1.el5_7.4.2.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ########################################### [100%]
   1:udev                   ########################################### [100%]

Ahora, lo mismo pero con las versión correcta de powerpath.

# rpm -iv EMCPower.LINUX-5.7.1.01.00-006.OL5_UEK2_R3.x86_64.rpm 

Ya podemos añadir la key y reniciar

# emcpreg -add XXXX-XXXX
# reboot

Cuando tengamos otra vez el servidor arrancado, verificamos que en el device mapper estan las LUNS que teniamos con multipah con el mismo UUID. Pero primeramente acabamos de configurar PowerPath:

# powermt check_registration
# powermt set policy=co dev=all
# powermt display dev=all
# powermt save

Comprobamos el dev mapper:

# ls -l /dev/mapper/
total 0
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce2027004ed03e645919e311 ../emcpowerc
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700a2ffea74fe15e311 ../emcpowerb
lrwxrwxrwx 1 root root      12 sep 10 10:08 360060160ce202700ec38369a364be111 ../emcpowera

Con esto ya tendríamos que tener incluso montado el cluster ocfs2

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2              3050092   1498204   1394452  52% /
/dev/sda1               101086     28542     67325  30% /boot
tmpfs                   541872         0    541872   0% /dev/shm
none                    541872        96    541776   1% /var/lib/xenstored
/dev/emcpowere        20971520    269076  20702444   2% /poolfsmnt/0004fb0000050000b8c6c5abcb3fd94b
/dev/emcpowerd       419430400  56515584 362914816  14% /OVS/Repositories/0004fb00000300000e98b1c9f943d355

Tengo que reconocer que en algunos aspectos como el RawDevice Mapping que tiene OVM está muy bien, es una lástima que con XenServer no lo tengamos solucionado ahún :D

Saludos

Añadir nuevo disco iscsi multipath ocfs2

En cada nodo del cluster

Reescanemos en busca de la nueva lun
iscsiadm -m session --rescan

Recargamos multipath
/etc/init.d/multipathd reload

multipath -v3

Verificamos que vemos los caminos hacia la nueva LUN
multipath -ll

Creemos los enlaces uuid
(como no se como se hace automaticamente en Suse, lo hago a mano)
blkid | grep /dev/dm-

En este caso asumo que es /dev/dm-1 con el UUID 325dab18-903a-4aae-8230-a9662294846e
cd /dev/disk/by-uuid
ln -s ../../dm-1 325dab18-903a-4aae-8230-a9662294846e

verificamos que es correcto y ya lo tenemos listo para añadir como dispositivo en el recurso fs del cluster

En un nodo del cluster

Formateamos el nuevo disco
mkfs.ocfs2 -N 16 /dev/dm-2

En el CRM

Añadimos el recurso clone fs:ocf:heartbeat con sus respectivas constraints de localización, colocación y orden y listos. Nuevo pool de espacio libre.

ionice - modificar prioridad de IO de disco

Este programa establece la clase de planificación io y la prioridad de un programa a la hora de escribir en disco. Linux soporta las siguienes 3 clases:

Idle: Un programa que se ejecuta con prioridad io inactivo, no va a escribir en disco si hay otro programa ha pedido io para un período de gracia definido. El impacto de los procesos de E / S de inactividad en la actividad normal del sistema debe ser cero. Esta clase de planificación, no hace falta ser un argumento de prioridad.

Best effort: Esta es la clase de planificación predeterminada para cualquier proceso que no ha pedido una prioridad io específica. Esta clase tiene un argumento de prioridad de 0-7 (menor número = máxima prioridad). Los programas que se ejecutan en la misma prioridad "Best effort" se sirven en un round-robin.

RealTime: La clase de planificación RT se da acceso por primera vez al disco, independientemente de lo que está ocurriendo en el sistema. Así, la clase RT necesita ser utilizado con cierto cuidado, ya que otros procesos pueden "morir de hambre".

-c
La clase de planificación. 1 para tiempo real, 2 para "mejor esfuerzo", 3 de inactividad.
-n
Los datos de clase de planificación. Esto define la clase de datos, si la clase acepta un argumento. Por tiempo real y mejor esfuerzo, 0-7 es un dato válido.
-p
Ir a un proceso pid para cambiar un proceso ya se está ejecutando. Si este argumento no se da, ionice ejecutará el programa en la lista con los parámetros especificados.

Ejemplos:

# ionice -c3 -p89

Sets process with PID 89 as an idle io process.

# ionice -c2 -n0 bash

Runs 'bash' as a best-effort program with highest priority.

# ionice -p89

Returns the class and priority of the process with PID 89.

Ejemplo practico para backups de discos de xen sobre particion ocsf2
sudo ionice -c 3 cp -r /xenstore/maquina1.raw /backup/xenstore

de esta forma que sólo se procesará la entrada y salida cuando el sistema esté libre y no tendremos problemas en entornos cluster.

OCFS2 self-fencing during cluster failover on SUSE Linux Enterprise

During a clustered failover or network disruption, all paths to the storage system can become unavailable. As a result, the nodes might fence by panicking. Set the O2CB_HEARTBEAT_THRESHOLD value in /etc/sysconfig/o2cb to a value large enough to ensure that the nodes do not self-fence.

Oracle Cluster File System (OCFS2) has a fencing mechanism that relies on each node being able to write a heartbeat value to a specific area on each OCFS2 volume. Every two seconds, each node writes a new heartbeat value, and reads the value of the other node. If a node is unable to write or read the heartbeat value, it retries the operation a specific number of times, and then self-fences by panicking the Linux kernel as it fails to obtain quorum.

During a clustered failover or network disruption, all paths to the storage system can become unavailable. None of the nodes in the OCFS2 cluster is able to write or read the heartbeat values. As a result, the nodes might fence by panicking.

With a dedicated TCP/IP network for the iSCSI link between Linux hosts and the storage system, a reasonable value usually is 181. This value corresponds to a total of 360 seconds before a node self-fences.

Depending on the load in the iSCSI network, you should raise the value. It is best to use a value in the range of 91 to 201 for a configuration with OCFS2 on multipath, and iSCSI devices.

Oracle RAC O2CB Cluster Service

Oracle RAC O2CB Cluster Service

Before we can do anything with OCFS2 like formatting or mounting the file system, we need to first have OCFS2's cluster stack, O2CB, running (which it will be as a result of the configuration process performed above). The stack includes the following services:

• NM: Node Manager that keep track of all the nodes in the cluster.conf
• HB: Heart beat service that issues up/down notifications when nodes join or leave the cluster
• TCP: Handles communication between the nodes
• DLM: Distributed lock manager that keeps track of all locks, its owners and status
• CONFIGFS: User space driven configuration file system mounted at /config
• DLMFS: User space interface to the kernel space DLM

All of the above cluster services have been packaged in the o2cb system service (/etc/init.d/o2cb). Here is a short listing of some of the more useful commands and options for the o2cb system service.

• /etc/init.d/o2cb status

  Module "configfs": Not loaded
  Filesystem "configfs": Not mounted
  Module "ocfs2_nodemanager": Not loaded
  Module "ocfs2_dlm": Not loaded
  Module "ocfs2_dlmfs": Not loaded
  Filesystem "ocfs2_dlmfs": Not mounted

  Note that with this example, all of the services are not loaded. I did an "unload" right before executing the "status" option. If you were to check the status of the o2cb service immediately after configuring OCFS using ocfs2console utility, they would all be loaded

• /etc/init.d/o2cb load

  Loading module "configfs": OK
  Mounting configfs filesystem at /config: OK
  Loading module "ocfs2_nodemanager": OK
  Loading module "ocfs2_dlm": OK
  Loading module "ocfs2_dlmfs": OK
  Mounting ocfs2_dlmfs filesystem at /dlm: OK

  Loads all OCFS modules.

• /etc/init.d/o2cb online ocfs2

  Starting cluster ocfs2: OK

  The above command will online the cluster we created, ocfs2.

• /etc/init.d/o2cb offline ocfs2

  Unmounting ocfs2_dlmfs filesystem: OK
  Unloading module "ocfs2_dlmfs": OK
  Unmounting configfs filesystem: OK
  Unloading module "configfs": OK

  The above command will offline the cluster we created, ocfs2.

• /etc/init.d/o2cb unload

  Cleaning heartbeat on ocfs2: OK
  Stopping cluster ocfs2: OK

http://www.debian-administration.org/articles/578

Cluster o2cb - ERROR: Wrong stack

/usr/lib/ocf/resource.d/ocfs/o2cb monitor
ERROR: Wrong stack

Ojo el o2cb init script esta ejecutandose.
Parar y borrar del inicio