DE69915871T2

DE69915871T2 - Verfahren und vorrichtung für ein tcp/ip lastausgleich und wiederherstellung eines prozesses in einem internet protocol (ip) netzwerkgruppensystem.

Info

Publication number: DE69915871T2
Application number: DE69915871T
Authority: DE
Inventors: Allen Kenneth ADELMAN; Lyon David KASHTAN; L. William PALTER; D. Derrell PIPER
Original assignee: Network Alchemy Inc
Current assignee: Chek Point Software Technologies Inc Redwood Us
Priority date: 1998-11-20
Filing date: 1999-10-15
Publication date: 2005-02-03
Anticipated expiration: 2019-10-16
Also published as: JP2003518338A; EP1135726A2; AU1211500A; WO2000031942A3; EP1135726B1; US6078957A; CA2351413A1; DE69915871D1; CA2351413C; WO2000031942A2

Description

TECHNISCHES GEBIET
Die Erfindung bezieht sich auf das Gebiet von Computersystemen in dem allgemeinen Netzkommunikationssektor. Genauer besteht die Erfindung in einem Verfahren und einer Vorrichtung für ein TCP/IP-Lastausgleichs- & Ausfallsicherungssystem in einem Internet-Protokoll-Netzclustersystem (IP-Netzclustersystem).
STAND DER TECHNIK
Da mehr und mehr Unternehmen Anwendungen des elektronischen Handels unter Verwendung des Internet entwickeln, um ihre Produkte zu vertreiben und deren Bestellung und Auslieferung zu verwalten, suchen diese Unternehmen nach kostengünstigen Internet-Verbindungen, die sowohl Sicherheit als auch hohe Verfügbarkeit bereitstellen. Derartige missionsentscheidende Anwendungen müssen jeden Tag den ganzen Tag laufen, wobei die Netzkomponenten sehr zuverlässig und leicht skalierbar sein müssen, da der Nachrichtenverkehr zunimmt. Nationale Netzbetreiber und lokale Internet-Dienst-Anbieter (ISP) bieten nun virtuelle private Netze (VPN) – erweiterte Internet-basierte Hauptnetze (Backbones), die Gesellschaftsarbeitsgruppen an weit ausgedehnten lokalen Netzen (LRN) miteinander verbinden – als die Lösung für diese Anforderungen an. Ähnlich bieten andere Firmen angehäufte bzw. geclusterte Systeme als eine Einrichtung zum Bereitstellen einer Netzskalierbarkeit und eines adaptiven Lastausgleichs in Netzsystemen an. TCP/IP-basierte Systeme werfen jedoch Probleme des Nachrichtenverkehrsverlusts und des Netzsitzungsneubeginns auf, falls keine effizienten Ausfallsicherungsprozesse realisiert sind.
Eine Anzahl von Firmen hat in jüngster Zeit derzeitige oder vorgeschlagene VPN-Produkte und/oder Systeme angekündigt, die verschiedentlich IPSec, IKE (ISAKMP/Oakley) Verschlüsselungsschlüsselverwaltung sowie Entwurfsprotokolle für Punkt-zu-Punkt-Tunnelprotokoll (PPTP, Point-to-Point Tunneling protocol) und Schicht-2-Tunnelprotokoll (L2TP, Layer 2 Tunneling protocol) unterstützen, um einen sicheren Verkehr für Benutzer bereitzustellen. Einige dieser Produkte umfassen Nways Multiprotocol Routing Services^TM 2.2 von IBM, die Produkte Optivity^TM und Centillion^TM von Bay Networks, das Paket MultiVPN^TM von Ascend Communication, die Produktfamilie ADI VPN von Digital Equipment und die VPN-geplanten Produkte RiverWorks^TM von Indus River. Es ist jedoch von keinem dieser Produkte bekannt, daß es Fähigkeiten anbietet, die die Verzögerung und die Sitzung durch einen gesteuerten Ausfallsicherungsprozeß minimieren.
Diese VPN stellen enorme Anforderungen an die Unternehmensnetzinfrastruktur. Einzelne Punkte von Ausfallkomponenten wie beispielsweise Zugängen bzw. Gateways, Zugangsschutzsystemen bzw. Firewalls, Tunnel-Servern und andere Drosselpunkte, die sehr zuverlässig und skalierbar ausgebildet werden müssen, werden mit redundanter Ausrüstung wie beispielsweise "sofort einsetzbarem Ersatz" bzw. "Hot-Standbys" und verschiedenen Typen von Clustersystemen behandelt.
Beispielsweise bietet CISCO^TM Inc. nun ein als LocalDirector^TM bezeichnetes neues Produkt an, das als eine Datenstation bzw. ein Front-End für eine Gruppe von Servern arbeitet, einen dynamischen Lastausgleich des TCP-Verkehrs zwischen Servern ausführt, um einen rechtzeitigen Zugriff und eine Antwort auf Anfragen sicherzustellen. Der LocalDirector stellt für Endbenutzer das Erscheinungsbild eines "virtuellen" Servers bereit. Zu Zwecken des Bereitstellens eines kontinuierlichen Zugriffs, falls der LocalDirector ausfällt, müssen Benutzer ein redundantes LocalDirector-System kaufen, das direkt mit der Primäreinheit verbunden ist, wobei die redundante Einheit als ein "Hot"-Standby fungiert. Die Standby-Einheit führt selbst keine Verarbeitungsarbeit durch, bis die Master-Einheit ausfällt. Die Standby-Einheit verwendet die Ausfallsicherungs-IP-Adresse und die Sekundärmedienzugriffssteuerungsadresse (Sekundär-MAC-Adresse) (die die gleichen wie bei der Primäreinheit sind), womit kein Adressenauflösungsprotokoll (ARP) zum Umschalten zu der Standby-Einheit erforderlich ist. Da die Standby-Einheit jedoch keine Zustandsinformationen über jede Verbindung hält, werden alle aktiven Verbindungen fallengelassen und müssen durch die Clients neu hergestellt werden. Da der "Hot-Standby" keine gleichzeitige Verarbeitung durchführt, bietet er außerdem weder eine Verarbeitungslastentlastung noch eine Skalierungsfähigkeit.
Valence^TM Research Inc. (in jüngster Zeit durch Microsoft^® Corporation gekauft) bietet ein als Convoy Cluster^TM (Convoy) bezeichnetes Softwareprodukt an. Convoy installiert sich als ein Standard-Windows-NT-Netztreiber und läuft auf einem vorhandenen LAN. Es arbeitet in einer sowohl für Server-Anwendungen als auch TCP/IP-Clients transparenten Art und Weise. Diese Clients können unter Verwendung einer IP-Adresse auf den Cluster zugreifen, als ob er ein einzelner Computer wäre. Convoy gleicht automatisch den Netzverkehr zwischen den geclusterten Computern aus und kann die Last wieder ausgleichen, wann immer ein Clustermitglied online kommt oder offline geht. Dieses System scheint jedoch zum Bestimmen, welcher Nachrichtentyp durch welches Clustermitglied zu verarbeiten ist, ein rechenintensives und speicherverschwendendes Verfahren dahingehend zu verwenden, daß die Nachrichtenquellenportadressen- und -zielportadressenkombination als ein Indexschlüssel verwendet wird, der gespeichert und mit der ähnlichen Kombination jeder eingehenden Nachricht verglichen werden muß, um es zu bestimmen, welches Mitglied die Nachricht zu verarbeiten hat. Außerdem führt dieses System keine Ausfallsicherung durch.
In dem Fachgebiet besteht ein Bedarf an einem IP-Netzclustersystem, das leicht skaliert werden kann, um die sprunghaft ansteigenden Bandbreitenanforderungen von Benutzern zu handhaben. Es besteht ein weiterer Bedarf, Netzverfügbarkeit, -zuverlässigkeit und -leistungsfähigkeit hinsichtlich Durchsatz, Verzögerung und Paketverlust zu maximieren, indem der Clustergemeinaufwand bzw. Cluster-Overhead so effizient wie möglich ausgebildet wird, da mehr und mehr Menschen in das Internet gelangen und länger in ihm bleiben. Es ist noch ein weiterer Bedarf vorhanden, ein zuverlässiges Ausfallsicherungssystem für TCP-basierte Systeme bereitzustellen, indem die Zustandsinformationen über alle Verbindungen gesichert werden, um den Paketverlust und den Bedarf an Neuverbindungen zu minimieren.
Computerclustersysteme einschließlich "Einzelsystembild"-Clustern bzw. "Single-System-Image"-Clustern sind in dem Fachgebiet bekannt. Siehe z. B. "Scalable Parallel Computing" von Kai Hwang & Zhiwei Xu, McGraw-Hill, 1998, ISBN 0-07-031798-4, Kapitel 9 & 10, Seiten 453–564, das in Verbindung mit diesem Dokument gelesen werden sollte. Verschiedene kommerzielle Clustersystemprodukte sind darin beschrieben, einschließlich des TruClustersT'''-Systems von DEC, des SP^TM-Systems von IBM, des Wolfpack^TM-Systems von Microsoft und des The Berkeley NOW Project. Es ist von keinem dieser Systeme bekannt, daß es eine effiziente IP-Netzclusterfähigkeit zusammen mit kombinierter Skalierbarkeit, Lastausgleich und gesteuerter TCP-Ausfallsicherung bereitstellt.
Die WO 98/26553 offenbart ein System und Verfahren für Viele-zu-viele-Ausfallsicherung und Lastausgleich in einem Netz von Computersystemen. Es wird eine Vielzahl von Dienstgruppen aufgebaut, wobei jede Dienstgruppe eine Vielzahl von Hosts umfaßt und jeder Host in der Dienstgruppe zum Ausführen der Computerdienste verfügbar ist, für die die Gruppe als Ganzes verantwortlich ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung überwindet die Nachteile der vorstehend beschriebenen Systeme durch ein Bereitstellen eines wirtschaftlichen, leistungsstarken, anpassungsfähigen Systems und Verfahrens zur Netzverkehrsüberwachung und gesteuerten Ausfallsicherung (controlled failover) in einem IP-Netzcluster.
Die vorliegende Erfindung besteht in einem Verfahren und einer Vorrichtung zur Überwachung einer Paketverlustaktivität in einem Internet-Protokoll-Netzclustersystem (IP-Netzclustersystem), die einen nützlichen, getrennten und konkreten Mechanismus zur gesteuerten Ausfallsicherung des TCP/IP-Netzclustersystems bereitstellen können. Ein adaptiver Intervallwert wird als eine Funktion des durchschnittlichen Paketverlusts in dem System bestimmt, und dieser adaptive Intervallwert wird zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht zu allen anderen Clustermitgliedern senden muß, verwendet, wobei die Am-Leben-Nachricht zum Bestimmen eines Netzpaketverlusts verwendet wird.
Die vorliegende Erfindung umfaßt eine Clustervorrichtung mit einer Vielzahl von Clustermitgliedern, wobei alle Clustermitglieder den gleichen Internet-Maschinennamen und die gleiche IP-Adresse aufweisen und jedes Mitglied eine Universalverarbeitungseinrichtung, eine Speichereinheit, ein Programm in der Speichereinheit, eine Anzeige und eine Eingabe-/Ausgabeeinheit aufweist; und die Vorrichtung einen ersten Mechanismus, der einen adaptiven Intervallwert bestimmt, der ein Zeitintervall als eine Funktion eines durchschnittlichen Paketverlusts in dem System darstellt, und einen zweiten Mechanismus zum Verwenden des adaptiven Intervallwerts zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht senden soll, wobei die Am-Leben-Nachricht zum Bestimmen eines Netzpaketverlusts verwendet wird, aufweist.
Die vorliegende Erfindung umfaßt ferner ein Verfahren zur Überwachung einer Netzaktivität und zur gesteuerten Ausfallsicherung in einem TCP/IP-Netzcluster, wobei der Cluster eine Vielzahl von Clustermitgliedern aufweist, wobei jedes Clustermitglied eine Verarbeitungseinrichtung, einen Speicher, einen Eingabe-/Ausgabeabschnitt, einen Bildschirm und Programme in dem Speicher zum Betreiben des Clustermitglieds aufweist, wobei das Verfahren Schritte des Bestimmens eines adaptiven Intervallwerts, der ein Zeitintervall als eine Funktion eines durchschnittlichen Paketverlusts in dem Cluster darstellt, und des Verwendens des adaptiven Intervallwerts zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht senden soll, wobei die Am-Leben-Nachricht zum Bestimmen einer Netzpaketverlustschätzung verwendet wird, umfaßt.
Einige oder alle dieser Aufgaben können grundsätzlich zumindest teilweise in einer vorteilhaften Art und Weise gelöst werden, indem die in den unabhängigen Patentansprüchen 1 und 11 niedergelegten Merkmale angewendet werden. Weitere Verbesserungen werden durch die abhängigen Patentansprüche bereitgestellt.
Andere Ausführungsbeispiele der vorliegenden Erfindung sind für den Fachmann aus der folgenden ausführlichen Beschreibung, in der nur die Ausführungsbeispiele der Erfindung auf dem Wege der Veranschaulichung der zu dieser Zeit besten bekannten Betriebsart zum Ausführen der Erfindung gezeigt und beschrieben sind, leicht ersichtlich. Die Erfindung ist zu anderen und verschiedenen Ausführungsbeispielen in der Lage, von denen einige zu Veranschaulichungszwecken beschrieben sein können, und mehrere der Einzelheiten können in verschiedenen offensichtlichen Beziehungen modifiziert werden, alles ohne von dem Bereich der vorliegenden Erfindung abzuweichen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Merkmale und Vorteile des Systems und Verfahrens der vorliegenden Erfindung sind aus der folgenden Beschreibung ersichtlich, wobei:
1 eine typische Internet-Netzkonfiguration veranschaulicht.
2 eine repräsentative Universalcomputer/Clustermitglied-Konfiguration veranschaulicht.
3 eine repräsentative Speicherbelegung von in einer relevanten Flash-Speicherkarte enthaltenen Daten veranschaulicht.
4 einen typischen IP-Netzcluster veranschaulicht.
5 eine allgemeine Speicherbelegung des bevorzugten Ausführungsbeispiels eines als ein Tunnel-Server fungierenden Clustermitglieds veranschaulicht.
6 ein Flußdiagramm des allgemeinen Betriebs des Clusters veranschaulicht, das den Clusteraufbauprozeß angibt.
7 eine beispielhafte TCP-Zustandsdatenstruktur veranschaulicht.
8A–8I Flußdiagramme veranschaulichen, die die Ereignisse, die der Master verarbeitet, und die Ereignisse, die die Nicht-Master-Clustermitglieder (Clients) verarbeiten müssen, darstellen.
9 ein Flußdiagramm veranschaulicht, das den normalen Pakethandhabungsprozeß nach dem Aufbauen des Clusters darstellt.
BESTE BETRIEBSART ZUM AUSFÜHREN DER ERFINDUNG
Es sind ein Verfahren und eine Vorrichtung zum Betreiben eines Internet-Protokoll-Netzclusters (IP-Netzclusters) offenbart. In der folgenden Beschreibung sind zu Zwecken der Erläuterung spezifische Daten und Konfigurationen dargelegt, um ein gründliches Verstehen der Erfindung zu ermöglichen. Bei dem gegenwärtig bevorzugten Ausführungsbeispiel ist der IP-Netzcluster in Form von einem VPN-Tunnel-Server-Cluster beschrieben. Es ist jedoch für den Fachmann ersichtlich, daß die Erfindung ohne die spezifischen Einzelheiten in verschiedenen Anwendungen wie beispielsweise einem Firewall-Cluster, einem Gateway- oder Router-Cluster usw. in die Praxis umgesetzt werden kann. In anderen Fällen sind allgemein bekannte Systeme und Protokolle in schematischer Form oder Blockschaltbildform gezeigt und beschrieben, um die Erfindung nicht unnötig unverständlich zu machen.
BETRIEBSUMGEBUNG
Die Umgebung, in der die Erfindung verwendet wird, umfaßt die allgemeine Szene der verteilten Datenverarbeitung, die im allgemeinen lokale Netze mit Netzknoten bzw. Hubs, Vermittlungsknoten bzw. Routern, Gateways, Tunnel-Servern, Anwendungs-Servern usw. umfaßt, die über das Internet mit anderen Clients und anderen Netzen verbunden sind, wobei durch verschiedene Mitglieder des Systems Programme und Daten zur Ausführung und zum Zugriff durch andere Mitglieder des Systems zur Verfügung gestellt werden. Einige der Elemente einer typischen Internet- Netzkonfiguration sind in 1 gezeigt, wobei eine Anzahl von Client-Maschinen 105, möglicherweise in einer Filiale eines Unternehmens, gezeigt sind, die mit einem Gateway/Hub/Tunnel-Server/usw. 106 verbunden sind, der selbst über eine Internet-Dienst-Anbieter-Verbindung (ISP-Verbindung) 108 mit dem Internet 107 verbunden ist. Es sind auch andere mögliche Clients 101, 103 gezeigt, die auf ähnliche Weise über eine ISP-Verbindung 104 mit dem Internet 107 verbunden sind, wobei diese Einheiten über eine ISP-Verbindung 109 zu einem Gateway/Tunnel-Server 110, der mit verschiedenen Unternehmensanwendungs-Servern 112, 113, 114 verbunden ist 111, die durch einen weiteren Hub/Router 115 mit verschiedenen lokalen Clients 116, 117, 118 verbunden sein können, mit möglicherweise einem Hauptsitz kommunizieren.
Der vorliegende IP-Netzcluster besteht aus einer Anzahl von Universalcomputereinheiten, die jeweils im allgemeinen die in 2 gezeigten Elemente umfassen, wobei das Universalsystem 201 eine Grundplatine 203 umfaßt, auf der sich ein Eingabe-/Ausgabeabschnitt ("E/A") 205, eine Zentraleinheit oder mehrere Zentraleinheiten ("CPU") 207 und ein Speicherabschnitt 209, mit dem eine Flash-Speicherkarte 211 verbunden sein kann, befinden. Der E/A Abschnitt 205 ist mit einer Tastatur 226, anderen ähnlichen Universalcomputereinheiten 225, 215, einer Plattenspeichereinheit 223 und einer CD-ROM-Laufwerkseinheit 217 verbunden. Die CD-ROM-Laufwerkseinheit 217 kann einen CD-ROM-Träger 219 lesen, der typischerweise Programme 221 und andere Daten enthält. Logikschaltungen oder andere Komponenten dieser programmierten Computer führen eine Folge von durch Computerprogramme vorgeschriebenen näher identifizierten Operationen aus, wie es nachstehend ausführlicher beschrieben ist.
Flash-Speichereinheiten enthalten typischerweise zusätzliche Daten, die in derartigen Computersystemen zu verschiedenen Zwecken verwendet werden. Bei dem bevorzugten Ausführungsbeispiel der Erfindung wird die Flash-Speicherkarte dazu verwendet, bestimmte Einheits-"Persönlichkeits"-Informationen zu enthalten, die in 3 gezeigt sind. Im allgemeinen enthält die bei dem derzeitigen Ausführungsbeispiel verwendete Flash-Karte den folgenden Typ von Informationen:
Kryptographisch signierter Kern – (301)
Konfigurationsdateien (wie beispielsweise Clustername, spezifische Einheits-IP-Adresse, Clusteradresse, Routinginformationskonfiguration usw.) – (303)
Zeiger auf Fehlernachrichtenprotokolle – (305)
Authentifizierungszertifikat – (307)
Sicherheitspolitik (z. B. Verschlüsselung benötigt oder nicht usw.) – (309)
DIE ERFINDUNG
Die Erfindung besteht in einem Internet-Protokoll-Clustersystem (IP-Clustersystem), das ein in hohem Maße skalierbares System bereitstellen kann, das den Durchsatz durch einen adaptiven Lastausgleich bei seinen Komponenten optimiert und das die Verzögerung und den Sitzungsverlust durch einen gesteuerten Ausfallsicherungsprozeß minimiert. Ein typisches IP-Clustersystem des bevorzugten Ausführungsbeispiels ist in 4 gezeigt, wobei das Internet 107 als mit einem typischen IP-Cluster 401, der programmierte Universalcomputereinheiten 403, 405, 407, 409 enthält, die als Protokollstapelverarbeitungsrichtungen für empfangene Nachrichtenpakete fungieren, verbunden gezeigt ist. Der IP-Cluster 401 ist typischerweise mit Anwendungs-Servern oder anderen Einheiten 411 eines ähnlichen Typs in dem Netz verbunden. In dieser Figur ist es gezeigt, daß eine beliebige Anzahl von Einheiten in einem Cluster vorhanden sein kann (z. B. Mitglied "n" 409), jedoch ist zu Zwecken der weiteren Veranschaulichung der Cluster als drei Einheiten aufweisend dargestellt, wobei es selbstverständlich ist, daß der Cluster der Erfindung nicht auf nur drei Einheiten beschränkt ist. Auch zu Zwecken der Veranschaulichung ist das bevorzugte Ausführungsbeispiel als ein Cluster beschrieben, dessen Anwendungen VPN-Tunnelprotokolle sein können, jedoch ist es selbstverständlich, daß diese Clustererfindung als ein Cluster verwendet werden kann, dessen Anwendung darin besteht, als eine Firewall zu fungieren oder als ein Gateway zu fungieren oder als eine Sicherheitsvorrichtung zu fungieren usw.
Bei dem bevorzugten Ausführungsbeispiel der Erfindung ist jedes der Clustermitglieder ein Computersystem mit einer Intel Grundplatine, zwei Intel Pentium^TM Prozessoren bzw. Verarbeitungseinrichtungen, einem 64-Megabyte-Speicher und zwei Intel Ethernet-Controllern und zwei HiFn kryptographischen Prozessoren bzw. Verarbeitungseinrichtungen. Die durch jede Verarbeitungseinrichtung ausgeführten Funktionen sind im allgemeinen unter Bezugnahme auf die allgemeine Speicherbelegung jeder Verarbeitungseinrichtung wie in 5 dargestellt gezeigt. Jedes Clustermitglied weist einen Betriebssystemkern 501, TCP/IP-Stapelroutinen 503 und verschiedene Clusterverwaltungsroutinen (nachstehend ausführlicher beschrieben) 505, Programmcode zum Verarbeiten einer Anwendung # 1 507, der bei dem bevorzugten Ausführungsbeispiel Code zum Verarbeiten des IPSec-Protokolls ist, Programmcode zum Verarbeiten einer Anwendung # 2 509, der bei dem bevorzugten Ausführungsbeispiel Code zum Verarbeiten des PPTP-Protokolls ist, Programmcode zum Verarbeiten einer Anwendung # 3 511, der bei dem bevorzugten Ausführungsbeispiel Code zum Verarbeiten des L2TP-Protokolls ist, und Programmcode zum Verarbeiten einer Anwendung # 4 513, der bei dem bevorzugten Ausführungsbeispiel Coderaum zum Verarbeiten eines zusätzlichen Protokolls wie vielleicht eines "Mobil-IP"-Protokolls ist, auf. Ausführliche Informationen über diese Protokolle können über die Homepage der IETF bei "http://www.ietf.org" gefunden werden. Die folgenden spezifischen Protokollunterlagen sollten in Verbindung mit diesem Dokument gelesen werden:

"Point-to-Point Tunneling Protocol--PPTP" Glen Zorn, G. Pall, K. Hamzeh, W. Verthein, J. Taarud, W. Little, 28.07.1998;
"Layer Two Tunneling Protocol", Allan Rubens, William Palter, T. Kolar, G. Pall, M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Mark Townsley, 22.05.1998;
Kent, S., Atkinson, R., "IP Authentication Header," draft-ietf-ipsec-auth-header07.txt.
Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," draft-ietf-ipsec-arch-sec-07.txt.
Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," draft-itef-ipsecesp-v2-06.txt.
Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms," draft-ietf-ipsec-ciph-cbc-04.txt.
Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use With Ipsec," draft-ietf-ipsec-ciph-null-O1.txt.
Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf ipsec-ciph-desexpiv-02.txt.
Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and AH," draft-ietfipsec-auth-hmac-md5-96-03.txt.
Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH," drafti etf-ipsec-auth-hmac-sha 196-03.txt.
Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-ietf-ipsec-isakmp-oakley-08.txt.
Maughan, D., Schertler, M., Schneider, M., und Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-10.{ps,txt}.
K. Orman, "The H. OAKLEY Key Determination Protocol," draft-ietf-ipsec-oakley-02.txt.
Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP," draft-ietf-ipsec-ipsec-doi-I0.txt.

Es wird erwartet, daß Tunnelprotokolle wie beispielsweise das Punkt-zu-Punkt-Tunnelprotokoll (PPTP) und das Schicht-2-Tunnelprotokoll (L2TP) in der sehr nahen Zukunft durch die Internet Engineering Task Force (IETF) als offizielle Standards bestätigt werden, obwohl sie derzeit nur "Entwurfs"-Standards sind, und diese Protokolle stellen zusammen mit dem Internet-Sicherheitsprotokoll (IPSec, Internet Security Protocol) die Grundlage für die erforderliche Sicherheit dieser VPN bereit.
Wieder mit Bezug auf 5 enthält das bevorzugte Ausführungsbeispiel in einem Clustermitglied auch eine Arbeitszuweisungstabelle 515, die die Nachrichten-/Sitzungs-Arbeitseinheits-Hash-Zahlen und die der Arbeitseinheit zugewiesene Clustermitglieds-id enthält; eine Tabelle, die die Anwendungszustandstabelle für dieses Clustermitglied enthält 517; eine ähnliche Anwendungszustandstabelle für die anderen Mitglieder des Clusters 519; einen Bereich zum Enthalten eingehender Nachrichten 521; und Datenhandhabungseinrichtungsroutinen zum Handhaben von Datennachrichten von anderen Mitgliedern des Clusters 523. Der Fachmann erkennt es, daß verschiedene andere Routinen und Nachrichtenspeicher in einem derartigen Speicher eines Clustermitglieds realisiert sein können, um eine Vielfalt von Funktionen und Anwendungen auszuführen.
Der allgemeine Betrieb des bevorzugten Ausführungsbeispiels des IP-Clusters ist nachstehend hinsichtlich (1) Clusteraufbau (6) einschließlich Prozessen für in den Cluster eintretende und den Cluster verlassende Mitglieder; (2) Master-Einheiten-Ereignisverarbeitung (8A–8F) und Client-Einheiten-Ereignisverarbeitung (8G–8I); und (3) schließlich normaler Nachrichtenverarbeitungsaktivität (9) beschrieben.
Nachstehend mit Bezug auf 6 ist die Clusteraufbauaktivität dargestellt. Bei dem Systemstart 601 versuchen Clustermitglieder, in den Cluster einzutreten, indem sie eine "Eintrittsanfrage"-Nachricht senden (ausstrahlen) 603. Diese "Eintritts"-Nachricht enthält ein von einer gültigen Zertifikatsautorität erhaltenes Authentifizierungszertifikat. Wenn die Master-Einheit diese "Eintritts"-Nachricht empfängt, überprüft sie das Zertifikat gegenüber einer Liste von gültigen Zertifikaten, die sie hält, und falls sie keine Übereinstimmung findet, teilt sie ihm einfach mit, daß der Eintritt fehlgeschlagen ist. Es ist zu beachten, daß normalerweise dann, wenn ein Systemadministrator eine Hinzufügung einer Hardwareeinheit zu einem vorhandenen Cluster plant, er seine Sicherheitsabteilung oder eine vorhandene Sicherheitszertifikatsautorität dazu auffordert, ein Zertifikat zu der neuen Einheit auszugeben und eine Kopie des Zertifikats zu der Master-Einheit in dem Cluster zu senden. Dieser Prozeß garantiert es, daß jemand nicht illegal eine Einheit mit einem Cluster verbinden kann, um gesicherte Nachrichten zu erhalten. Falls die Master-Einheit das Zertifikat aus der Eintrittsnachricht mit einem Zertifikat in Übereinstimmung bringt, das sie in ihrem Speicher hält, sendet sie eine Nachricht "OK zum Eintreten". Wenn eine Nachricht "OK zum Eintreten" empfangen wird 605, dann wird diese Einheit als ein Clustermitglied (Client oder Nicht-Master) bezeichnet 607. Es ist zu beachten, daß jedes Clustermitglied einen Master-Überwachungszeitgeber (d. h. eine Routine zum Verfolgen dessen, ob das Mitglied während eines bestimmten Intervalls, etwa innerhalb der letzten 200 Millisekunden, eine Am-Leben-Nachricht von dem Master erhalten hat) aufweist, und falls der Zeitgeber abläuft (d. h. keine Am-Leben-Nachricht von dem Master während des Intervalls), bedeutet dies, daß die Master-Einheit tot ist 607, und das Clustermitglied/der Client wird wieder versuchen, in den Cluster einzutreten (611). Ein anderes Ereignis, das das Clustermitglied/den Client 607 dazu veranlaßt, es zu versuchen, wieder einzutreten, besteht darin, daß es eine "Austrittsanfrage"-Nachricht erhält (d. h. ihm mitgeteilt wird, "den Cluster zu verlassen") 609. Falls das die Eintrittsanfragenachricht (603) aussendende Mitglied keine Nachricht "OK zum Eintreten" erhält 613, sendet das Mitglied Pakete aus (strahlt sie aus), die es anbieten, die Master-Einheit zu werden 615. Falls das Mitglied eine Nachricht "Anderer Master vorhanden" erhält 617, versucht das Mitglied, wieder einzutreten 603. Falls nachdem das Mitglied die Pakete ausgesendet hat, die es anbieten, der Master zu werden, das Mitglied für 100 Millisekunden keine Antwort erhält 619, sendet es ausgestrahlte Adressenauflösungsprotokollantworten (ARP-Antworten), um jedem an dem Netz mitzuteilen, welche Ethernet-Adresse für die Cluster-IP-Adresse zu verwenden ist 621, und fungiert nun als die Cluster-Master-Einheit 623. Falls bei diesem Prozeß das Cluster-Mitglied keine Angabe erhalten hat, daß ein weiterer Master vorhanden ist (bei 617), und nun denkt, daß es der einzige Master ist 623, aber noch eine Nachricht zum "aus dem Cluster Austreten" erhält 641, muß das Mitglied dazu zurückkehren, es zu versuchen, wieder einzutreten 642. Dies könnte z. B. passieren, falls die Konfigurationsversion dieses neuen Masters nicht richtig war. Er würde zurückkehren, eine aktualisierte Konfiguration bekommen und probieren, wieder einzutreten. Wenn auf ähnliche Weise dieses Mitglied, das denkt, daß es der neue Master ist 623, eine "Master-am-Leben"-Nachricht erhält 625 (die es angibt, daß ein weiteres Clustermitglied denkt, daß es die Master-Einheit ist), dann überprüft es, um zu sehen, ob die Master-am-Leben-Nachricht irgendwie von ihm war 627 (normalerweise erhält der Master seine eigenen Am-Leben-Nachrichten nicht, aber es kann passieren), und falls dem so ist, ignoriert er die Nachricht einfach 639. Falls jedoch die Master-am-Leben-Nachricht nicht von ihm selbst war 629, dann bedeutet dies, daß ein weiteres Clustermitglied vorhanden ist, das denkt, daß es die Master-Einheit ist, und irgendwie muß dieser "Gleichstand" bzw. "Tie" aufgelöst werden. (Dieser Gleichstandsauflösungsprozeß bzw. Tie-Break-Prozeß ist nachstehend mit Bezug auf die "Master-Ereignis"-Verarbeitung ausführlicher beschrieben). Falls der Gleichstand zugunsten des neuen Clustermitglieds aufgelöst wird, das denkt, daß es der Master ist 635, sendet es eine Nachricht "Anderer Master vorhanden" zu dem anderen Master und sendet noch einmal ausgestrahlte Adressenauflösungsprotokollantworten (ARP-Antworten), um es jedem an dem Netz mitzuteilen, welche Ethernet-Adresse für die neue Cluster-IP-Adresse zu verwenden ist 637 (da der andere Master das Gleiche getan haben kann). Wenn dieses neue Clustermitglied, das denkt, daß es der Master ist, den Tie-Break verliert 633, dann muß es gehen und wieder eintreten, um es zu versuchen, den Cluster stabilisiert zu bekommen. Dieser Prozeß erzeugt ein einzelnes Clustermitglied, das als die Master-Einheit fungiert, und die anderen Clustermitglieder, die es verstehen, daß sie lediglich Mitglieder sind.
Master-Einheit-Ereignisverarbeitung
Nachdem sich ein Cluster gebildet hat, sind verschiedene auftretende Ereignisse vorhanden, mit denen sich die Master-Einheit befassen muß. Wie diese bei dem bevorzugten Ausführungsbeispiel gehandhabt werden ist nachstehend unter Bezugnahme auf 8A–8F beschrieben. Mit Bezug auf 8A beschreibt das erste Master-Einheit-Ereignis den "Tie-Break"-Prozeß, wenn zwei Clustermitglieder es beanspruchen, die "Master-Einheit" zu sein. Sich aus dem vorstehenden ins Gedächtnis zurückrufend, daß der Master normalerweise nicht seine eigene "Am-Leben"-Nachricht empfängt, so daß falls ein Master eine "Master-am-Leben"-Nachricht erhält 801, es wahrscheinlich angibt, daß ein weiteres Clustermitglied denkt, daß es der Master ist. Bei dem bevorzugten Ausführungsbeispiel enthält die "Master-am-Leben"-Nachricht die Clustermitgliedsliste, das adaptive Am-Leben-Intervall (das nachstehend ausführlicher beschrieben ist) und den derzeitigen Satz von Arbeitszuweisungen für jedes Mitglied, der nur zu diagnostischen Zwecken verwendet wird. So fragt ein Master dann, wenn er eine Master-am-Leben-Nachricht erhält 801, zuerst "Ist sie von mir?" 803, und falls dem so ist, ignoriert er diese Nachricht einfach 807 und beendet 808. Wenn die Master-am-Leben-Nachricht nicht von dieser Master-Einheit ist 804, dann beginnt der "Tie-Break"-Prozeß, indem gefragt wird "Habe ich mehr Clustermitglieder als dieser andere Master?" 809. Wenn dieser Master dies tut, dann sendet er eine Nachricht "Anderer Master vorhanden" 825, die es dem anderen Master mitteilt, die Master-Rolle aufzugeben und wieder in den Cluster einzutreten. Der verbleibende Master sendet daraufhin noch einmal ausgestrahlte Adressenauflösungsprotokollantworten (ARP-Antworten), um es jedem an dem Netz mitzuteilen, welche Ethernet-Adresse für die Cluster-IP-Adresse zu verwenden ist 827, und beendet 808. Falls der derzeitige Master nicht mehr Clustermitglieder als dieser andere Master aufweist 811, fragt er "Habe ich weniger Clustermitglieder als der andere Master?" 813, und falls dem so ist 816, muß er die Master-Rolle zugunsten des anderen Masters aufgeben, indem er aus dem Cluster austritt 821 und als ein Mitglied/Nicht-Master wieder in den Cluster eintritt 823, wobei er zu 601 in 6 austritt. Wenn der derzeitige Master nicht weniger Mitglieder als der andere Master aufweist 815 (was es angibt, daß sie beide die gleiche Anzahl aufweisen), dann tritt der endgültige Tie-Break auf, indem gefragt wird "Ist meine IP-Adresse kleiner als seine?" 817, und falls dem so ist, gewinnt der derzeitige Master daraufhin wieder den Tie-Break 818 und sendet die Nachricht "Anderer Master vorhanden" wie zuvor 825. Wenn er jedoch diesen endgültigen Tie-Break verliert 819, dann tritt er aus dem Cluster aus, um als ein Nicht-Master-Mitglied wiedereinzutreten 821.
Nachstehend auf 8B Bezug nehmend tritt ein weiteres Master-Ereignis auf, wenn der Master eine "Client-am-Leben-Nachricht" erhält (d. h. eine von einem Nicht-Master-Clustermitglied) 830. Der Master fragt "Ist dieser Client in meinem Cluster?" 831, und falls dem nicht so ist, sendet der Master dem Client eine Nachricht "Aus Cluster austreten" 833, die es dem Client mitteilt, aus diesem Cluster auszutreten. Falls der Client aus dem Cluster dieses Masters ist, berechnet und speichert der Master einen Paketverlustdurchschnittswert unter Verwendung der Folgennummer der Client-am-Leben-Nachricht und des berechneten adaptiven Am-Leben-Intervalls 835. Der Master setzt daraufhin den Überwachungszeitgeber für diesen Client zurück 837. Die Überwachungszeitgeberroutine ist eine Betriebssystemroutine, die periodisch einen Zeitgeberwert überprüft, um zu sehen, ob das Aufallsicherungserfassungsintervall vergangen ist, seit der Wert zuletzt rückgesetzt wurde, und falls dem so ist, soll der Überwachungszeitgeber abgelaufen sein, und das System reagiert daraufhin, als ob der fragliche Client den Cluster verlassen hat, und weist die Arbeitslast des Clients den verbleibenden Clustermitgliedern neu zu.
Wie vorstehend angegeben sendet der Master periodisch eine Master-am-Leben-Nachricht aus, die die Clustermitgliedsliste, das adaptive Am-Leben-Intervall (das nachstehend ausführlicher beschrieben ist) und den derzeitigen Satz von Arbeitszuweisungen für jedes Mitglied, der nur zu diagnostischen Zwecken verwendet wird, enthält. (Siehe 8C). Darüber hinaus überprüft der Master periodisch (bei dem bevorzugten Ausführungsbeispiel alle 2 Sekunden) den Lastausgleich der Clustermitglieder. In 8D berechnet der Master dann, wenn der Zeitgeber abläuft 855, die Lastdifferenz zwischen dem am meisten belasteten (etwa "K") und dem am wenigsten belasteten (etwa "J") Clustermitglied 857 und fragt daraufhin "Würde ein Verschieben 1 Arbeitseinheit von dem am meisten Belasteten (K) zu dem am wenigsten Belasteten (J) eine Wirkung haben?", d. h. ob K > J ist K–1 ≥ J–1? 859. Falls dem so ist, sendet der Master daraufhin eine Anfrage "Arbeitszuweisung aufheben" zu dem am meisten belasteten Mitglied, mit dem am wenigsten belasteten Mitglied als dem Zielempfänger 863, und daraufhin überprüft der Master wieder die Lastzahlen 865. Wenn das Ergebnis des Bewegens 1 Arbeitseinheit nicht den am wenigsten Belasteten weniger als oder gleich dem am meisten Belasteten belassen würde 860, dann führt der Master keine Neuzuweisungen aus und beendet 861.
Ein weiteres Master-Ereignis tritt auf, wenn ein Überwachungszeitgeber für einen Client/ein Clustermitglied abläuft, wobei der Master den Client aus der Clusterdatenliste löscht und die Arbeit der gelöschten Einheit in einen Pool von nicht zugewiesener Arbeit geht, um normal neu zugewiesen zu werden, wenn die nächste Nachricht ankommt. (Siehe 8E).
Nachstehend mit Bezug auf 8F tritt ein weiteres Master-Ereignis bei dem bevorzugten Ausführungsbeispiel auf, wenn der Master eine Client-Eintrittsanfragenachricht erhält 875. Der Master teilt es dem Client anfänglich mit, zu warten, indem er eine NAK mit einem Grund "Operation im Werden begriffen" sendet 877. Der Master benachrichtigt daraufhin die Anwendungen, die vorhanden sind, daß ein Client versucht, in den Cluster einzutreten, da einige Anwendungen darüber Bescheid wissen möchten 879. Wenn z. B. IPSec eine der Anwendungen ist, dann kann es IPSec wünschen, diesen Client zu validieren, bevor es zustimmt, ihn in den Cluster eintreten zu lassen. Falls eine Anwendung die Eintrittsanfrage ablehnt, sendet der Master eine NAK mit dem Grund 855 und beendet. Falls alle Anwendungen die Eintrittsanfrage billigen, sendet der Master eine ACK, und der Eintritt geht weiter wie normal 887.
CLIENT-CLUSTERMITGLIEDS-EREIGNISSE
Die Nicht-Master-Clustermitglieder (Clients) müssen auch Am-Leben-Nachrichten senden und den Überwachungszeitgeber für den Master überwachen. Nachstehend mit Bezug auf 8G aktualisiert dann, wenn ein Client eine Master-am-Leben-Nachricht erhält 890, der Client sein adaptives Am-Leben-Intervall 891 und überprüft die Liste von Clustermitgliedern, um zu sehen, ob irgendwelche Mitglieder verloren worden sind 893. Falls dem so ist, benachrichtigt dieser Client seine Anwendungen, daß ein Clustermitglied abgegangen ist 895 (z. B. möchte IPSec es wissen). Der Client überprüft es auch, um zu sehen, ob irgendwelche Mitglieder zu dem Cluster hinzugefügt worden sind 897, und falls dem so ist, benachrichtigt er die Anwendungen 898 und setzt schließlich den Überwachungszeitgeber zum Überwachen des Masters zurück 899 und beendet. Jeder Client weist auch einen periodischen Zeitgeber auf, der an den durch den Master gesendeten Netzpaketverlustwert adaptiv ist, was von dem Client verlangt, periodisch eine Client-am-Leben-Nachricht (die einen monoton steigenden numerischen Wert enthält) zu dem Master zu senden. (Siehe 8H). Ferner weist jeder Client einen Master- Überwachungszeitgeber auf, den er überwachen muß, und falls er abläuft, muß der Client aus dem Cluster austreten und eine neue Eintrittsnachricht senden, um wieder in den Cluster einzutreten. (Siehe 8I).
NORMALE IP-PAKETVERARBEITUNG
Damit ein Clustermitglied nur seinen Anteil der Arbeitslast richtig verarbeitet, wird eines von drei Verfahren verwendet:

1. Die MAC-Adresse des Masters ist an die Cluster-IP-Adresse gebunden (unter Verwendung des ARP-Protokolls). Der Master wendet die (nachstehend ausführlicher beschriebene) Filterfunktion zum Klassifizieren der Arbeit und Weiterleiten jedes Pakets (falls notwendig) zu dem passenden Clustermitglied an.
2. Eine clusterweite Einpunktverbindungs-MAC-Adresse ist an die Cluster-IP-Adresse gebunden (unter Verwendung des ARP-Protokolls). Jedes Clustermitglied programmiert seine Netzschnittstelle, um Pakete von dieser MAC-Zieladresse zu akzeptieren. Nun kann jedes Clustermitglied alle Pakete mit dem Cluster-IP-Adressen-Ziel sehen. Jedes Mitglied wendet die Filterfunktion an und verwirft Pakete, die nicht Teil seiner Arbeitslast sind.
3. Verfahren 2 wird verwendet, aber mit einer Mehrpunktverbindungs-MAC-Adresse anstelle einer Einpunktverbindungs-MAC-Adresse. Dieses Verfahren ist erforderlich, wenn intelligente Paketvermittlungsvorrichtungen Teil des Netzes sind. Diese Vorrichtungen lernen es, welche Netzanschlüsse bzw. Netzports mit jeder Einpunktverbindungs-MAC-Adresse verbunden sind, wenn sie Pakete mit einer Einpunktverbindungs-MAC-Zieladresse sehen, und sie senden die Pakete nur zu dem Port, von dem es die Vermittlungsvorrichtung bestimmt hat, daß er mit der MAC-Adresse verbunden ist (nur 1 Port ist mit jeder Einpunktverbindungs-MAC-Adresse verbunden). Eine Mehrpunktverbindungs-MAC-Adresse veranlaßt die Paketvermittlungsvorrichtung zum Zustellen von Paketen mit der Cluster-IP-Zieladresse zu allen Clustermitgliedern.

Bei dem bevorzugten Ausführungsbeispiel ist ein Mechanismus vorhanden, um es zu bezeichnen, welches Clustermitglied eine Nachricht zu verarbeiten hat, und es den anderen Mitgliedern zu erlauben, die Nachricht nicht zu beachten, ohne unabsichtlich eine Nachricht "Rücksetzen" zu dem hervorbringenden Client zu senden. Das bevorzugte Ausführungsbeispiel verwendet einen "Filter"-Prozeß in jedem Clustermitglied, der unter Verwendung bestimmter Felder des eingehenden Nachrichtenkopfs eine Streuspeicherungsfunktion bzw. Hash-Funktion berechnet. Diese Hash-Berechnung dient als eine Einrichtung sowohl zum Zuweisen einer Arbeitseinheitsnummer zu einer Nachricht als auch zum Zuweisen einer Arbeitseinheit zu einem speziellen Clustermitglied zum Verarbeiten. Diese Technik erlaubt es einem Clustermitglied, es zu sagen, ob die eingehende Nachricht durch es verarbeitet werden muß, und daher wird die Möglichkeit einer unabsichtlichen Nachricht "Rücksetzen" ausgeschlossen. Es ist zu beachten, daß andere Lösungen für dieses Problem von "wie die Arbeit mit minimalem Gemeinaufwand bzw. Overhead zu dem richtigen Mitglied des Clusters zu bekommen ist" eine zwischen dem Netz und dem Cluster sitzende Hardwarefiltervorrichtung umfassen könnten, wobei das Hardwarefilter die Mitgliedszuweisungs- und Lastausgleichsfunktion durchführen würde. Da alle Clustermitglieder die gleiche MAC-Adresse aufweisen, ist es zu beachten, daß alle Clustermitglieder alle Nachrichten erhalten und der Weg, auf dem sie es sagen, ob sie die Nachricht weiter verarbeiten müssen, darin besteht, die Arbeitseinheitsnummer unter Verwendung des vorstehend beschriebenen Hash-Verfahrens zu berechnen und daraufhin die sich ergebende Arbeitseinheitsnummer gegen ihre Arbeitslasttabelle zu überprüfen, um zu sehen, ob sie ihnen zugewiesen ist. Falls dem nicht so ist, laden sie die Nachricht aus ihrem Speicher ab. Dies ist ein schnelles und effizientes Schema zum Abladen von Nachrichten, die die Einheiten nicht weiter verarbeiten müssen, und außerdem stellt es eine effiziente Grundlage zum Lastausgleich und zur effizienten Ausfallsicherungshandhabung, wenn ein Clustermitglied ausfällt, bereit.
Die normale Verarbeitung von IP-Paketen ist unter Bezugnahme auf 9 beschrieben. Bei dem Empfang eines Pakets 901 wird eine Bestimmung dahingehend ausgeführt, ob das Paket an eine Cluster-IP-Adresse adressiert ist 903 oder nicht. Wenn dem nicht so ist 905, dann wird es bestimmt, ob die IP-Adresse für dieses Clustermitglied ist, und falls dem so ist, wird es durch den IP-Stapel lokal verarbeitet 909. Falls das Paket weiterzuleiten ist (in diesem Fall arbeitet das System wie ein Router) 908, wird ein Weiterleitungsfilter angewendet, um die Arbeit zu klassifizieren 913. Dies bezeichnet es, ob das Paket für normale Arbeit für die Cluster-Clients ist oder Weiterleitungsarbeit ist. Wenn bei dem Schritt 903, in dem die Adresse überprüft wurde, um zu sehen, ob es eine Cluster-IP-Adresse war, die Antwort Ja war, dann wird ein ähnliches Arbeitssatzfilter angewendet 911, wobei die IP-Quellen- und Zieladressen Modulo 1024 streugespeichert werden, um einen Indexwert zu erzeugen, der zu verschiedenen Zwecken verwendet wird. Diese Indexwertberechnung (das Verarbeitungsfilter) ist bei dem derzeitigen Ausführungsbeispiel erforderlich und ist ausführlicher beschrieben wie folgt.
Grundsätzlich enthalten die Felder die IP-Adressen, das IP-Protokoll und die TCP/UDP-Portnummern, und falls die Anwendung L2TP ist, werden die Sitzungs- und Tunnel-ID-Felder alle zusammenaddiert (logisches XOR) und daraufhin verschoben, um eine eindeutige "Arbeitseinheits"-Nummer zwischen 0 und 1023 zu erzeugen.
Beispielsweise könnte bei dem bevorzugten Ausführungsbeispiel der Index berechnet werden wie folgt:
Wieder mit Bezug auf 9 und mit dem berechneten Arbeitssatzindexwert verwendet jedes diese Berechnung ausführende Mitglied den Indexwert als einen indirekten Zeiger zum Bestimmen für diesen Arbeitssatz, ob es sein zugewiesener Arbeitssatz ist 915, 917. Falls der Indexwert es nicht angibt, daß dieser Arbeitssatz diesem Clustermitglied zugewiesen worden ist, wird dann, wenn dieses Clustermitglied nicht der Cluster-Master ist, das Paket einfach durch dieses Clustermitglied fallengelassen 921, 923, 925. Wenn demgegenüber dieses Clustermitglied die Master-Einheit ist 926, dann muß der Master es überprüfen, um zu sehen, ob dieser Arbeitssatz einem der anderen Clustermitglieder zum Verarbeiten zugewiesen worden ist 927. Falls er einem anderen Clustermitglied zugewiesen worden ist 929, überprüft es der Master, um zu sehen, ob das Clustermitglied das Empfangen der Zuweisung quittiert hat 931, und falls dem so ist, überprüft es der Master, um zu sehen, ob er in der Mehrpunktverbindungsbetriebsart oder Einpunktverbindungs-/Weiterleitungsbetriebsart war 933, 935. Falls er in der Einpunktverbindungs- oder Mehrpunktverbindungsbetriebsart ist, läßt der Master das Paket fallen, da das zugewiesene Clustermitglied es gesehen hätte 936. Falls der Master jedoch in der Weiterleitungsbetriebsart war, wird der Master das Paket zum Verarbeiten zu dem zugewiesenen Mitglied weiterleiten 943. Wenn das zugewiesene Clustermitglied das Empfangen der Zuweisung noch nicht quittiert hat 940, dann wird das Paket gesichert, bis es die Zuweisung quittiert 941, und daraufhin das Paket zum Verarbeiten zu ihm weitergeleitet 943. Wenn dann, wenn der Master es bei 927 überprüft hat, um zu sehen, ob sein Arbeitssatz zugewiesen worden ist, die Antwort Nein ist 928, dann wird der Master diesen Arbeitssatz dem am wenigsten belasteten Mitglied zuweisen 937 und daraufhin seine vorherige Aufgabe fortsetzen 939, bis das zugewiesene Mitglied den Empfang der Zuweisung quittiert wie vorstehend beschrieben. Falls die Arbeit für dieses Mitglied ist, wird das Paket zu dem lokalen TCP/IP-Stapel geleitet.
Zustandsaufrechterhaltung
RFC 1180 A TCP/IP Tutorial, T. Socolofsky und C. Kale, Januar 1991 beschreibt allgemein die TCP/IP-Protokollsuite und sollte in Verbindung mit diesem Dokument gelesen werden. Bei der Erfindung besteht ein Schlüsselelement in der Fähigkeit, den TCP-Zustand in einen wesentlichen Abschnitt des Zustands und einen berechenbaren Abschnitt des Zustands aufzuteilen. Beispielsweise ändert sich der Zustand einer TCP-Nachricht beständig, und entsprechend wäre es für ein Clustermitglied nicht praktisch, jedesmal, wenn sich der Zustand ändert, diesen ganzen TCP-Zustand zu allen anderen Mitgliedern des Clusters zu übertragen. Dies würde eine übermäßige Menge von Speicher und Verarbeitungszeit erfordern und würde den Verkehr zu den Mitgliedern des Clusters im wesentlichen verdoppeln. Die Fähigkeit der Mitgliedseinheiten zum Aufrechterhalten des Zustands dieser eingehenden Nachrichten ist entscheidend für ihre Fähigkeit, den Ausfall einer Mitgliedseinheit zu handhaben, ohne ein Rücksetzen der Nachrichtensitzung zu erfordern.
7 stellt die Definition des bevorzugten Ausführungsbeispiels davon dar, welche Elemente des TCP- Zustands als wesentlich betrachtet werden und daher zu jedem Mitglied des Clusters übertragen werden müssen 701, wenn sie sich ändern, und welche Elemente des TCP-Zustands als aus dem wesentlichen Zustand berechenbar betrachtet werden 703 und daher nicht zu allen Mitgliedern des Clusters übertragen werden müssen, wenn sie sich ändern. Der TCP-Ausfallsicherungszustand 700 bei dem vorliegenden Ausführungsbeispiel umfaßt tatsächlich drei Abschnitte, einen anfänglichen Zustandsabschnitt 702, der nur einmal zu allen Clustermitgliedern gesendet werden muß; den wesentlichen Zustandsabschnitt 701, der zu allen Clustermitgliedern gesendet werden muß, damit sie ihn speichern, wenn sich ein in dem wesentlichen Abschnitt aufgelisteter Punkt ändert; und den berechenbaren Zustandsabschnitt 703, der nicht zu allen Mitgliedern gesendet wird. Die Daten auf der rechten Seite des Gleichheitszeichens ("=") für jedes Element geben es an, wie der Wert des Elements zu berechnen ist, wann immer es notwendig ist, dies zu tun.
Ausfallsicherungshandhabung
Wie vorstehend angegeben umfaßt das bevorzugte Ausführungsbeispiel der IP-Clustervorrichtung und des IP-Clusterverfahrens auch die Fähigkeit zum Überwachen des Betriebs jedes Clustermitglieds, um den Clusterbetrieb für eine optimale Leistungsfähigkeit zu verwalten. Dies bedeutet, sicherzustellen, daß das Clustersystem es schnell erkennt, wenn ein Clustermitglied aus einem Grund nicht betriebsfähig wird, sowie einen vernünftigen Prozeß zu haben, um es abzulehnen, ein Clustermitglied aufgrund von Paketverlusten als nicht betriebsfähig zu erklären, die in einem TCP/IP-Netz inhärent sind. Dieser Überwachungsprozeß wird bei dem bevorzugten Ausführungsbeispiel durch ein Verfahren durchgeführt, durch das jedes Nicht-Mitglied-Clustermitglied einen "Master-Überwachungszeitgeber" hält und der Master einen "Client-Überwachungszeitgeber" für alle Clustermitglieder hält. Diese Überwachungszeitgeber sind lediglich Routinen, durch die das OS des Clustermitglieds periodisch einen "Überwachungszeitwert" überprüft, um zu sehen, ob er mehr als eine Zeit "t" früher als die derzeitige Zeit ist (d. h. um zu sehen, ob der Überwachungszeitwert innerhalb der letzten Zeit "t" rückgesetzt worden ist). Wenn es die Routine befindet, daß die Differenz zwischen der derzeitigen Zeit und dem Überwachungszeitwert größer als die Zeit "t" ist, dann erklärt sie das mit dem Überwachungszeitgeber verbundene Clustermitglied als nicht betriebsfähig. Diese Überwachungszeitwerte werden rückgesetzt, wann immer ein Clustermitglied ein (gelegentlich als eine "Herzschlag"-Nachricht bezeichnetes) "Am-Leben"-Paket zu den anderen Mitgliedern sendet.
Im allgemeinen ist eine "Am-Leben"-Nachricht eine Nachricht, die durch eine Netzvorrichtung gesendet wird, um eine weitere Netzvorrichtung zu benachrichtigen, daß die virtuelle Schaltung zwischen den beiden noch aktiv ist. Bei dem bevorzugten Ausführungsbeispiel sendet die Master-Einheit ein "Master-am-Leben"-Paket, das eine Liste der Clustermitglieder, ein "adaptives Am-Leben-Intervall" und einen derzeitigen Satz von Arbeitszuweisungen für alle Mitglieder enthält. Die Nicht-Master-Clustermitglieder überwachen einen Master-Überwachungszeitgeber, um sich davon zu überzeugen, daß der Master noch am Leben ist, und verwenden den durch den Master zugeführten Wert "adaptives Am-Leben-Intervall" zum Bestimmen, wie häufig sie (die Nicht-Master-Clustermitglieder) ihre "Client-am-Leben"-Pakete senden müssen, so daß der Master ihr Vorhandensein in dem Cluster überwachen kann. Die "Client-am-Leben"-Pakete enthalten eine monoton steigende Folgennummer, die zum Messen eines Paketverlusts in dem System und zum Einstellen der Wahrscheinlichkeit eines Paketverlustwerts, die zum Einstellen des adaptiven Am-Leben-Intervalls verwendet wird, verwendet wird. Im allgemeinen werden diese Berechnungen bei dem bevorzugten Ausführungsbeispiel durchgeführt wie folgt, jedoch ist es für den Fachmann selbstverständlich, daß verschiedenartige Programmierung und Logikschaltungsprozesse verwendet werden können, um äquivalente Maßnahmen des Paketverlusts und betreffende Überwachungszeitgeberwerte zu erreichen.
Jeder Client umfaßt eine Folgennummer in seinem "Client-am-Leben"-Paket. Wenn der Master dieses Am-Leben-Paket für einen Client "x" erhält, führt er die folgenden Berechnungen aus: SΔ = [diese Folgennummer] – [letzte Folgennummer] – 1
Dieser Wert S_Δ ist typischerweise = 0 oder 1 und stellt die Anzahl von fallengelassenen Paketen zwischen den letzten beiden Am-Leben-Nachrichten oder den derzeitigen Paketverlust für den Client "x" dar.
Dieser Wert wird daraufhin in einer exponentiellen Glättungsformel verwendet, um einen derzeitigen durchschnittlichen Paketverlust "P" zu berechnen wie folgt: Pneu = PaltX[127/128] + SΔX[1/128]
Dieses P_neu stellt daraufhin die Wahrscheinlichkeit eines Paketverlusts dar, und Pⁿ (P in der n-ten Potenz) würde die Wahrscheinlichkeit eines Erhaltens von "n" aufeinanderfolgenden Paketverlusten darstellen. Und 1/Pⁿ wäre wie oft wir "n" Pakete nacheinander verlieren würden.
So ist "n" als die Anzahl von verlorenen Paketen pro Intervall definiert, und Pⁿ ist daraufhin die Wahrscheinlichkeit des Verlierens von "n" Paketen in einem Intervall. Offensichtlich ist dann, wenn wir in einem gegebenen Intervall mehr als eine Anzahl von Paketen verlieren, entweder das Clustermitglied schlecht funktionierend oder nicht betriebsfähig, oder das Netz hat Probleme. Bei dem bevorzugten Ausführungsbeispiel nehmen wir an, daß "n" eine Anzahl zwischen 2 und 20 ist, und berechnen seinen Wert adaptiv wie folgt.
Wir bezeichnen das Intervall als "K" und stellen 1/K = nPⁿ ein. Gemäß Politik stellen wir K = 3600 ein (was äquivalent zu einer Periode von 1 Woche ist) und berechnen daraufhin den kleinsten ganzzahligen Wert von "n", für den nPⁿ < 1/3600. Bei dem bevorzugten Ausführungsbeispiel wird dies getan, indem die Berechnung mit n = 2 begonnen wird und n iterativ um 1 erhöht wird, bis die Bedingung erfüllt ist. Der sich ergebende Wert von "n" ist das adaptive Am-Leben-Intervall, das der Master daraufhin zu allen Clustermitgliedern sendet, damit sie es bei dem Bestimmen, wie oft sie ihre "Client-am-Leben"-Nachrichten senden sollen, verwenden.
Während die Erfindung hinsichtlich eines bevorzugten Ausführungsbeispiels beschrieben ist, erkennt es der Fachmann, daß verschiedene Typen von Universalcomputerhardware für die vorstehend beschriebene Konfiguration eingesetzt werden können, um ein äquivalentes Ergebnis zu erreichen. Auf ähnliche Weise wird es erkannt, daß arithmetische Logikschaltungen zum Ausführen jeder erforderlichen Einrichtung in den Patentansprüchen konfiguriert sind, um Internet-Sicherheitsprotokolle und Tunnelprotokolle auszuführen; um es der Master-Einheit zu ermöglichen, Verarbeitungszuweisungen für eingehende Nachrichten adaptiv zu verteilen, und um es Clustermitgliedern zu ermöglichen, es zu erkennen, welche Nachrichten ihre zum Verarbeiten sind; und zum Erkennen von Nachrichten von anderen Mitgliedern in dem Cluster. Es ist für den Fachmann ersichtlich, daß Modifikationen und Variationen des bevorzugten Ausführungsbeispiels möglich sind, die in den Bereich der Erfindung wie durch die folgenden Patentansprüche begrenzt fallen.

Claims

Auf einem Computer realisiertes Verfahren zur Überwachung einer Netzaktivität und zur gesteuerten Ausfallsicherung in einem TCP/IP-Netzcluster, wobei der Cluster eine Vielzahl von Clustermitgliedern aufweist, wobei jedes Clustermitglied ein Computersystem mit einer Verarbeitungseinrichtung, einem Speicher, einem Programm in dem Speicher, einem Bildschirm und einer Eingabe-/Ausgabeeinheit umfaßt, wobei das Verfahren gekennzeichnet ist durch die Schritte: a. Bestimmen eines adaptiven Intervallwerts, der ein Zeitintervall als eine Funktion eines durchschnittlichen Paketverlusts in dem Cluster darstellt; und b. Verwenden des adaptiven Intervallwerts zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht zu allen anderen Clustermitgliedern senden soll, wobei die Am-Leben-Nachricht zum Bestimmen eines Netzpaketverlusts verwendet wird.
Verfahren nach Anspruch 1, mit dem zusätzlichen Schritt des Verwendens einer Folgennummer in einer derzeitigen Am-Leben-Nachricht zum Bestimmen eines derzeitigen Paketverlustwerts, der eine Anzahl von seit einem Empfang einer früheren Am-Leben-Nachricht verlorenen Paketen darstellt.
Verfahren nach Anspruch 2, wobei der derzeitige Paketverlustwert zum Aktualisieren einer durchschnittlichen Anzahl des Paketverlustwerts verwendet wird.
Verfahren nach Anspruch 3, mit dem zusätzlichen Schritt des Verwendens der aktualisierten durchschnittlichen Anzahl des Paketverlustwerts zum Überprüfen des adaptiven Intervallwerts.
Verfahren nach Anspruch 1, mit dem zusätzlichen Schritt des Verwendens einer Am-Leben-Nachricht zum Rücksetzen eines Überwachungszeitgebers, falls die Am-Leben-Nachricht empfangen wird, bevor der Überwachungszeitgeber abläuft.
Verfahren nach Anspruch 5, wobei ein Clustermitglied als nicht betriebsfähig betrachtet wird, falls der Überwachungszeitgeber abläuft.
Verfahren nach Anspruch 6, mit den zusätzlichen Schritten, daß jedes Clustermitglied es erkennt, daß ein Clustermitglied nicht betriebsfähig geworden ist, wobei eine Aufgabe, ein Cluster-Master zu sein, unmittelbar neu zugewiesen wird, falls es der Cluster-Master ist, der nicht betriebsfähig ist, wobei der Cluster-Master Arbeit neu zuweist, die dem ausgefallenen Clustermitglied zugewiesen wurde, wodurch die Arbeitslast bei verbleibenden Clustermitgliedern wieder ausgeglichen wird.
Verfahren nach Anspruch 1, mit dem zusätzlichen Schritt, daß jedes Clustermitglied einen Zustand für jede Nachrichtensitzungsverbindung einschließlich eines TCP-Zustands sichert, und zum Trennen dieses Zustands in einen wesentlichen Zustandsabschnitt und einen nicht wesentlichen Zustandsabschnitt.
Verfahren nach Anspruch 8, mit dem zusätzlichen Schritt, daß jedes Clustermitglied zu jedem anderen Clustermitglied den gesicherten wesentlichen Zustandsabschnitt für Nachrichtensitzungsverbindungen überträgt, für die das Clustermitglied verantwortlich ist, wobei eine derartige Übertragung auszuführen ist, wann immer der wesentliche Abschnitt des Zustands sich ändert, wodurch alle Clustermitglieder den wesentlichen Zustand für alle Nachrichtensitzungsverbindungen erhalten.
Verfahren nach Anspruch 9, mit dem zusätzlichen Schritt, daß ein Clustermitglied den nicht wesentlichen Zustandsabschnitt auf der Grundlage des gesicherten wesentlichen Zustandsabschnitts berechnet, wann immer eine betreffende Nachricht dem Clustermitglied neu zugewiesen wird, da ein weiteres Clustermitglied nicht betriebsfähig wird.
Internet-Protokoll-Netzclustervorrichtung (IP-Netzclustervorrichtung) mit einer Vielzahl von gegenseitig verbundenen Clustermitgliedern, wobei jedes Clustermitglied ein Computersystem mit einer Verarbeitungseinrichtung, einem Speicher, einem Programm in dem Speicher, einem Bildschirm und einer Eingabe-/Ausgabeeinheit umfaßt; und gekennzeichnet durch: eine Einrichtung zum Bestimmen eines adaptiven Intervallwerts, der ein Zeitintervall als eine Funktion eines durchschnittlichen Paketverlusts in dem Cluster darstellt; und eine Einrichtung zum Verwenden des adaptiven Intervallwerts zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht zu allen anderen Clustermitgliedern senden soll, wobei die Am-Leben-Nachricht zum Bestimmen eines Netzpaketverlusts verwendet wird.
Vorrichtung nach Anspruch 11, ferner mit einer Einrichtung zum Verwenden einer Folgennummer in einer derzeitigen Am-Leben-Nachricht zum Bestimmen eines derzeitigen Paketverlustwerts, der eine Anzahl von seit einem Empfang einer früheren Am-Leben-Nachricht verlorenen Paketen darstellt.
Vorrichtung nach Anspruch 12, wobei der derzeitige Paketverlustwert zum Aktualisieren einer durchschnittlichen Anzahl des Paketverlustwerts verwendet wird.
Vorrichtung nach Anspruch 13, ferner mit einer Einrichtung zum Verwenden der aktualisierten durchschnittlichen Anzahl des Paketverlustwerts zum Überprüfen des adaptiven Intervallwerts.
Vorrichtung nach Anspruch 11, ferner mit einer Einrichtung zum Verwenden einer Am-Leben-Nachricht zum Rücksetzen eines Überwachungszeitgebers, falls die Am-Leben-Nachricht empfangen wird, bevor der Überwachungszeitgeber abläuft.
Vorrichtung nach Anspruch 15, wobei ein Clustermitglied als nicht betriebsfähig betrachtet wird, falls der Überwachungszeitgeber abläuft.
Vorrichtung nach Anspruch 15, ferner mit einer Einrichtung in jedem Clustermitglied der Vielzahl von Clustermitgliedern zum Sichern eines wesentlichen Zustands für jede Nachrichtensitzungsverbindung einschließlich eines TCP-Zustands.
Vorrichtung nach Anspruch 17, ferner mit einer Einrichtung in jedem Clustermitglied der Vielzahl von Clustermitgliedern zum periodischen Übertragen des gesicherten wesentlichen Zustands für jede Nachrichtensitzungsverbindung zu jedem der anderen Mitglieder in dem Cluster.
Vorrichtung nach Anspruch 18, ferner mit einer Einrichtung in jedem Clustermitglied der Vielzahl von Clustermitgliedern, um es einem als eine Master-Einheit fungierenden Clustermitglied zu erlauben, ein nicht betriebsfähiges Clustermitglied zu erkennen, und um Arbeit des nicht betriebsfähigen Clustermitglieds verbleibenden Mitgliedern in dem Cluster neu zuzuweisen, wodurch die Verarbeitungslast wieder ausgeglichen wird und Nachrichtensitzungsverbindungen erhalten werden, und um es Clustermitgliedern, die nicht als eine Master-Einheit fungieren, zu erlauben, eine nicht betriebsfähige Master-Einheit zu erkennen, um unmittelbar und zusammenarbeitend eines der verbleibenden Clustermitglieder als eine neue Master-Einheit zu bezeichnen, wobei die neue Master-Einheit dazu dient, Arbeit des nicht betriebsfähigen Clustermitglieds verbleibenden Mitgliedern in dem Cluster neu zuzuweisen, wodurch die Verarbeitungslast wieder ausgeglichen wird und Nachrichtensitzungsverbindungen erhalten werden.
Vorrichtung nach Anspruch 11, wobei alle die Clustermitglieder durch einen einzelnen ausschließlich zugeordneten Internet-Maschinennamen und eine einzelne ausschließlich zugeordnete IP-Adresse für den Cluster adressierbar sind; die Einrichtung zum Bestimmen eines adaptiven Intervallwerts, der ein Zeitintervall als eine Funktion eines durchschnittlichen Paketverlusts in dem Cluster darstellt, ein erster Programmcodemechanismus ist; und die Einrichtung zum Verwenden des adaptiven Intervallwerts zum Bestimmen, wann ein Clustermitglied eine nächste Am-Leben-Nachricht zu allen anderen Clustermitgliedern senden soll, wobei die Am-Leben-Nachricht zum Bestimmen eines Netzpaketverlusts verwendet wird, ein zweiter Programmcodemechanismus ist.
Vorrichtung nach Anspruch 20, ferner mit einem Paketverlustmechanismus zum Verwenden einer Folgennummer in einer derzeitigen Am-Leben-Nachricht zum Bestimmen eines derzeitigen Paketverlustwerts, der eine Anzahl von seit einem Empfang einer früheren Am-Leben-Nachricht verlorenen Paketen darstellt.
Vorrichtung nach Anspruch 21, wobei der derzeitige Paketverlustwert zum Aktualisieren einer durchschnittlichen Anzahl des Paketverlustwerts verwendet wird.
Vorrichtung nach Anspruch 22, ferner mit einem dritten Codemechanismus zum Verwenden der aktualisierten durchschnittlichen Anzahl des Paketverlustwerts zum Überprüfen des adaptiven Intervallwerts und einem Kommunikationsmechanismus zum Senden des adaptiven Intervallwerts zu allen Clustermitgliedern in einer Am-Leben-Nachricht, wodurch die Clustermitglieder den adaptiven Intervallwert zum Bestimmen, wann ihre nächste Am-Leben-Nachricht zu senden ist, verwenden können.
Vorrichtung nach Anspruch 23, ferner mit einem vierten Codemechanismus zum Verwenden einer Am-Leben-Nachricht zum Rücksetzen eines Überwachungszeitgebers, falls die Am-Leben-Nachricht empfangen wird, bevor der Überwachungszeitgeber abläuft, wobei ein Clustermitglied als nicht betriebsfähig betrachtet wird, falls der Überwachungszeitgeber abläuft.
Vorrichtung nach Anspruch 24, ferner mit einem Überwachungseinrichtungsmechanismus zur Verwendung durch jedes Clustermitglied zum Erkennen, daß ein Clustermitglied nicht betriebsfähig geworden ist, um eine Aufgabe, ein Master-Clustermitglied zu sein, unmittelbar neu zuzuweisen, falls es ein Master-Clustermitglied ist, das nicht betriebsfähig ist, wobei das Master-Clustermitglied Arbeit neu zuweist, die dem ausgefallenen Clustermitglied zugewiesen wurde, wodurch die Last bei verbleibenden Clustermitgliedern wieder ausgeglichen wird.