WoSeBerry - Memoria técnica

Lista NO numerada:

• Esquemas
• Objetivos
• Comparativas
• Pruebas
• Divagar

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 2 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.

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