[go: up one dir, main page]

WO2000031639A1 - Überwachungs-komponente eines rechnersystems - Google Patents

Überwachungs-komponente eines rechnersystems Download PDF

Info

Publication number
WO2000031639A1
WO2000031639A1 PCT/EP1999/009055 EP9909055W WO0031639A1 WO 2000031639 A1 WO2000031639 A1 WO 2000031639A1 EP 9909055 W EP9909055 W EP 9909055W WO 0031639 A1 WO0031639 A1 WO 0031639A1
Authority
WO
WIPO (PCT)
Prior art keywords
applications
aem
availability
component
compliant
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/EP1999/009055
Other languages
English (en)
French (fr)
Inventor
Markus Lautenbacher
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
Siemens Corp
Original Assignee
Siemens AG
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, Siemens Corp filed Critical Siemens AG
Priority to EP99959313A priority Critical patent/EP1133729A1/de
Publication of WO2000031639A1 publication Critical patent/WO2000031639A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis

Definitions

  • Tele k ommunikationsdienste eg service nodes
  • Mission Critical Applications eg transactions in the financial sector
  • multimedia, interactive quasi-real-time network services it is necessary that the combination of computer platform (hardware, operating & Network Transport System [2] and network) and the applications running on it, i.e. a data processing system as a whole, offers particularly high availability.
  • the invention has for its object to overcome the disadvantages mentioned.
  • Availability Enhancing Middleware AEM offers a highly available service infrastructure as is necessary in areas such as telecommunications, finance, or interactive multimedia network services.
  • the AEM [3] shows the principle of how the AEM [3] fits into a computer system between the computer platform (Standard Operating & Network Transport System [2], network and hardware [1]) and the applications [4].
  • the A EM [3] is a pure software solution that is introduced into the computer as a new middleware layer between the standard operating & network transport system [2] including hardware [1] and the applications [4].
  • the middleware layer approach for the software implementation of the AEM allows the AEM to be made an inherent part of a newly developed computer system, but also enables retrofitting into an existing computer system.
  • Corresponding communication channels (denoted by (1) - (7) in FIGS. 2 and 3) effectively push the AEM between the normally direct communication of components [1], [2] and [4] in FIG. 1.
  • the AEM [3] controls the interaction (interaction) of applications [4] with the Operating & Network Transport System [2], network and hardware [1], and corrects any actions of the applications [4] with the aim of increasing the availability of the entire computer system (hardware, network, operating system, applications).
  • the AEM is able to integrate already existing applications (so-called non-AEM-compliant applications) (especially those existing applications that are only available in binary form) and on the other hand it has its own application programming interface (API) for special applications tailored the benefits of the AEM approach
  • AEM-compliant applications are available to offer these applications optimal access to the possibilities of the AEM.
  • FIG. 2 schematically shows an embodiment of the AEM middleware approach from FIG. 1 to increase the availability of data processing systems.
  • AEM architecture elements are designated with [ l ] - [5], communication connections between these elements with (l) - (7).
  • Network Transport System [2], AEM [3], several AEM-compliant [4a] and several non-AEM-compliant applications [4b]) are carried out as follows:
  • AEM-compliant applications [4a] communicate (1) via an open API provided by AEM [3a].
  • the API mediates (2) as an interface between the AEM-compliant applications [4a] and the corresponding subsystem [3b] of the AEM [3].
  • the AEM as a whole [3] checks and evaluates the incoming from the AEM-compliant application [4a]
  • Transport systems [3] are again monitored in the associated AEM subsystem [3b] and passed on to the AEM-compliant application [4a] (6). If the AEM [3] detects conflicts or problems, this is also signaled back to the AEM-compliant application [4a] (6).
  • AEM-compliant applications cover the handling of such feedback internally via the software standard technology of a so-called "event dealer” and delay then, for example, a memory request corresponding to the availability are of the overall system [5], this allows again.
  • AEM [4b] Applications that do not conform to AEM [4b] do not use the detour via AEM [3], but instead access (4) the resources of the Operating & Network Transport System [2].
  • the corresponding AEM subsystem [3c] monitors these system calls (e.g. through the "trace” system routine of the UNIX operating system) and the system messages generated thereby (5).
  • Analogous to the AEM-compliant applications [4a] the information obtained in this way about the non-AEM-compliant applications [4b] is considered by AEM [3] with regard to possible conflicts with other applications and compatibility with the availability of the overall system [5]. checked as a whole. If the AEM [3] detects corresponding problems, an attempt is made to eliminate them by stopping or terminating (e.g. UNIX signal "STOP" or "KILL”) of the corresponding non-AEM-compliant application [4b] (7).
  • terminating e.g. UNIX signal "STOP" or "KILL
  • FIGS. 1 and 2 show a detailed based on FIGS. 1 and 2
  • FIG. 3 also executes the AEM API [3a], the internal architecture of the AEM subsystems [3b] and [3c] and the associated AEM internal communication (il) - (i4).
  • the AEM API [3a] offers an interface that is secured with regard to overall availability for requesting so-called passive objects (PO), file access, memory handling, network communication, etc.
  • PO passive objects
  • the API offers corresponding so-called "stubs" object-oriented programming.
  • the interfaces are standard O perating system services such as FTP, TELNET, ... implemented as passive objects within the AEM [3]).
  • the A EM [3] holds information about the current state of the overall system [5] in the following central units:
  • This unit manages the runtime environment of the PO. All AEM-compliant applications are built from PO individual components using object-oriented methods.
  • This unit has the task of being networked
  • Security management Data and program code of different applications within the overall system should be kept separate from one another and attacks should be prevented.
  • the security management unit takes on this task.
  • This unit is a database in which persistent and temporary system-relevant information is kept; this includes information about the current system configuration with regard to hardware and software, the maximum values of the available system resources, and the resource profiles that are permitted
  • Resource management Define resource requirements per application, as well as the current system information about active applications.
  • This unit is responsible for managing local resources.
  • Resource management includes the detection of resource misuse by individual applications and the optimization of competing resource requirements by different applications.
  • the monitored resources include in particular CPU, memory, hard disk allocation, network connections.
  • This status information is updated via the exchange (2), which takes place via the AEM API [3a] via (1) with the AEM-compliant applications [4a], and internally (il) via the monitor unit.
  • the monitor acts as a central collection and
  • the monitor (3) communicates with the Operating & Network Transport System [2] of the AEM subsystem [3b] responsible for AEM-compliant applications [4a]. The monitor can therefore forward the AEM-compliant applications [4a] regarding the system status to the above-mentioned central units.
  • the monitor also receives indirect (i2) status information via the sensor unit, which is located in the AEM subsystem [3c] responsible for non-AEM-compliant applications [4b]. The monitor also forwards this status information to the above-mentioned central units.
  • the sensor monitors system calls (eg through the "trace” system routine of the UNIX operating system) and system messages (5) generated thereby, which are generated by non-AEM-compliant applications [4b] with direct access (4) to the resources of the Operating & Network Transport System [2] can be generated.
  • Deviates the detected in the monitor actual value of G eticianstatus from an adjustable set-profile eg respect. The number of active applications, machine load, memory usage, error rate, network status), so passes (i3) of the monitor the
  • the decision maker unit analyzes the conflict between actual and target value displayed by the monitor with regard to the system availability and makes a decision based on suitable, adjustable criteria (e.g. through rule- or case-based programming) to resolve the conflict, the system status and thus to bring the availability of the overall system [5] back into the permissible range.
  • suitable, adjustable criteria e.g. through rule- or case-based programming
  • the decision maker then informs (i4) the so-called "decision enforcement” unit of the decision made to ensure the availability of the
  • the task of the decision enforcement unit is to implement this countermeasure against the applications concerned. For this purpose, a corresponding message is sent to the application identified as the cause of the limited availability.
  • a corresponding message is sent to the application identified as the cause of the limited availability.
  • non-AEM-compliant applications [4b] direct (7) as a system signal
  • AEM-compliant applications [4a] indirectly (6) as AEM API message.
  • this unit must be equipped with appropriate system priorities (eg belonging to the UNIX owner "root” and with a sufficiently high process / task priority, which in turn can be set using the "nice" UNIX system command.).
  • An AEM-compliant application [4a] requests (1,2) more real memory (RAM) via the AEM API [3a].
  • the AEM [3] concludes that this would impair the availability of the overall system to an unacceptable extent and rejects the request with an appropriate AEM API response (6).
  • the AEM-compliant application [4a] responds to this feedback with its event handler by using the slower virtual memory (in UNIX terminology "swap space") instead of the fast real memory (RAM) (after this has been previously approved by the AEM or may already have been proposed as part of the first AEM feedback (6) as an alternative).
  • a non-AEM-compliant application [4b] bypasses the AEM [3] by using a direct system call and threatens to jeopardize the availability of the overall system [5] with regard to the availability of network resources (network connectivity) because at the same time all other applications also require network services.
  • the AEM [3] recognizes this conflict in its resource management and the risk that the requirements may escalate due to a certain non-AEM-compliant application [4b] at the expense of the other applications [4a, b].
  • the problematic, non-AEM-compliant application [4b] is therefore temporarily stopped via the decision maker and decision enforcement units (eg via the UNIX system signal "STOP") until the permissible requests for network resources by the other applications result in such a maximum occupancy by an individual Allow application.
  • the availability are of the overall system in an unacceptable extent b eeintr thesisen would not, thus remains as a single agent before its final termination only a temporary stop as an alternative measure to the Ensure system availability.
  • AEM-compliant applications or AEM-compliant interactions of an application can react more optimally in such cases via their event handler (eg with reduced requirements for network resources).
  • the optimal two-way communication (1,2,6) between AEM [3] and AEM-compliant applications [4a] can be used to avoid radical measures such as the temporary stopping necessary for non-AEM-compliant applications [4b] or even the final termination . Stopping or scheduling to ensure system availability are only used for AEM-compliant applications [4a] if the treatment via the event handler does not produce a sufficient result.
  • the AEM subsystem [3c] can of course also monitor the above-mentioned interaction of AEM-compliant applications for the use of non-AEM-compliant methods and system calls, or monitor the aforementioned interaction of those applications that have been programmed, for example, with the aid of an older version of the AEM-API and now (ie if you look at applications programmed for comparison via a new API) are only partially AEM-compliant.
  • the invention has the following features / advantages for ensuring high availability in data processing systems:

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Für bestimmte Anwendungen, z.B. für Telekommunikationsdienste, ist es erforderlich, dass dazu notwendige Rechnersysteme in ihrer Gesamtheit, d.h. in der Kombination aus Rechnerplattform und darauf laufenden Applikationen, eine besonders hohe Verfügbarkeit bieten. Die Erfindung löst dieses Problem durch eine Überwachungs-Komponente, die sw-schichtmässig zwischen Applikationen und Rechnerplattform eingefügt ist.

Description

Beschreibung
Überwachungs-Komponente eines Rechnersystems
In Datenverarbeitungsanlagen (Rechnersystemen) für
Telekommunikationsdienste (z.B. Service Nodes) , für sog. Mission Critical Applications (z.B. Transaktionen im Finanzbereich) oder für multimediale, interaktive quasi- Echtzeit Netzwerkdienste ist es erforderlich, daß die Kombination aus Rechnerplattform (Hardware, Operating & Network Transport System [2] und Netzwerk) und darauf laufenden Applikationen, also einer Datenverarbeitungsanlage als Ganzes, eine besonderes hohe Verfügbarkeit bietet.
Dabei soll die Verfügbarkeit gewährleistet sein gegen Probleme wie
• Hardware Ausfälle
• Interne Softwarefehler in Applikationen (Endlos-Schleifen, Speicherlecks, unsaubere Dateizugriffe,...), die zu einem Performance-Verlust des Gesamtsystems führen
• Externe, fehlerhafte Ereignisse (unterbrochene Netzwerkverbindungen, Verbindungsüberlastung, ... )
• Ressourcenkonflikte zwischen den einzelnen (u.U. von verschiedenen Benutzern eingebrachten) Applikationen, die gleichzeitig auf einem System ablaufen
• Performance-Verlust des Gesamtsystems (bis zum Denial-of- Service) wegen Überlastung durch die Gesamtheit der momentan aktiven Applikationen
In bisherigen Lösungen werden die genannten Probleme durch Einsatz von hoch spezieller Hard- u. Software gelöst. Bekannte Ansätze sind z.B. die Dopplung von Hardware und die Spiegelung von Daten im Parallelbetrieb oder im Hot/Cold- Stand-By.
Die Nachteile solcher Ansätze sind • eine doppelte Bereitstellung und Wartung von IT- Infrastruktur (Hard- und Software)
• inflexible Kombination von Spezialhardware mit hoch speziellen, proprietären Betriebssystemen • die dadurch erzwungene Verwendung von ebenfalls extrem plattformgebundenen, nicht portierbaren Applikationen und die Bindung an deren Hersteller
• die mangelnde Interoperabilität zu allgemein verfügbaren ( off-the-shelf") Hard- u. Softwarekomponenten aufgrund fehlender quasi-standard Interfaces
Insgesamt führen o.g. Nachteile zu einer extrem unbefriedigenden Wirtschaftlichkeit herkömmlicher, hochverfügbarer Systeme. Gleichzeitig lassen sich derartige Systeme nur sehr schwer an den rasanten technologischen Fortschritt im IT-Bereich anpassen.
Der Erfindung liegt die Aufgabe zugrunde, die genannten Nachteile zu überwinden.
Diese Aufgabe wird durch die Erfindung gelöst.
Im folgenden wird die Erfindung anhand der Zeichnung näher beschrieben, wobei die Zeichnung drei Figuren umfaßt.
Die im folgenden beschriebene Überwachungs-Komponente (Availability Enhancing Middleware AEM) bietet eine hochverfügbare Service Infrastruktur wie sie in Bereichen wie der Telekommunikation, im Finanzbereich, oder bei interaktiven Multimedia Netzdiensten notwendig ist.
Fig. 1 zeigt das Prinzip wie sich die AEM [3] in ein Rechnersystem zwischen die Rechnerplattform (Standard Operating & Network Transport System [2], Netzwerk und Hardware [1]) und die Applikationen [4] einfügt. Die AEM [3] stellt eine reine Softwarelösung dar, die als neuer Middleware Layer zwischen das Standard Operating & Network Transport System [2] inklusive Hardware [1] und die Applikationen [4] in den Rechner eingebracht wird. Der Middleware-Layer Ansatz für die softwaretechnische Realisierung der AEM erlaubt dabei, die AEM zu einem inhärenten Teil eines neu entwickelten Rechnersystems zu machen, ermöglicht gleichzeitig aber auch die Nachrüstung in ein existierendes Rechnersystem. Durch entsprechende Kommunikationskanäle (bezeichnet mit (l)-(7) in Fig. 2 und 3) schiebt sich die AEM quasi zwischen die normalerweise direkte Kommunikation der Komponenten [1], [2] und [4] in Fig. 1. Die AEM[3] kontrolliert dabei die Wechselwirkung (Interaktion) von Applikationen [4] mit Operating & Network Transport System [2], Netzwerk und Hardware [1], und korrigiert ggf. Aktionen der Applikationen [4] mit der Zielsetzung, eine erhöhte Verfügbarkeit des gesamten Rechnersystems (Hardware, Netzwerk, Operating System, Applikationen) zu gewährleisten.
Die AEM ist zum einen in der Lage bereits existierende Applikationen (sog. nicht AEM-konforme Applikationen) zu integrieren (vor allem solche existierende Applikationen, die nur in Binärform vorliegen) und stellt zum anderen ein eigenes Application Programming Interface (API) für speziell auf die Vorteile des AEM-Ansatzes zugeschnittene
Applikationen (sog. AEM-konforme Applikationen) zur Verfügung, um diesen Applikationen optimalen Zugriff auf die Möglichkeiten des AEM zu bieten.
Ein besonderer Vorteil der Erfindung besteht in der
Erreichung der erhöhten Verfügbarkeit durch einen Middleware- Ansatz auf Standard Hard- und Software unter Verwendung von offenen IT-Standards. Der bisherige Ansatz einer erhöhten Verfügbarkeit für Applikationen durch eine enge Integration von spezieller Hard- und Software wird ersetzt durch die Verlagerung dieser Funktionalität in eine intelligente Softwarezwischenschicht . Fig. 2 zeigt schematisch ein Ausführungsbeispiel des AEM Middleware Ansatzes aus Fig. 1 zur Erhöhung der Verfügbarkeit von Datenverarbeitungsanlagen. AEM-Architekturelemente sind mit [l]-[5] bezeichnet, Kommunikationsverbindungen zwischen diesen Elementen mit (l)-(7).
Die Behandlung von AEM-konformen [4a] und nicht AEM-konformen Applikationen [4b] zur Erhöhung der Verfügbarkeit des Gesamtsystems [5] (bestehend aus Hardware [1], Operating &
Network Transport System [2], AEM [3], mehreren AEM-konformen [4a] und mehreren nicht AEM-konformen Applikationen [4b]) erfolgt dabei folgendermaßen:
AEM-konforme Applikationen [4a] kommunizieren (1) über ein von der AEM zur Verfügung gestelltes, offenes API [3a] . Das API vermittelt (2) dabei als Schnittstelle zwischen den AEM- konformen Applikationen [4a] dem entsprechenden Subsystem [3b] des AEM [3] . Die AEM als Ganzes [3] prüft und bewertet den von der AEM-konformen Applikation [4a] eingehenden
Informationsstrom (Status- und Fehlermeldungen, Ressource- Anforderungen an Operating & Network Transport System [2], Zugriffe auf Dateisystem und Devices,...) auf Konsistenz, auf mögliche Konflikte mit anderen Applikationen und auf die Verträglichkeit mit der Verfügbarkeit des Gesamtsystems [5] .
Nach erfolgreicher Prüfung in der AEM [3] wird der Informationsstrom der AEM-konformen Applikation [4a] an das Operating & Network Transport System [2] weitergegeben (3) . Eventuelle Rückmeldungen (3) des Operating & Network
Transport Systems [3] werden wieder im zugehörigen AEM Subsystem [3b] überwacht und an die AEM-konforme Applikation [4a] weitergeben (6) . Entdeckt die AEM [3] Konflikte oder Probleme so wird dies ebenfalls der AEM-konformen Applikation [4a] zurücksignalisiert (6) . AEM-konforme Applikationen decken die Behandlung solcher Rückmeldungen intern über die Software Standardtechnik eines sog. "Event Händlers" ab und verzögern dann z.B. eine Speicheranforderung entsprechend bis die Verfügbarkeit des Gesamtsystems [5] dies wieder zuläßt.
Nicht AEM- onforme Applikationen [4b] benutzten nicht den Umweg über die AEM [3], sondern greifen (4) direkt auf die Ressourcen des Operating & Network Transport System [2] zu. Das entsprechende Subsystem der AEM [3c] überwacht diese Systemaufrufe (z.B. durch die "trace" Systemroutine des UNIX Operating Systems) und dadurch erzeugte Systemmeldungen (5) . Analog zu den AEM-konformen Applikationen [4a] wird die so über die nicht AEM-konformen Applikationen [4b] gewonnene Information im Hinblick auf mögliche Konflikte mit anderen Applikationen und die Verträglichkeit mit der Verfügbarkeit des Gesamtsystems [5] von der AEM [3] als Ganzes geprüft. Erkennt die AEM [3] entsprechende Probleme, so wird versucht, diese durch Anhalten bzw. Terminieren (z.B. UNIX Signal "STOP" bzw. "KILL") der entsprechenden nicht AEM-konformen Applikation [4b] zu beseitigen (7) .
Fig. 3 zeigt basierend auf Fig. 1 und 2 eine detaillierte
Architektur für ein Ausführungsbeispiel des AEM-Ansatzes zur Erhöhung der Verfügbarkeit von Datenverarbeitungsanlagen.
Die Funktionsweise der Architekturelemente [l]-[5] und der AEM-Kommunikation (l)-(7) aus Fig. 2 wird unverändert übernommen. Fig. 3 führt zusätzlich das AEM API [3a], die interne Architektur der AEM Subsysteme [3b] und [3c] und die zugehörige AEM-interne Kommunikation (il)-(i4) weiter aus.
Das AEM API [3a] bietet für AEM-konforme Applikationen [4a] eine hinsichtlich Gesamtverfügbarkeit abgesicherte Schnittstelle zur Anforderung von sog. Passiven Objekten (PO) , Dateizugriffen, Speicherbehandlung, Network Communication, etc. Das API bietet entsprechende sog. "Stubs" aus der objektorientierten Programmierung an. Im Sinne der Objektorientierung sind die Schnittstellen zu Standard Operating System Services wie z.B. FTP, TELNET,... als Passive Objekte innerhalb der AEM [3] realisiert) .
Die AEM [3] hält Informationen über den momentanen Zustand des Gesamtsystems [5] in folgenden Zentraleinheiten:
Passive Objekte (PO) Management:
Diese Einheit verwaltet die Laufzeitumgebung der PO. Alle AEM-konformen Applikationen sind nach objektorientierten Methoden aus PO Einzelbausteinen aufgebaut.
Distribution Component:
Diese Einheit hat die Aufgabe, im Falle eines vernetzten
Verbunds von nach dem AEM-Ansatz arbeitenden Datenverarbeitungsanlagen, die Ressourcen innerhalb dieses Verbunds nach einstellbaren Kriterien auszunutzen (z.B. gleichmäßige Lastverteilung auf alle Maschinen) und so einzelne Maschinen vor Ausfall durch lokale Überlastung zu schützen. Dazu werden z.B. PO zwischen den verschiedenen Datenverarbeitungsanlagen migriert oder entsprechende
Anforderungen von lokalen POs zu entsprechenden POs auf andere Datenverarbeitungsanlagen im Netzwerk delegiert.
Security Management: Daten und Programm-Code unterschiedlicher Applikationen innerhalb des Gesamtsystems sollen voneinander getrennt gehalten und Übergriffe verhindert werden. Diese Aufgabe übernimmt die Security Management Einheit.
Information Base:
Diese Einheit ist eine Datenbank in der persistente und temporäre systemrelevante Informationen gehalten werden; dazu zählen Informationen über die momentane Systemkonfiguration bzgl. Hard- und Software, die Maximalwerte der verfügbaren Systemressourcen, Ressource-Profiles die zulässigen
Ressource-Anforderungen per Applikation festlegen, sowie die aktuelle Systeminformation über aktive Applikationen. Resource Management:
Diese Einheit hat die Aufgabe der Verwaltung lokaler Ressourcen. Das Resource Management beinhaltet die Aufdeckung von Ressource-Mißbrauch durch einzelne Applikationen und die Optimierung konkurrierender Ressource-Anforderungen durch unterschiedliche Applikationen. Zu den überwachten Ressourcen zählen insbesondere CPU, Speicher, Festplattenbelegung, Netzwerkverbindungen (network connections) .
Die Aktualisierung dieser Zustandsinformation erfolgt über den Austausch (2), der über das AEM API [3a] via (1) mit den AEM-konformen Applikationen [4a] erfolgt, sowie intern (il) über die Monitor Einheit.
Der Monitor wirkt als zentrale Sammel- und
Überwachungseinheit der Informationen zum Gesamtsystemstatus sowie als eine Art Bussystem für den Informationsfluß innerhalb des AEM Subsystems [3b] . Über den Monitor wird erstens die Kommunikation (3) des für AEM-konforme Applikationen [4a] zuständigen AEM Subsystems [3b] mit dem Operating & Network Transport System [2] abgewickelt. Daher kann der Monitor die AEM-konforme Applikationen [4a] betreffenden Informationen zum Systemzustand an o.g. Zentraleinheiten weiterleiten. Der Monitor erhält zweitens auch indirekt (i2) Zustandsinformation über die Sensor Einheit, die sich im für nicht AEM-konforme Applikationen [4b] zuständigen AEM Subsystem [3c] befindet. Auch diese Zustandsinformationen leitet der Monitor an o.g. Zentraleinheiten weiter. Der Sensor überwacht Systemaufrufe (z.B. durch die "trace" Systemroutine des UNIX Operating Systems) und dadurch erzeugte Systemmeldungen (5) , die durch nicht AEM-konforme Applikationen [4b] bei direkten Zugriff (4) auf die Ressourcen des Operating & Network Transport System [2] erzeugt werden. Weicht der im Monitor ermittelte Ist-Wert des Gesamtsystemstatus von einem einstellbaren Soll-Profil (z.B. bzgl. der Anzahl der aktiven Applikationen, Maschinenauslastung, Speicherbelegung, Fehlerhäufigkeit, Netzwerkstatus, ) ab, so übergibt (i3) der Monitor den
Ist-Gesamtsystemstatus an die sog. "Decision Maker" Einheit zur weiteren Behandlung der Abweichung.
Die Decision Maker Einheit analysiert den vom Monitor angezeigten Konflikt zwischen Ist- und Soll-Wert im Hinblick auf die Systemverfügbarkeit und trifft nach geeigneten, einstellbaren Kriterien (z.B. durch regel- oder fallbasierte Programmierung) eine Entscheidung zur Lösung des Konflikts, um den Systemstatus und damit die Verfügbarkeit des Gesamtsystem [5] wieder in den zulässigen Bereich zu überführen.
Der Decision Maker informiert (i4) daraufhin die sog. "Decision Enforcement" Einheit über die getroffene Entscheidung zur Sicherstellung der Verfügbarkeit des
Gesamtsystems [5] . Aufgabe der Decision Enforcement Einheit ist es, diese Gegenmaßnahme gegenüber den betroffenen Applikationen zu realisieren. Dazu wird eine entsprechende Meldung an die als Verursacher für die eingeschränkte Verfügbarkeit ausgemachte Applikation geschickt. Bei nicht AEM-konformen Applikationen [4b] direkt (7) als System Signal, bei AEM-konformen Applikationen [4a] indirekt (6) als AEM API Meldung.
Damit eine Applikation auf eine entsprechende Meldung der
Decision Enforcement Einheit ausreichend reagiert, muß diese Einheit mit entsprechenden Systemprioritäten ausgestattet sein (z.B. dem UNIX owner "root" zugehörig und mit ausreichend hoher Process/Task Priorität, die wiederum über das "nice" UNIX Systemkommando einstellbar ist.). Fallbeispiele:
AEM-konforme Applikation:
Eine AEM-konforme Applikation [4a] fordert (1,2) über das AEM API [3a] mehr realen Speicher (RAM) an. Die AEM [3] kommt zu dem Schluß, daß dies die Verfügbarkeit des Gesamtsystems in nicht vertretbarem Rahmen beeinträchtigen würde und weist die Anforderung durch eine entsprechende AEM API Rückmeldung (6) ab. Die AEM-konforme Applikation [4a] reagiert mit ihrem Event Handler auf diese Rückmeldung, indem sie statt dem schnellen realen Speicher (RAM) , den langsameren virtuellen Speicher (in UNIX Terminologie "Swap Space") benutzt (nachdem dies vorher von der AEM genehmigt bzw. u.U. bereits als Teil der ersten AEM Rückmeldung (6) als Alternative vorgeschlagen wurde) .
Nicht AEM-konforme Applikation:
Eine nicht AEM-konforme Applikation [4b] belegt an der AEM [3] vorbei über direkten Systemaufruf erhebliche Netzwerk- Ressourcen und droht die Verfügbarkeit des Gesamtsystems [5] bzgl. der Verfügbarkeit von Netzwerk-Ressourcen (Network Connectivity) zu gefährden, da gleichzeitig alle anderen Applikationen auch Netzwerkdienste benötigen. Die AEM [3] erkennt in ihrem Ressourcen Management diesen Konflikt und die Gefahr eines Eskalierens der Anforderungen durch eine bestimmte nicht AEM-konforme Applikation [4b] zu Lasten der übrigen Applikationen [4a,b] . Über die Decision Maker und Decision Enforcement Einheiten wird daher die problematische nicht AEM-konforme Applikation [4b] temporär angehalten (z.B. über das UNIX System Signal "STOP") bis die zulässigen Anforderungen nach Netzwerkressourcen durch die übrigen Applikationen eine derart maximale Belegung durch eine einzelne Applikation erlauben. Bei einer nicht AEM-konformen Applikation bzw. einer nicht AEM-konformen Interaktion einer Applikation, die die Verfügbarkeit des Gesamtsystems in nicht vertretbarem Maße beeinträchtigen würden, bleibt somit als einziges Mittel vor ihrer endgültigen Terminierung nur ein temporäres Anhalten als Alternativmaßnahme, um die Systemverfügbarkeit sicherzustellen. AEM-konforme Applikationen bzw AEM-konforme Interaktionen einer Applikation können dagegen in solchen Fällen über ihren Event Handler optimaler reagieren (z.B. mit reduzierten Anforderungen nach Netzwerk-Ressourcen) . Durch die optimale wechselseitige Kommunikation (1,2,6) zwischen AEM [3] und AEM-konformen Applikationen [4a] lassen sich derart radikale Maßnahmen wie das für nicht AEM-konforme Applikationen [4b] notwendige temporäre Anhalten oder gar die endgültige Terminierung umgehen. Anhalten bzw. Terminierung zur Gewährleistung der Systemverfügbarkeit kommen für AEM- konforme Applikationen [4a] erst zum Einsatz, wenn die Behandlung über den Event Handler kein ausreichendes Ergebnis erbringt .
Das AEM Subsystem [3c] kann selbstverständlich auch die genannte Interaktion AEM-konformer Applikationen zusätzlich auf die Verwendung nicht AEM-konformer Methoden und Systemaufrufe hin überwachen oder die genannte Interaktion solcher Applikationen überwachen, die z.B unter Zuhilfenahme einer älteren Version des AEM-API programmiert wurden und nunmehr (d.h. wenn man über ein neues API programmierte Applikationen zum Vergleich betrachtet) nur noch zum Teil AEM-konform sind.
Abschließend zusammengefaßt weist die Erfindung zur Sicherung der Hochverfügbarkeit in Datenverarbeitungsanlagen folgende Merkmale/Vorteile auf:
• basierend auf allgemein verfügbarer, infolge
Massenproduktion sehr preiswerter ("off-the-shelf") Hard- und Software, Verwendung von de-facto Standards im Bereich Hard- und Software (soweit als möglich),
• Portierbarkeit, d.h. keine konzeptionelle Bindung an eine bestimmte Hard- oder Softwareplattform,
• Wegfall des Konzepts der "Verfügbarkeit durch Redundanz", d.h. z.B. der Hardware-Dopplung, Daten-Spiegelung,
• leichte Integration in existierende Systeme unter Verwendung bereits vorhandener Applikationen, d.h. Wiederverwendung der sog. "Installed Base".
Abkürzungen:
AEM Availability Enhancing Middleware API Application Programming Interface IT Informationstechnik

Claims

Patentansprüche
1. Überwachungs-Komponente eines Rechnersystems, die Interaktionen von Applikationen [4] mit der Rechnerplattform überwacht und die Abwehrmaßnahmen ergreift, wenn durch eine Interaktion die Verfügbarkeit des gesamten Rechnersystems beeinträchtigt wird bzw. würde.
2. Überwachungs-Komponente nach Anspruch 1, gekennzeichnet durch ein Application Programming Interface (API), über das Applikationen mit der Rechnerplattform interagieren können.
3. Überwachungs-Komponente nach Anspruch 1 oder 2, gekennzeichnet durch einen Sensor, der die Interaktion von Applikationen [4] mit dem System aufnimmt, indem er Systemaufrufe von Applikationen und/oder dadurch erzeugte Systemmeldungen (5) aufnimmt.
4. Überwachungs-Komponente nach Anspruch 1, dadurch gekennzeichnet, daß die Überwachungs-Komponente die Eigenschaft einer Middleware
Layer Komponente zwischen Rechnerplattform und Applikationen
[4] aufweist.
5. Überwachungs-Komponente nach einem der Ansprüche 1 bis 4, gekennzeichnet durch
- mindestens eine Zustandsspeicher-Komponente, die Informationen über den momentanen Zustand des Gesamtsystems speichert,
- eine Monitor-Komponente, die aus einer Interaktion Zustandsänderungsinformationen gewinnt, diese der mindestens einen Zustandsspeicher-Komponente zur Aktualisierung mitteilt, und anhand der in der mindestens einen Zustandsspeicher-Komponente gespeicherten
Zustandsinformationen den Gesamtsystemzustand ermittelt, - eine Entscheidungs-Komponente, die den Gesamtsystemzustand analysiert und entscheidet, ob und wenn ja, welche Maßnahmen zur Aufrechterhaltung der Verfügbarkeit ergriffen werden.
6. Verfahren zur Steigerung der Verfügbarkeit eines Rechnersystems, demgemäß
Interaktionen von Applikationen [4] mit der Rechnerplattform überwacht und Abwehrmaßnahmen ergriffent werden, wenn durch eine Interaktion die Verfügbarkeit des gesamten Rechnersystems beeinträchtigt wird bzw. würde.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet , daß Interaktionen von Applikationen mit der Rechnerplattform über ein Application Programming Interface (API) abgewickelt werden.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, daß
Interaktionen von Applikationen [4 ] mit der Rechnerplattform aufgenommen werden, indem Systemaufrufe von Applikationen und/oder dadurch erzeugte Systemmeldungen (5) überwacht werden.
PCT/EP1999/009055 1998-11-24 1999-11-23 Überwachungs-komponente eines rechnersystems Ceased WO2000031639A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP99959313A EP1133729A1 (de) 1998-11-24 1999-11-23 Überwachungs-komponente eines rechnersystems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP98122303.5 1998-11-24
EP98122303 1998-11-24

Publications (1)

Publication Number Publication Date
WO2000031639A1 true WO2000031639A1 (de) 2000-06-02

Family

ID=8233027

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1999/009055 Ceased WO2000031639A1 (de) 1998-11-24 1999-11-23 Überwachungs-komponente eines rechnersystems

Country Status (3)

Country Link
EP (1) EP1133729A1 (de)
CN (1) CN1328667A (de)
WO (1) WO2000031639A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010116441A1 (ja) * 2009-03-30 2010-10-14 富士通株式会社 無線電力供給システム、無線送電装置、および無線受電装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101221615B (zh) * 2008-02-05 2011-08-17 北京飞天诚信科技有限公司 监测目标软件的方法和智能密钥装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996032675A1 (en) * 1995-04-11 1996-10-17 Talati Kirit K Automated enforcement of behavior in application program
EP0827077A1 (de) * 1996-07-01 1998-03-04 Sun Microsystems, Inc. Objektorientiertes System, Verfahren und hergestellter Gegenstand für einen Klient-Server-Prozess zur Fehlerprotokollierung

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996032675A1 (en) * 1995-04-11 1996-10-17 Talati Kirit K Automated enforcement of behavior in application program
EP0827077A1 (de) * 1996-07-01 1998-03-04 Sun Microsystems, Inc. Objektorientiertes System, Verfahren und hergestellter Gegenstand für einen Klient-Server-Prozess zur Fehlerprotokollierung

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010116441A1 (ja) * 2009-03-30 2010-10-14 富士通株式会社 無線電力供給システム、無線送電装置、および無線受電装置

Also Published As

Publication number Publication date
EP1133729A1 (de) 2001-09-19
CN1328667A (zh) 2001-12-26

Similar Documents

Publication Publication Date Title
DE69614383T2 (de) Kontinuierlich verfügbarer datenbankserver mit mehreren knotengruppen mit sich minimal überschneidenden sätzen von datenbankteilkopien
DE69032673T2 (de) Verfahren und Vorrichtung zur dynamischen Verwaltung der Eingabe-/Ausgabeverbindungsmöglichkteiten
DE60220418T2 (de) Verfahren und Anbieter zur Systemsynchronisation
DE69623229T2 (de) Bindungsverfahren in einer Transaktion in einer verteilten Datenbank
DE60207251T2 (de) Verfahren zur sicherstellung des betriebs eines gruppierten nachrichtenvergebenden servers während knotenausfällen und netzwerkzuteilungen
DE60318468T2 (de) Verfahren zur lösung von entscheidungslosigkeiten in einem cluster-rechnersystem
DE10321454B4 (de) System und Verfahren zur Leistungsverwaltung in einem Computersystem mit mehreren Stromversorgungsnetzen
DE2740056A1 (de) Mulitprozessor-rechnersystem
DE2908316A1 (de) Multikonfigurierbares modulares verarbeitungssystem, das mit einem vorverarbeitungssystem integriert ist
DE112011102242T5 (de) Vorrichtung zum Verarbeiten einer Stapelarbeitseinheit
EP0959588A2 (de) Netzelement mit einer Steuerungseinrichtung und Steuerungsverfahren
DE112011103443T5 (de) Intelligente Schnittstelle für ein dezentrales Steuerungssystem
DE112010004530T5 (de) Transaktionsaktualisierung bei Dynamischen Verteilten Arbeitslasten
DE102016219854A1 (de) Computersystem und Verfahren zum dynamischen Anpassen eines software-definierten Netzwerks
DE4429969A1 (de) Verfahren für einen Programmpaketeaustausch in einem Mehrrechnersystem und Rechner dafür
DE102009004726A1 (de) Systeme und Verfahren zum Verfolgen von Befehlszeigern und Datenzugriffen
DE69617709T2 (de) Steuerung von gemeinsamen plattendaten in einer duplex-rechnereinheit
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
DE102007005207A1 (de) Software-Duplikation
EP0433350A1 (de) Betriebsprogramm für eine datenverarbeitungsanlage
WO2000031639A1 (de) Überwachungs-komponente eines rechnersystems
DE69615460T2 (de) Verfahren und Vorrichtung zur Zuteilung von Transaktionsidentifikatoren
EP1536328B1 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
EP0850545A1 (de) Ablaufumgebungssystem für service-applikationen eines kommunikationsnetzes
DE69800095T2 (de) Schnelles Semaphoreregister mit einer sicheren Arbeitsweise ohne spezifisches Busprotokoll

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99813681.6

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): BR CN ID US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 1999959313

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09856629

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1999959313

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999959313

Country of ref document: EP