Es una buena práctica construir un plan antes de desarrollar su aplicación. Empiece por definir los objetivos principales de la empresa, recopilar los requisitos, evaluar una posible pila tecnológica y comprender las integraciones. Al final del proceso, deberías tener un esquema de la arquitectura de referencia de tu aplicación, que actúa como un plano para implementar los componentes de tu infraestructura y define cómo fluyen los datos entre esos componentes.
En este ejemplo, estamos revisando un diseño de base de datos utilizando Galera para MySQL y MariaDB. Las bases de datos son componentes de misión crítica de muchas aplicaciones. Este valioso activo depende de la redundancia para mantener viva su carga de trabajo. Un solo punto de fallo puede afectar negativamente a las operaciones del negocio, a los acuerdos de tiempo de actividad y a la experiencia general del usuario.
Utilizando las arquitecturas de referencia como guía, puede construir implementaciones de bases de datos y aplicaciones resistentes que se escalan horizontalmente (sin tiempo de inactividad) a medida que su negocio crece.
¿Qué es la arquitectura de referencia?
Las arquitecturas de referencia son diagramas técnicos reutilizables que incorporan principios de diseño comunes y las mejores prácticas de la industria para implementar soluciones. Una arquitectura de referencia de la nube muy abstracta representa las conexiones entre las distintas instancias de computación, los equilibradores de carga, el almacenamiento, las redes definidas por software, etc.: el valor de sus bases de datos hace que sea un área clave de atención aquí.
Bases de datos y arquitectura de referencia
El objetivo principal es añadir redundancia y evitar que la base de datos sea un punto único de fallo. Hay diferentes maneras de lograr este objetivo dependiendo de las restricciones de la aplicación y de la carga de trabajo. Por ejemplo, una aplicación podría funcionar mejor dividiendo las lecturas y las escrituras en un modelo de replicación primario-secundario. Una necesidad de escalar las operaciones de escritura requeriría una estrategia con múltiples primarios.
Otras consideraciones son el volumen de datos, el cumplimiento de ACID, el proceso de conmutación por error/selección (manual o automático), el número previsto de conexiones de clientes y la tecnología de base de datos elegida. Estas consideraciones darán forma a la solución de base de datos y formarán la imagen más amplia de cómo estas piezas funcionan juntas en su arquitectura de referencia.
Cuándo utilizar Galera
Galera es una solución de base de datos de alta disponibilidad, gratuita y de código abierto, que es sencilla de gestionar y no depende de un único proveedor de la nube. Si su tecnología de base de datos es MySQL, o una de sus bifurcaciones como MariaDB o Percona, recomendamos encarecidamente Galera como solución duradera y portátil.
Ventajas del clúster Galera
- Fallos de nodo - Evita las condiciones de cerebro dividido invocando un quórum ponderado para elegir un componente primario en caso de fallos de nodo.
- Cluster Multi-Primario, Activo-Activo - Lee y escribe en cualquier nodo del cluster.
- Consistencia de los datos - Utiliza la replicación sincrónica basada en la certificación para garantizar el cumplimiento de ACID.
- Aprovisionamiento automático de nodos: cuando se recuperan los nodos que han fallado, o cuando se unen nuevos nodos al clúster, se sincronizan automáticamente con el estado del componente primario mediante transferencias de instantáneas de estado (SST) o transferencias incrementales de estado (IST).
Limitaciones del clúster Galera
- No hay soporte para MyISAM - Sólo soporta el motor InnoDB. Las escrituras en otros tipos de tablas, incluidas las tablas del sistema, no se replican.
- Formato de la tabla - Las tablas sin claves primarias no pueden ser eliminadas o replicadas correctamente.
- Consideración de la lógica- La lógica de la aplicación podría necesitar ser reescrita para evitar el uso de bloqueo explícito de tablas.
- Escalabilidad de escritura - Todos los nodos deben certificar que pueden escribir antes de comprometerse, por lo que el rendimiento de escritura disminuye a medida que el clúster crece. Recomendamos mantener el tamaño del clúster en tres nodos, suficiente para tener quórum y un rendimiento de escritura óptimo.
Elimine los puntos únicos de fallo
Utilicemos el ejemplo de una pila tradicional de LEMP, en la que el software de aplicación y la base de datos se han separado en diferentes instancias de computación en preparación para una futura escala. Esta configuración podría ser la siguiente:
La separación de preocupaciones es una buena práctica, y ciertamente ayuda a la escalabilidad; pero la falta de redundancia hace que tanto la base de datos como los servidores de aplicaciones sean un único punto de fallo. Podemos mejorar esta estructura para eliminar esos puntos únicos de fallo y construir la arquitectura general de referencia.
Configuración sencilla del clúster Galera con VLAN y cortafuegos en la nube
Un clúster Galera aumenta la capa de base de datos a tres nodos con replicación sincrónica entre ellos. Podemos utilizar un Linode VLAN para aislar el tráfico de replicación de las redes públicas y privadas compartidas, y un Cloud Firewall para restringir el acceso desde fuera del VLAN. Los nodos Galera comparten una dirección IP flotante, de modo que si uno falla, otro es capaz de hacerse cargo de servir peticiones al servidor de aplicaciones que no lo sabe.
La capa de la base de datos está ahora altamente disponible. Lo siguiente que hay que hacer es dirigir el servidor de aplicaciones. Este proceso es sencillo para las aplicaciones sin estado aplicaciones, pero hay que tener en cuenta algo más para las aplicaciones que son con estado. Dependiendo de cómo se mantenga el estado, puede ser necesario refactorizar el código y/o implementar la replicación de archivos con herramientas como Unison o Gluster. Para este ejemplo, supongamos que, excepto los archivos de sesión temporales, el estado de la aplicación es mantenido por la base de datos.
Equilibrio de carga y replicación de aplicaciones
El balanceo de carga proporciona a su aplicación alta disponibilidad y escalabilidad horizontal, pero una única instancia de balanceador de carga también crea un único punto de fallo. La redundancia sigue siendo un componente crítico de esta implementación. Linode NodeBalancers proporciona una solución lista para usar y de alta disponibilidad para facilitar la fijación de sesiones, la supervisión del estado y la distribución de las solicitudes de los clientes a un conjunto de nodos de aplicaciones backend.
Si un servidor de aplicaciones se cae, el NodeBalancer empezará a dirigir el tráfico sólo al nodo sano. En cuanto el nodo no sano se recupere, volverá a equilibrar las conexiones como antes. Esto facilita la adición, eliminación o actualización de los servidores de aplicaciones sin tiempo de inactividad, y debido a la solución activa-activa proporcionada por Galera, cualquier nodo de aplicación puede leer/escribir en cualquier nodo de base de datos.
LinodeEl equipo de ingeniería de soluciones comparte marcos, guías y herramientas como ésta para desarrollar aplicaciones teniendo en cuenta las mejores prácticas. Lee más sobre los beneficios de la alta disponibilidad que ofrecen los clústeres de Galera. Si estás listo para empezar a construir esto en Linode, echa un vistazo a nuestra guía para configurar clusters MariaDB con Galeria, Debian, y Ubuntu.
Comentarios