DE102006018232A1 - Dienstqualität in IT-Infrastrukturen - Google Patents

Dienstqualität in IT-Infrastrukturen Download PDF

Info

Publication number
DE102006018232A1
DE102006018232A1 DE102006018232A DE102006018232A DE102006018232A1 DE 102006018232 A1 DE102006018232 A1 DE 102006018232A1 DE 102006018232 A DE102006018232 A DE 102006018232A DE 102006018232 A DE102006018232 A DE 102006018232A DE 102006018232 A1 DE102006018232 A1 DE 102006018232A1
Authority
DE
Germany
Prior art keywords
data
delayed
calculation
qos
service
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.)
Withdrawn
Application number
DE102006018232A
Other languages
English (en)
Inventor
Joern Schimmelpfeng
Frank Nitsch
Martin Tischhaeuser
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.)
Micro Focus LLC
Original Assignee
Hewlett Packard Development Co LP
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 Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE102006018232A1 publication Critical patent/DE102006018232A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters

Landscapes

  • Engineering & Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Ein Verfahren wird bereitgestellt zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden. Die Daten aus den Datenquellen kommen regulär in Echtzeit an, aber Daten aus einer oder mehreren Datenquellen können gelegentlich verzögert sein. Das Verfahren umfasst: Berechnen einer Echtzeitangabe der Dienstqualität in einem ersten Prozess auf der Grundlage der regulären Daten, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten Berechnen einer verzögerten, aber exakteren Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess auf der Grundlage regulärer Information, die reguläre Daten und/oder von ihnen abgeleitete Information umfasst, und der verzögerten Daten.

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich im allgemeinen auf Dienstqualität in informationstechnologischen (IT) Infrastrukturen, und z.B. auf Verfahren, Computersysteme und Computerprogramme zum Bestimmen von Dienstqualität in IT-Infrastrukturen.
  • HINTERGRUND DER ERFINDUNG
  • Da heutzutage Informationssysteme allgegenwärtig werden und Unternehmen und Organisationen aller Branchen immer mehr von ihren Rechenressourcen abhängig werden, nimmt die Anforderung an die Verfügbarkeit von Hardware- und Softwarekomponenten einer IT-Infrastruktur (im wesentlichen ein Computer- oder Telekommunikationsnetzwerk, welches Anwendungen und darauf basierende Dienste umfasst) zu, während die Komplexität von IT-Infrastrukturen wächst. Eine IT-Infrastruktur umfasst oft eine Vielfalt von Systemen, z. B. Kabel, Repeater, Switche, Router, Zugangspunkte, Arbeitsplatzrechner, Server, Speichersysteme, von denen auf einigen Betriebssysteme, Middleware und Anwendungen laufen. Das Management all dieser Systeme wird nicht nur für große Organisationen immer wichtiger, sondern auch für mittelgroße und kleine. Ein Management vernetzter Systeme umfasst all die Maßnahmen, die notwendig sind, um den effektiven und effizienten Betrieb eines Systems und seiner Ressourcen in Einklang mit Zielen einer Organisation sicherzustellen (siehe z.B. H. Hegering et al.: "Integrated Management of Network Systems", Morgan Kaufmann Publishers, 1998, pp. 83–93).
  • Man kann Netzwerke und darauf bezogene Dienste im allgemeinen von einer technischen Perspektive oder einer geschäftsorientierten Perspektive sehen, die jedoch eng miteinander verwandt sind. Die technische Perspektive bezieht sich auf die technischen Aspekte des Netzwerkmanagements, wohingegen sich die geschäftsorientierte Perspektive hauptsächlich mit Dienstgütevereinbarungen (Service Level Agreements, SLA) zwischen Netzwerkanbietern und Kunden beschäftigt (siehe z.B. J. Lee et al.: "Integrating Service Level Agreements", Wiley Publishing, Inc. 2002, pp. 325). Die Wechselbeziehung zwischen ihnen besteht darin, dass die vom Anbieter gelieferte Dienstqualität (QoS) typischerweise vom technischen Entwurf, dem Funktionieren und der Leistungsfähigkeit der darunterliegenden Infrastruktur abhängt und dass Maßnahmen der QoS, die die in einem SLA gemachten Verpflichtungen widerspiegeln, normalerweise auf technischen Netzwerkmanagementtools basieren. Solche QoS-Maßnahmen gestatten ein kontinuierliches Verfolgen des gelieferten Dienstes und Beurteilung und Überprüfung, ob die Dienstlieferung der vereinbarten Dienstgütevereinbarung entspricht.
  • Vom technischen Blickwinkel aus kann das Gebiet des Netzwerkmanagements in fünf Bereiche eingeteilt werden, die man zusammengenommen manchmal "FCAPS" nennt. Fehlermanagement, Konfigurationsmanagement, Abrechnungsmanagement, Leistungsmanagement und Sicherheitsmanagement. Das Ziel des Fehlermanagements ist es, Fehler schnell zu detektieren und korrigieren, um sicherzustellen, dass ein hohes Niveau an Verfügbarkeit eines vernetzten Systems und der Dienste, die es bereitstellt, aufrechterhalten wird, wobei Fehler als eine Abweichung von den vorgeschriebenen Betriebszielen, Systemfunktionen oder Diensten definiert sind. Die Aufgaben, die sich aus diesem Ziel heraus entwickelt haben, umfassen: Überwachen von Netzwerk- und Systemzuständen, Antworten und Reagieren auf Fehlerbenachrichtigungen, wie Alarme, Diagnostizieren von Fehlerursachen, Einrichten von Fehlerpropagierung, etc. Konfigurationsmanagement beschäftigt sich mit der Anpassung von IT-Systemen an Betriebsumgebungen und umfasst das Setzen von Parametern, Installieren neuer Software, Erweitern alter Software, Anschließen von Geräten und Durchführen von Veränderungen an einer Netzwerktopologie. Abrechnungsmanagement umfasst Aufgaben wie Namens- und Adressverwaltung, Gewähren von Berechtigungen und die Abrechnungsdienste. Leistungsmanagement kann als eine systematische Fortsetzung des Fehlermanagements angesehen werden, da es nicht nur sicherstellt, dass ein Kommunikationsnetzwerk oder ein verteiltes System nur arbeitet, sondern weil es auch verlangt, dass das System gute Leistung erbringt. Es beschäftigt sich mit Daten wie Netzwerkdurchsatz, Netzwerklatenz, Fehlerraten, Speicherressourcen, CPU-Arbeitslast, Speicherverwendung, Antwortzeit von Servern, Verbindungseinrichtungszeit. Sicherheitsmanagement bezieht sich auf das Management von Sicherheit in verteilten Systemen, die die Ressourcen einer Firma oder eines Unternehmens umfassen, die wert sind, geschützt zu werden.
  • Um diese unterschiedlichen Managementaufgaben zu bewerkstelligen, sind auf der einen Seite einzelne Managementtools (wie Antwortzeittester, Troubleticketsysteme, etc.) und auf der anderen Seite Managementplattformen wie OpenView von Hewlett-Packard verfügbar (siehe z.B. N. Muller: "Focus on OpenView", CBM Books, 1995, pp. 1–20; J. Blommers: "OpenView Network Node Manager", Prentice Hall, 2001, pp. vi–xiii). Eine Managementplattform wie OpenView von Hewlett-Packard integriert mehrere Managementtools und managementbezogene Datenbanken und kann typischerweise entsprechend benutzerspezifischer Installationen und Bedürfnisse angepasst werden. Im Rahmen des Abwickelns von SLAs können fehler- und leistungsbezogene Informationen, die von Fehler und Leistungsmanagementanwendungen in der Form einzelner Managementtools und/oder innerhalb einer Managementplatform erzeugt werden (siehe z.B. Blommers pp. 119–174) als QoS Maßnahmen verwendet werden, um die erreichte QoS zu verfolgen und die Erfüllung der QoS mit in einem SLA gemachten Verpflichtungen zu verifizieren.
  • Aus der geschäftlichen Perspektive ist es die Qualität eines bereitgestellten IT-Dienstes, die zählt, am meisten ausgeprägt für Geschäftsbereiche, die völlig von IT-Diensten, wie E-Commerce-Unternehmen, abhängen. Ein Dienst in diesem Kontext ist eine abstraktere Entität, die typischerweise auf einer Kombination vieler Elemente einer IT-Infrastruktur, wie Kabeln, Netzwerkverbindungsgeräte, Gateways, Server, Anwendungen etc. basiert. Dienste sind z.B. Transportdienste durch ein Netzwerk, Namensdienste, E-Mail-Dienste, Web Anfrage-Antwort Dienste, Datenbankdienste und genauer Anwendungsdienste, die an individuelle Geschäftsbedürfnisse eines Unternehmens angepasst sind. Immer mehr solcher IT-Funktionen werden an Dienstanbieter ausgelagert. Der Dienstanbieter und der Kunde einigen sich typischerweise auf einen Vertrag, in dem der Dienstanbieter sich selbst zu bestimmten Qualitätsstandards des gelieferten Dienstes verpflichtet. Die Qualität eines Dienstes wird oft durch eine oder mehrere "Dienstgüten" quantifiziert, und ein Vertrag, in dem sich die beiden Parteien auf eine bestimmte (minimale) Dienstqualität einigen, wird deshalb eine "Dienstgütevereinbarung" genannt. Typischerweise definieren SLAs bestimmte Dienstgüteziele (SLOs), die vom Dienstanbieter erfüllt werden müssen. Typische SLOs sind eine bestimmte Verfügbarkeit der IT-Infrastruktur, eine gewisse Antwortzeit oder Netzwerklatenz, eine bestimmte Paketlieferungsgarantie oder eine (oft sehr komplexe) Kombination solcher Entitäten. Ein bekannter Typ von SLO verlangt, dass ein gewisses Ereignis (z. B. ein Fehler) überhaupt nicht geschieht; jedes einzelne Auftreten wird dann als eine SLO-Verletzung betrachtet und kann zu einer Strafe führen, die vom Dienstanbieter zu zahlen ist. Ein anderer Typ von SLO bezieht sich auf Entitäten, die über eine Zeitperiode, nachstehend "Erfüllungsperiode" genannt, kumuliert werden und verlangt, dass die kumulierten Entitäten unter oder über gewissen Schwellwerten gehalten werden; z.B. verlangt er, dass die Verfügbarkeit eines Dienstes über 99,95% innerhalb eines Kalendermonats ist. Wie oben erwähnt wurde, wird die tatsächlich gelieferte Dienstqualität quantitativ bestimmt, z.B. durch gemessene fehler- und leistungsbezogene Information, die von Fehler- und Leistungsmanagementanwendungen und, durch einen Vergleich der gemessenen Werte mit den SLOs produziert werden; es wird bestimmt, ob der gelieferte Dienst die vereinbarte SLA erfüllt.
  • Typischerweise kann ein Dienstanbieter, der sich selbst zu einem Dienst mit einer höheren Dienstgüte verpflichtet, z.B. eine höhere Verfügbarkeit oder kürzere Antwortzeit, gewöhnlich höhere Dienstgebühren verlangen als im Fall einer geringeren Dienstgüte, z.B. eine weniger ausgedehnte Verfügbarkeit oder eine längere Antwortzeit. Auf der anderen Seite wird ein Anbieter, der eine hohe Dienstgüte garantiert, entweder leichter die Dienstgütevereinbarung nicht einhalten und wird daher ein höheres Risiko einer Strafzahlung oder Schadenszahlung haben, oder wird höhere Betriebs- und Investitionskosten aufbringen müssen, um die vereinbarte Dienstgüte ohne höheres Fehlerrisiko einhalten zu können. Eine Kenntnis der tatsächlich vom Dienstanbieter gelieferten Dienstqualität wird normalerweise sowohl vom Dienstanbieter als auch vom Kunden während der laufenden Erfüllungsperioden, sowie am Ende dieser Perioden gewünscht.
  • Zu diesem Zweck umfasst ein SLA-Management typischerweise Sichtbarkeits- und Reportanforderungen, die in zwei Kategorien unterteilt werden können: Echtzeit und historisch. Ein Echtzeitreport ermöglicht z.B. einem IT-Operator zu bewerten, ob ein Fehler relevant für die Erfüllung eines SLA ist und um folglich die Gegenmaßnahmen zu priorisieren. Ein historischer Report am Ende einer Erfüllungsperiode wird typischerweise für Abgleichzwecke verwendet, d.h. um zu bewerten, ob der SLA erfüllt wurde, um Strafen oder Schäden, etc. zu berechnen (siehe z.B. Lee, pp. 49–52).
    •
  • DIE ERFINDUNG
  • Gemäß einem ersten Aspekt wird ein Verfahren bereitgestellt zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden. Die Daten aus den Datenquellen kommen regulär in Echtzeit an, aber Daten aus einer oder mehrerer Datenquellen können gelegentlich verzögert sein. Das Verfahren umfasst: Berechnen einer Echtzeitangabe der Dienstqualität in einem ersten Prozess auf der Grundlage der regulären Daten, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, Berechnen einer verzögerten aber exakteren Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess auf der Grundlage regulärer Information, die reguläre Daten und/oder von ihnen abgeleitete Information umfasst, und der verzögerten Daten.
  • Gemäß einem weiteren Aspekt wird ein Verfahren bereitgestellt zum Bestimmen von Dienstqualität (QoS) in einer IT Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden. Die Daten aus den Datenquellen kommen regulär in Echtzeit an, aber Daten aus einer oder mehrerer Datenquellen können gelegentlich verzögert sein, wobei das Verfahren umfasst: Überprüfen der Verfügbarkeit von Datenquellen; Berechnen, auf der Grundlage der regulären Daten, einer Echtzeitangabe der Dienstqualität in einem ersten Prozess, wobei die Angabe möglicherweise inexakt ist, weil verzögerte Daten nicht umfasst sind; und, in Reaktion auf eine Detektierung, dass eine oder mehrere Datenquellen nicht verfügbar sind, Bestimmen, welche Resultate der Echtzeitberechnung von der detektierten Datenquellen-Nichtverfügbarkeit betroffen sind und Abspeichern jenes Teils regulärer Information, d.h. jenen Teil regulärer Daten und von ihnen abgeleitete Information, der verwendet wird, um die betroffenen Resultate neu zu berechnen; Bestimmen, nach dem Empfang der verzögerten Daten, auf der Grundlage der gespeicherten regulären Information und der verzögerten Daten, einer verzögerten, aber exakteren Angabe der Dienstqualität durch Neuberechnen der Resultate des ersten Prozesses, die von der Datenquellen-Nichtverfügbarkeit betroffen waren, in einem zweien Prozess.
  • Gemäß einem weiteren Aspekt wird ein Computersystem bereitgestellt, das Dienstqualität (QoS) in einer IT-Infrastruktur bestimmen kann auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden, wobei die Daten von den Datenquellen regulär in Echtzeit ankommen, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können. Das Computersystem ist derart programmiert, dass es: auf der Grundlage der regulären Daten, eine Echtzeitangabe der Dienstqualität in einem ersten Prozess berechnet, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, eine verzögerte aber exaktere Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess berechnet, auf der Grundlage regulärer Information, die reguläre Daten und/oder davon abgeleitete Information umfasst, und der verzögerten Daten.
  • Gemäß einem weiteren Aspekt wird ein Computerprogramm bereitgestellt zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden. Die Daten aus den Datenquellen kommen regulär in Echtzeit an, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können, wobei beim Ausführen des Computerprogramms auf einem Computersystem folgendes Verfahren durchgeführt wird: Berechnen einer Echtzeitangabe der Dienstqualität in einem ersten Prozess auf der Grundlage der regulären Daten, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, Berechnen einer verzögerten aber exakteren Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess auf der Grundlage regulärer Information, die reguläre Daten und/oder von ihnen abgeleitete Information umfasst, und der verzögerten Daten.
    •
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Ausführungsformen der Erfindung werden nun beispielhaft und unter Bezugnahme auf die angefügten Zeichnungen beschrieben, in denen:
  • 1 ein abstraktes Architekturdiagramm eines beispielhaften QoS-Managementsystems und einer gemanagten IT-Infrastruktur ist, entsprechend Ausführungsformen der Erfindung;
  • 2A und 2B eine beispielhafte QoS-Überwachungsausgabe in einer Ausführungsform der Erfindung veranschaulichen;
  • 3 einen beispielhaften QoS-Bestimmungsprozess ohne Datenquellen-Nichtverfügbarkeit veranschaulicht;
  • 4 einen QoS-Bestimmungsprozess ähnlich zu 3, mit Datenquellen-Nichtverfügbarkeit, aber ohne einen Neuberechnungsprozess veranschaulicht;
  • 5 einen QoS-Bestimmungsprozess entsprechend einer Ausführungsform der Erfindung in einer beispielhaften Situation ähnlich zu 4 veranschaulicht, aber mit einem Neuberechnungsprozess;
  • 6 eine weitere Ausführung der Erfindung mit asynchronen Datenquellen veranschaulicht;
  • 7 ein beispielhafter Berechnungsgraph ist, der einen Berechnungsprozess einer Ausführungsform darstellt;
  • 8a–d Berechnungsgraphen zeigen, die veranschaulichen, welche reguläre Information in unterschiedlichen Ausführungsformen gespeichert wird;
  • 9a und b partielle Berechnungsgraphen zeigen, die in Ausführungsformen des Neuberechnungsprozesses verwendet werden;
  • 10a und b das Bearbeiten von Konfigurationsveränderungen entsprechend Ausführungsformen veranschaulichen;
  • 11a–d den Prozess der Zeitstempelabänderung entsprechend einiger Ausführungsformen veranschaulichen;
  • 12 ein Zustandsdiagramm eines Berechnungsprozesses entsprechend einer Ausführungsform ist;
  • 13 eine diagrammatische Darstellung einer Ausführungsform eines QoS-Managementcomputersystems ist.
  • Die Zeichnungen und die Beschreibung der Zeichnungen stellen Ausführungsformen der Erfindung dar, aber nicht die Erfindung selbst.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • 1 ist ein abstraktes Architekturdiagramm eines beispielhaften QoS-Managementsystems und einer gemanagten IT-Infrastruktur. Vor der detaillierten Beschreibung von 1 werden zunächst verschiedene Punkte der Ausführungsformen allgemein diskutiert.
  • Die beschriebenen Ausführungsformen beziehen sich auf die Bestimmung der Dienstqualität (Quality of Service, QoS) in einer IT-Infrastruktur, die ein Computernetzwerk oder ein Telekommunikationsnetzwerk sein kann, die darauf basierende Anwendungen und Dienste umfasst. Wie zu Beginn erwähnt wurde, umfasst eine IT-Infrastruktur typischerweise nicht nur physische Geräte wie Kabel, Netzwerkverbindungsgeräte und Endgeräte, sondern auch "logische" Bestandteile, wie Anwendungen, Middleware und Betriebssysteme, die auf den verbindenden Geräten und Endgeräten des Netzwerks laufen. Ein Dienst ist typischerweise eine Funktionalität, die sich auf eine Kombination vieler solcher physischer Geräte und logischer Bestandteile abstützt; Beispiele sind, wie zu Beginn erwähnt, Transportdienste durch ein Netzwerk, Namensdienste, E-Mail-Dienste, Web Anfrage-Antwort Dienste, Datenbankdienste, und eine Fülle spezifischer Anwendungsdienste, die individuellen Geschäftsbedürfnissen eines Unternehmens angepasst sind. Wenn solche Dienste an Dienstanbieter ausgelagert werden, wird typischerweise eine Übereinkunft zwischen dem Dienstanbieter und dem Kunden gemacht, die definiert, welche Dienstqualitätsgüte der Dienstanbieter verpflichtet ist zu liefern. Obwohl QoS oft eine qualitativ wahrgenommene Größe ist, wird sie quantitativ gemessen, um zu ermöglichen, dass die Erfüllung der in der SLA gemachten Verpflichtungen beständig verfolgt werden können und schließlich am Ende einer Erfüllungsperiode sowohl vom Dienstanbieter als auch vom Kunden auf objektive Art und Weise verifiziert werden können.
  • In einigen der Ausführungsformen basiert die Dienstqualitätsbestimmung auf quantitative Art und Weise auf einer Messung QoS-bezogener Entitäten, die die Verpflichtungen widerspiegeln, die im SLA gemacht werden. Diese Entitäten werden oft "Metriken" genannt (siehe Lee, pp. 315–319) oder "Metrikentitäten", und gemessene Instanzen dieser Entitäten werden nachstehend auch "Metrikwerte" oder "Metrikdaten" genannt. Beispiele gemessener Metriken sind Verfügbarkeit, z.B. die Verfügbarkeit eines Netzwerkverbindungsgerätes oder eines Endgerätes (die entsprechenden Metrikwerte können logische Werte sein, wie "wahr" für "verfügbar" und "falsch" für "nicht verfügbar"); Leistung, z. B. von Geräten oder die Netzwerkübertragung; Latenz, wie Antwortzeit eines Servers oder Netzwerkverzögerung; Zuverlässigkeit, z.B. ausgedrückt durch die Anzahl an Fehlern; wobei die gesamten später genannten Metrikwerte typischerweise numerische Werte sind (siehe Lee, pp. 44–46).
  • Die QoS-bezogenen Daten, z.B. die Metrikwerte, werden von geeigneten Datenquellen bereitgestellt. In einigen Ausführungsformen sind die Datenquellen Datenschnittstellen alleinstehender IT-Managementtools und/oder IT-Managementplattformen.
  • Normalerweise werden die Metrikdaten von den Datenquellen an ein QoS-Managementsystem in Echtzeit geliefert. "Echtzeit" bedeutet nicht, dass die Metrikdaten sofort nach dem Auftreten eines Ereignisses oder eines Status geliefert werden, das durch Metrikdaten widergespiegelt wird, sondern umfasst regulär auftretende Verzögerungen. Zum Beispiel wird ein solcher Vorfall oder Statusänderung typischerweise nicht sofort beobachtet, sondern erst nachdem eine asynchrone Nachricht empfangen wurde (im Fall von asynchroner Ereignisbenachrichtigung) oder eine Statusanfrage ausgeschickt wurde und eine Antwort wurde von einem betroffenen Managementtool empfangen wurde (im Fall von synchronem Statusreport). Zusätzlich benötigt das Managementtool dann typischerweise eine gewisse Verarbeitungszeit, um die Metrikdaten vorzubereiten. Schließlich gibt es typischerweise eine bestimmte Übertragungsverzögerung, die für die Übertragung der Metrikdaten aus der Datenquelle zum QoS-Managementsystem über ein Netzwerk benötigt wird. Die Summe dieser Beiträge ist die reguläre Verzögerung der Echtzeitmetrikdaten; diese Daten werden deshalb auch "reguläre Daten" genannt.
  • Im Gegensatz dazu können Metrikdaten weiterhin auf eine irreguläre Art und Weise verzögert sein. Zum Beispiel kann die Netzwerkverbindung zwischen einer oder mehrerer Datenquellen und dem QoS-Managementsystem für bestimmte Zeit außer Betrieb sein, und wenn die Netzwerkverbindung wieder in Betrieb tritt, werden die Metrikdaten, die in der Zwischenzeit produziert wurden und in der oder den betroffenen Datenquelle(n) gepuffert wurden, anschließend zum QoS-Managementsystem übermittelt. Eine andere Ursache irregulärer Verzögerungen kann sein, dass ein Datensammler des QoS-Managementsystems temporär nicht in der Lage ist, Metrikdaten aus einer oder mehreren Datenquellen zu empfangen, oder dass ein Datensender eines Managementtools temporär außer Dienst ist. Alle drei Verzögerungsursachen sollen durch die Ausdrücke "Datenquellen-Nichtverfügbarkeit" oder "Datenquellenfehler" nachstehend umfasst sein. In allen solchen Fällen, in einigen der Ausführungsformen werden die Metrikdaten, die während des Fehlers erzeugt wurden, in den Managementtools gepuffert und später zum Managementsystem weitergeleitet, wenn die Datenquelle wieder verfügbar ist, z.B. die Netzwerkverbindung, der Datensammler oder der Datensender wieder in Betrieb ist. Zu diesem Zweck basiert die Kommunikation in einigen Ausführungsformen zwischen den Datenquellen und dem QoS-Managementsystem auf einer sicheren Verbindungseinrichtung für die Datenübertragung zwischen der Datenquelle und dem QoS-Managementsystem, und die Datenübertragung wird nur als erfolgreich betrachtet, wenn der Datensammler den Empfang der Daten dem Sender bestätigt; Daten, die nicht erfolgreich übertragen werden können, werden gepuffert und später wieder gesendet (das Wiedersenden kann z.B. auf der Grundlage von "Trial and Error" geschehen, bis der Datenquellenfehler entfernt ist und eine erfolgreiche Lieferung möglich ist). Solche Daten werden "verzögerte Daten" genannt.
  • Das QoS-Managementsystem berechnet eine Angabe der Dienstqualität auf der Grundlage der Metrikdaten, die aus den Datenquellen empfangen werden. Typischerweise basiert ein SLO, das in einem SLA definiert ist, auf QoS-Parametern, die eine Kombination gemessener Metrikwerte sind; oft werden die QoS-Parameter über eine Erfüllungsperiode hinweg kumuliert. Das SLO verlangt typischerweise vom kumulierten QoS-Parameter, unter einem bestimmten Schwellwert zu bleiben.
  • Als ein einfaches Beispiel könnte ein SLA verlangen, dass der folgende SLO-Ausdruck wahr ist (unter Bezugnahme auf eine bestimmte vereinbarte Erfüllungsperiode z.B. ein Kalendermonat (durchschnittliche_server_antwort_zeit<0.2 sec) und (kumulierte_server_nichtverfügbarkeit≤0.02%) und (kumulierte_datenbank_nichtverfügbarkeit≤0,0.05%). Die in diesem Beispiel verwendeten Metrikdaten können wiederholt (z.B. alle fünf Sekunden) von drei verschiedenen Datenquellen geliefert werden. Zum Beispiel kann eine erste Datenquelle eine Datenbankantwortzeit (d.h. ein numerischer Wert) liefern, der alle fünf Sekunden gemessen wird, und zwei andere Datenquellen können alle fünf Sekunden einen logischen Wert liefern, der angibt, ob der fragliche Server und die Datenbank im vorliegenden Messintervall (z.B. das aktuelle Fünf-Sekunden-Intervall) verfügbar sind oder nicht. Ein beispielhaftes QoS-Managementsystem berechnet dann auf der Grundlage dieser Metrikwerte, die durchschnittliche_datenbank_antwort_zeit, gemittelt seit dem Beginn der Erfüllungsperiode und die kumulierte_server_nichtverfügbarkeit und kumulierte_datenbank_nichtverfügbarkeit, akkumuliert seit dem Beginn der Erfüllungsperiode. Jedoch sind im allgemeinen die akkumulierten QoS-Parameter nicht einfach gemessene Metrikwerte wie im obigen Beispiel, sondern sind Werte, die durch logische und/oder mathematische Kombinationen gemessener Metrikwerte, Schwellwertwerte etc., in jedem der kurzen Zeitintervalle, wie unten beschrieben, berechnet werden.
  • Um eine sinnvolle Erfüllungsvorhersage zu erhalten, werden in einigen Ausführungsformen die kumulierten Metrikwerte als ein Prozentwert der seit dem Beginn der Erfüllungsperiode vergangenen Zeit ausgedrückt. Falls zum Beispiel der Server drei Minuten am ersten Tag der Erfüllungsperiode nicht verfügbar ist, wäre die kumulierte_server_nichtverfügbarkeit am Ende des ersten Tags schon 0.021 %, der oben erwähnte SLO-Ausdruck wäre deshalb an jenem Zeitpunkt "falsch", und gibt dadurch an, dass die bereitgestellte Dienstqualität die SLA nicht erfüllt, falls sie auf diese Weise fortfährt. In einigen anderen Ausführungsformen werden die kumulierten Werte als eine Prozentzahl der vollen Länge der Erfüllungsperiode ausgedrückt, um eine Angabe bereitzustellen, wieviel Nichtverfügbarkeit während der aktuellen Erfüllungsperiode noch toleriert werden kann, und wobei der Dienst nichtsdestotrotz innerhalb der SLA-Verpflichtung bleibt. Zum Beispiel ist dem Dienstanbieter klar, dass, falls am 30. Tag einer 31-tägigen Erfüllungsperiode die kumulierte_server_nichtverfügbarkeit schon 0.02% erreicht hat, für die aktuelle Erfüllungsperiode keine weitere Server-Nichtverfügbarkeit auftreten darf, um die Dienstqualität zu erfüllen, zu der man sich im SLA verpflichtet hat.
  • Unter Verwendung des obigen Beispiels nehmen wir nun an, dass eine Datenquelle, die die gemessene Serverantwortzeit liefert, unverfügbar wird, z.B. weil die Netzwerkverbindung zwischen der Datenquelle ihren Betrieb einstellt, so dass die gemessenen Serverantwortzeitdaten an der Datenquelle gepuffert werden, aber nicht zum QoS-Managementsystem übermittelt werden. Als eine Konsequenz sind temporär nicht mehr alle Metrikdaten verfügbar, die benötigt werden, um eine exakte Echtzeitangabe der gegenwärtig bereitgestellten Dienstqualität zu berechnen. Falls demzufolge die Berechnung abgebrochen würde, bis die unterbrochene Netzwerkverbindung ihren Betrieb wiederaufnehmen würde und die gepufferten Serverantwortzeitdaten wieder verfügbar würden, wären der Dienstanbieter und der Kunde während der Aussetzzeitdauer "blind". Falls z.B. während der Aussetzzeitdauer der Server oder die Datenbank nicht-verfügbar würden, würde dies nicht beim QoS-Managementsystem bemerkt werden. Falls auf der anderen Seite die Berechnung nicht ausgesetzt, sondern fortgesetzt würde, z. B. unter Verwendung des letzten Werts der gemessenen Serverantwortzeit, die korrekt übertragen wurde anstelle der nicht-lieferbaren tatsächlich gemessenen Werte, könnte das Resultat der Berechnung inexakt sein. Falls z.B. die letzte gemessene Serverantwortzeit abnormal lang war und dieser abnormale Antwortzeitwert würde dann während der Ausssetzperiode anstelle der eigentlichen Serverantwortszeit verwendet werden, die in Wirklichkeit wieder normal geworden wäre, könnte dies zu einer scheinbaren Nichterfüllung der SLA führen, was in der Tat nicht korrekt wäre.
  • Um sowohl eine Echtzeitangabe als auch eine exakte Angabe der Dienstqualität bereitzustellen, werden in einigen Ausführungsformen zwei Prozesse ausgeführt: In einem ersten Prozess wird eine Angabe der Dienstqualität auf der Grundlage regulärer Daten berechnet. Diese Echtzeitangabe ist möglicherweise inexakt, da verzögerte Daten nicht umfasst sind, sie ist aber in Echtzeit. Nach dem Empfang verzögerter Daten wird eine verzögerte aber exaktere Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess berechnet. Diese spätere Berechnung wird auf der Grundlage dessen ausgeführt, was "reguläre Information" genannt wird, und der verzögerten Daten. Die "reguläre Information" kann entweder die regulären Daten oder die von ihnen abgeleitete Informationen sein, wie Zwischenergebnisse, die aus regulären Daten im ersten Prozess erhalten wurden, oder eine Kombination von beiden. Durch Bereitstellen dieser beiden Berechnungsprozesse können zwei in Konflikt stehende Ziele, Unmittelbarkeit und Genauigkeit der QoS-Bestimmung auf eine kombinierte Art und Weise erreicht werden.
  • Um die QoS-Angabe im zweiten Prozess neu berechnen zu können, wird die reguläre Information, die im zweiten Prozess verwendet werden soll, zumindest, bis die verzögerten Daten empfangen werden, gespeichert, und wird als eine Eingabe für die Neuberechnung verwendet, die im zweiten Prozess gemacht wird, zusammen mit den verzögerten Daten. In einigen Ausführungsformen werden alle regulären Daten normalerweise ungeachtet dessen gespeichert, ob ein Datenquellenfehler geschehen ist, so dass typischerweise die gesamten regulären Daten noch verfügbar sind, wenn verzögerte Daten empfangen werden. In einigen Ausführungsformen dieses Typs wird eine vollständige Neuberechnung durchgeführt, während der Neuberechnung des zweiten Prozesses der Verwendung der gespeicherten regulären Daten und der verzögerten Daten. In einigen dieser Ausführungsformen ist es wegen der Tatsache, dass die gesamten regulären Daten gespeichert sind, für das QoS-Managementsystem nicht einmal notwendig, Datenquellenfehler in einer frühen Phase zu bemerken, d.h. zum Beginn der Fehlerperiode; stattdessen ist es für den Datenquellenfehler ausreichend, rückblickend durch den Empfang verzögerter Daten bemerkt zu werden, nachdem die Datenquelle wieder verfügbar wurde. Der zweite Prozess wird dann gestartet. Wie unten beschrieben senden einige Typen von Datenquellen nicht kontinuierlich Daten, sondern nur selten beim Ereignis von Zustandsänderungen. Falls keine solche Statusänderung während einer Datenquellen-Nichtverfügbarkeitsperiode geschieht, wird der Datenquellenfehler nicht einmal bemerkt und der zweite Prozess wird nicht gestartet.
  • In anderen Ausführungsformen werden die regulären Daten nicht immer gespeichert, aber sie werden nur gespeichert, wenn ein Auftreten einer Datenquellen-Nichtverfügbarkeit detektiert wurde. In solchen Ausführungsformen wird ein Mechanismus bereitgestellt, der ermöglicht, dass eine Nichtverfügbarkeit einer Datenquelle in einem frühen Stadium detektiert wird, kurz nachdem die Datenquelle nicht-verfügbar wurde, woraufhin der zweite Prozess gestartet wird. In diesem frühen Stadium veranlasst der zweite Prozess hauptsächlich, dass die regulären Daten gespeichert werden. Später, wenn die Datenquelle wieder verfügbar ist und verzögerte Daten empfangen werden, berechnet der zweite Prozess die Dienstqualität neu unter Verwendung der gespeicherten regulären Daten und der verzögerten Daten.
  • In einer Variante der letztgenannten Ausführungsformen, werden nach Detektierung, dass eine oder mehrere Datenquellen nicht verfügbar sind, nicht alle regulären Daten gespeichert. Stattdessen bestimmt der zweite Prozess, der nach der Detektierung gestartet wird, welche Resultate der Echtzeitberechnung von der detektierten Datenquellen-Nichtverfügbarkeit betroffen sind und veranlasst, dass nur jener Teil der regulären Daten, der verwendet wird, um die betroffenen Resultate neu zu berechnen, abgespeichert wird.
  • In einer weiteren Variante werden nicht alle regulären Daten gespeichert, die verwendet werden, um die betroffenen Resultate neu zu berechnen, sondern Zwischenresultate, die aus den regulären Daten im ersten Berechnungsprozess erhalten wurden, werden gespeichert, falls die Zwischenresultate ausreichend sind, um die betroffenen Resultate neu zu berechnen. Natürlich wird in einigen Fällen eine Kombination regulärer Daten und Zwischenresultate abgespeichert und die Neuberechnung, z.B. falls ein Resultat des ersten Prozesses von der Datenquellen-Nichtverfügbarkeit betroffen ist, basiert sowohl auf bestimmten regulären Daten und auf Zwischenergebnissen, die aus ihnen berechnet werden. Der zweite Prozess, der gestartet wird, nach der Detektierung, dass eine Datenquelle nicht verfügbar wurde, bestimmt, welche regulären Daten und Zwischenergebnisse zu speichern sind, und veranlasst, dass diese gespeichert werden. Später, nach dem Empfang der verzögerten Daten bestimmt er eine verzögerte aber genauere Angabe der Dienstqualität auf der Grundlage der gespeicherten regulären Informationen (d.h. die gespeicherten regulären Daten und Zwischenergebnisse) und der verzögerten Daten, durch Neuberechnung der Resultate der Echtzeitberechnung des ersten Prozesses, die von der Datenquellen-Nichtverfügbarkeit betroffen waren. In diesen Varianten ist die Menge an Daten, die zu speichern ist, kleiner, und in der letzten Variante sind im zweiten Prozess weniger Berechnungen durchzuführen als in den anderen erwähnten Ausführungsformen.
  • Wie oben erwähnt, werden in einigen Ausführungsformen die QoS-Parameterwerte wiederholt berechnet für kurze Zeitintervalle; da die Berechnung einmal pro Zeitintervall stattfindet, bilden die Zeitintervalle "Berechnungszyklen". Die auf diese Weise berechneten QoS-Parameterwerte werden in einigen Ausführungsformen über die Zeit hinweg kombiniert, z.B. über die aktuelle Erfüllungsperiode kumuliert. Um die Metrikdaten den Berechnungszyklen zuzuweisen, zu dehnen sie gehören, werden in einigen Ausführungsformen die Metrikdaten von den Datenquellen mit Zeitstempeln markiert (ein Zeitstempel für jeden Wert), wobei ein Zeitstempel den Zeitpunkt angibt, an dem die Daten erzeugt wurden. Ein Bestandteil aus Metrikdaten und seinem Zeitstempel werden zusammen auch "Datenpunkt" genannt. Die Zeitstempel ermöglichen den Metrikdaten, in die richtige Reihenfolge gesetzt zu werden, und die Metrikdaten aus den unterschiedlichen Datenquellen werden in einer korrekten zeitlichen Beziehung auf der Grundlage ihrer Zeitstempel kombiniert. Im allgemeinen umfasst die Eingabe zu einem in einem bestimmten Berechnungszyklus ausgeführten Berechnung nur diese Metrikdaten, die (zu) diesem speziellen/spezifischen Berechnungszyklus gehören/entsprechen. In einigen Ausführungsformen wird dies nur im zweiten Berechnungsprozess gemacht, wohingegen im ersten Berechnungsprozess Metrikdaten, die zu anderen Berechnungszyklen als den gegenwärtig betrachteten Zyklus gehören, aufgrund des Echtzeitcharakters des ersten Prozesses verwendet werden können. In anderen Ausführungsformen jedoch werden sogar im ersten Berechnungsprozess nur Metrikdaten, die zum aktuellen Berechnungszyklus gehören, verwendet und für diesen Zyklus kombiniert.
  • Es wird nicht verlangt und ist normalerweise nicht einmal der Fall, dass in jedem Berechnungszyklus neue Datenpunkte aus den Datenquellen für all die Metrikentitäten empfangen werden, die die Eingabeentitäten der ausgeführten Berechnung sind; unter Verwendung des Beispiels oben wird nicht verlangt, dass ein neuer Datenpunkt für die metrische Entität "Serverantwortzeit", "Serververfügbarkeit" und "Datenbankverfügbarkeit" in jedem Berechnungszyklus empfangen wird. Stattdessen kann es passieren, dass in vielen Berechnungszyklen neue Datenpunkte für einige oder sogar alle Metrikentitäten fehlen. In einigen der Ausführungsformen wird beim Ereignis eines fehlenden neuen Datenpunkts einfach angenommen, dass der Wert einer Metrikentität, die als letztes empfangen wurde, gültig bleibt, bis ein neuer Datenpunkt für diese Entität empfangen wird. Unter Verwendung des obigen Beispiels nehmen wir nun an, dass Datenpunkte wie folgt empfangen werden:
    Figure 00150001
  • Dann werden in den erwähnten Ausführungsformen die folgenden Metrikwerte in den Berechnungszyklen verwendet:
    Figure 00150002
  • Es gibt unterschiedliche Ursachen für die Abwesenheit neuer Daten: obwohl es im Prinzip möglich ist, dass die Datenquellen regulär einen Datenpunkt pro Berechnungszyklus für jede Eingabeentität liefern, können einige Datenpunkte im Echtzeitberechnungsprozess wegen Datenquellenfehlern fehlen. Jedoch liefern in anderen Ausführungsformen einige oder alle Datenquellen ihre Daten mit einer geringeren Frequenz als die Datenzyklusfrequenz. In noch anderen Ausführungsformen liefern alle oder einige der Datenquellen ihre Daten auf eine asynchrone Art und Weise, z.B. senden sie nur einen Datenwert, wenn ein "Ereignis" (z.B. eine Zustandsänderung) stattfindet. In diesen Fällen sind neue Datenpunkte nicht einmal für alle Eingabeentitäten in jedem Berechnungszyklus dieses zweiten Berechnungsprozesses verfügbar; stattdessen werden die neuen Datenpunkte sogar ohne einen Datenquellenfehler mit einer geringeren Frequenz als der Berechnungszyklusfrequenz ankommen oder sogar in einer nicht-periodischen und unvorhersehbaren Art und Weise, im Fall asynchroner Ereignisse. In einigen der Ausführungsformen wird in solchen Fällen der vorhergehende empfangene Wert noch als gültig angesehen und wird in allen folgenden Berechnungszyklen verwendet, bis ein neuer Wert empfangen wird.
  • Andererseits kann es auch möglich sein, dass zwei Datenpunkte derselben Entität in denselben Berechnungszyklus fallen. Zum Beispiel kann ein Netzwerkelement für eine sehr kurze Zeit nicht-verfügbar werden, so dass zwei Ereignisse eines sofort nach dem anderen stattfinden, nämlich "Netzwerkelement ist nicht-verfügbar" und "Netzwerkelement ist verfügbar". In einigen Ausführungsformen werden zwei Datenpunkte, die diese Ereignisse repräsentieren, erzeugt, die innerhalb ein- und denselben Berechnungszyklus fallen. Solche Konflikte werden mit geeigneten Kollisionsregeln aufgelöst. Zum Beispiel wird in einigen dieser Ausführungsformen der "ernsteste" Wert solcher in Konflikt stehender Datenpunkte als der (einzige) Eingabewert für die Berechnung in diesem Berechnungszyklus (z. B. der Wert "nicht-verfügbar") verwendet, wohingegen der Wert des letzten von in Konflikt stehenden Datenpunkten derjenige ist, der in den folgenden Berechnungszyklen als der gültige Wert angenommen wird, bis ein neuer Wert empfangen wird. In anderen Ausführungsformen wird nur der Wert des letzten von in Konflikt stehenden Datenpunkten verwendet, und andere in Konflikt stehende Datenpunkte werden ignoriert. In den letztgenannten Ausführungsformen kann das Bearbeiten von in Konflikt stehenden Datenpunkten schon auf dem Niveau der Datenquellen gemacht werden. Zum Beispiel leiten in einigen Ausführungsformen die Datenquellen nur das letzte von in Konflikt stehenden Ereignissen weiter und werten die anderen weg. Dadurch wird garantiert, dass keine in Konflikt stehenden Datenpunkte zum QoS-Managementsystem übertragen werden. In einigen der Ausführungsformen, in denen die Konfliktauflösung auf dem Niveau der Datenquellen durchgeführt wird (oder in denen solche Konflikte nicht auftreten), z.B. wenn die Berechnungsintervalle kürzer sind als das minimale Zeitintervall zwischen aufeinanderfolgenden Ereignissen, ist die Zeitauflösung des Zeitstempelns gleich der Berechnungszyklusperiode. In anderen Worten gibt ein Zeitstempel nur an, zu welchem Berechnungszyklus ein Datenpunkt gehört, aber gibt nicht an, zu welchem Punkt innerhalb eines Berechnungszyklusintervalls ein Datenpunkt gehört. Zum Beispiel wird in einigen der Ausführungsformen ein inkrementeller Zähler verwendet, um die Zeitstempel herzustellen, wobei ein inkrementeller Schritt einem Berechnungszyklus entspricht. Zum Beispiel können sich die Zeitstempel für aufeinanderfolgende Berechnungszyklen wie folgt lesen: 001, 002, 003, etc. Wie oben erwähnt wurde, wird in einigen der Ausführungsformen reguläre Information (d.h. reguläre Daten und/oder Zwischenergebnisse, die aus ihnen im ersten Prozess erlangt wurden) nur gespeichert nach Detektierung, dass eine oder mehrere der Datenquellen nicht verfügbar sind, weil nur die reguläre Information, die zu den Berechnungszyklen gehört, die sich auf Zeiten beziehen, nachdem eine Datenquelle unverfügbar wurde in dem realen Berechnungsprozess verwendet werden. In solchen Ausführungsformen kann eine Diskrepanz auftreten wegen einer kleinen Zeitlücke zwischen der Zeit, als die Datenquelle tatsächlich nicht-verfügbar wurde und der Zeit, als dies detektiert wurde, falls es einen Datenpunkt in dieser Zeitlücke gibt. Da solch ein Datenpunkt weder im ersten Prozess verwendet werden würde (da er nicht regulär zum QoS-Managementsystem übermittelt wurde, sondern verzögert) noch in dem zweiten Prozess verwendet werden würde (da er zu einem Berechnungszyklus gehört, der nicht neu berechnet wird, da er vor der Detektierung der Nichtverfügbarkeit liegt, wäre er vollständig verloren. Um dieses Ereignis zu verhindern, wird in einigen Ausführungsformen der Zeitstempel eines solchen Datenpunkts (von der Datenquelle als ein verzögerter Datenpunkt übertragen, sobald die Quelle wieder verfügbar wurde, aber in der Tat zum Berechnungsintervall vor der Nichtverfügbarkeit gehörend) künstlich inkrementiert, so dass der Datenpunkt als zu einem Berechnungszyklus gehörend erscheint (z.B. der erste Zyklus), der durchgeführt wurde, nachdem die Nichtverfügbarkeit detektiert wurde. Auf diese Weise wird der Datenpunkt im zweiten Prozess verwendet, als wäre er erzeugt worden nachdem Nichtverfügbarkeit detektiert wurde.
  • Die Art und Weise, in der unterschiedliche Metrikentitäten im Berechnungsprozess kombiniert werden, der in jedem Berechnungszyklus durchgeführt wurde, kann durch einen Berechnungsgraphen dargestellt werden. Die Metrikeinheiten selbst und Schwellwerte, etc., mit denen sie kombiniert werden, sowie Berechnungsresultate und die logischen oder mathematischen Operationen, um die Resultate zu erzeugen, bilden die Knoten des Berechnungsgraphen. Falls z.B. in einem Berechnungsprozess überprüft werden musste, ob ein bestimmter Metrikwert oberhalb eines bestimmten Schwellwerts ist, würde der entsprechende Berechnungsgraph drei Knoten haben: ein erster Knoten würde die Metrikentität darstellen, ein zweiter Knoten den Wert des Schwellwerts, und ein dritter Knoten die logische Operation ">" und das Resultat des Vergleichs; das Resultat ist hier ein Boole'scher-Wert, der z.B. ein QoS-Parameter sein kann, der ein SLO darstellt, z.B. die Verfügbarkeit eines Servers. Die Knoten werden durch gerichteten Kanten verbunden, wobei die Richtung angibt, wie die Berechnung fortfährt. Zum Beispiel gibt es, falls man die gerichteten Kanten durch Pfeile illustriert, einen Pfeil, der vom ersten zum dritten Knoten zeigt und einen anderen Pfeil vom zweiten zum dritten Knoten. Im allgemeinen sind die Berechnungsgraphen komplexer und haben deshalb Zwischenknoten; solche Zwischenknoten stellen Zwischenergebnisse dar, die eine Eingabe für anschließende Berechnungen sind, die durch obige Knoten dargestellt werden.
  • Wie oben erwähnt, werden in einigen der Ausführungsformen alle Datenpunkte oder ein Berechnungszyklus, der die Eingabe des Berechnungsgraphen bildet, gespeichert, entweder unbedingt für alle Berechnungszyklen, oder für Berechnungszyklen, die der Detektierung eine Datenquellen-Nichtverfügbarkeit folgt. In diesen Ausführungsformen kann der im zweiten Prozess verwendete Berechnungsgraph derselbe sein wie im ersten Prozess, d.h. er kann der vollständige im ersten Prozess verwendete Berechnungsgraph sein. Mit anderen Worten sind die Berechnungstypen, die im ersten und zweiten Prozess ausgeführt werden, dieselben, und die Berechnungen in den beiden Prozessen unterscheiden sich nur, indem die in die Berechnungen eingegebenen Daten nicht dieselbe Quelle sein können (im ersten Berechnungsprozess fehlen die verzögerten Daten und nur die regulären Daten werden eingegeben, wohingegen im zweiten Berechnungsprozess sowohl die regulären und verzögerten Daten eingegeben werden).
  • In bestimmten Fällen, in denen sich der Berechnungsgraph nach oben verzweigt, kann die Abwesenheit der Werte einer Metrikeinheit wegen eines Datenquellenfehlers nur einen Zweig des Berechnungsgraphs betreffen, aber nicht die anderen. In einigen der Ausführungsformen basiert in solchen Fällen der zweite Prozess nicht auf dem vollständigen Berechnungsgraph, der im ersten Prozess verwendet wurde, sondern nur auf jenem Teil davon, der von der Abwesenheit der Metrikwerte dieser Entität betroffen ist. Dieser partielle Graph wird z.B. vom folgenden Algorithmus abgeleitet: alle gerichteten Pfade werden nach oben propagiert vom Knoten der fehlenden Entität zu den Knoten des obersten Niveaus, das durch Verfolgen der Richtung der Pfeile erreicht werden kann, die die Berechnungsrichtung angeben, wenn man den Graph auswertet. Diese Knoten sind markiert. Dann wird der Graph ausgehend von den markierten Knoten nach unten propagiert (entgegengesetzt zu den durch die Pfeile angegebenen Richtungen), wobei alle während dieses zweiten Propagierungsprozesses erreichten Knoten ebenfalls markiert werden. Die markierten Knoten und die gerichteten Verbindungen zwischen ihnen bilden den partiellen Graph, der im zweiten Berechnungsprozess verwendet wird. In einigen der Ausführungsformen wird der partielle Berechnungsgraph für den zweiten Prozess zu einem frühen Zeitpunkt nach der Detektierung einer Datenverzögerung bestimmt, und falls bestimmt wird, dass der partielle Berechnungsgraph, der im zweiten Berechnungsprozess verwendet werden soll, nur die Werte einiger aber nicht aller Metrikentitäten benötigt, werden nur die Werte dieser benötigten Metrikentitäten gespeichert.
  • In noch anderen Ausführungsformen werden, wie oben erklärt, nicht alle Werte der Metrikentitäten, die man benötigt, um einen (kompletten oder partiellen) Berechnungsgraph neu zu berechnen, gespeichert, sondern stattdessen werden die Zwischenergebnisse des ersten Berechnungsprozesses gespeichert, insoweit sie nicht von der Datenquellen-Nichtverfügbarkeit betroffen sind. Andere Zwischenergebnisse, die nicht von der Datenverzögerung betroffen sind, werden nicht gespeichert. Jedoch wird es nicht immer ausreichend sein, nur Zwischenergebnisse zu speichern, aber keine Metrikwerte. Falls z.B. ein Zwischenergebnis, das nicht (nur) von unteren Zwischenergebnissen in der Hierarchie des Berechnungsgraphen abhängt, sondern direkt von Metrikwerten abhängt, nur von einem Datenquellenfehler beeinflusst wird, werden diese Metrikwerte ebenfalls gespeichert. Wie oben erwähnt, werden Zwischenergebnisse durch Knoten in dem Berechnungsgraph dargestellt. Deshalb ist in Ausführungsformen, in denen Zwischenergebnisse im Neuberechnungsprozess gespeichert und wieder verwendet werden, der im zweiten Prozess verwendete Berechnungsgraph ein partieller Berechnungsgraph, der von den Knoten gebildet wird, die die gespeicherten Zwischenergebnisse und die gespeicherten Metrikwerte darstellen, und alle Knoten und Verbindungen des ersten Berechnungsgraphen, die oberhalb dieser "Startknoten" sind. Dieser partielle Berechnungsgraph wird zu einem frühen Zeitpunkt nach Detektierung eines Datenquellenfehlers bestimmt, um zu definieren, welche Zwischenergebnisse oder Metrikwerte zu puffern sind.
  • Der Berechnungsgraph braucht nicht immer derselbe sein, sondern kann von Zeit zu Zeit geändert werden (abgesehen von der Tatsache natürlich, dass der zweite Prozess in einigen Ausführungsformen auf einem partiellen Graphen des ersten Prozessgraphen basieren kann). Zum Beispiel können die Verpflichtungen, die in einem SLA gemacht wurden, zwischen Tag und Nacht differenzieren oder können von bestimmten Ereignissen abhängen (z.B. Verfügbarkeitsanforderungen können in Notfällen strenger sein). In einigen der Ausführungsformen wird die Verwendung eines abgeänderten Berechnungsgraphen angestoßen von sog. Zeitplanereignissen oder Konfigurationsereignissen, die angeben, dass eine Zeitplan- oder eine Konfigurationsänderung verlangt, dass ein abgeänderter Berechnungsgraph verwendet wird. Der abgeänderte Berechnungsgraph kann strukturell anders als der ursprüngliche sein, und/oder kann unterschiedliche Schwellwertwerte haben. Da der erste Berechnungsprozess in Echtzeit arbeitet, aber der zweite Prozess historische Arbeit durchführt, kann es passieren, dass der zweite Prozess unter Verwendung eines anderen Berechnungsgraphen als der des ersten Prozesses rechnet. Falls z. B. eine Konfigurationsänderung zu einem bestimmten Zeitpunkt passiert ist, die einen Berechnungsgraph B anstelle eines früheren Berechnungsgraphen A benötigt, dann wird für einige Zeit der erste Prozess den Berechnungsgraph B für das Verarbeiten der Echtzeitdaten berechnen, wohingegen der zweite Prozess weiterhin seine Neuberechnung auf dem vorhergehenden Berechnungsgraph A basiert.
  • Sobald diese im zweiten Prozess durchgeführte Berechnung den ersten Prozess eingeholt hat, wird die möglicherweise inexakte QoS-Angabe, die vom ersten Prozess während eines vorhergehenden Datenquellenfehlers berechnet wurde, durch eine genauere QoS-Angabe des zweiten Prozesses ersetzt, in dem die wegen eines Datenquellenfehlers verzögerten Daten berücksichtigt wurden, und die beiden Prozesse werden in einen Prozess zusammengeführt. In einigen der Ausführungsformen wird dies erreicht durch Synchronisieren des ersten Prozesses mit dem zweiten Prozess und anschließend Aussetzen des zweiten Prozesses. Zum Beispiel sendet der zweite Prozess kontinuierlich Synchronisationsanfragen, die den Zeitstempel des Berechnungszyklus enthalten, der gerade durchgeführt wird, an den ersten Prozess. Der erste Prozess vergleicht den empfangenen Zeitstempel mit dem Zeitstempel seines eigenen gerade durchgeführten Berechnungszyklus. Falls die Zeitstempel gleich sind, wird die Anfrage akzeptiert und der Synchronisationsprozess wird angestoßen (sollte der Zeitstempel des ersten Prozesses neu sein, wird die Anfrage auch akzeptiert, aber der zweite Prozess wird für eine Weile gestoppt, und der Synchronisationsprozess wird nur angestoßen, wenn beide Zeitstempel gleich sind). Im zweiten Synchronisierungsprozess werden die Werte der Entitäten des aktuellen Berechnungszykluses im Berechnungsgraph und alle akkumulierten Werte etc. des zweiten Prozesses zu den entsprechenden Entitäten des ersten Prozesses kopiert. Jedoch werden die vom zweiten Prozess gespeicherten Metrikwerte und Zwischenresultate gelöscht, und der zweite Prozess wird dann ausgesetzt. Alternativ ersetzt in anderen Ausführungsformen der zweite Prozess den ersten Prozess, wenn der zweite Prozess den ersten Prozess eingeholt hat.
  • Wie oben erwähnt, werden in einigen der Ausführungsformen alle Datenpunkte für eine ausreichende Zeitdauer gespeichert, ungeachtet dessen, ob eine Datenquelle tatsächlich nicht-verfügbar wurde oder nicht. In solchen Ausführungsformen besteht kein Bedarf für das QoS-Managementsystem, sich einer Datenquellen-Nichtverfügbarkeit in Echtzeit bewusst zu werden; stattdessen kann dieses Bewusstsein auch verzögert sein, wie die verzögerten Daten. Zum Beispiel wäre es ausreichend für das QoS-Managementsystem, sich nur rückblickend einem Datenquellenfehler bewusst zu werden durch den verzögerten Empfang der Daten, nachdem die Datenquelle wieder verfügbar wurde.
  • In anderen Ausführungsformen jedoch werden Datenpunkte und/oder Zwischenergebnisse, die im ersten Prozess berechnet wurden, nur nach Detektierung einer Datenquellen-Nichtverfügbarkeit gespeichert. In diesen Ausführungsformen wird ein Datenquellenfehler vom QoS-Managementsystem detektiert, kurz nachdem er tatsächlich auftrat. Mit anderen Worten, obwohl das QoS-Managementsystem nicht verzögerte Daten in seinem Echtzeitberechnungsprozess umfasst, wird ihm nichtsdestotrotz eine Datenquellen-Nichtverfügbarkeit in Echtzeit oder nahezu in Echtzeit bewusst.
  • In einigen der Ausführungsformen mit periodisch sendenden Datenquellen basiert diese Detektierung auf einer Datenquellenperiodizität eines Interterenzmechanismus. Falls z.B. plötzlich keine Daten mehr aus einer normal periodischen Datenquelle empfangen werden, schließt das QoS-System daraus, dass die Datenquelle nicht-verfügbar wurde.
  • In anderen Ausführungsformen kann die Periode der Datenquellen zu lang sein, um für eine Fehlerinferenz verwendet zu werden, oder die Datenquellen können ihre Daten auf asynchrone Weise schicken, d.h. ohne Anfrage vom QoS-Managementsystem und ohne Periodizität. Zum Beispiel kann eine asynchrone Datenquelle nur einen Datenwert schicken, wenn ein Netzwerkelement, das sie überwacht seinen Zustand von "verfügbar" auf "nicht-verfügbar" ändert, oder umgekehrt; falls keine solche Statusänderung in dem überwachten Netzwerkelement geschieht, wird so eine Datenquelle für eine lange Zeitdauer ruhig sein. Folglich gibt die Anwesenheit von Daten aus einer asynchronen Datenquelle nicht an, dass die Datenquelle nicht-verfügbar ist.
  • Um die Verfügbarkeit von Datenquellen zu überprüfen, werden in einigen der Ausführungsformen die Datenquellen von Zeit zu Zeit vom QoS-Managementsystem gepollt. In einigen Ausführungsformen wird das Polling periodisch durchgeführt, in kurzen Intervallen (z.B. alle 10 Sekunden), und wird daher auch "heartbeat polling" genannt. In einigen der Ausführungsformen bedeutet "Polling" das Senden einer speziellen Anfrage, ob die Datenquelle verfügbar ist. Eine gepollte Datenquelle gibt eine Antwort zurück, die angibt, ob die Datenquelle verfügbar ist oder nicht. Im Fall eines Fehlers des Netzwerkes zwischen Datenquelle und QoS-Managementsystem kann die Polling-Kommunikation auch scheitern; das QoS-Managementsystem folgert dann eine Datenquellen-Nichtverfügbarkeit aus der Abwesenheit einer Polling-Antwort. Polling-Anfragen, und die von den Datenquellen zurückgegebenen Antworten sind typischerweise kleiner und können schneller verarbeitet werden als komplexere Anfragen, wie Anfragen Daten zu schicken od. dgl. Nichtsdestotrotz wird in einigen der Ausführungsformen die Verfügbarkeit von Datenquellen überprüft durch Senden von Anfragen an sie, Daten zu senden, anstatt spezialisierte Polling-Anfragen. Falls eine Datenquelle nicht auf eine Polling-Anfrage antwortet oder in Antwort auf eine Polling-Anfrage angibt, dass sie nicht-verfügbar ist, wird der zweite Prozess angestoßen. Wie oben erklärt, führt der zweite Prozess noch keine Neuberechnung durch, da die Daten von der nicht-verfügbaren Datenquelle noch nicht verfügbar sind, aber veranlasst, dass die unverzögerten Datenpunkte und/oder Zwischenergebnisse des ersten Berechnungsprozesses gespeichert werden, zumindest insoweit als sie das Resultat des ersten Berechnungsprozesses betreffen. Die Neuberechnung, die Teil des zweiten Prozesses ist, beginnt später nach Empfang der verzögerten Daten.
  • Wie im Kontext asynchroner Datenquelle klar ist, impliziert ein Fehler einer solchen Datenquelle nur eine mögliche Datenverzögerung, aber bedeutet nicht notwendigerweise, dass ein Datenwert tatsächlich verzögert ist. Da eine asynchrone Datenquelle nur ein Datum senden kann, in dem Fall eines "Ereignisses" (z.B. ein Statuswechsel) wird kein Datenwert geschickt und folglich wird kein Datenwert tatsächlich verzögert sein, falls keine Statusänderung während der Datenquellen-Nichtverfügbarkeitsperiode geschieht. Folglich ist in solchen Fällen die Echtzeitberechnung trotz der Datenquellen-Nichtverfügbarkeit korrekt. Jedoch die Tatsache, dass es keine Ereignisdaten gab, die eine Statusänderung während der zweiten Datenquellen-Nichtverfügbarkeitsperiode angaben, wird erst bekannt werden, wenn die Datenquelle wieder verfügbar ist, weil dies aus der Tatsache gefolgert werden kann, dass die Datenquelle, nachdem sie wieder verfügbar wurde, keinen verzögerten Datenpunkt schickt; folglich, obwohl die Resultate des ersten und zweiten Prozesses gleich sind, wird die Gewissheit, dass das Resultat des ersten Berechnungsprozesses korrekt ist, nur vom zweiten Prozess bereitgestellt.
  • Wenn eine vorher nicht-verfügbare Datenquelle wieder verfügbar wird, beginnt sie die Datenpunkte an das QoS-Managementsystem weiterzuleiten, die während ihrer Nichtverfügbarkeitsperiode gepuffert wurden, falls welche vorlagen. Jedoch im Fall einer asynchronen Datenquelle weiß das QoS-Managementsystem per se nicht die Anzahl verzögerter Datenpunkte, die es empfangen sollte. Deshalb sendet in einigen der Ausführungsformen die Datenquelle entweder automatisch oder auf Anfrage vom QoS-Managementsystem eine Angabe der Anzahl verzögerter Datenpunkte oder alternativ ein Ende-der-Übertragung Angabe, dass alle verzögerten Datenpunkte übertragen wurden. Falls kein Datenpunkt verzögert war, wird die Zahlangabe Null sein, oder das Ende der Übertragungsangabe wird ohne irgendwelche vorher übertragenen Datenpunkte geschickt. Solch eine Angabe gibt dem QoS-Managementsystem Auskunft, dass kein Ereignis während der Nichtverfügbarkeitsperiode geschah. Da diese Information verzögert ist, soll sie auch durch den Ausdruck "verzögerte Daten" abgedeckt werden, der hierin verwendet wird, und der Empfang dieser Information soll durch den Ausdruck "Empfang verzögerter Daten" abgedeckt werden.
  • Schließlich sollte erwähnt werden, dass die Abwesenheit von Ereignissen während einer Verfügbarkeitsperiode auch aus der Tatsache hergeleitet werden kann, dass keine Daten empfangen werden, wenn die Datenquelle wieder verfügbar ist, ohne irgendeine Zahlangabe oder Ende-der-Übertragung Angabe. Wegen dieses Informationsgehalts, der verzögert empfangen wird, kann ein "kein Empfang" von Datenpunkten deshalb als ein "Empfang von verzögerten Daten" in der hierin verwendeten Sprache angesehen werden.
  • Einige der Ausführungsformen des Computerprogramms sind auf einem beliebigen maschinenlesbaren Medium enthalten, das den Programmcode speichern oder codieren kann. Der Ausdruck "maschinenlesbares Medium" soll dementsprechend aufgefasst werden, dass es z.B. Festzustandsspeicher und entfernbare und nicht entfernbare optische und magnetische Speichermedien umfasst. In anderen Ausführungsformen liegt das Computerprogramm in der Form eines propagierten Signals vor, das eine Darstellung des Programmcodes umfasst, welches in zunehmendem Maße der übliche Weg wird, Software zu verteilen. Das Signal wird z.B. auf einer elektromagnetischen Welle getragen, z.B. über ein Kupferkabel übertragen oder durch die Luft, oder eine Lichtwelle, die über eine optische Faser übertragen wird. Der Programmcode kann Maschinencode sein oder ein anderer Code, der in Maschinencode konvertiert werden kann, wie Quellcode in einer Mehrzweckprogrammiersprache, z.B. C, C++, Java, C# etc. Die Ausführungsformen eines Computersystems können kommerziell verfügbare mit dem Programmcode programmierte Allzweckcomputer sein.
  • 1: QoS-Managementsystemarchitektur:
  • Kehren wir nun zu 1 zurück, die die Architektur eines QoS-Managementsystems 1 und eines gemanagten IT-Netzwerks 2 veranschaulicht. Das gemanagte IT-Netzwerk 2 umfasst mehrere verbundene Netzwerkelemente 3, wie Host (Server, Arbeitsplatzrechner, Speichergeräte, Ausgabegeräte etc.) und Netzwerk-verbindende Geräte (Switche, Router, etc.). Das Netzwerk 2 wird von Netzwerkmanagementkomponenten 4 gemanagt, die Komponenten einer integrierten Managementplattform wie HP OpenView, und/oder alleinstehende Softwaretools sind. Die Managementtools 4 sind Fehler- und Leistungsmanagementtools, z.B. können sie Nichtverfügbarkeit detektieren, Fehler, drohende Fehler, schlechtes Funktionieren, die Leistungsprobleme, Latenz etc. der Netzwerkelemente 2 und der vom Netzwerk 2 bereitgestellten Anwendungen und Dienste. Die Managementkomponenten 4 erhalten entweder Informationen aus den Netzwerkelementen 3 auf asynchrone Weise, d.h. in der Form unaufgeforderter Benachrichtigungen (z.B. genannt "Traps" in SNMP), die von den Netzwerkelementen 3 geschickt werden, wie es z.B. in einem Ereignis einer Statusänderung, oder auf synchrone Weise, z.B. periodisch, oder als eine Antwort aus einem Netzwerkelement 3 zu einem entsprechenden Anfrage aus einer Managementkomponente 4 geschehen würde. Die Managementkomponenten 4 beschaffen die Information entweder auf asynchrone Art und Weise (z.B. durch den Empfang einer Benachrichtigung, dass ein Fehler stattgefunden hat in einem bestimmten Netzwerkelement 3) oder auf eine komplexe Art und Weise (wie z.B. in einer HTTP Server-Antwortzeitbestimmung, in der eine Managementkomponente 4 eine HTTP Testanfrage an ein Netzwerkelement 3 schickt, das ein HTTP Server in diesem Beispiel ist und misst die vergangene Zeit bis eine HTTP-Antwort vom HTTP-Server empfangen wird).
  • Da die Managementtools 4 das Funktionieren und Leistung des Netzwerks 2 und seiner Anwendungen und Dienste überwachen, können sie auch die Daten, die Metrikwerte bereitstellen, die von dem QoS-Managementsystem 1 benutzt werden, um die QoS objektiv zu bestimmen und zu überprüfen, ob die erreichte QoS den SLA erfüllt. Die eigentlichen Datenquellen sind Dateninterfaces, genannt "Metrikadapter" 5, an die Managementtools 4. Die Metrikwerte sind zeitgestempelt, entweder vom Managementtool 4 oder dem Metrikadapter 5, um den Zeitpunkt anzugeben, an dem die Daten erzeugt wurden. Wie oben erwähnt, sind die zeitgestempelten Metrikwerte "Daten", veranschaulicht bei 6 in 1. Die Metrikadapter 5 sammeln die Datenpunkte 6 aus ihrem Managementtool 4 und übertragen sie an einen Datensammler 7 des QoS-Managementsystems 1, das mehrere Datenempfänger 8 hat. Die Metrikadapter 5 und der Datensammler 7 sind durch ein Netzwerk miteinander verbunden, das Teil des Netzwerks 2 sein kann, oder eines anderen Local Area oder Wide Area Netzwerks. Die Übertragung der Datenpunkte 7 wird durchgeführt mit einem verbindungsbasierten Store- und Forwardmechanismus, z.B. unter Verwendung des HTTP-Protokolls. Der verbindungsbasierte Store- and Forwardmechanismus garantiert die Lieferung von Daten (gesendet in der Form von Datenpaketen); folglich wird sichergestellt, dass die Daten aus einem Metrikadapter 5 nicht irgendwo verloren gehen, sondern am Datenkollektor 7 empfangen werden. Falls ein Datenpunkt 6 nicht sofort geschickt werden kann, z.B. wegen eines Netzwerkfehlers wird er im ausgehenden Metrikadapter 5 lokal gepuffert bis eine erfolgreiche Lieferung möglich ist. Zu diesem Zweck haben die Metrikadapter 5 einen Puffer 9 zum Speichern gegenwärtig nicht lieferbarer Datenpunkte 6, und einen Datensender 10. Infolge des wegen des verbindungsbasierten Store- und Forwardmechanismus können die Datenpunkte 6 verzögert sein, aber nicht verloren.
  • Eine Verzögerung in der Übertragung eines Datenpunkts 6 aus einem Managementtool 4 an das QoS-Managementsystem kann aus mehreren Gründen auftreten. Zum Beispiel kann ein Fehler eines Datensenders 10 innerhalb eines Metrikadapters, genannt Metrikadapterfehler 11, ein Fehler in der Netzwerkverbindung zwischen einem Metrikadapter 5 und dem Datenkollektor 7, genannt Verbindungsfehler 12, oder ein Fehler eines Datenempfängers innerhalb des Datenkollektors 7, genannt Datensammlerfehler 13 stattfinden. Alle Datenpunkte 6, die während einer solchen Fehlerperiode erzeugt werden, werden im Puffer 9 des betroffenen Metrikadapters 5 gespeichert und werden zum Datenkollektor 7 übertragen, wenn der Datensender 10, die Netzwerkverbindung oder der Datenempfänger 8 wieder in Betrieb ist. In anderen Ausführungsformen kann ein Fehler auch in einer Managementkomponente auftreten, als ein Resultat dessen Datenpunkte 6 "tiefer" in der Managementkomponente 4 gepuffert werden und werden dem Metrikadapter 5 erst später bereitgestellt, der sie verspätet an den Datenkollektor 7 weiterleitet.
  • Der Datenkollektor 7 empfängt die unverzögerten und verzögerten Datenpunkte 6, wobei jeder einen Metrikwert und einen Zeitstempel aus den Metrikadaptern 5 enthält. Er sammelt die Datenpunkte 6 aus allen Metrikadaptern 5 und leitet sie an ein Berechnungssystem 14 weiter. Im Berechnungssystem 14 ist normalerweise, falls keine Verzögerung in der Übertragung von Datenpunkten stattgefunden hat, eine erste Berechnungsengine 15 aktiv. Falls Verzögerung aufgetreten ist und eine neue Berechnung wegen eines verzögerten Datums durchgeführt wird, ist eine zweite Berechnungsengine 16 ebenfalls aktiv. In einigen der Ausführungsformen sind die Berechnungsengine 15, 16 eigentlich logische Objekte nämlich Prozesse, die von einem oder mehreren Prozessoren des Berechnungssystems 14 ausgeführt werden. In anderen Ausführungsformen sind die ersten und zweiten Berechnungsengines 15, 16 physisch unterschiedliche Einheiten, z.B. ein dedizierter Prozessor, der geeignet programmiert ist, ist die erste Berechnungsengine 15 und ein anderer Prozessor, der ebenfalls geeignet programmiert ist, ist der zweite Berechnungsengine 16. In einigen Ausführungsformen, in denen die Berechnungsengines Prozesse sind, die von demselben Prozessor oder Prozessorsystem ausgeführt werden können, ist der zweite Berechnungsengine 16 nicht immer präsent; stattdessen wird der Prozess, der ihn repräsentiert nur initiiert, wenn eine Datenverzögerung detektiert wird und beendet wenn die QoS-Neuberechnung beendet wurde, wie unten erklärt wird.
  • Das Berechnungssystem 14 berechnet QoS-Parameter in Berechnungszyklen, auf der Grundlage der Datenpunkte 6 aus dem Datensammler 7. Die erste Berechnungsengine 15 berechnet die QoS-Parameter in Echtzeit; d.h. ohne Einschließen verzögerter Datenpunkte 6 in die Berechnungszyklen. Folglich kann die QoS-Parameter, die von der ersten Berechnungsengine 15 erhalten wurden, inexakt sein. Im Gegensatz dazu umfasst die zweite Berechnungsengine 16 die verzögerten Datenpunkte 7 in den Berechnungszyklen und stellt deshalb exaktere aber verzögerte QoS-Parameter bereit. Die Berechnungsengines 15, 16 umfassen auch Resultatakkumulatoren, die die in den Berechnungszyklen über die Zeit hinweg erhaltenen QoS-Parameter akkumulieren; die akkumulierten QoS-Parameter stellen eine objektive Angabe bereit, ob die innerhalb der Akkumuiationsperiode erreichte QoS die SLA erfüllt (falls die Akkumulationsperiode eine vergangene Erfüllungsperiode ist) oder sie erfüllen wird (falls die Akkumulationsperiode ein erster Teil einer aktuellen Erfüllungsperiode ist).
  • Berechnete QoS-Parameter und akkumulierte QoS-Parameter und, falls benötigt, Datenpunkte 6 aus dem Datensammler 7 und Zwischenberechnungsergebnisse können nicht nur zwischen der ersten und zweiten Berechnungsengine 15, 16 ausgetauscht werden, sondern werden auch über einen Datenexporteur 17 in einem Data Warehouse 18 gespeichert. Die akkumulierten QoS-Parameter werden auch übertragen und in einem Dienstgütemanagementserver (SLM) 19 gespeichert. Eine überwachende graphische Benutzerschnittstelle (GUI) 20 zeigt die akkumulierten QoS-Parameter in Echtzeit (von Zeit zu Zeit durch die exakteren Neuberechnungsresultate korrigiert) an, um einem Netzwerkoperator zu ermöglichen, den aktuellen QoS-Erfüllungsstatus zu bewerten und sofort zu intervenieren, wenn eine QoS Nichterfüllung bevorstehend ist. Der SLM-Server 19 ist auch mit einer Konfigurationsmanagement-Datenbank (CMDB) 21 und einem Konfigurationsbroker 22 verbunden. Die CMDB 21 speichert Daten, die Berechnungsgraphen darstellen, entsprechend derer das Berechnungssystem 14 die QoS-Parameter und Daten berechnet und akkumuliert, die die relevante Dienstgütevereinbarung (Schwellwerte, Konfigurationsdaten etc.) darstellen. Der Konfigurationsbroker 22 managt Konfigurationsänderungen und definiert eine aktuelle gültige Konfiguration. Konfigurationsänderungen sind alle Veränderungen, die den Berechnungsgraph beeinflussen, der definiert, was vom Berechnungssystem 14 zu berechnen ist; solche Konfigurationsänderungen können Veränderungen im Netzwerk 2, den Managementtools 4 und/oder der aktuell gültigen QoS-Definition sein (z.B. kann eine Dienstgütevereinbarung strengere Verfügbarkeitsanforderungen während normalen Arbeitsstunden als während anderen Zeitperioden definieren; entsprechend wird sich der Berechnungsgraph zu Beginn und am Ende der Arbeitsstunden verändern).
  • Außer seiner Fähigkeit QoS in Echtzeit zu überwachen, ist das QoS-Managementsystem 1 auch in der Lage, konkrete QoS-Erfüllungsreports bereitzustellen, z.B. Reports, die am Ende einer Erfüllungsperiode (z.B. am Ende jedes Monats) angeben, ob die QoS während der Erfüllungsperiode die Anforderungen erfüllte, die im SLA dargelegt wurden. Eine QoS-Reportkomponente 23 kann automatisch solche Reports unter Verwendung der akkumulierten QoS-Parameter erzeugen, die im Data Warehaus 18 gespeichert sind. Da die QoS-Reportkomponente 23 nicht Echtzeitanforderungen unterliegt, verwendet sie typischerweise nur die exakten akkumulierten QoS-Parameter, d.h. diejenigen, die von der Neuberechnung der zweiten Engine korrigiert wurden.
  • 2: Beispielhafte QoS Überwachung:
  • Eine beispielhafte Ausgabe in der Überwachungs-GUI 209 des QoS-Managementsystems in 1 ist in 2 dargestellt, die einen berechneten QoS-Parameter im zeitlichen Verlauf zeigt. Im gezeigten Beispiel wird angenommen, dass der QoS-Parameter die Verfügbarkeit eines Dienstes ist, der, z.B. ein logisches Und der Verfügbarkeit mehrerer einzelner Netzwerkelemente sein kann. Die horizontale Achse gibt die Zeit an, wohingegen die vertikale Achse spezifiziert, ob der Service "up" (an) oder "down" (aus) ist. In dem Beispiel von 2 wird eine Nichtverfügbarkeit des Dienstes von 4:30 A.M. bis 5:30 A.M. und von 7:00 A.M. bis 8.30 A.M. detektiert und in der Überwachungs-GUI 20 in Echtzeit angezeigt. Die Verfügbarkeit wird für kurze Zeitintervalle in der Größenordnung bestimmt, die von Sekunden bis zu einer Minute reicht (z.B. 31 Sekunden), muss aber nicht in der GUI 19 mit so einer feinen Auflösung angezeigt werden. Zwei Typen von Nichtverfügbarkeit werden hierin diskutiert, die unterschieden werden sollten: (i) die Nichtverfügbarkeit eines Dienstes oder Netzwerkelements, das für die QoS-Bestimmung relevant ist und deshalb dem QoS-Managementsystem bekannt sein sollte; (ii) die Nichtverfügbarkeit einer Datenquelle für Metrikwerte (die eine Nichtverfügbarkeit des Typs (i) repräsentieren kann), als ein Resultat, infolge dessen die Metrikwerte temporär nicht an das QoS-Managementsystem übermittelt werden, so dass dem QoS-Managementsystem temporär die Information nicht bekannt sein kann, die durch diese Metrikquelle dargestellt wird. Falls z.B. ein Zusammentreffen der Nichtverfügbarkeiten des Typs (i) und Typs (ii) auftritt, kann dem QoS-System nicht bekannt sein, dass der Dienst oder das Netzwerkelement nicht verfügbar ist.
  • 2b zeigt die akkumulierte Verfügbarkeit des Dienstes in dem Beispiel von 2a. Die vertikale Achse gibt hier die akkumulierte Verfügbarkeit des Dienstes an ausgedrückt als ein Prozentwert einer Gesamterfüllungsperiode, z.B. ein Monat. Genauer gesagt gibt die akkumulierte Verfügbarkeit zu einem Zeitpunkt t an 100% – (nichtverfügbarkeit_von_beginn_bis_t/gesamt_erfüllungs_periode). Klarerweise nimmt die akkumulierte Verfügbarkeit monoton ab, und ein Vergleich mit einem SLA-Schwellwert (einem SLO) kann am Ende der betrachteten Periode angeben, ob der SLA erfüllt wurde oder nicht. Im Beispiel von 2b wird angenommen, dass eine akkumulierte Verfügbarkeit von wenigstens 99% am Ende der Periode benötigt wird. Die gezeigte akkumulierte Verfügbarkeitskurve beginnt bei 100% (unter der Annahme, dass keine Nichtverfügbarkeit bisher passiert ist und nimmt während jeder der Nichtverfügbarkeitsperioden von 2a ab. Solch eine Kurve stellt dem Operator eine Echtzeitanzeige dessen bereit, wie das System den SLA-Schwellwert erreicht. Im gezeigten Beispiel hat die Kurve noch nicht den Schwellwert unterlaufen.
  • 3: QoS-Bestimmungsprozess ohne Datenquellen- Nichtverfügbarkeit:
  • 3 veranschaulicht die Berechnung von QoS-Parameterwerten, wie die Verfügbarkeit von 2 in einem Fall, in dem alle Datenpunkte 6 in Echtzeit an das QoS-Managementsystem übertragen werden, d.h. ohne irgendwelche unregelmäßige Verzögerung, d.h. in der Abwesenheit eines Metrikadapterfehlers 11, eines Verbindungsfehlers 12, eines Datensammlerfehlers 13, od. dgl. Dementsprechend brauchen keine verzögerten Datenpunkte berücksichtigt zu werden, alle Berechnungen werden erst von der ersten Berechnungsengine 15 gemacht, und die zweite Berechnungsengine 16 wird nicht initiiert (oder sie ist inaktiv) unter der Annahme natürlich, dass keine verzögerten Datenpunkte aus vorherigen Verzögerungen noch verarbeitet werden. Die Zeitachse ist in Berechnungszyklen 24 unterteilt. Jeder Berechnungszyklus 24 verwendet einen oder mehrere Metrikwerte (in 3: drei Werte) als Eingabe, von denen jeder als ein Dreieck auf der Zeitachse angegeben ist. Die Berechnungsgraphen 25 sind in 3 nur auf veranschaulichende Art und Weise oberhalb der Zeitachse gezeigt. Dies impliziert nicht, dass die Berechnungsgraphen 25 von links nach rechts ausgewertet werden, oder dass die Auswertung startet, wenn der erste Datenpunkt empfangen wird. Stattdessen wird ein Berechnungsgraph 25 typischerweise von unten nach oben ausgewertet. Außerdem hat ein Berechnungszyklus 25 normalerweise eine Empfangszeitbegrenzung, an dessen Ende alle im Zyklus 25 verwendeten Datenpunkte empfangen sein müssen, und eine Berechnungsperiode im Anschluss an die Empfangszeitbegrenzung, in der die eigentliche Berechnung durchgeführt wird.
  • 3 zeigt ein Beispiel eines "getakteten Systems", in dem alle Datenquellen, d.h. die Metrikadapter (MA) 5.1, 5.2 und 5.3 in 3 Datenpunkte 6 auf periodische Art und Weise erzeugen; im Beispiel von 3 erzeugt jede Datenquelle für jeden Berechnungszyklus 24 einen Datenpunkt 6. Folglich ist in der Abwesenheit von Datenverzögerungen eine komplette Menge neuer Metrikwerte für alle Eingabeentitäten des Berechnungsgraphen 25 für alle Berechnungszyklen 24 verfügbar. Im allgemeinen kann ein Metrikadapter 5 mehr oder weniger als einen Metrikwert in einem Berechnungszyklus 24 bereitstellen. Zum Beispiel senden in einigen Ausführungsformen einige oder alle der Metrikadapter 5 Datenpunkte 6 auf asynchrone Weise; z.B. senden sie nur einen Datenpunkt 6, falls eine Statusänderung aufgetreten ist (siehe z.B. 6). Wie oben erklärt, wird, falls in einem Berechnungszyklus 24 keine neuen Metrikwerte vorliegen, obwohl ein Wert in der Berechnung verwendet werden soll, in einigen Ausführungsformen der Metrikwert, der vom letzten entsprechenden empfangenen Datenpunkt 6 angegeben wird, als gültig betrachtet und in den Berechnungszyklen 24 verwendet, bis ein neuer entsprechender Datenpunkt empfangen wird. Die Metrikwerte der Datenpunkte 6 werden in jedem Berechnungszyklus 24 entsprechend eines Berechnungsgraphen 25 verarbeitet. Ein Berechnungsgraph 25 ist eine Widerspiegelung des SLO im SLA (genauer gesagt: jenes Teils des SLO, der sich auf einzelne Berechnungszyklen bezieht) und definiert, wie die gemessene Metrikwerte kombiniert werden müssen, um einen QoS-Parameter oder mehrere QoS-Parameter unterschiedlichen Typs für jeden Berechnungszyklus zu generieren. An dessen Spitze akkumuliert eine Akkumulationsfunktion 26 die in den einzelnen Berechnungszyklen 24 berechneten QoS-Parameter und erzeugt dadurch einen akkumulierten QoS-Parameter, z.B. eine akkumulierte Verfügbarkeitsangabe, wie in 2b dargestellt ist.
  • 4: QoS-Bestimmungsprozess mit Datenquellen-Nichtverfügbarkeit, aber mit einem Neuberechnungsprozess:
  • 4 veranschaulicht mögliche Folgen einer Datenquellen-Nichtverfügbarkeit, falls keine neue Berechnung durchgeführt wird. In diesem Beispiel werden nur zwei Metrikwerte in jedem Berechnungszyklus angegeben, und der Berechnungsgraph 25 kombiniert folglich zwei Metrikwerte (anstelle von drei, wie in 3). Zum Beispiel stellen die beiden Metrikwerte die Verfügbarkeit von zwei Netzwerkelementen 3 (1) durch Werte U (für "Up") oder D (für "Down") dar, und der Berechnungsgraph 25 kombiniert sie durch ein logisches UND, so dass der resultierende QoS-Parameter die kombinierte Verfügbarkeit angibt. Datenpunkte 6, die in Echtzeit ankommen, werden als Dreiecke angegeben, und Datenpunkte 6, die verzögert sind (z.B. wegen eines Fehlers 11, 12 oder 13) werden als "X" angegeben, wo sie regulär angekommen wären, und durch kleine Quadrate, wo sie tatsächlich nach der Verzögerung ankamen. In jedem der Berechnungszyklen 24 wird ein Datenpunkt aus jedem der beiden Metrikadapter 5.1, 5.2 erwartungsgemäß ankommen. Im gezeigten Beispiel sind die Datenpunkte 6 aus dem ersten Metrikadapter niemals verzögert und haben immer den Wert U ("Up"). Im ersten Berechnungszyklus 24 gibt der vom Metrikadapter 5.2 gesendete Metrikwert an, dass das Netzwerkelement an ist, aber im zweiten Berechnungszyklus 24 sendet der zweite Metrikadapter 5.2 eine Angabe, dass es ausgeschaltet ist (angegeben durch "D"), da in der Zwischenzeit das Netzwerkelement 3 nicht-verfügbar wurde. Es wird nun angenommen, dass kurz nachdem ein Metrikadapterfehler 11, ein Verbindungsfehler 12 oder ein Datensammlerfehler 13 stattfindet, so dass die Datenpunkte 6 aus dem Metrikadapter 5.2 nicht mehr vom Datensammler 7 in Echtzeit empfangen werden. Zwei Zyklen 24 später wird dieser Fehler 11, 12, 13 wieder entfernt. Obwohl die irregulär angekommenen übertragenen Datenpunkte 6 aus dem dritten und vierten Zyklen 24 nicht verloren sind, sondern nach der Verzögerung im fünften Zyklus 24 empfangen werden, werden sie nicht mehr berücksichtigt, da ihre Zeitstempel angeben, dass der entsprechende Metrikwert für vorhergehende Berechnungszyklen 24 erzeugt wurde. In den Zyklen 24 mit einem fehlenden Metrikwert wird von einem typischen Berechnungssystem angenommen, dass sich nichts geändert hat; d.h. es wird angenommen, dass der Metrikwert aus dem Metrikadapter 5.2 "D" war für sowohl den dritten als auch den vierten Zyklus 24, da er im zweiten Zyklus 24 "D" war. Es wird jedoch nun angenommen, dass das Netzwerkelement 3 schon wieder im dritten Zyklus 24 verfügbar wurde; dann sind die angenommenen Werte "D" und "D", die vom Berechnungssystem für den dritten und vierten Zyklus 24 wegen des Fehlers 11, 12 oder 13 verwendet werden sollten, falsch. Als ein Ergebnis wird die von der akkumulierten Funktion 26 erhaltene akkumulierte Verfügbarkeit inexakt sein; sie wird eine geringere akkumulierte Verfügbarkeit als die eigentliche angeben.
  • Aus Gründen der Vollständigkeit sollte erwähnt werden, dass es natürlich eine reguläre Verarbeitungsverzögerung zwischen dem Ende des Zeitfensters gibt, in dem die zu einem Berechnungszyklus 24 gehörenden Datenpunkte 6 empfangen werden und dem Moment, wenn das Berechnungsresultat, das auf ihnen basiert, d.h. ein QoS-Parameter, erhalten und zum bereits akkumulierten QoS-Parameter hinzugefügt wird. Aus Gründen der Einfachheit jedoch wird der Effekt des Metrikeingabewerts auf den akkumulierten QoS-Parameter als ein unmittelbarer gezeigt z.B. wird in 3 der Wert "D" im Datenpunkt 6 von Metrikadapter 5.2 im zweiten Berechnungszyklus 24 gezeigt, um den akkumulierten QoS-Parameter in demselben Berechnungszyklus zu verringern, wohingegen dies tatsächlich erst im nächsten oder darauffolgenden Berechnungszyklus geschieht.
  • 5: QoS-Bestimmungsprozess mit Neuberechnung:
  • 5 veranschaulicht einen QoS-Bestimmungsprozess in der beispielhaften Situation von 4, aber nun mit einem Neuberechnungsprozess. Zwei Prozesse werden in 5 gezeigt wie sie mit der Zeit fortschreiten, ein erster Prozess 27, der eine Echtzeitberechnung ausführt wie oben in Verbindung mit 4 erklärt wird, und ein zweiter Prozess 29. Solange keine Datenquellen-Nichtverfügbarkeit 11, 12, 13 beobachtet wurde, ist nur der erste Prozess 27 aktiv, aber der zweite Prozess 29 wurde noch nicht initiiert (oder ist untätig). Im Beispiel von 5 trifft dies auf die beiden ersten Berechnungszyklen zu, die als CC1 und CC2 bezeichnet werden. Die Echtzeitberechnung 28 berechnet den QoS-Parameter für diese Berechnungszyklen CC1 und CC2, und die Akkumulationsfunktion 26 akkumuliert die QoS-Parameter. Wie im Beispiel von 5 wird eine Datenquellen-Nichtverfügbarkeit 11, 12, 13 am Ende des zweiten Berechnungszykluses CC2 detektiert, woraufhin der zweite Prozess 29 gestartet wird. Da die Datenpunkte 26 von einer der Metrikentitäten, die die Eingabe der Berechnung bilden, nicht verfügbar sind (nämlich die Datenpunkte aus dem zweiten Metrikadapter 5.2) kann der zweite Prozess 23 nicht unmittelbar mit der Neuberechnung starten; stattdessen führt er vorbereitende Aktivitäten für die später durchzuführende Neuberechnung durch, wenn Datenpunkte, die aktuell nicht verfügbar sind, nach der Verzögerung empfangen werden. Zum Beispiel beginnt der zweite Prozess 29 einen speichernden Unterprozess 30, in dem die gesamte reguläre Information, die benötigt wird, um eine exakte Neuberechnung der QoS-Parameter und der akkumulierten QoS-Parameter durchzuführen, gespeichert wird. Im vorliegenden Beispiel werden die unverzögerten Datenpunkte aus dem Metrikadapter 5.1 gespeichert. Außerdem wird auch der letzte Werte des akkumulierten QoS-Parameters, der von dem ersten Prozess 27 berechnet wurde, der nicht von der Datenquellen-Nichtverfügbarkeit 11, 13 beeinträchtigt wurde, gespeichert; er ist der Startwert der Akkumulation, die später vom zweiten Prozess 29 ausgeführt wird. Die zwei Prozesse 27, 29 sind nebenläufige Prozesse.
  • Der erste Prozess 27 fährt fort mit dem Ausführen der Echtzeitberechnung 28 in den folgenden Berechnungszyklen CC3, CC4, ... und Berechnen des akkumulierten QoS-Parameters mittels der Akkumulationsfunktion 26, die zu einem Ergebnis führt, das auf der einen Seite in Echtzeit erhalten wird, aber auf der anderen Seite wegen der Datenquellen-Nichtverfügbarkeit 11, 12, 13, wie in Verbindung mit 4 beschrieben wurde, inexakt ist.
  • Im vorliegenden Beispiel wird die nicht-verfügbare Datenquelle (d.h. der Metrikadapter 5.2) nach dem vierten Berechnungszyklus CC4 wieder verfügbar. Die beiden Datenpunkte 6, die zur CC3 und CC4 gehören, die nicht rechtzeitig übertragen werden konnten und deshalb im Puffer 9 des Metrikadapters gepuffert wurden, werden nun zum Datensammler 7 als verzögerte Datenpunkte während des fünften Berechnungszykluses CC5 übertragen und werden auch vom speichernden Unterprozess 30 gespeichert. Der speichernde Unterprozess 30 speichert nun auch die neuen Datenpunkte 6 aus dem Metrikadapter 5.2, die nun auch auf reguläre Weise in den Berechnungszyklen CC5 bis CC7 empfangen werden. Sobald alle verzögerten Datenpunkte 6 empfangen wurden (d.h. zu Beginn des sechsten Berechnungszykluses des ersten Prozesses CC6) wird ein weiterer Unterprozess des zweiten Prozesses 29 gestartet, nämlich der Neuberechnungsprozess 31. Im Neuberechnungsprozess 31 werden die Berechnungszyklen 24 seit dem Auftreten der Datenquellen-Nichtverfügbarkeit 11, 12, 13 (d.h. die Berechnungszyklen CC3, CC4, ...) neu berechnet. In diesem Neuberechnungsprozess wird die gespeicherte reguläre Information (d.h. die gespeicherten Datenpunkte 6 aus dem ersten Metrikadapter 5.1) und die verzögerten Metrikdaten (d.h. die Datenpunkte 6 aus dem zweiten Metrikadapter 5.2, die im Metrikadapter 5.2 gepuffert wurden und dann nach der Verzögerung übertragen wurden) auf eine zeitkonsistente Art und Weise kombiniert, so dass diese Datenpunkte, die gemäß ihrer Zeitstempeln zum aktuell berechneten Berechnungszyklus 24 gehören, die Eingabe zum Berechnen in jedem Zyklus 24 bilden. Der in jedem Berechnungszyklus 24 erhaltene QoS-Parameter wird mit den gespeicherten akkumulierten QoS-Parametern unter Verwendung der Akkumulationsfunktion 26 kombiniert. Da der Neuberechnungsprozess 31 schneller voranschreitet als der Echtzeitberechnungsprozess 28, benötigt er weniger Zeit um einen Berechnungszyklus 24 auszuführen und holt den Echtzeitberechnungsprozess 28 ein. Im Beispiel von 5 benötigt er eine Zeitperiode, die zwei Echtzeitberechnungszyklen 24 entspricht, um fünf Berechnungszyklen neu zu berechnen. Im gezeigten Beispiel sind in den ersten beiden Berechnungszyklen nach der Initialisierung des zweiten Prozesses (CC3 und CC4) die Daten von MA 5.2 nicht verfügbar. Während des dritten Berechnungszyklus nach der Initialisierung (CC5) werden die Daten zum Datensammler 7 übermittelt, so dass der Neuberechnungsunterprozess 31 dann gestartet wird. Die verbleibenden beiden Berechnungszyklen (CC6 und CC7) werden für den Neuberechnungsunterprozess 31 benötigt, um den Echtzeitberechnungsprozess 28 einzuholen. Demzufolge, obwohl die Daten, die zu dreien der Berechnungszyklen (CC5 bis CC7) gehören, auf reguläre Weise empfangen werden, bilden diese Berechnungszyklen nicht einen Teil des Neuberechnungsunterprozesses 31, da die Zeit vom Beginn von CC5 bis zum Ende von CC7 benötigt wurde, um die verzögerten Daten zu erhalten, um die Neuberechnung durchzuführen und schließlich um den Echtzeit-Berechnungsprozess 28 einzuholen.
  • Wenn schließlich der Neuberechnungsprozess 31 den Echtzeit-Berechnungsprozess 28 eingeholt hat (d.h. am Ende von Berechnungszyklus CC7 in 5), wird eine Prozesszusammenführung 32 zweier Prozesse 27, 29 ausgeführt. Als ein Resultat wird der akkumulierte QoS-Parameter, der vom ersten Prozess 27 inexakt berechnet wurde, durch den exakteren akkumulierten vom zweiten Prozess 29 berechneten QoS-Parameter ersetzt. Außerdem fährt das QoS-Management 1 mit einem der beiden Prozesse 27, 29 fort, bis eine andere Datenquellen-Nichtverfügbarkeit 11, 12, 13 auftritt. Dies wird entweder durch Synchronisieren des ersten Prozesses 27 mit dem zweiten Prozess 29 und Suspendieren des zweiten Prozesses 29 erreicht, oder durch Ersetzen des ersten Prozesses 27 durch den zweiten Prozess 29.
  • 6: QoS-Bestimmungsprozess mit asynchronen Datenquellen:
  • In der Ausführungsform von 6 sind die Datenquellen nicht getaktet, sondern senden ihre Datenpunkte auf asynchrone Weise. In solch einem asynchronen System sendet ein Metrikadapter 5 einen Datenpunkt normalerweise nur, wenn ein "Ereignis" aufgetreten ist, d.h. ein Wechsel des Werts der Metrikentität, die mit dem fraglichen Metrikadapter assoziiert ist. Zum Beispiel wird in 6 angenommen, dass die Metrikadapter 5.1 und 5.2 Metrikwerte liefern, die die Verfügbarkeit von mit ihnen assoziierten Netzwerkelementen 3 repräsentieren. Das mit dem Metrikadapter 5.1 assoziierte Netzwerkelement 3 ist verfügbar bei t0, wird nicht verfügbar bei t4, verfügbar bei t6, nicht verfügbar bei t15 und verfügbar bei t20 (6a). Das mit Metrikadapter 5.2 assoziierte Netzwerkelement 3 ist verfügbar bei t0, wird nicht verfügbar bei t2, verfügbar bei t7, nicht verfügbar bei t13 und verfügbar bei t18 (6b). Folglich sendet in Abwesenheit eines Datenquellenfehlers 11, 12 oder 13 der erste Metrikadapter 5.1 Datenpunkte bei t0, t4, t6, t15 und t20 und der zweite Metrikadapter 5.2 sendet Datenpunkte bei t0, t2, t7, t13, t18. Tatsächlich tritt, wie unten beschrieben, eine Datenquellen-Nichtverfügbarkeit 11, 12, 13, die zu dem zweiten Metrikadapter 5.2 gehört, von t4 bis t13 auf, so dass Datenpunkte, die sich auf t6 und t13 beziehen, temporär im Metrikadapter 5.2 gepuffert werden und erst am Datensammler 7 nach der Verzögerung empfangen werden, wenn die Datenquelle wieder verfügbar ist; im Beispiel von 6 werden diese beiden Datenpunkte um t15 und t16 herum empfangen (6b).
  • Da die Datenpunkte 6 in auf einem ereignis-betriebene Weise und deshalb asynchrone Weise erzeugt werden, kann das QoS-Managementsystem nicht aus der Abwesenheit von Datenpunkten ableiten oder folgern, dass eine Datenquellen-Nichtverfügbarkeit 11, 12, 13 stattgefunden hat (wie es in einem getakteten System getan werden kann), stattdessen kann die Abwesenheit eines Datenpunkts, und wird normalerweise, aufgrund der Abwesenheit eines Datenpunkt erzeugenden Ereignisses sein. Um sich deshalb Datenquellen-Nichtverfügbarkeiten 11, 12, 13 bewusst zu werden, sobald sie auftreten, wird ein Polling-Prozess 33 permanent durchgeführt, in dem die Datenquellen regulär vom QoS-Managementsystem 1 gepollt werden, um ihre Verfügbarkeit zu verifizieren. In solch einem Heartbeat-Polling sendet das QoS-Managementsystem 1 periodisch Anfragen, ob die Datenquellen verfügbar sind, und eine gepollte Datenquelle gibt eine Antwort zurück, die angibt, ob sie verfügbar ist oder nicht. Falls die Antwort negativ ist oder keine Antwort empfangen wird, weiß das QoS-Managementsystem 1 oder nimmt an, dass die Datenquelle nicht verfügbar ist. Im Beispiel von 6 werden negative Pollingantworten aus dem zweiten Metrikadapter 5.2 zwischen t4 und t13 empfangen, so dass dem QoS-Managementsystem in Echtzeit bewusst ist, dass diese Datenquelle während der Zeitperiode nicht-verfügbar wurde (positive Pollingantworten werden als schattierte Kreise gezeichnet, wohingegen negative Pollingantworten als volle Kreise gezeichnet werden). In einigen der Ausführungsformen wird Polling einmal (oder sogar mehrmals) in jedem Berechnungszyklus 24 ausgeführt. In anderen Ausführungsformen wird Polling weniger häufig ausgeführt, z.B. in jedem fünften Berechnungszyklus. In einigen Ausführungsformen wird eine spezielle Behandlung von Ereignissen, die innerhalb des Zeitintervalls zwischen dem Auftreten eines Datenquellenfehlers und seiner verzögerten Detektierung fallen, durchgeführt, wie in Verbindung mit 11 unten beschrieben wird. Natürlich werden, je länger die Polling-Antwort-Latenz ist und je kleiner die Pollingperiode ist, desto häufiger solche Ereignisse auftreten.
  • Wie oben erwähnt, werden die Datenpunkte 6, die während der Nichtverfügbarkeitsperiode erzeugt werden, übertragen, sobald die Datenquelle wieder verfügbar ist, z.B. um die Zeitpunkte T15 und T16 herum. Wegen der asynchronen Natur der Datenpunkterzeugung weiß das QoS-Managementsystem nicht, wie viele Datenpunkte 6 während einer Nichtverfügbarkeitsperiode erzeugt wurden und kann streng gesprochen folglich nicht aus mit einer Verzögerung empfangenen Datenpunkte folgern, ob die empfangenen Datenpunkte alles Datenpunkte sind, die verzögert waren (im Gegensatz zu einem getakteten System, in dem so eine Folgerung möglich ist). Deshalb sendet, nachdem die Übertragung des letzten Datenpunktes 6, der gepuffert wurde, während der Nichtverfügbarkeitsperiode der fragliche Metrikadapter (d.h. der Metrikadapter 5.2 in dem Beispiel von 6 ein Ende-der-Übertragung (EOT) Signal 34 (6b). In einigen der Ausführungsformen wird das EOT-Signal 34 auch auf asynchrone Weise nach dem Abschicken des letzten gepufferten Datenpunkt 6 gesendet. In anderen Ausführungsformen sendet der Datensammler 7 des QoS-Managementsystems eine EOT-Anfrage 34 an den Metrikadapter 5.2 falls es annimmt, dass es alle gepufferten Datenpunkte 6 empfangen hat (z.B. nach einer gewissen Wartezeit seitdem der letzte empfangene gepufferte Datenpunkt verstrichen ist) und der Metrikadapter 5.2 gibt das EOT-Signal 34 in Antwort auf die EOT-Anfrage zurück.
  • Wie in der beispielhaften Ausführungsform eines getakteten Systems (5) werden nur diese Datenpunkte 6, die regulär empfangen wurde, in der Echtzeitberechnung 28 des ersten Prozesses 27 von 6 verwendet. Das bedeutet die Datenpunkte 6 aus Metrikadaptern 5.2, die während der Nichtverfügbarkeitsperiode an t7 und t13 erzeugt wurden, werden nicht in der Echtzeitberechnung 28 verwendet. Folglich sind die einzigen Datenpunkte 6 aus dem zweiten Metrikadapter 5.2, die in der Echtzeitberechnung 28 verwendet wurden, nur die die zu den Zeitpunkten t0, t2 und t18 erzeugt wurden. Die Echtzeitberechnung 28 nimmt deshalb an, dass das Netzwerkelement 3, das mit dem zweiten Metrikadapter 5.2 assoziiert ist, während der ganzen Periode von t2 bis zum Beginn von t18 nicht-verfügbar war, wie in 6 angegeben ist.
  • Der zweite Prozess 29 wird gestartet, sobald eine Datenquellen-Nichtverfügbarkeit 11, 12, 13 vom Polling-Prozess 33 beobachtet wird, d.h. bei t4 wie in 6d gezeigt wird. Wie in Verbindung mit 5 erklärt wird, umfasst der zweite Prozess 29 einen speichernden Unterprozess 30, der die regulären Daten (d.h. die Datenpunkte aus dem verfügbaren Metrikadapter 5.1 und/oder Zwischenberechnungsresultate aus der Echzeitberechnung 28 speichert sowie die verzögerten und unverzögerten Datenpunkte aus dem temporär nicht verfügbaren Metrikadapter 5.2 vom Beginn bis zum Ende des zweiten Prozesses 29. Sobald das EOT-Signal 34 empfangen wird, beginnt ein weiterer Unterprozess, der neue Berechnungsprozess 31. Sobald die Neuberechnung 31 die Echtzeitberechnung 28 eingeholt hat, werden die beiden Prozesse bei 32 zusammengeführt, wie in Verbindung mit 5 erklärt wird.
  • Die Eingabeschlange von Metrikwerten für die Echtzeitberechnung 28, genannt "Metrikeingabeschlange" 35, wird in 6e veranschaulicht. Wie oben erwähnt, umfasst die Metrikeingabeschlange 35 Datenpunkte von t0, t4, t6, t15, t20 aus Metrikadapter 5.1, Datenpunkte von t0, t2, t18 aus Metrikadapter 5.2. Die reguläre Information, die vom zweiten Prozess 29 gespeichert wird und bei der Neuberechnung 31 verwendet wird, wird als 36 bezeichnet in dem Beispiel von 6e und umfasst die nicht-verzögerten Datenpunkte von sowohl Metrikadaptern, die erzeugt wurden vom Beginn bis zum Ende des zweiten Prozesses 29, d.h. die Datenpunkte aus dem ersten Metrikadapter 5.2 erzeugt bei t4, t6, t15 und dem Datenpunkt aus dem zweiten Metrikadapter 5.2 erzeugt bei t18 (in anderen Ausführungsformen umfasst die reguläre Information Zwischenergebnisses der Echtzeitberechnung, wie in Verbindung mit 8d und 9b beschrieben werden wird.). Die zweite Eingabequelle zu der Neuberechnung 31 sind die verzögerten Datenpunkte 37, die in der temporär nicht verfügbaren Quelle gepuffert werden, d.h. die Datenpunkte aus dem zweiten Metrikadapter 5.2, die bei t7 und t13 erzeugt wurden.
  • 7–9: Berechnungsgraphen, Speicherung regulärer Information und teilweise Berechnung im Neuberechnungsprozess:
  • 7 veranschaulicht einen beispielhaften Berechnungsgraph 25, der die Berechnungen darstellt, die neben Berechnungszyklus 24 (3–6) des Echtzeitberechnungsprozesses gemacht werden. In einigen der Ausführungsformen wird derselbe Berechnungsgraph auch im Neuberechnungsprozess verwendet, in anderen Ausführungsformen jedoch wird nur ein Teil davon im Neuberechnungsprozess verwendet, wie in Verbindung mit 8 beschrieben wird.
  • Der Berechnungsgraph 25 hat unterschiedliche Knotenniveaus: Die Knoten mit dem untersten Niveau sind Metrikwerte 40 (genannt "MV" in 7), die in den Berechnungsgraph 25 in jedem Berechnungszyklus "eingespeist" werden. Knoten auf dem Zwischenniveau repräsentieren die Zwischenergebnisse (genannt "ZE" in 7), die im Verlauf des Berechnungsprozesses in jedem Berechnungszyklus erhalten werden. Die ZE-Knoten 42 umfassen auch einen Operator (z.B. kleiner, größer, gleich oder, und, etc.). Der die Art und Weise definiert, in der die Entitäten, die in den Knoten einfließen, kombiniert werden. Die Knoten am höchsten Niveau (die auch einen Operator umfassen können, wie die Zwischenknoten 42) sind die Resultate des Berechnungsprozesses in jedem Berechnungszyklus, die QoS-Parameter 43. Außerdem kann es Schwellwerte 41 geben, mit denen die Metrikwerte oder Zwischenergebnisse 42 verglichen werden; die Schwellwerte 41 können deshalb auch als Knoten auf unterstem Niveau oder mittlerem Niveau bezeichnet werden (z.B. kann ein einfacher Berechnungsgraph nur Knoten am untersten Niveau haben und Resultatknoten aber keine Zwischenergebnisknoten).
  • Der Graph 25 ist gerichtet; die Richtung der Verbindungen zwischen den Knoten, die die Propagierung von Metrikwerten 40, Schwellwerten 41 und Zwischenergebnissen 42 während des Berechnungsprozesses angibt. Die Berechnung beginnt auf untersten Niveau mit der Einspeisung von Metrikwerten und Schwellwerten 41 und mit der Berechnung der ersten Ergebnisse, die durch die gerichteten Verbindungen des Graphen und der Operatoren, die im Knoten umfasst sind, geleitet wird, zu denen die gerichteten Verbindungen führen. Die erhaltenen Zwischenergebnisse 42 werden weiter propagiert und auf diese Weise mit anderen Zwischenergebnissen 42, Metrikwerten und/oder Schwellwerten 41 kombiniert, bis das oberste Niveau erreicht ist und die QoS-Parameter 43 berechnet werden. Die QoS-Parameter 43 werden schließlich über die Zeit akkumuliert, wie oben in Verbindung mit 3–5 beschrieben wird.
  • In einfachen Fällen kann der Graph 25 eine baumähnliche Struktur haben, in der, wenn man sie von unten nach unten propagiert, es keine Verzweigungen gibt. Im allgemeinen kann der Berechnungsgrad 25 jedoch Verzweigungen haben, wie in 7 gezeigt ist. In diesem Beispiel werden vier Metrikwerte eingespeist: MV 40.1 (z.B. eine gemessene Antwortzeit eines ersten Servers, genannt "Server 1"), MV 40.2 (z.B. die gemessene Verfügbarkeit des Servers 1), MV 40.3 (z.B. die gemessene Antwortzeit eines zweiten Servers, genannt "Server 2", MV 40.4 (z.B. die gemessene Verfügbarkeit von Server 2), MV 40.5 (z.B. die gemessene Verfügbarkeit einer ersten Datenbank (genannt "DB1") und MV 40.6 (z.B. die gemessene Verfügbarkeit einer zweiten Datenbank, genannt "DB2". Ein beispielhafter erster Schwellwert 42.1 ist "0.2 sec." und ein zweiter Schwellwert 41.2 ist "0.1 sec.". Bei ZE 42.1 wird bestimmt, ob Server 1 reagiert durch Vergleichen des numerischen Metrikwerts MV 40.1 mit dem ersten Schwellwert 41.1 unter Verwendung des Operators "kleiner"; das Resultat ist ein logischer Wert. Analog wird bei ZE 42.2 bestimmt, ob Server 2 reagiert durch Vergleichen des numerischen Metrikwerts MV 40.3 mit dem zweiten Schwellwert 41.2. Bei ZE 42.3 wird bestimmt, ob Server 1 arbeitet durch Bestimmen eines logischen UNDs des Resultats von ZE 42.1 und des logischen Metrikwerts MV 40.2. Dasselbe wird gemacht, um zu bestimmen, ob Server 2 arbeitet bei ZE 42.4 durch Verbinden des Kombinieren des Ergebnisses von ZE 42.2 der Metrikwerte MV 40.4. Bei ZE 42.5 wird bestimmt, ob die kombinierten Datenbanken verfügbar sind durch Bilden eines logischen UNDs der Metrikwerte MV 40.5 und 40.6.
  • Schließlich wird im Beispiel von 7 angenommen, dass zwei QoS-Parameter aus den Zwischenergebnissen ZE 42.3 bis 42.5 bestimmt werden: Ein erster QoS-Parameter 43.1 gibt z.B. an, dass ein Webdienst, der alternativ durch Server 1 oder Server 2 bereitgestellt werden kann, verfügbar ist und eine minimale Leistung hat. Der QoS-Parameter 43.1 ist deshalb ein logisches ODER des von ZE 42.3 und ZE 42.4, welcher die Verfügbarkeit und Leistung einzelner Server angibt, aber hängt nicht von ZE 42.5 ab, das die kombinierten Datenbankverfügbarkeit angibt. Im Gegenteil wird der zweite QoS-Parameter 43.2 angenommen, um die Verfügbarkeit und Leistung eines Datendienstes anzugeben, der sich auf Server 2 stützt, (aber nicht auf Server 1) und die Datenbanken DB1 und DB2. Folglich wird im Beispiel von 7 der QoS-Parameter 43.2 gebildet durch ein logisches UND von ZE 42.4 und ZE 42.5, hängt aber nicht von ZE 42.3 ab.
  • In der beispielhaften Berechnungsgraphstruktur von 7 kann eine Nichtverfügbarkeit der Datenquelle, die den Metrikwert MV40.3 oder MV40.4 liefert, verursachen, dass sowohl die QoS-Parameter 43.1 und 43.2, die in der Echtzeitberechnung berechnet wurden, inexakt sind, so dass sowohl QoS-Parameter 43.1 und 43.2 im Neuberechnungsprozeß neu berechnet werden müssen, wenn die Datenquelle wieder verfügbar ist und die verzögerten Datenpunkte liefert, die während der Nichtverfügbarkeitsperiode auftraten. Im Gegensatz dazu beeinflusst eine Nichtverfügbarkeit einer der Datenquellen, die MV 40.1, MV 40.2, MV 40.5 oder MV40.6 liefert, nur einen der QoS-Parameter 43.1 oder 43.2. In den letztgenannten Fällen ist es deshalb im Prinzip ausreichend nur den einzigen betroffenen QoS-Parameter neu zu berechnen, d.h. 43.1 oder 43.2.
  • 8a–d veranschaulichen einen Berechnungsgraph in einer abstrakteren Weise, in der Schwellwertknoten und Operatoren nicht gezeichnet sind und in der die gezeichneten Knoten durch Großbuchstaben "A" bis "P" bezeichnet sind. Die Knoten A und B sind QoS-Parameterknoten 43, die Knoten C–J sind Zwischenergebnisknoten 42 und die Knoten K–P sind Metrikwerteeingabeknoten 40. Der Graph 25 von 8 ist nicht identisch mit dem detaillierteren Beispiel von 7 (z.B. hat er mehrere Zwischenergebnisknoten 42, wohingegen 7 nur fünf solcher Knoten hat), aber er ist ähnlich zu ihm, da er auch ein verzweigter Graph ist, in dem einige der Metrikwerte Eingabeknoten 40 (nämlich Knoten K, L, M und Knoten O, P) nur einen der QoS-Parameterknoten 43 beeinflussen, wohingegen andere Knoten (nämlich Knoten N) beide QoS-Parameterknoten 43 beeinflusst.
  • Nehmen wir nun an, dass eine der Datenquellen temporär nicht-verfügbar wird, nämlich die Datenquelle, die die Metrikwerte an den Metrikwertknoten L liefert, z.B. wegen eines Fehlers 11, 12 oder 13 (1). Dies wird angegeben durch einen durch einen Pfeil, der zu Knoten 11 zeigt in den 8a–d.
  • 8b bis d veranschaulichen, welche reguläre Information dann in den unterschiedlichen Ausführungsformen gespeichert wird. In 8b bis d werden diese Knoten, die Zwischenergebnisse der Datenpunkte darstellen, die gespeichert werden, als Doppelkreise gezeichnet.
  • 8b veranschaulicht Ausführungsformen, in denen alle regulär übermittelten Datenpunkte K, M bis P gespeichert werden ungeachtet dessen, ob alle diese Datenpunkte tatsächlich im Neuberechnungsprozess benötigt werden oder nicht. In einigen dieser Ausführungsformen werden diese Datenpunkte immer gespeichert, d.h. sogar in der Abwesenheit eines Datenquellenfehlers, wohingegen in anderen Ausführungsformen sie nur gespeichert werden, solange der zweite Prozess aktiv ist, d.h. nach der Detektierung des Datenquellenfehlers und vor Beendigung des zweiten Prozesses. Natürlich werden, wie in den 5 und 6 gezeigt ist, die Datenpunkte aus temporär nicht verfügbaren Datenquellen entsprechend dem Knoten L ebenfalls gespeichert, sobald die Datenquelle wieder verfügbar geworden ist (dies trifft auch auf die folgenden 8c und d zu).
  • 8c veranschaulicht eine andere Ausführungsform, die ähnlich zu 8b ist, in der die reguläre gespeicherte Information aus regulär empfangenen Datenpunkten (anstelle von Zwischenergebnissen) besteht. Jedoch werden im Gegensatz zu 8b nicht alle regulär empfangenen Datenpunkte gespeichert, sondern nur die, die im Neuberechnungsprozess benötigt werden, um den betroffenen QoS-Parameter neu zu berechnen, der vom Datenquellenfehler betroffen ist. Im Beispiel von 8c betrifft der Datenquellenfehler nur den QoS-Parameterknoten A, so dass nur die regulär empfangenen Datenpunkte aus den Knoten, die den QoS-Parameterknoten A beeinflussen, d.h. die durch die Knoten K, M und N dargestellten Datenpunkte, gespeichert werden. Dieses Beispiel zeigt, dass die Definition dessen, was zur regulären Information gehört, die gespeichert wird, wahlweise davon abhängt, welche Datenquelle im speziellen Fall fehlschlägt. Deshalb ist die erste Aktivität des zweiten Prozesses nach ihrer Initialisierung zu bestimmen, was zur regulären Information gehört, die gespeichert werden soll, z.B. auf der Grundlage vorbestimmter Regeln. Die Aktivität des Speicherns der regulären Information beginnt erst nach der Detektierung des Datenquellenfehlers und der Bestimmung, was gespeichert werden soll.
  • 8d veranschaulicht noch eine weitere Ausführungsform, in der die reguläre gespeicherte Information aus Zwischenresultaten besteht, insoweit sie im Neuberechnungsprozess verwendet werden können. Im gezeigten Beispiel werden die Zwischenergebnisse, die durch Knoten D und G dargestellt sind, gespeichert. In einigen Fällen kann das Speichern von Zwischenergebnissen nicht ausreichend sein, sondern Datenpunkte werden auch in der regulär gespeicherten Information umfasst, um zu ermöglichen, dass QoS-Parameter neu berechnet werden, die von der Datenquellenfehler betroffen sind, z.B. in 8d die Datenpunkte, die durch den Metrikeingabewert Knoten K abgespeichert werden, da sie das erste Zwischenergebnis beeinflussen, das durch Knoten I dargestellt wird (dieses Ergebnis kann erst nach dem Empfang der verzögerten, durch Knoten L dargestellten Datenpunkte neu berechnet werden). Wie im Fall von 8c hängt die Definition dessen, welche Zwischenergebnisse und/oder Datenpunkte zur regulären Information gehören, die gespeichert werden soll, im allgemeinen davon ab, welche der Datenquellen ausgefallen ist. Nach der Detektierung des Datenquellenfehlers, bestimmt der zweite Prozess, welche Zwischenergebnisse und/oder Datenpunkte gespeichert werden sollen, um zu ermöglichen, den betroffenen QoS-Parameter neu zu berechnen, und dann beginnt der tatsächliche Speicherungsprozess.
  • In den Ausführungsformen, in denen alle Datenpunkte gespeichert werden, wie in 8, kann (aber muss nicht) der im zweiten Prozess durchgeführte Neuberechnungsprozess den vollständigen Berechnungsgraphen 25 neu berechnen, der in der Echtzeitberechnung des ersten Prozesses verwendet wurde, nun auch unter der Verwendung der nach der Verzögerung übertragenen Datenpunkte, die nicht in der Echtzeitberechnung des ersten Prozesses umfasst waren. Zum Beispiel wird in solch einer Ausführungsform der Berechnungsgraph 25 von 8b sowohl in der Echtzeitberechnung des ersten Prozesses als auch in der Neuberechnung des zweiten Prozesses verwendet. In anderen Ausführungsformen werden jedoch nur einige der Berechnungen der Echtzeitberechnung im Neuberechnungsprozess wiederholt, dann einschließlich der nach der Verzögerung empfangenen Datenpunkte; folglich ist der Berechnungsgraph, der die Berechnungen darstellt, die während des Neuberechnungsprozesses gemacht werden, ein partieller Graph des Berechnungsgraphen 25 des ersten Prozesses. 9a und b veranschaulichen zwei solcher partieller Berechnungsgraphen, die als 25' und 25'' bezeichnet werden. Das erste Beispiel, partieller Graph 25' von 9a, bezieht sich auf die in 8c gezeigte Ausführungsform, in der nur die Datenpunkte gespeichert werden, die den von der Datenquellen-Nichtverfügbarkeit betroffenen QoS-Parameter beeinflussen, d.h. die durch die Knoten K, M und N dargestellten Datenpunkte. Folglich ist der partielle Graph 25' nur jener Teil des Berechnungsgraphen 25 des ersten Prozesses, der mit dem betroffenen QoS-Parameter A assoziiert ist, aber umfasst nicht jene Knoten und Verbindungen, die nur mit dem anderen, nicht-betroffenen QoS-Parameter B (d.h. umfasst nicht Knoten B, E, I, J, O, P und ihre Verbindungen) assoziiert sind.
  • Die zweite Ausführungsform eines in 9b gezeigten partiellen Berechnungsgraphen 25'' bezieht sich auf die Ausführungsform von 8d, in der Zwischenergebnisse gespeichert werden. Der partielle Berechnungsgraph 25'' ist jener Teil des vollständigen Berechnungsgraphen 25 des ersten Prozesses, der die reguläre gespeicherte Information (d.h. die Zwischenergebnisknoten G und D sowie den Metrikeingabewertknoten K) darstellt, die nach der Verzögerung übertragenen Datenpunkte (d.h. Knoten L), und all die Knoten, die Zwischenergebnisse und daraus berechnete Endergebnisse (d.h. Knoten F, C, und C) darstellen, sowie die Verbindungen zwischen all diesen Knoten.
  • 10: Bearbeitung von Konfigurations- und Zeitplanänderungen
  • Ein beispielhafter Berechnungsgraph 25Y ist auf der linken Seite von 10a gezeigt. Der Berechnungsgraph 25Y hat zwei Eingabemetrikwerte Y1 und Y2, die sich z.B. auf die Verfügbarkeit und Latenz eines Servers Y beziehen können. Ein QoS-Parameter V wird aus den Eingabemetrikwerten Y1 und Y2 berechnet. Zum Beispiel kann der QoS-Parameter V eine vom Server Y gelieferte Dienstqualität darstellen. Es wird im Beispiel von 10a angenommen, dass zu irgendeinem Zeitpunkt eine Konfigurationsänderung stattfindet, entsprechend der ein weiterer Server, als "Server Z" bezeichnet, hinzugefügt wird. Nehmen wir nun an, dass der Server "Z" auch den Dienst V liefert. Die Konfigurationsänderung wird auf dem Niveau des Berechnungsgraphen durch eine Erweiterung des ursprünglichen Berechnungsgraphen 25Y modelliert. Der resultierende erweiterte Berechnungsgraph ist der Berechnungsgraph 25YZ auf der rechten Seite von 10a. Z.B. hat der Berechnungsgraph 25YZ zwei zusätzliche Eingabemetrikwerte Z1 und Z2, die ebenfalls den berechneten QoS-Parameter betreffen. Der QoS-Parameter V kann ein logisches ODER sein oder die Zwischenergebnisse W und X, ähnlich dem QoS-Parameter 43.1, der in 7 gezeigt wird.
  • 10b, die ein Diagramm ähnlich zu 5 ist, veranschaulicht die Verwendung der unterschiedlichen Berechnungsgraphen 25Y und 25YZ auf eine zeitkonsistente Art und Weise. Die Konfigurationsveränderung geschieht zwischen den zweiten und dritten Berechnungszyklen CC2 und CC3. Folglich werden im ersten Prozess 27, der die Echtzeitberechnung 28 durchführt, zwei Eingabemetrikwerte in den Berechnungszyklen gezeigt bevor die Konfigurationsänderung, CC1 und CC2, aber vier Eingabemetrikwerte werden gezeigt in Berechnungszyklen nach der Konfigurationsänderung, CC3 bis CC5. Es wird in 10b angenommen, dass ein Datenquellenfehler geschieht, während CC2 und CC3 als ein Resultat dessen der zweite Prozess 29 gestartet wird, mit dem speichernden Unterprozess 30 zu Beginn von CC2 und die Datenpunkte, die normalerweise aus der nun nicht-verfügbaren Datenquelle geliefert werden würden, werden in dieser Datenquelle temporär gepuffert. Der Neuberechnungsunterprozess 31 wird gestartet, sobald die gepufferten Datenpunkte, die nicht-verfügbar waren in der Echtzeitberechnung 28 am Datenkollektor 7 (1) empfangen werden, z.B. zu Beginn des Berechnungszykluses CC4. Der neue Berechnungsunterprozess 31 berücksichtigt die Konfigurationsänderungen in einer konsistenten Art und Weise, d.h. er verwendet den ersten Berechnungsgraph 25Y in der Neuberechnung CC2' des Berechnungszykluses CC2 (der mit der Konfiguration vor der Konfigurationsänderung assoziiert ist) und verwendet den zweiten Berechnungsgraphen 25YZ in der Neuberechnung CC3' und CC4' der Berechnungszyklen CC3 und CC4 (die mit der Konfiguration nach der Konfigurationsänderung assoziiert sind). Zu diesem Zweck speichert der speichernde Unterprozess nicht nur Datenpunkte und/oder Zwischenergebnisse, sondern auch die Konfigurationsgraphen 25Y, 25YZ, die in der Echtzeitberechnung verwendet werden, für jedes Berechnungsintervall, entweder in einer vollständigen Form oder einer partiellen Form, wie in Verbindung mit 9 veranschaulicht ist.
  • Die in 10 gezeigte Funktionalität trifft auch auf Zeitplanänderungen zu. Die Verpflichtungen, die in einem SLA gemacht werden, können über die Zeit hinweg entsprechend eines Plans variieren. Zum Beispiel kann die benötigte Dienstqualität während Arbeitsstunden höher sein als während Nicht-Arbeitsstunden. Unterschiedliche Berechnungsgraphen können mit den unterschiedlichen Quellen assoziiert sein. Eine Planänderung, die z.B. jeden Tag am Ende der normalen Arbeitsstunden geschehen kann, wird in einer Art und Weise analog zum Bearbeiten von Konfigurationsänderungen in 10 behandelt.
  • 11: Zeitstempelabänderung:
  • 11, die ähnlich zu 6 ist, veranschaulicht mögliche Folgen einer "Fehlerbewusstseinsverzögerung" 44. Im Beispiel von 11 wird angenommen, dass drei Datenpunkte von einem Metrikadapter 5.2 erzeugt werden, ein erster Datenpunkt am Berechnungszyklus 0, der eine Statusänderung "UP" angibt, ein zweiter am Berechnungszyklus 2, der eine Statusänderung "DOWN" angibt, und ein dritter am Berechnungszyklus 10, der eine Statusänderung "UP" angibt. Außerdem wird angenommen, dass der Metrikadapter 5.2 während Berechnungszyklen CC2 bis CC12 nicht verfügbar ist. Jedoch nehmen wir nun im Gegensatz zu 6 an, dass dem QOS-Managementsystem 1 nicht sofort die Datenquellen-Nichtverfügbarkeit bewusst wird, sondern erst mit einer Verzögerung (die oben erwähnte "Fehler-Bewusstseinsverzögerung" 44) von, sagen wir, einem Berechnungszyklus. Dies kann z.B. wegen Verzögerungen sein, die inhärent mit dem Polling-Prozess 33 stattfinden. In 11a wird diese Verzögerung 44 durch die vollen Kreisen veranschaulicht (die negative Polling-Antworten angeben), die relativ zum Nichtverfügbarkeitsintervall um einen Berechnungszyklus verschoben sind.
  • 11b veranschaulicht, was in diesen Beispielen in der Echtzeitberechnung geschieht: wegen der Nichtverfügbarkeit des Metrikadapters MA 5.2 werden die Datenpunkte mit Zeitstempeln "2" und "10" nicht in Echtzeit übermittelt, sondern werden im Metrikadapter MA 5.2 gepuffert. Folglich hat die Echtzeitberechnung nur den Datenpunkt mit Zeitstempel "0" zu ihrer Verfügung und nimmt daher an, dass der Metrikwert, der von diesem Datenpunkt angegeben wird, gültig bleibt; d.h. sie nimmt an, dass der Metrikwert die ganze Zeit über "UP" ist.
  • Wegen der Fehlerbewusstseinsverzögerung 44 beginnt der zweite Prozess erst im Berechnungszyklus 3 die reguläre Information zu speichern, d.h. mit einer Verzögerung 44 entsprechend eines Zykluses. Mit anderen Worten, die regulären Daten, die zum Berechnungszyklus CC2 gehören, werden nicht gespeichert, und der Neuberechnungsprozess, der später durchgeführt wird, wird nicht den Berechnungszyklus CC2 neu berechnen, sondern wird erst mit Berechnungszyklus CC3 starten.
  • Sobald der temporär nicht-verfügbare Metrikadapter MA 5.2 im Berechnungszyklus CC13 wieder verfügbar wird, überträgt er seine gepufferten Datenpunkte, d.h. die Datenpunkte mit Zeitstempeln 2 und 10 an den Datensammler 7 (1). Der Datenpunkt mit dem Zeitstempel 2 wurde wegen der Datenquellen-Nichtverfügbarkeit nicht in der Echtzeitberechnung verwendet, aber der neue Berechnungsprozess ist auch nicht vorbereitet, diesen Datenpunkt zu verdauen. Dies ist wegen der Fehlerbewusstseinsverzögerung 44, die veranlasst, die neue Berechnung erst mit Berechnungszyklus CC3 zu starten; der Datenpunkt mit dem Zeitstempel "2" kann deshalb nicht konsistent mit irgendeinem Berechnungszyklus assoziiert werden, der in dem Neuberechnungsprozess verarbeitet wird. Folglich, wie in 11c gezeigt wird, wird dieser Datenpunkt ohne Zeitstempelabänderung ignoriert, und der Neuberechnungsprozess nimmt deshalb an, dass der Metrikwert den ganzen Neuberechnungsprozess hinweg "UP" ist, wie durch den vorherigen Datenpunkt mit Zeitstempel "0" angegeben ist.
  • In einigen der Ausführungsformen wird eine Zeitstempelabänderung in solchen Fällen durchgeführt, wie sie in 11d veranschaulicht sind. Wenn ein Datenpunkt mit einer Verzögerung empfangen wird und deshalb nicht in der Echtzeitberechnung umfasst werden konnte, aber auf der anderen Seite zu einem Berechnungszyklus gehört, der vor dem ersten Berechnungszyklus des Neuberechnungsprozesses liegt, wird der Zeitstempel dieses Datenpunkts inkrementiert, so dass der Datenpunkt anscheinend zum ersten Berechnungszyklus gehört, der in dem Neuberechnungsprozess verarbeitet wird (im Falle in Konflikt stehender Datenpunkte kann eine Kollisionsregel dann eine Kollision auflösen; z.B. kann der Datenpunkt mit dem jüngsten Originalzeitstempel verwendet werden). Im Beispiel von 11d wird der Zeitstempel des Datenpunktes des fraglichen Datenpunkts von zwei auf drei inkrementiert. Wie aus 11 d gesehen werden kann, ist das erhaltene Resultat mit der Zeitstempelabänderung exakter als das ohne Zeitstempelabänderung; der Neuberechnungsprozess verfehlt nicht zu bemerken, dass der Metrikwert sich von "UP" nach "DOWN" änderte. Stattdessen verursacht die Fehlerbewusstseinsverzögerung 44 nur eine kleine Inexaktheit, nämlich eine Verzögerung dieser Änderung um einen Berechnungszyklus.
  • 12: Zustandsdiagramm des Berechnungsprozesses:
  • 12 ist ein Zustandsdiagramm der Echtzeitberechnung und des Neuberechnungsprozesses 28, 31. Es veranschaulicht die Zustände, durch die die erste Berechnungsengine 15 oder zweite Berechnungsengine 16 (1) in jedem Berechnungszyklus läuft.
  • Bei 45 wird die Metrikschlange 35 (6) nach neuen Datenpunkten überprüft. In der Echtzeitberechnung umfasst die Metrikschlange 35 nur regulär übertragene Datenpunkte. In der Echtzeitberechnung beinhaltet die Metrikschlange jedoch die reguläre Information, die vom zweiten Prozess gespeichert wird (d.h. gespeicherte regulär übertragene Datenpunkte und/oder gespeicherte Zwischenergebnisse, die in der Echtzeitberechnung erhalten wurden) und die Datenpunkte, die nach einer Verzögerung übertragen wurden. Bei 45 werden alle Datenpunkte gelesen, die einen Zeitstempel haben, der dem aktuellen Berechnungszyklus entspricht. Ein Datenpunkt wird nur einmal aus der Metrikschlange gelesen und kann normalerweise nicht ein zweites Mal aus dem Datensammler gelesen werden. Bei 47 werden die Metrikwerte in dem Berechnungsgraph mit den Werten aus den Datenpunkten erneuert, die in 46 gelesen wurden. Bei 47 wird der Berechnungsgraph mit den erneuerten Metrikwerten verarbeitet, d.h. die Berechnungen, die durch den Berechnungsgraphen dargestellt werden, werden ausgeführt. Bei 49 wird der QoS-Parameter, der als ein Resultat von 48 erhalten wird, zum vorherigen Wert des akkumulierten QoS-Parameter addiert, so dass ein neuer kumulierter QoS-Parameter erhalten wird. Bei 50 werden die Werte der Knoten des Berechnungsgraphes oder einiger davon und der akkumulierte QoS-Parameter an den Datenexporteur 17 und/oder an den SLM Server 19 (1) exportiert, im Data Warehouse 18 und/oder dem CMDB 21 gespeichert und werden in der Überwachungs GUI 20 überwacht. In dem Echtzeitberechnungsprozess werden die Werte der Knoten und des akkumulierten QoS-Parameter auch an die zweite Berechnungsengine exportiert, die jeden Teil der Daten speichert, die die reguläre Information darstellt, die im Neuberechnungsprozess verwendet wird, wie oben beschrieben wurde.
  • 13: QoS-Management-Computersystem
  • 13 ist eine diagrammatische Repräsentation eines Computersystems, das die Funktionalität des QoS-Managementsystems 1 von 1 bereitstellt und wird deshalb als "QoS-Management-Computersystem 1" bezeichnet. Innerhalb des QoS-Management-Computersystems 1 kann eine Menge von Instruktionen ausgeführt werden, um zu veranlassen, dass das Computersystem irgendeine der Methodologien ausführt, die hierin diskutiert wurden. Das QoS-Management-Computersystem 1 umfasst einen Prozessor 51, einen Hauptspeicher 52 und ein Netzwerkschnittstellengerät 53, die miteinander über einen Bus 54 kommuizieren. Optional kann es weiterhin einen statischen Speicher 55 und eine Laufwerkeinheit 56 umfassen. Ein alphanumerisches Eingabegerät 57 und ein Cursorsteuerungsgerät 58 können eine QoS-Management-Benutzerschnittstelle bilden. Das Netzwerkschnittstellengerät 53 verbindet das QoS-Management-Computersystem mit den Metrikadaptern 5 und dem gemanagten IT-Netzwerk 2. Eine Menge von Instruktionen (d.h. Software) 59, die eine oder alle der oben beschriebenen Methodologien verkörpert, sitzt vollständig oder zumindest teilweise in oder auf einem maschinenlesbaren Medium, z.B. dem Hauptspeicher 52 und/oder dem Prozessor 51. Ein maschinenlesbares Medium, auf dem die Software 59 sitzt, kann auch ein Datenträger 60 sein (z.B. eine nicht-auswechselbare magnetische Festplatte oder eine optische oder magnetische auswechselbare Scheibe), der Teil der Laufwerkseinheit 56 ist. Die Software 59 kann weiterhin als ein propagiertes Signal 61 über das Internet und das IT-Netzwerk 2 durch das Netzwerkschnittstellengerät 53 übertragen oder empfangen werden.
  • Folglich ermöglichen die beschriebenen Ausführungsformen von Dienstgüte-Managementtools sowohl eine Echtzeitüberwachung als auch eine exakte Angabe der Qualität eines zur Verfügung gestellten Dienstes, sogar wenn Datenquellen für Metrikwerte temporär nicht verfügbar sind.

Claims (22)

  1. Verfahren zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden, wobei die Daten aus den Datenquellen regulär in Echtzeit ankommen, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können, wobei das Verfahren umfasst: Berechnen einer Echtzeitangabe der Dienstqualität in einem ersten Prozess auf der Grundlage der regulären Daten, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, Berechnen einer verzögerten aber exakteren Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess auf der Grundlage regulärer Information, die reguläre Daten und/oder von ihnen abgeleitete Information umfasst, und der verzögerten Daten.
  2. Verfahren nach Anspruch 1, wobei die regulären Daten gespeichert werden, und wobei, nach dem Empfang der verzögerten Daten, die verzögerte aber exaktere Angabe der Dienstqualität im zweiten Prozess auf der Grundlage der gespeicherten regulären Daten und der verzögerten Daten berechnet wird.
  3. Verfahren nach Anspruch 1 oder 2, welches ferner umfasst: Überprüfen der Verfügbarkeit von Datenquellen; In Reaktion auf eine Detektierung, dass eine oder mehrere Datenquellen nicht verfügbar sind, Abspeichern der regulären Daten; Berechnen, nach dem Empfang der verzögerten Daten, auf der Grundlage der gespeicherten regulären Daten und der verzögerten Daten, der verzögerten, aber exakteren Angabe der Dienstqualität im zweiten Prozess.
  4. Verfahren nach einem der Ansprüche 1 bis 3, welches ferner umfasst: Überprüfen der Verfügbarkeit von Datenquellen; in Reaktion auf eine Detektierung, dass eine oder mehrere Datenquellen nicht verfügbar sind, Bestimmen, welche Resultate der Echtzeitberechnung von der detektierten Datenquellen-Nichtverfügbarkeit betroffen sind und Abspeichern jenes Teils regulärer Information, der verwendet wird, um die betroffenen Resultate neu zu berechnen; Berechnen, nach dem Empfang der verzögerten Daten, die verzögerte aber exaktere Angabe der Dienstqualität auf der Grundlage der gespeicherten regulären Information und der verzögerten Daten, durch Neuberechnen der Resultate des ersten Prozesses, die von der Datenquellen-Nichtverfügbarkeit betroffen waren, im zweiten Prozess.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei die Aktivitäten des Berechnens umfassen Berechnen QoS Parameterwerte für Kurzzeitintervalle, folglich Bilden von Berechnungszyklen, und Kombinieren dieser QoS Parameterwerte über die Zeit.
  6. Verfahren nach Anspruch 5, wobei die Datenquellen ihre QoS-bezogenen Daten mit einem Zeitstempel bereitstellen, der den Zeitpunkt angibt, wann die Daten erzeugt wurden, wobei ein Datum und sein Zeitstempel "Datenpunkt" genannt wird, und wobei wenigstens im zweiten Prozess die Datenpunkte in korrekte Reihenfolge gebracht werden und auf der Grundlage ihrer Zeitstempel kombiniert werden.
  7. Verfahren nach Anspruch 6, wobei wenigstens im zweiten Prozess nur Datenpunkte in einem Berechnungszyklus kombiniert werden, die, wegen ihres Zeitstempels, zum Berechnungszyklus gehören.
  8. Verfahren nach Anspruch 6 oder 7, wobei der Zeitstempel eines verzögerten Datenpunkts inkrementiert wird, wenn der Datenpunkt erzeugt wurde zwischen dem Auftreten der Verzögerung und seiner Detektierung, so dass der Datenpunkt im zweiten Prozess verwendet wird, als wäre er nach der Detektierung der Verzögerung erzeugt worden.
  9. Verfahren nach einem der Ansprüche 5 bis 8, wobei die Berechnung der QoS-Parameterwerte in den Berechnungszyklen auf einem Berechnungsgraphen basiert, der angibt, wie die Daten aus den Datenquellen kombiniert werden soll.
  10. Verfahren nach Anspruch 9, wobei der zweite Prozess auf dem vollständigen Berechnungsgraphen basiert, oder auf einem Teil des Berechnungsgraphen, der im ersten Prozess verwendet wurde.
  11. Verfahren nach Anspruch 9 oder 10, wobei der erste Prozess Zwischenergebnisse offen legt, die von Knoten des Berechnungsgraphen dargestellt werden, wobei einige der Zwischenergebnisse von einer Datenquellen-Nichtverfügbarkeit betroffen sind, während andere Zwischenergebnisse davon nicht betroffen sind und deshalb im ersten Prozess korrekt berechnet werden, wobei nicht-betroffene Zwischenergebnisse, die andere Knoten im Berechnungsgraphen beeinflussen, gepuffert werden und im zweiten Prozess wiederverwendet werden, der deshalb auf einem anderen Berechnungsgraphen beruht.
  12. Verfahren nach einem der Ansprüche 9 bis 11, wobei die Prozesse Plan- und Konfigurierungsereignisse bearbeiten können, die die Verwendung abgeänderter Berechnungsgraphen anstoßen, wobei die abgeänderten Berechnungsgraphen sowohl im ersten als auch im zweiten Prozess auf zeit-konsistente Weise verwendet werden.
  13. Verfahren nach einem der Ansprüche 1 bis 12, wobei, nachdem der zweite Prozess den ersten Prozess eingeholt hat, der erste Prozess mit dem zweiten Prozess synchronisiert wird, und der zweite Prozess aufgelöst wird.
  14. Verfahren nach einem der Ansprüche 1 bis 12, wobei, nachdem der zweite Prozess den ersten Prozess eingeholt hat, der zweite Prozess den ersten Prozess ersetzt.
  15. Verfahren nach einem der Ansprüche 1 bis 14, wobei die von einer Datenquelle empfangenen Daten Daten sind, deren Empfang erwartet wird, weil sie alle periodisch von der Datenquelle gesendet werden, oder auf Anfrage vom QoS Management System hin.
  16. Verfahren nach Anspruch 15, wobei die Verfügbarkeit einer Datenquelle von einem Inferenzmechanismus überprüft wird und wobei, in Reaktion auf eine detektierte Nicht-Verfügbarkeit, der zweite Prozess angestoßen wird.
  17. Verfahren nach einem der Ansprüche 1 bis 16, wobei die von einer Datenquelle empfangenen Daten asynchron übermittelte Ereignisdaten sind.
  18. Verfahren nach Anspruch 17, wobei eine Datenquelle von Zeit zu Zeit gepollt wird und dabei die Verfügbarkeit der Datenquelle überprüft wird, und wobei, in Reaktion auf eine detektierte Nicht-Verfügbarkeit, der zweite Prozess angestoßen wird,
  19. Verfahren nach Anspruch 17 oder 18, wobei, wenn Daten aus einer Datenquelle verzögert waren, aber letztlich übermittelt werden konnten, die Datenquelle eine Ende-der-Übertragung-Angabe sendet, dass alle verzögerten Daten übertragen wurden.
  20. Verfahren zum Bestimmen von Dienstqualität (QoS) in einer IT Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden, wobei die Daten aus den Datenquellen regulär in Echtzeit ankommen, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können, wobei das Verfahren umfasst: Überprüfen der Verfügbarkeit von Datenquellen; Berechnen, auf der Grundlage der regulären Daten, eine Echtzeitangabe der Dienstqualität in einem ersten Prozess, wobei die Angabe möglicherweise inexakt ist, weil verzögerte Daten nicht umfasst sind; und, in Reaktion auf eine Detektierung, dass eine oder mehrere Datenquellen nicht verfügbar sind, Bestimmen, welche Resultate der Echtzeitberechnung von der detektierten Datenquellen-Nichtverfügbarkeit betroffen sind und Abspeichern jenes Teils regulärer Information, d.h. jenen Teil regulärer Daten und von ihnen abgeleitete Information, der verwendet wird, um die betroffenen Resultate neu zu berechnen; Bestimmen, nach dem Empfang der verzögerten Daten, auf der Grundlage der gespeicherten regulären Information und der verzögerten Daten, einer verzögerten, aber exakteren Angabe der Dienstqualität durch Neuberechnen der Resultate des ersten Prozesses, die von der Datenquellen-Nichtverfügbarkeit betroffen waren, in einem zweiten Prozess.
  21. Computersystem zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden, wobei die Daten von den Datenquellen regulär in Echtzeit ankommen, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können, wobei das Computersystem derart programmiert ist, dass es: auf der Grundlage der regulären Daten, eine Echtzeitangabe der Dienstqualität in einem ersten Prozess berechnet, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, eine verzögerte aber exaktere Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess berechnet, auf der Grundlage regulärer Information, die reguläre Daten und/oder davon abgeleitete Information umfasst, und der verzögerten Daten.
  22. Computerprogramm zum Bestimmen von Dienstqualität (QoS) in einer IT-Infrastruktur auf der Grundlage QoS-bezogener Daten, die aus Datenquellen für diese QoS-bezogenen Daten empfangen werden, wobei die Daten aus den Datenquellen regulär in Echtzeit ankommen, aber Daten aus einer oder mehrerer Datenquellen gelegentlich verzögert sein können, wobei beim Ausführen des Computerprogramms auf einem Computersystem folgendes Verfahren durchgeführt wird: Berechnen einer Echtzeitangabe der Dienstqualität in einem ersten Prozess auf der Grundlage der regulären Daten, wobei diese Angabe möglicherweise inexakt ist, da verzögerte Daten nicht umfasst sind; nach dem Empfang der verzögerten Daten, Berechnen einer verzögerten aber exakteren Angabe der Dienstqualität in einem zweiten nebenläufigen Prozess auf der Grundlage regulärer Information, die reguläre Daten und/oder von ihnen abgeleitete Information umfasst, und der verzögerten Daten.
DE102006018232A 2005-04-19 2006-04-19 Dienstqualität in IT-Infrastrukturen Withdrawn DE102006018232A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/109,285 US7924732B2 (en) 2005-04-19 2005-04-19 Quality of service in IT infrastructures
US11/109,285 2005-04-19

Publications (1)

Publication Number Publication Date
DE102006018232A1 true DE102006018232A1 (de) 2006-11-02

Family

ID=37085229

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102006018232A Withdrawn DE102006018232A1 (de) 2005-04-19 2006-04-19 Dienstqualität in IT-Infrastrukturen

Country Status (2)

Country Link
US (1) US7924732B2 (de)
DE (1) DE102006018232A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8433541B2 (en) 2009-01-12 2013-04-30 Repower Systems Ag Method and system for monitoring a wind energy installation
CN105991366A (zh) * 2015-03-05 2016-10-05 ***通信集团福建有限公司 一种业务监控方法及***

Families Citing this family (183)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658091B1 (en) 2002-02-01 2003-12-02 @Security Broadband Corp. LIfestyle multimedia security system
US9141276B2 (en) 2005-03-16 2015-09-22 Icontrol Networks, Inc. Integrated interface for mobile device
US10142392B2 (en) 2007-01-24 2018-11-27 Icontrol Networks, Inc. Methods and systems for improved system performance
US11582065B2 (en) 2007-06-12 2023-02-14 Icontrol Networks, Inc. Systems and methods for device communication
US10721087B2 (en) 2005-03-16 2020-07-21 Icontrol Networks, Inc. Method for networked touchscreen with integrated interfaces
US11368429B2 (en) 2004-03-16 2022-06-21 Icontrol Networks, Inc. Premises management configuration and control
US8635350B2 (en) 2006-06-12 2014-01-21 Icontrol Networks, Inc. IP device discovery systems and methods
US10444964B2 (en) 2007-06-12 2019-10-15 Icontrol Networks, Inc. Control system user interface
US10127802B2 (en) 2010-09-28 2018-11-13 Icontrol Networks, Inc. Integrated security system with parallel processing architecture
US9729342B2 (en) 2010-12-20 2017-08-08 Icontrol Networks, Inc. Defining and implementing sensor triggered response rules
US9609003B1 (en) 2007-06-12 2017-03-28 Icontrol Networks, Inc. Generating risk profile using data of home monitoring and security system
US10375253B2 (en) 2008-08-25 2019-08-06 Icontrol Networks, Inc. Security system with networked touchscreen and gateway
US11113950B2 (en) 2005-03-16 2021-09-07 Icontrol Networks, Inc. Gateway integrated with premises security system
US11343380B2 (en) 2004-03-16 2022-05-24 Icontrol Networks, Inc. Premises system automation
US10313303B2 (en) 2007-06-12 2019-06-04 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
AU2005223267B2 (en) 2004-03-16 2010-12-09 Icontrol Networks, Inc. Premises management system
US10339791B2 (en) 2007-06-12 2019-07-02 Icontrol Networks, Inc. Security network integrated with premise security system
US10200504B2 (en) 2007-06-12 2019-02-05 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US9191228B2 (en) 2005-03-16 2015-11-17 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US10237237B2 (en) 2007-06-12 2019-03-19 Icontrol Networks, Inc. Communication protocols in integrated systems
US11244545B2 (en) 2004-03-16 2022-02-08 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US11277465B2 (en) 2004-03-16 2022-03-15 Icontrol Networks, Inc. Generating risk profile using data of home monitoring and security system
US20090077623A1 (en) 2005-03-16 2009-03-19 Marc Baum Security Network Integrating Security System and Network Devices
US11811845B2 (en) 2004-03-16 2023-11-07 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US11677577B2 (en) 2004-03-16 2023-06-13 Icontrol Networks, Inc. Premises system management using status signal
US10522026B2 (en) 2008-08-11 2019-12-31 Icontrol Networks, Inc. Automation system user interface with three-dimensional display
US10348575B2 (en) 2013-06-27 2019-07-09 Icontrol Networks, Inc. Control system user interface
US10382452B1 (en) 2007-06-12 2019-08-13 Icontrol Networks, Inc. Communication protocols in integrated systems
US8963713B2 (en) 2005-03-16 2015-02-24 Icontrol Networks, Inc. Integrated security network with security alarm signaling system
US11916870B2 (en) 2004-03-16 2024-02-27 Icontrol Networks, Inc. Gateway registry methods and systems
US7711796B2 (en) 2006-06-12 2010-05-04 Icontrol Networks, Inc. Gateway registry methods and systems
US11201755B2 (en) 2004-03-16 2021-12-14 Icontrol Networks, Inc. Premises system management using status signal
US9531593B2 (en) 2007-06-12 2016-12-27 Icontrol Networks, Inc. Takeover processes in security network integrated with premise security system
US10156959B2 (en) 2005-03-16 2018-12-18 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US11316958B2 (en) 2008-08-11 2022-04-26 Icontrol Networks, Inc. Virtual device systems and methods
US11489812B2 (en) 2004-03-16 2022-11-01 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
US20170118037A1 (en) 2008-08-11 2017-04-27 Icontrol Networks, Inc. Integrated cloud system for premises automation
US8988221B2 (en) 2005-03-16 2015-03-24 Icontrol Networks, Inc. Integrated security system with parallel processing architecture
US11159484B2 (en) 2004-03-16 2021-10-26 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
US10645347B2 (en) 2013-08-09 2020-05-05 Icn Acquisition, Llc System, method and apparatus for remote monitoring
US20110128378A1 (en) 2005-03-16 2011-06-02 Reza Raji Modular Electronic Display Platform
US11496568B2 (en) 2005-03-16 2022-11-08 Icontrol Networks, Inc. Security system with networked touchscreen
US9450776B2 (en) 2005-03-16 2016-09-20 Icontrol Networks, Inc. Forming a security network including integrated security system components
US11700142B2 (en) 2005-03-16 2023-07-11 Icontrol Networks, Inc. Security network integrating security system and network devices
US20120324566A1 (en) 2005-03-16 2012-12-20 Marc Baum Takeover Processes In Security Network Integrated With Premise Security System
US11615697B2 (en) 2005-03-16 2023-03-28 Icontrol Networks, Inc. Premise management systems and methods
US20170180198A1 (en) 2008-08-11 2017-06-22 Marc Baum Forming a security network including integrated security system components
US10999254B2 (en) 2005-03-16 2021-05-04 Icontrol Networks, Inc. System for data routing in networks
US9306809B2 (en) 2007-06-12 2016-04-05 Icontrol Networks, Inc. Security system with networked touchscreen
US7698417B2 (en) * 2005-06-15 2010-04-13 Microsoft Corporation Optimized performance counter monitoring
US7636711B2 (en) * 2005-06-28 2009-12-22 Microsoft Corporation Extensible workflows
WO2007056747A2 (en) 2005-11-08 2007-05-18 Conexant Systems Collision avoidance systems and methods
US8031661B2 (en) * 2005-11-08 2011-10-04 Intellectual Ventures I Llc Symmetric transmit opportunity (TXOP) truncation
US7756828B2 (en) * 2006-02-28 2010-07-13 Microsoft Corporation Configuration management database state model
JP2007318740A (ja) * 2006-04-24 2007-12-06 Fujitsu Ltd 対応支援方法、対応支援システム、対応支援装置及びコンピュータプログラム
US8504679B2 (en) * 2006-05-09 2013-08-06 Netlq Corporation Methods, systems and computer program products for managing execution of information technology (IT) processes
US7726309B2 (en) * 2006-06-05 2010-06-01 Ric Investments, Llc Flexible connector
US10079839B1 (en) 2007-06-12 2018-09-18 Icontrol Networks, Inc. Activation of gateway device
US8488447B2 (en) 2006-06-30 2013-07-16 Centurylink Intellectual Property Llc System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance
US8289965B2 (en) 2006-10-19 2012-10-16 Embarq Holdings Company, Llc System and method for establishing a communications session with an end-user based on the state of a network connection
US8000318B2 (en) 2006-06-30 2011-08-16 Embarq Holdings Company, Llc System and method for call routing based on transmission performance of a packet network
US8717911B2 (en) 2006-06-30 2014-05-06 Centurylink Intellectual Property Llc System and method for collecting network performance information
US9094257B2 (en) 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8194643B2 (en) 2006-10-19 2012-06-05 Embarq Holdings Company, Llc System and method for monitoring the connection of an end-user to a remote network
US7765294B2 (en) 2006-06-30 2010-07-27 Embarq Holdings Company, Llc System and method for managing subscriber usage of a communications network
US7948909B2 (en) 2006-06-30 2011-05-24 Embarq Holdings Company, Llc System and method for resetting counters counting network performance information at network communications devices on a packet network
US8223654B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc Application-specific integrated circuit for monitoring and optimizing interlayer network performance
US8224255B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for managing radio frequency windows
US8107366B2 (en) 2006-08-22 2012-01-31 Embarq Holdings Company, LP System and method for using centralized network performance tables to manage network communications
US8144587B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
US9479341B2 (en) 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US7808918B2 (en) * 2006-08-22 2010-10-05 Embarq Holdings Company, Llc System and method for dynamically shaping network traffic
US8576722B2 (en) 2006-08-22 2013-11-05 Centurylink Intellectual Property Llc System and method for modifying connectivity fault management packets
US8144586B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for controlling network bandwidth with a connection admission control engine
US8307065B2 (en) 2006-08-22 2012-11-06 Centurylink Intellectual Property Llc System and method for remotely controlling network operators
US8189468B2 (en) 2006-10-25 2012-05-29 Embarq Holdings, Company, LLC System and method for regulating messages between networks
US8064391B2 (en) 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US7940735B2 (en) 2006-08-22 2011-05-10 Embarq Holdings Company, Llc System and method for selecting an access point
US8531954B2 (en) 2006-08-22 2013-09-10 Centurylink Intellectual Property Llc System and method for handling reservation requests with a connection admission control engine
US8098579B2 (en) 2006-08-22 2012-01-17 Embarq Holdings Company, LP System and method for adjusting the window size of a TCP packet through remote network elements
US8238253B2 (en) 2006-08-22 2012-08-07 Embarq Holdings Company, Llc System and method for monitoring interlayer devices and optimizing network performance
US8750158B2 (en) 2006-08-22 2014-06-10 Centurylink Intellectual Property Llc System and method for differentiated billing
US8228791B2 (en) 2006-08-22 2012-07-24 Embarq Holdings Company, Llc System and method for routing communications between packet networks based on intercarrier agreements
US8194555B2 (en) 2006-08-22 2012-06-05 Embarq Holdings Company, Llc System and method for using distributed network performance information tables to manage network communications
US8537695B2 (en) 2006-08-22 2013-09-17 Centurylink Intellectual Property Llc System and method for establishing a call being received by a trunk on a packet network
US8015294B2 (en) 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US8619600B2 (en) 2006-08-22 2013-12-31 Centurylink Intellectual Property Llc System and method for establishing calls over a call path having best path metrics
US8743703B2 (en) 2006-08-22 2014-06-03 Centurylink Intellectual Property Llc System and method for tracking application resource usage
US8223655B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for provisioning resources of a packet network based on collected network performance information
US8130793B2 (en) 2006-08-22 2012-03-06 Embarq Holdings Company, Llc System and method for enabling reciprocal billing for different types of communications over a packet network
US8274905B2 (en) 2006-08-22 2012-09-25 Embarq Holdings Company, Llc System and method for displaying a graph representative of network performance over a time period
US8040811B2 (en) 2006-08-22 2011-10-18 Embarq Holdings Company, Llc System and method for collecting and managing network performance information
US7843831B2 (en) 2006-08-22 2010-11-30 Embarq Holdings Company Llc System and method for routing data on a packet network
US8407765B2 (en) 2006-08-22 2013-03-26 Centurylink Intellectual Property Llc System and method for restricting access to network performance information tables
US7684332B2 (en) 2006-08-22 2010-03-23 Embarq Holdings Company, Llc System and method for adjusting the window size of a TCP packet through network elements
US8125897B2 (en) 2006-08-22 2012-02-28 Embarq Holdings Company Lp System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets
US8549405B2 (en) 2006-08-22 2013-10-01 Centurylink Intellectual Property Llc System and method for displaying a graphical representation of a network to identify nodes and node segments on the network that are not operating normally
US7889660B2 (en) 2006-08-22 2011-02-15 Embarq Holdings Company, Llc System and method for synchronizing counters on an asynchronous packet communications network
US8199653B2 (en) 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
EP1916621A1 (de) * 2006-10-26 2008-04-30 Hewlett-Packard Development Company, L.P. Anpassen von Computer-Netzwerken
US11706279B2 (en) 2007-01-24 2023-07-18 Icontrol Networks, Inc. Methods and systems for data communication
WO2008098066A2 (en) * 2007-02-06 2008-08-14 Entropic Communications Inc. A layer-2 management entity messaging framework in a network
US7633385B2 (en) 2007-02-28 2009-12-15 Ucontrol, Inc. Method and system for communicating with and controlling an alarm system from a remote server
US8451986B2 (en) 2007-04-23 2013-05-28 Icontrol Networks, Inc. Method and system for automatically providing alternate network access for telecommunications
US8111692B2 (en) 2007-05-31 2012-02-07 Embarq Holdings Company Llc System and method for modifying network traffic
US8176180B2 (en) * 2007-06-04 2012-05-08 International Business Machines Corporation Dynamically matching data service capabilities to data service level objectives
US10616075B2 (en) 2007-06-12 2020-04-07 Icontrol Networks, Inc. Communication protocols in integrated systems
US10523689B2 (en) 2007-06-12 2019-12-31 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US10498830B2 (en) 2007-06-12 2019-12-03 Icontrol Networks, Inc. Wi-Fi-to-serial encapsulation in systems
US11646907B2 (en) 2007-06-12 2023-05-09 Icontrol Networks, Inc. Communication protocols in integrated systems
US11218878B2 (en) 2007-06-12 2022-01-04 Icontrol Networks, Inc. Communication protocols in integrated systems
US11089122B2 (en) 2007-06-12 2021-08-10 Icontrol Networks, Inc. Controlling data routing among networks
US11212192B2 (en) 2007-06-12 2021-12-28 Icontrol Networks, Inc. Communication protocols in integrated systems
US11237714B2 (en) 2007-06-12 2022-02-01 Control Networks, Inc. Control system user interface
US10389736B2 (en) 2007-06-12 2019-08-20 Icontrol Networks, Inc. Communication protocols in integrated systems
US11601810B2 (en) 2007-06-12 2023-03-07 Icontrol Networks, Inc. Communication protocols in integrated systems
US10051078B2 (en) * 2007-06-12 2018-08-14 Icontrol Networks, Inc. WiFi-to-serial encapsulation in systems
US11316753B2 (en) 2007-06-12 2022-04-26 Icontrol Networks, Inc. Communication protocols in integrated systems
US10423309B2 (en) 2007-06-12 2019-09-24 Icontrol Networks, Inc. Device integration framework
US11423756B2 (en) 2007-06-12 2022-08-23 Icontrol Networks, Inc. Communication protocols in integrated systems
US12003387B2 (en) 2012-06-27 2024-06-04 Comcast Cable Communications, Llc Control system user interface
US10666523B2 (en) 2007-06-12 2020-05-26 Icontrol Networks, Inc. Communication protocols in integrated systems
US11831462B2 (en) 2007-08-24 2023-11-28 Icontrol Networks, Inc. Controlling data routing in premises management systems
US8682705B2 (en) 2007-12-28 2014-03-25 International Business Machines Corporation Information technology management based on computer dynamically adjusted discrete phases of event correlation
US8447859B2 (en) 2007-12-28 2013-05-21 International Business Machines Corporation Adaptive business resiliency computer system for information technology environments
US7958393B2 (en) * 2007-12-28 2011-06-07 International Business Machines Corporation Conditional actions based on runtime conditions of a computer system environment
US20090172149A1 (en) 2007-12-28 2009-07-02 International Business Machines Corporation Real-time information technology environments
US8341014B2 (en) 2007-12-28 2012-12-25 International Business Machines Corporation Recovery segments for computer business applications
US8990810B2 (en) 2007-12-28 2015-03-24 International Business Machines Corporation Projecting an effect, using a pairing construct, of execution of a proposed action on a computing environment
US8763006B2 (en) 2007-12-28 2014-06-24 International Business Machines Corporation Dynamic generation of processes in computing environments
US8868441B2 (en) 2007-12-28 2014-10-21 International Business Machines Corporation Non-disruptively changing a computing environment
US9558459B2 (en) 2007-12-28 2017-01-31 International Business Machines Corporation Dynamic selection of actions in an information technology environment
US8326910B2 (en) 2007-12-28 2012-12-04 International Business Machines Corporation Programmatic validation in an information technology environment
US8826077B2 (en) 2007-12-28 2014-09-02 International Business Machines Corporation Defining a computer recovery process that matches the scope of outage including determining a root cause and performing escalated recovery operations
US8346931B2 (en) 2007-12-28 2013-01-01 International Business Machines Corporation Conditional computer runtime control of an information technology environment based on pairing constructs
US8782662B2 (en) 2007-12-28 2014-07-15 International Business Machines Corporation Adaptive computer sequencing of actions
US8751283B2 (en) 2007-12-28 2014-06-10 International Business Machines Corporation Defining and using templates in configuring information technology environments
US8677174B2 (en) 2007-12-28 2014-03-18 International Business Machines Corporation Management of runtime events in a computer environment using a containment region
US8375244B2 (en) 2007-12-28 2013-02-12 International Business Machines Corporation Managing processing of a computing environment during failures of the environment
US8428983B2 (en) 2007-12-28 2013-04-23 International Business Machines Corporation Facilitating availability of information technology resources based on pattern system environments
US8365185B2 (en) 2007-12-28 2013-01-29 International Business Machines Corporation Preventing execution of processes responsive to changes in the environment
US11916928B2 (en) 2008-01-24 2024-02-27 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US8068425B2 (en) 2008-04-09 2011-11-29 Embarq Holdings Company, Llc System and method for using network performance information to determine improved measures of path states
US20170185278A1 (en) 2008-08-11 2017-06-29 Icontrol Networks, Inc. Automation system user interface
US11729255B2 (en) 2008-08-11 2023-08-15 Icontrol Networks, Inc. Integrated cloud system with lightweight gateway for premises automation
US10530839B2 (en) 2008-08-11 2020-01-07 Icontrol Networks, Inc. Integrated cloud system with lightweight gateway for premises automation
US11758026B2 (en) 2008-08-11 2023-09-12 Icontrol Networks, Inc. Virtual device systems and methods
US11258625B2 (en) 2008-08-11 2022-02-22 Icontrol Networks, Inc. Mobile premises automation platform
US11792036B2 (en) 2008-08-11 2023-10-17 Icontrol Networks, Inc. Mobile premises automation platform
US9628440B2 (en) 2008-11-12 2017-04-18 Icontrol Networks, Inc. Takeover processes in security network integrated with premise security system
US8638211B2 (en) 2009-04-30 2014-01-28 Icontrol Networks, Inc. Configurable controller and interface for home SMA, phone and multimedia
US20110012902A1 (en) * 2009-07-16 2011-01-20 Jaganathan Rajagopalan Method and system for visualizing the performance of applications
US8885010B2 (en) * 2010-03-04 2014-11-11 Telefonica, S.A. Multipoint conference method that does not use a server
EP2569712B1 (de) 2010-05-10 2021-10-13 Icontrol Networks, Inc. Benutzeroberfläche für ein steuersystem
US9430502B1 (en) * 2010-09-10 2016-08-30 Tellabs Operations, Inc. Method and apparatus for collecting and storing statistics data from network elements using scalable architecture
US8836467B1 (en) 2010-09-28 2014-09-16 Icontrol Networks, Inc. Method, system and apparatus for automated reporting of account and sensor zone information to a central station
US9230314B2 (en) * 2010-11-08 2016-01-05 Nec Corporation Information processing device having a function to control QoS of media analysis system
US11750414B2 (en) 2010-12-16 2023-09-05 Icontrol Networks, Inc. Bidirectional security sensor communication for a premises security system
US9147337B2 (en) 2010-12-17 2015-09-29 Icontrol Networks, Inc. Method and system for logging security event data
US8914499B2 (en) * 2011-02-17 2014-12-16 Zenoss, Inc. Method and apparatus for event correlation related to service impact analysis in a virtualized environment
US8903893B2 (en) * 2011-11-15 2014-12-02 International Business Machines Corporation Diagnostic heartbeating in a distributed data processing environment
US8521574B1 (en) 2012-06-20 2013-08-27 International Business Machines Corporation Prioritizing client accounts
US9077631B2 (en) * 2012-10-04 2015-07-07 Verizon Patent And Licensing Inc. Network capacity planning
GB2507338A (en) 2012-10-26 2014-04-30 Ibm Determining system topology graph changes in a distributed computing system
US9857825B1 (en) * 2012-10-29 2018-01-02 Washington State University Rate based failure detection
US9071677B2 (en) * 2013-02-12 2015-06-30 Unify Square, Inc. Enhanced data capture, analysis, and reporting for unified communications
US9928975B1 (en) 2013-03-14 2018-03-27 Icontrol Networks, Inc. Three-way switch
US9867143B1 (en) 2013-03-15 2018-01-09 Icontrol Networks, Inc. Adaptive Power Modulation
US9287727B1 (en) 2013-03-15 2016-03-15 Icontrol Networks, Inc. Temporal voltage adaptive lithium battery charger
EP3061209B1 (de) * 2013-10-23 2018-10-03 Telefonaktiebolaget LM Ericsson (publ) Verfahren, knoten und computerprogramm zur aktivierung der zuweisung von ressourcenkomponenten
US11405463B2 (en) 2014-03-03 2022-08-02 Icontrol Networks, Inc. Media content management
US11146637B2 (en) 2014-03-03 2021-10-12 Icontrol Networks, Inc. Media content management
US20160006500A1 (en) * 2014-07-02 2016-01-07 At&T Intellectual Property I, L.P. Satellite packet network for cellular backhaul of access point devices
US11430072B1 (en) 2014-07-31 2022-08-30 Intuit Inc. System and method of generating estimates used to calculate taxes
US11861734B1 (en) 2014-08-18 2024-01-02 Intuit Inc. Methods systems and articles of manufacture for efficiently calculating a tax return in a tax return preparation application
US9853863B1 (en) 2014-10-08 2017-12-26 Servicenow, Inc. Collision detection using state management of configuration items
US11222384B1 (en) * 2014-11-26 2022-01-11 Intuit Inc. System and method for automated data estimation for tax preparation
US10235722B1 (en) 2014-11-26 2019-03-19 Intuit Inc. Systems and methods for analyzing and determining estimated taxes
US10140666B1 (en) 2015-03-30 2018-11-27 Intuit Inc. System and method for targeted data gathering for tax preparation
WO2017028880A1 (en) * 2015-08-14 2017-02-23 Telefonaktiebolaget Lm Ericsson (Publ) Service level agreement in radio base station
US10986011B2 (en) * 2017-10-18 2021-04-20 Google Llc Unobtrusive support for third-party traffic monitoring
US20220353158A1 (en) * 2019-09-09 2022-11-03 Ntt Docomo, Inc. Service quality management system
US11388077B2 (en) * 2019-10-30 2022-07-12 Netspective Communications Llc Computer-executable and traceable metric queues system

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5583792A (en) * 1994-05-27 1996-12-10 San-Qi Li Method and apparatus for integration of traffic measurement and queueing performance evaluation in a network system
US6578077B1 (en) * 1997-05-27 2003-06-10 Novell, Inc. Traffic monitoring tool for bandwidth management
US6678250B1 (en) * 1999-02-19 2004-01-13 3Com Corporation Method and system for monitoring and management of the performance of real-time networks
US6631122B1 (en) * 1999-06-11 2003-10-07 Nortel Networks Limited Method and system for wireless QOS agent for all-IP network
US20020019843A1 (en) * 2000-04-26 2002-02-14 Killian Robert T. Multiprocessor object control
US7307954B1 (en) * 2000-06-23 2007-12-11 Nokia Corporation Differentiated service network and method of operating a differentiated service network
US7277962B2 (en) * 2000-12-01 2007-10-02 Fujitsu Limited Method and apparatus for packet scheduling using virtual time stamp for high capacity combined input and output queued switching system
US6917589B2 (en) * 2001-01-25 2005-07-12 Agere Systems Inc. Automatic quality of service assignment in ethernet switches
GB0104973D0 (en) * 2001-02-28 2001-04-18 Nokia Networks Oy Quality of service monitor
US7197557B1 (en) * 2001-05-29 2007-03-27 Keynote Systems, Inc. Method and system for evaluating quality of service for streaming audio and video
US20050013244A1 (en) * 2001-12-14 2005-01-20 Parlos Alexander G System for actively controlling distributed applications
US6850525B2 (en) * 2002-01-04 2005-02-01 Level 3 Communications, Inc. Voice over internet protocol (VoIP) network performance monitor
US20040205752A1 (en) * 2003-04-09 2004-10-14 Ching-Roung Chou Method and system for management of traffic processor resources supporting UMTS QoS classes
US7430179B2 (en) * 2003-06-28 2008-09-30 Geopacket Corporation Quality determination for packetized information
WO2005013567A1 (ja) * 2003-08-05 2005-02-10 Fujitsu Limited 通信区間の品質の分析システム
US7466692B2 (en) * 2004-09-09 2008-12-16 Alcatel-Lucent Usa Inc. Method and apparatus for performing quality-of-service calculations on packet-based networks
US20060218271A1 (en) * 2005-03-16 2006-09-28 Nokia Corporation Triggered statistics reporting

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8433541B2 (en) 2009-01-12 2013-04-30 Repower Systems Ag Method and system for monitoring a wind energy installation
CN105991366A (zh) * 2015-03-05 2016-10-05 ***通信集团福建有限公司 一种业务监控方法及***

Also Published As

Publication number Publication date
US20060245369A1 (en) 2006-11-02
US7924732B2 (en) 2011-04-12

Similar Documents

Publication Publication Date Title
DE102006018232A1 (de) Dienstqualität in IT-Infrastrukturen
DE60214862T2 (de) Methode für die verbesserte verwaltung von einer ereignisdatenbasis und system für ereignismeldung in einem netzwerk
DE60214994T2 (de) Verfahren und system zur verringerung von falschalarmen in netzwerkfehlermanagementsystemen
DE102004016850B4 (de) Verfahren, Management-Server und Computerprogramm zum Zuordnen von Status-Nachrichten überwachter Objekte einer IT-Ifrastruktur
DE60108608T2 (de) Verfahren und Vorrichtung zur effizienten reaktiven Überwachung
DE69634928T2 (de) Netzwerkverwaltungssystem mit verbesserter Knotenerkennung und -überwachung
DE69432746T2 (de) Ereignisverarbeitungssystem und Verfahren zur Herstellen eines solchen Systems
US7831708B2 (en) Method and system to aggregate evaluation of at least one metric across a plurality of resources
US7058704B1 (en) Method and apparatus for implementing a service-level agreement
US20060117059A1 (en) System and method for monitoring and managing performance and availability data from multiple data providers using a plurality of executable decision trees to consolidate, correlate, and diagnose said data
DE60220287T2 (de) System und verfahren zur überwachung von software-warteschlangenanwendungen
US6609083B2 (en) Adaptive performance data measurement and collections
DE60000307T2 (de) Verfahren und Vorrichtung zur Feststellung von Service Abweichungen in transaktionsorientierten Netzwerken
DE102005028926B4 (de) Fehlertolerantes Modulartesten von Diensten
DE19607515A1 (de) Ein Computerbetriebsverwaltungssystem für ein Computerbetriebssystem, das dazu in der Lage ist gleichzeitig eine Mehrzahl von Anwendungsprogrammen auszuführen
DE102006041058B4 (de) Verfahren zur Nachführung von Netzparametern
DE102005020893A1 (de) System zur adaptiven Bestimmung von Operationseigenschaften einer ausführbaren Anwendung
DE10306598B4 (de) Verfahren und Vorrichtung zum Bestimmen einer Verfügbarkeit von zusammenarbeitende Hardware- und Softwarekomponenten umfassenden elektronischen Systemen und entsprechendes Computerprogramm
DE112019007400T5 (de) Verfahren zur Verifizierung eines Interrupt-Antriebssystems basierend auf einem Interrupt-Sequenzdiagramm
DE60302846T2 (de) Vorrichtung und Verfahren zur Planung der Konfiguration eines Telekommunikationsnetzwerkes mittels Vorhersage des Wandels
DE602005002418T2 (de) Verwaltungsverfahren und -system für Netzverwaltungssysteme
EP1520433A1 (de) Erkennung von dienst-minderleistungen in einem kommunikationsnetz
DE69801896T2 (de) Verfahren und system zur leistungmessung und beobachtung der qualitaet eines informationssystem
DE19640346C2 (de) Verfahren zum Überprüfen eines gemäß einem Kommunikationsprotokoll durchgeführten Datenaustausches
Kosinski et al. Definition and evaluation of penalty functions in sla management framework

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOU, US

Free format text: FORMER OWNER: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., HOUSTON, TEX., US

Owner name: ENTIT SOFTWARE LLC, SUNNYVALE, US

Free format text: FORMER OWNER: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., HOUSTON, TEX., US

R082 Change of representative

Representative=s name: SAMSON & PARTNER PATENTANWAELTE MBB, DE

R081 Change of applicant/patentee

Owner name: ENTIT SOFTWARE LLC, SUNNYVALE, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TEX., US

R082 Change of representative

Representative=s name: SAMSON & PARTNER PATENTANWAELTE MBB, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee