Gua para la instalacin de un clster de bases de datos

Clster de altas prestaciones para medianas y pequeas bases de datos que utilizan a PostgreSQL como sistema de gestin de bases de datos.

Universidad de las Ciencias Informticas, Carretera a San Antonio de los Baos, km 2 , Boyeros, Ciudad de la Habana, Cuba. Autor para la correspondencia: yordunez@estudiantes.uci.cu

Yoemir Orduez Santana, Ing. Adrian Misael Pea Montero, Ing. Marcos Luis Ortiz Valmaseda, Ing. Daymel Bonne Sols.

Centro de Tecnologas de Gestin de Datos (DATEC)

Tabla de contenido

Prefacio ......................................................................................................................................................... 3 Audiencia................................................................................................................................................... 3 Secciones de Gua. ..................................................................................................................................... 3 Sobre PostgreSQL. ..................................................................................................................................... 3 Sobre PgPool-II. ......................................................................................................................................... 4 Sobre Debian GNU/Linux ........................................................................................................................... 5 Arquitectura del Sistema............................................................................................................................ 5 Instalacin de paquetes y configuracin de dependencias. ........................................................................ 6 Configuracin de PostgreSQL. .................................................................................................................... 8 Configuracin de PgPool-II ......................................................................................................................... 9 Pruebas de Replicacin ............................................................................................................................ 15 Instalacin y Configuracin de Heartbeat ................................................................................................. 18

Prefacio.
Esta gua muestra cmo instalar y configurar un clster de servidores de bases de datos PostgreSQL, gestionado mediante un middleware llamado PgPool-II, montado sobre el sistema operativo Debian GNU/Linux. El clster antes mencionado ofrece capacidades de replicacin y balanceo de carga. Este prefacio contiene: Audiencia. Secciones de la Gua.

Audiencia. Esta gua est orientada a: Administradores de bases de datos PostgreSQL que deseen adquirir habilidades en cuanto al trabajo con la tecnologa clster, para aumentar la capacidad de respuesta y la disponibilidad de los servidores que utilicen el SGBD anterior. Secciones de Gua. La Gua tiene las siguientes secciones: Sobre PostgreSQL. Sobre PgPool-II. Sobre Debian GNU/Linux. Arquitectura del sistema. Instalacin de paquetes y configuracin. Configuracin de PostgreSQL. Configuracin de PgPool-II. Pruebas de Replicacin. Instalacin y Configuracin de Heartbeat.

Sobre PostgreSQL. PostgreSQL es la base de datos relacional de cdigo abierto ms avanzada del mundo. Distribuida bajo licencia BSD (del ingls, Berkeley Software Distribution), lleva ms de 15 aos desarrollndose y su arquitectura goza de una excelente reputacin por su fiabilidad, integridad de datos y correctitud.

PostgreSQL dispone de versiones para prcticamente todos los sistemas operativos y cumple totalmente con ACID (del ingls, Atomicity, Consistency, Isolation, Durability). Tiene soporte para claves extranjeras, joins, vistas, disparadores y procedimientos almacenados (en mltiples lenguajes de programacin). Incluye la mayora de los tipos de datos de SQL92 y SQL99 y, as mismo, soporta el almacenamiento de grandes objetos binarios, como imgenes, sonidos y vdeos. Tiene interfaces de programacin nativas para C/C++, Java, .Net, Perl, PHP, Python, Ruby, Tcl y ODBC adems de una excepcional documentacin. PostgreSQL ofrece sofisticadas caractersticas tales como control concurrente multi-versin (MVCC), point in time recovery (PITR), tablespaces, replicacin asncrona, transacciones anidadas (savepoints), copias de seguridad en caliente/en lnea, un sofisticado planificador/optimizador de consultas y write ahead logging para ser tolerante a fallos de hardware. Soporta juegos de caracteres internacionales, codificaciones de caracteres multi-byte, unicode y realiza ordenaciones dependiendo de la configuracin de idioma local, de la diferenciacin de maysculas y minsculas y del formato. Es altamente escalable tanto en la cantidad bruta de datos que puede manejar como en el nmero de usuarios concurrentes que puede atender. Hay sistemas activos en produccin con PostgreSQL que manejan ms de 4 terabytes de datos. Sobre PgPool-II. PgPool-II habla los protocolos de frontend y backend de PostgreSQL, y pasa las conexiones entre ellos. De ese modo, una aplicacin de base de datos (frontend) cree que PgPool-II es el verdadero servidor de PostgreSQL, y el servidor (backend) ve a PgPool-II como uno de sus clientes. Debido a que PgPool-II es transparente tanto para el servidor como para el cliente, una aplicacin de base de datos existente puede empezar a usarse con PgPool-II casi sin ningn cambio en su cdigo fuente. PgPool-II funciona sobre Linux, Solaris, FreeBSD y la mayora de las arquitecturas UNIX (Para Windows no est soportado). Las versiones de PostgreSQL soportadas son de la 6.4 para arriba. Para usar la paralelizacin de consultas es necesaria la versin 7.4 o superior.

PgPool-II proporciona las siguientes caractersticas:

Limita el excedente de conexiones. PostgreSQL soporta un cierto nmero de conexiones concurrentes y rechaza las que superen dicha cifra. Aumentar el lmite mximo de conexiones incrementa el consumo de recursos y afecta al rendimiento del sistema. PgPool-II tiene tambin un lmite mximo de conexiones, pero las conexiones extras se mantienen en una cola en lugar de devolver un error inmediatamente. 4

Pool de conexiones. PgPool-II mantiene abiertas las conexiones a los servidores PostgreSQL y las reutiliza siempre que se solicita una nueva conexin con las mismas propiedades (nombre de usuario, base de datos y versin del protocolo). Ello reduce la sobrecarga en las conexiones y mejora la productividad global del sistema. Replicacin. PgPool-II puede gestionar mltiples servidores PostgreSQL. El uso de la funcin de replicacin permite crear una copia en dos o ms discos fsicos, de modo que el servicio puede continuar sin parar los servidores en caso de fallo en algn disco. Balanceo de carga. Si se replica una base de datos, la ejecucin de una consulta SELECT en cualquiera de los servidores devolver el mismo resultado. PgPool-II se aprovecha de la caracterstica de replicacin para reducir la carga en cada uno de los servidores PostgreSQL distribuyendo las consultas SELECT entre los mltiples servidores, mejorando as la productividad global del sistema. En el mejor caso, el rendimiento mejora proporcionalmente al nmero de servidores PostgreSQL. El balanceo de carga funciona mejor en la situacin en la cual hay muchos usuarios ejecutando muchas consultas al mismo tiempo. Paralelizacin de consultas. Al usar la funcin de paralelizacin de consultas, los datos pueden dividirse entre varios servidores, de modo que la consulta puede ejecutarse en todos los servidores de manera concurrente para reducir el tiempo total de ejecucin. La paralelizacin de consultas es una solucin adecuada para bsquedas de datos a gran escala. Sobre Debian GNU/Linux. Debian GNU/Linux es un sistema operativo libre (el conjunto de programas bsicos y utilidades que hacen que un ordenador funcione). Debian utiliza el ncleo Linux y las herramientas bsicas de GNU. Para esta instalacin se utilizar el sistema operativo Debian Lenny para la arquitectura x86_64 (AMD64/EM64T), partiendo de una instalacin bsica, sin ninguna tarea seleccionada en el selector de tareas del instalador. El sistema de ficheros elegido ser XFS. Arquitectura del Sistema. Primeramente manejar el trmino clster, que no es ms que un conjunto de computadoras, a menudo con semejantes componentes de hardware, que se interconectan entre s a travs de un 5

sistema de red de alta velocidad y son capaces de elevar la eficiencia para realizar determinadas tareas que individualmente no podran realizar debido a la creciente necesidad de potencia computacional que demandan algunas aplicaciones. En esta gua se persiguen dos objetivos: Alta Disponibilidad. Alto Rendimiento. La funcionalidad que se persigue en dicho clster es que el mismo acte como servidor de bases de datos, realizando esta actividad a travs de las siguientes aplicaciones: PostgreSQL, el sistema gestor de bases de datos (SGBD). PgPool-II, el middleware que gestiona la alta disponibilidad de los servidores de PostgreSQL. Heartbeat, software para dar alta disponibilidad a PgPool-II y a la direccin IP de servicio. Esta configuracin permite obtener alta disponibilidad de todos los servicios y recursos en las dos mquinas destinadas a este clster. El diagrama de la arquitectura resultante sera el siguiente:

Instalacin de paquetes y configuracin de dependencias. Se utilizarn las siguientes versiones de software: 6

 PostgreSQL-8.4. PgPool-II-2.2.5. Heartbeat-2. A continuacin se muestra un resumen de los datos que se usarn: Nodo 1: Hostname: pgsql1. Direccin IP administrativa: 10.34.17.55. Nodo 2: Hostname: pgsql2. Direccin IP administrativa: 10.34.17.56. PgPool-II: Direccin IP de servicio: 192.168.1.1. Puerto de gestin: 9898. Puerto de servicio: 9999. Es preciso que las entradas correspondientes a los datos anteriores existan en el fichero /etc/hosts:

10.34.17.55 pgsql1 10.34.17.56 pgsql2

Se comenzar configurando PostgreSQL en ambos nodos, todos los comandos tienen que ejecutarse como root o mediante sudo, a menos que se indique el uso del usuario postgres. Las dependencias para la compilacin de PgPool-II, se resuelven instalando:

apt-get install libpq-dev postgresql-server-dev-8.4 bison build-essential

Resueltas las dependencias, empezaremos instalando PostgreSQL en ambos nodos:

apt-get install postgresql-8.4 postgresql-contrib-8.4 postgresql-doc-8.4 uuid libdbd-pg-perl

Configuracin de PostgreSQL. Los siguientes pasos se aplican a ambas instancias de PostgreSQL en los nodos pgsql1 y pgsql2. Se empezar editando la configuracin de PostgreSQL para permitir el acceso incondicional del usuario pgpool2, que ser el usuario de base de datos del clster. Por incondicional se refiere al modo trust, el cual permite la validacin del usuario sin necesidad de contrasea, este modo se va a configurar en el fichero /etc/postgresql/8.4/main/pg_hba.conf
hosts all pgpool2 10.34.17.55/32 trust

Debe autenticarse como usuario postgres, para de esta forma crear al superusuario pgpool2:
su - postgres createuser --superuser pgpool2

Se incluir el acceso para el usuario pgpool2 desde la direccin IP donde se ejecutar el mismo, (en estos momentos en la direccin 10.34.17.55): A continuacin se edita el siguiente fichero /etc/postgresql/8.3/main/pg_hba.conf
host all pgpool2 10.34.17.55/32 trust

Como vemos anteriormente, al usuario pgpool2, en esta gua se le dio acceso a todas las bases de datos, pero en un marco de trabajo fuera de las pruebas que se quieren hacer se le restringe el permiso solo a aquellas bases de datos que vaya a usar. Aclarar que existen varias restricciones en la autenticacin y control de acceso en los modos que utiliza PgPool-II, los cuales se explican a continuacin: En el modo Replicacin y en el modo Maestro-Esclavo, solo son soportados los mtodos: trust y clear text password. En todos los dems modos que utiliza PgPool-II, se soportan los siguientes mtodos: trust, clear text password, crypt, md5. A continuacin se activa el archivado del Write-Ahead Log (WAL) de PostgreSQL, pues har falta para poder usar PITR (Point-In-Time Recovery) desde PgPool-II. Editamos el fichero de configuracin /etc/postgresql/8.3/main/postgresql.conf y cambiamos los dos parmetros siguientes:

archive_mode = on archive_command = 'exit 0'

Ya que slo se har uso de la caracterstica de PITR cuando se vaya a recuperar un nodo cado o aadir uno nuevo, por defecto se ha configurado el parmetro archive_command para que no haga nada (exit 0). Esto se hace debido a que la activacin o desactivacin del archivado de ficheros WAL requiere de un reinicio del servidor, pero la alteracin del comando o script que realiza la tarea de archivar el fichero WAL rotado por PostgreSQL tan slo requiere de una recarga de la configuracin. As, PostgreSQL se comportar como si no estuviera archivando ficheros de log, generando dichos ficheros (de 16 MB cada uno) con normalidad en /var/lib/postgresql/8.4/main/pg_xlog y rotndolos a partir del octavo que almacene. Acto seguido crearemos el directorio /var/lib/postgresql/pg_xlog_archive, directorio donde archivaremos (copiaremos) los ficheros WAL cuando lo necesitemos y le daremos permisos para el usuario postgres:
mkdir --mode=700 /var/lib/postgresql/pg_xlog_archive chown postgres:postgres /var/lib/postgresql/pg_xlog_archive

Por ltimo, se indicar a PostgreSQL que escuche en todas las interfaces pues, por defecto, slo lo hace en el localhost. Editamos el fichero /etc/postgresql/8.4/main/postgresql.conf cambiando la siguiente directiva:
listen_addresses = '*'

Tambin se puede restringir a 127.0.0.1 y la direccin IP administrativa del nodo (10.34.17.55 en el primer nodo, 10.34.17.56 en el segundo) para asegurarnos de que no est escuchando en la direccin IP de servicio del clster (la 192.168.1.1, que queremos utilizar nicamente para pgpoolII). Se reinicia a PostgreSQL para activar los cambios:
/etc/init.d/postgresql-8.4 restart

Configuracin de PgPool-II. La configuracin de pgpool-II se realizar nicamente en el nodo pgsql1, pues slo en ese host est instalado. 9

El fichero pcp.conf es un fichero de nombres de usuarios y contraseas, usado para autenticarse en la interfaz. Todos los comandos requieren que pcp.conf se haya configurado. Tras la instalacin de pgpool-II se crea un fichero /etc/pgpool-II/pcp.conf.sample de ejemplo. Configurar ese fichero es tan sencillo como cambiarle el nombre al fichero y aadir el usuario y contrasea deseado.

cp --archive /etc/pgpool-II/pcp.conf.sample /etc/pgpool/pcp.conf

Posteriormente se edita para aadir el usuario y contrasea en el formato:

Usuario:

En este artculo se usa root como nombre de usuario. Para generar la suma MD5 de nuestra contrasea podemos usar la utilidad pg_md5:

/usr/sbin/pg_md5 -p
password: <password> 34b339799d540a72bf1c408c0e68afdd

Luego se crea un fichero de configuracin para pgpool-II a partir del que viene como ejemplo:
cp --archive /etc/pgpool-II/pgpool.conf.sample /etc/pgpool-II/etc/pgpool.conf

Se debe editar el fichero para configurarlo a gusto. siguientes funcionalidades:

Pool de conexiones. Replicacin. Balanceo de carga.

Para este artculo se configurarn las

Se comenzar con una configuracin bsica para arrancar pgpool-II y se irn aadiendo funcionalidades. Editamos el fichero /etc/pgpool-II/pgpool.conf para dejarlo tal y como sigue:

10

listen_addresses = '*' port = 9999 pcp_port = 9898 socket_dir = '/var/run/postgresql' pcp_socket_dir = '/var/run/postgresql' backend_socket_dir = '/var/run/postgresql' pcp_timeout = 10 num_init_children = 32 max_pool = 4 child_life_time = 300 connection_life_time = 0 child_max_connections = 0 client_idle_limit = 0 authentication_timeout = 60 logdir = '/var/run/PostgreSQL' replication_mode = true load_balance_mode = true replication_stop_on_mismatch = true replicate_select = false reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT' print_timestamp = true master_slave_mode = false connection_cache = true health_check_timeout = 20 health_check_period = 60 health_check_user = 'pgpool2' failover_command = '' failback_command = '' insert_lock = false ignore_leading_white_space = true log_statement = false log_connections = false log_hostname = false parallel_mode = false enable_query_cache = false pgpool2_hostname = 'pgsql1' system_db_hostname = 'localhost' system_db_port = 5432 system_db_dbname = 'pgpool' system_db_schema = 'pgpool_catalog' system_db_user = 'pgpool' system_db_password = '' backend_hostname0 = '10.34.17.55' backend_port0 = 5432 backend_weight0 = 1 backend_hostname1 = '10.34.17.56' backend_port1 = 5432 backend_weight1 = 1 enable_pool_hba = false recovery_user = 'pgpool2' recovery_password = '' recovery_1st_stage_command = '' recovery_2nd_stage_command = '' recovery_timeout = 90

11

Todas las directivas de configuracin estn explicadas en la pgina web de pgpool-II (se adjunta a este documento dicho manual de PgPool-II). Como aspectos a destacar de la anterior configuracin se tiene lo siguiente:
Mediante la directiva listen_addresses indica inicialmente que pgpool-II escuche en todas

las interfaces.
Mediante las directivas logdir, socket_dir, pcp_socket_dir y backend_socket_dir, se

configura, respectivamente, que el pid y todos los sockets de los diferentes procesos que forman pgpool-II se guarden en el directorio por defecto de Debian para PostgreSQL, /var/run/postgresql.
Se activa el pool de conexiones (directiva connection_cache) pero dejamos todas las dems

funcionalidades desactivadas (replication_mode, load_balance_mode, replicate_select y master_slave_mode).

Mediante las directivas health_check_timeout, health_check_period y health_check_user, se

configura la comprobacin de estado de los servidores PostgreSQL para que se haga con el usuario de base de datos pgpool2, cada 60 segundos y con un tiempo mximo de espera de 20 segundos.
Se dejan todos los lmites de conexiones, nmero de procesos, tiempos de espera y

similares a sus valores por defecto. El siguiente paso es crear el script de arranque de pgpool-II, que se sita en /etc/init.d/pgpool, a continuacin se muestra un tpico script, basado en el original del paquete pgpool de Debian:

12

#!/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/sbin/pgpool PIDFILE=/var/run/pgpool/pgpool.pid test -x $DAEMON || exit 5 # Include pgpool defaults if available if [ -f /etc/default/pgpool ] ; then . /etc/default/pgpool fi install -o postgres -d /var/run/pgpool OPTS="" if [ x"$PGPOOL_LOG_DEBUG" = x"yes" ]; then OPTS="$OPTS -d" fi . /lib/lsb/init-functions is_running() { pidofproc -p $PIDFILE $DAEMON >/dev/null } d_start() { if is_running; then : else su -c "$DAEMON -n $OPTS 2>&1 </dev/null | logger -t pgpool -p ${PGPOOL_SYSLOG_FACILITY:-local0}.$ fi } d_stop() { killproc -p $PIDFILE $DAEMON -INT status=$? [ $status -eq 0 ] || [ $status -eq 3 ] return $? } case "$1" in start) log_daemon_msg "Starting pgpool-II" pgpool d_start log_end_msg $? ;; stop) log_daemon_msg "Stopping pgpool-II" pgpool d_stop log_end_msg $? ;; status) is_running status=$? if [ $status -eq 0 ]; then log_success_msg "pgpool-II is running." else log_failure_msg "pgpool-II is not running." fi exit $status ;;

13

restart|force-reload) log_daemon_msg "Restarting pgpool-II" pgpool d_stop && sleep 1 && d_start log_end_msg $? ;; try-restart) if $0 status >/dev/null; then $0 restart else exit 0 fi ;; reload) exit 3 ;; *) log_failure_msg "Usage: $0 {start|stop|status|restart|tryrestart|reload|force-reload}" exit 2 ;; esac

Siguiendo el estndar Debian, se crear el fichero /etc/default/pgpool con los valores de configuracin de arranque del daemon. Opcionalmente, se aprovecha para ponerlo en modo debug al arrancar:

# Defaults for pgpool initscript # sourced by /etc/init.d/pgpool # syslog facility for pgpool; see logger(1) PGPOOL_SYSLOG_FACILITY=local0 # set to "yes" if you want to enable debugging messages to the log PGPOOL_LOG_DEBUG=no

Se arranca PgPool-II:
/etc/init.d/pgpool start

Se puede observar el correcto arranque del daemon (o los errores en caso contrario) monitorizando el syslog, por ejemplo mediante el uso del comando tail:
/usr/bin/tail -f /var/log/syslog | ccze

14

A partir de este momento se debe ser capaz de conectarse al puerto 9999 de la direccin IP de administracin del nodo pgsql1 (la direccin IP de servicio no estar disponible hasta que configuremos la alta disponibilidad con Heartbeat):
/usr/bin/psql -h 10.34.17.55 -p 9999 -U pgpool2 -d postgres

Ahora se puede monitorizar las conexiones a los nodos de PostgreSQL, por lo cual activamos las directivas log_connections y log_disconnections en los ficheros de configuracin

/etc/postgresql/8.4/main/postgresql.conf de cada nodo, reiniciando PostgreSQL para que los cambios surjan efecto. Tras haber comprobado que ya podemos conectarnos, se procede a activar la replicacin y el balanceo de carga editando el fichero /etc/pgpool/pgpool.conf y cambiando las directivas siguientes:
replication_mode = true load_balance_mode = true replication_stop_on_mismatch = true

Para activar los cambios reiniciaremos pgpool-II:

/etc/init.d/pgpool restart

Pruebas de Replicacin. En el paquete PostgreSQL-contrib-8.4 se puede encontrar una utilidad llamada pgbench. Esta utilidad permite, en primer lugar, inicializar una base de datos con una serie de tablas sencillas y, en segundo lugar, realizar pruebas de rendimiento sobre servidores PostgreSQL mediante la ejecucin de una cierta cantidad de consultas de varios tipos y con una concurrencia parametrizable. A partir de este momento se trabaja desde un tercer equipo, actuando ya como cliente del clster. Por comodidad, se dar de alta a las entradas del fichero /etc/hosts mencionadas anteriormente en el artculo, igual que se hizo en ambos nodos del clster. El primer paso consistir en crear la base de datos bench_replication: Con log_statement y log_connections activados en /etc/pgpool/pgpool.conf, mostrar entradas en createdb -h 10.34.17.55 -p 9999 -U pgpool2 bench_replication
createlang -h 10.34.17.55 -p 9999 /var/log/syslog similares a las siguientes: -U pgpool2 -d bench_replication plpgsql

15

Con log_statement = 'all' en /etc/postgresql/8.4/main/postgresql.conf, en el log de cualquiera de los PostgreSQL aparecern las siguientes lneas:
LOG: LOG: LOG: LOG: LOG: connection received: host=10.34.17.55 port=33690 connection authorized: user=pgpool2 database=postgres statement: CREATE DATABASE bench_replication; statement: RESET ALL statement: SET SESSION AUTHORIZATION DEFAULT

Autenticndose como usuario postgres se puede usar psql para ver las bases de datos y verificar que se han creado:
$ su - postgres $ psql -l List of databases Name | Owner | Encoding -------------------+----------+----------bench_replication | pgpool2 | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows)

Se procede ahora al llenado de la base de datos que se cre con tablas e informacin mediante el uso de pgbench:
/usr/lib/postgresql/8.4/bin/pgbench -i -h 10.34.17.55 -p 9999 -U pgpool2 -d bench_replication

Mediante el siguiente script se procede a contar el nmero de registros insertados en cada instancia de PostgreSQL sin pasar por pgpool-II, de modo que se pueda verificar que la replicacin se ha realizado correctamente:

16

#!/bin/sh PGSQL=/usr/bin/psql HEAD=/usr/bin/head TAIL=/usr/bin/tail CUT=/usr/bin/cut IP_LIST="10.34.17.55 10.34.17.56" PORT=5432 for ip in $IP_LIST do echo "ip address: $ip" for t in pgbench_branches pgbench_tellers pgbench_accounts pgbench_history do echo -n "table $t: " COUNT=`$PGSQL -h $ip -p $PORT -U pgpool2 -d bench_replication -c "SELECT count(*) FROM $t" | $HEAD -n 3 | $TAIL -n 1` echo $COUNT done done exit 0

Para poder ver cmo se balancean las consultas, teniendo activada la directiva log_statement = 'all' en /etc/postgresql/8.4/main/postgresql.conf de ambos PostgreSQL, se puede utilizar el siguiente script para ver qu consultas aparecen en el log de cada nodo:

#!/bin/sh PGSQL=/usr/bin/psql HEAD=/usr/bin/head TAIL=/usr/bin/tail CUT=/usr/bin/cut IP_LIST="10.34.17.55" PORT=9999 for ip in $IP_LIST do echo "ip address: $ip" for t in pgbench_branches pgbench_tellers pgbench_accounts pgbench_history do echo -n "table $t: " COUNT=`$PGSQL -h $ip -p $PORT -U pgpool2 -d bench_replication -c "SELECT count(*) FROM $t" | $HEAD -n 3 | $TAIL -n 1` echo $COUNT done done exit 0

A continuacin se ejecutar el benchmark bsico de pgbench, de modo que se pueda apreciar el comportamiento del clster bajo continuas inserciones, actualizaciones y consultas. Desde la consola ejecutaremos: 17

/usr/lib/postgresql/8.4/bin/pgbench -h 10.34.17.55 -p 9999 -U pgpool2 -d bench_replication -c 10 -t 1000

El resultado obtenido ser similar al siguiente:

[..] transaction type: TPC-B (sort of) scaling factor: 1 number of clients: 1 number of transactions per client: 10 number of transactions actually processed: 10/10 tps = 119.105754 (including connections establishing) tps = 126.179781 (excluding connections establishing)

Si se monitoriza el log de pgpool-II en /var/log/syslog y los logs de ambas instancias de PostgreSQL, se ver cmo en el primer nodo se ejecutan todas las consultas (update, select, update, update, insert) mientras que en el segundo slo las insert y las update. Esto se debe a que cada transaccin est explcitamente declarada (BEGIN...END) y, en ese caso, pgpool-II no hace uso ms que del nodo principal. Instalacin y Configuracin de Heartbeat.

El programa Heartbeat es uno de los componentes principales del proyecto. Fcilmente portable, corre en todos los Linux conocidos, as como en FreeBSD y Solaris. Heartbeat es una de las implementaciones principales del estndar Open Clster Framework (OCF). Heartbeat fue la primera pieza de software que se escribi para el proyecto Linux-HA. Puede llevar a cabo la deteccin de la cada de nodos, las comunicaciones y la gestin del clster en un solo proceso. Actualmente soporta un modelo de dependencias muy sofisticado para clsteres de N nodos, y es muy til y estable. La unidad de gestin de Heartbeat es el recurso. Los recursos pueden ser, por ejemplo, direcciones IP o servicios (aplicaciones). Los siguientes tipos de aplicaciones son tpicos ejemplos:
Servidores de bases de datos. Servidores web. Aplicaciones ERP. Servidores de correo electrnico. Cortafuegos. Servidores de ficheros.

18

 Servidores de DNS. Servidores de DHCP. Servidores de proxy-cach.

El primer paso para la instalacin y configuracin de la herramienta ser su instalacin en ambos nodos:
apt-get install Heartbeat-2

Luego de haber instalado correctamente la herramienta, se necesita saber que los ficheros de configuracin de Heartbeat se encuentran en /etc/ha.d/:
ha.cf: fichero de configuracin principal. haresources: fichero de configuracin de recursos. authkeys: informacin de autenticacin.

Es preciso antes de empezar con el proceso de configuracin de cada unos de los ficheros, introducir dos conceptos de uso frecuente con Heartbeat: Direccin IP de servicio. Direccin IP administrativa. Una direccin de servicio es una direccin que es gestionada por el sistema de Alta Disponibilidad y que es movida por el clster all donde los servicios correspondientes se estn ejecutando. Estas direcciones de servicio son direcciones a travs de las cuales los clientes y usuarios de los servicios en HA (Alta Disponibilidad) acceden a dichos servicios. Tpicamente se almacenan en DNS con nombres conocidos. Es importante que la direccin de servicio no sea gestionada por el sistema operativo, sino que sea el software de HA (Alta Disponibilidad) el nico que la maneje. Si se le da una direccin administrativa al sistema de HA (Alta Disponibilidad) para que la gestione, esto causar problemas pues se confundir al sistema de HA (Alta Disponibilidad) y el sistema operativo de la mquina, pelendose ambos por la direccin IP administrativa de la mquina. En cambio, una direccin administrativa es una direccin que est permanentemente asociada a un nodo especfico del clster. Tales direcciones son muy tiles, y se recomienda encarecidamente que una direccin de este tipo sea reservada para cada nodo del clster, de manera que el administrador de sistemas pueda 19

acceder al nodo del clster incluso si no hay servicios ejecutndose. Para la mayora de sistemas, una direccin de este tipo es obligatoria. Asimismo, se recomienda que se reserve una de estas direcciones para cada interfaz, de modo que se puedan testear las interfaces incluso cuando no estn activas. Tal y como se ha especificado al inicio de este artculo, la configuracin de direcciones administrativas y de servicio es la siguiente: Direccin administrativa pgsql1: 10.34.17.55 Direccin administrativa pgsql2: 10.34.17.56 Direccin de servicio: 192.168.1.1 Si usted est trabajando con mquinas virtuales debe agregar una nueva tarjeta de red por cada nodo que tenga, esto lo hara directamente en la herramienta en este caso Vmware-7.0.1 Pasos a seguir:

1. Hacer clic encima de la opcin Edit virtual machine settings.

20

2. Hacer clic encima de la opcin Network Adapter y presionar el botn adicionar.

21

3. Seleccionamos la opcin Custom: Specific virtual network y dentro de ella seleccionamos el tipo de conexin que deseamos, en este caso VMnet2. Con estos pasos se garantiza la existencia de una nueva tarjeta de red en cada nodo donde se realizaron los anteriores pasos. En el caso que no se est utilizando mquinas virtuales, es decir que se trabaje directamente en el servidor debe configurar la direccin de servicio en el fichero /etc/network/interfaces siempre y cuando no incluyamos su autoconfiguracin (en forma de directiva auto o allow-hotplug). El fichero /etc/network/interfaces del nodo pgsql1 podra quedar tal y como sigue:
auto lo iface lo inet loopback # Direccin administrativa allow-hotplug eth0 iface eth0 inet static address 10.34.17.55 netmask 255.255.255.0 network 10.34.17.0 broadcast 10.34.17.255 gateway 192.168.0.1 # Direccin de servicio iface eth1:0 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255

22

La declaracin de la direccin de servicio en el fichero /etc/network/interfaces es completamente prescindible al usar el agente de recursos IPaddr2. El nico propsito es dejar constancia de ella en el sistema fuera de la configuracin de Heartbeat. A continuacin se edita cada uno de los ficheros de configuracin de Heartbeat: Empezaremos con el fichero ha.cf:
cd /etc/ha.d/ cp /usr/share/doc/heartbeat/ha.cf.gz /etc/ha.d/ gunzip ha.cf.gz

Se edita el fichero /etc/ha.d/ha.cf y se configura a su gusto, por ejemplo tal y como sigue:
debugfile /var/log/ha-debug logfile /var/log/ha-log keepalive 2 deadtime 30 warntime 30 initdead 30 udpport bcast node node 694 eth0 # Linux pgsql1 pgsql2

auto_failback on

Se edita el fichero /etc/ha.d/haresources y se aade la siguiente lnea:

pgsql1 IPaddr2::192.168.1.2/24/eth1:0 pgpool

Esto indica a Heartbeat que el nodo maestro es pgsql1 y que debe gestionar dos recursos: La direccin IP de servicio 192.168.1.2. El servicio pgpool2. El orden es muy importante. Primero se especifica el hostname del nodo que consideramos maestro. Segundo, los recursos. El orden de los recursos tambin es crtico, pues Heartbeat los iniciar en orden de izquierda a derecha, y los detendr en orden de derecha a izquierda (y no 23

queremos que intente arrancar el servicio pgpool2 antes de disponer de la direccin IP en la cual pgpool-II debe escuchar). Heartbeat buscar el script de arranque del servicio que debe gestionar en /etc/init.d. Por lo que se crea un enlace dbil al script de arranque pgpool2 para que Heartbeat pueda encontrarlo:

cd /etc/ha.d/resource.d ln --symbolic /etc/init.d/pgpool

De este modo pgpool2 no se arrancar al iniciarse el nodo, sino que ser Heartbeat quien lo arranque si detecta que as tiene que hacerlo, es decir, si decide que ste nodo debe asumir el papel de maestro. A continuacin se edita el fichero /etc/ha.d/authkeys:

auth 1 1 sha1 8ec030984ba7dc6ba2dadb4ef2204b26

Authkeys es obligatorio que sea accesible slo por el usuario root y que tenga permisos 600. Los dems, 664. Les damos los permisos adecuados a los ficheros:

chown root:root /etc/ha.d/authkeys /etc/ha.d/haresources /etc/ha.d/ha.cf chmod 600 /etc/ha.d/authkeys chmod 664 /etc/ha.d/haresources /etc/ha.d/ha.cf

Finalmente, se configura el logger daemon, especfico de Heartbeat. Se toma el fichero de ejemplo en /usr/share/doc/heartbeat:
cp --archive /usr/share/doc/heartbeat/logd.cf /etc/

Se edita el fichero /etc/logd.cf:

24

debugfile /var/log/ha-debug logfile /var/log/ha-log daemon

logfacility entity logd useapphbd no sendqlen 256 recvqlen 256

Se repiten los anteriores pasos para el nodo pgsql2. Los ficheros de configuracin sern idnticos en ambos nodos, sin diferencia alguna, por lo que podemos copiar los ficheros de configuracin desde pgsql1 a pgsql2 sin problemas. Ahora ya se est en disposicin para iniciar la alta disponibilidad. Debido a que el logd puede estar iniciado con una configuracin por defecto, se debe de estar seguro, primero de que Heartbeat est completamente parado en ambos nodos:
/etc/init.d/heartbeat stop

Es posible que debamos esperar a algn timeout. Ahora, con una diferencia mxima de 120 segundos (directiva initdead en /etc/ha.d/ha.cf), se ejecutar el script de inicio, primero en pgsql1 y despus en pgsql2:
/etc/init.d/heartbeat start

En el syslog se puede observar que se ha establecido la conexin con ambos servidores de PostgreSQL y est esperando peticiones:
tail -n 500 /var/log/syslog | grep pgpool | ccze -A pgsql1 pgpool: LOG: pid 4594: pgpool successfully started

25