Base de datos operativa CDP (COD) es una base de datos transaccional autónoma impulsada por Apache HBase y Apache Phoenix. Es uno de los principales servicios de datos que se ejecuta en la nube pública de Cloudera Data Platform (CDP). Puede acceder a COD directamente desde su consola CDP. Con COD, los desarrolladores de aplicaciones ahora pueden aprovechar el poder de HBase y Phoenix sin los gastos generales que a menudo están relacionados con la implementación y la administración. COD es fácil de aprovisionar y autoadministrado, lo que significa que los desarrolladores pueden aprovisionar una nueva instancia de base de datos en cuestión de minutos y comenzar a crear prototipos rápidamente. Las funciones autónomas, como el escalado automático, la reparación automática y el ajuste automático, garantizan que no haya que preocuparse por la gestión y administración de la base de datos.
En este blog, compartiremos cómo CDP Operational Database puede brindar alta disponibilidad para sus aplicaciones cuando se ejecutan en múltiples zonas de disponibilidad en AWS.
Para entender completamente qué es una implementación Multi-AZ significa para su infraestructura, es fundamental reconocer cómo Amazon Web Services está configurado en todo el mundo y, por lo tanto, cómo proporciona los servicios de redundancia sin importar su ubicación. Como se explica en la documentación oficial de Amazon, la nube de AWS se compone de varias regiones, que son ubicaciones físicas en todo el mundo. Si bien las interrupciones de AZ no se rastrean oficialmente, los clientes de Cloudera informaron haber experimentado interrupciones de AZ 1 o 2 veces al año. Por lo tanto, se requieren implementaciones de extensión Multi-AZ para lograr una disponibilidad de más del 99,95 %.
Cada región comprende una serie de centros de datos físicos separados, conocidos como zonas de disponibilidad (AZ) . Cada AZ es una instalación autónoma con sus propias capacidades de energía, conectividad y red. La mayoría de las regiones albergan de 2 a 3 zonas de disponibilidad diferentes cada una, lo que proporciona una redundancia adecuada dentro de una región determinada (una AZ se representa mediante un código de región seguido de una letra de identificación; por ejemplo, us-west-1a) .
Sin embargo, esta redundancia solo se aplica a la capa de almacenamiento (S3) y no existe para las máquinas virtuales utilizadas para su instancia de base de datos. Si algo causara una interrupción en la zona de disponibilidad donde residen las instancias de su servidor, su base de datos dejaría de funcionar, ya que toda la infraestructura informática estaría fuera de línea.
Aquí es donde entra en juego la implementación Multi-AZ. Una implementación Multi-AZ significa que la infraestructura de cómputo para los servidores principales y regionales de HBase se distribuye en varias zonas de disponibilidad, lo que garantiza que cuando una sola zona de disponibilidad tiene una interrupción, solo una parte de los servidores regionales estarán afectados y los clientes cambiarán automáticamente a los servidores restantes en las zonas de disponibilidad disponibles. De manera similar, el maestro de respaldo (asumiendo que el maestro principal estaba en la zona de disponibilidad con una interrupción) asumirá automáticamente el rol del maestro que falla, ya que se implementa en una zona de disponibilidad separada del servidor principal principal. Todo esto es automático y no requiere configuración, administración ni acciones desde el punto de vista del usuario/administrativo. Simplemente funciona para garantizar que una aplicación no sufra una interrupción debido a la pérdida de una sola AZ.
Demostración
Las bases de datos COD recién creadas aprovecharán automáticamente todas las zonas de disponibilidad configuradas en el entorno. Por lo tanto, es crucial configurar el entorno con las zonas que nos gustaría usar.
Por ejemplo, tenemos un entorno con las siguientes zonas de disponibilidad:us-west-1a, us-west-1b y us-west-1c. Cuando implementamos una base de datos COD, se implementa automáticamente de forma multi-AZ:¡no hay nada que hacer! Echemos un vistazo entre bastidores y veamos qué hay en la consola de AWS.
COD se asegura de que los nodos trabajadores se distribuyan por igual en las zonas de disponibilidad configuradas. (Masters y Leader también se implementan en diferentes zonas de disponibilidad para proporcionar una alta disponibilidad para el quórum de ZooKeeper).
Apache HBase ya tiene capacidades integradas de conmutación por error, por lo que en caso de que un AZ se desconecte, el sistema ya está listo para continuar de forma instantánea y automática con los servicios de su base de datos.
Para agregar un poco más de diversión, ejecutemos una prueba de carga HBase simple durante nuestra prueba. HBase tiene una herramienta de prueba de carga integrada que podemos usar para una prueba de escritura de larga duración:
hbase ltt -escribir 10:1024:10 -num_keys 10000000
Simulemos la falla de AZ ahora y veamos qué sucede. La forma más fácil de hacerlo es agregar una nueva ACL de red que deshabilite el tráfico de entrada y salida de una subred determinada que realiza condiciones similares a una interrupción real de AWS.
En el primer minuto no vemos nada particularmente interesante en la página de estado porque, desde la perspectiva de COD, la base de datos aún está en buen estado.
Pero noté que el cliente dejó de progresar.
En 10-20 segundos, el maestro se da cuenta de que algunos de los servidores de la región están muertos.
Si la interrupción afecta al maestro activo, HBase cambiará automáticamente a la copia de seguridad que asumirá la función después de 10 a 20 segundos.
La falla no toma mucho tiempo, después de 2-3 minutos y algunos errores de región transitorios, el cliente puede progresar nuevamente. El maestro tuvo que hacer la transición de las regiones inactivas a los servidores de regiones activos.
Para simular el final de la interrupción, deshagamos la creación de la ACL de la red eliminándola. Los servidores de región se están conectando de nuevo al maestro.
Ahora estamos de vuelta donde empezamos originalmente. COD se ha recuperado completamente de la interrupción. En las solicitudes de escritura podemos ver dos caídas:la primera es cuando el cliente hizo la transición a los restantes servidores regionales en vivo, la segunda un poco más tarde es cuando el balanceador de carga de HBase movió las regiones a los servidores reconectados.
COD en HDFS
El almacenamiento de objetos en la nube es la capa de almacenamiento predeterminada para COD y distribuye los datos en 3 zonas de disponibilidad detrás y se reequilibrará entre bastidores. HBase solo tiene que hacer algunas tareas domésticas (transición de región) para servir a las regiones con los servidores restantes, lo que hace que esta sea una operación relativamente rápida.
Para casos de uso de alto rendimiento, COD admite el uso de HDFS como su almacenamiento subyacente. En este paradigma de implementación, configuramos automáticamente el reconocimiento de racks de HDFS para la tolerancia a fallas colocando una réplica de bloque en un rack diferente y asignando los racks a las zonas de disponibilidad. Esto proporciona disponibilidad de datos en caso de que falle un conmutador de red o una partición dentro del clúster. Por lo tanto, el comportamiento de la demostración anterior es muy similar al que vería al implementar COD con HDFS.
Resumen
La implementación de Multi-AZ es crucial para las bases de datos de alta disponibilidad y ahora COD lo admite en AWS como una vista previa técnica entre bastidores sin costo adicional. Hace que su carga de trabajo operativa sea más robusta y confiable sin configuración adicional. Estará disponible de forma general y admitirá proveedores de nube adicionales (Microsoft, Google) pronto.
Comuníquese con su equipo de cuentas de Cloudera si está interesado en obtener más información sobre cómo migrar de su implementación de HBase a la base de datos operativa de CDP en la nube pública o pruébelo con Cloudera Test Drive.
