ES2320601T3 - Metodo para reconstruir el estado de un calculo. - Google Patents

Metodo para reconstruir el estado de un calculo. Download PDF

Info

Publication number
ES2320601T3
ES2320601T3 ES96943730T ES96943730T ES2320601T3 ES 2320601 T3 ES2320601 T3 ES 2320601T3 ES 96943730 T ES96943730 T ES 96943730T ES 96943730 T ES96943730 T ES 96943730T ES 2320601 T3 ES2320601 T3 ES 2320601T3
Authority
ES
Spain
Prior art keywords
execution
phase
application
program
orders
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES96943730T
Other languages
English (en)
Inventor
Craig Stanfill
Cliff Lasser
Robert Lordi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ab Initio Software LLC
Original Assignee
Ab Initio Software LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ab Initio Software LLC filed Critical Ab Initio Software LLC
Application granted granted Critical
Publication of ES2320601T3 publication Critical patent/ES2320601T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1471Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1474Saving, restoring, recovering or retrying in transactions

Abstract

PROCEDIMIENTOS Y SISTEMAS PARA EJECUTAR Y VERIFICAR APLICACIONES EN PARALELO Y DISTRIBUIDAS QUE NO PRECISAN MODIFICAR LOS PROGRAMAS UTILIZADOS EN EL SISTEMA NI EFECTUAR MODIFICACIONES EN EL SISTEMA OPERATIVO UTILIZADO. UNA REALIZACION DE LA INVENCION INCLUYE LAS SIGUIENTES OPERACIONES GENERALES: INICIAR UNA APLICACION EN UN SISTEMA DE PROCESAMIENTO PARALELO (40), CONTROLAR LOS PROCESOS PARA LA APLICACION, QUE INCLUYE REGISTRAR COMANDOS Y RESPUESTAS (41, 42, 43), CONTROLAR UN PROTOCOLO UTILIZADO (44), DETECTAR FALLOS DE LAS APLICACIONES (45, 46) Y CONTINUAR LA EJECUCION DE LA APLICACION A PARTIR DE LA OPERACION MAS RECIENTEMENTE REALIZADA DESPUES DE "REPRODUCIR" LOS COMANDOS Y RESPUESTAS REGISTRADOS (47).

Description

Método para reconstruir el estado de un cálculo.
Antecedentes del invento 1. Campo del invento
Este invento se refiere a sistemas de tratamiento por ordenador y, más particularmente, a métodos y sistemas para reconstruir el estado de un cálculo interrumpido en un entorno de ordenador con tratamiento en paralelo.
2. Descripción de la técnica relacionada
Las velocidades de cálculo de los ordenadores monoprocesador han avanzado en forma muy considerable en las últimas tres décadas. Sin embargo, muchos campos requieren una capacidad de cálculo que supera, incluso, la del ordenador monoprocesador más rápido. Un ejemplo reside en un tratamiento transaccional, en que múltiples usuarios acceden en forma concurrente a los recursos del ordenador y en el que los tiempos de respuesta deben ser bajos para que el sistema sea comercialmente aceptable. Otro ejemplo reside en la minería de bases de datos, en donde deben tratarse centenares de gigabytes de información, y donde el tratamiento de datos en un ordenador en serie podría llevar días o semanas. En consecuencia, se ha desarrollado una variedad de sistemas de "tratamiento en paralelo" para resolver tales problemas. Para los fines de esta exposición, los sistemas de tratamiento en paralelo incluyen cualquier configuración de sistemas de ordenador que utilicen múltiples unidades centrales de tratamiento (CPU), ya sean locales (por ejemplo, sistemas multiprocesador tales como los ordenadores SMP), ya sean localmente distribuidos (por ejemplo, múltiples procesadores acoplados como conglomerados o MPP), o remotos o remotamente distribuidos (por ejemplo, múltiples procesadores acoplados a través de redes LAN o WAN) o cualquier combinación de ellos.
Típicamente, las aplicaciones complejas de tratamiento de datos que se ejecutan en sistemas de tratamiento en paralelo llevan a cabo cambios en múltiples colecciones externas de datos (ficheros, bases de datos, etc.). Tales aplicaciones hacen esto ejecutando uno o más programas de forma concurrente o en secuencia. Si se produce un fallo, pueden haberse introducido cambios en las colecciones externas de datos que hagan que estos no puedan ser utilizados por la aplicación en curso o por otras aplicaciones. En los sistemas de tratamiento en paralelo, el problema se agrava ya que la colección de datos se extenderá, con frecuencia, por muchos nodos y unidades de almacenamiento (por ejemplo, discos magnéticos) diferentes, haciendo que el trabajo requerido para "volver atrás" el estado de los datos se incremente proporcionalmente con el número de unidades de almacenamiento. De manera similar, el número de programas que deben terminarse puede ser elevado.
Para recuperarse de tales fallos, es necesario interrumpir la aplicación en curso (es decir, la que ha fallado) y, luego
(1)
deshacer todos los cambios realizados por las aplicaciones desde el arranque (una "vuelta atrás total"), o
(2)
devolver el estado del sistema a un "punto de control" intermedio y reiniciar la ejecución desde ese punto (una "vuelta atrás parcial").
\vskip1.000000\baselineskip
Las vueltas atrás parciales desde un punto de control (denominadas también "utilización de puntos de control") tienen ventajas con respecto a las vueltas atrás totales, por cuanto se perderá menos trabajo si se produce un fallo, y las vueltas atrás parciales requieren conservar menos información. Sin embargo, la utilización de puntos de control constituye un problema técnico complicado, dado que es difícil (1) capturar el estado de programas en ejecución; (2) volver hacia atrás en forma consistente el estado de todos los ficheros de datos que se modifican; y (3) capturar datos en tránsito entre programas (por ejemplo, datos que están siendo enviados por una red). El problema se complica por el hecho de que, en la mayoría de los casos, los programas de aplicación deben escribirse especialmente para proporcionar el empleo de puntos de control. En general, no es posible modificar programas no diseñados para ello con el fin de añadir llamadas explícitas a un paquete de software de empleo de puntos de control sin llevar a cabo cambios sustanciales en el código fuente del programa. Además, la mayoría de los sistemas operativos no proporcionan medidas para capturar datos en tránsito entre programas.
El documento US 4665520 describe un método para la recuperación de una aplicación que ha fallado en un sistema de tratamiento distribuido utilizando la vuelta atrás mediante puntos de control, en combinación con registro/reproducción de mensajes entre procesos.
El documento US 5440726 describe una recuperación progresiva del proceso en una aplicación de intercambio de mensajes en un sistema de tratamiento en paralelo utilizando creación de puntos de control/vuelta atrás del proceso de la aplicación, junto con registro/reproducción de mensajes.
El documento EP 0578406 describe un método para la recuperación de un programa de aplicación de transacciones distribuidas que utiliza un protocolo de confirmación de transacciones en dos fases mediante el uso de un registro de recuperación de transacciones, que es reproducido cuando se reinicia la aplicación.
En consecuencia existe la necesidad de un método de proporcionar el uso de puntos de control para aplicaciones que no lo hagan específicamente. El presente invento proporciona un método de esta clase que sea particularmente útil para aplicaciones que se ejecutan en sistemas de tratamiento en paralelo y, también, útil para aplicaciones que se ejecuten en sistemas de tratamiento distribuido.
Sumario del invento
El presente invento, que se define con detalle en las reivindicaciones independientes adjuntas, reside en un método y un sistema para ejecutar y almacenar el estado de cálculo en aplicaciones en paralelo y distribuidas, que no exija modificación alguna de los programas utilizados en el sistema ni cambios en el sistema operativo subyacente. El invento
comprende dos realizaciones diferentes. La primera realización preferida comprende los siguientes pasos generales:
(1)
iniciar una aplicación en un sistema de tratamiento en paralelo;
(2)
controlar los procesos para la aplicación, incluyendo el registro de órdenes y respuestas;
(3)
controlar un protocolo de confirmación;
(4)
detectar fallos de la aplicación;
(5)
continuar la ejecución de la aplicación desde la transacción más recientemente confirmada después de "reproducir" las órdenes y las respuestas registradas.
\vskip1.000000\baselineskip
La segunda realización preferida comprende los siguientes pasos generales:
(1)
iniciar una aplicación en un sistema de tratamiento en paralelo;
(2)
controlar los procesos de la aplicación, incluyendo el registro recurrente de la imagen de la memoria de un programa controlador que controla la aplicación;
(3)
controlar un protocolo de confirmación;
(4)
detectar fallos de la aplicación;
(5)
continuar la ejecución de la aplicación a partir de la transacción más recientemente confirmada después de "restaurar" la imagen de la memoria registrada del programa controlador.
\vskip1.000000\baselineskip
Las características principales de la arquitectura del invento son:
(1)
Control central: Las aplicaciones se ejecutan desde un punto central de control. En la realización preferida, un único programa "controlador" con un único hilo de control ilustra y vigila todos los programas y colecciones de datos que constituyen la aplicación.
(2)
Control mediante anfitrión y agentes: Para permitir la distribución del tratamiento entre múltiples nodos, se utiliza un programa denominado "agente" para activar cambios en nodos remotos. En la realización preferida, se forma, en cada nodo, una instancia de un agente separado. El control global del sistema se mantiene mediante un programa "anfitrión", que gestiona las comunicaciones con el programa controlador y los agentes, y mantiene el estado global del sistema.
(3)
Un único canal de órdenes: Se mantiene un "canal de órdenes" entre el programa controlador y el programa anfitrión. En la realización preferida, el programa controlador solamente realiza cambios en el sistema mediante un conjunto de órdenes y contestaciones utilizando el canal de órdenes.
(4)
Registro del tráfico por el canal de órdenes o imagen de la memoria: En la primera realización, todas las órdenes y contestaciones que pasan por el canal de órdenes son registradas por el programa anfitrión y guardadas en un almacenamiento no volátil. En la segunda realización, la imagen de la memoria del programa controlador que controla la aplicación, es grabada concurrentemente por el programa anfitrión y guardada en un almacenamiento no volátil.
(5)
Control basado en las transacciones: En la realización preferida, todas las operaciones realizadas a través del canal de órdenes utilizan un protocolo de confirmación (de preferencia un protocolo de confirmación en dos fases), para garantizar la atomicidad global.
(6)
Recuperación con recapitulación: Utilizando los antes mencionados mecanismos, el invento proporciona la posibilidad de "recuperar" una aplicación que haya fallado, simplemente, volviendo a ponerla en ejecución. Dicho en pocas palabras, el estado de todos los datos es restaurado a través del protocolo de confirmación, luego se utiliza el tráfico registrado en el canal de órdenes para "engañar" al programa controlador haciéndole creer que se está ejecutando de nuevo la aplicación, o se restaura la imagen de la memoria del último estado bueno conocido para el programa controlador. Debido a la naturaleza determinística de los programas de ordenador de hilo único, el programa controlador acabará, necesariamente, como último estado bueno conocido, en el mismo estado que lo hizo la primera vez que se ejecutó el programa.
\vskip1.000000\baselineskip
El principal uso proyectado del invento reside en las aplicaciones tradicionales de tratamiento de datos (por ejemplo, sistemas contables, sistemas de transacciones en tandas, etc.), pero el invento podría aplicarse en casi cualquier aplicación de ordenador que lleve a cabo cambios en ficheros o en bases de datos.
Los detalles de la realización preferida del presente invento se establecen en los dibujos adjuntos y en la descripción que sigue. Una vez se conozcan los detalles del invento, a un experto en la técnica le resultarán evidentes numerosos cambios e innovaciones adicionales.
Breve descripción de los dibujos
La figura 1 es un diagrama de bloques que muestra los componentes de software y el flujo de control de un sistema de creación de puntos de control de acuerdo con el presente invento.
La figura 2a es un diagrama de bloques que muestra la ejecución normal de un programa dotado de puntos de control de acuerdo con el presente invento.
La figura 2b es un diagrama de bloques que muestra un fallo durante la ejecución del programa con puntos de control de la figura 2a.
La figura 2c es un diagrama de bloques que muestra la recuperación del fallo de la figura 2b.
La figura 3 es un diagrama de bloques que muestra los componentes de software y el flujo de control de un sistema de creación de puntos de control durante la recuperación de un fallo de acuerdo con el presente invento.
La figura 4 es una gráfica de control que muestra en forma resumida las operaciones funcionales básicas de la realización de recapitulación del presente invento.
La figura 5 es una gráfica de flujo que muestra, en forma resumida, las operaciones funcionales básicas de la realización de restauración del presente invento.
Designaciones y números de referencia similares indican elementos similares en las distintas figuras.
Descripción detallada del invento
En toda esta descripción, los ejemplos y la realización preferida ilustrados deben considerarse como ilustrativos y no como limitaciones del presente invento.
Visión general
La figura 1 es un diagrama de bloques que muestra los componentes de software y el flujo de control del sistema para guardar periódicamente el estado de ejecución del programa, de acuerdo con el presente invento. Un sistema anfitrión 10 incluye un programa anfitrión 12, un programa controlador 14 y un sistema 16 de almacenamiento de datos para registrar órdenes y contestaciones. El programa anfitrión 12 y el programa controlador 14 están acoplados mediante un canal de órdenes 18 (que, por ejemplo, puede ser un canal lógico de una línea de transmisión física). En la realización preferida, el programa anfitrión 12 es, realmente, un objeto contenido en el espacio de direcciones del programa controlador 14. En su lugar podría incorporarse un proceso separado que ejecutase el programa anfitrión. Sin embargo, la división en "programa anfitrión" y "programa controlador" es una forma conveniente de describir la arquitectura del presente invento.
El sistema anfitrión 10 está acoplado a, por lo menos, un sistema remoto 20 por medio de un canal 22 de comunicaciones de agente (que, por ejemplo, puede ser un canal lógico en un enlace de datos físico 22 usual). Dentro de cada sistema remoto 20 hay un agente 24 que está acoplado al almacenamiento de datos remoto 26.
Todos los componentes ilustrados en la figura 1 están activos durante una ejecución normal. El programa controlador 14 emite órdenes al programa anfitrión 12 para efectuar operaciones en aplicaciones en varios sistemas remotos 20. El programa anfitrión 12 responde a tales órdenes emitiendo órdenes para que uno o más agentes 24 realicen las operaciones requeridas. Los agentes 24 contestan al programa anfitrión 12 cuando se completan las operaciones, y el programa anfitrión 12 contesta, a su vez, al programa controlador 14. Todas las órdenes y contestaciones intercambiadas entre el programa controlador 14 y el programa anfitrión 12 son registradas en el sistema 16 de almacenamiento de datos.
La figura 2a ilustra la ejecución normal de un programa en un sistema dotado de puntos de control, para guardar periódicamente el estado de ejecución, de acuerdo con el presente invento. En el ejemplo mostrado, la aplicación se ejecuta en tres fases, comenzando en un estado inicial 0, continuando en la fase 0 hasta un estado de punto de control 1, siguiendo luego por la fase 2 hasta un estado de punto de control 2 y, luego, por la fase 3 hasta un estado final.
La figura 2b es un diagrama de bloques que muestra un fallo durante la ejecución del programa con puntos de control de la figura 2a. Un fallo puede producirse si, por ejemplo, uno de los nodos "cae" y ha de volverse a poner en marcha de nuevo. En el ejemplo ilustrado, algo después de haberse alcanzado el estado del punto de control 1, se produce un fallo. La ejecución se detiene en mitad de la fase 1, dejando el estado externo de los sistemas de tratamiento en paralelo en un estado de fallo indeseable.
La figura 2c es un diagrama de bloques que muestra la recuperación del fallo ilustrado en la figura 2b gracias al uso del presente invento. Cuando la aplicación se recupera volviendo a ejecutarla de nuevo, se vuelven atrás las operaciones realizadas en la fase 1 que ha fallado, devolviendo el estado externo del sistema de tratamiento al estado que existía en el estado del punto de control 1. Luego, se "restauran" o se "recapitulan" todas las fases terminadas (en este ejemplo, la fase 0). En la recapitulación, el programa controlador 14 parte de nuevo de su estado inicial y funciona normalmente. Sin embargo, no se producen cambios del estado externo hasta que el programa 14 llega al mismo estado que existía en el estado del punto de control 1. En la restauración, se restaura la imagen guardada del programa controlador 14 y, luego, empieza a funcionar normalmente desde ese punto. Después de ello, se ejecutan normalmente la fase que ha fallado (la fase 1 en este ejemplo) y todas las fases subsiguientes, llevando la aplicación a través del estado del punto de control 2 y, de allí, al estado final.
La figura 3 es un diagrama de bloques que muestra la arquitectura de un sistema con puntos de control de acuerdo con el presente invento, durante una recapitulación. Durante el modo de recapitulación, el programa controlador 14 parte del estado inicial. Cada orden procedente el programa controlador 14 es emitida de nuevo al programa anfitrión 12, que compara esa orden con las órdenes y contestaciones registradas, previamente almacenadas en el sistema 16 de almacenamiento de datos. En tanto la secuencia de órdenes procedentes del programa controlador 14 coincidan con las órdenes registradas, las contestaciones registradas correspondientes pueden ser alimentadas de nuevo por el programa anfitrión 12 al programa controlador 14, "engañando", en efecto, al programa controlador 14 que piensa que las fases que están siendo recapituladas, se están ejecutando, de hecho, normalmente. Sin embargo, no se está transformando, moviendo, etc., dato alguno. Así, el paso de recapitulación se ejecuta de forma extremadamente rápida, hasta que el programa controlador 14 alcanza el estado del último punto de control bueno conocido. En ese punto, el programa controlador 12 sale del modo de recapitulación y retoma el modo de funcionamiento normal, proporcionando órdenes desde el programa controlador 14 a los agentes 24 de los sistemas remotos 20, en forma normal.
El invento puede llevarse a la práctica mediante hardware o mediante software, o mediante una combinación de ambos. Sin embargo, de preferencia, el invento se pone en práctica en programas de ordenador que se ejecutan en ordenadores programables que comprenden, cada uno, un procesador, un sistema de almacenamiento de datos (que incluye elementos de almacenamiento y/o de memoria volátil y no volátil), al menos un dispositivo de entrada y, al menos un dispositivo de salida. Se aplica código de programa a los datos de entrada para realizar las funciones descritas en este documento y generar información de salida. La información de salida se aplica, en forma conocida, a uno o más dispositivos de salida.
Cada programa se escribe, preferiblemente, en un lenguaje de programación orientado a objetos o de elevado nivel procedimental para comunicar con un sistema de ordenador. Sin embargo, los programas pueden escribirse, si se desea, en lenguaje de máquina o ensamblador. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado.
Cada uno de tales programas de ordenador se almacena, de preferencia, en un medio o dispositivo de almacenamiento (por ejemplo, una ROM o un disquete magnético) que pueda ser leído por un ordenador programable para fines generales o especiales, para configurar y hacer funcionar el ordenador cuando el medio o dispositivo de almacenamiento sea leído por el ordenador para llevar a cabo los procedimientos descritos en este documento. También puede considerarse llevar a la práctica el sistema del invento como medio de almacenamiento legible por un ordenador, configurado con un programa de ordenador, cuyo medio de almacenamiento así configurado haga que un ordenador funcione de forma específica y predefinida para ejecutar las funciones descritas en este documento.
\vskip1.000000\baselineskip
El programa controlador
El invento hace uso de un programa controlador 14 que proporciona funciones de supervisión para establecer y controlar la ejecución de uno o más programas existentes sin puntos de control. Si se desea, pueden incluirse funciones adicionales. En la realización preferida, el programa controlador 14 realiza, por lo menos, las funciones definidas en lo que sigue:
(a)
Iniciar tarea. Cuando arranca el programa controlador 14, solicita que el sistema anfitrión 10 cree una instancia del programa anfitrión 12. El sistema anfitrión 10 responde proporcionando al programa controlador 14 un identificador o puntero hacia un canal 18 de órdenes para comunicación con el programa anfitrión 12 y el sistema 16 de almacenamiento de datos. El programa controlador 14 se conecta con el programa anfitrión 12 por el canal 18 de órdenes y emite una orden de "iniciar tarea" para el programa anfitrión 12. Esta orden incluye el nombre de un "fichero de recuperación" que ha de ser establecido por el sistema anfitrión 10 en el sistema 16 de almacenamiento de datos. (En algunas ejecuciones prácticas, la "conexión" puede requerir que se inicie un proceso separado; en otras ejecuciones prácticas, la "conexión" únicamente requiere que se inicialicen algunas estructuras de datos internas. En cualquier caso, la primera acción es, siempre, iniciar una tarea como se ha descrito).
(b)
Órdenes: El canal de órdenes 18 acepta, al menos, las siguientes órdenes del programa controlador 14:
(1)
Llamar a procedimiento remoto: Esta llamada hace que un agente remoto 24 ejecute una orden. La orden de llamar a procedimiento remoto (RPC) especifica el nodo en el que ha de ejecutarse la orden. Si en ese nodo no hay ningún agente que se esté ejecutando en ese momento, el programa anfitrión 12 pone en marcha un agente remoto 24 en dicho nodo.
(2)
Iniciar proceso: Esta orden hace que un agente 24 inicie un proceso. De nuevo, la orden especifica el nodo en el que ha de ejecutarse el proceso. Si en ese nodo, en ese momento, no se está ejecutando ningún agente, el programa anfitrión 12 pone en marcha un agente remoto 24 en dicho nodo.
(3)
Esperar. Esta orden hace que se suspenda la ejecución de una función del programa controlador 14 hasta que todos los procesos hayan finalizado su ejecución.
(4)
Preparar; Confirmar; Volver atrás. Estas tres órdenes tienen su significado usual en la técnica anterior en lo que respecta a un protocolo usual de tratamiento de transacciones con confirmación en dos fases.
(c)
Recepción de contestaciones. Cada orden tiene como consecuencia exactamente un mensaje de contestación. Las órdenes y las contestaciones pueden entremezclarse arbitrariamente (por ejemplo, pueden emitirse varias órdenes antes de que retornen las contestaciones correspondientes). El programa controlador 14 acepta, al menos, las siguientes contestaciones del programa anfitrión 12:
(1)
Contestación a la llamada a procedimiento remoto: El contenido de este mensaje es específico para el procedimiento que se invocó mediante una orden de RPC.
(2)
ID de proceso: Cuando se inicia un proceso en un sistema (anfitrión 10 o remoto 20), el sistema contesta con un identificador para ese proceso.
(3)
Estado de espera: Una indicación sobre si los diversos procesos terminaron con éxito.
(4)
Estado de Preparar/Confirmar/Volver atrás. Un indicador de un suceso o un estado de fallo.
(d)
Abortar: Esta orden significa que ha de detenerse la ejecución. El programa anfitrión 12 intentará llevar a cabo una vuelta atrás (que puede fallar si, por ejemplo, uno de los nodos involucrados en el cálculo, ha "caído"). Ya tenga éxito o no la vuelta atrás, el canal de órdenes 18 es, típicamente, destruido. Una orden de abortar puede emitirse manualmente mediante el programa controlador 14 si, por ejemplo, el programa controlador 14 detecta un fallo en tiempo de ejecución. También puede emitirse implícitamente una orden de abortar si falla el programa controlador 14.
(e)
Terminar tarea. Esta orden significa que no ha de realizarse más trabajo, Típicamente, se destruye el canal de órdenes 18 y todos los cambios realizados por la aplicación se convierten en irrevocables.
(f)
Órdenes adicionales. Pueden añadirse, según se desee, órdenes adicionales, pero carecen de importancia para los fines de esta exposición.
\vskip1.000000\baselineskip
Es importante que el programa controlador 14 divide la ejecución de una aplicación en una serie de "fases", de tal forma que, entre fases, es necesario que todos los procesos estén inactivos (por ejemplo, terminen o lleguen a un estado de espera sin que haya transferencias de datos pendientes). Una fase consiste en los siguientes pasos:
(1)
El programa controlador 14 emite una serie de RPC (por ejemplo, para establecer ficheros de datos, etc.) que serán necesarios para uno o más programas de aplicaciones.
(2)
Opcionalmente, el programa controlador 14 emite una serie de órdenes de inicio de proceso.
(3)
Si se ha iniciado cualquier proceso, entonces, tras haberse puesto en marcha un número deseado de los mismos, el programa controlador 14 emite una orden de esperar y suspende el funcionamiento hasta que termina la espera, dando tiempo, así, a que se completen los procesos. En general, todos los procesos que tengan que llevar a cabo una comunicación cruzada con otros procesos, deben finalizarse de manera concurrente.
(4)
Si se desea, la secuencia de pasos (1)-(3) puede repetirse varias veces.
(5)
El programa controlador 14 emite órdenes de preparar y confirmar, haciendo que la transacción en curso sea confirmada y que cualesquiera cambios realizados durante la transacción en curso, resulten permanentes.
(6)
Siguen otras fases de ejecución.
\vskip1.000000\baselineskip
Un paso clave consiste en emitir la orden de esperar sobre una base recurrente, ya que una vez terminada esta orden, se garantiza que en el sistema no existen programas de aplicación activos y que no hay datos en tránsito en los canales de comunicaciones. Esta característica permite que el invento soslaye las dificultades inherentes a la captura de estado de programas en ejecución y a la captura de datos en tránsito en los canales de comunicaciones.
Una consecuencia de este diseño es que pueden no crearse puntos de control mientras los programas están en ejecución. Si uno de los programas se ejecuta durante varias horas, entonces habrá, necesariamente, un período de varias horas en el que no será posible crear un punto de control. Es responsabilidad del programa de control 14, que con frecuencia habrá sido escrito por un usuario de este sistema, garantizar que el tiempo de ejecución de cualquier fase no es excesivo.
En la técnica anterior se cuenta con dos técnicas que pueden utilizarse para reducir la duración de las fases. La primera de ellas consiste en reducir el uso de "encauzamiento" entre etapas sucesivas de un tratamiento dentro de una fase. Específicamente, una práctica común es constituir aplicaciones a partir de programas componentes enlazándolos a través de canales de comunicaciones, técnica denominada "encauzamiento". Ambos programas componentes se ejecutarían, necesariamente, en la misma fase. Si a consecuencia de esto se tuviese una fase demasiado larga, entonces el que escriba el controlador podría sustituir los canales de comunicaciones por ficheros temporales y ejecutar cada programa componente en una fase de ejecución separada. La segunda técnica consiste en dividir los datos más finamente. Por ejemplo, en vez de tratar un único fichero con 10 gigabytes, podría dividírsele en 10 subficheros de 1 gigabyte cada uno y tratar cada subfichero en una sola fase de ejecución. Debido al hecho de que los tiempos de ejecución de la mayor parte de las aplicaciones son aproximadamente proporcionales a las longitudes de sus ficheros de entrada, este método podría conseguir, por ejemplo, una reducción de 10 veces en la duración de las fases, mejorando notablemente la frecuencia con que pueden crearse puntos de control. (En la técnica anterior, esta subdivisión adicional se ha realizado sobre una base ad-hoc y ha exigido, generalmente, la modificación de los programas y, quizás, que haya de escribirse software adicional. Se hace referencia a la solicitud de patente, también en tramitación, titulada "Sistema de sobredivisión y método de incrementar los puntos de control en aplicaciones en paralelo basadas en componentes", cedida al cesionario del presente invento, en la que se explican algunos métodos generales mediante los cuales puede conseguirse esta subdivisión sin modificación de los programas originales).
\vskip1.000000\baselineskip
Bases de datos de estado (SDB)
El sistema anfitrión 10 crea una base de datos de estado para sí mismo (la "SDB del anfitrión"). Cada agente 24 crea, también, su propia base de datos de estado (las "SDB del agente"). La SDB del anfitrión se utiliza para registrar tráfico por el canal de órdenes cuando se utiliza la realización de recapitulación del presente invento, para registrar qué fase está siendo ejecutada, y para registrar información necesaria para el tratamiento de confirmación de transacciones. Las SDB de agente se utilizan para registrar información para tratamiento de recuperación y tratamiento de confirmación de transacciones. En la realización preferida, una SDB solamente existe en memoria durante la vida del programa que accede a ella. Sin embargo, todos los cambios a la SDB son registrados en secuencia en un fichero diario ordenado (un "registro") en un almacenamiento no volátil, tal como el sistema 16 de almacenamiento de datos. En cualquier momento, una SDB puede ser reconstruida en memoria a partir del registro correspondiente. En la realización preferida, el registro es el único almacenamiento persistente asociado con una SDB. La reconstrucción de una SDB se lleva a cabo empezando con una base de datos vacía y leyendo del registro una serie de cambios en la base de datos, y reflejando los cambios en el contenido de la base de datos en memoria.
En la realización preferida, todas las entradas a una SDB adoptan la forma de un par de cadenas de texto: una clave y un valor. Cuando se registra una entrada ("Put" = "Poner"), el programa que llama suministra una entrada de clave/valor que se almacena en la base de datos. Si existe, antes de la operación Put, una entrada con una clave idéntica, es reemplazada. Cuando se lee una entrada ("Get" = "Tomar"), el programa que llama suministra una clave y, si existe una entrada que tenga esa clave, se devuelve su cadena de valor. Además, en la realización preferida, la interconexión de la SDB permite la creación de listas, que son secuencias de entradas a las que se puede acceder en secuencia en vez de mediante una clave. Las entradas Lista son valores de cadena normales.
Un usuario "abre" una SDB aportando el nombre de un fichero de registro. Si el fichero de registro existe, es leído y se reconstruye la correspondiente SDB a partir de su contenido. Si no existe el fichero de registro, se le crea y se crea una SDB en memoria como estructura de datos vacía. La SDB queda entonces disponible para realizar operaciones Put y Get hasta que se la cierra. El cierre de una base de datos se efectúa explícitamente empleando una operación Close (Cerrar) o, implícitamente, si deja de existir el programa que accede.
\newpage
En la realización preferida, todas las operaciones sobre una SDB se agrupan en "transacciones". Cualquier Put o Get iniciará una nueva transacción si no hay una ya en progreso. Una transacción continúa a través de subsiguientes instrucciones de Put y de Get hasta que:
(1)
se realiza una operación de confirmación sobre la SDB.
(2)
Se realiza una operación de restauración de la SDB, que cancela los efectos de toda la transacción sobre la SDB.
(3)
Se cierra la SDB, lo que, implícitamente, devuelve cualesquiera transacciones activas al último estado bueno conocido.
En la realización preferida, las transacciones sobre una SDB no forman parte de la arquitectura de confirmación global y tienen una granularidad mucho más fina.
\vskip1.000000\baselineskip
El programa anfitrión
Cuando el programa controlador 14 inicia una tarea, el sistema anfitrión 10 crea un canal de órdenes 18 para permitir la comunicación entre el programa controlador 14 y un programa anfitrión 12. El programa anfitrión 12 trata los datos en el extremo del sistema anfitrión 10 del canal de órdenes 18. Existe un programa anfitrión para cada aplicación. El programa anfitrión 12 funciona como sigue:
(a)
Inicio de tarea. En la realización preferida, las siguientes funciones son realizadas por el programa anfitrión 12 al comienzo de una aplicación:
(1)
ID de la tarea. El programa anfitrión 12 crea un identificador único denominado "ID de la tarea" empleando la dirección de Internet del sistema en el que se ejecuta el programa anfitrión 12, una marca de tiempo y la ID del proceso del programa anfitrión 12.
(2)
SBD del anfitrión. El programa anfitrión 12 crea la SDB del anfitrión, utilizando la ID de la tarea como identificador. En la realización preferida, la ID de la tarea se almacena en la SDB del anfitrión.
(3)
Fichero de recuperación. El programa anfitrión 12 también graba un fichero denominado "fichero de recuperación" para el sistema 16 de almacenamiento de datos al comienzo de su ejecución. Este fichero también contiene la ID de la tarea, que puede utilizarse para abrir la SDB del anfitrión.
(b)
Agentes y nodos remotos. El programa anfitrión 12 inicia procesos y trabaja sobre ficheros/bases de datos a través de uno o más agentes 24. Cada agente 24 establece una conexión bidireccional (un canal 22 de órdenes de agente) con el programa anfitrión 12, para transmitir órdenes al agente 24 y recibir contestaciones del agente 24. Un agente 24 es iniciado en cada sistema remoto 20 donde se ejecutarán programas de aplicación o donde están situados ficheros u otras colecciones de datos. En la realización preferida, los agentes 24 son iniciados sobre una base de acuerdo con las necesidades, en lugar de todos a una al comienzo de una aplicación.
(c)
Ejecución de fases. El programa anfitrión 12 utiliza agentes 24 para llevar a la práctica la división de la ejecución de una aplicación sin puntos de control en fases, con dirección del programa controlador 14. El programa anfitrión 12 es responsable de los mecanismos transaccionales que ejecutan esta división y realiza ciertas funciones de coordinación y de contabilidad, como se describe en lo que sigue.
\quad
En la realización preferida, las fases se numeran partiendo de cero. Una fase está, siempre, en uno de cuatro "estados": RUNNING (EJECUCIÓN), ERROR, PREPARED (PREPARADA) o COMMITTING (CONFIRMANDO). Cuando se inicia una nueva fase, se encuentra en estado de RUNNING. Continúa en el estado RUNNING en tanto se realicen operaciones remotas durante la fase.
\quad
El número de fases en curso y su estado se registran en la SDB del anfitrión. Esta información es registrada en cada transición de estado. En cualquier momento durante la fase, el programa controlador 14 puede invocar la función de vuelta atrás. Esta función hace que se anulen los efectos de todas las operaciones realizadas hasta entonces durante una fase en curso, devolviendo todo estado cambiado al que existía al inicio de la fase y poniendo la fase en el estado de RUNNING.
\quad
Durante cada fase, mientras se encuentra en el estado de RUNNING, el programa controlador 14 puede emitir órdenes de iniciar procesos y para llamar a procedimientos remotos (RPC) hacia el programa anfitrión 12. El programa anfitrión 12 envía estas órdenes al agente 24 apropiado, recoge las contestaciones de cada agente 24 y las envía al programa controlador 14. En la realización de recapitulación del presente invento, todas estas órdenes y las réplicas correspondientes son registradas en la SDB del anfitrión. Esta información es utilizada para el "modo de recapitulación" descrito más abajo.
\quad
Una vez se ha salido de todos los procesos iniciados por el programa controlador 14, éste puede invocar la función Preparar, poniendo la fase corriente de una aplicación en el estado PREPARED. A continuación de esto, el programa controlador 14 puede invocar la función Confirmar, lo que hace que todos los efectos de todas las operaciones realizadas durante la fase se produzcan completa, correcta e irrevocablemente, finalizando así la fase. También puede llamarse a la función de Vuelta atrás en el estado PREPARED, con el mismo efecto que si la llamada se realizase antes de la función Prepare.
\quad
La realización preferida del presente invento hace uso de un protocolo usual de confirmación de dos fases. En la realización de recapitulación preferida, el protocolo de confirmación en dos fases, es como sigue:
(1)
Preparar. La orden preparar es ejecutada por el programa anfitrión 12:
1)
Almacenando los datos del canal de órdenes registrados desde la fase corriente en la SDB del anfitrión, empleando una clave que contiene el número de la fase en curso. Si existiese ya dicha información (por ejemplo, debido a una ejecución previa de la misma fase que falló durante el proceso de confirmación), será borrada por la nueva información.
2)
Enviando una orden Preparar desde el programa anfitrión 12 a cada agente 24 que ejecutaba órdenes durante la fase. Cada agente 24, de acuerdo con el protocolo usual de confirmación en dos fases, entra en un estado PREPARED de tal modo que, en cualquier momento subsiguiente, puede ejecutar una orden de Volver atrás que devolverá el estado de todos los recursos bajo control del agente 24, o una orden Confirmar que hará que todos los cambios de todos los recursos bajo control del agente 24, se conviertan en permanentes. Este estado PREPARED debe ser duradero, es decir, debe ser posible reconstruir el estado preparado tras un fallo del sistema y, luego, ejecutar una operación de Volver atrás o de Confirmar. Cuando se ha conseguido el estado PREPARED, cada agente 24 señalará este hecho respondiendo a la orden Preparar.
3)
Esperando que todos los agentes 24 indiquen que se ha completado satisfactoriamente la orden Preparar.
4)
Fijar el estado del programa anfitrión 12 en PREPARED, y tomar nota de ese cambio en la SDB del anfitrión.
(2)
Confirmar. La orden Confirmar se lleva a cabo:
1)
Estableciendo el estado del programa anfitrión 12 en COMMITING, y tomar nota de ese cambio en la SDB del anfitrión.
2)
Enviando una orden Confirmar a cada agente 24 que ejecute órdenes durante la fase. Entonces, cada agente 24 hará que todos los cambios en todos los recursos que controla, se conviertan en permanentes, borrando posiblemente información que pudiera haberse requerido en el caso de una vuelta atrás. Cuando dicho tratamiento haya terminado, señalará este hecho respondiendo a la orden Confirmar.
3)
Esperando que todos los agentes 24 indiquen la terminación, con éxito, de la orden Confirmar.
4)
Estableciendo el estado del programa anfitrión 12 en RUNNING, incrementando el número de fase y tomando nota de estos cambios en la SDB de anfitrión.
\quad
Durante el estado PREPARED o RUNNING, si una condición de error es detectada por el sistema operativo o por la aplicación, se hará que la fase pase al estado ERROR. En la realización preferida, mientras se encuentra en este estado, no puede realizarse operación remota alguna, ni puede cambiarse el estado de la fase, ni puede iniciarse una nueva fase. En la realización preferida, las únicas acciones legales en este punto son:
(1)
Depuración: El programa controlador 14 puede, en forma conocida, utilizar algunas órdenes informativas para depurar la aplicación y/o recopilar información de diagnóstico.
(2)
Salida: Cuando sale el programa controlador 14, el programa anfitrión 12 puede intentar la emisión de una orden Volver atrás en nombre del programa controlador 14.
(3)
Volver atrás: El programa controlador 14 puede emitir una orden Volver atrás, que pondrá al sistema en su estado de inicio de la fase en curso, deshaciendo cualesquiera cambios en ficheros/bases de datos, como se ha descrito en lo que antecede.
\newpage
\quad
En resumen, los cambios de estado legales para el programa anfitrión 12 son los siguientes:
(1)
Estado inicial: RUNNING
(2)
En cualquier estado que no se COMMITTING, una condición de error provoca una transición al estado ERROR. De este estado se puede salir mediante una orden Restaurar, que pondrá al sistema en el estado RUNNING, o si se sale del programa controlador 14.
(3)
En el estado RUNNING, una operación Preparar da lugar a una transición al estado PREPARED. Durante los estados RUNNING o PREPARED, una operación de Vuelta atrás hace que se deshaga la fase, en cuyo caso el número de fase no varía y el sistema realiza, de vuelta, una transición al estado RUNNING.
(4)
En el estado PREPARED, una operación Confirmar provoca una transición al estado COMMITTING. Este estado se mantiene mientras dura la operación de Confirmar, luego hace avanzar al número de fase, da por terminada la fase en curso e inicia una nueva fase en el estado RUNNING. Una vez la SDB del anfitrión registra la transición al estado COMMITTING, la detección de un error hará que el sistema aborte. Al volver a ponerse en marcha el sistema, se completará la operación COMMITTING. No es posible una vuelta atrás mientras se está en el estado COMMITING.
\quad
Tras completarse (confirmarse) todas las fases de la aplicación, el programa controlador 14 emite una orden Cerrar, que indica que la aplicación se ha completado con éxito. Esta operación borra el fichero de recuperación y la SDB del anfitrión.
\quad
En la realización de restauración del presente invento, el procedimiento es similar, pero con varias excepciones. En primer lugar, las órdenes y las contestaciones no se almacenan en la SDB del anfitrión. En lugar de ello, después de ser emitida la orden Preparar por el programa controlador 14 y de ser ejecutada por el programa anfitrión 12 y los agentes 24, se almacena, en forma conocida, un fichero de imagen de memoria del programa controlador 14, de preferencia en un almacenamiento no volátil tal como una unidad de disco. La imagen de memoria comprende todo el espacio de direcciones (incluyendo ficheros de intercambio, etc.) para el programa controlador 14 o solamente las estructuras de datos críticas del programa controlador 14 (según lo determinado por un programador para una ejecución práctica particular del programa controlador 14), necesarias para recrear un estado guardado para el programa controlador 14. Una vez confirmada la grabación del fichero de imagen de memoria (por ejemplo, comparando la imagen del programa todavía en memoria con el fichero de imagen almacenado), y después de que el sistema entra en el estado Preparado, el programa controlador 14 emite la orden Confirmar y el programa anfitrión 12 y los agentes 24 la ejecutan, como en lo que antecede. En la realización preferida, se graba y se confirma un siguiente fichero de imagen de memoria antes de borrarse un fichero de imagen de memoria previo (es decir, se mantienen copias "A" y "B", en forma conocida). Un fichero de imagen de memoria previo solamente debe suprimirse tras haberse completado una operación Confirmar.
(d)
Recuperación: Se considera que cualquier aplicación que termine sin haberse ejecutado la operación Cerrar, ha fallado. Cuando se vuelve a poner en marcha la aplicación, se dispara una recuperación. En la realización preferida, siempre que se inicie un programa 12, se comprueba la existencia de un fichero de recuperación. En la realización preferida, si existe el fichero, el programa anfitrión 12 supone que ha ocurrido un fallo anterior y que el intento es para volver a poner en ejecución la tarea anterior.
\quad
El primer paso en la recuperación es restaurar todos los ficheros y las bases de datos a su estado más recientemente confirmado. Si la SDB del anfitrión indica un estado de RUNNING, ERROR o PREPARED, entonces el programa anfitrión 12 emite una orden de Vuelta atrás, haciendo, en forma conocida, que se deshagan todas las operaciones sin confirmar. Si la SDB del anfitrión indica un estado RUNNING, el programa anfitrión 12 vuelve a emitir la orden Confirmar, completando la que, evidentemente, fue una operación de Confirmar interrumpida.
\quad
En la realización de recapitulación del presente invento, el programa anfitrión 12 entra, entonces, en el modo de recapitulación. Como se ha hecho notar en lo que antecede, el programa controlador 14 interacciona con el resto del sistema a través de un único canal de órdenes 18, cuyo tráfico es almacenado, automáticamente, en la SDB del anfitrión durante el proceso Confirmar, empleando una clave que contiene el número de fase apropiado. Cuando se recapitule la fase, el programa anfitrión 12 empezará recuperando de la SDB del anfitrión el tráfico guardado del canal de órdenes. Para la recapitulación, se vuelve a iniciar el programa controlador 14 a partir de su estado inicial, y funciona normalmente. En el transcurso de la recapitulación, todas las órdenes enviadas por el programa controlador 14 son desechadas por el programa anfitrión 12 (después de, por motivos de seguridad, compararlas con el tráfico de mensajes de órdenes registrado; esto, sin embargo, es opcional). Siempre que el programa controlador 14 espere recibir un mensaje de contestación a través del canal de órdenes 18, el programa anfitrión 12 busca una contestación a partir del tráfico de contestaciones entrantes registradas en el sistema 16 de almacenamiento de datos e inmediatamente proporcionada al programa controlador 14. Debido a la naturaleza determinística de los programas de ordenador de un solo hilo, este proceso tendrá como resultado que el programa controlador 14 ejecute la misma secuencia de órdenes que llevó a cabo durante la ejecución que falló, y el programa de aplicación controlado terminará en el mismo estado en que acabó en la pasada previa.
\quad
Cuando se ha reproducido el tráfico del canal de órdenes registrado de todas las fases confirmadas, se garantiza que:
(1)
El programa controlador 14 ha sido restaurado (por recapitulación) al estado que adoptó tras la operación Confirmar más reciente; y
(2)
Todos los ficheros y las bases de datos han sido, también, restauradas (merced al uso del protocolo de confirmación en dos fases) al estado que habían adoptado tras la operación Confirmar más reciente.
\quad
Así, se restablece el estado del sistema y la ejecución puede continuar normalmente.
\quad
En la realización de restauración del presente invento, el procedimiento es algo diferente:
(1)
Si la SDB del anfitrión indica un estado PREPARED y hay dos ficheros de imagen de memoria guardados (A y B), entonces el programa anfitrión 12 borra el fichero más nuevo (prohibiendo así la posibilidad de una orden de Confirmar duplicada), emite una orden Volver atrás y vuelve a cargar en memoria el fichero de imagen más antiguo (es decir, la última imagen buena guardada, conocida, del programa controlador 14). Si la SDB del anfitrión indica un estado de PREPARED y solamente hay guardado un fichero de imagen de memoria (A o B), entonces el programa anfitrión 12 emite una orden Volver atrás y vuelve a cargar en memoria ese fichero de imagen.
(2)
Si la SDB de anfitrión indica un estado RUNNING, entonces el programa anfitrión 12 emite una orden Confirmar y vuelve a cargar en memoria el fichero de imagen más reciente.
(3)
Si la SDB de anfitrión indica un estado RUNNING o ERROR y hay guardados dos ficheros de imagen de memoria, entonces el programa anfitrión 12 emite una orden Volver atrás y carga de nuevo en memoria el fichero de imagen más nuevo; si solamente hay guardado un fichero de imagen de memoria, entonces el programa anfitrión 12 emite una orden Volver atrás y carga de nuevo en memoria ese fichero de imagen.
\quad
En cualquier caso, el programa anfitrión 12 restablece luego el canal de órdenes 18 y reanuda la ejecución del programa controlador 14.
\quad
El protocolo de restauración garantiza que:
(1)
Si el fallo se produce antes de entrar en el estado COMMIT, se realiza una Vuelta atrás y se utiliza el fichero de imagen de memoria más antiguo (estado previo a PREPARE). Si el fallo se produce mientras se está en el estado COMMIT, se finaliza la operación Confirmar y se utiliza la imagen de memoria más nueva (estado posterior a PREPARE). Si el fallo se produce después de entrar en el estado COMMIT, se realiza una Vuelta atrás y se utiliza la imagen de memoria más nueva (estado posterior a PREPARE).
(2)
Todos los ficheros y las bases de datos han sido restaurados también (mediante el uso, por ejemplo, del protocolo de confirmación en dos fases) al estado en que se encontraban tras la operación Confirmar más reciente.
\quad
Así, se restaura el estado del sistema y la ejecución puede continuar normalmente.
\vskip1.000000\baselineskip
Agentes
La descripción que sigue se aplica a cada agente 24 iniciado por el programa anfitrión 12. La expresión "nodo local" se utiliza para indicar el sistema en el que se está ejecutando un agente 24 particular.
Cada agente 24 realiza las operaciones reales necesarias para ejecutar una aplicación. Un agente 24 es responsable de la realización de las operaciones sólo en el sistema remoto 20 en el que se está ejecutando. Estas operaciones incluyen la ejecución de llamadas a procedimientos remotos, la confirmación y la vuelta atrás de tales operaciones y procesos de creación y de vigilancia. Puede considerarse que un agente 24 reside "entre" una aplicación y el sistema operativo en el sentido de que un agente 24 controla cuándo y cómo puede ejecutarse una aplicación.
Las órdenes son enviadas por el programa controlador 14 a un agente 24 a través del programa anfitrión 12 en forma de llamadas a procedimientos remotos (RPC). En la realización preferida, una orden RPC consiste en un identificador seguido por una serie de argumentos, todos los cuales son cadenas de texto. El agente 24 contiene una tabla que correlaciona los identificadores de órdenes RPC con "gestionadores de RPC", siendo un gestionador un objeto que permite la invocación de sub-rutinas para realizar la RPC, confirmar la RPC, y volver atrás la RPC. El agente 24 gestiona, así, la RPC localizando el gestionador de RPC apropiado, proporcionando luego a ese gestionador de RPC los argumentos de la RPC. La rutina de gestión de la RPC analiza sintácticamente las cadenas de argumentos y realiza la operación requerida. A continuación, la rutina de gestión de la RPC produce una cadena de contestación que es enviada de vuelta al programa controlador 14 a través del programa anfitrión 12. Cada cadena de contestación incluye información sobre el éxito de la orden y cualquier dato devuelto solicitado. En la realización preferida, se utiliza una RPC especial para iniciar procesos, como se explica en lo que sigue.
Cuando se inicia un agente 24, la primera orden de RPC que recibe es una orden Iniciar agente. Esta orden notifica al agente 24 la ID de la tarea para la aplicación y asigna al nodo local una "ID de nodo" única. El agente 24 abre entonces una base de datos de estado denominada la "SDB del agente". El nombre de la SDB del agente se deriva de la ID de la tarea y de la ID del nodo y es, asimismo, único en toda la aplicación.
Cada agente 24 sigue las fases de la aplicación junto con el programa anfitrión 12. Cuando el programa anfitrión 12 realiza una operación Preparar o Confirmar, lo hace enviando órdenes RPC de Preparar nodo y Confirmar nodo, a cada uno de sus agentes 24. En las realizaciones preferidas, el programa controlador 14 solamente considerará que la aplicación en conjunto está en estado PREPARED una vez que todos los agentes 24 han respondido satisfactoriamente a sus órdenes Preparar Nodo individuales. Similarmente, la aplicación sólo considerará confirmada una fase y avanzará a la fase siguiente, cuando todos los agentes 24 hayan respondido satisfactoriamente a sus órdenes Confirmar Nodo.
Cada agente 24 registra la fase en curso y su estado en su SDB del agente. Los cuatro estados definidos y los cambios de estado permitidos son como en el programa anfitrión 12 y, en el caso normal, siguen a los del programa anfitrión 12. El estado de fase en curso (y el número de fase en curso) pueden recuperarse mediante el programa controlador 14 utilizando una orden RPC "NodeState" ("EstadodeNodo").
Cuando el programa controlador 14 invoca la función Cerrar, emite una orden Cerrar a cada agente 24. Cada agente 24 responde verificando que el estado de fase local es en ejecución y que no se están ejecutando procesos y, luego, borra su SDB del agente asociada.
En la realización preferida, cada agente 24 realiza operaciones de RPC que son parte de la fase y, por tanto, están sometidas a la arquitectura confirmar/volver atrás. Para hacer esto, cada agente 24 hace uso de su SDB del agente. Específicamente, para cada fase, un agente 24 crea, en su SDB del agente, una lista denominada la "CR_LIST" (LISTA_CR) en la que se realiza una entrada por cada operación. En forma conocida, cada entrada contiene información suficiente para deshacer la operación. La lista está ordenada, de preferencia, de modo que las operaciones puedan deshacerse en orden inverso a aquél en que se realizaron.
En la realización preferida, por uniformidad, todas las RPC deben estar en conformidad con las siguientes restricciones:
(1)
Si una RPC cambia el estado de un fichero/base de datos, debe guardar cualquier información que pueda ser necesaria para deshacer todos los cambios y volver atrás en ese fichero/base de datos, y crear una entrada en la CR_LIST. Esta entrada debe contener la identidad de la orden de RPC que se está ejecutando, de manera que pueda localizarse el gestionador de RPC apropiado durante el proceso de confirmación/vuelta atrás.
(2)
Cada gestionador de RPC debe proporcionar medios para llevar a la práctica las operaciones de Preparar, Confirmar y Volver atrás (que pueden ser operaciones nulas si la RPC no realiza cambios ni en base de datos ni en fichero alguno).
(3)
Cada gestionador de RPC puede utilizar, opcionalmente, la SDB de cada agente 24 para almacenar cualquier información necesaria para satisfacer estos requisitos.
(4)
No se requiere acción especial alguna para las RPC que no cambien el estado de ficheros ni de bases de datos.
\vskip1.000000\baselineskip
En la realización preferida, los programas de aplicación deben obedecer las siguientes reglas:
(1)
Si un proceso modifica ficheros/bases de datos, debe proporcionar medios para deshacer los cambios y para llevar a la práctica las operaciones de Preparar/Confirmar/Volver atrás. Los procesos bajo el control de un agente 24 tienen, también, acceso a las SDB del agente. Por ejemplo, el programa de aplicación puede crear entradas en la CR_LIST. Tales entradas deben contener el identificador para una orden RPC que lleve a la práctica las apropiadas operaciones de confirmación/vuelta atrás. Sin embargo, en este caso, una RPC no tiene lugar realmente, de forma que se introduce un identificador para una "RPC falsa".
(2)
Alternativamente, el programa controlador 14 puede emitir varias RPC en nombre de un proceso que tendrán el mismo efecto.
\vskip1.000000\baselineskip
La orden Iniciar Proceso para el agente 24 hace que el agente 24 ejecute un fichero de imagen de programa de aplicación especificado, poniendo así en marcha un "proceso" en el nodo local. En la realización preferida, los argumentos para esta orden aportan:
(1)
El fichero imagen ejecutable para el programa
(2)
La lista de argumentos del programa.
(3)
Cualquier información sobre el entorno del sistema operativo, requerida por el programa.
(4)
Ficheros o vías de acceso que han de ser abiertas en el proceso para uso como entrada, salida y canales de error estándar.
(5)
El código de estado de salida con el que el programa debe salir para indicar una ejecución satisfactoria.
(6)
Un modo de depuración (la depuración se describe más adelante).
\vskip1.000000\baselineskip
Cada agente 24 mantiene una lista de todos los procesos que se encuentran bajo su control. A medida que se inician los procesos, se añaden a esta lista los identificadores para esos procesos.
En la realización preferida, cada agente 24 no espera la terminación de un proceso antes de contestar al programa controlador 14. Cada agente 24 permite que el proceso se ejecute concurrentemente con el agente 24, al tiempo que vigila la ejecución del proceso. En todo momento, un agente 24 está al corriente del "estado del proceso" que, en la realización preferida es uno de entre PS_RUNNING (PS_EJECUTÁNDOSE), PS_ERROR, PS_DEBUG (PS_DEPURACIÓN) o PS_EXITED (PS_HA_SALIDO).
El estado PS_RUNNING indica que se está ejecutando un proceso de un programa sin problemas conocidos. El estado PS_ERROR indica que se sabe que el proceso ha encontrado un problema irresoluble y, (1) ha señalado una condición de error (una señal o una trampa de error), o (2) ha salido con un estado de error indicativo de un fallo, o (3) ha salido de forma anormal (por ejemplo, abortando o siendo terminado manualmente por un operador). El estado PS_EXITED indica que el proceso ha completado satisfactoriamente su ejecución y ha terminado por sí mismo normalmente. El estado PS_DEBUG se describe en el apartado "depuración" en lo que sigue.
En la realización preferida, el programa controlador 14 puede preguntar el estado de un proceso empleando una orden RPC "ProcState" ("EstadodeProceso"). Cada agente 24 mantiene, también, un estado de proceso agregado que indica el estado de todos los procesos que se le ha ordenado iniciar en conjunto. Este estado agregado se denomina "estado de proceso de nodo" y es diferente del estado confirmar/volver atrás del nodo (RUNNING, PREPARED, COMMITTING, ERROR). Los estados de proceso de nodo son los mismos que los cuatro estados de proceso y se definen como sigue:
(1)
si algún proceso se encuentra en el estado PS_DEBUG, entonces el estado agregado es PS_DEBUG, de otro modo,
(2)
si cualquier proceso se encuentra en el estado PS_ERROR, entonces el estado agregado es PS_ERROR, de otro modo,
(3)
si cualquier proceso se encuentra en el estado PS_RUNNING, entonces el estado agregado es PS_RUNNING, de otro modo,
(4)
el estado agregado es PS_EXITED (todos los procesos han terminado y se ha salido de ellos normalmente).
Las transiciones del estado de proceso de nodo afectan al estado confirmar/volver atrás del nodo. Específicamente, si el estado de proceso de nodo pasa al estado PS_ERROR, entonces el estado confirmar/volver atrás del nodo pasará, automáticamente, al estado ERROR. Además, solamente es legal pasar del estado RUNNING al estado PREPARED, o del estado PREPARED al estado RUNNING, si el estado de proceso es PS_EXITED.
El estado de proceso agregado puede ser recuperado por el programa controlador 14 utilizando la orden NodeState (Estado de nodo) del agente.
En la realización preferida, los procesos pueden emitir mensajes de error a través de canales de E/S de error estándar. Por ejemplo, en UNIX, este es el fichero de E/S "stderr". Tal salida puede ser encaminada, opcionalmente, al agente 24 desde cualquier proceso, y está disponible para el programa controlador 14 a través de la orden RPC "Eread".
El programa controlador 14 tropieza, frecuentemente, con una circunstancia en la que no puede continuar su ejecución hasta que todos los procesos iniciados en un nodo o grupo de nodos, hayan sido ejecutados por completo. Para acomodar esta circunstancia, el agente 24 soporta una orcen "Wait" (Esperar) procedente del programa controlador 14. La orden Esperar hace que un agente 24 retrase su constelación hasta que el estado de proceso de nodo deja de estar en el estado PS_RUNNING (es decir, el estado es PS_DEBUG, PS_ERROR o PS_EXITED). La contestación a la orden Esperar indica a los procesos que han originado la condición Esperar que terminen. El programa controlador 14 puede cancelar, también, la condición Esperar enviando una orden RPC "Sync" ("Sinc") al agente 24 durante la condición Esperar. La orden Sinc tanto si se ha recibido accidentalmente una contestación a la espera como si no (porque la contestación a esperar y la orden sinc se cruzan en el canal de órdenes 18).
\vskip1.000000\baselineskip
Depuración de procesos
De vez en cuando, resulta útil que el programa controlador 14 le permita al usuario realizar la depuración de un proceso particular del sistema. La depuración supone poner en marcha un proceso bajo el control de un depurador estándar, como el disponible en cualquier sistema operativo particular. Un usuario puede querer depurar un proceso desde el comienzo de su ejecución. Alternativamente, el usuario puede querer depurar un proceso solamente si encuentra una condición de error, es decir, cuando el proceso cambia al estado de proceso PS_ERROR.
En la realización preferida, cuando se pone en marcha un proceso (utilizando la orden Iniciar Proceso), puede especificarse su ejecución en cualquiera de tres "modos de depuración": DEBUG_NONE (NO_DEPURAR), DEBUG_START (DEPURAR_DESDE_INICIO) y DEBUG_TRACE (SEGUIR_DEPURACIÓN). En un programa que se encuentre en el modo de depuración DEBUG_NONE no se ejecutará el depurador. Los procesos en que se especifique el modo DEBUG_START se ejecutarán desde el comienzo con un depurador asociado. Los procesos en que se especifique el modo DEBUG_TRACE, serán vigilados por el agente 24 y, si entrasen en cualquiera de varias condiciones de error detectables (que pueden incluir trampas de error, señales o decisiones de abortar), serán detenidos y se ejecutará un depurador en asociación con el proceso que falla.
En la realización preferida, un agente 24 no inicia el depurador en forma autónoma. En vez de ello, cuando hay necesidad de depurar un proceso (según se indica mediante el modo depurar), el agente 24 pasa el proceso al estado de proceso PS_DEBUG. Esto hace que el estado de proceso agregado pase a PS_DEBUG. Este estado se le comunica al programa controlador 14 (por ejemplo, este estado hace que finalice una condición de espera). En ese momento, el programa controlador 14 puede invocar un depurador para el proceso utilizando una orden RPC "depurar". Esta orden especifica un programa a ejecutar, presumiblemente, un guión de órdenes, al que se le pasará información suficiente (a través de la lista de argumentos) para iniciar un depurador elegido.
\vskip1.000000\baselineskip
Recuperación
Cada agente mantiene un estado y un número de fase local que se almacenan en su SDB del agente. El número de fase es mantenido en sincronismo con el del programa anfitrión 12 mediante el protocolo preparar/confirmar. El estado de fase se deriva, principalmente, del estado de proceso y es utilizado por el programa controlador 14 para calcular el estado de la fase en curso para la aplicación en su conjunto.
Cuando el programa controlador 14 es vuelto a invocar tras un fallo, le dice al programa anfitrión 12 que inicie una tarea. Si se encuentra un "fichero de recuperación", entonces el programa anfitrión 12 entra en el "modo de recuperación" y recupera el estado de los agentes 24 como sigue:
(1)
Se utiliza la SDB del anfitrión para determinar el conjunto de procesos de agente 24 en ejecución en el momento del fallo.
(2)
Se crea un nuevo agente 24 en cada uno de tales nodos.
(3)
Cada agente 24 recibe una orden "Iniciar Agente" con la ID de tarea.
(4)
Los agentes 24 reconocen esta ID de tarea como una aplicación existente, porque la SDB del agente todavía existe (su nombre se deriva de la ID de la tarea).
(5)
Cada agente 24 abre su SDB, que se ha reconstruido a partir de su registro, y extrae el estado, el número de fase en curso y la lista confirmar-volver atrás.
(6)
Si el programa anfitrión 12 está en un estado distinto de COMMITTING, transmitirá entonces una orden de Vuelta atrás a los agentes 24 que hará que los agentes 24 deshagan, en orden inverso, todas las operaciones realizadas en esa fase. Si, por otro lado, el programa anfitrión 12 estaba en el estado COMMITTING, volverá a emitir una orden Confirmar a los agentes 24. Cualquier agente 24 que se encuentre en estado COMMITTING completará lo que, evidentemente, era una operación de confirmación interrumpida recorriendo la lista de confirmar-volver atrás en orden directo, ejecutando los métodos de confirmación de todas las entradas. Cualquier agente 24 que se encuentre, a su vez, en estado RUNNING, tratará la orden Confirmar como una orden Nula (ya que, evidentemente, la anterior operación de Confirmación se había completado en este nodo pero no en algunos otros nodos).
(7)
En ese punto, los agentes 24 consideran que, ellos mismos, se encuentran al inicio de esa fase en el estado RUNNING, y pueden proceder a aceptar órdenes del programa controlador 14.
\vskip1.000000\baselineskip
Sumario
La figura 4 es una gráfica de flujo que muestra, en forma resumida, las operaciones funcionales básicas de la realización de recapitulación del presente invento. El programa controlador 14 inicia procesos en los sistemas remotos 20 (Paso 40). El programa anfitrión 12 registra todas las órdenes de control procedentes del programa controlador 14 (Paso 41), así como todas las contestaciones al programa controlador 14 (Paso 42). Cada agente 24 ejecuta una aplicación en fases en su respectivo sistema remoto 20 (Paso 43). Las aplicaciones ejecutan un protocolo preparar-confirmar para almacenar estados de ficheros y de sistemas mientras mantienen la consistencia del sistema (Paso 44). Si se produce un fallo, se restaura el estado del sistema y se reinicia el programa controlador 14, emitiéndose órdenes al programa anfitrión 12 (Paso 45). El programa anfitrión 12 lee las contestaciones coincidentes para cada orden y envía las contestaciones al programa controlador 14, en un modo de recapitulación, hasta el final (Paso 46). El programa controlador 14 continúa controlando entonces los procesos de aplicación a partir del último punto de control bueno (Paso 47).
La figura 5 es un diagrama de flujo que muestra, en forma resumida, las operaciones funcionales básicas de la realización de restauración del presente invento. El programa controlador 14 inicia procesos en sistemas remotos 20 (Paso 50). Cada agente 24 ejecuta una aplicación en fases en su respectivo sistema remoto 20 (Paso 51). Las aplicaciones ejecutan la parte de preparación de un protocolo de confirmación para almacenar estados de ficheros y de sistemas (Paso 52). Se almacena una imagen de memoria del programa controlador 14 después de terminado el protocolo de preparación (Paso 53). Las aplicaciones ejecutan un protocolo de confirmación para completar el almacenamiento seguro de los estados de ficheros y de sistemas, al tiempo que mantienen la consistencia del sistema (Paso 54). Si se produce un fallo, se restaura el estado del sistema y la imagen de memoria almacenada del programa controlador 14 es cargada de nuevo en memoria (Paso 55). El programa controlador 14 continúa entonces controlando los procesos de aplicación a partir del último punto de control bueno (Paso 56).
Se han descrito varias realizaciones del presente invento. No obstante, se comprenderá que pueden realizarse diversas modificaciones sin por ello apartarse del espíritu ni del alcance del presente invento. Por ejemplo, el invento podría aplicarse a sistemas con una sola CPU. Además, si bien se prefiere un protocolo de confirmación en dos fases, pueden utilizarse otros protocolos de confirmación que guarden en forma segura el estado del sistema al tiempo que mantienen la consistencia del mismo. En consecuencia, se comprenderá que el invento no ha de considerarse limitado por la realización específica ilustrada, sino solamente por el alcance de las reivindicaciones adjuntas.

Claims (20)

1. Un método para ejecutar una aplicación de ordenador en un sistema de tratamiento en paralelo, en el que dicha aplicación carece de la posibilidad de establecer puntos de control previamente programados, que comprende los pasos de:
\quad
ejecutar una aplicación en una serie de fases de ejecución en un sistema de tratamiento en paralelo, de tal forma que los procesos de la aplicación estén inactivos entre fases de ejecución;
\quad
controlar el tratamiento de cada fase de ejecución, incluyendo la creación de instancias y la vigilancia de todos los programas y colecciones de datos que formen la aplicación;
\quad
guardar el estado final de cada fase de ejecución terminada con éxito;
\quad
detectar un fallo de la aplicación en cualquiera de tales fases de ejecución;
\quad
restaurar el último estado final guardado de la fase de ejecución antes de la fase de ejecución en que se detectó el fallo; y
\quad
reiniciar la aplicación al comienzo de la fase de ejecución en que se detectó el fallo.
2. El método de la reivindicación 1, en el que los programas de vigilancia y de creación de instancias y las colecciones de datos que forman la aplicación, incluyen la emisión de órdenes y la recepción de contestaciones a tales órdenes.
3. El método de la reivindicación 2, que incluye, además, registrar todas las citadas órdenes y las contestaciones a dichas órdenes.
4. El método de la reivindicación 3, en el que la restauración del último estado final guardado en la fase de ejecución previa a la fase de ejecución en que se detectó un fallo, incluye recapitular todas las órdenes y las contestaciones a tales órdenes registradas desde el comienzo de la ejecución de la aplicación hasta el último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo.
5. El método de la reivindicación 1, en el que los programas de vigilancia y de creación de instancias y las colecciones de datos que forman la aplicación, incluyen programas de vigilancia que se ejecutan en diferentes partes del sistema de tratamiento en paralelo utilizando un programa controlador (14).
6. El método de la reivindicación 5, que incluye además, al término de cada fase de ejecución completada con éxito, guardar al menos las estructuras de datos del programa controlador necesarias para recrear un estado guardado para el programa controlador.
7. El método de la reivindicación 6, en el que la restauración del último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo, incluye restaurar el programa controlador volviendo a cargar en memoria las estructuras de datos guardadas del programa controlador hasta el término de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo.
8. El método de la reivindicación 1, en el que se guarda el estado final de cada fase de ejecución completada con éxito después de esperar hasta que los procesos iniciados en la fase de ejecución se han completado y no hay transferencias de datos pendientes entre diferentes partes del sistema de tratamiento en paralelo.
9. El método de la reivindicación 1, en el que el estado final de cada fase de ejecución completada con éxito se guarda mediante un protocolo de confirmación en dos fases.
10. El método de la reivindicación 1, que incluye además emitir, repetidamente, una orden de espera para suspender la operación con el fin de dar tiempo a que se completen los procesos, incluyendo las transferencias de datos pendientes antes de guardar el estado final de cada fase de ejecución completada satisfactoriamente.
11. Un medio de almacenamiento legible por ordenador, configurado con un programa de ordenador para ejecutar una aplicación de ordenador en un sistema de tratamiento en paralelo, en el que tal aplicación carece de la capacidad de crear puntos de control previamente programados, cuyo medio de almacenamiento está configurado para hacer que un ordenador funcione de manera específica y predefinida a fin de realizar las funciones de:
\quad
ejecutar una aplicación en una serie de fases de ejecución en un sistema de tratamiento en paralelo, de tal manera que los procesos de la aplicación estén inactivos entre fases de ejecución;
\quad
controlar el tratamiento de cada fase de ejecución incluyendo la vigilancia y la creación de instancias de todos los programas y colecciones de datos que forman la aplicación;
\quad
guardar el estado final de cada fase de ejecución completada con éxito;
\quad
detectar un fallo de la aplicación en cualquiera de tales fases de ejecución;
\quad
restaurar el último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo; y
\quad
reiniciar la aplicación al comienzo de la fase de ejecución en que se detectó el fallo.
12. El medio de almacenamiento legible por ordenador de la reivindicación 11, en el que los programas de vigilancia y creación de instancias y las colecciones de datos que forman la aplicación, incluyen la emisión de órdenes y la recepción de contestaciones a tales órdenes.
13. El medio de almacenamiento legible por ordenador de la reivindicación 12, para realizar, además, la función de registrar todas las mencionadas órdenes y contestaciones de tales órdenes.
14. El medio de almacenamiento legible por ordenador de la reivindicación 13, en el que la restauración del último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo, incluye recapitular todas las órdenes y las contestaciones a tales órdenes registradas, desde el comienzo de la ejecución de la aplicación hasta el último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo.
15. El medio de almacenamiento legible por ordenador de la reivindicación 11, en el que los programas de vigilancia y creación de instancias y las colecciones de datos que forman la aplicación, incluyen programas de vigilancia que se ejecutan en diferentes partes del sistema de tratamiento en paralelo utilizando un programa de control (14).
16. El medio de almacenamiento legible por ordenador de la reivindicación 15, para realizar, además, la función de, al término de cada fase de ejecución completada satisfactoriamente, guardar al menos las estructuras de datos del programa controlador necesarias para recrear un estado guardado para el programa de control.
17. El medio de almacenamiento legible por ordenador de la reivindicación 16, en el que la restauración del último estado final guardado de la fase de ejecución previa a la fase de ejecución en que se detectó el fallo, incluye restaurar el programa controlador volviendo a cargar en memoria la estructura de datos guardada del programa controlador hasta el término de la fase de ejecución previa a la fase de ejecución en se detectó el fallo.
18. El medio de almacenamiento legible por ordenador de la reivindicación 11, en el que se guarda el estado final de cada fase de ejecución completada satisfactoriamente, después de esperar hasta que los procesos iniciados en la fase de ejecución se hayan completado y no queden transferencias de datos pendientes entre diferentes partes del sistema de tratamiento en paralelo.
19. El medio de almacenamiento legible por ordenador de la reivindicación 11, en el que el estado final de cada fase de ejecución completada con éxito se guarda mediante un protocolo de confirmación en dos fases.
20. El medio de almacenamiento legible por ordenador de la reivindicación 11, para realizar, además, la función de emitir, repetidamente, una orden de espera para suspender la operación con el fin de dar tiempo a que se completen los procesos incluyendo transferencias de datos pendientes antes de guardar el estado final de cada fase de ejecución completada satisfactoriamente.
ES96943730T 1995-12-11 1996-12-11 Metodo para reconstruir el estado de un calculo. Expired - Lifetime ES2320601T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/570,724 US5712971A (en) 1995-12-11 1995-12-11 Methods and systems for reconstructing the state of a computation
US570724 1995-12-11

Publications (1)

Publication Number Publication Date
ES2320601T3 true ES2320601T3 (es) 2009-05-25

Family

ID=24280795

Family Applications (1)

Application Number Title Priority Date Filing Date
ES96943730T Expired - Lifetime ES2320601T3 (es) 1995-12-11 1996-12-11 Metodo para reconstruir el estado de un calculo.

Country Status (11)

Country Link
US (1) US5712971A (es)
EP (1) EP0954779B8 (es)
JP (2) JP3573463B2 (es)
AT (1) ATE423351T1 (es)
AU (1) AU1288897A (es)
CA (1) CA2240347C (es)
DE (1) DE69637836D1 (es)
DK (1) DK0954779T3 (es)
ES (1) ES2320601T3 (es)
PT (1) PT954779E (es)
WO (1) WO1997022052A1 (es)

Families Citing this family (138)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5931954A (en) * 1996-01-31 1999-08-03 Kabushiki Kaisha Toshiba I/O control apparatus having check recovery function
GB2311391A (en) * 1996-03-19 1997-09-24 Ibm Restart and recovery of OMG compliant transaction systems
US5909681A (en) 1996-03-25 1999-06-01 Torrent Systems, Inc. Computer system and computerized method for partitioning data for parallel processing
US6324567B2 (en) * 1997-06-11 2001-11-27 Oracle Corporation Method and apparatus for providing multiple commands to a server
AU8674098A (en) * 1997-07-31 1999-02-22 Data Net Corporation Method and apparatus for implementing software connectivity for client/server applications
US6009258A (en) * 1997-09-26 1999-12-28 Symantec Corporation Methods and devices for unwinding stack of frozen program and for restarting the program from unwound state
US5911060A (en) * 1997-09-26 1999-06-08 Symantec Corporation Computer method and apparatus for unfreezing an apparently frozen application program being executed under control of an operating system
US6029177A (en) * 1997-11-13 2000-02-22 Electronic Data Systems Corporation Method and system for maintaining the integrity of a database providing persistent storage for objects
JPH11282684A (ja) * 1998-03-27 1999-10-15 Canon Inc 画像処理装置、画像処理装置の制御方法、および記憶媒体
US6477663B1 (en) * 1998-04-09 2002-11-05 Compaq Computer Corporation Method and apparatus for providing process pair protection for complex applications
US6175932B1 (en) * 1998-04-20 2001-01-16 National Instruments Corporation System and method for providing state capture and restoration to an I/O system
US8631066B2 (en) * 1998-09-10 2014-01-14 Vmware, Inc. Mechanism for providing virtual machines for use by multiple users
US6397351B1 (en) 1998-09-28 2002-05-28 International Business Machines Corporation Method and apparatus for rapid data restoration including on-demand output of sorted logged changes
US6226759B1 (en) 1998-09-28 2001-05-01 International Business Machines Corporation Method and apparatus for immediate data backup by duplicating pointers and freezing pointer/data counterparts
US6256751B1 (en) * 1998-10-29 2001-07-03 International Business Machines Corporation Restoring checkpointed processes without restoring attributes of external data referenced by the processes
US6338147B1 (en) 1998-10-29 2002-01-08 International Business Machines Corporation Program products for performing checkpoint/restart of a parallel program
US6393583B1 (en) 1998-10-29 2002-05-21 International Business Machines Corporation Method of performing checkpoint/restart of a parallel program
US6401216B1 (en) 1998-10-29 2002-06-04 International Business Machines Corporation System of performing checkpoint/restart of a parallel program
EP1185928A1 (en) 1998-12-16 2002-03-13 Kent Ridge Digital Labs Process oriented computing environment
US7047232B1 (en) * 1999-01-13 2006-05-16 Ab Initio Software Corporation Parallelizing applications of script-driven tools
JP4237354B2 (ja) * 1999-09-29 2009-03-11 株式会社東芝 トランザクション処理方法及びトランザクション処理システム
US6630946B2 (en) 1999-11-10 2003-10-07 Symantec Corporation Methods for automatically locating data-containing windows in frozen applications program and saving contents
US6631480B2 (en) 1999-11-10 2003-10-07 Symantec Corporation Methods and systems for protecting data from potential corruption by a crashed computer program
US6662310B2 (en) 1999-11-10 2003-12-09 Symantec Corporation Methods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data
US6584581B1 (en) * 1999-12-06 2003-06-24 Ab Initio Software Corporation Continuous flow checkpointing data processing
US6678701B1 (en) 2000-01-05 2004-01-13 International Business Machines Corporation Technique for establishing a point of consistency in a parallel database loading system
EP1128266A3 (en) * 2000-02-22 2004-02-25 Orsus Solutions Limited Cooperative software application architecture
TW525329B (en) * 2000-05-29 2003-03-21 Omron Tateisi Electronics Co Power supply module and power supply unit using the same
US6944790B2 (en) * 2001-04-05 2005-09-13 International Business Machines Corporation System and method for collecting and restoring user environment data using removable storage
US8234156B2 (en) * 2001-06-28 2012-07-31 Jpmorgan Chase Bank, N.A. System and method for characterizing and selecting technology transition options
US6883114B2 (en) * 2001-11-08 2005-04-19 M-Systems Flash Disk Pioneers Ltd. Block device driver enabling a ruggedized file system
KR20030056540A (ko) * 2001-12-28 2003-07-04 한국전자통신연구원 데이터베이스 관리 시스템에서 시스템 고장에 대비한 파일삭제 및 회복 방법
US7168008B2 (en) * 2002-01-18 2007-01-23 Mobitv, Inc. Method and system for isolating and protecting software components
US6880051B2 (en) * 2002-03-14 2005-04-12 International Business Machines Corporation Method, system, and program for maintaining backup copies of files in a backup storage device
GB0211179D0 (en) * 2002-05-16 2002-06-26 Ibm A method,apparatus and computer program for reducing the amount of data checkpointed
US7024591B2 (en) * 2002-07-12 2006-04-04 Crossroads Systems, Inc. Mechanism for enabling enhanced fibre channel error recovery across redundant paths using SCSI level commands
US20040083158A1 (en) * 2002-10-09 2004-04-29 Mark Addison Systems and methods for distributing pricing data for complex derivative securities
US7167850B2 (en) * 2002-10-10 2007-01-23 Ab Initio Software Corporation Startup and control of graph-based computation
US7340650B2 (en) * 2002-10-30 2008-03-04 Jp Morgan Chase & Co. Method to measure stored procedure execution statistics
US7149752B2 (en) * 2002-12-03 2006-12-12 Jp Morgan Chase Bank Method for simplifying databinding in application programs
US7085759B2 (en) 2002-12-06 2006-08-01 Jpmorgan Chase Bank System and method for communicating data to a process
US8032439B2 (en) * 2003-01-07 2011-10-04 Jpmorgan Chase Bank, N.A. System and method for process scheduling
US7401156B2 (en) * 2003-02-03 2008-07-15 Jp Morgan Chase Bank Method using control interface to suspend software network environment running on network devices for loading and executing another software network environment
US7484087B2 (en) * 2003-02-24 2009-01-27 Jp Morgan Chase Bank Systems, methods, and software for preventing redundant processing of transmissions sent to a remote host computer
JP4345334B2 (ja) * 2003-03-28 2009-10-14 日本電気株式会社 耐障害計算機システム、プログラム並列実行方法およびプログラム
US7379998B2 (en) * 2003-03-31 2008-05-27 Jp Morgan Chase Bank System and method for multi-platform queue queries
US20040230602A1 (en) * 2003-05-14 2004-11-18 Andrew Doddington System and method for decoupling data presentation layer and data gathering and storage layer in a distributed data processing system
US7366722B2 (en) * 2003-05-15 2008-04-29 Jp Morgan Chase Bank System and method for specifying application services and distributing them across multiple processors using XML
US7509641B2 (en) * 2003-05-16 2009-03-24 Jp Morgan Chase Bank Job processing framework
US7634500B1 (en) 2003-11-03 2009-12-15 Netlogic Microsystems, Inc. Multiple string searching using content addressable memory
EP1690163A4 (en) * 2003-11-17 2011-07-13 Virginia Tech Intell Prop TRANSPARENT CREATION OF CONTROL POINTS AND MIGRATION OF PROCESSES IN A DISTRIBUTED SYSTEM
US7281023B2 (en) * 2003-12-15 2007-10-09 At&T Knowledge Ventures, L.P. Architecture of database application with robust online recoverability
US20050144174A1 (en) * 2003-12-31 2005-06-30 Leonid Pesenson Framework for providing remote processing of a graphical user interface
US8689185B1 (en) * 2004-01-27 2014-04-01 United Services Automobile Association (Usaa) System and method for processing electronic data
US8140348B2 (en) * 2004-01-30 2012-03-20 International Business Machines Corporation Method, system, and program for facilitating flow control
US7650606B2 (en) * 2004-01-30 2010-01-19 International Business Machines Corporation System recovery
US7366801B2 (en) * 2004-01-30 2008-04-29 International Business Machines Corporation Method for buffering work requests
US7702767B2 (en) * 2004-03-09 2010-04-20 Jp Morgan Chase Bank User connectivity process management system
US9734222B1 (en) 2004-04-06 2017-08-15 Jpmorgan Chase Bank, N.A. Methods and systems for using script files to obtain, format and transport data
US20050222990A1 (en) * 2004-04-06 2005-10-06 Milne Kenneth T Methods and systems for using script files to obtain, format and disseminate database information
AU2005234798B2 (en) * 2004-04-26 2009-01-08 Jp Morgan Chase Bank System and method for routing messages
US7665127B1 (en) 2004-06-30 2010-02-16 Jp Morgan Chase Bank System and method for providing access to protected services
US7386752B1 (en) * 2004-06-30 2008-06-10 Symantec Operating Corporation Using asset dependencies to identify the recovery set and optionally automate and/or optimize the recovery
US7392471B1 (en) 2004-07-28 2008-06-24 Jp Morgan Chase Bank System and method for comparing extensible markup language (XML) documents
US20060085492A1 (en) * 2004-10-14 2006-04-20 Singh Arun K System and method for modifying process navigation
FR2882448B1 (fr) * 2005-01-21 2007-05-04 Meiosys Soc Par Actions Simpli Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif
US7478278B2 (en) * 2005-04-14 2009-01-13 International Business Machines Corporation Template based parallel checkpointing in a massively parallel computer system
EP1899902B1 (en) * 2005-05-30 2011-12-28 Semiconductor Energy Laboratory Co., Ltd. Semiconductor device and driving method thereof
US7877350B2 (en) * 2005-06-27 2011-01-25 Ab Initio Technology Llc Managing metadata for graph-based computations
US8572516B1 (en) 2005-08-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for controlling a screen saver
US7636946B2 (en) * 2005-08-31 2009-12-22 Microsoft Corporation Unwanted file modification and transactions
US7353332B2 (en) * 2005-10-11 2008-04-01 Integrated Device Technology, Inc. Switching circuit implementing variable string matching
US7499933B1 (en) 2005-11-12 2009-03-03 Jpmorgan Chase Bank, N.A. System and method for managing enterprise application configuration
US8181016B1 (en) 2005-12-01 2012-05-15 Jpmorgan Chase Bank, N.A. Applications access re-certification system
KR100833681B1 (ko) 2005-12-08 2008-05-29 한국전자통신연구원 커밋 프로토콜을 이용한 병행 프로세스 메모리 관리 시스템및 관리 방법
US7574591B2 (en) * 2006-01-12 2009-08-11 Microsoft Corporation Capturing and restoring application state after unexpected application shutdown
US7716461B2 (en) * 2006-01-12 2010-05-11 Microsoft Corporation Capturing and restoring application state after unexpected application shutdown
US7913249B1 (en) 2006-03-07 2011-03-22 Jpmorgan Chase Bank, N.A. Software installation checker
US7895565B1 (en) 2006-03-15 2011-02-22 Jp Morgan Chase Bank, N.A. Integrated system and method for validating the functionality and performance of software applications
US7571347B2 (en) * 2006-03-20 2009-08-04 Sun Microsystems, Inc. Method and apparatus for providing fault-tolerance in parallel-processing systems
US20070276879A1 (en) * 2006-05-26 2007-11-29 Rothman Michael A Sparse checkpoint and rollback
US7610172B2 (en) * 2006-06-16 2009-10-27 Jpmorgan Chase Bank, N.A. Method and system for monitoring non-occurring events
EP1873643A1 (en) * 2006-06-30 2008-01-02 Alcatel Lucent Service objects with rollback-recovery
AU2007286155B2 (en) 2006-08-10 2013-12-12 Ab Initio Technology Llc. Distributing services in graph-based computations
US7539031B2 (en) * 2006-09-19 2009-05-26 Netlogic Microsystems, Inc. Inexact pattern searching using bitmap contained in a bitcheck command
US7529746B2 (en) * 2006-09-19 2009-05-05 Netlogic Microsystems, Inc. Search circuit having individually selectable search engines
US7783654B1 (en) 2006-09-19 2010-08-24 Netlogic Microsystems, Inc. Multiple string searching using content addressable memory
US7539032B2 (en) * 2006-09-19 2009-05-26 Netlogic Microsystems, Inc. Regular expression searching of packet contents using dedicated search circuits
US7644080B2 (en) * 2006-09-19 2010-01-05 Netlogic Microsystems, Inc. Method and apparatus for managing multiple data flows in a content search system
US7624105B2 (en) * 2006-09-19 2009-11-24 Netlogic Microsystems, Inc. Search engine having multiple co-processors for performing inexact pattern search operations
US7917486B1 (en) 2007-01-18 2011-03-29 Netlogic Microsystems, Inc. Optimizing search trees by increasing failure size parameter
WO2008092162A2 (en) 2007-01-26 2008-07-31 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US7630982B2 (en) 2007-02-24 2009-12-08 Trend Micro Incorporated Fast identification of complex strings in a data stream
JP5251002B2 (ja) * 2007-05-25 2013-07-31 富士通株式会社 分散処理プログラム、分散処理方法、分散処理装置、および分散処理システム
CA2965896C (en) 2007-07-26 2020-01-07 Ab Initio Technology Llc Transactional graph-based computation with error handling
US7643353B1 (en) 2007-10-25 2010-01-05 Netlogic Microsystems, Inc. Content addressable memory having programmable interconnect structure
US8776018B2 (en) 2008-01-11 2014-07-08 International Business Machines Corporation System and method for restartable provisioning of software components
EP2271987A4 (en) * 2008-05-01 2011-04-20 Hewlett Packard Development Co STORING CONTROL POINT DATA IN NON-VOLATILE MEMORY
US20090282058A1 (en) * 2008-05-12 2009-11-12 Expressor Software Method and system for developing data integration applications with reusable functional rules that are managed according to their output variables
US7924589B1 (en) 2008-06-03 2011-04-12 Netlogic Microsystems, Inc. Row redundancy for content addressable memory having programmable interconnect structure
US8291261B2 (en) * 2008-11-05 2012-10-16 Vulcan Technologies Llc Lightweight application-level runtime state save-and-restore utility
JP2010165251A (ja) 2009-01-16 2010-07-29 Toshiba Corp 情報処理装置及びプロセッサ並びに情報処理方法
KR20150038758A (ko) 2009-02-13 2015-04-08 아브 이니티오 테크놀로지 엘엘시 태스크 실행 관리
US7916510B1 (en) 2009-08-10 2011-03-29 Netlogic Microsystems, Inc. Reformulating regular expressions into architecture-dependent bit groups
US7924590B1 (en) 2009-08-10 2011-04-12 Netlogic Microsystems, Inc. Compiling regular expressions for programmable content addressable memory devices
US8667329B2 (en) * 2009-09-25 2014-03-04 Ab Initio Technology Llc Processing transactions in graph-based applications
US9665620B2 (en) * 2010-01-15 2017-05-30 Ab Initio Technology Llc Managing data queries
CN102263652A (zh) * 2010-05-31 2011-11-30 鸿富锦精密工业(深圳)有限公司 网络装置及更改其参数设定的方法
CN107066241B (zh) 2010-06-15 2021-03-09 起元技术有限责任公司 用于动态加载基于图的计算的系统和方法
US8527488B1 (en) 2010-07-08 2013-09-03 Netlogic Microsystems, Inc. Negative regular expression search operations
US9002946B2 (en) * 2010-08-25 2015-04-07 Autodesk, Inc. Dual modeling environment in which commands are executed concurrently and independently on both a light weight version of a proxy module on a client and a precise version of the proxy module on a server
US8862603B1 (en) 2010-11-03 2014-10-14 Netlogic Microsystems, Inc. Minimizing state lists for non-deterministic finite state automatons
US9116759B2 (en) * 2011-02-18 2015-08-25 Ab Initio Technology Llc Restarting data processing systems
US9021299B2 (en) 2011-02-18 2015-04-28 Ab Initio Technology Llc Restarting processes
US9116955B2 (en) 2011-05-02 2015-08-25 Ab Initio Technology Llc Managing data queries
US9135124B2 (en) * 2012-04-30 2015-09-15 Hewlett-Packard Development Company, L.P. Sequence indicator for command communicated to a sequential access storage device
US9317467B2 (en) 2012-09-27 2016-04-19 Hewlett Packard Enterprise Development Lp Session key associated with communication path
JP6085897B2 (ja) * 2012-10-09 2017-03-01 ▲ホア▼▲ウェイ▼技術有限公司Huawei Technologies Co.,Ltd. ウェブアプリケーションにデータベースの変更内容を取得させるための方法及びシステム
US10108521B2 (en) 2012-11-16 2018-10-23 Ab Initio Technology Llc Dynamic component performance monitoring
US9507682B2 (en) 2012-11-16 2016-11-29 Ab Initio Technology Llc Dynamic graph performance monitoring
US9274926B2 (en) 2013-01-03 2016-03-01 Ab Initio Technology Llc Configurable testing of computer programs
US10002041B1 (en) 2013-02-01 2018-06-19 Jpmorgan Chase Bank, N.A. System and method for maintaining the health of a machine
US9720655B1 (en) 2013-02-01 2017-08-01 Jpmorgan Chase Bank, N.A. User interface event orchestration
US9088459B1 (en) 2013-02-22 2015-07-21 Jpmorgan Chase Bank, N.A. Breadth-first resource allocation system and methods
US9619410B1 (en) 2013-10-03 2017-04-11 Jpmorgan Chase Bank, N.A. Systems and methods for packet switching
WO2015060991A1 (en) 2013-10-21 2015-04-30 Ab Initio Technology Llc Checkpointing a collection of data units
WO2015085152A1 (en) 2013-12-05 2015-06-11 Ab Initio Technology Llc Managing interfaces for dataflow graphs composed of sub-graphs
EP3077904B1 (en) 2013-12-06 2018-04-11 AB Initio Technology LLC Source code translation
US9542259B1 (en) 2013-12-23 2017-01-10 Jpmorgan Chase Bank, N.A. Automated incident resolution system and method
US9868054B1 (en) 2014-02-10 2018-01-16 Jpmorgan Chase Bank, N.A. Dynamic game deployment
US10437819B2 (en) 2014-11-14 2019-10-08 Ab Initio Technology Llc Processing queries containing a union-type operation
US10417281B2 (en) 2015-02-18 2019-09-17 Ab Initio Technology Llc Querying a data source on a network
US10657134B2 (en) 2015-08-05 2020-05-19 Ab Initio Technology Llc Selecting queries for execution on a stream of real-time data
CN108475189B (zh) 2015-12-21 2021-07-09 起元技术有限责任公司 子图接口生成的方法、系统及计算机可读介质
US10601890B2 (en) 2016-01-14 2020-03-24 Ab Initio Technology Llc Recoverable stream processing
JP6665892B2 (ja) * 2018-07-04 2020-03-13 富士通株式会社 情報処理システム,情報処理装置および制御プログラム
US11093223B2 (en) 2019-07-18 2021-08-17 Ab Initio Technology Llc Automatically converting a program written in a procedural programming language into a dataflow graph and related systems and methods
US11847027B2 (en) 2022-03-15 2023-12-19 Microsoft Technology Licensing, Llc Automated configuration conflict resolution and lightweight restoration

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4823256A (en) * 1984-06-22 1989-04-18 American Telephone And Telegraph Company, At&T Bell Laboratories Reconfigurable dual processor system
US4665520A (en) * 1985-02-01 1987-05-12 International Business Machines Corporation Optimistic recovery in a distributed processing system
US4703481A (en) * 1985-08-16 1987-10-27 Hewlett-Packard Company Method and apparatus for fault recovery within a computing system
US5121486A (en) * 1987-11-20 1992-06-09 Hitachi, Ltd Network control system for dynamically switching a logical connection between an identified terminal device and an indicated processing unit
US5313584A (en) * 1991-11-25 1994-05-17 Unisys Corporation Multiple I/O processor system
US5335343A (en) * 1992-07-06 1994-08-02 Digital Equipment Corporation Distributed transaction processing using two-phase commit protocol with presumed-commit without log force
US5435003A (en) * 1993-10-07 1995-07-18 British Telecommunications Public Limited Company Restoration in communications networks
US5530802A (en) * 1994-06-22 1996-06-25 At&T Corp. Input sequence reordering method for software failure recovery
US5440726A (en) * 1994-06-22 1995-08-08 At&T Corp. Progressive retry method and apparatus having reusable software modules for software failure recovery in multi-process message-passing applications
US5590277A (en) * 1994-06-22 1996-12-31 Lucent Technologies Inc. Progressive retry method and apparatus for software failure recovery in multi-process message-passing applications

Also Published As

Publication number Publication date
US5712971A (en) 1998-01-27
AU1288897A (en) 1997-07-03
DE69637836D1 (en) 2009-04-02
PT954779E (pt) 2009-04-28
CA2240347C (en) 2001-07-10
DK0954779T3 (da) 2009-04-06
EP0954779A4 (en) 2007-05-09
JP3675802B2 (ja) 2005-07-27
EP0954779B8 (en) 2009-04-22
JP2002505768A (ja) 2002-02-19
JP2004094963A (ja) 2004-03-25
ATE423351T1 (de) 2009-03-15
EP0954779A1 (en) 1999-11-10
EP0954779B1 (en) 2009-02-18
WO1997022052A1 (en) 1997-06-19
CA2240347A1 (en) 1997-06-19
JP3573463B2 (ja) 2004-10-06

Similar Documents

Publication Publication Date Title
ES2320601T3 (es) Metodo para reconstruir el estado de un calculo.
US6766471B2 (en) User-level checkpoint and restart for groups of processes
EP1495414B1 (en) Transparent consistent active replication of multithreaded application programs
EP0772136B1 (en) Method of commitment in a distributed database transaction
US7178062B1 (en) Methods and apparatus for executing code while avoiding interference
US5276876A (en) Registration of resources for commit procedures
US5261089A (en) Optimization of commit procedures by utilizing a two-phase commit procedure only when necessary
JPS63225851A (ja) 複数データ処理装置間フアイル共有方式
US6092084A (en) One system of a multisystem environment taking over log entries owned by another system
Sharma et al. Grove: a separation-logic library for verifying distributed systems
US6076095A (en) Method of one system of a multisystem environment taking over log entries owned by another system
Gray Agent Tcl: Alpha Release 1.1
Salzberg et al. DSDT: Durable scripts containing database transactions
Campbell et al. Practical fault tolerant software for asynchronous systems
Ravindran et al. Failure transparency in remote procedure calls
Weggerle et al. Transaction based device driver developement
Reiss et al. Automated support for recovery
Nett et al. Implementing fault-tolerance in a distributed system architecture
Mellor-Crummey et al. Elmwood-An Object-Oriented Multiprocessor Operating System
Krawczuk Distributed debugging based on deterministic reexecution: methodology and design of a working prototype
Kobus et al. Paxos STM–User Guide
Gibson Computation management in a single address space system
Drew Fail-safety techniques and their extensions to concurrent systems
TERA COMPUTER CO SEATTLE WA User Process Checkpoint/Restart. Revision 1.1.
Carpenter Wull ye come in eärly spring/John Alden Carpenter; poem by William Barnes.