WO2006079574A1 - Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen - Google Patents

Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen Download PDF

Info

Publication number
WO2006079574A1
WO2006079574A1 PCT/EP2006/050028 EP2006050028W WO2006079574A1 WO 2006079574 A1 WO2006079574 A1 WO 2006079574A1 EP 2006050028 W EP2006050028 W EP 2006050028W WO 2006079574 A1 WO2006079574 A1 WO 2006079574A1
Authority
WO
WIPO (PCT)
Prior art keywords
arp
address
level
foc
addresses
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2006/050028
Other languages
English (en)
French (fr)
Inventor
Norbert LÖBIG
Jürgen TEGELER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Nokia Solutions and Networks GmbH and Co KG
Siemens Corp
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Priority to US11/883,277 priority Critical patent/US7730168B2/en
Priority to ES06700314T priority patent/ES2391901T3/es
Priority to EP06700314A priority patent/EP1844598B1/de
Priority to DK06700314.5T priority patent/DK1844598T3/da
Priority to CN2006800035038A priority patent/CN101112070B/zh
Publication of WO2006079574A1 publication Critical patent/WO2006079574A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • redundant resources are kept available in the prior art. These can be embodied, for example, as computer capacity, storage or input / output capacities, the resource being provided by a
  • the replacement device has its own packet address, which is different from the one of the failed device. In this case, all communication partners must be explicitly switched to this new packet address.
  • the device taking over the function of the failed device has the capability to provide the packet address of the failed device.
  • This has the advantage that no avoidable in terms of high availability scenarios time delays and unavailability arise.
  • this has the advantage of lesser demands on the communication partners, who in this second case do not have to switch to a different packet address in failure scenarios. have to be switched.
  • Ahead- this is based on the fact that the logical packet address that can be replaced by a plurality of devices is unambiguously and reliably resolved to the likewise packet-based physical addressing of the upstream network d. H . is assigned. This is necessary because the network must address each of the devices with their own physical HW address.
  • the logical packet address is formed as an IP address and the physical address as a globally unique MAC address of the participating Ethernet interface. So that the impairment of the function due to the failure of the active device can be kept particularly low from the point of view of the IP network and the remote communication partners, a so-called "IP failover" function is carried out, whereby a device redundant to the failed device takes over Their functions also include their IP address, which means that the IP address of the failed device is transferred to a functioning device with the same IP address, and the device can have other IP addresses that are not IP failover addresses.
  • the IP failover function can be implemented in such a way that the accepting device assigns to the IP addresses which it accepts a respective message for address resolution (gratuitous ARP) on its local area network (LAN) and thus de facto a broadcast message into the surrounding network. All receiving devices then update their address lists (ARP caches) by checking their cached IP addresses for the received address resolutions (logical IP address to physical MAC address on the Ethernet), and also entering the MAC address of the receiving device overwrite the MAC address of the failed device. This is the prerequisite for the remote communication via IP (Internet Protocol) with the computer system. Systems at least at the application level do not notice the failure within the computer system.
  • IP Internet Protocol
  • the invention has for its object to provide a way and a device, with the help of the occurrence and impact of "split brain” scenarios can be minimized.
  • the advantage of the invention can be seen in address handling at the application level.
  • the assessment of whether a platform is functional or needs to be replaced by an IP failover function is determined at the application level by the fail-over control function based on a plurality of environmental criteria (environmental parameters).
  • An environmental criterion or parameters may be the availability / unavailability of the communication to the redundant device, the ability to communicate with other devices that control the replacement circuit, the accessibility of central resources necessary for the proper handling of the device's tasks.
  • the fail-over control ensures that at any time the two redundant devices are assigned from a plurality of redundant devices Environmental criteria not at the same time to active operation, d. H . Provision of IP fail-over addresses can be set.
  • the ARP request is made dependent on whether, in particular, a predetermined message exchange (handshake) between ARP module and failover control can be performed at the application level.
  • HW mechanisms for resetting the device can be used in such a way that the packet-based interfaces are deactivated as the first action of the automatic restart in order to further reduce the time window for possible address conflicts after SW problems.
  • a further advantage of the invention is the fact that listening on the network is performed for the purpose of operator alarming in the event of permanent inconsistency between the state of one of the redundant devices specified by the fail-over control and the address resolutions exchanged in the network ,
  • Environmental parameters include state variables of the own system or foreign systems, communication and protocol relationships, accesses to remote units such as data bases.
  • m 2 should apply, but this should not be any limitation of the method with regard to any number of devices should .
  • the facilities are designed as (computer) platforms.
  • a network management NM can be provided in the network.
  • each of the platforms PIf1, PIf2 has at least one packet-based interface and is able to serve a plurality of failover addresses with a defined functionality.
  • the two platforms consequently form a large number of redundant devices with regard to the aforementioned failover addresses and the functionality to be provided for them.
  • an environment parameter is set for exactly one of the two platforms at any given time and is not set for the rest of the platform (s).
  • the environmental parameter should be the operating states act / standby. If the environment parameter is set for one of the two platforms, this should provide communication about the failover addresses and the desired processing function. If the environment criterion is not set for a platform, it should not provide the failover addresses. External control provides the environmental parameters in the manner described. For the sake of simplicity, a platform with set environmental parameter will be referred to as active (act) below. the fail over address, one with no environment parameter set as standby (stb). referred to the failover addresses. In this case, it is particularly excluded that an environmental parameter is permanently set to active for more than one platform.
  • the ARP module notifies the Fail Over Control FOC that an ARP request has been received.
  • An ARP request is only acknowledged if the Fail Over Control FOC of a device explicitly allows this.
  • ARP requests are de facto not answered autonomously via a low level function of the IOP stack or the operating system, but rather out of the application level.
  • a failure or snagging of the application level of the platform thus leads to the fact that the Fail Over Control FOC this device is also no longer available, so that subsequently arriving ARP requests are no longer answered.
  • ARP requests will not be answered if either the Fail over Control FOC considers this to be correct or if the communication of the ARP module with the Fail over Control is disturbed.
  • the failover control FOC does not answer ARP requests when the device is in the status stb. Being stuck at the application level shuts down the ARP handling of the affected device.
  • a platform active with regard to the failover address receives an ARP request, it will answer it, but assumes that other platforms could also unjustifiably claim the IP failover address.
  • it sends at least one gratuitous ARP to resolve the sender address as a precautionary measure. This is done at the initiative of Fail over Control from the application level of the facility.
  • Fail over Control from the application level of the facility.
  • gratuitious ARP is precautionarily cyclically generated with a certain minimum distance. This is also done at the initiative of Fail over Control from the device application level. Also in this case, an interface between FOC on application level and the ARP module is required. Each ARP request is notified and, in addition or as an alternative, leads to the possibly repeatedly applied gratuitous ARP initiated from the application level.
  • HW monitoring of the platform can take place on the application level. This has the consequence that a sticking of the platform or the fail-over control of this platform due to SW defect or overload can be detected quickly and leads to the recovery caused by HW mechanisms of the platform or parts of the platform, if necessary , also disable the packet - based interfaces as a first action resp. be reset. With the onset of a platform formerly active for a packet address, the environmental parameters will change in such a way that one of the other intended platforms assumes their functions and thus ensures complete availability of the functionality offered by the platform. The HW monitoring requires the presence of appropriate HW functions.
  • a platform deactivates its IP failover addresses if it determines the permanent loss of accessibility of the environmental parameters.
  • the environment parameters of another platform are set in such a way that it will henceforth serve the named IP fail-over addresses and thus do not have its own interaction.
  • These failover addresses would lead to unwanted faults and malfunctions.
  • Resource availability for example, internal resources for processing processing or undisturbed communication with other external processing instances) are included in the environmental parameter.
  • each platform can receive the acknowledgments on ARP requests and the gratuitous ARPs of further platforms from the ARP module into the fail over control FOC by listening to the network.
  • the fail over control instructs the ARP module, all ARP responses, which are not sent as broadcast messages, and all ARP requests and gratuitous ARPs that are sent in broadcast mode and used for address resolution, to deliver the fail over control when the In this case, the IP failover addresses served by the fail-over control experience a different resolution than the resolution to their own MAC address.
  • Failover Control to optionally check the consistency of the content with its own environment parameter. This means that it can be used to determine which other platform feels responsible for the failover address at a time.
  • the platform active with respect to the address can thus output the physical address of an unauthorized accessing further platform for alert purposes and deploy gratuitous ARPs for correction.
  • An address-inactive platform or any other platform on the network can thus recognize the platforms involved in a split brain situation and alert the operator.
  • a platform inactive with respect to the address can check its own environment parameter against the address resolution in the network for consistency and also alert the operator. Due to the alerting and to be regarded as a last resort operator intervention, the duration of a possible address conflict is further reduced and the availability of the function provided further increased.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)
  • Computer And Data Communications (AREA)

Abstract

Ein ,,split brain" Scenario ist bei Hochverfügbarkeitsforderungen unbedingt zu vermeiden. Beim Stand der Technik ist zur Behandlung dieser Problematik eine separate Hardware Einheit vorgesehen, die die einzelnen Einrichtungen auf IP-Ebeneüberwacht. Diese Hardware Einheit sorgt dafür, dass nur dann ein IP-Failover stattfindet, wenn die als ausgefallen erkannte Einrichtung auch keine ARP requests mehr beantwortet. Problematisch an dieser Lösung ist, dass das entsprechende Verfahren aufwendig und vergleichsweise langsam ist. Die Erfindung löst dieses Problem, indem eine Kommunikationsbeziehung zwischen einer auf Applikationsebene arbeitenden Umschaltesteuervorrichtung (FOC) und dem auf Protokollebene arbeitenden Modul (ARP) bereitgestellt wird, über die eine Verlagerung des Quittierens der korrekten physikalischen Adresse (ARP Request) auf die Applikationsebene vorgenommen wird.

Description

Beschreibung
Verfahren und Vorrichtung zur Zuordnung von Paketadressen einer Mehrzahl von Einrichtungen
In zuverlässigen Rechnersystemen, wie sie in Kommunikationssystemen eingesetzt sind, werden beim Stand der Technik redundante Ressourcen bereitgehalten . Diese können beispielsweise als Rechnerkapazität, Speicher- oder Ein-/Ausgabe-Kapa- zitäten ausgebildet sein, wobei die Ressource von einer
Plattform oder Einrichtung bereitgestellt wird. Beim Ausfall einer Einrichtung übernimmt eine redundante Einrichtung unmittelbar die Aufgaben der ausgefallenen Einrichtung, so dass von außen gesehen Funktion und Verfügbarkeit nur minimal beeinträchtigt sind.
Weist eine hinsichtlich ihrer Funktion zu ersetzende ausgefallene Einrichtung paketbasierte Schnittstellen auf, über die sie in Kontakt mit anderen Einrichtungen steht, so gibt es prinzipiell zwei Möglichkeiten, die Operabilität wiederherzustellen :
Im ersten Fall hat die ersatzgeschaltete Einrichtung eine eigene Paketadresse, die von derj enigen der ausgefallenen Einrichtung verschieden ist . In diesem Fall müssen alle Kommunikationspartner explizit auf diese neue Paketadresse umgeschaltet werden .
Im zweiten Fall hat die die Funktion der ausgefallenen Ein- richtung übernehmende Einrichtung die Fähigkeit, die Paketadresse der ausgefallen Einrichtung bereitzustellen . Dies hat den Vorteil, dass keine im Hinblick auf Hochverfügbarkeitsszenarien vermeidbaren Zeitverzüge und Nichterreichbarkeiten entstehen . Außerdem hat das den Vorteil geringerer Anforder- ungen an die Kommunikationspartner, die in diesem zweiten Falle in Ausfallszenarien nicht auf eine andere Paketadresse umschalten müssen bzw . umgeschaltet werden müssen . Voraus- Setzung hierfür ist aber, dass die über eine Mehrzahl von Einrichtungen ersatzschaltbare logische Paketadresse eindeutig und zuverlässig auf die ebenfalls paketbasierte physikalische Adressierung des vorgelagerten Netzes aufgelöst d. h . zugeordnet wird. Dies ist notwendig, da das Netz j ede der Einrichtungen mit ihrer eigenen physikalischen HW-Adresse ansprechen muss .
Im Hinblick auf das Beispiel eines IP-basierten Paketnetzes ist die logische Paketadresse als IP-Adresse und die physikalische Adresse als weltweit eindeutige MAC-Adresse der beteiligten Ethernet-Schnittstelle ausgebildet . Damit die Beeinträchtigung der Funktion durch den Ausfall der aktiven Einrichtung aus Sicht des IP-Netzes und der fernen Kommuni- kationspartner besonders gering gehalten werden kann, wird eine sogenannte „IP-Failover" - Funktion ausgeführt . Hierbei übernimmt eine zu der ausgefallenen Einrichtung redundante Einrichtung mit deren Funktionen auch deren IP-Adresse . Dies bedeutet, dass die IP-Adresse der ausgefallenen Einrichtung auf eine funktionsfähige Einrichtung mit derselben IP-Adresse übertragen wird. Daneben kann die Einrichtung weitere IP- Adressen haben, die keine IP-Failover Adressen sind.
Die IP-Failover Funktion kann so realisiert sein, dass die übernehmende Einrichtung zu den IP-Adressen, die sie übernimmt, j eweils eine Nachricht zur Adressauflösung (gratuitous ARP) auf ihr lokales Netz (LAN) absetzt und damit de facto eine Broadcast-Nachricht in das sie umgebende Netz sendet . Alle empfangenden Einrichtungen aktualisieren daraufhin ihre Adresslisten (ARP Caches ) , indem sie in ihre Caches befindlichen IP-Adressen hinsichtlich der empfangenen Adressauflösungen (logische IP-Adresse zu physikalischer MAC Adresse am Ethernet) überprüfen, gegenebenfalls die MAC-Adresse der übernehmenden Einrichtung eintragen und dabei die MAC-Adresse der ausgefallenen Einrichtung überschreiben . Dies ist die Voraussetzung dafür, dass die über IP (Internet Protokoll) mit dem Rechnersystem kommunizierenden, entfernten Partner- Systeme zumindest auf Applikationsebene den Ausfall innerhalb des Rechnersystems nicht bemerken .
Für die Zeit zwischen dem Ausfall einer Einrichtung bis zur Ersatzschaltung durch die redundante Einrichtung werden insbesondere Nachrichten, die von externen Kommunikationspartnern stammen, durch den der ausgefallenen Einrichtung vorgelagerten Router nicht erfolgreich zugestellt werden können . Gleiches gilt für weitere Kommunikationspartner der Einrichtung am gleichen Netz (LAN) . Spätestens mit dem Ablauf der Gültigkeitszeit der Adressauflösung wird ein Kommunikationspartner, z . B . der Router, die ausgefallene IP- Adresse erneut auflösen wollen . Hierzu generiert er eine Adressauflösungsanfrage an sein Netz (ARP request) . Dies hat die Wirkung, dass alle am Netz befindlichen Einrichtungen die Anfrage erhalten, ob sie für eine vorgegebene logische Paketadresse zuständig sind und dies gegebenenfalls in der Quittung unter Angabe ihrer physikalischen MAC-Adresse am Netz offenbaren . Erfolgt dies nun in der kurzen Zeit zwischen Ausfall und Ersatzschaltung, so wird die betroffene IP-
Adresse sogar aus der Adressliste des Routers herausfallen, da keine gültige Adressauflösung auf eine MAC-Adresse gefunden werden kann . Für hochzuverlässige Systeme ist es daher wichtig, den Zeitraum zwischen Fehlerbeginn und Ersatzschaltung auf ein Minimum zu begrenzen .
Leider können auch mit dieser Vorgehensweise nicht alle möglichen Ersatzschaltescenarien behandelt werden . So ist von kommerziellen Rechnerplattformen bekannt, dass diese dauer- haft auf Applikationsebene hängen bleiben können, d. h . einzelne Applikationsprozesse oder Applikationsprozeßanteile (Threads ) oder gegebenenfalls sogar alle Applikationsprozesse können nicht mehr zum Ablauf gebracht werden . Dies bedeutet aber nicht, dass auf IP-Ebene die Kommunikation mit vorge- lagerten Routern oder anderen Kommunikationspartnern am Netz ebenfalls unterbrochen ist, diese kann unter Umständen weiter aufrechterhalten bleiben . Die Überwachung der Rechnerplatt- form erkennt nun den Ausfall und schaltet inklusive IP- Failover Adressen auf eine redundant vorgehaltene Einrichtung um. Damit befinden sich aber plötzlich zwei Einrichtungen am Netz , die beide die betroffenen logischen IP-Failover Paketadressen auf Anforderung auf ihre eigene physikalische MAC-Adresse auflösen .
Damit ist es dem Zufall überlassen, ob ein vorgelagerter Router zum Zeitpunkt des Zustellens einer Nachricht gerade die ausgefallene Einrichtung oder die operable, ersatzgeschaltete Einrichtung adressiert . Wenn also der ARP Modul (Teil des IP Stack) der ausgefallenen Einrichtung noch ARP requests beantworten kann und aufgrund anderer Gegebenheiten eine Ersatzschaltung inklusive IP-Failover stattgefunden hat, kann es zu einer gravierenden andauernden Kommunikationsstörung und damit zum Funktionsverlust der Einrichtung kommen . Wenn in dieser Situation beide Einrichtungen einen ARP request für eine IP-Failover Adresse empfangen, für die eine Ersatzschaltung stattgefunden hat, beantworten ihn beide . Wenn nun die ausgefallene Einrichtung die ARP response zufällig später schickt als die operable ersatzgeschaltete Einrichtung, speichern alle Kommunikationspartner und Router des Netzes die MAC-Adresse der ausgefallenen Einrichtung als die zugehörige MAC-Adresse zur IP-Failover Adresse, wenn sie diese IP fail-over Adresse bereits aktuell auf eine MAC
Adresse aufgelöst haben, also zu der genannten Einrichtung bereits Kommunikation besteht . Die IP-Nachrichten werden also weiterhin an die ausgefallene Einrichtung geschickt statt an die ersatzgeschaltete Einrichtung, die die Funktion der ausgefallenen übernehmen sollte . In einem solchen Fall ist es also nicht kontrollierbar, welche der beiden Einrichtungen die IP-Nachrichten empfängt und inwieweit sie noch bearbeitet werden . Die Gefahr, dass Fehlfunktionen oder Funktionsverlust eintreten oder eventuell sogar inkonsistente Daten entstehen, ist sehr groß . Ein solches Szenario wird in der Fachliteratur auch als „split brain" Scenario bezeichnet und ist bei Hochverfügbarkeitsforderungen unbedingt zu vermeiden . Beim Stand der Technik ist zur Behandlung dieser Problematik eine separate Hard- wäre Einheit vorgesehen, die die einzelnen Plattformen einer Redundanz Einheit (i . a . eines Redundanz Paares ) auf IP-Ebene überwacht . Diese Hardware Einheit sorgt dafür, dass nur dann ein IP-Failover stattfindet, wenn die als ausgefallen erkannte Einrichtung oder Plattform auch keine ARP requests mehr sendet/ beantwortet . Problematisch an dieser Lösung ist, dass das entsprechende Verfahren aufwendig und vergleichsweise langsam ist (im ungünstigen Fällen im Minutenbereich) .
Der Erfindung liegt die Aufgabe zugrunde, einen Weg und eine Vorrichtung aufzuzeigen, mit deren Hilfe das Auftreten und die Auswirkungen von „split brain" Scenarien minimiert werden können .
Die Erfindung wird ausgehend von den in den Oberbegriffen der Patentansprüche 1 und 10 angegebenen Merkmale durch die kennzeichnenden Merkmale gelöst .
Der Vorteil an der Erfindung ist im Adresshandling auf Applikationsebene zu sehen . Die Beurteilung, ob eine Plattform funktionsfähig ist oder durch eine IP-Failover Funktion ersatzgeschaltet werden muss , wird auf Applikationsebene von der Funktion der Fail-over Control aufgrund einer Mehrzahl von Umgebungskriterien (Umgebungsparametern) bestimmt . Ein Umgebungskriterium oder Umgebungsparameter kann die Verfüg- barkeit/ NichtVerfügbarkeit der Kommunikation zur redundanten Einrichtung sein, die Möglichkeit der Kommunikation zu weiteren Einrichtungen, die die Ersatzschaltung steuern, die Zugreifbarkeit zentraler Ressourcen, die für die ordnungsgemäße Bearbeitung der Aufgaben der Einrichtung notwendig sind. Die Fail-over Control sorgt dafür, dass zu j eder Zeit die zwei redundanten Einrichtungen aus einer Mehrzahl von redundanten Einrichtungen zugeordneten Umgebungskriterien nicht zugleich auf aktiven Betrieb, d. h . Bereitstellung der IP fail-over Adressen eingestellt sein können . Erfindungsgemäß besitzt die Fail-over Control Funktionen in j eder der redundanten Einrichtungen mit IP fail-over Adressen und läuft auf Applikationsebene als Applikationsprozeß oder Teil davon, der bei j edem vom ARP Modul empfangenen ARP request befragt wird, ob eine ARP response zu schicken ist . Es erfolgt also grundsätzlich kein unbedingtes ARP response auf einer unter der Ap- plikationsebene befindlichen Ebene . Der ARP request wird erfindungsgemäss davon abhängig gemacht, ob insbesondere ein vorgegebener Nachrichtenaustausch (Handshake) zwischen ARP Modul und Failover Control auf Applikationsebene durchgeführt werden kann .
Durch das Handshake Verfahren wird auch im Falle von nicht mehr ausgeführten Applikationen einfach, sicher und zweifelsfrei erkannt, dass keine ARP requests beantwortet werden dürfen . Damit kann eine redundante Einrichtung gemäß Steuerung der Fail-over Control die IP fail-over Adressen auch in diesem Falle übernehmen, ohne dass die ausgefallene, bzgl . der Applikationsebene nicht mehr funktionierende Einrichtung die Adressumschaltung auf einem Level unterhalb des Applikationslevels durch ungewollte ARP responses stört . Es wird also eine Abhängigkeit eingeführt zwischen einer Fail over Control (FOC) in der Anwenderschicht und dem ARP Modul auf der niedrigeren Schicht des IP-Stack . Diese stellt sicher, dass bei beliebigen Ausfallszenarien der ARP Modul logisch synchron zum Zustand der Fail over Control arbeitet und er in der Lage ist, j eweils die richtige Information (Nachrichten zur IP-Failover Adresse an diese Plattform schicken/ nicht schicken) ins Netz kommuniziert . Eine externe Überwachung der Plattform, die über die Fail over Control auf Applikationsebene hinausgeht, wie dies beim Stand der Technik der Fall ist, ist damit nicht erforderlich . Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben .
So ist weiterhin vorgesehen, die Zeitfenster für unzulässigen Cache Inhalt durch freilaufende Adressauflösungsnachrichten, die zusätzlich nach ARP Request oder als Folge empfangener inkonsistenter Adressauflösungen (ARP Request /Response, Gratuitous ARP) aus der Applikationsebene ausgebracht werden, zu verkürzen .
Darüber hinaus können HW-Mechanismen zum Rücksetzen der Einrichtung in der Weise genutzt werden, dass als erste Aktion des automatischen Wiederanlaufs die paketbasierten Schnittstellen deaktiviert werden, um das Zeitfenster für mögliche Adresskonflikte nach SW-Problemen weiter zu reduzieren .
Schließlich ist ein weiterer Vorteil der Erfindung darin zu sehen, dass ein Lauschen am Netz zum Zweck der Bediener- alarmierung durchgeführt wird im Falle dauerhafter Inkon- sistenz zwischen dem durch die Fail-over Control vorgegebenen Zustand einer der redundanten Einrichtungen und den im Netz ausgetauschten Adressauflösungen .
Durch Kombination aller voranstehend aufgezeigten Mechanismen wird die höchste funktionale Verfügbarkeit erreicht .
Die Erfindung wird im Folgenden anhand eines figürlich dargestellten Ausführungsbeispiels näher erläutert . Demgemäß wird die Erfindung anhand zweier Plattformen (m = 2 ) beschrieben, die an ein LAN angeschlossen sind.
Dabei sind unter Umgebungsparametern Zustandsgrößen des eigenen Systems oder fremder Systeme, Kommunikations- -und Protokollbeziehungen, Zugriffe auf abgesetzte Einheiten wie Daten- basen zu verstehen . Bei vorliegendem Ausführungsbeispiel soll m = 2 gelten, was aber keinerlei Einschränkung des Verfahrens hinsichtlich einer beliebigen Anzahl von Einrichtungen sein soll . Die Einrichtungen sind als (Rechner) Plattformen ausgebildet . Ferner kann im Netz ein Network Management NM vorgesehen sein .
Im fehlerfreien Betrieb sind alle m = 2 Plattformen aktiviert und alle Prozesse verfügbar . Jede der Plattformen PIf1 , PIf2 hat mindestens eine paketbasierte Schnittstelle und ist in der Lage, eine Mehrzahl von Failover Adressen mit einer definierten Funktionalität zu bedienen . Die beiden Platt- formen bilden folglich eine Menge redundanter Einrichtungen im Hinblick auf die genannten Failover Adressen und die für sie zu erbringende Funktionalität .
Ein Umgebungsparameter wird zu j eder Zeit für genau eine der beiden Plattformen gesetzt ist und für die restliche Plattform (en) nicht gesetzt . Gemäß vorliegendem Ausführungsbeispiel soll der Umgebungsparameter die Betriebszustände act/ standby sein . Ist der Umgebungsparameter für eine der beiden Plattformen gesetzt, so soll diese die Kommunikation über die Failover Adressen und die gewünschte Verarbeitungsfunktion bereitstellen . Ist das Umgebungskriterium für eine Plattform nicht gesetzt, soll diese die Failover Adressen nicht bereitstellen . Durch externe Steuerung werden die Umgebungsparameter in der beschriebenen Art zur Verfügung gestellt . Aus Gründen der Einfachheit wird im folgenden eine Plattform mit gesetztem Umgebungsparameter als aktiv (act) bzgl . der Fail over Adressen, eine ohne gesetzten Umgebungsparameter als standby (stb) bzgl . der Failover Adressen bezeichnet . Es ist hierbei insbesondere ausgeschlossen, dass ein Umgebungsparameter dauerhaft für mehr als eine Plattform auf aktiv gesetzt ist . Gemäß der Figur gibt es auf j eder der beiden Plattformen PIf1 , PIf2 einen Applikationsprozess „Fail over Control" FOC, der eine Schnittstelle zu einem Modul ARP der Plattform aufweist und die Information besitzt, ob sich die Einrichtung bezüglich der Failover Adressen im Zustand „act" oder „stb" befindet . Der Zustand "act" bedeutet dabei, dass die Plattform die Fail over Adressen bedient . Ein vorgelagerter Router muss Nachrichten mit diesen logischen Paketadressen zu dieser Plattform senden . Daher beantwortet der ARP Modul dieser Einrichtung die zugehörigen Adressauflösungsanforderungen (ARP requests ) . Der Zustand "Stb" bedeutet hingegen, dass die Plattform die Failover Adresse nicht bedient . Ein vorgelagerter Router darf Nachrichten mit diesen logischen Paket- adressen nicht zu dieser Einrichtung senden . Der ARP Modul dieser Einrichtung beantwortet die zugehörigen ARP requests daher nicht .
Der ARP Modul teilt der Fail Over Control FOC mit, dass ein ARP request empfangen wurde . Ein ARP request wird nur quittiert, falls die Fail Over Control FOC einer Einrichtung dies explizit erlaubt . Damit werden ARP Requests de facto nicht über eine low level Funktion des IOP Stacks oder des Betriebssystems autark beantwortet, sondern aus der Applika- tionsebene heraus . Ein Ausfall oder Hängenbleiben der Applikationsebene der Plattform führt folglich dazu, dass die Fail Over Control FOC dieser Einrichtung auch nicht mehr verfügbar ist, womit nachfolgend eintreffende ARP requests nicht mehr beantwortet werden . ARP requests werden dann nicht beant- wortet, wenn entweder die Fail over Control FOC dies für richtig hält oder wenn die Kommunikation des ARP Moduls mit der Fail over Control gestört ist . Die Fail over Control FOC beantwortet ARP Requests insbesondere dann nicht, wenn die Einrichtung im Zustand stb ist . Ein Hängenbleiben auf Appli- kationsebene führt zur Abschaltung des ARP Handlings der betroffenen Einrichtung .
Durch diese innerhalb der Plattform erfolgte Verlagerung des Quittierens von ARP Requests auf die Applikationsebene, d. h . aus einem Anwenderprozess der Plattform heraus , wird vermieden, dass die ARP-Funktion noch aktiv ist, obwohl der Applikationslevel nicht mehr funktionstüchtig ist . (Letzteres könnte zum Ersatzschalten der Einrichtung dienen, also der Veränderung des Umgebungsparameters der ungestörten redundanten Einrichtung auf aktiv) . Sollte es dennoch zum Split Brain Effekt kommen, so wird die Auswirkung optional durch folgende Maßnahme eingeschränkt :
Erhält eine bezüglich der Failover Adresse aktive Plattform einen ARP Request, so beantwortet sie diesen, geht aber davon aus , dass weitere Plattformen unberechtigterweise ebenfalls die IP- Failover Adresse beanspruchen könnten . Also sendet sie vorsorglich nach gewissem zeitlichem Abstand der Quittung auf den ARP Request mindestens ein Gratuitous ARP zur Auflösung der Absenderadresse sicherheitshalber hinterher . Dies erfolgt auf Initiative der Fail over Control aus der Appli- kationsebene der Einrichtung heraus . Damit kann ein fälschlich bestehender ARP Cache Inhalt eines Kommunikationspartners am Netz oder eines vorgelagerten Routers schnell korrigiert werden, so dass die Zeitfenster, in denen wegen des Split brain Effektes unrichtige Cache Inhalte vorhanden sein können, extrem verkürzt werden .
Bleiben ARP Requests aus , so wird gratuitious ARP vorsorglich zyklisch in gewissem Mindestabstand generiert . Dies erfolgt ebenfalls auf Initiative der Fail over Control aus der Applkationsebene der Einrichtung heraus . Auch für diesen Fall ist eine Schnittstelle zwischen Fail Over Control FOC auf Applikationslevel und dem ARP Modul erforderlich . Jeder ARP Request wird notifiziert und führt zusätzlich oder alternativ zum aus dem Applikationslevel angereiztem eventuell mehrfach ausgebrachten Gratuitous ARP .
Eine derartige Vorgehensweise ist immer dann vorteilhaft, wenn die Umgebungsparameter durch unterschiedliche Laufzeiten in den beteiligten Plattformen kurzzeitig inkonsistent sein können . Ist also z . B . im Rahmen einer routinemäßigen oder manuellen Umschaltung die aktivierte Plattform bereits aktiv, wohingegen die zu deaktivierende Plattform noch nicht deakti- viert wurde, und kommt es in diesem Zeitfenster zu einem ARP Request eines vorgeschalteten Routers , so antworten beide . Bei symmetrischer Implementierung werden beide dann auch ein zeitverzögertes Gratuitous ARP nachsetzen wollen . Durch den Zeitversatz wird die Änderung des Umgebungskriteriums die abzuschaltende Plattform mit hoher Wahrscheinlichkeit vor dem Ausbringen des zusätzlichen Gratuitous ARPs erreichen, so dass dies seitens der abzuschaltenden Plattform unterbleibt, und die u . U . inkorrekte Adressauflösung von der aktivierten Plattform korrigiert wird.
Optional kann zusätzlich zu dieser Vorgehensweise eine HW- Überwachung der Plattform auf der Applikationsebene erfolgen . Dies hat zur Folge, dass ein Hängenbleiben der Plattform oder der Fail-over Control dieser Plattform wegen SW-Defekt oder Überlastung schnell erkannt werden kann und zu dem durch HW- Mechanismen bewirkten Wiederanlauf der Plattform oder von Teilen der Plattform führt, im Rahmen dessen ggf . auch die paketbasierten Schnittstellen als erste Aktion deaktiviert bzw . zurückgesetzt werden . Mit dem Anlauf einer ehemals für eine Paketadresse aktiven Plattform werden sich die Umgebungsparameter derart verändern, dass eine der weiteren vorgesehenen Plattformen deren Funktionen übernimmt und so lückenlose Verfügbarkeit der von der Plattform gebotenen Funktionalität gewährleistet . Die HW-Überwachung setzt das Vorhandensein entsprechender HW-Funktionen voraus .
In einer weiteren Ausgestaltung der Erfindung ist vorgesehen, dass eine Plattform ihre IP-Failover Adressen deaktiviert, falls sie den dauerhaften Verlust der Zugreifbarkeit der Umgebungsparameter feststellt . Sie geht in diesem Falle davon aus , dass hiermit die Umgebungsparameter einer weiteren Plattformen derart eingestellt werden, dass diese fortan die genannten IP fail-over Adressen bedienen wird und damit keine eigene Interaktion bzgl . dieser Failover Adressen zu ungewollten Störungen und Fehlfunktionen führen würde . Die Ressourcenverfügbarkeit (z . B . interne Ressourcen für Verar- beitung oder die ungestörte Kommunikation mit weiteren externen Verarbeitungsinstanzen) gehen in den Umgebungsparameter mit ein .
Befinden sich Plattformen zur alternativen Bedienung einer Failover Adresse am gleichen Netz , so kann j ede Plattform durch Lauschen am Netz die Quittungen auf ARP-Requests und die Gratuitous ARPs weiterer Plattformen vom ARP Modul in die Fail over Control FOC übertragen bekommen . Die Fail over Control instruiert hierzu den ARP Modul, alle ARP Responses , die j a nicht als Broadcast Nachrichten gesendet werden, und alle ARP Requests und gratuitous ARPs die im Broadcast Mode verschickt werden und zur Adressauflösung herangezogen werden der Fail Over Control dann zuzustellen, wenn die von der Fail Over Control bedienten IP-Failover Adressen hierbei eine andere als die Auflösung auf die eigene MAC-Adresse erfahren .
Hiermit kann die Fail over Control optional die Konsistenz der Inhalte mit dem eigenen Umgebungsparameter überprüfen . Dies bedeutet, dass auf diesem Wege festgestellt werden kann, welche weitere Plattform sich zu einer Zeit für die Failover Adresse zuständig fühlt . Die bezüglich der Adresse aktive Plattform kann die physikalische Adresse einer unberechtigt zugreifenden weiteren Plattform damit zum Alarmierungszwecke ausgeben und Gratuitous ARPs zur Korrektur ausbringen . Eine bezüglich der Adresse inaktive Plattform oder eine beliebige weitere Plattform am Netz kann damit die an einer split brain Situation beteiligten Plattformen erkennen und den Bediener alarmieren . Eine bezüglich der Adresse inaktive Plattform kann den eigenen Umgebungsparameter gegen die Adressauflösung im Netz auf Konsistenz prüfen und ebenfalls den Bediener alarmieren . Durch die Alarmierung und den als letztes Mittel anzusehenden Bedienereingriff wird die Zeitdauer eines möglichen Adresskonflikts weiter verkürzt und die Verfügbarkeit der zur Verfügung gestellten Funktion weiter erhöht .

Claims

Patentansprüche
1. Verfahren zur Zuordnung von logischen Adressen zu physikalischen Adressen einer Mehrzahl von Einrichtungen, die mit- einander in Wirkverbindung stehen und die j eweils einen auf Protokollebene arbeitenden Modul (ARP) aufweisen, mit dessen Hilfe eine Zuordnung der logischen zu den physikalischen Adressen von Kommunikationspartnern vorgenommen wird, indem vom Modul eine Anfragenachricht (ARP Request) eines Kommuni- kationspartners empfangen und von einer der Einrichtungen mit ihrer physikalischen Adresse quittiert (ARP Response) wird, dadurch gekennzeichnet, dass eine Kommunikationsbeziehung zwischen einer auf Applikationsebene arbeitenden Umschaltesteuerfunktion (FOC) und dem auf Protokollebene arbeitenden Modul (ARP) bereitgestellt wird, über die eine Verlagerung des Quittierens einer Anfragenachricht (ARP request) mit der physikalischen Adresse auf Applikationsebene vorgenommen wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass nach einem vorgegebenen zeitlichen Abstand, nachdem die korrekte physikalische Adresse (ARP Response) über die Applikationsebene quittiert wurde, erneut mindestens eine auf Applikationsebene durch die Umschaltesteuerfunktion (FOC) initiierte Nachricht zur Zuordnung der physikalischen Adresse zu den logischen Adressen (Gratuitous ARP) freilaufend über den Modul (ARP) an alle Kommunikationspartner gesendet wird.
3. Verfahren nach Anspruch 1 oder 2 , dadurch gekennzeichnet, dass wahlweise zusätzlich eine HW-Überwachung der Verfügbarkeit der Applikationsebene der Einrichtungen oder der Verfügbarkeit der Umschaltesteuerfunktion der Einrichtungen vorge- sehen ist, deren Ansprechen zu Maßnahmen des Wiederanlaufs der nichtverfügbaren Teile der Einrichtung führt .
4. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, dass die Umschaltesteuerfunktion (FOC) einer Einrichtung zur Entscheidung, ob eine Anfragenachricht (ARP request) beant- wortet wird, einen oder eine Mehrzahl von Umgebungsparameter heranzieht .
5. Verfahren nach Anspruch 1 bis 4 , dadurch gekennzeichnet, dass die logischen Adressen wenigstens einer der Einrichtungen deaktiviert werden, falls ein dauerhafter Verlust der Zugreifbarkeit der Umgebungsparameter festgestellt wird.
6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine der Einrichtungen zur alternativen Bedienung einer logischen Adresse durch Lauschen am Netz die Nachrichten zur Zuordnung von logischen und physikalischen Adressen (ARP response, gratuitous ARP) der weiteren Einrichtungen in die Umschaltesteuervorrichtung (FOC) übertragen bekommen .
7. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die empfangenen AdressZuordnungen gegen die Umgebungs- parameter plausibilisiert werden und eine Alarmierung des Bedieners über eine Network Management Funktion unter Ausgabe von Fehlerindizien erfolgt .
8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die logische Adresse als IP-Failover Adresse ausgebildet ist .
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die physikalische Adresse als MAC-Adresse ausgebildet ist .
10. Vorrichtung zum Umschalten zwischen wenigstens zwei redundanten Einrichtungen, dadurch gekennzeichnet, dass eine Kommunikationsbeziehung zwischen einer auf Applikationsebene arbeitenden Umschaltesteuervorrichtung (FOC) und dem auf Protokollebene arbeitenden Modul (ARP) bereitgestellt ist, über die die Verfügbarkeit von logischen Adressen unter einer physikalischen Adresse einer Einrichtung davon abhängig gemacht wird, ob ein Nachrichtenaustausch (Handshake) zwischen der auf Applikationsebene arbeitenden Umschaltesteuervorrichtung (FOC) und dem auf Protokollebene arbeitenden Modul (ARP) durchgeführt werden kann .
PCT/EP2006/050028 2005-01-28 2006-01-04 Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen Ceased WO2006079574A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US11/883,277 US7730168B2 (en) 2005-01-28 2006-01-04 Method and apparatus for assigning packet addresses to a plurality of devices
ES06700314T ES2391901T3 (es) 2005-01-28 2006-01-04 Procedimiento y disposiitvo para asignar direcciones de paquetes a un conjunto de equipos
EP06700314A EP1844598B1 (de) 2005-01-28 2006-01-04 Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen
DK06700314.5T DK1844598T3 (da) 2005-01-28 2006-01-04 Fremgangsmåde og indretning til tildeling af pakkeadresser til en flerhed af indretninger
CN2006800035038A CN101112070B (zh) 2005-01-28 2006-01-04 用于将分组地址分配给多个设备的方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005004151A DE102005004151A1 (de) 2005-01-28 2005-01-28 Verfahren und Vorrichtung zur Zuordnung von Paketadressen einer Mehrzahl von Einrichtung
DE102005004151.5 2005-01-28

Publications (1)

Publication Number Publication Date
WO2006079574A1 true WO2006079574A1 (de) 2006-08-03

Family

ID=35967018

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/050028 Ceased WO2006079574A1 (de) 2005-01-28 2006-01-04 Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen

Country Status (7)

Country Link
US (1) US7730168B2 (de)
EP (1) EP1844598B1 (de)
CN (1) CN101112070B (de)
DE (1) DE102005004151A1 (de)
DK (1) DK1844598T3 (de)
ES (1) ES2391901T3 (de)
WO (1) WO2006079574A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5699658B2 (ja) * 2011-02-10 2015-04-15 日本電気株式会社 待機系計算機、クラスタシステム、サービス提供方法およびプログラム
CN102742214A (zh) * 2011-07-13 2012-10-17 青岛海信传媒网络技术有限公司 改善高可用性系统可靠性的方法和装置
US8903991B1 (en) * 2011-12-22 2014-12-02 Emc Corporation Clustered computer system using ARP protocol to identify connectivity issues
CN104137086A (zh) * 2012-02-20 2014-11-05 三菱电机株式会社 信息系统管理装置、信息系统管理方法以及程序
CN104158707B (zh) * 2014-08-29 2017-10-17 新华三技术有限公司 一种检测并处理集群脑裂的方法和装置
EP3979573A4 (de) * 2019-07-05 2022-06-08 Mitsubishi Electric Corporation Relaisvorrichtung und netzwerksystem

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5836910A (en) * 1995-03-13 1998-11-17 Alaris Medical Systems, Inc. Method and apparatus for logical addressing in a modular patient care system
US5983278A (en) * 1996-04-19 1999-11-09 Lucent Technologies Inc. Low-loss, fair bandwidth allocation flow control in a packet switch
US6219697B1 (en) * 1997-05-02 2001-04-17 3Com Corporation Method and apparatus for operating the internet protocol over a high-speed serial bus
US6944785B2 (en) * 2001-07-23 2005-09-13 Network Appliance, Inc. High-availability cluster virtual server system
US20030048501A1 (en) * 2001-09-12 2003-03-13 Michael Guess Metropolitan area local access service system
US20050086342A1 (en) * 2003-09-19 2005-04-21 Andrew Burt Techniques for client-transparent TCP migration
KR100633666B1 (ko) * 2004-02-25 2006-10-12 엘지전자 주식회사 홈 네트워크 시스템 및 그 제어 방법

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BRUSCHI D ET AL.: "S-ARP: a secure address resolution protocol", COMPUTER SECURITY APPLICATIONS CONFERENCE, 2003. PROCEEDINGS. 19TH ANN UAL 8-12 DEC. 2003, PISCATAWAY; NJ; USA, 8 December 2003 (2003-12-08), pages 66 - 74
FAN C C ET AL: "The raincore distributed session service for networking elements", PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM., PROCEEDINGS 15TH INTERNATIONAL SAN FRANCISCO, CA, USA 23-27 APRIL 2001, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 23 April 2001 (2001-04-23), pages 1673 - 1681, XP010544581, ISBN: 0-7695-0990-8 *
STEVENS W R ED - STEVENS ET AL: "TCP/IP Illustrated, ARP: ADDRESS RESOLUTION PROTOCOL", TCP/IP ILLUSTRATED. VOL. 1 : THE PROTOCOLS, PROFESSIONAL COMPUTING SERIES, READING, MA : ADDISON WESLEY, US, vol. VOL. 1, 1994, pages 53 - 68, XP002247360, ISBN: 0-201-63346-9 *
WENSONG ZHANG: "Linux Virtual Server for Scalable Network Services", PAPER, 2000, Ottawa Linux Symposium 2000, pages 1 - 10, XP002372188, Retrieved from the Internet <URL:http://www.linuxvirtualserver.org/ols/lvs.pdf> [retrieved on 20060315] *

Also Published As

Publication number Publication date
US7730168B2 (en) 2010-06-01
DE102005004151A1 (de) 2006-08-10
CN101112070B (zh) 2011-03-30
EP1844598B1 (de) 2012-08-08
CN101112070A (zh) 2008-01-23
EP1844598A1 (de) 2007-10-17
DK1844598T3 (da) 2012-11-12
ES2391901T3 (es) 2012-11-30
US20080313314A1 (en) 2008-12-18

Similar Documents

Publication Publication Date Title
DE60106467T2 (de) Verfahren zum Installieren Überwachungsagenten, System und Computerprogramm von Objekten in einem IT-Netz Überwachung
DE602004010111T2 (de) Backup-zellensteuerung
DE112019007432B4 (de) Elektronische steuereinheit und programm
DE102021107655A1 (de) Protokollverwaltung für ein mehrknotendatenverarbeitungssystem
EP2491492B1 (de) Automatisierungssystem und verfahren zum betrieb eines automatisierungssystems
EP1358554B1 (de) Automatische inbetriebnahme eines clustersystems nach einem heilbaren fehler
EP3113461B1 (de) Verfahren zum aufbau von kommunikationsverbindungen zu redundant betriebenen steuerungsgeräten eines industriellen automatisierungssystems und steuerungsgerät
EP3142296B1 (de) Verfahren zur konfiguration eines modularen steuerungsgeräts eines industriellen automatisierungssystems und modulares steuerungsgerät
EP3787237A1 (de) Verfahren zur datenübermittlung in einem redundant betreibbaren kommunikationsnetz und koppel-kommunikationsgerät
DE112012006382B4 (de) Kommunikationsvorrichtung und Kommunikationssystem
EP1844598B1 (de) Verfahren und vorrichtung zur zuordnung von paketadressen einer mehrzahl von einrichtungen
DE102004050350B4 (de) Verfahren und Vorrichtung zur Redundanzkontrolle von elektrischen Einrichtungen
DE60309012T2 (de) Verfahren und system zur sicherstellung eines busses und eines steuerservers
DE10305415B4 (de) Verfahren und Vorrichtung zum medienredundanten Betreiben eines Endgeräts in einem Netzwerk
EP1692816B1 (de) Verfahren zum ersatzschalten von räumlich getrennten vermittlungssystemen
EP1619849B1 (de) Verfahren zum Synchronisieren eines verteilten Systems
EP3054654B1 (de) Netzwerksystem und verfahren zur namensauflösung in einem netzwerksystem
EP3035600A1 (de) Verfahren zur Diagnose der Erreichbarkeit von Netzwerkteilnehmern, Netzwerkteilnehmer und IP-basiertes Netzwerk
EP1851934B1 (de) Verfahren zur fehlererkennung eines nachrichteninterfaces in einer kommunikationseinrichtung
WO2005003982A1 (de) Zuordnung von stationsadressen zu kommunikationsteilnehmern in einem bussystem
DE102007053916A1 (de) Verfahren zum Verwalten von Netzkomponenten in einem Netzwerk und Netzkomponente
EP1692880B1 (de) Verfahren zum ersatzschalten von r umlich getrennten vermitt lungssystemen
DE102009036178A1 (de) Verfahren und Antwort-Mittel zum verkürzten Beantworten einer Anfrage bei Nicht-Verfügbarkeit einer angefragten Server-Vorrichtung
DE102024136952A1 (de) Failover der netzwerkadresszuweisung
EP3910882A1 (de) Ausfallsicherer betrieb eines netzwerks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006700314

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11883277

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2007552613

Country of ref document: JP

Ref document number: 200680003503.8

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2006700314

Country of ref document: EP