Antes que comenzara el diseño de NDB Cluster
en 1996, era evidente que uno de los mayores problemas que
encontraríamos al construir bases de datos paralelas sería la
comunicación entre los nodos de la red. Por esta razón,
NDB Cluster se diseñó desde el comienzo para
permitir el uso de un número de mecanismos de transporte
distintos. En este manual, usamos el término
transporter para ello.
Actualmente el código MySQL Cluster incluye soporte para 4 transportes distintos. La mayoría de usuarios usan TCP/IP sobre Ethernet ya que es ubicuo. Este también es el transporter más probado en MySQL Cluster.
Estamos trabajando para asegurar que la comunicación con el proceso ndbd se hace en “chucnks” tan grandes como sea posible ya que esto beneficia a todos los tipos de transimisión de datos.
Para los usuarios que lo deseen, también es posible usar interconexión de cluster para mejorar el rendimiento. Hay dos formas de hacerlo: puede diseñar un transporter a medida o puede usar implementaciones de socket que sobrepasen la pila TCP/IP de una forma u otra. Hemos expermientando con ambas técnicas usando la tecnología SCI (Scalable Coherent Interface) desarrollada por Dolphin.
En esta secció mostraremos cómo se puede adaptar un cluster configurado para comunicación TCP/IP normal para que use SCI Sockets. Esta documentación se basa en SCI Sockets versión 2.3.0 de 01 Octubre 2004.
Prerequisitos
Cualquier máquina que quiera que use SCI Sockets necesita disponer de tarjetas SCI .
Es posible usar SCI Sockets con cualquier versión de MySQL Cluster. No se necesita ninguna compilación especial ya que usa llamadas de socket normales que están disponibles en MySQL Cluster. Sin embargo, SCI Sockets se soportan sólo en los kernels Linux 2.4 y 2.6 . SCI Transporters se ha probado con éxito en sistemas operativos adicionales aunque sólo lo hemos verificado con Linux 2.4 hasta ahora.
Esencialmente hay cuatro requerimientos para SCI Sockets:
-
Compilar las bibliotecas SCI Socket.
-
Instlara las bibliotecas del kernel SCI Socket.
-
Instalación de uno o dos ficheros de configuración.
-
La biblioteca de kernel SCI Socket debe estar activada para toda la máquina o para la shell en que se arranca el proceso MySQL Cluster.
Este proceso debe repetirse para cada máquina del cluster en que quiera usar SCI Sockets para comunicación entre nodos.
Necesita dos paquetes para que funcione SCI Sockets :
-
El paquete de código fuente con las bibliotecas de soporte DIS para las bibliotecas SCI Sockets .
-
El paquete de código fuente para las bibliotecas SCI Socket mismas.
Actualmente, estan disponible sólo en formato de código
fuente. Las últimas versiones de estos paquetes al escribir
esto están disponibles como (respectivamente)
DIS_GPL_2_5_0_SEP_10_2004.tar.gz y
SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz.
Debería poder encontrar estas versiones (o posteriores) en
http://www.dolphinics.no/support/downloads.html.
Instalación de paquetes
Una vez que tiene los paquetes con las bibliotecas, el siguiente paso es descomprimirlas en los directorios apropiados, con la biblioteca SCI Sockets en un directorio bajo el código DIS. Luego, necesita compilar las bibliotecas. Este ejemplo muestra los comandos usados en Linux/x86 para realizar esta tarea:
shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/ shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz shell> cd ../adm/bin/Linux_pkgs shell> ./make_PSB_66_release
Es posible compilar estas bibliotecas para algunos procesadores 64-bit. Para compilar las bibliotecas para Opteron CPUs usando la extensión 64-bit , ejectue make_PSB_66_X86_64_release en lugar a make_PSB_66_release; si la compilación se hace en una máquina Itanium, debe usar make_PSB_66_IA64_release. La variante X86-64 debe funcionar para arquitecturas Intel EM64T pero no se ha probado.
Una vez que se completa el proceso de compilación ,las
bibliotecas compiladas se encuentran en un fichero tar zipeado
con un nombre entre las líneas de
DIS-<operating-system>-time-date.
Es hora de instalar el paquete en el lugar apropiado. En este
ejemplo lo guardaremos en /opt/DIS.
(Nota: Seguramente necesitará
ejecutar lo siguiente como root del sistema.)
shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/ shell> cd /opt shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz shell> mv DIS_Linux_2.4.20-8_181004 DIS
Configuración de red
Ahora que todos los binarios y bibliotecas están en su lugar adecuado, necesitamos asegurarnos que las tarjetas SCI tiene IDs de nodo adecuados en el espacio de direcciones SCI.
Es necesario decidir la estructura de red antes de seguir. Hay tres tipo de estructura de red que pueden usarse en este contexto:
-
Anillo simple unidimensional
-
Uno o más switches con un anilo para cada puerto de switch
-
Un toro de dos o tres dimensiones.
Cada una de estas topologías tiene su propio método para proporcionar Ids de nodo. Discutimos cada una de las mismas brévemente.
Un anillo simple usa IDs de nodo que son múltipes de 4 distintos a cero: 4, 8, 12,...
La siguiente posibilidad usa swithces SCI. Un switch SCI tiene 8 puertos, cada uno de los cuales puede soportar un anillo. Es necesario asegurarse que distintos anillos usan distintos espacios de nombres. En una configuración típica, el primer puerto usa IDs de nodo por debajo de 64 (4 - 60), el siguiente puerto los siguientes 64 IDs (68 - 124) , y así, con IDs de nodo 452 - 508 siendo asignados al octavo puerto.
Las estructuras de red de toro bi o tri dimensional se tienen en cuenta donde cada nodo se localiza en cada dimensión, incrementando en 4 para cada nodo en la primera dimensión, en 63 cada nodo en la segunda dimensión, y (donde sea aplicable) en 1024 en la tercera dimensión. Consulte Dolphin's Web site para más documentación.
En nuestras pruebasa hemos usado switches, aunque las instalaciones de cluster más grandes usan toros bi o tri dimensionales. La ventaja proporcionada por switches es que, con tarjetas SCI duales y switches duales, es posible constuir con facilidad relativa una red redundante donde el tiempo de fallo medio en la red SCI es del orden de 100 microsegundos. Esto lo soporta el transporte SCI en MySQL Cluster y también está bajo desarrollo par la implementación SCI Socket .
Evitar fallos en el toro 2D/3D es posible pero requiere el envío de nuevos índices de enrutamiento a todos los nodos. Sin embargo, esto requiere sólo 100 milisegundos o así para completarse y debería ser aceptable para la mayoría de casos de alta disponibilidad.
Situar los nodos de datos del cluster adecuadamente en la arquitectura de switch hace que sea posible usar 2 switches para construir una arquitectura en que puedan interconectarse 16 máquinas y que un fallo único no pueda afectar a más de una. Con 32 máquinas y 2 switches se puede configurar el cluster de forma que un fallo único no pueda causar la pérdida de más de dos nodos; en este caso es posible saber qué par de nodos está afectado. Por lo tanto, poner los dos nodos en grupos de nodos separados hace que la instalación de MySQL Cluster sea “segura” .
Para poner el ID de nodo en una tarjeta SCI use el siguiente
comando en el directorio /opt/DIS/sbin. En
este ejemplo -c 1 se refiere al número de la
tarjeta SCI (siempre será 1 si sólo hay 1 tarjeta en la
máquina) , -a 0 se refiere al adaptador 0, y
68 es el ID del nodo:
shell> ./sciconfig -c 1 -a 0 -n 68
Si tiene varias tarjetas SCI en la misma máquina, puede
determinar qué tarjeta tiene cada slot ejecutando el siguiente
comando (de nuevo asumimos que el directorio de trabajo actual
es /opt/DIS/sbin):
shell> ./sciconfig -c 1 -gsn
Esto le retorna el número de serie de la tarjeta SCI. Luego
repita este procedimiento con -c 2, y siga
con cada tarjeta en la máquina. Una vez que ha relacionado cada
tarjeta con cada slot, puede poner los IDs de nodo para todas
las tarjetas.
Una vez instaladas la bibliotecas y binarios necesarios, y
configurado el ID de nodo SCI, el siguiente paso es configurar
el mapeo de nombres de equipo (o direcciones IP) con el ID del
nodo SCI. Esto se realiza en el fichero de configuración de los
sockets SCI, que debería encontrarse en
/etc/sci/scisock.conf. En este fichero,
cada nombre de máquina o dirección IP se mapea con el ID de
nodo SCI. Aquí hay un ejemplo sencillo de un fichero de
configuración:
#host #nodeId alpha 8 beta 12 192.168.10.20 16
Es posible limitar la configuración para que se aplique sólo a
un subconjunto de los puertos disponibles para estos equipos. Un
fichero de configuración adicional
/etc/sci/scisock_opt.conf puede usarse para
esto, como se muestra aquí:
#-key -type -values EnablePortsByDefault yes EnablePort tcp 2200 DisablePort tcp 2201 EnablePortRange tcp 2202 2219 DisablePortRange tcp 2220 2231
Instalación de drivers
Con los ficheros de configuración en su lugar, se pueden instalar los drivers.
Primero los drivers de bajo nivel y luego el driver del socket SCI:
shell> cd DIS/sbin/ shell> ./drv-install add PSB66 shell> ./scisocket-install add
Si se desea, la instalación puede chequearse invocando un script que verifica que todos los nodos en el los ficheros de configuración del socket SCI son accesibles:
shell> cd /opt/DIS/sbin/ shell> ./status.sh
Si descubre un error y necesita cambiar la configuración del socket SCI, es necesario usar ksocketconfig para ello:
shell> cd /opt/DIS/util shell> ./ksocketconfig -f
Testing y Setup
Para asegurar que los sockets SCI están siendo usados, puede
emplear el programa de testeo latency_bench .
Usando este componente del servidor de utilidades, los clientes
pueden conectar con el servidor para testear la latencia de la
conexión; determinar si el SCI está activado o no debe ser muy
simple observando la latencia.
(Nota: Antes de usar
latency_bench, es necesario incializar la
variable de entorno LD_PRELOAD como se
muestra posteriormente.)
Para inicializar un servidor, use:
shell> cd /opt/DIS/bin/socket shell> ./latency_bench -server
Para ejecutar un cliente, use latency_bench
de nuevo, excepto que esta vez con la opción
-client :
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client server_hostname
La configuración del socket SCI debería estar completa ahora y MySQL Cluster preparado para usar SCI Sockets y SCI transporter (consulte Sección 16.4.4.10, “Conexiones de transporte SCI en MySQL Cluster”).
Arrancar el Cluster
El siguiente paso en el proceso es arrancar MySQL Cluster. Para
permitir el uso de SCI Sockets es necesario inicializar la
variable de entorno LD_PRELOAD antes de
arrancar ndbd, mysqld, y
ndb_mgmd. Esta variable debe apuntar a la
biblioteca kernel para SCI Sockets.
Para arrancar ndbd en un bash shell, haga:
bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so bash-shell> ndbd
En un entorno tcsh se puede hacer lo mismo con:
tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so tcsh-shell> ndbd
Nota: MySQL Cluster sólo puede usar la variante de kernel de SCI Sockets.
El proceso ndbd tiene un número de constructores simples que se usan para acceder a los datos en MySQL Cluster. Hemos creado un benchmark sencillo para comprobar el rendimiento de cada uno de ellos y los efectos en el rendimiento de varias interconexiones.
Hay cuatro métodos de acceso:
-
Acceso por clave primaria
Este es el acceso simple a un registro a través de su clave primaria. Es el caso más sencillo en que sólo se accede a un registro a la vez, que significa que el coste total de preparar un número de mensajes TCP/IP y un número de costes para cambio de contexto se envían mediante esta simple petición. En el caaso en que se envían accesos a varias claves primarias en un proceso batch estos accesos comparten el coste de preparar los mensajes TPC/IP necesarios y los cambios de contexto. Si los mensajes TCP/IP son para destinaciones distintas, se debe preparar mensajes adicionales.
-
Acceso por clave única
Son similares a los anteriores, con la excepción que los accesos por clave única se ejecutan como lecturas en una tabla índice seguidos por su acceso por clave primaria a la tabla. Sin embargo, sólo se envía una petición desde el servidor MySQL, y la lectura de la tabla índice es tratada por ndbd. Estas peticiones también se benefician del uso de batch.
-
Escaneo de toda la tabla
Cuando no existen índices para la búsqueda en una tabla, se realiza un escaneo completo. Se envía como petición úncia al proceso ndbd , que divide el escaneo de tabla en un conjunto de escaneos paralelos en todos los procesos ndbd del proceso. En futuras versiones de MySQL Cluster, un nodo SQL será capaz de filtrar algunos de estos escaneos.
-
Escaneo de rangos usando índices ordenados
Cuando se usa un índice ordenado, realiza un escaneo igual que lo hace un escaneo de tabla completo, excepto que escanea sólo los registros en el rango usados por la consulta transmitidas por el MySQL server (nodo SQL).
Para chequear el rendimiento base de estos métodos de acceso hemos desarrollado un conjunto de benchmarks. Uno de ellos testReadPerf, testea accesos simple y en batch por clave primaria y única. Este benchmark también mide el coste de preparar los escaneos de rango ejecutando escaneos que retornan un único registro. Hay una variante de este benchmark que usa un escaneo de rango para recibir un batch de registros.
De este modo, podemos determinar el coste de accesos de clave única y accesos de escaneo de registro simple, así como medir el impacto del medio de comunicación usdo, en métodos de acceso base.
En nuestros tests, ejecutamos los benchmarks para transporters normales usando sockets TCP/IP sockets y una configuración similar usando sockets SCI. Las figuras posteriores son pequeños accesos de 20 registros por acceso. Las diferencias entre accesos seriales y mediante batch se decrementan en un factor de 3 a 4 usando registros de 2 kB. SCI Sockets no se testearon con registros de 2 kB. Los tests se realizaron en un cluster con 2 nodos de datos en 2 máquinas de CPU dual equipadas con procesadores AMD MP1900+ .
Tipo de acceso: TCP/IP sockets SCI Socket Acceso Serial clave primaria: 400 microsegundos 160 microsegundos Acceso Batched clave primaria 28 microsegundos 22 microsegundos Acceso Serial indice unico: 500 microsegundos 250 microsegundos Acceso Batched indice unico: 70 microsegundos 36 microsegundos Acceso Indexado igualdad: 1250 microsegundos 750 microsegundos Índice rango: 24 microsegundos 12 microsegundos
También realizamos otro conjunto de tests para chequear el rendimiento de los SCI Sockets vis-à-vis contra el SCI transporter, y ambos comparados con el TCP/IP transporter. Todos estos tests usaron acceso por clave primaria de forma serial o multi-flujo, o multi-flujo y batch.
Los tests mostraron que los sockets SCI eran 100% más rápido que TCP/IP. El transporter SCI era más rápido en la mayoría de casos comparado con los sockets SCI. Un caso notable ocurrión con muchos flujos en el programa de test, que mostró que el tramporter SCI no funcionaba muy bien usado por el proceso mysqld.
Nuestra conclusión global fue que, para la mayoría de benchmarks, usando sockets SCI mejoraba el rendimiento aproximadamente 100% sobre TCP/IP, excepto en raros casos cuando el rendimiento de la configuración no es un tema importante. Esto puede ocurrir cuando los filtros de escaneo toman la mayoría del tiempo de proceso o cuando los procesos batchs muy grandes de accesos por clave primaria se realizan. En tal caso, el proceso de la CPU en los procesos ndbd es la mayor parte del proceso.
Usar el transporter SCI en lugar de SCI Sockets sólo es de interés en comunicación entre procesos ndbd. Usar el SCI transporter también es sólo de interés si una CPU puede dedicarse al proceso ndbd ya que el SCI transporter se asegura que su proceso nunca estará en espera. Es importante asegurar que la prioridad del proceso ndbd está configurada de tal modo que el proceso no pierde prioridad debido a ejecutarse durante un periodo de tiempo extendido, como puede pasar por bloqueo de procesos por la CPU en Linux 2.6. Si tal configuración es posible, entonces el proceso ndbd se beneficiará de un 10-70% comparado con usar SCI sockets. (Las diferencias más grandes se verán al realizar actualizaciones y probablemente en escaneos paralelos también
Hay otras implementaciones de socket para clusters de máquinas, incluyendo Myrinet, Gigabit Ethernet, Infiniband y la interfaz VIA . Hemos testeado MySQL Cluster hasta ahora sólo con SCI sockets.También incluímos documentación acerca de cómo preparar SCI sockets usando TCP/IP ordinario para MySQL Cluster.