Tolerancia a errores y migración tras error automática de host de gestión
La arquitectura robusta de LSF se ha diseñado teniendo en cuenta la tolerancia a errores. Cada componente del sistema tiene una operación de recuperación para que los componentes vitales sean supervisados por otro componente y puedan recuperarse automáticamente de una anomalía.
LSF está diseñado para seguir funcionando incluso si algunos de los hosts del clúster no están disponibles. Un host del clúster actúa como host de gestión , pero si el host de gestión deja de estar disponible, otro host de gestión candidato toma el control. LSF está disponible cuando un candidato de host de gestión está disponible en el clúster.
LSF puede tolerar la anomalía de cualquier host o grupo de hosts del clúster. Cuando un host deja de estar disponible, todos los trabajos que se ejecutan en ese host se vuelven a poner en cola o se pierden, en función de si el trabajo se ha marcado como que se puede volver a ejecutar. Ningún otro trabajo pendiente o en ejecución se ve afectado.
Cómo funciona la migración tras error
La tolerancia a errores depende del archivo de registro de sucesos, lsb.events, que se conserva en el servidor de archivos primario. Cada suceso del sistema se registra en este archivo, incluidos todos los envíos de trabajos y los cambios de estado de trabajo y host. Si el host de gestión deja de estar disponible, se elige un nuevo host de gestión en la lista de candidatos de gestión y el daemon sbatchd en el nuevo host de gestión inicia un nuevo daemon mbatchd . El nuevo daemon mbatchd lee el archivo lsb.events para recuperar el estado del sistema.
Registro de eventos duplicados
Para los sitios que no desean basarse únicamente en un servidor de archivos central para la información de recuperación, LSF se puede configurar para mantener un registro de sucesos duplicado manteniendo una réplica del archivo lsb.events . La réplica se almacena en el servidor de archivos y se utiliza si la copia primaria no está disponible. Cuando se habilita el registro de sucesos duplicado, el registro de sucesos primario se almacena localmente en el primer host de gestión y se resincroniza con la copia replicada cuando se recupera el host.
Migración tras error de host
El host de LSF gestión de se elige dinámicamente. Si el host de gestión actual deja de estar disponible, otro host toma el control automáticamente. El host de gestión de migración tras error se selecciona en la lista definida en el parámetro LSF_MASTER_LIST del archivo lsf.conf (especificado en el archivo install.config durante la instalación). El primer host disponible de la lista actúa como host de gestión .
Los trabajos en ejecución están gestionados por el daemon sbatchd en cada host de servidor. Cuando se inicia el nuevo daemon mbatchd , sondea el daemon sbatchd en cada host y encuentra el estado de sus trabajos. Si el daemon sbatchd falla pero el host sigue en ejecución, los jobsque que se están ejecutando en el host no se perderán. Cuando se reinicia el daemon sbatchd , recupera el control de todos los trabajos que se ejecutan en el host.
Migración tras error de trabajos
Los trabajos se pueden enviar como reejecutables, de modo que se vuelvan a ejecutar automáticamente desde el principio o como checkpointable, para que se vuelvan a iniciar desde un punto de comprobación en otro host si se pierden debido a una anomalía de host.
Si todos los hosts de un clúster quedan inactivos, se perderán todos los trabajos en ejecución. Cuando un host candidato de gestión vuelve a estar activo y toma el control como host de gestión , lee el archivo lsb.events para obtener el estado de todos los trabajos por lotes. Se presupone que los trabajos que se estaban ejecutando cuando los sistemas estaban inactivos se han salido a menos que se hayan marcado como reejecutables y se envíe un correo electrónico al usuario que los envía. Los trabajos pendientes permanecen en sus colas y se planifican a medida que los hosts pasan a estar disponibles.
Clúster particionado
Si el clúster está particionado por una anomalía de red, un LIM de host de gestión toma el control en cada lado de la partición mientras que un candidato de host de gestión está disponible en cada lado de la partición. El compartimiento de carga interactivo permanece disponible mientras que cada host sigue teniendo acceso a los archivos ejecutables LSF.
Red particionada
Si la red está particionada, sólo una de las particiones puede acceder al archivo lsb.events , por lo que los servicios de LSF sólo están disponibles en un lado de la partición. Se utiliza un archivo de bloqueo para asegurarse de que sólo se ejecuta un daemon mbatchd en el clúster.
Manejo de excepciones de trabajo
Puede configurar hosts y colas para que LSF detecte condiciones excepcionales mientras se ejecutan los trabajos y emprenda automáticamente la acción adecuada. Puede personalizar qué excepciones se detectan y las acciones correspondientes. Por ejemplo, puede establecer LSF para reiniciar un trabajo automáticamente si sale con un código de error específico.