Open edX es una plataforma para actividades educativas en línea. Dada la situación en la que se encuentra el mundo, todas estas plataformas enfrentan mayores cargas y su importancia ha aumentado significativamente. Esas no son solo las plataformas de "ayuda", sino que a menudo se convierten en la principal forma en que se realizan las actividades educativas. Esto conduce a mayores requisitos con respecto a la carga que pueden manejar o la disponibilidad de la plataforma.
Open edX es un producto complejo que consta de varios elementos. Uno de ellos es la base de datos MySQL. En este breve blog, nos gustaría analizar cómo puede mejorar la alta disponibilidad de la plataforma Open edX.
Obviamente, la única base de datos MySQL es un único punto de falla y, como tal, no es un enfoque adecuado para las implementaciones de producción. Hay varias formas de mejorar la disponibilidad de la base de datos MySQL.
Para empezar, puede ejecutar la configuración maestro-esclavo mediante replicación asincrónica o semisíncrona. La ventaja de esto es que, cuando el maestro no está disponible, puede promover uno de los esclavos y continuar con la operación. La principal desventaja de una configuración de este tipo es que la conmutación por error debe realizarse manualmente, lo que aumenta el tiempo de inactividad o debe usar algún software externo (por ejemplo, ClusterControl), pero aún así puede llevar un poco de tiempo. Finalmente, cualquier tipo de replicación asíncrona o semi-sincrónica está sujeta a retrasos en la replicación. Esto puede afectar seriamente los escenarios de lectura después de escritura en los que la aplicación ejecuta una escritura en el maestro y luego intenta leer esos datos del esclavo de inmediato.
Otro enfoque sería usar un Galera Cluster para almacenar los datos de la plataforma Open edX. Podemos comenzar con tres clústeres de nodos:dichos clústeres pueden manejar automáticamente la falla de un solo nodo. Los dos nodos restantes seguirán funcionando y responderán a las consultas provenientes de la aplicación. Otra ventaja de Galera es que, a pesar de que es "virtualmente" síncrono (lo que significa que es casi síncrono), hay una manera de hacer cumplir las verificaciones de causalidad y obligar a los grupos a entrar en el modo síncrono (incluso si paga por ello con rendimiento reducido).
Ambos escenarios requerirían algún tipo de balanceador de carga frente a ellos, que manejaría el tráfico y lo redirigiría a un destino adecuado.
Veamos cómo ClusterControl puede ayudarlo a implementar un Galera Cluster con un conjunto de balanceadores de carga que puede usar para su plataforma Open edX.
Implementación del clúster de MariaDB
Esta vez intentaremos usar MariaDB Cluster como nuestro backend. Una vez más, el primer paso es el mismo, debemos elegir "Implementar" en el asistente:
Una vez que haga eso, tenemos que definir la conectividad SSH, sin contraseña, clave El acceso SSH basado en SSH es un requisito para ClusterControl; de lo contrario, no podrá administrar la infraestructura de la base de datos.
Luego debemos decidir sobre el proveedor, la versión, la contraseña, los hosts y algunos configuraciones adicionales:
Con todos esos detalles completos, estamos listos para continuar con la implementación.
Implementación de ProxySQL
La base de datos en sí no es el único elemento que queremos implementar. También necesitamos un balanceador de carga que usaremos para dirigir el tráfico a los nodos que están disponibles en el momento dado. También lo usaremos para proporcionar división de lectura/escritura, dirigiendo todas las escrituras a un solo nodo MariaDB Galera. Esto nos ayudará a evitar conflictos entre escrituras ejecutadas en diferentes nodos de Galera.
Para ProxySQL ClusterControl también se requiere completar cierta información; debe elegir el host para instalarlo, decida la versión de ProxySQL, las credenciales para los usuarios administrativos y de monitoreo. Esos usuarios se utilizarán para administrar ProxySQL y monitorear el estado de su clúster de Galera. También debe importar usuarios de bases de datos existentes o crear uno nuevo para su aplicación. Finalmente, depende de usted decidir qué nodos de base de datos desea usar con ProxySQL y decidir si usa transacciones implícitas.
Implementación de Keepalived
Como siguiente paso implementaremos Keepalived. La idea aquí es tener una IP virtual que apunte a la instancia de ProxySQL en funcionamiento. Dicho VIP se puede usar en la aplicación como punto final para la conectividad de la base de datos MySQL.
Después de pasar detalles como las instancias de ProxySQL que deben monitorearse, la IP virtual y el La interfaz VIP debe vincularse a Estamos listos para implementar. Después de un par de minutos, todo debería estar listo y la topología debería tener el siguiente aspecto:
Eso es prácticamente todo cuando se trata de la implementación. Puede apuntar su plataforma Open edX hacia el VIP y el puerto 6033, esto debería ser suficiente para obtener la conectividad a su base de datos de back-end. El último bit restante, si lo encuentra necesario, sería configurar comprobaciones de causalidad. Hay una variable wsrep_sync_wait que puede hacer precisamente eso. Puede habilitar pruebas en varios patrones de acceso:lecturas, actualizaciones, inserciones, borrados, reemplazos y comandos MOSTRAR. Si solo estamos interesados en las consultas SELECT, estableceremos esta variable en '1' usando la gestión de configuración de ClusterControl.
Esto realizará este cambio en todos los nodos del clúster MariaDB.
Eso es todo. Si desea compartir algo de su experiencia con Open edX, puede dejarnos un comentario.
