Guía para la Instalación de un clúster de bases de datos

5/13/2018 Guía para la Instalación de un clúster de bases de datos - slidepdf.com

http://slidepdf.com/reader/full/guia-para-la-instalacion-de-un-cluster-de-bases-de-datos 1/25

Guía para la instalación de un clúster de bases de datos

Clúster de altas prestaciones para medianas y pequeñas bases de datos que utilizan a

PostgreSQL como sistema de gestión de bases de datos.

Universidad de las Ciencias Informáticas, Carretera a San Antonio de los Baños, km 2 ½,

Boyeros, Ciudad de la Habana, Cuba.

Autor para la correspondencia:

[email protected]

Yoemir Orduñez Santana, Ing. Adrian Misael Peña Montero, Ing. Marcos Luis Ortiz

Valmaseda, Ing. Daymel Bonne Solís.

Centro de Tecnologías de Gestión de Datos (DATEC)

mailto:[email protected]





2

Tabla de contenido

Prefacio ......................................................................................................................................................... 3

Audiencia ................................................................................................................................................... 3

Secciones de Guía. ..................................................................................................................................... 3

Sobre PostgreSQL. ..................................................................................................................................... 3

Sobre PgPool-II. ......................................................................................................................................... 4

Sobre Debian GNU/Linux ........................................................................................................................... 5

Arquitectura del Sistema ............................................................................................................................ 5

Instalación de paquetes y configuración de dependencias. ........................................................................ 6

Configuración de PostgreSQL. .................................................................................................................... 8

Configuración de PgPool-II ......................................................................................................................... 9

Pruebas de Replicación ............................................................................................................................ 15

Instalación y Configuración de Heartbeat ................................................................................................. 18



3

Prefacio.

Esta guía muestra cómo instalar y configurar un clúster de servidores de bases de datos

PostgreSQL, gestionado mediante un middleware llamado PgPool-II, montado sobre el sistema

operativo Debian GNU/Linux.

El clúster antes mencionado ofrece capacidades de replicación y balanceo de carga.

Este prefacio contiene:

- Audiencia.

- Secciones de la Guía.

Audiencia.

Esta guía está orientada a:

- Administradores de bases de datos PostgreSQL que deseen adquirir habilidades en cuanto

al trabajo con la tecnología clúster, para aumentar la capacidad de respuesta y la

disponibilidad de los servidores que utilicen el SGBD anterior.

Secciones de Guía.

La Guía tiene las siguientes secciones:

Sobre PostgreSQL.

Sobre PgPool-II.

Sobre Debian GNU/Linux.

Arquitectura del sistema.

Instalación de paquetes y configuración.

Configuración de PostgreSQL.

Configuración de PgPool-II.

Pruebas de Replicación.

Instalación y Configuración de Heartbeat.

Sobre PostgreSQL.

PostgreSQL es la base de datos relacional de código abierto más avanzada del mundo. Distribuida

bajo licencia BSD (del inglés, Berkeley Software Distribution ), lleva más de 15 años

desarrollándose y su arquitectura goza de una excelente reputación por su fiabilidad, integridad de

datos y correctitud.



4

PostgreSQL dispone de versiones para prácticamente todos los sistemas operativos y cumple

totalmente con ACID (del inglés, Atomicity, Consistency, Isolation, Durability ). Tiene soporte para

claves extranjeras, joins , vistas, disparadores y procedimientos almacenados (en múltiples

lenguajes de programación). Incluye la mayoría de los tipos de datos de SQL92 y SQL99 y, así

mismo, soporta el almacenamiento de grandes objetos binarios, como imágenes, sonidos y vídeos.

Tiene interfaces de programación nativas para C/C++, Java, .Net, Perl, PHP, Python, Ruby, Tcl y

ODBC además de una excepcional documentación.

PostgreSQL ofrece sofisticadas características tales como control concurrente multi-versión

(MVCC), point in time recovery (PITR), tablespaces , replicación asíncrona, transacciones anidadas

(savepoints ), copias de seguridad en caliente/en línea, 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 configuración de idioma local, de la diferenciación de mayúsculas y minúsculas

y del formato. Es altamente escalable tanto en la cantidad bruta de datos que puede manejar como

en el número de usuarios concurrentes que puede atender. Hay sistemas activos en producción

con PostgreSQL que manejan más de 4 terabytes de datos.

Sobre PgPool-II.

PgPool-II habla los protocolos de frontend y backend de PostgreSQL, y pasa las conexiones entreellos. De ese modo, una aplicación 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 aplicación de base

de datos existente puede empezar a usarse con PgPool-II casi sin ningún cambio en su código

fuente.

PgPool-II funciona sobre Linux, Solaris, FreeBSD y la mayoría de las arquitecturas UNIX (Para

Windows no está soportado). Las versiones de PostgreSQL soportadas son de la 6.4 para arriba.

Para usar la paralelización de consultas es necesaria la versión 7.4 o superior.

PgPool-II proporciona las siguientes características:

Limita el excedente de conexiones.

PostgreSQL soporta un cierto número de conexiones concurrentes y rechaza las que superen

dicha cifra. Aumentar el límite máximo de conexiones incrementa el consumo de recursos y afecta

al rendimiento del sistema. PgPool-II tiene también un límite máximo de conexiones, pero lasconexiones extras se mantienen en una cola en lugar de devolver un error inmediatamente.



5

Pool de conexiones.

PgPool-II mantiene abiertas las conexiones a los servidores PostgreSQL y las reutiliza siempre que

se solicita una nueva conexión con las mismas propiedades (nombre de usuario, base de datos y

versión del protocolo). Ello reduce la sobrecarga en las conexiones y mejora la productividad globaldel sistema.

Replicación.

PgPool-II puede gestionar múltiples servidores PostgreSQL. El uso de la función de replicación

permite crear una copia en dos o más discos físicos, de modo que el servicio puede continuar sin

parar los servidores en caso de fallo en algún disco.

Balanceo de carga.

Si se replica una base de datos, la ejecución de una consulta SELECT en cualquiera de los

servidores devolverá el mismo resultado. PgPool-II se aprovecha de la característica de replicación

para reducir la carga en cada uno de los servidores PostgreSQL distribuyendo las consultas

SELECT entre los múltiples servidores, mejorando así la productividad global del sistema. En el

mejor caso, el rendimiento mejora proporcionalmente al número de servidores PostgreSQL. El

balanceo de carga funciona mejor en la situación en la cual hay muchos usuarios ejecutando

muchas consultas al mismo tiempo.

Paralelización de consultas.

Al usar la función de paralelización 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 ejecución. La paralelización de consultas es una solución adecuada para

búsquedas de datos a gran escala.

Sobre Debian GNU/Linux.

Debian GNU/Linux es un sistema operativo libre (el conjunto de programas básicos y utilidades que

hacen que un ordenador funcione). Debian utiliza el núcleo Linux y las herramientas básicas de

GNU. Para esta instalación se utilizará el sistema operativo Debian Lenny para la arquitectura

x86_64 (AMD64/EM64T), partiendo de una instalación básica, sin ninguna tarea seleccionada en el

selector de tareas del instalador. El sistema de ficheros elegido será XFS.

Arquitectura del Sistema.

Primeramente manejar el término clúster, que no es más que un conjunto de computadoras, amenudo con semejantes componentes de hardware , que se interconectan entre sí a través de un



6

sistema de red de alta velocidad y son capaces de elevar la eficiencia para realizar determinadas

tareas que individualmente no podrían realizar debido a la creciente necesidad de potencia

computacional que demandan algunas aplicaciones.

En esta guía se persiguen dos objetivos:

Alta Disponibilidad.

Alto Rendimiento.

La funcionalidad que se persigue en dicho clúster es que el mismo actúe como servidor de bases

de datos, realizando esta actividad a través 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 dirección IP de servicio .

Esta configuración permite obtener alta disponibilidad de todos los servicios y recursos en las dos

máquinas destinadas a este clúster. El diagrama de la arquitectura resultante sería el siguiente:

Instalación de paquetes y configuración de dependencias.

Se utilizarán las siguientes versiones de software:



7

PostgreSQL-8.4.

PgPool-II-2.2.5.

Heartbeat-2.

A continuación se muestra un resumen de los datos que se usarán:

Nodo 1:

Hostname: pgsql1.

Dirección IP administrativa: 10.34.17.55.

Nodo 2:

Hostname: pgsql2.

Dirección IP administrativa: 10.34.17.56.

PgPool-II:

Dirección IP de servicio: 192.168.1.1.

Puerto de gestión: 9898.

Puerto de servicio: 9999.

Es preciso que las entradas correspondientes a los datos anteriores existan en el fichero

/etc/hosts:

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 compilación de PgPool-II, se resuelven instalando:

Resueltas las dependencias, empezaremos instalando PostgreSQL en ambos nodos:

10.34.17.55 pgsql1

10.34.17.56 pgsql2

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

apt-get install postgresql-8.4 postgresql-contrib-8.4 postgresql-doc-8.4 uuidlibdbd-pg-perl



8

Configuración de PostgreSQL.

Los siguientes pasos se aplican a ambas instancias de PostgreSQL en los nodos pgsql1 y pgsql2.

Se empezará editando la configuración de PostgreSQL para permitir el acceso incondicional del

usuario pgpool2, que será el usuario de base de datos del clúster.

Por incondicional se refiere al modo trust, el cual permite la validación del usuario sin necesidad de

contraseña, este modo se va a configurar en el fichero /etc/postgresql/8.4/main/pg_hba.conf

Debe autenticarse como usuario postgres , para de esta forma crear al superusuario pgpool2:

Se incluirá el acceso para el usuario pgpool2 desde la dirección IP donde se ejecutará el mismo,

(en estos momentos en la dirección 10.34.17.55):

A continuación se edita el siguiente fichero /etc/postgresql/8.3/main/pg_hba.conf

Como vemos anteriormente, al usuario pgpool2, en esta guía 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 autenticación y control de acceso en los modos que

utiliza PgPool-II, los cuales se explican a continuación:

En el modo Replicación y en el modo Maestro-Esclavo, solo son soportados los métodos:

trust y clear text password.

En todos los demás modos que utiliza PgPool-II, se soportan los siguientes métodos: trust,

clear text password, crypt, md5.

A continuación 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

configuración /etc/postgresql/8.3/main/postgresql.conf y cambiamos los dos parámetros

siguientes:

hosts all pgpool2 10.34.17.55/32 trust

su - postgres

createuser --superuser pgpool2

host all pgpool2 10.34.17.55/32 trust



9

Ya que sólo se hará uso de la característica de PITR cuando se vaya a recuperar un nodo caído o

añadir uno nuevo, por defecto se ha configurado el parámetro archive_command para que no haga

nada (exit 0). Esto se hace debido a que la activación o desactivación del archivado de ficheros

WAL requiere de un reinicio del servidor, pero la alteración del comando o script que realiza la

tarea de archivar el fichero WAL rotado por PostgreSQL tan sólo requiere de una recarga de la

configuración.

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

rotándolos 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:

Por último, se indicará a PostgreSQL que escuche en todas las interfaces pues, por defecto, sólo lo

hace en el localhost. Editamos el fichero /etc/postgresql/8.4/main/postgresql.conf cambiando la

siguiente directiva:

También se puede restringir a 127.0.0.1 y la dirección 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

dirección IP de servicio del clúster (la 192.168.1.1, que queremos utilizar únicamente para pgpool-

II).

Se reinicia a PostgreSQL para activar los cambios:

Configuración de PgPool-II.

La configuración de pgpool-II se realizará únicamente en el nodo pgsql1, pues sólo en ese host

está instalado.

archive_mode = on

archive_command = 'exit 0'

mkdir --mode=700 /var/lib/postgresql/pg_xlog_archivechown postgres:postgres /var/lib/postgresql/pg_xlog_archive

listen_addresses = '*'

/etc/init.d/postgresql-8.4 restart



10

El fichero pcp.conf es un fichero de nombres de usuarios y contraseñas, usado para autenticarse

en la interfaz. Todos los comandos requieren que pcp.conf se haya configurado. Tras la instalación

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 añadir el usuario y contraseña deseado.

Posteriormente se edita para añadir el usuario y contraseña en el formato:

En este artículo se usa root como nombre de usuario. Para generar la suma MD5 de nuestra

contraseña podemos usar la utilidad pg_md5:

Luego se crea un f ichero de configuración para pgpool-II a partir del que viene como ejemplo:

Se debe editar el fichero para configurarlo a gusto. Para este artículo se configurarán las

siguientes funcionalidades:

Pool de conexiones.

Replicación.

Balanceo de carga.

Se comenzará con una configuración básica para arrancar pgpool-II y se irán añadiendo

funcionalidades. Editamos el fichero /etc/pgpool-II/pgpool.conf para dejarlo tal y como sigue:

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

Usuario:

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

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



11

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 = 10num_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 = falseignore_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



12

Todas las directivas de configuración están explicadas en la página web de pgpool-II (se adjunta a

este documento dicho manual de PgPool-II). Como aspectos a destacar de la anterior configuración

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 demás

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 comprobación 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 máximo de espera

de 20 segundos.

Se dejan todos los límites de conexiones, número 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 sitúa en /etc/init.d/pgpool , a

continuación se muestra un típico script, basado en el original del paquete pgpool de Debian:



13

#!/bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/binDAEMON=/usr/sbin/pgpoolPIDFILE=/var/run/pgpool/pgpool.pid

test -x $DAEMON || exit 5

# Include pgpool defaults if availableif [ -f /etc/default/pgpool ] ; then

. /etc/default/pgpoolfiinstall -o postgres -d /var/run/pgpoolOPTS=""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:

elsesu -c "$DAEMON -n $OPTS 2>&1 </dev/null | logger -t pgpool -p

${PGPOOL_SYSLOG_FACILITY:-local0}.$fi

}

d_stop() {killproc -p $PIDFILE $DAEMON -INTstatus=$?[ $status -eq 0 ] || [ $status -eq 3 ]return $?

}case "$1" in

start)log_daemon_msg "Starting pgpool-II" pgpoold_startlog_end_msg $?;;stop)

log_daemon_msg "Stopping pgpool-II" pgpoold_stoplog_end_msg $?;;

status)is_runningstatus=$?if [ $status -eq 0 ]; then

log_success_msg "pgpool-II is running."else

log_failure_msg "pgpool-II is not running."fiexit $status

;;



14

Siguiendo el estándar Debian, se creará el fichero /etc/default/pgpool con los valores de

configuración de arranque del daemon. Opcionalmente, se aprovecha para ponerlo en modo debug

al arrancar:

Se arranca PgPool-II:

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 :

# 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 logPGPOOL_LOG_DEBUG=no

/etc/init.d/pgpool start

/usr/bin/tail -f /var/log/syslog | ccze

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|try-

restart|reload|force-reload}"exit 2

;;

esac



15

A partir de este momento se debe ser capaz de conectarse al puerto 9999 de la dirección IP de

administración del nodo pgsql1 (la dirección IP de servicio no estará disponible hasta que

configuremos la alta disponibilidad con Heartbeat):

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 configuración

/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 replicación y el

balanceo de carga editando el fichero /etc/pgpool/pgpool.conf y cambiando las directivas

siguientes:

Para activar los cambios reiniciaremos pgpool-II:

Pruebas de Replicación.

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

ejecución 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 clúster.

Por comodidad, se dará de alta a las entradas del fichero /etc/hosts mencionadas anteriormente

en el artículo, igual que se hizo en ambos nodos del clúster. 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

/var/log/syslog similares a las siguientes:

/usr/bin/psql -h 10.34.17.55 -p 9999 -U pgpool2 -d postgres

replication_mode = trueload_balance_mode = truere lication sto on mismatch = true

/etc/init.d/pgpool restart

createdb -h 10.34.17.55 -p 9999 -U pgpool2 bench_replicationcreatelang -h 10.34.17.55 -p 9999 -U pgpool2 -d bench_replication plpgsql



16

Con log_statement = 'all' en /etc/postgresql/8.4/main/postgresql.conf , en el log de cualquiera de

los PostgreSQL aparecerán las siguientes líneas:

Autenticándose como usuario postgres se puede usar psql para ver las bases de datos y verificar

que se han creado:

Se procede ahora al llenado de la base de datos que se creó con tablas e información mediante el

uso de pgbench:

Mediante el siguiente script se procede a contar el número de registros insertados en cada

instancia de PostgreSQL sin pasar por pgpool-II, de modo que se pueda verificar que la replicación

se ha realizado correctamente:

LOG: connection received: host=10.34.17.55 port=33690LOG: connection authorized: user=pgpool2 database=postgres

LOG: statement: CREATE DATABASE bench_replication;LOG: statement: RESET ALLLOG: statement: SET SESSION AUTHORIZATION DEFAULT

$ su - postgres$ psql -l

List of databases

Name | Owner | Encoding-------------------+----------+-----------bench_replication | pgpool2 | SQL_ASCIIpostgres | postgres | SQL_ASCIItemplate0 | postgres | SQL_ASCIItemplate1 | postgres | SQL_ASCII

(4 rows)

/usr/lib/postgresql/8.4/bin/pgbench -i -h 10.34.17.55 -p 9999 -U pgpool2 -dbench_replication



17

Para poder ver cómo 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:

A continuación se ejecutará el benchmark básico de pgbench , de modo que se pueda apreciar el

comportamiento del clúster bajo continuas inserciones, actualizaciones y consultas. Desde laconsola ejecutaremos:

#!/bin/sh

PGSQL=/usr/bin/psqlHEAD=/usr/bin/headTAIL=/usr/bin/tailCUT=/usr/bin/cutIP_LIST="10.34.17.55 10.34.17.56"PORT=5432

for ip in $IP_LISTdo

echo "ip address: $ip"for t in pgbench_branches pgbench_tellers pgbench_accounts

pgbench_historydo

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

#!/bin/sh

PGSQL=/usr/bin/psqlHEAD=/usr/bin/headTAIL=/usr/bin/tailCUT=/usr/bin/cutIP_LIST="10.34.17.55"PORT=9999

for ip in $IP_LISTdo

echo "ip address: $ip"for t in pgbench_branches pgbench_tellers pgbench_accounts

pgbench_historydo

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 $COUNTdone

done



18

El resultado obtenido será similar al siguiente:

Si se monitoriza el log de pgpool-II en /var/log/syslog y los logs de ambas instancias de

PostgreSQL, se verá cómo en el primer nodo se ejecutan todas las consultas (update, select,

update, update, insert ) mientras que en el segundo sólo las insert y las update . Esto se debe a que

cada transacción está explícitamente declarada (BEGIN ...END ) y, en ese caso, pgpool-II no hace

uso más que del nodo principal.

Instalación y Configuración de Heartbeat.

El programa Heartbeat es uno de los componentes principales del proyecto. Fácilmente portable,

corre en todos los Linux conocidos, así como en FreeBSD y Solaris. Heartbeat es una de las

implementaciones principales del estándar Open Clúster Framework (OCF).

Heartbeat fue la primera pieza de software que se escribió para el proyecto Linux-HA. Puede llevar

a cabo la detección de la caída de nodos, las comunicaciones y la gestión del clúster en un solo

proceso. Actualmente soporta un modelo de dependencias muy sofisticado para clústeres de N

nodos, y es muy útil y estable. La unidad de gestión de Heartbeat es el recurso. Los recursos

pueden ser, por ejemplo, direcciones IP o servicios (aplicaciones). Los siguientes tipos de

aplicaciones son típicos ejemplos:

Servidores de bases de datos.

Servidores web.

Aplicaciones ERP.

Servidores de correo electrónico.

Cortafuegos.

Servidores de ficheros.

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

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

http://if%28confirm%28%27http//opencf.org/%20%20/n/nThis%20file%20was%20not%20retrieved%20by%20Teleport%20Pro,%20because%20it%20is%20addressed%20on%20a%20domain%20or%20path%20outside%20the%20boundaries%20set%20for%20its%20Starting%20Address.%20%20/n/nDo%20you%20want%20to%20open%20it%20from%20the%20server?%27))window.location=%27http://opencf.org/%27

http://if%28confirm%28%27http//opencf.org/%20%20/n/nThis%20file%20was%20not%20retrieved%20by%20Teleport%20Pro,%20because%20it%20is%20addressed%20on%20a%20domain%20or%20path%20outside%20the%20boundaries%20set%20for%20its%20Starting%20Address.%20%20/n/nDo%20you%20want%20to%20open%20it%20from%20the%20server?%27))window.location=%27http://opencf.org/%27



19

Servidores de DNS.

Servidores de DHCP.

Servidores de proxy-caché.

El primer paso para la instalación y configuración de la herramienta será su instalación en ambos

nodos:

Luego de haber instalado correctamente la herramienta, se necesita saber que los ficheros de

configuración de Heartbeat se encuentran en /etc/ha.d/:

ha.cf: fichero de configuración principal.

haresources: fichero de configuración de recursos.

authkeys: información de autenticación.

Es preciso antes de empezar con el proceso de configuración de cada unos de los ficheros,

introducir dos conceptos de uso frecuente con Heartbeat:

Dirección IP de servicio.

Dirección IP administrativa.

Una dirección de servicio es una dirección que es gestionada por el sistema de Alta Disponibilidad

y que es movida por el clúster allí donde los servicios correspondientes se estén ejecutando. Estas

direcciones de servicio son direcciones a través de las cuales los clientes y usuarios de los

servicios en HA (Alta Disponibilidad) acceden a dichos servicios. Típicamente se almacenan en

DNS con nombres conocidos.

Es importante que la dirección 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 direcciónadministrativa 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 máquina,

peleándose ambos por la dirección IP administrativa de la máquina.

En cambio, una dirección administrativa es una dirección que está permanentemente asociada a un

nodo específico del clúster.

Tales direcciones son muy útiles, y se recomienda encarecidamente que una dirección de este tipo

sea reservada para cada nodo del clúster, de manera que el administrador de sistemas pueda

apt-get install Heartbeat-2



20

acceder al nodo del clúster incluso si no hay servicios ejecutándose. Para la mayoría de sistemas,

una dirección 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 estén activas.

Tal y como se ha especificado al inicio de este artículo, la configuración de direcciones

administrativas y de servicio es la siguiente:

Dirección administrativa pgsql1: 10.34.17.55

Dirección administrativa pgsql2: 10.34.17.56

Dirección de servicio: 192.168.1.1

Si usted está trabajando con máquinas virtuales debe agregar una nueva tarjeta de red por cada

nodo que tenga, esto lo haría directamente en la herramienta en este caso Vmware-7.0.1

Pasos a seguir:

1. Hacer clic encima de la opción “Edit virtual machine setting s”.



21

2. Hacer clic encima de la opción “Network Adapter ” y presionar el botón adicionar.



22

3. Seleccionamos la opción Custom : “Specific virtual network ” y dentro de ella

seleccionamos el tipo de conexión 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 máquinas virtuales, es decir que se trabaje directamente en el

servidor debe configurar la dirección de servicio en el fichero /etc/network/interfaces siempre y

cuando no incluyamos su autoconfiguración (en forma de directiva auto o allow-hotplug). El fichero

/etc/network/interfaces del nodo pgsql1 podría quedar tal y como sigue:

auto loiface lo inet loopback

# Dirección administrativaallow-hotplug eth0iface eth0 inet static

address 10.34.17.55netmask 255.255.255.0network 10.34.17.0broadcast 10.34.17.255gateway 192.168.0.1

# Dirección de servicioiface eth1:0 inet staticaddress 192.168.1.2netmask 255.255.255.0network 192.168.1.0broadcast 192.168.1.255



23

La declaración de la dirección de servicio en el fichero /etc/network/interfaces es completamente

prescindible al usar el agente de recursos IPaddr2. El único propósito es dejar constancia de ella

en el sistema fuera de la configuración de Heartbeat.

A continuación se edita cada uno de los ficheros de configuración de Heartbeat:

Empezaremos con el fichero ha.cf :

Se edita el fichero /etc/ha.d/ha.cf y se configura a su gusto, por ejemplo tal y como sigue:

Se edita el fichero /etc/ha.d/haresources y se añade la siguiente línea:

Esto indica a Heartbeat que el nodo maestro es pgsql1 y que debe gestionar dos recursos:

La dirección 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 también es crítico, pues Heartbeat los

iniciará en orden de izquierda a derecha, y los detendrá en orden de derecha a izquierda (y no

cd /etc/ha.d/cp /usr/share/doc/heartbeat/ha.cf.gz /etc/ha.d/gunzip ha.cf.gz

debugfile /var/log/ha-debug

logfile /var/log/ha-log

keepalive 2

deadtime 30

warntime 30

initdead 30

udpport 694

bcast eth0 # Linux

auto_failback on

node pgsql1

node pgsql2

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



24

queremos que intente arrancar el servicio pgpool2 antes de disponer de la dirección 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 débil al script de arranque pgpool2 para que Heartbeat pueda encontrarlo:

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 continuación se edita el f ichero /etc/ha.d/authkeys :

Authkeys es obligatorio que sea accesible sólo por el usuario root y que tenga permisos 600. Los

demás, 664. Les damos los permisos adecuados a los ficheros:

Finalmente, se configura el logger daemon, específico de Heartbeat. Se toma el fichero de ejemplo

en /usr/share/doc/heartbeat :

Se edita el fichero /etc/logd.cf :

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

auth 1

1 sha1 8ec030984ba7dc6ba2dadb4ef2204b26

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

cp --archive /usr/share/doc/heartbeat/logd.cf /etc/



25

Se repiten los anteriores pasos para el nodo pgsql2. Los ficheros de configuración serán idénticos

en ambos nodos, sin diferencia alguna, por lo que podemos copiar los ficheros de configuración

desde pgsql1 a pgsql2 sin problemas.

Ahora ya se está en disposición para iniciar la alta disponibilidad. Debido a que el logd puede estar

iniciado con una configuración por defecto, se debe de estar seguro, primero de que Heartbeat está

completamente parado en ambos nodos:

Es posible que debamos esperar a algún timeout . Ahora, con una diferencia máxima de 120

segundos (directiva initdead en /etc/ha.d/ha.cf ), se ejecutará el script de inicio, primero en pgsql1 y

después en pgsql2:

En el syslog se puede observar que se ha establecido la conexión con ambos servidores de

PostgreSQL y está esperando peticiones:

debugfile /var/log/ha-debug

logfile /var/log/ha-log

logfacility daemon

entity logd

useapphbd no

sendqlen 256

recvqlen 256

/etc/init.d/heartbeat stop

/etc/init.d/heartbeat start

tail -n 500 /var/log/syslog | grep pgpool | ccze -Apgsql1 pgpool: LOG: pid 4594: pgpool successfully started

Documents

Guía para la Instalación de un clúster de bases de datos