DE112021003276T5

DE112021003276T5 - Ressourcenverwaltung einer softwareanwendung mit mehreren softwarekomponenten

Info

Publication number: DE112021003276T5
Application number: DE112021003276.3T
Authority: DE
Inventors: Gabriele De Capoa; Massimo Villani
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-07-31
Filing date: 2021-07-28
Publication date: 2023-06-29
Also published as: CN116194895A; GB2612548A; JP2023535607A; GB202302590D0; US20220035668A1; WO2022024006A1; US11500686B2

Abstract

Eine Lösung für eine Ressourcenverwaltung einer Softwareanwendung wird vorgeschlagen, die eine Mehrzahl von Softwarekomponenten umfasst, welche miteinander interagieren. Ein entsprechendes Verfahren umfasst ein Überwachen von derzeitigen Zuständen der Softwarekomponenten und ein Schätzen eines zukünftigen Verbrauchs von einer oder mehreren Datenverarbeitungsressourcen durch jede Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten; eine Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten wird dann entsprechend gesteuert. Ein Computerprogramm und ein Computerprogrammprodukt zum Durchführen des Verfahrens werden ebenfalls vorgeschlagen. Überdies wird ein System zum Ausführen des Verfahrens vorgeschlagen.

Description

HINTERGRUND
Die vorliegende Offenbarung betrifft das Gebiet der Informationstechnologie. Genauer gesagt, diese Offenbarung betrifft eine Ressourcenverwaltung von Softwareanwendungen.
Softwareanwendungen erfordern mehrere Datenverarbeitungsressourcen für ihre Ausführung (wie beispielsweise Verarbeitungs-, Speicher- und Netzwerkressourcen). Die (Ressourcen-)Verwaltung dieser Datenverarbeitungsressourcen spielt eine Schlüsselrolle im Hinblick auf den Betrieb der Softwareanwendungen; tatsächlich wirkt sich die Ressourcenverwaltung in hohem Maße auf die Leistung, die Verfügbarkeit und die Kosten der Softwareanwendungen aus.
KURZDARSTELLUNG
Eine vereinfachte Kurzdarstellung der vorliegenden Offenbarung wird hierin präsentiert, um ein grundlegendes Verständnis der Offenbarung zu vermitteln; der alleinige Zweck dieser Kurzdarstellung besteht jedoch darin, einige Konzepte der Offenbarung in vereinfachter Form als Einleitung zu ihrer folgenden ausführlicheren Beschreibung vorzustellen, und sie ist weder als Identifizierung ihrer Schlüsselelemente noch als Skizzierung ihres Umfangs zu interpretieren.
Allgemein ausgedrückt beruht die vorliegende Offenbarung auf dem Gedanken, den Ressourcenverbrauch einer jeden Softwarekomponente anhand von Zuständen der Softwarekomponenten der Softwareanwendung zu schätzen.
Insbesondere stellt eine Ausführungsform ein Verfahren zur Ressourcenverwaltung einer Softwareanwendung bereit, die eine Mehrzahl von Softwarekomponenten umfasst, welche miteinander interagieren. Ein entsprechendes Verfahren umfasst ein Überwachen von derzeitigen Zuständen der Softwarekomponenten und ein Schätzen eines zukünftigen Verbrauchs von einer oder mehreren Datenverarbeitungsressourcen durch jede Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten; eine Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten wird dann entsprechend gesteuert.
Ein weiterer Aspekt stellt ein Computerprogramm zur Ausführung des Verfahrens bereit.
Ein weiterer Aspekt stellt ein entsprechendes Computerprogrammprodukt bereit.
Ein weiterer Aspekt stellt ein entsprechendes System bereit.
Genauer gesagt, ein oder mehrere Aspekte der vorliegenden Offenbarung sind in den unabhängigen Ansprüchen und vorteilhafte Merkmale der Offenbarung sind in den abhängigen Ansprüchen mit dem Wortlaut aller Ansprüche dargelegt, der durch Bezugnahme wörtlich hierin übernommen ist (wobei jedes vorteilhafte Merkmal unter Bezugnahme auf einen bestimmten Aspekt bereitgestellt wird, der mutatis mutandis für jeden anderen Aspekt gilt).
Figurenliste
Diese und weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung gehen aus der folgenden ausführlichen Beschreibung von veranschaulichenden Ausführungsformen der Erfindung hervor, die in Verbindung mit den beiliegenden Zeichnungen gelesen werden soll. Die verschiedenen Merkmale der Zeichnungen sind nicht maßstabsgetreu, da die Veranschaulichungen dem Fachmann das Verständnis der Erfindung in Verbindung mit der ausführlichen Beschreibung durch Übersichtlichkeit erleichtern sollen. In den Zeichnungen:

Die 1A bis 1D stellen die allgemeinen Grundgedanken der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung dar;
2 zeigt eine schematische Blockdarstellung einer Datenverarbeitungsinfrastruktur, in der die Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung in die Praxis umgesetzt werden kann;
3 zeigt die Hauptsoftwarekomponenten, die verwendet werden können, um die Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung auszuführen;
die 4A und 4B zeigen ein Aktivitätsdiagramm, das den Ablauf von Aktivitäten in Bezug auf eine Ausführung der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung beschreibt; und
5 stellt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung dar.

AUSFÜHRLICHE BESCHREIBUNG
Softwareanwendungen erfordern mehrere Datenverarbeitungsressourcen für ihre Ausführung, wie beispielsweise Verarbeitungs-, Speicher- und Netzwerkressourcen. Die Ressourcenverwaltung dieser Datenverarbeitungsressourcen spielt eine Schlüsselrolle im Hinblick auf den Betrieb der Softwareanwendungen; tatsächlich wirkt sich die Ressourcenverwaltung in hohem Maße auf die Leistung, die Verfügbarkeit und die Kosten der Softwareanwendungen aus.
Die Datenverarbeitungsressourcen können den Softwareanwendungen gemäß deren Standardarbeitslasten statisch zugeordnet werden, zum Beispiel abgeleitet aus Langzeitinformationen. Dieser Ansatz ist jedoch in Datenverarbeitungsumgebungen, in denen sich die Arbeitslasten im Laufe der Zeit stark ändern können (in einer Weise, die nicht von vornherein bekannt ist), vollkommen unwirksam.
Alternativ können die Datenverarbeitungsressourcen den Softwareanwendungen gemäß deren Kontingentbedarf dynamisch zugeordnet werden. Dies ist für virtualisierte Datenverarbeitungsumgebungen typisch, in denen die Datenverarbeitungsressourcen von einem virtuellen Typ sind, d.h. Software-Emulation von physischen Datenverarbeitungsressourcen, so dass sie weitgehend in Echtzeit (verhältnismäßig schnell) zugeordnet werden können.
Hierzu können Überwachungstechniken verwendet werden, um die Leistung der Softwareanwendungen zu überwachen, zum Beispiel, indem entsprechende Leistungsmetriken im Laufe der Zeit gemessen werden. Auf diese Weise kann, sobald die überwachte Leistung einer beliebigen Softwareanwendung anzeigt, dass diese in einen kritischen Zustand eingetreten ist, die Zuordnung der Datenverarbeitungsressourcen zu der Softwareanwendung entsprechend aktualisiert werden, um ihn zu beseitigen. Die Zuordnung der Datenverarbeitungsressourcen kann jedoch erst aktualisiert werden, nachdem die kritischen Zustände erkannt worden sind; überdies braucht jede Aktualisierung eine bestimmte Zeit, bis sie wirksam wird. All das Vorgenannte kann Verzögerungen beim Beheben der kritischen Zustände der Softwareanwendungen verursachen.
Alternativ können Vorhersagetechniken verwendet werden, um den Ressourcenverbrauch der Datenverarbeitungsressourcen durch die Softwareanwendungen vorherzusagen. Auf diese Weise kann, sobald der vorhergesagte Ressourcenverbrauch einer beliebigen Softwareanwendung anzeigt, dass sie in nächster Zeit voraussichtlich in einen kritischen Zustand eintreten wird, die Zuordnung der Datenverarbeitungsressourcen zu der Softwareanwendung entsprechend aktualisiert werden, um ihn zu verhindern. Die Vorhersagetechniken beruhen auf Vorhersagemodellen der Softwareanwendungen, die zum Beispiel von deren derzeitigen internen Zuständen abhängig sind; die Vorhersagemodelle können im Laufe der Zeit auch gemäß einer Arbeitslast der Softwareanwendungen geändert werden (um sich daran anzupassen).
Viele Softwareanwendungen werden in mehrere Softwarekomponenten aufgeteilt, die untereinander interagieren. Ein typisches Beispiel findet sich in Cloud-(Computing-)Umgebungen. In diesem Fall führen die Softwarekomponenten einer jeden Softwareanwendung im Allgemeinen entsprechende Services und insbesondere Mikroservices aus; jeder Service kann die anderen Services der Softwareanwendung (zusätzlich zu externen Services) aufrufen, um die benötigte Funktionalität bereitzustellen. Diese Architektur stellt Modularität bereit, erhöht die Skalierbarkeit, ermöglicht eine Integration und fördert die Entwicklung im Verbund. Überdies kann jede Softwareanwendung mit einer oder mehreren Instanzen ihrer Softwarekomponenten an verschiedenen Orten eingesetzt werden; dies ermöglicht es, die Arbeitslast der Softwareanwendung zu verteilen, und stellt Redundanz bereit, um die Zuverlässigkeit zu erhöhen.
In diesem Fall sind die vorstehend beschriebenen Vorhersagetechniken jedoch ziemlich unwirksam. Wenn die Ressourcenverwaltung auf der Ebene einer jeden Softwareanwendung als Ganzes angewandt wird, ist es tatsächlich schwierig, die benötigten Datenverarbeitungsressourcen über deren gesamte Softwarekomponenten hinweg zuzuordnen, insbesondere, wenn sie an verschiedenen Orten verteilt sind. Wenn die Ressourcenverwaltung auf der Ebene einer jeden Softwarekomponente einzeln angewandt wird, ist es hingegen schwierig, den Ressourcenverbrauch der Datenverarbeitungskomponente aufgrund von deren Korrelation mit den anderen Softwarekomponenten derselben Softwareanwendung vorherzusagen.
Folglich werden die Datenverarbeitungsressourcen den Softwarekomponenten möglicherweise nicht korrekt zugeordnet. Insbesondere werden gegebenenfalls mehr Datenverarbeitungsressourcen als nötig bereitgestellt; in diesem Fall bleiben die überzähligen Datenverarbeitungsressourcen die meiste Zeit ungenutzt (mit einer entsprechenden Verschwendung der Ressourcen, was auch mit unnötigen Kosten in Cloud-Umgebungen verbunden sein kann, wenn die Datenverarbeitungsressourcen nutzungsorientiert in Rechnung gestellt werden). Umgekehrt, was gefährlicher ist, werden gegebenenfalls weniger Datenverarbeitungsressourcen als nötig bereitgestellt; in diesem Fall kann der Mangel an Datenverarbeitungsressourcen eine Leistungseinbuße der Softwareanwendung bis hin zu deren völligem Absturz verursachen (was in vielen Situationen in der Praxis möglicherweise nicht hinnehmbar ist, so zum Beispiel, wenn ein entsprechendes Service Level Agreement einzuhalten ist).
Unter Bezugnahme insbesondere auf die 1A bis 1D sind die allgemeinen Grundgedanken der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung gezeigt.
Unter Bezugnahme auf 1A ist eine Softwareanwendung gezeigt; die Softwareanwendung ist zum Beispiel vom Typ „Cloud“ (als ein Service in einer Cloudumgebung durch einen entsprechenden Cloud-Provider bereitgestellt). Die Softwareanwendung umfasst eine Mehrzahl von Softwarekomponenten, die auf einem oder mehreren Datenverarbeitungssystemen ausgeführt werden. Zum Beispiel führen die Softwarekomponenten entsprechende Services aus; jeder Service stellt, unabhängig von seiner Ausführung, eine eigenständige Funktionalität bereit, die durch eine klar strukturierte Schnittstelle angefordert werden kann. Insbesondere kann es sich bei den Services um Mikroservices handeln; jeder Mikroservice ist verhältnismäßig klein, differenziert (um eine einzelne Funktion durchzuführen), unabhängig einsetzbar und durch ein einfaches Protokoll (wie beispielsweise HTTP) zugänglich.
Bei der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung wird ein derzeitiger Zustand einer jeden Softwarekomponente überwacht (zum Beispiel, indem eine oder mehrere Arbeitslastmetriken von ihr überwacht werden).
Unter Bezugnahme auf 1B werden für jede Softwarekomponente entsprechende zukünftige Verbräuche durch die Softwarekomponente von einer oder mehreren Datenverarbeitungsressourcen der entsprechenden Datenverarbeitungssysteme geschätzt (bei einem nächsten Mal, wie beispielsweise in ein paar Minuten); die zukünftigen Verbräuche einer jeden Softwarekomponente werden anhand der derzeitigen Zustände von (allen) Softwarekomponenten gemäß einem oder mehreren Schätzmodellen geschätzt. Zum Beispiel wird in einer Ausführungsform ein zukünftiger Zustand einer jeden Softwarekomponente (beim gleichen nächsten Mal wie vorstehend) anhand ihres derzeitigen Zustands gemäß einem Anwendungsmodell der gesamten Softwareanwendung geschätzt; das Anwendungsmodell beruht auf Korrelationen unter den Softwarekomponenten in der Softwareanwendung (wie durch ihre gegenseitigen Aufrufe definiert).
Unter Bezugnahme auf 1C werden die zukünftigen Verbräuche einer jeden Softwarekomponente dann anhand ihres zukünftigen Zustands gemäß einem Komponentenmodell der Softwarekomponente geschätzt.
Unter Bezugnahme auf 1D wird eine Zuordnung der entsprechenden Datenverarbeitungsressourcen zu den Softwarekomponenten gemäß ihren zukünftigen Verbräuchen gesteuert (indem sie zum Beispiel erhöht wird, wenn ein zukünftiger Verbrauch zu hoch ist, und verringert wird, wenn ein zukünftiger Verbrauch zu gering ist).
Die vorstehend beschriebene Lösung verbessert die Zuordnung der Datenverarbeitungsressourcen zu der Softwareanwendung über ihre gesamten Softwarekomponenten hinweg erheblich (selbst wenn sie an verschiedenen Orten verteilt sind). Insbesondere wird die Zuordnung der Softwarekomponenten jetzt einzeln auf die Softwarekomponenten (anstatt monolithisch auf die Softwareanwendung) angewandt; gleichzeitig wird die Zuordnung der Softwarekomponenten unter Berücksichtigung der Korrelationen unter den Softwarekomponenten in der Softwareanwendung angewandt (anstatt auf jede Softwarekomponente allein).
Auf diese Weise wird das Risiko, jeder Softwarekomponente mehr Datenverarbeitungsressourcen als nötig und vor allem weniger Datenverarbeitungsressourcen als nötig bereitzustellen, erheblich verringert; dadurch können folglich Datenverarbeitungsressourcen (und mögliche damit verbundene Kosten) gespart und Arbeitslastspitzen in den meisten Situationen in der Praxis aufgefangen werden (mit einer vorteilhaften Wirkung auf ein Serviceziel der Softwareanwendung).
Folglich wird ein hohes Maß an Elastizität der Softwareanwendung erreicht, und zwar mit ihren Softwarekomponenten, die sich an ihre veränderliche Arbeitslast automatisch selbst anpassen. Insbesondere wird die Zuordnung der Datenverarbeitungsressourcen proaktiv durchgeführt, so dass es möglich ist, im Voraus einzugreifen (im Allgemeinen vor dem Eintreten eines kritischen Zustands).
Dies ist besonders sinnvoll in dynamischen Umgebungen, wie sie für Cloud-Umgebungen typisch sind, in denen sich die Arbeitslast der Softwareanwendung im Laufe der Zeit auf unvorhersehbare Weise ändern kann.
Unter Bezugnahme auf 2 ist eine schematische Blockdarstellung einer Datenverarbeitungsinfrastruktur 200 gezeigt, in der die Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung in die Praxis umgesetzt werden kann.
Die Datenverarbeitungsinfrastruktur 200 umfasst einen oder mehrere Cloud-Provider 205 (in der Figur ist nur einer gezeigt). Jeder Cloud-Provider 205 ist eine Entität, die einen Pool von Datenverarbeitungsressourcen als Cloud-Services (d.h., gemeinsam genutzte Datenverarbeitungsressourcen, die sehr schnell bereitgestellt, konfiguriert und freigegeben werden können) bereitstellt; die Datenverarbeitungsressourcen (im Allgemeinen vom virtuellen Typ, d.h. Software-Emulationen von physischen Datenverarbeitungsressourcen) werden Nutzern des Cloud-Providers 205 auf Anforderung bereitgestellt, so dass jeder Nutzer die alleinige Kontrolle über die Datenverarbeitungsressourcen hat (die dann genau so verwendet werden können, als wären sie dem Nutzer zugeordnet). Die Datenverarbeitungsressourcen können gemäß mehreren Servicemodellen bereitgestellt werden, insbesondere Infrastructure as a Service (laaS), Platform as a Service (PaaS), Software As a Service (SaaS) und Network as a Service (NaaS). Überdies können die Datenverarbeitungsressourcen gemäß verschiedenen Einsatzmodellen bereitgestellt werden, insbesondere Public Cloud (d.h. für die breite Öffentlichkeit), Private Cloud (d.h. für eine einzelne Organisation), Community Cloud (d.h. für mehrere Organisationen) oder Hybrid Cloud (beruhend auf einer Kombination aus verschiedenen Einsatzmodellen). Insbesondere, soweit für die vorliegende Offenbarung relevant, können die Datenverarbeitungsressourcen den Softwarekomponenten (die entsprechende Mikroservices ausführen) einer jeden Softwareanwendung der Nutzer zugeordnet werden.
Die Nutzer verbinden sich mit dem Cloud-Provider 205 mit entsprechenden Client-Datenverarbeitungsmaschinen, oder einfach Clients, 210 (zum Beispiel vom Typ Thin) über ein (Übertragungs-)Netzwerk 215; zum Beispiel kann es sich bei dem Netzwerk 215 um das Internet für eine Public/Community Cloud oder ein LAN für eine Private Cloud handeln. Hierzu stellt der Cloud-Provider 205 eine Front-End-Komponente zur Verfügung, um darauf zuzugreifen (zum Beispiel über einen Webbrowser der Clients 210); die Front-End-Komponente ist über eine Schnittstelle mit einer Back-End-Komponente verbunden, welche die Mikroservices tatsächlich ausführt (wobei von außen nicht auf diese Backend-Komponente zugegriffen werden kann, so dass die Nutzer keine Kenntnis von ihrem Standort und ihrer Konfiguration haben).
Der Cloud-Provider 205 wird in einer oder mehreren Serverfarmen 220 ausgeführt. Jede Serverfarm 220 umfasst mehrere Server-Datenverarbeitungsmaschinen, oder einfach Server, 225 (zum Beispiel vom Typ Rack oder Blade) und mehrere Speicherplatten 230 (zum Beispiel vom Typ RAID), die Massenspeicher von diesen implementieren; jeder Server 225 wiederum umfasst (in der Figur nicht gezeigt) einen oder mehrere Mikroprozessoren (µP), die eine logische Funktion des Servers 225 bereitstellen, einen nicht flüchtigen Speicher (ROM), der Basiscode für ein Bootstrapping des Servers 225 speichert, und einen flüchtigen Speicher (RAM), der als Arbeitsspeicher durch die Mikroprozessoren verwendet wird. Die Serverfarm 220 umfasst auch eine Konsole 235, um sie zu steuern (zum Beispiel einen Personal Computer, der auch mit einem Laufwerk zum Lesen/Beschreiben von austauschbaren Speichereinheiten 240, wie beispielsweise optischen Platten wie DVDs, ausgestattet ist). Ein Switch-/Router-Subsystem 245 verwaltet jedwede Übertragungen zwischen den Servern 225, den Platten 230 und der Konsole 235 sowie mit dem Netzwerk 215; hierzu sind die Server 225, die Platten 230 und die Konsole 235 mit dem Switch/Router-Subsystem 245 (dank entsprechender Netzadapter) über ein Verkabelungssubsystem 250 verbunden.
Unter Bezugnahme auf 3 sind die Hauptsoftwarekomponenten gezeigt, die verwendet werden können, um die Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung auszuführen.
Im Einzelnen sind alle Softwarekomponenten (Programme und Daten) als Ganzes mit der Bezugszahl 300 bezeichnet. Die Softwarekomponenten 300 sind üblicherweise in den Massenspeichern gespeichert und werden (zumindest teilweise) in die Arbeitsspeicher der Server geladen, wenn die Programme ausgeführt werden. Die Programme werden in den Massenspeichern installiert, indem sie zum Beispiel aus austauschbaren Speichereinheiten gelesen und/oder aus dem Netzwerk heruntergeladen werden. In diesem Zusammenhang kann jedes Programm ein Modul, ein Segment oder ein Teil von Code sein, das bzw. der eine oder mehrere ausführbare Anweisungen zur Ausführung der angegebenen logischen Funktion umfasst.
Die Softwareanwendungen verfügen über ihre Softwarekomponenten, bezeichnet mit SCi für die i-te Softwarekomponente, die auf einem oder mehreren (Ausführungs-)Servern eingesetzt werden, welche mit der Bezugszahl 225e unterschieden werden. Jeder Ausführungsserver 225e (in der Figur ist nur einer gezeigt) führt eine Virtualisierungsschicht 305e aus (zum Beispiel einen Hypervisor, ein Betriebssystem usw.); die Virtualisierungsschicht 305e stellt virtuelle Datenverarbeitungsressourcen bereit, die entsprechenden physischen Datenverarbeitungsressourcen des Ausführungsservers 225e zugeordnet sind (wie beispielsweise Verarbeitungsfunktion, Arbeitsspeicher, Massenspeicher, Netzwerkfunktionalitäten usw.). Die auf dem Ausführungsserver 225e ausgeführten Softwarekomponenten SCi werden dedizierten (virtuellen) Datenverarbeitungsressourcen zugeordnet, welche von der Virtualisierungsschicht 305e bereitgestellt werden. Zum Beispiel kann es sich bei den Softwarekomponenten SCi um Container (die auch als Zonen oder private Server bezeichnet werden) handeln, die jeweils eine (getrennte) Anwendungsumgebung emulieren, welche auf einem (gemeinsam genutzten) Betriebssystem ausgeführt wird (dank von diesem bereitgestellten Ressourcentrennungsfunktionen).
Jede Softwarekomponente SCi verfügt über ein zugehöriges Manifest MNi. Das Manifest MNi speichert Metadaten in Bezug auf die Softwarekomponente SCi (die zum Beispiel für ihren Einsatz, ihren Aufruf, ihre Überwachung usw. verwendet werden). Bei der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung speichert das Manifest MNi des Weiteren ein Komponentenmodell der Softwarekomponente SCi. Das Komponentenmodell definiert einen (Ressourcen-)Verbrauch einer jeden Datenverarbeitungsressource durch die Softwarekomponente SCi als Funktion ihres Zustands (wie beispielsweise linear, exponentiell, polynomial, konstant usw.). Zum Beispiel wird der Zustand der Softwarekomponente SCi durch ihre Arbeitslast definiert, die durch eine oder mehrere Arbeitslastmetriken angegeben wird (wie beispielsweise Aufrufhäufigkeit, HTTP-Anforderungshäufigkeit, Antworthäufigkeit usw.) Zudem kann der Zustand auch durch einen internen Zustand der Softwarekomponente SCi definiert werden (wie beispielsweise einen Punkt in einem entsprechenden Ablaufplan).
Ein Ressourcenmanager 310 verwaltet die Zuordnung der Datenverarbeitungsressourcen der Ausführungsserver 225e zu den Softwareanwendungen gemäß einer Ausführungsform der vorliegenden Offenbarung. Der Ressourcenmanager 310 wird auf einem (Verwaltungs-(Server), unterschieden mit der Bezugszahl 225m, mit einer ähnlichen Virtualisierungsschicht 305m ausgeführt; zum Beispiel wird der Ressourcenmanager 310 in einer zugeordneten Virtuellen Maschine (VM) ausgeführt, die eine entsprechende physische Datenverarbeitungsmaschine emuliert. Der Ressourcenmanager 310 umfasst die folgenden Softwarekomponenten.
Eine Zustandsüberwachungsfunktion 315 überwacht den Zustand der Softwarekomponenten SCi. Die Zustandsüberwachungsfunktion 315 fragt jede Softwarekomponente SCI ab und schreibt in ein Derzeitige-Zustände-Repository 320. Das Derzeitige-Zustände-Repository 320 umfasst einen Eintrag für jede Softwarekomponente SCi, der einen derzeitigen Zustand von ihr angibt. Zum Beispiel speichert der Eintrag einen derzeitigen Wert einer jeden Arbeitslastmetrik (derzeitige Metrik) der in ihrem Komponentenmodell angegebenen Softwarekomponente SCi; zudem kann der Eintrag auch den internen Zustand speichern, in dem sich die Softwarekomponente SCi derzeit befindet (derzeitiger interner Zustand). Eine Zustandsschätzfunktion 325 schätzt einen zukünftigen Zustand einer jeden Softwarekomponente SCi. Die Zustandsschätzfunktion 325 liest das Derzeitige-Zustände-Repository 320 und ein Anwendungsmodelle-Repository 330.
Das Anwendungsmodelle-Repository 330 umfasst einen Eintrag für jede Softwareanwendung, der ein Anwendungsmodell von ihr speichert. Das Anwendungsmodell definiert den zukünftigen Zustand einer jeden Softwarekomponente SCi der Softwareanwendung als Funktion des derzeitigen Zustands von allen ihren Softwarekomponenten SCi. Insbesondere definiert das Anwendungsmodell einen zukünftigen Wert einer jeden Arbeitslastmetrik (zukünftigen Metrik) der Softwarekomponente SCi als Funktion der derzeitigen Metriken von allen Softwarekomponenten SCi. Das Anwendungsmodell beruht auf einem Trend im Laufe der Zeit der Aufrufe der Softwarekomponenten SCi in der Softwareanwendung (der anhand ihrer Struktur und/oder anhand von Simulationen festgestellt wird); wenn zum Beispiel eine erste Softwarekomponente SCi im Allgemeinen eine zweite Softwarekomponente SCi aufruft, wird die Arbeitslast der ersten Softwarekomponente SCi nach einer Weile wahrscheinlich an die zweite Softwarekomponente SCi übergeben. Insbesondere kann das Anwendungsmodell in drei verschiedenen Betriebsarten angewandt werden (in Abhängigkeit von einem entsprechenden Betriebsart-Parameter). Insbesondere kann der Betriebsart-Parameter auf „Basis“ („baseline“), „Minimum“ oder „Maximum“ eingestellt werden, um eine Basis des zukünftigen Werts einer jeden Arbeitslastmetrik (zukünftige Basismetrik) für einen Standardzustand der Softwarekomponente SCi, ein Minimum des zukünftigen Werts einer jeden Arbeitslastmetrik (zukünftige Minimum-Metrik) für einen besten Zustand der Softwarekomponente SCi bzw. ein Maximum des zukünftigen Werts einer jeden Arbeitslastmetrik (zukünftige Maximum-Metrik) für einen ungünstigsten Zustand der Softwarekomponente SCI bereitzustellen. Zum Beispiel führt der Trend der Aufrufe der Softwarekomponente SCi im Allgemeinen zu mehreren mögliche Szenarien; daher kann der Standardzustand durch einen Durchschnitt der Aufrufe der Softwarekomponente SCi definiert werden (in dem wahrscheinlichsten Szenario oder in einer Kombination der möglichen, nach ihrer Wahrscheinlichkeit gewichteten Szenarien), der beste Zustand kann durch ein Minimum der Aufrufe der Softwarekomponente SCi definiert werden (in dem Szenario mit den geringstmöglichen Aufrufen) und der ungünstigste Zustand kann durch ein Maximum der Aufrufe der Softwarekomponente SCI definiert werden (in dem Szenario mit den höchstmöglichen Aufrufen).
Die Zustandsschätzfunktion 325 schreibt in ein Zukünftige-Zustände-Repository 335. Das Zukünftige-Zustände-Repository 335 umfasst einen Eintrag für jede Softwarekomponente SCi, der einen zukünftigen Zustand von ihr angibt; zum Beispiel speichert der Eintrag die zukünftigen Basismetriken, die zukünftigen Minimum-Metriken und die zukünftigen Maximum-Metriken der gleichen Arbeitslastmetriken der Softwarekomponente SCi in dem Derzeitige-Zustände-Repository 320. Der Eintrag speichert des Weiteren eine bisherige Version der zukünftigen Basismetriken (bisherige zukünftige Metriken), die bisher für die Gegenwart geschätzt wurden.
Eine Verbrauchsüberwachungsfunktion 340 überwacht einen Verbrauch der Datenverarbeitungsressourcen der Ausführungsserver 225e durch die Softwarekomponenten SCi. Die Verbrauchsüberwachungsfunktion 340 fragt die Virtualisierungsschichten 305e der Ausführungsserver 225e ab. Die Verbrauchsüberwachungsfunktion 340 schreibt in ein Derzeitige-Verbräuche-Repository 345. Das Derzeitige-Verbräuche-Repository 345 umfasst einen Eintrag für jede Softwarekomponente SCi, der einen derzeitigen Wert des Verbrauchs (derzeitiger Verbrauch) einer jeden Datenverarbeitungsressource durch die Softwarekomponente SCi angibt.
Eine Verbrauchsschätzfunktion 350 überwacht den Verbrauch der Datenverarbeitungsressourcen in der Zukunft durch die Softwarekomponenten SCi. Die Verbrauchsschätzfunktion 350 liest das Derzeitige-Zustände-Repository 320, das Zukünftige-Zustände-Repository 335 und die Manifeste MNi. Die Verbrauchsschätzfunktion 350 schreibt in ein Zukünftige-Verbräuche-Repository 355. Das Zukünftige-Verbräuche-Repository 355 umfasst einen Eintrag für jede Softwarekomponente SCi, der einen zukünftigen Wert des Verbrauchs (zukünftiger Verbrauch) einer jeden Datenverarbeitungsressource durch die Softwarekomponente SCi angibt. Insbesondere umfasst der Eintrag für jede Datenverarbeitungsressource eine Basis des zukünftigen Werts ihres Verbrauchs (zukünftiger Basisverbrauch) für den Standardzustand der Softwarekomponente SCi, ein Minimum des zukünftigen Werts ihres Verbrauchs (zukünftiger Minimum-Verbrauch) für den besten Zustand der Softwarekomponente SCi und ein Maximum des zukünftigen Werts ihres Verbrauchs (zukünftiger Maximum-Verbrauch) für den ungünstigsten Zustand der Softwarekomponente SCI. Der Eintrag speichert des Weiteren eine bisherige Version der zukünftigen Basisverbräuche (bisherige zukünftige Verbräuche), die bisher für die Gegenwart geschätzt wurden.
Eine Verbrauchsverfeinerungsfunktion 360 verfeinert die zukünftigen Verbräuche der Softwarekomponenten SCi mit einem Feedback-Mechanismus. Die Verbrauchsverfeinerungsfunktion 360 liest das Derzeitige-Verbräuche-Repository 345 und sie liest/schreibt in das Zukünftige-Verbräuche-Repository 355. Eine Verbrauchsprüffunktion 365 prüft die (möglicherweise verfeinerten) zukünftigen Verbräuche der Softwarekomponenten SCi. Die Verbrauchsprüffunktion 365 liest das Derzeitige-Zustände-Repository 320, das Zukünftige-Zustände-Repository 335, das Derzeitige-Verbräuche-Repository 345 und das Zukünftige-Verbräuche-Repository 355. Die Verbrauchsprüffunktion 365 steuert eine Ressourcenzuordnungsfunktion 370. Die Ressourcenzuordnungsfunktion 370 steuert die Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten SCi. Hierzu steuert die Ressourcenzuordnungsfunktion 370 die Virtualisierungsschichten 305e der Ausführungsserver 225e.
Unter Bezugnahme auf die 4A und 4B ist ein Aktivitätsdiagramm gezeigt, das den Ablauf von Aktivitäten in Bezug auf eine Ausführung der Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung beschreibt.
Insbesondere stellt das Aktivitätsdiagramm einen beispielhaften Prozess dar, der verwendet werden kann, um die Zuordnung von Datenverarbeitungsressourcen zu einer generischen Softwareanwendung (die mehrere Softwarekomponenten umfasst) mit einem Verfahren 400 zu verwalten. In diesem Zusammenhang kann jeder Block einer oder mehreren ausführbaren Anweisungen zur Ausführung der angegebenen logischen Funktion auf jeder Workstation entsprechen.
Der Prozess schaltet immer dann, wenn ein (Prüf-)Ereignis eintritt, das eine Prüfung der Zuordnung der Datenverarbeitungsressourcen zu der Softwareanwendung auslöst, vom Block 403 zum Block 406; dies geschieht zum Beispiel periodisch zu entsprechenden Prüfzeitpunkten (wie beispielsweise alle 5 bis 15 Min.). Als Reaktion darauf, misst (oder erfasst) die Zustandsüberwachungsfunktion die derzeitigen Metriken, und möglicherweise auch die derzeitigen internen Zustände, von allen Softwarekomponenten der Softwareanwendung (die ihre derzeitigen Zustände definieren), die mit WMi(j)_PRE für die i-te Softwarekomponente und die j-te Arbeitslastmetrik bezeichnet sind; die Zustandsüberwachungsfunktion speichert dann die derzeitigen Metriken WMi(j)_PRE in dem entsprechenden Repository (indem sie ihre bisherige Version ersetzt). Es erfolgt dann der Eintritt in eine Schleife, um die Softwarekomponenten zu verarbeiten. Die Schleife beginnt am Block 409, in dem eine (aktuelle) Softwarekomponente berücksichtigt wird (wobei bei einer ersten in einer beliebigen Reihenfolge begonnen wird). Die Zustandsschätzfunktion am Block 412 schätzt die zukünftigen Basismetriken, die zukünftigen Minimum-Metriken und die zukünftigen Maximum-Metriken sowie möglicherweise auch die zukünftigen internen Zustände der Softwarekomponente (die ihren zukünftigen Zustand definieren), welche mit WMi(j)_FUT, WMi(j)_FUTmin bzw. WMi(j)_FUTmax bezeichnet sind. Die zukünftigen Basismetriken WMi(j)_FUT, die zukünftigen Minimum-Metriken WMi(j)_FUTmin und die zukünftigen Maximum-Metriken WMi(j)_FUTmax werden geschätzt, indem das Anwendungsmodell der Softwareanwendung MOD_APP auf die derzeitigen Metriken WM∀i(∀j)_PRE von allen Softwarekomponenten (aus den entsprechenden Repositories abgerufen) angewandt wird, wobei der Betriebsart-Parameter auf „Basis“, „Minimum“ bzw. „Maximum“ eingestellt wird: $\begin{array}{l} WMi (j)_FUT = MOD_APP (WM \forall i (\forall j)_PRE,"Basis"), \\ WMi (j)_FUTmin = MOD_APP (WM \forall i (\forall j)_PRE,"Minimum"), \\ WMi (j)_FUTmax = MOD_APP (WM \forall i (\forall j)_PRE,"Maximum"); \end{array}$
die Zustandsschätzfunktion speichert diese Werte in dem Zukünftige-Zustände-Repository, nachdem sie die zu einem bisherigen Prüfzeitpunkt geschätzten zukünftigen Basismetriken, welche deren zu einem immer noch bisherigen Prüfzeitpunkt geschätzte Version ersetzen, verschoben hat, wodurch sie zu den bisherigen zukünftigen Metriken, mit WMi(j)_FUT[-1] bezeichnet, werden. Die Verbrauchsüberwachungsfunktion am Block 415 misst (oder erfasst) die derzeitigen Verbräuche der Datenverarbeitungsressourcen von allen Softwarekomponenten der Softwareanwendung, die mit RCi(k)_PRE für die i-te Softwarekomponente und die k-te Datenverarbeitungsressource bezeichnet sind; die Verbrauchsüberwachungsfunktion speichert die derzeitigen Verbräuche RCi(k)_PRE dann in dem entsprechenden Repository (indem sie deren bisherige Version ersetzt).
Es folgt nun der Eintritt in eine weitere Schleife, um die Datenverarbeitungsressourcen der Softwarekomponente zu verarbeiten. Die Schleife beginnt am Block 418, in dem eine (aktuelle) Datenverarbeitungsressource berücksichtigt wird (wobei bei einer ersten in einer beliebigen Reihenfolge begonnen wird). Die Zustandsschätzfunktion am Block 421 schätzt den zukünftigen Basisverbrauch, den zukünftigen Minimum-Verbrauch und den zukünftigen Maximum-Verbrauch der Datenverarbeitungsressource durch die Softwarekomponente (die ihren zukünftigen Verbrauch definieren), welche mit RCi(k)_FUT, RCi(k)_FUTmin bzw. RCi(k)_FUTmax bezeichnet sind.
Der zukünftige Basisverbrauch RCi(k)_FUT, der zukünftige Minimum-Verbrauch RCi(k)_FUTmin und der zukünftige Maximum-Verbrauch RCi(k)_FUTmax werden geschätzt, indem das Komponentenmodell der Softwarekomponente MOD_COMi (aus dem entsprechenden Manifest abgerufen) auf die zukünftigen Basismetriken WMi(∀j)_FUT, die zukünftigen Minimum-Metriken WMi(Vj)_FUTmin bzw. die zukünftigen Maximum-Metriken WMi(Vj)_FUTmax (aus dem entsprechenden Repository abgerufen) angewandt werden: $\begin{array}{l} RCi (k)_FUT = MOD_COMi (WMi (\forall_{j})_FUT), \\ RCi (k)_FUTmin = MOD_COMi (WMi (\forall_{j})_FUTmin), \\ RCi (k)_FUTmax = MOD_COMi (WMi (\forall_{j})_FUTmax); \end{array}$
die Verbrauchsschätzfunktion speichert diese Werte in dem Zukünftige-Verbräuche-Repository, nachdem sie den zu einem bisherigen Prüfzeitpunkt geschätzten zukünftigen Basisverbrauch, welcher seine zu einem immer noch bisherigen Prüfzeitpunkt geschätzte Version ersetzt, verschoben hat, wodurch er zu dem bisherigen zukünftigen Verbrauch der Datenverarbeitungsressource, mit RCi(k)_FUT[-1] bezeichnet, wird.
Die Verbrauchsverfeinerungsfunktion am Block 424 berechnet einen (Verbrauchs-)Fehler ERRi(k) der Schätzung des bisherigen zukünftigen Verbrauchs RCi(k)_FUT[-1], durchgeführt zu dem bisherigen Prüfzeitpunkt für den derzeitigen Prüfzeitpunkt, in Bezug auf den derzeitigen Verbrauch RCi(k)_PRE, welcher dessen tatsächlichen Wert, gemessen zu dem derzeitigen Prüfzeitpunkt (aus den entsprechenden Repositories abgerufen) darstellt: $ERRi (k) = RCi (k)_FUT [- 1] - Rci (k)_PRE .$
Die Verbrauchsverfeinerungsfunktion am Block 427 verfeinert den zukünftigen Minimum-Verbrauch RCi(k)_FUTmin und die Maximum-Verbrauchsmetriken RCi(k)_FUTmin, indem sie sie mit der zukünftigen Basisverbrauchsmetrik RCi(k)_FUT vergleicht, welche aktualisiert wird gemäß dem Verbrauchsfehler ERRi(k): $\begin{array}{l} RCi (k)_FUTmin = min [RCi (k)_FUTmin,RCi (k)_FUT - ERRi (k)], \\ RCi (k)_FUTmax = max [RCi (k)_FUTmax,RCi (k)_FUT - ERRi (k)] . \end{array}$
Es erfolgt der Eintritt in eine weitere Schleife, um entsprechende (Metrik-)Fehler ERRi(k,j) der Schätzung (für die i-te Softwarekomponente) des zukünftigen Verbrauchs der k-ten Datenverarbeitungsressource, die nur von der j-ten Arbeitslastmetrik abhängig ist, zu berechnen (durchgeführt zu dem bisherigen Prüfzeitpunkt für den derzeitigen Prüfzeitpunkt). Die Schleife beginnt am Block 430, in dem die Verbrauchsprüffunktion eine (aktuelle) Arbeitslastmetrik berücksichtigt (wobei bei einer ersten in einer beliebigen Reihenfolge begonnen wird). In dieser Phase kann die Verbrauchsprüffunktion auch die zu berücksichtigenden Arbeitslastmetriken gemäß ihrer Korrelation mit dem Verbrauch der Datenverarbeitungsressource filtern. Insbesondere werden die Arbeitslastmetriken zum Beispiel mit einer Linear Discriminant Analysis (die auf einem Trainingssatz beruht, der aus Langzeitdaten der Arbeitslastmetriken und deren Metrikfehlern abgeleitet wird) in eine relevante Klasse (die erheblich zum Verbrauch der Datenverarbeitungsressource beiträgt) und eine nicht relevante Klasse (die nicht erheblich zum Verbrauch der Datenverarbeitungsressource beiträgt) eingeteilt; die Verarbeitung wird dann nur auf die relevanten Metriken beschränkt. Dadurch kann die Rechenkomplexität verringert werden, ohne dass sich dies negativ auf die Zuverlässigkeit auswirkt. In jedem Fall schätzt die Verbrauchsprüffunktion am Block 433 einen teilweisen zukünftigen Verbrauch RCi(k,j)_FUT für den derzeitigen Prüfzeitpunkt (für die k-te Datenverarbeitungsressource der i-ten Softwarekomponente), der nur von dieser j-ten Arbeitslastmetrik abhängig ist.
Der teilweise zukünftige Verbrauch RCi(k,j)_FUT wird geschätzt, indem das Komponentenmodell der Softwarekomponente MOD_COMi (aus dem entsprechenden Manifest abgerufen) auf die bisherige zukünftige Metrik WMi(j)_FUT[-1] der j-ten Arbeitslastmetrik (zum bisherigen Prüfzeitpunkt für den derzeitigen Prüfzeitpunkt geschätzt) und auf die derzeitigen Metriken WMi(j')_PRE (wobei j'≠j) der anderen Arbeitslastmetriken, die sich von ihr unterscheiden (die gleich ihrer zu dem derzeitigen Prüfzeitpunkt gemessenen tatsächlichen Werte sind) angewandt wird: $RCi (k,j)_FUT [- 1] = MOD_COMi (WMi (j)_FUT [-1],WMi (j')_PRE) .$
Die Verbrauchsprüffunktion am Block 436 berechnet den Metrikfehler ERRi(k,j) des teilweisen zukünftigen Verbrauchs RCi(k,j)_FUT[-1], geschätzt für den derzeitigen Prüfzeitpunkt, in Bezug auf den derzeitigen Verbrauch RCi(k)_PRE, der dessen tatsächlichen Wert, gemessen zum derzeitigen Prüfzeitpunkt (aus dem entsprechenden Repository abgerufen) $ERRi (k,j) = RCi (k,j)_FUT [- 1] - RCi (k)_PRE,$
darstellt.
Ein Test wird am Block 439 durchgeführt, in dem die Verbrauchsprüffunktion prüft, ob eine letzte Arbeitslastmetrik verarbeitet wurde. Wenn nicht, kehrt der Aktivitätsablauf zum Block 430 zurück, um die gleichen Operationen an einer nächsten Arbeitslastmetrik zu wiederholen. Umgekehrt wird (sobald alle Arbeitslastmetriken verarbeitet wurden) die Schleife verlassen, indem in den Block 442 hinab geschaltet wird.
An diesem Punkt berechnet die Verbrauchsprüffunktion einen (niedrigen) Prüfgrenzwert TH1i(k) und einen (hohen) Prüfgrenzwert TH2i(k) gemäß den Metrikfehlern ERRi(k,Vj) von allen Arbeitslastmetriken (der i-ten Softwarekomponente für die k-te Datenverarbeitungsressource); zum Beispiel werden die Prüfgrenzwerte TH1i(k),TH2i(k) auf eine skalierte Summe der Metrikfehler ERRi(k, ∀j) eingestellt: $T h 1 i (k) = S C 1 \cdot \sum_{j} E R R i (k, j),$
$T h 2 i (k) = S C 2 \cdot \sum_{j} E R R i (k, j) .$
wobei SC1 ein (niedriger) Skalierungsfaktor und SC2 ein (hoher) Skalierungsfaktor ist. Der Skalierungsfaktor SC2 ist streng höher als der Skalierungsfaktor SC1 (so dass der Prüfgrenzwert TH2i streng höher als der Prüfgrenzwert TH1i ist). Zum Beispiel wird der Skalierungsfaktor SC2 auf 0,6 bis 0,8, vorzugsweise auf 0,7 eingestellt, und der Skalierungsfaktor SC1 wird auf 0,2 bis 0,4, vorzugsweise auf 0,3 eingestellt.
Der Aktivitätsablauf verzweigt am Block 445 gemäß einem Vergleich des (möglicherweise verfeinerten) zukünftigen Minimum-Verbrauchs RCi(k)_FUTmin und des zukünftigen Maximum-Verbrauchs RCi(k)_FUTmax mit dem Prüfgrenzwert TH1i bzw. dem Prüfgrenzwert TH2i. Insbesondere, wenn sowohl der zukünftige Minimum-Verbrauch RCi(k)_FUTmin (möglicherweise streng) niedriger als der Prüfgrenzwert TH1i und der zukünftige Maximum-Verbrauch RCi(k)_FUTmax (möglicherweise streng) höher als der Prüfgrenzwert TH2i ist, schaltet der Prozess hinab in den Block 448. Das bedeutet, dass die Schätzung sowohl des zukünftigen Minimum-Verbrauchs RCi(k)_FUTmin als auch des zukünftigen Maximum-Verbrauchs RCi(k)_FUTmax genau ist. Daher ordnet die Ressourcenzuordnungsfunktion die Datenverarbeitungsressourcen der Softwarekomponente entsprechend zu; zum Beispiel ordnet die Ressourcenzuordnungsfunktion die Datenverarbeitungsressource einem Bereich zwischen dem zukünftigen Minimum-Verbrauch RCi(k)_FUTmin und dem zukünftigen Maximum-Verbrauch RCi(k)_FUTmax zu.
Der Prozess wird dann am Block 451 fortgesetzt; derselbe Punkt wird auch direkt vom Block 445 aus erreicht (ohne sich auf die Zuordnung der Datenverarbeitungsressource zu der Softwarekomponente auszuwirken), wenn der zukünftige Minimum-Verbrauch RCi(k)_FUTmin (möglicherweise streng) höher als der Prüfgrenzwert TH1i und/oder der zukünftige Maximum-Verbrauch RCi(k)_FUTmax (möglicherweise streng) niedriger als der Prüfgrenzwert TH2i ist (was bedeutet, dass mindestens einer von ihnen nicht genau ist).
An diesem Punkt prüft die Verbrauchsprüffunktion, ob eine letzte Datenverarbeitungsressource verarbeitet wurde. Wenn nicht, kehrt der Aktivitätsablauf zum Block 418 zurück, um die gleichen Operationen an einer nächsten Datenverarbeitungsressource zu wiederholen. Umgekehrt wird (sobald alle Datenverarbeitungsressourcen verarbeitet wurden) die Schleife verlassen, indem in den Block 454 hinab geschaltet wird. Die Zustandsschätzfunktion prüft nun, ob eine letzte Softwarekomponente verarbeitet wurde. Wenn nicht, kehrt der Aktivitätsablauf zum Block 409 zurück, um die gleichen Operationen an einer nächsten Softwarekomponente zu wiederholen. Umgekehrt wird (sobald alle Softwarekomponenten verarbeitet wurden) die Schleife verlassen, indem zum Block 403 zurückgekehrt wird, wo auf ein nächstes Prüfereignis gewartet wird.
Natürlich kann der Fachmann, um lokale und bestimmte Anforderungen zu erfüllen, viele logische und/oder physische Modifikationen und Änderungen auf die vorliegende Offenbarung anwenden. Genauer gesagt, obgleich diese Offenbarung unter Bezugnahme auf eine oder mehrere Ausführungsformen der Offenbarung mit einem bestimmten Grad an Genauigkeit beschrieben wurde, sollte klar sein, dass verschiedene Weglassungen, Ersetzungen und Änderungen an der Form und an Einzelheiten sowie weitere Ausführungsformen möglich sind. Im Einzelnen können verschiedene Ausführungsformen der vorliegenden Offenbarung sogar ohne die bestimmten Einzelheiten (wie beispielsweise die numerischen Werte), die in der vorausgehenden Beschreibung angegeben wurden, um sie verständlicher zu machen, in die Praxis umgesetzt werden; umgekehrt wurden hinlänglich bekannte Merkmale gegebenenfalls weggelassen oder vereinfacht, um die Beschreibung nicht mit unnötigen Einzelheiten zu überfrachten. Überdies ist ausdrücklich beabsichtigt, dass bestimmte Elemente und/oder Verfahrensschritte, die in Verbindung mit einer beliebigen Ausführungsform der vorliegenden Offenbarung beschrieben wurden, einer generellen Ausgestaltungswahl halber in jede beliebige weitere Ausführungsform integriert werden können. Überdies sollen Elemente, die in einer gleichen Gruppe und in verschiedenen Ausführungsformen, Beispielen oder Alternativen dargestellt werden, nicht als de facto einander entsprechend ausgelegt werden (vielmehr handelt es sich um getrennte und autonome Entitäten). In jedem Fall sollte jeder numerische Wert als ein gemäß anwendbaren Toleranzen geänderter Wert gelesen werden; insbesondere, sofern nicht anders angegeben, sollten die Begriffe „weitgehend“, „circa“, „ungefähr“ und dergleichen als innerhalb von 10 %, vorzugsweise 5 % und noch bevorzugter 1 % liegend verstanden werden. Überdies sollte jeder Bereich von numerischen Werten als ausdrücklich eine beliebige mögliche Zahl entlang des Kontinuums innerhalb des Bereichs (einschließlich seiner Endpunkte) angebend angesehen werden. Ordinale oder andere Qualifikationsmerkmale werden lediglich als Bezeichnungen zur Unterscheidung von Elementen mit dem gleichen Namen verwendet, bedeuten selbst aber keine Priorität, Vorrangstellung oder Reihenfolge. Die Begriffe „umfassen“, „haben“, „enthalten“, „einschließen“ und dergleichen sollten mit einer offenen, nicht abschließenden Bedeutung (d.h. nicht auf die aufgeführten Elemente beschränkt) angesehen werden, die Begriffe „beruhend auf‟, „abhängig von“, „gemäß“, „Funktion von“ und dergleichen sollten als eine nicht ausschließliche Beziehung (d.h., mit möglichen weiteren eingeschlossenen Variablen) angesehen werden, der Begriff „ein“/„eine“ sollte als ein oder mehrere Elemente (soweit nicht ausdrücklich anders angegeben) angesehen werden und der Begriff „Mittel für“ (oder eine beliebige Mittel-plus-Funktion-Formulierung) sollte als eine beliebige Struktur angesehen werden, die so ausgelegt oder konfiguriert ist, dass sie die relevante Funktion durchführt.
Zum Beispiel stellt eine Ausführungsform ein Verfahren zur Ressourcenverwaltung einer Softwareanwendung bereit. Jedoch kann die Softwareanwendung von einem beliebigen Typ sein (zum Beispiel Anwendungssoftware, Middleware-Software, Systemsoftware und dergleichen, die in einer beliebigen Umgebung, wie beispielsweise Cloud, Client/Server, einer eigenständigen Umgebung und dergleichen usw., ausgeführt wird).
In einer Ausführungsform umfasst die Softwareanwendung eine Mehrzahl von Softwarekomponenten, die miteinander interagieren. Jedoch können die Softwarekomponenten in beliebiger Zahl vorhanden und von einem beliebigen Typ sein (zum Beispiel Services, Module, Jobs usw.).
In einer Ausführungsform umfasst das Verfahren die folgenden Schritte unter der Kontrolle eines Datenverarbeitungssystems. Jedoch kann das Datenverarbeitungssystem von einem beliebigen Typ sein (zum Beispiel eine dedizierte virtuelle/physische Maschine, dieselbe virtuelle/physische Maschine, in der einige der Softwarekomponenten (bis hin zu allen) ausgeführt werden, usw.).
In einer Ausführungsform umfasst das Verfahren ein Überwachen (durch das Datenverarbeitungssystem) von entsprechenden derzeitigen Zuständen der Softwarekomponenten. Jedoch können die derzeitigen Zustände der Softwarekomponenten auf beliebige Weise definiert werden (zum Beispiel durch beliebige Arbeitslastmetriken, einen beliebigen internen Zustand, deren Kombination usw.), und sie können auf beliebige Weise überwacht werden (zum Beispiel, indem zu einem beliebigen Prüfzeitpunkt gemessen wird, indem während einer jeden Prüfperiode laufend gemessen wird (wie beispielsweise alle 10 bis 30 Sekunden) und entsprechende Durchschnittswerte dann über die letzte Prüfperiode zu einem jeden Prüfzeitpunkt berechnet werden usw.).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) von entsprechenden zukünftigen Verbräuchen von einer oder mehreren Datenverarbeitungsressourcen, von denen jeder einen zukünftigen Wert eines Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt. Jedoch können die Datenverarbeitungsressourcen von einem beliebigen Datenverarbeitungssystem (zum Beispiel einem oder mehreren physischen/virtuellen Servern usw.), in beliebiger Zahl vorhanden und von einem beliebigen Typ sein (zum Beispiel teilweise, unterschiedliche und zusätzliche Datenverarbeitungsressourcen in Bezug auf die vorstehend erwähnten, von einem virtuellen und/oder physischen Typ usw.); überdies können ihre zukünftigen Verbräuche auf beliebige Weise definiert werden (zum Beispiel absolute Werte, Prozentsätze usw.).
In einer Ausführungsform werden die zukünftigen Verbräuche der Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten gemäß mindestens einem Schätzmodell geschätzt. Jedoch können die Schätzmodelle in beliebiger Zahl vorhanden (zum Beispiel ein Anwendungsmodell für die ganze Softwareanwendung und entsprechende Komponentenmodelle für die Softwarekomponenten, ein einzelnes globales Modell oder entsprechende einzelne Modelle für die Softwarekomponenten, die ihre jeweilige Logik kumulieren, usw.) und von einem beliebigen Typ sein (zum Beispiel analytisch, diskret und dergleichen, explizit oder implizit, wie beispielsweise in entsprechende neuronale Netze eingebettet usw.).
In einer Ausführungsform umfasst das Verfahren ein Steuern (durch das Datenverarbeitungssystem) einer Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten gemäß den entsprechenden zukünftigen Verbräuchen. Jedoch kann die Zuordnung auf beliebige Weise (zum Beispiel Erhöhen/Verringern der Datenverarbeitungsressourcen, Hinzufügen/Entfernen von Instanzen der Softwarekomponenten, Durchführen eines erneuten Staging der Softwareanwendung usw.) gemäß den zukünftigen Verbräuchen (zum Beispiel gemäß absoluten Werten, relativen Werten in Bezug auf die derzeitigen Verbräuche usw.) gesteuert werden.
Weitere Ausführungsformen stellen zusätzliche vorteilhafte Merkmale bereit, die in einer Grundausführung jedoch ganz weggelassen werden können.
Insbesondere umfasst das Verfahren in einer Ausführungsform ein Überwachen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des derzeitigen Zustands der Softwarekomponente einschließlich entsprechender derzeitiger Metriken von einer oder mehreren Arbeitslastmetriken der Softwarekomponente, von denen jede einen derzeitigen Wert der entsprechenden Arbeitslastmetrik angibt. Jedoch können die Arbeitslastmetriken in beliebiger Zahl vorhanden und von einem beliebigen Typ sein (zum Beispiel teilweise, unterschiedliche und zusätzliche Arbeitslastmetriken in Bezug auf die vorstehend erwähnten) und ihre derzeitigen Werte können auf beliebige Weise definiert werden (zum Beispiel absolute Werte, Prozentsätze usw.).
In einer Ausführungsform umfasst das mindestens eine Schätzmodell ein Anwendungsmodell der Softwareanwendung und entsprechende Komponentenmodelle der Softwarekomponenten. Jedoch können das Anwendungsmodell und die Komponentenmodelle von einem beliebigen Typ sein (sie können entweder gleich sein oder sich voneinander unterscheiden).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem) von entsprechenden zukünftigen Zuständen der Softwarekomponenten. Jedoch können die zukünftigen Zustände auf beliebige Weise definiert werden (entweder gleich oder unterschiedlich in Bezug auf die derzeitigen Zustände).
In einer Ausführungsform werden die zukünftigen Zustände einer jeden der Softwarekomponenten anhand der derzeitigen Zustände der Softwarekomponenten gemäß dem Anwendungsmodell geschätzt. Jedoch kann das Anwendungsmodell von einem beliebigen Typ sein (zum Beispiel auf den derzeitigen Zuständen der Softwarekomponenten, auf einem derzeitigen internen Zustand der Softwareanwendung, auf den derzeitigen internen Zuständen der Softwarekomponenten, auf einer beliebigen Kombination daraus usw. beruhen).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) der zukünftigen Verbräuche der Softwarekomponente anhand des zukünftigen Zustands der Softwarekomponente gemäß dem Komponentenmodell der Softwarekomponente. Jedoch kann das Komponentenmodell von einem beliebigen Typ sein (zum Beispiel auf dem zukünftigen Zustand, auf dem zukünftigen internen Zustand, auf beiden von ihnen usw. beruhen); in jedem Fall wird die Möglichkeit, die zukünftigen Verbräuche der Softwarekomponenten direkt anhand ihrer derzeitigen Zustände zu schätzen, nicht ausgeschlossen.
In einer Ausführungsform umfasst das Verfahren ein Lesen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des Komponentenmodells aus einem Manifest der Softwarekomponente. Jedoch kann das Manifest von einem beliebigen Typ sein (zum Beispiel XML-Text usw.), es kann auf beliebige Weise bereitgestellt werden (zum Beispiel zusammen mit der Softwarekomponente gespeichert, in einem zentralen Repository veröffentlicht usw.) und es kann auf beliebige Weise gelesen werden (zum Beispiel direkt, über einen Fernbefehl usw.); in jedem Fall wird die Möglichkeit, das Komponentenmodell auf andere Weise, selbst unabhängig von dem Manifest, sofern vorhanden, der Softwarekomponente bereitzustellen, nicht ausgeschlossen.
In einer Ausführungsform umfasst das Verfahren ein Messen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) von entsprechenden derzeitigen Verbräuchen der Datenverarbeitungsressourcen, von denen jeder einen derzeitigen Wert des Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt. Jedoch können die derzeitigen Verbräuche von einem beliebigen Typ sein (entweder gleich oder unterschiedlich in Bezug auf die zukünftigen Verbräuche) und sie können auf beliebige Weise gemessen werden (zum Beispiel nur einmal zu einem beliebigen Prüfzeitpunkt, zwei oder mehrere Male um den beliebigen Prüfzeitpunkt herum, woraufhin entsprechende Durchschnittswerte berechnet werden, usw.).
In einer Ausführungsform umfasst das Verfahren ein Berechnen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) von entsprechenden Schätzfehlern der Datenverarbeitungsressourcen. Jedoch können die Schätzfehler von einem beliebigen Typ sein (zum Beispiel für jede Datenverarbeitungsressource ein einzelner Verbrauchsfehler, entsprechende Metrikfehler für die Arbeitslastmetriken, eine beliebige Kombination daraus usw.).
In einer Ausführungsform wird der Schätzfehler einer jeden der Datenverarbeitungsressourcen gemäß dem derzeitigen Verbrauch und einem bisherigen zukünftigen Verbrauch geschätzt, der aus dem bisher geschätzten zukünftigen Verbrauch besteht. Jedoch kann der Schätzfehler auf beliebige Weise geschätzt werden (zum Beispiel gemäß einem beliebigen Vergleich zwischen dem derzeitigen Verbrauch und dem zukünftigen Basisverbrauch, zwischen dem derzeitigen Verbrauch und den teilweisen zukünftigen Verbräuchen der Arbeitslastmetriken usw.).
In einer Ausführungsform umfasst das Verfahren ein weiteres Steuern (durch das Datenverarbeitungssystem) der Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten gemäß den entsprechenden Schätzfehlern. Jedoch kann die Zuordnung gemäß den Schätzfehlern auf beliebige Weise gesteuert werden (zum Beispiel, indem die Schätzfehler verwendet werden, um die zukünftigen Verbräuche zu verfeinern, um die Zuordnung der Datenverarbeitungsressourcen auszulösen, oder eine beliebige Kombination daraus usw.).
In einer Ausführungsform umfasst das Verfahren ein Verfeinern (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des zukünftigen Verbrauchs einer jeden der Datenverarbeitungsressourcen gemäß dem Schätzfehler der Datenverarbeitungsressource. Jedoch können die zukünftigen Verbräuche auf beliebige Weise verfeinert werden (zum Beispiel, indem die zukünftigen Minimum-/Maximum-Verbräuche, der zukünftige Basisverbrauch, eine beliebige Kombination daraus usw. aktualisiert werden).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) der zukünftigen Verbräuche der Datenverarbeitungsressourcen einschließlich entsprechender zukünftiger Basisverbräuche, zukünftiger Minimum-Verbräuche und zukünftiger Maximum-Verbräuche. Jedoch können die zukünftigen Basis-/Minimum-/Maximum-Verbräuche auf beliebige Weise geschätzt werden (zum Beispiel anhand von zukünftigen Basis-/Minimum-/Maximum-Zuständen, die anhand der derzeitigen Zustände, direkt anhand der derzeitigen Zustände usw. geschätzt werden).
In einer Ausführungsform geben der zukünftige Basisverbrauch, der zukünftige Minimum-Verbrauch und der zukünftige Maximum-Verbrauch einer jeden der Datenverarbeitungsressourcen eine Basis, ein Minimum bzw. ein Maximum des zukünftigen Werts des Verbrauchs der entsprechenden Datenverarbeitungsressource an. Jedoch können die Basis/das Minimum/das Maximum des zukünftigen Werts des Verbrauchs auf beliebige Weise definiert werden (wobei zum Beispiel die Basis dem Mittelwert, dem Modus, dem Modalwert, das Minimum/Maximum dem höchsten/niedrigsten Wert, mit oder ohne Filtern von Spitzen usw., entspricht).
In einer Ausführungsform umfasst das Verfahren ein Berechnen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) der Schätzfehler einschließlich entsprechender Verbrauchsfehler; der Verbrauchsfehler einer jeden der Datenverarbeitungsressourcen wird gemäß einer Differenz zwischen dem derzeitigen Verbrauch der Datenverarbeitungsressource und einem bisherigen zukünftigen Verbrauch der Datenverarbeitungsressource (der aus dem bisher geschätzten zukünftigen Basisverbrauch der Datenverarbeitungsressource besteht) berechnet. Jedoch kann der Verbrauchsfehler auf beliebige Weise berechnet werden (zum Beispiel in absoluten Zahlen, in relativen Zahlen in Bezug auf den derzeitigen Verbrauch usw.).
In einer Ausführungsform umfasst das Verfahren ein Verfeinern (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des zukünftigen Minimum-Verbrauchs und des zukünftigen Maximum-Verbrauchs einer jeden der Datenverarbeitungsressourcen gemäß dem zukünftigen Basisverbrauch und dem Verbrauchsfehler der Datenverarbeitungsressource. Jedoch können die zukünftigen Minimum-/Maximum-Verbräuche auf beliebige Weise verfeinert werden (zum Beispiel, indem sie mit dem gemäß dem Verbrauchsfehler aktualisierten zukünftigen Basisverbrauch verglichen werden, indem sie direkt gemäß einem Prozentsatz des Verbrauchsfehlers aktualisiert werden usw.).
In einer Ausführungsform umfasst das Verfahren ein Einstellen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des zukünftigen Minimum-Verbrauchs einer jeden der Datenverarbeitungsressourcen auf ein Minimum zwischen dem zukünftigen Minimum-Verbrauch und dem zukünftigen Basisverbrauch abzüglich des Verbrauchsfehlers der Datenverarbeitungsressource. Jedoch wird die Möglichkeit nicht ausgeschlossen, den zukünftigen Minimum-Verbrauch mit dem auf eine beliebige andere Weise gemäß dem Verbrauchsfehler aktualisierten zukünftigen Basisverbrauch zu vergleichen (zum Beispiel, indem der Verbrauchsfehler oder ein beliebiger Prozentsatz davon subtrahiert wird oder indem eine Division durch den Verbrauchsfehler oder einen beliebigen Prozentsatz davon erfolgt usw.).
In einer Ausführungsform umfasst das Verfahren ein Einstellen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des zukünftigen Maximum-Verbrauchs einer jeden der Datenverarbeitungsressourcen auf ein Maximum zwischen dem zukünftigen Maximum-Verbrauch und dem zukünftigen Basisverbrauch zuzüglich des Verbrauchsfehlers der Datenverarbeitungsressource. Jedoch wird die Möglichkeit nicht ausgeschlossen, den zukünftigen Maximum-Verbrauch mit dem auf eine beliebige andere Weise gemäß dem Verbrauchsfehler aktualisierten zukünftigen Basisverbrauch zu vergleichen (zum Beispiel, indem der Verbrauchsfehler oder ein beliebiger Prozentsatz davon addiert wird oder indem eine Multiplikation mit dem Verbrauchsfehler oder einem beliebigen Prozentsatz davon erfolgt usw.).
In einer Ausführungsform umfasst das Verfahren ein Auslösen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des Steuerns der Zuordnung einer jeden der Datenverarbeitungsressourcen gemäß einem Vergleich des zukünftigen Verbrauchs der Datenverarbeitungsressource mit einem oder mehreren entsprechenden Prüfgrenzwerten auf der Grundlage des Schätzfehlers der Datenverarbeitungsressource. Jedoch können die Prüfgrenzwerte in beliebiger Zahl vorhanden sein und auf beliebige Weise auf dem Schätzfehler beruhen (zum Beispiel anhand der entsprechenden Metrikfehler, des Verbrauchsfehlers, einer beliebigen Kombination daraus usw. berechnet werden); die Zuordnung kann gemäß einem beliebigen Vergleich des zukünftigen Verbrauchs mit den Prüfgrenzwerten ausgelöst werden (zum Beispiel, indem der zukünftige Minimum-Verbrauch, der zukünftige Maximum-Verbrauch, der zukünftige Basisverbrauch, eine beliebige Kombination daraus verglichen werden, sobald entsprechende Bedingungen erfüllt sind oder erst, nachdem dies bei zwei oder mehreren Prüfzeitpunkten geschehen ist usw.).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) von entsprechenden zukünftigen Metriken für die Arbeitslastmetriken, von denen jede einen zukünftigen Wert der entsprechenden Arbeitslastmetrik der Softwarekomponente angibt. Jedoch können die zukünftigen Metriken von einem beliebigen Typ sein (entweder gleich oder unterschiedlich in Bezug auf die derzeitigen Metriken).
In einer Ausführungsform wird die zukünftige Metrik einer jeden der Arbeitslastmetriken der Softwarekomponente anhand der derzeitigen Metriken der Arbeitslastmetrik der Softwarekomponenten gemäß dem mindestens einen Schätzmodell geschätzt. Jedoch kann die zukünftige Metrik auf beliebige Weise geschätzt werden (zum Beispiel mit oder ohne Berücksichtigung der internen Zustände der Softwarekomponenten, der derzeitigen Metriken von einer oder mehreren anderen Arbeitslasten usw.).
In einer Ausführungsform umfasst das Verfahren ein Schätzen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten), für jede der Datenverarbeitungsressourcen, von entsprechenden teilweisen zukünftigen Verbräuchen für die Arbeitslastmetriken. Jedoch können die teilweisen zukünftigen Verbräuche in beliebiger Zahl vorhanden (zum Beispiel für alle Arbeitslastmetriken oder nur für einen Teil davon usw.) und von einem beliebigen Typ sein (zum Beispiel entweder gleich oder unterschiedlich in Bezug auf die zukünftigen Verbräuche usw.).
In einer Ausführungsform wird der teilweise zukünftige Verbrauch einer jeden der Arbeitslastmetriken anhand einer bisherigen zukünftigen Metrik der Arbeitslastmetrik (die aus der zukünftigen Metrik der bisher geschätzten Arbeitslastmetrik besteht) und den derzeitigen Metriken von beliebigen anderen Arbeitslastmetriken gemäß dem mindesten einen Schätzmodell geschätzt. Jedoch kann der teilweise zukünftige Verbrauch auf beliebige Weise geschätzt werden (zum Beispiel mit oder ohne Berücksichtigung der internen Zustände der Softwareanwendungen usw.).
In einer Ausführungsform umfasst das Verfahren ein Berechnen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des Schätzfehlers einer jeden der Datenverarbeitungsressourcen, der entsprechende Metrikfehler für die Arbeitslastmetriken umfasst; der Metrikfehler einer jeden der Arbeitslastmetriken wird gemäß einer Differenz zwischen dem derzeitigen Verbrauch der Datenverarbeitungsressource und dem teilweisen zukünftigen Verbrauch der Arbeitslastmetrik für die Datenverarbeitungsressource berechnet. Jedoch können die Metrikfehler in beliebiger Weise berechnet werden (zum Beispiel in absoluten Zahlen, in relativen Zahlen in Bezug auf den derzeitigen Verbrauch usw.).
In einer Ausführungsform umfasst das Verfahren ein Einstellen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) der Prüfgrenzwerte einer jeden der Datenverarbeitungsressourcen gemäß den Metrikfehlern der Datenverarbeitungsressource. Jedoch können die Prüfgrenzwerte in beliebiger Zahl vorhanden sein (zum Beispiel einer für den zukünftigen Minimum-Verbrauch und ein weiterer für den zukünftigen Maximum-Verbrauch, ein einziger für beide von ihnen usw.) und sie können gemäß den Metrikfehlern auf beliebige Weise eingestellt werden (zum Beispiel, indem die Metrikfehler summiert, multipliziert und dergleichen werden, mit oder ohne Gewichtung der Metrikfehler, mit oder ohne Anwenden eines beliebigen Skalierungsfaktors usw.).
In einer Ausführungsform umfasst das Verfahren ein Auslösen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des Steuerns der Zuordnung einer jeden der Datenverarbeitungsressourcen als Reaktion darauf, dass der zukünftige Minimum-Verbrauch der Datenverarbeitungsressource niedriger als ein niedriger der Prüfgrenzwerte und der zukünftigen Maximum-Verbrauch der Datenverarbeitungsressource höher als ein hoher der Prüfgrenzwerte ist, welcher höher als der niedrige Prüfgrenzwert ist. Jedoch kann die Zuordnung gemäß einem beliebigen Vergleich des zukünftigen Minimum-/ Maximum-Verbrauchs mit beliebigen Prüfgrenzwerten ausgelöst werden (zum Beispiel, wenn die entsprechenden Bedingungen sowohl durch den zukünftigen Minimum-Verbrauch als auch den zukünftigen Maximum-Verbrauch, durch nur einen von ihnen usw. erfüllt sind).
In einer Ausführungsform umfasst das Verfahren ein Einstellen (durch das Datenverarbeitungssystem für jede der Softwarekomponenten) des niedrigen Prüfgrenzwerts und des hohen Prüfgrenzwerts einer jeden der Datenverarbeitungsressourcen auf eine Summe der Arbeitslastmetriken der Datenverarbeitungsressource, multipliziert mit einem niedrigen Skalierungsfaktor bzw. einem hohen Skalierungsfaktor (wobei der hohe Skalierungsfaktor höher als der niedrige Skalierungsfaktor ist). Jedoch kann der niedrige/hohe Skalierungsfaktor einen beliebigen Wert haben (entweder in absoluten oder in relativen Zahlen).
In einer Ausführungsform handelt es sich bei der Softwareanwendung um eine Cloud-Softwareanwendung. Jedoch kann die Cloud-Softwareanwendung von einem beliebigen Typ sein (zum Beispiel laaS, PaaS, SaaS oder NaaS, Public, Hybrid oder Private usw.).
In einer Ausführungsform führen die Softwarekomponenten entsprechende Services aus. Jedoch können die Services von einem beliebigen Typ sein (zum Beispiel Standard-, Mikro-, Nano-Services usw.).
Im Allgemeinen gelten ähnliche Überlegungen, wenn die gleiche Lösung mit einem gleichwertigen Verfahren ausgeführt wird (indem ähnliche Schritte mit den gleichen Funktionen oder mehr Schritte oder Teile davon verwendet werden, einige nicht unbedingt notwendige Schritte entfernt oder weitere optionale Schritte hinzugefügt werden); überdies können die Schritte in einer anderen Reihenfolge, gleichzeitig oder ineinander verschachtelt (zumindest teilweise) durchgeführt werden.
Eine Ausführungsform stellt ein Computerprogramm bereit, das so konfiguriert ist, dass es ein Datenverarbeitungssystem dazu veranlasst, das vorstehend erwähnte Verfahren durchzuführen. Eine Ausführungsform stellt ein Computerprogrammprodukt bereit, das ein durch einen Computer lesbares Speichermedium umfasst, welches über damit verkörperte Programmanweisungen verfügt; die Programmanweisungen sind durch ein Datenverarbeitungssystem ausführbar, um das Datenverarbeitungssystem dazu zu veranlassen, selbiges Verfahren durchzuführen. Jedoch kann das Computerprogramm als ein eigenständiges Modul, als ein Plug-in für eine bereits bestehende Softwareanwendung (zum Beispiel einen Cloud-Manager) oder direkt darin ausgeführt sein. Überdies kann das Computerprogramm auf einem beliebigen Datenverarbeitungssystem ausgeführt werden (siehe nachstehend). In jedem Fall bietet sich die Lösung gemäß einer Ausführungsform der vorliegenden Offenbarung selbst für eine Ausführung mit einer Hardwarestruktur (zum Beispiel durch elektronische Schaltungen, die in einen oder mehrere Chips aus Halbleitermaterial integriert sind) oder mit einer Kombination aus Software und Hardware an, die in geeigneter Weise programmiert oder auf andere Weise konfiguriert ist.
Eine Ausführungsform stellt ein System bereit, das Mittel umfasst, die so konfiguriert sind, dass sie die Schritte des vorstehend beschriebenen Verfahrens durchführen. Eine Ausführungsform stellt ein System bereit, das eine Schaltung umfasst (d.h. eine beliebige Hardware, die in geeigneter Weise, zum Beispiel durch Software, konfiguriert ist), um jeden Schritt des vorstehend beschriebenen Verfahrens durchzuführen. Jedoch kann das System eine beliebige Anzahl und einen beliebigen Typ von Datenverarbeitungsmaschinen umfassen (zum Beispiel vom physischen und/oder virtuellen Typ) und es kann über eine beliebige Architektur verfügen (eigenständig oder verteilt, wobei die Datenverarbeitungsmaschinen untereinander über ein beliebiges lokales, Weitverkehrs-, globales, Mobilfunk- oder Satellitennetz Daten austauschen und einen beliebigen Typ von verdrahteten und/oder drahtlosen Verbindungen nutzen).
Im Allgemeinen gelten ähnliche Überlegungen, wenn das System eine andere Struktur hat oder gleichwertige Komponenten umfasst oder wenn es andere operative Merkmale hat. In jedem Fall kann jede Komponente davon in weitere Elemente aufgeteilt oder zwei oder mehr Komponenten können zu einem einzigen Element zusammengeführt werden; überdies kann jede Komponente repliziert werden, um die parallele Ausführung der entsprechenden Operationen zu unterstützen. Überdies, sofern nichts anderes angegeben ist, braucht jede beliebige Interaktion zwischen verschiedenen Komponenten im Allgemeinen nicht fortlaufend zu sein und sie kann entweder direkt oder indirekt durch einen oder mehrere Vermittler erfolgen.
Die hierin beschriebenen Programme werden auf der Grundlage der Anwendung angegeben, für die sie in einer speziellen Ausführungsform der Erfindung ausgeführt werden. Es ist jedoch darauf hinzuweisen, dass jedwede bestimmte Programm-Nomenklatur hierin lediglich aus Gründen der Zweckmäßigkeit verwendet wird, und somit sollte die Erfindung nicht auf eine ausschließliche Verwendung in einer speziellen Anwendung, die von dieser Nomenklatur angegeben und/oder durch diese Nomenklatur stillschweigend vorausgesetzt wird, beschränkt werden.
Ausführungsformen der Erfindung können Endbenutzern durch eine Cloud-Computing-Infrastruktur bereitgestellt werden. Cloud-Computing bezieht sich im Allgemeinen auf die als ein Dienst über ein Netz erfolgende Bereitstellung von skalierbaren Datenverarbeitungsressourcen. Formaler ausgedrückt, Cloud-Computing kann als eine Möglichkeit der Datenverarbeitung definiert werden, die eine Abstraktion zwischen der Datenverarbeitungsressource und ihrer zugrunde liegenden technischen Architektur (z.B. Server, Speicher, Netzwerke) bereitstellt, was einen komfortablen, bedarfsweisen Netzwerkzugriff auf einen gemeinsam genutzten Bestand an konfigurierbaren Datenverarbeitungsressourcen ermöglicht, die schnell bereitgestellt und mit minimalem Verwaltungsaufwand oder minimaler Interaktion eines Dienstanbieters freigegeben werden können. Folglich ermöglicht Cloud-Computing einem Nutzer den Zugriff auf virtuelle Datenverarbeitungsressourcen (z.B. Speicher, Daten, Anwendungen und sogar ganze virtualisierte Datenverarbeitungssysteme) in „der Cloud“, ohne Rücksicht auf die zugrunde liegenden physischen Systeme (oder Standorte dieser Systeme), die zur Bereitstellung der Datenverarbeitungsressourcen verwendet werden.
Üblicherweise werden Cloud-Computing-Ressourcen einem Nutzer nutzungsorientiert bereitgestellt, wobei Nutzern nur die tatsächlich verwendeten Datenverarbeitungsressourcen berechnet werden (z.B. durch einen Nutzer verbrauchter Speicherplatz oder eine Anzahl von virtualisierten, durch den Nutzer instanziierten Systemen). Ein Nutzer kann jederzeit und von überall über das Internet auf beliebige der Ressourcen zugreifen, die sich in der Cloud befinden. Im Kontext der vorliegenden Erfindung kann ein Nutzer auf eine normierte Suchmaschine oder zugehörige, in der Cloud vorhandene Daten zugreifen. Zum Beispiel könnte die normierte Suchmaschine auf einem Datenverarbeitungssystem in der Cloud ausgeführt werden und normierte Suchen ausführen. In einem solchen Fall könnte die normierte Suchmaschine einen Korpus von Informationen normieren und einen Index der Normierungen an einer Speicherposition in der Cloud speichern. Dadurch wird einem Nutzer ermöglicht, von einem beliebigen Datenverarbeitungssystem aus, das an ein mit der Cloud verbundenes Netzwerk (z.B. das Internet) angeschlossen ist, auf diese Informationen zugreifen.
Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Vielmehr können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen weiteren Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerken, Netzwerkbandbreite, Servern, Verarbeitung, Hauptspeichern, Speichern, Anwendungen, virtuellen Maschinen und Services), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften umfassen, mindestens drei Servicemodelle und mindestens vier Implementierungsmodelle.
Bei den Eigenschaften handelt es sich um die folgenden:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für den Typ von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.

Bei den Servicemodellen handelt es sich um die folgenden:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Bei den Einsatzmodellen handelt es sich um die folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten aufweist.

Unter Bezugnahme auf 5 ist ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch den Cloud-Computing-Provider 205 (wie in 2 gezeigt) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 5 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:

Eine Hardware- und Softwareschicht 560 umfasst Hardware- und Softwarekomponenten. Zu Beispielen für Hardwarekomponenten gehören: Mainframe-Computer 561; auf der RISC- (Reduced Instruction Set Computer) Architektur beruhende Server 562; Server 563; Blade-Server 564; Speichereinheiten 565; und Netzwerke sowie Netzwerkkomponenten 566. In einigen Ausführungsformen umfassen Softwarekomponenten eine Netzwerk-Anwendungsserver-Software 567 und eine Datenbanksoftware 568.

Eine Virtualisierungsschicht 570 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 571; virtueller Speicher 572, zum Beispiel die Datenspeichereinheit 240, wie in 1 gezeigt; virtuelle Netzwerke 573, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 574; und virtuelle Clients 575.
In einem Beispiel kann eine Verwaltungsschicht 580 die nachstehend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 581 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 582 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungssoftwarelizenzen umfassen. Eine Sicherheit stellt die Identitätsprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 583 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 584 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 585 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
Eine Arbeitslastschicht 590 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 591; Software-Entwicklung und Lebenszyklusverwaltung 592; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 593; Datenanalytikverarbeitung 594; Transaktionsverarbeitung 595; und Ressourcenverwaltung 596. Die Ressourcenverwaltung 596 kann Ressourcen unter Softwarekomponenten zuordnen.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen Integrationsstufe technischer Details handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine auswechselbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein auswechselbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übermittelte elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmwareanweisungen, zustandssetzende Daten, Konfigurationsdaten für eine integrierte Schaltung oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch einen beliebigen Typ Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel durch das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field-programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder in den Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Abschnitt von Anweisungen darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Ausführung der festgelegten logischen Funktion(en) aufweist. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit als ein Schritt durchgeführt, gleichzeitig ausgeführt, im Wesentlichen gleichzeitig ausgeführt, in einer sich teilweise oder ganz zeitlich überlappenden Weise ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung erfolgten zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Änderungen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt befindlichen Technologien am besten zu erklären bzw. um anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

Verfahren zur Ressourcenverwaltung einer Softwareanwendung, die eine Mehrzahl von Softwarekomponenten aufweist, welche miteinander interagieren, wobei das Verfahren umfasst: Überwachen, durch ein Datenverarbeitungssystem, von entsprechenden derzeitigen Zuständen der Mehrzahl von Softwarekomponenten; Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, von entsprechenden zukünftigen Verbräuchen von einer oder mehreren Datenverarbeitungsressourcen, von denen jeder einen zukünftigen Wert eines Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt, wobei die zukünftigen Verbräuche der Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten gemäß mindestens einem Schätzmodell geschätzt werden; und Steuern, durch das Datenverarbeitungssystem, einer Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten gemäß den entsprechenden zukünftigen Verbräuchen.
Verfahren nach Anspruch 1, wobei das Verfahren umfasst: Überwachen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des derzeitigen Zustands der Softwarekomponente, die entsprechende derzeitige Metriken von einer oder mehreren Arbeitslastmetriken der Softwarekomponente aufweist, von denen jede einen derzeitigen Wert der entsprechenden Arbeitslastmetrik angibt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das mindestens eine Schätzmodell ein Anwendungsmodell der Softwareanwendung und entsprechende Komponentenmodelle der Mehrzahl von Softwarekomponenten aufweist, wobei das Verfahren umfasst: Schätzen, durch das Datenverarbeitungssystem, von entsprechenden zukünftigen Zuständen der Mehrzahl von Softwarekomponenten, wobei der zukünftige Zustand einer jeden der Softwarekomponenten anhand der derzeitigen Zustände der Softwarekomponenten gemäß dem Anwendungsmodell geschätzt wird; und Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, der zukünftigen Verbräuche der Softwarekomponente anhand des zukünftigen Zustands der Softwarekomponente gemäß dem Komponentenmodell der Softwarekomponente.
Verfahren nach Anspruch 3, wobei das Verfahren umfasst: Lesen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des Komponentenmodells aus einem Manifest der Softwarekomponente.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren umfasst: Messen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, von entsprechenden derzeitigen Verbräuchen der Datenverarbeitungsressourcen, von denen jeder einen derzeitigen Wert des Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt; Berechnen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, von entsprechenden Schätzfehlern der Datenverarbeitungsressourcen, wobei der Schätzfehler einer jeden der Datenverarbeitungsressourcen gemäß dem derzeitigen Verbrauch und einem bisherigen zukünftigen Verbrauch geschätzt wird, der aus dem bisher geschätzten zukünftigen Verbrauch besteht; und weiteres Steuern, durch das Datenverarbeitungssystem, der Zuordnung der Datenverarbeitungsressourcen zu der Mehrzahl von Softwarekomponenten gemäß den entsprechenden Schätzfehlern.
Verfahren nach Anspruch 5, wobei das Verfahren umfasst: Verfeinern, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des zukünftigen Verbrauchs einer jeden der Datenverarbeitungsressourcen gemäß dem Schätzfehler der Datenverarbeitungsressource.
Verfahren nach Anspruch 6, wobei das Verfahren umfasst: Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, der zukünftigen Verbräuche der Datenverarbeitungsressourcen, die entsprechende zukünftige Basisverbräuche, zukünftige Minimum-Verbräuche und zukünftige Maximum-Verbräuche aufweisen, wobei der zukünftige Basisverbrauch, der zukünftige Minimum-Verbrauch und der zukünftige Maximum-Verbrauch einer jeden der Datenverarbeitungsressourcen eine Basis, ein Minimum bzw. ein Maximum des zukünftigen Werts des Verbrauchs der entsprechenden Datenverarbeitungsressource angibt; Berechnen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, der Schätzfehler, die entsprechende Verbrauchsfehler aufweisen; wobei der Verbrauchsfehler einer jeden der Datenverarbeitungsressourcen gemäß einer Differenz zwischen dem derzeitigen Verbrauch der Datenverarbeitungsressource und einem bisherigen zukünftigen Verbrauch der Datenverarbeitungsressource berechnet wird, der aus dem bisher geschätzten zukünftigen Basisverbrauch der Datenverarbeitungsressource besteht; und Verfeinern, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des zukünftigen Minimum-Verbrauchs und des zukünftigen Maximum-Verbrauchs einer jeden der Datenverarbeitungsressourcen gemäß dem zukünftigen Basisverbrauch und dem Verbrauchsfehler der Datenverarbeitungsressource.
Verfahren nach Anspruch 7, wobei das Verfahren umfasst: Einstellen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des zukünftigen Minimum-Verbrauchs einer jeden der Datenverarbeitungsressourcen auf ein Minimum zwischen dem zukünftigen Minimum-Verbrauch und dem zukünftigen Basisverbrauch abzüglich des Verbrauchsfehlers der Datenverarbeitungsressource; und Einstellen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des zukünftigen Maximum-Verbrauchs einer jeden der Datenverarbeitungsressourcen auf ein Maximum zwischen dem zukünftigen Maximum-Verbrauch und dem zukünftigen Basisverbrauch zuzüglich des Verbrauchsfehlers der Datenverarbeitungsressource.
Verfahren nach Anspruch 5, wobei das Verfahren umfasst: Auslösen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des Steuerns der Zuordnung einer jeden der Datenverarbeitungsressourcen gemäß einem Vergleich des zukünftigen Verbrauchs der Datenverarbeitungsressource mit einem oder mehreren entsprechenden Prüfgrenzwerten auf der Grundlage des Schätzfehlers der Datenverarbeitungsressource.
Verfahren nach Anspruch 9, wobei das Verfahren umfasst: Überwachen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des derzeitigen Zustands der Softwarekomponente, die entsprechende derzeitige Metriken von einer oder mehreren Arbeitslastmetriken der Softwarekomponente aufweist, von denen jede einen derzeitigen Wert der entsprechenden Arbeitslastmetrik angibt; Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, von entsprechenden zukünftigen Metriken für die Arbeitslastmetriken, von denen jede einen zukünftigen Wert der entsprechenden Arbeitslastmetrik der Softwarekomponente angibt, wobei die zukünftige Metrik einer jeden der Arbeitslastmetriken der Softwarekomponente anhand der derzeitigen Metriken der Arbeitslastmetrik der Softwarekomponenten gemäß dem mindestens einen Schätzmodell geschätzt wird; Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, für jede der Datenverarbeitungsressourcen von entsprechenden teilweisen zukünftigen Verbräuchen für die Arbeitslastmetriken, wobei der teilweise zukünftige Verbrauch einer jeden der Arbeitslastmetriken anhand einer bisherigen zukünftigen Metrik der Arbeitslastmetrik geschätzt wird, die aus der zukünftigen Metrik der bisher geschätzten Arbeitslastmetrik und den derzeitigen Metriken von beliebigen anderen Arbeitslastmetriken gemäß dem mindesten einen Schätzmodell geschätzt wird; Berechnen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des Schätzfehlers einer jeden der Datenverarbeitungsressourcen, der entsprechende Metrikfehler für die Arbeitslastmetriken umfasst; wobei der Metrikfehler einer jeden der Arbeitslastmetriken gemäß einer Differenz zwischen dem derzeitigen Verbrauch der Datenverarbeitungsressource und dem teilweisen zukünftigen Verbrauch der Arbeitslastmetrik für die Datenverarbeitungsressource berechnet wird; und Einstellen, durch das Datenverarbeitungssystem für jede der Softwarekomponenten, der Prüfgrenzwerte einer jeden der Datenverarbeitungsressourcen gemäß den Metrikfehlern der Datenverarbeitungsressource.
Verfahren nach Anspruch 10, wobei das Verfahren umfasst: Schätzen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, der zukünftigen Verbräuche der Datenverarbeitungsressourcen, die entsprechende zukünftige Minimum-Verbräuche und zukünftige Maximum-Verbräuche aufweisen, wobei der zukünftige Minimum-Verbrauch und der zukünftige Maximum-Verbrauch einer jeden der Datenverarbeitungsressourcen ein Minimum bzw. ein Maximum des zukünftigen Werts des Verbrauchs der entsprechenden Datenverarbeitungsressource angibt; und Auslösen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des Steuerns der Zuordnung einer jeden der Datenverarbeitungsressourcen als Reaktion darauf, dass der zukünftige Minimum-Verbrauch der Datenverarbeitungsressource niedriger als ein niedriger der Prüfgrenzwerte und der zukünftige Maximum-Verbrauch der Datenverarbeitungsressource höher als ein hoher der Prüfgrenzwerte ist, welcher höher als der niedrige Prüfgrenzwert ist.
Verfahren nach Anspruch 11, wobei das Verfahren umfasst: Einstellen, durch das Datenverarbeitungssystem für jede der Mehrzahl von Softwarekomponenten, des niedrigen Prüfgrenzwerts und des hohen Prüfgrenzwerts einer jeden der Datenverarbeitungsressourcen auf eine Summe von Arbeitslastmetriken der Datenverarbeitungsressource, multipliziert mit einem niedrigen Skalierungsfaktor bzw. einem hohen Skalierungsfaktor, wobei der hohe Skalierungsfaktor höher als der niedrige Skalierungsfaktor ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Softwareanwendung eine Cloud-Softwareanwendung ist und die Mehrzahl von Softwarekomponenten entsprechende Services ausführen.
Computerprogrammprodukt zur Ressourcenverwaltung einer Softwareanwendung, die eine Mehrzahl von Softwarekomponenten aufweist, welche miteinander interagieren, wobei das Computerprogrammprodukt aufweist: ein oder mehrere durch einen Computer lesbare, greifbare Speichermedien und Programmanweisungen, die auf mindestens einem Speichermedium des einen oder der mehreren greifbaren Speichermedien gespeichert sind, wobei die Programmanweisungen durch ein Datenverarbeitungssystem ausführbar sind, um das Datenverarbeitungssystem dazu zu veranlassen, ein Verfahren durchzuführen, das umfasst: Überwachen von entsprechenden derzeitigen Zuständen der Mehrzahl von Softwarekomponenten; Schätzen, für jede der Mehrzahl von Softwarekomponenten, von entsprechenden zukünftigen Verbräuchen von einer oder mehreren Datenverarbeitungsressourcen, von denen jede einen zukünftigen Wert eines Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt, wobei die zukünftigen Verbräuche der Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten gemäß mindestens einem Schätzmodell geschätzt werden; und Steuern einer Zuordnung der Datenverarbeitungsressourcen zu der Mehrzahl von Softwarekomponenten gemäß den entsprechenden zukünftigen Verbräuchen.
System zur Ressourcenverwaltung einer Softwareanwendung, die eine Mehrzahl von Softwarekomponenten aufweist, welche miteinander interagieren, wobei das System aufweist: eine Überwachungsfunktion, um entsprechende derzeitige Zustände der Softwarekomponenten zu überwachen; eine Schätzfunktion, um für jede der Softwarekomponenten entsprechende zukünftige Verbräuche von einer oder mehreren Datenverarbeitungsressourcen zu schätzen, von denen jeder einen zukünftigen Wert eines Verbrauchs der entsprechenden Datenverarbeitungsressource durch die Softwarekomponente angibt, wobei die zukünftigen Verbräuche der Softwarekomponente anhand der derzeitigen Zustände der Softwarekomponenten gemäß mindestens einem Schätzmodell geschätzt werden; und eine Steuerfunktion, um eine Zuordnung der Datenverarbeitungsressourcen zu den Softwarekomponenten gemäß den entsprechenden zukünftigen Verbräuchen zu steuern.