Modulado 3.0

if (bored) try { while ( ! ( this.succeed() )) } catch ( IhaveSoMuchTimeException e) {};

Cluster de alta disponibilidad y balance de carga para tu Base de datos

Seguro que alguna vez te has encontrado con la situación de que tu base de datos tiene demasiada carga y te enfrentas a un eterno dilema, actualizar el hardware a un servidor más potente o adquirir hardware más económico y montar un cluster. En ambas situaciones nos enfrentamos a la decisión de tener que hacer una inversión económica y nos surge la duda de elegir la decisión correcta. Cuando hay dinero de por medio, no siempre es fácil para un administrador de sistemas convencer al jefe de cual es la solución “óptima”, a no ser que éste goce de plena confianza por parte de su jefe.

Pues bien, con este artículo intentaré plasmar algunas de las ventajas que tiene la opción dos, el cluster frente a hardware de última generación.

Lo primero que tenemos que plantearnos es lo siguiente, siempre tenemos que preveer que nuestra base de datos puede crecer hasta el punto de que tanto la carga del servidor como el espacio puede llegar a ser un problema. Por eso mismo, una configuración en cluster puede ayudarnos a solventar problemas en un futuro. Otra cosa a tener en cuenta, es la disponibilidad, pues para muchas empresas e instituciones, la caída de la base de datos puede suponer perdidas económicas cuantitativas, o el no poder ofrecer un tipo de servicio específico, estas y muchas otras situaciones problemáticas ya tipificadas  que pueden generarnos un gran dolor de cabeza. En cuanto al espacio, dependiendo del crecimiento de la propia base de datos, quizás este problema sea fácilmente solventable añadiendo simplemente discos duros al servidor principal, pero incluso en muchos casos esto no es suficiente, dependiendo como he dicho de la magnitud de la base de datos.

Ahora bien ¿Cómo puede ayudar un cluster en este tipo de situaciones? De forma muy sencilla, por el clásico divide y vencerás. Una configuración en cluster consiste en una serie de servidores que trabajan al unísono como si fueran uno sólo, ofreciendo: alto rendimiento, alta disponibilidad, balance de carga y escalabilidad. Un esquema sencillo de este tipo de configuración usando un mínimo de tres servidores sería el siguiente:

Esquema 1
Esquema 1

Como podemos apreciar en la imagen, tenemos un servidor principal al que llamamos Director, ¿Cuales son sus funciones? Este servidor se encarga de gestionar el balance de carga entre los nodos y al mismo tiempo de comprobar que ambos nodos están activos (alta disponibilidad). Normalmente, las aplicaciones que se encargan de comprobar la disponibilidad se les conoce como Heartbeart (latido de corazón), y su función principal es asegurarse de que al menos uno de los nodos esta activo para poder garantizar el servicio. Un ejemplo de software que se encarga de ofrecer este tipo de servicio es UltraMonkey. Hoy día, por suerte, también disponemos de soluciones bastante competentes como  MySQL Cluster, que consta de las herramientas necesarias para que podamos configurar nuestro cluster para nuestra base de datos (con sus limitaciones) sin tener muchos problemas. Normalmente, en configuraciones corporativas, el balanceo de carga es llevado a cabo por el front-end del cluster, que son una serie de máquinas que se encargan de repartir las peticiones del cluster principal que se conoce como back-end. En nuestro caso, nuestro front-end sería solo la máquina Director y nuestro back-end los nodos 1 y 2, pero tengamos en cuenta que también podrían ser dos o varias las que se encargaran de este proceso. Un software que por desgracia ha dejado de desarrollarse que se encargaba de esta función de balanceo era OpenMosix.

De este modo, podemos sacar claramente las ventajas que tiene invertir un poco de tiempo y dinero en configurar nuestros servidores usando un modelo de Cluster. Puesto que el fallo de una de las máquinas (Nodos) no supondría el cese del servicio. Además, en cuanto a escalabilidad, simplemente tendríamos que añadir nuevos servidores a la configuración, tanto en la parte de balanceo como en los nodos, incluso, si el espacio empezara a convertirse en un problema, podríamos añadir un servicio de almacenamiento externo (distribuido).

Se que este artículo se puede extender mucho más, pero mi intención no es tanto la de que esto se convierta en un tutorial, mas bien, ayudar a quién no esté tan especializado en estos temas a que pueda tomar una buena decisión.

Anuncios

6 Respuestas a “Cluster de alta disponibilidad y balance de carga para tu Base de datos

  1. PAul noviembre 28, 2008 en 4:07 am

    Muy bueno !!! Ahora falta la parte práctica con ejemplos de MySQL Cluster o pgCluster 🙂

  2. rfpp noviembre 28, 2008 en 4:26 pm

    Gracias, es precisamente lo que estoy preparando Paul.

  3. Miguel diciembre 7, 2008 en 12:09 am

    Interesante, unas preguntas. ¿Nodo 1 y 2 son réplicas exactas, no? ¿De ser así, cómo funciona cuando escribimos a la base de datos? Por último, en el esquema si falla el “Director” se cae todo. ¿Entonces que recomendarías, tener un buen servidor para el Director o tener otro Director de respaldo?

  4. rfpp diciembre 7, 2008 en 3:13 pm

    Hola Miguel, veo que te has adelantado a la siguiente entrada que estaba preparando, aún así responderé con mucho gusto.
    Lo primero que quiero destacar es que el esquema que puse en la entrada es un poco “irreal”, lo único que quería era explicar un poco las diferentes funciones de ciertas máquinas en un cluster. Ahora bien, siguiendo el mismo esquema, como tu bien dices, Nodo 1 y 2 son replicas exactas que reciben peticiones de consulta del Director, ¿Como funciona a la hora de escribir? Dependerá del SGBD que estemos usando, y sobretodo tener en cuenta un detalle importante referente a la configuración. Hablando de MySQL tenemos que diferenciar entre MySQL Cluster y replicación. En una configuración de replicas (que no es nuestro caso) siempre tenemos un servidor maestro y otro esclavo. Por lo tanto las transacciones se hacen de forma secuencial y es el maestro el que se encarga de actualizar los nodos de replica (esclavos). El problema principal que podemos encontrar con la replicación es que se nos puede dar el caso de una transacción lenta o algún otro tipo de problema en alguno de los nodos esclavos y de este modo podríamos llegar a tener inconsistencia en los datos que tenemos en cada uno de los nodos (no se si me explico correctamente). Con MySQL Cluster en el momento que uno de los nodos recibe una transacción se actualiza automáticamente en el resto de los nodos. Esto se consigue gracias al motor NDB que incorpora MySQL Cluster y es crucial que las tablas de nuestra base de datos (de cada Nodo) usen este engine si queremos que funcione correctamente. Los datos técnicos de como se produce dicha actualización no los conozco, tampoco soy un experto en la materia.
    Respondiendo a tu segunda pregunta, lo ideal es tener siempre un mínimo de dos maquinas que funcionen como director. Digamos que es crucial para el correcto funcionamiento que el front-end del cluster no se caiga. Si falla el director, apaga y vámonos. Por eso dependerá de cuantas máquinas dispongas para el cluster. Conozco muchos casos que hacen configuraciones de alta disponibilidad-balance de carga con dos maquinas solamente. Ambas las configuran como nodo y director. Si estas pensando en hacer algo parecido te invito a que ojees la documentación de UltraMonkey. Aún así pronto publicaré una entrada precisamente hablando un poco sobre este tema, de todas formas, espero que esta respuesta este a la altura de tus preguntas.

  5. Pingback:Linux Virtual Server: Clusters en Linux « desmierdes 3.0

  6. keyla julio 25, 2010 en 9:17 pm

    Interesante tengo una duda, si se usa un cluster mysql el balanceo de cargar entre los nodos es automatico o es manual???? que se necesitaria para configurar el balanceo de carga?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: