Visión general de la alta disponibilidad y la recuperación tras desastre para Databases for Elasticsearch
La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. En el caso de los servicios, la disponibilidad se define en el Acuerdo de Nivel de Servicio. La disponibilidad incluye tanto los eventos planificados como los no planificados, como el mantenimiento, los fallos y las catástrofes. (HA) es la capacidad de un servicio de permanecer operativo y accesible ante fallos inesperados. La recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de recuperación de la instancia de servicio a un estado de funcionamiento.
Databases for Elasticsearch es un servicio regional que cumple los Objetivos de Nivel de Servicio(OEN ) definidos con el plan estándar.
Para más información, véase Acuerdo de nivel de servicio(SLA). Para más información sobre las regiones y centros de datos disponibles en IBM Cloud para Databases for Elasticsearch, consulte Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Databases for Elasticsearch proporciona funciones de replicación, conmutación por error y alta disponibilidad para proteger sus bases de datos y datos del mantenimiento de la infraestructura, las actualizaciones y algunos fallos. Los despliegues contienen un clúster con tres miembros de datos. Elasticsearch utiliza índices para almacenar datos y cada índice tiene un shard primario y un shard réplica. Elasticsearch utiliza un modelo de replicación de datos basado en el modelo de copia de seguridad primaria. El shard primario sirve como punto de entrada principal para las operaciones de indexación, mientras que las otras copias se conocen como shards réplica. La replicación asíncrona se emplea para mantener actualizados los fragmentos de réplica. Elasticsearch garantiza la estabilidad del estado del clúster y facilita la conmutación por error. En caso de que el nodo maestro deje de estar disponible, se elige un nuevo maestro y los shards réplica del nuevo maestro son promovidos a maestro. Los shards líder y réplica están distribuidos geográficamente en diferentes zonas dentro del clúster para mitigar el riesgo de fallos simultáneos.
Puede ampliar aún más la alta disponibilidad añadiendo más réplicas a los índices, pero esto conlleva costes de almacenamiento adicionales que deben tenerse en cuenta.
Revise la documentación de Elasticsearch sobre técnicas de replicación para comprender las limitaciones y compensaciones asociadas a la estrategia de replicación asíncrona que se despliega por defecto.
Funciones de alta disponibilidad
Databases for Elasticsearch admite las siguientes funciones de alta disponibilidad:
| Característica | Descripción | Consideración |
|---|---|---|
| Conmutación automática | Estándar en todos los clústeres y resistente frente al fallo de una zona o de un único miembro. | |
| Número de miembros | Mínimo 3 miembros. Por defecto es un despliegue Estándar tres. | |
| Escalado horizontal | Es posible escalar horizontalmente su despliegue de IBM Cloud Databases for Elasticsearch añadiendo más nodos Elasticsearch (también denominados miembros). Añadir más nodos aumenta la capacidad y la fiabilidad. |
Arquitectura de recuperación en caso de catástrofe
Funciones de recuperación en caso de catástrofe
Databases for Elasticsearch admite las siguientes funciones de recuperación ante desastres:
| Característica | Descripción | Consideración |
|---|---|---|
| Restauración de copias de seguridad | Crear una base de datos a partir de una copia de seguridad creada previamente. Para obtener más información, consulte Gestión de copias de seguridad en Cloud Databases. | Las nuevas cadenas de conexión para la base de datos restaurada deben referenciarse en toda la carga de trabajo. |
| Escalado horizontal | Es posible escalar horizontalmente su despliegue de IBM Cloud Databases for Elasticsearch añadiendo más nodos Elasticsearch (también denominados miembros). Añadir más nodos hará que su base de datos sea más resistente a los fallos de varias zonas. | |
| Instantáneas | Puede almacenar instantáneas en un repositorio de instantáneas accesible desde varias regiones. Sin embargo, las instantáneas no son en tiempo real y se suelen utilizar para realizar copias de seguridad y restauraciones, más que para una conmutación por error inmediata. En caso de fallo, debes restaurar desde una instantánea manualmente. |
Planificación de la RD
Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. A medida que elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y resoluciones.
| Anomalía | Resolución |
|---|---|
| Fallo de hardware (punto único) | IBM proporciona una base de datos resistente a un único punto de fallo de hardware dentro de una zona, sin necesidad de configuración. |
| error de zona | Conmutación automática. Los miembros de la base de datos se distribuyen entre las zonas. La configuración de tres miembros proporciona una resistencia adicional a los fallos de varias zonas. |
| Corrupción de datos | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción o para datos de origen para corregir la corrupción en la base de datos restaurada. |
| Fracaso regional | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción. |
Alta disponibilidad a nivel de aplicación
Las aplicaciones que se comunican a través de redes y servicios en la nube están sujetas a errores de conexión transitorios. Diseñe sus aplicaciones para reintentar las conexiones cuando se produzcan errores por una pérdida temporal de conectividad con su implantación o con IBM Cloud.
Como Databases for Elasticsearch es un servicio gestionado, las actualizaciones periódicas y el mantenimiento de la base de datos forman parte de las operaciones normales. Esto puede hacer que, ocasionalmente durante intervalos cortos, la base de datos no esté disponible. También puede hacer que la base de datos desencadene una migración tras error, vuelva a intentarlo y vuelva a conectarse. La base de datos tarda poco tiempo en determinar qué miembro es una réplica y cuál es el líder, por lo que también puede darse una breve interrupción de la conexión. La migración tras error suele tardar menos de 30 segundos.
Las aplicaciones deben estar diseñadas de modo que gestionen las interrupciones temporales en la base de datos, implementen el manejo de errores para los mandatos anómalos de la base de datos e implementen la lógica de reintento para recuperarse de una interrupción temporal.
No se esperan faltas de disponibilidad de base de datos ni interrupciones de conexión de varios minutos. Abre un caso de soporte con detalles si tienes periodos de más de un minuto sin conectividad para que podamos investigar.
límites de conexiones
Databases for Elasticsearch no tiene restricciones en cuanto al número de conexiones que se abren a la base de datos, ya que utiliza la API REST para interactuar con la base de datos. Elasticsearch proporcionan una buena experiencia de uso para las operaciones básicas, como la búsqueda de texto completo, el resaltado, las agregaciones y la indexación.
Si desea obtener más rendimiento de nuestra base de datos, consulte la página Optimizar Elasticsearch para obtener más información.
Sus responsabilidades en HA y DR
La siguiente información puede ayudarle a crear y practicar continuamente su plan de HA y DR.
Cuando se restaura una base de datos a partir de copias de seguridad o se utiliza la restauración puntual, se crea una nueva base de datos con nuevas cadenas de conexión. Las cargas de trabajo y los procesos existentes deben ajustarse para consumir las nuevas cadenas de conexión.
Una base de datos recuperada también puede necesitar las mismas dependencias creadas por el cliente de la base de datos siniestrada. Garantizar la existencia de estos y otros servicios en la región recuperada:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
Recuerda que al borrar una base de datos también se borran sus copias de seguridad asociadas. Sin embargo, las bases de datos borradas pueden recuperarse en un plazo limitado. Para obtener más información, consulte la documentación de Preguntas frecuentes sobre copias de seguridad, donde encontrará detalles específicos sobre los procedimientos de recuperación de bases de datos.
No es posible copiar copias de seguridad fuera de IBM Cloud, por lo que se recomienda utilizar las herramientas específicas de la base de datos para realizar copias de seguridad adicionales. Puede ser necesario para recuperarse de la eliminación maliciosa de una base de datos seguida de una recuperación-eliminación de una base de datos. Una gestión cuidadosa del acceso IAM a las bases de datos puede ayudar a reducir la exposición a este problema.
La siguiente lista de comprobación asociada a cada característica puede ayudarle a crear y poner en práctica su plan.
- Restauración de copias de seguridad
- Verificar que las copias de seguridad están disponibles con la frecuencia deseada para cumplir los requisitos de RPO. La gestión de las copias de seguridad de Cloud Databases documenta la frecuencia de las copias de seguridad.
- Existen algunas restricciones en las regiones de restauración de bases de datos - verifique que sus objetivos de restauración pueden ser alcanzados leyendo la gestión de copias de seguridad Cloud Databases.
- Compruebe que el periodo de conservación de las copias de seguridad cumple sus requisitos.
- Programe restauraciones de prueba con regularidad para verificar que los tiempos de restauración reales cumplen el RTO definido. Recuerda que el tamaño de la base de datos influye significativamente en el tiempo de restauración. Ten en cuenta estrategias para minimizar los tiempos de restauración, como dividir las bases de datos grandes en unidades más pequeñas y manejables y purgar los datos no utilizados.
- Verifique el servicio Key Protect.
Para saber más sobre la propiedad de la responsabilidad entre el cliente y IBM Cloud por el uso de Databases for Elasticsearch, consulte Responsabilidades compartidas en Cloud Databases.
Manténgase informado: IBM notificaciones
Las actualizaciones que afectan a las cargas de trabajo de los clientes se comunican a través de las notificaciones de IBM Cloud. Para mantenerse informado sobre el mantenimiento previsto, los anuncios y las notas de la versión relacionadas con este servicio, consulte la página de notificaciones y estado de la supervisión. Además, revise periódicamente la página Política de versiones para conocer las últimas actualizaciones sobre versiones y fechas de fin de vida útil.