Diferència entre revisions de la pàgina «WoSeBerry - Manual técnico»
| Línia 809: | Línia 809: | ||
| − | == Pruebas de rendimiento == | + | == Pruebas de rendimiento - Apache Benchmark == |
Como suele ser habitual en cualquier proyecto, una vez tenemos la infraestructura funcionando, es conveniente realizar las correspondientes pruebas de rendimiento. En nuestro caso, realizaremos pruebas principalmente sobre el servidor web apache y registraremos sus resultados. | Como suele ser habitual en cualquier proyecto, una vez tenemos la infraestructura funcionando, es conveniente realizar las correspondientes pruebas de rendimiento. En nuestro caso, realizaremos pruebas principalmente sobre el servidor web apache y registraremos sus resultados. | ||
Revisió del 14:13, 25 maig 2018
En esta página se explicará la instalación y configuración del software necesario para llevar a cabo el proyecto Woseberry.
Configuración de las Raspberry Pi
Instalación del sistema operativo
Todas las Raspberry Pi de nuestro proyecto cuentan con el sistema operativo Raspbian. Este sistema es la adaptación de la distribución Debian adaptada al hardware de una Raspberry. A excepción del resto de Raspberry, la Raspberry con función de firewall (BERRY-01) llevará instalada la versión con interfaz gráfica.
Una vez instalado el sistema operativo Raspbian en cada una de las Raspberry, procederemos a la configuración básica con la ejecución del siguiente comando:
$ sudo raspi-config
Asignación del direccionamiento IP
Dado que el proyecto está montado bajo una LAN, se creó una red independiente con IPs de clase privada de tipo C. Para configurar la IP estática en las Raspberry deberemos editar el siguiente fichero:
$ sudo nano /etc/dhcpcd.conf
En éste asignaremos el direccionamiento correspondiente a cada Raspberry:
| BERRY-01 | BERRY-02 | BERRY-03 | |||
|---|---|---|---|---|---|
 |
|
 |
|
|
|
| BERRY-04 | BERRY-05 | BERRY-06 | |||
|
|
|
|
|
|
Configuración básica para la Raspberry firewall
Dado que todo el escenario estará montado bajo una LAN, deberemos configurar en la Raspberry con función de firewall (BERRY-01) aspectos como:
- Servidor DNS: Nos proporcionará la asignación de un dominio para la tienda online.
- Enrutamiento: Permitirá la circulación de tráfico.
- Enmascaramiento: Permitirá enmascarar el tráfico de la red LAN con la IP de la interfaz "eth1".
Servidor DNS
Para configurar un servidor DNS en Raspbian necesitaremos instalar el paquete "bind9", para ello ejecutaremos el siguiente comando:
pi@BERRY-01:~$ sudo apt install bind9
Una vez instalado, realizaremos una copia de seguridad de los archivos de configuración. De esta manera, en caso de tener un error podremos restaurar la configuración por defecto:
pi@BERRY-01:~$ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak pi@BERRY-01:~$ sudo cp /etc/bind/db.local /etc/bind/db.woseberry
Seguidamente editaremos el archivo /etc/bind/named.conf.local para crear la zona directa e indicar cual es el archivo que contiene su configuración:
pi@BERRY-01:~$ sudo nano /etc/bind/named.conf.local
zone "woseberry.tk" {
type master;
file "/etc/bind/db.woseberry";
};
Por último, crearemos la zona directa editando el fichero /etc/bind/db.woseberry
pi@BERRY-01:~$ sudo nano /etc/bind/db.woseberry
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA woseberry.tk. root.woseberry.tk. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS woseberry.tk
@ IN A 192.168.30.123
BERRY-01 IN A 192.168.30.254
BERRY-02 IN A 192.168.30.2
BERRY-03 IN A 192.168.30.3
BERRY-04 IN A 192.168.30.4
BERRY-05 IN A 192.168.30.5
BERRY-06 IN A 192.168.30.6
Enrutamiento y enmascaramiento
Dado que la BERRY-01 es la encargada de dar acceso a Internet a la LAN, es primordial activar la directiva de enrutamiento además de enmascarar las IP de la LAN por la IP de la interfaz eth1. Para ello, editaremos el archivo /etc/rc.local con la finalidad de que dichas directivas se ejecuten en el inicio del sistema.
pi@BERRY-01:~$ sudo nano /etc/rc.local
… # Activar el enrutamiento echo 1 > /proc/sys/net/ipv4/ip_forward # Enmascarar el tráfico de la LAN con la IP de la interfaz que nos proporciona salida a Internet iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o eth1 -j MASQUERADE exit 0
Instalación y configuración WordPress
Ahora que tenemos salida a Internet desde la LAN procederemos a realizar la instalación del los servidores de base de datos y los gestores de contenido WordPress.
Instalación servidor base de datos MySQL
Instalaremos el paquete mysql-server en las BERRY-04, BERRY-05 y BERRY-06, las cuales son las encargadas de almacenar todos los datos que se generarán en la tienda virtual. Para ello ejecutaremos el siguiente comando en las tres Raspberry:
$ sudo apt install mysql-server mysql-client phpmyadmin
Finalizada la instalación, generaremos un usuario llamado pi que tendrá todos los privilegios en cualquier base de datos y desde cualquier máquina. Realizaremos la siguiente operación en las tres Raspberry:
pi@BERRY-04:~$ sudo su root@BERRY-04:/home/pi# mysql -u root MariaDB [(none)]> CREATE USER 'pi'@'%' IDENTIFIED BY 'woseberry'; MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'pi'@'%'; MariaDB [(none)]> FLUSH PRIVILEGES; MariaDB [(none)]> exit;
Aprovechando que estamos gestionando las bases de datos y los usuarios, crearemos una base de datos llamada wordpress y un usuario con el mismo nombre con permisos sobre esa base de datos.
MariaDB [(none)]> CREATE DATABASE wordpress; MariaDB [(none)]> GRANT ALL ON wordpress.* TO 'wordpress'@'%' IDENTIFIED BY 'woseberry'; MariaDB [(none)]> FLUSH PRIVILEGES; MariaDB [(none)]> exit;
Instalación servidor web apache
Con los servidores de base de datos ya en marcha en las BERRY-04, BERRY-05 y BERRY-06, procederemos a la instalación de los servidores web en las BERRY-02 y BERRY-03. Para que WordPress funcione correctamente, necesitamos instalar los siguientes paquetes en ambas Raspberry:
$ sudo apt-get install apache2 php7.0 libapache2-mod-php7.0 php7.0-mysql php7.0-curl php7.0-gd php7.0-imap php7.0-mcrypt php7.0-recode php7.0-tidy php7.0-xmlrpc
Descarga, instalación y configuración WordPress
¡Importante! Todos estos pasos deberán realizarse en las BERRY-02 y BERRY-03 de manera idéntica. Excepto en el archivo de configuración wp-config.php, el cual se indicarán IP distintas en la base de datos
Una vez tenemos operativo el servicio de apache2 junto al resto de dependencias necesarias, procederemos con la instalación y configuración de WordPress. Por tal de mejorar la seguridad en la tienda virtual, nos descargaremos la última versión estable, la cual corrige todos los errores encontrados hasta la fecha.
Para ello, ejecutaremos el siguiente comando en las BERRY-02 y BERRY-03:
$ wget https://es.wordpress.org/wordpress-4.9.5-es_ES.zip
Seguidamente, descomprimiremos el gestor de contenido y lo copiaremos en el directorio /var/www/html:
$ unzip wordpress-4.9.5-es_ES.zip $ sudo cp -R wordpress/* /var/www/html
Dado que en la instalación de apache2 nos genera un archivo index.html en el que podemos ver que el servicio está funcionando correctamente, procederemos a eliminarlo para que no haya conflicto con el resto de archivos de WordPress:
$ sudo rm /var/www/html/index.html
Una vez hecho esto, copiaremos el archivo de configuración de WordPress para proceder a su configuración más adelante:
$ sudo cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php
Modificaremos los permisos de los archivos de WordPress por tal de que no estén asignados al usuario root:
$ sudo chown -R www-data:www-data /var/www/html/ $ sudo chmod -R 755 /var/www/html/
Por último, activaremos dos módulos de apache2 esenciales para el funcionamiento correcto de WordPress:
$ sudo a2enmod headers $ sudo a2enmod rewrite
Finalizados todos los pasos, reiniciaremos apache2 para aplicar los cambios:
$ sudo service apache2 restart
El siguiente paso será configurar WordPress indicandole la ubicación de la base de datos, junto al usuario y contraseña que la administrarán. Por ahora, la BERRY-02 apuntará a la base de datos BERRY-04. Por otro lado, la BERRY-03 apuntará a la BERRY-05.
Modificamos el archivo de configuración wp-config.php para vincularlo con la base de datos correspondiente.
pi@BERRY-02:~$ sudo nano /var/www/html/wp-config.php
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'wordpress');
/** MySQL database password */
define('DB_PASSWORD', 'woseberry');
/** MySQL hostname */
define('DB_HOST', '192.168.30.4');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', );
Y para la BERRY-03 su configuración será la siguiente:
pi@BERRY-03:~$ sudo nano /var/www/html/wp-config.php
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'wordpress');
/** MySQL database password */
define('DB_PASSWORD', 'woseberry');
/** MySQL hostname */
define('DB_HOST', '192.168.30.5');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', );
Ahora solo nos falta completar el proceso de instalación desde la interfaz web. Para ello, en la barra de direcciones de un navegador web, escribimos el dominio o la dirección IP del servidor de la siguiente forma http://dominio_o_IP
En nuestro caso, accederemos mediante el dominio:
http://woseberry.tk
Certificados SSL - HTTPS
Dado que la finalidad es conseguir una tienda online que sea operativa, es primordial que cuente con unos certificados SSL que acrediten que la tienda es segura y se puede comprar en ella sin miedo a que nuestros datos se vean comprometidos por falta de seguridad. Para ello, las empresas suelen pagar por unos certificados validados por entidades certificadoras que acreditan la autenticidad de los certificados. Sin embargo, también existe la posibilidad de hacerlo de manera gratuita completando unos formularios y cumpliendo determinados requisitos. Paralelamente, también debemos realizar las configuraciones oportunas para que nuestro site funcione de forma segura a través del puerto 443 con el protocolo HTTPS.
Crear, configurar e instalar certificados - Let's Encrypt
Podemos utilizar la página web Get HTTPS for free para conseguir unos certificados válidos acreditados por esta entidad. Para ello se deben siguir ciertos pasos que detallamos a continuación.
Generar clave privada y solicitud de firma de certificado
Para generar una clave privada ejecutamos el siguiente comando en una de las Raspberry Pi.
$ openssl genrsa 4096 > Certificados/domain.key
Seguidamente generamos una petición de firma de certificado (CSR) con el dominio, en nuestro caso woseberry.tk
$ openssl req -new -sha256 -key Certificados/domain.key -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=DNS:woseberry.tk"))
Firmar la petición API
Para que la entidad Let’s Encrypt pueda validar que somos realmente nosotros quienes solicitamos los certificados y los que disponemos del servidor donde queremos instalarlos, deberemos ir generando unas claves a partir de nuestra clave privada. De este modo, devolviendo el HASH resultante podrán acreditar nuestra identidad y propiedad del dominio. Uno de los pasos a realizar es la configuración de un registro TXT en los DNS de nuestro proveedor de dominio que apunten al dominio woseberry.tk. Por esta razón, es primordial tener registrado dicho dominio y apuntarlo a un servidor público en Internet. De esta manera, al configurar el registro TXT en el DNS, Let’s Encrypt podrá validar correctamente nuestra identidad.
Instalación de certificados
Una vez finalizados los pasos anteriores, dispondremos de 3 claves:
- domain.key
- domain.crt
- intermediate.pem
Estas claves las utilizaremos tanto en los servidores Apache de las Raspberry BERRY-02 y BERRY-03 como para la BERRY-01 con HAProxy. Por lo tanto, es primordial disponer de estos tres archivos en las tres Raspberry. Para ello, podemos copiarlos mediante el siguiente comando en la Raspberry correspondiente.
$ scp Certificados/* pi@BERRY-01:/home/pi/Certificados $ scp Certificados/* pi@BERRY-02:/home/pi/Certificados $ scp Certificados/* pi@BERRY-03:/home/pi/Certificados
Creamos la misma carpeta en las tres Raspberry para almacenar las claves.
$ sudo mkdir /etc/apache2/ssl
Una vez hayamos transferido los certificados y tengamos la carpeta /etc/apache2/ssl creada en las tres Raspberry, moveremos las claves a dicha carpeta mediante el siguiente comando.
$ sudo mv Certificados/* /etc/apache2/ssl
Configuración de los servidores web con los certificados
¡Importante! Esta configuración deberá realizarse en las BERRY-02 y BERRY-03.
En primer lugar activamos el modulo SSL de apache2.
$ sudo a2enmod ssl
Antes de modificar el archivo de configuración default-ssl.conf, hacemos una copia de seguridad del site SSL.
$ 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 y especificar las rutas al certificado y clave privada.
$ 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/domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/domain.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</IfModule>
Habilitamos el site con SSL.
$ sudo a2ensite default-ssl.conf
Para aplicar los cambios debemos reiniciar el servicio de apache2.
$ sudo service apache2 restart
Balanceo de las páginas web - HAProxy
Instalación y configuración
Con los gestores de contenido ya operativos, el siguiente paso será configurar el balanceo de carga hacia ellos. Para ello instalaremos el paquete HAProxy ejecutando el siguiente comando en la BERRY-01:
pi@BERRY-01:~$ sudo apt install haproxy
Para poder iniciar el balanceador de carga, debemos entrar en el archivo /etc/default/haproxy y modificar el valor por defecto de la línea "ENABLED" por el valor 1
pi@BERRY-01:~$ sudo nano /etc/default/haproxy
... ENABLED=1
En el archivo de configuración de HAProxy disponemos de los apartados generales con los que el servicio comprueba el estado de los servidores, los logs donde guarda cada suceso, el modo de conexión que realiza para cada chequeo, etc.
Un parámetro importante a cambiar es el tiempo en el que HAProxy realiza el chequeo para comprobar el estado de los servidores. Por defecto, su valor está a 30 segundos. Si queremos mejorar la alta disponibilidad, deberemos bajar este valor, sin embargo, hay que tener en cuenta que al bajar este valor se generará más tráfico en la red por culpa de los chequeos.
En nuestro caso reduciremos este valor a 10 segundos:
pi@BERRY-01:~$ sudo nano /etc/haproxy/haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 10s
user haproxy
group haproxy
daemon
Para balancear el tráfico hacia los diferentes servidores web, editaremos el archivo de configuración /etc/haproxy/haproxy.cfg. Al final del fichero crearemos un nuevo frontend el cual permite escuchar peticiones tanto por el puerto 80 como por el puerto 443 en cualquiera de las interfaces de la BERRY-01. Estas peticiones las reedirigirá hacia los servidores web indicados por el puerto 443. Además, también deberá conservar las sesiones pertinentes para que un usuario pueda iniciar sesión y no la pierda mientras navega por las diferentes páginas o realiza una compra.
pi@BERRY-01:~$ sudo nano /etc/haproxy/haproxy.cfg
frontend woseberry
bind *:80
bind *:443 ssl crt /etc/apache2/ssl/intermediate.pem
default_backend apaches
backend apaches
balance leastconn
cookie SRVNAME insert
server BERRY-02 192.168.30.2:443 check cookie BERRY-02 check ssl verify none
server BERRY-03 192.168.30.3:443 check cookie BERRY-03 check ssl verify none
Una vez realizada toda la configuración, reiniciaremos el servicio de HAProxy para aplicar los cambios:
pi@BERRY-01:~$ sudo service haproxy restart
Gracias a HAProxy habremos conseguido el balanceo de carga entre ambos WordPress consiguiendo un esquema como el siguiente:
 |
| Esquema del balanceo con HAProxy entre ambos WordPress |
Visualizar el log
Para visualizar cada comprobación que hace el servicio HAProxy en la BERRY-01, disponemos de un log general situado en la carpeta /var/log/. Este log registra cada operación de comprobación realizada y también queda registrado cuando uno de los nodos falla.
Si queremos disponer por un log independiente por cada frontend configurado, podemos activarlo con la siguiente directiva:
log /var/log/haproxy_frontend
Sin embargo, tenemos que considerar que cada comprobación que realice HAProxy quedará registrada en este log, por lo que el archivo aumentará de tamaño poco a poco y podría provocar que nos quedáramos sin espacio en disco.
En el siguiente ejemplo, podemos comprobar como el servicio se ha iniciado:
May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy woseberry started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy woseberry started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy apaches started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy apaches started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy mysql started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy mysql started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy databases started. May 17 17:05:04 BERRY-01 haproxy[2309]: Proxy databases started.
En este ejemplo podemos observar como la conexión con la BERRY-03 se ha perdido y unos minutos más tarde se restablece:
May 17 17:05:06 BERRY-01 haproxy[2313]: Server apaches/BERRY-03 is DOWN, reason: Layer4 timeout, check duration: 2000ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. May 17 17:18:11 BERRY-01 haproxy[2313]: Server apaches/BERRY-03 is UP, reason: Layer6 check passed, check duration: 250ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.
Replicación bases de datos - Galera
Instalación y configuración de Galera
Para poder utilizar el software Galera, debemos asegurarnos de tener instalados los siguientes paquetes en todos los servidores MySQL. En nuestro caso en las BERRY-04, BERRY-05 y BERRY-06:
- mysql-server
- mariadb-server
- mariadb-server-10.1
- rsync
- python3-software-properties
El siguiente paso será editar el archivo /etc/mysql/mariadb.conf.d/50-server.cnf. En este fichero deberemos buscar la línea con el parámetro bind-address y comentarla:
$ sudo nano /etc/mysql/mariadb.conf/50-server.cnf
... # bind-address = 127.0.0.1 ...
Configuración del nodo principal
Deberemos tener claro con que nodo vamos a iniciar el cluster, ya que el archivo de configuración de Galera variará con respecto al resto de nodos. En nuestro caso, el nodo principal y creador del cluster será la BERRY-04.
Por defecto, Galera no dispone de ningún archivo de configuración de ejemplo, por lo que deberemos crearlo manualmente. El único requisito fundamental será que este archivo esté ubicado en el directorio /etc/mysql/conf.d y tenga como extensión .cnf
Crearemos el fichero en el nodo principal:
pi@BERRY-04:~$ sudo touch /etc/mysql/conf.d/galera.cnf
En él, configuraremos los siguientes parámetros:
[galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 wsrep_sst_method=rsync # Node configuration wsrep_cluster_address="gcomm://" wsrep_node_address=192.168.30.4 wsrep_node_name="NODO_1" # Custom settings wsrep_cluster_name="Cluster_galera" bind-address=192.168.30.4
La información resaltada es aquella que deberemos cambiar en cada archivo de configuración de cada nodo. Dado que la BERRY-04 la hemos establecido como nodo principal, el apartado wsrep_cluster_address deberá permanecer tal y como se muestra. Sin embargo, veremos que en el resto de nodos deberemos especificar la IP de cada nodo.
En los apartados wsrep_node_address y bind-address deberemos indicar la dirección IP o nombre DNS del nodo donde se está aplicando la configuración. El apartado wsrep_node_name nos proporcionará un nombre identificativo por cada nodo. Podemos personalizarlo al igual que el apartado wsrep_cluster_name, el cual solo define un nombre común para el clúster.
Finalizada la configuración pararemos el servicio de MySQL:
pi@BERRY-04:~$ sudo systemctl stop mysql
Una vez detenido, iniciaremos el cluster con el siguiente comando:
pi@BERRY-04:~$ sudo galera_new_cluster
Por último, iniciaremos el servicio de MySQL:
pi@BERRY-04:~$ sudo systemctl start mysql
Configuración para el resto de nodos
Al igual que en el nodo principal, deberemos crear el fichero de configuración en el directorio correspondiente:
$ sudo touch /etc/mysql/conf.d/galera.cnf
En él, configuraremos los siguientes parámetros (BERRY-05):
[galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 wsrep_sst_method=rsync # Node configuration wsrep_cluster_address="gcomm://192.168.30.4,192.168.30.5,192.168.30.6" wsrep_node_address=192.168.30.5 wsrep_node_name="NODO_2" # Custom settings wsrep_cluster_name="Cluster_galera" bind-address=192.168.30.5
Y en el caso de la BERRY-06:
[galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so binlog_format=row default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 wsrep_sst_method=rsync # Node configuration wsrep_cluster_address="gcomm://192.168.30.4,192.168.30.5,192.168.30.6" wsrep_node_address=192.168.30.6 wsrep_node_name="NODO_3" # Custom settings wsrep_cluster_name="Cluster_galera" bind-address=192.168.30.6
Como podemos observar, las BERRY-05 y BERRY-06 contienen la misma información. Los únicos parámetros que hay que variar por cada nodo son wsrep_node_address, wsrep_node_name y bind-address.
Una vez tengamos los archivos de configuración de Galera en el resto de nodos reiniciaremos el servicio MySQL en cada uno de ellos. ¡Importante! Hay que reiniciar el servicio uno a uno, esperando a que finalice el de un servidor para poder reiniciar el del otro:
$ sudo systemctl restart mysql
Podremos comprobar que todos los nodos se han unido al clúster ejecutando la siguiente sentencia SQL en cualquiera de ellos:
$ sudo mysql -u root -p -e 'SELECT VARIABLE_VALUE as "Núm. nodos" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"'
+-------------+ | Núm. nodos | +-------------+ | 3 | +-------------+
Gracias a Galera, habremos conseguido la replicación entre bases de datos y tendremos un esquema parecido al siguiente:
 |
| Esquema de la replicación de Galera con el balanceo de HAProxy |
Usuario de chequeo
Por tal de que HAProxy sea capaz de comprobar que nodo MariaDB está operativo y cual está caído, deberemos crear un usuario sin contraseña. HAProxy utilizará este usuario para establecer una conexión y así mantener el nodo operativo. Para crear este usuario entraremos en la consola de MySQL en cualquiera de los nodos, como por ejemplo la BERRY-04:
pi@BERRY-04:~$ mysql -u pi -p
Una vez hayamos entrado en la consola, crearemos el usuario ejecutando el siguiente comando. ¡Importante! El usuario no debe tener contraseña definida ni permisos sobre otras bases de datos, ya que únicamente se utilizará para establecer una conexión a modo de chequeo:
MariaDB [(none)]> CREATE USER 'haproxy'@'192.168.30.254';
El usuario se llamará haproxy para ser más identificativo y solo permitirá conectarse desde la IP donde está instalado HAProxy.
Dado que las bases de datos están replicadas, tan solo deberemos crearlo en uno de los nodos. Ejecutando la siguiente sentencia SQL en el resto de nodos podremos comprobar que el usuario se ha replicado correctamente:
MariaDB [(none)]> SELECT haproxy from mysql.user;
Donde podremos ver toda la información del usuario haproxy:
Balanceo de las bases de datos - HAProxy
Configuración del balanceo
Ahora que ya tenemos las bases de datos funcionando con el software Galera, es decir, funcionando en cluster y replicadas, balancearemos el tráfico hacia ellas para conseguir el mayor rendimiento posible. Para ello editaremos la configuración de HAProxy en el fichero /etc/haproxy/haproxy.cfg:
pi@BERRY-01:~$ sudo nano /etc/haproxy/haproxy.cfg
Añadiendo las siguientes líneas al final del fichero:
frontend mysql bind 192.168.30.254:3306 mode tcp default_backend databases backend databases balance roundrobin mode tcp option tcpka option mysql-check user haproxy server BERRY-04 192.168.30.4:3306 check weight 1 server BERRY-05 192.168.30.5:3306 check weight 1 server BERRY-06 192.168.30.6:3306 check weight 1
Como podemos observar, hemos creado un nuevo frontend encargado de escuchar peticiones a la IP 192.168.30.254 por el puerto 3306. Cuando estas peticiones se realicen redireccionará el tráfico hacia el backend llamado databases. Este backend balancea con el algoritmo roundrobin hacia los servidores MySQL de las BERRY-04, BERRY-05 y BERRY-06. Para comprobar que el servicio está operativo y sigue funcionando, realizará una conexión hacia la base de datos con el usuario haproxy, el cual creamos en el apartado anterior.
Finalizada esta configuración reiniciaremos el servicio de HAProxy para aplicar los cambios:
pi@BERRY-01:~$ sudo service haproxy restart
Configuración de los servidores web
Hasta ahora, cada servidor web estaba configurado para realizar peticiones a una base de datos en concreto. Sin embargo, ahora que tenemos un sistema de replicas y balanceado, conviene que todos los servidores web soliciten la petición de la base de datos al HAProxy. De esta manera, él será el encargado de indicar a que base de datos realizar la consulta.
Para ello, deberemos editar el archivo /var/www/html/wp-config.php en los servidores web e indicar la nueva IP de la base de datos:
$ sudo nano /var/www/html/wp-config.php
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'wordpress');
/** MySQL database password */
define('DB_PASSWORD', 'woseberry');
/** MySQL hostname */
define('DB_HOST', '192.168.30.254');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', );
Sincronizacíon de las uploads en WordPress - Rsync
Ahora que ya tenemos la replicación en las bases de datos, debemos tener en cuenta que WordPress almacena todas las imágenes de manera local, es decir, en el mismo servidor web. Para solucionar esta inconcurrencia de datos disponemos de dos mecanismos como:
- Creación de un directorio compartido entre los servidores web: NFS
- Sincronización del directorio wp-content: Rsync
En nuestro caso, hemos elegido la opción de sincronización de los directorios, ya que de esta manera nos ahorraremos la instalación de un nuevo servicio como es NFS. Simplemente con la utilización del paquete rsync conseguiremos mantener el directorio wp-content en ambos servidores web de manera idéntica. Esta sincronización la programaremos para que se realice cada 15 minutos, comprobando aquellos ficheros que son diferentes y realizando la copia mediante el uso de SSH. Para poder programar esta sincronización utilizaremos la herramienta del sistema crontab:
pi@BERRY-02:~$ crontab -e
Añadiendo la siguiente línea al final del fichero:
# m h dom mon dow command */15 * * * * rsync -ahvrz /var/www/html/wp-content/uploads/* pi@192.168.30.3:/var/www/html/wp-content/uploads
Dado que la copia se realiza con el uso de SSH, cuando se establezca la conexión nos pedirá la contraseña del usuario. Si queremos evitar esta acción y que se realice la sincronización sin interacción del usuario deberemos generar una clave pública y una clave privada para el usuario pi en la BERRY-02:
pi@BERRY-02:~$ ssh-keygen
Seguidamente copiaremos la clave pública en la BERRY-03 para que permanezca en la lista de claves autorizadas:
pi@BERRY-02:~$ ssh-copy-id pi@192.168.30.3
Finalizada esta operación, la BERRY-02 se conectará automáticamente por SSH a la BERRY-03 y realizará una sincronización del directorio wp-content en caso de que haya ficheros o directorios distintos.
Realizaremos la misma operación en la BERRY-03, indicando al IP de la BERRY-02 en la conexión por SSH.
Envío de correos en caso de error en MySQL - SSMTP
Para el administrador de todo este escenario, es primordial tener constancia cuanto antes siempre que falle uno de los servidores. De esta manera, se puede aplicar solución al problema y seguir ofreciendo un servicio de alta disponibilidad al usuario. Es por ello que la creación de pequeños chequeos que revisen el funcionamiento correcto de servicios como apache2 o mysql, sea primordial.
En cada uno de los servidores se creará un script que monitorice el servicio correspondiente. En el caso de las BERRY-02 o BERRY-03 se monitorizará el servicio apache2. En cuanto a las BERRY-04, BERRY-05 y BERRY-06 se monitorizará el servicio de mysql.
Instalación y configuración de ssmtp
¡Importante! Está configuración debe realizarse en las BERRY-04, BERRY-05 y BERRY-06
El paquete ssmtp nos permite enviar correos a través de la terminal GNU/Linux. De esta manera, en el momento que el sistema se de cuenta de que el servicio que se estaba monitorizando cae, enviará un correo a la cuenta del administrador.
Para instalar este paquete ejecutaremos el siguiente comando todas las Raspberry:
$ sudo apt install ssmtp
Seguidamente, editaremos el archivo de configuración /etc/ssmtp/ssmtp.conf:
$ sudo nano /etc/ssmtp/ssmtp.conf
# Config file for sSMTP sendmail # Correo utilizado para enviar mensajes [email protected] # Servidor de correo utilizado mailhub=smtp.gmail.com:465 # Dominio de correo rewriteDomain=gmail.com # Credenciales cuenta de correo AuthUser=woseberry AuthPass=woseberryP@ssw0rd FromLineOverride=YES UseTLS=YES # The full hostname hostname=DEBIAN-VM
Script de monitorizaje
En el caso de las BERRY-04, BERRY-05 y BERRY-06 que son las encargadas de almacenar las bases de datos. El script se encargará de revisar que el servicio esté en marcha constantemente. En el momento en el que falle, se ejecutará la orden de enviar un correo al administrador con información como la hora, el estado actual del servicio y el log de errores:
#!/bin/bash
servicio=mysql
fecha=$(date)
maquina=$(hostname)
estadoServicio=$(service mysql status)
logError=$(tail -n 20 /var/log/mysql/error.log)
mensajeError="Al parecer se ha detenido $servicio en la $maquina aproximadamente. Hora aproximada: $fecha"
if (( $(ps -ef | grep -v grep | grep $servicio | wc -l) == 0 )); then
echo -e "Subject: ERROR - MySQL\n\n$mensajeError\n\n$estadoServicio\n\n$logError" | ssmtp [email protected]
fi
Una vez creado el script, deberemos añadirlo en el demonio crontab para que se ejecute cada cierto tiempo, como por ejemplo, cada 10 minutos. Dado que este script contiene comandos de superusuario o de root, deberemos añadirlo al crontab con privilegios:
$ sudo crontab -e
Y añadiremos al final del archivo las siguientes líneas:
# Revisar el funcionamiento de MySQL */10 * * * * bash /home/pi/Scripts/mailMySQL_cron.sh
Realizar copias de seguridad en la base de datos - MySQLdump
Aunque tengamos nuestras bases de datos replicadas y eso ya nos proporcione cierto nivel de seguridad, siempre es recomendable realizar copias de seguridad periódicamente.
Con el siguiente script, podemos crear un backup de la base de datos wordpress en cualquier momento, ya que el comando mysqldump antes de proceder a realizar el backup bloquea las tablas de la base de datos para que no se pueda escribir durante la copia y así obtener un backup fiable con integridad de sus datos. Como resultado, obtendremos un archivo con extensión .sql con el nombre especificado más la fecha y hora del instante de la realización de dicho backup.
#!/bin/bash
mysqldump --user=pi --password=woseberry wordpress > backup_wordpress_$(date "+%d-%m-%Y_%H:%M:%S").sql
echo "Copia de seguridad de la base de datos wordpress realizada."
Pero al margen de poder realizar el backup en cualquier momento, es importante programarlo para que éste se ejecute automáticamente.
En esta ocasión configuraremos el demonio crontab en las BERRY-04, BERRY-05 y BERRY-06 para que ejecute el script creado, cada día a las 4 en punto de la madrugada, ya que es la hora con menos actividad de la página en España, y realice un backup de la base de datos wordpress.
Ejecutamos el crontab del usuario root:
$ sudo crontab -e
Añadimos las siguientes líneas al final del archivo:
# Realizar backup de la base de datos wordpress 00 4 * * * bash /home/pi/Scripts/backup_wordpressdb.sh
Configuración del firewall - IPtables
Ahora que tenemos todo el esquema montado, es conveniente denegar algunos accesos malintencionados que intenten vulnerar la seguridad de la tienda virtual. Para ello se ejecutará un script al inicio del sistema en la BERRY-01:
#!/bin/bash # Borrar toda las reglas iptables -F iptables -X iptables -Z # Definir las políticas por defecto iptables -P INPUT DROP iptables -P OUTPUT ACCEPT # Permitir las conexiones SSH en ambas interfaces iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT # Permitir las conexiones DNS en ambas interfaces iptables -A INPUT -i eth1 -p tcp --dport 53 -j ACCEPT iptables -A INPUT -i eth1 -p udp --dport 53 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT # Permitir las peticiones HTTP y HTTPS en ambas interfaces iptables -A INPUT -i eth1 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -i eth1 -p tcp --dport 443 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT # Permitir las peticiones MySQL en la interfaz interna iptables -A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT iptables -A INPUT -i eth0 -p udp --dport 3306 -j ACCEPT # Permitir las conexiones preestablecidas iptables -A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Habilitar el enrutamiento echo 1 > /proc/sys/net/ipv4/ip_forward # Enmascarar la red LAN con la interfaz eth1 (Internet) iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o eth1 -j MASQUERADE
Seguidamente, añadiremos la ejecucción de este script en el archivo /etc/rc.local:
pi@BERRY-01:~$ sudo nano /etc/rc.local
… # Ejecutar las reglas del firewall bash /home/pi/Scripts/firewall.sh exit 0
Pruebas de rendimiento - Apache Benchmark
Como suele ser habitual en cualquier proyecto, una vez tenemos la infraestructura funcionando, es conveniente realizar las correspondientes pruebas de rendimiento. En nuestro caso, realizaremos pruebas principalmente sobre el servidor web apache y registraremos sus resultados.
Para realizar dichas pruebas de rendimiento utilizaremos el programa Apache Bench, y para instalarlo deberemos ejecutar el siguiente comando:
$ sudo apt-get install apache2-utils
Para realizar una prueba de rendimiento de por ejemplo 200 peticiones, ejecutándose con una concurrencia de 20 peticiones simultáneas, sobre la página web woseberry.tk y guardando los resultados en un archivo, el comando a ejecutar sería el siguiente:
$ ab -g resultados.tsv -n 200 -c 20 https://woseberry.tk/
ab es Apache Bench
-g resultados.tsv guarda los resultados en el archivo resultados.tsv
-n 200 indica que se harán 200 peticiones
-c 20 indica que se harán 20 peticiones concurrentes
https://woseberry.tk/ es la URL que vamos a testear
Resultado de la ejecución del comando anterior:
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking woseberry.tk (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests
Server Software: Apache/2.4.25
Server Hostname: woseberry.tk
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,4096,256
Document Path: /
Document Length: 48189 bytes
Concurrency Level: 20
Time taken for tests: 62.257 seconds
Complete requests: 200
Failed requests: 0
Total transferred: 9700200 bytes
HTML transferred: 9637800 bytes
Requests per second: 3.21 [#/sec] (mean)
Time per request: 6225.711 [ms] (mean)
Time per request: 311.286 [ms] (mean, across all concurrent requests)
Transfer rate: 152.16 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 198 893 1055.8 587 3969
Processing: 1483 5251 1276.6 5368 9083
Waiting: 1449 5052 1286.8 5090 9034
Total: 1869 6144 1484.3 6149 10674
Percentage of the requests served within a certain time (ms)
50% 6149
66% 6502
75% 6807
80% 7039
90% 7920
95% 9012
98% 9675
99% 9880
100% 10674 (longest request)
Interpretación de resultados
Como podemos ver en el resultado de la prueba de rendimiento, obtenemos una gran cantidad de datos, y aunque la mayoría de ellos tienen una gran importancia para poder medir determinados aspectos, los que podemos considerar como genéricamente más relevantes son los siguientes:
Peticiones completadas: 200
Peticiones fallidas: 0
Peticiones por segundo: 3.21 (promedio)
Tiempo por petición en segundos: 6.23 (promedio)
Tiempo por petición en segundos: 0.31 (promedio, en todas las solicitudes simultáneas)
Velocidad de transferencia (Kbytes/sec): 152.16 recibidos
Promedio tiempos de conexión (segundos):
Conectar: 0.89
En espera: 5.05
Proceso: 5.25
Total: 6,14