Procedimiento y disposiitvo para asignar direcciones de paquetes a un conjunto de equipos.

Procedimiento para asignar direcciones lógicas a direcciones físicas de un conjunto de equipos para unaconmutación entre al menos dos equipos redundantes del conjunto de equipos que se encuentran en conexiónoperativa y que presentan en cada caso un módulo (ARP) que funciona en un nivel que se encuentra bajo elnivel de aplicación,

con cuya ayuda se realiza una asignación de las direcciones lógicas a las direcciones físicasde interlocutores de comunicación, recibiéndose del módulo (ARP) que trabaja en un nivel inferior al nivel deaplicación un mensaje de solicitud ARP Request de un interlocutor de comunicación y acusándose recibo porparte de uno de los equipos con su dirección física con ARP Response,

caracterizado porque se proporciona una relación de comunicación entre una función de control deconmutación (FOC) que trabaja en el nivel de aplicación y el módulo (ARP) que trabaja a un nivel inferior al nivelde aplicación,

comunicando el módulo (ARP) que trabaja a un nivel inferior al nivel de aplicación a la función de control deconmutación (FOC) que trabaja sobre el nivel de aplicación, mediante la relación de comunicación, que se harecibido el mensaje de solicitud ARP Request,

acusándose recibo al mensaje de solicitud ARP Request sólo con la dirección física, en el caso de que la funciónde control de conmutación (FOC), que trabaja en el nivel de aplicación, lo permita, eincluyendo la función de control de conmutación (FOC), que trabaja en el nivel de aplicación un equipo paradecidir si se contesta un mensaje de solicitud ARP Request un parámetroo un conjunto de parámetros deentorno.

Procedimiento y dispositivo para asignar direcciones de paquetes a un conjunto de equipos.

En sistemas de ordenadores fiables, tal como los que se utilizan en sistemas de comunicación, se mantienen disponibles recursos redundantes según el estado de la técnica. Los mismos pueden estar configurados por ejemplo como capacidad de ordenador, capacidades de memoria o de entrada/salida, aportando el recurso una plataforma o equipo. Cuando falla un equipo, asume inmediatamente un equipo redundante las tareas del equipo que ha fallado, por lo que visto desde fuera el funcionamiento y la disponibilidad sólo se ven mínimamente afectados.

En la publicación WENSONG ZHANG: “Linux Virtual Server for Scalable Network Services” (servidor virtual Linux para servicios de red escalables) , PAPERr, [Online] 2000, páginas 1-10, XP002372188 Ottawa Linux Symposium 2000, URL: http//www.linuxvirtualserver.org/ols/lvs.pdf [encontrado el 2006-03-15] se describen la motivación, el proyecto y la implementación interna de un servidor Linux virtual. El objetivo de este servidor Linux virtual es poner a disposición un marco básico, muy escalable y de alta disponibilidad para establecer servicios de red mediante utilización de un gran cluster de servidores usuales en el mercado. Aquí se amplía la pila (Stack) del Linux Kernel en el sentido de apoyar tres técnicas de distribución de carga de IP que permiten que servicios paralelos de distintos tipos de Server Clusters aparezcan como un servicio bajo una única dirección de IP.

En el libro de STEVENS W R ED-STEVENS Y COLAB.: “TCP/IP Illustrated, ARP: ADDRESS RESOLUTION PROTOCOL” TCP/IP ILLUSTRATED. VOL. 1: THE PROTOCOLS, PROFESSIONAL COMPUTING SERIES, READING (Revista TCP/IP, ARP: Protocolo de resolución de direcciones. Revista TCP/IP. Vol. 1: Los protocolos, ciclo de ordenadores profesionales, lección. MA. ADDISON WESLEY, US, Bd. VOL. 1, 1994, páginas 53-68, XP002247360 ISBN: 0-201-63346-9 se describen en particular el Address Resolution Protocol (ARP; protocolo de resolución de direciones) y el Reverse Address Resolution Protocol (RARP; protocolo inverso de resolución de direcciones) .

En la publicación BRUSCHI D Y COLAB.: “SARP: a secure address resolution protocol” COMPUTER SECURITY APPLICATIONS CONFERENCE 2003. PROCEEDINGS. 19TH ANNUAL “SARP: Un protocolo seguro de resolución de direcciones” Conferencia sobre aplicaciones de seguridad de ordenadores, 2003. Actas. 19ª anual” 8-12 DEC. 2003, PISCATAWAY;NJ;USA IEEE LNKD-DOI: 10.1109/CSAC.2003.1254311, 8 diciembre 2003 (2003-12-08) , páginas 66-74. XP010673780 ISBN: 978-0-7695-2041-4 se debate una versión segura del protocolo de resolución de direcciones ARP.

Cuando un equipo que ha fallado y cuyo funcionamiento ha de sustituirse presenta interfaces basadas en paquetes, a través de las cuales está en contacto el mismo con otros equipos, entonces hay básicamente dos posibilidades de restablecer la operatividad.

En el primer caso tiene el equipo conectado como sustitutivo una dirección de paquetes propia, que es distinta de la del equipo que ha fallado. En este caso deben conmutarse todos los interlocutores de comunicación explícitamente a esta nueva dirección de paquetes.

En el segundo caso tiene el equipo que asume la función del equipo que ha fallado la facultad de proporcionar la dirección de paquetes del equipo que ha fallado. Esto tiene la ventaja de que no aparecen demoras así como situaciones de no alcanzabilidad que pueden evitarse en consideración a los escenarios de alta disponibilidad. Además esto tiene la ventaja de menores exigencias a los interlocutores de comunicación, que en este segundo caso, cuando sucede un fallo, no tienen que conmutar o ser conmutados a otra dirección de paquetes. No obstante, para ello es una premisa necesaria que la dirección lógica de paquetes que puede conectarse sustitutivamente en un conjunto de equipos se traduzca, es decir, se asigne al direccionamiento físico, igualmente basado en paquetes, de la red antepuesta. Esto es necesario, ya que la red debe responder a cada uno de los equipos con su propia dirección física de HW.

En cuanto al ejemplo de una red de paquetes basada en IP, está configurada la dirección lógica de paquetes como dirección de IP y la dirección física como dirección MAC inequívoca a nivel mundial de la interfaz Ethernet que participa. Para que la repercusión negativa en el funcionamiento debida al fallo del equipo activo pueda mantenerse especialmente reducida desde el punto de vista de la red de IP y de los interlocutores de comunicación remotos, se ejecuta una llamada función “IP-Failover" (de sustitución en caso de fallo) . Aquí asume un equipo redundante respecto al equipo que ha fallado, además de sus funciones, también su dirección de IP. Esto significa que la dirección de IP del equipo que ha fallado se transmite a un equipo en condiciones de funcionar con la misma dirección de IP. Junto a ello, puede tener el equipo otras direcciones de IP que no son direcciones de IP-Failover.

La función IP-Failover puede estar realizada tal que el equipo que asume el nuevo papel, respecto a las direcciones de IP que él mismo asume, envía en cada caso un mensaje relativo a la resolución de direcciones (gratuitous ARP; ARP gratuito o innecesario) a su red local (LAN) y con ello envía de facto un mensaje de Broadcast (radio) a la red que lo rodea. Todos los equipos receptores actualizan a continuación sus listas de direcciones (ARP caches o máscaras) , comprobando los mismos las direcciones de IP que se encuentran en sus caches en relación con las resoluciones de direcciones recibidas (dirección lógica de IP a dirección MAC física en Ethernet) , dado el caso inscriben la dirección MAC del equipo que asume la función y sobreescriben entonces la dirección MAC del equipo que ha fallado. Esta es la premisa para que los sistemas interlocutores remotos, que comunican mediante IP (protocolo de Internet) con el sistema de ordenadores, no noten, al menos en el nivel de aplicación, el fallo dentro del sistema de ordenadores.

Durante el tiempo entre el fallo de un equipo hasta la conexión sustitutoria mediante el equipo redundante, no pueden enviarse con éxito en particular los mensajes que procedían de interlocutores de comunicación externos mediante el enrutador antepuesto al equipo que ha fallado. Lo mismo rige en cuanto a otros interlocutores de comunicación del equipo en la misma red (LAN) . A lo más tardar una vez transcurrido el tiempo de validez de la resolución de la dirección, pretenderá un interlocutor de comunicación, por ejemplo el enrutador, traducir de nuevo la dirección de IP que ha fallado. Para ello genera el mismo una solicitud de resolución de la dirección a su red (ARP request) . Esto tiene el efecto de que todos los equipos que se encuentran en la red reciben la solicitud aun cuando los mismos son competentes para una dirección de paquetes lógica predeterminada y dan a conocer esto dado el caso en el acuse de recibo indicando su dirección MAC física en la red. Si esto se realiza ahora en el corto espacio de tiempo entre el fallo y la conexión sustitutoria, entonces caerá la dirección de IP afectada incluso de la lista de direcciones del enrutador, ya que no puede encontrarse ningún traslado de dirección válido a una dirección MAC. Para sistemas de alta fiabilidad es por lo tanto importante limitar a un mínimo el espacio de tiempo entre el comienzo de la falta y la conexión sustitutoria.

Por desgracia no pueden tratarse también mediante este procedimiento todos los escenarios de conexión sustituitoria posibles. Así se sabe por las plataformas de ordenadores comerciales que los mismos pueden permanecer bloqueados de forma duradera en el nivel de aplicación, es decir, que no pueden correr procesos de aplicación individuales o partes de procesos de aplicación (Threads) o dado el caso incluso todos los procesos de aplicación. No obstante, esto no significa que en el nivel de IP la comunicación con enrutadores antepuestos u otros interlocutores de comunicación de la red esté igualmente interrumpida, pudiendo la misma seguir manteniéndose en determinadas circunstancias. El sistema de vigilancia de la plataforma de ordenadores detecta ahora el fallo y conmuta incluso las direcciones de IP-Failover a un equipo mantenido como redundante. Pero con ello se encuentran de repente dos equipos en la red que traducen ambas direcciones de paquetes lógicos IP-Failover sobre demanda a su propia dirección MAC física.

Con ello queda al azar si un enrutador antepuesto,... [Seguir leyendo]

1. Procedimiento para asignar direcciones lógicas a direcciones físicas de un conjunto de equipos para una conmutación entre al menos dos equipos redundantes del conjunto de equipos que se encuentran en conexión operativa y que presentan en cada caso un módulo (ARP) que funciona en un nivel que se encuentra bajo el nivel de aplicación, con cuya ayuda se realiza una asignación de las direcciones lógicas a las direcciones físicas de interlocutores de comunicación, recibiéndose del módulo (ARP) que trabaja en un nivel inferior al nivel de aplicación un mensaje de solicitud ARP Request de un interlocutor de comunicación y acusándose recibo por parte de uno de los equipos con su dirección física con ARP Response, caracterizado porque se proporciona una relación de comunicación entre una función de control de conmutación (FOC) que trabaja en el nivel de aplicación y el módulo (ARP) que trabaja a un nivel inferior al nivel de aplicación, comunicando el módulo (ARP) que trabaja a un nivel inferior al nivel de aplicación a la función de control de conmutación (FOC) que trabaja sobre el nivel de aplicación, mediante la relación de comunicación, que se ha recibido el mensaje de solicitud ARP Request, acusándose recibo al mensaje de solicitud ARP Request sólo con la dirección física, en el caso de que la función de control de conmutación (FOC) , que trabaja en el nivel de aplicación, lo permita, e incluyendo la función de control de conmutación (FOC) , que trabaja en el nivel de aplicación un equipo para decidir si se contesta un mensaje de solicitud ARP Request un parámetroo un conjunto de parámetros de entorno.

2. Procedimiento según la reivindicación 1, caracterizado porque tras un espacio de tiempo predeterminado una vez que se ha acusado recibo a la dirección física correcta con ARP Response en el nivel de aplicación, se envía de nuevo al menos un mensaje iniciado en el nivel de aplicación mediante la función de control de conmutación (FOC) que trabaja sobre el nivel de aplicación para la asignación de la dirección física a las direcciones lógicas con Gratuitous ARP libremente a través del módulo (ARP) que trabaja a un nivel que se encuentra debajo del nivel de aplicación, a todos los interlocutores de comunicación.

3. Procedimiento según la reivindicación 1 ó 2, caracterizado porque está prevista a elección adicionalmente una vigilancia de HW de los equipos en el nivel de aplicación o una vigilancia de HW de la disponibilidad de la función de conmutación de los equipos, cuya activación da lugar a medidas de rearranque de las partes no disponibles del equipo.

4. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque las direcciones lógicas de al menos uno de los equipos se desactivan cuando se detecta una pérdida duradera de la accesibilidad de los parámetros de entorno.

5. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque uno de los parámetros de entorno está activado en todo momento para exactamente uno de los equipos redundantes, de los que al menos hay dos, y no está activado para los demás equipos del total de equipos redundantes, de los que al menos hay dos, en el que cuando uno de los parámetros de entorno está activado para uno de los equipos, de los que al menos hay dos, uno de los equipos redundantes, de los que al menos hay dos, proporciona una comunicación sobre direcciones de failover y una función de procesamiento y los restantes equipos redundantes, de los que al menos hay dos, no proporcionan la comunicación sobre las direcciones de failover.

6. Procedimiento según la reivindicación 5, caracterizado porque uno de los parámetros de entorno es proporcionado por un control externo.

7. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque uno de los equipos para el servicio operativo de una dirección lógica, mediante escucha en la red, recibe la transmisión de los mensajes ARP Response, Gratuitous ARP para la asignación de direcciones lógicas y físicas de los demás equipos en el dispositivo de control de conmutación (FOC) que funciona en el nivel de aplicación.

8. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque las asignaciones de dirección recibidas son sometidas a plausibilidad frente a los parámetros de entorno y se emite una alarma al operario mediante una función de gestión de la red (Network Management) emitiéndose indicadores de falta.

9. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la dirección lógica está configurada como dirección IP-Failover.

10. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la dirección física está configurada como dirección MAC.

11. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque un parámetro de entorno es la disponibilidad/no disponibilidad de una comunicación con un equipo redundante del conjunto de equipos, o porque un parámetro de entorno es la posibilidad de comunicación con otros equipos que controlan la conexión sustitutoria, o porque un parámetro de entorno es la accesibilidad de recursos centrales que son necesarios para el tratamiento correcto de las tareas de uno del conjunto de los equipos.

12. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque un parámetro de entorno es un estado de servicio de uno del conjunto de equipos.

13. Dispositivo que incluye un dispositivo de control de conmutación (FOC) que funciona en un nivel de aplicación para la conmutación entre al menos dos equipos redundantes que presentan en cada caso un módulo (ARP) que funciona en un nivel que se encuentra bajo el nivel de aplicación, con cuya ayuda se realiza una asignación de las direcciones lógicas a las direcciones físicas de interlocutores de comunicación, recibiéndose del módulo (ARP) que trabaja en un nivel inferior al nivel de aplicación un mensaje de solicitud ARP Request de un interlocutor de comunicación y acusándose recibo por parte de uno de los equipos con su dirección física con ARP Response, caracterizado porque el dispositivo de control de conmutación (FOC) que funciona en el nivel de aplicación y el módulo (ARP) que funciona a un nivel por debajo del nivel de aplicación presentan respectivos medios para establecer una relación de comunicación entre el dispositivo de control de conmutación (FOC) que funciona en el nivel de aplicación y el módulo (ARP) que funciona a un nivel que se encuentra por debajo del nivel de aplicación, en el que mediante la relación de comunicación la disponibilidad de direcciones lógicas bajo una dirección física de un equipo se hace depender de si puede realizarse un intercambio de mensajes (handshake) entre el dispositivo de control de conmutación (FOC) que funciona en el nivel de aplicación y el módulo (ARP) que funciona a un nivel que se encuentra por debajo del nivel de aplicación, en el que el módulo (ARP) que trabaja a un nivel inferior al nivel de aplicación contiene medios para comunicar a la función de control de conmutación (FOC) que trabaja sobre el nivel de aplicación, mediante la relación de comunicación, que se ha recibido el mensaje de solicitud ARP Request, en el que se acusa recibo al mensaje de solicitud ARP Request sólo con la dirección física, en el caso de que la función de control de conmutación (FOC) , que trabaja en el nivel de aplicación, lo permita, y en el que la función de control de conmutación (FOC) , que trabaja en el nivel de aplicación de un equipo para decidir si se contesta un mensaje de solicitud ARP Request, posee medios para incluir un parámetro o un conjunto de parámetros de entorno.

14. Dispositivo según la reivindicación 13 caracterizado porque uno de los parámetros de entorno está activado en todo momento para exactamente uno de los equipos redundantes, de los que al menos hay dos, y no está activado para los demás equipos redundantes, de los que al menos hay dos, en el que cuando uno de los parámetros de entorno está activado para uno de los equipos, de los que al menos hay dos, uno de los equipos redundantes, de los que al menos hay dos, proporciona una comunicación sobre direcciones de failover y una función de procesamiento y los restantes equipos del conjunto de equipos redundantes, de los que al menos hay dos, no proporcionan la comunicación sobre las direcciones de failover, y porque uno de los parámetros de entorno es aportado por un sistema de control externo.

15. Dispositivo según una de las reivindicaciones 13 o 14, caracterizado porque un parámetro de entorno es un estado de servicio de uno de los equipos redundantes, de los que al menos hay dos.