WoSeBerry - Memoria técnica

Lista cosas a poner:

• Esquemas
• Objetivos
• Comparativas
• Pruebas
• Divagar

Motivos para utilizar Raspberry Pi

Inicialmente contemplamos la posibilidad de realizar el proyecto en placas Raspberry Pi en vez de en simples máquinas virtuales para cumplir con uno de los teóricos requisitos para los proyectos de este año y también para llevar a cabo el proyecto de un modo más real y similar a como podríamos implementarlo en un entorno de producción.

El principal motivo para utilizar las Raspberry ha sido el propósito educativo, ya que de este modo, hemos podido tener varios servidores físicos independientes y comunicarlos entre sí mediante balanceadores de carga, creando clústeres y demás técnicas, que han aumentado el rendimiento y la alta disponibilidad de la arquitectura implementada.

Pero aunque nosotros en un primer momento consideramos que probablemente crear los servidores en placas Raspberry no sería la solución ideal para un entorno de producción, la realidad, basándonos en diferentes pruebas de rendimiento realizadas, nos ha demostrado que es una posibilidad 100% viable y debe considerarse como una opción válida a la hora de llevar a cabo un proyecto real.

Utilizar placas Raspberry Pi en lugar de en servidores tradicionales nos ofrece diferentes ventajas. En primer lugar y como es evidente la cuestión del espacio físico, ya que no todo el mundo dispone de un espacio grande y óptimo para poder montar varios servidores con sus cajas, cables... una pequeña Raspberry (o varias de ellas) nos solucionan el tema del espacio. Por otro lado, está el no menos importante tema económico, ya que por menos de 40€ podemos adquirir una Raspberry Pi y un servidor sencillo difícilmente lo conseguiremos por menos de 400€, lo que significa que el precio por servidor se dispararía considerablemente. Además, gracias a su alimentación por USB, su consumo será prácticamente nulo, por lo que no supondrá un gasto de añadido a la empresa que quiera montar una infraestructura con Raspberry Pi.

Por otro lado, el hardware de una Raspberry te permite implementar cualquier tipo de servidor, no únicamente una tienda online. Pueden llegar a utilizarse a modo de cámara de vigilancia, servidor web o incluso servidor de archivos.

Por todo lo anteriormente expuesto, consideramos que para cualquier pequeña e incluso dependiendo el caso, mediana empresa, montar sus servidores en placas Raspberry Pi sería una muy buena opción que les ahorraría espacio, tiempo y dinero.

Ventajas y desventajas tipos de clúster de base de datos

Elegir el tipo de aquitectura sobre la cual implementaremos nuestras bases de datos no es una decisión trivial, ya que de ello también dependerá el buen funcionamiento de un proyecto y además, hay que tener en cuenta que cambiar esto una vez en producción es complicado e indudablemente ocasionaría paros en el servicio. Debe ser una decisión tomada en base a un análisis de las ventajas y desventajas de cada modelo, teniendo en cuenta múltiples factores y valorando cada una de las posibilidades, ya que una mala elección desde el inicio podría provocar futuros problemas como inoperatividad del servicio.

Los dos principales tipos de clúster existentes y que hemos evaluado para el proyecto son Master-Slave y Master-Master.

Arquitectura Master-Slave
Ventajas	- Facilidad para hacer backups ya que una de las bases de datos es de solo lectura. - Las aplicaciones analíticas pueden leer del esclavo sin afectar al rendimiento del maestro. - Los esclavos se pueden desconectar y volver a sincronizar con el maestro sin tiempo de inactividad.
Desventajas	- En el caso de un fallo, un esclavo debe ser promovido/transformado a maestro para tomar su lugar. Sin conmutación por error automática o con implementación compleja. - Tiempo de inactividad y posiblemente pérdida de datos cuando falla un master. - Todas las escrituras tienen que hacerse directamente a la base de datos master. - Cada esclavo adicional agrega algo de carga al maestro, ya que el registro binario debe leer y copiar los datos a cada esclavo. - La aplicación podría tener que reiniciarse en caso de fallo del maestro.

Arquitectura Master-Master
Ventajas	- Si un maestro falla, otros maestros continúan actualizando la base de datos. - Los Masters se pueden ubicar en varios sitios físicos, es decir, distribuidos en la red. - Las aplicaciones pueden leer y escribir en ambas bases de datos. - Distribuye la carga de escritura en ambos nodos maestros, por lo tanto obtenemos un mayor rendimiento de escritura. - Conmutación por fallo simple, automática y rápida.
Desventajas	- Los sistemas de replicación son más complejos de configurar y aumentan la latencia de la comunicación. - Problemas como la resolución de conflictos pueden volverse intratables a medida que aumenta el número de nodos implicados y podrían hacer este sistema menos consistente.

Una vez evaluados los pros y contras de cada tipo de clúster y las necesidades del proyecto que llevamos a cabo, hemos decidido implementar el clúster de tipo Master-Master. Este modelo es el que más ventajas nos ofrece, en cuanto a disponibilidad, rendimiento, flexibilidad, etc. Y como nuestro proyecto consta de 3 bases de datos, podemos mantener la latencia de la comunicación controlada con unos buenos tiempos de respuesta. Por ello consideramos que aunque pueda requerir algo más de configuración que otros tipos de cluster, merece la pena la inversión de ese tiempo, porque sin duda el modelo Master-Master es el más recomendable en este caso.

Utilizar como mínimo 3 nodos de base de datos

Un clúster de bases de datos master-master con 2 nodos creado con Galera Cluster no nos proporcionará un servicio de alta disponibilidad.

Para un funcionamiento correcto el cual ofrezca una integridad de datos y un servicio de alta disponibilidad, debemos disponer con al menos 3 nodos (o más), teniendo preferiblemente un número impar de éstos en nuestra infraestructura. Esto es así debido al quorum con el que galera trabaja y utiliza cuando falla uno o más nodos. El quorum es el algoritmo que utiliza galera para determinar la viabilidad en la replicación en caso de que uno o varios nodos hayan caído y vuelvan a estar operativos.

Además de los fallos de un solo nodo, el clúster puede dividirse en varios componentes debido a una fallo de la red. Un componente es un conjunto de nodos que están conectados entre sí, pero no a los nodos que forman otros componentes. En estas situaciones, solo un componente puede continuar modificando el estado de la base de datos para evitar la divergencia del historial y mantener la integridad de los datos. Este componente se llama componente primario.

Escenario con un clúster formado por tres nodos

Cuando por el motivo que sea, un nodo o varios nodos fallan o pierden la comunicación con los otros, el tamaño del componente (grupo de nodos comunicados entre si) es el que determinará qué grupo de nodos activos se convierte en el componente principal y por lo tanto obtiene el quorum del clúster y puede continuar modificando la base de datos.

El quórum requiere una mayoría, lo que significa que no puede tener conmutación por error automática en un clúster de dos nodos. Esto es porque el fallo de uno, hace que el nodo restante pase automáticamente a un estado no primario, es decir, en un cluster de 2 nodos, si uno de los 2 falla, el servicio deja de ser accesible para conservar la integridad de los datos.

Escenario con un clúster formado por dos nodos

Los clústeres que tienen un número par de nodos corren el riesgo de quedar inoperativos si se pierde la conectividad en la red de manera que la cantidad de nodos se divida exactamente a la mitad y a ambos lados haya el mismo número de nodos. En tal caso, ninguno de los dos grupos de nodos puede retener el quórum y ambos ingresan en un estado no primario. Para minimizar el riesgo de que esto suceda en clústeres que tienen un número par de nodos, se puede dividir previamente el clúster de forma que un componente siempre disponga de un mayor número de nodos y por lo tanto le otorguemos la condición de componente primario.

Existe una fórmula matemática para el cálculo del quórum que nos indica que el quórum sólo se conserva si el peso de la suma de los nodos en un nuevo componente, excede estrictamente la mitad que el componente primario anterior.

Fórmula para calcular el quorum

Por defecto, el peso de un nodo es 1, pero esto se puede personalizar utilizando el parámetro pc.weight

Si deseamos modificar el peso de un nodo, y aumentarlo por ejemplo a 2, entraremos en la base de datos en cuestión e introduciremos el siguiente comando:

mysql> SET  GLOBAL  wsrep_provider_options = "pc.weight = 2" ;

Crear y configurar certificados SSL autofirmados

Mediante el paquete de herramientas OpenSSL podemos crear certificados SSL autofirmados para disponer de un acceso seguro a nuestra web mediante el navegador a través de https, aunque como estáran firmados por nosotros mismos y no por una entidad certificadora oficial, el navegador nos mostrará el candado de color rojo.

En primer lugar activamos el modulo SSL de apache2.

pi@BERRY-02:~$ sudo a2enmod ssl

Creamos una carpeta para almacenar las claves.

pi@BERRY-02:~$ sudo mkdir /etc/apache2/ssl

Ahora crearemos la clave privada y pública.

pi@BERRY-02:~$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/woseberry.key -out /etc/apache2/ssl/woseberry.crt

Introducimos los datos que nos solicita, en nuestro caso los siguientes:

Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Barcelona
Locality Name (eg, city) []:Barcelona
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Woseberry
Organizational Unit Name (eg, section) []:Woseberry
Common Name (e.g. server FQDN or YOUR name) []:192.168.30.2
Email Address []:[email protected]

Como resultado obtendremos la clave privada y certificado correspondientes:

• woseberry.key → Clave privada
• woseberry.crt → Certificado

Concatenamos la clave privada y el certificado en un mismo archivo con extensión .pem

pi@BERRY-02:~$ sudo cat /etc/apache2/ssl/woseberry.key /etc/apache2/ssl/woseberry.crt > /etc/apache2/ssl/woseberry.pem

Antes de modificar el archivo default-ssl.conf, hacemos una copia de seguridad del site SSL.

pi@BERRY-02:~$ sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Ahora ya podemos modificar el archivo del site SSL.

pi@BERRY-02:~$ sudo nano /etc/apache2/sites-available/default-ssl.conf

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin [email protected]
                
                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on
                SSLCertificateFile      /etc/apache2/ssl/woseberry.crt
                SSLCertificateKeyFile /etc/apache2/ssl/woseberry.key

                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

        </VirtualHost>
</IfModule>

Habilitamos el site con SSL.

pi@BERRY-02:~$ sudo a2ensite default-ssl.conf

Para aplicar los cambios debemos reiniciar el servicio de apache2.

pi@BERRY-02:~$ sudo service apache2 restart