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

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

Instalacion y configuracion de HAProxy en CentOS/RHEL 6/7

haproxy

HaProxy

Instalacion de HaProxy

El servicio haproxy es parte del paquete “haproxy” que podemos instalar via yum

yum install -y haproxy

El archivo de configuracion principal del servicio es el /etc/haproxy/haproxy.cfg dicho archivo esta separado en 3 partes, global, defaults y luego las configuraciones de los distintos servicios, los mismos pueden ser de tipo frontend, backend o listen

Abajo un ejemplo de configuracion basico de global:

global
    log             127.0.0.1 local2
    chroot          /var/lib/haproxy
    pidfile         /var/run/haproxy.pid
    maxconn         4000
    user            haproxy
    group           haproxy
    stats socket    /var/lib/haproxy/stats
    daemon

log : Direccion IP y facility que utilizara el demonio para guardar registros via Syslog
chroot : Ruta de ejecucion y enjaulamiento del demonio
pidfile : Ruta del archivo PID
maxconn : Numero maximo de conexiones concurrentes que aceptara el demonio
user : Usuario con el cual se ejecuta el demonio
group : Grupo con el cual se ejecuta el demonio
daemon : Modo en el que se levantara el proceso, por defecto daemon ya que se utiliza como servicio del S.O.
stats socket : Ruta del archivo socket para las estadisticas, el mismo puede ser consultado con el comando socat


Ejemplo de configuracion basica de defaults

Las configuraciones defaults son las que se setean por defecto para cada frontend, backend o listen que creemos.

defaults
    mode        http
    maxconn     3000
    option      dontlognull
    option      http-server-close
    option      redispatch
    retries     3
    timeout http-request        1m
    timeout queue               1m
    timeout connect             10s
    timeout client              10m
    timeout server              10m
    timeout http-keep-alive     10s
    timeout check               10s
    tcplog

mode : El modo default en el cual trabajaran los frontend, backend y listen, puede ser tcp o http
maxconn *: Cantidad maxima de conexiones para cada frontend, backend o listen *
option dontlognull : Evita que se registre en los logs repuestas nulas o vacias
option http-server-close : Fuerza el cierre de la conexion una vez que se recibio la respuesta del servidor backend
option redispatch : Activa la redistribución de sesión en caso de fallo de conexión
retries : Numero de intentos sobre un servidor luego de un fallo de conexion
timeout http-request *: Tiempo de espera para recibir la respuesta HTTP completa *
timeout queue : Tiempo de espera para las conexiones que estan en espera
timeout connect : Tiempo de espera para que el servidor acepte la conexion
timeout client : Tiempo maximo de inactividad del lado del cliente
timeout server : Tiempo maximo de inactividad del lado del servidor
timeout http-keep-alive : Tiempo maximo de espera para reutilizar una conexion HTTP
timeout check : Tiempo maximo de espera para que los servidores respondan los chequeos luego de abrir la conexion
tcplog : Modo de logueo, los mas utilizados son tcplog y httplog, tcplog registra las peticiones y que nodo atendio la misma, httplog registra la URL solicitada por el cliente


Definicion de frontend

El frontend es la parte de en la cual se especifica el tipo de aplicacion, los puertos y direcciones IP en las que escuchara el servicio, tambien se establecen las primeras reglas para las conexiones, el frontend seria el encargado de recibir las conexiones de los clientes.
Ejemplo de frontend para balancear conexiones HTTP:

frontend f_webfarm
    bind 192.168.1.1:80
    bind 192.168.1.2:80
    mode http
    acl acl_nagios hdr_end(host) -i nagios.infratic.com
    acl acl_git url_beg /git
    use_backend b_nagios if acl_nagios
    use_backend b_git if acl_git
    default_backend b_webfarm

bind : IP:Puerto que debe abrir el HaProxy para dicho frontend, pueden ser distintas direcciones IP y distintos puertos, tambien se puede poner 0.0.0.0:80 para que abra el puerto 80 de todas las IPs que tiene configurado el S.O.
mode : Modo en el que trabajara , si no se especifica hereda de la configuracion defaults.
acl : acl se utilizan para crear reglas o politicas, por ejemplo en el primer caso crea una acl para cuando se consulta a git.infratic.com, luego se crea una acl para cuando se consulta al /git

Las acl’s mas comunes son:
url_beg: String con el cual inicia la URL.
url_sub: String del subfolder.
url_end: String con el cual termina la URL.
hdr_end(host): Nombre al cual intenta conectarse el cliente.

use_backend : Se utiliza para determinar cual sera el backend a utilizar en caso de que se cumplan una o varias acl’s.
default_backend : Hace referencia al nombre del backend que se utilizara en caso de que no se cumpla ninguna regla de use_backend.


Definicion de backend

La configuracion backend es donde se determinan cuales son los nodos, cuales son los metodos de chequeo de vida y cuales son las opcion o metodos de balanceo
Ejemplo basico de backend

backend backend_web
    mode http
    balance source
    option http-server-close
    option httpclose
    option forceclose
    cookie SERVERID insert nocache indirect
    option httpchk GET /test HTTP/1.1\r\nHost:\ lb.infratic.com\r\n
    server jb1 jb1.infratic.com:8280 check cookie JB1 inter 10s
    server jb2 jb2.infratic.com:8280 check cookie JB2 inter 10s

mode : Modo en el que trabajara , si no se especifica hereda de la configuracion defaults.
balance : Se establece el tipo de balanceo a utilizar.

Los metodos mas utilizados son:
roundrobin: Distribuye la carga entre los nodos de manerae equitativa, es decir si tenemos 2 nodos para cada 10 conexiones caeran 5 a cada nodo.
source: Realiza el balanceo basandose en la direccion IP del cliente, es decir cada vez que un cliente se conecte ira al mismo nodo al cual fue en la primera conexion (siempre y cuando el nodo este activo)

option http-server-close : Fuerza a cerrar las conexiones http entre el balanceador y el nodo
option httpclose : Cierra la conexion http entre el cliente y el balanceador (Agregar el header Connection:Close)
option forceclose : Fuerza el cierre de las conexiones http entre el cliente y el balanceador
cookie SERVERID : Establece el ID del cookie para cada nodo backend
option httpchk : Se establece el metodo PING, seria el metodo por el cual el balanceador se dara cuenta cuando un nodo caiga, en el caso de HTTP el balanceador espera una respuesta diferente al codigo HTTP 500, si un nodo retorna HTTP 500 dicho nodo sera marcado como caido
server : Se configura cada nodo backend, la sintaxis es “server nombre fqdn_o_ip opciones”.

Las opciones mas usadas son:
check: Establece que se debe chequear el nodo
check port: Establece el puerto en el cual se realizara el chequeo
cookie: Establece el ID para los cookies de dicho nodo
inter: Intervalo entre chequeos
maxconn: Cantidad maxima de conexiones para dicho nodo
weight: Peso del nodo, mientras mas peso tengo, mas conexiones le caeran
backup: Se establece el nodo como backup, es decir que solo le caeran conexiones al momento que todos los nodos activos caigan


Definicion de listen

La configuracion listen es una mezcla entre frontend y backend, dentro del listen se establecen las direcciones IPs y puertos donde se escuchanb y a la vez se determinan cuales son los nodos, a diferencias del frontend tiene cierta limitaciones a la hora de tener varios backends basandose en la url para discriminar a que backend debe ir
Ejemplo basico de listen

listen MariaDB_farm 0.0.0.0:3306
    mode tcp
    option mysql-check user haproxy_check
    option tcplog
    balance source
    server  av-db1 av-db1.infratic.com:3306 check inter 5s
    server  av-db2 av-db2.infratic.com:3306 check inter 5s

Las opciones utilizadas en listen tienen el mismo significado tanto en backend como en frontend*