DE112010003144T5

DE112010003144T5 - Erweiterbare Grundstruktur zur Unterstützung verschiedener Einsatzarchitekturen

Info

Publication number: DE112010003144T5
Application number: DE112010003144T
Authority: DE
Inventors: Devendra Rajkumar Jaisinghani
Original assignee: eBay Inc
Current assignee: eBay Inc
Priority date: 2009-07-31
Filing date: 2010-07-30
Publication date: 2012-07-05
Also published as: US20110029673A1; US9491117B2; CN102576354A; US20160043903A1; US10374978B2; WO2011014827A1; US9729468B2; US20110029981A1; US10931599B2; US9329951B2; US20120102180A1; GB2485712A8; US20130080902A1; US20160197851A1; US8316305B2; US9201557B2; GB201203172D0; US20110029882A1; GB2485712B; US20110029810A1

Abstract

Ein Verfahren zum Managen von Diensten und Ressourcen über eine Vielzahl von Einsatzarchitekturen wird beschrieben. Das Verfahren beginnt durch Definieren eines Profils, das einer Einsatzarchitektur entspricht. Jedes Profil wird gemäß einem Metamodell definiert. Das Metamodell umfasst ein Dienstobjekt, das einen Dienst darstellt, der über ein Netzwerk zugänglich ist, Ressourcenobjekte, die von dem Dienst verbrauchte Ressourcen darstellen, Zwischenbeziehungen zwischen dem Dienst und den Ressourcen und Zwischenbeziehungen zwischen den Ressourcen. Für jedes Profil wird basierend auf dem Profil eine Topologie erzeugt. Die Topologie umfasst die Ressourcen, die verwendet werden, um eine Aufgabe auszuführen.

Description

Querverweis
Diese Erfindung beansprucht den Prioritätsvorteil der vorläufigen US-Anmeldung Nr. 61/230 254, eingereicht am 31. Juli 2009 mit dem Titel „Management of Services and Resources” und der US-Anmeldung Nr. 12/718 924, eingereicht am 5. März 2010 mit dem Titel „Extensible Framework to Support Different Deployment Architectures”, die hier in ihrer Gesamtheit per Referenz eingebunden sind.
Gebiet
Die vorliegende Anmeldung betrifft allgemein das Management bzw. die Verwaltung von Diensten und Betriebsmitteln bzw. Ressourcen in einem Datenzentrum oder einer Cloud-Computing-Umgebung und in einem spezifischen Beispiel eine erweiterbare Grundstruktur zur Unterstützung verschiedener Einsatzarchitekturen.
Hintergrund
In einer Datenzentrumsumgebung kann es viele Dienste geben, um Geschäftsziele zu erreichen oder um andere Dienste zu unterstützen. In machen Kontexten können diese Dienste das Handeln (Artikel verkaufen, zu verkaufenden Artikel ansehen, etc.), Nachrichtenübermittlungsdienste und Suchen umfassen. Alle diese Dienste verbrauchen Hardware- und Software-Ressourcen. Beispiele für Hardware-Ressourcen umfassen Rechner (Server), das Netzwerk (Switches bzw. Vermittlungsstellen, Load-Balancer bzw. Lastausgleicher bzw. Lastverteiler, Firewalls, etc.), Speicher (SAN, NAS, etc.), und jene für die Letzteren enthalten das Betriebssystem, einen Anwendungsplattformstapel (Java Virtual Machine, Tomcat Servlet Container, etc.) und eine Datenbank. Diese Hardware- und Software-Ressourcen werden abhängig von den Anforderungen des bestimmten Dienstes in verschiedenen Konfigurationen eingerichtet. Auf die Konfigurationen wird als „Einsatzarchitekturen” Bezug genommen. Beispiele für Einsatzarchitekturen umfassen die traditionelle 3-Schichten-Architektur (Web-Schicht, Anwendungsschicht, Datenbankschicht, die jeweils einen Lastausgleicher für die die Verkehrsverteilung haben können), eine Nachrichtenübermittlungsdienstinfrastruktur, etc. Innerhalb dieser kann es Variationen geben, zum Beispiel können Lastausgleicher paarweise eingesetzt werden, um eine hohe Verfügbarkeit (HA) bereitzustellen. Herkömmlicherweise gab es Managementsysteme für jede Teilmenge der Datenzentrumsumgebung. Zum Beispiel gibt es Netzmanagementsysteme, die sich auf das Managen (z. B. Konfigurieren, Funktionsprüfen, Leistungsüberwachen) von Switches konzentrieren. Andere konzentrieren sich auf Anwendungen (z. B. Anwendungseinsatz, etc.). Dies führt zu einer Ausuferung von Managementsystemen.
Kurze Beschreibung der Zeichnungen
Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen dargestellt, wobei:
1 ein Blockdiagamm einer Netzwerkumgebung ist, in der verschiedene Ausführungsformen betrieben werden können.
2 ein Blockdiagramm eines Managementsystems gemäß verschiedenen Ausführungsformen ist.
3 ein Flussdiagramm eines Verfahrens zur Verwendung einer Modellgrundstruktur in der Domänenanordnung gemäß verschiedenen Ausführungsformen ist.
4 eine Hierarchie von Objekten innerhalb einer Ressourcen-Klassifikation gemäß verschiedenen Ausführungsformen ist.
5 ein Blockdiagramm einer Modellstruktur für Hardware- und Software-Ressourcen gemäß einigen Ausführungsformen ist.
6 ein Blockdiagramm einer Modellstruktur ist, die zu einer Gruppe gemäß verschiedenen Ausführungsformen gehört.
7 ein Blockdiagramm einer Modellstruktur zum Speichern von Daten gemäß verschiedenen Ausführungsformen ist.
8 eine schematische Maschinendarstellung ist, innerhalb, welcher ein Satz von Anweisungen ausgeführt werden kann, um die Maschine eine oder mehrere der hier diskutierten Methodiken durchführen zu lassen.
9 ein Blockdiagramm einer Profilerzeugungseinrichtung gemäß verschiedenen Ausführungsformen ist.
10 ein Blockdiagramm eines in zwei Schichten strukturierten Informationsmodells gemäß einigen Ausführungsformen ist.
Detaillierte Beschreibung
Beispielverfahren und Systeme zum Managen von Diensten in einer Datenzentrumsumgebung und von diesen Diensten verbrauchten Ressourcen unter Verwendung einer erweiterbaren Grundstruktur werden beschrieben. In der folgenden Beschreibung sind für Erklärungszwecke zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis von Beispielausführungsformen bereitzustellen. Es wird jedoch für Fachleute der Technik offensichtlich, dass die vorliegende Erfindung ohne diese spezifischen Details in die Praxis umgesetzt werden kann. Wie er hier verwendet wird, kann der Begriff „oder” in einem einschließenden oder ausschließenden Sinn ausgelegt werden.
In einem großen Unternehmensrechensystem werden Dienste unter Verwendung verschiedener Systeme bereitgestellt. Beispiele für derartige Systeme stellen Handelsdienste, Suchdienste, Nachrichtenübermittlungsdienste, Bezahldienste und Webveröffentlichungsdienste bereit. Da jedes System getrennte Funktionen durchführt, hängt der Betrieb eines Unternehmensrechensystems als ein Ganzes von der Leistungsfähigkeit jedes der anderen Systeme ab. Dies gilt insbesondere, wenn mehr als ein System verwendet wird, um eine Transaktion oder einen „Fluss” auszuführen. Um zum Beispiel einen Verkauf in einem Internethandelssystem abzuschließen, können die Systeme, die den Such-, Webveröffentlichungs-, Bezahl- und Nachrichtenübermittlungsdiensten entsprechen, zu bestimmten Zeiten in dem Fluss verwendet werden.
Die Systeme sind unter Verwendung einer oder mehrerer Ressourcen implementiert. Die Ressourcen können Hardware-Ressourcen und/oder Software-Ressourcen sein. Beispiele für Hardware-Ressourcen umfassen Server, Router, Lastausgleicher und ähnliches. Beispiele für Software-Ressourcen umfassen Betriebssysteme, Anwendungen und ähnliches.
In dem Kontext eines Managementsystems wird jede gemanagte Funktionseinheit (d. h. ein Dienst oder eine Ressource) im Hinblick auf ihre Betriebskonfiguration, Leistung und ihren Status (zum Beispiel aktiven Status) modelliert. Ferner steht jede derartige modellierte Funktionseinheit in Beziehung mit einer oder mehreren modellierten Funktionseinheiten, um die realen Beziehungen widerzuspiegeln. Zum Beispiel läuft ein Computerprogramm (eine Anwendung) auf einem Betriebssystem, und daher spiegeln entsprechende modellierte Funktionseinheiten im Inneren des Managementsystems auch diese Beziehung wider. Das sich ergebende Modell aus modellierten Funktionseinheiten (wobei jede Funktionseinheit aus Attributen besteht, die ihre Konfiguration, Leistung und ihren Status spezifizieren) und ihre Zwischenbeziehungen sind als ein Informationsmodell bekannt. Das Informationsmodell wird in einem Modellierungswerkzeug erzeugt und in einer Modellablage gespeichert, die zum Beispiel von Systemarchitekten verwendet werden soll.
Jede Art von Dienst hat eine Einsatzarchitektur, welche die verschiedenen Bestandteilressourcen, ihre Zwischenbeziehungen und gegebenenfalls ihre Abhängigkeiten von anderen Diensten zeigt. In dem Kontext eines modellgetriebenen Managementsystems kann die Einsatzarchitektur jedes Dienstes in Form eines spezifischen Informationsmodells spezifiziert werden. In diesem Kontext wird auf das Informationsmodell als ein Einsatzprofil („Profil”) Bezug genommen. Somit wird das Profil verwendet, um die Einsatzarchitektur in Form ihrer funktionalen und nichtfunktionalen Kriterien zu spezifizieren. Zur Veranschaulichung kann das einfachste Profil die „Anzahl N von Servern” sein, wobei die Server zusammenhängend zugewiesen werden. Ein anderes Profil kann der herkömmlichen 3-Schichten-Architektur entsprechen, die aus Lastausgleichern, Servern, die als Webserver verwendet werden sollen, Servern, die als Anwendungsserver verwendet werden sollen, Servern, die als Datenbankserver verwendet werden sollen, und einem Schicht-3-Switch, um LAN-Vermittlung und Schicht-3-Routing zwischen VLANs bereitzustellen, besteht. Die drei Servertypen können unterschiedliche Fähigkeiten haben (z. B. können Datenbankserver große Big-Iron-Boxen sein, und die Webserver können Blade-Server oder sogar virtuelle Maschinen sein). Andere Variationen können ein anderes Profil ergeben, zum Beispiel können Lastausgleicher in einer Aktiv-Aktiv-(oder Aktiv-Passiv-)Konfiguration eingerichtet sein, um Hochverfügbarkeit bereitzustellen.
Noch ein anderes Profil kann das 3-Schichten-Profil verwenden, um ein Profil eines anderen Dienstes zu erzeugen. Zum Beispiel kann ein Profil spezifizieren, dass der Webserver (Software) auf den Schicht-1-Servern eingesetzt werden soll, dass Anwendungsserver (Software) auf den Schicht-2-Servern eingesetzt werden sollen, und dass eine Datenbank auf Schicht-3-Servern eingesetzt werden soll, und so weiter. In diesen Profilen kann der Anwendungscode, der in den Anwendungsservern eingesetzt werden soll, von anderen Diensten (zum Beispiel einem Protokollierungsdienst) abhängen.
Die verschiedenen Einsatzarchitekturen in einem Datenzentrum oder einer Cloud-Computing-Umgebung haben viele gemeinsame Ressourcentypen, wie etwa Server, Lastausgleicher, Betriebssysteme, etc. Um zuzulassen, dass ein einzelnes Managementsystem mehrere Einsatzarchitekturen versteht, werden die gemeinsamen Ressourcentypdefinitionen zwischen Profilen wiederverwendet. Dies wird durch Strukturieren des Informationsmodells in zwei Schichten, wie in 10 gezeigt, erledigt. Das Basismodul 1002 stellt die Definitionen für gemeinsame Ressourcentypen, wie etwa Server, Betriebssysteme, etc. bereit, während die oberste Schicht die Definitionen für Ressourcen- und Diensttypen bereitstellt, die für einen bestimmten Dienst, wie etwa Handeln 1004, Nachrichtenübermittlungsdienste 1006, Suche 1008, Bezahlung 1010 und Webveröffentlichung 1012 spezifisch sind. Dann wird ein Profil aufgebaut, indem die Dienst- und Ressourcentypen zusammen mit den Typen in dem Basismodul 1002 in eine bestimmte Domäne eingearbeitet werden.
Wenn ein Dienst eingesetzt werden soll, wird seine Einsatzkonfiguration in Form der Anzahl und des Typs von Ressourcen, Konfigurationsparametern von Ressourcen einzeln oder nach Typ spezifiziert, und dann werden geeignete Ressourceninstanzen bestimmt und zugewiesen. Dies erlaubt dem Managementsystem, den Einsatz und andere Lebenszyklus-Managementaufgaben zu automatisieren. In dem Kontext der vorliegenden Erfindung werden derartige Informationen in einer Spezifikation erfasst, die als eine Einsatztopologie (von hier ab als eine Topologie bezeichnet) bezeichnet wird. Eine Topologie ist eine Realisierung eines Profils. Die Spezifikation einer Topologie geht in zwei Stufen voran – logisch und physikalisch. Eine logische Topologie spezifiziert abstrakte Typen von Ressourcen und ihre Mächtigkeiten (z. B. 10 Blade-Server), und eine physikalische Topologie spezifiziert sowohl die konkreten Ressourcentypen als auch ihre spezifischen Instanzen (z. B. IBM LS 20 Blade-Server mit Anlagen-ID 54321 abcde).
Das Managementsystem managt Dienste, die verschiedenen Profilen entsprechen, erlaubt die Einführung neuer Profile und managt daher neue Dienste, wenn sich ein Datenzentrum oder eine Cloud-Computing-Umgebung entwickelt. Ferner tut es dies, ohne die Subsysteme des Managementsystems zu modifizieren oder das Managementsystem erneut einzusetzen oder ein laufendes Managementsystem neu zu starten. Diese Ziele können erreicht werden, indem ein generischer Dienstmanager, ein Metamodell und eine Plug-in-Grundstruktur bereitgestellt werden.
Ein Dienstmanager ist dafür verantwortlich, den Lebenszyklus und das Dienstniveaumanagement eines Dienstes abzuschließen. Beispiele für Lebenszyklusbetriebe umfassen den Einsatz, die Konfiguration, den Start, die Aktivierung, die Aktualisierung etc., und diese Betriebe können als ein Ganzes für den Dienst oder für spezifische oder gruppierte Ressourcen, die von dem Dienst benutzt werden, ausgeführt werden. Jede Instanz eines Dienstmanagers kann mehrere Dienstinstanzen managen, die dem gleichen Profil entsprechen. Diese Spezifität liegt in den Steuerungen, die für einen abstrakten Ressourcentyp (z. B. Lastausgleicher) spezifisch sind, und in den Adaptern, die für einen konkreten Ressourcentyp (z. B. Citrix NetScaler Lastausgleicher) spezifisch sind. Wenn der Dienst das erste Mal eingesetzt wird, untersucht der Dienstmanager die Topologie syntaktisch und lädt die entsprechenden Steuerungen und zugehörigen Adapter dynamisch für jeden eindeutigen Dienst und Ressource, die spezifiziert sind.
Jede Steuerung in einem Dienstmanager managt mehrere Instanzen des gleichen Dienstes oder Ressourcentyps, da sie pro abstraktem Typ definiert ist. Zum Beispiel wird eine einzige Lastausgleichsteuerung verwendet, um alle Lastausgleicher in dem Dienst ungeachtet des bestimmten Fabrikats oder Modells des verwendeten Lastausgleichers zu managen. Adapter sind spezifisch für konkrete Typen (z. B. ein bestimmtes Fabrikat oder Modell) und setzen generische Befehle auf Befehle um, die für die Implementierung spezifisch sind. Zum Beispiel gibt es einen NetScaler-Lastausgleicher-Adapter, einen F5 BigIP-Lastausgleicher-Adapter und so weiter. Um als solches eine Unterstützung für einen Zeus-Lastausgleicher einzuführen, wird nur sein Adapter bereitgestellt. Um einen neuen Typ einzuführen, werden zum Beispiel ein SSL-Beschleuniger, seine Steuerung und Adapter für die konkreten Typen (z. B. eine Adapter für den Coyote Point-SSL-Beschleuniger) bereitgestellt. Die vorstehend angeführten Beispiele sind hardwarespezifisch, aber das Konzept ist ebenso auf Softwaretypen anwendbar.
Die Informationselemente, die verschiedenen Ressourcen- und Diensttypen entsprechen, und die zugehörigen Managementsemantiken werden auf die Steuerungen und Adapter innerhalb eines Dienstmanagers beschränkt. Der Rest des Managementsystems (einschließlich von Dienstmanagerkomponenten außer Steuerungen und Adaptern) arbeitet auf einer höheren Abstraktionsebene des Informationsmodells. Auf diese Abstraktion wird als ein Metamodell Bezug genommen. Da die Subsysteme auf der Ebene des Metamodells arbeiten sollen, werden sie von den Änderungen, die in einem vorhandenen Profil vorgenommen werden, oder durch eine Einführung eines neuen Profils nicht beeinflusst, solange das Profit dem Metamodell entspricht. Somit erlaubt die Verwendung eines Metamodells das Management neuer Dienste, deren Profile möglicherweise neue Modellelemente (z. B. einen neuen Typ, wie etwa einen SSL-Beschleuniger) enthalten können.
Das Metamodell definiert die folgenden acht Metaobjekte: Dienst, Ressource, Teil, Konfiguration, Leistung, Fähigkeit, Gruppe und Anwendungsdaten. Ein Ressourcen-Metaobjekt hat auch Subtypen. Das Metamodell spezifiziert auch die Beziehungen zwischen diesen Metaobjekten. Jeder Typ in einem Profil wird als eines der Metaobjekte klassifiziert (d. h. subtypisiert). Zum Beispiel wird jede Ressource in einem Profil als einer der Ressourcen-Subtypen in dem Metamodell subtypisiert. Als ein konkretes Beispiel werden Lastausgleicher, Switch, Router, Firewall von einem Netzwerkelement subtypisiert, das seinerseits von der Hardware-Ressource subtypisiert wird. Die Hardware-Ressource wird ihrerseits von einer Ressource subtypisiert. Um eine neue Funktionseinheit, zum Beispiel einen SSL-Beschleuniger, einzuführen, kann die neue Funktionseinheit von einem Netzwerkelement abgeleitet werden (was sie durch Verallgemeinerung ebenfalls zu einer Hardware-Ressource und einer Ressource macht).
Das Metamodell kann als ein Modell zum Erzeugen von Profilen gesehen werden. Ein Benutzer oder ein Domänenexperte (z. B. ein Anwendungsarchitekt), der Managementfähigkeiten für einen neuen Dienst einführen möchte, kann die Modellablage überprüfen und aus den verfügbaren Ressourcentypen auswählen und (falls benötigt) für diese Domäne spezifische neue Ressourcen- oder Diensttypen erzeugen. Die neu erzeugten Typen werden von den vorhandenen Metaobjekten oder Subtypen subklassifiziert. Als nächstes kann der Domänenexperte die geeigneten Beziehungen und Mächtigkeiten zwischen den verschiedenen Dienst- und Ressourcentypen erzeugen und dadurch ein neues Profit erzeugen. Dieses Profil kann dann in dem Managementsystem versioniert und gespeichert werden.
Damit das Managementsystem die Konfiguration, die Mächtigkeit, die Ressourcenbindung und die Beziehungsinformationen, wie in der Topologie spezifiziert, verwendet, erzeugt das Managementsystem intern eine programmatische Darstellung der Typen. Dies wird durch Erzeugen von Klassendefinitionen aus dem Profit erledigt. Wenn eine Topologie als eine Eingabe spezifiziert wird, kann das Managementsystem die entsprechenden Objekte erzeugen, von denen die genannten Informationen erhalten werden können. In einer Beispielimplementierung kann das Profil durch ein XML-Schema und die Topologie durch ein XML-Instanzdokument dargestellt werden. Dann können unter Verwendung einer JAXB-Grundstruktur die Java-Klassendarstellungen erzeugt werden, und zur Laufzeit kann die Topologie syntaktisch untersucht werden, um die entsprechenden Java-Objekte zu erzeugen.
Eine Plug-in-Grundstruktur wird bereitgestellt, um dem Managementsystem zu ermöglichen, Fähigkeiten dynamisch zu laden, um neue Dienste mit möglicherweise neuen Einsatzarchitekturen zu laden. Insbesondere erlaubt die Plug-in-Grundstruktur die Bündelung von Klassendarstellungen der Modellelemente in dem Profil und der entsprechenden Steuerungen und Adapter nach Bedarf in einer Bibliothek. Die derart erzeugte Bibliothek wird als ein Plug-in bezeichnet und wird unter Verwendung der Plug-in-Grundstruktur in dem Management-System gespeichert. Die Klassen und die Plug-ins werden versioniert, um dynamische Klassen-/Bibliothekladefehler zu verhindern. Die Plug-in-Grundstruktur pflegt eine Abbildung zwischen dem 2-Tupel [Profilnamen, Profilversion] und dem 2-Tupel [Plug-in-Name, Plug-in-Version]. Wenn ein Dienst eingesetzt werden soll, inspiziert der Dienstmanager die Topologie-Metadaten, wobei der zugehörige Profilname und die Versionsnummer gespeichert werden. Unter Verwendung dieser Informationen bestimmt der Dienstmanager das entsprechende Plug-in mit der richtigen Version, und lädt es unter Verwendung der verfügbaren Sprach- und Betriebssystemeinrichtungen dynamisch in seinen Adressraum. All dies wird erledigt, ohne das Managementsystem neu einsetzen oder ohne das laufende Managementsystem neu starten zu müssen. Ferner brauchen keine Subsystemmodifikationen vorgenommen zu werden, da der Rest des Systems auf der Ebene des Metamodells arbeitet. Somit wird unter Verwendung eines generischen Dienstmanagers, eines Metamodells und einer Plug-in-Grundstruktur die Erweiterbarkeit erreicht.
Als ein Beispiel können die Suchdomänenexperte (oder das „Suchteam”) anstatt ihr eigenes Managementsystem zum Managen der Suchinfrastruktur (die aus mehreren Diensten und Ressourcen besteht) zu entwickeln, die Grundstrukturfähigkeiten des erweiterbaren Modells (Überwachung, Konfigurationsmanagement, Ressourcenmanagement, etc.) zu ihrem Vorteil nutzen und nur die Teile hinzufügen, die für die Suchdomäne spezifisch sind. Insbesondere kann das Suchteam seine Profile unter Wiederverwendung der Definitionen des Servers, des Lastausgleichers, des Betriebssystems, etc. aufbauen und neue Elemente, zum Beispiel einen Abfrageknoten (eine Software-Ressource) einführen. Das Suchteam kann sein(e) Profil(e) entsprechend dem Metamodell machen. Für neue Typen kann das Suchteam die relevanten Steuerungen und Adapter schreiben. Das Suchteam kann ein geeignetes Plug-in erzeugen, das die Klassendefinitionen der Modellelemente in dem Profil und die relevanten Steuerungen und Adapter nach Bedarf paketieren. Das Plug-in kann dann in dem Managementsystem versioniert und gespeichert und dynamisch geladen werden, wenn der entsprechende Dienst eingesetzt werden soll.
1 ist ein Blockdiagramm 100 einer beispielhaften Infrastrukturumgebung, wie etwa eines Datenzentrums und ist als Beziehungen zwischen Diensten 170, Ressourcen 180 und einem Managementsystem umfassend gezeigt. Die Dienste 170 können zum Beispiel Suchdienste 175A, Marktplatzdienste 175B der Version 3, Managementdienste 175C Marktplatzdienste 175D der Version 4, Nachrichtenübermittlungsdienste 175E und jeden beliebigen anderen Dienst 175N, der Ressourcen nutzt und gemanagt werden kann, umfassen. Die Ressourcen 180 können zum Beispiel Rechnerressourcen 185A, Speicherressourcen 185B, Betriebssystemressourcen 185C, VLAN-Ressourcen 185D, Netzwerkressourcen 185E, IP-Adressressourcen 185F, Anwendungsressourcen 185G und jede andere Ressource 185N, welche die Dienste 170 nutzen können, umfassen. In einer Beispielausführungsform umfasst das Managementsystem 110 ein Betriebslebenszyklusmanagement-(OLCM-)Maschine 120, um unter anderem die Dienste 170 derart einzusetzen, dass sie Ressourcen verwenden, die aus den Ressourcen 180 ausgewählt sind. In einer Beispielausführungsform umfasst das Managementsystem 110 auch eine Dienstniveaumanagement-(SLM-)Maschine 150, um unter anderem die Dienste 170 und die Ressourcen 180 zu überwachen und wenigstens eine der Ressourcen 180 dynamisch zuzuweisen, so dass jeder der Dienste 170 ein spezifisches Dienstniveau aufrecht erhält, wie es durch Schlüsselleistungsindikatoren (KPIs), wie etwa die mittlere Antwortzeit oder den Durchsatz, definiert ist.
In einer Beispielausführungsform sind die Dienste 170 und die Ressourcen 180 mit dem Managementsystem 100 derart gekoppelt, dass das Managementsystem 110 die Dienste 170 und die Ressourcen 180 unter Verwendung der OLCM-Maschine 120 und der SLM-Maschine 150 managen kann. In einer Beispielausführungsform sind einer der Dienste 170 und eine oder mehrere der Ressourcen 180 gekoppelt, so dass eine oder mehrere der Ressourcen 180 einem der Dienste 170 zugewiesen sind oder einer der Dienste 170 derart eingesetzt wird, dass er eine oder mehrere der Ressourcen 180 verwendet.
2 ist ein Blockdiagramm des Managementsystems 102 gemäß verschiedener Ausführungsformen. Das Managementsystem 102 umfasst eine optionale Profilerzeugungseinrichtung 202, einen oder mehrere Dienstmanager 204, einen Mikrokern 210, einen Verteiler 212, einen Konfigurationsmanager 214, einen Bereitstellungsmanager 216, einen Ressourcenmanager 218 und einen Sperrmanager 220. Das Managementsystem 102 stellt Betriebszyklusdauermanagement, dynamische Ressourcenzuweisung und Dienstniveau-Managementfähigkeiten für die gemanagten Dienste und die Bestandteilressourcen bereit.
Nun Bezug nehmend auf 9 ist eine Beispielprofilerzeugungseinrichtung 202 abgebildet. Die Profilerzeugungseinrichtung empfängt eine oder mehrere Eingaben von einem Benutzer 902 (z. B. einem Domänenexperten) und greift auf die Modellablage 904 zu. Die Modellablage 904 speichert Modelle und Metamodelle von Diensten und Ressourcen. Der Benutzer 902 verwendet, soweit angemessen, Modellelemente aus der Modellablage 904 wieder für die Einsatzarchitektur des gerade erzeugten Diensttyps. Wenn neue Modellelemente erzeugt werden müssen, erzeugt der Benutzer 902 ihre Definitionen in dem Werkzeug. Ferner wird jedes neu erzeugte Modellelement von einem Metaobjekt oder von einem der Ressourcensubtypen, wie jeweils anwendbar, subklassifiziert. Abhängigkeiten und Eltern-Kind-Beziehungen zwischen den Modellelementen können nach Bedarf erzeugt werden. Wenn Abhängigkeiten zwischen dem Zielprofil und anderen Profilen bestehen (das heißt, der Zieldiensttyp hängt von einem anderen Diensttyp ab), können derartige Abhängigkeiten ebenfalls erzeugt werden. In einer Beispielausführungsform kann das Modell für die Einsatzarchitektur in UML erzeugt werden, und dann kann die UML-Darstellung in eine XML-Schemadarstellung transformiert werden. Anschließend kann das XML-Schema unter Verwendung von JAXB kompiliert werden, um die Java-Klassendarstellungen zu erzeugen. Wenn das Profil einmal erzeugt ist, dann wird es von dem Werkzeug exportiert und in dem Managementsystem versioniert und gespeichert.
Wenn eine neue Dienstinstanz erzeugt und eingesetzt wird, verwendet der Benutzer (zum Beispiel ein Betriebsarchitekt) einen Topologie-Editor, um die Topologie zu erzeugen. Die derart erzeugte Topologie ist eine logische Topologie. Eine logische Topologie gibt abstrakte Ressourcentypen (z. B. „Server”, „Lastausgleicher”, „Switch”, etc.) und, wie viele (z. B. Mächtigkeit) der Ressourcen verwendet werden sollen, an. Anschließend werden in einem Zweischrittverfahren – das den abstrakten Ressourcentyp mit einem konkreten Ressourcentyp (z. B. „NetScaler Lastausgleicher”, „Cisco 3550 Switch”, „LS20 Server”, etc.) verbindet und dann mit einer tatsächlichen Ressourceninstanz verbindet, Ressourcenbindungen für die abstrakte Ressource erzeugt. Dies ergibt die Erzeugung einer physikalischen Topologie. In manchen Fällen kann das Managementsystem 102 den konkreten Ressourcentyp bequemerweise mit einer tatsächlichen Ressourceninstanz verbinden, wenn der Dienst eingesetzt wird.
Der Dienstmanager 204 managt Dienst- und Bestandteilressourcen gemäß den Profilen innerhalb des Datenzentrums 104 oder der Cloud-Computing-Umgebung 106. Insbesondere stellt der Dienstmanager 204 das Dienstniveaumanagement (SLM) und das Betriebslebenszyklusmanagement (OLCM) für den Dienst und Bestandteilressourcen bereit. Basierend auf der physikalischen Topologie beginnt, managt und/oder beendet der Dienstmanager 204 die Ausführung durch die tatsächlichen Ressourcen in dem Datenzentrum 104 und/oder der Cloud-Computing-Umgebung 106, um den Dienst bereitzustellen.
Der Dienstmanager 204 umfasst eine Steuerung 206, die für einen Dienst- oder Ressourcentyp spezifisch ist. Er ist für den gesamten Lebenszyklus und das Dienstniveaumanagement aller Dienst-/Ressourceninstanzen unter ihrer Steuerung verantwortlich. Jeder Dienstmanager 204 als solches kann mehr als eine Steuerung 206 für Dienste umfassen, die mehr als einen Ressourcentyp verbrauchen.
Der Dienstmanager 204 umfasst ferner Adapter 208, die eine Umsetzung von Befehlen, die von der Steuerung 206 empfangen werden, auf arteigene Befehle, die von der/n konkreten Ressourceninstanz/en ausführbar sind. Die Steuerung 206 kann für jeden konkreten Ressourcentyp auf einen bestimmten Adapter 208 zugreifen. Ein einziger Adapter kann verwendet werden, um mit mehr als einer Instanz des gleichen konkreten Ressourcentyps zu kommunizieren.
Der Mikrokern 210 stellt das Lebenszyklus- und Dienstniveaumanagement für jedes Subsystem (z. B. den Dienstmanager 204, den Verteiler 212, den Konfigurationsmanager 214, den Bereitstellungsmanager 216, den Ressourcenmanager 218 und den Sperrmanager 220) bereit. Er stellt auch die Dienstregistrierungsfähigkeit und eine Dienstsperrfähigkeit bereit, um Dienstendpunkte der Subsysteme jeweils zu registrieren und zu sperren.
Der Verteiler 212 dient als ein Eintrittspunkt in das Managementsystem 102. Er empfängt alle Client-Anfragen, bestimmt durch Nachsehen in dem Mikrokern 210 das Subsystem, an das die Anfrage gerichtet ist, und schickt die Anfrage dann an das Zielsubsystem. Er stellt auch die Benutzerauthentifizierung und Berechtigung für das Managementsystem 102 bereit und erzeugt und unterhält Benutzersitzungen. Die Benutzerauthentifizierung kann an einen anderen Server, der von dem Managementsystem 102 verschieden ist, delegiert werden. Die Benutzerberechtigung kann basierend auf Rollen und Rechten eines bestimmten Benutzers intern durchgeführt werden. Nach der erfolgreichen Authentifizierung und Berechtigung wird eine Benutzersitzung erzeugt, und die Sitzung besteht, bis eine Zeitspanne abgelaufen ist, oder wenn sich der Benutzer abmeldet.
Der Konfigurationsmanager 214 kann vorhandene Profile und/oder ihre entsprechenden Topologien (z. B. logische oder physikalische), die in einer Konfigurationsablage gespeichert sind, speichern/auf sie zugreifen. In manchen Fällen kann die Konfigurationsablage unter Verwendung eines relationalen Datenbankmanagements (RDBMS) implementiert sein oder kann eine Konfigurationsmanagementdatenbank (CMDB) sein.
Der Konfigurationsmanager 214 kann auf der Ebene des Metamodells anstatt auf der Ebene der Modellelemente in den Profilen arbeiten, um die Unabhängigkeit von einzelnen Einsatzarchitekturen/Modellen zu bewahren. Der Konfigurationsmanager 214 kann die Topologie (die zum Beispiel als ein XML-Dokument gespeichert ist) basierend auf den entsprechenden Metaobjekten in relationale Datenbanktabellen umsetzen. Der Konfigurationsmanager 214 kann ferner Versionsvektoren für die Profile, Topologien (sowohl logische als auch physikalische) und einzelne Objekte innerhalb der Topologie erzeugen und pflegen, um dem Managementsystem 102 zu erlauben, einen Dienst auf eine frühere (oder spätere) Version seiner eingesetzten Topologie zurückzusetzen oder vorzuziehen. Der Konfigurationsmanager 214 kann zusätzlich die eingesetzten Konfigurationen überprüfen und sicherstellen, dass es keine Konfigurationsabweichung in den Ressourcen gibt. Wenn eine Konfigurationsabweichung erfasst wird, kann der relevante Dienstmanager 204 der betroffenen Ressource geeignete Korrekturmaßnahmen ergreifen.
Der Bereitstellungsmanager 216 ist verantwortlich für den Einsatz von Ressourcen einschließlich eines Betriebssystems, eines Anwendungsstapels (z. B. Java Virtual Machine (JVM), Servlet Container) und Anwendungscode für Rechenelemente (z. B. Server). Da eine Vielfalt spezialisierter Produkte und Werkzeuge verfügbar sein kann, stellt der Bereitstellungsmanager 216 eine Dienstschicht bereit, um diese Produkte und Werkzeuge unter Verwendung von Adaptern 218 zu abstrahieren. Beispiele für derartige Werkzeuge umfassen Altiris von Symantec für den OS-Einsatz und den TurboRoller von eBay für den Anwendungsstapel- und Codeeinsatz, sind aber nicht darauf beschränkt.
Der Ressourcenmanager 218 ist für das Reservieren und Zuweisen tatsächlicher konkreter Ressourcen verantwortlich. Reservierungen können gemietet werden, das heißt, die Reservierungen laufen bis zu einer bestimmten Zeit ab, wenn sie nicht von einem bestimmten Benutzer verwendet werden. Die Reservierungen können permanent (oder bis zu einer spezifizierten Maximaldauer) sein, indem eine Ressourcenzuweisung basierend auf einem Diensteinsatzbefehl, der von dem Benutzer (z. B. einem Systemverwalter) abgesetzt wird, durchgeführt wird. Der Ressourcenmanager 218 kann ferner Ressourcen dynamisch zuweisen und die Ressourcenzuweisung regelmäßig zwischen Diensten einstellen.
Der Sperrmanager 220 kann arbeiten, um einen gleichzeitigen Zugriff auf eine gemeinsam genutzte Ressource zu verhindern. In manchen Fällen werden Ressourcen von verschiedenen Diensten gemeinsam genutzt. Wenn mehrere Dienstmanger 204 gleichzeitig auf eine gemeinsam genutzte Ressource zugreifen, besteht eine Möglichkeit, dass eine Inkonsistenz in der Konfiguration der Ressource erzeugt wird, da nicht alle Ressourcen einen seriellen Zugriff erzwingen oder bereitstellen. Daher kann ein Außerband-Synchronisierungsmechanismus oder ein wechselseitiger Ausschlussmechanismus bereitgestellt werden. Um auf eine Ressource zuzugreifen, erhält der Servicemanager 204 zuerst eine Sperre von dem Sperrmanager 220 und gibt die Sperre, nachdem seine Sitzung mit der gemanagten Ressource vorbei ist, frei. Sperren sind gemietet, das heißt, sie laufen nach einer spezifizierten Dauer ab. Eine Miete kann nach Bedarf auf ein abstimmbares Maximum verlängert werden. Sperren sind auch über Neustarts hinweg ablaufinvariant und beständig.
3 ist ein Flussdiagramm eines Verfahrens 200 zum Erzeugen von Profilen und Topologien. Jeder Dienst (z. B. Nachrichtenübermittlung oder Handeln, etc.) hat seine entsprechende Einsatzarchitektur. Die Einsatzarchitektur wird, wie vorstehend beschrieben, in einem Schritt 302 bestimmt oder erzeugt.
Allerdings ist diese Architektur von einem Softwareprogramm nicht verwertbar. So wird ein Profil erzeugt, das von Software verwertbar ist. Das Profil wird in einem Schritt 304 unter Verwendung des Metamodells und der vorhandenen Modellbibliothek (die Bibliothek wird das Basismodul plus möglicherweise andere von Benutzern beigetragene Modellelemente, die wiederverwendet werden können, enthalten) erzeugt. Neue Modellelemente (üblicherweise domänenspezifisch) können bei Bedarf ebenfalls erzeugt werden. Das Profil wird dann in dem Managementsystem versioniert und gespeichert.
Wenn eine neue Dienstinstanz (z. B. eine neue Instanz des Nachrichtenübermittlungssystems) eingesetzt werden soll, wird in einem Schritt 306 ihre (Einsatz-)Topologie basierend auf den von dem Benutzer gelieferten Parametern (z. B. Anzahl von Servern, Konfigurationsparameter, etc.) oder nach einer Strategie erzeugt. Die so erzeugte Topologie ist eine logische Topologie. Der nächste Schritt ist, Ressourcenbindungen herzustellen, als deren Ergebnis eine physikalische Topologie erzeugt wird. Sowohl die logische als auch die physikalische Topologie werden in dem Managementsystem (genauer in dem Konfigurationsmanager) versioniert und gespeichert. Die Topologien können unter Verwendung eines Topologie-Editors visuell oder durch ein anderes Programm programmatisch erzeugt werden. Wenn einmal alle ausstehenden Freigaben erhalten wurden, wird die physikalische Topologie eingesetzt (genauer wird sie von dem Managementsystem verwendet, um die Dienstinstanz einzusetzen).
4 ist eine Hierarchie von Objekten 400, die verwendet wird, um Ressourcen innerhalb eines Metamodells gemäß verschiedenen Ausführungsformen zu klassifizieren. Die Hierarchie ist im Allgemeinen aus verschiedenen Ressourcentypen zusammengesetzt.
Die Ressource 402 kann in einen oder mehrere Ressourcentypen klassifiziert oder subtypisiert werden. Diese Ressourcen sind in dem vorliegenden Beispiel des Modells als eine zweite Schicht unter der Ressource 402 abgebildet und umfassen die Hardware-Ressource 404, die IP-Adresse 406, das virtuelle lokale Netzwerk (VLAN) 406 und die Software-Ressource 410. Das Metamodell kann die zusätzliche Klassifizierung von Ressourcen berücksichtigen.
Die Hardware-Ressource 404 und die Software-Ressource 410 können in dem Metmodell weiter in Subtypen klassifiziert werden. Diese Subtypen sind in 4 in der dritten und vierten Schicht abgebildet. Diese Subtypen in 4 sollen in dem Metamodell nicht einschränkend sein. Eine Hardware-Ressource 404 kann als ein Rechenelement 412 (z. B. ein Server, eine virtuelle Maschine, ein Rechner oder ein Handgerät) oder als ein Netzwerkelement 414 (z. B. ein Router, ein Lastausgleicher, Firewall, etc.) oder als ein Speicherelement 416 (z. B. eine Speichervorrichtung, eine optische Speichervorrichtung, ein Speichernetzwerk, ein über Netzwerk angeschlossener Speicher, etc.) subtypisiert werden. Eine Software-Ressource 410 kann als ein Betriebssystem 418 (z. B. Windows, Linux, etc.) oder als eine Anwendung 420 (z. B. Browser oder Textverarbeitung) subtypisiert werden. Die Anwendung 420 kann ferner als ein Anwendungs-Container 422 (z. B. Java Virtual Machine, Servlet Container) subtypisiert werden.
5 ist ein Blockdiagramm, um die Zusammensetzung von Hardware- und Software-Ressourcen in einem Metamodell gemäß einigen Ausführungsformen zu zeigen. Sowohl die Hardware-Ressource 404 als auch die Software-Ressource 410 haben Objekte, die ihre Konfiguration 502, Leistung 504 und Fähigkeit 506 beschreiben. Informationen in dem Konfigurationsobjekt 502 werden verwendet, um die Ressourceninstanzen zu konfigurieren. Ein Konfigurationsobjekt 502 kann selbst aus (nicht gezeigten) Kindkonfigurationsobjekten zusammengesetzt sein. Informationen, die erhalten werden, indem Leistungsmetriken der entsprechenden Ressourceninstanz überwacht werden, werden in dem Leistungsobjekt 504 gespeichert. In dem Fähigkeitsobjekt 506 gespeicherte Informationen beschreiben die Fähigkeiten (z. B. Anzahl von CPUs, Speichergröße, Durchsatz, Antwortzeit, etc.) des Ressourcentyps. Sie können während der automatisierten Ressourcenzuweisung verwendet werden, indem die von einem Ressourcentyp geforderten Fähigkeiten spezifiziert werden und diese mit den von einem tatsächlichen konkreten Typ bereitgestellten Fähigkeiten abgeglichen werden. Sowohl die Hardware-Ressource 404 als auch die Software-Ressource 410 können jeweils aus einem Hardwareteil 508 (z. B. Netzwerkschnittstellenkarte) und einem Softwareteil 510 (z. B. einer dynamisch verknüpften Bibliothek) aufgebaut sein. Jeder Teil kann auch ein zugehöriges (nicht gezeigtes) Fähigkeitsobjekt haben. Manche Teile können selbst aus Subteilen (Hardware-Subteil 512 und Software-Subteil 514) zusammengesetzt sein und so weiter. Ein Hardwareteil kann mit einem anderen entfernten Hardwareteil 516 verbunden sein, um auf eine entfernte Hardware-Ressource 518 zuzugreifen. Zum Beispiel kann ein Netzwerkanschluss (Hardwareteil 508) auf einem Server (Hardware-Ressource 404) durch ein Ethernetkabel mit einem anderen Netzwerkanschluss (entfernter Hardwareteil 516) auf einem Netzwerkswitch (entfernte Hardware-Ressource 518) verbunden sein.
6 ist ein Blockdiagramm einer Modellstruktur 600, die zu einem Gruppenobjekt 602 in einem Metamodell gemäß verschiedenen Ausführungsformen gehört. In manchen Fällen werden Ressourcen 604 (z. B. die Hardware-Ressource 404 und die Software-Ressource 412) und/oder Teile 606 gruppiert, um gruppierte Arbeitsschritte zu ermöglichen. Als Beispiele können Server (die Rechenelemente sind) in einen Pool gruppiert werden, und zusammenhängende IP-Adressen können in ein Subnetz gruppiert werden. Die Gruppierung kann über ein Gruppenobjekt 602 bereitgestellt werden. Jede Gruppe kann optional ein zugehöriges Konfigurationsobjekt 610 und ein Leistungsobjekt 608 haben.
7 ist ein Blockdiagramm einer Modellstruktur 700 für Anwendungsdaten in einem Metamodell gemäß verschiedenen Ausführungsformen. Die Anwendungsdaten 702 können in einem Dateisystem gespeichert werden, das zu einem Betriebssystem 418 gehört und von der Anwendung 420 betreut oder verwendet wird. Beispiele für Anwendungsdaten 702 umfassen Datenbanktabellen, und diejenigen für Inhalte umfassen Webseiten.
8 ist eine schematische Darstellung der Maschine, innerhalb derer ein Satz von Anweisungen, um die Maschine zu veranlassen, eine oder mehrere der hier diskutierten Methodiken durchzuführen, ausgeführt werden kann. In alternativen Ausführungsformen arbeitet die Maschine als eine unabhängige Vorrichtung oder kann mit anderen Maschinen verbunden (z. B. vernetzt) sein. In einem vernetzten Einsatz kann die Maschine innerhalb des Leistungsvermögens eines Servers oder einer Client-Maschine in einer Server-Client-Netzwerkumgebung oder als Peer-Maschine in einer Peer-to-Peer (oder verteilten) Netzwerkumgebung arbeiten. Die Maschine kann ein Serverrechner, ein Client-Rechner, ein Personalcomputer (PC), ein Settop-Rechner (STB), ein persönlicher digitaler Assistent (PDA), ein Zellulartelefon, eine Webanwendung, ein Netzwerkrouter, ein Switch oder eine Bridge, oder jede Maschine sein, die fähig ist, einen Satz von Anweisungen (sequentielle oder andere) auszuführen, die Aktionen spezifizieren, die von dieser Maschine ausgeführt werden sollen. Während ferner nur eine einzige Maschine dargestellt ist, soll der Begriff „Maschine” auch als jede Sammlung von Maschinen umfassend verstanden werden, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen ausführen, um eine oder mehrerer der hier diskutierten Methodiken durchzuführen.
Das Beispielrechnersystem 800 umfasst einen Prozessor 802 (z. B. eine zentrale Verarbeitungseinheit (CPU), eine Graphikverarbeitungseinheit (GPU) oder beides), einen Hauptspeicher 804 und einen statischen Speicher 806, die über einen Bus 808 miteinander kommunizieren. Das Rechnersystem 800 kann ferner eine Videoanzeigeeinheit 810 (z. B. eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT)) umfassen. Das Rechnersystem 800 umfasst auch eine alphanumerische Eingabevorrichtung 812 (z. B. eine Tastatur), eine Mauszeigersteuervorrichtung 814 (z. B. eine Maus), eine Plattenlaufwerkeinheit 816, eine Signalerzeugungsvorrichtung 818 (z. B. einen Lautsprecher) und eine Netzwerkschnittstellenvorrichtung 820.
Die Plattenlaufwerkeinheit 816 umfasst ein maschinenlesbares Medium 822, auf dem ein oder mehrere Sätze von Anweisungen (z. B. Software 824) gespeichert sind, welche eine oder mehrere der hier beschriebenen Methodiken oder Funktionen verkörpern. Die Software 824 kann während ihrer Ausführung durch das Computersystem 800 auch vollständig oder zumindest teilweise in dem Hauptspeicher 804 und/oder in dem Prozessor 804 residieren, wobei der Hauptspeicher 804 und der Prozessor 802 ebenfalls maschinenlesbare Medien bilden.
Die Software 824 kann ferner über die Schnittstellenvorrichtung 820 über ein Netzwerk 826 gesendet oder empfangen werden.
Während das maschinenlesbare Medium 822 in einer Beispielausführungsform als ein einzelnes Medium gezeigt ist, sollte der Begriff „maschinenlesbares Medium” derart verstanden werden, dass er ein einzelnes Medium oder mehrere Medien (z. B. eine zentralisierte oder verteilte Datenbank und/oder zugehörige Cachespeicher und Server), die den einen oder die mehreren Sätze von Anweisungen speichern, umfasst. Der Begriff „maschinenlesbares Medium” soll auch derart verstanden werden, dass er jedes Medium umfasst, das fähig ist, einen Satz von Anweisungen für die Ausführung durch die Maschine, der bewirkt, dass die Maschine eine oder mehrere der Methodiken der vorliegenden Erfindung ausführt, zu speichern, zu codieren oder zu befördern. Der Begriff „maschinenlesbares Medium” soll folglich derart verstanden werden, dass er Festkörperspeicher, optische und magnetische Medien und Trägerwellensignale umfasst, aber nicht darauf beschränkt ist.
Somit wurden ein Verfahren und ein System zum Managen einer Vielzahl von Domänenarchitekturen unter Verwendung einer Modellgrundstruktur beschrieben. Obwohl die vorliegende Erfindung unter Bezug auf spezifische Beispielausführungsformen beschrieben wurde, wird offensichtlich, dass vielfältige Modifikationen und Änderungen an diesen Ausführungsformen vorgenommen werden können, ohne von dem weiteren Geist und Bereich der Erfindung abzuweichen. Folglich sind die Beschreibung und die Zeichnungen vielmehr in einem veranschaulichenden als einem einschränkenden Sinn zu betrachten.
Manche hier beschriebenen Ausführungsformen werden verwendet, um ein oder mehrere technische Probleme zu lösen. Zum Beispiel können manche Ausführungsformen eine effizientere Ressourcenverwaltung erleichtern und den Bedarf, ein System neu einzusetzen, verringern, wenn eine Architekturdomäne hinzugefügt oder modifiziert wird.
Die Zusammenfassung der Offenbarung ist bereitgestellt, um CFR 37 §1.72(b) zu entsprechen, worin eine Zusammenfassung gefordert wird, die dem Leser erlaubt, das Wesen der technischen Offenbarung schnell zu bestimmen. Sie wird mit dem Verständnis eingereicht, dass sie nicht verwendet wird, um den Bereich der Patentansprüche auszulegen oder zu begrenzen. Außerdem ist in der vorangehenden detaillierten Beschreibung zu erkennen, dass zu dem Zweck, die Offenbarung zu rationalisieren, verschiedene Merkmale in einer einzigen Ausführungsform zusammen gruppiert sind. Das Verfahren der Offenbarung soll nicht als eine Absicht widerspiegelnd ausgelegt werden, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern als in jedem Patentanspruch ausdrücklich angegeben. Vielmehr liegt der erfinderische Gegenstand, wie die folgenden Patentansprüche wiedergeben, in weniger als allen Merkmalen einer einzigen offenbarten Ausführungsform. Folglich sind die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch selbständig als eine einzelne Ausführungsform steht.

Claims

Verfahren, das umfasst: Definieren eines Profils, das einer Einsatzarchitektur entspricht, wobei jedes Profil gemäß einem Metamodell definiert wird, wobei das Metamodell umfasst: ein Dienstobjekt, das einen Dienst darstellt, der über ein Netzwerk zugänglich ist, und Ressourcenobjekte, die von dem Dienst verbrauchte Ressourcen darstellen, und Zwischenbeziehungen zwischen dem Dienst und den Ressourcen; und Zwischenbeziehungen zwischen den Ressourcen, und für jedes Profil unter Verwendung eines oder mehrerer Prozessoren Erzeugen einer Topologie basierend auf dem Profil, wobei die Topologie die Ressourcen zum Durchführen einer Aufgabe umfasst.
Verfahren nach Anspruch 1, wobei das Metamodell ferner Konfigurationsobjekte umfasst, die jeweils zu einem Ressourcenobjekt der Ressourcenobjekte gehören, wobei die Konfigurationsobjekte eine zu dem Ressourcenobjekt gehörende Konfiguration angeben.
Verfahren nach Anspruch 1, wobei das Metamodell ferner Leistungsobjekte umfasst, die jeweils zu dem Ressourcenobjekt gehören, wobei die Leistungsobjekte eine Leistungsmetrik des Ressourcenobjekts angeben.
Verfahren nach Anspruch 1, wobei das Metamodell ferner Fähigkeitsobjekte umfasst, die jeweils zu dem Ressourcenobjekt gehören, wobei die Fähigkeitsobjekte eine Fähigkeitsmetrik des Ressourcenobjekts angeben.
Verfahren nach Anspruch 1, wobei wenigstens ein Teil der Profile gemäß einem Basismodell für die Architekturdomäne und eine weitere Architekturdomäne definiert ist.
Verfahren nach Anspruch 1, wobei das Dienstobjekt mit einem weiteren Konfigurationsobjekt, einem weiteren Leistungsobjekt und einem weiteren Fähigkeitsobjekt verknüpft wird.
Verfahren nach Anspruch 1, wobei das Ressourcenobjekt eine Hardware-Ressource oder eine Software-Ressource oder eine Internetprotokoll-(IP-)Adresse oder ein virtuelles lokales Netzwerk (VLAN) ist und die Hardware- und Software-Ressource eine Vielzahl von Teilobjekten umfasst.
Verfahren nach Anspruch 1, wobei das Metamodell ein Gruppenobjekt umfasst, wobei das Gruppenobjekt ein oder mehrere der Ressourcenobjekte oder eines oder mehrere der Teilobjekte bestimmt, wobei das Gruppenobjekt ein zugehöriges Leistungsobjekt und ein zugehöriges Konfigurationsobjekt hat.
Verfahren nach Anspruch 1, das ferner das Management des in der Topologie spezifizierten Dienstes umfasst, durch: Managen einer Ressource der Ressourcen innerhalb der Topologie, wobei die Ressource dem Ressourcenobjekt entspricht, und Managen einer physikalischen Komponente, die der Ressource in der Topologie entspricht, basierend auf dem Profil der Ressource in der Topologie.
System, das umfasst: ein Managementsystem, das durch einen oder mehrere Prozessoren implementiert ist, um auf ein oder mehrere Dienstprofile in einer Einsatzarchitektur zuzugreifen und um basierend auf einem Profil eine Topologie zu erzeugen, wobei die Profile gemäß einem Metamodell definiert sind, wobei das Metamodell umfasst: ein Dienstobjekt, das einen Dienst der Dienste darstellt, und Ressourcenobjekte, die von wenigstens einem Teil der Dienste verbrauchte Ressourcen darstellen, und Zwischenbeziehungen zwischen dem Dienst und den Ressourcen; und Zwischenbeziehungen zwischen den Ressourcen; und einen Dienstmanager, um den Betriebslebenszyklus und die Dienstniveaus des Dienstes zu managen, wobei der Dienst der Einsatzarchitektur entspricht, für die der Dienstmanager konfiguriert ist, um dynamisch zu laden: eine Steuerung, um eine Ressource der Ressourcen innerhalb der Topologie zu managen, wobei die Ressource dem Ressourcenobjekt entspricht, und einen Adapter, um Befehle von der Steuerung an eine Instanz der gemanagten Ressource zu übersetzen.
System nach Anspruch 10, wobei das Metamodell ferner Konfigurationsobjekte umfasst, die jeweils zu einem Ressourcenobjekt der Ressourcenobjekte gehören, wobei die Konfigurationsobjekte eine zu dem Ressourcenobjekt gehörende Konfiguration angeben.
System nach Anspruch 10, wobei das Metamodell ferner Leistungsobjekte umfasst, die jeweils zu dem Ressourcenobjekt gehören, wobei die Leistungsobjekte eine Leistungsmetrik des Ressourcenobjekts angeben.
System nach Anspruch 10, wobei das Metamodell ferner Fähigkeitsobjekte umfasst, die jeweils zu dem Ressourcenobjekt gehören, wobei die Fähigkeitsobjekte eine Fähigkeitsmetrik des Ressourcenobjekts angeben.
System nach Anspruch 10, das ferner einen Konfigurationsmanager umfasst, um das eine oder die mehreren Profile und die Topologie in eine Speichervorrichtung zu speichern und eine Konfiguration einer Ressource in der Topologie zu verifizieren.
System nach Anspruch 10, das ferner einen Ressourcenmanager umfasst, um die von einem Dienst der Dienste verbrauchten Ressourcen zuzuweisen.
System nach Anspruch 10, das ferner einen Mikrokern umfasst, um den Dienstmanager zu erzeugen und zu steuern.
System nach Anspruch 10, wobei das Profil gemäß einem Basismodell definiert ist, wobei das Basismodell die Elemente, die über Einsatzarchitekturen hinweg gemeinsam sind, und ferner eine Sammlung der Elemente, die nur für eine gegebene Einsatzarchitektur spezifisch sind, umfasst.
System nach Anspruch 17, wobei das Metamodell ein Gruppenobjekt umfasst, wobei das Gruppenobjekt ein oder mehrere der Ressourcenobjekte umfasst, wobei das Gruppenobjekt ein zugehöriges Leistungsobjekt und ein zugehöriges Konfigurationsobjekt hat.
System nach Anspruch 10, wobei die Ressourceninstanz in einem Datenzentrum ist.
System nach Anspruch 10, wobei die physikalische Komponente in einer Cloud-Computing-Umgebung ist.
System nach Anspruch 10, wobei die Ressourcen eine Hardware-Ressource und/oder eine Software-Ressource und/oder eine Internetprotokoll-(IP-)Adresse und/oder ein virtuelles lokales Netzwerk (VLAN) umfassen.
System nach Anspruch 21, wobei die Hardware-Ressourcen und die Software-Ressourcen ferner Teile umfassen.
System nach Anspruch 22, wobei die der Hardware-Ressource entsprechenden Ressourcen Rechenelemente, Netzwerkelemente und Speicherelemente umfassen.
System nach Anspruch 22, wobei die der Software-Ressource entsprechenden Ressourcen Betriebssysteme und Anwendungen umfassen.
Computerlesbares Speichermedium mit darauf ausgeführten Anweisungen, wobei die Anweisungen durch einen oder mehrere Prozessoren ausführbar sind, um ein Verfahren zum Managen von Diensten über eine Vielzahl von Einsatzarchitekturen hinweg durchzuführen, wobei das Verfahren umfasst: Definieren eines Profils für jede Einsatzarchitektur, wobei das Profil gemäß einem Metamodell definiert ist, wobei das Metamodell umfasst ein Dienstobjekt, das einen Dienst des einen oder der mehreren Dienste darstellt, und Ressourcenobjekte, die von dem Dienst verbrauchte Ressourcen darstellen, und Zwischenbeziehungen zwischen dem Dienst und den Ressourcen; und Zwischenbeziehungen zwischen den Ressourcen; und für jedes Profil Erzeugen einer Topologie basierend auf dem Profil unter Verwendung eines oder mehrerer Prozessoren, wobei die Topologie die Ressourcen umfasst, um eine Aufgabe auszuführen.