Create oVirt/RHEV’s VM backup

Create backup of oVirt / RHEV’s VMs

[TOC]

Introduction

I’ve been working with oVirt since version 3.5 as main virtualization platform, from day one i were looking for a tool to create VM backups based on snapshot as many solutions does with VMWARE, after some research i didn’t find a tool that fulfilled my requirements so i decided to create one using oVirt python API.

Requirements

  • oVirt >= 4.0
  • Virtual machine with CentOS 7 with this tools installed, we’ll call this VM bkpvm
  • bkpvm should be on the same oVirt Datacenter of the VM we need to take backup of
  • bkpvm should have enought space to store backups
  • Storage Domain should have enought space to take snapshots

How does it work?

This script should run on bkpvm and it connect to oVirt API to do:
– Create snapshot
– Attach disk to bkpvm
– Create a qcow2 file of the VM’s disk
– Delete snapshot

After finish it creates a qcow2 file for each VM’s disk

Instalation

Prerequisites

Install required repositories on bkpvm:

yum install -y epel-release
yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

Install required packages from repositories configured:

yum install -y qemu-img python-ovirt-engine-sdk4 python-requests git ovirt-guest-agent wget

Download

cd /opt
git clone https://github.com/vacosta94/VirtBKP.git

We need to get our oVirt’s CA in order to establish secure connections to oVirt API

cd /opt/VirtBKP
wget --insecure "https://ovirt.infratic.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA"

Usage

Configure

There is a configuration file default.conf inside VirtBKP folder, that file have all the parameters required by the tool. Should modify this file according your environment as follow:

vim /opt/VirtBKP/default.conf
[bkp]
url             = https://ovirt.example.com/ovirt-engine/api
user            = admin@internal
password        = password
ca_file         = ca.crt
bkpvm           = bkpvm
bckdir          = /mnt/

[restore]
url             = https://ovirt.example.com/ovirt-engine/api
user            = admin@internal
password        = password
ca_file         = ca.crt
storage         = gfs_pool0
proxy           = ovirt.example.com
proxyport       = 54323
  • url: oVirt API URL
  • user: User name
  • password: User password
  • ca_file: Path to ca.crt
  • bkpvm: Name of our bkpvm
  • bckdir: Path to store backups in .qcow2 format
  • storage: Storage domain where we’ll restore our backups
  • proxy: IP or hostname of the ovirt-image-proxy host (Default: ovirt-engine)
  • proxyport: TCP port of the ovirt-image-proxy (Default: 54323)

Create backup

In order to create backups of virtual machines you should use the syntax bellow:

/opt/VirtBKP/backup_vm.py <configuration_file> <vm_name>

Example:

/opt/VirtBKP/backup_vm.py /opt/VirtBKP/default.conf webserver

Restore backup

In order to restore an existing backup you should use the syntax bellow:

/opt/VirtBKP/upload_disk.py <configuration_file> <qcow2_file>

Example

/opt/VirtBKP/upload_disk.py /mnt/webserver_2017-04-28-00h.qcow2

Crear backup de maquinas virtuales oVirt

Crear backup de maquinas virtuales oVirt

Introduccion

Vengo trabajando con oVirt desde la version 3.5 como plataforma de virtualizacion tanto para ambientes de laboratorio, ambientes de produccion y hasta este mismo sitio, desde el inicio busque una forma facil de crear backups de maquinas virtuales basadas en snapshots, luego de investigar encontre de que existia una API pensada para realizar backups de maquinas virtuales, investigando un poco mas encontre scripts que permitian exportar maquinas virtuales de forma a tener un respaldo de las mismas.

Si bien esa solucion me sirvio durante mucho tiempo, rapidamente se volvio muy poco practica a medida que las maquinas virtuales que alojaba crecian, por el simple hecho de que esta solucion necesitaba 3 veces el tamaño de tu maquina virtual debido a que antes de exportar la maquina, la debe clonar.

Una vez que el espacio se volvio un problema decidi, crear mi propio script de backup para maquinas virtuales sobre oVirt.

El proceso es quizas un poco mas complejo que la solucion que acabo de comentar pero necesito menos espacio en disco!. En este documento detallare como funciona y como utilizar la herramienta que cree, espero que le sirva a alguien.

Como funciona

Requisitos:

Los requisitos para utilizar esta solucion son los siguientes:

  • oVirt >= 4.0
  • Una maquina virtual CentOS 7 a la que llamaremos bkpvm
  • Esta maquina virtual debe estar en el mismo Datacenter que las VMs a las que queremos respaldar
  • Esta maquina virtual debe tener espacio suficiente para copiar el disco virtual de las VMs

Que hace exactamente

El script se debe ejecutar en la bkpvm y la misma debe poder acceder a los dominios de almacenamiento donde estan los discos de las maquinas que queremos respaldar.
Los pasos que ejecuta el script son los siguientes:

  • Se conecta a la API de oVirt
  • Crea un snapshot de la maquina que queremos respaldar
  • Adjunta el disco del snapshot a la bkpvm
  • Crea una imagen qcow2 del disco en cuestion
  • Elimina el snapshot
  • Se desconecta de la API de oVirt

Al terminar en forma de respaldo nos queda un archivo qcow2 que no es mas que el disco de la maquina virtual, este archivo lo podemos luego subir al oVirt.

Descargar y utilizar la herramienta

Descargar

Una vez que tenemos nuestra bkpvm instalada debemos instalar un par de paquetes que utiliza el script
Primero debemos habilitar epel y el repositorio de oVirt

yum install -y epel-release
yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

Luego instalamos las librerias necesarias de python

yum install -y qemu-img python-ovirt-engine-sdk4 python-requests git

Luego descargamos la ultima version de la herramienta

cd /opt
git clone https://github.com/vacosta94/VirtBKP.git

Obtener CA de nuestro oVirt, deben reemplazar ovirt.example.com por la url de acceso de su oVirt

cd /opt/VirtBKP
curl --insecure "https://ovirt.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA" -o ca.crt;

Configurar

Dentro de la carpeta VirtBKP existe un archivo llamado default.conf, ese archivo es el ejemplo de configuracion que utiliza la herramienta, deben modificar ese archivo con sus datos de acceso, el archivo debe quedar de la siguiente forma:

vim /opt/VirtBKP/default.conf
[bkp]
url            = https://ovirt.example.com/ovirt-engine/api
user        = admin@internal
password    = password
ca_file        = ca.crt
bkpvm        = bkpvm
bckdir         = /mnt/

[restore]
url            = https://ovirt.example.com/ovirt-engine/api
user        = admin@internal
password    = password
ca_file        = ca.crt
storage        = gfs_pool0
proxy        = ovirt.example.com
proxyport    = 54323
  • url Es la URL de nuestro oVirt
  • user El usuario a utilizar para las tareas de backup
  • password Password de dicho usuario
  • ca_file Ruta del ca.crt que descargamos anteriormente
  • bkpvm Nombre de la maquina virtual que creara los backups, este nombre debe ser el nombre que se ve en el portal de administracion de oVirt
  • bckdir Directorio donde se almacenaran los archivos .qcow2
  • storage Dominio de almacenamiento donde se restaurara la imagen .qcow2, este nombre debe ser el nombre que se ve en el portal de administracion de oVirt
  • proxy Equipo que se utilizara como proxy para restaurar la imagen qcow2
  • proxyport Puerto de dicho proxy 54323 es el puerto por defecto del ovirt-image-io-proxy

Crear backup

Para crear backups de maquinas virtuales la sintaxis es la siguiente

python /opt/VirtBKP/backup_vm.py <archivo_conf> <nombre_vm_respaldar>

Por ejemplo para crear un backup de una VM de nombre webserver utilizando la configuracion cargada en el archivo default.conf

python /opt/VirtBKP/backup_vm.py default.conf webserver

Restaurar backup

Para restaurar un backup la sintaxis en la siguiente

python /opt/VirtBKP/upload_disk.py <archivo_conf> <archivo_qcow2>

El archivo qcow2 es el archivo que se creo durante la tarea de respaldo, por ejemplo si el archivo se encuentra en /mnt/webserver_2017-04-28-00h.qcow2

python upload_disk.py /mnt/webserver_2017-04-28-00h.qcow2

Forzar replicacion csync2

Forzar replicacion de directorios csync2

En caso de que tengamos implementada la replicacion de archivos via csync2es probable que existan casos en los que necesitemos forzar la replicacion de archivos manualmente ya sea para asegurarnos que esta todo replicado o para identificar problemas

Identificar configuración

Lo primero que tenemos que hacer es identificar para que configuración o para que directorio queremos forzar la replicacion

Las configuraciones las podemos encontrar dentro del directorio /etc/csync2/

El csync2 permite tener varias configuraciones diferentes y dentro de cada configuración podemos definir uno o mas directorios que se replicaran, estas configuraciones se definen en los archivos /etc/csync2/csync2_nombreconf.cfg, donde nombreconf es el nombre de la configuración.

Forzar la replicacion

Una vez identificado el nombre de la configuración podemos forzar la replicacion con el siguiente comando

csync2 -C nombreconf -xXvrB

Ejemplo, si nuestra configuración se llama www

csync2 -C www -xXvrB

Explicación de las opciones utilizadas:

  • C: Para identificar la configuración
  • x: Verifica todos los archivos y sus actualizaciones
  • X: Verifica archivos borrados
  • r: Verifica de forma recursiva directorios y sub-directorios
  • B: No bloquea la base de datos sqlite con grandes transacciones
  • v: habilita el modo verbose, se puede habilitar mas nivel de detalle agregando la opción varias veces. Ejemplo: csync2 -C www -xXvvvvrB

En algunos casos la replicacion falla debido a que faltan directorios padres en los otros equipos, en estos casos existen 2 soluciones:

  • Sincronizar la estructura de directorio a mano, esto seria crear a mano los directorios faltantes en los demás nodos
  • Ejecutar la sincronizacion en modo ejecución inicial, esto se hace agregando la opción -I, esto es un tanto arriesgado porque podemos llegar a perder datos, se debe ejecutar en el nodo que tiene la ultima versión de los datos

Instalar Haroopad en Fedora 23

Instalar Haroopad en Fedora 23

Que es Haroopad?

Haroopad es una herramienta que nos permite crear y modificar documentos utilizando MarkDown de forma sencilla y no requiere muchos recursos de hardware a diferencia de otros editores que tienden a consumir mucha memoria RAM.

Abajo un print de la herramienta en ejecucion:
https://i2.wp.com/blog.infratic.com/imagenes/haroopad/haroopad_screen.png?w=648

Pueden encontrar mas informacion sobre la herramienta en su pagina oficial:
http://pad.haroopress.com

Instalando Haroopad

Las tareas que demos seguir para instalar haroopad en Fedora son:

  • Instalar los paquetes necesarios
  • Descargar la version para Debian de 64 o 32 bits
  • Convertir el paquete .deb a .rpm
  • Instalar el paquete .rpm

Instalar los paquetes necesarios

Los dos paquetes que estaremos necesitando son wget y alien.

  • wget: para descargar Haroopad
  • alien: para convertir de .deb a .rpm

Esto lo hacemos con el comando dnf

dnf install -y wget alien

Descargar Haroopad

Para 32 bits:

cd /tmp
wget "https://bitbucket.org/rhiokim/haroopad-download/downloads/haroopad-v0.13.1-ia32.deb"

Para 64 bits:

cd /tmp
wget "https://bitbucket.org/rhiokim/haroopad-download/downloads/haroopad-v0.13.1-x64.deb"

Convertir el paquete a .rpm

Para esto utilizamos el comando alien
32 bits:

alien /tmp/haroopad-v0.13.1-ia32.deb --to-rpm --scripts

64 bits:

alien /tmp/haroopad-v0.13.1-x64.deb --to-rpm --scripts

Instalar el .rpm de Haroopad

Para esto utilizamos el comando rpm
32 bits:

rpm -ivh --nodeps /tmp/haroopad-v0.13.1-ia32.rpm

64 bits:

rpm -ivh --nodeps /tmp/haroopad-v0.13.1-x64.rpm

Finalmente esto nos deberia de crear una entrada en el menu de aplicaciones, tambien podemos usar Haroopad ejecutando desde la linea de comandos:

haroopad

Configurar Let’s Encrypt con HaProxy en RHEL/CentOS/SL 7

Configurar Let's Encrypt con HaProxy en RHEL/CentOS/SL 7

Let's ecnypt nos sirve de CA para tener nuestros certificados firmados sin necesadidad de pagar por ello, este es el motivo por el cual se volvio tan famoso los ultimos tiempos, "Seguridad Gratis!"

En este documento demostraremos como configurar let's encrypt con HaProxy para proteger nuestros sitios HTTP

Primero debemos instalar todos los paquetes necesarios

Instalar paquetes necesarios

yum install git bc

Descargar letsencrypt

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Creacion del certificado

Antes de crear el certificado

Es muy importante que nos aseguremos que exista un registro DNS publico para el nombre de dominio para el cual queremos crear el certificado y que apunte a la IP de nuestro HaProxy, tambien debemos bajar el HaProxy debido a que el plugin standalone de la herramienta certbot necesita abrir los puertos 80 y 443, debemos de asegurarnos que desde internet se pueda acceder a los puerto 80 y 443 de nuestro servidor.

service haproxy stop

Ejecutar Let's Encrypt y obtener nuestro certificado

El comando letsencrypt-auto se encarga de instalar y configurar todas las dependencias que necesitamos para crear nuestros certificados.

Las opciones que utilizamos son las siguientes:

-d dominio.com: Aqui ingresamos el dominio para el cual queremos crear el certificado
-m maildeladministrador@dominio.com: Aqui ingresamos el correo del administrador, este correo nos podria ayudar en el futuro para recuperar los archivos .key
--agree-tos: Esta opcion acepta los terminos de servicio de let's encrypt

# /opt/letsencrypt/letsencrypt-auto certonly --standalone -d www.infratic.com -m vic.ad94@gmail.com --agree-tos
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for www.infratic.com
Waiting for verification...
Cleaning up challenges
 
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/www.infratic.com/fullchain.pem. Your cert
   will expire on 2017-08-08. To obtain a new or tweaked version of
   this certificate in the future, simply run letsencrypt-auto again.
   To non-interactively renew *all* of your certificates, run
   "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:
 
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Esto nos tuvo que crear los siguientes archivos en el directorio /etc/letsencrypt/live/dominio.com/

La descripcion de los diferentes archivos que se encuentran en dicho directorio son las siguientes

cert.pem: Your domain's certificate
chain.pem: The Let's Encrypt chain certificate
fullchain.pem: cert.pem and chain.pem combined
privkey.pem: Your certificate's private key

Configurar HaProxy para usear certificados

Preparando los ceriticados

Ahora debemos crear el .pem para el haproxy dentro de la carpeta /etc/haproxy/certs

# mkdir /etc/haproxy/certs
# cat /etc/letsencrypt/live/www.infratic.com/fullchain.pem /etc/letsencrypt/live/www.infratic.com/privkey.pem >> /etc/haproxy/certs/www.infratic.com.pem

Luego debemos crear el archivo /etc/haproxy/certs/list.txt que nos permitira tener varios dominios con sus respectivos certificados en el mismo balanceador

El archivo debe tener la siguiente sintaxis

/ruta/archivo/dominio.com.pem dominio.com

En este caso

/etc/haproxy/certs/www.infratic.com.pem       www.infratic.com

Para esto podemos usar el comando echo

# echo "/etc/haproxy/certs/www.infratic.com.pem       www.infratic.com" >>  /etc/haproxy/certs/list.txt

Configurando HaProxy

Lo que debemos hacer en nuestro HaProxy es definir la lista de certificados para el frontend o listen
En este caso configuraremos nuestro frontend el cual tendra un solo backend, recuerden que pueden tener mas backend utilizando ACLs en el frontend

Configurar el frontend

Creamos el frontend que escuchara en el puerto 443 y publicara nuestro certificado agregando las siguientes lineas al archivo /etc/haproxy/haproxy.cfg.

En el frontend se crea una ACL llamada letsencrypt-acl del tipo path_beg, esta ACL nos servira mas adelante al momento de renovar los certificados

frontend www-https
   bind 0.0.0.0:443 ssl crt-list /etc/haproxy/certs/list.txt
   reqadd X-Forwarded-Proto:\ https
   acl letsencrypt-acl path_beg /.well-known/acme-challenge/
   use_backend letsencrypt-backend if letsencrypt-acl
   default_backend www-backend

Configurar el backend

Creamos nuestro backend agregando las siguientes lineas al archivo /etc/haproxy/haproxy.cfg

backend b_webfarm
    mode http
    option forwardfor
    balance source
    cookie SRVNAME insert nocache
    server  av-app1 av-app1.infratic.com:80 cookie S1 check port 80 inter 10s weight 1
    server  av-app2 av-app2.infratic.com:80 cookie S2 check port 80 inter 10s weight 10

Luego debemos crear un backend que se utiliza para las validaciones de letsencrypt, que nos permite actualizar luego el certificado sin detener el servicio haproxy, este backend es referenciado en el fronted que creamos previamente, para eso agregamos las siguientes lineas al archivo /etc/haproxy/haproxy.cfg

backend letsencrypt-backend
   server letsencrypt 127.0.0.1:54321

Configurar renovacion automatica

Los certificados de Let's Encrypt tienen una duracion maxima de 90 dias, en este caso configuraremos la auto-renovacion cada 2 meses de forma a que tengamos tiempo para resolver problemas de autualizacion en caso de que se presenten
Para esta tarea crearemos un script que reciba como parametro el nombre del dominio y ejecute todos los comandos necesarios para la renovacion

# vi /opt/letsencrypt/renew.sh

Y agregamos lo siguiente

#!/bin/bash
dominio=$1
/opt/letsencrypt/letsencrypt-auto certonly --agree-tos --renew-by-default --standalone-supported-challenges http-01 --http-01-port 54321 -d $dominio
cat /etc/letsencrypt/live/$dominio/fullchain.pem /etc/letsencrypt/live/$dominio/privkey.pem >> /etc/haproxy/certs/$dominio.pem
service haproxy reload

Luego asignamos permisos de ejecucion al script

chmod 755 /opt/letsencrypt/renew.sh

Ahora debemos agregar una tarea cron que ejecute este script cada 2 meses

crontab -e

Y agregamos

00 02 * */2 * /opt/letsencrypt/renew.sh

Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

El problema al momento de querer extender un disco virtual o lun de datos es que por mas que el sistema operativo reconozca el tamaño nuevo del disco, al momento de querer utilizar ese espacio nuevo es necesario extender la particion, o de utlima crear una particion nueva. Esto requiere reinicios en caso de que el disco se este utilizando, el reinicio es para que el S.O. vuelva a leer la tabla de particiones.

La forma de evitar tener que reiniciar cada vez que querramos extender nuestra LUN o disco virtual es implementando LVM sobre el disco directo sin particion

Primero crearemos el Volume Group de forma directa sobre la LUN o disco virtual

En este ejemplo lo haremos con un disco virtual exclusivo para datos de 10GB que es el /dev/sdb

Lo primero que tenemos que hacer es verificar que el S.O. vea el disco

# fdisk -l /dev/sdb
 
Disk /dev/sdb: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Verificamos que el disco este vacio

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

No nos muestra nada por lo tanto esta vacio

Formateamos el disco completo como Physical Volume

# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Creamos un Volume Group

# vgcreate testvg /dev/sdb
  Volume group "testvg" successfully created

Luego creamos un Logical Volume de pruebas con 8G

# lvcreate -n testlv -L8G testvg
  Logical volume "testlv" created.

Creamos un FS XFS sobre el volumen y lo montamos en el /mnt

# mkfs.xfs /dev/testvg/testlv
# mount  /dev/testvg/testlv /mnt
# df -h /mnt/
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv   8,0G    33M  8,0G   1% /mnt

Ahora ampliamos el disco desde la consola de administracion de VMWARE o el virtualizador que usemos (esto no lo voy a mostrar aca)

Es necesario re-escanear el disco desde el S.O. para que este vea el nuevo tamaño

Esto lo hacemos con el siguiente comando:

echo 1 > /sys/class/block/#dispositivo/device/rescan

Donde #dispositivo es el nombre de nuestro disco en cuestion, en este caso lo haremos sobre la sda.

echo 1 > /sys/class/block/sdb/device/rescan

Hecho esto el S.O. ya deberia reconocer el nuevo tamaño, por ende podemos ampliar nuestra particion

#  fdisk -l /dev/sdb
 
Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Luego debemos extender el Physical Volume

# pvresize /dev/sdb
  Physical volume "/dev/sdb" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
# vgs testvg
  VG     #PV #LV #SN Attr   VSize  VFree
  testvg   1   1   0 wz--n- 20,00g 12,00g

Con el comando vgs verificamos que el Volume Group reconocio el nuevo espacio. Luego podemos extender nuestro Logical Volume para que llegue a los 18G

# lvresize -L18G /dev/testvg/testlv
  Size of logical volume testvg/testlv changed from 8,00 GiB (2048 extents) to 18,00 GiB (4608 extents).
  Logical volume testlv successfully resized.

Con esto ya podemos extender nuestro FileSystem

# xfs_growfs /dev/testvg/testlv
meta-data=/dev/mapper/testvg-testlv isize=256    agcount=4, agsize=524288 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2097152 to 4718592
 
 
# df -h /dev/testvg/testlv
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv    18G    33M   18G   1% /mnt

Con esto evitamos la necesidad de reiniciar nuestros equipos para extender nuestros discos virtuales o LUNs

Uno de los puntos mas importantes es detectar si los discos contienen datos antes de formatearlos.

Detectar si un disco esta siendo utilizado

Para detectar si un disco esta siendo utilizado podemos utilizar el comando dd de la siguiente forma:

dd if=/dev/sdb bs=512 count=2 |strings
Si el disco esta vacio deberia mostrar algo parecido a lo siguiente

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

En caso que tenga LVM deberia de mostrar algo parecido a lo siguiente:

# dd if=/dev/sdb bs=512 count=2 | strings
2+0 records in
2+0 records out
LABELONE
LVM2 0016hxjXHBW8Bm1xLnQZoEBDoKzWi0x8IRG
1024 bytes (1.0 kB) copied, 7.9217e-05 s, 12.9 MB/s

Medir rendimiento de red en Linux RHEL/CentOS/SL

qperf: Medir rendimiento de red en Linux RHEL/CentOS/SL

qperf es una herramienta que nos permites hacer numerosas pruebas de rendimiento de conectividad entre 2 nodos, estas pruebas pueden ir desde ancho de banda hasta latencia del vinculo.

Instalar la herramienta

Antes de comenzar debemos de instalar nuestra herramienta de benchmark qperf, la misma se encuentra dentro de los repositorios oficiales de CentOS/RHEL, por lo tanto podemos instalarlo via yum

yum install -y qperf

Una vez instalada la herramienta debemos tener en cuenta un par de aspectos sobre el funcionamiento de la misma.

Basicamente qperf trabaja de la siguiente manera:

  • Paso 1: En uno de los nodos (puede ser cualquier de los 2), debemos ejecutar el comando qperf solo. Al ejecutarlo de esa manera el qperf abre el puerto 19765.
    qperf
  • Paso 2: En el otro nodo debemos ejecutar el comando qperf con la sintaxis de prueba de rendimiento que seria la siguiente:
    qperf SERVERNODE [OPTIONS] TESTS

    Al ejecutarlo lo que hace es conectarse al puerto 19765 del otro nodo y realizar la prueba solicitada por el usuario.

Lo mas importante a tener en cuenta con el qperf es que establece una conexion entre los dos nodos, por lo tanto en caso de que los equipos tengan cortafuegos habilitados podrian bloquear las pruebas

Pruebas que puede realizar qperf

La herramienta qperf tiene una gran lista de pruebas que puede realizar, podemos consultar dicha lista con el siguiente comando:

qperf --help tests

En este caso nos enfocaremos en 2 pruebas:

tcp_bw: Ancho de banda utilizable para conexiones TCP
tcp_lat: Latencia al abrir una conexion TCP

Ejemplo de uso de qperf

TCP Bandwith

Primero ejecutamos qperf en el nodo 2

[root@node2 ~]# qperf

Luego ejecutamos la prueba en el otro nodo

[root@node1 ~]#   qperf node2 tcp_bw
tcp_bw:
    bw  =  53.6 MB/sec

En este ejemplo nuestro ancho de banda para conexiones TCP es de 53,6 MB/s

TCP Latency

Primero ejecutamos qperf en el nodo 2

[root@node2 ~]# qperf

Luego ejecutamos la prueba en el otro nodo

[root@node1 ~]# qperf node2 tcp_lat
tcp_lat:
    latency  =  35.7 us

En este ejemplo nuestra latencia es de 35.7 us

Es muy importante tener en cuenta que la carga de red al momento de las pruebas puede afectar a los resultados

Analizar Crash/Core dump HP-UX

Analizar crash HPUX

Para analizar los crash que se generan en HPUX utilizaremos el comando kwdb

Lo primero que debemos hacer es identificar el directorio del crash dentro de /var/adm/crash/crash.N donde N es el numero de crash generado

Luego debemos acceder a dicho directorio

cd /var/adm/crash/crash.1

E ingresamos a las consola del kwdb con el siguiente comando:

kwdb -q4 -p -m .

Una vez adentro activamos 14

q4> set kwdb q4 on

Luego ejecutamos los reportes WhatHappened, WhatHappened -HANG y Analyze AU

Los mismos los redireccionamos a los archivos what.out, whath.out y ana.out respectivamente

q4> run WhatHappened > what.out 
processing ....... done!
 
q4> run WhatHappened -HANG > whath.out
processing ....... done!
 
q4> run Analyze AU > ana.out 
processing ....... done!
 
q4> exit

Luego nada mas nos queda leer estos 3 archivos para ver que errores encontramos

more what.out
 
more whath.out
 
more ana.out

Avoid ARP requests RHEL/CentOS/SL

Avoid ARP requests RHEL/CentOS/SL

To avoid send or receive arp request we can use arptables, this tool is very similar to iptables

Install arptables

yum install -y arptables

Avoid send ARP requests to specific host

As iptables in arptables you can use -d flag to determine destination.

And if we want to create a rule for the arp packages we send, we must use OUTPUT chain

Example, to avoid sending request to 192.178.1.1:

arptables -A OUTPUT -d 192.178.1.1 -j DROP

Avoid receive ARP requests from specific host

As iptables in arptables you can use -s flag to determine source.

An if we want to create a rule for the arp packages we receive, we must use INPUT chain

Example, to avoid receive request to 192.178.1.1:

arptables -A INPUT -s 192.178.1.1 -j DROP

To make those changes persistents, we must save configuration:

arptables-save  > /etc/sysconfig/arptables

then start and enable arptables service

service arptables start
 
chkconfig arptables on

Solucionar error failed to load selinux policy freezing RHEL/CentOS 7

Solucionar error failed to load selinux policy freezing

Este error se da debido a que los archivos no tienen etiqueta selinux, este error se podria dar por ejemplo cuando cambiamos la politica de SeLinux de disabled a enforcing.
La manera de solucionar esto es iniciando el equipo sin SELinux activo y forzar el re-etiquetado de todos los archivos

Deshabilitar SeLinux durante el proceso de arranque

El selinux se puede deshabilitar en la linea de arranca del grub, para esto debemos editar la linea de arranque del grub y al final de los parametros del kernel se debe agregar, selinux=0

Una vez hecho esto iniciamos el equipo y una vez adentro activamos el selinux en modo permissive, para esto el archivo /etc/selinux/config debe quedar de la siguiente manera:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

y creamos el archivo /.autorelabel para que fuerce el re-etiquetado de todos los archivos del FS

touch /.autorelabel

Luego debemos reiniciar el equipo, al siguiente inicio debera re-etiquetar todos los archivos (esto podria tardar bastante, dependiendo de la cantidad de archivos que tenga cada FS), una vez que termine el re-etiquetado y nos permita ingresar al sistema podemos activar en selinux con el comando

setenforce 1

Luego activamos de manera permanente el SELinux, para esto el archivo /etc/selinux/config debe quedar de la siguiente manera:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Una vez que terminamos todos los pasos, se recomienda reiniciar una vez mas el equipo para asegurarse de que el SELinux se active de manera automatica y que el equipo inicie sin problemas