Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Databricks es una plataforma de inteligencia artificial y datos basados en Apache Spark colaborativa optimizada para Microsoft Azure. Proporciona un entorno unificado para cargas de trabajo de macrodatos e inteligencia artificial y combina lo mejor de Databricks y Azure para simplificar la ingeniería de datos, la ciencia de datos y el aprendizaje automático.
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 Azure Databricks mantiene la resistencia frente a varias posibles interrupciones y problemas y cómo puede configurar la resistencia para satisfacer sus requisitos. En las instrucciones se describen los errores transitorios, las interrupciones de zona de disponibilidad, las interrupciones de región y el mantenimiento del servicio. En este artículo también se describe cómo usar copias de seguridad para recuperarse de otros problemas y se resalta información clave sobre el contrato de nivel de servicio (SLA) de Azure Databricks.
Recomendaciones de implementación de producción
Para obtener información sobre cómo implementar Azure Databricks para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Azure Databricks.
Introducción a la arquitectura de confiabilidad
Debe comprender la confiabilidad de cada componente principal de Azure Databricks:
El plano de control es una colección de servicios sin estado que administra los metadatos del área de trabajo, el acceso de usuario, la programación de trabajos y la administración de clústeres. Estos servicios están respaldados por bases de datos que se replican en múltiples zonas de disponibilidad dentro de las regiones admitidas.
La raíz del sistema de archivos de Databricks (DBFS) es una cuenta de almacenamiento que Azure Databricks aprovisiona automáticamente al crear un área de trabajo de Azure Databricks en la cuenta en la nube. Se recomienda no almacenar datos en la raíz de DBFS y deshabilitar esta cuenta de almacenamiento si es posible.
El almacenamiento del catálogo de Unity incluye una o varias cuentas de almacenamiento que almacenan los datos del catálogo de Unity en la cuenta en la nube. Para obtener más información, consulte Introducción al catálogo de Unity.
El plano de proceso ejecuta cargas de trabajo de procesamiento de datos mediante clústeres de máquinas virtuales (VM). El plano de proceso controla los errores transitorios y reemplaza automáticamente los nodos con errores sin intervención del usuario. Puede elegir entre varios tipos de recursos de proceso. Para obtener más información, consulte Computación.
La disponibilidad del área de trabajo depende de la disponibilidad del plano de control, pero los clústeres de proceso pueden seguir procesando trabajos incluso durante las interrupciones del plano de control.
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.
Puede controlar los reintentos de las tareas dentro de trabajos de Lakeflow para ayudar a recuperar de errores transitorios.
En el caso de las aplicaciones que se ejecutan en Azure Databricks, implemente la lógica de reintento con retroceso exponencial al conectarse a servicios externos o servicios de Azure, como Storage, Azure SQL Database o Azure Event Hubs. Databricks Runtime incluye resistencia integrada para muchos servicios de Azure, pero el código de la aplicación debe controlar errores transitorios específicos del servicio.
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 Databricks admite redundancia de zona para cada componente:
Plano de control: En regiones que admiten zonas de disponibilidad, el plano de control se ejecuta en varias zonas de disponibilidad. El plano de control controla los errores de zona automáticamente, con un impacto mínimo y ninguna intervención del usuario necesaria.
Los datos del área de trabajo del plano de control se almacenan en bases de datos. En las regiones que admiten zonas de disponibilidad, las bases de datos se replican en varias zonas de la región. Las cuentas de almacenamiento que atienden imágenes en tiempo de ejecución de Databricks también son redundantes dentro de la región. Todas las regiones tienen cuentas de almacenamiento secundarias que se usan cuando la cuenta de almacenamiento principal está inactiva.
Raíz de DBFS: En las regiones que admiten zonas de disponibilidad, puede configurar la cuenta de almacenamiento para que la raíz de DBFS use el almacenamiento con redundancia de zona (ZRS). En regiones emparejadas que admiten zonas de disponibilidad, puede usar opcionalmente almacenamiento con redundancia de zona geográfica (GZRS).
Plano de proceso: Databricks admite la distribución automática de zonas para los recursos de proceso, lo que significa que los recursos se distribuyen entre varias zonas de disponibilidad. Esta distribución ayuda a las cargas de trabajo de producción a lograr resistencia a las interrupciones de zona.
Cuando se usa el proceso sin servidor, no se seleccionan explícitamente zonas para el proceso. Databricks administra la selección de zona de las máquinas virtuales y el reemplazo de máquinas virtuales que podrían perderse debido a interrupciones de zona.
Requisitos
Para usar la compatibilidad con zonas de disponibilidad en Azure Databricks, necesita los siguientes requisitos:
Compatibilidad con regiones: La compatibilidad con la zona de disponibilidad de Azure Databricks está disponible en todas las regiones de Azure que admiten Azure Databricks y proporcionan zonas de disponibilidad. Para obtener una lista de las regiones que admiten Azure Databricks, consulte Productos disponibles por región. Para obtener una lista completa de las regiones que admiten zonas de disponibilidad, consulte Regiones de Azure que admiten zonas de disponibilidad.
Replicación de almacenamiento: Configure las cuentas de almacenamiento del área de trabajo para usar ZRS o GZRS (cuando esté disponible).
Capacidad de proceso: Asegúrese de que existe suficiente capacidad de proceso en varias zonas de la región de destino. Azure Databricks distribuye automáticamente los nodos de clúster entre zonas, pero debe comprobar que los tipos de instancia seleccionados están disponibles en todas las zonas de destino.
Consideraciones
Azure Databricks distribuye automáticamente los nodos de clúster entre zonas de disponibilidad. La distribución depende de la capacidad disponible en cada zona. Durante períodos de alta demanda, los nodos de un clúster se pueden concentrar en menos zonas. Cuando usas computación sin servidor, Azure Databricks gestiona la selección de zona de las máquinas virtuales (VMs) y el reemplazo de VMs que podrían perderse debido a fallos de zonas.
Cost
La distribución de zona no afecta a los costos de proceso porque paga por el mismo número de máquinas virtuales, independientemente de su ubicación de zona de disponibilidad. Para obtener más información, consulte Precios de computación de Azure Databricks.
La redundancia predeterminada para la cuenta de almacenamiento administrada o la raíz de DBFS es el almacenamiento con redundancia geográfica (GRS). Cambiar a ZRS o GZRS puede afectar a los costos de almacenamiento. Para obtener más información, consulte Precios de Azure Blob Storage.
Configurar soporte de zonas de disponibilidad
Plano de control: El plano de control admite automáticamente la redundancia de zona en regiones que tienen zonas de disponibilidad. No es necesario configurar nada.
Raíz de DBFS: Puede configurar la redundancia de zona para el almacenamiento raíz de DBFS al crear un área de trabajo o modificar una área de trabajo existente:
Cree un nuevo área de trabajo con almacenamiento raíz de DBFS redundante de zona: Cuando cree un nuevo área de trabajo de Azure Databricks, puede configurar opcionalmente la cuenta de almacenamiento asociada para utilizar ZRS o GZRS en lugar del GRS predeterminado. Para más información, consulte Cambio de las opciones de redundancia de almacenamiento del área de trabajo.
Habilite la redundancia de zona en el almacenamiento raíz de DBFS: En el caso de las áreas de trabajo existentes, puede cambiar la configuración de redundancia de la cuenta de almacenamiento del área de trabajo a ZRS o GZRS. Para obtener más información sobre cómo habilitar la redundancia de zona, consulte Cambio de la configuración de replicación para una cuenta de almacenamiento.
Plano de proceso: Los nodos de clúster se distribuyen automáticamente entre zonas de disponibilidad. No se requiere ninguna configuración de cliente para la distribución de zona.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando un área de trabajo está configurada con compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.
Replicación de datos entre zonas: La replicación de datos para el almacenamiento del área de trabajo se produce sincrónicamente entre zonas cuando la raíz de DBFS usa una cuenta ZRS o GZRS. Este enfoque garantiza una coherencia sólida con un impacto mínimo en el rendimiento.
Enrutamiento de tráfico entre zonas: Azure Databricks distribuye automáticamente los nodos de clúster entre zonas durante la creación del clúster. El servicio equilibra la carga de proceso entre zonas mientras mantiene la localidad de datos para obtener un rendimiento óptimo.
Comportamiento durante un fallo de zona
En esta sección se describe qué esperar cuando un área de trabajo está configurada con soporte para zona de disponibilidad y hay una interrupción en la zona de disponibilidad.
Detección y respuesta: Microsoft detecta automáticamente errores de zona e inicia procedimientos de respuesta. No es necesario realizar ninguna acción para la conmutación por error de nivel de zona.
Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Pero puede usar la página de estado de Azure Databricks para ver una introducción a todos los servicios principales de Azure Databricks. También puede suscribirse a actualizaciones de estado de componentes individuales del servicio y recibir una alerta cuando cambie el estado del servicio al que está suscrito.
Solicitudes activas: La ejecución de clústeres podría perder nodos en la zona afectada. El administrador de clústeres solicita automáticamente nodos de reemplazo de zonas restantes. Si se pierde el nodo del controlador, el clúster y el trabajo se reinician completamente.
Pérdida de datos esperada:
Plano de control: No se espera ninguna pérdida de datos durante una interrupción de zona.
Raíz de DBFS: los datos del área de trabajo permanecen disponibles si usa configuraciones de almacenamiento de ZRS o GZRS.
Plano de proceso: Los datos almacenados en caché en máquinas virtuales son efímeros. Los datos perdidos de las máquinas virtuales durante un error de zona se recuperan del almacenamiento. Si se pierde el nodo del controlador, el trabajo se reinicia y vuelve a calcular los resultados.
Tiempo de inactividad esperado:
Plano de control: el plano de control de Databricks realiza la conmutación por error automática a zonas correctas en unos 15 minutos.
Raíz de DBFS: No se espera ningún tiempo de inactividad para las cuentas de almacenamiento que usan ZRS o GZRS.
Plano de proceso: Si se pierden nodos porque sus máquinas virtuales residen en la zona de disponibilidad afectada, el administrador de clústeres de Azure solicita nodos de reemplazo del proveedor de proceso de Azure. Si las zonas correctas restantes tienen capacidad suficiente para cumplir la solicitud, el proveedor de proceso extrae nodos de las zonas correctas para reemplazar los nodos perdidos. Este proceso puede tardar varios minutos.
Si el nodo del controlador se pierde debido al error de zona, se reinicia todo el clúster, lo que puede provocar tiempos de recuperación más largos en comparación con la pérdida de nodos de trabajo. Planee este comportamiento en las estrategias de programación y supervisión del trabajo.
Puede usar grupos de instancias o sin servidor para reducir este tiempo.
Reenrutamiento del tráfico:
Plano de control: el plano de control de Databricks realiza la conmutación por error automática a zonas correctas en unos 15 minutos.
Raíz de DBFS: Azure Storage redirige automáticamente las solicitudes a los clústeres de almacenamiento en zonas correctas.
Plano de proceso: el administrador de clústeres cambia automáticamente a nodos de zonas correctas.
Recuperación de zona
Cuando la zona de disponibilidad fallida se recupera, Azure Databricks reanuda las operaciones normales automáticamente en todas las zonas. El administrador de clústeres puede reequilibrar la distribución de nodos durante las posteriores creaciones de nodos, pero los nodos existentes continúan ejecutándose en sus zonas actuales hasta que finalizan.
No es necesario realizar ninguna acción para las operaciones de conmutación por recuperación. La distribución de zona normal se reanuda para las nuevas implementaciones de clúster.
Prueba de fallos de zona
Azure Databricks es un servicio administrado en el que Microsoft controla la conmutación por error de zona automáticamente y realiza pruebas periódicas de zona inactiva. No es necesario probar los escenarios de fallo de zona para el servicio en sí.
Para las aplicaciones que se ejecutan en Azure Databricks, pruebe la resistencia del trabajo simulando errores de nodo de controlador y supervisando el comportamiento de reinicio del clúster. Verifique que los trabajos de procesamiento de datos pueden manejar los reinicios del cluster y reanudarse desde los puntos de control adecuados.
Resistencia a errores en toda la región
Azure Databricks es un servicio de una sola región. Si la región no está disponible, el área de trabajo tampoco está disponible. Si necesita implementaciones en varias regiones, consulte Recuperación ante desastres de Azure Databricks.
Soluciones personalizadas de varias regiones para la resistencia
Azure Databricks no proporciona funcionalidades integradas en varias regiones. Para una protección multirregional completa de sus cargas de trabajo analíticas, debe implementar su propio enfoque.
Las soluciones típicas de varias regiones implican dos o más áreas de trabajo. Puede elegir entre varias estrategias, incluidas las arquitecturas activa-pasiva y activa-activa.
Para elegir una arquitectura, tenga en cuenta los siguientes factores:
- La importancia de la carga de trabajo para su empresa
- La posible duración de una interrupción (horas o posiblemente un día completo)
- El esfuerzo necesario para hacer que el área de trabajo esté totalmente operativa
- El esfuerzo necesario para restaurar o recuperar la región primaria
Para ver las cargas de trabajo que requieren protección en varias regiones, consulte Recuperación ante desastres de Azure Databricks.
Copia de seguridad y recuperación
Azure Databricks realiza automáticamente copias de seguridad de bases de datos como parte de las operaciones administradas del servicio. Este proceso incluye contenido de cuadernos, definiciones de trabajos, configuraciones de clúster y configuración de control de acceso.
Nota:
Si se produce un error de zona, Azure Databricks no espera ninguna pérdida de datos.
Se recomienda almacenar los datos en el almacenamiento del catálogo de Unity. Puede replicar datos a través de la replicación de almacenamiento o la clonación diferencial.
Las funcionalidades de copia de seguridad y restauración de nivel de área de trabajo no están disponibles directamente. Planee los procedimientos de recreación del área de trabajo que incluyen la restauración de configuraciones, usuarios y controles de acceso desde los procesos de sincronización.
Resistencia al mantenimiento del servicio
Azure Databricks realiza el mantenimiento automático de la plataforma para aplicar actualizaciones de seguridad, implementar nuevas características y mejorar la confiabilidad del servicio. Puede configurar las ventanas de mantenimiento del clúster para reducir la probabilidad de mantenimiento que afecte a las cargas de trabajo de producción. Para más información, consulte Actualización automática del clúster.
Acuerdo de nivel de servicio
El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.