MySQL Cluster

MySQL Cluster
Información sobre la plantilla
MySQL Cluster.jpeg
Motor de almacenamiento de MySQL
LicenciaGNU
Sitio web
Sitio oficial de MySQL Cluster


MySQL Cluster. Es una versión de alta disponibilidad, alta redundancia de MySQL adaptada para el entorno de computación distribuida. Usa el motor de almacenamiento NDB Cluster para permitir la ejecución de varios servidores MySQL en un cluster. Este motor de almacenamiento está disponible en las distribuciones binarias de MySQL 5.0 y en los RPMs compatibles con las distribuciones Linux más modernas.

Panorámica

MySQL Cluster es una tecnología que permite clustering de bases de datos en memoria en un entorno de no compartición. La arquitectura de no compartición permite que el sistema funcione con hardware barato, y sin ningún requerimiento especial de hardware o software. Tampoco tienen ningún punto único de fallo porque cada componente tiene su propia memoria y disco.

MySQL Cluster integra el servidor MySQL estándar con un motor de almacenamiento clusterizado en memoria llamado NDB.

Conceptos básicos de Basic MySQL Cluster

Motor de almacenamiento NDB

Este es un motor de almacenamiento en memoria que ofrece alta disponibilidad y persistencia de datos. Es altamente configurable ofreciendo un gran número de opciones para manejar el balanceo de cargas y la tolerancia a fallas.

Nodo de administración (Nodo MGM)

Este tipo de nodo cumple con la función de manejar, controlar y coordinar los otros nodos dentro del clúster. Implementa funciones de configuración de datos, Iniciar o detener otros nodos dentro del clúster, ejecutar respaldos, u otras tareas administrativas. Debido a que controla y configura el resto de los nodos, debe iniciarse antes que cualquier otro tipo de nodos utilizando el comando ndb_mgmd.

Nodo de datos

Este tipo de nodo almacena los datos. La cantidad de nodos de este tipo dentro del cluster es igual a a la cantidad de replicas por la cantidad de fragmentos. Es decir, si se manejan 4 replicas de los datos con 2 fragmentos, se necesitarían 8 nodos de datos. No es necesario manejar más de una réplica. Este tipo de nodo se levanta utilizando el comando ndbd.

Nodo SQL (MySQL server)

A través de este tipo de nodos se accede a los datos clusterizados. Básicamente, consiste en un servidor MySQL Server que utiliza el motor de almacenamiento NDB. Se inicia utilizando el comando ndbcluster, especificando el archivo de configuración necesario para este servidor .

Clientes MySQL

Para conectarse a un cluster MySQL remotamente, se debe utilizar el mismo cliente utilizado para conectarse a un servidor MySQL no clusterizado. El clúster es transparente para los clientes.

Clientes administrativos

Existen otro tipo de clientes que se comunican con el servidor de administración y proveen las mismas funcionalidades que un nodo de este tipo. A diferencia de los nodos administrativos, los clientes permiten ejecutar las tareas de administración remotamente. Algunas tareas que pueden realizarse con estos clientes incluyen iniciar o detener nodos, administrar el seguimiento de mensajes de depuración, mostrar el estado de otros nodos y sus respectivas versiones, realizar respaldos, etc.

Elementos de la Arquitectura

Un MySQL Cluster consiste en un conjunto de máquinas, cada una ejecutando un número de procesos incluyendo servidores MySQL , nodos de datos para NDB Cluster, servidores de administración, y programas especializados de acceso a datos.

La arquitectura de MySQL CLuster está diseñada para no tener un sólo punto de falla, cada componente será un servidor independiente y debe tener su propia capacidad de almacenamiento y memoria para trabajar. En la arquitectura del Clúster de MySQL se proponen cuatro puntos, un manager, un nodos SQL y dos nodos de datos, esto con el fin de distribuir las cargas, mantener una gran disponibilidad y redundancia de datos.

El Clúster de MySQL está conformado por tres tipos de nodos, estos son:

El nodo de administración (ndb_mgmd) : Este tipo de nodo cumple con la función de manejar, controlar y coordinar los otros nodos dentro del clúster, proporciona datos de configuración, permite iniciar y parar nodos, ejecutar copias de seguridad, permite conocer el estado de los nodos de datos y ejecuta otras actividades administrativas. Como este tipo de nodo administra la configuración de otros nodos, un nodo de este tipo debe arrancarse primero, antes de cualquier otro nodo. En ambientes de alta disponibilidad es recomendable tener más de un nodo de administración o manager node.

El nodo de datos (ndbd) : Este es el tipo de nodo que almacena los datos del cluster. Hay tantos nodos de datos como réplicas. No es necesario tener más de un nodo de datos pero si solo se tiene un nodo de datos la redundancia se perdería, por eso en el modelo planteado se propone trabajar con dos nodos de datos, los cuales trabajarán de manera sincronizada y cada uno será la réplica del otro.

El nodo SQL (mysqld): Estos nodos son los que accede a los datos del clúster y los que mantienen los esquemas de las bases del LMS. En el caso de MySQL Cluster, un nodo cliente es un servidor MySQL tradicional que usa el motor NDB Cluster. Estos nodos serán los nodos por medio de los cuales las aplicaciones accederán a los datos almacenados en la base de datos, en este caso el Cluster de base de datos.

La arquitectura presentada en este ejemplo es una arquitectura básica en la que se muestra como instalar y configurar una base de datos en clúster de MySQL. Es importante aclarar que en ambientes de alta disponibilidad es recomendable instalar más de un nodo manager y más de un nodo SQL, esto con el fin de distribuir cargas y respaldar siempre el funcionamiento del sistema.

Arquitectura-MySQLCluster.png

Todos estos programas funcionan juntos para formar un MySQL Cluster. Cuando se almacenan los datos en el motor NDB Cluster, las tablas se almacenan en los nodos de datos. Tales tablas son directamente accesibles desde todos los otros servidores MySQL en el cluster. Los datos almacenados en los nodos de datos de MySQL Cluster pueden replicarse: el cluster puede tratar fallos de nodos de datos individuales sin otro impacto a parte de abortar unas pocas transacciones debido a la pérdida de estado de transacción. Como las aplicaciones transaccionales se suponen que tratan fallos transaccionales, esto no debería ser un problema.

Al llevar MySQL Cluster al mundo Open Source , MySQL propociona tratamiento de datos clusterizado con alta disponibilidad, alto rendimiento, y escalabilidad disponible para todo el que lo necesite.

Procesos principales

MySQLD El proceso de servidor de bases de datos tradicional que puede ser utilizado en ambientes de clúster o aislado. Para que este proceso sea utilizado dentro de un clúster MySQL, necesita ser construido especialmente para soportar el motor de almacenamiento NDB, los binarios compilados disponibles en el sitio de MySQL ya integran esta funcionalidad al proceso.

Una manera fácil de asegurase que se dispone de la versión correcta para un clúster MySQL es invocando el comando SHOW ENGINES dentro del ambiente desde el servidor buscando la existencia del motor NDB. Este comando muestra la totalidad de los motores soportados por el proceso actualmente instalado.

Para poder unir un servidor MySQL a un cluster, es necesario poder interactuar con el nodo de administración de dicho cluster. Para esto en el archivo de configuración de MySQL (my.cfg) se debe especificar el string de conexión a dicho servidor. La comunicación entre servidores se realiza mediante el protocolo TCP/IP por lo cual es necesario indicar en el string de conexión la dirección IP del nodo administrativo y el puerto en el cual se publica el servicio de administración.

NDBD

El proceso ndbd es el encargado de manejar todos los datos de las tablas utilizando el motor ndbd clúster. Este proceso soporta la funcionalidad de manejo de transacciones distribuidas entre los nodos, recuperación de nodos defectuosos o fuera de línea, checkpoint to disk (el momento en el que los datos son escritos efectivamente a disco), respaldo en línea, y otras tareas relativas a la distribución del clúster.

El conjunto de procesos distribuido ndbd cooperan colectivamente en la tarea de manejo de datos. Cada uno de estos procesos genera un conjunto de archivos de log independientes que es almacenado en el directorio DataDir especificado en el archivo de configuración de cada nodo de datos (config.ini). Para poder conectar un nodo de datos es necesario proveer al proceso ndbd con la información necesaria acerca del nodo administrativo. Análogamente a como se realiza con el nodo MySQLserver, se debe especificar dirección IP y puerto del mismo en el archivo de configuración.

Cuándo un proceso ndbd comienza su ejecución, se levantan dos procesos, uno de ellos es llamado angel. El proceso angel supervisa la ejecución del proceso de almacenamiento, y en caso de falla, vuelve a iniciarlo. Por esto, si se intenta detener el proceso ndbd utilizando el comando kill de Unix, es necesario acabar con los dos procesos, comenzando con el proceso angel, dado que sino este volverá a iniciar el proceso de datos. La mejor manera de acabar con un proceso ndbd de un nodo es utilizando los comandos apropiados en el nodo de administración o utilizando un cliente de administración externo.

El proceso de ejecución utiliza un hilo para leer, escribir, escanear datos y realizar otras actividades. Este hilo está implementado de manera asíncrona con el objetivo de poder realizar fácilmente múltiples actividades concurrentes. Se utiliza otro hilo para supervisar que la ejecución no se detenga o genere un deadlock. El acceso a los archivos en el disco se realiza a través de múltiples hilos, manejando cada uno un archivo de datos en particular. De esta forma el proceso ndbd es capaz de hacer uso exhaustivo de arquitecturas con múltiples procesadores de una manera óptima.

NDB_MGMD

Es el proceso que controla el servidor de administración, siendo responsable de conocer y mantener la configuración del clúster y distribuir dicha información a todos los nodos que la soliciten al unirse al cluster. Mantiene también el log de las actividades del clúster y reporta su estado a los clientes que se conectan a él.

En un esquema con un único servidor de administración, no es necesario especificar un string de conexión al nodo de administración dado que es el mismo el propio servidor. Si se está trabajando en un esquema donde existe más de un nodo de administración se debe especificar identificar cada uno con un ID específico e indicar las cadenas de conexión a cada uno de ellos.

Junto con el proceso NDB_MDMd se encuentra ndb_mgm, que es responsable de manejar el cliente de administración que interactúa con el nodo de administración. El cliente de administración se comunica con el nodo de administración utilizando una API en C. Esta API se puede utilizar para desarrollar aplicaciones dedicadas a controlar y administrar el clúster de una manera personalizada.

Hardware, software y redes

Una de las ventajas de MySQL Cluster es que puede ejecutarse en hardware normal sin ningún requerimiento especial a parte de grandes cantidades de RAM, debido al hecho que todos los datos se almacenan en memoria. Naturalmente, múltiples CPUs y más rápidas mejoran el rendimiento. Los requerimientos de memoria para procesos cluster son relativamente pequeños.

Los requerimientos de software para Cluster son modestos. Los sistemas operativos de las máquinas no requieren ningún modulo no usual, servicios, aplicaciones o configuración extraña para soportar MySQL Cluster.

  • Para Linux los requerimientos del software MySQL son simples: todo lo necesario es una versión de producción de MySQL-MAX 5.0; para tener soporte de cluster. No es necesario compilar MySQL para usar cluster.

Para la comunicación entre nodos, el cluster soporta red TCP/IP en cualquier topología estándar, y como mínimo se espera una red 100 Mbps Ethernet , más un switch, hub, o router para proporcionar conectividad de red al cluster entero. Se recomienda que MySQL Cluster se ejecute en su subred que no está compartida con máquinas no-cluster por las siguientes razones:

Seguridad: La comunicación entre nodos del cluster no está cifradas. La única forma de proteger transmisiones dentro de un MySQL Cluster es ejecutar su cluster en una red protegida. Si se trata de usar MySQL Cluster para aplicaciones Web , el cluster debe residir detrás de un firewall y no en su DMZ o en otro lugar.

Eficiencia: Inicializar un MySQL Cluster en una red privada o protegida permite que el cluster haga uso exclusivo del ancho de banda entre máquinas del cluster. Usar un switch para el MySQL Cluster no sólo ayuda a protegerse de accesos no autorizados a los datos del cluster, también asegura que los nodos del cluster están protegidos de interferencias causadas por transmisiones entre otras máquinas en la red. Para mayor confianza se puede usar switches duales y tarjetas duales para eliminar la red como punto único de fallo; varios dispositivos soportan fallos para estos enlaces de comunicación.

Para evitar reserva innecesaria de recursos, el servidor se configura por defecto con el motor NDB desactivado. Para activar NDB, se necesita configurar el fichero de configuración my.cnf del servidor con la opción --ndbcluster .

Desde que MySQL server es parte del cluster, necesita datos de configuración que sepa cómo acceder al nodo MGM para obtener datos de configuración del cluster. El comportamiento por defecto es buscar el nodo MGM en localhost. Sin embargo, se puede especificar su localización donde se encuentre, esto puede hacerse en my.cnf o en la línea de comandos del servidor MySQL. Antes de poderse usar el NDB, al menos un nodo MGM debe ser operacional, así como los nodos de datos deseados.

Configuración

Configurar MySQL Cluster requiere trabajar con dos ficheros:

my.cnf: Especifica opciones para todos los ejecutables del MySQL Cluster . Este fichero, debe ser accesible por cada ejecutable del cluster.

config.ini: Este fichero es de sólo lectura por el servidor de administración del MySQL Cluster , que distribuye la información contenida en el mismo a todos los procesos participantes en el cluster. config.ini contiene una descripción de cada nodo del cluster. Esto incluye los parámetros de configuración para nodos de datos y parámetros de configuración para conexiones entre todos los nodos del cluster.

Conexiones TCP/IP

TCP/IP es el mecanismo de transporte por defecto para establecer conexiones en MySQL Cluster. Normalmente no es necesario definir conexiones ya que el cluster automáticamente crea una conexión entre todos los nodos de datos, entre cada nodo de datos y los nodos MySQL server y entre cada nodo y el servidor de administración.

Fuentes

  • Manual de MySQL 5.0 MySql Cluster. Disponible en: “dev.mysql.com”. Consultado el 23 de noviembre del 2011