DE102016105589A1 - Anwenden von Firmware-Updates in einem System mit Null-Stillstandszeit durch wahlweise Abschalten und Einschalten von Hardware unter Verwenden einer Hypervisor-Schicht - Google Patents

Anwenden von Firmware-Updates in einem System mit Null-Stillstandszeit durch wahlweise Abschalten und Einschalten von Hardware unter Verwenden einer Hypervisor-Schicht Download PDF

Info

Publication number
DE102016105589A1
DE102016105589A1 DE102016105589.1A DE102016105589A DE102016105589A1 DE 102016105589 A1 DE102016105589 A1 DE 102016105589A1 DE 102016105589 A DE102016105589 A DE 102016105589A DE 102016105589 A1 DE102016105589 A1 DE 102016105589A1
Authority
DE
Germany
Prior art keywords
server
hardware component
hypervisor
firmware
firmware update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102016105589.1A
Other languages
English (en)
Inventor
Sumeet Kochar
Randolph S. Kolvick
John M. Borkenhagen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lenovo Singapore Pte Ltd
Original Assignee
Lenovo Singapore Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lenovo Singapore Pte Ltd filed Critical Lenovo Singapore Pte Ltd
Publication of DE102016105589A1 publication Critical patent/DE102016105589A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/654Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

Ein Verfahren umfasst ein Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt, und ein Ausführen eines einzelnen Betriebssystems und wenigstens einer Applikation über den Scale-up Hypervisor hinaus umfasst. Das Verfahren umfasst ferner ein Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes zur Verfügung steht. Der Scale-up Hypervisor entfernt alle Last von der ersten Hardwarekomponente, und das identifizierte Firmware-Update wird auf die erste Hardwarekomponente angewandt, während die erste Hardwarekomponente inaktiv ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen. Vorzugsweise kann das Verfahren verwendet werden, um Firmware-Updates sequentiell auf verschiedene Hardwarekomponenten über die Vielzahl der Server hinweg anzuwenden, ohne jemals die gesamte Vielzahl der Server abzuschalten.

Description

  • Hintergrund
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf Verfahren und Systeme zum Aktualisieren von Firmware in den Hardwarekomponenten eines Servers.
  • Hintergrund der relevanten Technik
  • Ein Datenzentrum ist eine Anlage, bei der Computerausstattung und darauf bezogene Infrastruktur für einen zentralen Betrieb und Management konsolidiert sind. Computerausstattung kann in einem Datenzentrum untereinander verbunden sein, um große leistungsstarke Computersysteme herzustellen, die in der Lage sind, große Mengen von Daten für Firmen wie große Unternehmen, Web-Hostdienste und Internet-Suchmaschinen zu speichern und zu verarbeiten. Ein Datenzentrum kann irgendeine Anzahl von Gestellen enthalten, wobei jedes in der Lage ist, eine große Anzahl von Diensten und unterstützender Ausstattung, wie Schaltern, Netzgeräten, Netzwerkkommunikationsschnittstellen, Umgebungssteuerungen, und Sicherheitsgeräten zu enthalten. Server und unterstützende Ausstattung sind typischerweise in Gestell-montierten Mehrfach-Server-Gehäusen (z.B. einem mehr-flügeligen Chassis) und in einer Konfiguration mit hoher Dichte angeordnet. So viele Server und Gestell-montierte Gehäuse wie benötigt können untereinander verbunden werden, um ein System, das die gewünschte Ausführung aufweist, zu erzeugen.
  • Einzelpersonen und Geschäftsleute wünschen, dass ihre Computerapplikationen keine Ausfallzeiten erfahren, um Beeinflussungen ihrer Arbeitsaufgaben, ihrer Geschäftsobjekte und Kundenanfragen zu vermeiden. Dieses übt Druck darauf aus, die Wartungsintervalle klein zu halten, so dass benötigte Wartung und Updates oft so lange wie möglich verzögert werden. Zum Beispiel kann ein Server oder ein Cluster von Servern fortgesetzt eine Firmware-Version ausführen, die längst überholt ist. Ein Hauptgrund Firmware nicht zu aktualisieren ist, dass die Aufgabe Firmware zu aktualisieren typischerweise eine beträchtliche Zeitdauer erfordert, um abgeschlossen zu werden, und dann einen Neustart des Servers erfordert. Unglücklicherweise bedeutet das Fortsetzen des Nutzens der alten Firmware, dass die Systemzuverlässigkeit mit der Zeit abnimmt, wenn kritische Fehlerbehebungen nicht angewandt werden. Diese Art der Abnahme der Zuverlässigkeit ist besonders bedenklich für komplexe skalierte Systeme, bei denen kritische Fehlerbehebungen häufig herausgegeben werden. Ein komplexes skaliertes System zum Aktualisieren von Firmware offline zu nehmen kann in einer vollständigen Unterbrechung des Dienstes resultieren, weil es unerschwinglich teuer ist, ein redundantes skaliertes System zu diesem Zweck zu installieren.
  • Kurze Zusammenfassung
  • Eine Ausführungsform der vorliegenden Erfindung stellt ein Verfahren zur Verfügung, das ein Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt, und ein Ausführen eines einzelnen Betriebssystems und wenigstens einer Applikation über den Scale-up Hypervisor hinaus umfasst. Das Verfahren umfasst ferner ein Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes verfügbar ist. Der Scale-up Hypervisor entfernt alle Last von der ersten Hardwarekomponente und das identifizierte Firmware-Update wird auf die erste Hardwarekomponente angewandt, während die erste Hardwarekomponente inaktiv ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen.
  • Eine andere Ausführungsform der vorliegenden Erfindung stellt ein Computerprogrammprodukt zur Verfügung zum Anwenden eines Firmware-Updates, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium aufweist, das Programminstruktionen aufweist, die darin enthalten sind, und wobei die Programminstruktionen durch einen Prozessor ausführbar sind, um den Prozessor zu veranlassen, das Verfahren auszuführen. Das Verfahren umfasst ein Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt, und ein Ausführen eines einzelnen Betriebssystems und wenigstens einer Applikation über den Scale-up Hypervisor hinaus. Das Verfahren umfasst ferner ein Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes zur Verfügung steht. Der Scale-up Hypervisor entfernt alle Last von der ersten Hardwarekomponente und das identifizierte Firmware-Update wird auf die erste Hardwarekomponente angewandt, während die erste Hardwarekomponente inaktiv ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen.
  • Kurze Beschreibung der verschiedenen Ansichten der Zeichnungen
  • 1 ist ein Diagramm, eines Computer-Clusters unter Verwenden eines Scale-up Hypervisors, der geeignet ist zum Aktualisieren von Firmware an verschiedenen Computerknoten und Komponenten des Clusters.
  • 2 ist ein Diagramm eines Computerknotens, der verwendet werden kann gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung.
  • 3 ist ein schematisches Diagramm eines Prozesses zum Bestimmen der Zeiteinteilung und des Umfangs des Firmware-Updates.
  • 4 ist ein schematisches Diagramm eines Out-of-Band-(OOB)Prozesses zum Aktualisieren von Firmware über den Baseboard-Management-Controller (BMC).
  • 5 ist ein schematisches Diagramm eines In-Band-(IB)Prozesses zum Aktualisieren von Firmware über das Betriebssystem (OS, operating system).
  • 6 ist ein schematisches Diagramm eines In-Band-(IB)Prozesses zum Aktualisieren von Firmware über das Betriebssystem (OS) und den Baseboard-Management-Controller (BMC).
  • 7 ist eine Tabelle, die ein Firmware-Update-Paket darstellt.
  • 8 ist ein Satz von Tabellen, die vitale Produktdaten (VPD) für jeden Server oder Computerknoten darstellen, einschließlich einer Identifizierung der installierten Firmwareversion für jedes Hardwaregerät, das Firmware verwendet.
  • 9A–D sind schematische Diagramme, die einen Prozess darstellen zum Entfernen von Last von einem Serverelement (9A), zum Setzen des Serverelements in den Offline-Modus (9B), zum Aktualisieren der Firmware auf dem Serverelement (9C) und zum Zurückbringen des Serverelements in den Online-Modus, um Last zu handhaben (9D).
  • 10 ist ein Flussdiagramm eines Verfahrens des sequentiellen Aktualisierens von Firmware auf einer Vielzahl von Serverelementen.
  • Detaillierte Beschreibung
  • Eine Ausführungsform der vorliegenden Erfindung stellt ein Verfahren zur Verfügung, das ein Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt, und ein Ausführen eines einzelnen Betriebssystems und wenigstens eine Applikation über den Scale-up Hypervisor hinaus umfasst. Das Verfahren umfasst ferner ein Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes verfügbar ist. Der Scale-up Hypervisor entfernt alle Last von der ersten Hardwarekomponente und das identifizierte Firmware-Update wird auf die erste Hardwarekomponente angewandt, während die erste Hardwarekomponente leer ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen.
  • Ein Scale-up Hypervisor kann auf einem Serverkomplex ausgeführt werden, einschließlich eines einzelnen Servers oder einen Serverkomplex, der eine Vielzahl von Servern einschließt, die einen großen symmetrischen Multi-Prozessor (SMP, symmetric multi-processor) bilden, der wie ein einzelner Server für das Betriebssystem (OS) erscheint. Darauf wird manchmal als SMP-Skalierung Bezug genommen. Ausführungsformen der vorliegenden Erfindung verwenden den Scale-up Hypervisor in einem Verfahren zum Anwenden von Firmware-Updates auf irgendeine Hardwarekomponente in dem Serverkomplex. Wie hierin offenbart, kann der Scale-up Hypervisor Last von irgendeiner Hardwarekomponente oder einem Server entfernen, um ein Aktualisieren oder Reparieren der relevanten Firmware unter Fortsetzen des Ausführens des Betriebssystems und einer Applikation auf dem Serverkomplex zu erleichtern. Mit anderen Worten, das identifizierte Firmware-Update kann auf eine erste Hardwarekomponente angewandt werden, ohne dass die Applikation irgendeine Stillstandszeit erfährt. Ein vorteilhafter Aspekt der verschiedenen Ausführungsformen der Erfindung ist, dass Firmware-Updates sequentiell auf Hardwarekomponenten über den Serverkomplex hinweg angewandt werden können.
  • Optional kann das Verfahren ferner umfassen, dass der Scale-up Hypervisor Last der ersten Hardwarekomponente zuordnet, nachdem das identifizierte Firmware-Update der ersten Hardwarekomponente abgeschlossen ist. Als ein Ergebnis wird die Kapazität der ersten Hardwarekomponente nur für eine kurze Zeitdauer nicht verfügbar sein, während die Firmware der ersten Hardwarekomponente aktualisiert wird. In einer weiteren Option kann das Verfahren ferner ein Identifizieren eines Firmware-Updates, das für eine zweite Hardwarekomponente innerhalb des Serverkomplexes verfügbar ist, das Entfernen der Last von der zweiten Hardwarekomponente zu einer oder mehreren anderen Hardwarekomponenten innerhalb des Serverkomplexes durch den Scale-up Hypervisor, und ein Anwenden des identifizierten Firmware-Updates auf die zweite Hardwarekomponente, während der Hypervisor fortsetzt, das Betriebssystem und die Applikation auf dem Serverkomplex auszuführen, umfassen. In ähnlicher Weise können Verfahren der vorliegenden Erfindung sequentiell Last von irgendeiner oder mehreren Hardwarekomponenten entfernen und die Firmware auf der einen oder mehreren Hardwarekomponenten aktualisieren, bevor ein Aktualisieren der Firmware auf irgendeiner weiteren Hardwarekomponente stattfindet. Es sollte erkennbar sein, dass, wenn der Serverkomplex eine Vielzahl von Servern einschließt und Last von dem gesamten Server entfernt wird, dann ein Firmware-Update simultan auf irgendeinem oder allen der Hardwarekomponenten auf dem Server angewandt werden kann.
  • In einer anderen Ausführungsform kann das Verfahren ferner umfassen, dass der Scale-up Hypervisor alle Last von einem ersten Server innerhalb des Serverkomplexes entfernt, und dann den ersten Server in einen Offline-Modus stellt, nachdem alle Last von dem ersten Server entfernt wurden. Nachdem das identifizierte Firmware-Update abgeschlossen wurde, kann das Verfahren den ersten Server zurück in den Online-Modus bringen und die Last dem ersten Server zuordnen. Optional kann das identifizierte Firmware-Update auf einen Prozessor des ersten Servers angewandt werden. Ferner kann es wünschenswert sein, wenn ein Server in den Offline-Modus gebracht ist, die Firmware-Updates auf irgendeine der Hardwarekomponenten auf diesem Server, für die ein Firmware-Update verfügbar ist, anzuwenden. Mit dem Server im Offline-Modus ist nach wie vor Leistung für das Plattform-Management-Modul verfügbar (nämlich den Baseboard-Management-Controller (BMC) oder das integrierte Management-Modul (IMM)) und es ist möglich, irgendein Firmware-Update anzuwenden, das durch das Plattform-Management-Modul gehandhabt werden kann. Zum Beispiel kann der Administrator Instruktionen und Firmware-Updates zu dem Plattform-Management-Modul über ein Netzwerk kommunizieren.
  • Das Verfahren kann ferner umfassen, dass der Scale-up Hypervisor Systemressourcen-Auslastungsdaten für jeden Server oder jede Hardwarekomponente zu einem Plattform-Management-Modul auf jeden Server reicht. Derartige Daten können in regelmäßigen Intervallen in Reaktion auf eine Anfrage von dem Plattform-Management-Modul, oder in Reaktion auf das Erreichen eines vorbestimmten Schwellwerts der Systemressourcen-Auslastung, überführt werden. Optional kann das Verfahren das Update der Firmware in Reaktion auf die Systemressourcen-Auslastung für alle Server initiieren, die eine geringere als eine vorbestimmte Auslastung aufweisen. Noch weiterhin kann die Systemressourcen-Auslastung als eine Funktion der Zeit des Tages, des Tages der Woche oder des Tages des Jahres modelliert werden, so dass eine geeignete Zeit zum Anwenden eines Firmware-Updates vorbestimmt oder geplant werden kann. Ein derartiges Modellieren kann durch ein Administratormodul unter Verwenden von Systemressourcen-Auslastungsdaten, die von dem Scale-up Hypervisor über das Betriebssystem des Plattform-Management-Moduls empfangen werden, vorbereitet sein. Ein bevorzugtes Verfahren umfasst ein Anfragen des Plattform-Management-Moduls, eine gegenwärtige Systemressourcen-Auslastung zu einer Zeit zu berichten, zu der die Modellierung von der Systemressourcen-Auslastung erwartet, geringer zu sein als eine vorbestimmte Systemressourcen-Auslastung, und ein Initiieren des Firmware-Updates, falls das Plattform-Management-Modul zeigt, dass die gegenwärtige Systemressourcen-Auslastung geringer als eine vorbestimmte Systemressourcen-Auslastung ist. In einer speziellen Option kann das Plattform-Management-Modul den Scale-up Hypervisor anfordern, um die Systemressourcen-Auslastung für eine oder mehrere Hardwarekomponenten, die durch das Administratormodul als ein Firmware-Update verfügbar zu haben identifiziert sind, bereitzustellen.
  • Ausführungsformen der Erfindung können umfassen, dass das Betriebssystem ein Firmware-Update für eine Hardwarekomponente des ersten Servers anwendet. Darüber hinaus kann das Plattform-Management-Modul ein Firmware-Update auf eine zweite Hardwarekomponente des ersten Servers anwenden. Irgendwelche individuellen Firmware-Updates können entweder durch das Betriebssystem oder durch das Plattform-Management-Modul angewendet werden, in Abhängigkeit von der Konfiguration des Servers. Darüber hinaus kann ein Firmware-Update-Paket Firmware-Updates für mehrere Hardwarekomponenten eines Servers einschließen, die durch das Betriebssystem, das Plattform-Managment-Modul oder beide, das Betriebssystem und das Plattform-Management-Modul, angewandt werden können. Es sollte erkennbar sein, dass einige Hardwarekomponenten eines Servers nur in der Lage sein können, ein Firmware-Update durch das Betriebssystem zu empfangen und andere Hardwarekomponenten des Servers können nur in der Lage sein, ein Firmware-Update durch das Plattform-Management-Modul zu empfangen. Zusätzlich können bestimmte Hardwarekomponenten wie der Prozessor nur ein Firmware-Update empfangen, während der Server in einem Offline-Modus ist.
  • Der Administrator kann die Firmwareversion der auf einer Hardwarekomponente installierten Firmware mit der Firmwareversion eines Firmware-Updates, das für die Hardwarekomponente zur Verfügung steht, vergleichen, um zu bestimmen, ob die Firmware der Hardwarekomponente zu aktualisieren ist. Informationen, welche die gegenwärtig installierten Firmwareversionen von verschiedenen Hardwarekomponenten betreffen, können dem Administrator von dem Plattform-Management-Modul berichtet werden, welches diese Informationen als vitale Produktdaten speichert. Ein Firmware-Update-Paket, das dem Administrator zur Verfügung steht, wird aktualisierte Firmware-Versionen für ein oder mehrere Hardwarekomponententypen, Modelle oder Versionen umfassen. Deshalb kann der Administrator bestimmen, ob irgendeines der verfügbaren Hardware-Updates auf irgendeine der Hardwarekomponenten eines bestimmten der Server angewandt werden sollte.
  • Der Scale-up Hypervisor ist für ein Verschieben der Last verantwortlich, um ein Firmware-Update einer Hardwarekomponente zu erleichtern. Vorzugsweise wird ein Firmware-Update verzögert oder für die Zeitdauer geplant, wenn die Systemressourcen-Auslastung niedrig genug ist, so dass ein oder mehrere Hardwarekomponenten in den Offline-Modus zu schalten nicht in einer bemerkenswerten Reduktion der Leistung resultiert. Nach einem Bestimmen, dass ein Hardware-Update für eine besondere Hardwarekomponente anzuwenden ist, kann der Scale-up Hypervisor den Gebrauch einer ersten Hardwarekomponente eines ersten Servers verhindern, während ein Firmware-Update auf die Hardwarekomponente angewandt wird. Während der Scale-up Hypervisor alle Last von einem Server entfernen kann und den Server in den Offline-Modus versetzen kann, ist es dem Scale-up Hypervisor auch möglich, den Gebrauch von einem oder mehreren Hardwarekomponenten zu verhindern, ohne alle Last weg von dem ersten Server zu migrieren und ohne den ersten Server in den Offline-Modus zu versetzen. Speziell kann der Scale-up Hypervisor Last unter den Hardwarekomponenten des gleichen Typs innerhalb eines gegebenen Servers bewegen, wie ein Entfernen von Last von einem Prozessor in einem Mehrfach-Prozessor-Server. Es sollte erkennbar sein, dass ein Bewegen von Last, die innerhalb eines Servers lokalisiert ist, einem Bewegen von Last von einem zu einem anderen (fernen) Server innerhalb des Komplexes aufgrund der reduzierten Latenz vorzuziehen ist, um die Aufgabe abzuschließen und den Gebrauch einer Netzwerk-Bandbreite zu vermeiden.
  • Eine andere Ausführungsform der vorliegenden Erfindung stellt ein Computerprogrammprodukt zum Anwenden von Firmware-Updates zur Verfügung, wobei das Computerprogrammprodukt ein computerlesbares Speichermedium aufweist, das Programminstruktionen darin enthaltend besitzt, und wobei die Programminstruktionen durch einen Prozessor ausführbar sind, um den Prozessor zu veranlassen, ein Verfahren auszuführen. Das Verfahren umfasst ein Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt, und ein Ausführen eines einzelnen Betriebssystems und wenigstens einer Applikation über den Scale-up Hypervisor hinaus. Das Verfahren umfasst ferner ein Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes zur Verfügung steht. Der Scale-up Hypervisor entfernt alle Last von der ersten Hardwarekomponente und das identifizierte Firmware-Update wird auf die erste Hardwarekomponente angewandt, während die erste Hardwarekomponente inaktiv ist, und der Hypervisor das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen fortsetzt.
  • Das vorhergehende Computerprogrammprodukt kann ferner einen computerlesbaren Programmcode zum Anwenden oder Initiieren von irgendeinem oder mehreren Aspekten der hierin beschriebenen Verfahren umfassen. Dementsprechend wird eine separate Beschreibung der Verfahren nicht in diesem Kontext eines Computerprogrammproduktes reproduziert.
  • 1 ist ein Diagramm eines Systems 10, das einen Serverkomplex einschließt, der einen Scale-up Hypervisor oder eine Hypervisor-Schicht 40 betreibt, die geeignet ist, um Firmware für Hardwarekomponenten über eine Vielzahl von Computerknoten oder Server 20 zu aktualisieren. Die Hypervisor-Schicht 40 spannt sich über die Vielzahl der Server 20 in einem skalierten Komplex, wie einem symmetrischen Mehrfach-Computersystem, und virtualisiert die physikalischen Hardwarekomponenten der Server 20 in die Form einer virtuellen Maschine 42. Der Hypervisor kann jedoch ebenso auf einem einzelnen der Server 20 laufen. Die virtuelle Maschine 42 beherbergt ein Betriebssystem 44, das Applikationen 46 ermöglicht, installiert zu werden und über das Betriebssystem ausgeführt zu werden. Die Hypervisor-Schicht 40 lässt eine Vielzahl der Server 20 für das Betriebssystem 44 als einen einzelnen Server erscheinen. Es ist die Hypervisor-Schicht 40, die verwaltet, wie die Last von einer Applikation 46 verschiedenen Servern oder Hardwarekomponenten innerhalb der Server zugewiesen wird. Dementsprechend kann die Hypervisor-Schicht Last von einer ausgewählten Hardwarekomponente, wenn gewünscht, entfernen, um ein Hardware-Update zu erleichtern.
  • In dem System 10 sind die individuellen Server 20 für eine Kommunikation über ein Netzwerk 48 verbunden, welches vorzugsweise ein privates Netzwerk wie ein Ethernet-Netzwerk ist. Das Netzwerk ermöglicht den Servern, Aufgaben zu koordinieren, wie ein Aufrechterhalten gespiegelter Speicher unter den Servern. Das gleiche Netzwerk 48 oder ein separates Netzwerk können für Out-of-Band-(OOB)Kommunikationen zwischen einem Administratormodul (oder einfach “Administrator”) 50 und einem Plattform-Management-Modul, hier als ein Baseboard-Management-Modul (BMC) oder integriertes Managementmodul (IMM) 30 gezeigt, für jeden Server 20 verwendet werden. Zum Beispiel kann die OOB-Kommunikation über das Netzwerk durch den Administrator 50 verwendet werden, um Systemquellen-Gebrauchsdaten von dem BMC 30 zu erwerben und Firmware-Updates hinunter zu dem BMC 30 zu schieben. Der Administrator 50 kann auch In-Band (IB) mit dem Betriebssystem 44 kommunizieren, um Firmware-Updates bereitzustellen. Weiterhin kann sich der Administrator in ähnlicher OOB- und/oder IB-Kommunikation mit anderen vergrößerten Systemen 52 derart befinden, dass der Administrator Firmware-Updates für viele vergrößerte Systeme koordinieren kann. Ohne eine Begrenzung wird gezeigt, dass der Administrator 50 Firmware-Updates 54 und Update-Logik 56 aufweist.
  • Der Computerknoten oder Server 20 umfasst einen Prozessor oder eine zentrale Verarbeitungseinheit (CPU) 21, einen Speicher 22, eine Netzwerkschnittstelle 23, einen PCI-Adapter 24 und eine vereinheitlichte ausdehnbare Firmware-Schnittstelle (UEFI) 25, die jeweils mit einem System-Bus verbunden sind. Das Plattform-Management-Modul, das als ein Baseboard-Management-Controller (BMC) oder integriertes Management-Modul (IMM) 30 gezeigt wird, umfasst einen Service-Prozessor, der verschiedenen Funktionen dient, einschließlich der Überwachungssystemausführung. Für die Zwecke der Ausführungsformen der vorliegenden Erfindung führt das BMC 30 eine Plattform-Management-Logik 32 aus und weist einen Zugriff auf die Firmware-vitalen-Produktdaten (VPD, vital product data) 34 für die Hardwarekomponenten des Servers 20 auf. Das BMC 30 umfasst auch eine Schnittstelle, wie eine Tastatur-Steuerart-(KCS)Schnittstelle oder die schnellere “LAN über USB” Schnittstelle 36, zu der CPU 21 auf. Die KCS und LAN über USB sind In-Band-Schnittstellen, die eine Kommunikation zwischen dem BMC 30 und der CPU 21 ermöglichen, wie für den Hypervisor und die Betriebssystem-Tools, um Updates auf das BMC oder für das BMC herunterzuschieben, um Firmware-Updates auf der CPU anzuwenden. Es sollte erkennbar sein, dass irgendeine spezifische Serverkonfiguration andere oder zusätzliche Kommunikationskanäle einschließt. Zum Beispiel können einige Chipsätze einen Stift einschließen, der für eine Kommunikation mit dem BMC oder einem anderen Plattform-Management-Modul zugeordnet ist.
  • Ein Verwenden einer LAN-über-USB-Schnittstelle ermöglicht In-Band-Kommunikationen mit dem BMC/IMM, ohne dass der BMC/IMM über IPMI-Gerätetreiber verfügen oder USB-Hintergrundroutinen bzw. Daemons aufweisen müsste. Stattdessen präsentiert die BMC/IMM-Hardware auf dem System-Board eine interne Ethernet-NIC von dem BMC/IMM für das Betriebssystem. Das LAN über USB wird auch die “USB-In-Band-Schnittstelle” in der IMM-Web-Schnittstelle genannt. Typischerweise wird eine IMM IP-Adresse für die LAN-über-USB-Schnittstelle als eine statische Adresse von 169.254.95.118 mit einer Hilfsnetz-Maske von 255.255.0.0 eingestellt. Im Fall einer IP-Adressen-Kollision auf dem Netzwerk könnte das IMM eine unterschiedliche IP-Adresse im Bereich von 169.254.xxx.xxx-Bereich erhalten. Weil das IMM eine unterschiedliche IP-Adresse für die LAN-über-USB-Schnittstelle erhalten könnte, verwenden die Lenovo Advanced Settings Utility (ASU) und Firmware Flash Utilities, DSA, und der IBM Director Agent das Service Location Protocol (SLP), um die IMM IP-Adresse zu entdecken. Diese Tools führen eine SLP-Multicast-Discovery auf der LAN-über-USB-Schnittstelle durch. Wenn sie eine Antwort von dem IMM empfangen, erhalten sie die Attribute, welche die IP-Adresse enthalten, die das IMM für die LAN-über-USB-Schnittstelle verwendet.
  • 2 ist ein Diagramm eines Computerknotens oder Servers, der gemäß verschiedener Ausführungsformen der vorliegender Erfindung verwendet werden kann. Der Computerknoten 20 schließt eine Prozessoreinheit 21 ein, die mit einem System-Bus 106 gekoppelt ist. Die Prozessoreinheit 21 kann einen oder mehrere Prozessoren verwenden, von denen jeder einen oder mehrere Prozessorkerne aufweist. Ein optionaler Videoadapter 108, welcher eine Anzeige 22 antreibt/stützt, kann auch mit dem System-Bus 106 gekoppelt sein. Der System-Bus 106 ist über eine Bus-Brücke 112 mit einem Eingabe/Ausgabe-(E/A)Bus 114 gekoppelt, der mit einer E/A-Schnittstelle 116 gekoppelt ist. Die E/A-Schnittstelle 116 ermöglicht eine Kommunikation mit verschiedenen E/A-Geräten, wie einschließlich einer Tastatur 23 und einer Maus 24. Die E/A-Geräte können optional Speichergeräte einschließen, wie CD-ROM-Laufwerke und Multimediaschnittstellen, andere Drucker und externe USB-Port(s). Während das Format der Ports, die mit der E/A-Schnittstelle 116 verbunden sind, irgendein dem Fachmann der Technik von Computerarchitektur bekanntes Format sein kann, sind in einer bevorzugten Ausführungsform einige oder alle dieser Ports universelle Serien-Bus-(USB)Ports 126. Wie gezeigt, ist der Computerknoten 20 in der Lage über ein Netzwerk 48 unter Verwenden einer Netzwerkschnittstelle 23 zu kommunizieren. Das Netzwerk 48 ist vorzugsweise ein privates Netzwerk wie ein Ethernet-LAN.
  • Eine Festplattenschnittstelle 132 ist auch mit dem System-Bus 106 gekoppelt und ist mit der Festplatte 134 über eine Schnittstelle gekoppelt. In einer bevorzugten Ausführungsform ist die Festplatte 134 mit einem Systemspeicher 22 bestückt, welcher auch mit dem System-Bus 106 gekoppelt ist. Der Systemspeicher ist als ein flüchtiger Speicher in einem Computer 100 auf niedrigstem Niveau definiert. Dieser flüchtige Speicher kann zusätzlich höhere Niveaus der flüchtigen Speicher (nicht gezeigt) aufweisen, einschließlich, aber nicht begrenzt auf, Cache-Speicher, Register und Pufferspeicher. Die Daten, die den Systemspeicher 136 belegen, können den Hypervisor 40, das Betriebssystem (OS) 44 und die Applikationsprogramme 46 umfassen. Die Hardwareelemente, die im Computer 20 gezeigt werden, sollen nicht erschöpfend sein, sondern vielmehr Komponenten darstellen, die geeignet sind, die Prozesse eines Computerknotens oder Servers auszuführen.
  • 36 sind Diagramme, die nur bestimmte Dinge und Verbindungen des Systems 10 der 1 zusammen mit Schritten eines Prozesses darstellen. Die Schritte in jeder der 36 sind keine ausschließlichen Verfahren, sondern wurden in getrennte Figuren aufgeteilt, um die Erörterung zu vereinfachen und potentiellen Variationen in den Verfahren der vorliegenden Erfindung hervorzuheben. Darüber hinaus wurden Bezugszeichen der Dinge weggelassen, um nicht von der Darstellung der Schritte wegzuführen. Es ist verständlich, dass die Verfahren auch in Relation zu irgendeinem anderen oder mehreren Servern in einem Serverkomplex ausgeführt werden können.
  • Die allgemeine Strategie, die in diesen Prozessen verwirklicht wird, ist ein Verbrauchen von Host-CPU-Ressourcen, welche für bestehende Last benötigt werden, zu vermeiden. Da das BMC seine eigenen Prozessoren besitzt, die unabhängig von der Host-CPU laufen können, und der Administrator Out-of-Band über das Netzwerk mit dem BMC kommunizieren kann, kann der Administrator Daten von dem BMC sammeln und Firmware-Updates für das BMC zur Verfügung stellen, ohne irgendeinen Einfluss auf die Last zu haben. Wenn das BMC anzeigt, dass der Systemressourcengebrauch ausreichend niedrig ist, kann das Firmware-Update auf zwei unterschiedlichen Wegen oder als Kombination der zwei Wege fortgesetzt werden. In einer ersten Option kann der Administrator das Firmware-Update über das Netzwerk zu dem BMC schicken, welches Firmware-Updates auf bestimmte Hardwarekomponenten wie eine UEFI, FPGA oder dem BMC selbst anwenden kann. In einer zweiten Option kann der Administrator Update-Tools auf das Betriebssystem, das In-Band ausgeführt wird, laden, wobei die Tools ausgeführt werden, um die Firmware-Updates auszuführen. Wenn die Tools als In-Band in dem Gastbetriebssystem ausgeführt werden, kann das Betriebssystem weiterhin bestimmte Firmware-Updates über den In-Band-Kanal, wie einem LAN über USB, zu dem BMC zum Anwenden auf die relevante Hardwarekomponente(n) befördern.
  • 3 ist ein schematisches Diagramm eines Prozesses 60 zum Bestimmen der Zeiteinteilung und des Umfangs eines Firmware-Updates für eine oder mehrere Hardwarekomponenten eines besondern Servers. Es ist ersichtlich, dass der Administrator mit anderen Servern in dem System zusammenwirken kann (siehe 1), um die gleichen oder ähnlichen Prozesse durchzuführen. Im Schritt 61 empfängt der Administrator ein Firmware-Update-Paket. Dieses kann zum Beispiel in Form einer Update-Diskette oder eines Downloads von einer Webseite des Herstellers erhalten werden. Ein typisches Update-Paket umfasst eine Auszeichnungssprachen-(XML, extensible markup language)Definitionsdatei zusammen mit den aktuellen Firmware-Updates. Die XML-Datei aus dem Update-Paket kann ausgelesen werden, um einen Versionsvergleichen, zwischen der Firmwareversion, welche gegenwärtig in dem System installiert ist, und der, welche angefordert wird, um durch das Firmware-Update-Paket ersetzt zu werden, zu erleichtern und zu verifizieren, dass das Firmware-Update auf ein passendes System oder eine passende Hardwarekomponente angewandt wird.
  • Im Schritt 62 stellt das BMC oder ein anderes Plattform-Management-Modul vitale Produktdaten (VPD) für den Administrator zur Verfügung, welche die Firmwareversionen, die gegenwärtig auf den Hardwarekomponenten des relevanten Computerknotens oder Servers installiert sind, aufzählen. Im Schritt 63 führt der Administrator eine Firmware-Versions-Prüfung aus, durch Vergleichen des Firmware-Update-Paketes mit den vitalen Produktdaten. Dementsprechend kann der Administrator jene Hardwarekomponenten des Servers identifizieren, für die ein Firmware-Update verfügbar ist. Wo anwendbar, kann der Administrator auch verschiedene Qualifikationsregeln anwenden, um zu verifizieren, dass das verfügbare Update mit einer Hardwarekomponente kompatibel oder mit vorhergehenden Firmwareversionen kompatibel ist. In einigen Fällen kann es notwendig sein, ein oder mehrere zwischenzeitliche Firmwareversionen anzuwenden, um Inkompatibilitätsschwierigkeiten zu vermeiden.
  • Im Schritt 64 sendet der Administrator dem BMC eine Anfrage nach einem Firmware-Update in Bezug auf die relevante(n) Hardwarekomponente(n). Im Schritt 65 sendet das BMC eine Anfrage nach Systemressourcen-Auslastungsdaten an den Hypervisor, möglicherweise unter Spezifizieren der Hardwarekomponenten, für welche ein Firmware-Update zur Verfügung steht. Dann reagiert der Hypervisor mit Systemressourcen-Auslastungsdaten für die relevante Hardwarekomponente im Schritt 66. Basierend auf einer Bestimmung, ob die Systemressourcenauslastung geringer als ein vorbestimmtes Niveau ist, kann der BMC dem Administrator im Schritt 67 anzeigen, ob es eine geeignete Zeit gibt, um das Firmware-Update anzuwenden oder nicht, und vielleicht, ob irgendein derartiges Firmware-Update In-Band (IB) oder Out-of-Band (OOB) ausgeführt werden sollte. Es sollte erkennbar sein, dass die Anfrage für die Systemressourcenauslastung auf ein oder mehrere Hardwarekomponenten begrenzt ist, für welche ein Firmware-Update zur Verfügung steht, oder die Anfrage nach Systemressourcengebrauch an den gesamten Server gerichtet sein kann.
  • Obwohl nicht speziell in 3 gezeigt, kann der Administrator die Systemressourcenauslastung über eine Zeitdauer modellieren, um abzuwarten bis die Systemressourcenauslastung wahrscheinlich niedrig ist. Abhängig von dem Systemressourcenauslastungsmuster kann der Gebrauch zu einer bestimmten Tageszeit, einer bestimmten Wochenzeit, einer bestimmten Woche oder einem Wochenende eines Jahres usw. niedrig sein und es kann eine dieser Zeitspannen abgewartet werden, um ein Firmware-Update abzufragen.
  • 4 ist ein schematisches Diagramm eines Out-of-Band-(OOB)Prozesses 70 zum Aktualisieren von Firmware über das Baseboard-Management-Controller (BMC). Im Schritt 71 sendet der Administrator das Firmware-Update für eine oder mehrere Hardwarekomponenten zu dem BMC. Im Schritt 72 fordert das BMC, dass der Hypervisor die Last (WL) von der(den) relevanten Hardwarekomponente(n) entfernt. Im Schritt 73 bestätigt der Hypervisor, dass die Last entfernt wurde oder zeigt auf andere Weise an, dass Last auf der (den) relevanten Hardwarekomponente(n) zugelassen sein wird. Zum Beispiel kann die Hypervisor-Schicht die gegenwärtige Last des Servers auf einen oder mehrere andere Server in dem vergrößerten Komplex konsolidieren oder, wenn das gegenwärtige Firmware-Update nur 1 oder 2 Hardwarekomponenten innerhalb des Servers verwendet, dann kann der Hypervisor wahlweise diese Hardwarekomponenten unterbringen und die Last, falls vorhanden, auf eine redundante Ressource innerhalb des vergrößerten Komplexes bewegen, um ein selektives Rücksetzen dieser Hardwarekomponenten zu ermöglichen, ohne zu fordern, dass das gesamte Chassis oder der gesamte vergrößerte Komplex zurückzusetzen ist. Im Schritt 74 wendet das BMC das Firmware-Update auf eine oder mehrere Hardwarekomponente(n), wie die UEFI, das BMC/IMM, die FPGA oder den Chipsatz/die CPU, an. Danach benachrichtigt das BMC den Hypervisor im Schritt 75A, dass das Update derart vervollständigt wurde, dass der Hypervisor die Hardwarekomponente(n) zurück in Dienst stellen kann. Auf ähnliche Weise benachrichtigt der Schritt 75B den Administrator, dass das Firmware-Update vervollständigt wurde. Sowohl die VPD der BMC als auch irgendeine ähnliche Tabelle, die durch den Administrator bereitgestellt wird, können zurückgewonnen werden, um zu reflektieren, dass die relevanten Hardwarekomponenten jetzt auf der neuen Firmware-Version ausgeführt werden.
  • 5 ist ein schematisches Diagramm eines In-Band-(IB) Prozesses 80 für das Aktualisieren von Firmware über das Betriebssystem (OS). Im Schritt 81 sendet der Administrator Firmware-Updates an das Betriebssystem. Im Schritt 82 fordert das Betriebssystem den Hypervisor auf, Last von den relevanten Hardwarekomponenten zu entfernen. Im Schritt 83 bestätigt der Hypervisor, dass die Last entfernt wurde oder zeigt in anderer Weise an, dass die relevanten Hardwarekomponenten zum Empfangen eines Firmware-Updates bereit sind. Im Schritt 84 wendet das Betriebssystem, und/oder ein Update-Tool, das vom Administrator empfangen wird, die Firmware-Updates auf die relevanten Hardwarekomponenten, wie einen PCI-Adapter, an. Dann benachrichtigen die Schritte 85A und 85B den Hypervisor oder den Administrator, dass die Firmware-Updates vervollständigt wurden.
  • 6 ist ein schematisches Diagramm eines In-Band-(IB)Prozesses 90 zum Aktualisieren von Firmware über das Betriebssystem (OS) und den Baseboard-Management-Controller (BMC). Im Schritt 91 sendet der Administrator Firmware-Updates zu dem Betriebssystem. Im Schritt 92 fordert das Betriebssystem den Hypervisor auf, Last von den relevanten Hardwarekomponenten zu entfernen. Im Schritt 93 bestätigt der Hypervisor, dass die Last entfernt wurde oder zeigt in anderer Weise an, dass die relevanten Hardwarekomponenten zum Empfangen eines Firmware-Updates bereit sind. Im Schritt 94 liefert das Betriebssystem, und/oder ein Update-Tool, das vom Administrator empfangen wird, die Firmware-Updates oder wenigstens einen Teil der Firmware-Updates an den BMC aus. Im Schritt 95 wendet das BMC die Firmware-Updates auf die relevanten Hardwarekomponenten, wie die UEFI, das BMC/IMM, die FPGA oder den Chipsatz/die CPU, an. Im Schritt 96 berichtet das BMC an das Betriebssystem, dass die Firmware-Updates vervollständigt wurden und im Schritt 97 berichtet das Betriebssystem dem Administrator, dass die Updates vervollständigt wurden.
  • 7 ist eine Tabelle 54, die ein Firmware-Update-Paket darstellt. Jede Zeile der Tabelle identifiziert ein Hardware-Gerät, die Firmware-Version(en), die in dem Firmware-Update-Paket bereitgestellt wird und kann optional Kompatibilitätsregeln umfassen.
  • 8 ist ein Satz von Tabellen, die vitale Produktdaten (VPD) 34 für jeden Server oder Computerknoten in dem System darstellen. Jede Tabelle identifiziert jedes Hardwaregerät und jede Komponente auf dem speziellen Server, das/die Firmware verwendet, und die Firmware-Version, die auf dieser Hardwarekomponente installiert ist. Zusammen stellen die Tabelle der 7 und die Tabellen der 8 ausreichende Daten zur Verfügung, so dass der Administrator bestimmen kann, welche Hardwaregeräte eine der Firmware-Updates in dem Firmware-Update-Paket benötigt.
  • 9A–D sind schematische Diagramme, die einen Prozess darstellen zum Entfernen einer Last von einem Serverelement (9A), zum Setzen des Serverelements in den Offline-Modus (9B), zum Aktualisieren der Firmware auf dem Serverelement (9C) und zum Zurückbringen des Serverelements in den Online-Modus, um Last zu handhaben (9D).
  • Bezug nehmend auf 9A, ist die Hypervisor-Schicht 40 verantwortlich für ein Migrieren der Last von dem Serverelement 1 zu einem oder mehreren anderen Serverelementen, um ein Anwenden eines Firmware-Updates auf das Serverelement 1 zu erleichtern. Allgemein gesprochen, kann das Serverelement ohne Begrenzung ein ladbarer Knoten (Server), ein oder mehrere Prozessoren innerhalb eines Multiprozessorkomplexes, ein PCI-Express-Adapter, ein Datenspeichergerät, ein spezielles DIMM oder ein Netzgerät sein.
  • 9B zeigt, dass das Serverelement 1 in den Offline-Modus geschaltet werden kann, nachdem die Last von dem Serverelement 1 entfernt wurde. Man beachte, dass alle, viele oder wenigstens einige der anderen Serverelemente weiterhin im Online-Modus bleiben und zum fortgesetzten Abarbeiten einer Last verwendet werden können, wie eine Applikation, die auf dem Betriebssystem 44 ausgeführt wird. Sobald jedoch das Serverelement 1 im Offline-Modus ist, ist die Kapazität des gesamten Systems des Serverelements reduziert, so dass das Verfahren vorzugsweise nur das Serverelement 1 während einer Zeitspanne in den Offline-Modus stellt, in welcher der Systemressourcengebrauch geringer als irgendein vorbestimmtes Niveau ist.
  • 9C zeigt ein Firmware-Update oder eine Aktualisierung, die auf das Serverelement 1, während es im Offline-Modus ist, angewandt wird. Dieses Firmware-Update kann auf irgendeine oder mehrere Hilfskomponenten des Serverelements 1, falls überhaupt, angewandt werden.
  • 9D zeigt, dass, nachdem das Firmware-Update vervollständigt wurde, das Serverelement 1 im laufenden Betrieb hinzugefügt (Hot-Add) oder in anderer Weise in den Online-Modus zurückgebracht wird, so dass der Hypervisor wieder die Last dem Serverelement 1 zuordnen kann. Dies kann eine neue Last oder Last, die von einem anderem Serverelement migriert ist, sein. Es sollte erkennbar sein, dass die Schritte, die in den 9A bis 9D dargestellt sind, dann mit Bezug auf ein anderes der Serverelemente wiederholt werden können, um die Firmware in diesem Serverelement zu aktualisieren. Eine beliebige Anzahl von Wiederholungen kann ausgeführt werden, um ein Verfahren eines sequentiellen Entfernens von Last und ein Aktualisieren der Firmware über einen Abschnitt oder vollständig über den skalierten Komplex hinweg anzuwenden. Durch das sequentielle Aktualisieren von lediglich Hilfsabschnitten des skalierten Komplexes, aber niemals des gesamten Komplexes auf einmal, kann ein Firmware-Update auf den gesamten Komplex angewandt werden, ohne dass der gesamte Komplex in den Offline-Modus versetzt wird oder dass die Last eine Stillstandszeit oder einen wesentlichen Verlust der Qualität erfährt.
  • 10 ist ein Flussdiagramm eines Verfahrens 140 des sequentiellen Aktualisierens von Firmware auf einer Vielzahl von Serverelementen. Nach Empfangen von Firmware-Updates im Schritt 142, bestimmt Schritt 144, ob der gesamte Systemgebrauch größer als ein vorbestimmter Sollwert ist. Wenn dem so ist, dann wartet der Schritt 146 vor einem Zurückkehren zu dem Bestimmungsschritt 144. Wenn die gesamte Systemauslastung nicht größer als ein vorbestimmter Sollwert ist, dann identifiziert der Schritt 148 eine Hardwarekomponente, die ein Firmware-Update benötigt (d.h. ein Firmware-Update ist für diese Hardwarekomponente verfügbar). Wenn der Schritt 150 bestimmt, dass die Last einer ausgewählten Hardwarekomponente nicht geringer ist als ein vorbestimmter Sollwert, dann wird die Komponente beim Schritt 152 übersprungen. Wenn die ausgewählte Hardwarekomponente jedoch Last aufweist, die geringer als der vorbestimmte Sollwert ist, dann wird die Last entfernt und die Hardwarekomponente wird im Schritt 154 in den Offline-Modus gesetzt, das Firmware-Update wird auf die Hardwarekomponente im Schritt 156 angewandt und die ausgewählte Hardwarekomponente wird zurück in den Online-Modus gebracht und die Last im Schritt 158 zugeordnet. Nach entweder dem Schritt 152 oder 158, bestimmt der Schritt 160, ob andere Hardwaregeräte vorhanden sind, die ein Firmware-Update benötigen. Wenn das der Fall ist, dann kehrt das Verfahren zum Schritt 148 zurück, um die nächste Hardwarekomponente, die zu aktualisieren ist, zu identifizieren. Wenn keine anderen Hardwaregeräte zu aktualisieren sind, dann endet das Verfahren.
  • Wie für den Fachmann der Technik ersichtlich, kann die vorliegende Erfindung ein System, ein Verfahren oder ein Computerprogrammprodukt umfassen. Dementsprechend kann die vorliegende Erfindung die Form einer vollständigen Hardwareausführung, einer vollständigen Softwareausführung (einschließlich Firmware, vorhandene Software, Mikro-Code, usw.) oder einer Ausführungsform haben, die Software- und Hardwareaspekte, auf welche alle allgemein hierein als “Schaltung”, “Modul” oder “System” Bezug genommen wird, kombiniert. Darüber hinaus kann die vorliegende Erfindung die Form eines Computerprogrammproduktes, das in einem oder mehreren computerlesbaren Speichermedien enthalten ist, aufnehmen, welche einen computerlesbaren Programmcode darin gespeichert haben.
  • Irgendwelche Kombinationen von einem oder mehreren computerverwendbaren oder computerlesbaren Speichermedien können eingesetzt werden. Das computerverwendbare oder computerlesbare Speichermedium kann zum Beispiel sein, ist aber nicht begrenzt auf, eine elektronische, magnetische, elektromagnetische oder Halbleiter-Vorrichtung oder ein Gerät. Stärker spezifizierte Beispiele (einer nicht erschöpfenden Liste) der computerlesbaren Speichermedien schließen ein: eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM oder Flash-Speicher), einen tragbare Kompaktdiskette-Festwertspeicher (CD-ROM), ein optisches Speichergerät oder ein magnetisches Speichergerät. Das computerverwendbare oder computerlesbare Speichermedium kann sogar Papier sein oder ein anderes geeignetes Medium, auf dem das Programm gedruckt ist, da das Programm elektronisch über zum Beispiel optisches Scannen des Papers oder eines anderen Mediums aufgenommen, dann kompiliert, interpretiert oder auf andere Weise in geeigneter Form, falls notwendig, verarbeitet und dann in einem Computerspeicher gespeichert werden kann. In dem Kontext dieses Dokumentes kann ein computerverwendbares oder computerlesbares Speichermedium irgendein Speichermedium sein, das das Programm enthalten oder für den Gebrauch durch den Computer speichern kann. Ein computerverwendbarer Programmcode, der auf dem computerverwendbaren Speichermedium enthalten ist, kann durch ein sich ausbreitendes Datensignal entweder im Basisband oder als Teil einer Trägerwelle verbreitet werden. Der computerverwendbare Programmcode kann von einem Speichermedium zu einem anderen Speichermedium übertragen werden unter Verwendung irgendeines geeigneten Übertragungsmediums, einschließlich, aber nicht begrenzt auf, drahtlos, drahtgebunden, optische Faserkabel, RF, usw.
  • Ein Computerprogrammcode zum Ausführen der Operationen der vorliegenden Erfindung kann in irgendeiner Kombination von einer oder mehreren Programmsprachen, einschließlich einer objektorientierten Programmsprache wie Java, Smalltalk, C++ oder dergleichen, und konventionellen prozessbezogenen Programmsprachen, wie der "C"-Programmsprache oder ähnliche Programmsprachen geschrieben sein. Der Programmcode kann vollständig auf einem Nutzercomputer, teilweise auf einem Nutzercomputer, als ein allein stehendes Softwarepaket, teilweise auf dem Nutzercomputer und teilweise auf einem fernen Computer oder vollständig auf einem fernen Computer oder Server ausgeführt werden. In dem letzteren Szenario kann der ferne Computer mit dem Nutzercomputer über irgendeine Art von Netzwerk verbunden sein, einschließlich einem Nahbereichsnetzwerk (LAN) oder einem Fernbereichsnetzwerk (WAN) oder die Verbindung kann durch einen externen Computer (zum Beispiel durch das Internet unter Verwenden eines Internet-Service-Providers) ausgeführt werden.
  • Die vorliegende Erfindung wird unten mit Bezug auf Flussdiagrammdarstellungen oder Blockdiagrammen von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es ist verständlich, dass jeder Block der Flussdiagrammdarstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammdarstellungen und/oder Blockdiagrammen durch Computerprogramminstruktionen ausgeführt sein können. Diese Computerprogramminstruktionen können durch einen Prozessor eines Computers für allgemeine Zwecke, eines Computers für spezielle Zwecke oder durch andere programmierbare Datenverarbeitungsvorrichtungen bereitgestellt werden, eine Maschine erzeugen, so dass die Instruktionen, die über den Prozessor des Computers oder anderer programmierbare Datenverarbeitungsvorrichtungen ausgeführt werden, Mittel erzeugen zum Ausführen der Funktionen/Aktionen, die in dem Flussdiagramm und/oder Blockdiagramm-Block oder den Blöcken spezifiziert werden.
  • Diese Computerprogramminstruktionen können auch in einem computerlesbaren Speichermedium gespeichert werden, das einen Computer oder andere programmierbare Datenverarbeitungseinrichtungen anweisen kann, in einer bestimmten Weise zu funktionieren, so dass die Instruktionen, die in dem computerlesbaren Speichermedium gespeichert sind, einen Gegenstand eines Herstellers erzeugen, einschließlich Instruktionsmittel, welche die Funktionen/Aktionen, die in den Flussdiagramm und/oder Blockdiagramm-Block oder den Blöcken spezifiziert sind, einschließen.
  • Die Computerprogramminstruktionen können auch auf einem Computer oder anderen programmierbaren Datenverarbeitungsvorrichtungen geladen sein, um eine Serie von Verfahrensschritten zu verursachen, um auf einem Computer oder einer anderen programmierbaren Vorrichtung einen computerimplementierten Prozess zu erzeugen, so dass Instruktionen, welche auf dem Computer oder einer anderen programmierbaren Vorrichtung durchgeführt werden, Prozesse zum Ausführen der Instruktionen/Aktionen, die in dem Flussdiagramm und/oder Blockdiagramm-Block oder den Blöcken bereitgestellt werden.
  • Das Flussdiagramm und die Blockdiagramme in den Figuren zeigen die Architektur, Funktionalität und den Betrieb der möglichen Ausführungen der Systeme, Verfahren und Computerprogrammprodukte gemäß den verschiedenen Ausführungen der vorliegenden Erfindung dar. In dieser Beziehung kann jeder Block des Flussdiagramms oder der Blockdiagramme ein Modul, Segment oder einen Abschnitt eines Codes darstellen, welcher eine oder mehrere ausführbare Instruktionen zum Ausführen der spezifizierten logischen Funktion(en) darstellt. In einigen alternativen Ausführungen können die Funktionen, die in dem Block notiert sind, außerhalb der Reihenfolge, die in den Figuren notiert ist, erscheinen. Zum Beispiel können zwei Blöcke in Reihenfolge tatsächlich im Wesentlichen gleichzeitig ausgeführt werden oder Blöcke können manchmal in der entgegengesetzten Reihenfolge ausgeführt werden, abhängig von der betroffenen Funktionalität. Jeder Block der Blockdiagramme und/oder der Flussdiagrammdarstellung, und Kombinationen der Blöcke in den Blockdiagrammen und/oder der Flussdiagrammdarstellung, kann durch hardware-basierende Systeme für einen speziellen Zweck ausgeführt werden, welche die spezifizierten Formen oder Aktionen oder Kombinationen der Hardware für spezielle Zwecke und der Computerinstruktionen ausführen.
  • Die hierin verwendete Terminologie ist nur zum Zweck der Beschreibung besonderer Ausführungsform und ist nicht bestimmt, die Erfindung zu begrenzen. Wie hierin verwendet, sollen die Singularformen “ein”, “eine” und “der, die, das” auch die Pluralformen einzuschließen, außer der Kontext zeigt klar etwas anderes. Es wird ferner verständlich sein, dass die Ausdrücke “umfassen” und/oder “umfassend”, wenn sie in dieser Spezifikation verwendet werden, die Anwesenheit der festgestellten Merkmale, der ganzzahligen Programmierungen, der Schritte, der Operationen, der Elemente, der Komponenten und/oder Gruppen spezifizieren, aber die Anwesenheit von zusätzlichen von einem oder mehreren anderen Merkmalen, ganzzahligen Programmierungen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon nicht ausschließen. Die Ausdrücke “vorzugsweise”, “bevorzugt”, “vorziehen”, “optional”, “kann” und ähnliche Ausdrücke werden verwendet, um zu zeigen, dass ein Gegenstand, eine Bedingung oder ein Schritt, auf den sie sich beziehen, ein optionales (nicht gefordertes) Merkmal der Erfindung ist.
  • Die entsprechenden Strukturen, Materialien, Aktionen und Äquivalente von allen Mitteln oder Schritten plus Funktionselementen in den Ansprüchen unten beabsichtigen irgendeine Struktur, ein Material oder eine Aktion zum Durchführen der Funktionen in Kombination mit anderen beanspruchten Elementen, wie sie speziell beansprucht werden, einzuschließen. Die Beschreibung der vorliegenden Erfindung wurde zum Zweck der Darstellung und der Beschreibung vorgestellt, aber sie ist nicht beabsichtigt, erschöpfend oder begrenzend für die offenbarte Form zu sein. Viele Modifikationen und Variationen werden für den Fachmann der Technik naheliegend sein, ohne von dem Rahmen und dem Geist der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um am besten die Prinzipien der Erfindung und die praktische Anwendung zu erklären und andere Fachleute der Technik in die Lage zu versetzen, die Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifikationen zu verstehen, die für den besonderen vorgesehenen Gebrauch geeignet sind.

Claims (20)

  1. Verfahren, umfassend: – Ausführen eines Scale-up Hypervisors auf einem Serverkomplex, der wenigstens einen Server einschließt; – Ausführen eines einzelnen Betriebssytems und wenigstens einer Applikation über den Scale-up Hypervisor hinaus; – Identifizieren eines Firmware-Updates, das für eine erste Hardwarekomponente innerhalb des Serverkomplexes verfügbar ist; – wobei der Scale-up Hypervisor alle Last von der ersten Hardwarekomponente entfernt; und – das identifizierte Firmware-Update auf die erste Hardwarekomponente angewandt wird, während die erste Hardwarekomponente leer ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und wenigstens eine Applikation auszuführen.
  2. Verfahren nach Anspruch 1, wobei der Scale-up Hypervisor, der alle Last von der ersten Hardwarekomponente entfernt, einschließt, dass der Scale-up Hypervisor alle Last von der ersten Hardwarekomponente zu wenigstens einer anderen Hardwarekomponente innerhalb des Serverkomplexes migriert, wobei die erste Hardwarekomponente und die wenigstens eine andere Hardwarekomponente von dem gleichen Komponententyp sind.
  3. Verfahren nach Anspruch 1, wobei der Scale-up Hypervisor, der alle Last von der ersten Hardwarekomponente entfernt, einschließt, dass der Scale-up Hypervisor der ersten Hardwarekomponente ermöglicht, eine laufende Last abzuarbeiten, ohne irgendeine zusätzliche Last zu der ersten Hardwarekomponente zuzuordnen.
  4. Verfahren nach Anspruch 1, wobei das identifizierte Firmware-Update auf die erste Hardwarekomponente angewandt wird, ohne dass die Applikation eine Stillstandszeit erfährt.
  5. Verfahren nach Anspruch 1, wobei die erste Hardwarekomponente ein Prozessor in einem Server ist, der mehrere Prozessoren aufweist.
  6. Verfahren nach Anspruch 1, ferner umfassend: – Zuordnen der Last zu der ersten Hardwarekomponente durch den Scale-up Hypervisor, nachdem das identifizierte Firmware-Update der ersten Hardwarekomponente abgeschlossen wurde.
  7. Verfahren nach Anspruch 6, ferner umfassend: – Identifizieren eines Firmware-Updates, das für eine zweite Hardwarekomponente innerhalb des Serverkomplexes zur Verfügung steht; – Entfernen der Last von der zweiten Hardwarekomponente durch den Scale-up Hypervisor; und – Anwenden des identifizierten Firmware-Updates auf die zweite Hardwarekomponente, während die zweite Hardwarekomponente inaktiv ist und der Hypervisor fortsetzt, das einzelne Betriebssystem und die wenigstens eine Applikation auszuführen.
  8. Verfahren nach Anspruch 1, ferner umfassend: – Anwenden eines Firmware-Updates auf die erste Hardwarekomponente des ersten Servers durch das Betriebssystem.
  9. Verfahren nach Anspruch 8, ferner umfassend: – Anwenden eines Firmware-Update auf eine zweite Hardwarekomponente des ersten Servers durch ein Plattform-Management-Modul auf dem ersten Server.
  10. Verfahren nach Anspruch 1, ferner umfassend: – Vergleichen der Firmwareversion der Firmware, die auf der Hardwarekomponente installiert ist, mit der Firmwareversion eines Firmware-Updates, das für die Hardware zur Verfügung steht, durch einen Administrator, um zu bestimmen, ob die Firmware der Hardwarekomponente zu aktualisieren ist.
  11. Verfahren nach Anspruch 1, wobei der Serverkomplex eine Vielzahl von Servern umfasst.
  12. Verfahren nach Anspruch 11, ferner umfassend: – Verschieben aller Last von einem ersten Server innerhalb des Serverkomplexes zu einem oder mehreren anderen Servern innerhalb des Serverkomplexes durch den Scale-up Hypervirsor; – Schalten des ersten Servers in einen Offline-Modus, nachdem all die Last von dem ersten Server entfernt wurde; und – Zurückbringen des ersten Servers in den Online-Modus und Zuordnen der Last zu dem ersten Server, nachdem das identifizierte Firmware-Update vervollständigt wurde.
  13. Verfahren nach Anspruch 11, wobei ein Firmware-Update auf irgendeine Hardwarekomponente in der Vielzahl der Server angewandt werden kann.
  14. Verfahren nach Anspruch 13, ferner umfassend: – sequentielles Anwenden der Firmware-Updates auf eine Vielzahl an Hardwarekomponenten über die Vielzahl der Server des Serverkomplexes.
  15. Verfahren nach Anspruch 1, ferner umfassend: – Weitergeben der Systemressourcenauslastungs-Daten für den wenigstens einen Server zu einem Plattform-Management-Modul auf dem wenigstens einen Server durch den Scale-up Hypervisor.
  16. Verfahren nach Anspruch 15, ferner umfassend: – Initiieren des Firmware-Updates in Reaktion auf eine Systemressourcenauslastung, die geringer als eine vorbestimmte Größe des Systemressourcenauslastung ist.
  17. Verfahren nach Anspruch 15, ferner umfassend: – Modellieren der Systemressourcenauslastung als eine Funktion der Tageszeit, des Tages der Woche oder des Tages eines Jahres.
  18. Verfahren nach Anspruch 17, wobei die Systemressourcenauslastung durch ein Administratormodul modelliert wird, das nicht Teil des Serverkomplexes ist.
  19. Verfahren nach Anspruch 17, ferner umfassend: – ein Auffordern des Plattform-Management-Moduls, die gegenwärtige Systemressourcenauslastung zu einer Zeit zu berichten, zu der das Modellieren erwarten lässt, dass die Systemressourcenauslastung geringer ist als eine vorbestimmte Systemressourcenauslastung; und – ein Initiieren des Firmware-Updates, falls das Plattform-Management-Modul zeigt, dass die gegenwärtige Systemressourcenauslastunggeringer als eine vorbestimmte Größe der Systemressourcenauslastungist.
  20. Verfahren nach Anspruch 19, ferner umfassend: – Auffordern des Scale-up Hypervisor durch das Plattform Management Modul, die Systemressourcenauslastung für eine oder mehrere Hardwarekomponenten bereitzustellen, die durch das Administratormodul identifiziert sind, ein verfügbares Firmware-Update aufzuweisen.
DE102016105589.1A 2015-03-24 2016-03-24 Anwenden von Firmware-Updates in einem System mit Null-Stillstandszeit durch wahlweise Abschalten und Einschalten von Hardware unter Verwenden einer Hypervisor-Schicht Pending DE102016105589A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/667,259 US9851996B2 (en) 2015-03-24 2015-03-24 Applying firmware updates in a system with zero downtime by selectively offlining and onlining hardware using a scale-up hypervisor layer
US14/667,259 2015-03-24

Publications (1)

Publication Number Publication Date
DE102016105589A1 true DE102016105589A1 (de) 2016-09-29

Family

ID=56889743

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016105589.1A Pending DE102016105589A1 (de) 2015-03-24 2016-03-24 Anwenden von Firmware-Updates in einem System mit Null-Stillstandszeit durch wahlweise Abschalten und Einschalten von Hardware unter Verwenden einer Hypervisor-Schicht

Country Status (3)

Country Link
US (1) US9851996B2 (de)
CN (1) CN106020854B (de)
DE (1) DE102016105589A1 (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10044795B2 (en) 2014-07-11 2018-08-07 Vmware Inc. Methods and apparatus for rack deployments for virtual computing environments
US10740081B2 (en) * 2015-06-30 2020-08-11 Vmware, Inc. Methods and apparatus for software lifecycle management of a virtual computing environment
JP6436242B2 (ja) * 2015-09-17 2018-12-12 株式会社安川電機 産業機器の通信システム、通信方法、及び産業機器
US9930051B1 (en) * 2015-11-06 2018-03-27 Amazon Technologies, Inc. Remote management of hardware hosts in cloud infrastructure
US10474475B2 (en) * 2016-03-02 2019-11-12 Western Digital Technologies, Inc. Non-intrusive restart of a task manager
US10671376B2 (en) * 2016-03-15 2020-06-02 Shenzhen Skyworth-Rgb Electronic Co., Ltd. Server program hot upgrading method and device
US10034407B2 (en) * 2016-07-22 2018-07-24 Intel Corporation Storage sled for a data center
US10146527B2 (en) * 2016-10-12 2018-12-04 Samsung Electronics Co., Ltd. Method and apparatus for using BMC as proxy for NVME over fabrics device firmware upgrade
CN106598646A (zh) * 2016-11-14 2017-04-26 深圳市金立通信设备有限公司 程序更新方法和终端
KR102579467B1 (ko) * 2017-01-05 2023-09-18 주식회사 쏠리드 분산 안테나 시스템의 데이터 관리 장치 및 데이터 관리 방법
CN107066305B (zh) * 2017-05-11 2020-07-28 北京百度网讯科技有限公司 用于更新服务器的服务器固件的方法和装置以及服务器
CN109491855B (zh) * 2017-09-12 2023-07-14 联想企业解决方案(新加坡)有限公司 管理计算设备的方法
US11296921B2 (en) * 2017-12-03 2022-04-05 Intel Corporation Out-of-band management of FPGA bitstreams
CN108459942A (zh) * 2018-03-15 2018-08-28 联想(北京)有限公司 一种数据处理方法、装置及存储介质
US10990373B2 (en) 2018-05-18 2021-04-27 Nutanix, Inc. Service managers and firmware version selections in distributed computing systems
CN110825393B (zh) * 2018-08-07 2023-11-17 联想企业解决方案(新加坡)有限公司 将固件下载至服务器的系统和方法
US10901721B2 (en) 2018-09-20 2021-01-26 Vmware, Inc. Methods and apparatus for version aliasing mechanisms and cumulative upgrades for software lifecycle management
US10642646B1 (en) * 2018-10-24 2020-05-05 American Megatrends International, Llc Techniques of securely performing logic as service in BMC
US10831467B2 (en) * 2018-10-25 2020-11-10 American Megatrends International, Llc Techniques of updating host device firmware via service processor
CN109634634A (zh) * 2018-12-12 2019-04-16 浪潮(北京)电子信息产业有限公司 一种bmc固件升级方法、装置及终端
US11194589B2 (en) * 2019-01-08 2021-12-07 Dell Products L.P. Information handling system adaptive component reset
US11126420B2 (en) * 2019-01-08 2021-09-21 Dell Products L.P. Component firmware update from baseboard management controller
US11182145B2 (en) 2019-03-15 2021-11-23 International Business Machines Corporation Optimizing updates to distributed data processing applications
US10956170B2 (en) * 2019-03-22 2021-03-23 Dell Products L.P. BIOS setting modification system
US11200046B2 (en) * 2019-10-22 2021-12-14 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Managing composable compute system infrastructure with support for decoupled firmware updates
CN110851138A (zh) * 2019-11-06 2020-02-28 山东超越数控电子股份有限公司 一种将内核和应用分离的bmc软件开发方法
US11671314B2 (en) * 2020-06-11 2023-06-06 Dell Products L.P. Configuring HCI management network via management controller
US11677680B2 (en) * 2021-03-05 2023-06-13 Dell Products L.P. Dynamic allocation of bandwidth to virtual network ports
WO2022271157A1 (en) * 2021-06-22 2022-12-29 Hewlett-Packard Development Company, L.P. Instruction updates to hardware devices

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9020801B2 (en) 2003-08-11 2015-04-28 Scalemp Inc. Cluster-based operating system-agnostic virtual computing system
US20070061441A1 (en) * 2003-10-08 2007-03-15 Landis John A Para-virtualized computer system with I/0 server partitions that map physical host hardware for access by guest partitions
WO2005036806A2 (en) * 2003-10-08 2005-04-21 Unisys Corporation Scalable partition memory mapping system
US8141065B2 (en) * 2007-09-27 2012-03-20 Alcatel Lucent Method and apparatus for performing non service affecting software upgrades in place
US8201161B2 (en) * 2008-01-07 2012-06-12 Lenovo (Singapore) Pte. Ltd. System and method to update device driver or firmware using a hypervisor environment without system shutdown
CN102081552A (zh) * 2009-12-01 2011-06-01 华为技术有限公司 一种物理机到虚拟机的在线迁移方法、装置和系统
US8463984B2 (en) * 2009-12-31 2013-06-11 Seagate Technology Llc Dynamic data flow management in a multiple cache architecture
US8402454B2 (en) * 2010-09-22 2013-03-19 Telefonaktiebolaget L M Ericsson (Publ) In-service software upgrade on cards of virtual partition of network element that includes directing traffic away from cards of virtual partition
CN103186404B (zh) * 2011-12-28 2016-01-06 英业达股份有限公司 系统固件更新方法与使用该方法的服务器系统
CN102629207B (zh) * 2012-03-05 2016-12-14 浪潮通用软件有限公司 一种多租户环境运行实例分时更新的方法
CN102664894B (zh) * 2012-04-25 2015-03-25 浪潮(北京)电子信息产业有限公司 一种基于云计算的软件提供系统及方法

Also Published As

Publication number Publication date
CN106020854A (zh) 2016-10-12
US9851996B2 (en) 2017-12-26
US20160283221A1 (en) 2016-09-29
CN106020854B (zh) 2021-02-09

Similar Documents

Publication Publication Date Title
DE102016105589A1 (de) Anwenden von Firmware-Updates in einem System mit Null-Stillstandszeit durch wahlweise Abschalten und Einschalten von Hardware unter Verwenden einer Hypervisor-Schicht
DE112016003120B4 (de) Umleiten einer Kopie beim Schreiben
DE102015102678B4 (de) Systeme und verfahren zur abbild-recovery
DE102015105884B4 (de) Rechenknoten und Verfahren zur Migration einer virtuellen Maschine, Rechenzentrummanager zur Migration virtueller Maschinen, Maschinenlesbares Speichermedium und Rechenvorrichtungen
DE112010003554B4 (de) Symmetrische Direktmigration von Virtuellen Maschinen
DE112012000693B4 (de) Ausführen einer Vielzahl von Instanzen einer Anwendung
DE112010003144T5 (de) Erweiterbare Grundstruktur zur Unterstützung verschiedener Einsatzarchitekturen
DE112018006769B4 (de) Erweiterte zwischenspeicherzuweisung basierend auf virtuellen knotenressourcen
DE112010004160T5 (de) Portieren virtueller Abbilder zwischen Plattformen
DE102009023953A1 (de) Verfahren zum Booten eines zustandslosen Client
DE112018003524T5 (de) Dynamische datenverlagerung unter verwendung von speicherbänken auf cloud-grundlage
DE112013000369T5 (de) Verwaltung von Threads innerhalb einer Datenverarbeitungsumgebung
DE102010001339A1 (de) Verwalten von Anforderungen von Betriebssystemen, die in virtuellen Maschinen ablaufen
DE112016007336B4 (de) Informationsverarbeitungsvorrichtung, Vorrichtungszuweisungsverfahren undVorrichtungszuweisungsprogramm
DE112013000904T5 (de) Durchführen von Aktualisierungen von Quellcode, der auf einer Vielzahl von Rechenknoten ausgeführt wird
DE112020000912T5 (de) Verwalten von software-programmen
DE112018005135T5 (de) Thin provisioning unter verwendung von speicherbänken auf cloud-grundlage
DE112021005636T5 (de) Migrieren von komplexen legacy-anwendungen
DE112020005819T5 (de) Virtuelle einschübe in einem server
DE102018207314A1 (de) Software-definierte mikrodienste
DE112018000227T5 (de) Verfahren zum teilweisen Aktualisieren von Dateninhalten in einem verteilten Speichernetzwerk
DE102012221261A1 (de) Verfahren zum Zwischenspeichern und System zum Ausführen des Verfahrens zum Zwischenspeichern zum Betreiben eines mindestens einen Host-Computer aufweisenden Computerserversystems
DE102008016180A1 (de) Darlegen von Systemtopologie für die Ausführungsumgebung
DE112021005927T5 (de) Patchen von arbeitsabläufen
DE112016004264T5 (de) Verfahren und vorrichtung zum dynamischen auslagern der ausführung von maschinencode in einer anwendung an eine virtuelle maschine

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: GRUENECKER PATENT- UND RECHTSANWAELTE PARTG MB, DE