Confiabilidad en Azure Data Explorer

Azure Data Explorer es un servicio de análisis que permite ingerir, almacenar y consultar grandes volúmenes de datos con baja latencia. Normalmente se usa para cargas de trabajo de análisis de registros, telemetría y series temporales que requieren consultas rápidas sobre grandes conjuntos de datos.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure Data Explorer sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad y errores en toda la región. También se describen las opciones de copia de seguridad y restauración y la resistencia al mantenimiento del servicio y se resalta la información clave sobre el contrato de nivel de servicio (SLA) de Azure Data Explorer.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda realizar los pasos siguientes para mejorar la confiabilidad del clúster de Azure Data Explorer:

• Implemente un clúster completo. Azure Data Explorer proporciona clústeres gratuitos con fines de prueba. En el caso de las cargas de trabajo de producción, implemente un clúster completo.
• Habilite la compatibilidad con la zona de disponibilidad. Azure Data Explorer admite zonas de disponibilidad. Cuando la compatibilidad con zonas de disponibilidad está habilitada, los nodos de proceso se distribuyen entre varias zonas de disponibilidad y los datos se almacenan mediante el almacenamiento con redundancia de zona. Esta configuración mejora la resistencia a los errores de zona de disponibilidad.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

El recurso principal que implemente es un clúster, que representa la infraestructura que necesita para ingerir, almacenar y consultar los datos. Con un clúster, se crean bases de datos, que a su vez contienen tablas.

Los clústeres realizan la ingesta para recuperar datos de otros orígenes de datos y cargarlos en una tabla del clúster. A continuación, los datos se pueden consultar mediante la sintaxis del lenguaje de consulta kusto (KQL). Los clústeres también tienen un conjunto de operaciones de administración que puede realizar.

Arquitectura física

Un clúster de Azure Data Explorer tiene dos capas principales que son aplicables a su configuración de confiabilidad:

• Capa de proceso: Azure Data Explorer es una plataforma informática distribuida y puede tener dos o más nodos de máquinas virtuales (VM), dependiendo de la escala y el tipo de rol de nodo. Los nodos controlan el trabajo de ingesta y procesamiento de consultas de datos. No gestionas directamente ni ves las máquinas virtuales del nodo. La plataforma administra automáticamente la creación de instancias, la supervisión del estado y el reemplazo de nodos incorrectos. Cuando el clúster está configurado para usar zonas de disponibilidad, los nodos se distribuyen entre distintos centros de datos.

• Capa de almacenamiento: Azure Data Explorer usa Azure Storage como su capa de persistencia duradera. Azure Storage proporciona automáticamente tolerancia a errores, con la configuración predeterminada que ofrece almacenamiento con redundancia local (LRS) dentro de un centro de datos. Se conservan tres réplicas. Si se pierde una réplica mientras está en uso, se implementa otra sin interrupción. Cuando el clúster está configurado para usar varias zonas de disponibilidad, las réplicas se distribuyen entre distintos centros de datos.

Para más información, consulte Funcionamiento de Azure Data Explorer.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Para crear resistencia a errores transitorios al usar Azure Data Explorer, siga estos procedimientos:

• Confíe en el comportamiento de reintento integrado cuando use la ingesta en cola.
• Use bibliotecas y SDK de cliente proporcionados por Microsoft, que reintentan automáticamente cuando se producen errores transitorios.
• Si usa las API REST de Azure Data Explorer directamente, vuelva a intentar las consultas y las operaciones de administración que produzcan errores debido a un error transitorio.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Azure Data Explorer admite dos tipos de configuración de zona de disponibilidad:

• Con redundancia de zona (recomendado): Al habilitar zonas de disponibilidad en el clúster, los nodos del clúster se distribuyen entre varias zonas. Microsoft administra la distribución de nodos en las zonas de disponibilidad seleccionadas y controla la detección y respuesta a los errores de zona de disponibilidad. Un clúster con redundancia de zona es resistente a una interrupción de zona de disponibilidad.

  Al configurar el clúster para que sea con redundancia de zona, los datos se almacenan mediante el almacenamiento con redundancia de zona de Azure Storage (ZRS), que replica de forma sincrónica al menos tres copias de los datos en varias zonas de disponibilidad.

  

• Zonal: Opcionalmente, puede seleccionar una sola zona al habilitar zonas de disponibilidad en el clúster. Microsoft coloca todos sus nodos de cómputo en esa zona. Se trata de un clúster zonal (de una sola zona). Esta configuración puede ayudar ocasionalmente si tiene una carga de trabajo inusualmente sensible a la latencia, pero no proporciona resistencia a interrupciones de zona.

  Importante

  La asignación a una sola zona de disponibilidad solo se recomienda cuando la latencia entre zonas es demasiado alta para sus necesidades y después de comprobar que la latencia no cumple sus requisitos. Por sí mismo, un recurso zonal no proporciona resistencia a una interrupción de zona de disponibilidad. Para mejorar la resiliencia de un recurso zonal, debe desplegar explícitamente recursos independientes en múltiples zonas de disponibilidad y configurar el enrutamiento del tráfico y la conmutación por error. Para obtener más información, consulte Recursos zonales y resistencia de zona.

  La selección de zona solo se aplica a los nodos de proceso. En el caso de un clúster zonal, los datos de almacenamiento siguen usando LRS y pueden almacenarse en una zona diferente a los nodos de proceso.

  

Si no habilita zonas de disponibilidad, el clúster es no zonal, lo que significa que Azure selecciona la zona de disponibilidad para cada nodo y los datos. Si alguna zona de disponibilidad de la región tiene una interrupción, puede afectar a los nodos, datos o ambos del clúster. No se recomienda una configuración no zonal porque no proporciona protección contra interrupciones de zona de disponibilidad.

Requisitos

• Compatibilidad con regiones: La compatibilidad con zonas de disponibilidad está disponible en regiones de Azure que admiten zonas de disponibilidad.

  Sin embargo, algunos tamaños y tipos de nodo de proceso solo están disponibles en regiones específicas o zonas específicas dentro de una región.

• Clústeres completos: La compatibilidad con zonas de disponibilidad está disponible con clústeres completos. No está disponible con clústeres gratuitos.

Consideraciones

Selección de zona: En el caso de los nodos de proceso, elija las zonas de disponibilidad que se van a usar. Microsoft administra la ubicación de la zona de almacenamiento y las réplicas de almacenamiento se pueden colocar en zonas diferentes a los nodos de proceso.

Costo

La habilitación del soporte para zonas de disponibilidad conlleva costos adicionales para el almacenamiento con redundancia de zona, que se factura a una tarifa más alta que el almacenamiento con redundancia local. Para más información, consulte Precios de Azure Storage.

Los nodos de cálculo se cobran a la misma tarifa independientemente de si se utiliza soporte para zonas de disponibilidad. Para más información, consulte los Precios de Azure Data Explorer.

Configurar soporte de zonas de disponibilidad

• Cree un clúster con compatibilidad con la zona de disponibilidad: Puede habilitar la compatibilidad con zonas de disponibilidad al crear un nuevo clúster de Azure Data Explorer. Para más información, consulte Creación de un clúster y una base de datos.

  Al crear un clúster habilitado para zonas de disponibilidad mediante el portal de Azure, automáticamente tiene redundancia de zona y Microsoft selecciona las zonas.

  Para seleccionar zonas usted mismo o para crear un clúster zonal, use otro enfoque de implementación como las API de Azure Resource Manager o Bicep. En la mayoría de las situaciones, se recomienda crear un clúster con redundancia de zona y usar todas las zonas de la región.

  Nota:

  Cuando selecciona qué zonas de disponibilidad usar, en realidad está seleccionando la zona de disponibilidad lógica. Si implementa otros componentes de carga de trabajo en una suscripción de Azure diferente, pueden usar un número de zona de disponibilidad lógica diferente para acceder a la misma zona de disponibilidad física. Para obtener más información, consulte zonas de disponibilidad física y lógica.

• Habilitación de zonas de disponibilidad en un clúster existente (versión preliminar): Puede migrar un clúster no zonal existente para usar zonas de disponibilidad. Esta funcionalidad está en versión preliminar. Para más información, consulte Migración del clúster para admitir varias zonas de disponibilidad.

• Volver a configurar zonas de disponibilidad en un clúster existente (versión preliminar): Puede cambiar las zonas usadas para un clúster. Esta funcionalidad está en versión preliminar. Para más información, consulte Migración del clúster para admitir varias zonas de disponibilidad.

• Deshabilite la compatibilidad con zonas de disponibilidad en un clúster existente: Después de configurar un clúster con zonas de disponibilidad, no se puede cambiar el clúster para que no use zonas de disponibilidad.

• Compruebe la configuración de la zona de disponibilidad para los clústeres: Puede usar la propiedad de estado de zona del clúster (la zoneStatus propiedad de la API REST) para comprobar la configuración de zona de disponibilidad de un clúster.

  Si el valor es Zonal, significa que el clúster se ha configurado para usar zonas de disponibilidad. Sin embargo, el clúster puede ser zonal o redundante por zona. Para determinar qué, use la propiedad zones . Si la lista de zonas tiene una zona enumerada, el clúster es zonal (zona única). Si tiene varias zonas enumeradas, es redundante de zona.

Planeamiento y administración de capacidad

Cuando una zona de disponibilidad no está disponible, es posible que los nodos de esa zona no estén disponibles temporalmente, lo que reduce la capacidad de proceso del clúster hasta que se recupere la zona.

Si el clúster no puede tolerar la pérdida de capacidad, considere la posibilidad de sobreaprovisionar el clúster. Este enfoque permite que la solución tolere cierta pérdida de capacidad y siga funcionando sin que se vea afectado su rendimiento. Sin embargo, al sobreaprovisionar el clúster, es posible que el clúster tenga un número de nodos desequilibrado entre zonas.

Distribución de instancias a través de zonas

La capa de proceso del clúster usa un enfoque de mejor esfuerzo para distribuir uniformemente las instancias entre las zonas que seleccione.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al configurar un clúster para la compatibilidad con zonas de disponibilidad y todas las zonas están operativas.

• Operación entre zonas: Durante el funcionamiento normal, Azure Data Explorer usa todos los nodos de proceso disponibles para la ingesta, el procesamiento de consultas y otras operaciones. El trabajo se distribuye entre nodos independientemente de su zona de disponibilidad.

• Replicación de datos entre zonas: El comportamiento de replicación de datos entre zonas depende de la configuración de zona de disponibilidad que usa el clúster.

  • Con redundancia de zona: Los datos se replican sincrónicamente entre zonas de disponibilidad mediante el almacenamiento con redundancia de zona de Azure Storage. Esto proporciona un alto nivel de coherencia de datos y minimiza el riesgo de pérdida de datos durante un error de zona.

  • Zonal: Los datos se almacenan mediante el almacenamiento con redundancia local de Azure Storage, lo que significa que las tres copias pueden estar en una sola zona de disponibilidad.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar al configurar un clúster para la compatibilidad con zonas de disponibilidad y se produce una interrupción en una de las zonas.

• Detección y respuesta: La responsabilidad de la detección y la respuesta depende de la configuración de zona de disponibilidad que usa el clúster.

  • Con redundancia de zona: Microsoft detecta fallos en las zonas de disponibilidad y gestiona la respuesta de Azure Data Explorer. No es necesario hacer nada para iniciar una conmutación por error de la zona.

  • Zonal: Usted es responsable de detectar una falla que afecta una zona de disponibilidad utilizada por su clúster. También es responsable de cualquier respuesta que decida llevar a cabo, como cambiar a un segundo clúster previamente configurado en otra zona de disponibilidad.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Las solicitudes activas que dependen de los recursos de proceso o almacenamiento de la zona con errores podrían finalizarse y el cliente debería reintentarlas. Asegúrese de que las aplicaciones están preparadas siguiendo las instrucciones de control de errores transitorios.

• Pérdida de datos esperada: La pérdida de datos esperada depende de la configuración de zona de disponibilidad que usa el clúster.

  • Con redundancia de zona: No se espera ninguna pérdida de datos durante una interrupción de la zona de disponibilidad porque los datos se replican sincrónicamente entre zonas.

  • Zonal: Los datos no están disponibles hasta que se recupere la zona. En el improbable caso de una pérdida permanente de una zona que contiene todas las réplicas de almacenamiento, es posible que los datos se pierdan permanentemente.

• Tiempo de inactividad esperado: El tiempo de inactividad esperado depende de la configuración de zona de disponibilidad que usa el clúster.

  • Zona-redundante: Una breve interrupción del servicio podría ocurrir mientras el tráfico se redirige a zonas de disponibilidad saludables. Asegúrese de que las aplicaciones están preparadas siguiendo las instrucciones de control de errores transitorios.

  • Zonal: Los nodos de cómputo del clúster no están disponibles hasta que se restablezca la zona de disponibilidad. Es posible que tampoco pueda acceder a los datos del clúster durante un fallo de zona.

• Redistribución: El comportamiento de reenrutamiento del tráfico depende de la configuración de zona de disponibilidad que usa el clúster.

  • Redundancia de zona: Azure Data Explorer enruta nuevas solicitudes a los recursos de proceso y almacenamiento en las zonas saludables restantes.

  • Zonal: El clúster no está disponible hasta que se recupere la zona de disponibilidad.

Recuperación de zona

Cuando se recupera la zona de disponibilidad que ha fallado, Microsoft recrea los nodos del clúster y las réplicas de almacenamiento en esa zona y restaura la distribución normal del tráfico en todas las zonas. No se requiere ninguna acción del cliente.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa el clúster.

• Con redundancia de zona: Microsoft administra completamente la conmutación por error de zona de disponibilidad y la recuperación para Azure Data Explorer. No es necesario iniciar ni validar los procesos de fallo de las zonas de disponibilidad.

• Zonal: Para simular parcialmente la pérdida de todos los nodos de cómputo durante una interrupción de zona, puede detener su clúster. Puede usar este enfoque para validar las partes de sus propios procesos de detección de caída de zona y conmutación por error.

Resistencia a errores en toda la región

Un clúster de Azure Data Explorer se implementa en una sola región de Azure. Si esa región deja de estar disponible, el clúster y sus datos no están disponibles.

Soluciones personalizadas de varias regiones para la resistencia

Para minimizar el impacto empresarial de una interrupción de la región, puede implementar clústeres independientes de Azure Data Explorer en varias regiones. Cada clúster es independiente, y usted es responsable de administrar cada clúster, así como de coordinar la replicación de datos, el enrutamiento del tráfico y la recuperación ante fallos entre regiones.

Puede decidir entre diferentes tipos de configuraciones de clúster de varias regiones, que admiten distintos niveles de tiempo de recuperación, posible pérdida de datos, esfuerzo y costo. Puede seleccionar regiones de Azure para cada clúster que admita los requisitos de latencia y residencia de datos. Para más información sobre las configuraciones y los patrones de clúster de varias regiones que puede seguir, consulte Interrupción de una región de Azure.

Copias de seguridad y restauración

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Azure Data Explorer no proporciona una funcionalidad nativa de copia de seguridad y restauración. Si necesita realizar copias de seguridad de los datos, puede tener en cuenta los siguientes enfoques:

• Exportación continua, que exporta periódicamente datos al almacenamiento externo y admite exactamente una exportación de datos admitidos.
• Exportación de datos al almacenamiento en la nube, que permite exportar manualmente los datos al almacenamiento externo.
• Ingerir datos sin procesar en Azure Data Explorer desde una fuente de entrada, como un lago de datos, del que puede hacer una copia de seguridad por separado.

Resistencia a la eliminación accidental

Azure Data Explorer incluye varios mecanismos para ayudarle a protegerse frente a la eliminación accidental de clústeres, bases de datos, tablas y tablas externas:

• Eliminación accidental de clústeres o bases de datos: La eliminación accidental de clústeres o bases de datos es una acción irrecuperable. Para evitar la pérdida de datos, habilite un bloqueo de eliminación en el clúster o el recurso de base de datos.

• Eliminación accidental de tablas: Los usuarios con permisos de administrador de tablas o superiores pueden quitar tablas. Si uno de esos usuarios elimina accidentalmente una tabla, puede recuperarla mediante el comando .undo drop table. Para que este comando se ejecute correctamente, primero debe habilitar la propiedad recoverability (capacidad de recuperación) en la directiva de retención.

• Eliminación accidental de tablas externas:las tablas externas son entidades de esquema de consulta de Kusto que hacen referencia a datos almacenados fuera de la base de datos. La eliminación de una tabla externa solo elimina los metadatos de la tabla. Para recuperarlos, vuelva a ejecutar el comando de creación de la tabla.

  En el caso de las tablas externas de Azure Blob Storage y Azure Data Lake, use la funcionalidad de eliminación temporal para protegerse frente a la eliminación accidental o sobrescritura de un blob durante un período de tiempo configurado por el usuario.

Resistencia al mantenimiento del servicio

Azure Data Explorer aplica periódicamente las actualizaciones del servicio y realiza un mantenimiento rutinario. La plataforma Azure controla estas actividades automáticamente mientras permanece dentro de los niveles de disponibilidad especificados en el Acuerdo de Nivel de Servicio. Asegúrese de que las aplicaciones están preparadas para la pérdida ocasional de conectividad durante el mantenimiento del servicio siguiendo las instrucciones de control de errores transitorios.

Para más información sobre el próximo mantenimiento, use Azure Service Health.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Para que sea apto para el Acuerdo de Nivel de Servicio de disponibilidad de Azure Data Explorer, la aplicación debe controlar los errores transitorios mediante el reintento de solicitudes con errores.

Contenido relacionado

• Confiabilidad en Azure
• Introducción a Azure Data Explorer
• Introducción a la continuidad empresarial y recuperación ante desastres