ES2963703T3 - Procedimientos, dispositivos y sistemas para actualizaciones no disruptivas de un motor de coordinación distribuida en un entorno informático distribuido - Google Patents

Abstract

Un método implementado por computadora y un sistema distribuido para mantener la coherencia de las aplicaciones cliente en una pluralidad de nodos servidores puede comprender proporcionar una primera y una segunda versión de un motor de coordinación distribuida (DConE). La primera versión del DConE puede recibir propuestas, llegar a acuerdos al respecto y generar un primer orden de acuerdos que especifica un orden en el que las aplicaciones del cliente deben ejecutar las propuestas acordadas y actualizar correspondientemente sus respectivos estados. Luego, la primera versión del DConE puede procesar una propuesta de cambio de versión, tras lo cual la primera versión del DConE puede dejar de llegar a más acuerdos. Una segunda versión del DConE puede entonces hacerse cargo de llegar a acuerdos sobre las propuestas y generar un segundo orden de acuerdos, comenzando con la propuesta de Versión de Cambio acordada. Cualquier propuesta acordada, recibida de la primera versión del DConE después de la propuesta de ChangeVersion acordada, puede enviarse de regreso a la segunda versión del DConE para permitir que la segunda versión del DConE llegue a un acuerdo al respecto. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Procedimientos, dispositivos y sistemas para actualizaciones no disruptivas de un motor de coordinación distribuida en un entorno informático distribuido

ANTECEDENTES

El campo de las realizaciones divulgadas en la presente memoria descriptiva incluye sistemas distribuidos. En particular, las realizaciones se dirigen a un sistema distribuido (y la funcionalidad habilitada por el mismo) que utiliza instancias de un motor de coordinación distribuida sobre una Red de Área Amplia (WAN) para aceptar propuestas y generar acuerdos ordenados correspondientes que son consumidos por las aplicaciones. Sin embargo, el motor de coordinación distribuida debe actualizarse de vez en cuando, sin interrumpir la aplicación para la cual el motor de coordinación distribuida está generando acuerdos ni interrumpir el flujo de propuestas y acuerdos.

El documento de patente US2016/105507 es un procedimiento implementado por ordenador que comprende procesar acuerdos recibidos a través de una red informática en una primera máquina de estados replicada implementada en procesos que pertenecen a una primera membresía en un orden definido por un primer conjunto de acuerdos ordenados globalmente asociados con la primera membresía. El procedimiento además comprende recibir un acuerdo para cambiar de membresía que está configurado para provocar que la primera máquina de estados replicada se implemente en procesos que pertenecen a una segunda membresía que está asociada con un segundo conjunto de acuerdos ordenados globalmente y procesar el acuerdo para cambiar de membresía en un punto dentro del primer conjunto de acuerdos ordenados globalmente.

El documento de patente US2014/189004 es un procedimiento implementado por ordenador para implementar una membresía de nodos en un sistema informático distribuido que puede comprender seleccionar nodos para que formen parte de una membresía de nodos. El procedimiento crea una tarea de membresía que identifica un nodo creador de membresía como el nodo que está creando la membresía y que comprende un objetivo de membresía que identifica al menos un nodo del sistema informático distribuido que se convertirá en miembro de la membresía; y además crea una baliza configurada para enviar un mensaje de creación de membresía a cada nodo identificado, comprendiendo el mensaje de creación de membresía al menos una identidad de la tarea de membresía y una identificación de la membresía. Al recibir una respuesta de un nodo en el objetivo de membresía, el nodo del cual se recibió la respuesta puede ser eliminado de la baliza. La membresía se puede implementar cuando se haya recibido una respuesta de cada uno de los nodos identificados en el objetivo de membresía.

SUMARIO DE LA INVENCIÓN

En un primer aspecto de la invención se proporciona un sistema distribuido de acuerdo con la reivindicación 1. En otro aspecto de la invención, se proporciona un procedimiento implementado por ordenador para mantener la coherencia de las aplicaciones de cliente en una pluralidad de nodos de servidor, siendo el procedimiento de acuerdo con la reivindicación 6.

Las realizaciones preferentes se definen en las reivindicaciones dependientes.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

La Figura 1 es un diagrama de bloques de un sistema configurado de acuerdo con una realización.

La Figura 2 es un diagrama de una propuesta de acuerdo con una realización.

La Figura 3 es un diagrama de una propuesta de cliente como formateada y/o almacenada en la cola de entrada, de acuerdo con una realización.

La Figura 4 es un diagrama que ilustra una propuesta acordada (por ejemplo, un acuerdo), como formateada y/o almacenada en la cola de salida de acuerdo con una realización.

La Figura 5 es un diagrama de bloques que ilustra un sistema distribuido de acuerdo con una realización y que muestra diversos aspectos del procedimiento implementado por ordenador para mantener la coherencia de las aplicaciones de cliente en dicho sistema distribuido.

La Figura 6 es un diagrama de flujo de un procedimiento implementado por ordenador de acuerdo con una realización.

La Figura 7 es un diagrama de bloques de un dispositivo informático con el que se pueden poner en práctica las realizaciones mostradas y descritas en la presente memoria descriptiva.

DESCRIPCIÓN DETALLADA

Definiciones

Sistema distribuido: un sistema distribuido comprende una colección de procesos distintos que pueden estar separados espacialmente y que pueden comunicarse entre sí mediante el intercambio de mensajes o eventos. Máquina de estados replicada: un enfoque de máquina de estados replicada es un procedimiento para implementar un servicio tolerante a fallos replicando servidores y coordinando las interacciones del cliente con las réplicas del servidor. Estas máquinas de estados se “replican”, ya que el estado de la máquina de estados evoluciona de manera idéntica en todos los aprendices. Las réplicas de un único servidor se ejecutan en procesadores separados de un sistema distribuido y se utilizan protocolos para coordinar las interacciones del cliente con estas réplicas. Un ejemplo e implementación de una máquina de estados replicada es una máquina de estados determinista que consume su estado de manera determinista.

Acuerdos: Un acuerdo es uno seleccionado entre una pluralidad potencial de eventos de propuestas generados por los Proponentes y entregados a los Aprendices.

Secuencia global de acuerdos: De acuerdo con una realización, las propuestas de los clientes se presentan y acuerdan al menos por una mayoría de Aceptadores y se entregan en una secuencia global de acuerdos. Los nodos de servidor y las aplicaciones de cliente que reciben la secuencia global de acuerdos pueden luego ejecutar las transacciones subyacentes en el orden especificado por la secuencia global de acuerdos y actualizar su estado, por consiguiente, asegurando así que todas las aplicaciones de cliente se actualicen en el mismo orden.

Motor de coordinación/acuerdo distribuido (DConE): una realización requiere que un motor de coordinación o acuerdo genere una secuencia global ordenada de transacciones acordadas a través de una implementación novedosa de nivel de producción del protocolo de consenso de Paxos. Un DConE ejemplar se describe en la Solicitud de Patente de EE. UU. cedida comúnmente, con número de serie 12/069.986 presentada el 13 de febrero de 2008 (publicada como US 2008-0140726). DConE es una máquina de estados replicada determinista, continuamente disponible y tolerante a fallos. DConE funciona recopilando eventos generados por los Proponentes, organizándolos en una secuencia global ordenada con la ayuda de los Aceptadores y entregándolos en esa secuencia a los Aprendices. Los Aprendices implementan su lógica de negocios (implementando transacciones, por ejemplo) manejando la secuencia ordenada de eventos entregados. DConE garantiza la entrega de cada evento de propuesta de transacción al menos una vez a cada nodo de aprendiz en la misma secuencia global ordenada de propuestas acordadas.

Sin bloqueo: En la presente memoria descriptiva, el término “sin bloqueo” se refiere a la capacidad de un conjunto de procesos de permanecer total o parcialmente disponible mientras se realizan cambios en ese conjunto.

Proponentes: De acuerdo con una realización, los proponentes son procesos que están configurados y habilitados para sugerir transacciones (propuestas para realizar cambios en el estado de una aplicación, un conjunto de datos y similares).

Aceptadores: De acuerdo con una realización, los aceptadores son procesos que están configurados para participar en la decisión sobre el orden de las propuestas realizadas por los proponentes. De acuerdo con una realización, sólo cuando una mayoría de aceptadores ha determinado que una propuesta ocupa un lugar particular en la secuencia global de acuerdos se convierte en un acuerdo (por ejemplo, una propuesta acordada). Los aceptadores, de acuerdo con una realización, pueden configurarse para participar solo en la decisión sobre el orden de los acuerdos y no razonar/preocuparse por el contenido subyacente de los acuerdos (como se describe en la presente memoria descriptiva, el valor del acuerdo es opaco para el DConE). Los aceptadores pueden configurarse como entidades independientes de la aplicación.

Aprendices: De acuerdo con una realización, los aprendices aprenden de los acuerdos realizados entre los proponentes y los aceptadores y aplican los acuerdos en un orden determinista a la solicitud a través de su secuencia de propuesta de salida. En una realización, se proporciona una identidad de acuerdo, al igual que un almacén persistente que, para cada máquina de estados replicada, permite registrar de manera persistente una secuencia de acuerdos. Se garantiza que cada propuesta se entregará al menos una vez a cada Aprendiz de una membresía en particular.

Motor de Coordinación Distribuida (DConE)

De acuerdo con una realización, DConE implementa una versión empresarial mejorada del algoritmo Paxos. De acuerdo con el algoritmo Paxos, se instala una máquina de estados replicada con cada nodo del sistema distribuido. Luego, las máquinas de estados replicadas funcionan como pares para entregar un enfoque cooperativo para la gestión de transacciones de intercambio que garantiza el mismo orden de transacción en cada nodo, aunque no necesariamente al mismo tiempo. Las máquinas de estados replicadas en los nodos de servidor que implementan el algoritmo Paxos pueden cumplir uno de tres roles: (1) Proponentes; (2) Aceptadores; y (3) Aprendices. Hay tres fases en el algoritmo Paxos, que pueden repetirse durante el proceso de llegar a un consenso: (1) elección de un nodo como coordinador o Proponente; (2) transmisión de la propuesta de transacción a sus pares que luego asumen el rol de Aprendices, quienes aceptan o rechazan la propuesta; y (3) aceptación, una vez que la mayoría de los nodos reconocen al Proponente y aceptan su propuesta, permitiendo alcanzar un consenso. La máquina de estados replicada que asumió el rol de coordinador luego transmite un mensaje de confirmación para notificar a todos sus pares que continúen con la transacción.

Para evitar escenarios en los que varios nodos intentan actuar como coordinadores de la misma propuesta, Paxos asigna un orden a los sucesivos nodos coordinadores y restringe la elección de cada coordinador al seleccionar un valor que se acordará para el número de propuesta. Para respaldar esto, cada nodo realiza un seguimiento del número de secuencia de la propuesta acordada más reciente que ha visto. Cuando un nodo emite una propuesta, genera un número de secuencia para la propuesta con un valor superior al último que conoció y lo transmite a los demás nodos. Si la mayoría de los otros nodos responden indicando que no han visto un número de secuencia mayor, el nodo puede actuar como coordinador o líder de la propuesta. En este punto, los demás coordinadores no pueden proceder hasta que se llegue a un consenso sobre la propuesta actual. El número de secuencia del proponente no puede ser utilizado por otros nodos que intenten ser coordinadores al mismo tiempo, y todas las propuestas futuras deben utilizar un número de secuencia más alto para lograr consenso para transacciones futuras.

Llegar a un consenso con DConE

Con el fin de comprender el enfoque de DConE para el procesamiento de transacciones distribuidas, a continuación, se detallan los componentes principales de cada instancia de DConE que respaldan su capacidad de replicación activa-activa: el administrador de propuestas, el secuenciador local, el administrador de acuerdos y el secuenciador global. Cuando se envía una propuesta al sistema distribuido para que la procese un cliente en cualquier nodo, el componente administrador de propuestas de la instancia local de DConE genera una propuesta para la transacción, que incluye los datos de transacción. Dichos datos de transacción pueden incluir al menos la identificación del cliente y el cambio propuesto. Luego, la instancia DConE asigna un número de secuencia local (LSN) a la propuesta. El LSN refleja el orden en el que se envió la transacción en relación con todas las demás transacciones en esa ubicación. Los LSN no necesitan ser números consecutivos, simplemente únicos. Luego, el secuenciador local guarda la propuesta con el número de secuencia local asignado en su registro de propuestas. Si se produce una interrupción de la red o del servidor antes de que la instancia local de DConE pueda enviar la propuesta a sus pares durante el proceso de acuerdo que se describe a continuación, volverá a enviar esa propuesta después de que se recupere.

A continuación, el administrador de acuerdos de DConE determina un número de acuerdo, que representa un número de secuencia global (GSN) propuesto para la propuesta que la instancia local de DConE enviará a sus pares en otros nodos. De acuerdo con Paxos, el número de acuerdo es simplemente un incremento del GSN de la última propuesta aceptada por todos los nodos. Este número de acuerdo se utiliza luego para obtener consenso sobre el orden de la propuesta en todos los nodos, de modo que se mantenga la equivalencia de una copia. La propuesta con el número de acuerdo se puede escribir en el registro de acuerdos. El registro de acuerdos o el libro mayor replicado de cada instancia de DConE contiene al menos todos los acuerdos completados, independientemente del nodo de servidor en el que se originaron los acuerdos completados. En caso de una interrupción de la red, el registro de acuerdos indicará dónde quedó el nodo antes de perder su conexión con los otros nodos en el sistema distribuido, lo que lo hace útil durante el proceso de recuperación automatizada del DConE.

Luego, el administrador de acuerdos de la instancia DConE local puede iniciar un protocolo de acuerdo y la propuesta puede enviarse a sus pares. Una vez que el quórum de los pares de la instancia DConE llega a un acuerdo sobre la propuesta, el número de acuerdo se utiliza como GSN en todos los nodos, ya que ahora se ha logrado el orden de las transacciones globales. El concepto de quórum permite a DConE llegar a un acuerdo sin necesidad de que todos los nodos estén disponibles o estén de acuerdo. El concepto de quórum es un elemento importante del desempeño de DConE, así como de su tolerancia a fallos.

Si el acuerdo se ve adelantado por una propuesta competidora, el administrador de acuerdos intenta repetidamente llegar a un acuerdo con un nuevo número de acuerdo. Cada vez que se vuelve a intentar llegar a un acuerdo, se crea una entrada con el nuevo número de acuerdo en el registro de acuerdos. Una vez que se llega a un acuerdo mediante quórum, el nodo de aplicación local pone en cola la propuesta acordada en su secuencia global. En este punto, la instancia DConE local pasa la transacción a su respectivo programador de bloqueo para su procesamiento, en el orden numérico de secuencia global acordado. Es importante señalar que la instancia DConE en la que se originó la propuesta no espera a que ninguno de los otros nodos complete la ejecución de la transacción; sólo espera que se llegue a un acuerdo, lo que permitirá a los usuarios experimentar un rendimiento de velocidad LAN a través de una WAN.

Preservar la Secuencia Local

Debido a que DConE soporta acuerdos simultáneos por motivos de desempeño, es posible que el quórum llegue a un acuerdo fuera de orden. Es decir, es posible llegar a un acuerdo sobre una propuesta que se presentó después de una propuesta enviada previamente y aún no acordada en otro nodo.

Recuérdese que DConE toma propuestas de múltiples nodos de servidor, las recopila en un orden global único y lo hace accesible a todos los demás nodos de servidor. Considérese también una aplicación construida sobre DConE. A veces es deseable, para un determinado nodo de servidor, implementar un proceso por orden de llegada o primero en entrar primero en salir (FIFO) en el manejo de las propuestas en función de su hora de llegada y asegurarse de que se emiten en el mismo orden. Este tipo de ordenación puede estar exigida, por ejemplo, por una política de equidad o una restricción de ordenación causal, que son dos requisitos que se cumplen, de acuerdo con una realización, mediante la captura y el logro de consenso sobre todas las propuestas emitidas por la pluralidad de nodos de servidor. Cualquier post-procesamiento se realiza de forma determinista. Como la emisión resultante de DConE es idéntica en todos los nodos de servidor, una propiedad de DConE, la emisión de la etapa de post-procesamiento dará como resultado una secuencia idéntica de acuerdo en todos los nodos de servidor, que luego se consumen en el orden exigido por GSN para mantener la coherencia en todas las aplicaciones.

Lo siguiente ilustra una realización que permite a DConE determinar la ordenación global de las transacciones preservando al mismo tiempo la secuencia local de envío de propuestas. Supóngase que un nodo de servidor envía sus dos primeras propuestas a DConE y el administrador de propuestas asigna LSN 1 y LSN 2 a las propuestas respectivas. Supongamos además que se han acordado un total de 25 propuestas con GSN del 1 al 25 y que los otros nodos de servidor no han presentado propuestas intermedias. Supóngase además que el quórum llegó a un acuerdo sobre el LSN 2 antes de llegar a un acuerdo sobre el LSN 1. Si la secuencia local no importara para la solicitud, entonces el LSN 2 tendría el número de acuerdo y el GSN 26, y el LSN 1 tendría el número de acuerdo y el GSN 27. Luego, las propuestas se escribirían en ese orden en todos los nodos de servidor. Si el requisito es garantizar que la secuencia local se preserve en todos los nodos independientemente de dónde se originen las propuestas, una realización utiliza una combinación del LSN, el número de acuerdo, que en este caso puede terminar siendo o no el GSN, y la identificación del proponente, que representa un identificador único global para la instancia DConE donde se originó la propuesta, para construir una secuencia global que preserve el orden de la secuencia local. En efecto, la secuencia global se clasifica en orden de secuencia local dentro de la identificación del proponente y se pasa al programador de bloqueo, que se analiza a continuación, en cada nodo de servidor.

El Programador de Bloqueo

El programador de bloqueo en cada nodo de servidor en el que DConE pasa propuestas acordadas a la aplicación que se ejecuta en cada uno de los nodos de servidor. El programador de bloqueos se comporta como un programador de base de datos, no como un administrador de bloqueos distribuido. El término “programador de bloqueo” proviene del hecho de que se basa en los bloqueos especificados por la aplicación para el control de concurrencia, de modo que se pueden procesar en paralelo una gran cantidad de transacciones no conflictivas. El programador de bloqueo es agnóstico con respecto al orden global. El orden en el que el programador de bloqueo envía transacciones a la aplicación subyacente en cada sitio está impulsado por una cola local de eventos secuenciados globalmente (la cola GSN) que se le pasa desde su respectiva instancia DConE en ese nodo de servidor. Esto permite que los programadores de bloqueo completamente locales en cada nodo de servidor logren una equivalencia de una copia sin ningún conocimiento del estado global. En una realización, es el programador de bloqueo el que interactúa con la aplicación subyacente, y no DConE directamente.

Lograr Rendimiento y Escalabilidad

DConE extiende significativamente la funcionalidad del algoritmo Paxos, permitiendo así un rendimiento mejorado a escala. Dicha funcionalidad extendida incluye quórum, manejo de acuerdos simultáneos, retroceso y prevención de colisiones, evolución dinámica de grupos, recolección de basura distribuida, números redondos distinguidos y justos para propuestas y reservas débiles, para identificar solo algunas áreas abarcadas por dicha funcionalidad extendida.

Quórum

El concepto de quórum utilizado por DConE permite optimizar el rendimiento y minimizar el impacto de las interrupciones de la red y del servidor en función de la distribución de los clientes y la actividad entre los nodos de servidor. Las opciones de configuración de quórum disponibles incluyen mayoría, singleton y unánime. El sistema distribuido puede configurarse para operar con un consenso que se logra mediante un quórum mayoritario, aunque también es posible un consenso único y unánime. En el quórum de mayoría, se requiere que la mayoría de los nodos de servidor respondan a cualquier propuesta. DConE también soporta el concepto de un nodo distinguido que puede actuar como desempate en caso de que haya un número par de nodos de servidor en el sistema distribuido. Con un quórum de singleton, sólo un nodo tiene que responder a las propuestas. El nodo de servidor seleccionado como quórum de singleton bajo esta configuración puede ser el nodo de servidor que tenga la mayor cantidad de clientes y nivel de actividad comercial. El beneficio es que no se genera tráfico de red de área amplia (WAN) durante el proceso de acuerdo en el nodo de servidor con el mayor volumen de transacciones. El acuerdo lo maneja en su totalidad la instancia DConE local en el nodo de quórum. Los otros nodos de servidor envían sus propuestas para obtener el acuerdo del nodo de quórum de singleton, pero generalmente experimentan un rendimiento rápido porque solo requieren que el nodo de servidor singleton designado acepte sus propuestas, no que las complete, antes de entregárselas a sus respectivos programadores de bloqueo locales. El quórum unánime requiere que todos los nodos de servidor respondan y es inherentemente la configuración menos eficiente y la que genera la mayor cantidad de tráfico WAN.

DConE también soporta la rotación del quórum de una región a otra basándose en un modelo de seguimiento del sol. Esto permite optimizar el rendimiento sobre la base de las horas de trabajo normales en cada sitio en un sistema distribuido globalmente. Además, el enfoque de quórum funciona en combinación con las funciones de recuperación automatizada de DConE para minimizar el impacto de las interrupciones de la red y las caídas del servidor en un sistema distribuido.

Acuerdo Concurrente

El algoritmo Paxos sólo permite llegar a un acuerdo sobre una propuesta a la vez. Esto tiene el efecto obvio de ralentizar el rendimiento en un entorno de alto volumen de transacciones. DConE permite que múltiples propuestas de múltiples proponentes progresen simultáneamente, en lugar de esperar a que todos o un quórum de los nodos de servidor alcancen un acuerdo propuesta por propuesta.

Retroceso y Prevención de Colisiones

DConE proporciona un mecanismo de retroceso para evitar la repetida prevención de los proponentes por parte de sus pares. Las máquinas de estados replicadas convencionales permiten al proponente prevenido iniciar inmediatamente una nueva ronda con un número de acuerdo mayor que el del prevenido. Este enfoque puede hacer que un protocolo de acuerdo se deteriore durante un período prolongado y degrade gravemente el rendimiento. Con DConE, cuando se adelanta una ronda, la instancia de DConE que inició la propuesta calcula la duración del retraso de retroceso. Luego, el proponente espera este período antes de iniciar la siguiente ronda. DConE utiliza un enfoque similar a los protocolos de Detección De Colisiones/Acceso Múltiple con Detección de Operador (CSMA/CD) para Ethernet no conmutada.

Copia de Seguridad y Recuperación Automatizadas

La capacidad de replicación activa-activa de DConE ofrece una copia de seguridad activa continua de forma predeterminada al convertir cada nodo de servidor en un espejo de los demás. Esto se aprovecha para proporcionar recuperación automatizada a través de una WAN o LAN cuando un nodo de servidor se queda atrás debido a fallas de la red o del servidor. No se requiere intervención manual. Si un nodo de servidor en el sistema distribuido pierde contacto con sus pares, pero todavía está disponible para los clientes en su ubicación, esos clientes seguirán teniendo acceso de lectura al sistema distribuido, pero no podrán iniciar propuestas, ya que el proceso de acuerdo no puede proceder. Esto evita que surja un escenario de cerebro dividido que provocaría que el nodo de servidor no estuviera sincronizado con sus pares, violando así el requisito de una equivalencia de copia en todos los nodos de servidor. Sin embargo, aún se pueden enviar propuestas en los nodos de servidor restantes, siempre que todavía haya quórum disponible. Esto minimiza el impacto de las interrupciones de la red y las fallas del servidor en el sistema distribuido. Tan pronto como el nodo de servidor fallido vuelve a estar en línea, su instancia DConE se pone al día automáticamente con todas las propuestas acordadas por sus pares mientras estaba fuera de línea. Esto se puede lograr utilizando el registro de acuerdos. El registro de acuerdos contiene la última propuesta acordada en el nodo de servidor antes de que ocurriera la interrupción. Cuando comienza el proceso de recuperación, la instancia DConE del nodo de servidor solicita a sus pares todos los acuerdos después de la última transacción registrada en su registro de acuerdos. Además, cualquier propuesta dejada en el registro de propuestas que no completó el proceso de acuerdo se vuelve a enviar automáticamente por la instancia DConE local, una vez que se completa la puesta al día. Esto significa que, independientemente de si se produce una interrupción antes o después de llegar a un acuerdo sobre cualquier propuesta entre los nodos de servidor en un sistema distribuido, no se perderá ningún dato.

Además, las capacidades de recuperación automatizada de DConE eliminan la necesidad de soluciones de duplicación de disco que solo funcionan a través de una LAN, no de una WAN, y requieren la intervención del administrador para lograr la recuperación. Como resultado, estas soluciones pueden introducir el riesgo de un tiempo de inactividad prolongado y pérdida de datos debido a errores humanos. Finalmente, las funciones de recuperación automatizada de DConE también permiten desconectar los servidores para su mantenimiento sin interrumpir el acceso de los usuarios, ya que los clientes pueden ser redirigidos a un nodo de servidor en otro sitio mientras el suyo está desconectado. Esto hace posible la operación completa las 24 horas del día, los 7 días de la semana en un entorno distribuido globalmente.

La Figura 1 es un diagrama de un sistema distribuido que utiliza un motor de coordinación distribuida (DConE) de acuerdo con una realización. De acuerdo con una realización, se puede proporcionar y coordinar una pluralidad (preferentemente impar) (por ejemplo, 3, 5, 7...) de nodos de servidor, a través de una red informática, mediante un único DConE 108 o instancias separadas de DConE 108. Únicamente con fines ilustrativos, en la Figura 1 se muestran tres nodos de servidor 102, 104, 106, cada uno de ellos acoplado a una instancia de DConE 108. De hecho, DConE 108 puede configurarse como un agente o instancia en cada nodo o grupo de nodos (que pueden estar muy separados entre sí), con los agentes o instancias coordinándose entre sí a través de una red como una LAN o una WAN como Internet. De acuerdo con una realización, los acuerdos generados por las instancias DConE 108, iniciados en uno de los nodos de servidor 102, 104 o 106, se propagan a los otros nodos de servidor de manera coherente por medio del DConE 108. De esta manera, las aplicaciones de cliente pueden depender de acuerdos coherentes y ordenados que se distribuyen y/o replican en todos los nodos de servidor acoplados al sistema distribuido. Los procedimientos de replicación descritos en la presente memoria proporcionan un modelo activo-activo de alta disponibilidad para un sistema distribuido y permiten el equilibrio de carga entre los nodos de servidor constituyentes del sistema distribuido.

El DConE 108 puede estar configurado para determinar el orden global de los acuerdos (por ejemplo, actualizaciones de un libro mayor distribuido que registra todas las transacciones que ocurren en un intercambio o mercado, cambios en el proyecto de software controlado por versión y/o cambios en cualquier base de datos distribuida o aplicación de cliente). Como todas las máquinas de estados replicadas o aplicaciones de cliente comienzan en el mismo estado y como se hace que todos los nodos de servidor apliquen actualizaciones en el mismo orden determinista (pero no necesariamente, de acuerdo con las realizaciones, al mismo tiempo), el estado de las máquinas de estados replicadas o las aplicaciones de cliente permanecerán coherentes (o alcanzarán la coherencia) en todos los nodos.

De acuerdo con una realización, y como se muestra en la Figura 1, la coherencia de los acuerdos sobre múltiples nodos de servidor 102, 104, 106 se puede lograr de la siguiente manera. Como se muestra en (1), uno de los nodos de servidor (en este caso, el nodo de servidor 102) recibe una solicitud de cliente o una propuesta de un cliente, tal como una propuesta para realizar un cambio en un espacio de nombres, el estado de una aplicación, una solicitud para comprar o vender una cantidad específica de bienes o servicios que eventualmente provocará una actualización de un libro mayor distribuido, una propuesta para realizar un cambio en una base de datos o una propuesta para añadir bloques de datos a un archivo, crear un archivo o crear un directorio, por ejemplo. Como se muestra en la Figura 2, las solicitudes o propuestas de cliente 200, de acuerdo con una realización, pueden formarse como tuplas, y cada una de dichas tuplas puede incluir un identificador de solicitud único proporcionado por el cliente como se muestra en 202, un tipo de propuesta 204 que determina si la propuesta es una propuesta de aplicación (una propuesta para cambiar el estado de la aplicación) o una propuesta de control de DConE (una propuesta para ser utilizada internamente por DConE), un identificador de cliente único 206 y un conjunto de bytes que forman la solicitud de propuesta 208, que forma la carga útil de la propuesta de cliente 200. La carga útil de la propuesta del cliente, mostrada en 208 en la Figura 2, puede ser opaca para el DConE 108. Por lo tanto, una propuesta de control de DConE está dirigida al DConE para su procesamiento, en lugar de a una solicitud de cliente. Un ejemplo de una propuesta de control de DConE es una propuesta para que el DConE cambie su membresía, como se establece en la patente US 9.332.069 de propiedad común.

Volviendo ahora a la Figura 1 y al ejemplo que se desarrolla en la misma, el nodo de servidor 104 recibe una propuesta 1 y el nodo de servidor 106 recibe una propuesta 2. De acuerdo con una realización, en lugar de que el nodo de servidor 102 actualice inmediatamente el estado de su aplicación con el evento (por ejemplo, leer, escribir, eliminar, etc.) encapsulado dentro de la propuesta 3, el nodo de servidor 104 actualiza inmediatamente el estado de su aplicación con el evento encapsulado dentro de la propuesta 1 recibida y el nodo de servidor 106 actualiza inmediatamente el estado de su aplicación, espacio de nombres y similares con los eventos encapsulados dentro de la propuesta 2, y luego propagando dichas actualizaciones a las otras aplicaciones en los nodos de servidor 102, 104, 106, estas solicitudes de cliente separadas se pasan como propuestas, desde una cola compartida persistente (una base de datos relacional, por ejemplo) al DConE 108, que los envía de vuelta a los nodos de servidor 102, 104, 106 como una lista ordenada de acuerdos, después de que la mayoría de los nodos Aceptadores hayan llegado a un acuerdo al respecto (el acuerdo se alcanza por consenso por cualquier protocolo de consenso que esté en vigor), como se describe en la presente memoria.

Es decir, como se muestra en la Figura 1, en respuesta a la recepción de la propuesta 3 (por ejemplo, solicitud de cliente 3), el nodo de servidor 102 puede emitir una propuesta Prop3 al DConE 108 como se muestra en (2). De manera similar, en respuesta a la recepción de la propuesta 1 (por ejemplo, solicitud de cliente 1), el nodo de servidor 104 puede emitir una propuesta Propl al DConE 108 como se muestra en (2) y en respuesta a la recepción de la propuesta 2 (por ejemplo, solicitud de cliente 2), el nodo de servidor 106 puede emitir una propuesta Prop2 al DConE 108 como también se muestra en (2). El DConE 108, de acuerdo con una realización, luego obtiene acuerdos a través del consenso de una mayoría de nodos Aceptadores, serializa las propuestas acordadas, ordena las propuestas que recibe como se muestra en (3) y alimenta de manera idéntica aquellas propuestas que se han acordado como una cola de salida persistente de acuerdos ordenados globalmente (en este caso, ordenados como AGR3 seguido de AGR1 seguido de AGR2) de vuelta a las aplicaciones que se ejecutan en los nodos de servidor 102, 104, 106, como se muestra en (4). Las aplicaciones de cliente en los nodos de servidor 102, 104 y 106, al recibir la secuencia ordenada de acuerdos AGR3, AGR1 y AGR2, implementan estos acuerdos en ese orden determinista y actualizan correspondientemente sus respectivos estados de modo que cada uno se mantenga coherente (y/o llevados hasta la coherencia) a través de los nodos de servidor 102, 104, 106. De esta manera, los estados de las aplicaciones pueden actualizarse de forma asincrónica, como se sugiere en (5), sin pérdida de coherencia. Estas actualizaciones pueden luego (pero no es necesario) guardarse como transacciones de diario en el respectivo almacenamiento persistente local 110, 112, 114 que puede (pero no es necesario, como lo indican las líneas discontinuas en 110, 112 y 114) estar acoplado o ser accesible para los nodos de servidor 102, 104, 106. Luego, se pueden devolver notificaciones a los clientes que han enviado las solicitudes de cliente según corresponda.

Por lo tanto, de acuerdo con una realización, los nodos de servidor 102, 104, 106 no registran directamente las solicitudes de los clientes, sino que las reempaquetan y redirigen como propuestas al DConE 108 para su acuerdo mediante consenso, serialización y ordenación. Las actualizaciones del estado de las aplicaciones y/o bases de datos almacenadas en estos nodos de servidor son luego emitidas desde y por el DConE 108 como un conjunto de acuerdos persistentes y ordenados globalmente. Esto garantiza que la aplicación en cada nodo de servidor 102, 104, 106 se actualice cuando finalmente se implemente la solicitud del cliente, de modo que las actualizaciones se aplicarán de manera transparente y coherente a todas las aplicaciones previstas en los nodos de servidor en el clúster. De esta manera, el estado de las aplicaciones en cada uno de la pluralidad de nodos de servidor en todo el sistema distribuido puede mantenerse, a lo largo del tiempo, en un estado coherente.

Por lo tanto, un papel importante del DConE 108, de acuerdo con una realización, es procesar las solicitudes de los clientes como propuestas recibidas desde los nodos de servidor y transformarlas en una secuencia ordenada global persistente de acuerdos. Los nodos de servidor (que pueden estar ampliamente separados por geografía y zonas horarias) pueden luego implementar los cambios o transacciones subyacentes a los acuerdos de esa secuencia de acuerdos ordenada globalmente y alimentar los cambios o actualizaciones ordenados a las aplicaciones de los clientes.

Como se muestra en la Figura 3, una tupla de propuesta puede codificarse en un formato que es invariante entre las versiones de DConE, ya sea que la propuesta sea una propuesta de aplicación o una propuesta de control. La propuesta de cliente 300, tal como se almacena en la cola de entrada al DConE 108, puede incluir la propuesta de cliente 200, emparejada con un número de secuencia local o LSN 302. En operación, al crear la propuesta que se enviará al DConE 108, el nodo de servidor le da a la propuesta un LSN, que puede ser un número entero simple. En una implementación, el LSN es local únicamente para el nodo de servidor. En operación normal, el proceso DConE 108 saca de la cola una propuesta de cliente de la cola de entrada, llega a un acuerdo con los otros nodos Aceptadores y asigna un número de secuencia global (GSN) a la propuesta. El DConE 108 puede entonces enviar la propuesta así ordenada globalmente a una cola de salida persistente compartida denominada cola de salida. En una implementación, se puede usar una base de datos relacional para recibir y almacenar las propuestas ordenadas globalmente, que salen del DConE para ser consumidas por la aplicación o por el propio DConE si la propuesta es una propuesta de control. El formato de cada una de las entradas en las propuestas persistentes ordenadas globalmente puede incluir el GSN y la propuesta. El formato y la codificación de esto pueden ser invariantes entre las versiones de DConE. Luego, las aplicaciones en los nodos de servidor sacan de la cola y procesan la propuesta acordada y ordenada (si es una propuesta de aplicación) en el orden especificado por el orden de<g>S<n>desde la cola de salida. El DConE 108 procesa las propuestas de control cuando, según el GSN, les toca ejecutar el acuerdo.

El GSN puede estar configurado, de acuerdo con una realización, como un número único que aumenta monótonamente, pero puede configurarse de otra manera, como podrán reconocer los expertos en esta técnica. El GSN también se puede utilizar para comparar el progreso de diferentes nodos de servidor en la actualización del estado de su aplicación y para mantener el estado de la misma coherente entre los nodos de servidor. Por ejemplo, si el nodo de servidor 102 acaba de procesar un acuerdo numerado GSN1, que es más pequeño que el GSN2 que acaba de procesar el nodo de servidor 104, se deduce que la instancia de la aplicación en el nodo de servidor 102 se encuentra actualmente en un estado anterior a la instancia de la aplicación en el nodo de servidor 104.

De acuerdo con una implementación y como se muestra en la Figura 4, el GSN 402 para una propuesta acordada 300 puede ser en sí mismo una tupla que consiste en dos partes, el número de versión 404 de DConE bajo el cual se llegó al acuerdo y un número de secuencia global. 406 dentro de esa versión del DConE, en la forma de, por ejemplo, {número-versión, número-secuencia-versión}. Una aplicación solo sacará de la cola y procesará los GSN de la cola de salida persistente de acuerdos que coincidan con el número de versión actual de DConE hasta que se le indique que cambie el número de versión, lo que hace que la aplicación comience a procesar acuerdos emitidos desde un DConE (por ejemplo, actualizado) tiene un número de versión diferente. Como se indicó anteriormente, una de las razones por las que un DConE tiene un número de versión diferente es la necesidad periódica de actualizar el DConE.

De acuerdo con una realización, las solicitudes de lectura de los clientes no requieren que el DConE 108 llegue a un consenso, sólo escribe. Cabe señalar que, de acuerdo con una realización, el DConE 108 no garantiza que las instancias de la aplicación de cliente subyacente sean idénticas en todos los nodos de servidor en todo momento. Más bien, el DConE 108 garantiza que las aplicaciones de cliente en el nodo de servidor 102, 104, 106 aprenderán de manera coherente cada acuerdo en el mismo orden que todos los demás nodos de servidor. De esta manera, el DConE 108 está configurado para generar una secuencia ordenada globalmente de propuestas acordadas que se suministra de manera idéntica a todos los nodos de servidor 102, 104, 106 para generar actualizaciones predecibles y ordenadas secuencialmente para las aplicaciones de cliente. A su vez, esto garantiza que los acuerdos sean consumidos por cada instancia de las aplicaciones de cliente que se ejecutan en cada nodo de servidor en el mismo orden, lo que hace que cada instancia de las mismas evolucione de una manera predecible, a prueba de manipulaciones y determinista.

De acuerdo con una realización, se pueden llevar a cabo actualizaciones de los diarios almacenados en el almacenamiento persistente local 110, 112, 114. Sin embargo, la coherencia de las aplicaciones de cliente en los nodos de servidor 102, 104, 106 no depende de dichas actualizaciones de los diarios y cada uno de los almacenamientos persistentes (si están presentes), de acuerdo con una realización, es local para un nodo de servidor y no se comparte a través de la red con otros nodos de servidor. De manera similar, mantener la coherencia de las aplicaciones de cliente entre los nodos de servidor 102, 104, 106 no depende de compartir otros recursos, tales como memoria o recursos de procesador.

No hay ningún nodo de servidor preferido (maestro o distinguido de otro modo) en el sistema distribuido, según las realizaciones. De hecho, si uno o más nodos de servidor fallan o se desconectan por mantenimiento (o por cualquier otro motivo), otros nodos de servidor activos están disponibles para atender las solicitudes (propuestas) de los clientes sin ninguna interrupción en el acceso. De acuerdo con una realización, tan pronto como un nodo de servidor previamente inactivo vuelve a estar en línea, puede resincronizarse automáticamente con los otros servidores de nodos de servidor. Dicha sincronización puede comprender el aprendizaje de todas las propuestas acordadas que fueron emitidas por el DConE 108 desde que el nodo de servidor se cayó o se desconectó. Se eliminan tanto la condición de cerebro dividido como la pérdida de datos, ya que las aplicaciones de cliente en todos los nodos de servidor siempre se mantienen o se llevan al sincronismo, proporcionando así una copia de seguridad activa continua de forma predeterminada. Tanto la conmutación por error como la recuperación son inmediatas y automáticas, lo que elimina aún más la necesidad de intervención manual y el riesgo de error del administrador. Además, ninguno de los nodos de servidor 102, 104, 106 está configurado como nodo de servidor pasivo o en espera. De hecho, de acuerdo con una realización, todos los servidores de nodos de servidor en el sistema distribuido están configurados para soportar solicitudes simultáneas de clientes para acceso o transacciones dentro del sistema distribuido. Por consiguiente, esto permite escalar fácilmente el sistema distribuido para admitir nodos de servidor adicionales, sin sacrificar el rendimiento a medida que aumenta la carga de trabajo. De acuerdo con una realización, no hay servidores de reserva pasivos en el sistema distribuido actual y se eliminan las vulnerabilidades y los cuellos de botella de un único nodo de servidor coordinador maestro. Además, distribuir las solicitudes de los clientes a través de múltiples nodos de servidor 102, 104, 106 (y/u otros, no mostrados en la Figura 1) distribuye inherentemente la carga de procesamiento y el tráfico entre todos los nodos de servidor disponibles. También se puede llevar a cabo el equilibrio de carga activo entre los nodos de servidor 102, 104, 106.

De acuerdo con una realización, una única propuesta no puede tener presencia tanto en la cola de entrada de DConE como en el estado persistente interno de DConE. De hecho, una propuesta está en la cola de entrada o ha sido sacada de la cola por DConE, procesada y persistida internamente en, digamos, una base de datos interna de DConE. Por lo tanto, para protegerse contra tales fallas, en el lado de entrada, se tiene cuidado de asegurar que las propuestas de los clientes no sean acordadas dos veces por DConE y, en el lado de salida de DConE, que las propuestas acordadas (también denominadas en la presente memoria “acuerdos”) no sean emitidas dos veces. Para lograr esto en el lado de entrada, de acuerdo con una realización, cuando DConE saca de la cola y lee una propuesta de su cola de entrada, se puede realizar una verificación para garantizar que DConE no haya visto antes el LSN 302 asociado con esta propuesta. Si DConE ha procesado previamente la propuesta de cliente 200 asociada con el LSN de la propuesta recién sacada de la cola, la propuesta se descarta, suponiendo que se produjo una falla al sacar de la cola y/o transferir la propuesta de la cola del cliente al DConE 108. Por lo tanto, De acuerdo con una realización, el DConE 108 no necesita mantener un registro de cada LSN 3021 que tiene listo, sólo el último. De manera similar, para protegerse contra fallas en el lado de salida del DConE, el DConE 108 puede configurarse de modo que, antes de añadir un acuerdo a la cola de salida, el DConE 108 garantice que no haya ningún otro acuerdo en la cola de salida que tenga el mismo GSN. De hecho, es sólo después de que DConE 108 haya determinado que ningún otro acuerdo asociado con el mismo GSN ya esté presente en su salida que compromete el acuerdo objeto a su cola de salida, para así abordar la cuestión de que un acuerdo se envíe más de una vez a la cola de salida debido a una falla. Para hacerlo, de acuerdo con una realización, la cola de salida persistente de DConE mantiene un registro del último GSN que se emitió desde DConE 108.

Manejo de Propuestas de Aplicaciones de DConE en la Actualización

También se describen realizaciones de procedimientos, dispositivos y sistemas para mantener la coherencia de los acuerdos y la coherencia en el estado de las aplicaciones de cliente en dicho sistema distribuido a través de una WAN, a medida que se actualiza el motor de coordinación distribuida. Cuando se deben actualizar los motores DConE, el cliente no debe experimentar ninguna interrupción y el estado de las aplicaciones de cliente debe continuar evolucionando de manera determinista y predecible, incluso durante el cambio de una versión del DConE a otra versión del DConE. Para hacerlo, una realización requiere que el cliente interactúe con las colas de entrada y salida de DConE utilizando un protocolo invariante, en el que el proceso de sacar de la cola y procesamiento de propuestas, logro de acuerdos y emisión de acuerdos se mantiene continuo durante el proceso de actualización.

En la presente memoria descriptiva, y con referencia a la Figura 5, se supone que la versión actual de DConE es DConE v1 como se muestra en 506. En operación y como se describió anteriormente, los procesos DConE v 1506 se están ejecutando y haciendo acuerdos, leyendo desde la cola de entrada DConE 508 y enviando acuerdos ordenados por GSN a la cola de salida DConE 510. Estos acuerdos son procesados, en orden GSN, por la aplicación de cliente 502. Cuando se vuelve necesario actualizar el DConE 506, otro conjunto de procesos DConE, DConE v2, que se muestra en la Figura 2 en 512, se puede crear una instancia y se puede iniciar en cada nodo (por ejemplo). Cada una de las instancias de los procesos DConE v2 512 puede entonces, de acuerdo con una realización, conectarse a la cola de entrada DConE 508 como se muestra en 514. De manera similar, cada una de las instancias de los procesos DConE v2512 también puede conectarse a la cola de salida DConE 510, como se muestra en 516. Inicialmente, de acuerdo con una realización, DConE v2 512 solo monitoriza las colas de entrada y salida 508, 510, pero no procesa ninguna propuesta de cliente.

De acuerdo con una realización, cuando se desea realizar el cambio de DConE v1 506 a DConE v2 512, se puede añadir una propuesta especial, denominada aquí propuesta de ChangeVersion, a la cola de entrada 508 en cada nodo. La propuesta de ChangeVersion, de acuerdo con una realización, puede incluir el número de versión del DConE v2512. En esta etapa, tanto DConE v1 506 como DConE v2 están monitorizando la cola de entrada 508, pero solo DConE v1 506 está procesando las propuestas y generando los acuerdos correspondientes. a su cola de salida 510. Cuando la propuesta de ChangeVersion alcanza DConE v1 506, se saca de la cola y se envía para procesamiento por DConE v1 506. De acuerdo con una realización, el procesamiento de la propuesta de ChangeVersion por DConE v1 506 dirige efectivamente el cambio desde DConE v1 506 a DConE v2512. De acuerdo con una realización, esta propuesta de ChangeVersion es la última propuesta que es sacada de la cola y procesada por DConE v1 506, con un acuerdo sobre la propuesta de ChangeVersion que se envía a la cola de salida 510. A partir de entonces, DConE v2512, que ya está acoplado a la cola de entrada 508 y a la cola de salida 510, procesará todas las propuestas en la cola de entrada 508 después de la propuesta de ChangeVersion. En este punto, tanto DConE v1506 como DConE v2 están llegando a acuerdos y colocando las propuestas en la cola de salida 510. Sin embargo, después de recibir y procesar la propuesta de ChangeVersion por parte de DConE v1 506, DConE v2512 será el único que realizará y generará acuerdos en la cola de salida 510. En una implementación, el primer acuerdo procesado por DConE v2 512 puede estar asociado con un GSN inicial predeterminado, tal como GSN cero (0). Sin embargo, se pueden usar otros GSN iniciales, siempre que el GSN predeterminado inicial seleccionado no se haya usado antes, como podrán apreciar los expertos.

En operación y de acuerdo con una realización, la propuesta de ChangeVersion enviada a la cola de entrada 508 puede ser procesada y aceptada por DConE v1 506, y puede asignarse, con referencia a la Figura 4, un GSN 402 que comprende tanto un número de versión 404 y un número de secuencia de versión 406, indicado como {v1, X}. De acuerdo con una realización, la aplicación de cliente 502 puede estar configurada de modo que, cuando consuma este acuerdo {v1, X}, dejará de procesar cualquier acuerdo que tenga un número de versión v1 404. Es decir, la aplicación de cliente 502, al recibir y consumir el acuerdo correspondiente a la propuesta de ChangeVersion dejará de consumir cualquier acuerdo adicional de DConE v1506. Además, de acuerdo con una realización, cualquier acuerdo en la cola de salida 510 que se origina en DConE v1 506 que se presenta a la aplicación de cliente 502 que tiene un GSN (específicamente, un número de secuencia de versión 406) mayor que el número de secuencia de versión del acuerdo correspondiente a la aplicación de cliente de propuesta de ChangeVersion 502 se enrutan y se envían de vuelta a la cola de entrada 508 donde serán procesados por DConE v2512. Por ejemplo, cuando la aplicación de cliente 502 se presenta con el acuerdo {v1, X+1} y cualquier otro acuerdo de DConE v1 506 que tenga un número de secuencia de versión mayor que X será redirigido y enviado de vuelta a la cola de entrada 508 como propuestas correspondientes, a ser sacadas de la cola y acordadas por DConE v2512, y cualquier acuerdo resultante tendrá un número de versión v2. La aplicación 502 puede entonces pasar a buscar el acuerdo {v2, 0}, donde 0 es el número de secuencia de versión inicial predeterminada 406. El nuevo DConE v2512 actualizado puede entonces comenzar a procesar las propuestas en la cola de entrada 508, todas mientras verifica que no haya sacado de la cola y procesado previamente la misma propuesta, utilizando el mecanismo de verificación LSN detallado anteriormente.

Nótese que debido a que cada uno de los n nodos de servidor genera una propuesta de ChangeVersion y la coloca en su respectiva cola de entrada 508, habrá n acuerdos correspondientes. De acuerdo con una realización, después de ver un primer acuerdo correspondiente a la propuesta de ChangeVersion, la aplicación ignorará posteriormente los acuerdos de ChangeVersion que encuentre para el mismo número de versión y lo hará sin redirigirlos a la cola de entrada 508; es decir, dichos acuerdos no se vuelven a proponer. De acuerdo con una realización, si la aplicación de cliente 502 vuelve a proponer una propuesta porque tiene la versión anterior (en el ejemplo que se está desarrollando aquí, v1) y DConE v1 506 todavía está procesando propuestas de la cola de entrada 508, entonces la propuesta será acordado por DConE v1 506 con un número de versión v1 nuevamente, y no se volverá a proponer hasta que el proceso DConE v2 se haga cargo y únicamente (con exclusión de DConE v1506) comience a procesar propuestas y generar los acuerdos correspondientes.

Manejo de Propuestas de Control de DConE en la Actualización

De acuerdo con una realización, una vez que se ha agregado una propuesta de ChangeVersion a la cola de entrada 508, entonces cualquier propuesta de control de DConE en la cola de entrada 508 dirigida a DConE v1 506 puede rechazarse o convertirse en propuestas de DConE de nueva versión; es decir, propuestas de control que están configuradas para operar en DConE v2512. Esto es posible ya que después de que la propuesta de ChangeVersion se haya agregado a la cola de entrada 508, solo la versión más nueva de DConE (DConE v2 512) leerá desde la cola de entrada 508. En una implementación, DConE v2 512 puede estar configurado para procesar propuestas heredadas, puede configurarse para rechazar propuestas heredadas o puede reescribirlas de modo que operen en DConE v2512 de la misma manera o de manera similar a como fueron diseñadas para operar en DConE v1 506. De acuerdo con una realización, para que una propuesta de control configurada para consumo por DConE v1 506 se acuerde después de que se emita una propuesta de ChangeVersion, la propuesta de control v1 (es decir, la propuesta de control configurada para consumo por DConE v1 506) puede ser añadida a la cola de entrada 508 antes de la propuesta de ChangeVersion, pero el proceso de acuerdo dentro de DConE v1 506 puede reordenarlos en la salida. La propuesta de control v1 puede entonces redirigirse y enviarse de nuevo a la cola de entrada 508 para su consumo por parte de DConE v2 512 para su aprobación. En este caso, el DConE v2512 puede tratar dicha propuesta de control de varias maneras. De acuerdo con una realización, DConE v2 512 puede rechazar la propuesta de control e informar al cliente que la propuesta de control fue rechazada. Esto le da al cliente la oportunidad de descartar la propuesta de control o reformatearla para que DConE v2 512 la consuma. Alternativamente, DConE v2 512 puede aceptar la propuesta heredada si sabe cómo procesarla. En algunas implementaciones, cualquier versión posterior de DConE puede configurarse para tener la capacidad de procesar todas o algunas propuestas de control de versiones anteriores de DConE. Aun así, alternativamente, la versión más reciente de DConE (en nuestro ejemplo, DConE v2 512) puede reemplazar laz1 con una propuesta de control de tipo v2 que sea semánticamente equivalente y lograr un acuerdo al respecto.

Desactivar la versión antigua de DConE

De acuerdo con una realización, una vez que la versión más nueva de DConE está en ejecución, sacando de la cola los acuerdos de entrada 508, procesándolos y emitiendo los acuerdos correspondientes en la cola de salida 510, el DConE más antiguo que está reemplazando puede desactivarse o de otra manera se le impide procesar más propuestas y se deshabilita. Sin embargo, las instancias de la versión anterior de DConE no deben desactivarse si todavía tienen acuerdos en vigor; es decir, propuestas que aún se están acordando y colocando en la cola de salida 510. Para abordar esto, de acuerdo con una realización, se verifican todas las instancias de DConE v1 506 para garantizar que ya no tengan ningún acuerdo en curso antes de desactivarse. Al hacerlo, se garantiza que ninguna propuesta quedará sin procesar y/o no se volverá a enviar durante un proceso de actualización de DConE.

La Figura 6 es un diagrama de flujo de un procedimiento implementado por ordenador de acuerdo con una realización. Más particularmente, la Figura 6 es un diagrama de flujo de un procedimiento implementado por ordenador para mantener la coherencia de las aplicaciones de cliente en una pluralidad de nodos de servidor. Como se muestra en B602, el procedimiento puede comprender proporcionar una primera versión de un motor de coordinación distribuida (DConE), acoplado a uno o más de la pluralidad de nodos de servidor. En la primera versión del DConE, las propuestas pueden recibirse en una cola de entrada, los acuerdos sobre las propuestas acordadas y una primera ordenación de acuerdos pueden generarse en una cola de salida acoplada a uno o más de la pluralidad de nodos de servidor, como se muestra en B604. La primera ordenación de acuerdos puede, como se describe y muestra en la presente memoria, especificar un orden en el que las aplicaciones de cliente deben ejecutar acuerdos constituyentes de la primera ordenación de acuerdos y actualizar correspondientemente sus respectivos estados. Como se muestra en B606, se puede monitorizar la cola de entrada para detectar una propuesta de ChangeVersion y llegar a un acuerdo sobre la propuesta de ChangeVersion. El acuerdo sobre la propuesta de ChangeVersion puede entonces enviarse a la cola de salida y la primera versión del DConE puede dejar de llegar a más acuerdos sobre las propuestas en la cola de entrada.

Como se muestra en B608, se puede proporcionar una segunda versión del DConE y acoplarla a uno o más de la pluralidad de nodos de servidor. Como se muestra en B608, en la segunda versión del DConE, después de que el acuerdo correspondiente a la propuesta de ChangeVersion se haya enviado a la cola de salida, se pueden llegar a acuerdos sobre las propuestas en la cola de entrada y se puede emitir una segunda ordenación de acuerdos en la cola de salida, comenzando con el acuerdo correspondiente a la propuesta de ChangeVersion. Como lo exige B610, la segunda ordenación de acuerdos puede incluir propuestas sobre las cuales se ha llegado a acuerdos y puede especificar un orden en el que las aplicaciones de cliente deben ejecutar acuerdos constituyentes de la segunda ordenación de acuerdos y actualizar por consiguiente sus respectivos estados. A partir de entonces, como se muestra en B612, cualquier propuesta acordada, recibida de la primera versión del DConE después de recibir el acuerdo sobre la propuesta de ChangeVersion, puede enviarse de vuelta a la segunda versión del DConE a través de la cola de entrada para habilitar la segunda versión del DConE para llegar a un acuerdo al respecto.

De acuerdo con realizaciones adicionales, la primera versión del DConE puede apagarse, deshabilitarse, eliminarse o dejarse inoperativa de otro modo después de que la primera versión del DConE haya terminado de llegar a acuerdos sobre cualquier propuesta en vuelo (acuerdo actualmente en curso) una vez que se ha llegado al acuerdo correspondiente a la propuesta de ChangeVersion. Cada acuerdo de la primera y la segunda ordenación de acuerdos puede comprender una propuesta y un número de secuencia global (GSN) que puede comprender un número de versión del DConE habiendo llegado a un acuerdo sobre la propuesta y un número de secuencia de versión. Cada una de las aplicaciones de cliente puede estar configurada para ejecutar únicamente propuestas cuyos GSN comprendan un número de versión que coincida con un número de versión predeterminado. El número de versión predeterminado puede ser el número de versión actual o, en una actualización de DConE que se acaba de implementar, el número de versión del DConE actualizado. De esta manera, el procedimiento puede comprender además cambiar el número de versión predeterminado de la primera a la segunda versión del DConE. En una realización, el envío de cualquier propuesta acordada a la segunda versión del DConE puede realizarse mediante una de las aplicaciones de cliente. De acuerdo con una realización, las propuestas pueden comprender propuestas de aplicación para realizar cambios en el estado de las aplicaciones de cliente y/o propuestas de control de DConE que están configuradas para realizar cambios de control o configuración en la primera o segunda versiones del DConE. En una realización, la segunda versión del DConE puede: a) rechazar una propuesta de control configurada para realizar controles o configuraciones para la primera versión del DConE; b) aceptar una propuesta de control configurada para realizar controles o configuraciones a la primera versión del DConE y llegar a un acuerdo al respecto; o c) reemplazar una propuesta de control configurada para realizar controles o configuraciones de la primera versión del DConE por una propuesta de control semánticamente similar configurada para realizar controles o configuraciones de la segunda versión del DConE.

Como se muestra y describe en la presente memoria descriptiva, una realización es un sistema distribuido, que comprende una pluralidad de nodos de servidor, una primera versión del DConE y una segunda versión del DConE. De acuerdo con una realización, cada uno o uno seleccionado de la pluralidad de nodos de servidor puede comprender una aplicación de cliente y puede estar configurado para recibir solicitudes de cliente para cambiar un estado de la aplicación de cliente y generar propuestas correspondientes. La primera versión del DConE, acoplada a uno o más de la pluralidad de nodos de servidor, puede estar configurada para recibir las propuestas en una cola de entrada, y puede estar además configurada para llegar a acuerdos sobre las propuestas y emitir una primera ordenación de acuerdos en una cola de salida acoplada a al menos uno de la pluralidad de nodos de servidor. La primera ordenación de acuerdos puede especificar el orden en el que las aplicaciones de cliente deben ejecutar los acuerdos constituyentes de la primera ordenación de acuerdos y actualizar correspondientemente sus respectivos estados. De acuerdo con una realización, la primera versión del DConE puede configurarse además para monitorizar la cola de entrada para una propuesta de ChangeVersion, para llegar a un acuerdo sobre la misma, para colocar el acuerdo sobre la propuesta de ChangeVersion en la cola de salida y posteriormente para no llegar a más acuerdos sobre las propuestas en la cola de entrada. La segunda versión del DConE puede estar acoplada a la cola de entrada y a la cola de salida y puede estar configurada además para, después de que se haya llegado a un acuerdo sobre la propuesta de ChangeVersion, llegar a acuerdos sobre las propuestas en la cola de entrada y emitir una segunda ordenación de acuerdos en la cola de salida, comenzando con el acuerdo sobre la propuesta de ChangeVersion. La segunda ordenación de acuerdos puede incluir propuestas sobre las cuales se ha llegado a un acuerdo y puede especificar el orden en el que las aplicaciones de cliente deben ejecutar los acuerdos constituyentes de la segunda ordenación de acuerdos y actualizar correspondientemente sus respectivos estados. De acuerdo con una realización, una o más de las aplicaciones de cliente están configuradas además para provocar que cualquier propuesta acordada recibida de la primera versión del DConE después de recibir el acuerdo correspondiente a la propuesta de ChangeVersion se envíe de vuelta a la segunda versión del DConE a través de la cola de entrada, para aprobación por parte de la segunda versión del DConE.

De acuerdo con otra realización adicional, un procedimiento implementado por ordenador para mantener la coherencia de las aplicaciones de cliente en una pluralidad de nodos de servidor puede comprender proporcionar una primera versión de un DConE; en la primera versión del DConE, llegar a acuerdos sobre propuestas y generar una primera ordenación de acuerdos que especifica un orden en el que las aplicaciones de cliente deben ejecutar las propuestas acordadas por la primera versión del DConE y actualizar correspondientemente sus respectivos estados; proporcionar una segunda versión de un DConE; llegar a un acuerdo sobre una propuesta de ChangeVersion en la primera versión del DConE; dejar de llegar a acuerdos sobre propuestas en la segunda versión del DConE después de que se llega a un acuerdo sobre la propuesta de ChangeVersion y emitir una segunda ordenación de acuerdos que especifica un orden en el que las aplicaciones de cliente deben ejecutar las propuestas acordadas por la segunda versión del DConE y actualizar correspondientemente sus respectivos estados; y enviar cualquier propuesta acordada, recibida de la primera versión del DConE después de que se llegue a un acuerdo sobre la propuesta de ChangeVersion, de vuelta a la segunda versión del DConE para permitir que la segunda versión del DConE llegue a un acuerdo al respecto.

Hardware físico

La Figura 7 ilustra un diagrama de bloques de un dispositivo informático con el que se pueden implementar realizaciones. El dispositivo informático de la Figura 7 puede incluir un bus 701 u otro mecanismo de comunicación para comunicar información, y uno o más procesadores 702 acoplados con el bus 701 para procesar información. El dispositivo informático puede comprender además una memoria de acceso aleatorio (RAM) u otro dispositivo de almacenamiento dinámico 704 (denominado memoria principal), acoplado al bus 701 para almacenar información e instrucciones que serán ejecutadas por el(los) procesador(es) 702. La memoria principal (tangible y no transitoria, cuyos términos, en la presente memoria descriptiva, excluyen señalesper sey formas de onda) 704 también pueden usarse para almacenar variables temporales u otra información intermedia durante la ejecución de instrucciones por parte del procesador 702. El dispositivo informático de la Figura 7 también puede incluir una memoria de solo lectura (ROM) y/u otro dispositivo de almacenamiento estático 706 acoplado al bus 701 para almacenar información estática e instrucciones para el(los) procesador(es) 702. Un dispositivo de almacenamiento de datos 707, tal como un disco magnético y/o dispositivo de almacenamiento de datos de estado sólido puede acoplarse al bus 701 para almacenar información e instrucciones, tales como las que serían necesarias para llevar a cabo la funcionalidad mostrada y divulgada en relación con las Figuras 1-6. El dispositivo informático también puede estar acoplado a través del bus 701 a un dispositivo de visualización 721 para mostrar información a un usuario de un ordenador. Un dispositivo de entrada alfanumérico 722, que incluye teclas alfanuméricas y otras, puede acoplarse al bus 701 para comunicar información y selecciones de comandos al procesador(es) 702. Otro tipo de dispositivo de entrada de usuario es el control de cursor 723, tal como un mouse, una bola de seguimiento, o teclas de dirección del cursor para comunicar información de dirección y selecciones de comandos al (a los) procesador(es) 702 y para controlar el movimiento del cursor en la pantalla 721. El dispositivo informático de la Figura 7 puede acoplarse, a través de una interfaz de comunicación (por ejemplo, módem, tarjeta de interfaz de red o NIC) 708 a la red 726.

Como se muestra, el dispositivo de almacenamiento 707 puede incluir dispositivos de almacenamiento de datos de acceso directo tales como discos magnéticos 730, memorias semiconductoras no volátiles (EEPROM, Flash, etc.) 732, un dispositivo de almacenamiento de datos híbrido que comprende tanto discos magnéticos como memorias semiconductoras no volátiles, como se sugiere en 731. Las referencias 704, 706 y 707 son ejemplos de medios tangibles, no transitorios, legibles por ordenador que tienen datos almacenados en los mismos que representan secuencias de instrucciones que, cuando se ejecutan por uno o más dispositivos informáticos, implementan aspectos de la sistemas y procedimientos distribuidos descritos y mostrados en la presente memoria. Algunas de estas instrucciones pueden almacenarse localmente en un dispositivo informático de cliente, mientras que otras de estas instrucciones pueden almacenarse (y/o ejecutarse) de forma remota y comunicarse al ordenador de cliente a través de la red 726. En otras realizaciones, todas estas instrucciones pueden almacenarse localmente en el dispositivo informático de cliente u otro dispositivo informático independiente, mientras que, en otras realizaciones adicionales, todas estas instrucciones se almacenan y ejecutan de forma remota (por ejemplo, en uno o más servidores remotos) y los resultados se comunican al dispositivo informático de cliente. En aún otra realización, las instrucciones (lógica de procesamiento) pueden almacenarse en otra forma de un medio tangible, no transitorio, legible por ordenador, tal como se muestra en 728. Por ejemplo, la referencia 728 puede implementarse como un disco óptico (o algún otro tipo de tecnología de almacenamiento), que puede constituir un soporte de datos adecuado para cargar las instrucciones almacenadas en el mismo en uno o más dispositivos informáticos, reconfigurando así los dispositivos informáticos para una o más de las realizaciones descritas y mostradas en la presente memoria descriptiva. En otras implementaciones, la referencia 728 puede incorporarse como una unidad de estado sólido cifrada. Otras implementaciones son posibles.

Las realizaciones de la presente invención están relacionadas con el uso de dispositivos informáticos para mantener la coherencia de las aplicaciones de cliente a través de una red informática en un sistema distribuido. De acuerdo con una realización, los procedimientos, dispositivos y sistemas descritos en la presente memoria descriptiva pueden ser proporcionados por uno o más dispositivos informáticos en respuesta a procesador(es) 702 que ejecutan secuencias de instrucciones, que incorporan aspectos de los procedimientos implementados por ordenador mostrados y descritos en la presente memoria descriptiva, contenidos en la memoria 704. Dichas instrucciones pueden leerse en la memoria 704 desde otro medio legible por ordenador, tal como el dispositivo de almacenamiento de datos 707 u otro soporte de datos (óptico, magnético, etc.), tal como se muestra en 728. La ejecución de las secuencias de instrucciones contenidas en la memoria 704 hace que el(los) procesador(es) 702 realicen las etapas y tengan la funcionalidad descrita en la presente memoria descriptiva. En realizaciones alternativas, se pueden usar circuitos cableados en lugar de o en combinación con instrucciones de software para implementar las realizaciones descritas. Por lo tanto, las realizaciones no se limitan a ninguna combinación específica de circuitos de hardware y software. De hecho, los expertos en la técnica deberían entender que cualquier sistema informático adecuado puede implementar la funcionalidad descrita en la presente memoria descriptiva. Los dispositivos informáticos pueden incluir uno o varios microprocesadores que funcionan para realizar las funciones deseadas. En una realización, las instrucciones ejecutadas por el microprocesador o los microprocesadores son operables para hacer que el microprocesador realice las etapas descritas en la presente memoria descriptiva. Las instrucciones pueden almacenarse en cualquier medio legible por ordenador. En una realización, pueden almacenarse en una memoria semiconductora no volátil externa al microprocesador o integrarse con el microprocesador. En otra realización, las instrucciones pueden almacenarse en un disco y leerse en una memoria semiconductora volátil antes de que el microprocesador las ejecute.

Partes de la descripción detallada anterior describen procesos y representaciones simbólicas de operaciones mediante dispositivos informáticos que pueden incluir componentes informáticos, incluida una unidad de procesamiento local, dispositivos de almacenamiento de memoria para la unidad de procesamiento local, dispositivos de visualización y dispositivos de entrada. Además, dichos procesos y operaciones pueden utilizar componentes informáticos en un entorno informático distribuido heterogéneo que incluye, por ejemplo, servidores de archivos remotos, servidores informáticos y dispositivos de almacenamiento de memoria. Estos componentes informáticos distribuidos pueden ser accesibles a la unidad de procesamiento local a través de una red de comunicación.

Los procesos y operaciones realizadas por el ordenador incluyen la manipulación de bits de datos por una unidad de procesamiento local y/o servidor remoto y el mantenimiento de estos bits dentro de estructuras de datos residentes en uno o más de los dispositivos de almacenamiento de memoria locales o remotos. Estas estructuras de datos imponen una organización física a la colección de bits de datos almacenados dentro de un dispositivo de almacenamiento de memoria y representan elementos del espectro electromagnético.

Un proceso, tal como los procedimientos de aumento de datos implementados por ordenador descritos y mostrados en la presente memoria descriptiva, generalmente se puede definir como una secuencia de etapas ejecutadas por ordenador que conducen a un resultado deseado. Estas etapas generalmente requieren manipulaciones físicas de cantidades físicas. Por lo general, aunque no necesariamente, estas cantidades pueden tomar la forma de señales eléctricas, magnéticas u ópticas capaces de almacenarse, transferirse, combinarse, compararse o manipularse de otro modo. Es convencional para los expertos en la técnica referirse a estas señales como bits o bytes (cuando tienen niveles lógicos binarios), valores de píxeles, obras, valores, elementos, símbolos, caracteres, términos, números, puntos, registros, objetos, imágenes, archivos, directorios, subdirectorios o similares. Sin embargo, debe tenerse en cuenta que estos y otros términos similares deben asociarse con cantidades físicas apropiadas para las operaciones del ordenador, y que estos términos son simplemente etiquetas convencionales aplicadas a cantidades físicas que existen dentro y durante la operación del ordenador.

También debe entenderse que las manipulaciones dentro del ordenador a menudo se denominan en términos tales como añadir, comparar, mover, posicionar, colocar, iluminar, eliminar, alterar y similares. Las operaciones descritas en la presente memoria son operaciones de máquina realizadas junto con diversas entradas proporcionadas por un operador o usuario de un agente humano o de inteligencia artificial que interactúa con el ordenador. Las máquinas utilizadas para realizar las operaciones descritas en la presente memoria incluyen ordenadores digitales de uso general locales o remotas u otros dispositivos informáticos similares.

Además, debe entenderse que los programas, procesos, procedimientos, etc. descritos en la presente memoria descriptiva no están relacionados ni limitados a ningún ordenador o aparato en particular ni están relacionados ni limitados a ninguna arquitectura de red de comunicación en particular. Más bien, se pueden usar varios tipos de máquinas de hardware de uso general con módulos de programa construidos de acuerdo con las enseñanzas descritas en la presente memoria descriptiva. De manera similar, puede resultar ventajoso construir un aparato especializado para realizar las etapas del procedimiento descritas en la presente memoria descriptiva mediante sistemas informáticos dedicados en una arquitectura de red específica con lógica cableada o programas almacenados en una memoria no volátil, como una memoria de solo lectura.

Si bien se han descrito ciertas realizaciones de ejemplo, estas realizaciones se han presentado a modo de ejemplo únicamente y no pretenden limitar el alcance de las realizaciones descritas en la presente memoria descriptiva. Por lo tanto, nada en la descripción anterior pretende implicar que cualquier rasgo, característica, etapa, módulo o bloque particular sea necesario o indispensable. De hecho, los nuevos procedimientos y sistemas descritos en la presente memoria descriptiva pueden incorporarse en una variedad de otras formas; además, se pueden realizar diversas omisiones, sustituciones y cambios en la forma de los procedimientos y sistemas descritos en la presente memoria descriptiva siempre que entren dentro del alcance de las reivindicaciones.

Claims (14)

REIVINDICACIONES

1. Un sistema distribuido, que comprende:

una pluralidad de nodos de servidor (102, 104, 106, 504), comprendiendo cada uno una aplicación de cliente (502) y estando configurados para recibir solicitudes de cliente (200) para cambiar un estado de la aplicación de cliente y generar propuestas correspondientes;

una primera versión (506, B602) de un motor de coordinación distribuida “DConE”, acoplado a la pluralidad de nodos de servidor a través de respectivas colas de entrada y salida y configurado para recibir las propuestas en las colas de entrada, estando configurada además la primera versión del DConE (B606) para llegar a acuerdos sobre las propuestas y emitir una primera ordenación de acuerdos en colas de salida, acopladas a la pluralidad de nodos de servidor, especificando la primera ordenación de acuerdos un orden en el que las aplicaciones de cliente deben ejecutar acuerdos constituyentes de la primera ordenación de acuerdos y actualizar correspondientemente sus respectivos estados, estando configurada además la primera versión del DConE para monitorizar las colas de entrada para una propuesta predeterminada configurada para dirigir una transición de la primera a una segunda versión (512) del DConE, para sacar de la cola la propuesta predeterminada, presentar la propuesta predeterminada para su procesamiento y llegar a un acuerdo al respecto utilizando un protocolo de consenso, colocar el acuerdo sobre la propuesta predeterminada en las colas de salida y posteriormente no llegar a más acuerdos sobre las propuestas en las colas de entrada; y

estando acoplada la segunda versión (512, B608) del DConE a las respectivas colas de entrada y salida, estando configurada además la segunda versión del DConE para, después de que se haya llegado a un acuerdo sobre la propuesta predeterminada, llegar a acuerdos sobre las propuestas en las colas de entrada y emitir una segunda ordenación de acuerdos en las colas de salida, comenzando con el acuerdo sobre la propuesta predeterminada, incluyendo la segunda ordenación de acuerdos propuestas sobre las cuales se ha llegado a un acuerdo (B610) y especificando un orden en el que se ejecutarán las aplicaciones de cliente constituyentes de acuerdos de la segunda ordenación de acuerdos y actualizar correspondientemente sus respectivos estados,

en el que cada aplicación de cliente está configurada además para provocar (B612) que cualquier propuesta acordada recibida de la primera versión del DConE después de recibir el acuerdo correspondiente a la propuesta predeterminada se envíe de vuelta a la segunda versión del DConE a través de las colas de entrada.

2. El sistema distribuido según la reivindicación 1, en el que la primera versión (506) del DConE comprende una instancia del mismo para cada uno de la pluralidad de nodos de servidor (504) y en el que la segunda versión (512) del DConE comprende una instancia del mismo para cada uno de la pluralidad de nodos de servidor.

3. El sistema distribuido según la reivindicación 1 o 2, en el que la primera versión del DConE se apaga después de que la primera versión del DConE haya terminado de llegar a acuerdos sobre cualquier propuesta en vuelo después de que se haya llegado al acuerdo correspondiente a la propuesta predeterminada.

4. El sistema distribuido según la reivindicación 1, 2 o 3, en el que las propuestas comprenden al menos una de propuestas de aplicación para realizar cambios en el estado de las aplicaciones de cliente (502) y propuestas de control de DConE configuradas para realizar cambios de control o configuración en la primera (506) o segunda (512) versiones del DConE.

5. El sistema distribuido según la reivindicación 4, en el que la segunda versión (512) del DConE está configurada además para uno de:

rechazar una propuesta de control configurada para realizar controles o configuraciones a la primera versión del DConE;

aceptar una propuesta de control configurada para realizar controles o configuraciones a la primera versión del DConE y llegar a un acuerdo al respecto; y

reemplazar una propuesta de control configurada para realizar controles o configuraciones en la primera versión del DConE por una propuesta de control semánticamente similar configurada para realizar controles o configuraciones en la segunda versión del DConE.

6. Un procedimiento implementado por ordenador para mantener la coherencia de aplicaciones de cliente (502) en una pluralidad de nodos de servidor (102, 104, 106, 502), que comprende:

proporcionar (B602) una primera versión (506) de un motor de coordinación distribuida “DConE”, acoplado a al menos uno de la pluralidad de nodos de servidor y, en la primera versión del DConE:

recibir (B604) propuestas en respectivas colas de entrada acopladas a la pluralidad de nodos de servidor, llegar a acuerdos sobre las propuestas y emitir una primera ordenación de acuerdos en respectivas colas de salida acopladas a la pluralidad de nodos de servidor, especificando la primera ordenación de acuerdos un orden en el que las aplicaciones de cliente deben ejecutar acuerdos constituyentes de la primera ordenación de acuerdos y actualizar correspondientemente sus respectivos estados; y

monitorizar (B606) las colas de entrada para una propuesta predeterminada configurada para dirigir una transición de la primera versión a una segunda versión del DConE, llegar a un acuerdo sobre la propuesta predeterminada utilizando un protocolo de consenso, generar el acuerdo sobre la propuesta predeterminada en las colas de salida y posteriormente dejar de llegar a más acuerdos sobre las propuestas en las colas de entrada; y

proporcionar (B608) la segunda versión del DConE acoplada a al menos uno de la pluralidad de nodos de servidor y, en la segunda versión del DConE:

después de que el acuerdo correspondiente a la propuesta predeterminada haya sido emitido a las colas de salida, llegar a acuerdos (B610) sobre las propuestas en las colas de entrada y emitir una segunda ordenación de acuerdos en las colas de salida, comenzando con el acuerdo correspondiente a la propuesta predeterminada, incluyendo la segunda ordenación de acuerdos propuestas sobre qué acuerdos se han llegado y especifica un orden en el que las aplicaciones de cliente deben ejecutar acuerdos constituyentes de la segunda ordenación de acuerdos y actualizar correspondientemente sus respectivos estados, y

enviar (B612) cualquier propuesta acordada, recibida de la primera versión del DConE después de la recepción del acuerdo sobre la propuesta predeterminada, de vuelta a la segunda versión del DConE a través de las colas de entrada para permitir que la segunda versión del DConE llegue a un acuerdo al respecto.

7. El procedimiento implementado por ordenador según la reivindicación 6, en el que el envío de cualquier propuesta acordada de vuelta a la segunda versión (512) del DConE se ejecuta por una de las aplicaciones de cliente.

8. El procedimiento implementado por ordenador según la reivindicación 6 o 7, que además comprende apagar la primera versión (506) del DConE después de que la primera versión del DConE haya terminado de llegar a acuerdos sobre cualquier propuesta en vuelo después de que se haya llegado al acuerdo correspondiente a la propuesta predeterminada.

9. El procedimiento implementado por ordenador según la reivindicación 6, en el que las propuestas comprenden al menos una de propuestas de aplicación para realizar cambios en el estado de las aplicaciones de cliente (502) y propuestas de control de DConE configuradas para realizar cambios de control o configuración en la primera o segunda versiones del DConE.

10. El procedimiento implementado por ordenador según la reivindicación 9, que además comprende la segunda versión del DConE uno de:

rechazar una propuesta de control configurada para realizar controles o configuraciones a la primera versión del DConE;

aceptar una propuesta de control configurada para realizar controles o configuraciones a la primera versión del DConE y llegar a un acuerdo al respecto; y

reemplazar una propuesta de control configurada para realizar controles o configuraciones en la primera versión del DConE por una propuesta de control semánticamente similar configurada para realizar controles o configuraciones en la segunda versión del DConE.

11. El sistema distribuido según cualquiera de las reivindicaciones 1 a 5 o el procedimiento implementado por ordenador según cualquiera de las reivindicaciones 6 a 10, en el que cada acuerdo de la primera y segunda ordenación de acuerdos comprende:

una propuesta (200); y

un número de secuencia global “GSN” (402) que comprende un número de versión (404) del DConE que ha llegado a un acuerdo sobre la propuesta y un número de secuencia de versión (406).

12. El procedimiento implementado por ordenador según la reivindicación 11, que además comprende:

configurar cada una de las aplicaciones de cliente (502) para ejecutar únicamente propuestas cuyos GSN comprendan un número de versión (404) que coincida con un número de versión predeterminado; y

cambiar el número de versión predeterminado de la primera a la segunda versión del DConE.

13. El sistema distribuido según la reivindicación 11, en el que cada una de las aplicaciones de cliente (502) está configurada para ejecutar únicamente propuestas cuyos GSN comprendan un número de versión que coincida con un número de versión predeterminado.

14. El sistema distribuido según la reivindicación 13, en el que el número de versión predeterminado se selecciona entre la primera versión del DConE y la segunda versión del DConE.