jueves, 22 de diciembre de 2011

ISCSi Persistente en CentOS

Volvi, en forma de fichas.....

Hoy les presentare, estimados lectores, como solucionar uno de los grandes problemas con el mapeo de unidades ISCSi, la persistencia de nombres.
Generalmente al montar unidades ISCSi al reiniciar el equipo se modifica el nombre del disco, o se cruzan como es en mi caso, a saber /dev/sda se convierte en /dev/sdb al reiniciar un servidor y viceversa.

Esto se hace mediante el servicio udev, le definimos que por cada UUID de unidad ISCSi le asigne siempre el mismo dispositivo (/dev/iscsi0 /dev/iscsi1 o lo que fuere)

Primero se debe obtener el id de los discos. Se debe ejecutar el siguiente comando

 scsi_id -g -u -s /block/sda
Recordar apuntar a /block y no a /dev, esto se podria ver tambien ejecutando fdisk -l y cambiar el /dev por /block:

[root@remo ~]# fdisk -l

Disk /dev/xvdd: 117 MB, 117549056 bytes
255 heads, 63 sectors/track, 14 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/xvdd doesn't contain a valid partition table

Disk /dev/xvda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *           1          13      104391   83  Linux
/dev/xvda2              14        2610    20860402+  8e  Linux LVM

Disk /dev/sda: 12.5 GB, 12582912000 bytes
64 heads, 32 sectors/track, 12000 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 14.6 GB, 14696841216 bytes
64 heads, 32 sectors/track, 14016 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Disk /dev/sdb doesn't contain a valid partition table

Entonces, para obtener el UUID del disco se debe ejecutar


 scsi_id -g -u -s /block/sda
14f504e46494c45524a5a5471534c2d4f69724e2d6e546164

 scsi_id -g -u -s /block/sdb
14f504e46494c45524a6b705679642d63366b312d41673268
Apuntar los UUID que seran usados mas adelante...
Ahora, se debe crear un nuevo archivo dentro de /etc/udev/rules.d llamado
20-names.rules
La sintaxis es la siguiente:


KERNEL=="sd*", BUS=="scsi",  PROGRAM="sbin/scsi_id", RESULT=="14f504e46494c45524a5a5471534c2d4f69724e2d6e546164", NAME="iscsi0"
KERNEL=="sd*", BUS=="scsi",  PROGRAM="sbin/scsi_id", RESULT=="14f504e46494c45524a6b705679642d63366b312d41673268", NAME="iscsi1"
o sea que en mi caso /dev/sdb va a llamarse /dev/iscsi1 y /dev/sda se va a llamar /dev/iscsi0

Editar el archivo /etc/scsi_id.config, comentar todas las lineas y agregar lo siguiente (en negrita)

#
# options=
# vendor=string[,model=string],options=

# some libata drives require vpd page 0x80
options=-g

Sin hacer esto NO FUNCIONA asi que no olvidarlo!!!

Ahora se debe editar el archivo /etc/rc.local y agregar /sbin/start_udev
Reiniciar el equipo y listo!
No olvidar de cambiar el /etc/fstab porque /dev/sda y /dev/sdb no existen mas luego del cambio

martes, 12 de julio de 2011

Cluster JBoss con Session Replication

En esta entrega os explicare como armar un cluster de servidores de aplicaciones Java con replicacion de sesion. He elegido JBoss porque me place (?).

Elementos

*1 aplicacion desarrollada en Java
*2 o mas servidores JBoss ya instalados. En mi caso son dos y los voy a llamar application1(192.168.70.249) y application2 (192.168.70.250)
*1 o mas servidores Apache (en mi caso son dos) con mod_jk instalado

Se asume que se parte desde una instalacion funcionando (standalone) y una aplicacion tambien funcionando. La idea es pasar de un servidor a un cluster de servidores... De todas maneras en la practica es bastante complicado y tedioso hacer este tipo de migraciones, pero me parece que vale la pena compartirlo.

Para que JBoss funcione en modo cluster se deben colocar los arhivos a desplegar en el directorio $JBOSS_HOME/server/all/deploy en cada servidor del cluster. Tambien se podria poner en el directorio $JBOSS_HOME/server/all/farm que hace el deploy automatico entre todos los nodos del cluster.

Luego, hay que modificar el script de inicio, que seria asi, por ejemplo para el servidor 1


#!/bin/bash

/usr/local/jboss/bin/run.sh -b 192.168.70.249 -c all  >/dev/null 2>&1 &

echo servicio jboss iniciado...
y modificar el arhivo de configuracion $JBOSS_HOME/bin/run.conf. En negrita esta el parametro a agregar en cada nodo del cluster:

if [ "x$JAVA_OPTS" = "x" ]; then
   JAVA_OPTS="-Xms512m -Xmx3000m  -XX:PermSize=256m -XX:MaxPermSize=512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Djboss,partition.name=cluster
-Dsun.rmi.dgc.server.gcInterval=3600000 -Duser.timezone=GMT-03:00"
Luego, en cada instancia de jboss modificar el archivo $JBOSS_HOME/server/all/deploy/jboss-web.deployer/server.xml y agregar en la siguiente linea lo que se muestra en negrita:
  
< Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker1" >


En mi caso worker1 es el servidor application1.

Ahora se le debe indicar a JBoss que vamos a usar un balanceador (mod_jk). Para esto editar el archivo $JBOSS_HOME/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml y agregar en la siguiente linea lo que se muestra en negrita:
 < attribute name="UseJK" >true< /attribute >
 Ahora, descomprimir el archivo ear a hacer deploy y editar el archivo /WEB-INF/web.xml. Agregar lo que esta en negrita:
el parameto se debe agregar dentro del contexto y NO DENTRO DE OTRO, sino NO FUNCIONA.

< web-app
        version="2.5"
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" >
       
       
       
    < distributable/ >

Luego, editar el archivo /WEB-INF/jboss-web.xml, y agregar lo siguiente:
< jboss-web >
 
   < replication-config >
     < replication-trigger >SET_AND_NON_PRIMITIVE_GET< /replication-trigger >
     < replication-granularity >SESSION< /replication-granularity >
    < replication-field-batch-mode >true< /replication-field-batch-mode >
     < /replication-config >

< /jboss-web >
Yo utilice SESSION replication que es lo que necesitaba, para mas info... http://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/beta500/html/clustering-http-app.html


Segurizando la consola jmx

Como la replicacion entre los servidores esta hecha por medio de jms, se precisa de la consola de jboss para monitorear la replicacion se debe segurizar, de lo contrario cualquier usuario sin autenticar puede reiniciar el servidor, editar configuraciones, etc.
Editar el archivo $JBOSS_HOME/server/all/conf/login-config.xml y agregar:

       < application-policy name = "jmx-console" >
                < authentication >
                < login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
                             flag = "sufficient" >
        < module-option name="usersProperties" >props/jmx-console-users.properties< /module-option >
        < module-option name="rolesProperties" >props/jmx-console-roles.properties< /module-option >
        < /login-module >
        < /authentication >
        < /application-policy >
        < application-policy
                name="other" >
                < authentication >
                        < login-module
                                code="org.jboss.security.auth.spi.UsersRolesLoginModule"
                                flag="required" />
                < /authentication >
        < /application-policy >
Ahora, se debe editar el archivo $JBOSS_HOME/server/all/conf/props/jmx-console-users.properties (en el caso que no exista crearlo)

# A sample users.properties file for use with the UsersRolesLoginModule
admin=password_del_admin
Y tambien el archivo $JBOSS_HOME/server/all/conf/props/jmx-console-roles.properties

# A sample roles.properties file for use with the UsersRolesLoginModule
admin=JBossAdmin,HttpInvoker
En el caso de utilizar otro usuario que no sea admin, cambiarlo.

Configuracion de Apache:

Para hacer el balanceo de carga se utiliza Apache con el modulo mod_jk.
La instalacion de mod_jk requiere los siguientes paquetes (y sus dependencias que se instalaran automaticamente). Esto para CentOS / RedHat / Fedora

yum install -y httpd-devel gcc
Se baja el modulo a compilar


wget http://apache.dattatec.com//tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.32-src.tar.gz
se descomprime, se compila y se instala en cada servidor apache.

tar -xzvf tomcat-connectors-1.2.32-src.tar.gz
cd tomcat-*
./configure --with-apxs=/usr/sbin/apxs
./make
./make install
 ahora editar el archivo /etc/httpd/conf.d/workers.properties. Este archivo es el de configuracion del balanceador de carga, aqui se van a definir los nodos del cluster, el peso para distribuir el trabajo, etc

#esta es la ruta de $JBOSS_HOME
workers.tomcat_home=/usr/local/jboss
#ruta a la jdk de la aplicacion
workers.java_home=/usr/local/java
#slash (en el caso de linux / en el caso de windows \)
ps=/
#lista de workers, router seria el cluster, status es para chequear estado de los servidores
worker.list=router,status
#defino nodo 1
worker.worker1.port=8009
worker.worker1.host=192.168.70.249
worker.worker1.socket_timeout=300
worker.worker1.type=ajp13
#defino el nodo 2
worker.worker2.port=8009
worker.worker2.host=192.168.70.250
worker.worker2.socket_timeout=300
worker.worker2.type=ajp13
#defino la carga (este parametro es relacional, es decir que si a cada nodo le pongo 1, distribuira la carga 1 a 1, si el nodo 1 tiene 10 y el nodo 2 tiene 1, la relacion de trabajo es 10 a 1)
worker.worker1.lbfactor=1
worker.worker2.lbfactor=1
#defino tipo de balanceo (lb=loadbalancing) 
worker.router.type=lb
worker.router.balance_workers=worker1,worker2
#defino que la sesion persista en cada worker
worker.router.sticky_session=1
worker.inprocess.type=jni
worker.status.type=status
Por ultimo, se define el virtual host y como sera montado por apache, en /etc/httpd/conf.d/vhosts.conf 
#Cargo el modulo compilado anteriormente
LoadModule jk_module modules/mod_jk.so
NameVirtualHost *
ServerName nombredelservidor
ServerSignature Off
#llamo a workers.properties
JkWorkersFile /etc/httpd/conf.d/workers.properties
# Defino los logs
JkLogFile /var/log/httpd/mod_jk.log
# log level [debug/error/info]
JkLogLevel debug
# Formato de log
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
kRequestLogFormat "%w %V %T"
JkShmFile /var/log/httpd/jk.shm
ServerAlias 1.2.3.4
ServerAdmin support@pepe.com
DocumentRoot /var/www/vhosts/
ErrorLog logs/cluster_error
CustomLog logs/cluster-access_log common
#envio los requests al cluster (llamado router) JkMount * router


Esto es todo por hoy amiguitos, cualquier duda, puteada o lo que quieran me avisan.
Un saludo a todos los que me conocen

viernes, 3 de junio de 2011

FIlesystem en Cluster OCFS2 para Centos / Red Hat

Saludos desde el ciberespacio lectores virtuales (?)

En esta nueva entrega os explicare como instalar un filesystem en cluster (Oracle Cluster Filesystem 2). Muy util para soluciones de alta disponibilidad, es bastante simple de instalar comparado a otras opciones, como por ejemplo GFS2 de RedHat. Yo lo utilizo para compartir logfiles de una instalacion en cluster de PostgreSQL, pero sirve para cualquier cosa...
En mi configuracion se instalo sobre una unidad iscsi, compartida entre dos servidores (Nodos), uno real y otro virtual (con xen).

La instalacion se debe realizar en todos los nodos que vayan a compartir el filesystem.

Primero se instalan las dependencias en los nodos
yum install -y vte

Luego se descargan los paquetes de OCFS2, para mi caso de 64 bits, si necesitan para 32 bits los pueden descargar de http://oss.oracle.com/projects/ocfs/files/

wget http://oss.oracle.com/projects/ocfs2/dist/files/RedHat/RHEL5/x86_64/1.4.7-1/2.6.18-238.9.1.el5/ocfs2-2.6.18-238.9.1.el5-1.4.7-1.el5.x86_64.rpm
wget http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/x86_64/1.4.4-1/ocfs2-tools-1.4.4-1.el5.x86_64.rpm
wget http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/x86_64/1.4.4-1/ocfs2console-1.4.4-1.el5.x86_64.rpm
rpm -ivh ocfs2-2.6.18-238.9.1.el5-1.4.7-1.el5.x86_64.rpm ocfs2-tools-1.4.4-1.el5.x86_64.rpm ocfs2console-1.4.4-1.el5.x86_64.rpm
 Luego se instalan los rpm

rpm -ivh ocfs2-2.6.18-238.9.1.el5-1.4.7-1.el5.x86_64.rpm ocfs2-tools-1.4.4-1.el5.x86_64.rpm ocfs2console-1.4.4-1.el5.x86_64.rpm

Para el nodo con kernel xen, difiere un poco la instalacion

wget http://oss.oracle.com/projects/ocfs2/dist/files/RedHat/RHEL5/x86_64/1.4.7-1/2.6.18-238.el5/ocfs2-2.6.18-238.el5xen-1.4.7-1.el5.x86_64.rpm
wget http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/x86_64/1.4.4-1/ocfs2-tools-1.4.4-1.el5.x86_64.rpm
wget http://oss.oracle.com/projects/ocfs2-tools/dist/files/RedHat/RHEL5/x86_64/1.4.4-1/ocfs2console-1.4.4-1.el5.x86_64.rpm

rpm -ivh ocfs2-2.6.18-238.el5xen-1.4.7-1.el5.x86_64.rpm ocfs2-tools-1.4.4-1.el5.x86_64.rpm ocfs2console-1.4.4-1.el5.x86_64.rpm 

En alguno de los dos nodos, ahora, hay que darle formato al disco:



mkfs.ocfs2 --fs-features=nosparse,inline-data /dev/mapper/mpath2p1

(cambiar /dev/mapper/mpath2p1 por la unidad correspondiente segun el caso)

ahora se activa el o2cb. NOTA: va a tirar un error la primera vez


/etc/init.d/o2cb enable

Writing O2CB configuration: OK
Loading filesystem "configfs": OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading stack plugin "o2cb": OK
Cluster not known

Luego se edita el archivo /etc/ocfs2/cluster.conf con la configuracion de los nodos y el nombre del cluster
node:
        ip_port = 7777
        ip_address = 10.10.10.30
        number = 0
        name = db02.crapfields.com.ar
        cluster = ocfs2

node:
        ip_port = 7777
        ip_address = 10.10.10.20
        number = 1
        name = db01.crapfields.com.ar
        cluster = ocfs2

cluster:
        node_count = 2
        name = ocfs2

Ahora si, se inicia el servicio
/etc/init.d/o2cb start
de paso, ya lo agrego como servicio del sistema
chkconfig o2cb on

Finalmente se monta la unidad

mount /dev/mpath/mpath2p1 /u02

En el caso de necesitar que se monte la unidad al inicio del sistema, editar el archivo /etc/fstab

/dev/mapper/mpath2p1     /u02                   ocfs2   _netdev,datavolume     0 0


y eso es todo! Espero que les sirva.

viernes, 20 de mayo de 2011

Heartbeat en Red Hat Enterprise Linux 5 (RHEL 5)

Una vez mas por este baticanal, amigos 2.0 les vengo a mostrar una nueva solucion a los problemas cotidianos del administrador de red (??)
Generalmente trabajo con CentOS, pero esta vez me pagaron una licencia de RedHat para unos blades que estoy configurando. Necesitaba usar Heartbeat (para alta disponibilidad de servicios), y me encontre con que no esta en los repositorios pagos de RedHat.

La instalacion es bastante simple, por medio de rpms. Ahi les va el como:

Primero instalar paquetes de dependencias
yum install -y libtool-ltdl openhpi-libs PyXML pygtk2-libglade
wget http://download.fedora.redhat.com/pub/epel/5/x86_64/libnet-1.1.5-1.el5.x86_64.rpm
rpm -ivh libnet-1.1.5-1.el5.x86_64.rpm


Ahora si se instalan los paquetes de heartbeat en cuestion

wget http://serverbeach1.fedoraproject.org/pub/epel/5/x86_64/heartbeat-pils-2.1.4-11.el5.x86_64.rpm
rpm -ivh heartbeat-pils-2.1.4-11.el5.x86_64.rpm
wget http://serverbeach1.fedoraproject.org/pub/epel/5/x86_64/heartbeat-stonith-2.1.4-11.el5.x86_64.rpm
rpm -ivh heartbeat-stonith-2.1.4-11.el5.x86_64.rpm
wget http://serverbeach1.fedoraproject.org/pub/epel/5/x86_64/heartbeat-2.1.4-11.el5.x86_64.rpm
rpm -ivh heartbeat-2.1.4-11.el5.x86_64.rpm
wget http://serverbeach1.fedoraproject.org/pub/epel/5/x86_64/heartbeat-gui-2.1.4-11.el5.x86_64.rpm
rpm -ivh heartbeat-gui-2.1.4-11.el5.x86_64.rpm

En el proximo programa (?) os explicare que es heartbeat, para que sirve y como se configura.

Un saludo a todos los que me conocen!

miércoles, 6 de abril de 2011

Solucionando error en Xen "received packet with own address as source address"

Hola ciberamigos... hoy me encontre con un problema un poco extraño en dos de mis VM en Xen. Un error que decia asi:

vif 0.0: received packet with own address as source address

Esto se debe a un problema con CentOS y la instalacion de Xen, el encontrarse dos o mas maquinas con Dom0 en la misma red. Supongamos que el equipo A recibe broadcast del equipo B, y este ve que esta recibiendo un paquete con su misma mac address (o algo asi, la verdad no entendi bien, no estudie ccna (?!!?!?))

Buscando y buscando encontre la solucion gracias a un tal Cyrus Katrak, asi que los creditos son para el.

se debe reemplazar el archivo /etc/xen/scripts/network-bridge por el siguiente

#!/bin/bash
#============================================================================
# Default Xen network start/stop script.
# Xend calls a network script when it starts.
# The script name to use is defined in /etc/xen/xend-config.sxp
# in the network-script field.
#
# This script creates a bridge (default xenbr${vifnum}), adds a device
# (default eth${vifnum}) to it, copies the IP addresses from the device
# to the bridge and adjusts the routes accordingly.
#
# If all goes well, this should ensure that networking stays up.
# However, some configurations are upset by this, especially
# NFS roots. If the bridged setup does not meet your needs,
# configure a different script, for example using routing instead.
#
# Usage:
#
# network-bridge (start|stop|status) {VAR=VAL}*
#
# Vars:
#
# vifnum Virtual device number to use (default 0). Numbers >=8
# require the netback driver to have nloopbacks set to a
# higher value than its default of 8.
# bridge The bridge to use (default xenbr${vifnum}).
# netdev The interface to add to the bridge (default eth${vifnum}).
# antispoof Whether to use iptables to prevent spoofing (default no).
#
# Internal Vars:
# pdev="p${netdev}"
# vdev="veth${vifnum}"
# vif0="vif0.${vifnum}"
#
# start:
# Creates the bridge
# Copies the IP and MAC addresses from netdev to vdev
# Renames netdev to be pdev
# Renames vdev to be netdev
# Enslaves pdev, vdev to bridge
#
# stop:
# Removes netdev from the bridge
# Transfers addresses, routes from netdev to pdev
# Renames netdev to vdev
# Renames pdev to netdev
# Deletes bridge
#
# status:
# Print addresses, interfaces, routes
#
#============================================================================

#macid is used to uniquely identify this dom0 on this network
#change this to avoid MAC address conflicts if you get:
#"peth0: received packet with own address as source address"
macid="F0"

dir=$(dirname "$0")
. "$dir/xen-script-common.sh"
. "$dir/xen-network-common.sh"

findCommand "$@"
evalVariables "$@"

vifnum=${vifnum:-$(ip route list | awk '/^default / { print $NF }' | sed 's/^[^0-9]*//')}
vifnum=${vifnum:-0}
bridge=${bridge:-xenbr${vifnum}}
netdev=${netdev:-eth${vifnum}}
antispoof=${antispoof:-no}

pdev="p${netdev}"
vdev="veth${vifnum}"
vif0="vif0.${vifnum}"

get_ip_info() {
addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e 's/ .*//'`
gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
}

do_ifup() {
if ! ifup $1 ; then
if [ ${addr_pfx} ] ; then
# use the info from get_ip_info()
ip addr flush $1
ip addr add ${addr_pfx} dev $1
ip link set dev $1 up
[ ${gateway} ] && ip route add default via ${gateway}
fi
fi
}

# Usage: transfer_addrs src dst
# Copy all IP addresses (including aliases) from device $src to device $dst.
transfer_addrs () {
local src=$1
local dst=$2
# Don't bother if $dst already has IP addresses.
if ip addr show dev ${dst} | egrep -q '^ *inet ' ; then
return
fi
# Address lines start with 'inet' and have the device in them.
# Replace 'inet' with 'ip addr add' and change the device name $src
# to 'dev $src'.
ip addr show dev ${src} | egrep '^ *inet ' | sed -e "
s/inet/ip addr add/
s@\([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+/[0-9]\+\)@\1@
s/${src}/dev ${dst}/
" | sh -e
# Remove automatic routes on destination device
ip route list | sed -ne "
/dev ${dst}\( \|$\)/ {
s/^/ip route del /
p
}" | sh -e
}

# Usage: transfer_routes src dst
# Get all IP routes to device $src, delete them, and
# add the same routes to device $dst.
# The original routes have to be deleted, otherwise adding them
# for $dst fails (duplicate routes).
transfer_routes () {
local src=$1
local dst=$2
# List all routes and grep the ones with $src in.
# Stick 'ip route del' on the front to delete.
# Change $src to $dst and use 'ip route add' to add.
ip route list | sed -ne "
/dev ${src}\( \|$\)/ {
h
s/^/ip route del /
P
g
s/${src}/${dst}/
s/^/ip route add /
P
d
}" | sh -e
}


##

Reiniciar el equipo y listo, solucionado!

viernes, 1 de abril de 2011

Cluster de Alta disponibilidad con LVS (Linux Virtual Server)

Alta disponibilidad de servicios con LVS (Linux Virtual Server)

Hola amiguitos virtuales(?).Hoy les voy a mostrar como hice para configurar un cluster de alta disponibilidad de Apache. Tambien se puede hacer de otros servicios (FTP, Telnet, etc).

La estructura de funcionamiento es la siguiente; hay uno o mas balanceadores o directores que comparten una ip virtual que es la que presta servicio, es decir que los clientes se conectan a una ip, supongamos 192.168.10.27. Esta seria la ip virtual, los equipos directores tienen 2 direcciones ip, la real (que no se comparte, supongamos 192.168.10.23) y la virtual que se comparte con los demas directores del servicio.
Se completa la configuracion con dos servidores Apache (en este caso son dos, pueden ser mas).
Hay distintos tipos de ruteo en lvs, en este caso use Direct Routing porque tengo todo en la misma red, de otro modo habria que usar NAT.

En mi caso son dos directores y dos apache. Los cuatro equipos tienen CentOS, asi que esta guia es valida para CentOS / Red Hat / Fedora, aunque conceptualmente es lo mismo en cualquier linux, salvo la herramienta para configurar el cluster lvs que es propietaria de Red Hat, tal vez en otras distros haya algo similar

En los directores lvs:

Instalar piranha (consola de configuracion de HA) e ipvsadm (paquete de servicios lvs)
yum install -y ipvsadm piranha


Habilitar los servicios al inicio.

chkconfig pulse on
chkconfig piranha-gui on
chkconfig httpd on

Establecer una clave para el servicio piranha

piranha-passwd

Habilitar forwarding de paquetes en el kernel y modificar parametros ARP

en /etc/sysctl.conf agregar o editar las siguientes lineas

net.ipv4.ip_forward = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2


Se reinicia el equipo para que queden aplicados los cambios y luego para acceder a piranha http://ip.del.director:3636


Luego en "Global Settings" se configura la ip del director primario, en mi caso 192.168.10.23 y el tipo de red (Direct Routing). En el campo "Private server IP" no poner nada, ya que en este caso no hay dos adaptadores de red en el director.



En Redundancy ingresar la ip del director lvs secundario, en mi caso 192.168.10.24, lo demas dejarlo como esta.



Ahora, en virtual server se configura la ip que prestara servicio, es decir la ip visible de servicio. En mi caso seria para acceder al servicio, por ejemplo http://192.168.10.27.
Dejar todo como esta y en el tipo de scheduling seleccionar "Weightead-least Connections". Esta opcion es para que distribuya la carga en funcion al peso que tenga cada equipo y es proporcional. Suponiendo que Servidor A tiene peso 1 y Servidor B tiene peso 2, por cada DOS conexiones que tenga B, el servidor A va a tener una.

Una vez finalizado esto en la opcion de REAL SERVERS, se ingresan las ips y el peso de los equipos que van a prestar servicio, en el ejemplo es 192.168.10.205 con peso 1 (y 192.168.10.102 con peso 1 que ya lo configure desde antes).


Ya esta casi finalizada la configuracion, solo hay que definir el monitoreo de los servicios (en MONITORING SCRIPTS). Yo no utilice la opcion por defecto de piranha sino que use un script que me robe por ahi (!)
en /etc/sysconfig/ha crear un archivo llamado check_apache

#!/bin/bash
if links -dump -eval 'set connection.receive_timeout = 1' -eval 'set connection.retries = 1' -eval 'set connection.unrestartable_receive_timeout = 1' http://$1/ > /dev/null 2>&1; then

echo "OK"

else

echo "FAILURE"

fi

exit 0

Se guarda el archivo y se pasa a configurar en piranha el script de monitoreo. (No olvidar de darle permisos 755 al archivo).



Aceptar para aplicar los cambios, y NO OLVIDAR DE ACTIVAR LOS SERVIDORES!!!. Si no se activan no inicia el servicio despues....

Para configurar el director secundario (192.168.10.24 en mi caso) copiar el archivo /etc/sysconfig/ha/lvs.cf del primario hacia el secundario y el script check_apache dentro del mismo directorio.
Una vez terminado esto, hacer un service pulse restart en los dos directores.
En /var/log/messages se muestra el estado del servicio, por ejemplo

Apr 1 13:00:18 xxxx pulse[7834]: STARTING PULSE AS MASTER
Apr 1 13:00:21 xxxx pulse[7834]: backup inactive: activating lvs
Apr 1 13:00:21 xxxx lvs[7839]: starting virtual service web1 active: 80
Apr 1 13:00:21 xxxx nanny[7848]: starting LVS client monitor for 192.168.10.27:80 -> 192.168.10.205:80
Apr 1 13:00:21 xxxx lvs[7839]: create_monitor for web1/application1 running as pid 7848
Apr 1 13:00:21 xxxx nanny[7852]: starting LVS client monitor for 192.168.10.27:80 -> 192.168.10.120:80
Apr 1 13:00:21 xxxx lvs[7839]: create_monitor for web1/application2 running as pid 7852
Apr 1 13:00:21 xxxx nanny[7848]: [ active ] making 192.168.10.205:80 available
Apr 1 13:00:21 xxxx nanny[7852]: [ active ] making 192.168.10.120:80 available
Apr 1 13:00:26 xxxx pulse[7843]: gratuitous lvs arps finished

Listo con los directores. Si se prueba el servicio NO VA A FUNCIONAR, esto es por un problema de ARP en lvs, para mas info detallada http://www.linuxvirtualserver.org/docs/arp.html

Se proponen varias soluciones, yo utilice arptables. Para esto EN LOS SERVIDORES REALES, se debe instalar el paquete arptables

yum install -y arptables_jf
una vez instalado el paquete, se inicia el servicio y se corren los comandos arp correspondientes

service arptables_jf start
arptables -A IN -d 192.168.10.27 -j DROP # se dropean los pedidos arp a la ip virtual del lvs. En otros casos cambiar 192.168.10.27 por la correspondiente

arptables -A OUT -d 192.168.10.27 -j mangle --mangle-ip-s 192.168.10.205 # se sacan los paquetes de la ip flotante por la ip REAL del servidor, en otros casos cambiar 192.168.10.205 por la ip del servidor.
Guardar las tablas:

service arptables_jf save
Activar servicio arptables al inicio

chkconfig arptables_jf on

Ahora se debe crear un adaptador virtual con la ip virtual de lvs

ifconfig eth0:1 192.168.10.27 netmask 255.255.255.0 broadcast 192.168.10.255 up
NOTA: Agregar esta linea a /etc/rc.local ya que al reiniciarse el equipo se pierden esos cambios

agregar a /etc/sysctl.conf

net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
Reiniciar el equipo y listo!

Al acceder a http://192.168.10.27 tendremos un cluster apache con failover y balanceo de carga (en mi caso con relacion 1 a 1).




martes, 15 de marzo de 2011

Instalando paquetes en XenServer 5.x

Para instalar paquetes ya precompilados (rpm) en versiones de XenServer (por ejemplo algun compilador tipo gcc o cpp que no vienen instalados por defecto) se debe habilitar el repositorio base, ya que el repositorio por defecto solo tiene las herramientas para xen.

por ejemplo


yum --enablerepo=base install cpp gcc

En mi caso lo necesitaba para compilar un agente de inventario de hardware. No olvidar que el XenServer es un kernel de CentOS, asi que algunos rpm para Centos / Fedora / Red Hat pueden llegar a servir.