Compartir a través de

Procedimientos recomendados de Azure Batch

  • Artículo

En este artículo se describen procedimientos recomendados y consejos útiles para usar el servicio Azure Batch de forma eficaz. Estos consejos pueden ayudarle a mejorar el rendimiento y a evitar problemas de diseño en las soluciones de Batch.

Sugerencia

Para obtener instrucciones sobre la seguridad en Azure Batch, consulte Seguridad de Batch y prácticas recomendadas de cumplimiento.

Grupos

Los grupos de Batch son los recursos de proceso para ejecutar trabajos en el servicio de Batch. En las secciones siguientes se proporcionan recomendaciones para trabajar con grupos de Batch.

Configuración y nomenclatura de grupos

  • Modo de asignación de grupo: al crear una cuenta de Batch, puede elegir entre dos modos de asignación de grupo: Servicio de Batch o Suscripción de usuario. En la mayoría de los casos, debe usar el modo predeterminado servicio Batch, en el que los grupos se asignan en segundo plano en las suscripciones administradas por Batch. En el modo de suscripción de usuario alternativo, tanto las máquinas virtuales de Batch como otros recursos se crean directamente en su suscripción cuando se crea un grupo. Las cuentas de suscripción de usuario se utilizan principalmente para habilitar un subconjunto pequeño, pero importante, de escenarios. Para obtener más información, consulte Configuración adicional para el modo de suscripción de usuario.

  • Modo de comunicación de nodo classic o simplified: los grupos también se pueden configurar en uno de los dos modos de comunicación de nodo: clásico o simplificado. En el modelo de comunicación de nodo clásico, el servicio Batch inicia la comunicación con los nodos de proceso, y estos también requieren la comunicación con Azure Storage. En el modelo de comunicación de nodo simplificado, los nodos de proceso inician la comunicación con el servicio Batch. Debido al ámbito reducido de las conexiones entrantes o salientes necesarias y a que no se requiere acceso saliente de Azure Storage para la operación de línea de base, se recomienda usar el modelo de comunicación de nodo simplificado. Algunas mejoras futuras en el servicio Batch también requerirán el modelo de comunicación de nodo simplificado. El modelo de comunicación de nodo clásico se retirará el 31 de marzo de 2026.

  • Consideraciones sobre el tiempo de ejecución de los trabajos y tareas: si tiene trabajos compuestos principalmente de tareas de corta duración y los recuentos totales de tareas previstos son reducidos (de modo que el tiempo de ejecución total esperado del trabajo no es largo), no asigne un nuevo grupo a cada trabajo. El tiempo de asignación de los nodos acortará el tiempo de ejecución del trabajo.

  • Varios nodos de proceso: no se garantiza que los nodos individuales estén siempre disponibles. Aunque no es habitual, los errores de hardware, las actualizaciones del sistema operativo y un sinfín de otros problemas pueden hacer que los nodos individuales estén sin conexión. Si la carga de trabajo de Batch requiere un progreso determinista y garantizado, debe asignar grupos con varios nodos.

  • Imágenes con fechas de fin de ciclo de vida (EOL) inminentes: se recomienda evitar imágenes con fechas de fin de ciclo de vida (EOL) inminentes de soporte técnico de Batch. Estas fechas se pueden detectar con la ListSupportedImages API, PowerShell o la CLI de Azure. Es su responsabilidad actualizar periódicamente la vista de las fechas de fin del ciclo de vida (EOL) correspondientes a los grupos y migrar las cargas de trabajo antes de esas fechas. Si usa una imagen personalizada con un agente de nodo especificado, asegúrese de seguir las fechas de final del ciclo de vida del soporte técnico de Batch de la imagen de la que deriva su imagen personalizada o con la que se alinea. Una imagen sin una fecha de batchSupportEndOfLife especificada indica que el servicio Batch aún no ha determinado esa fecha. La ausencia de fecha no indica que la imagen correspondiente se vaya a admitir indefinidamente. Se puede agregar una fecha EOL o actualizarla más adelante en cualquier momento.

  • SKU de máquina virtual con fechas de fin de vida (EOL) pendientes: al igual que con las imágenes de máquina virtual, las SKU de máquina virtual o las familias también pueden llegar al fin de la vida útil (EOL) de soporte técnico de Batch. Estas fechas se pueden detectar con la ListSupportedVirtualMachineSkus API, PowerShell o la CLI de Azure. Planee la migración de la carga de trabajo a una SKU de máquina virtual que no esté en su EOL mediante la creación de un nuevo grupo con una SKU de máquina virtual compatible adecuada. La ausencia de una fecha de batchSupportEndOfLife asociada para una SKU de máquina virtual no indica que se admitirá indefinidamente una SKU de máquina virtual determinada. Se puede agregar una fecha EOL o actualizarla más adelante en cualquier momento.

  • Nombres únicos de recurso: los recursos de Batch (trabajos, grupos, etc.) suelen ser inestables a lo largo del tiempo. Por ejemplo, puede crear un grupo el lunes, eliminarlo el martes y, después, crear otro grupo similar el jueves. Cada recurso nuevo que cree debe recibir un nombre único que no haya usado antes. Puede crear unicidad utilizando un GUID (como nombre completo del recurso o como parte de él) o insertando en el nombre del recurso la fecha y hora a la que se creó. Batch admite la propiedad DisplayName, que puede dar a un recurso un nombre más legible, incluso si el identificador de recurso real no es descriptivo. El uso de nombres únicos facilita la diferenciación de un recurso determinado en los registros y las métricas. También elimina la ambigüedad si alguna vez tiene que archivar un caso de soporte técnico para un recurso.

  • Continuidad durante el mantenimiento y los errores en el grupo: es mejor que los trabajos usen los grupos dinámicamente. Si los trabajos usan el mismo grupo para todo, existe la posibilidad de que los trabajos no se ejecuten si algo sale mal con el grupo. Este principio es especialmente importante para las cargas de trabajo que dependen del tiempo. Por ejemplo, seleccione o cree un grupo de forma dinámica cuando programe cada trabajo, o tenga una manera de invalidar el nombre del grupo para que pueda omitir un grupo con un estado incorrecto.

  • Continuidad empresarial durante el mantenimiento y los errores del grupo: hay muchas causas posibles por las que puede que un grupo no alcance el tamaño necesario que quiere, como errores internos o restricciones de capacidad. Asegúrese de que puede redirigir los trabajos a otro grupo (posiblemente con un tamaño de máquina virtual diferente usando UpdateJob) si es necesario. Evite confiar en un identificador de grupo estático con la esperanza de que nunca se eliminará ni cambiará.

Seguridad del grupo

Límite de aislamiento

Con respecto al aislamiento, si su escenario requiere aislar los trabajos o tareas entre sí, debe hacerlo colocándolos en grupos independientes. Un grupo es el límite de aislamiento de seguridad en Batch y, de forma predeterminada, dos grupos no son visibles ni pueden comunicarse entre sí. Evite el uso de cuentas de Batch independientes como medio de aislamiento de seguridad a menos que el entorno mayor del que opera la cuenta de Batch requiera aislamiento.

Actualizaciones del agente de nodo de Batch

Los agentes de nodo de Batch no se actualizan automáticamente para los grupos que tienen algún nodo de proceso. Para asegurarse de que los grupos de Batch reciben las últimas correcciones de seguridad y actualizaciones del agente de nodo de Batch, debe cambiar el tamaño del grupo a cero nodos de proceso o volver a crear el grupo. Se recomienda supervisar las notas de la versión del agente de nodo de Batch para conocer los cambios a las nuevas versiones del agente de nodo de Batch. La comprobación periódica de las actualizaciones cuando se publican le permite planear las actualizaciones a la versión más reciente del agente.

Antes de volver a crear o cambiar el tamaño del grupo, debe descargar los registros del agente de nodo con fines de depuración, si tiene problemas con el grupo o los nodos de proceso de Batch. Este proceso se explica con más detalle en la sección Nodos.

Nota

Para obtener instrucciones generales sobre la seguridad en Azure Batch, consulte Seguridad de Batch y prácticas recomendadas de cumplimiento.

Actualizaciones del sistema operativo

Se recomienda que la imagen de máquina virtual seleccionada para un grupo de Batch esté actualizada con las actualizaciones de seguridad proporcionadas por el publicador más reciente. Algunas imágenes pueden realizar actualizaciones automáticas de paquetes durante el arranque (o poco después), lo que puede interferir en determinadas acciones dirigidas por el usuario, como la recuperación de actualizaciones del repositorio de paquetes (por ejemplo, apt update) o la instalación de paquetes durante acciones como StartTask.

Se recomienda habilitar la actualización automática del sistema operativo para grupos de Batch, lo que permite que la infraestructura subyacente de Azure coordine las actualizaciones en todo el grupo. Esta opción se puede configurar para que no interrumpa la ejecución de tareas. La actualización automática del sistema operativo no admite todos los sistemas operativos compatibles con Batch. Para obtener más información, consulte la Matriz de soporte de actualización automática del sistema operativo de Virtual Machine Scale Sets. En el caso de los sistemas operativos Windows, asegúrese de que no está habilitando la propiedad virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates cuando usa la actualización automática del sistema operativo en el grupo de Batch.

Azure Batch no comprueba ni garantiza que las imágenes permitidas para su uso con el servicio tengan las actualizaciones de seguridad más recientes. Las actualizaciones en las imágenes están en el ámbito del publicador de la imagen, y no de Azure Batch. Para determinadas imágenes publicadas en microsoft-azure-batch, no hay ninguna garantía de que estas imágenes estén actualizadas con su imagen derivada ascendente.

Vigencia del grupo y facturación

La vigencia del grupo puede variar en función del método de asignación y de las opciones que se apliquen a la configuración del grupo. Los grupos pueden tener una vigencia arbitraria y un número de nodos de ejecución variable en cualquier momento. Es su responsabilidad administrar los nodos de proceso del grupo, ya sea explícitamente o a través de las características proporcionadas por el servicio (escalado automático o autogrupo).

  • Recreación del grupo: Evite eliminar y volver a crear grupos a diario. En su lugar, cree un nuevo grupo y actualice los trabajos existentes para que apunten al nuevo grupo. Cuando se hayan pasado todas las tareas al nuevo grupo, elimine el grupo anterior.

  • Eficiencia y facturación de los grupos: Batch en sí no genera ningún cargo adicional. Sin embargo, se generan cargos por los recursos de Azure utilizados, como los de proceso, almacenamiento, redes y cualesquiera otros recursos que haya necesitado su carga de trabajo de Batch. Se le facturará por cada nodo de proceso del grupo, independientemente del estado en el que se encuentre. Para más información, consulte Análisis de costos y presupuestos para Azure Batch.

  • Discos de SO efímero: los grupos de configuración de máquina virtual pueden usar discos de SO efímeros, que crean el disco de SO en la caché de la máquina virtual o SSD temporal, para evitar costos adicionales asociados a los discos administrados.

Errores de asignación de grupos

Los errores de asignación de grupos pueden producirse en cualquier momento durante la primera asignación o en los siguientes cambios de tamaño. Estos errores pueden deberse a un agotamiento temporal de la capacidad en una región o a errores en otros servicios de Azure de los que depende Batch. La cuota básica no es una garantía, sino un límite.

Tiempo de inactividad no planeado

Los grupos de Batch pueden experimentar eventos de tiempo de inactividad en Azure. Debe saber que pueden surgir problemas y, por tanto, debe desarrollar el flujo de trabajo para que sea resistente a la repetición de ejecuciones. En caso de que se produzca un error en los nodos, Batch intentará recuperar automáticamente estos nodos de ejecución en su nombre. Esta recuperación puede desencadenar la reprogramación de cualquier tarea que esté en ejecución en el nodo que se restaura o en otro nodo disponible. Consulte Diseño de reintentos para más información sobre las tareas interrumpidas.

Grupos de imágenes personalizados

Al crear un grupo en Azure Batch con Configuración de máquina virtual, se especifica una imagen de máquina virtual (VM) que proporciona el sistema operativo para cada nodo de proceso en el grupo. Puede crear el grupo con una imagen de Azure Marketplace compatible, o bien crear una imagen personalizada con una imagen de Azure Compute Gallery. Aunque también puede usar una imagen administrada para crear un grupo de imágenes personalizadas, se recomienda crear imágenes personalizadas mediante Azure Compute Gallery siempre que sea posible. Azure Compute Gallery ayuda a aprovisionar grupos con más rapidez, a escalar cantidades más grandes de máquinas virtuales y a mejorar la confiabilidad cuando se aprovisionan máquinas virtuales.

Imágenes de terceros

Pueden crearse grupos con imágenes de terceros publicadas en Azure Marketplace. Con cuentas de Batch en modo de suscripción de usuario, puede mostrarse el error "Allocation failed due to marketplace purchase eligibility check" (Error en la asignación debido a la comprobación de la validez de la compra en Marketplace) al crear un grupo con determinadas imágenes de terceros. Para resolver este error, acepte los términos establecidos por el publicador de la imagen. Puede hacerlo con Azure PowerShell o la CLI de Azure.

Grupos de contenedores

Al crear un grupo de Batch con una red virtual, puede haber efectos secundarios de interacción entre la red virtual especificada y el puente Docker predeterminado. Docker, de manera predeterminada, creará un puente de red con una especificación de subred de 172.17.0.0/16. Asegúrese de que no haya intervalos IP en conflicto entre el puente de red de Docker y la red virtual.

Docker Hub limita el número de extracción de imágenes. Asegúrese de que la carga de trabajo no supera los límites de velocidad publicados para imágenes basadas en Docker Hub. Se recomienda usar Azure Container Registry directamente o aprovechar caché de artefactos en ACR.

Dependencia de la región de Azure

No debería depender de una sola región de Azure si tiene una carga de trabajo que depende del tiempo o de la producción. Aunque es poco frecuente, hay problemas que pueden afectar a toda una región. Por ejemplo, si su procesamiento tiene que iniciarse en un momento determinado, considere la posibilidad de escalar verticalmente el grupo de la región principal justo antes de la hora de inicio. Si se produce un error en la escala del grupo, puede revertir la escala de un grupo verticalmente en una región (o regiones) de copia de seguridad.

Los grupos en varias cuentas de distintas regiones proporcionan una copia de seguridad preparada y de fácil acceso si se produce algún problema con otro grupo. Para más información, consulte Diseño de la aplicación para una alta disponibilidad.

Trabajos

Un trabajo es un contenedor diseñado para contener cientos, miles o incluso millones de tareas. Siga estas instrucciones al crear trabajos.

Menos trabajos, más tareas

El uso de un trabajo para ejecutar una única tarea es ineficaz. Por ejemplo, es más eficaz usar un único trabajo que contenga 1000 tareas en lugar de crear 100 trabajos que contengan 10 tareas cada uno. Si usara 1000 trabajos, cada uno con una sola tarea, sería el enfoque menos eficaz, más lento y más costoso.

Evite diseñar una solución de Batch que requiera miles de trabajos activos simultáneamente. No hay ninguna cuota para las tareas, por lo que la ejecución de muchas tareas en el menor número de trabajos posible sería un uso eficiente de las cuotas de trabajos y programación de trabajos.

Vigencia del trabajo

Un trabajo de Batch tiene una vigencia indefinida hasta que se elimine del sistema. Su estado designa si este puede aceptar más tareas para la programación.

Un trabajo no cambia automáticamente al estado completado a menos que se termine explícitamente. Esta acción se puede desencadenar automáticamente con la propiedad onAllTasksComplete o con maxWallClockTime.

Hay una cuota predeterminada de trabajos activos y programaciones de trabajos. Los trabajos y las programaciones de trabajos con el estado completado no cuentan para esta cuota.

Elimine los trabajos cuando ya no sean necesarios, incluso si están en estado completado. Aunque los trabajos completados no cuentan para la cuota de trabajos activos, resulta beneficioso limpiar periódicamente los trabajos completados. Por ejemplo, la enumeración de trabajos será más eficaz cuando el número total de trabajos sea un conjunto más pequeño (incluso si se aplican filtros adecuados a la solicitud).

Tareas

Las tareas son unidades de trabajo individuales que componen un trabajo. El usuario envía las tareas y Batch las programa en nodos de proceso. En las secciones siguientes se proporcionan sugerencias para diseñar las tareas para controlar los problemas y tener un rendimiento eficaz.

Almacenamiento de datos de tareas

Los nodos de proceso son efímeros por naturaleza. Algunas características de Batch, como el grupo automático y la escalabilidad automática, pueden facilitar la desaparición de los nodos. Cuando los nodos dejan un grupo (debido a un cambio de tamaño o una eliminación del grupo), también se eliminan todos los archivos de dichos nodos. Por este motivo, una tarea debe mover su salida del nodo en el que se está ejecutando a un almacén duradero antes de completarse. Del mismo modo, si se produce un error en una tarea, debe trasladar los registros necesarios para diagnosticar el error en un almacén duradero.

Batch tiene compatibilidad integrada con Azure Storage para cargar datos a través de OutputFiles y con varios sistemas de archivos compartidos, o bien puede realizar la carga usted mismo en sus tareas.

Administración de la duración de la tarea

Elimine las tareas cuando ya no sean necesarias o establezca la restricción de tarea retentionTime. Si se establece un retentionTime, Batch limpia automáticamente el espacio en disco que usa la tarea cuando retentionTime expire.

La eliminación de tareas hace dos cosas:

  • Garantiza que no tenga tareas acumuladas en el trabajo. Esta acción le ayudará a evitar dificultades para encontrar la tarea que le interesa, ya que tendrá que filtrar por las tareas completadas.
  • Limpia los datos de la tarea correspondiente en el nodo (siempre que no se haya alcanzado el valor de retentionTime). Esta acción ayuda a garantizar que los nodos no se llenen con los datos de la tarea y se queden sin espacio en disco.

Nota

En el caso de las tareas enviadas a Batch, la llamada a DeleteTask API tarda hasta 10 minutos en surtir efecto. Antes de ello, es posible que se impida que se programen otras tareas. Esto se debe a que Batch Scheduler sigue intentando programar las tareas que acaba de eliminar. Si quiere eliminar una tarea poco después de enviarla, es mejor que finalice la tarea (ya que la solicitud de finalización de la tarea surtirá efecto inmediatamente). A continuación, elimine la tarea 10 minutos más tarde.

Envío de un gran número de tareas en la recopilación

Las tareas se pueden enviar de forma individual o en colecciones. Envíe tareas en colecciones hasta un máximo de 100 a la vez al realizar el envío masivo de tareas para reducir la sobrecarga y el tiempo de envío.

Establecimiento del número máximo de tareas por nodo correctamente

Batch admite tareas de sobresuscripción en nodos (que ejecutan más tareas que núcleos tiene un nodo). Depende de usted asegurarse de que las tareas tengan un tamaño acorde con los nodos del grupo. Por ejemplo, su experiencia podría verse degradada si intenta programar ocho tareas, cada una de las cuales consume un 25 % de uso de CPU en un nodo (en un grupo con taskSlotsPerNode = 8).

Diseño de reintentos y reejecución

Batch puede reintentar automáticamente las tareas. Hay dos tipos de reintentos: controlados por el usuario e internos. Los reintentos controlados por el usuario los especifica el elemento maxTaskRetryCount de la tarea. Cuando un programa especificado en la tarea sale con un código de salida distinto de cero, la tarea se reintenta hasta el valor de maxTaskRetryCount.

Aunque es poco frecuente, se puede reintentar una tarea internamente debido a errores en el nodo de proceso, como no poder actualizar el estado interno o un error en el nodo mientras la tarea se está ejecutando. La tarea se reintentará en el mismo nodo de proceso, si es posible, hasta un límite interno antes de que se desista y se aplace la tarea que Batch va a reprogramar, potencialmente en un nodo de proceso diferente.

No hay ninguna diferencia de diseño al ejecutar las tareas en nodos dedicados o en nodos de acceso puntual. Tanto si una tarea se reemplaza mientras se ejecuta en un nodo de acceso puntual como si se interrumpe debido a un error en un nodo dedicado, ambas situaciones se mitigarían diseñando la tarea para resistir el error.

Creación de tareas durables

Las tareas deben diseñarse para resistir errores y dar cabida al reintento. Este principio es especialmente importante para las tareas de larga duración. Asegúrese de que las tareas generan el mismo resultado único, incluso si se ejecutan más de una vez. Una manera de lograr este resultado es convertir las tareas en "búsqueda de objetivo". Otra manera es asegurarse de que las tareas sean idempotentes (las tareas tendrán el mismo resultado independientemente de cuántas veces se ejecuten).

Un ejemplo común es una tarea de copia archivos en un nodo de proceso. Un enfoque sencillo es una tarea que copia todos los archivos especificados cada vez que se ejecuta, lo que resulta ineficaz y no se ha creado para resistir errores. En su lugar, cree una tarea para asegurarse de que los archivos se encuentran en el nodo de proceso; una tarea que no vuelva a copiar los archivos que ya están presentes. De esta manera, la tarea se retomará en el punto en que se quedó si se interrumpió.

Evitación de un breve tiempo de ejecución

Las tareas que solo se ejecutan durante uno o dos segundos no son ideales. Intente realizar una cantidad significativa de trabajo en una tarea individual (un mínimo de 10 segundos y hasta horas o días). Si cada tarea se está ejecutando durante un minuto (o más), la sobrecarga de programación como una fracción del tiempo de proceso general es pequeña.

Uso del ámbito de grupo para tareas cortas en nodos de Windows

Al programar una tarea en nodos de Batch, puede elegir si desea ejecutarlo con el ámbito de la tarea o con el ámbito del grupo. Si la tarea solo se va a ejecutar durante un breve período de tiempo, su ámbito puede ser ineficaz debido a los recursos necesarios para crear la cuenta de usuario automático para dicha tarea. Si desea mayor eficacia, considere la posibilidad de establecer estas tareas en el ámbito del grupo. Para más información, consulte Ejecución de una tarea como usuario automático con ámbito de grupo.

Nodos

Un nodo de proceso es una máquina virtual de Azure o una máquina virtual de servicio en la nube dedicada al proceso de una parte de la carga de trabajo de la aplicación. Siga estas instrucciones al trabajar con nodos.

Tareas de inicio: duración e idempotencia

Al igual que otras tareas, el nodo tarea de inicio debe ser idempotente. Las tareas de inicio se vuelven a ejecutar cuando se reinician el nodo de ejecución o el agente de Batch. Una tarea idempotente es simplemente una que genera un resultado coherente cuando se ejecuta varias veces.

La ejecución de las tareas de inicio no debe durar mucho tiempo ni deben acoplarse a la duración del nodo de ejecución. Si necesita iniciar programas que son servicios o cuya naturaleza es similar a la de un servicio, cree una tarea de inicio que permita que estos programas se inicien y administren mediante instalaciones del sistema operativo, como systemd en servicios de Linux o Windows. La tarea de inicio todavía debe crearse como idempotente, para que su posterior ejecución se controle correctamente si estos programas se instalaron previamente como servicios.

Sugerencia

Cuando Batch vuelva a ejecutar la tarea de inicio, intentará eliminar el directorio de la tarea de inicio y lo volverá a crear. Si Batch no puede volver a crear el directorio de la tarea de inicio, el nodo de ejecución no podrá iniciar dicha tarea.

Estos servicios no deben bloquear archivos en los directorios administrados por Batch del nodo, ya que, si lo hacen, Batch no podrá eliminar los directorios a causa de los bloqueos. Por ejemplo, en lugar de configurar el inicio del servicio directamente desde el directorio de trabajo de la tarea de inicio, copie los archivos en otra parte de forma idempotente. A continuación, instale el servicio desde esa ubicación mediante las instalaciones del sistema operativo.

Nodos aislados

Considere la posibilidad de usar tamaños de VM aislados para las cargas de trabajo que cuenten con requisitos normativos o de cumplimiento. Los tamaños aislados admitidos en el modo de configuración de máquina virtual incluyen Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5 y Standard_E64i_v3. Para obtener más información sobre los tamaños de VM aislados, consulte Aislamiento de máquinas virtuales en Azure.

Evitación de la creación de uniones de directorio en Windows

Las uniones de directorios, que a veces se denominan vínculos físicos, son difíciles de tratar durante la limpieza de tareas y trabajos. Use vínculos simbólicos (soft-links) en lugar de vínculos físicos.

Discos temporales y AZ_BATCH_NODE_ROOT_DIR

Batch se basa en discos temporales de máquina virtual (en tamaños de máquina virtual compatibles con Batch) para almacenar en ellos metadatos relacionados con la ejecución de tareas junto con los artefactos de cada ejecución de tareas. Algunos ejemplos de estos directorios o puntos de montaje de discos temporales son: /mnt/batch, /mnt/resource/batch y D:\batch\tasks. Estos puntos de montaje y directorios y sus directorios primarios no se pueden reemplazar, volver a montar, unir, usar con vínculos simbólicos ni redirigir de ninguna otra forma. Hacerlo puede producir inestabilidad. Si necesita más espacio en disco, considere la posibilidad de usar un tamaño de máquina virtual o una familia de máquinas que tenga un espacio en disco temporal que satisfaga sus requisitos o conectar discos de datos. Para obtener más información, consulte la siguiente sección sobre cómo conectar y preparar discos de datos para nodos de proceso.

Conectar y preparar los discos de datos

Cada nodo de proceso individual tiene asociada la misma especificación de disco de datos si se especifica como parte de la instancia del grupo de Batch. Solo se pueden conectar nuevos discos de datos a grupos de Batch. Estos discos de datos conectados a los nodos de proceso no se particionan, formatean ni montan automáticamente. Es su responsabilidad realizar estas operaciones como parte de la tarea de inicio. Estas tareas iniciales deben diseñarse para que sean idempotentes. Es posible volver a ejecutar las tareas de inicio en los nodos de ejecución. Si la tarea de inicio no es idempotente, se puede producir una pérdida de datos en los discos de datos.

Sugerencia

Al montar un disco de datos en Linux, si anida el punto de montaje de disco en los puntos de montaje temporales de Azure, como /mnt o /mnt/resource, se debe tener cuidado para que no se introduzcan razas de dependencias. Por ejemplo, si el sistema operativo realiza automáticamente estos montajes, puede haber una carrera entre el disco temporal que se monta y los discos de datos que se montan en el elemento primario. Se deben realizar pasos para asegurarse de que las dependencias adecuadas se aplican mediante instalaciones disponibles, como systemd o aplazar el montaje del disco de datos en la tarea de inicio como parte del script de preparación del disco de datos idempotente.

Preparación de discos de datos en grupos de Batch de Linux

Los discos de datos de Azure en Linux se presentan como dispositivos de bloque y se les asigna un identificador sd[X] típico. No debe basarse en asignaciones de sd[X] estáticas, porque estas etiquetas se asignan dinámicamente en el momento del arranque y no se garantiza que sean coherentes entre el primer arranque y los siguientes. Debe identificar los discos conectados a través de las asignaciones presentadas en /dev/disk/azure/scsi1/. Por ejemplo, si especificó LUN 0 para el disco de datos en la API AddPool, este disco se manifestaría como /dev/disk/azure/scsi1/lun0. Por ejemplo, si enumerase este directorio, podría ver lo siguiente:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

No es necesario volver a traducir la referencia a la asignación de sd[X] en el script de preparación. En su lugar, haga referencia al dispositivo directamente. En este ejemplo, este dispositivo sería /dev/disk/azure/scsi1/lun0. Puede proporcionar este identificador directamente a fdisk, mkfs y cualquier otra herramienta necesaria para el flujo de trabajo. Como alternativa, puede usar lsblk con blkid para asignar el UUID del disco.

Para más información sobre los discos de datos de Azure en Linux, incluidos los métodos alternativos de localización de discos de datos y opciones /etc/fstab, consulte este artículo. Asegúrese de que no haya dependencias o carreras como se describe en la nota de sugerencia antes de promover el método en uso de producción.

Preparación de discos de datos en grupos de Batch de Windows

Los discos de datos de Azure conectados a los nodos de proceso Windows de Batch se presentan sin particiones y sin formato. Debe enumerar los discos con particiones RAW para realizar acciones como parte de la tarea de inicio. Esta información se puede recuperar con el cmdlet Get-Disk de PowerShell. Por ejemplo, podría ver lo siguiente:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Donde el disco número 2 es el disco de datos sin inicializar conectado a este nodo de proceso. Después, estos discos se pueden inicializar, particionar y formatear según sea necesario para el flujo de trabajo.

Para más información sobre los discos de datos de Azure en Windows, incluidos los scripts de PowerShell de ejemplo, consulte este artículo. Asegúrese de que los scripts de ejemplo se validan para la idempotencia antes de la promoción en uso de producción.

Recopilación de registros del agente de Batch

Si observa un problema relacionado con el comportamiento de un nodo o tareas en ejecución en un nodo, recopile los registros del agente de Batch antes de desasignar los nodos en cuestión. Puede recopilar los registros del agente de Batch mediante la API de registros del servicio de Batch de carga. Estos registros se pueden proporcionar como parte de una incidencia de soporte técnico a Microsoft y ayudarán a solucionar los problemas.

Batch API

Errores de tiempo de espera

Los errores de tiempo de espera no indican necesariamente que el servicio no pudo procesar la solicitud. Cuando se produce un error de tiempo de espera, debe reintentar la operación o recuperar el estado del recurso, según proceda para la situación, para comprobar si la operación se realizó correctamente o no.

Conectividad

Revise la siguiente guía relacionada con la conectividad en las soluciones de Batch.

Grupos de seguridad de red (NSG) y Rutas definidas por el usuario (UDR)

Al aprovisionar grupos de Batch en una red virtual, asegúrese de seguir las instrucciones sobre el uso de la etiqueta de servicio BatchNodeManagement.region, los puertos, los protocolos y la dirección de la regla. Se recomienda encarecidamente el uso de la etiqueta de servicio. No utilice las direcciones IP subyacentes del servicio Batch, porque pueden cambiar con el tiempo. El uso directo de las direcciones IP del servicio Batch puede provocar inestabilidad o interrupciones para los grupos de Batch.

En el caso de las rutas definidas por el usuario (UDR), se recomienda usar etiquetas de servicio de región BatchNodeManagement. en lugar de direcciones IP de servicio Batch, ya que pueden cambiar con el tiempo.

Respetar DNS

Asegúrese de que los sistemas respeten el período de vida (TTL) de DNS para la dirección URL del servicio de la cuenta de Batch. Además, asegúrese de que los clientes del servicio Batch y otros mecanismos de conectividad con este servicio no se basan en direcciones IP.

Las solicitudes HTTP con códigos de estado de nivel 5xx junto con un encabezado "Conexión: cerrar" en la respuesta requieren ajustar el comportamiento del cliente del servicio Batch. Su cliente del servicio Batch debe cumplir la recomendación y cerrar la conexión actual, resolver los DNS de la dirección URL de servicio de la cuenta de Batch e intentar seguir las solicitudes en una conexión nueva.

Reintento automático de las solicitudes

Asegúrese de que los clientes del servicio Batch tienen las directivas de reintento adecuadas para volver a intentar automáticamente las solicitudes, incluso durante el funcionamiento normal y no exclusivamente durante períodos de tiempo de mantenimiento del servicio. Estas directivas de reintento deben abarcar un intervalo de al menos 5 minutos. Se proporcionan capacidades de reintento automático con varios SDK de Batch, como la clase RetryPolicyProvider de .NET.

Direcciones IP públicas estáticas

Normalmente, se accede a las máquinas virtuales de un grupo de Batch mediante direcciones IP públicas que pueden cambiar a lo largo de la duración del grupo. Esta naturaleza dinámica puede dificultar la interacción con una base de datos u otro servicio externo que limite el acceso a determinadas direcciones IP. Para solucionarlo, puede crear un grupo que use un conjunto de direcciones IP públicas estáticas que usted controle. Para más información, consulte Creación de un grupo de Azure Batch con direcciones IP públicas especificadas.

Dependencias subyacentes del nodo Batch

Tenga en cuenta las siguientes dependencias y restricciones al diseñar sus soluciones de Batch.

Recursos creados por el sistema

Azure Batch crea y administra un conjunto de usuarios y grupos en la máquina virtual, que no se deben modificar:

Windows:

  • Un usuario llamado PoolNonAdmin
  • Un grupo de usuarios denominado WATaskCommon

Linux:

  • Un usuario llamado _azbatch

Sugerencia

La nomenclatura de estos usuarios o grupos son artefactos de implementación y están sujetos a cambios en cualquier momento.

Limpieza de archivos

Batch intenta limpiar activamente el directorio de trabajo en el que se ejecutan las tareas, una vez que expira el tiempo de retención. Es su responsabilidad limpiar cualquier archivo que se escriba fuera de este directorio para evitar llenar el espacio en disco.

La limpieza automatizada del directorio de trabajo se bloquea si ejecuta un servicio en Windows desde el directorio de trabajo de la tarea de inicio, porque la carpeta todavía está en uso. Esta acción degrada el rendimiento. Para solucionar este problema, cambie el directorio de ese servicio a otro directorio que no esté administrado por Batch.

Pasos siguientes