ES2626655T3

ES2626655T3 - Conmutación por error de clientes agrupados

Info

Publication number: ES2626655T3
Application number: ES12829430.3T
Authority: ES
Inventors: David M. KRUSE; Diaa Fathalla; James T. Pinkerton; Mathew George; Prashanth Prahalad; Thomas E. JOLLY
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2011-09-09
Filing date: 2012-09-07
Publication date: 2017-07-25
Anticipated expiration: 2032-09-07
Also published as: MX336341B; ZA201401381B; SG11201400442SA; US20130066941A1; EP2754059A2; MX2014002783A; EP2754059B1; CO6900122A2; IN2014CN01748A; WO2013036697A2; IL231373A; CN102932164A; CA2847597A1; JP6210987B2; WO2013036697A3; JP2014529141A; IL231373A0; KR101941728B1; US8788579B2; RU2595755C2

Abstract

Un procedimiento para proporcionar acceso continuo a un recurso, comprendiendo el procedimiento: recibir en un grupo (106) de servidores, que incluye al menos un servidor (106A, 106B, 106C; 208, 216), una primera solicitud (222) para acceder a un recurso (226) desde una aplicación (203) cliente, ejecutándose la aplicación cliente en un primer cliente (102A; 202), en el que la primera solicitud se recibe desde el primer cliente en un grupo (106; 201) de clientes; asociar en el grupo de servidores un primer identificador de instancia de aplicación con el recurso; permitir por el grupo de servidores el primer acceso solicitado al recurso; recibir en el grupo de servidores una segunda solicitud (224) para el recurso desde la aplicación cliente después de recuperarse de un fallo, en el que la segunda solicitud se recibe desde un segundo cliente (102B; 204) diferente del primer cliente; recibir en el grupo de servidores un segundo identificador de instancia de aplicación asociado con la segunda solicitud; determinar si el primer identificador de instancia de aplicación y el segundo identificador de instancia de aplicación son los mismos; y cuando los identificadores de instancia de aplicación primero y segundo son los mismos, realizar por el grupo de servidores las etapas que comprenden: invalidar la primera solicitud; y conceder la segunda solicitud de acceso al recurso.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Conmutacion por error de clientes agrupados Antecedentes

Los entornos agrupados, por ejemplo, los entornos donde se distribuye la carga de trabajo a traves de multiples maquinas, se usan habitualmente para proporcionar conmutacion por error y alta disponibilidad de informacion a los clientes. Los entornos agrupados permiten a los clientes acceder a recursos a traves del uno o mas nodos que son una parte del entorno. Un entorno agrupado puede actuar como un cliente, un servidor, o ambos. En un servidor de grupo de clientes, una aplicacion puede residir en cualquiera de los nodos que forman el grupo. La aplicacion puede emitir solicitudes de recursos que se almacenan localmente en el grupo de clientes o se almacenan a distancia. Si se produce un error en el nodo, el cliente realiza una conmutacion por error, o migra, a un nodo diferente del grupo. Sin embargo, cuando el cliente solicita de nuevo el acceso a un recurso con el que estaba trabajando en el momento del error, el recurso puede estar acotado o bloqueado por el servidor para el nodo cliente anterior en el que residfa la aplicacion.

Se han hecho realizaciones con respecto a estas y otras consideraciones. Ademas, aunque se han discutido problemas relativamente espedficos, debe entenderse que las realizaciones no deben limitarse a resolver los problemas espedficos identificados en los antecedentes.

El documento EP 1 643 406 A2 se refiere a la reutilizacion del identificador de registro. Se proporciona una funcion para generar y usar un unico identificador como una clave para identificar una unica instancia de agente de usuario entre los multiples agentes de usuario del mismo usuario. La instalacion genera un identificador para una primera instancia de agente de usuario, que es una instancia de un usuario en una instancia de aplicacion. La funcion usa el identificador para un registro de la primera instancia de agente de usuario con un servidor logico y asocia el identificador con la primera instancia de agente de usuario y el par de registro de servidor logico. A continuacion, la funcion usa el identificador para un registro posterior de la primera instancia de agente de usuario con el servidor logico.

El documento US 7 664 991 B1 se refiere a un sistema y un procedimiento para la recuperacion de E/S de sistemas de archivos distribuidos. Las realizaciones pueden detectar una perdida de acceso a un servidor en la red de almacenamiento y recuperar las solicitudes de E/S de aplicacion en tiempo real una vez que se restablece el acceso al servidor. Las realizaciones pueden detectar fallos en el servidor y/o en la red y almacenar solicitudes de E/S fallidas y nuevas. Puede detectarse la recuperacion del fallo (por ejemplo, reconexion de la red, reinicio del nodo servidor o conmutacion por error, si se trata de un entorno agrupado) y, despues de que se detecte la recuperacion, puede enviarse al servidor cualquier solicitud de E/S fallida y nueva almacenada. En una realizacion, para detectar la recuperacion del fallo, una solicitud de E/S fallida puede volver a emitirse repetidamente hasta que la solicitud de E/S tenga exito. Las realizaciones pueden implementarse en una diversidad de entornos de almacenamiento, incluyendo entornos donde los clientes emiten E/S directas a traves de una red de almacenamiento para almacenar y controlar las E/S a traves de una red a un servidor.

Sumario

El presente sumario se proporciona para presentar una seleccion de conceptos en una forma simplificada que se describen adicionalmente a continuacion en la seccion Descripcion Detallada. El presente sumario no pretende identificar las caractensticas clave o las caractensticas esenciales del objeto reivindicado, ni pretende usarse como ayuda para determinar el ambito del objeto reivindicado.

En el presente documento se desvelan sistemas y procedimientos que proporcionan una aplicacion o un procedimiento con acceso continuo a un recurso despues de que la aplicacion migre a un nuevo nodo en un entorno de cliente agrupado. Una aplicacion o un procedimiento residente en un nodo en un grupo de clientes envfa una solicitud a un servidor para acceder a un recurso. En las realizaciones, se usa un unico identificador de instancia de aplicacion para identificar una aplicacion que solicita un recurso. El unico identificador de aplicacion puede estar provisto de la solicitud. Cuando el cliente accede a un recurso, el identificador de instancia de aplicacion se asocia con el recurso solicitado.

Antes de que la aplicacion o el procedimiento complete sus operaciones en el recurso, el nodo en el que reside el cliente en el entorno agrupado puede experimentar un error que hace que falle o se pierda el acceso de otro modo al recurso antes de que la aplicacion libere correctamente el recurso. En tales circunstancias, el recurso puede permanecer en un estado acotado o bloqueado en el servidor por la solicitud del cliente anterior. Tras fallar en un nodo diferente en el grupo de clientes, la aplicacion en el nuevo nodo cliente puede restablecer una conexion con el servidor que gestiona el recurso y realizar una segunda solicitud del recurso al que la aplicacion tema acceso anteriormente en el momento del error. La segunda solicitud puede incluir el identificador de instancia de aplicacion que se envio con la primera solicitud. Aunque la segunda solicitud del recurso puede recibirse de un nodo diferente en el entorno agrupado, el identificador de instancia de aplicacion permite que el servidor que gestiona la solicitud determine que la segunda solicitud pertenece a la misma aplicacion o procedimiento que habfa bloqueado previamente el recurso. Si lo hace, el servidor puede invalidar el recurso y conceder la segunda solicitud del cliente

5

10

15

20

25

30

35

40

45

50

55

para acceder al recurso mientras garantiza que no se produzca una situacion de conflicto.

Las realizaciones pueden implementarse como un procedimiento informatico, un sistema informatico o como un artfculo de fabricacion tal como un producto de programa informatico o un medio legible por ordenador. El producto de programa informatico puede ser un medio de almacenamiento informatico legible por un sistema informatico y que codifica un programa informatico de instrucciones para ejecutar un procedimiento informatico. El producto de programa informatico tambien puede ser una senal propagada en un soporte legible por un sistema informatico y que codifica un programa informatico de instrucciones para ejecutar un procedimiento informatico.

Breve descripcion de los dibujos

Se describen realizaciones no limitantes y no exhaustivas con referencia a las siguientes figuras.

La figura 1 ilustra un sistema que puede usarse para implementar las realizaciones descritas en el presente documento.

La figura 2 es un diagrama de bloques que ilustra un entorno de software que puede usarse para implementar las realizaciones desveladas en el presente documento.

La figura 3 es una realizacion de un procedimiento que un cliente puede realizar para obtener acceso continuo a un recurso en un entorno agrupado.

La figura 4 es una realizacion de un procedimiento realizado por un nodo en un entorno agrupado para proporcionar acceso continuo a un recurso.

La figura 5 ilustra un diagrama de bloques de un entorno informatico adecuado para implementar las realizaciones.

Descripcion detallada

A continuacion, se describen mas detalladamente diversas realizaciones con referencia a los dibujos adjuntos, que forman parte de la misma, y que muestran realizaciones espedficas a modo de ejemplo. Sin embargo, las realizaciones pueden implementarse en muchas formas diferentes y no deben interpretarse como limitadas a las realizaciones expuestas en el presente documento; por el contrario, estas realizaciones se proporcionan de manera que la presente divulgacion sera minuciosa y completa y transmitira con todo detalle el ambito de las realizaciones a los expertos en la materia. Las realizaciones pueden ponerse en practica como procedimientos, sistemas o dispositivos. En consecuencia, las realizaciones pueden adoptar la forma de una implementacion de hardware, una implementacion completamente de software o una implementacion que combina aspectos de software y hardware. Por lo tanto, la siguiente descripcion detallada no debe tomarse en un sentido limitante.

Las realizaciones de la presente divulgacion estan relacionadas con la provision de mecanismos de conmutacion por error de cliente agrupado que permiten a un solicitante volver a obtener acceso a un recurso despues de un suceso de conmutacion por error. En las realizaciones, un solicitante puede ser un procedimiento, una aplicacion o uno o mas procedimientos secundarios de una aplicacion. Un recurso puede ser un archivo, un objeto, datos o cualquier otro tipo de recurso en un entorno informatico. En las realizaciones, un recurso puede residir en un servidor independiente o puede residir en un entorno agrupado. En las realizaciones desveladas en el presente documento, un entorno agrupado puede incluir uno o mas nodos (por ejemplo, dispositivos de cliente y/o de servidor).

En una realizacion a modo de ejemplo, una aplicacion que reside en un nodo en un entorno agrupado puede solicitar acceso a un recurso espedfico. En las realizaciones, el recurso puede almacenarse localmente (por ejemplo, en el nodo cliente), en un dispositivo remoto (por ejemplo, un servidor remoto o un nodo diferente en el entorno agrupado de cliente), o en un entorno agrupado (por ejemplo, un entorno que contiene multiples nodos) que es diferente del entorno agrupado de cliente. Por ejemplo, en las realizaciones el entorno agrupado puede ser un grupo de clientes o de servidores; sin embargo, los expertos en la materia apreciaran que los sistemas y los procedimientos desvelados en el presente documento pueden emplearse en cualquier otro tipo de entorno, tal como, pero sin limitarse a, una red virtual.

En dichos entornos, los recursos pueden compartirse entre clientes y aplicaciones. Cuando una aplicacion accede a un recurso, el recurso puede estar acotado o bloqueado, prohibiendo de este modo que otras aplicaciones accedan al recurso hasta que la aplicacion de acceso libere el recurso. El acotamiento o bloqueo del recurso puede emplearse para proteger contra un conflicto, es decir, proteger contra la modificacion del recurso por otra aplicacion antes de que la aplicacion de acceso haya realizado sus operaciones en el recurso. Sin embargo, si falla el nodo en un entorno de cliente agrupado, la aplicacion que accede al recurso puede no liberar correctamente el recurso de un estado acotado o bloqueado. Por ejemplo, el nodo cliente que accede al recurso en nombre de la aplicacion puede perder una conexion de red, puede colgarse, o puede perder de otro modo el acceso al recurso antes de que la aplicacion complete sus operaciones y libere adecuadamente el recurso. Por lo tanto, el recurso puede permanecer en un estado en el que no esta disponible para otros clientes o aplicaciones. Pueden emplearse mecanismos que liberen automaticamente un recurso de un estado acotado o bloqueado, evitando de este modo que el recurso se bloquee permanentemente. Sin embargo, estos mecanismos a menudo esperan un penodo de tiempo antes de liberar un recurso acotado o bloqueado.

5

10

15

20

25

30

35

40

45

50

55

60

En algunos casos, cuando la aplicacion realiza una conmutacion por error para migrar desde el nodo cliente fallido a un nodo cliente diferente en el grupo de clientes, la aplicacion puede intentar restablecer su conexion anterior con el servidor y reanudar su o sus operaciones en el recurso a traves del nodo cliente diferente. Sin embargo, debido a que el recurso no se ha liberado correctamente por el nodo cliente fallido, que ha accedido previamente al recurso en nombre de la aplicacion, debido al error, la aplicacion que tema acceso previo al recurso puede no ser capaz de reanudar su acceso al recurso hasta que el servidor libere el recurso de su estado acotado o bloqueado. Sin embargo, debido a que ahora un nodo diferente esta intentando acceder al recurso en nombre de la aplicacion, el servidor puede no ser capaz de identificar la aplicacion como la misma aplicacion que establecio previamente el bloqueo en el recurso. Sin embargo, debido a que la misma aplicacion esta intentando acceder al recurso, no existe una situacion de conflicto. En estas situaciones, esperar que el servidor libere el bloqueo anterior en el recurso puede provocar un retraso inaceptable para la aplicacion.

Tal como se ha descrito, debido a que la aplicacion esta operando en un entorno de cliente agrupado, cuando la aplicacion solicita acceder al recurso una segunda vez, la solicitud de acceso al recurso puede realizarse desde una localizacion diferente, tal como un nodo diferente en el entorno de cliente agrupado. Por lo tanto, la segunda solicitud puede proceder de una localizacion o direccion IP diferente. Debido a que la solicitud puede realizarse desde una localizacion diferente, un servidor puede tener dificultades para garantizar que el cliente o la aplicacion que intenta volver a acceder al recurso sea, en realidad, el mismo cliente que accedio previamente al recurso. Los sistemas y procedimientos desvelados en el presente documento proporcionan mecanismos para identificar situaciones donde la misma aplicacion esta intentando acceder a un recurso, evitando de este modo dicho retraso y proporcionando un acceso continuo de la aplicacion al recurso.

La figura 1 ilustra un sistema 100 que puede usarse para implementar algunas de las realizaciones desveladas en el presente documento. El sistema 100 incluye un grupo 102 de clientes y un grupo 106 de servidores. El grupo de clientes incluye multiples nodos, tales como los clientes 102A y 102B. Los clientes 102A y 102B pueden ser un dispositivo o aplicacion que reside en el grupo 102 de clientes. El grupo 102 de clientes puede comunicarse con el grupo 106 de servidores a traves de la red 108. En las realizaciones, la red puede ser Internet, una WAN, una LAN o cualquier otro tipo de red conocida en la tecnica. El grupo 106 de servidores almacena los recursos a los que acceden las aplicaciones del grupo 102 de clientes (por ejemplo, las aplicaciones que residen en el cliente 102A o el cliente 102B). En las realizaciones, un cliente (por ejemplo, el cliente 102A) puede establecer una sesion con el grupo 106 para acceder a los recursos del grupo 106 en nombre de una aplicacion que reside en el cliente. Aunque en la figura 1, el grupo 102 de clientes solo incluye dos clientes (por ejemplo, el cliente 102A y el cliente 102B), los expertos en la materia apreciaran que puede incluirse cualquier numero de clientes en el grupo 102 de clientes.

Como se muestra en la figura 1, el grupo 106 de servidores incluye los servidores 106A, 106B y 106C, que proporcionan una alta disponibilidad y redundancia para la informacion almacenada en el grupo 106. En las realizaciones, el grupo 106 puede tener un sistema de archivos, una base de datos u otra informacion a la que acceden los clientes 102 y 104. Aunque en la figura 1 se muestran tres servidores, en otras realizaciones el grupo 106 puede incluir mas de tres servidores, o menos de tres servidores. Ademas, aunque las realizaciones descritas en el presente documento se refieren a un cliente que se comunica con un servidor que es parte de un grupo de servidores, los expertos en la materia apreciaran que las realizaciones desveladas en el presente documento tambien pueden realizarse usando un servidor independiente.

En las realizaciones, el grupo 102 de clientes proporciona mecanismos de conmutacion por error que permiten a un cliente migrar desde un primer nodo cliente a un segundo nodo cliente en caso de que se produzca un error o un fallo en el primer nodo cliente. Los expertos en la materia apreciaran que puede emplearse cualquier tipo de mecanismo de conmutacion por error con los sistemas y procedimientos desvelados en el presente documento. Los procedimientos y sistemas desvelados en el presente documento pueden emplearse para evitar un retraso indebido cuando una aplicacion intenta volver a obtener el acceso a un recurso que migra de un cliente a otro (por ejemplo, del cliente 102a al cliente 102B) en el caso de una conmutacion por error. En las realizaciones, un identificador de instancia de aplicacion que identifica la aplicacion que accede al recurso puede asociarse con el recurso. El identificador de instancia de aplicacion puede ser un identificador unico global (GUID) que esta asociado con una aplicacion, una accion realizada por una aplicacion o un procedimiento secundario de una aplicacion. Por ejemplo, en una realizacion, una aplicacion puede asociarse con un identificador de instancia de aplicacion que es un GUID. En otra realizacion, un identificador de instancia de aplicacion puede asociarse con una operacion o accion espedfica realizada por una aplicacion. Por ejemplo, si la aplicacion emite dos solicitudes abiertas diferentes para dos archivos diferentes, cada solicitud abierta puede tener su propio identificador de instancia de aplicacion. En otra realizacion mas, un identificador de instancia de aplicacion puede asociarse con uno o mas procedimientos secundarios de la aplicacion. Como sera evidente para los expertos en la materia a partir de las realizaciones descritas en el presente documento, la asociacion del identificador de instancia de aplicacion de una aplicacion con sus uno o mas procedimientos secundarios permitira que los procedimientos secundarios accedan al recurso si el recurso se coloca en un estado bloqueado o acotado que pertenece a la aplicacion. En las realizaciones, el identificador de instancia de aplicacion puede enviarse por el cliente en el momento de, o despues de, enviar una solicitud para un recurso.

De acuerdo con otra realizacion, ademas de almacenar la informacion a la que acceden los clientes que forman parte del grupo 102 de clientes, el grupo 106 de servidores tambien proporciona un mecanismo de conmutacion por

5

10

15

20

25

30

35

40

45

50

55

60

error que permite el acceso continuo de un recurso en caso de fallo de un nodo servidor. De nuevo, los expertos en la materia apreciaran que puede emplearse cualquier tipo de mecanismo de conmutacion por error con los sistemas y procedimientos desvelados en el presente documento.

En las realizaciones, cuando un cliente solicita acceso a un recurso en nombre de una aplicacion, el identificador de instancia de aplicacion de la aplicacion se envfa con la solicitud. El servidor que recibe la solicitud puede asociar el identificador de instancia de aplicacion con el recurso. Por ejemplo, el grupo de servidores puede almacenar el identificador de instancia de aplicacion en una tabla o cache localizada en uno o mas nodos (por ejemplo, servidores tales como los servidores 106a, 106B y/o 106C) localizados en el grupo 106 de servidores de tal manera que el identificador de instancia de aplicacion se asocia con el recurso. Antes de que el cliente se haga con el recurso, el cliente puede experimentar un error que lo obligara a perder la conexion con el recurso. Por ejemplo, el cliente que aloja la aplicacion o que realiza solicitudes u operaciones en nombre de la aplicacion puede perder su conexion de red al grupo de servidores, el cliente puede colgarse o puede producirse cualquier otro tipo de error que interfiera con el uso de las aplicaciones del recurso. Tras experimentar el error, la aplicacion puede conmutar por error a un nuevo nodo cliente en el grupo 102 de clientes. El nuevo nodo cliente puede volver a conectarse al grupo de servidores y enviar una segunda solicitud para acceder al recurso en nombre de la aplicacion. En las realizaciones, el cliente puede volver a conectar con el mismo nodo en el grupo 106 de servidores o un nodo diferente. La segunda solicitud para acceder al recurso puede incluir el identificador de instancia de aplicacion de la aplicacion. Tras recibir la segunda solicitud, el servidor (por ejemplo, un servidor 106A del grupo 106 de servidores) compara el identificador de instancia de aplicacion de la segunda solicitud con el identificador de instancia de aplicacion asociado con el recurso. Si coinciden los dos identificadores de instancia de aplicacion, el grupo de servidores invalida el recurso. En las realizaciones, la invalidacion del recurso puede comprender cerrar un archivo, eliminar un bloqueo del recurso o realizar de otro modo cualquier accion que libere el recurso para su uso. A continuacion, el nodo servidor puede conceder la segunda solicitud de la aplicacion para acceder al recurso. Si el identificador de instancia de aplicacion del segundo nodo no coincide con el identificador de aplicacion asociado con el recurso, el servidor no permitira el acceso al recurso hasta que se libere el recurso.

Para ilustrar una realizacion, un solicitante (por ejemplo, un procedimiento, una aplicacion, etc.) en el cliente 102A en el grupo 102 de clientes puede solicitar que el cliente 102A establezca una sesion con un servidor del grupo 106 de servidores. Por ejemplo, el cliente 102A puede establecer una sesion con el servidor 106A para acceder a una base de datos almacenada que esta en el servidor 106A o que forma parte del grupo 106 de servidores, en el que el servidor 106A puede acceder a la base de datos. A continuacion, el cliente 102A envfa una solicitud de un recurso en nombre del solicitante. Un identificador de instancia de aplicacion que identifica al solicitante esta asociado con la solicitud. En las realizaciones, la solicitud puede incluir el identificador de instancia de aplicacion o el identificador de instancia de aplicacion puede enviarse por separado de una manera tal que el servidor 106A pueda determinar que el identificador de instancia de aplicacion se asocia con la solicitud. En otra realizacion mas, el servidor 106A o el grupo 106A de servidores puede tener ya la informacion necesaria para asociar el identificador de instancia de aplicacion con la solicitud sin tener que recibir el identificador de instancia de aplicacion junto con la solicitud. A continuacion, el servidor 106A concede al solicitante acceso al recurso, permitiendo de este modo al solicitante realizar operaciones sobre o acceder de otro modo al recurso. Cuando se concede al solicitante acceso al recurso, el servidor 106A asocia un identificador de instancia de aplicacion con el recurso de una manera tal que indica que el solicitante esta actualmente accediendo al recurso. A continuacion, el recurso puede acotarse o bloquearse para que otros clientes o aplicaciones no puedan acceder o modificar el recurso hasta que el cliente 102 haya completado su operacion.

Antes de que el solicitante complete sus operaciones en el recurso, se produce un error que hace que el cliente 102A falle o pierda de otro modo su conexion al recurso. Debido a que el solicitante del cliente ha completado su operacion, no ha liberado el control del recurso. Por lo tanto, el recurso puede permanecer en un estado acotado o bloqueado. El grupo 102 de solicitantes o clientes puede emplear un mecanismo de conmutacion por error para hacer migrar el solicitante del cliente 102A al cliente 102B. Una vez completada la operacion de conmutacion por error, el cliente 102B puede volver a conectarse al grupo 106 de servidores en nombre del solicitante. El cliente 102B puede volver a conectarse al servidor 106A o establecer una nueva conexion con cualquier otro servidor en el grupo 106 de servidores (por ejemplo, el servidor 106B o 106C). En una situacion a modo de ejemplo, el cliente 102B vuelve a conectarse al servidor 106A. Tras volver a conectarse, el cliente 102B puede enviar una segunda solicitud para acceder al recurso en nombre del solicitante. Como se ha indicado anteriormente, debido a que el solicitante no ha liberado el control del recurso, el recurso aun puede estar en un estado bloqueado o acotado. Con el fin de acceder al recurso sin esperar que el servidor cambie automaticamente el estado del recurso, por ejemplo, a traves de una operacion de tiempo de espera, el solicitante puede proporcionar de nuevo su identificador de instancia de aplicacion con la segunda solicitud. El servidor 106A compara el identificador de instancia de aplicacion provisto de la segunda solicitud al identificador de instancia de aplicacion asociado con el recurso. Por ejemplo, comparando el identificador de instancia de aplicacion recibido o asociado de otro modo con la segunda solicitud a un identificador de instancia de aplicacion que el servidor 106A ha asociado con el recurso. El identificador de instancia de aplicacion asociado puede almacenarse en una cache o tabla local del servidor 106A, o puede almacenarse en otro lugar en el grupo 106 de servidores. Si el identificador de instancia de aplicacion almacenado en la cache coincide con el identificador de instancia de aplicacion que esta asociado con el recurso, el servidor 106A invalida o libera de otro modo el recurso y permite al cliente 102B acceder de nuevo al recurso en nombre del

5

10

15

20

25

30

35

40

45

50

55

60

solicitante sin esperar a que se libere el recurso por algun otro mecanismo (por ejemplo, por el tiempo de espera de estado acotado o bloqueado). Si los identificadores de instancia de aplicacion no coinciden, el cliente 102B tendra que esperar a que el recurso se libere antes de acceder al mismo.

Aunque en el ejemplo anterior, el cliente 102B se ha vuelto a conectar al mismo servidor 106A, tambien es posible, en otras realizaciones, que el cliente se conecte a otro nodo en el grupo 106 de servidores. Por ejemplo, el cliente 102B puede volver a conectarse al servidor 106B y presentar una segunda solicitud para volver a obtener el acceso al recurso en nombre del solicitante. La segunda solicitud puede asociarse de nuevo con el identificador de instancia de aplicacion del solicitante, por ejemplo, al incluirse en la segunda solicitud o asociarse de otro modo con la segunda solicitud. En este ejemplo, el servidor 106B puede no tener el identificador de instancia de aplicacion asociado con el recurso almacenado en su cache local debido a que el acceso original del recurso estaba en el servidor 106A. En tal situacion, el servidor 106B puede contactar con los otros servidores del grupo 106 de servidores para determinar si tienen un identificador de aplicacion asociado con el recurso. Si el identificador de aplicacion asociado con el recurso se almacena en un nodo diferente del grupo de servidores (por ejemplo, el servidor 106A), el identificador de instancia de aplicacion en el otro nodo del grupo de servidores se compara con el identificador de instancia de aplicacion provisto de la segunda solicitud. Si coinciden, el servidor 106B puede enviar una solicitud al servidor 106A para invalidar el recurso y, a continuacion, el servidor 106B puede permitir al solicitante (ahora en el cliente 102B) acceder al recurso. Si los identificadores de instancia de aplicacion no coinciden, el cliente 102B tendra que esperar a que se libere el recurso.

Basandose en los ejemplos anteriores, los expertos en la materia apreciaran que cualquier nodo cliente en el grupo 102 de clientes puede solicitar acceso y, a continuacion, proporcionar acceso, a un solicitante en el grupo 102 de clientes. Ademas, cualquier nodo servidor en un grupo de servidores (por ejemplo, cualquier servidor en el grupo 106 de servidores) es capaz de determinar si el solicitante tema acceso previamente al recurso incluso si el acceso se produjo en un nodo servidor diferente en el grupo de servidores. Los expertos en la materia apreciaran que la siguiente descripcion es simplemente un ejemplo de como puede operar la realizacion mostrada en la figura 1 y de que existen otras realizaciones. Por ejemplo, en lugar de acceder a recursos en un servidor remoto o en un grupo de servidores, los nodos cliente pueden realizar las realizaciones descritas en el presente documento para proporcionar a los solicitantes (por ejemplo, aplicaciones o procedimientos) acceso continuo a recursos que residen en el entorno agrupado (por ejemplo, en los mismos o diferentes nodos de grupo de clientes que forman el grupo de clientes). Como se describe con mayor detalle a continuacion, las realizaciones descritas en el presente documento pueden implicar diversas etapas u operaciones diferentes. Ademas, las realizaciones descritas en el presente documento pueden implementarse usando cualquier componente o modulo de software o hardware apropiado.

Volviendo ahora a la figura 2, la figura ilustra un diagrama de bloques de un entorno 200 de software que muestra un grupo 201 de nodos cliente con multiples nodos cliente (por ejemplo, los clientes 202 y 204) y un grupo 206 de nodos servidor con multiples nodos servidor (por ejemplo, el nodo 1 208 y el nodo 2 216). En las realizaciones, el cliente 202 solicita el acceso a un recurso, tal como el recurso 226, en un entorno 206 de grupo de servidores en nombre de un solicitante. El grupo 201 de nodos cliente puede ser un grupo de clientes, tal como el grupo 102 de clientes (figura 1). Aunque no se ilustra, el grupo de clientes puede contener mas de dos clientes. El grupo 206 de nodos servidor, puede ser un grupo de servidores, tal como el grupo 106 de servidores (figura 1) o puede ser cualquier otro tipo de entorno agrupado, tal como, pero sin limitarse a, una red virtual. El recurso 226 puede almacenarse en un almacen 228 de datos que es parte del entorno agrupado. Aunque no se muestra, en unas realizaciones alternativas, el almacen 228 de datos puede no ser parte del entorno agrupado, pero puede conectarse al entorno agrupado a traves de una red. Ejemplos de dicha red incluyen, pero sin limitarse a, Internet, una WAN, una LAN, o cualquier otro tipo de red conocida en la tecnica. En otras realizaciones mas, el almacen de datos puede ser parte de un nodo (por ejemplo, un dispositivo) que es una parte del grupo 206.

El grupo 206 de nodos servidor puede incluir uno o mas nodos, tales como el nodo 1 208 y el nodo 2 216. Aunque en la figura 2 solo se ilustran dos nodos, puede incluirse cualquier numero de grupos de nodos en el entorno 206 agrupado. En las realizaciones, los grupos 208 y 216 de nodos son capaces de recibir una solicitud para realizar una operacion en y/o conceder el acceso al recurso 226. En las realizaciones, el recurso 226 puede ser un archivo, un objeto, una aplicacion, datos o cualquier otro tipo de recurso almacenado en o accesible para un nodo en el grupo 206 de nodos o para un servidor independiente.

En las realizaciones, un cliente envfa una solicitud 222 inicial al entorno 206 agrupado. Como se ilustra en la figura 2, la solicitud 222 inicial puede enviarse por el cliente 202 y recibirse por el nodo 1 208. Sin embargo, en realizaciones alternativas, la solicitud 222 inicial puede enviarse por el cliente o cualquier otro nodo cliente en el grupo 201 de clientes y recibirse por el nodo 2 216 o cualquier otro nodo en el grupo 206 de servidores. Un ejemplo de solicitudes incluye, pero sin limitarse a, solicitudes para crear, abrir o acceder de otro modo a un archivo. La solicitud 222 puede transmitirse desde el cliente al grupo de nodos a traves de una red, tal como, pero sin limitarse a, Internet, una WAN, una LAN o cualquier otro tipo de red conocida en la tecnica. La solicitud 222 inicial puede incluir una solicitud de acceso a un recurso, tal como el recurso 226. En las realizaciones, la solicitud 222 tambien puede incluir un identificador de instancia de aplicacion que identifica el solicitante en cuyo nombre esta haciendo la solicitud el cliente 202. En las realizaciones, la solicitud 222 inicial puede consistir en uno o mas mensajes. Por ejemplo, la solicitud 222 puede ser un unico mensaje que contiene tanto la solicitud como un identificador de instancia de aplicacion. En otra realizacion, la solicitud 222 pueden ser multiples mensajes que incluyen una o mas

5

10

15

20

25

30

35

40

45

50

55

60

solicitudes, asf como uno o mas identificadores de instancia de aplicacion. En las realizaciones, el cliente 202 puede incluir una cache 214 de instancia de aplicacion que se usa para almacenar y/o generar uno o mas identificadores de instancia de aplicacion que pueden transmitirse con la solicitud 222.

Como se muestra en la figura 2, el nodo 1 208 puede recibir la solicitud 222 y un identificador de instancia de aplicacion del cliente 202. Si el recurso 226 solicitado esta disponible, por ejemplo, no acotado o bloqueado por otro cliente o aplicacion, el nodo 1 puede conceder a la solicitud del cliente (por ejemplo, el cliente 202) el acceso al recurso 226 en nombre de un solicitante que se esta ejecutando en el cliente. Tras conceder acceso al recurso 226, el controlador 210 de filtro puede asignar o crear de otro modo una asociacion entre el cliente 202 y el recurso 226 almacenando el identificador de instancia de aplicacion que ha recibido del cliente 202. En las realizaciones, la asociacion puede almacenarse como un objeto en la cache 212 de instancia de aplicacion que es una parte del nodo 1. Aunque la realizacion ilustrada muestra la cache 212 de instancia de aplicacion como una parte del nodo 1 208, en las realizaciones, la cache 212 de instancia de aplicacion puede almacenarse en otro lugar como una parte del grupo 206 de nodos. Los expertos en la materia apreciaran que el grupo 206 de nodos puede incluir una o mas caches de instancia de aplicacion, tal como la cache 220 de instancia de aplicacion en el nodo 2 216. En las realizaciones, cuando hay mas de una cache de instancia de aplicacion, los datos almacenados en las multiples caches de instancia de aplicacion pueden replicarse a traves de todas las caches de instancia de aplicacion o cada cache de instancia de aplicacion puede almacenar datos por separado.

En una realizacion, el identificador de instancia de aplicacion recibido del cliente, un identificador de instancia de aplicacion que identifica un solicitante (por ejemplo, una aplicacion o un procedimiento), puede almacenarse en una estructura _NETWORK_APP_INSTANCE_ECP_CONTEXT. La estructura

_NETWORK_APP_INSTANCE_ECP_CONTEXT puede definirse de la siguiente manera:

typdef struct _NETWORK_APP_INSTANCE_ECP_CONTEXT {

USHORT Size;

USHORT Reserved;

GUID AppInstancelD;

} _NETWORK_APP_INSTANCE_ECP_CONTEXT,

*PNETWORK_APP_INSTANCE_ECP_CONTEXT;

En tales realizaciones, el tamano variable puede almacenar informacion relacionada con el tamano de la estructura y el AppInstancelD variable puede ser un identificador de instancia de aplicacion unico para una aplicacion cliente de grupo de conmutacion por error, tal como un solicitante que ejecuta en el cliente 202. En las realizaciones, la _NETWORK_APP_INSTANCE_ECP_CONTEXT, u otro objeto o variable que contiene el identificador de instancia de aplicacion del solicitante pueden almacenarse en la cache 214 de identificador unico global (GUID). En las realizaciones, la estructura _NeTWORK_APP_INSTANCE_ECP_CONTEXT puede enviarse desde un cliente a un servidor en asociacion con una solicitud de acceso a un recurso (por ejemplo, una solicitud de creacion o de apertura). En una realizacion, el identificador de instancia de aplicacion del solicitante puede almacenarse en la cache GUID del nodo cliente que el solicitante esta ejecutando en el entorno 201 de cliente agrupado. En otra realizacion, aunque no se muestra en la figura 2, el grupo 201 de nodo cliente puede tener un deposito central que almacena identificadores de instancia de aplicacion. En tal realizacion, multiples nodos cliente en el grupo 201 de nodos cliente pueden acceder al deposito centralizado. En otra realizacion mas, los identificadores de instancia de aplicacion pueden almacenarse a traves de multiples caches GUID (por ejemplo, el cache 214 GUID y el cache 216 GUID). En tales realizaciones, el grupo 201 de nodos cliente puede emplear un algoritmo de replicacion para garantizar que las multiples caches GUID contengan los mismos identificadores de instancia de aplicacion.

Como se ha descrito anteriormente, el identificador de instancia de aplicacion puede asociarse con el recurso 226 mientras que el cliente 202 accede al recurso 226 en nombre de un solicitante. Un nodo 206 servidor puede almacenar dicha asociacion en una o mas caches de instancia de aplicacion que forman parte del grupo 206 de nodos servidor, tales como las caches 212 y 220 de instancia de aplicacion. En una realizacion, el identificador de instancia de aplicacion puede asociarse con el recurso anadiendolo a una lista de parametros extra creados (ECP) del recurso 226. La lista de ECP puede almacenarse en una cache de instancia de aplicacion que forma parte del grupo 206 de nodos servidor, tales como las caches 212 y 220 de instancia de aplicacion. En las realizaciones, cuando un ECP se recibe por un servidor, el servidor extrae un identificador de instancia de aplicacion del ECP y lo anade a una cache para asociarse con un recurso, un manipulador de recursos, etc. Como se ha descrito con respecto al almacenamiento de identificadores de instancia de aplicacion en el grupo 201 de clientes, los identificadores de instancia de aplicacion asociados con un nodo pueden almacenarse en una cache de instancia de aplicacion individual en un nodo en el grupo 206 de nodos servidor, en un deposito central en el grupo 206 de servidores o replicarse a traves de multiples caches de instancia de aplicacion en multiples nodos en el grupo 206 de nodos servidor.

En las realizaciones, el recurso 226 esta acotado o bloqueado mientras que un solicitante que ejecuta en el cliente 202 tiene acceso al recurso 226, impidiendo de este modo que otros clientes o aplicaciones accedan al recurso 226 y evitando cualquier conflicto potencial. En las realizaciones, antes de que el solicitante complete su operacion en el recurso 226, el cliente 202 experimenta un error que hace que pierda la conexion con el recurso. Por ejemplo, el cliente puede colgarse, desconectarse o perder su conexion de red con el nodo 208 servidor. En tales casos, el

5

10

15

20

25

30

35

40

45

50

55

60

recurso 226 puede estar todavfa en un estado acotado o bloqueado debido a que el solicitante no ha liberado un bloqueo en el recurso, evitando de este modo que otros clientes accedan al recurso 226.

Cuando el error se produce en el cliente 202, el solicitante puede utilizar un mecanismo 232 de conmutacion por error de cliente para migrar a un nuevo nodo cliente (por ejemplo, el cliente 204) en el grupo 201 de clientes. Los expertos en la materia apreciaran que puede emplearse cualquier tipo de mecanismo de conmutacion por error en la conmutacion 232 por error de cliente. En las realizaciones, el mecanismo 232 de conmutacion por error tambien puede incluir la migracion del identificador de instancia de aplicacion del solicitante que puede haberse almacenado en la cache 214 GUID en el cliente 202 fallido. Una vez completada la migracion, el solicitante puede intentar volver a obtener el acceso al recurso 226. En las realizaciones, el cliente 204 puede enviar una segunda solicitud 224 al nodo 1 para solicitar acceso al recurso 226 en nombre del solicitante. Sin embargo, sin las realizaciones de acceso continuo desveladas en el presente documento, cuando el nodo 1 208 recibe una solicitud para acceder al recurso 226 en nombre del cliente 204 (el remitente de la segunda solicitud 224), puede denegar la solicitud debido a que el recurso 226 esta todavfa en un estado acotado o bloqueado desde el acceso previo que el cliente 202 hizo en nombre del recurso. Sin las realizaciones desveladas en el presente documento, el nodo 1 208 reconocena que la segunda solicitud de acceso al recurso 226 fue desde una localizacion diferente (por ejemplo, el cliente 204). El nodo 1 208 no podna determinar que la solicitud es para el mismo solicitante que mantiene el bloqueo del recurso 226 y, por lo tanto, determinana que la concesion de la solicitud dana como resultado un conflicto. Sin embargo, si el mismo solicitante esta intentando acceder al recurso 226, no hay ningun motivo de conflicto y obligar al cliente a esperar que el recurso se libere por el sistema puede dar como resultado retrasos indebidos.

El identificador de instancia de aplicacion puede usarse para resolver este problema. En las realizaciones, la segunda solicitud 224 tambien puede incluir que el identificador de instancia de aplicacion identifique que el solicitante ha migrado al cliente 204 durante la conmutacion por error mostrada en 232. En las realizaciones, el identificador de instancia de aplicacion del solicitante puede estar presente en la cache 228 GUID del cliente 204 antes de la migracion del solicitante durante la conmutacion 232 por error de cliente. Por ejemplo, puede haberse empleado un mecanismo de replicacion para replicar el identificador de instancia de aplicacion del solicitante a traves de los nodos en el grupo 201 de clientes. En otra realizacion, el solicitante 203 puede almacenar su identificador de instancia de aplicacion. En otra realizacion mas, puede hacerse migrar el identificador de instancia de aplicacion del solicitante 203 durante la conmutacion 232 por error de cliente.

Tal como se ha descrito con respecto a la solicitud 222, el identificador de instancia de aplicacion puede transmitirse en el mismo mensaje que la segunda solicitud 224 o la segunda solicitud 224 puede estar compuesta por un numero de mensajes diferentes. Cuando la segunda solicitud se recibe en el grupo 206 de nodos, o un nodo individual en el grupo, tal como el nodo 1 208, y el servidor de recepcion determina que el recurso esta acotado o bloqueado, se determina si el identificador de instancia de aplicacion en la segunda solicitud 224 es el mismo que el identificador de instancia de aplicacion asociado con el recurso 226. En las realizaciones, el nodo 2 216 comparara el identificador de instancia de aplicacion recibido con la segunda solicitud 222 con el identificador de instancia de aplicacion que esta asociado con el recurso 226. El identificador de aplicacion asociado con el recurso 226 puede almacenarse en la cache 212 de instancia de aplicacion del nodo 1 212. En las realizaciones donde existen multiples caches de instancia de aplicacion en el grupo 206 de nodos, la determinacion puede comprobar mas de una cache de instancia de aplicacion en el grupo 206 de nodos. En tales realizaciones, si un identificador de instancia de aplicacion coincidente no esta localizado en la cache 212 de instancia de aplicacion, el nodo 1 216 puede enviar una solicitud al nodo 2 212 para determinar si un identificador de instancia de aplicacion coincidente esta localizado en la cache 220 de instancia de aplicacion.

En una realizacion, si el identificador de instancia de aplicacion recibido en la segunda solicitud 224 no coincide con el identificador de instancia de aplicacion asociado con el recurso 226 (que puede almacenarse en la cache 212 y/o 220 de instancia de aplicacion), la segunda solicitud 224 puede no concederse hasta que el recurso 226 este libre. Sin embargo, si se encuentra una coincidencia, el servidor de recepcion (por ejemplo, el nodo 1 208) y/o el grupo 206 de nodos servidor realizan acciones para conceder acceso al recurso 226 sin provocar un retraso indebido al cliente 204 y al solicitante 203. En tales casos, el grupo 206 de nodos puede invalidar el recurso 226, sacando de este modo el recurso 226 de un estado acotado o bloqueado. En las realizaciones, invalidar un acceso previo puede comprender cualquier accion que saque un recurso fuera de un estado acotado o bloqueado. Un ejemplo no limitante es cerrar un archivo abierto (por ejemplo, si el recurso 226 es un archivo). Una vez que el acceso anterior esta invalidado, puede concederse la segunda solicitud 224 para acceder al recurso 226, proporcionando de este modo un acceso continuo al solicitante 203.

En una realizacion, el nodo que recibe la segunda solicitud 224, tal como el nodo 1 208 en la figura 2, puede realizar las acciones necesarias para invalidar el acceso previo del recurso 226 si un nodo diferente (por ejemplo, el nodo 2 216) tiene acceso y/o permiso para invalidar el acceso previo. Sin embargo, en algunos casos, el nodo que recibe la solicitud puede no tener acceso o permiso para invalidar el acceso previo. Por ejemplo, tal instancia puede producirse si la solicitud 222 original se hizo al nodo 2 216, en cuyo caso, el nodo 2 216 puede tener control sobre el recurso. En tales casos, el nodo que recibe la segunda solicitud 224 puede enviar una solicitud al nodo de control para invalidar el acceso previo. Una vez que el nodo de control ha invalidado el acceso previo, el nodo que recibe la segunda solicitud 224 puede conceder la segunda solicitud 224. En otras realizaciones, el nodo que recibe la segunda solicitud 224 puede enviar una solicitud a un nodo diferente para conceder al cliente 204 y/o al solicitante

5

10

15

20

25

30

35

40

203 (ahora residente en el cliente 204) el acceso al recurso 226.

El procedimiento descrito evita un retraso indebido en la concesion de una segunda solicitud 224 para acceder a un recurso 226 de un solicitante 203 que ha accedido previamente y aun mantiene un bloqueo en el recurso 226 a traves del uso de identificadores de instancia de aplicacion. Ademas, los identificadores de instancia de aplicacion ofrecen la ventaja de garantizar que cualquier solicitud concedida no cree un conflicto en el recurso 226. Por ejemplo, si la solicitud se ha recibido de una aplicacion diferente, la solicitud incluira un identificador de instancia de aplicacion que es diferente del identificador de instancia de aplicacion asociado con el recurso que dana como resultado que se rechazara la solicitud. Debido a que los identificadores de instancia de aplicacion son identificadores globalmente unicos, el identificador de instancia de aplicacion para diferentes aplicaciones no sera el mismo.

La figura 3 es una realizacion de un procedimiento 300 que un solicitante puede emplear para obtener acceso continuo a un recurso en un entorno agrupado de cliente. Por ejemplo, un solicitante puede ser un cliente, tal como el cliente 202 (figura 2), que emplea el procedimiento 300 para acceder a un recurso (por ejemplo, el recurso 226). En las realizaciones, el recurso puede residir en una maquina remota, tal como un servidor. El servidor puede ser un servidor independiente o parte de un entorno agrupado, tal como el grupo 206 de servidores (figura 2). El flujo comienza en la operacion 302 donde se envfa una solicitud de un recurso a un servidor. En las realizaciones, la solicitud puede ser acceder a un recurso. En las realizaciones, el acceso a un recurso puede comprender abrir un archivo, crear un archivo, o acceder o realizar de otro modo una operacion en un recurso que puede ser remoto para un cliente. En las realizaciones, un solicitante puede operar en un entorno agrupado de cliente. En tales realizaciones, la solicitud enviada en la operacion 302 puede enviarse desde un primer cliente en el entorno agrupado de cliente.

El flujo continua hacia la operacion 304 donde se envfa un identificador de instancia de aplicacion, por ejemplo, a un servidor (por ejemplo, un servidor independiente o un nodo en un entorno agrupado). En una realizacion, el primer cliente que envio la solicitud tambien puede enviar el identificador de instancia de aplicacion en nombre del solicitante. Como se ha descrito anteriormente, un identificador de instancia de aplicacion es un GUID que identifica al solicitante (por ejemplo, una aplicacion, un cliente o un procedimiento secundario de una aplicacion que solicita acceso a un recurso). En una realizacion, el identificador de instancia de aplicacion puede enviarse en un mensaje transmitido a traves de una red. El identificador de instancia de aplicacion puede transmitirse en el mismo mensaje que contiene la solicitud en la operacion 302 o puede transmitirse en un mensaje diferente. En dichas realizaciones, un objeto que contiene el identificador de instancia de aplicacion, tal como, pero sin limitarse a, la _NETWORK_APP_INSTANCE_ECP_CONTEXT descrita con respecto a la figura 2, puede enviarse en la operacion 302.

En una realizacion, puede usarse una interfaz para enviar el identificador de instancia de aplicacion en la operacion 304. La interfaz puede ser una interfaz de nivel de nucleo localizada en un cliente o disponible para un cliente que opera en un entorno agrupado de cliente. En las realizaciones, la interfaz de nivel de nucleo puede usarse por el solicitante y/o el cliente para enviar un identificador de instancia de aplicacion a un servidor. El siguiente es un ejemplo no limitante de una interfaz de nivel de nucleo que puede emplearse en la operacion 304 para enviar un identificador de instancia de aplicacion:

# if(NTDDI_VERSION >= NTDDI_WIN8)

//

// Contexto de ECP para una aplicacion para proporcionar su ID de instancia, //

typedef struct _NETWORK_APP_INSTANCE_ECP_CONTEXT {

//

// Esto debe establecerse para el tamano de esta estructura,

//

USHORT Size;

//

5

10

15

20

25

// Esto debe establecerse a cero,

//

USHORT Reserved;

//

// El llamante coloca un GUID que siempre debe ser unico para una unica instancia de la aplicacion.

//

GUID AppInstancelD;

} NETWORK_APP_INSTANCE_ECP_CONTEXT,

*PNETWORK_APP_INSTANCE_ECP_CONTEXT;

//

// El GUID usado para la estructura APP_INSTANCE_ECP_CONTEXT.

//

// {6AA6BC45-A7EF-4af7-9008-FA462E144D74}

//

DEFINE_GUID(GUID_ECP_NETWORK_APP_INSTANCE, 0x6aa6bc45, 0xa7ef, 0x4af7, 0x90,

0x8, 0xfa, 0x46, 0x2e, 0x14, 0x4d, 0x74);

# endif // NTDDI VERSION >= NTDDI WIN8

Aunque se proporciona una interfaz de nivel de nucleo espedfica, los expertos en la materia apreciaran que pueden emplearse otras interfaces de nivel de nucleo en la operacion 304 para enviar el identificador de instancia de aplicacion.

En otra realizacion, puede emplearse una interfaz de usuario de aplicacion (API) en la operacion 304 para enviar un identificador de instancia de aplicacion. En dicha realizacion, el solicitante y/o el cliente pueden enviar un identificador de instancia de aplicacion haciendo una llamada a la API. La API puede alojarse en el cliente que realiza la operacion 304 (por ejemplo, el primer cliente en un grupo de servidores) o la API puede alojarse en otro dispositivo y acceder a la misma por el solicitante u otra aplicacion o procedimiento. El siguiente es un ejemplo no limitante de una API que puede emplearse en la operacion 304 para enviar un identificador de instancia de aplicacion:

NTSTATUS RegisterAppInstance (

_in PGUID AppInstance );

Aunque se proporciona una API espedfica, los expertos en la materia apreciaran que pueden emplearse otras API en la operacion 304. Ademas, aunque la operacion 304 se ilustra como una operacion discreta, los expertos en la materia apreciaran que el envfo del identificador de instancia de aplicacion puede realizarse simultaneamente con el envfo de la solicitud en la operacion 302.

Cuando el recurso solicitado no esta bloqueado, la solicitud enviada en la operacion 302 se concede y el flujo continua hacia la operacion 306 donde se accede al recurso. Como se ha descrito anteriormente, el servidor o dispositivo que controla el recurso puede colocar el recurso en un estado acotado o bloqueado mientras el solicitante accede al recurso en la operacion 306. En algun momento, mientras se accede al recurso, se produce un error, tal como los errores descritos con referencia a la figura 2, que hace que el cliente falle o pierda de otro modo la conexion al recurso. El error puede hacer que el cliente (por ejemplo, el primer cliente en el grupo de servidores) pierda el acceso al recurso antes de que el solicitante complete su uso del recurso. En tales circunstancias, el recurso puede no liberarse de su estado acotado o bloqueado.

5

10

15

20

25

30

35

40

45

50

55

60

El flujo continua hacia la operacion 308, donde se realiza una operacion de conmutacion por error. En las realizaciones, la operacion de conmutacion por error puede comprender la clonacion del solicitante y su estado a un cliente diferente en el grupo de nodos cliente (por ejemplo, un segundo cliente). En las realizaciones, el estado del solicitante puede clonarse en el segundo y el solicitante puede ejecutarse en el segundo cliente de una manera tal que pueda reanudar la ejecucion desde el punto donde fallo el primer cliente. En otra realizacion, el solicitante puede estar en comunicacion con el primer cliente (en lugar de ejecutarse en el mismo) en el momento de la primera conmutacion por error de los clientes. En tales realizaciones, la operacion de conmutacion por error puede comprender que el solicitante establezca comunicaciones con un segundo cliente en el grupo de clientes.

En las realizaciones, la informacion de estado, incluyendo pero sin limitarse al identificador de instancia de aplicacion de solicitantes, puede transferirse desde el primer cliente al segundo cliente. En una realizacion, el primer cliente puede enviar un mensaje que incluye el identificador de instancia de aplicacion del solicitante y/o la informacion de estado del solicitante. El identificador de instancia de aplicacion y/o el estado pueden enviarse durante el procedimiento de conmutacion por error o, en las realizaciones, pueden enviarse antes de que el primer cliente fracase, tal como durante un procedimiento de replicacion que clona informacion a traves de los clientes en un entorno agrupado de cliente. En otra realizacion, el identificador de instancia de aplicacion del solicitante y/o la informacion de estado pueden almacenarse en una localizacion o deposito central en la red agrupada de cliente. En dichas realizaciones, el procedimiento de conmutacion por error puede proporcionar al segundo cliente la localizacion del identificador de instancia de aplicacion del solicitante y/o informacion de estado. En otra realizacion mas, el solicitante puede mantener su identificador de instancia de aplicacion. En tales realizaciones, la operacion de conmutacion por error de cliente puede comprender volver a localizar o establecer de otro modo una conexion entre el solicitante y un segundo cliente.

En las realizaciones, despues de la operacion de conmutacion por error de cliente, el flujo continua hacia la operacion 310. En la operacion 310, se envfa una segunda solicitud para el mismo recurso al entorno agrupado. En las realizaciones, la segunda solicitud se envfa por el segundo cliente en el grupo de clientes en nombre del solicitante. La segunda solicitud puede enviarse usando la misma manera que se ha descrito con respecto al primer recurso en la operacion 302. Con el fin de mantener un acceso continuo al recurso y evitar un retraso indebido, el flujo continua hacia la operacion 312 donde el identificador de instancia de aplicacion se envfa nuevamente al entorno agrupado. El identificador de instancia de aplicacion puede enviarse en la operacion 308 de acuerdo con una de las realizaciones descritas con respecto a la operacion 304. En las realizaciones, debido a que un cliente diferente (por ejemplo, el segundo cliente) esta enviando la segunda solicitud, el servidor que recibe la solicitud puede no ser capaz de identificar la segunda solicitud como perteneciente al mismo solicitante que mantiene un bloqueo en el recurso (por ejemplo, debido a que la solicitud se realiza desde una maquina diferente, una direccion diferente, etc.). Sin embargo, enviando los identificadores de instancia de aplicacion en las operaciones 304 y 308, el servidor sera capaz de identificar las solicitudes como pertenecientes al mismo solicitante y concedera acceso continuo al recurso como se ha descrito anteriormente con respecto a las figuras 1 y 2. El flujo continua hacia la operacion 314 y el solicitante reanuda el acceso al recurso. En las realizaciones, el segundo cliente puede recibir una respuesta a la segunda solicitud desde el servidor indicando que el servidor ha concedido la segunda solicitud. En las realizaciones, tras recibir la indicacion, el segundo cliente puede acceder al recurso en nombre del solicitante.

La figura 4 es una realizacion de un procedimiento 400 realizado por un nodo en un entorno agrupado de servidor para proporcionar acceso continuo a un recurso. Las realizaciones del procedimiento 400 pueden realizarse por un nodo tal como el nodo 1 208 (figura 2) en un entorno agrupado, tal como el grupo 206 de nodos (figura 2). En las realizaciones, el procedimiento 400 puede realizarse por un nodo que tiene acceso a un recurso. El flujo comienza en la operacion 402 donde el nodo recibe una solicitud de un recurso. En las realizaciones, un recurso puede ser un archivo, un objeto, un procedimiento, datos o cualquier otro tipo de recurso que este bajo el control de y/o al que pueda accederse por el nodo que realiza la operacion 400. Un identificador de instancia de aplicacion puede recibirse con la solicitud en la operacion 402.

El flujo continua hacia la operacion de decision 404 donde se determina si el recurso esta en un estado acotado o bloqueado. Los expertos en la materia apreciaran que en la operacion 404 puede emplearse cualquier manera de determinar si un recurso esta acotado o bloqueado. Si el recurso no esta en un estado acotado o bloqueado, el flujo se ramifica hacia NO en la operacion 412 donde se concede la solicitud del recurso. En las realizaciones, la concesion de la solicitud puede comprender permitir al solicitante el acceso al recurso, realizar una operacion en el recurso en nombre del solicitante, o permitir cualquier tipo de acceso o modificacion al recurso. Por ejemplo, la concesion de la solicitud en la operacion 412 puede incluir abrir un archivo o crear un archivo.

Si el recurso esta en un estado acotado o bloqueado, el flujo se ramifica hacia Sf desde la operacion 404 a la operacion de decision 406. En la operacion de decision 406, el identificador de instancia de aplicacion recibido con la solicitud en la operacion 402 se compara con un identificador de instancia de aplicacion que esta asociado con el recurso. Por ejemplo, como se describe con respecto a la figura 2, un nodo puede asociar un identificador de instancia de aplicacion con un recurso cuando un cliente o aplicacion accede a un recurso. Como se ha descrito anteriormente, la asociacion del identificador de instancia de aplicacion de un solicitante que accede a un recurso puede almacenarse en un nodo, por ejemplo, en una cache de instancia de aplicacion, como se describe en varias realizaciones expuestas en la figura 2. En las realizaciones, el identificador de instancia de aplicacion que se proporciona en un ECP enviado con una solicitud para un recurso, por ejemplo, en una estructura

5

10

15

20

25

30

35

40

45

50

55

_NETWORK_APP_INSTANCE_ECP_CONTEXT, puede anadirse a una lista de ECP asociada con el recurso.

En una realizacion, la asociacion del recurso de instancia de aplicacion puede residir localmente en el nodo que realiza el procedimiento 400. En tales casos, la comparacion puede realizarse en una cache de instancia de aplicacion local residente en el servidor. Sin embargo, tal como se ha expuesto con respecto a la figura 2, un entorno agrupado puede contener un numero de caches de instancia de aplicacion distribuidas a traves de diferentes nodos. Ademas, cada una de las diferentes caches de instancia de aplicacion puede almacenar datos separados y/o diferentes. El identificador de aplicacion asociado con el recurso acotado o bloqueado puede almacenarse en un nodo diferente en el entorno agrupado. En tales casos, la operacion 406 puede incluir el envfo de una solicitud a un nodo diferente para realizar la comparacion en la operacion 406. La solicitud puede incluir el identificador de instancia de aplicacion recibido en la operacion 402.

Si el identificador de instancia de aplicacion recibido no es el mismo que el identificador de instancia de aplicacion asociado con el recurso, el flujo se ramifica hacia NO en la operacion 410. En la operacion 410 se deniega la solicitud de acceso al recurso recibido en la operacion 402. En las realizaciones, la solicitud puede denegarse con el fin de evitar un conflicto de recursos. Debido a que el identificador de aplicacion recibido no es el mismo que el identificador de instancia de aplicacion asociado, la solicitud de acceso al recurso recibido en la operacion 402 es de un solicitante o aplicacion diferente. La concesion de una solicitud al cliente o aplicacion diferente, como puede ser en este caso, puede provocar una situacion de conflicto que interfiera con la aplicacion que actualmente accede al recurso. Por ejemplo, la aplicacion diferente puede modificar el recurso de una manera que modifica o interfiere de otro modo con las operaciones realizadas en el recurso por el solicitante que actualmente mantiene un bloqueo en el recurso.

Sin embargo, recibir un identificador de aplicacion con la solicitud 402 que es el mismo que el identificador de aplicacion asociado con los recursos acotados o bloqueados indica que puede haber ocurrido un error que provoco que el solicitante que accedfa al recurso perdiera su acceso al recurso sin liberar adecuadamente el recurso. Por ejemplo, el solicitante puede operar en un grupo de nodos cliente. El cliente espedfico en el que el solicitante estaba operando podna haber perdido la conexion al servidor o fallado antes de que el solicitante completara sus operaciones sobre el recurso. Con el fin de proporcionar acceso continuo al recurso, es decir, para permitir al solicitante volver a obtener el acceso al recurso sin experimentar retrasos indebidos o inaceptables, el flujo se ramifica hacia Sf en la operacion 408.

En la operacion 408, el recurso esta invalidado. Como se ha descrito anteriormente, la invalidacion del recurso puede incluir el cambio del estado acotado del recurso o eliminar de otro modo un bloqueo en el recurso. Por ejemplo, si el recurso es un archivo, invalidar el recurso puede incluir el cierre del archivo. Los expertos en la materia apreciaran que en la operacion 408 puede emplearse cualquier procedimiento de liberacion de un recurso acotado o bloqueado.

Haciendo referencia de nuevo a la figura 2, en las realizaciones, el acceso a un recurso puede estar bajo el control de un nodo en el entorno agrupado diferente del nodo que recibe la solicitud de acceso al recurso en la operacion 402. Por ejemplo, un manipulador del recurso puede residir en un nodo diferente en el entorno agrupado. En tales realizaciones, invalidar el recurso puede incluir enviar una solicitud al nodo que controla el acceso al recurso para invalidar el recurso. En respuesta al envfo de la solicitud, el nodo remoto puede invalidar el recurso.

Despues de que el recurso se invalide, el flujo continua hacia la operacion 412 donde se concede la solicitud de acceso al recurso. La concesion de la solicitud puede comprender permitir al solicitante el acceso al recurso, realizar una operacion en el recurso en nombre del solicitante, o permitir cualquier tipo de acceso o modificacion al recurso. Por ejemplo, la concesion de la solicitud en la operacion 412 puede incluir abrir un archivo o crear un archivo. La concesion de dicho acceso puede realizarse por el nodo que recibe la solicitud en la operacion 402, o por otro nodo en el entorno agrupado.

Los procedimientos 300 y 400 son simplemente algunos ejemplos de flujos operativos que pueden realizarse de acuerdo con las realizaciones. Las realizaciones no estan limitadas a la descripcion espedfica proporcionada anteriormente con respecto a las figuras 3-6 y pueden incluir operaciones adicionales. Ademas, las etapas operativas representadas pueden combinarse en otras etapas y/o reordenarse. Ademas, pueden usarse mas o menos etapas con respecto a las empleadas con los procedimientos descritos en las figuras 3-4.

La figura 5 ilustra un sistema 500 informatico general, que puede usarse para implementar las realizaciones descritas en el presente documento. El sistema 500 informatico es solo un ejemplo de un entorno informatico y no pretende sugerir ninguna limitacion en cuanto al ambito de uso o funcionalidad de las arquitecturas informaticas y de red. Tampoco debe interpretarse que el sistema 500 informatico tenga ninguna dependencia o requisito relacionado con uno cualquiera o una combinacion de los componentes ilustrados en el sistema 500 informatico a modo de ejemplo. En las realizaciones, el sistema 500 puede usarse como los clientes y/o servidores descritos anteriormente con respecto a las figuras 1 y 2.

En su configuracion mas basica, el sistema 500 incluye habitualmente al menos una unidad 502 de procesamiento y una memoria 504. Dependiendo de la configuracion exacta y del tipo de dispositivo informatico, la memoria 504

5

10

15

20

25

30

35

40

45

50

puede ser volatil (tal como RAM), no volatil (tal como ROM, memoria flash, etc.) o alguna combinacion. Esta configuracion mas basica se ilustra en la figura 5 por la lmea 506 discontinua. La memoria 504 de sistema almacena las instrucciones 520, tales como las instrucciones para realizar los procedimientos de disponibilidad continua desvelados en el presente documento y los datos 522, tales como los identificadores de instancia de aplicacion que pueden almacenarse en un sistema de almacenamiento de archivos con un almacenamiento tal como el almacenamiento 508.

La expresion medio legible por ordenador tal como se usa en el presente documento puede incluir medios de almacenamiento informatico. Los medios de almacenamiento informatico pueden incluir medios volatiles y no volatiles, extrafbles y no extrafbles, implementados en cualquier procedimiento o tecnologfa para el almacenamiento de informacion, tales como instrucciones legibles por ordenador, estructuras de datos, modulos de programa u otros datos. La memoria 504 de sistema, el almacenamiento extrafble y el almacenamiento 508 no extrafble son todos ejemplos de medios de almacenamiento informatico (por ejemplo, el almacenamiento de memoria). Los medios de almacenamiento informatico pueden incluir, pero sin limitarse a, RAM, ROM, memoria de solo lectura borrable electricamente (EEPROM), memoria flash u otra tecnologfa de memoria, CD-ROM, discos versatiles digitales (DVD) u otro almacenamiento optico, cinta magnetica, almacenamiento en disco magnetico u otros dispositivos de almacenamiento magnetico, o cualquier otro medio que pueda usarse para almacenar informacion y al que pueda accederse por el dispositivo 500 informatico. Cualquiera de tales medios de almacenamiento informatico puede ser parte del dispositivo 500. El dispositivo 500 informatico tambien puede tener un dispositivo(s) (514) de entrada, tal como un teclado, un raton, un puntero, un dispositivo de entrada de sonido, un dispositivo de entrada tactil, etc. Tambien puede incluirse un dispositivo(s) 516 de salida, tal como una pantalla, unos altavoces, una impresora, etc. Los dispositivos mencionados anteriormente son ejemplos y pueden usarse otros.

La expresion medio legible por ordenador tal como se usa en el presente documento tambien puede incluir medios de comunicacion. Los medios de comunicacion pueden incorporarse mediante instrucciones legibles por ordenador, estructuras de datos, modulos de programa u otros datos en una senal de datos modulada, tal como una onda portadora u otro mecanismo de transporte, e incluyen cualquier medio de suministro de informacion. La expresion “senal de datos modulada” puede describir una senal que tiene una o mas caractensticas establecidas o cambiadas de tal manera que codifican informacion en la senal. A modo de ejemplo, y sin limitacion, los medios de comunicacion pueden incluir medios cableados, tales como una red cableada o una conexion directa por cable, y medios inalambricos, tales como medios acusticos, de radiofrecuencia (RF), infrarrojos y otros medios inalambricos.

Las realizaciones de la invencion pueden ponerse en practica a traves de un sistema en un chip (SOC) donde cada uno o muchos de los componentes ilustrados en la figura 5 pueden integrarse en un unico circuito integrado. Un dispositivo SOC de este tipo puede incluir una o mas unidades de procesamiento, unidades graficas, unidades de comunicaciones, unidades de virtualizacion de sistemas y diversas funcionalidades de aplicacion, todas las cuales estan integradas (o “quemadas”) sobre el sustrato de chip como un unico circuito integrado. Cuando se opera a traves de un SOC, la funcionalidad, descrita en el presente documento, con respecto a proporcionar acceso continuo a un recurso puede operar a traves de una logica de aplicacion espedfica integrada con otros componentes del dispositivo/sistema 500 informatico en el unico circuito integrado (chip).

Se ha hecho referencia a lo largo de la presente memoria descriptiva a “una realizacion”, lo que significa que un rasgo, estructura o caractenstica descrita espedfica se incluye en al menos una realizacion. Por lo tanto, el uso de tales frases puede referirse a mas de una realizacion. Ademas, los rasgos, estructuras o caractensticas descritas pueden combinarse de cualquier manera adecuada en una o mas realizaciones.

Sin embargo, los expertos en la materia pueden reconocer que las realizaciones pueden ponerse en practica sin uno o mas de los detalles espedficos, o con otros procedimientos, recursos, materiales, etc. En otros casos, no se han mostrado o descrito en detalle estructuras, recursos u operaciones bien conocidas, simplemente para evitar complicar aspectos de las realizaciones.

Aunque se han ilustrado y descrito realizaciones y aplicaciones a modo de ejemplo, debe entenderse que las realizaciones no se limitan a la configuracion y los recursos precisos descritos anteriormente. Pueden hacerse diversas modificaciones, cambios y variaciones evidentes para los expertos en la materia en la disposicion, operacion y detalles de los procedimientos y sistemas desvelados en el presente documento.

Claims

5

10

15

20

25

30

35

40

45

50

REIVINDICACIONES

1. Un procedimiento para proporcionar acceso continuo a un recurso, comprendiendo el procedimiento:

recibir en un grupo (106) de servidores, que incluye al menos un servidor (106A, 106B, 106C; 208, 216), una primera solicitud (222) para acceder a un recurso (226) desde una aplicacion (203) cliente, ejecutandose la aplicacion cliente en un primer cliente (102A; 202), en el que la primera solicitud se recibe desde el primer cliente en un grupo (106; 201) de clientes;

asociar en el grupo de servidores un primer identificador de instancia de aplicacion con el recurso; permitir por el grupo de servidores el primer acceso solicitado al recurso;

recibir en el grupo de servidores una segunda solicitud (224) para el recurso desde la aplicacion cliente despues de recuperarse de un fallo, en el que la segunda solicitud se recibe desde un segundo cliente (102B; 204) diferente del primer cliente;

recibir en el grupo de servidores un segundo identificador de instancia de aplicacion asociado con la segunda solicitud;

determinar si el primer identificador de instancia de aplicacion y el segundo identificador de instancia de aplicacion son los mismos; y

cuando los identificadores de instancia de aplicacion primero y segundo son los mismos, realizar por el grupo de servidores las etapas que comprenden:

invalidar la primera solicitud; y

conceder la segunda solicitud de acceso al recurso.
2. El procedimiento de la reivindicacion 1, en el que el primer identificador de instancia de aplicacion esta asociado con una instancia de aplicacion de una solicitud abierta.
3. El procedimiento de la reivindicacion 1, en el que el primer identificador de instancia de aplicacion esta asociado con un procedimiento.
4. El procedimiento de la reivindicacion 1, en el que el primer identificador de instancia de aplicacion esta asociado con al menos un procedimiento secundario de una aplicacion.
5. El procedimiento de la reivindicacion 1, en el que la asociacion del primer identificador de instancia de aplicacion comprende recibir el primer identificador de instancia de aplicacion en una estructura _NETWORK_APP_INSTANCE_ECP_CONTEXT.
6. Un procedimiento para proporcionar una conmutacion por error de clientes agrupados para hacer migrar una aplicacion (203) cliente desde un primer cliente (102A; 202) a un segundo cliente (102B; 204), comprendiendo el procedimiento:

recibir, desde el primer cliente (102A; 202) en el segundo cliente (102B; 204), un identificador de instancia de aplicacion para la aplicacion (203) cliente;

enviar, desde el segundo cliente a un grupo (106) de servidores que incluye al menos un servidor (106A, 106B, 106C; 208, 216), una solicitud (224) para acceder al recurso en nombre de la aplicacion cliente; enviar, desde el segundo cliente al grupo de servidores, el identificador de instancia de aplicacion para la aplicacion cliente; y

acceder, por el segundo cliente, cuando se permite por el grupo (106) de servidores, al recurso en nombre de la aplicacion cliente.
7. El procedimiento de la reivindicacion 6, en el que un servidor que previamente ha concedido una solicitud para acceder al recurso desde el primer cliente en nombre de la aplicacion cliente es el servidor que ha permitido el acceso al recurso por el segundo cliente.
8. El procedimiento de la reivindicacion 6, en el que el segundo cliente envfa la solicitud en respuesta a una conmutacion por error de aplicacion cliente.
9. Un sistema para facilitar la conmutacion por error de aplicacion cliente en un entorno agrupado, comprendiendo el sistema:

un grupo (106) de servidores que incluye al menos un servidor (106A, 106B, 106C; 208, 216) que comprende:

al menos un procesador (502) configurado para ejecutar instrucciones ejecutables por ordenador; al menos un medio de almacenamiento legible por ordenador que almacena las instrucciones ejecutables por ordenador que cuando se ejecutan por el al menos un procesador se adaptan para realizar las siguientes etapas:

recibir una primera solicitud (222) para acceder a un recurso (226) desde un primer cliente (102A; 202) en nombre de una aplicacion (203) cliente;

10

15

20

asociar un primer identificador de instancia de aplicacion con el recurso; permitir el acceso de la aplicacion cliente al recurso;

recibir una segunda solicitud (224) para el recurso desde un segundo cliente (102B; 204), en el que el segundo cliente es diferente del primer cliente;

recibir, desde el segundo cliente, un segundo identificador de instancia de aplicacion asociado con la segunda solicitud;

determinar si el primer identificador de instancia de aplicacion y el segundo identificador de instancia de aplicacion son los mismos;

cuando los identificadores de instancia de aplicacion primero y segundo son los mismos, realizar las etapas que comprenden:

invalidar la primera solicitud; y

conceder la segunda solicitud de acceso al recurso.
10. El sistema de la reivindicacion 9, en el que el sistema comprende ademas:

el primer cliente, que comprende:

al menos un procesador configurado para ejecutar instrucciones ejecutables por ordenador; al menos un medio de almacenamiento legible por ordenador que almacena las instrucciones ejecutables por ordenador que cuando se ejecutan por el al menos un procesador se adaptan para realizar las siguientes etapas:

enviar la primera solicitud;

enviar el identificador de instancia de aplicacion a un segundo cliente.