DE112021004290B4

DE112021004290B4 - Gemeinsames nutzen von zwischengespeicherten klassendaten in einer containerisierten umgebung

Info

Publication number: DE112021004290B4
Application number: DE112021004290.4T
Authority: DE
Inventors: Anyang Yu; Dhruv Chopra; Alen Badel; Vijay Sundaresan; Marius Pirvu; Michael Dawson; Daniel Heidinga
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-09-23
Filing date: 2021-07-20
Publication date: 2024-07-11
Anticipated expiration: 2041-07-21
Also published as: WO2022062613A1; GB2614157A; CN116171425A; US11188354B1; JP2023542673A; GB202303787D0; DE112021004290T5; GB2614157B

Abstract

Durch einen Computer umgesetztes Verfahren zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten, wobei das Verfahren aufweist:Initiieren (S255) eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung;Empfangen (S255) von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein der verwalteten Laufzeitanwendung zugehöriges Argument und eine Arbeitsknotenkennung umfasst, die einem Arbeitsknoten, worker node, entspricht, der der verwalteten Laufzeitanwendung zugehörig ist;Lokalisieren (S260) eines ersten Zwischenspeichers für gemeinsam genutzte Klassen, SCC, der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch einen Server verwaltet wird;in Reaktion auf ein Lokalisieren (S260) des ersten SCCs:Senden (S260) des ersten SCCs an einen Client (104), der dem Arbeitsknoten zugehörig ist, undSpeichern (S265) des ersten SCCs in einem lokalen SCC-Repository;Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden;Bestimmen (S275), die erste Aktualisierungsanforderung zu akzeptieren; undin Reaktion auf ein Akzeptieren (S275) der ersten Aktualisierungsanforderung:Analysieren (S285) einer Mehrzahl von Aktualisierungsanforderungen, einschließlich der ersten Aktualisierungsanforderung, um analysierte Aktualisierungsanforderungsdaten zu erstellen,Bestimmen (S285), auf Grundlage der analysierten Aktualisierungsanforderungsdaten, dass die analysierten Aktualisierungsanforderungsdaten neue Daten umfassen, die mehr als einer Aktualisierungsanforderung der Mehrzahl von Aktualisierungsanforderungen gemeinsam sind, undModifizieren (S290) des ersten SCCs auf Grundlage der neuen Daten, um einen zweiten SCC zu generieren.

Description

HINTERGRUND
Die vorliegende Erfindung betrifft allgemein das Gebiet von Datenverarbeitung in großem Umfang und insbesondere Datenverarbeitungsumgebungen von „Platform as a Service“ mit mehreren isolierten Benutzerbereichen, die manchmal als „Container“ bezeichnet werden.
In einer Datenverarbeitungsumgebung „Platform as a Service“ sind Benutzerbereiche durch Verwenden einer Virtualisierung voneinander isoliert, die auf Betriebssystemebene umgesetzt ist.
In einigen dynamischen Sprach-Datenverarbeitungsumgebungen führen Anwendungen während der Laufzeit eine Just-in-Time- (JIT) Kompilierung durch, und Klassendateien, die schreibgeschützte Klassendaten und Ahead-of-Time- (AOT) kompilierten Code enthalten, der ausgeführt werden soll, werden nach Bedarf geladen. Einige Systeme verwenden einen Zwischenspeicherungsmechanismus, in den beim Anwendungsstart die erforderlichen Klassen schnell aus der dem Arbeitsspeicher zugeordneten Datei (dem im RAM befindlichen Zwischenspeicher (Cache) für gemeinsam genutzte Klassen) geladen werden, während die JIT-Kompilierung zwischengespeicherte AOT-kompilierte Teile schnell lädt.
MANTON, Y.: The multi-layer shared dass cache for Docker. Veröffentlicht am 05.11.2019. URL: https://blog.openj9.org/2019/11/05/the-multi-layer-shared-class-cachefor-docker/ [abgerufen am 06.03.2024] beschreibt das Feature der mehrschichtigen Shared Class Caches (SCCs) in Eclipse OpenJ9, das für Docker-Images konzipiert wurde. Die Fähigkeit des Shared Class Cache ist einer der Hauptgründe, warum OpenJ9 schneller starten kann und weniger Speicher verbraucht, insbesondere wenn mehrere Java Virtual Machines (JVMs) gleichzeitig laufen.
US 2012 / 0 272 239 A1 beschreibt Techniken für das Teilen von Java-Klasseninformationen in virtualisierten Computerumgebungen.
KURZDARSTELLUNG DER ERFINDUNG
Gemäß einem Aspekt der vorliegenden Erfindung liegt ein Verfahren, ein Computerprogrammprodukt und/oder ein System zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten vor, das die folgenden Operationen (nicht notwendigerweise in der nachstehenden Reihenfolge) durchführt, (i) Initiieren eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung; (ii) Empfangen von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein Argument, das der verwalteten Laufzeitanwendung zugehörig ist, und eine Arbeitsknotenkennung umfassen, die einem Arbeitsknoten (worker node) entspricht, der der verwalteten Laufzeitanwendung zugehörig ist; (iii) Lokalisieren eines ersten Zwischenspeichers für gemeinsam genutzte Klassen (SCC), der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch einen Server verwaltet wird; und (iv) in Reaktion auf ein Lokalisieren des ersten SCCs: (a) Senden des ersten SCCs an einen Client, der dem Arbeitsknoten zugehörig ist, und (b) Speichern des ersten SCCs in einem lokalen SCC-Repository; (v) Empfangen, von dem Client, einer ersten Aktualisierungsanforderung, die einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden; (vi) Bestimmen, die erste Aktualisierungsanforderung zu akzeptieren; und (vii) in Reaktion auf ein Akzeptieren der ersten Aktualisierungsanforderung: (a) Analysieren einer Mehrzahl von Aktualisierungsanforderungen, einschließlich der ersten Aktualisierungsanforderung, um analysierte Aktualisierungsanforderungsdaten zu erstellen, (b) Bestimmen, auf Grundlage der analysierten Aktualisierungsanforderungsdaten, dass die analysierten Aktualisierungsanforderungsdaten neue Daten umfassen, die mehr als einer Aktualisierungsanforderung der Mehrzahl von Aktualisierungsanforderungen gemeinsam sind, und (c) Modifizieren des ersten SCCs auf Grundlage der neuen Daten, um einen zweiten SCC zu generieren.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung liegt ein Verfahren, ein Computerprogrammprodukt und/oder ein System zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten vor, das die folgenden Operationen (nicht notwendigerweise in der nachstehenden Reihenfolge) durchführt: (i) Initiieren eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung; (ii) Empfangen von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein Argument, das der verwalteten Laufzeitanwendung zugehörig ist, und eine Arbeitsknotenkennung umfassen, die einem Arbeitsknoten entspricht, der der verwalteten Laufzeitanwendung zugehörig ist; (iii) Lokalisieren eines ersten Zwischenspeichers für gemeinsam genutzte Klassen (SCC), der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch einen Server verwaltet wird; und (iv) in Reaktion auf ein Lokalisieren des ersten SCCs: (a) Senden des ersten SCCs an einen Client, der dem Arbeitsknoten zugehörig ist, und (b) Speichern des ersten SCCs in einem lokalen SCC-Repository; (v) Empfangen, von dem Client, einer ersten Aktualisierungsanforderung, die von der verwalteten Laufzeitanwendung stammt und dem ersten SCC zugehörig ist, wobei die erste Aktualisierungsanforderung einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden; (vi) Bestimmen, die erste Aktualisierungsanforderung abzulehnen; und (vii) in Reaktion auf ein Ablehnen der ersten Aktualisierungsanforderung an den Client einen zweiten SCC senden.
Die Erfindung wird durch die Merkmale der unabhängigen Ansprüche beschrieben. Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 stellt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung dar;
2 stellt Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung dar;
3 ist ein Blockschaubild eines Systems gemäß mindestens einer Ausführungsform der vorliegenden Erfindung;
4 ist ein Ablaufplan, der ein Verfahren zeigt, das zumindest teilweise gemäß mindestens einer Ausführungsform der vorliegenden Erfindung durchgeführt wird;
5 ist ein Blockschaubild, das einen Abschnitt einer Maschinenlogik (zum Beispiel Software) eines Systems gemäß mindestens einer Ausführungsform der vorliegenden Erfindung zeigt;
6 ist ein Blockschaubild, das einige Komponenten eines Systems gemäß mindestens einer Ausführungsform der vorliegenden Erfindung zeigt; und
7 ist ein Blockschaubild, das einen Informationsfluss zwischen verschiedenen Systemkomponenten gemäß mindestens einer Ausführungsform der vorliegenden Erfindung zeigt.

AUSFÜHRLICHE BESCHREIBUNG
Ein Container-Orchestrator weist gemäß einigen Ausführungsformen der vorliegenden Erfindung ein Subsystem eines Orchestrators für ein gemeinsames Nutzen von Klassen (CSO) auf. Der CSO verwaltet ein gemeinsames Nutzen von Klassendaten zwischen containerisierten Anwendungen in einer Cloud-Umgebung, um eine Anwendungs-Startleistung, eine Inanspruchnahme der CPU und einen Arbeitsspeicherbedarf zu verbessern. Ein Zwischenspeicher für gemeinsam genutzte Klassen erlaubt mehreren virtuellen Maschinen, die isoliert voneinander arbeiten, einen einzelnen Zwischenspeicher gemeinsam zu nutzen, der hierin als „Zwischenspeicher für gemeinsam genutzte Klassen (shared dass cache)“ (SCC) bezeichnet wird, der Anwendungsklassendaten enthält. Ein Zwischenspeicher für Klassen, der als eine dem Arbeitsspeicher zugeordnete Datei konfiguriert ist, speichert drei Informationsteile: (1) den unveränderlichen Teil der Klassen, (2) Ahead-of-Time- (AOT) kompilierten Code und (3) Profilerstellungsdaten.
Dieser Abschnitt „Ausführliche Beschreibung“ ist in die folgenden Unterabschnitte gegliedert: (i) Die Hardware- und Software-Umgebung; (ii) Beispielhafte Ausführungsform; (iii) Weitere Kommentare und/oder Ausführungsformen; und (iv) Definitionen.
I. DIE HARDWARE- UND SOFTWARE-UMGEBUNG
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen technischen Detailintegrationsebene handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen enthalten, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine konkrete Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zum Ausführen von Anweisungen beibehalten und speichern kann. Das durch einen Computer lesbare Speichermedium kann zum Beispiel eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiter-Speichereinheit oder jede geeignete Kombination aus dem Vorgenannten sein, es ist aber nicht darauf beschränkt. Zu einer nicht erschöpfenden Liste von spezifischeren Beispielen des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare 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 tragbarer CD-ROM, eine DVD, ein Arbeitsspeicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination des Vorgenannten. Ein durch einen Computer lesbares Speichermedium soll, wie hierin verwendet, 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 andere Übertragungsmedien ausbreiten (z.B. durch ein Lichtwellenleiterkabel geleitete Lichtimpulse) oder durch einen Draht übertragene 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 Weitverkehrsnetzwerk 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 Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben sind, 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 Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In dem letzteren Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch jeden Typ von Netzwerk verbunden werden, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann zu einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, feldprogrammierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Veranschaulichungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es sollte klar sein, dass jeder Block der Ablaufplanveranschaulichungen und/oder der Blockschaubilder und Kombinationen von Blöcken in den Ablaufplanveranschaulichungen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen umgesetzt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können für einen Prozessor eines Computers oder eine andere programmierbare Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. eine andere programmierbare Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Schritte erstellen. 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, sodass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen 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 Arbeitsschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen durch einen Computer umgesetzten Prozess zu erzeugen, sodass 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 Blockschaubilder angegebenen Funktionen/Schritte umsetzen.
Die Ablaufpläne und Blockschaubilder 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 den Ablaufplänen oder den Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zum Umsetzen der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Umsetzungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt auftreten. Zum Beispiel können zwei nacheinander gezeigte Blöcke tatsächlich als ein Schritt erreicht werden, der gleichzeitig, im Wesentlichen gleichzeitig, in einer teilweise oder vollständig zeitlich überlappenden Weise ausgeführt wird, oder die Blöcke können manchmal in der umgekehrten Reihenfolge ausgeführt werden, was von der beteiligten Funktionalität abhängt. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufplandarstellungen sowie Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplandarstellung durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die angegebenen Funktionen oder Handlungen durchführen oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud Computing enthält, sollte klar sein, dass die Umsetzung der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jedem beliebigen Typ von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung umgesetzt werden.
Cloud Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Nutzungsmodelle umfassen.
Die Eigenschaften sind wie folgt:
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 des Dienstes 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 die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Der Ressourcen-Verbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
Die Dienstmodelle sind wie folgt:
Software as a Service (SaaS): Die für den Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur ausgeführten Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. eine auf dem Web beruhende eMail) 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, Verarbeitung, 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 eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Die Nutzungsmodelle sind wie folgt:
Private Cloud: Die Cloud-Infrastruktur wird ausschließlich für eine Organisation betrieben. Sie kann von der Organisation oder einer Drittpartei verwaltet werden und kann innerhalb oder außerhalb von Geschäftsräumen vorhanden sein.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine bestimmte Community, die gemeinsame Problemstellungen hat (z.B. Berücksichtigung von Zielsetzung, Sicherheitsanforderungen, Richtlinien und Konformität). Sie kann von den Organisationen oder einer Drittpartei verwaltet werden und kann innerhalb oder außerhalb der Geschäftsräume vorhanden sein.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und gehört einer Organisation, die Cloud-Dienste verkauft.
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 eine Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert, wobei der Schwerpunkt auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität liegt. Im Mittelpunkt von Cloud Computing steht eine Infrastruktur, die ein Netzwerk von miteinander verbundenen Knoten enthält.
Unter folgender Bezugnahme auf 1 wird eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt, enthält die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen lokale Datenverarbeitungseinheiten, die von Nutzern der Cloud verwendet werden, wie beispielsweise Personal Digital Assistant (PDA) oder Mobiltelefon 54A, Desktop-Computer 54B, Laptop-Computer 54C und/oder Fahrzeug-Computersystem 54N, Daten austauschen können. Die Knoten 10 können untereinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken gruppiert sein (nicht gezeigt), wie beispielsweise Private, Community, Public oder Hybrid Cloud, wie hierin oben beschrieben, oder in einer Kombination davon. Damit hat die Cloud-Computing-Umgebung 50 die Möglichkeit, eine Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keinerlei Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sollte klar sein, dass die in 1 gezeigten Typen von Datenverarbeitungseinheiten 54A bis 54N nur zur Veranschaulichung dienen sollen, und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 mit jedem Typ einer computerisierten Einheit über jeden Typ von Netzwerk und/oder eine über ein Netzwerk adressierbare Verbindung (z.B. unter Verwendung eines Web-Browsers) Daten austauschen können.
Unter folgender Bezugnahme auf 2 wird eine Gruppe von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (1) bereitgestellt werden. Dabei sollte von Anfang an klar sein, dass die in 2 gezeigten Komponenten, Schichten und Funktionen lediglich zur Veranschaulichung dienen sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten zählen: Mainframes 61; Server auf Grundlage einer RISC- (Reduced Instruction Set Computer) Architektur 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke und vernetzte Komponenten 66. In einigen Ausführungsformen enthalten Software-Komponenten Software für Netzwerkanwendungsserver 67 und Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, von der aus die folgenden Beispiele für virtuelle Entitäten bereitgestellt werden können: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73, einschließlich virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; virtuelle Clients 75; und Orchestrator 76 für gemeinsames Nutzen von Klassen.
In einem Beispiel kann eine Verwaltungsschicht 80 die im Folgenden beschriebenen Funktionen bereitstellen. Eine Ressourcenbereitstellung 81 sorgt für eine dynamische Beschaffung von Datenverarbeitungsressourcen und weiteren Ressourcen, die zum Ausführen von Aufgaben innerhalb der Cloud-Computing-Umgebung eingesetzt werden. Messung und Preisbestimmung 82 ermöglichen beim Einsatz von Ressourcen innerhalb der Cloud-Computing-Umgebung eine Kostenverfolgung und eine Abrechnung oder Rechnungsstellung für die Inanspruchnahme dieser Ressourcen. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware umfassen. Eine Sicherheitsfunktion stellt eine Identitätsprüfung für Cloud-Nutzer und -Aufgaben sowie einen Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt den Zugang zur Cloud-Computing-Umgebung für Nutzer und Systemadministratoren bereit. Eine Service-Level- (Dienstgüte) Verwaltung 84 sorgt für Zuweisung und Verwaltung von Cloud-Computing-Ressourcen, sodass erforderliche Service-Levels eingehalten werden. Planung und Vertragserfüllung des Service Level Agreement (SLA) (Dienstgütevereinbarung) 85 stellen eine Vorab-Vereinbarung für und Beschaffung von Cloud-Computing-Ressourcen bereit, für die gemäß eines SLA eine zukünftige Anforderung erwartet wird.
Eine Arbeitslastenschicht 90 stellt Beispiele für eine Funktionalität bereit, für welche die Cloud-Computing-Umgebung genutzt werden kann. Zu Beispielen von Arbeitslasten und Funktionen, die von dieser Schicht aus bereitgestellt werden können, zählen: Zuordnung und Navigation 91; Software-Entwicklung und Lifecycle-Management 92; Bereitstellung von virtuellen Schulungen 93; Datenanalyseverarbeitung 94; und Transaktionsverarbeitung 95.
Eine Ausführungsform einer möglichen Hardware- und Software-Umgebung für Software und/oder Verfahren gemäß der vorliegenden Erfindung wird im Folgenden ausführlich unter Bezugnahme auf die Figuren beschrieben. 3 ist ein funktionales Blockschaubild, das verschiedene Abschnitte eines Systems 100 von vernetzten Computern veranschaulicht, das umfasst: ein Container-Orchestratorsubsystem 102; ein Client-Computersubsystem 104; ein Datenübertragungsnetzwerk 114; einen Server-Computer 200; eine Datenübertragungseinheit 202; einen Prozessorsatz 204; einen Eingabe/Ausgabe- (E/A) Schnittstellensatz 296; einen Arbeitsspeicher 208; einen persistenten Speicher 210; eine Anzeigeeinheit 212; externe Einheiten 214; einen Direktzugriffs-Arbeitsspeicher (RAM 230); einen Zwischenspeicher 232; und ein Container-Orchestratorprogramm 300.
Das Container-Orchestratorsubsystem 102 ist in vielerlei Hinsicht repräsentativ für das bzw. die verschiedenen Computersubsysteme in der vorliegenden Erfindung. Dementsprechend werden mehrere Abschnitte des Container-Orchestratorsubsystems 102 in den folgenden Absätzen erläutert.
Das Container-Orchestratorsubsystem 102 kann ein Laptop-Computer, ein Tablet-Computer, ein Netbook-Computer, ein Personal Computer (PC), ein Desktop-Computer, ein Personal Digital Assistant (PDA), ein Smartphone oder jede programmierbare elektronische Einheit sein, die zu einem Datenaustausch mit den Client-Subsystemen über das Datenübertragungsnetzwerk 114 fähig ist. Das Container-Orchestratorprogramm 300 ist eine Sammlung von durch eine Maschine lesbaren Anweisungen und/oder Daten, die zum Erstellen, Verwalten und Steuern bestimmter Software-Funktionen verwendet werden, die im Folgenden ausführlich im Unterabschnitt „Beispielhafte Ausführungsform“ dieses Abschnitts „Ausführliche Beschreibung“ erläutert werden.
Das Container-Orchestratorsubsystem 102 ist fähig, mit anderen Computer-Subsystemen über das Datenübertragungsnetzwerk 114 Daten auszutauschen. Das Datenübertragungsnetzwerk 114 kann zum Beispiel ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN) wie das Internet oder eine Kombination aus beiden sein und kann drahtgebundene, drahtlose oder Lichtwellenleiter-Verbindungen umfassen. Im Allgemeinen kann das Datenübertragungsnetzwerk 114 jede Kombination von Verbindungen und Protokollen sein, die Datenübertragungen zwischen einem Server und Client-Subsystemen unterstützen.
Das Container-Orchestratorsubsystem 102 wird als Blockschaubild mit vielen Doppelpfeilen gezeigt. Diese Doppelpfeile (keine separaten Bezugszeichen) stellen eine Datenübertragungsstruktur dar, die Datenübertragungen zwischen verschiedenen Komponenten des Container-Orchestratorsubsystems 102 bereitstellt. Diese Datenübertragungsstruktur kann mit jeder Architektur umgesetzt werden, die für ein Übergeben von Daten und/oder Steuerinformationen zwischen Prozessoren (wie Mikroprozessoren, Datenübertragungs- und Netzwerkprozessoren usw.), Systemarbeitsspeichern, Peripherie-Einheiten und jeden anderen Hardware-Komponenten in einem System ausgelegt ist. Zum Beispiel kann die Datenübertragungsstruktur zumindest teilweise mit einem oder mehreren Bussen umgesetzt werden.
Der Arbeitsspeicher 208 und der persistente Speicher 210 sind durch einen Computer lesbare Speichermedien. Im Allgemeinen kann der Arbeitsspeicher 208 jedes geeignete flüchtige oder nicht flüchtige, durch einen Computer lesbare Speichermedium enthalten. Ferner wird angemerkt, dass jetzt und/oder in naher Zukunft: (i) externe Einheiten 214 fähig sein können, einen Teil oder den gesamten Arbeitsspeicher für das Container-Orchestratorsubsystem bereitzustellen; und/oder (ii) Einheiten außerhalb des Container-Orchestratorsubsystems 102 fähig sein können, Arbeitsspeicher für das Container-Orchestratorsubsystem 102 bereitzustellen.
Das Container-Orchestratorprogramm 300 wird im persistenten Speicher 210 für einen Zugriff auf und/oder eine Ausführung durch einen oder mehrere der jeweiligen Computerprozessorsätze 204 gespeichert, in der Regel über einen oder mehrere Arbeitsspeicher des Arbeitsspeichers 208. Der persistente Speicher 210: (i) ist mindestens persistenter als ein Signal während der Übertragung; (ii) speichert das Programm (einschließlich seiner Soft-Logik und/oder Daten) auf einem konkreten Medium (wie beispielweise magnetischen oder optischen Bereichen); und (iii) ist wesentlich weniger persistent als der permanente Speicher. Alternativ kann ein Datenspeicher persistenter und/oder permanenter als der Speichertyp sein, der von dem persistenten Speicher 210 bereitgestellt wird.
Das Container-Orchestratorprogramm 300 kann durch eine Maschine lesbare und durchführbare Anweisungen und/oder wesentliche Daten umfassen (also den Typ von Daten, die in einer Datenbank gespeichert sind). In dieser bestimmten Ausführungsform umfasst der persistente Speicher 210 eine Magnetfestplatte. Um einige der möglichen Variationen zu nennen, kann der persistente Speicher 210 einen Solid-State-Festplattenspeicher, eine Halbleiter-Speichereinheit, einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen Flash-Speicher oder jedes andere durch einen Computer lesbare Speichermedium umfassen, das fähig ist, Programmanweisungen oder digitale Informationen zu speichern.
Die von dem persistenten Speicher 210 verwendeten Medien können auch entfernbar sein. Zum Beispiel kann eine entfernbare Festplatte für den persistenten Speicher 210 verwendet werden. Weitere Beispiele umfassen optische und magnetische Platten, USB-Sticks und Smart-Cards, die für einen Datentransfer in ein anderes durch einen Computer lesbares Speichermedium, das ebenfalls Teil des persistenten Speichers 210 ist, in ein Laufwerk eingesetzt werden.
Die Datenübertragungseinheit 202 sorgt in diesen Beispielen für Datenübertragungen mit anderen Datenverarbeitungssystemen oder -einheiten, die sich außerhalb des Container-Orchestratorsubsystems 102 befinden. In diesen Beispielen enthält die Datenübertragungseinheit 202 eine oder mehrere Netzwerk-Schnittstellenkarten. Die Datenübertragungseinheit 202 kann Datenübertragungen durch die Verwendung von physischen und/oder drahtlosen Datenübertragungsverbindungen bereitstellen. Alle hierin erörterten Software-Module können in eine persistente Speichereinheit (wie beispielsweise den persistenten Speicher 210) über eine Datenübertragungseinheit (wie beispielsweise die Datenübertragungseinheit 202) heruntergeladen werden.
Ein E/A-Schnittstellensatz 206 ermöglicht die Eingabe und Ausgabe von Daten mit anderen Einheiten, die mit dem Server-Computer 200 lokal in Datenaustausch verbunden sein können. Zum Beispiel stellt der E/A-Schnittstellensatz 206 eine Verbindung zu externen Einheiten 214 bereit. Die externen Einheiten 214 können Einheiten umfassen, wie zum Beispiel eine Tastatur, ein Tastenfeld, einen Berührungsbildschirm und/oder eine andere geeignete Eingabeeinheit. Die externen Einheiten 214 können auch tragbare, durch einen Computer lesbare Speichermedien umfassen, wie zum Beispiel USB-Sticks, tragbare optische oder Magnetplatten und Arbeitsspeicherkarten. Software und Daten, die zum Ausüben von Ausführungsformen der vorliegenden Erfindung verwendet werden, zum Beispiel das Container-Orchestratorprogramm 300, können auf derartigen tragbaren, durch einen Computer lesbaren Speichermedien gespeichert werden. In diesen Ausführungsformen kann die relevante Software insgesamt oder teilweise über die E/A-Schnittstelle 206 auf den persistenten Speicher 210 geladen werden (oder ist dazu nicht fähig). Der E/A-Schnittstellensatz 206 ist auch mit der Anzeigeeinheit 212 in Datenaustausch verbunden.
Die Anzeigeeinheit 212 stellt einen Mechanismus zum Anzeigen von Daten für einen Benutzer bereit und kann zum Beispiel ein Computermonitor oder ein Smartphone-Anzeigebildschirm sein.
Die hierin beschriebenen Programme werden auf Grundlage der Anwendung identifiziert, für die sie in einer bestimmten Ausführungsform der Erfindung umgesetzt werden. Es sollte jedoch klar sein, dass jede bestimmte Programm-Nomenklatur hierin aus rein praktischen Gründen verwendet wird, und die Erfindung somit nicht allein auf die Verwendung in einer bestimmten identifizierten Anwendung und/oder durch eine derartige Nomenklatur impliziert eingeschränkt sein soll.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zweck einer Veranschaulichung erstellt, sie sollen aber keineswegs erschöpfend oder auf die offenbarten Ausführungsformen eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, die nicht von dem Schutzumfang der beschriebenen Ausführungsformen abweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt gefundenen Technologien bestmöglich zu erklären oder es anderen Fachleuten zu ermöglichen, die hierin offenbarten Ausführungsformen zu verstehen.
II. BEISPIELHAFTE AUSFÜHRUNGSFORM
4 zeigt einen Ablaufplan 250, der ein Verfahren gemäß der vorliegenden Erfindung darstellt. 5 zeigt das Container-Orchestratorprogramm 300 zum Durchführen von mindestens einigen der Verfahrensoperationen des Ablaufplans 250. Dieses Verfahren und die zugehörige Software werden im Folgenden im Verlauf der nachstehenden Absätze unter umfassender Bezugnahme auf 4 (für die Blöcke der Verfahrens-Operationen) und 5 (für die Software-Blöcke) erläutert. Ein physischer Speicherplatz, an dem das Container-Orchestratorprogramm 300 von 5 gespeichert werden kann, befindet sich im persistenten Speicher 210 (siehe 3).
Die Verarbeitung beginnt mit einer Operation S255, in der das Container-Orchestratorprogramm 300 einen Start einer verwalteten Laufzeitanwendung in einem ersten Container einer containerisierten Umgebung initiiert. Ein Orchestratormodul für ein gemeinsames Nutzen von Klassen (CSO-Modul 310) des Container-Orchestratorprogramms 300 empfängt Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, eine Liste mit Argumenten, die an eine erste Instanz der verwalteten Laufzeitanwendung übergeben wird, und eine Arbeitsknotenkennung umfasst, die einem Arbeitsknoten entspricht, der die erste Instanz der verwalteten Laufzeitanwendung hostet.
Die Verarbeitung fährt mit einer Operation S260 fort, in der das Zwischenspeichermodul 312 für gemeinsam genutzte Klassen des Container-Orchestratorprogramms 300 ein zentrales SCC-Repository für einen Zwischenspeicher (SCC) für gemeinsam genutzte Klassen durchsucht, der für eine Verwendung durch die verwaltete Laufzeitanwendung geeignet ist. Eine Eignung beruht auf bestimmten Attributen, die der verwalteten Laufzeitanwendung zugehörig sind. Diese Attribute können eine Kennung, die dem Anwendungsabbild zugehörig ist, ein oder mehrere Argumente, die einem Start oder einer Operation der Anwendung zugehörig sind und/oder eine Kennung, die dem ersten Container zugehörig ist, umfassen.
Die Verarbeitung fährt mit einer Operation S265 fort, in der ein Client-Untermodul eines Orchestrators für ein gemeinsames Nutzen eines Zwischenspeichers (CSO-Client-Untermodul 316) des CSO-Moduls 310 des Container-Orchestratorprogramms 300 den Zwischenspeicher für gemeinsam genutzte Klassen lokal auf der verwalteten Laufzeitanwendung, also in dem ersten Container, speichert.
Die Verarbeitung fährt mit einer Operation S270 fort, in der das zentrale CSO-Server-Untermodul 314 eine Aktualisierungsanforderung von dem CSO-Client-Untermodul 316 empfängt (entsprechend der verwalteten Laufzeitanwendung oder jeder anderen Anwendung, die innerhalb oder außerhalb des ersten Containers ausgeführt wird).
Die Verarbeitung fährt mit einer Entscheidung S275 fort, in der das zentrale CSO-Server-Untermodul 314 bestimmt, ob die oben genannte empfangene Aktualisierungsanforderung in Bezug auf die Operation S270 akzeptiert oder abgelehnt werden soll. Wenn das zentrale CSO-Server-Untermodul 314 bestimmt, die Aktualisierungsanforderung abzulehnen (Entscheidung S275, Verzweigung „Ablehnen“), fährt die Verarbeitung mit einer Operation S280 fort, in der das zentrale CSO-Server-Untermodul 314 dem Anforderer (in diesem Fall dem CSO-Client-Untermodul 316) einen zweiten Zwischenspeicher für gemeinsam genutzte Klassen zur Verwendung durch die verwaltete Laufzeitanweisung sendet.
Wenn das zentrale CSO-Server-Untermodul 314 bestimmt, die Aktualisierungsanforderung zu akzeptieren (Entscheidung S275, Verzweigung „Akzeptieren“), fährt die Verarbeitung mit einer Operation S285 fort, in der das zentrale CSO-Server-Untermodul 314 die Aktualisierungsanforderung zusammen mit anderen Anforderungen (sofern vorhanden) speichert, die vorher empfangen und gespeichert worden sind.
Wenn eine Schwellenwertanzahl von Anforderungen angesammelt worden ist (oder ein anderes Auslöse-Ereignis eintritt), analysiert das zentrale CSO-Server-Untermodul 314 die Mehrzahl von angesammelten Aktualisierungsanforderungen. In der Ausführungsform von 4 bestimmt das zentrale CSO-Server-Untermodul 314, dass zwei oder mehr Aktualisierungsanforderungen mindestens einige allgemeine Daten gemeinsam nutzen. Hinweis: In einigen Ausführungsformen werden mehrere Aktualisierungsanforderungen, die demselben Anwendungstyp zugehörig sind, zusammen analysiert,
Die Verarbeitung fährt mit einer Operation S290 fort, in der das zentrale CSO-Server-Untermodul 314 in Reaktion auf das Bestimmen, dass zwei oder mehr Aktualisierungsanforderungen mindestens einige allgemeine Daten gemeinsam nutzen, die allgemeinen Daten zu dem ersten Zwischenspeicher für gemeinsam genutzte Daten hinzufügt, um einen zweiten Zwischenspeicher für gemeinsam genutzte Klassen zu generieren.
Die Verarbeitung fährt mit einer Operation S295 fort, in der das zentrale CSO-Server-Untermodul 314 nachfolgende Aktualisierungsanforderungen aus Bereitstellungen ablehnt, die dem ersten Zwischenspeicher für gemeinsam genutzte Klassen zugehörig sind.
III. WEITERE KOMMENTARE UND/ODER AUSFÜHRUNGSFORMEN
Einige Ausführungsformen der vorliegenden Erfindung würdigen einen oder mehrere der folgenden Fakten, potenziellen Probleme und/oder potenziellen Bereiche zur Verbesserung in Bezug auf den derzeitigen Stand der Technik hinsichtlich dynamischen Sprachumgebungen (zum Beispiel Java): (i) eine Just-in-Time- (JIT) Kompilierung kann Mehraufwand hinzufügen, der sich negativ auf die Leistung einer Anwendung auswirkt, insbesondere beim Hochfahren, wenn der überwiegende Teil der JIT-Kompilierung stattfindet; (ii) die JIT-Kompilierung kann eine schnelles Hochfahren und Anlaufen der Anwendung behindern; und/oder (iii) in Fällen, in denen Klassendateien auf Anforderung geladen werden, kann für Anwendungen mit einer großen Anzahl von zu ladenden Klassen das Laden von Klassen erheblich zu einem Verlangsamen des Hochfahrens der Anwendung beitragen.
In einigen Ausführungsformen verweist der Begriff „Anwendung“ auf SoftwareProgramme, die auf einer virtuellen Maschine ausgeführt werden, die eine „Just-in-Time“-Kompilierung durchführen kann. Nicht erschöpfende Beispiele für derartige Anwendungen umfassen eine Web-Anwendung für den Aktienmarkt, die über Spring Boot erstellt wurde, und eine Web-Anwendung für Hotelbuchungen, die über Open Liberty erstellt wurde. Spring Boot und Open Liberty werden auf einer virtuellen Java-Maschine ausgeführt.
Zwar wird hierin auf bestimmte Produkte Bezug genommen (zum Beispiel „Java“, „OpenJ9“, und „JVM“), doch sind Ausführungsformen der vorliegenden Erfindung nicht auf derartige Produkte beschränkt. Einige Ausführungsformen gelten auch für andere dynamische Laufzeit-Anwendungen, die bestimmte Zwischenspeicherungsmechanismen verwenden, wie zum Beispiel den Zwischenspeicher für gemeinsam genutzte Klassen. (Hinweis: Die Begriffe „Spring Boot“, „Open Liberty“, „Java“, „Java Virtual Machine“, „OpenJ9“ und/oder „JVM“ können weltweit Markenrechten in verschiedenen Gerichtsbarkeiten unterliegen und werden hierin nur in Bezug auf die durch die Warenzeichen zutreffend benannten Produkte oder Dienste in dem Maße verwendet, als derartige Markenrechte vorhanden sind.)
Einige Ausführungsformen der vorliegenden Erfindung können ein bzw. einen oder mehrere der folgenden Merkmale, Eigenschaften und/oder Vorteile umfassen: (i) kontinuierliche Verbesserung des Zwischenspeichers von kompilierten Verfahren; (ii) Anwendung eines kontinuierlichen und inkrementellen Verbesserungsansatzes, in dem das JIT eine schnellere Version eines Verfahrens kompiliert, das verfolgt und mit dem Zwischenspeicher zusammengeführt werden kann ; (iii) Optimierung rund um den Anwendungsfall von Anwendungslaufzeiten auf der Cloud; (iv) eine Lösung konzentriert sich auf einen Orchestrierungsrahmen, der eine Container-Konfiguration automatisiert; (v) Statistiken die zum Verbessern der Leistung verwendet werden können, werden zur Wiederverwendung an einen zentralen Speicherplatz gesendet, um die Kompilierungsprofile der Anwendung kontinuierlich zu verbessern; (vi) Kompilierungsprofile sind dynamisch und fähig, Daten zentral auszutauschen, um das Kompilierungsprofil zu erhalten und zu verbessern, das jeder jeweiligen Arbeitslast auf Anforderung zugehörig ist.
Einige Ausführungsformen der vorliegenden Erfindung werden hierin im Kontext von OpenJ9 beschrieben, sind aber hinsichtlich der Anwendbarkeit nicht auf OpenJ9 beschränkt. In OpenJ9 werden die Klassendaten einer Java-Anwendung in einem Zwischenspeicher für gemeinsam genutzte Klassen (SCC) gespeichert. Ein Zwischenspeicher für gemeinsam genutzte Klassen (SCC) ist eine einem Arbeitsspeicher zugeordnete Datei, die Informationen speichert, die Folgendes umfassen: (i) den unveränderlichen Teil der Klassen, (ii) Ahead-of-Time- (AOT) kompilierten Code und (iii) Profilerstellungsdaten. Das Hochfahren der Anwendung wird beschleunigt, weil die erforderlichen Klassen schnell aus der dem Arbeitsspeicher zugeordneten Datei geladen werden können (dem SCC, der sich wahrscheinlich im RAM befindet), während die JIT-Kompilierung reduziert wird, um zwischengespeicherte AOT-kompilierte Teile schnell zu laden. Das Auffüllen des SCCs erfolgt transparent während der Laufzeit, wodurch sichergestellt wird, dass nur Klassen und Verfahren zwischengespeichert werden, die von der Anwendung benötigt werden, und AOT-Teile werden zumindest bis zu einem gewissen Grad auf die in Ausführung befindliche Anwendung zugeschnitten. (Hinweis: Die Begriffe „OpenJ9“ und/oder „Java“ können weltweit Markenrechten in verschiedenen Gerichtsbarkeiten unterliegen und werden hierin nur in Bezug auf die Produkte oder Dienste, die durch die Warenzeichen zutreffend benannt werden, in dem Maße verwendet, als derartige Markenrechte vorhanden sind.)
Ein Orchestrator für ein gemeinsames Nutzen von Klassen (CSO) gemäß einigen Ausführungsformen der vorliegenden Erfindung führt mindestens die folgenden Funktionen durch: (i) Bereitstellen von kompatiblen SCCs hoher Qualität für jede Bereitstellung einer Java-Anwendung auf der Cloud; (ii) kontinuierliche Verbesserung der Qualität von SCCs, die für jede Bereitstellung durch Sammeln von SCC-Daten aus ausgeführten Anwendungen und Durchführen einer Offline-Verarbeitung auf Grundlage der gesammelten SCC-Daten bereitgestellt werden, wobei eine minimale Auswirkung auf die ausgeführten Anwendungen verursacht wird.
Der Orchestrator für ein gemeinsames Nutzen von Klassen (CSO) verbessert herkömmliche Lösungen durch: (i) Verbessern der Qualität des Zwischenspeichers für gemeinsam genutzte Klassen (SCC); und/oder (ii) Verbessern der Benutzerfreundlichkeit der Funktion zur gemeinsamen SCC-Nutzung von Java-Anwendungen in einer Container-Umgebung. Diese Verbesserungen werden nachstehend in den folgenden nummerierten Absätzen beschrieben.
Verbessern der Qualität des SCCs: In einigen Ausführungsformen tragen ausgeführte containerisierte Java-Anwendungen ihre eigenen Laufzeitklassendaten über einen SCC-Konsolidierungsmechanismus zu einem entsprechenden (ursprünglichen) SCC bei. Der Konsolidierungsmechanismus kombiniert Aktualisierungen von ausgeführten Anwendungen desselben Typs, um einen neu gebildeten SCC von höherer Qualität für eine Verwendung durch zukünftige Anwendungen zu generieren. Der Mechanismus stellt sicher, dass der neu gebildete SCC mindestens genauso gut oder besser als der ursprüngliche SCC durchgeführt wird.
Verbessern der Benutzerfreundlichkeit der Funktion zur gemeinsamen SCC-Nutzung von Java-Anwendungen in einer Container-Umgebung: In einigen Ausführungsformen optimiert ein SCC-Aktualisierungsmechanismus die Größe des SCC-Datenaustauschs und die Zeit des SCC-Datenaustauschs zwischen ausgeführten Anwendungen auf der Cloud, um die Auswirkung des CSO auf ausgeführte Anwendungen und die Netzwerk-Bandbreite zu minimieren.
Ein Blockschaubild 600 von 6 zeigt einen Überblick über Komponenten eines Systems gemäß der vorliegenden Erfindung. Das System umfasst: einen Container-Orchestrator 602 (startet neue Java-Anwendungen); einen zentralen Server-Agent eines Orchestrators für ein gemeinsames Nutzen von Klassen (CSO) 604; einen SCC-Konsolidierungsmechanismus 606; einen SCC-Einrichtungsmechanismus 608; einen SCC-Aktualisierungsmechanismus 610; einen CSO-Client-Agent 612; ein zentrales Repository für einen Zwischenspeicher für gemeinsam genutzte Klassen (SCC) 614; und ein lokales SCC-Repository 616. Interaktionen und Informationsflüsse unter und zwischen den verschiedenen Systemkomponenten werden durch Pfeile angezeigt und in den folgenden wenigen Absätzen erörtert.
Einige Ausführungsformen fügen die folgenden Software-Agents dem CSO hinzu: (i) den zentralen CSO-Server-Agent 604; und/oder (ii) den CSO-Client-Agent 612.
Zentraler CSO-Server-Agent:
Einige Ausführungsformen platzieren den zentralen CSO-Server-Agent 604 auf einem dedizierten Knoten, der separat und von jedem Knoten verschieden ist, der einen CSO-Client-Agent hostet, wie zum Beispiel den CSO-Client-Agent 612. Der zentrale CSO-Server-Agent 604 führt die folgenden Funktionen durch: (i) Bereitstellen von frisch gestarteten Java-Anwendungs-Containern mit geeigneten SCCs beim Hochfahren, wobei der zentrale CSO-Server-Agent 604 mit einem vorhandenen Container-Orchestrierungssystem Daten austauscht, um dem CSO zu gestatten, sich Informationen über alle Java-Anwendungsabbilder im Spiel (innerhalb des Bereichs des CSO) zu verschaffen; (ii) Verwalten des zentralen Repositorys für einen Zwischenspeicher für gemeinsam genutzte Klassen (SCC) 614, das für persistierende SCCs für jedes Java-Anwendungsabbild verwendet wird; (iii) Zuordnen einer Mehrzahl von Java-Anwendungs-Containern zu einer jeweils entsprechenden Mehrzahl von CSO-Client-Agents 612; und/oder (iv) Bearbeiten von Aktualisierungen des CSO-Client-Agents 612, um SCCs von höherer Qualität für jedes Java-Anwendungsabbild zu generieren,.
CSO-Client-Agent:
Der CSO-Client-Agent 612 ist ein Hintergrundprozess, der auf jedem Arbeitsknoten ausgeführt wird und darauf ausgeführte Anwendungen bedient. Zu Funktionen des CSO-Client-Agents 612 zählen: (i) Überwachen von Zuständen der virtuellen Java-Maschine (JVM), wobei die Zustände „aktiv“, „inaktiv“ oder „wird beendigt“ umfassen; (ii) Senden von Aktualisierungen an den zentralen CSO-Server-Agent 604, wenn ein Anwendungszustand entweder „inaktiv“ oder „wird beendigt“ ist; und/oder (iii) Verwalten des lokalen SCC-Repositorys 616, das Zwischenspeicher für gemeinsam genutzte Klassen (SCCs) auf Arbeitsknoten beibehält.
Der zentrale Server-Orchestrator (CSO) weist drei Mechanismen auf, die in Verbindung mit dem zentralen CSO-Server-Agent 604 und dem CSO-Client-Agent 612 umgesetzt werden, die die folgenden Mechanismen umfassen: (i) SCC-Einrichtungsmechanismus 608; (ii) SCC-Aktualisierungsmechanismus 610; und/oder (iii) SCC-Konsolidierungsmechanismus 606.
SCC-EINRICHTUNGSMECHANISMUS:
Der SCC-Einrichtungsmechanismus 608 richtet einen geeigneten Basis-SCC für eine neu gestartete Java-Anwendungsinstanz ein, indem mindestens einige der folgenden Operationen durchgeführt werden: (i) Empfangen von Informationen in Bezug auf eine neue Java-Anwendungsinstanz: (ii) Senden eines Basis-SCCs an den CSO-Client-Agent 612; und/oder (iii) Speichern des Basis-SCCs in dem lokalen SCC-Repository 616. Diese Operationen werden weiter in den folgenden wenigen Absätzen beschrieben.
Empfangen von Informationen in Bezug auf eine neue Java-Anwendungsinstanz:
Der zentrale CSO-Server-Agent 604 empfängt Informationen, die zu der Java-Anwendungsinstanz gehören, die gerade gestartet werden soll, von einem vorhandenen Container-Orchestrierungssystem (Container-Orchestrator 602), und versucht, einen geeigneten Basis-SCC zu finden. Zu beachten ist, dass der zugehörige Container bereits einen SCC umfassen kann, der zur Abbild-Erstellungszeit bereitgestellt wurde. Informationen, die von dem Container-Orchestrator 602 empfangen werden, umfassen: (i) eine Abbildkennung (Abbild-ID), die zum Identifizieren eines geeigneten Basis-SCCs verwendet wird; (ii) Argumente, die an die Java-Anwendungsinstanz übergeben werden, die zum Identifizieren eines geeigneten Basis-SCCs verwendet werden; und/oder (iii) einen Knoten, auf dem die Java-Anwendungsinstanz ausgeführt werden soll, die zum Auffinden des zugehörigen CSO-Client-Agents 612 verwendet wird. Jeder Basis-SCC im zentralen SCC-Repository 614 wird durch die Abbild-ID und die Argumente gekennzeichnet, die an die Java-Anwendungsinstanz übergeben werden. Dementsprechend nutzen mehrere Java-Anwendungsinstanzen, die dieselbe Abbild-ID und dieselben Argumente haben, denselben Basis-SCC gemeinsam.
Senden von Basis-SCC an CSO-Client:
Der zentrale CSO-Server-Agent 604 identifiziert einen geeigneten Basis-SCC zumindest teilweise auf Grundlage der Knoteninformationen. Der zentrale CSO-Server-Agent 604 sendet den Basis-SCC zu dem entsprechenden CSO-Client-Agent 612. Der zentrale CSO-Server-Agent 604 sendet den Basis-SCC, den die Anwendung benötigt, über den zugehörigen CSO-Client-Agent 612. Jede Anwendung ist einem CSO-Client zugehörig, da sie sich auf demselben Knoten befinden.
Basis-SCC lokal speichern:
Der CSO-Client-Agent 612 speichert den Basis-SCC in dem lokalen SCC-Repository 616, in dem der Basis-SCC zur Verwendung durch die neue Java-Anwendungsinstanz verfügbar gemacht wird.
SCC-AKTUALISIERUNGSMECHANISMUS:
Der SCC-Aktualisierungsmechanismus 610 verwaltet SCC-Aktualisierungen, indem zumindest einige der folgenden Operationen durchgeführt werden: (i) Aktualisierung eines ursprünglichen SCCs; (ii) Zuordnung von ausgeführten Anwendungen zu einem CSO-Client (siehe CSO-Client-Agent 612); (iii) Erweitern des SCCs; und/oder (iv) Senden einer SCC-Aktualisierungsanforderung an den zentralen CSO-Server-Agent 604. Der zentrale CSO-Server-Agent 604 kann die Anforderung potenziell aufgrund einer Reihe von Gründen ablehnen. Die vorgenannten Operationen und Gründe für ein potenzielles Ablehnen der Anforderung und zugehörigen Antworten dazu werden nachstehend in den folgenden wenigen Absätzen beschrieben.
Ursprünglichen SCC aktualisieren:
Eine Aktualisierung ist im Wesentlichen die Differenz (eine Diff) zwischen dem ursprünglichen (Basis-) SCC, die der virtuellen Java-Maschine (JVM) der Anwendung beim Hochfahren der neuen Java-Anwendungsinstanz zur Verfügung gestellt wird, und neuen SCC-Hinzufügungen, die die JVM anschließend generiert.
Ausgeführte Anwendungen einem CSO-Client zuordnen:
Einige Ausführungsformen ordnen jeder in der Cloud ausgeführten Anwendung einen CSO-Client zu (siehe CSO-Client-Agent 612). Dementsprechend gibt es für jeden Arbeitsknoten einen CSO-Client-Agent 612. Der CSO-Client-Agent 612 berechnet eine Aktualisierung (einen Zwischenspeicher für Klassen) für jede Anwendung und sendet sie an den zentralen CSO-Server-Agent 604, wenn sich die Anwendung in einem „inaktiven“ Zustand befindet oder eine Ausführung beendet hat (sich in einem Zustand „wird beendet“ befindet). Indem der CSO-Client-Agent 612 darauf wartet, dass die Anwendung entweder in einen Zustand „inaktiv“ oder „wird beendet“ eintritt, trägt er zum Optimieren des Netzwerkverkehrs bei, da die Aktualisierung sich nicht im Wettstreit um Netzwerkbandbreite mit der Anwendung befindet. Der Zeitpunkt, zu dem die Aktualisierung stattfindet, variiert je nach Anwendung und/oder der Arbeitslast der Anwendung. Der CSO-Client nutzt einen JVM-Mechanismus zur Inaktiv-Erkennung, um ein Senden einer Aktualisierung einer Anwendung an den zentralen CSO-Server (siehe zentraler CSO-Server-Agent 604) zu planen.
Den SCC erweitern:
Der Zwischenspeicher für gemeinsam genutzte Klassen (SCC) wird von beiden Enden zur Mitte hin erweitert, wobei Klassendaten an einem Ende des SCCs hinzugefügt werden und JIT-Daten an dem anderen Ende hinzugefügt werden. In Bezug auf den SCC gibt es zwei „Basiszeiger“ für den ursprünglichen SCC und zwei „aktuelle Zeiger“ für die neuen Hinzufügungen durch die JVM. Eine SCC-Aktualisierung weist den Inhalt zwischen den Basiszeigern und den aktuellen Zeigern auf. Der CSO-Client-Agent 612 verfolgt die Basiszeiger und generiert eine SCC-Aktualisierung für jede Java-Anwendungsinstanz.
Eine SCC-Aktualisierungsanforderung an den zentralen CSO-Server senden:
Bevor eine SCC-Aktualisierungsanforderung gesendet wird, sendet der CSO-Client-Agent 612 (der einem bestimmten Knoten zugehörig ist) eine Anforderung an den zentralen CSO-Server-Agent 604, um sicherzustellen, dass die SCC-Aktualisierung für eine weitere Verarbeitung akzeptiert wird. Wenn der zentrale CSO-Server-Agent 604 die Anforderung ablehnt, verwirft der zentrale CSO-Server-Agent 604 die Anforderung. Anschließend verwendet die nächste Instanz der Anwendung auf dem bestimmten Knoten einen neuen SCC, der von dem zentralen CSO-Server-Agent 604 bereitgestellt wird. Die SCC-Aktualisierungsanforderung weist die folgenden Informationen auf: (i) eine Anwendungsabbild-ID (zum Identifizieren des Anwendungstyps); (ii) an den Container übergebene Argumente (zum Identifizieren des Anwendungstyps); (iii) Hardware-Informationen (zum Identifizieren des Anwendungstyps); (iv) Knoteninformationen (zum Identifizieren, von welchem CSO-Client sie stammen); (v) SCC-Metadaten (zum Beispiel SCC-Basisversion, Größe usw.); und/oder (vi) Ausführungsverhaltensdaten (zum Beispiel, ob die Anwendung korrekt/wie erwartet/wie üblich geendet hat).
In einigen Ausführungsformen verweisen die Begriffe „Anwendungstyp“, „verwalteter Laufzeitanwendungstyp“ und ähnliche Begriffe auf eine Docker-Abbildkennung (Anwendungsabbild-ID). Zum Beispiel wird eine Web-Anwendung für den Aktienmarkt angenommen. Um die Web-Anwendung in der Cloud aufzurufen und auszuführen, ist die Web-Anwendung in einigen Ausführungsformen in ein Docker-Abbild gepackt. Die Docker-Abbild-ID der Web-Anwendung ist die „Anwendungsabbild-ID“. Mechanismen und/oder Merkmale, die sich auf ein gemeinsames Nutzen von Klassendaten beziehen, gelten in Ausführungsformen der vorliegenden Erfindung für Anwendungen desselben Typs. Instanzen derselben Anwendung können untereinander Daten gemeinsam nutzen. In Bezug auf das vorgenannte Docker-Beispiel kann das Docker-Abbild, das der Web-Anwendung für den Aktienmarkt zugehörig ist, viele verschiedene Instanzen (Docker-Container) haben, die auf verschiedenen Maschinen in der Cloud bereitgestellt werden (sie können den Börsendienst durch Verwenden einer Vielfalt von physischen Maschinen bedienen, die sich an einer Vielfalt von physischen Standorten befinden). Alle Instanzen haben dieselbe Docker-Abbild-ID und werden demzufolge als vom selben Typ betrachtet und sind fähig, untereinander Daten gemeinsam zu nutzen. Als andere Anwendung wird zum Beispiel eine Web-Anwendung für Video-Streaming angenommen. Die Web-Anwendung für Video-Streaming und die Web-Anwendung für den Aktienmarkt haben verschiedene Docker-Abbild-IDs und gehören demzufolge nicht zu demselben Typ. Instanzen der Web-Anwendung für Video-Streaming haben dieselbe Docker-Abbild-ID und können demzufolge untereinander Daten gemeinsam nutzen. Instanzen der Web-Anwendung für Video-Streaming sind jedoch nicht fähig, Daten mit Instanzen der Web-Anwendung für den Aktienmarkt gemeinsam zu nutzen.
Hinweis: Der Begriff „Docker“ kann weltweit Markenrechten in verschiedenen Gerichtsbarkeiten unterliegen und wird hierin nur in Bezug auf die durch die Warenzeichen zutreffend benannten Produkte oder Dienste in dem Maße verwendet, als derartige Markenrechte vorhanden sind.
Mögliche Gründe für ein Ablehnen einer Anforderung und zugehörige Antworten:
Der zentrale CSO-Server-Agent 604 kann eine Anforderung aufgrund von mindestens einem der folgenden Gründe oder Faktoren ablehnen: (i) ein SCC für den Anwendungstyp auf dem zentralen CSO-Server ist voll und akzeptiert keine neuen Aktualisierungen mehr, weshalb der CSO-Client-Agent 612 damit aufhört, Aktualisierungen für die entsprechende Java-Anwendungsinstanz zu berechnen und zu senden; (ii) der zentrale CSO-Server-Agent 604 bestimmt, dass sich die Anwendung nicht normal verhalten hat (zum Beispiel gibt die Anwendung einen Fehlercode, einen ungewöhnlichen Rückgabecode und/oder einen unerwarteten Rückgabecode zurück), und in Reaktion darauf wird die Aktualisierung als ungültig erachtet; und/oder (iii) der zentrale CSO-Server-Agent 604 erachtet die SCC-Aktualisierung für überholt und akzeptiert demzufolge Aktualisierungen von derartigen überholten Versionen nicht mehr. Eine SCC-Aktualisierung wird für überholt erachtet, wenn der zentrale CSO-Server-Agent 604 eine neuere SCC-Basisversion im Vergleich mit der SCC-Basisversion hat, die der Aktualisierung zugehörig ist, weshalb der CSO-Client-Agent 612 in diesem Fall damit aufhört, SCC-Aktualisierungen für die entsprechende Java-Anwendungsinstanz zu berechnen und zu senden.
SCC-KONSOLIDIERUNGSMECHANISMUS:
Die SCC-Konsolidierung generiert gemäß einigen Ausführungsformen der vorliegenden Erfindung SCCs von höherer Qualität auf Grundlage, zumindest teilweise, von SCC-Aktualisierungen, die von einem oder mehreren CSO-Clients bereitgestellt werden (zum Beispiel dem CSO-Client-Agent 612). Der zentrale CSO-Server-Agent 604 analysiert (offline) eine Schwellenwertanzahl von zuletzt empfangenen SCC-Aktualisierungen, um einen neuen Basis-SCC zu erstellen, der von allen nachfolgenden Java-Anwendungsinstanzen desselben Typs verwendet werden kann. Jeder SCC-Typ ist einem Anwendungstyp zugeordnet. Während Instanzen einer Anwendung den Zwischenspeicher auffüllen, nutzen alle Instanzen der Anwendung gemeinsam denselben SCC.
Der zentrale CSO-Server-Agent 604 erstellt einen neuen Basis-SCC wie folgt:

bei jedem Empfang einer Aktualisierung für einen bestimmten Anwendungstyp durch den zentralen CSO-Server wird die Aktualisierung für eine spätere Verarbeitung gespeichert;
sobald der zentrale CSO-Server-Agent 604 eine Schwellenwertanzahl von Aktualisierungen empfangen hat, hört der zentrale CSO-Server-Agent 604 damit auf, neue Aktualisierungen zu empfangen und erstellt einen neuen SCC auf Grundlage der gespeicherten Aktualisierungen (die Schwellenwertanzahl beruht auf heuristischen Werten - in einigen Ausführungsformen ist sie zum Beispiel auf 80 % aller Anwendungsinstanzen festgelegt, die aktuell denselben Basis-SCC aus dem zentralen CSO-Server verwenden);
wenn es einen dem Anwendungstyp zugehörigen Basis-SCC gibt, der auf dem zentralen CSO-Server vorhanden ist, wird der gesamte Inhalt des Basis-SCCs in dem neuen Basis-SCC verwendet;
wenn es neue Daten gibt, die mehr als einer SCC-Aktualisierung gemeinsam sind, fügt der zentrale CSO-Server-Agent 604 die neuen Daten zu dem neuen SCC hinzu (wenn zum Beispiel mehr als die Hälfte der Aktualisierungen eine Kompilierung desselben Verfahrens angibt, erachtet der zentrale CSO-Server-Agent 603 das Verfahren als „wichtig“ und nimmt das Verfahren in den neuen Basis-SCC auf);
sobald der zentrale CSO-Server 604 einen neuen Basis-SCC generiert, lehnt der zentrale CSO-Server-Agent 604 alle Aktualisierungsanforderungen ab, die aus Bereitstellungen empfangen wurden, die durch Verwenden des alten SCCs gestartet wurden, und akzeptiert danach Aktualisierungen nur aus Bereitstellungen, die durch Verwenden des neuen Basis-SCCs gestartet wurden.

Einige Ausführungsformen der vorliegenden Erfindung können ein bzw. einen oder mehrere der folgenden Merkmale, Eigenschaften und/oder Vorteile umfassen: (i) ein Zwischenspeicher für gemeinsam genutzte Klassen (SCC) kann dynamisch (lesen/schreiben) statt statisch (nur lesen) sein; (ii) Profilerstellungsdaten und andere Just-in-Time- (JIT) Kompiliererhinweise können von Ausführung zu Ausführung unterschiedlich sein; (iii) Profilerstellungsdaten können im Lauf der Zeit angesammelt werden, um ein besseres Bild des Zustands einer Anwendung bereitzustellen; und/oder (iv) dynamische Daten in dem SCC ermöglichen es Entwicklern, Offline-Analysen des Zustands von verschiedenen Anwendungen durchzuführen und SCCs, die optimiert werden sollen, dynamisch und kompakter für jede Anwendung zu modifizieren.
Einige Ausführungsformen der vorliegenden Erfindung würdigen einen oder mehrere der folgenden Fakten, potenziellen Probleme und/oder potenziellen Bereiche zur Verbesserung in Bezug auf den derzeitigen Stand der Technik: (i) der SCC ist eine dem Arbeitsspeicher zugeordnete Datei; (ii) Klassendaten in einem SCC umfassen einen unveränderlichen Teil der Klassen; (iii) Just-in-Time- (JIT) kompilierte Daten können Ahead-of-Time- (AOT) kompilierten Code und Profilerstellungsdaten umfassen; (iv) möglicher Weise ist ein „Aufwärm-Durchlauf“ erforderlich, um den Zwischenspeicher für gemeinsam genutzte Klassen aufzufüllen; (v) anschließende Ausführungen können eine verbesserte Anlaufzeit und verbesserten Speicherbedarf aufweisen; und/oder (vi) müssen möglicherweise auf demselben Knoten vorhanden sein.
Ein Blockschaubild 700 von 7 zeigt einen Prozess zum Einrichten, Aktualisieren und Konsolidieren von Zwischenspeichern für gemeinsam genutzte Klassen gemäß einigen Ausführungsformen der vorliegenden Erfindung, darunter: zentraler CSO-Server-Agent 604; erster CSO-Client-Agent 612-1; zweiter CSO-Client-Agent 612-2; zentrales SCC-Repository 614, das SCC₅, SCC₆ ... SCC_k aufweist; erstes lokales SCC-Repository 616-1, das SCC₁, SCC₂ ... SCC_k aufweist; zweites lokales SCC-Repository 616-2, das SCC₅, SCC₄ ... SCC_m aufweist; JVM₁ 701; JVM₂ 702; JVM₃ 703; JVM₄ 704; erster Knoten 721; zweiter Knoten 722; dritter Knoten 723; und/oder ausstehende Diffs 724.
Die folgenden Operationen 1 bis 11 entsprechen jeweils entsprechend nummerierten Pfeilen in 7. Drei Prozesse gemäß einigen Ausführungsformen der vorliegenden Erfindung (und oben unter Bezugnahme auf 6 erläutert) weisen auf: SCC-Einrichtung (Operationen 1 bis 7); SCC-Aktualisierung (Operationen 8 bis 10); und SCC-Konsolidierung (Operation 11).
SCC-Einrichtung

1. Der Orchestrator für gemeinsam genutzten Zwischenspeicher (erster CSO-Client-Agent 612-1) empfängt Informationen von dem ersten lokalen Repository für Zwischenspeicher für gemeinsam genutzte Klassen (erstes lokales SCC-Repository 616-1) in Bezug auf ein Container-Abbild, das gestartet werden soll, und die zugehörigen Parameter. Der erste CSO-Client-Agent 612-1 durchsucht das lokale Repository 616-1 nach einem geeigneten SCC.
2. Wenn der erste CSO-Client-Agent 612-1 einen geeigneten SCC findet, hängt der erste CSO-Client-Agent 612-1 den SCC in einen virtuellen Java-Maschinen-Container ein (zum Beispiel JVM₁ 701).
3. Wenn der erste CSO-Client-Agent 612-1 keinen geeigneten SCC in dem ersten lokalen SCC-Repository 616-1 findet, sendet der erste CSO-Client-Agent 612-1 eine Anforderung an den zentralen CSO-Server-Agent 604, einen geeigneten SCC zu finden.
4. Der zentrale CSO-Server-Agent 604 durchsucht das zentrale SCC-Repository 614 (ein globales SCC-Repository), findet einen geeigneten SCC und ruft ihn ab.
5. Der zentrale CSO-Server-Agent 604 gibt den geeigneten SCC an den ersten CSO-Client-Agent 612-1 zurück.
6. Der erste CSO-Client-Agent 612-1 installiert den geeigneten SCC in dem lokalen Repository.
7. Der erste CSO-Client-Agent 612-1 hängt den geeigneten SCC in die JVM₁ 701 auch ein.

SCC-Aktualisierung

8. Der zweite CSO-Client-Agent 612-2 fragt den Zustand von zugehörigen JVMs ab (JVM₃ 703, and JVM₄ 704). Der zweite CSO-Client-Agent 612-2 fragt ferner den SCC-Zustand ab, der sich in dem zweiten lokalen SCC-Repository 612-2 befindet, um zu bestimmen, ob die JVM₃ 703, und/oder die JVM₄ 704 neuen Inhalt haben, der in einem entsprechenden SCC des zweiten lokalen SCC-Repositorys 612-2 noch nicht vorhanden ist. Wenn eine Schwellenwertmenge an neuem Inhalt in der JVM₃ 703 und/oder der JVM₄ 704 vorhanden ist, berechnet der zweite CSO-Client-Agent 612-2 eine Differenz (eine „Diff“) auf Grundlage von neuem Inhalt, der der JVM₃ 703 und/oder der JVM₄ 704 zugehörig ist, in Bezug auf den Inhalt, der in dem zweiten lokalen SCC-Repository 612-2 zwischengespeichert ist.
9. Der zweite CSO-Client-Agent 612-2 sendet eine Aktualisierungsanforderung einschließlich der Diff an den zentralen CSO-Server-Agent 604. In einigen Ausführungsformen sendet der zweite CSO-Client-Agent 612-2 zuerst eine „Stichprobennachricht“, um zu bestimmen, ob der zentrale CSO-Server-Agent 604 die Aktualisierungsanforderung akzeptiert.
10. In Reaktion auf ein Akzeptieren der Aktualisierungsanforderung speichert der zentrale CSO-Server-Agent 604 die Diff in ausstehenden Diffs 724.

SCC-Konsolidierunq

11. In Reaktion auf ein Ansammeln einer Schwellenwertanzahl von neuen Aktualisierungsanforderungen in ausstehenden Diffs 724 analysiert der CSO-Server die Aktualisierungsanforderungen (einschließlich jeweils entsprechender ausstehender Diffs) und wählt Informationen für eine Propagierung in das zentrale SCC-Repository 614 aus (ein globales Repository). Das zentrale SCC-Repository 614 erhöht die Basisversion jedes Zwischenspeichers für gemeinsam genutzte Klassen (SCC₅, SCC₅, ... SCC_k), der aktualisiert wird. Der zentrale CSO-Server-Agent 604 lehnt Aktualisierungen ab, die an niedrigere Versionen gerichtet sind.

Einige Ausführungsformen der vorliegenden Erfindung können ein bzw. einen oder mehrere der folgenden Merkmale, Eigenschaften und/oder Vorteile umfassen: (i) gemeinsames Nutzen von dynamischen Klassendaten; (ii) kontinuierliches Verbessern der Qualität von Klassendaten in einer Cloud-Umgebung; (iii) ein Zwischenspeicher-Aktualisierungssystem erzeugt effizient Aktualisierungen für einen Zwischenspeicher für gemeinsam genutzte Klassen durch Bereitstellen von Software-Agents auf jedem Knoten und durch Verfolgen von Snapshots der Zwischenspeicherbasis für gemeinsam genutzte Klassen für jede Anwendung, die in einer Cloud-Umgebung ausgeführt wird; (iv) ein Zwischenspeicher-Konsolidierungssystem verbessert kontinuierlich die Qualität des Zwischenspeichers durch effizientes Sammeln von Aktualisierungen für Zwischenspeicher für Klassen von Software-Agents und durch effizientes Konsolidieren der Aktualisierungen durch Verwenden eines Satzes von Regeln, der Verbesserungen gegenüber herkömmlichen Lösungen sicherstellt; (v) ein Zwischenspeicher-Orchestrierungssystem verwaltet ein Zwischenspeichern von Daten aus allen in einer Cloud-Umgebung ausgeführten Anwendungen; (vi) ein Zwischenspeicher-Aktualisierungs- und -Konsolidierungssystem verbessert die im Lauf der Zeit zwischengespeicherten Ergebnisse kontinuierlich; (vii) Verbessern der Anwendbarkeit von dynamischen gemeinsam genutzten Klassendaten in einer Cloud-Umgebung; (viii) Bereitstellen eines Orchestrators für gemeinsames Nutzen von Klassen; (ix) gemeinsames Cloud-übergreifendes und/oder Cluster-übergreifendes Nutzen von Klassendaten; und/oder (x) Initiieren eines Starts einer verwalteten Laufzeitanwendung durch einen Orchestrator für ein gemeinsames Nutzen von Klassen in einer containerisierten Umgebung.
Einige Ausführungsformen der vorliegenden Erfindung weisen ein durch einen Computer umgesetztes Verfahren, ein Computerprogrammprodukt zum Durchführen des Verfahrens und/oder ein Computersystem zum Durchführen des Verfahrens zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten auf, wobei das Verfahren aufweist: (i) in Reaktion auf ein Initiieren eines Starts einer verwalteten Laufzeitanwendung durch einen Container-Orchestrator in einer containerisierten Umgebung, Empfangen, durch einen zentralen Server eines Orchestrators für ein gemeinsames Nutzen von Klassen, von Informationen, die eine Abbildkennung, Argumente, die an eine Instanz der verwalteten Laufzeitanwendung übergeben wurden, und eine Kennung eines Arbeitsknotens umfassen, der die Instanz ausführen soll, von dem Container-Orchestrator; (ii) in Reaktion auf ein Auffinden, durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen, eines geeigneten Basis-Zwischenspeichers für gemeinsam genutzte Klassen in dem zentralen Repository von Zwischenspeichern für gemeinsam genutzte Klassen auf Grundlage der Suchkriterien, die die Abbild-ID und die Liste von Argumenten aufweisen, die an die Instanz der verwalteten Laufzeitanwendung übergeben wurden, Senden des geeigneten Basis-Zwischenspeichers für gemeinsam genutzte Klassen durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen an einen entsprechenden Client des Orchestrators für ein gemeinsames Nutzen von Klassen, der durch Verwenden der Informationen für den Arbeitsknoten identifiziert wurde; (iii) in Reaktion auf ein Empfangen des geeigneten Basis-Zwischenspeichers für gemeinsam genutzte Klassen von dem zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen, Speichern des geeigneten Basis-Zwischenspeichers für gemeinsam genutzte Klassen durch den entsprechenden Client des Orchestrators für ein gemeinsames Nutzen von Klassen in einem lokalen Repository für Zwischenspeicher von gemeinsam genutzten Klassen zur Verwendung durch die Instanz der verwalteten Laufzeitanwendung; (iv) in Reaktion darauf, dass der zentrale Server des Orchestrators für ein gemeinsames Nutzen von Klassen von dem entsprechenden Client des Orchestrators für gemeinsames Nutzen von Klassen eine Anforderung empfängt, eine Aktualisierung zu verarbeiten, die die Abbild-ID, die übergebenen Argumente, Hardware-Informationen, Knoteninformationen, zusätzliche gemeinsam genutzte Klassendaten in Bezug auf den Basis-SCC umfasst, der von dem Client des Orchestrators für ein gemeinsames Nutzen von Klassen empfangen wurde, Bestimmen, durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen, ob die Aktualisierung akzeptiert wird; (v) in Reaktion auf ein Ablehnen der Anforderung, die Aktualisierung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen zu verarbeiten, Verwerfen der Aktualisierung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen; (vi) Senden eines neuen Zwischenspeichers für gemeinsam genutzte Klassen durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen an den entsprechenden Client des Orchestrators für ein gemeinsames Nutzen von Klassen; (vii) in Reaktion auf ein Akzeptieren der Anforderung zum Verarbeiten der Aktualisierung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen für einen bestimmten Typ der verwalteten Laufzeitanwendung, Speichern der Aktualisierung für eine spätere Offline-Verarbeitung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen; (viii) Analysieren einer konfigurierbaren Anzahl von letzten Aktualisierungen, die von dem zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen empfangen wurden, um analysierte Daten zu erstellen; (ix) in Reaktion auf eine Bestimmung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen durch Verwenden der analysierten Daten, dass auf dem zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen ein alter Basis-Zwischenspeicher für gemeinsam genutzte Klassen für den bestimmten Typ vorhanden ist, Generieren eines neuen Basis-Zwischenspeichers für gemeinsam genutzte Klassen durch Verwenden des gesamten Inhalts des alten Basis-Zwischenspeichers für gemeinsam genutzte Klassen; (x) in Reaktion auf eine Bestimmung durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen, dass neue gemeinsame Daten zwischen mehr als einer Aktualisierung vorhanden sind, Hinzufügen der neuen Daten zu dem neuen Basis-Zwischenspeicher für gemeinsam genutzte Klassen durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen; und (xi) in Reaktion auf ein Generieren des neuen Basis-Zwischenspeichers für gemeinsam genutzte Klassen, Ablehnen, durch den zentralen Server des Orchestrators für ein gemeinsames Nutzen von Klassen, von Aktualisierungsanforderungen aus Bereitstellungen, die durch Verwenden des alten Zwischenspeichers für gemeinsam genutzte Klassen gestartet wurden.
In einer beispielhaften Ausführungsform wird das folgende Szenario betrachtet, in dem drei Knoten (node-1, node-2 und node-3) jeweils Folgendes hosten: drei Instanzen einer Anwendung (app-1, app-2 und app-3, alle von einem bestimmten Anwendungstyp); drei Clients (CSO-1, CSO-2 und CSO-3) eines lokalen Zwischenspeichers eines Orchestrators (CSO) für ein gemeinsames Nutzen ; und drei lokale Zwischenspeicher-Repositorys (cache-1, cache-2 und cache-3). Ein vierter Knoten (node-4) hostet einen zentralen CSO-Server und ein zentrales Zwischenspeicher-Repository, das einen Basis-Zwischenspeicher für gemeinsam genutzte Klassen (SCC) aufweist, der für Anwendungen des bestimmten Anwendungstyps spezifisch ist.
Der zentrale CSO-Server tauscht mit CSO-1, CSO-2 und CSO-3 Daten aus, um irgendwelche lokalen Zwischenspeicher-Aktualisierungen zu empfangen, die app-1, app-2 und app-3 während der Ausführung generieren. Auf Grundlage der empfangenen lokalen Zwischenspeicher-Aktualisierungen aktualisiert der zentrale CSO-Server den Basis-SCC, der dem bestimmten Anwendungstyp entspricht, in dem zentralen Zwischenspeicher-Repository.
Während die app-1 ausgeführt wird, sammelt und speichert der CSO-1 zugehörige Daten in dem lokalen Zwischenspeicher-Repository cache-1. Im Folgenden wird angenommen, dass der CSO-1 schließlich eine Aktualisierungsanforderung generiert und die Anforderung an den zentralen CSO-Server sendet. Der zentrale CSO-Server durchsucht das zentrale Zwischenspeicher-Repository nach einem geeigneten Basis-SCC. Wenn der zentrale CSO-Server den Basis-SCC identifiziert hat, bestimmt er, dass der cache-1 (lokal für app-1) überholt ist. In Reaktion darauf lehnt der zentrale CSO-Server die Aktualisierungsanforderung von dem CSO-1 ab und sendet den Basis-SCC von dem zentralen Zwischenspeicher-Repository an den CSO-1 auf dem node-1. Derselbe Prozess findet für app-2 und app3 statt, wobei der CSO-2 und der CSO-3 jeweils zugehörige Zwischenspeicherdaten in jeweiligen lokalen Zwischenspeichern sammeln und speichern, Aktualisierungsanforderungen an den zentralen CSO-Server senden und aktualisierte Basis-SCCs empfangen, um ihre lokalen Zwischenspeicher zu aktualisieren, falls/wenn für jeweilige lokale Zwischenspeicher durch den zentralen CSO-Server bestimmt worden ist, dass sie überholt sind.
Die entsprechenden Strukturen, Materialien, und Entsprechungen aller Mittel oder Schritt-plus-Funktion-Elemente in den nachstehenden Ansprüchen sollen alle Strukturen, Materialien oder Handlungen zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen enthalten, wie speziell beansprucht. Die Beschreibung der vorliegenden Offenbarung wurde zum Zweck der Veranschaulichung und Beschreibung erstellt, sie soll aber keineswegs erschöpfend oder auf die offenbarte Form der Offenbarung eingeschränkt sein. Für Fachleute sind viele Modifizierungen und Variationen offenkundig, die nicht von dem Schutzumfang und Erfindungsgedanken der Offenbarung abweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Offenbarung und die praktische Anwendung am besten zu erklären und es anderen Fachleuten zu ermöglichen, die Offenbarung für verschiedene Ausführungsformen mit verschiedenen Modifizierungen zu verstehen, die für die vorgesehene bestimmte Verwendung geeignet sind.
IV. DEFINITIONEN
Vorliegende Erfindung: sie sollte nicht als absolute Angabe aufgefasst werden, dass der durch den Begriff „vorliegende Erfindung“ beschriebene Anspruchsgegenstand entweder durch die Ansprüche wie angemeldet oder durch die Ansprüche abgedeckt wird, die sich möglicherweise nach dem Patenterteilungsverfahren ergeben; zwar wird der Begriff „vorliegende Erfindung“ verwendet, um den Leser dabei zu unterstützen, ein allgemeines Gefühl dafür zu bekommen, wofür die Offenbarungen hierin für potenziell neu gehalten werden, diese Auslegung, wie durch die Verwendung des Begriffs „vorliegende Erfindung“ angegeben, ist vorläufig und einstweilig und Änderungen im Verlauf des Patenterteilungsverfahrens unterworfen, wenn relevante Informationen entwickelt werden und wenn die Ansprüche potenziell geändert werden.
Ausführungsform: siehe oben die Definition von „vorliegende Erfindung“ähnliche Vorsichtshinweise gelten für den Begriff „Ausführungsform“.
und/oder: inklusive oder; zum Beispiel bedeutet A, B „und/oder“ C, dass mindestens eines von A oder B oder C wahr und anwendbar ist.
Umfassend/umfassen/umfasst: sofern nicht anderweitig explizit angemerkt, bedeutet dies „einschließlich, aber nicht notwendigerweise darauf beschränkt“.
Benutzer/Abonnent: umfasst Folgendes, ist aber nicht notwendigerweise darauf beschränkt: (i) eine einzelne individuelle Person; (ii) eine Entität künstlicher Intelligenz mit ausreichender Intelligenz, um als Benutzer oder Abonnent zu wirken; und/oder (iii) eine Gruppe von zugehörigen Benutzern oder Abonnenten.
Elektrisch verbunden: bedeutet entweder direkt elektrisch verbunden oder indirekt elektrisch verbunden, sodass dazwischen liegende Elemente vorhanden sind; eine elektrische Verbindung kann Elemente wie Kondensatoren, Induktoren, Transformatoren, Vakuumröhren und dergleichen umfassen, sie ist aber nicht darauf beschränkt.
Datenübertragung: jedes Datenübertragungsschema, das derzeit bekannt ist oder zukünftig entwickelt wird, das eine drahtlose Datenübertragung, eine drahtgebundene Datenübertragung und Datenübertragungspfade umfasst, die drahtlose und drahtgebundene Abschnitte haben, wobei die Datenübertragung nicht notwendigerweise beschränkt ist auf: (i) direkte Datenübertragung; (ii) indirekte Datenübertragung; und/oder (iii) Datenübertragung, wobei das Format, der Paketierungszustand, der Datenträger, der Verschlüsselungszustand und/oder das Protokoll über den gesamten Verlauf der Datenübertragung konstant bleiben.
Empfangen/bereitstellen/senden/eingeben/ausgeben/melden: sofern nicht explizit anders angegeben, sollen diese Wörter nicht so verstanden werden, dass sie Folgendes implizieren: (i) einen speziellen Grad einer Direktheit in Bezug auf die Beziehung zwischen ihren Objekten und Subjekten; und/oder (ii) ein Fehlen von dazwischenliegenden Komponenten, Aktionen und/oder Dingen, die zwischen ihren Objekten und Subjekten angeordnet sind.
Ohne wesentliches Eingreifen durch eine Person: ein Prozess, der automatisch erfolgt (oft durch eine Operation einer Maschinenlogik, wie zum Beispiel Software) mit wenig oder gar keiner Eingabe durch eine Person; zu einigen Beispielen, an denen „Kein wesentliches Eingreifen durch eine Person“ beteiligt ist, gehören: (i) ein Computer führt eine komplexe Verarbeitung durch und eine Person schaltet den Computer aufgrund eines Ausfalls des Stromnetzes auf eine alternative Stromversorgung um, sodass die Verarbeitung ohne Unterbrechung fortgesetzt wird ; (ii) der Computer ist dabei, eine ressourcenintensive Verarbeitung durchzuführen, und die Person bestätigt, dass die ressourcenintensive Verarbeitung tatsächlich durchgeführt werden soll (in diesem Fall erfolgt der Bestätigungsprozess, isoliert betrachtet, durch wesentliches Eingreifen einer Person, aber die ressourcenintensive Verarbeitung umfasst keinerlei wesentliches Eingreifen durch eine Person, ungeachtet der Ja-Nein-Bestätigung, die durch eine Person erfolgen muss); und (iii) durch Verwenden einer Maschinenlogik hat ein Computer eine gewichtige Entscheidung getroffen (zum Beispiel, allen Flugzeuge in Erwartung von schlechtem Wetter Startverbot zu erteilen), aber der Computer muss vor dem Umsetzen der gewichtigen Entscheidung eine einfache Ja-Nein-Bestätigung von einer menschlichen Quelle erhalten.
Automatisch: ohne Eingreifen durch eine Person.
Modul/Untermodul: jedes Set von Hardware, Firmware und/oder Software, das funktionell zum Ausführen irgendeiner Funktion arbeitet, ohne Berücksichtigung, ob das Modul: (i) sich in einer einzelnen lokalen Nähe befindet; (ii) über einen weiten Bereich verteilt ist; (iii) sich in einer einzelnen Nähe in einem größeren Abschnitt von Software-Code befindet; (iv) sich in einem einzelnen Abschnitt von Software-Code befindet; (v) sich in einer einzelnen Speichereinheit, einem Arbeitsspeicher oder Medium befindet; (vi) mechanisch verbunden ist; (vii) elektrisch verbunden ist; und/oder (viii) in Datenaustausch verbunden ist.
Computer: jede Einheit mit signifikanten Datenverarbeitungs- und/oder maschinenlesbaren Anweisungslesefähigkeiten, einschließlich, aber nicht beschränkt auf: Desktop-Computer, Mainframe-Computer, Laptop-Computer, Einheiten auf Grundlage von feldprogrammierbarer Gatter-Anordnung (FPGA), Smartphones, Personal Digital Assistants (PDAs), angebaute oder eingefügte Computer, eingebettete einheitenartige Computer, und/oder Einheiten auf Grundlage einer anwendungsspezifischen integrierten Schaltung (ASIC).

Claims

Durch einen Computer umgesetztes Verfahren zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten, wobei das Verfahren aufweist: Initiieren (S255) eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung; Empfangen (S255) von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein der verwalteten Laufzeitanwendung zugehöriges Argument und eine Arbeitsknotenkennung umfasst, die einem Arbeitsknoten, worker node, entspricht, der der verwalteten Laufzeitanwendung zugehörig ist; Lokalisieren (S260) eines ersten Zwischenspeichers für gemeinsam genutzte Klassen, SCC, der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch einen Server verwaltet wird; in Reaktion auf ein Lokalisieren (S260) des ersten SCCs: Senden (S260) des ersten SCCs an einen Client (104), der dem Arbeitsknoten zugehörig ist, und Speichern (S265) des ersten SCCs in einem lokalen SCC-Repository; Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden; Bestimmen (S275), die erste Aktualisierungsanforderung zu akzeptieren; und in Reaktion auf ein Akzeptieren (S275) der ersten Aktualisierungsanforderung: Analysieren (S285) einer Mehrzahl von Aktualisierungsanforderungen, einschließlich der ersten Aktualisierungsanforderung, um analysierte Aktualisierungsanforderungsdaten zu erstellen, Bestimmen (S285), auf Grundlage der analysierten Aktualisierungsanforderungsdaten, dass die analysierten Aktualisierungsanforderungsdaten neue Daten umfassen, die mehr als einer Aktualisierungsanforderung der Mehrzahl von Aktualisierungsanforderungen gemeinsam sind, und Modifizieren (S290) des ersten SCCs auf Grundlage der neuen Daten, um einen zweiten SCC zu generieren.
Verfahren nach Anspruch 1, wobei der Typ der verwalteten Laufzeitanwendung auf der Anwendungsabbildkennung beruht, wobei eine Mehrzahl von verwalteten Laufzeitanwendungen, die eine gemeinsame Anwendungsabbildkennung haben, von einem selben Typ sind.
Verfahren nach Anspruch 1, das ferner aufweist: Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die von der verwalteten Laufzeitanwendung stammt und dem ersten SCC zugehörig ist, wobei die erste Aktualisierungsanforderung einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und akkumuliert wurden; Bestimmen (S270), die erste Aktualisierungsanforderung abzulehnen; und in Reaktion auf ein Ablehnen der ersten Aktualisierungsanforderung, Senden (S280) eines zweiten SCCs an den Client (104).
Verfahren nach Anspruch 3, wobei ein Bestimmen, die erste Aktualisierungsanforderung abzulehnen, auf einem Faktor beruht, der aus der Gruppe ausgewählt wurde, die umfasst: i. der erste SCC ist voll; ii. die verwaltete Laufzeitanwendung gibt einen Fehlercode zurück; iii. die verwaltete Laufzeitanwendung gibt einen unerwarteten Rückgabecode zurück; und iv. der zweite SCC ist neuer als der erste SCC.
Verfahren nach Anspruch 1, wobei der Server auf einem dedizierten Knoten platziert ist, der von dem Arbeitsknoten getrennt und verschieden ist.
Verfahren nach Anspruch 1, wobei der Server eine Aufgabe durchführt, die aus der Gruppe ausgewählt wird, die umfasst: Bereitstellen des Containers mit dem ersten SCC in Verbindung mit dem Start der verwalteten Laufzeitanwendung; Austauschen von Daten mit einem Container-Orchestrierungssystem, um Informationen in Bezug auf verwaltete Laufzeitanwendungsabbilder innerhalb eines Geltungsbereichs des Servers zu erhalten; Verwalten des zentralen SCC-Repositorys; Zuordnen des Containers zu einem entsprechenden Client (104); und Aktualisieren des ersten SCCs gemäß einer Aktualisierungsanforderung, die von dem Client (104) empfangen wurde.
Computerprogrammprodukt zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten, die aufweisen: ein oder mehrere durch einen Computer lesbare Speichermedien und Programmanweisungen, die insgesamt auf dem einen oder den mehreren durch einen Computer lesbaren Speichermedien gespeichert sind, wobei die Programmanweisungen Anweisungen aufweisen, die programmiert sind zum Durchführen von: Initiieren (S255) eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung; Empfangen (S255) von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein Argument, das der verwalteten Laufzeitanwendung zugehörig ist, und eine Arbeitsknotenkennung umfasst, die einem Arbeitsknoten entspricht, der der verwalteten Laufzeitanwendung zugehörig ist; Lokalisieren (S260) eines ersten Zwischenspeichers für gemeinsam genutzte Klassen, eines ersten SCCs, der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch einen Server verwaltet wird; in Reaktion auf ein Lokalisieren (S260) des ersten SCCs: Senden (S260) des ersten SCCs an einen Client (104), der dem Arbeitsknoten zugehörig ist, und Speichern (S265) des ersten SCCs in einem lokalen SCC-Repository; Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden; Bestimmen (S275), die erste Aktualisierungsanforderung zu akzeptieren; und In Reaktion auf ein Akzeptieren (S275) der ersten Aktualisierungsanforderung: Analysieren (S285) einer Mehrzahl von Aktualisierungsanforderungen, einschließlich der ersten Aktualisierungsanforderung, um analysierte Aktualisierungsanforderungsdaten zu erstellen, Bestimmen (S285), auf Grundlage der analysierten Aktualisierungsanforderungsdaten, dass die analysierten Aktualisierungsanforderungsdaten neue Daten umfassen, die mehr als einer Aktualisierungsanforderung von der Mehrzahl von Aktualisierungsanforderungen gemeinsam sind, und Modifizieren (S290) des ersten SCCs auf Grundlage der neuen Daten, um einen zweiten SCC zu generieren.
Computerprogrammprodukt nach Anspruch 7, wobei der Typ der verwalteten Laufzeitanwendung auf der Anwendungsabbildkennung beruht, wobei eine Mehrzahl von verwalteten Laufzeitanwendungen, die eine gemeinsame Anwendungsabbildkennung haben, von einem selben Typ sind.
Computerprogrammprodukt nach Anspruch 7, das ferner Anweisungen aufweist, die programmiert sind zum Durchführen von: Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die von der verwalteten Laufzeitanwendung stammt und dem ersten SCC zugehörig ist, wobei die erste Aktualisierungsanforderung einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden. Bestimmen (S270), die erste Aktualisierungsanforderung abzulehnen; und in Reaktion auf ein Ablehnen der ersten Aktualisierungsanforderung, Senden (S280) eines zweiten SCCs an den Client (104).
Computerprogrammprodukt nach Anspruch 9, wobei ein Bestimmen, die erste Aktualisierungsanforderung abzulehnen, auf einem Faktor beruht, der aus der Gruppe ausgewählt wurde, die umfasst: i. der erste SCC ist voll; ii. die verwaltete Laufzeitanwendung gibt einen Fehlercode zurück; iii. die verwaltete Laufzeitanwendung gibt einen unerwarteten Rückgabecode zurück; und iv. der zweite SCC ist neuer als der erste SCC.
Computerprogrammprodukt nach Anspruch 7, wobei der Server auf einem dedizierten Knoten platziert ist, der von dem Arbeitsknoten getrennt und verschieden ist.
Computerprogrammprodukt nach Anspruch 7, wobei der Server eine Aufgabe durchführt, die aus der Gruppe ausgewählt wird, die umfasst: Bereitstellen des Containers mit dem ersten SCC in Verbindung mit dem Start der verwalteten Laufzeitanwendung; Austauschen von Daten mit einem Container-Orchestrierungssystem, um Informationen in Bezug auf verwaltete Laufzeitanwendungsabbilder innerhalb eines Geltungsbereichs des Servers zu erhalten; Verwalten des zentralen SCC-Repositorys; Zuordnen des Containers zu einem entsprechenden Client (104); und Aktualisieren des ersten SCCs gemäß einer Aktualisierungsanforderung, die von dem Client (104) empfangen wurde.
Computersystem zum gemeinsamen Nutzen von zwischengespeicherten Klassendaten, die aufweisen: einen Prozessorsatz (204); und ein oder mehrere durch einen Computer lesbare Speichermedien; wobei: der Prozessorsatz (204) strukturiert, angeordnet, verbunden und/oder programmiert ist, um Programmanweisungen auszuführen, die auf dem einen oder den mehreren durch einen Computer lesbaren Speichermedien gespeichert sind; und die Programmanweisungen Anweisungen umfassen, die programmiert sind zum Durchführen von: Initiieren (S255) eines Starts einer verwalteten Laufzeitanwendung in einem Container einer containerisierten Umgebung; Empfangen (S255), durch einen zentralen Server eines Orchestrators zum gemeinsamen Nutzen von Klassen, CSO (310), von Informationen in Bezug auf die verwaltete Laufzeitanwendung, die eine Anwendungsabbildkennung, ein Argument, das der verwalteten Laufzeitanwendung zugehörig ist, und eine Arbeitsknotenkennung umfassen, die einem Arbeitsknoten entspricht, der der verwalteten Laufzeitanwendung zugehörig ist; Lokalisieren (S260) eines ersten Zwischenspeichers für gemeinsam genutzte Klassen, eines ersten SCCs, der durch eine Kombination der Anwendungsabbildkennung und des Arguments in einem zentralen SCC-Repository gekennzeichnet ist, das durch den zentralen CSO-Server verwaltet wird; In Reaktion auf ein Lokalisieren (S260) des ersten SCCs: Senden (S260) des ersten SCCs an einen CSO-Client (104), der dem Arbeitsknoten zugehörig ist, und Speichern (S265) des ersten SCCs in einem lokalen SCC-Repository; Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden; Bestimmen (S275), die erste Aktualisierungsanforderung zu akzeptieren; und in Reaktion auf ein Akzeptieren (S275) der ersten Aktualisierungsanforderung: Analysieren (S285) einer Mehrzahl von Aktualisierungsanforderungen, einschließlich der ersten Aktualisierungsanforderung, um analysierte Aktualisierungsanforderungsdaten zu erstellen, Bestimmen (S285), auf Grundlage der analysierten Aktualisierungsanforderungsdaten, dass die analysierten Aktualisierungsanforderungsdaten neue Daten umfassen, die mehr als einer Aktualisierungsanforderung der Mehrzahl von Aktualisierungsanforderungen gemeinsam sind, und Modifizieren (S290) des ersten SCCs auf Grundlage der neuen Daten, um einen zweiten SCC zu generieren.
Computersystem nach Anspruch 13, wobei der Typ der verwalteten Laufzeitanwendung auf der Anwendungsabbildkennung beruht, wobei eine Mehrzahl von verwalteten Laufzeitanwendungen, die eine gemeinsame Anwendungsabbildkennung haben, von einem selben Typ sind.
Computersystem nach Anspruch 13, das ferner Anweisungen aufweist, die programmiert sind zum Durchführen von: Empfangen (S270), von dem Client (104), einer ersten Aktualisierungsanforderung, die von der verwalteten Laufzeitanwendung stammt und dem ersten SCC zugehörig ist, wobei die erste Aktualisierungsanforderung einem Typ der verwalteten Laufzeitanwendung zugehörig ist, die die Anwendungsabbildkennung, das Argument, Informationen in Bezug auf den Arbeitsknoten, zusätzliche Klassendaten, Ahead-of-Time-kompilierte Daten und Ausführungsdaten umfasst, die im Laufe der Zeit in Bezug auf den ersten SCC generiert und angesammelt wurden. Bestimmen (S270), die erste Aktualisierungsanforderung abzulehnen; und in Reaktion auf ein Ablehnen der ersten Aktualisierungsanforderung, Senden (S280) eines zweiten SCCs an den Client (104).
Computersystem nach Anspruch 15, wobei ein Bestimmen, die erste Aktualisierungsanforderung abzulehnen, auf einem Faktor beruht, der aus der Gruppe ausgewählt wurde, die umfasst: i. der erste SCC ist voll; ii. die verwaltete Laufzeitanwendung gibt einen Fehlercode zurück; iii. die verwaltete Laufzeitanwendung gibt einen unerwarteten Rückgabecode zurück; und iv. der zweite SCC ist neuer als der erste SCC.
Computersystem nach Anspruch 13, wobei der Server eine Aufgabe durchführt, die aus der Gruppe ausgewählt wird, die umfasst: Bereitstellen des Containers mit dem ersten SCC in Verbindung mit dem Start der verwalteten Laufzeitanwendung; Austauschen von Daten mit einem Container-Orchestrierungssystem, um Informationen in Bezug auf verwaltete Laufzeitanwendungsabbilder innerhalb eines Geltungsbereichs des Servers zu erhalten; Verwalten des zentralen SCC-Repositorys; Zuordnen des Containers zu einem entsprechenden Client (104); und Aktualisieren des ersten SCCs gemäß einer Aktualisierungsanforderung, die von dem Client (104) empfangen wurde.