¿Que es el Elastic Stack?

Elastic Stack es una solución OpenSource que suele emplearse tanto como para el análisis de datos de tipo timeseries, como por ejemplo logs de aplicación, como también para datos estáticos tipo catálogo de productos o inventarios.

Se puede considerar a elasticsearch como una base de datos NoSQL  timeseries basada en el motor de búsqueda Apache Lucene.

La suite de Elastic Stack es un producto de OpenSource que está compuesta por los siguientes productos

    

• Kibana, es la interfaz de visualización.
• Elasticsearch, el core de la solución, es donde se guardan e indexan los documentos.
• Logstash, es la herramienta de ingestión, transformación y enriquecimiento de datos
• Beats, son pequeños agentes de propositio especifico que permiten ingesta de datos

Elasticsearch es el corazón del Stack, escrito en Java y con licencia Apache, es un motor de búsqueda cuya finalidad es realizar el indexado, análisis y búsqueda de documentos casi en tiempo real, esto quiere decir que permite la consulta de los datos indexados en tan solo unos segundos de delay, dependiendo de como sea la configuración de la instalación que hagamos.

Este motor escala muy bien en forma horizontal gracias a la posibilidad de particionar (sharding) y al replicado de los índices, esto nos permite usar hardware comodity y no gastar mucho dinero en instancias o hardware especializado

 Las consultas y operaciones al motor se realizan mediante una interface REST y en formato JSON con el lenguaje DSL, el cual es muy práctico y flexible.

Puede trabajar de forma de schema on read y schema on write lo cual le da mayor flexibilidad versus sus competidores

Se puede extender mediante plugins, x-pack (que merece de por si mismo un apartado) y otros como por ejemplo S3 repository plugin que permite guardar la toma de backups en AWS.

Logstash, es la parte del Stack que permite la ingesta de datos, es la solución de ETL que nos es provista por la suite. Esta pieza de software puede ser cambiada por alguna otra de preferencia como por ejemplo fluentd.

Logstash puede tomar y procesar los datos de varias entradas, logs, puertos TCP, colas de mensajería, etc y los puede enviar a múltiples destinos, entre ellos a elasticsearch o bien a una cola de mensajería.

Los datos de entrada pueden enriquecerse mediante plugins como el de GeoIP que permite identificar de que parte del mundo es la IP origen en, por ejemplo, un log de transacciones de un servidor web, logrando de esta manera una nueva dimensión en el análisis de los datos ingeridos.

Beats, estos son agentes livianos que permiten hacer ingesta de datos con mínima configuración por parte del usuario.

Los Beats pueden enviar los datos recolectados directamente a elasticsearch o a logstash si se requiere un major enriquecimiento de los mismos.

Sirven para recolectar cierto tipo de información y resolver problemáticas por ejemplo metricas de sistema operativo, ingerir un archivo, analizar tráfico de red, etc

Actualmente existen estos Beats:

• Metricbeat, colecta métricas del sistema y servicios (cpu, memoria, etc)
• Auditbeat, toma la información de sistema de auditoria de un equipo Linux
• Packetbeat, captura el trafico de red (tcpdump) e interpreta multiples protocolos de aplicación
• Filebeat, ingesta y centralización de logs (files)
• Winlogbeat, envía la información de los eventos de Windows para procesar en elasticsearch
• Heatbeat, monitorea la disponibilidad de servicios
• Functionbeat, permite hacer el deploy de funciones FAAS (AWS Lambdas)

Como se puede ver existen diversos agentes para solucionar problemas de la manera mas simple y sencilla.

Kibana, es la herramienta  visual del stack en la cual podemos configurar visualizaciones para agregar a dashborads, también permite hacer gestión del cluster de elastic y manejo de los índices. Como otras partes del stack, esta también permite ser ampliada mediante plugins.

Kibana también permite hacer monitoreo en base a los datos que se ingesta, machine learning y detección de anomalías, análisis de relaciones mediante grafos, presentaciones tipo powerpoint con datos realtime en canvas.

Algunos dashboards de Kibana para resolver casos de uso

Análisis de texto en redes sociales (Twitter)

Análisis de datos de un sitio de e-comerce

En resumen el Elastic Stack es una solución para análisis de datos que provee resuelve  multiples casos de uso en ya sea dashboards de operacion, dashboards gerenciales.

Manejo de LVM en Linux

LVM

A un nivel macro LVM se basa en las siguientes estructuras

Volume Group (VG)

Es la estructura que agrupa uno o mas discos (PVs). El espacio disponible se usa para crear los logical volumes

Physical Volume (PV)

Es un disco, LUN o particion inicializada con una cabecera de datos de LVM

Logical Volume (LV)

Se conforman con el espacio disponible de los VGs, luego los LVs contendrán FSs o serán usados como RAW devices.

De forma sencilla el concepto es el siguiente, se agrupan los discos en un VG, el espacio utilizable del VG es la suma del espacio de cada uno de los discos, de esta forma se elimina la limitante del disco físico. Luego apartir del espacio libre del VG se generan los LVs

Inicializacion de un PV

Para poder controlar un disco mediante LVM primero se le deben crear una cabecera con estructuras de control mediante el comando pvcreate <caracter device special file>

#pvcreate /dev/rdisk/disk5

Physical volume "/dev/rdisk/disk5" has been successfully created.

Si el disco ya estuvo bajo control de LVM y tiene una cabecera LVM, el comando fallara, para poder reescribir la cabecera para poder reutilizar el disco se debe utilizar el flag -f

Creación de un VG

Cuando creamos un VG, el LVM divide a los discos que lo integran en porciones de igual tamaño llamadas physical extents, estas porciones conforman la mínima unidad de asignación de espacio en disco. Por default el tamaño de los PE es de 4MB. Ahora procedemos con la creación del VG, en este caso vamos a armar un vg con Layout 1.0, para ver como se realiza con layout 2.x hacer click aqui de todas formas aconsejo primero leer los conceptos de esta nota primero.

#mkdir /dev/vg01

#mknod /dev/vg01/group c 64 0x010000

#vgcreate /dev/vg01 /dev/disk/disk5

Volume group "/dev/vg01" has been successfully created.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

De esta forma tenemos creado nuestro nuevo vg. Antes de verificar

Para ver el estado del VG y sus características usamos el comando vgdisplay

#vgdisplay vg01

--- Volume groups ---

VG Name                     /dev/vg01

VG Write Access             read/write

VG Status                   available

Max LV                      255

Cur LV                      0

Open LV                     0

Max PV                      16

Cur PV                      1

Act PV                      1

Max PE per PV               1016

VGDA                        2

PE Size (Mbytes)            4

Total PE                    499

Alloc PE                    0

Free PE                     499

Total PVG                   0

Total Spare PVs             0

Total Spare PVs in use      0

VG Version                  1.0

VG Max Size                 65024m

VG Max Extents              16256

Parámetros de un VG

PE Size, es el tamaño del PE, por default de 4MB, se puede especificar con la opción -s del vgcreate.

Max PE per PV, que define la cantidad máxima de PE por disco, si en este caso solo puedo direccionar 4GBs por disco,si quisiera colocar un disco de mayor tamaño debería recrear el VG y especificar un tamaño adecuado de Max PE per PV se especifica con la opción -e del vgcreate.

Max LV, la cantidad máxima de LVs que puede alojar el VG, se especifica con la opción -l del vgcreate.

Max PV, la cantidad máxima de discos que puedo agregar al VG, se especifica con la opción -p del vgcreate.

Para ver el espacio libre que tengo en el VG multiplico el Tamaño del PE por la cantidad de PE libres, en este caso

4*499=1996MB

Creación de un LV

Así como los PV están compuestos de PE, los LV están compuestos de Logical extents (LE). Los LE están asociados a los PE, si el disco no tiene mirror un LE esta asociado a un PE, si tenemos mirroreado el LV un LE esta asociado a 2 PE uno de cada disco.

Para crear un LV corremos el comando lvcreate

#lvcreate -L 100 -n mylv vg01

Logical volume "/dev/vg01/mylv" has been successfully created with

character device "/dev/vg01/rmylv".

Logical volume "/dev/vg01/mylv" has been successfully extended.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Donde -L es el tamaño en MB -n es el nombre del LV, si no se especifica se le asigna automaticamente un nombre y por ultimo se indica cual es el vg en donde se creara el LV

En este caso el tamaño de mi PE es de 16MB y quiero crear un LV de 100MB

#lvcreate -L 100 -n mylv vg01

Warning: rounding up logical volume size to extent boundary at size "112" MB.

Logical volume "/dev/vg01/mylv" has been successfully created with

character device "/dev/vg00/rmylv".

Logical volume "/dev/vg01/mylv" has been successfully extended.

Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg01.conf

Como 100 no es multiplo de 16, el sistema redondea hacia arriba el tamaño especificado al multiplo de 16 mas cercano

Tambien se puede especificar el tamaño del lv en extents con la opción -l

Para ver el estado del LV y su configuración corremos el comando lvdisplay

#lvdisplay /dev/vg01/mylv

--- Logical volumes ---

LV Name                     /dev/vg01/mylv

VG Name                     /dev/vg01

LV Permission               read/write

LV Status                   available/syncd

Mirror copies               0

Consistency Recovery        MWC

Schedule                    parallel

LV Size (Mbytes)            100

Current LE                  25

Allocated PE                25

Stripes                     0

Stripe Size (Kbytes)        0

Bad block                   on

Allocation                  strict

IO Timeout (Seconds)        default

Creacion de un FS

#newfs -F vxfs -b 8192 /dev/vg01/rmylv

    version 7 layout

    102400 sectors, 12800 blocks of size 8192, log size 128 blocks

    largefiles supported

Una vez que se le dio formato al logical volume se puede montar el FS.

#mkdir /fs1

#mount /dev/vg01/mylv /fs1

Para verificar puedo correr el comando bdf

#bdf

Filesystem          kbytes    used   avail %used Mounted on

/dev/vg00/lvol3     671744  396864  272848   59% /

/dev/vg00/lvol1    1081344  347656  728032   32% /stand

/dev/vg00/lvol8    4042752 1740360 2288608   43% /var

/dev/vg00/lvol5    4927488 2107168 2798360   43% /usr

/dev/vg00/lvol4     131072   30592   99824   23% /tmp

/dev/vg00/lvol7    5484544 3427176 2041376   63% /opt

/dev/vg00/lvol6     102400    5464   96184    5% /home

/dev/vg01/mylv      102400    2288   99344    2% /fs1

Para hacer persistente este cambio debo editar el archivo /etc/fstab

/dev/vg01/mylv /fs1 vxfs delaylog 0 2

donde el indico el LV que contiene el FS, el tipo de FS, opciones de montaje, campo reservado y el nro de secuencia en el que se hacer el chequeo de consistencia al inicio del equipo.

Con la incorporacion de OnlineJFS se puede redimensionar un FS en linea

Ampliación de un FS

Si es que hay espacio disponible en VG extendemos el tamaño del LV,

Verifico que haya espacio en el VG

#vgdisplay vg01 |egrep -e "PE Size" -e "Free PE"

PE Size (Mbytes)            4

Free PE                     474

Vemos que tenemos 1896MB disponibles en el VG. Ahora voy a extender mi LV de 100MBs a 250MBs

#lvextend -L 256 /dev/vg01/mylv

Logical volume "/dev/vg01/mylv" has been successfully extended.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

#lvdisplay  /dev/vg01/mylv

--- Logical volumes ---

LV Name                     /dev/vg01/mylv

VG Name                     /dev/vg01

LV Permission               read/write

LV Status                   available/syncd

Mirror copies               0

Consistency Recovery        MWC

Schedule                    parallel

LV Size (Mbytes)            256

Current LE                  64

Allocated PE                64

Stripes                     0

Stripe Size (Kbytes)        0

Bad block                   on

Allocation                  strict

IO Timeout (Seconds)        default

La salida del lvdisplay nos muestra reflejado el cambio en el LV, que pasa si corro un bdf ahora

#bdf /fs1

Filesystem          kbytes    used   avail %used Mounted on

/dev/vg01/mylv      102400    2288   99344    2% /fs1

Vemos que el tamaño del FS no se incremento, para ello debo correr un fsadm

#fsadm -F vxfs -b 262144 /fs1

UX:vxfs fsadm: INFO: V-3-25942: /dev/vg01/rmylv size increased from 102400 sectors to 262144 sectors

El parámetro -F indica el tipo de FS, -b indica en bloques de 1K el nuevo tamaño al cual quiero extender el FS. Para verificar corro nuevamente bdf

#bdf /fs1

Filesystem          kbytes    used   avail %used Mounted on

/dev/vg01/mylv      262144    2288  257840    1% /fs1

Reducir el tamaño de un FS en linea

El procedimiento es similar pero de manera inversa, primero se achica el FS y luego se reduce el LV. Siempre se recomienda tener un backup de los datos del FS antes de reducirlo.

Como ejemplo vamos a reducir el /fs1 a 128MBs

#fsadm -F vxfs -b 131072  /fs1

UX:vxfs fsadm: INFO: V-3-23586: /dev/vg01/rmylv is currently 262144 sectors - size will be reduced

Verificamos el FS con un bdf

#bdf /fs1

Filesystem          kbytes    used   avail %used Mounted on

/dev/vg01/mylv      131072    2288  127792    2% /fs1

Reducimos el LV para recuperar el espacio al VG

#lvreduce -L 128 /dev/vg01/mylv

When a logical volume is reduced useful data might get lost;

do you really want the command to proceed (y/n) : y

Logical volume "/dev/vg01/mylv" has been successfully reduced.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Se puede verificar el estado del lv como se hizo cuando se extendió con un lvdisplay

#lvdisplay /dev/vg01/mylv

--- Logical volumes ---

LV Name                     /dev/vg01/mylv

VG Name                     /dev/vg01

LV Permission               read/write

LV Status                   available/syncd

Mirror copies               0

Consistency Recovery        MWC

Schedule                    parallel

LV Size (Mbytes)            128

Current LE                  32

Allocated PE                32

Stripes                     0

Stripe Size (Kbytes)        0

Bad block                   on

Allocation                  strict

IO Timeout (Seconds)        default

Ampliacion sin OnlineJFS

Si no se posee OnlineJFS se puede extender un FS pero para ello necesitamos desmontarlo. En principio se extiende el LV como vimos antes, luego desmontamos el FS y por ultimo ejecutamos extendfs.

Ejemplo, extenderemos el /fs1 a 512MB

#lvextend -L 512 /dev/vg01/mylv

Logical volume "/dev/vg01/mylv" has been successfully extended.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

#umount /fs1

#extendfs /dev/vg01/rmylv

#mount /fs1

#bdf /fs1

Filesystem          kbytes    used   avail %used Mounted on

/dev/vg01/mylv      524288    2304  517920    0% /fs1

Borrado de un LV

Si no necesitamos mas un LV y queremos recuperar su espacio, podemos removerlo. Primero es una buena norma tomarun backup de los datos que contiene, desmontarlo y luego removerlo.

#mount /fs1

#lvremove /dev/vg01/mylv

The logical volume "/dev/vg01/mylv" is not empty;

do you really want to delete the logical volume (y/n) : y

Logical volume "/dev/vg01/mylv" has been successfully removed.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Borrado de un VG

Cuando no necesitemos mas un VG podemos borrarlo, existen dos maneras:

• vgremove
•  vgexport

Con vgremove, debemos primero remover todos los LV que existan en el VG

Con vgexport no es necesario borrar ningún LV del VG y corremos con la ventaja que si nos equivocamos y necesitamos recuperar el VG, solo debemos importarlo nuevamente. Específicamente cuando exportamos un VG preservamos la estructura de LVM de los discos este procedimiento quita la vinculacion de OS con el VG.

Para borrar el VG

Una vez borrados los LV corremos el vgremove

#vgremove vg01

Volume group "vg01" has been successfully removed.

Para exportar el VG

#vgchange -a n vg01

Volume group "vg01" has been successfully changed.

#vgexport vg01

vgexport: Volume group "vg01" has been successfully removed.

Si necesito volver a importar el vg corro lo siguiente

#vgimport vg01 /dev/disk/disk5

vgimport: Volume group "/dev/vg01" has been successfully created.

Warning: A backup of this volume group may not exist on this machine.

Please remember to take a backup using the vgcfgbackup command after activating the volume group.

#vgchange -a y vg01

Activated volume group.

Volume group "vg01" has been successfully changed.

Si el VG tuviera FSs ya se podrían montar y usar.

Extender un VG

Cuando nos estamos quedando sin espacio en un VG podemos extenderlo agregándole otro PV, el comando a utilizar se llama vgextend, los pasos son identificar el nuevo disco, inicializarlo y agregarlo al VG

ioscan -fnNC disk

Class     I  H/W Path  Driver S/W State   H/W Type     Description

===================================================================

disk      2  64000/0xfa00/0x0  esdisk   CLAIMED     DEVICE       HP      Virtual NullDVD

                      /dev/disk/disk2   /dev/rdisk/disk2

disk      3  64000/0xfa00/0x1  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk

                      /dev/disk/disk3      /dev/disk/disk3_p2   /dev/rdisk/disk3     /dev/rdisk/disk3_p2

                      /dev/disk/disk3_p1   /dev/disk/disk3_p3   /dev/rdisk/disk3_p1  /dev/rdisk/disk3_p3

disk      5  64000/0xfa00/0x5  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk

                      /dev/disk/disk5   /dev/rdisk/disk5

disk      7  64000/0xfa00/0x6  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk
                      /dev/disk/disk7   /dev/rdisk/disk7

En este caso el disco nuevo es el disk7

#pvcreate /dev/rdisk/disk7

Physical volume "/dev/rdisk/disk7" has been successfully created.

#vgextend vg01 /dev/disk/disk7

Volume group "vg01" has been successfully extended.

Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Para verificar y chequear el estado del VG corremos un vgdisplay

<root@test2:/dev>vgdisplay vg01

--- Volume groups ---

VG Name                     /dev/vg01

VG Write Access             read/write

VG Status                   available

Max LV                      255

Cur LV                      0

Open LV                     0

Max PV                      16

Cur PV                      2
Act PV                      2

Max PE per PV               1016

VGDA                        4

PE Size (Mbytes)            4

Total PE                    998

Alloc PE                    0

Free PE                     998

Total PVG                   0

Total Spare PVs             0

Total Spare PVs in use      0

VG Version                  1.0

VG Max Size                 65024m

VG Max Extents              16256

Aqui vemos que la tanto la cantidad de discos como el espacio libre ha aumentado.

Algunas cajas de disco pueden extender el tamaño de la LUN,  HP-UX 11v3 tiene la capacidad de notar ese cambio y reflejarlo en las estructuras de LVM.

Extension dinamica de una LUN (Dynamic LUN Expansion DLE)

Para esto primero necesitamos que nos agranden la LUN que estamos usando. Luego que nos hayan extendido la LUN corremos un vgmodify de la siguiente forma

 vgmodify -a -E /dev/vg01

HPUX IV Volume raid

En este articulo vamos a ver como interactuar con un RAID Hardware en un host HP-UX.  Este equipo presenta un disco fallado, lo que vamos hacer primero es ver los logs del kernel para obtener mas datos


#dmesg
 .....
boot device's HP-UX HW path is: 0.1.1.0.a0cf13e19130310.0

    System Console is on the Built-In Serial Interface
igelan0: INITIALIZING HP PCI-X 1000Base-T Dual-port Built-in at hardware path 0/1/2/0
igelan1: INITIALIZING HP PCI-X 1000Base-T Dual-port Built-in at hardware path 0/1/2/1
iether2: INITIALIZING HP A7012-60601 PCI/PCI-X 1000Base-T Dual-port Adapter at hardware path 0/2/1/0
iether3: INITIALIZING HP A7012-60601 PCI/PCI-X 1000Base-T Dual-port Adapter at hardware path 0/2/1/1
AF_INET socket/streams output daemon running, pid 48
afinet_prelink: module installed
Starting the STREAMS daemons-phase 1
LVM: Root VG activated
    Swap device table:  (start & size given in 512-byte blocks)
        entry 0 - major is 64, minor is 0x2; start = 0, size = 33521664
    Dump device table:  (start & size given in 1-Kbyte blocks)
        entry 0000000000000000 - major is 1, minor is 0x0; start = 2349920, size = 16760832
Create STCP device files
Starting the STREAMS daemons-phase 2
     $Revision: vmunix:    B.11.31_LR FLAVOR=perf
Memory Information:
    physical page size = 4096 bytes, logical page size = 4096 bytes
    Physical: 33533100 Kbytes, lockable: 25172052 Kbytes, available: 28646020 Kbytes

0/0/2/2.2 ms
64000/0x0/0x0.0x0 estp
64000/0x0/0x0.0x0.0x0 eslpt
255/1/0.0 tgt
255/1/0.0.0 sdisk
64000/0xfa00/0x3 esdisk
0/0/2/0.1 usbcomposite
0/0/2/0.1.0 hid
0/0/2/0.1.1 hid
....
SAS driver at 0/1/1/0 (/dev/sasd1) : RAID volume at SAS address 0x0a0cf13e19130310 is in a degraded state.
SAS driver at 0/1/1/0 (/dev/sasd1) : RAID volume at SAS address 0x0a0cf13e19130310 is in a degraded state.


En la salida vemos que nos esta alarmando que el volumen RAID esta en estado degradado, ahora que tenemos la confirmación por parte del sistema que el equipo tiene un problema vamos a revisar mas a fondo

Si bien ya tenemos el special file para comunicarnos con el driver del RAID, vamos a ver el estado del mismo via ioscan

# ioscan -fn|more
Class        I  H/W Path       Driver       S/W State   H/W Type     Description
=================================================================================
root         0                 root           CLAIMED     BUS_NEXUS
ioa          0  0              sba            CLAIMED     BUS_NEXUS    System Bus Adapter (4030)
ba           0  0/0            lba            CLAIMED     BUS_NEXUS    Local PCI-X Bus Adapter (122e)
tty          0  0/0/1/0        rmp3f01        CLAIMED     INTERFACE    PCI class(255,0) (103c1303)
tty          1  0/0/1/1        rmp3f01        CLAIMED     INTERFACE    PCI SimpleComm (103c1302)
tty          2  0/0/1/2        asio0          CLAIMED     INTERFACE    PCI Serial (103c1048)
                              /dev/diag/mux2  /dev/mux2       /dev/tty2p0
usb          0  0/0/2/0        hcd            CLAIMED     INTERFACE    NEC OHCI Controller
usbcomp      0  0/0/2/0.1      usbcomposite   CLAIMED     DEVICE       USB Composite Device
usbhid       0  0/0/2/0.1.0    hid            CLAIMED     DEVICE       USB HID Kbd(0)
                              /dev/hid/hid_000
usbhid       1  0/0/2/0.1.1    hid            CLAIMED     DEVICE       USB HID Pointer(1)
                              /dev/hid/hid_001
usb          1  0/0/2/1        hcd            CLAIMED     INTERFACE    NEC OHCI Controller
usb          2  0/0/2/2        ehci           CLAIMED     INTERFACE    NEC EHCI Controller
usbms        0  0/0/2/2.2      ms             CLAIMED     DEVICE       USB Mass Storage [0]
graphics     0  0/0/3/0        gvid_core      CLAIMED     INTERFACE    PCI Display (1002515e)
ba           1  0/1            lba            CLAIMED     BUS_NEXUS    Local PCI-X Bus Adapter (122e)
escsi_ctlr   1  0/1/1/0        sasd           CLAIMED     INTERFACE    HP  PCI/PCI-X SAS MPT Adapter
                              /dev/sasd1
ext_bus      2  0/1/1/0.0.0    sasd_vbus      CLAIMED     INTERFACE    SAS Device Interface
target      17  0/1/1/0.0.0.2  tgt            CLAIMED     DEVICE
disk         1  0/1/1/0.0.0.2.0           sdisk          CLAIMED     DEVICE       HP      IR Volume
                              /dev/dsk/c2t2d0     /dev/dsk/c2t2d0s2   /dev/rdsk/c2t2d0    /dev/rdsk/c2t2d0s2
                              /dev/dsk/c2t2d0s1   /dev/dsk/c2t2d0s3   /dev/rdsk/c2t2d0s1  /dev/rdsk/c2t2d0s3
target      16  0/1/1/0.0.0.3  tgt            CLAIMED     DEVICE
disk         8  0/1/1/0.0.0.3.0           sdisk          CLAIMED     DEVICE       HP      IR Volume
                              /dev/dsk/c2t3d0   /dev/rdsk/c2t3d0

Vemos que el estado de la controladora esta en CLAIMED y ahora vamos a indagar en el estado del Internal RAID del sistema

# sasmgr get_info -D /dev/sasd1 -q raid

Fri Jan  8 10:20:50 2016

---------- LOGICAL DRIVE 5 ----------

Raid Level                                         : RAID 1
Volume sas address                                 : 0xb852a4c047edba
Device Special File                                : /dev/rdsk/c2t3d0
Raid State                                         : OPTIMAL
Raid Status Flag                                   : ENABLED
Raid Size                                          : 69618
Rebuild Rate                                       : 0.00 %
Rebuild Progress                                   : 100.00 %

Participating Physical Drive(s) :

SAS Address         Enc   Bay   Size(MB)      Type            State

0x5000c500176a2371   1     5    70007         SECONDARY       ONLINE
0x5000c5001764d9b1   1     6    70007         PRIMARY         ONLINE

---------- LOGICAL DRIVE 7 ----------

Raid Level                                         : RAID 1
Volume sas address                                 : 0xa0cf13e19130310
Device Special File                                : /dev/rdsk/c2t2d0
Raid State                                         : DEGRADED
Raid Status Flag                                   : ENABLED
Raid Size                                          : 69618
Rebuild Rate                                       : 0.00 %
Rebuild Progress                                   : 100.00 %

Participating Physical Drive(s) :

SAS Address         Enc   Bay   Size(MB)      Type            State

0x5000c5001764f35d   1     8    70007         PRIMARY         ONLINE
0x5000c5001764a169   1     7    70007         SECONDARY       FAILED

La salida del comando nos indica cual es el disco que presenta la falla y su ubicacion para identificarlo y cambiarlo

Usando Global File System y KVM - GFS2 + KVM

En esta nota vamos a compartir un disco entre 2 hosts a los cuales le vamos a instalar GFS2 para que puedan escribir de manera concurrente. Para realizar esta configuracion vamos a utilizar en una infraestructura virtual basada en KVM (ver nota anterior de KVM) para mas detalle o profundizar conceptos).

Vamos a dar por sentado que tenemos dos maquinas virtuales funcionando

# virsh list
 Id    Name                           State
----------------------------------------------------
 1     vmCentOS1                      running
 2     vmCentOS2                      running

Primero creamos el disco virtual a compartir

qemu-img create -f raw shared.raw 5G
Formatting 'shared.raw', fmt=raw size=5368709120 

Ahora ya creado vamos a presentarlos a ambas VMs

  

Entramos al virsh

# virsh 

Presentamos los devices 

virsh # attach-disk vmCentOS1 /VMs/shared.raw vdb --shareable
Disk attached successfully

virsh # attach-disk vmCentOS2 /VMs/shared.raw vdb --shareable
Disk attached successfully

Verificamos dentro de las VMs si se ve el disco nuevo

[root@vmCentos1 ~]# fdisk -l
...

Disk /dev/vdb: 5368 MB, 5368709120 bytes
16 heads, 63 sectors/track, 10402 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

[root@vmCentos2 ~]# fdisk -l
...

Disk /dev/vdb: 5368 MB, 5368709120 bytes
16 heads, 63 sectors/track, 10402 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Para poder utilizar GFS2 necesitamos instalar los siguientes paquetes, en caso de necesitar mas debido a dependencias yum las seleccionara automaticamente

# yum install lvm2-cluster gfs2-utils

Una vez instalado tendremos que realizar la configuracion del cluster y en especial el fencing, ya que si no esta presente servicio de clvmd no levantara.

El fencing es un mecanismo que se utiliza para aislar a los nodos que no estan respondiendo dentro del cluster, en particular el GFS2/CLVMD cuando detectan una falla en un host, ejecutan el metodo de fencing y detienen las operaciones de entrada/salida hasta que termine la operacion de fencing.
Para hacer fencing vamos a usar fence-virtd, el cual lo instalamos en el host

# yum install fence-virt fence-virtd fence-virtd-libvirt fence-virtd-multicast

En las VMs solo es necesario el paquete fence-virt.
Luego de instalar debemos crear el directorio /etc/cluster y configurar el servicio de fencing
# mkdir /etc/cluster

# fence_virtd -c
Module search path [/usr/lib64/fence-virt]:

Available backends:
    libvirt 0.1
Available listeners:
    multicast 1.1

Listener modules are responsible for accepting requests
from fencing clients.

Listener module [multicast]:

The multicast listener module is designed for use environments
where the guests and hosts may communicate over a network using
multicast.

The multicast address is the address that a client will use to
send fencing requests to fence_virtd.

Multicast IP Address [225.0.0.12]:

Using ipv4 as family.

Multicast IP Port [1229]:

Setting a preferred interface causes fence_virtd to listen only
on that interface.  Normally, it listens on the default network
interface.  In environments where the virtual machines are
using the host machine as a gateway, this *must* be set
(typically to virbr0).
Set to 'none' for no interface.

Interface [none]: virbr0

The key file is the shared key information which is used to
authenticate fencing requests.  The contents of this file must
be distributed to each physical host and virtual machine within
a cluster.

Key File [/etc/cluster/fence_xvm.key]:

Backend modules are responsible for routing requests to
the appropriate hypervisor or management layer.

Backend module [checkpoint]: libvirt

The libvirt backend module is designed for single desktops or
servers.  Do not use in environments where virtual machines
may be migrated between hosts.

Libvirt URI [qemu:///system]:

Configuration complete.

=== Begin Configuration ===
backends {
    libvirt {
        uri = "qemu:///system";
    }

}

listeners {
    multicast {
        interface = "virbr0";
        port = "1229";
        family = "ipv4";
        address = "225.0.0.12";
        key_file = "/etc/cluster/fence_xvm.key";
    }

}

fence_virtd {
    module_path = "/usr/lib64/fence-virt";
    backend = "libvirt";
    listener = "multicast";
}

=== End Configuration ===
Replace /etc/fence_virt.conf with the above [y/N]? y

Ahora creamos la key que usaremos


#  dd if=/dev/urandom of=/etc/cluster/fence_xvm.key bs=4k count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.00238924 s, 1.7 MB/s

Copiamos la key a ambos guests

# scp /etc/cluster/fence_xvm.key root@vmCentOS1:/etc/cluster/fence_xvm.key

# scp /etc/cluster/fence_xvm.key root@vmCentOS2:/etc/cluster/fence_xvm.key

Para validar que la configuracion funciona, corremos desde el host fisico la siguiente linea

# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on
Desde la VM, probamos tambien si la configuracion tuvo exito

[root@vmCentos1 ~]# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on

Desde la otra VM tambien lo probamos

[root@vmCentos2 ~]# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on

Ya aqui estamos en condiciones de poder hacer otro tipo de prueba como el reboot o el apagado de un nodo por medio del fencing

[root@vmCentos1 ~]# fence_xvm -o reboot -H vmCentOS2

Si todo se configuro correctamente, en este momento se debio haber reiniciado el vmCentOS2.
Ahora generaremos un template basico para nuestro cluster

<cluster name="cluster1" config_version="2">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="vmCentOS1.domain" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="vmCentOS2.domain." nodeid="2">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
     <fencedevice agent="fence_xvm" name="virtfence1" key_file="/etc/cluster/fence_xvm.key" multicast_address="225.0.0.12"/>
   </fencedevices>
   <rm>
   </rm>
 </cluster>

Con la configuracion creada podemos levantar y configurar el servicio de cluster 

[root@vmCentos1 cluster]# chkconfig cman on
[root@vmCentos2 cluster]# service cman start
Starting cluster:
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Tuning DLM kernel config...                             [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]

Ahora copiamos el /etc/cluster/cluster.conf al otro nodo del cluster y levamtamos y configuramos el cman igual que en el vmCentOS1

En este momento podemos levantar el servicio de clvmd

[root@vmCentos1 ~]# service clvmd start
Starting clvmd: dlm: Using TCP for communications

Activating VG(s):   2 logical volume(s) in volume group "vg_vmcentos1" now active
  clvmd not running on node vmCentOS2.domain.
[  OK  ]


Corremos el mismo comando desde el nodo 2, en mi caso vmCentOS2 y ya finalmente estamos en condiciones de poder comartir el volumen.

Ahora pasamos a la configuracion de LVM, todos estos pasos son iguales a cuando trabajamos sin cluster, proximamante voy hacer una guia de LVM para Linux aunque es muy similar a lo que es HP-UX, de la cual si tengo una entrada en el blog

Primero creamos el physical volume 
[root@vmCentos1 ~]# pvcreate  /dev/vdb
  Physical volume "/dev/vdb" successfully created

Segundo creamos el volume group

[root@vmCentos1 ~]# vgcreate vgshared /dev/vdb
  Clustered volume group "vgshared" successfully created

Tercero creamos un logical volume

[root@vmCentos1 ~]# lvcreate -L 1024 -n lvol1 vgshared
  Logical volume "lvol1" created

Como ultimo paso nos resta darle formato al volumen, formato que sera gfs2, las opciones del comando son, 

-p tipo de lock, en este caso es un lock distribuido entre los nodos, 
-t  nombre de cluster seguido, el nombre del filesystem separado por :
-j la cantidad de journals a crear, que indica la cantidad de nodos que comparten el filesystem, en este caso configure 5 por un tema de escalabilidad.

[root@vmCentos1 ~]# mkfs.gfs2 -p lock_dlm -t cluster1:fsvgsharedlvol1 -j 5 /dev/vgshared/lvol1
This will destroy any data on /dev/vgshared/lvol1.
It appears to contain: symbolic link to `../dm-2'

Are you sure you want to proceed? [y/n] y

Device:                    /dev/vgshared/lvol1
Blocksize:                 4096
Device Size                1.00 GB (262144 blocks)
Filesystem Size:           1.00 GB (262142 blocks)
Journals:                  5
Resource Groups:           4
Locking Protocol:          "lock_dlm"
Lock Table:                "cluster1:fsvgsharedlvol1"
UUID:                      09053a2a-5a43-3c7d-d46a-919586c612b2

Corremos un vgscan en el nodo2 para importar la configuracion

Agregamos las entradas correspondientes en ambos /etc/fstabs

#
## FSs compartidos gfs2
#

/dev/mapper/vgshared-lvol1    /sharedfs    gfs2   defaults,acl    0 0

creamos el punto de montaje en ambos nodos

# mkdir /sharedfs

Montamos el filesystem, en este paso tendremos tambien que activar el servicio de gfs2 para que cuando reiniciemos las VMs estas monten automaticamente el FS que creamos, esta de mas decir que estas operaciones tambien se deben realizar en ambos nodos

# chkconfig gfs2 on
# mount /sharedfs
 
Verificamos que este montado

[root@vmCentos1 /]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg_vmcentos1-lv_root
                       9845280   2411808   6933352  26% /
tmpfs                   510208     28744    481464   6% /dev/shm
/dev/vda1               495844     55904    414340  12% /boot
/dev/mapper/vgshared-lvol1
                       1048400    661916    386484  64% /sharedfs
 
Corremos un mount -v para ver el tipo de filesystem

[root@vmCentos1 /]# mount -v
/dev/mapper/vg_vmcentos1-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/vda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/vgshared-lvol1 on /sharedfs type gfs2 (rw,seclabel,relatime,hostdata=jid=1,acl)

 Como prueba final vamos a escribir en nuestro FS desde los dos nodos, primero vamos a ver el contenido del /sharedfs

[root@vmCentos1 sharedfs]# ls -la
total 8
drwxr-xr-x.  2 root root 3864 May  3 12:13 .
dr-xr-xr-x. 27 root root 4096 May  3 11:51 ..
y

[root@vmCentos2 sharedfs]# ls -al
total 8
drwxr-xr-x.  2 root root 3864 May  3 12:13 .
dr-xr-xr-x. 27 root root 4096 May  3 11:50 ..
[root@vmCentos2 sharedfs]# 

Ahora vamos a escribir unos archivos 

Primero desde el vmCentos1

[root@vmCentos1 sharedfs]# echo hola > hola
 
Luego en el vmCentos2

[root@vmCentos2 sharedfs]# echo mundo > mundo

Verificamos desde ambos nodos

Desde el vmCentos1

[root@vmCentos1 sharedfs]# ls
hola  mundo

y luego desde el vmCentos2




[root@vmCentos2 sharedfs]# ls
hola  mundo