Costo de tiempo de inactividad de la base de datos
Una estudiar ManageForce estima el costo promedio de la interrupción de la base de datos en $ 474,000 por horaLas interrupciones prolongadas de la base de datos son el resultado de un diseño deficiente con respecto a la alta disponibilidad.
Con el crecimiento exponencial de los datos generados a través de Internet (se espera que alcance los 180 bytes zeta para fines de 2025) y la creciente dependencia de diferentes tecnologías de bases de datos para servir estos datos a los usuarios objetivo, el costo del tiempo de inactividad de la base de datos seguirá aumentando en el próximos años
Este blog primero introducirá los principales conceptos de usabilidad. Luego, enumeraremos algunos patrones que brindan implementaciones de bases de datos de alta disponibilidad y, finalmente, explicaremos cómo las soluciones de Canonical pueden ayudarlo a implementar aplicaciones de alta disponibilidad.
Conceptos Avanzados
Antes de entrar en los detalles de cómo lograr una alta disponibilidad de la base de datos, asegurémonos de tener una comprensión común de algunos conceptos.
Disponibilidad y Durabilidad
Disponibilidad es medida tiempo de actividad Un servicio dado durante un período de tiempo. Puede entenderse como lo contrario de apagar.Por ejemplo, disponibilidad mensual 99,95% Esto significa un máximo de unos 22 minutos de tiempo de inactividad al mes.
Durabilidad Mide la capacidad de un sistema dado para retener datos contra ciertas fallas. (por ejemplo, falla de hardware). Por ejemplo, una durabilidad del 99,999999999 % por año significa que por cada 100 000 millones de objetos almacenados, ¡puede perder un objeto por año!
Tenga en cuenta que la disponibilidad y la durabilidad de los datos son bastante diferentes. Es posible que no pueda acceder a los datos durante una interrupción de la base de datos, pero aún desea que los datos persistentes estén accesibles cuando la base de datos se inicie nuevamente.
cómputo y almacenamiento
Para el resto de este blog, usaré ejemplo Referirse a calcular Parte de la implementación de la base de datos en el host dado. Una instancia es la interfaz a la que se conectan los clientes de la base de datos.
Aparte de, Yo usaría esta palabra base de datos Referirse a almacenamiento Las secciones, esencialmente «archivos» de datos, son administradas por la instancia asociada.
Tenga en cuenta que la instancia y la base de datos pueden residir en diferentes hosts.
Patrones para lograr una alta disponibilidad de la base de datos
La alta disponibilidad generalmente se logra mediante el uso de redundancia y aislamiento estructura. redundancia Esto se logra duplicando algunos componentes de la base de datos.aislamiento Esto se logra colocando componentes redundantes en hosts separados.
el término grupo Hace referencia a todos los componentes de una implementación de base de datos, incluidos sus componentes redundantes. Juntos, estos componentes aseguran la usabilidad de la solución.
Exploremos algunos patrones de agrupamiento en la siguiente sección.
Redundancia/estructura de clúster
Como hemos visto antes, podemos hacer que dos partes principales de la implementación de nuestra base de datos sean redundantes para una alta disponibilidad:
- Instancia de base de datos, se refiere a la parte informática.
- Base de datos, se refiere a la parte de almacenamiento.
clúster a nivel de instancia
En este tipo de clúster, protegemos la parte de la instancia de la base de datos implementando varias instancias en diferentes hosts. Las bases de datos normalmente residen en almacenamiento remoto visible para todos los hosts relevantes.
Podemos tener 2 tipos de clústeres a nivel de instancia:
- activo/activo La instancia está procesando el tipo de solicitudes de cliente de base de datos en paralelo. Este es el caso de Real Application Cluster para Oracle Database. Cuando ocurre un problema con una instancia, las solicitudes de los clientes de la base de datos se enrutan a las instancias restantes en buen estado.
- activo pasivo En un momento dado, solo una instancia maneja activamente el tipo de solicitudes de cliente de base de datos. Cuando hay un problema con la instancia activa anterior, la solicitud del cliente se desviará a la instancia activa recién elegida. Este agrupamiento lo proporciona la instancia de clúster de conmutación por error (FCI) de Microsoft SQL Server y el servidor de clúster de Veritas.
Clúster de nivel de base de datos
En este tipo de clúster, protegemos tanto la instancia de la base de datos como la base de datos. Proteger solo la base de datos puede dar como resultado que sus datos estén protegidos pero que no se pueda acceder a ellos rápidamente.
Tenga en cuenta que podemos crear una copia sin conexión de la base de datos con fines de copia de seguridad. Sin embargo, en este caso, el objetivo principal es proteger los datos.
La alta disponibilidad de la base de datos se logra a través de la replicación. Podemos distinguir dos tipos de replicación en función de la capa que la realiza:
- basado en almacenamiento Replicación, donde un protocolo de nivel de almacenamiento/sistema de archivos empuja los cambios que ocurren en una base de datos a otras bases de datos. Este es el tipo de clúster proporcionado por la combinación de Failover Cluster Instance (FCI) y Storage Spaces Direct para Microsoft SQL Server. En este tipo de replicación, la instancia adjunta suele estar en modo de espera y el acuerdo de replicación suele ser síncrono.
- Solución basada en base de datos Replicación, donde los protocolos de nivel de base de datos envían los cambios que ocurren en una base de datos a otras bases de datos. Esto está agrupado por soluciones como ReplicaSet para MongoDB, Grupos de disponibilidad AlwaysOn para Microsoft SQL Server y Data Guard para Oracle Database. Para la replicación de soluciones basadas en bases de datos podemos tener 2 subtipos:
- replicación lógica: replicamos las solicitudes de los clientes de la base de datos de una instancia a otra. Este tipo de replicación es compatible con la replicación basada en declaraciones de Oracle Golden Gate y MySQL.
- copia fisica: replicamos el impacto de las solicitudes de los clientes de la base de datos en los datos de una base de datos a otra (a través de una instancia). Esta replicación es compatible con la replicación basada en filas de Oracle Data Guard y MySQL.
usamos la palabra réplica Representa una base de datos adicional producida por el mecanismo de replicación.
Este básico La base de datos/instancia es la que recibe el tráfico de escritura del cliente.
no compartas nada Una implementación de base de datos consta de servidores independientes, cada uno con su propia memoria, cómputo y almacenamiento dedicados. Tienden a proporcionar una mayor disponibilidad porque nos permiten aprovechar todas las estructuras de aislamiento que veremos en la siguiente sección.
Construcción aislada
El aislamiento se trata de reducir el radio de impacto de un evento de falla/desastre determinado en los componentes del clúster. Cuanto más separados estén los componentes redundantes, es menos probable que fallen al mismo tiempo.
Aislamiento del servidor
Esta es la forma más básica de aislamiento. La colocación de componentes redundantes en servidores separados evita que las fallas en las tarjetas de red, los dispositivos de almacenamiento conectados o las CPU afecten a todos sus componentes redundantes.
aislamiento de bastidor
Un bastidor es un recinto estandarizado para el montaje de servidores y otros equipos electrónicos. Los servidores alojados en el mismo bastidor pueden compartir muchos elementos, como conmutadores de red y cables de alimentación. La colocación de componentes redundantes en servidores alojados en diferentes bastidores evita que la falla de uno de los componentes compartidos del bastidor afecte todas sus implementaciones.
Aislamiento del centro de datos
Por lo general, todos los servidores alojados en un centro de datos determinado comparten la infraestructura de energía y refrigeración. El uso de múltiples centros de datos para alojar la implementación de su base de datos le permitirá responder a eventos más amplios, como fallas de energía y operaciones de mantenimiento en todo el centro de datos.
Aislamiento de zona de disponibilidad
Los proveedores de nube pública popularizaron el concepto de «zonas de disponibilidad». Consiste en uno o más centros de datos que están geográficamente cerca uno del otro.
El uso de varias zonas de disponibilidad para hospedar la implementación de su base de datos puede proteger sus servicios de desastres «naturales», como incendios e inundaciones.
Aislamiento regional
Podemos ir un paso más allá de forma aislada y utilizar varias regiones para la implementación de nuestra base de datos. Esta configuración puede proteger su base de datos de grandes desastres como tormentas, erupciones volcánicas o incluso inestabilidad política (considere mover sus cargas de trabajo de una zona de guerra a otra).
Ahora que tenemos una buena visión general de cómo hacer que una implementación de base de datos dada sea resistente a ciertos eventos de falla, debemos asegurarnos de que podemos automáticamente Aprovecha su elasticidad.
Gestión automática de conmutación por error
conmutación por error es el proceso mediante el cual transferimos la propiedad de un servicio de base de datos de un servidor fallido a un servidor saludable.
La conmutación por error puede ser iniciada manualmente por un ser humano o automáticamente por un componente de la implementación de la base de datos. Confiar en la intervención humana puede resultar en un tiempo de inactividad más largo que la conmutación por error automática y debe evitarse.
Conmutación por error del lado del servidor
Para iniciar automáticamente una conmutación por error desde la base de datos principal a la réplica, el componente debe monitorear el estado de cada instancia y decidir a qué instancia en buen estado se debe transferir el servicio.
Aquí hay una lista de herramientas de conmutación por error para algunas bases de datos populares:
- orquestador Para MySQL/MariaDB
- patronus (incluido el almacén de configuración distribuido requerido) para PostgreSQL
- Clústeres de conmutación por error de Windows Server (WSFC) incluidos los participantes testigo electoral Para servidor SQL
- Oráculo guardia de datos (incluidos los componentes de observador) para Oracle Database
Si planea usar una herramienta de este tipo, deberá realizar una serie de pruebas (en el maestro y las réplicas) para asegurarse de que el clúster se comporte como espera:
- Detener correctamente el proceso de la instancia de la base de datos principal
- Elimine el proceso de la instancia de la base de datos principal de repente
- Reinicie el servidor administrado
- Terminar el proceso de clúster/conmutación por error
- Aísle la instancia de base de datos relevante del resto de la instancia de base de datos desde una perspectiva de red
Dependiendo del comportamiento de la solución elegida, es posible que deba implementar sus propias personalizaciones para cumplir con sus requisitos.
Conmutación por error del lado de la aplicación
Un aspecto importante de la alta disponibilidad de la base de datos que a menudo se pasa por alto es la capacidad de una aplicación para (re)conectarse rápidamente a una instancia de base de datos saludable después de una conmutación por error del servidor.
Para que su aplicación conmute por error rápidamente a una instancia saludable, es posible que deba:
- Establezca configuraciones sensibles de mantenimiento de TCP para permitir que su aplicación detecte conexiones desconectadas a tiempo.
- Establezca un tiempo de espera en todas las llamadas a la base de datos para evitar que la conexión se cuelgue.
- Implemente la lógica de reintento en su aplicación para mitigar ciertos tipos de errores de base de datos/red.
- Utilice el proxy de la base de datos para ocultar los cambios en el host principal de los clientes de la base de datos.
Como vimos en la sección anterior, garantizar la alta disponibilidad de una base de datos implica mucho trabajo en el diseño, prueba y mantenimiento de múltiples componentes y configuraciones.
En la siguiente sección, analizaremos los productos de Canonical que pueden ayudarlo a lograr sus objetivos de alta disponibilidad.
Proporciona soluciones canónicas de alta disponibilidad.
macropolio es la respuesta de Canonical a la gestión automática de aplicaciones complejas que involucran cualquier cantidad de tecnologías, incluidas las bases de datos.
Ofrecemos una cuidada selección lista Fascinantes operadores de Juju para varias bases de datos con alta disponibilidad integrada y automatización de conmutación por error.
Además, la capacidad única de Juju para expresar las relaciones entre varias cargas de trabajo puede ayudarlo a garantizar, por ejemplo, que su aplicación siempre tendrá como destino una instancia de base de datos saludable.
Juju ayuda a DevOps, DBA y SRE a implementar, mantener y actualizar aplicaciones rápidamente de manera holística.
El ecosistema de Juju permite a sus usuarios conservar un alto grado de personalización y libertad:
- Proporcionamos operadores de código abierto que puede personalizar y ampliar a voluntad.
- Puede decidir conservar el acceso total a la infraestructura subyacente o dejar que administremos la infraestructura por usted.
- Juju puede implementar sus aplicaciones en múltiples nubes, lo que le brinda la libertad de elegir la aplicación que mejor se adapte a sus necesidades.
Contáctenos para obtener más información sobre Juju y nuestras soluciones para lograr una alta disponibilidad para sus cargas de trabajo.
