Afectadas por la pandemia de COVID-19, muchas PYMES/pymes están haciendo la transición a plataformas en línea. Las clases presenciales o físicas también se ven afectadas por esta pandemia y muchas escuelas y universidades también están haciendo la transición a las clases en línea y están buscando herramientas que estén disponibles para seguir sirviendo a los estudiantes o alumnos, como lo ha hecho la educación. para no ser obstaculizado. Una de las plataformas famosas que están disponibles para fines educativos en línea o de aprendizaje en línea es Moodle.
¿Qué es Moodle?
Moodle es un software de código abierto para el sistema de gestión de aprendizaje en línea, o LMS (también conocido como entorno de aprendizaje virtual o VLE) bajo la licencia GPL. Permite a los educadores crear su propio sitio web privado lleno de cursos dinámicos que amplían el aprendizaje, en cualquier momento y en cualquier lugar. Moodle tiene un soporte completo con fácil acceso y funciones para profesores, estudiantes o administradores.
Debido a que es una plataforma de código abierto y de software libre, puede usar este software de forma gratuita y sin regalías, al igual que cualquier otro software de código abierto. Solo se incurre en costos cuando este software está alojado en una plataforma de alojamiento paga, o si lo aloja con su Moodle Cloud. Moodle también está disponible para dispositivos portátiles como móviles o tabletas.
¿Por qué necesita una base de datos de alta disponibilidad?
En la década de 1990, se inventó una solución muy simple para alta disponibilidad (HA):Heartbeat. Un clúster de Heartbeat básicamente podía hacer dos cosas:monitoreaba dos nodos (y no más de dos) y estaba configurado para iniciar uno o más servicios en esos dos nodos. Si el nodo que hospedaba los recursos en ese momento dejaba de funcionar, reiniciaba los recursos del clúster en el nodo restante. Aunque el lanzamiento inicial de Heartbeat no tenía monitoreo de los recursos en sí, esto cambió hasta el lanzamiento de Heartbeat 2.0 a principios de la década de 2000, donde permite administrar más de dos nodos en el clúster. Básicamente, esto comprende el estado del clúster HA de Linux que se basa en gran parte en Heartbeat 2.0. A partir de ahora, muchas soluciones HA se vieron afectadas y se han desarrollado y creado para minimizar el tiempo de inactividad, especialmente para los recursos críticos.
Estar altamente disponible no solo significa minimizar el tiempo de inactividad. También cubre el grado de responsabilidad de poder operar y mantener continuamente los servicios que ofrece y promete a sus clientes. Estar disponible para los clientes no significa que también seas capaz de responderles en caso de que necesiten ayuda. Tiene que poner la aplicación y el sistema de su empresa en pleno funcionamiento como si siempre fuera el estado normal de operaciones, incluso si se ha producido un desastre sin precedentes.
No puede operar su aplicación VLE usando Moodle mientras su base de datos está en mantenimiento. Si solo tiene un único servidor de base de datos, lo cual es muy común para la configuración de aplicaciones simples y livianas, una vez que el servidor se cae, su aplicación se detiene. Si tiene un clúster de base de datos que utiliza la replicación maestro-esclavo y luego se encuentra con un incidente sin precedentes que, a su vez, hace que su aplicación esté escribiendo en dos maestros después del incidente, eso podría ser un gran desastre que a su vez causa la corrupción de datos en toda su aplicación comercial y capa de datos Si hubo pagos continuos que ocurrieron en ese momento, eso podría ser un gran desastre e implica una gran cantidad de trabajo al realizar la recuperación de datos.
Entonces, ¿por qué su base de datos debe tener alta disponibilidad? Es porque tiene que ser,
- Capaz de realizar el mantenimiento o la interrupción planificada de manera factible y en la ventana de mantenimiento permitida
- El tiempo de actividad es vital y debe evitar el tiempo de inactividad cuando sea necesario
- El SLA es importante en su mayor grado para lograr un servicio al cliente de alta calidad
- Proporcionar servicio continuo y facilidad de uso
- Ningún punto único de falla
- Capaz de realizar una conmutación por error cuando el maestro se rompe o falla
- Evite el escenario de cerebro dividido en el que varios maestros actúan como escritores activos al mismo tiempo
Creación del clúster de base de datos
Ahora que hemos enfatizado la importancia de tener HA como plan y como solución para su clúster de base de datos, especialmente para PostgreSQL, concentrémonos en construir el clúster de arriba a abajo para lograr un alto configuración disponible lista para la configuración de la aplicación Moodle.
Instalación de PostgreSQL
En primer lugar, ¿por qué PostgreSQL? PostgreSQL tiene grandes ventajas en comparación con otras bases de datos compatibles con Moodle. Es una cuestión de preferencia si tengo que resumir, ya que todas las bases de datos compatibles con Moodle son capaces de manejar los datos y también están sujetas a optimización. Depende de cuán hábil y experimentado esté utilizando la base de datos. Aunque para resumir por qué usar PostgreSQL, es una base de datos confiable y su sofisticado software de código abierto, especialmente en bases de datos que se pueden comparar con otros proveedores que son propietarios, como Oracle y MS SQL. Admite el paralelismo de consultas, puede administrar bases de datos grandes o enormes, tiene un amplio soporte para JSON y mucho más. Puede consultarlo aquí para conocer las razones por las que elegir PostgreSQL. Ahora procedamos a instalar PostgreSQL
Para este blog, usaremos PostgreSQL 12 con Ubuntu 18.04 (Bionic Beaver). Luego, para la configuración de alta disponibilidad, debe tener un nodo principal y al menos un nodo en espera (réplica) para el cual se hará cargo una vez que el maestro se apague.
- Configure el repositorio y la clave de firma
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Instalar el servidor PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Haga esto también en la réplica de destino, pero debe configurarla como una copia de seguridad o una réplica. Alternativamente, le sugiero que use ClusterControl y lo descargue, ya que es gratis. Sería cada vez más rápido instalar y configurar una configuración principal/en espera. Para mi configuración usando ClusterControl y usando la pestaña de vista Topología, obtuve la siguiente topología:
Tener una configuración maestra/esclava o primaria/en espera, no significa que está totalmente cubierto para un clúster de base de datos de alta disponibilidad. Todavía no está altamente disponible. Una vez que el principal o el maestro fallan, no es probable que ocurra una conmutación por error. Otra cosa es que no hay equilibrio de conexiones de clientes que van al maestro contra el esclavo. Aunque el equilibrio de carga entre maestro/esclavo no implica que deba configurarse o que deba aplicarse para cumplir con una configuración de alta disponibilidad. Tener un equilibrio de carga entre el maestro/principal y un esclavo/en espera ayuda a que su nodo maestro estrese el alto rendimiento de la carga, especialmente en horas de mucho tráfico.
Configuración del equilibrio de carga
Como se mencionó anteriormente, el equilibrio de carga entre el maestro y el esclavo ayuda a su maestro a separar la carga. No es ideal si deja que su modo de espera solo se use para la replicación o se haga cargo en caso de que el maestro se caiga. Aunque eso puede funcionar, sin embargo, implica tiempo de inactividad y trabajo manual si el maestro falla, ya que debe cambiar el rol de su nodo en espera a un maestro. Eso también está bien, pero nuevamente, tener un balanceador de carga puede ayudar a dirigir las escrituras al maestro y luego dirigir las lecturas entre el maestro y el esclavo. Básicamente, esto le proporciona división de lectura/escritura. Para hacer esto, hay muchas opciones entre las que puede elegir con PostgreSQL. Básicamente, la configuración más común pero simple y liviana es usar HAProxy.
Aunque hay opciones como usar PgBouncer o pgpool-II. Para simplificar este blog, usemos HAProxy. Para instalar HAProxy, es bastante sencillo si usa ClusterControl. Hagámoslo a través de ClusterControl. Para hacer eso, puede ir a la pestaña Administrar, seleccionar Equilibrador de carga como se muestra a continuación,
Dado que necesitamos una configuración de alta disponibilidad para su clúster de base de datos PostgreSQL, debemos tener al menos dos nodos. Entonces, si su nodo HAProxy principal falla, entonces el HAProxy pasivo o en espera puede tomar el control. Veamos cómo se ve en mi extremo,
Aunque se ve bien. Esta configuración sigue siendo insuficiente. Si cree que somos buenos para una configuración de alta disponibilidad con esa topología, no hay conmutación por error en caso de que HAProxy se caiga en el nodo 192.168.30.222 en el puerto 9600 o si 192.168.30.223:9600 se cae y si su aplicación está configurada para eso. host, todavía hay tiempo de inactividad si no se ha realizado una configuración proactiva. De esa manera, tiene tiempo de inactividad si tiene que configurarse manualmente. En este caso, usaremos y configuraremos Keepalived para que las instancias de HAProxy sean monitoreadas de cerca por su salud y conmutación por error en caso de que el otro nodo encuentre un problema.
Mantener los balanceadores de carga altamente disponibles
Ahora que tenemos balanceadores de carga en la parte superior de nuestras bases de datos, necesitamos que nuestro HAProxy esté siempre activo en caso de que el nodo principal para el punto final de la aplicación se caiga. Básicamente, lo que HAProxy puede hacer con la configuración que tenemos en la sección anterior, las aplicaciones pueden usar 192.168.30.223 o 192.168.30.222 con los puertos 5433 (puerto de lectura y escritura) y 5434 (puerto de solo lectura) respectivamente. Ahora hay una molestia en caso de que necesite cambiar en caso de que los otros nodos se caigan, además lo malo es que está dañando el negocio ya que cubre el tiempo de inactividad si no hay una conmutación por error automática para manejarlo. Evitar el tiempo de inactividad es la mejor ruta aquí, a menos que tenga un SLA muy bajo y un RTO y RPO altos.
Para aliviar tal desastre o tiempo de inactividad, sugerimos configurar Keepalived sobre HAProxy. Básicamente, HAProxy equilibrará la carga entre lectura y escritura, siempre que le proporcione división de lectura y escritura, y Keepalived solo monitorea el estado de los nodos HAProxy y logrará seleccionar el nodo más saludable de acuerdo con la configuración deseada. Keepalived es una herramienta que puedes usar para hacer que los nodos HAProxy sean monitoreados, aunque no es tan complejo para administrar bases de datos. Keepalived utiliza VIP (IP virtual) que se asigna al nodo HAProxy primario predeterminado y luego reasigna ese VIP en caso de que el nodo HAProxy primario falle y lo apunta al nodo HAProxy subsiguiente o en espera.
Ahora configuremos esto usando ClusterControl ya que es más rápido y fácil de administrar con ClusterControl. Para hacer esto, es básicamente el mismo enfoque que la forma en que configuramos HAProxy, pero en su lugar seleccionamos Keepalived como se muestra a continuación,
Básicamente, si instala Keepalived manualmente, estamos seleccionando el primario contra el secundario en caso de que HAProxy principal falle. Veamos cómo se ve nuestra vista de topología,
Esto podría parecer muy prometedor. Básicamente, el cliente de la aplicación Moodle se conectará al VIP, es decir, 192.168.30.201 en los puertos 5433 (puerto de lectura y escritura) y 5434 (puerto de solo lectura). Por ejemplo, verificarlo en un host externo que tengo,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)que revela que solo el nodo escritor que tengo apunta a mi nodo maestro, es decir, 192.168.30.22. Luego, mi puerto de solo lectura debe ir a los nodos maestro y esclavo como se muestra a continuación,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Esto revela que tanto mi nodo principal como el de reserva se identifican como nodos de "lectura de base de datos".
Ahora esto parece muy prometedor como lo que he dicho antes. Aún así, hay una parte que falta aquí que en realidad es muy importante. No existe un mecanismo de conmutación por error de la base de datos que esté listo para este tipo de configuración. Sin embargo, tenemos Keepalived que monitorea HAProxy y luego realiza una conmutación por error al cambiar el VIP en caso de que el HAProxy principal falle o muera. Sin embargo, Keepalived no está configurado para manejar la configuración compleja que tiene PostgreSQL. Hay uno muy decente que está disponible y es gratuito para configurarlo. Puede utilizar Slony-I, un sistema de replicación de terceros.
Tener un mecanismo de conmutación por error para su clúster de PostgreSQL
Hay formas de proporcionar un mecanismo de conmutación por error para su PostgreSQL. Slony-I o comúnmente llamado simplemente Slony es una de las herramientas comunes que se utilizan. Aunque Slony requiere que su configuración sea una replicación lógica, ya que requiere una configuración de editor/suscriptor, puede que no sea ideal para otras configuraciones que utilizan una replicación de transmisión estándar. La desventaja de usar Slony es que no proporciona ninguna detección automática para sistemas fallidos o no admite cercado de nodos. Por lo tanto, un comúnmente llamado STONITH (dispara al otro nodo en la cabeza o dispara al nodo fallido en la cabeza) que básicamente elimina el fallido para no evitar escenarios de cerebro dividido donde múltiples nodos maestros (nodos escritores activos) están aceptando escrituras en el Mismo tiempo. Aunque esto se puede configurar de manera adecuada, aún así puede llevar mucho tiempo y ser complicado si se crea con menos experiencia e información sobre qué escenarios sucederán para PostgreSQL cuando ocurra un desastre. Para Slony, abandonar las transacciones comprometidas es una decisión comercial que no puede tomar un sistema de base de datos. Si alguien quiere poner los comandos a continuación en una secuencia de comandos ejecutada automáticamente desde el sistema de monitoreo de red, entonces deja a su propia disposición que sean sus datos y su política de conmutación por error.
Alternativamente, si está buscando opciones empresariales pero puede tomar su dinero a un costo razonable, entonces ClusterControl tiene recuperación automática para clústeres de PostgreSQL. Básicamente, la recuperación automática responde a los problemas mencionados anteriormente con Slony. Aunque nuestra recuperación automática se prueba mejor con la replicación de transmisión y solo es compatible con el tipo de replicación de transmisión de la configuración de PostgreSQL. ¿Entonces, cómo funciona? Básicamente, solo tiene que activar los botones de recuperación automática como se muestra a continuación,
Esto admite cercado de nodos, lo que significa que eliminará el nodo que falla en caso el nodo vuelve a estar vivo por alguna razón que no se prevé. Aparte de eso, la recuperación automática de ClusterControl admite la recuperación de nodos y clústeres, de modo que si un nodo maestro o esclavo se apaga o elimina accidentalmente, ClusterControl intentará reactivarlo, especialmente si ocurre fuera de una interrupción planificada o una ventana de mantenimiento. Esta característica justa lo protege de haber agotado los temores de la base de datos y, al mismo tiempo, también le brinda un monitoreo proactivo que le notificará sobre algún posible desastre antes de que sea demasiado tarde para recuperarse.
Conclusión
Las configuraciones de alta disponibilidad para su clúster de base de datos, especialmente para Moodle, pueden variar según el tipo de configuración y los requisitos que necesite. Ya sea que dependa puramente de tecnologías gratuitas y de código abierto o que haya otras opciones que valen la pena invertir en su aplicación empresarial, siempre que el presupuesto se ajuste, ya que puede brindarle una situación en la que todos ganan, especialmente si solo desea más enfoque. en el lado comercial de las cosas que centrarse en otras herramientas como la administración y el tipo de trabajo devops.
