DEPARTAMENTO ADMINISTRATIVO NACIONAL DE ESTADÍSTICA. Oficina de Sistemas

Tamaño: px

Comenzar la demostración a partir de la página:

Download "DEPARTAMENTO ADMINISTRATIVO NACIONAL DE ESTADÍSTICA. Oficina de Sistemas"

Andrea Ortega Tebar
hace 8 años
Vistas:

1 DEPARTAMENTO ADMINISTRATIVO NACIONAL DE ESTADÍSTICA Oficina de Sistemas INFRAESTRUCTURA BASE DE DATOS Mayo de 2011

2 TABLA DE CONTENIDO 1. TIPO DE BASE DE DATOS BALANCEO DE CARGA PARA SERVIDORES DE APLICACIÓN CONFIGURACIÓN ACTUAL REQUERIMIENTOS Servidor de aplicaciones Servidores físicos REFERENCIAS

CONFIGURACIÓN ACTUAL... 5 4. REQUERIMIENTOS... 6 4.

3 1. TIPO DE BASE DE DATOS Es una base de datos relacional en SGBD MySQL, open source distribuida bajo licencia dual es decir posee una versión comunitaria y una versión Enterprise, se puede ejecutar en la gran mayoría de sistemas operativos existentes en la actualidad, entre ellos Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows. Las características más importantes y soportadas son: Es una base de datos 100% ACID Llaves Foraneas(foreign keys) Joins Vistas (views) Disparadores (triggers) Reglas (Rules) Funciones/procedimientos almacenados (stored procedures) Soporta el almacenamiento de objetos binarios grandes (gráficos, videos, sonido,...) Replicación asincrona Nested transactions (savepoints) Two-phase commit Copias de seguridad en caliente (Online/hot backups) Unicode Juegos de caracteres internacionales SQL92/SQL99 La instalación de la base de datos bajo MySQL se puede hacer de diferentes formas, así: Un servidor de Base de datos: Esta alternativa presenta un servidor dedicado de base de datos en el cual toma importancia el afinamiento de los parámetros que se realicen sobre la configuración de MySQL, si bien es la configuración más sencilla dado que solo es necesario la instalación de la herramienta y del afinamiento de la configuración no presenta ningún esquema redundante frente a fallos. Dos servidores uno maestro el otro esclavo: En este esquema se plantea tener 2 servidores uno que posea instalado MySQL, en este se define un nodo maestro que será el encargado de responder las peticiones realizadas por los usuarios, y un servidor esclavo el cual es simplemente 3

Las características más importantes y soportadas son: Es una base de datos 100% ACID Llaves Foraneas(foreign keys) Joins Vistas (views) Disparadores (triggers) Reglas (Rules) Funciones/procedimientos

4 una réplica del servidor maestro. En caso de que el servidor maestro falle el servidor esclavo asume el papel de servidor maestro y responde las peticiones solicitadas. 2. BALANCEO DE CARGA PARA SERVIDORES DE APLICACIÓN La instalación de servidores de aplicación para la infraestructura se puede hacer de diferentes formas, así: Un servidor. Dos servidores: Un servidor secundario se activa manualmente en caso de que el primario falle. Dos servidores: Un servidor secundario se activa automáticamente en caso de que el primario falle. Dos servidores: El servidor primario y el secundario atienden peticiones HTTP usando IPs diferentes. Dos servidores: Los dos atienden peticiones usando una IP. Uso de dos servidores dedicados para balanceo de carga y por lo menos dos servidores WEB. Se propone que se usen dos servidores para balanceo de carga, y dos servidores para servir páginas WEB. La alternativa con un servidor es la más fácil de administrar pero al mismo tiempo es la que ofrece menos respaldo en caso de fallos en de hardware o software. Tener dos servidores es útil debido a que existe un servidor secundario disponible para ser usado si el primario falla. No obstante el que los dos servidores no estén activos todo el tiempo hace que el administrador de los servidores no esté obligado a que los dos sean funcionales en todo momento y es probable que por falta de tiempo se termine usando un sólo servidor. En caso de que se decida usar un servidor de respaldo y tenerlo configurado todo el tiempo, cuando sólo hay un servidor activo es más difícil garantizar que el servidor de respaldo funcionará correctamente si es necesario usarlo. En este caso el servidor secundario se activa automáticamente, y esto es mejor que hacerlo de forma manual. De todas formas se heredan las desventajas de la alternativa 2. Cuando se usan dos servidores web activos al tiempo es más fácil 4

Dos servidores: Un servidor secundario se activa manualmente en caso de que el primario falle. Dos servidores: Un servidor secundario se activa automáticamente en caso de que el primario falle.

5 garantizar el respaldo en caso de fallas de uno de los servidores. Se suele definir dos IPs para un mismo dominio en un servidor DNS para hacer que se usen los dos servidores. Esta forma de balanceo no es perfecta por el caché que se realiza con el protocolo DNS pero de todas formas es un método bastante usado. Cuando dos servidores atienden usando una IP, se puede tener un balanceador de carga de uno de los dos servidores (en el activo). Esta solución tiene una ventaja, y es que los dos servidores deben estar configurados en todo momento, por lo que si uno de ellos falla el otro estará listo para mantener la disponibilidad. Una desventaja es que el balanceador de carga comparte CPU con el servidor web (Apache en este caso), y si por alguna razón el apache consume todo el cómputo disponible esto afectará al balanceador. Este efecto está mitigado por el uso de un usuario privilegiado para ejecutar el balanceador de carga (root), por lo que este proceso correrá con mayor prioridad que Apache2 que no corre como root, sino como usuario sin privilegios. Usar dos servidores dedicados para balanceo de carga y por lo menos dos servidores WEB es una alternativa atractiva porque los computadores dedicados a balanceo de carga y alta disponibilidad no realizan procesamiento adicional y esto permite garantizar que estas máquinas se comporten de manera estable. Si se compara con la alternativa anterior, se nota que en este caso un problema con el servidor web Apache no afectará la alta disponibilidad. Los dos balanceadores de carga operan automáticamente y si uno de ellos deja de funcionar, el otro entra en operación rápidamente. Esto garantiza alta disponibilidad así como mayor desempeño. Otra ventaja de esta solución es que es escalable y tolerante a más fallos. Puede fallar uno de los balanceadores, también pueden fallar los servidores HTTP. Es escalable porque se pueden destinar más de dos servidores para servir peticiones HTTP. A continuación se describe detalladamente la configuración actual y la propuesta. 3. CONFIGURACIÓN ACTUAL La configuración propuesta incluye cuatro servidores. Dos de bajo desempeño y dos de alto desempeño. Los dos últimos ya son los que ya se han instalado. Esta corresponde a la alternativa 6. 5

Cuando dos servidores atienden usando una IP, se puede tener un balanceador de carga de uno de los dos servidores (en el activo).

6 VENTAJAS En cuanto a seguridad, ya que la base de datos y los servidores WEB no quedan físicamente conectados a la Intranet y a sus usuarios. Sólo los balanceadores de carga quedan conectados a la Intranet y estos tienen instalado el mínimo número de programas y un programa Firewall que sólo deja abiertos algunos puertos necesarios (80 y 22 usualmente). Se puede hacer mantenimiento a los servidores sin necesidad de interrumpir el servicio a todos los usuarios, ya que en todo momento uno de los balanceadores o uno de los servidores WEB puede ser sacado de servicio. Los computadores para balanceo de carga no necesitan ser de grandes prestaciones, pero cada uno de ellos requiere dos tarjetas de red. Los balanceadores de carga ejecutan el programa Heartbeat, que se encarga de hacer que uno de ellos sea el principal. Para esto, el programa heartbeat intercambia latidos (beats) por Ethernet y por puerto serial, si este está disponible. Esto permite que uno de ellos sea seleccionado como activo. El balanceador activo ejecuta un balanceador de carga IP (Linux Virtual Server - LVS), que se encarga de redirigir las conexiones a los servidores WEB disponibles. Si uno de los servidores WEB deja de responder peticiones HTTP, LVS lo saca de pool de servidores y sólo envía peticiones a los servidores activos. Este monitoreo es configurable, y usualmente se hace haciendo una petición HTTP periódica a los servidores (por ejemplo, a /status.php). Si la petición falla, el balanceador sabrá que el servidor no está disponible. Para facilidad de administración se recomienda el uso del programa keepalived, que facilita la administración del servidor. La configuración de los servidores WEB no es diferente a la actual. Cada uno ejecuta Apache y los programas necesarios para acceder al almacenamiento de archivos compartidos. El servidor de bases de datos se puede mantener dentro de la zona de servidores, aislado de la Intranet usando una VLAN. 4. REQUERIMIENTOS Para la configuración actual se necesitan los siguientes requerimientos de Hardware y Software. 6

7 Aplicación de captura y seguimiento a los operativos: 4.1 Servidor de aplicaciones Apache o superior PHP 5.3 o superior Mysql 5.0 o superior OCFS o superior Haproxy 1.6 o superior Hearthbeat stonith o superior Birt 2.6 o superior Jboss 5 o superior. 4.2 Servidores físicos Dos servidores de 2 procesadores con 4 Gb de ram Servidores de aplicación. Dos servidores de 2 procesadores con 6 Gb de ram Servidores de base de datos. Dos servidores de 2 procesadores con 2GB de ram Servidores de balanceo de cargas. Los valores de la configuración son los valores que poseen los servidores actualmente, la infraestructura si se desea aumentar el valor de estos valores es viable, no requieren ser maquinas físicas, pero si se desea colocar en un esquema virtualizado se recomienda que no queden en la misma máquina para no perder la alta disponibilidad que plantea la configuración. Se recomienda la utilización de sistema operativo Linux kernel 2.6 o superior. 7

Dos servidores de 2 procesadores con 6 Gb de ram Servidores de base de datos. Dos servidores de 2 procesadores con 2GB de ram Servidores de balanceo de cargas.

8 5. REFERENCIAS Heartbeat : HAProxy: Keepalived: Linux Virtual Server: 8

Documentos relacionados

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED. Antonio Madrena Lucenilla 21 de Diciembre de 2012 I.E.S.

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED Obra bajo licencia Creative Commons Antonio Madrena Lucenilla 21 de Diciembre de 2012 I.E.S. Gonzalo Nazareno INDICE DE CONTENIDO