DE102011085335A1

DE102011085335A1 - Auf rack-ebene modulares server- und speicher-framework

Info

Publication number: DE102011085335A1
Application number: DE102011085335A
Authority: DE
Inventors: German Florez-Larrahondo; Jimmy Pike; John Stuewe; Joseph Sekel; Richard Mills; Joe Vivio
Original assignee: Dell Products LP
Current assignee: Dell Products LP
Priority date: 2010-11-04
Filing date: 2011-10-27
Publication date: 2012-05-10
Also published as: US8838286B2; GB2485643A; CN102469740A; GB201118076D0; US20120116590A1; CN102469740B; SG180070A1; GB2485643B

Abstract

Ein auf Rack-Ebene modulares Server- und Speicher-Framework wird offenbart. Das modulare Rack-System umfasst eine Mehrzahl von Baugruppenträgern, die in ein oder mehrere Racks platziert sind und eine Mehrzahl von Schlitten, die in jedem Baugruppenträger platziert ist. Jeder Schlitten umfasst ein Informationsverarbeitungssystem, ein gemeinsam genutztes Lüfter-Modul, ein gemeinsam genutztes Energiemodul und ein gemeinsam genutztes Management-Modul. Das gemeinsam genutzte Lüfter-Modul kühlt die Mehrzahl der Schlitten in jedem Baugruppenträger und das gemeinsam genutzte Energiemodul liefert elektrinem oder mehreren Baugruppenträgern. Das gemeinsam genutzte Management-Modul managt den Betrieb der Mehrzahl der Baugruppenträger.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht im Allgemeinen auf Informationsverarbeitungssysteme und spezieller auf ein auf Rack-Ebene modulares Server- und Speicher-Framework.
HINTERGRUND
Da der Wert und die Verwendung von Informationen beständig anwachsen, suchen Privatpersonen und Unternehmen nach zusätzlichen Möglichkeiten, um Informationen zu verarbeiten und zu speichern. Eine den Benutzern verfügbare Option sind Informationsverarbeitungssysteme. Im Allgemeinen verarbeitet ein Informationsverarbeitungssystem, übersetzt, speichert und/oder überträgt Informationen oder Daten für geschäftliche, persönliche oder andere Zwecke, wobei den Benutzern ermöglicht wird, Nutzen aus dem Wert der Informationen zu ziehen. Da Technologie und Informationsverarbeitungsbedürfnisse und Erfordernisse zwischen verschiedenen Benutzern oder Anwendungen variieren, können Informationsverarbeitungssysteme variieren, hinsichtlich welche Informationen verarbeitet werden, wie die Informationen verarbeitet werden und wie viel Informationen verarbeitet, gespeichert oder übertragen werden und wie schnell und wirkungsvoll die Informationen verarbeitet, gespeichert oder übertragen werden können. Die Unterschiede zwischen den Informationsverarbeitungssystemen erlauben es, dass Informationsverarbeitungssysteme allgemein sind oder für einen speziellen Benutzer oder eine spezielle Anwendung konfiguriert sind, wie die Verarbeitung von Finanztransaktionen, Reservierungen bei Fluglinien, Datenspeicherungen in Unternehmen oder weltweite Kommunikation. Informationsverarbeitungssysteme können zusätzlich eine Vielzahl von Hardware und Software Komponenten einschließen, die so ausgelegt werden können, dass sie Informationen verarbeiten, speichern und übertragen können und ein oder mehrere Rechnersysteme, Datenspeichersysteme und Netzwerksysteme umfassen können.
Ein Informationsverarbeitungssystem, wie etwa ein Server-System, kann in ein Rack (Steckgehäuse) platziert werden. Ein Rack kann mehrere Server-Systeme beherbergen und mehrere Racks werden normalerweise in einen Raum platziert, der als ein Datenzentrum oder als ein Server-Raum bekannt ist. Ein typischer Server-Raum umfasst Reihen von Racks. Eine Schwierigkeit von Datenzentren ist die Wärme, die durch mehrere Server in dem Datenzentrum erzeugt werden. Überschüssige Wärme führt zu hohen Kühlkosten für ein Datenzentrum und kann zu einer Verschlechterung des Leistungsverhaltens der Computersysteme des Racks oder des Datenzentrums führen. Darüber hinaus beinhalten Server häufig aktive Komponenten. Sobald ein Server in ein Rack installiert worden ist, kann der Ausfall einer aktiven Komponente des Servers die Notwendigkeit für einen Service erforderlich machen, der die Systemkosten erhöht und der zeitaufwändig sein kann.
Es ist wünschenswert die Server, die in einem Datenzentrum lokalisiert sind, wirksam zu managen und zu überwachen, um die Instandhaltungskosten nach der Installation, die mit den Servern verbunden sind, zu minimieren. Zusätzlich ist es wünschenswert eine optimale Systemeffizienz zu erzielen, in dem den Servern ermöglicht wird Systemressourcen, wie etwa Lüfter, die zum Kühlen der Server und der Stromverteilungseinheiten der Server benötigt werden, gemeinsam zu nutzen.
ZUSAMMENFASSUNG
Die vorliegende Offenbarung bezieht im Allgemeinen auf Informationsverarbeitungssysteme und spezieller auf ein auf Rack-Ebene modulares Server- und Speicher-Framework.
In einer beispielhaften Ausführungsform ist die vorliegende Erfindung auf ein modulares Informationsverarbeitungssystem-Framework gerichtet. Das modulare Informationsverarbeitungssystem kann ein Rack beinhalten, das zumindest einen Baugruppenträger (chassis) enthält; einen Schlitten (sled), der in dem Baugruppenträger platziert ist; wobei der Schlitten zumindest ein Informationsverarbeitungssystem beinhaltet; einen Lüfter, der in dem Baugruppenträger platziert ist, um das Informationsverarbeitungssystem zu kühlen; einen Lüfter-Controller, der kommunikativ mit dem Lüfter verbunden ist; wobei der Lüfter-Controller den Betrieb des Lüfters managt; einen Knoten-Controller, der dem Schlitten zugeordnet ist; wobei der Knoten-Controller den Betrieb des Schlittens managt; ein Energiemodul, um elektrische Energie dem Informationsverarbeitungssystem bereitzustellen; einen Energiemodul-Controller zum Managen des Energiemoduls; und einen primären Domain-Controller, der kommunikativ mit dem Lüfter-Controller verbunden ist, dem Knoten-Controller und dem Energiemodul; wobei der primäre Domain-Controller den Betrieb des zumindest einen Lüfter-Controllers, des Knoten-Controllers und des Energiemoduls managt.
In einer weiteren beispielhaften Ausführungsform ist die vorliegende Erfindung auf ein modulares Rack-System gerichtet. Das modulare Rack-System kann eine Mehrzahl von Baugruppenträgern beinhalten, die in einem oder mehreren Racks platziert sind; eine Mehrzahl von Schlitten, die in jedem Baugruppenträger platziert sind; wobei jeder Schlitten ein Informationsverarbeitungssystem umfasst; ein gemeinsam genutztes Lüfter-Modul zum Kühlen der Mehrzahl von Schlitten in jedem Baugruppenträger; ein gemeinsam genutztes Energiemodul zum Bereitstellen von elektrischer Leistung an einen oder mehrere Schlitten in einem oder mehreren Baugruppenträgern; und ein gemeinsam genutztes Management-Modul zum Managen des Betriebs der Mehrzahl der Baugruppenträger.
Die hierin offenbarten Verfahren und Systeme stellen demzufolge ein effizientes Managen und Überwachen von Informationsverarbeitungssystemen bereit, die in einem Datenzentrum lokalisiert sein können und minimieren damit die nach der Installation auftretenden Instandhaltungskosten. Darüber hinaus optimieren die Verfahren und Systeme der vorliegenden Anmeldung den Systemwirkungsgrad indem sie erlauben, dass zwei oder mehr Informationsverarbeitungssysteme Systemressourcen wie etwa Spannungsversorgungen und Lüfter gemeinsam nutzen. Weitere technische Vorteile werden für Fachleute mit Blick auf die folgende Beschreibung, die Ansprüche und die Zeichnungen offensichtlich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Ein vollständigeres Verständnis der vorliegenden Ausführungsformen und deren Vorteile kann mit Bezug auf die folgende Beschreibung, die in Verbindung mit den begleitenden Zeichnungen betrachtet wird, gewonnen werden, in welchen ähnliche Bezugszeichen ähnliche Merkmale anzeigen und wobei:
Die 1 ist eine bildhafte Ansicht eines modularen Rack-Systems in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 2 ist eine bildhafte Ansicht eines Baugruppenträgers in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 3 ist eine perspektivische Ansicht des Baugruppenträgers der 2.
Die 4 ist eine Nahaufnahme eines modularen Rack-Systems in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 5 ist ein Blockdiagramm eines Systemmanagement-Frameworks (system management framework) für das modulare Rack-System in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 6 ist ein Blockdiagramm des Software-Stapels (software stack) für den Lüfter-Controller der 5 in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 7 ist ein Blockdiagramm eines Software-Stapels für den Knoten-Controller der 5 in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 8 ist ein Blockdiagramm der Software-Architektur des Domain-Controllers der 5 in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 9 ist ein gemeinsam genutztes Energieversorgungssystem in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung.
Die 10 stellt die Verbindung eines Baugruppenträgers zu einer Energieverteilungseinheit in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung dar.
Die 11 stellt eine Management-Vorrichtung in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung dar.
Obwohl Ausführungsformen dieser Offenbarung dargestellt und beschrieben worden sind und mit Bezug auf beispielhafte Ausführungsformen der Offenbarung definiert sind, implizieren solche Bezüge keine Beschränkung der Offenbarung und keine solche Beschränkung soll daraus abgeleitet werden. Der offenbarte Gegenstand ist einer beträchtlichen Modifikation, Änderung oder Äquivalenten in Form und Funktion fähig, wie es den einschlägigen Fachleuten auffallen wird und die die Vorteile (benefits) dieser Offenbarung kennen. Die dargestellten und beschriebenen Ausführungsformen dieser Offenbarung sind nur Beispiele und nicht erschöpfend für den Geltungsbereich der Offenbarung.
DETAILLIERTE BESCHREIBUNG
Für Zwecke dieser Offenbarung kann ein Informationsverarbeitungssystem irgendein Mittel oder eine Anordnung von Mitteln umfassen, die betriebsfähig sind, um irgendeine Form von Informationen, Intelligenz oder Daten für geschäftliche, wissenschaftliche, zum Steuern oder für andere Zwecke zu berechnen, klassifizieren, verarbeiten, senden, empfangen, abfragen, hervorbringen, schalten, speichern, anzeigen, bekanntmachen, nachweisen, abnehmen, vervielfältigen, bearbeiten oder benutzen. Ein Informationsverarbeitungssystem kann beispielsweise ein Personal-Computer ein Netzwerkspeichergerät oder irgendein anderes geeignetes Gerät sein und kann in der Größe, der Form, dem Leistungsverhalten, der Funktionalität und dem Preis variieren. Das Informationsverarbeitungssystem kann einen Schreib-Lesespeicher (RAM, Random Access Memory) eine oder mehrere Verarbeitungsressourcen, wie etwa eine zentrale Verarbeitungseinheit (CPU, Central Processing Unit) oder Hardware- oder Softwarekontro111ogik, ROM und/oder andere Arten von nichtflüchtigem Speicher umfassen.
Zusätzliche Komponenten des Informationsverarbeitungssystems können ein oder mehrere Festplattenlaufwerke, ein oder mehrere Netzwerkanschlüsse für die Kommunikation mit externen Geräten ebenso wie verschiedene Eingabe- und Ausgabe (I/O) Geräte sein wie etwa eine Tastatur, eine Maus oder ein Video-Display. Das Informationsverarbeitungssystem kann ferner einen oder mehrere Busse umfassen, die betriebsfähig sind, um Kommunikationen zwischen verschiedenen Hardware-Komponenten zu übertragen.
Ein Informationsverarbeitungssystem kann in einem Rack untergebracht sein. Wie beispielsweise in der 1 gezeigt ist, können Server und/oder Datenspeichergeräte in einem Datenzentrum in einem Rack 102 angeordnet sein. Wie von Fachleuten anerkannt werden wird, kann der Server aus zumindest einer Hauptplatine (mother board), einer CPU und einem Speicher bestehen. Ein Datenzentrum kann ein oder mehrere Racks 102 umfassen, abhängig von den Systemanforderungen des Nutzers. Das Rack 102 kann ein oder mehrere Baugruppenträger 104 umfassen. Ein Baugruppenträger 104 ist in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung eine modulare Komponente, die das gemeinsame Nutzen kritischer Server-Komponenten von vielen Servern erleichtert. In einer exemplarischen Ausführungsform kann der Baugruppenträger 104 ein 4U Baugruppenträger (4U chassis) sein. Jeder Baugruppenträger 104 ist innen zweckmäßigerweise frei von aktiven Komponenten oder an seiner Rückwand (backplane), um den Service-Bedarf nach seiner Installation zu minimieren.
Wie detaillierter in den 2 und 4 gezeigt ist, kann der Baugruppenträger 104 Schlitten 106 umfassen. Der Schlitten 106 kann einen oder mehrere Server 107 einschließen. Das Rack 102 kann einen oder mehrere rechnerbetonte Schlitten (computational sleds), Speicherschlitten (storage sleds) oder eine Kombination davon umfassen. Wie es für Fachleute auf der Basis dieser Offenbarung offensichtlich sein wird, können, obwohl die rechnerbetonten Schlitten (computational sleds) und/oder die Datenspeicherschlitten in der exemplarischen Ausführungsform vertikal angeordnet sind, diese ebenfalls horizontal angeordnet werden. Wie in den 2 und 3 gezeigt, kann eine beispielhafte Ausführungsform des Baugruppenträgers 104 bis zu zehn vertikale rechnerbetonte Schlitten, fünf doppeltbreite Schlitten, die zwölf oder mehr Festplattenlaufwerke oder eine hybride Anordnung umfassen, einschließlich einer Kombination von rechnerbetonten und Speicherschlitten. Wie Fachleute anerkennen werden, ist die vorliegende Erfindung nicht auf eine spezifische Anzahl oder Konfiguration von Schlitten 106 in einem Baugruppenträger 104 begrenzt. In einer beispielhaften Ausführungsform können im Falle horizontaler Schlitten vier 1U Schlitten mit voller Breite, die einen dichten Server in jeder 1U unterstützen, einschließlich von vier Steckersystemen (socket systems) verwendet werden. Wie es für Fachleute offensichtlich sein wird, können mit den Vorteilen dieser Offenbarung andere Anordnungen der rechnerbetonten und Speicherschlitten in Abhängigkeit von den Systemanforderungen und/oder den Präferenzen verwendet werden.
Der Baugruppenträger 104 kann ferner ein gemeinsam genutztes Lüfter-Modul in einer Kühlstrecke 110 an der Rückseite des Baugruppenträgers 104 umfassen. In einer beispielhaften Ausführungsform weist das gemeinsam genutzte Lüfter-Modul eine 4U Auflösung auf. In einer Ausführungsform können drei Lüfter 108 in dem gemeinsam genutzten Lüfter-Modul zum Kühlen der Schlitten 106 in dem Baugruppenträger 104 verwendet werden. Es können jedoch mehr oder weniger Lüfter in dem gemeinsam genutzten Lüfter-Modul in Abhängigkeit der Systemleistungsfähigkeit und der Systemanforderungen verwendet werden. Die Lüfter 108 können von einem Lüfter-Controller 508 gemanagt werden, dessen Betrieb wird detaillierter unten in Verbindung mit den 5 und 6 diskutiert. Wie Fachleute, die die Vorteile dieser Offenbarung kennen, anerkennen werden, kann der Lüfter-Controller 508 von der Rückseite ohne Stromabschaltung des Racks 102 getauscht werden (may be hot swapped from the back of the rack 102).
Zusätzlich kann jeder Baugruppenträger 104 elektrische Energie über Kabel empfangen, die von der Energieverteilungseinheit („PDU”, Power Distribution Unit) kommt, was unten detaillierter in Verbindung mit den 5, 9 und 10 diskutiert werden wird. Wie unten diskutiert wird, kann die PDU 902 eine oder mehrere Energieversorgungseinheiten („PSUs”, Power Supply Units) 904 aufweisen. Deshalb wird die elektrische Energie, die von allen PSUs 904 erzeugt wird auf alle Baugruppenträger 104 aufgeteilt, die mit der PDU 902 verbunden sind. Im Gegenzug wird dann jeder Baugruppenträger 104 die elektrische Energie, die er empfängt, an die individuellen Schlitten 106 verteilen, die in diesem Baugruppenträger enthalten sind.
Zwischen der Kühlstrecke 110 und den Schlitten 106 gibt es Rückwände (backplanes) 112. Der Baugruppenträger 104 kann eine Energie- und Management-Rückwand umfassen, die elektrische Energie an jeden der Schlitten 106 verteilt. Die Energie- und Management-Rückwand kann ferner Hochgeschwindigkeitsnetzwerksignale (wie zum Beispiel Ethernet) tragen und Netzwerksignale mit niedriger Geschwindigkeit (wie zum Beispiel System Management Bus). In einer Ausführungsform kann das System weiterhin eine optionale Speicherrückwand umfassen, die es einem rechnerbetonten Schlitten erlaubt Zugriff auf einen oder mehrere Speicherschlitten in dem gleichen Baugruppenträger 104 über SA-TA/SAS Signale zu haben. Die Speicherrückwandanschlüsse können mit den rechnerbetonten Rückwandanschlüssen über SATA/SAS Verbindungskabel (patch cables) verbunden sein.
Wie in 5 gezeigt, offenbaren das System und die hierin offenbarten Verfahren ein Framework für eine gemeinsam genutzte Kühlung, eine gemeinsam genutzte Energie und ein gemeinsam genutztes Management der Schlitten 106. Jeder Schlitten 106 innerhalb des Baugruppenträgers 104 kann als ein Knoten behandelt werden, der zentral über ein Netzwerk gemanagt wird, beispielsweise ein Ethernet-basiertes Management-Netzwerk. Ein Domain-Controller 514 kann einen Zugangspunkt für einen Nutzer zum Managen des Systems bereitstellen, Die Betriebsarten des Domain-Controllers 514 werden detaillierter weiter unten diskutiert werden. Dementsprechend kann, wie in der 5 gezeigt, jeder Schlitten ferner einen Knoten-Controller 502 einschließen, der Systemmanagement- und Überwachungsfähigkeiten bereitstellt. Der Knoten-Controller 502 kann jeden der Server 107 in einem Schlitten 106 managen. Der Knoten-Controller 502 managt die Energie der Server 107, schaltet die LED-Lichter an, liest Temperaturen aus, leitet Daten von der seriellen Konsole weiter, usw. Er ist auch dafür zuständig, die richtigen Stromschienen bereitzustellen, um die Komponenten des Servers 107 mit elektrischer Energie zu versorgen. Ein Endnutzer 518 interagiert nicht direkt mit dem Knoten-Controller 502. Stattdessen kommuniziert der Knoten-Controller 502 mit dem Domain-Controller 514 und anderen Geräten in dem Management-Netzwerk. Der Ausdruck „Management-Netzwerk” bezieht sich auf ein internes Netzwerk, das einem Endnutzer nicht zugänglich ist, das verschiedenen Controllern in dem Netzwerk ermöglicht untereinander zu kommunizieren und speziell mit dem Domain-Controller 514 zu kommunizieren. In einer beispielhaften Ausführungsform kann das Management-Netzwerk ein Ethernet 10/100 Netzwerk sein. Der Ausdruck „Domain” („domain”), wie er hierin benutzt wird, bezieht sich auf ein logisches Konzept, das einem Satz von Schlitten 106, Lüftern 108, Energieversorgungen 510, 116 und anderen Geräten anzeigt, die in einem Rack 102 angeordnet sind oder über einen Satz von Racks verteilt sind und die von demselben Domain-Controller 514 gemanagt werden können.
Das Netzwerk kann einen Zusammenschlussschalter (consolidation switch) 506 innerhalb jedes Baugruppenträgers 104 zu einem zentralen Management-Schalter 516 bei einem zentralen Management-Domain-Controller 514 verbinden, der einen einzigen (redundanten) Zugangspunkt für einen Nutzer durch eine Schnittstelle, wie etwa zum Beispiel ein Command-Line-Interface, ein Simple-Network-Management-Protocol oder ein Data-Center-Manageability-Interface bereitstellt. Der Domain-Controller 514 ermöglicht einem Endnutzer eine Domain zu managen und zu überwachen. Zum Beispiel kann der Domain-Controller 514 alle Schlitten 506, Lüfter 108 und Energieversorgungseinheiten 510, 116 in einem oder mehreren Baugruppenträgern 104 verwalten. Der Domain-Controller 514 kommuniziert mit den untergeordneten Controllern unter Verwendung des Management-Netzwerks. Wie hierin diskutiert, bezieht sich der Ausdruck „untergeordneter Controller” („low level controller”) auf Knoten-Controller, Lüfter-Controller und Energie-Controller, die eine Funktionalität anbieten, auf die der Endnutzer 518 jedoch nicht direkt zugreifen kann. Der Domain-Controller 514 kann einen robusten Software-Stapel (robust software stack) aufweisen, um einem Endnutzer 518 viele verschiedene Wege zum Managen des Systems bereitzustellen. In einer Ausführungsform kann das System zwei Domain-Controller 514, 524 umfassen. Falls der primäre Domain-Controller 514 ausfällt, kann ein automatischer Ausfallsicherungsprozess (failover process) auftreten und der sekundäre Controller 524 kann übernehmen und der primäre Domain-Controller werden.
Unter normalen Betriebsbedingungen kann der primäre Controller 514 eine Verbindung zu dem sekundären Domain-Controller 524 durch das Management-Netzwerk aufweisen. Wie von Fachleuten anerkannt werden wird, kann mit den Vorteilen dieser Offenbarung eine Anzahl geeigneter Verfahren zum Bereitstellen dieser Verbindung verwendet werden. In einer beispielhaften Ausführungsform kann die Verbindung eine TCP Verbindung sein. Der primäre Domain-Controller 514 kann eine „Ich-bin-unter-Spannung-stehend”-(„I'm alive”)Nachricht an den sekundären Domain-Controller 524 durch die TCP Verbindungen alle paar Sekunden senden. Der primäre Domain-Controller 514 kann ferner wichtige Aktualisierungen an den sekundären Domain-Controller 524 wie etwa Registrierungsnachrichten, Alarme usw. durch die TCP Verbindung senden. Der sekundäre Domain-Controller 524 arbeitet in einer Schleife, die den Zeitstempel der letzten „Ich-bin-unter-Spannung”-Nachricht, die von dem primären Domain-Controller 514 empfangen wurde, überprüft.
Falls der zweite Domain-Controller 524 vom Netz geht oder anderweitig nicht mehr betriebsfähig wird, während der primäre Domain-Controller 514 arbeitsfähig ist, wird der primäre Domain-Controller 514 detektieren, dass der sekundäre Domain-Controller 524 nicht erreicht werden kann (die TCP Verbindung ist unterbrochen). Dann wird ein Alarm erzeugt. Der primäre Domain-Controller 514 wird dann versuchen, die TCP Verbindung wieder herzustellen (wobei er einige Sekunden zwischen den Versuchen pausiert). Wenn eine erfolgreiche TCP Verbindung mit dem zweiten Domain-Controller 524 hergestellt wird, wird ein Ereignis erzeugt, um das System davon zu unterrichten, dass der Fehler behoben worden ist.
Falls der primäre Domain-Controller 514 vom Netz geht oder anderweitig funktionsunfähig wird, während der sekundäre Domain-Controller 524 in Betrieb ist, wird der sekundäre Domain-Controller 524 nicht länger eine „Ich-bin-unter-Spannung-stehend”-Nachricht erhalten. Falls der sekundäre Domain-Controller 524 keine „Ich-bin-unter-Spannung-stehend”-Nachricht empfängt, nachdem eine vorbestimmte Zeit abgelaufen ist, wird er erkennen, dass der primäre Domain-Controller 514 funktionsunfähig geworden ist. Als Reaktion kann der sekundäre Domain-Controller 524 einen Alarm an das System erzeugen und/oder seine Betriebsart ändern und der primäre Domain-Controller für das System werden. Es kann passieren, dass die untergeordneten Controller die Änderung in dem Domain-Controller nicht sofort bemerken. Dadurch können, während der Übergang stattfindet, einige „alte” Sensordaten-Pakete verloren gehen. Es werden jedoch aktuelle (up-to-date) Sensordaten zwischengespeichert werden, sobald der sekundäre Domain-Controller übernimmt. In ähnlicher Weise kann infolge des Ausfalls des primären Domain-Controllers 514 eine Nutzerschnittstelle (zum Beispiel eine Comand Line Interface oder ein Web Service) zu dem primären Controller (at the primary) unterbrochen werden. Es wird jedoch nach einigen Sekunden, wenn der Übergang stattfindet, ein neuer Versuch zum Verbinden erfolgreich sein und der Nutzer kann die Befehle wiederholen. Als nächstes wird der neue primäre Controller versuchen, eine TCP Sitzung mit einem neuen sekundären Domain-Controller aufzubauen.
Die 11 stellt eine Management-Vorrichtung 1100 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung dar. Die Management-Vorrichtung 1100 kann bis zu zwei Domain-Controller 514, 524 und einen Ethernet-Schalter (ethernet switch) 516 enthalten. Ein System, das in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist, kann bis zu einer Management-Vorrichtung 1100 pro Rack 102 umfassen. In Beispielen, in denen ein Nutzer Systemredundanz wünscht, kann die Management-Vorrichtung 1100 sowohl einen primären Domain-Controller 514 und einen sekundären Domain-Controller 524 umfassen. In Gegensatz dazu kann, wenn ein Nutzer Redundanz nicht benötigt, die Management-Vorrichtung 1100 nur einen primären Domain-Controller 514 umfassen. Darüber hinaus können mehr-Rack-Systeme, die keine Redundanz erfordern, ein Rack 102 mit einer Management-Vorrichtung 1100 umfassen, welche einen Domain-Controller aufweist und einen Ethernet-Schalter und die andere Management-Vorrichtung 1100 mit nur einem Schalter. Eine Management-Vorrichtung 1100 gemäß einer Ausführungsform der vorliegenden Erfindung kann einen Drehschalter umfassen, der mit der Position des Racks 102 gesetzt werden kann, sodass jedem Rack 102 eine verschiedene Nummer zugewiesen werden kann. Dies ist Teil der Positionsinformationen, die jedes Gerät in dem System aufweist. Zum Beispiel wird einem Schlitten 106 eine ihm zugewiesene Rack/Baugruppenträger/Schlitten Identifizierung (Rack/Chassis/Sled identification) aufweisen.
Nun zurückkehrend zur 5, kann, um die Schlitten 106 zu managen und zu überwachen, der Knoten-Controller 502, der einem Schlitten 106 zugeordnet ist eine physikalische Verbindung zu Sensoren, der Hauptplatine oder zu Erweiterungsplatinen aufweisen, die das Management der mehreren Server 107 in einem Schlitten 106 bereitstellen. Der Knoten-Controller 502 kann auf einem Mikroprozessor laufen. In einer Ausführungsform kann der Mikroprozessor ein kleines eingebettetes (embedded) Betriebssystem umfassen. Eine der Hauptverantwortlichkeiten des Knoten-Controller 502 kann sein elektrische Energie den Schlitten 106 einschließlich der Hauptplatinen, den Festplattenlaufwerken und/oder den Speicherschlitten, die einem Schlitten 106 zugeordnet sind, bereitzustellen und zu managen. Energie-Management-Befehle können dem Knoten-Controller von einem Bedienfeld (panel) auf dem Baugruppenträger 104 durch das Management-Netzwerk und/oder einen Baseboard-Management-Controller („BMC”) bereitgestellt werden. Der Knoten-Controller 502 kann für das Sammeln von Daten und das Alarmieren zuständig sein. Der Knoten-Controller 502 kann dann periodisch Daten an den Domain-Controller 514 und/oder Benachrichtigungen an den Domain-Controller 514 senden, wenn interessierende Ereignisse auftreten. Darüber hinaus kann der Knoten-Controller 502 Sensordaten an den Lüfter-Controller des Baugruppenträgers 508 senden. Zum Beispiel kann zusätzlich zum Senden der Baugruppenträger-Sensordaten, wie etwa Temperatur-Sensordaten an den Domain-Controller 514, die gespeichert werden sollen, der Knoten-Controller 502 ebenfalls Sensordaten an den Lüfter-Controller 508 des Baugruppenträgers 104 senden. Der Lüfter-Controller 508 kann dann die Sensordaten zum Kontrollieren der Geschwindigkeit der Lüfter 108 verwenden.
Der Lüfter-Controller 508 kann Software umfassen, um die Geschwindigkeit und den Status der Lüfter 108 zu kontrollieren und zu überwachen und den Domain-Controller 514 von kritischen Ereignissen der Lüfter 108 zu unterrichten. Der Lüfter-Controller 508 kann mit einem Domain-Controller 514 über das Management-Netzwerk kommunizieren. Der Lüfter-Controller 508 kann Temperaturdaten von allen Knoten-Controllern 502 empfangen, die in dem gleichen Baugruppenträger 104 lokalisiert sind, um die Lüftergeschwindigkeiten zu regulieren, um den thermischen Anforderungen des Systems zu entsprechen. Der Lüfter-Controller 508 kann eine Hauptkonfigurationsdatei umfassen, die seine verschiedenen Komponenten beim Starten lesen müssen und die von dem Domain-Controller 514 überschrieben werden kann. Insbesondere, die Parameter, die das Verhalten des Lüfter-Controllers 508 kontrollieren wie etwa die Abfrage-Frequenz (pulling frequency), die vorgegebenen Fehlerbeseitigungspegel (default debug levels) usw., müssen von der Konfigurationsdatei gelesen werden und können zum Testen und für Abstimmungszwecke von dem Domain-Controller 514 überschrieben werden.
Nun der 6 zuwendend, ist ein Blockdiagramm der Komponenten des Lüfter-Controllers 508 gezeigt. Der Lüfter-Controller kann eine Netzwerkabstraktionsschicht 602 und eine Hardware-Abstraktionsschicht (network abstraction layer) 604 einschließen. Die Verbindungen zwischen den Diensten in dem Lüfter-Controller 508 können implementierungsabhängig sein und werden zu einem großen Teil von der darunterliegenden Hardware beeinflusst. Zum Beispiel können die Verbindungen einfach Aufrufe zum Laden von Bibliotheken sein, von gemeinsam genutztem Speicher oder von Interprozess-Kommunikations-Frameworks wie etwa Warteschlangen (queues). Die Netzwerkabstraktionsschicht 602 ermöglicht es dem Lüfter-Controller 508 Nachrichten von dem Netzwerk zu senden und zu empfangen, ohne mit dem darunterliegenden Netzwerkprotokoll, das verwendet wird, befasst zu sein. Der Lüfter-Controller 508 kann einen Identifikationsdienst 606 umfassen, der die physikalische Position des Lüfter-Controllers 508 bestimmt. Insbesondere kann die erste Aufgabe von dem Lüfter-Controller 508 sein, sich selbst zu identifizieren. Da ein Lüfter-Controller 508 in einem Baugruppenträger 104 eines Racks 102 lokalisiert ist, kann diese Identifikation auf der physikalischen Position des Lüfter-Controllers basiert sein. Unter Verwendung der Hardware-Abstraktionsschicht 604 wird der Lüfter-Controller 508 die Baugruppenträger-Nummer bestimmen, die ihm zugeordnet ist. Die Baugruppenträger-Nummer wird als eine Positionszeichenkette (location string) bekannt sein und kann einem Host-Namen (host name) des Lüfter-Controllers 508 zugewiesen werden. Wie Fachleute anerkennen werden, kann mit dem Vorteilen dieser Offenbarung, basierend auf der physikalischen Position des Lüfter-Controllers 508 eine statische Adresse dem Lüfter-Controller 508 zugewiesen werden. Sobald eine IP-Adresse dem Lüfter-Controller 508 zugewiesen ist, muss jeder andere Dienst in dem Lüfter-Controller 508 neu gestartet werden. Der Lüfter-Controller 508 wird dann validieren, dass die Adresse in dem Netzwerk eindeutig ist. Wenn die zugewiesene Adresse) nicht eindeutig ist, wird der Lüfter-Controller 508 einen Fehler an den Logdienst (log service) 614 senden und versuchen, eine Adresse aus einem reservierten Adressenpool zu bekommen.
In einer Ausführungsform kann ein dynamischer Lüfter-Controller 608 bereitgestellt werden, um die Geschwindigkeit der Lüfter 108 zu regulieren. Sensoren (nicht gezeigt) können in dem System platziert werden. Die dynamische Lüfterkontrolle 608 kann periodisch Sensorablesungen von einem mehreren Sensoren des Baugruppenträgers 104 empfangen und kann dynamisch die Geschwindigkeit der Lüfter 108 unter Verwendung eines PID-Controller-Algorithmus anpassen, welcher mit Sensordaten von den Schlitten 106 in dem Baugruppenträger 104 und andere Umgebungssensoren, die vor dem Baugruppenträger 104 platziert sind, gespeist wird. Zum Beispiel kann der dynamische Lüfter-Controller 608 die folgenden Sensordaten von jedem Schlitten 106 empfangen: Ausgangsumgebungstemperatur (auf der Grundlage von Temperaturproben des Knoten-Controllers 502); CPU-Temperatur (von dem BMC); die DIMM-Temperatur (von dem BMC); und den Schlittenenergieverbrauch. Zusätzlich kann der Lüfter-Controller 608 periodisch Sensorablesungen von dem Baugruppenträger 504, wie etwa die Umgebungstemperatur, empfangen. Für jede der Sensorablesungen wird es einen diskreten PID-Controller in dem dynamischen Lüfter-Controller 608 geben. Wie von Fachleuten anerkannt werden wird, können mit dem Vorteilen dieser Offenbarung die PID-Controller die Lüfter-Geschwindigkeit kontrollieren, basierend auf der einen oder der mehreren Variablen, die von den Sensoren empfangen werden, die in dem System verwendet werden. Wenn es einen Sensorausfall gibt, wenn. der Lüfter-Controller 508 ausfällt oder wenn die dynamische Lüfterkontrolle 608 anderweitig ausfällt und nicht wiederhergestellt werden kann, werden die Lüfter angewiesen werden, mit maximaler Geschwindigkeit zu arbeiten.
Da der Betrieb eines solchen Rückkopplungskontrollsystems Fachleuten bekannt ist, wird er hierin im Detail nicht diskutiert. Wenn einer der Lüfter 108 des Lüfter-Moduls ausfällt, wird der Lüfter-Controller 508 die verbleibenden Lüfter anweisen mit maximaler Geschwindigkeit zu funktionieren. In einer beispielhaften Ausführungsform können im Falle eines Firmware-Ausfalls die Lüfter 108 veranlasst werden, mit maximaler Geschwindigkeit zu arbeiten, während der Lüfter-Controller 508 neu gestartet wird.
Der Benachrichtigungsdienst 610 des Lüfter-Controllers 508 kann Nachrichten von dem Lüfter-Controller 508 an den Domain-Controller 514 und andere Empfänger senden. Die Nachrichten können Datenaktualisierungen oder interessierende Ereignisse (zum Beispiel Lüfter-Fehler) einschließen. Die erste Aufgabe des Unterrichtungsdienstes 610 ist es, den Domain-Controller 514 zu unterrichten, dass der Lüfter-Controller 508 bereit ist. Darüber hinaus kann nach der anfänglichen „Registrierung”, der Benachrichtigungsdienst Nachrichten, die von anderen Komponenten des Lüfter-Controllers 508 empfangen wurden, an den Domain-Controller 514 und andere Geräte (zum Beispiel an die dynamische Lüfterkontrolle 608) weiterleiten. Der Lüfter-Controller 508 kann ferner einen Befehlsabhördienst (command listener service) 612 umfassen, der Nachrichten oder Befehle von dem Domain-Controller 514 durch eine verbindungsorientierte Sitzung (connection oriented session), die vorher erzeugt worden ist, empfängt. Der Befehlsabhörer (command listener) 612 kann ankommende Anforderungen in eine Warteschlange stellen und kann sie nacheinander abarbeiten. Die maximale Größe der Warteschlange kann aus der Konfigurationsdatei ausgelesen werden. Im Ergebnis müssen die Verfahren, die von dem Befehlsabhörer 612 ausgeführt werden, um Management- und Überwachungsoperationen durchzuführen, nicht Thread-sicher (thread safe) sein, obwohl das Verwenden eines Thread-sichereren Verfahrens empfohlen wird. Obwohl unter normalen Betriebsbedingungen nur eine einzige Verbindung von dem Domain-Controller 514 benötigt wird, ist es wünschenswert, die Fähigkeit zu besitzen, mehr als eine Verbindung in die Warteschlange für Fehlerbeseitigungszwecke zu erlauben, so dass ein Test-Client Befehle an den Lüfter-Controller 508 senden kann, selbst wenn er mit einem Domain-Controller 514 verbunden ist.
Der Lüfter-Controller 508 kann ferner einen Logdienst (log service) 614 umfassen, der Nachrichten von anderen Komponenten des Lüfter-Controllers 508 empfängt und diese in einem physikalischen Medium speichert, das eine permanente Position sein kann (zum Beispiel ein EEPROM). Der Logdienst 614 kann die Logeinträge in dem physikalischen Medium rotieren, sodass es niemals voll ist und dass die jüngsten Nachrichten verfügbar bleiben. Die maximale Größe des Logeintrags hängt von den verfügbaren Hardware-Ressourcen ab und kann Teil der Konfigurationsdatei sein. Zum Beispiel kann in einer Ausführungsform die Anzahl der Nachrichten in dem Logdienst 614 500 sein, während sie in einer anderen Ausführungsform 20 sein kann.
Zusätzlich kann der Lüfter-Controller 508 einen Überwachungsdienst 616 umfassen, der für jeden Sensor von Interesse (zum Beispiel einen Geschwindigkeitssensor) den letzten Ablesewert erhält und der Ereignisse von Interesse (zum Beispiel einen Lüfter-Fehler) an den Benachrichtigungsdienst 610 feuert (fire), wenn die Sensordaten aus einem vorbestimmten akzeptablen Bereichs fallen. Ferner kann der Überwachungsdienst 616 periodische Aktualisierungen von dynamischen Daten an den Domain-Controller 514 über den Benachrichtigungsdienst 610 senden. In einer Ausführungsform kann der Überwachungsdienst 616 beständig Daten von der Hardware-Abstraktionsschicht 604 für jeden „Sensor” bei einer vorbestimmten Frequenz abfragen und kann eine vorbestimmte Anzahl von Sensorablesungen in einem Speicher speichern. Die gespeicherten Sensorablesungen können dann verwendet werden, um einen Mittelwert für den bestimmten Sensor zu berechnen, der berichtet wird, wenn der Überwachungsdienst 616 über einen Sensor befragt wird. Die Anzahl der Sensordaten, die gespeichert werden soll und die Abtastrate kann in der Konfigurationsdatei gesetzt werden.
In einer Ausführungsform kann der Überwachungsdienst 616 des Lüfter-Controllers 508 empfangene Sensordaten verwenden und sie mit drei Betriebsbereichen vergleichen, um zu bestimmen, ob die Lüfter 108 in dem normalen Bereich, dem Warnbereich oder dem Alarmbereich arbeiten. Jedes Mal, wenn ein Sensor in einen dieser Bereiche eintritt, kann der Überwachungsdienst 616 des Lüfter-Controllers 508 ein Ereignis an den Benachrichtigungsdienst 610 feuern, der den Endnutzer 518 über den Domain-Controller 514 benachrichtigen wird.
Die Bereiche für jede Kategorie können in der Konfigurationsdatei durch den Domain-Controller 514 gesetzt werden.
Schließlich kann der Lüfter-Controller 508 ein Herzschlagsignal (heartbeat signal) 618 einschließen, das ein einfaches Gerät (low end device) ist, das den Lüfter-Controller 508 bei einer vorgegebenen Frequenz abfragt und das die Lüfter zum Betrieb bei voller Geschwindigkeit zurücksetzt, wenn es keine Antwort von dem Lüfter-Controller 508 erhält.
Um einen flexiblen und wartbaren Code zu erzeugen, können die Lüfter-Controller-Dienste so angeordnet sein, dass sie nicht direkt mit der Hardware wechselwirken. Stattdessen kann der Lüfter-Controller 508 eine Hardware-Abstraktionsschicht 604 umfassen, die als eine Schnittstelle zwischen den Diensten und der Hardware 620 wirkt. Falls beispielsweise der Befehlsabhördienst 612 einen Befehl zum Ausschalten eines Lüfters 108 erhält, kann der Befehlsabhörer 612 eine Anfrage an die Hardware-Abstraktionsschicht 604 senden, die das physikalische Medium und das Protokoll zum Durchführen der Aufgabe kennt. Wie Fachleuten bekannt sein wird, kann mit den Vorteilen dieser Offenbarung ein Lüfter-Controller 508 eine Anzahl von Hardware-Geräten 62 verwalten, einschließlich, ohne jedoch darauf beschränkt zu sein eine Lüfter-PWM 620a, einen Lüfter-Drehzahlmesser 620b, ein EEPROM/Flash 620c, ein „Ausfall-ohne-Schaden”-Controller („fail no harm” controller) 620d.
Nun zurückkehrend zu 5 kann der Knoten-Controller 502 Management- und Überwachungsoperationen durchführen, die von dem Domain-Controller 504 angefordert werden wie etwa das Energie-Management des Servers. Der Knoten-Controller 502 kann mit dem Domain-Controller 514 unter Verwendung des Management-Netzwerks kommunizieren.
Der Domain-Controller 514 kann eine Hauptkonfigurationsdatei einschließen, die die verschiedenen Komponenten des Knoten-Controllers 502 zum Starten lesen muss. Diese Konfigurationsdatei kann von dem Domain-Controller 514 überschrieben werden. Dementsprechend müssen die Parameter, die das Leistungsverhalten des Knoten-Controllers 502 kontrollieren wie etwa die Abfragefrequenz, die voreingestellten Fehlerbeseitigungspegel, usw. von der Hauptkonfigurationsdatei gelesen werden und können zum Testen oder für Abstimmzwecke überschrieben werden. Die Anwesenheit der Hauptkonfigurationsdatei entfernt die harte Programmierung (hard coding) von dem Code und ermöglicht ein Leistungsverhalten mit minimalen Modifikationen während des Testens des Systems. Zusätzlich kann eine Kopie der ursprünglichen Konfigurationsdatei in dem System beibehalten werden, um ein „Zurücksetzen” zu ermöglichen, wobei die ursprüngliche Konfigurationsdatei in den Knoten-Controller geschrieben wird und das System neu gestartet wird.
Nun der 7 zuwendend, wird ein Blockdiagramm von einigen beispielhaften Komponenten des Knoten-Controllers 502 dargestellt. Der Knoten-Controller 502 kann eine Reihe von wohldefinierten Diensten einschließen und kann von einer Netzwerk-Abstraktionsschicht 702 und einer Hardware-Abstraktionsschicht 704 Gebrauch machen, welche der Software Flexibilität und Portabilität geben. Die Verbindung zwischen den Diensten kann implementationsabhängig sein und kann einen Einfluss auf die darunterliegende Hardware haben. In einigen Ausführungsbeispielen kann dies ein einfaches Verfahren zum Aufrufen von geladenen Bibliotheken, gemeinsam genutzter Speicher oder zwischen Prozesskommunikations-Frameworks sein wie etwa Warteschlangen.
Die Netzwerk-Abstraktionsschicht 702 kann der Software ermöglichen, Nachrichten von dem Netzwerk zu senden oder zu empfangen, ohne sich über das darunterliegende Netzwerkprotokoll, das verwendet wird, Gedanken zu machen. Eine der ersten Aufgaben des Knoten-Controllers 502 ist es, sich gegenüber dem System auszuweisen. In einer Ausführungsform kann der Knoten-Controller 502 sich selbst gegenüber dem System durch Spezifizieren seiner physikalischen Position ausweisen, die in einem spezifischen Rack 102, einem Baugruppenträger 104 und einem Schlitten 106 bestehen kann. Dementsprechend kann eine der ersten Komponenten, um das System zu starten, der Identifikationsdienst 706 sein, der die physikalische Position des Knoten-Controllers 502 bestimmt. Unter Verwendung der Hardware-Abstraktionsschicht 704 wird der Knoten-Controller 502 die Baugruppenträgernummer und die Knotennummer innerhalb des Baugruppenträgers 104 bestimmen, an dem er lokalisiert ist. Eine statische Adresse kann der Position des bestimmten Knoten-Controllers 502 zu gewiesen werden. Sobald eine IP-Adresse zu gewiesen ist, müssen alle anderen Dienste des Knoten-Controllers 502 neu gestartet werden. Der Knoten-Controller 502 kann dann sicherstellen, dass die zugewiesene Adresse eindeutig für das Netzwerk ist. Falls die Adresse nicht eindeutig ist, kann der Knoten-Controller 512 einen Fehler schreiben und versuchen eine Adresse von dem reservierten Pool zu bekommen. Der Identifikationsprozess kann häufig ausgeführt werden (zum Beispiel alle 10 Sekunden) und falls die Position geändert wird, sollte er sich erneut anmelden.
Der Benachrichtigungsdienst 708 kann Nachrichten von dem Knoten-Controller 502 an den Domain-Controller 514 und andere Empfänger senden. Diese Nachrichten können Datenaktualisierungen umfassen (zum Beispiel Sensordaten) und/oder interessierende Ereignisse (zum Beispiel eine Änderung des Zustands und Fehler). Die erste Aufgabe des Benachrichtigungsdienstes 708 ist es, den Domain-Controller 514 zu benachrichtigen, dass der Knoten-Controller 502 bereit ist und den Knoten-Controller 502 an dem Domain-Controller 514 „registrieren”. Falls der ursprüngliche Versuch zum Anmelden des Knoten-Controllers 502 nicht erfolgreich war, kann der Benachrichtigungsdienst 708 dann eine vorbestimmte Zeit darüber warten und dann erneut versuchen bis eine Verbindung hergestellt ist. Zusätzlich kann der Benachrichtigungsdienst 708 Nachrichten von anderen Diensten und/oder anderen Modulen an den Knoten-Controller 502 durch das Management-Netzwerk weiterleiten. In einer Ausführungsform kann der Benachrichtigungsdienst 708 Nachrichten an den Domain-Controller 514 zu vorbestimmten Zeitintervallen senden, um das unwahrscheinliche Ereignis, dass sowohl der primäre Domain-Controller 514 als auch der sekundäre Domain-Controller 524 (wie weiter unten detaillierter diskutiert) beide außer Betrieb sind, zu detektieren. Sobald die Registrierung abgeschlossen worden ist, kann der Benachrichtigungsdienst 708 Sensor- und andere dynamische Daten von der Hardware lesen, die von dem Knoten-Controller 502 gemanagt wird; Bestimmen, ob die ausgelesenen Daten interessierende Ereignisse bewirken, die durch den Benachrichtigungsdienst 708 abgefeuert werden sollen, in dem diese mit einem akzeptablen Bereich verglichen werden; und periodisches Senden von Aktualisierungen von dynamischen Daten an den Domain-Controller 514 über den Benachrichtigungsdienst 708.
Der Knoten-Controller 502 kann ferner einen Befehlsabhördienst 710 einschließen. Der Befehlsabhördienst 710 kann Nachrichten oder Befehle von dem Domain-Controller 514 durch eine verbindungsorientierte Sitzung empfangen, die vorher erzeugt worden ist. Die Befehlsabhördienst 710 kann ankommende Anforderungen in eine Warteschlange stellen und sie eine nach der anderen zu gegebener Zeit erfüllen. Dementsprechend müssen die Verfahren, die von dem Befehlsabhördienst 710 zum Durchführen von Management- und Überwachungsoperationen ausgeführt werden, nicht Thread-sicher (thread safe) sein. In einer Ausführungsform kann mehr als eine Verbindung in der Warteschlange erlaubt sein.
Zusätzlich kann der Knoten-Controller 502 einen seriellen Konsolendienst 712 einschließen. Der serielle Konsolendienst 712 kann in zwei Betriebsarten ablaufen. Die erste ist die gepufferte Betriebsart, in der der Knoten-Controller 502 Daten von dem Konsolenanschluss des Servers 107 sammelt und diese in einem rotierenden Pufferspeicher speichert. Die zweite Betriebsart ist die interaktive Betriebsart, in der der Endnutzer 518 mit der seriellen Konsole eines Servers 107 über den Knoten-Controller 502 interagiert. Die Implementierung der interaktiven Betriebsart emuliert einen Endnutzer 518 als wäre er direkt mit einem seriellen Anschluss des seriellen Konsolendienstes 702 verbunden, obwohl in Wirklichkeit jede Kommunikation zwischen dem Endnutzer 518 und dem seriellen Konsolendienst 512 durch den Domain-Controller 514 und den Knoten-Controller 502 gehen muss. In einer Ausführungsform kann die gepufferte Betriebsart die vorgegebene Betriebsart des Dienstes für den seriellen Konsolendienst 702 sein. Der Pufferspeicher kann ein FIFO-Design aufweisen, wobei die älteren Datenbytes fallengelassen werden, um es zu ermöglichen, dass neue Bytes oben dem Pufferspeicher hinzugefügt werden.
Ein Logdienst 714 kann ferner bereitgestellt werden, um Nachrichten von anderen Komponenten des Knoten-Controllers 502 zu empfangen und diese in einem physikalischen Medium zu speichern wie etwa einem EEPROM. Der Knoten-Controller 502 kann ferner einen Überwachungsdienst 716 für jeden Sensor einschließen, der eine Systemeigenschaft von Interesse überwacht (zum Beispiel eine Temperatur, einen elektrischen Energieverbrauch, eine Spannung, einen Strom, usw.). In einer Ausführungsform kann der Überwachungsdienst 716 ständig Daten für jede gemanagte Hardware 718 von der Hardware-Abstraktionsschicht 704 abfragen. Der Überwachungsdienst 716 kann den zuletzt von dem Sensor gelesenen Wert behalten und kann Ereignisse an den Benachrichtigungsdienst 708 feuern. Zum Beispiel kann, falls der Temperatursensor (nicht gezeigt) eine Temperatur anzeigt, die eine vorbestimmte Sicherheitsschwelle überschreitet, der Überwachungsdienst 716 ein Ereignis an den Benachrichtigungsdienst 708 feuern, in dem er den Benachrichtigungsdienst 708 von dieser Tatsache informiert. In einer Ausführungsform können potenzielle Systemfehler reduziert werden, dadurch ein Wert einer interessierenden Größe durch den Überwachungsdienst 716 gespeichert wird, der ein Mittelwert einer Zahl von Sensorablesungen über ein vorbestimmtes Zeitintervall ist. In einer Ausführungsform können die Sensordaten mit einem „akzeptablen Bereich” mit einem bestimmten Sensor verglichen werden, um zu bestimmen, ob ein Schwellenwert erreicht worden ist. Der Überwachungsdienst 716 kann die Sensordaten an den Domain-Controller 514 und/oder an andere Empfänger (zum Beispiel die Lüfter-Controller 508) zu einer vorgegebenen Frequenz weiterschieben. In einer Ausführungsform kann der Überwachungsdienst 716 ferner mit dem BMC der Schlitten 106 interagieren, um Daten zu sammeln und/oder um Daten weiterzuschieben.
Wie Fachleute anerkennen werden, kann mit den Vorteilen der vorliegenden Erfindung der Knoten-Controller 502 eine Anzahl von Hardware-Komponenten 718 managen, einschließlich, ohne jedoch darauf beschränkt zu sein, eine Hauptplatine (mother board) 718a, physikalische Positions-Bus/Anschlüsse 718b, LEDs 718c, Sensoren 718d und einen EEPROM/Flash 718e. Um jedoch einen flexiblen und wartbaren Code zu erzeugen, können die Knoten-Controller-Dienste 502 nicht direkt mit der System-Hardware, die gemanagt werden soll, interagieren. Stattdessen können die Knoten-Controller-Dienste 502 eine Hardware-Abstraktionsschicht 704 verwenden, die die Hardware abstrahiert. Falls beispielsweise der Befehlsabhördienst 710 einen Befehl zum Ausschalten einer LED 718c erhält, kann der Befehlsabhördienst 710 eine Anforderung an die Hardware-Abstraktionsschicht 704 senden. Die Hardware-Abstraktionsschicht 704 kennt das physikalische Medium und Protokoll zum Managen der LED. Im Ergebnis muss für den Fall, dass die Hardware, auf der der Knoten-Controller 512 läuft, geändert wird, nur die Hardware-Abstraktionsschicht 704 und vielleicht die Netzwerk-Abstraktionsschicht 702 geändert werden, während die anderen Systemkomponenten im Wesentlichen dieselben bleiben. Der Knoten-Controller 502 ist viel kostengünstiger als ein voll ausgestatteter Baseboard-Management-Controller, trotzdem stellt er die kritischsten Fähigkeiten bereit, die Kunden eines Hyperskalen-Datenzentrums (hyper scale data center) wünschen können.
Nun zurückkehrend zur 5 können die I²C-Signale (I2C signals) 504 verwendet werden, um jedem Schlitten 106 seine Position in dem Baugruppenträger 104 anzuzeigen. Zusätzlich können die I²C-Signale 504 als eine Hintertür zum Senden oder Empfangen von Daten für den Fall verwendet werden, dass der Knoten-Controller 502 keine IP-Adresse bekommen kann oder der Ethernet-Schalter 506 beschädigt ist. In der Rückwand von jedem Baugruppenträger 104 kann es einen Schalter (switch) 506 geben, der ein Ethernet-Netzwerk erzeugt, das es dem Knoten-Controller 502 ermöglicht, mit anderen Geräten zu kommunizieren.
Wie in der 5 gezeigt, kann das System ein oder mehrere Energieversorgungsmodule 510 einschließen, die elektrische Energie an einen oder mehrere Baugruppenträger 104 liefern. Das Energiemodul 510 kann eine Energieverteilungseinheit („PDU”, power distribution unit) einschließen, die elektrische Energie von dem Datenzentrum und/oder den Wechselstrom-Anschlüssen empfängt, die die Komponenten von dritter Seite speisen und elektrische Energie dem Baugruppenträger 104 bereitstellen. Das Energiemodul 510 kann an einen Energiemodul-Controller 512 angeschlossen werden, der Management- und Überwachungsfähigkeiten für das Energiemodul 510 bereitstellt, das eine PDU, PSUs und AC-Anschlüsse, usw. bereitstellt. Der Energiemodul-Controller 512 kann mit einem Domain-Controller 514 über das Management-Netzwerk kommunizieren. Dementsprechend kann das System ein gemeinsam genutztes Energiesubsystem einschließen, das elektrische Energie von dem Energiemodul 510 an ein oder mehrere Baugruppenträger 104 verteilt. Die Betriebsarten des gemeinsam genutzten Energiesystems werden detaillierter in Verbindung mit der 9 diskutiert.
In einer beispielhaften Ausführungsform kann der Baugruppenträger 104 eine Batteriesicherung (battery backup) 116 einschließen. Die Batteriesicherung 116 kann elektrische Gleichstrom-Energie den Servern 107 im Falle eines PDU-Ausfalls bereitstellen. Der Energiemodul-Controller 512 stellt das Management und die Überwachung der Batteriesicherung 116 bereit. Der Energiemodul-Controller 502 kann nur die kritischsten Einstellungen und die Metriken extrahieren, die von der Batteriesicherung 116 bereitgestellt werden (zum Beispiel den Status der Batterie, die verbleibende Zeit, usw.) und diese dem Endnutzer 518 anzeigen. Alarme und/oder Ereignisse, die von der Batteriesicherung 116 erzeugt werden, können auch von dem Energiemodul-Controller 512 weitergeleitet werden.
Wie weiter unten im Detail diskutiert werden wird, kann der Domain-Controller 514 betriebsbereit zum Ausführen von einer oder mehrerer der folgenden Funktionen in Abhängigkeit von den Systemanforderungen sein: Anzeigen einer Inventur aller Geräte des Baugruppenträgers 104; Ermöglichen des Setzens und des Anzeigens von Baugruppenträgerinformationen, wie etwa den Baugruppenträgernamen, den Typ des Baugruppenträgers und die Höhe des Baugruppenträgers (zum Beispiel 42U), um das Inventar-Management zu ermöglichen; Managen der elektrischen Energie der Server in einem oder mehreren Schlitten 106; Überwachen des Energieverbrauchs, die von jedem Gerät in dem Rack verbraucht wird, ebenso wie des gesamten Energieverbrauchs; Überwachen der Temperatur der verschiedenen Sensoren in den Controllern des Baugruppenträgers 104; Überwachen der Lüfter-Geschwindigkeiten; Bereitstellen einer Aggregation von kritischen Maßnahmen wie etwa einer maximalen Temperatur, einer mittleren Temperatur, Gerätefehlern, usw.; Detektieren des Ausfalls von irgendeinem Controller in dem Baugruppenträger 104 und anderer kritischer Bedingungen; es den Controllern in dem Baugruppenträger 104 ermöglichen ohne negativen Einfluss auf das Systemleistungsverhalten aktualisiert zu werden; Beibehalten einer Historie von Sensordaten in einer Datenbank und Bereitstellen von statistischen Leistungsdaten; Ermöglichen die elektrische Energie auf Baugruppenträger-Ebene zu deckeln, wenn der gesamte Energieverbrauch des Racks eine vorbestimmte Schwelle überschreitet, wenn es einen Ausfall von Energieversorgungen gibt oder um die Systemarbeitslasten anzupassen.
Der Domain-Controller 514 kann mit einem Schalter 516 verbunden sein, der verwendet wird, um die Schalter in dem Baugruppenträger 104 zu aggregieren. Ein Endnutzer 518 kann irgendein Gerät in dem Rack unter Verwendung des Domain-Controllers 514 managen. Dies umfasst das Energiemanagement und Energieüberwachung, die Sensorüberwachung, serial over LAN (seriell über LAN), die Detektion von kritischen Alarmen in dem Rack und/oder andere Systemeigenschaften, von denen gewünscht wird, dass sie überwacht oder kontrolliert werden sollen.
Der Betrieb des Domain-Controllers 514 wird detaillierter mit Bezug auf die 8 beschrieben. Wie in der 8 gezeigt, sind die beiden Hauptkomponenten des Domain-Controllers 514 die Manager 802 und die Schnittstellen 804. Ein Manager ist ein Modul, das für das Management und die Überwachung eines spezifischen Teils des Systems zuständig ist und Schnittstellen sind der Code, der Management- und Überwachungsfähigkeiten den Endnutzern 518 bereitstellt. Die Manager 802 können Objekte enthalten, die in einer Datenbank gespeichert sind. Es kann ein Objekt geben, das jedem Gerät in dem System von dem Rack 102 bis zu dem Domain-Controller 514 selber entspricht. Objekte haben Eigenschaften und Verfahren. Zum Beispiel kann ein Rack-Objekt Eigenschaften, wie eine maximale Temperatur, einen maximaler Energieverbrauch, usw. aufweisen und Verfahren wie etwa Energiemanagement (Ein/Aus). Die Objekte können in Tabellen einer Datenbank gespeichert werden, die die aktuellsten Daten enthält.
Die Schnittstellen 804 empfangen Befehle von dem Endnutzer 518 und kommunizieren mit dem geeigneten Manager 802, um die Anfragen zu befriedigen. Dementsprechend werden die Schnittstellen 804 und die Manager 802 getrennt, so dass zum Beispiel ein Code, der eine Leistungsmessung von einem Knoten-Controller 502 liest, nichts zu tun hat mit dem Code, der dem Domain-Controller 514 ermöglicht, neu zu starten.
Die Manager 802 können einen Gerätemanager 806 einschließen. Der Gerätemanager 806 kann kommunikativ an einen Cache (Zwischenspeicher) 808 für Sensordaten gekoppelt sein, die von den untergeordneten Controllern (low level controllers) bereitgestellt werden. Ein einziger Domain-Controller 514 kann mit vielen untergeordneten Controllern interagieren. Zum Beispiel kann der Geräte-Manager 806 Sensordaten von den Schlitten 506, den Lüftern 108, der Energieversorgung des Gehäuses 114 und der Batteriesicherung 116 empfangen. Die untergeordneten Controller können Daten an den Geräte-Manager 806 des Baugruppenträger-Controllers 514 weiterschieben. Der Geräte-Manager 806 kann diese Daten in einem Cache 808 speichern, so dass sie schnell abgerufen werden können, wenn der Endnutzer 518 Überwachungsdaten anfordert. Zusätzlich kann der Geräte-Manager 806 Daten in einer Datenbank speichern, die es dem Nutzer 108 ermöglichen historische Daten abzulegen (to dump historical data) und es dem Geräte-Manager 806 ermöglichen, dem Nutzer 518 mit statistischen Daten bezüglich des Systemleistungsverhaltens zu versorgen. Zum Beispiel können in einer beispielhaften Ausführungsform Sensordaten von jedem untergeordneten Controller in einem zentralen Cache 808 gesammelt werden. Nach einem vorbestimmten Abtastintervall kann der gesamte Cache-Inhalt 808 in die Datenbank ausgegeben werden. Zusätzlich kann der Cache aktuelle Überwachungsdaten bereitstellen, die ein Konsument benötigt. Zum Beispiel kann eine Anfrage durch den Endnutzer 518 bezüglich des Echtzeitenergieverbrauchs eines Schlittens 106 von dem Cache 808 befriedigt werden, ohne es notwendig zu machen einen TCP Befehl von dem Geräte-Manager 806 an den Knoten-Controller 502 zu senden.
Für den unwahrscheinlichen Fall, dass der Domain-Controller 514 ein Paket von einem untergeordneten Controller erhält, der nicht angemeldet geworden ist, wird der Domain-Controller 514 ein Ereignis erzeugen, das zugrundeliegende User Datagram Protocol Paket untersuchen, eine IP-Adresse für den untergeordneten Controller bekommen und einen Befehl zum Erhalten von Controller-Informationen senden, so dass der Cache 808 aktualisiert werden kann. Wie Fachleute anerkennen werden, sollte dies mit den Vorteilen dieser Offenbarung nur passieren, wenn ein untergeordnete Controller sich an dem Domain-Controller 514 angemeldet hat und der Domain-Controller außer Betrieb geht, bevor die Aktualisierung an den zweiten redundanten Domain-Controller 524 gesendet wird.
Die untergeordneten Controller (zum Beispiel die Knoten-Controller 502) haben die Fähigkeit nur einen Befehl gleichzeitig auszuführen. Im Gegensatz dazu, kann aus Skalierungsgründen mehr als ein Befehl von einem Domain-Controller 514 gleichzeitig ausgeführt werden. In einer Ausführungsform kann eine Komponente des Geräte-Managers 806 des Domain-Controllers 514 eine Aufgaben-Pool-Architektur (task pool architecture) einschließen wie sie von Webservern benutzt wird, die von der Apache Software Foundation verfügbar sind, die in Delaware ansässig ist, um die Ausführung von mehr als einem Befehl gleichzeitig zu ermöglichen. Speziell bei Verwendung einer Aufgaben-Pool-Architektur kann ein Satz von Threads parallel arbeiten, um einen Satz von Befehlen auszuführen. Zum Beispiel kann die elektrische Energie von 100 Knoten dadurch gemanagt werden, dass 10 Threads die elektrische Energie von 10 Knoten managen.
In einer beispielhaften Ausführungsform kann, falls der Cache 808 detektiert, dass ein untergeordneter Controller seine Daten nicht rechtzeitig aktualisiert hat ein „getsensordata”-Signal („Erhalte-Sensor-Daten”-Signal) an den speziellen untergeordneten Controller senden. Die Zeitspanne, die vergehen kann, bevor ein „getsensordata”-Signal an den spezifischen untergeordneten Controller gesendet wird, kann von dem Nutzer 518 in Abhängigkeit der Systemanforderungen voreingestellt werden. Wenn die Lieferung des „getsensordata”-Signals an den bestimmten untergeordneten Controller fehlschlägt oder wenn der Cache 808 kein antwortendes Signal von dem untergeordneten Controller empfängt, kann der Cache 808 die alten Daten, die sich auf diesen untergeordneten Controller beziehen, entfernen und ein Ereignis erzeugen, um eine Benachrichtigung des Problems bereitzustellen.
In einer beispielhaften Ausführungsform kann der Domain-Controller 514 ferner einen Benachrichtigungs-Manager 810 einschließen. Der Benachrichtigungs-Manager 810 handelt als ein „Behälter” („container”) für die Ereignisse und Alarme in dem System, die in eine Warteschlange 811 gestellt werden und an den Benachrichtigungs-Manager 810 geliefert werden. Zum Beispiel kann der Benachrichtigungs-Manager 810 Informationen enthalten, dass „das System gestartet worden ist”, oder dass „der Temperatursensor im Knoten 1 eine kritische Schwelle übersteigt”. Der Benachrichtigungs-Manager 810 ist für das Versenden von interessierenden Ereignissen (zum Beispiel eine Temperatur oberhalb des Schwellenwerts, ein System wurde initiiert, usw.) zu verschiedenen Zielen zuständig. In einer Ausführungsform kann der Benachrichtigungs-Manager 810 die Ereignisse und/oder die Alarme von einer Simple Network Management Protocol (SNMP) Falle (trap) 812 abfangen, die verwendet werden kann, um mit dem Netzwerk verbundene Geräte auf Bedingungen zu überwachen, die administrative Aufmerksamkeit erfordern. Der Betrieb einer SNMP Falle (SNMP trap) ist Fachleuten wohl bekannt und wird deshalb hierin nicht im Detail diskutiert. In ähnlicher Weise werden Fachleute anerkennen, dass mit den Vorteilen dieser Offenbarung der Benachrichtigungs-Manager 810 Ereignisse und/oder Alarme zu anderen Zielen verteilen kann wie etwa zum Beispiel an einen Log, an einen Systemlog (Syslog) 814 oder die anderen geeigneten Ziele. Die SNMP Falle 812 und/oder der Systemlog 814 können benutzt werden, um einen Endnutzer 514 von den Ereignissen und/oder Alarmen, die in dem Benachrichtigungs-Manager 810 enthalten sind, durch eine Nutzerschnittstelle 816 und/oder andere Verteiler 818 zu benachrichtigen.
In einer Ausführungsform kann der Domain-Controller 514 ferner einen Sicherheitsmanager 820 einschließen. Der Sicherheitsmanager 820 ist für die Authentifizierung und/oder die Funktion-basierte Autorisierung (role based authorization) zuständig. Die Autorisierung kann unter Verwendung eines lokalen oder eines entfernten Datenverzeichnisses durchgeführt werden. In einer Ausführungsform kann das lokale Datenverzeichnis unter dem Lightweight Directory Access Protocol („LDAP”) arbeiten. Das Datenverzeichnis kann Informationen über die Nutzer auf einem lokalen LDAP Server 822 enthalten und kann erweitert werden, um zusätzliche Informationen hinzufügen, wenn/falls benötigt. Standardmäßig kann das System einen lokalen LDAP Server 822 mit lokalen Nutzern (zum Beispiel einem Administrator) einschließen. Jedoch kann ein Endnutzer 518 einen weiteren LDAP Server oder ähnliche Customers Directory Servers 823 hinzufügen, so dass der Domain-Controller 514 weitere Nutzer versteht. Dementsprechend kann in einer beispielhaften Ausführungsform der Domain-Controller 514 standardmäßig (by default) drei Nutzer haben: einen Gast (guest), einen Administrator (administrator) und einen Betreiber (operator). Die Informationen können in dem lokalen LDAP Server 822 gespeichert werden. Jedoch kann ein Endnutzer 518 seine eigenen Customer Directory Servers 823 zusammen mit hunderten Nutzern haben. Der Endnutzer 518 sollte in der Lage sein, seinen eigenen Customer Directory Server 823 mit dem Domain-Controller 514 zu verbinden, so dass der Domain-Controller 514 dann von einem der hunderten von Nutzern verwendet werden kann. Die Informationen für die meisten Nutzer können in einem lokalen LDAP Datenverzeichnis (zum Beispiel Openldap) gespeichert werden. Wie Fachleute anerkennen werden, muss mit den Vorteilen dieser Offenbarung, falls ein Domain-Controller 514 unter dem Linux-System läuft, das Linux-System davon wissen, dass die Nutzerinformationen in dem lokalen LDAP Datenverzeichnis gespeichert sind und muss die Secure Shell (SSH) oder Telnet Autorisierung für die Nutzer mittels LDAP ermöglichen.
Jeder Systemmanager muss den Sicherheitsmanager 820 überprüfen, um zu bestimmen, ob eine Handlung durchgeführt werden kann oder nicht, wodurch eine Funktions-basierte (role based) Zugangskontrolle ermöglicht wird. In einer Ausführungsform kann das System nur zwei Rollen erlauben: (1) Eine Gastrolle mit nur Lese-Rechten und (2) eine administrative Rolle mit Schreib-/Lese-Rechten.
Zusätzlich kann der Sicherheitsmanager die Firewall setzen und den Verkehr beschränken, der aus dem Domain-Controller 514 heraus und in diesen hinein geht. In einer Ausführungsform können die Operationen des Systems vereinfacht werden, dadurch dass der Sicherheitsmanager 820 vorhanden ist, der den gesamten abgehenden Verkehr ermöglicht, während er den ankommenden Verkehr beschränkt.
In einer Ausführungsform kann der Domain-Controller 514 einen Domain-Controller-Manager 824 einschließen, der für das Managen des Domain-Controllers 514 selber verantwortlich ist. Die Funktionen des Domain-Controller-Managers 824 können beispielsweise einschießen, das Vernetzen des Domain-Controllers 514, das Neustarten des Domain-Controllers 514, usw. Zusätzlich kann der Domain-Controller-Manager 824 die Abfrage von Log-Einträgen von dem darunterliegenden Dateisystem erlauben.
Der Domain-Controller 514 kann ferner einen Redundanz-Manager 826 einschließen. Der Redundanz-Manager 826 ist für das Senden und/oder das Empfangen von „Herzschlägen” („heart beats”) von den Domain-Controllern in dem Netzwerk verantwortlich wie zum Beispiel dem sekundären Domain-Controller 524. Es ist die Aufgabe des Redundanz-Managers 826 sicherzustellen, dass, wenn ein Domain-Controller abstirbt, ein anderer ohne Unterbrechungen des Systemleistungsverhaltens übernimmt.
In einer Ausführungsform kann der Domain-Controller 514 betriebsfähig sein, um als ein Trivial File Transfer Protocol („TFTP”) für Datentransfers zu wirken, wie etwa wenn Datei-Aktualisierungen gemacht werden. In ähnlicher Weise kann der Domain-Controller 514 betriebsfähig sein als ein Dynamic Host Configuration Protocol („DHCP”) für eine dynamische IP-Adresskonfiguration zu wirken, wenn der Controller nicht in der Lage ist, eine physikalische Position zu erfassen. Zusätzlich kann der Domain-Controller 514 betriebsfähig sein, als ein Simple Network Time Protocol („SNTP”) Server zu wirken, um die Zeit für alle Controller in dem Netzwerk zu synchronisieren.
Zusätzlich zu den Managern 802 umfasst der Domain-Controller 514 Schnittstellen 804. In einer Ausführungsform kann der Domain-Controller 514 eine Scriptfähige (scriptable) Command Line Interface („CLI”) (Kommandozeilen-Schnittstelle) 828 einschließen. In einer Ausführungsform kann das Command Line Interface mit ähnlichen Merkmalen wie die Systems Management Architecture for Server Hardware („SMASH”)/Communication Link Protocol („CLP”) geschrieben werden. Die gesamten Systemfähigkeiten können durch die Scriptfähige CLI 828 dargestellt werden. Die Script-fähige CLI 828 kann mit einem Endnutzer 518 unter Verwendung des SSH oder des Telnet Protokolls kommunizieren.
Mit dem seriellen Konsolendienst 712 in der gepufferten Betriebsart kann der Endnutzer 518 sich in den Domain-Controller 514 zum Zugreifen auf die CLI 828 einloggen. In der CLI 828 kann der Endnutzer 518 den Befehl zum Zugreifen auf die gepufferten Daten eintippen. In Antwort darauf führt die CLI 828 eine Aufgabe in dem Gerätemanager 806 durch. Der Gerätemanager 806 kann dann eine TCP/IP Nachricht an den geeigneten Knoten-Controller 502 zum Anfordern von gepufferten seriellen Daten senden. Der Knoten-Controller 502 wird dann eine Erwiderungsnachricht erzeugen und seine FIFO gepufferten Daten in diese Erwiderung stellen. Die Nachricht wird von dem Gerätemanager 806 durch das Netzwerk empfangen und der Gerätemanager 806 wird auf die CLI 828 mit den Daten erwidern. Die Daten können dann durch die CLI 828 angezeigt werden. Wenn die gepufferte Betriebsart vorliegt, wird die Übertragung von seriellen Daten von der Hauptplatine an den FIFO des Knoten-Controllers 502 niemals unterbrochen.
In einer Ausführungsform kann der serielle Konsolendienst 712 in der interaktiven Betriebsart betriebsfähig sein, der es einem Endnutzer 518 erlaubt mit einem Server 107 durch seinen seriellen Anschluss in Wechselwirkung zu treten. In dieser Ausführungsform kann der Endnutzer 518 sich in den Domain-Controller 514 einloggen, um auf die CLI 828 mittels SSH oder Telnet zuzugreifen. Der Endnutzer 518 kann dann den Befehl eintippen, um eine interaktive Sitzung mit einem Server 107 in einem Schlitten 106 zu starten. Dabei führt die CLI 828 eine Aufgabe in dem Geräte-Manager 806 aus. Der Geräte-Manager 806 sendet eine TCP Nachricht an den geeigneten Knoten-Controller 502, um den Start der interaktiven Sitzung anzufordern. Der Knoten-Controller 502 kann dann den Befehl bestätigen und dem Domain-Controller 514 erwidern, dass er bereit ist. Zusätzlich kann der Knoten-Controller 502 einen Thread erzeugen (spawn), der Daten an den Universal Asynchronous Receiver/Transmitter („UART”) senden und von diesem empfangen wird. Der Geräte-Manager 806 erwidert der CLI 828, dass die Verbindung bereit ist und die CLI 828 startet eine TCP Verbindung zu dem Knoten-Controller 502 mit dem zum Senden und Empfangen von Daten gegebenen Anschluss. Immer, wenn ein Zeichen empfangen wird, kann es an den Knoten-Controller 502 weitergeleitet werden, der das empfangene Zeichen dann an den seriellen Anschluss des bestimmten Servers 107 weiterleiten wird. Nun kann der Knoten-Controller 502 den seriellen Anschluss des Servers 107 lesen und die Antwort zurück durch die TCP Verbindung an die CLI 828 senden. Der Thread/Prozess an dem Geräte-Manager 806 kann dann die Daten in die CLI 828 einstellen. Der Endnutzer 518 kann die interaktive Sitzung durch Eingeben geeigneter Befehle in die CLI 828 verlassen. Falls die gepufferte Betriebsart eingeschaltet ist, wird sie nicht mit der interaktiven Sitzung interferieren. Vielmehr sollte sie sich normal verhalten und die Ausgabe des seriellen Konsolendienstes 712 aufzeichnen. Da ferner der Domain-Controller 514 einen seriellen Anschluss aufweist, kann der Kunde auf die CLI 828 über diesen Anschluss zugreifen und irgendwelche CLI Befehle durchführen einschließlich serial over LAN Befehle an einen Server 107.
Die Schnittstellen 804 des Domain-Controllers 514 können ferner ein SNMP 830 einschließen, das benutzt werden kann, um grundlegende Systemoperationen durchzuführen wie etwa zum Beispiel das Managen der elektrischen Energie der Knoten, das Lesen des Inventars, usw.
Eine Intelligent Platform Management Interface („IPMI”, intelligente Plattform-Management-Schnittstelle) 832 kann es einem Nutzer 518 ermöglichen IPMI oder Data Center Manageability Interface („DCMI”, Datenzentrum-Manageability-Schnittstelle) Nachrichten durch ein Local Area Network („LAN”, lokales Netzwerk) an den Domain-Controller 514 zu senden. Der Domain-Controller 514 kann IP Aliasing bereitstellen, um mehrere IP Adressen zu dem Netzwerk aufzudecken, wobei jede einem spezifischen Schlitten 106 zugeordnet ist. Die Nachricht wird von dem Domain-Controller 514 empfangen und an den geeigneten Schlitten 106 weitergeleitet. Der Knoten-Controller 502 kann das unbearbeitete IPMI Packet, das in der Remote Management and Control Protocol+ („RMCP+”) Nachricht enthalten ist, bearbeiten und jeder IPMI Software-Stapel (IPMI software stack) wird von dem Domain-Controller 514 bearbeitet.
Eine MPMI Schnittstelle kann ferner für jedes Rack 102 in dem Domain-Controller 514 existieren und kann OEM Befehle für das Management auf Rack-Ebene bereitstellen. Zum Beispiel kann das Management auf Rack-Ebene das Auflisten des Inventars des Baugruppenträgers 104 in einem Rack 102 einschließen einschließlich der darin enthaltenen Schlitten 106, der Positionen der Schlitten 106 innerhalb des Baugruppenträgers 104, der IPMI Adresse der Schlitten 106, die gemanagt werden sollen und des Status der Schlitten 106. Zusätzlich kann das Management auf Rack-Ebene Informationen von Lüfter-Controllern 508 einschließen wie etwa zum Beispiel der Status von jedem Lüfter 108 und/oder die Geschwindigkeit von jedem Lüfter 108. Das Management auf Rack-Ebene kann ferner Informationen über die Energiemodul-Controller 512 einschließen wie etwa den Status von jeder PDU, der verbrauchten elektrischen Energie, ebenso wie eine Anzeige von kritischen Maßnahmen des Baugruppenträgers 104 wie etwa des gesamten Energieverbrauchs und der maximalen Temperatur.
Der Domain-Controller 514 kann ferner SMASH Schnittstellen 834 einschließen. SMASH ist ein Standard-Management-Framework, das oberhalb der Manager 802 platziert werden kann. Wie Fachleute anerkennen werden, verwendet SMASH einen Objekt-orientierten Ansatz zum Definieren von Management- und Überwachungsfähigkeiten eines Systems und verwendet „Bereitsteller” („providers”), um Daten von dem Managementsystem in das Objekt-orientierte Framework zu bekommen. Ein Vorteil der Verwendung von SMASH Schnittstellen ist es, dass sie die Verwendung von Standard-Nutzerschnittstellen wie etwa SMASH/CLP 836 für Befehlszeilen-Schnittstellen (command line interfaces) und Common Information Model(„CIM”)/Extensible Markup Language („XML”) oder Web Service-Management („WS-MAN”) 838 für Web-Dienste erlauben.
In einer Ausführungsform kann ein Betriebssystem-Wächter (Operating System watchdog) 840 ständig den Status von verschiedenen Systemkomponenten überprüfen und die notwendigen Komponenten im Falle eines Ausfalls oder eines Absturzes neu zu starten.
In einer Ausführungsform kann der Domain-Controller 514 für das Erzwingen einer Energiedeckelung (power cap) zuständig sein, falls diese von dem Nutzer als Teil der Energiedeckelungsstrategie (power capping policy) auf Rack-Ebene eingerichtet wurde. In dieser Ausführungsform können die Energieüberwachungssensoren (nicht gezeigt) mit einer vorbestimmten Frequenz aktualisiert werden. Eine Energieschwelle kann Ausnahmeregelungshandlungen durchführen, wie sie von dem periodischen Durchlaufen einer Energieoption oder von einem Log gefordert werden, falls der Energieverbrauch die Schwellengrenze für eine spezifizierte Zeitdauer übersteigt. Die Ausnahmezeitgrenze kann ein Vielfaches der Energieüberwachungsabtastzeit sein. Während des Betriebs kann der Nutzer 518 eine vorbestimmte Energiedeckelung für den Baugruppenträger 104 definieren. Der Domain-Controller 514 kann dann eine Nachricht an den Knoten-Controller 502 senden, um die Energiedeckelung zu starten. Diese Nachricht kann eine Energieschwelle umfassen, eine Ausnahmezeitgrenze, die Maßnahme, die zu durchzuführen ist, wenn die Ausnahmezeitgrenze überschritten wird und eine Notfallzeitgrenze. Das System kann dann eingestellt werden, um die Schwelle zu deckeln oder einfach das Ereignis des Überschreitens der Schwelle zu protokollieren. Wie Fachleute anerkennen werden, kann mit den Vorteilen der vorliegenden Offenbarung der Schwellenwert als ein mittlerer Energieverbrauch über eine vorbestimmte Zeitdauer bezeichnet werden. In einer Ausführungsform kann, falls der Energieverbrauch die Schwelle übersteigt, eine Benachrichtigung an den Domain-Controller 514 gesendet werden. Falls der Energieverbrauch unter die Schwelle vor dem Ablauf des Zeitlimits fällt, wird der Knoten-Controller 502 keine weitere Handlung unternehmen. Falls jedoch die Zeitgrenze abläuft, kann der Knoten-Controller 502 in Abhängigkeit der Anweisungen, die er von dem Domain-Controller 514 erhalten hat, eine Deckelung erzwingen oder eine Benachrichtigung verursachen. Falls die Deckelungsprozedur, die von dem Knoten-Controller 502 implementiert wird, erfolgreich ist, kann das System seinen Betrieb fortsetzen. Falls jedoch die Notfallzeitgrenze erreicht ist und der Energieverbrauch nicht unter den Schwellenwert zurückgegangen ist, werden die Server 107 abgeschaltet. In einer Ausführungsform kann der Knoten-Controller 502 die Energiedeckelungseinstellungen in einem Flash-Speicher speichern, so dass die Einstellungen sogar nach einem Reset erhalten bleiben. Der Domain-Controller 514 kann dann die Energiedeckelungsfähigkeiten des Systems freigeben oder abschalten. Dementsprechend kann ein Endnutzer 518 die Energiedeckelung freigeben oder abschalten und/oder die verschiedenen Engergiedeckelungsparameter durch die CLI 828 und dem Domain-Controller 514 zuordnen.
In einer beispielhaften Ausführungsform kann eine auf Rack-Ebene blinde Deckelung verwendet werden, um die Energiedeckelung den Servern 107 zuzuweisen. In dieser Ausführungsform wird die Deckelung gleichmäßig auf alle Server 107 in dem Rack 102 aufgeteilt. Das Verfahren ist nützlich, wenn alle Server ähnliche Eigenschaften aufweisen und eine ähnliche Funktionalität bereitstellen. In einer weiteren Ausführungsform kann eine auf Rack-Ebene gerechte Deckelung zum Zuweisen der Energiedeckelung an die Server 107 verwendet werden. In dieser Ausführungsform wird die Energiedeckelung durch Ermöglichen der Neuverteilung von Energie unter den Servern 107 erzwungen, um so viel wie möglich an Energiedeckelung für die Server zu vermeiden, die mehr ausgelastet sind (im Allgemeinen diejenigen, die mehr Energie verbrauchen). Dies ist ein kontinuierlicher Prozess und es ist ein guter Ansatz um ein Reduzieren des Leistungsverhaltens der kritischsten Server zu verhindern, obwohl das Leistungsverhalten der Server die am wenigsten Energie verbrauchen am meisten beeinflusst werden wird. Wie Fachleute anerkennen werden, sollte mit den Vorteilen dieser Offenbarung in jedem Verfahren, wenn ein Server nicht mehr weiter gedeckelt werden kann (d. h. weitere Versuche zum Reduzieren des Energieverbrauchs würden fehlschlagen) eher abgeschaltet werden, so dass das Energiebudget garantiert wird.
In Beispielen in denen der Endnutzer 518 spezifische Leistungsverhaltensziele für eine Anwendung hat (zum Beispiel eine Antwortzeit auf Anfragen), kann die Energiedeckelung verwendet werden, um die Energie in den Servern 107 zu reduzieren, während gleichzeitig die Leistungsverhaltensziele aufrechterhalten werden, wobei letztendlich die Betriebsausgaben des Baugruppenträgers 104 verringert werden. Dementsprechend kann der Endnutzer 518 zuerst den Energieverbrauch in einem Rack 102 oder in einem Satz von Servern 107 abfragen und das System deckeln, um den Energieverbrauch zu reduzieren. Der Endnutzer 518 kann dann das Leistungsverhalten der Anwendung unter dem festgelegten Energieschema messen. Dieser Prozess kann durchgeführt werden, bis ein optimales Leistungsverhalten und eine Energiedeckelungskonfiguration identifiziert ist.
In einer beispielhaften Ausführungsform kann der Endnutzer 518 eine Deckelung auf einen Server 107 anwenden. In einer anderen Ausführungsform kann eine auf Gruppen-Ebene blinde Deckelung zum Bestimmen der Energiedeckelung für die Systemkomponenten verwendet werden. In dieser Ausführungsform kann sobald die optimale Energiedeckelung durch Experimentieren identifiziert worden ist, die gleiche Deckelung für einen oder mehrere Server in dem Rack 102 angewendet werden (es wird erwartet, dass die Server die gleichen Anwendungen ausführen, die verwendet wurden, um die optimale Deckelung zu bestimmen). Da die Script-fähige CLI 828 es einem Endnutzer 518 erlaubt Energiedeckelung auf einer Server-Ebene einzustellen und den Energieverbrauch von verschiedenen Geräten in einem Rack 102 auszulesen, könnte der Endnutzer den Energiedeckelungsprozess von einem externen Server kontrollieren.
In einigen Beispielen kann es wünschenswert sein, die Energiedeckelung im Falle kritischer Ausfälle in dem Kühlsystem anzuwenden. Zum Beispiel könnte, falls die Einlasstemperatur drastisch ansteigt, ein Drosseln der Systemkomponenten über eine Deckelung helfen, um zeitweise die Systemtemperatur zu reduzieren ohne die Notwendigkeit auf den internen thermischen Auslöser (trip) zu warten. Im Speziellen kann der Endnutzer 518 einen gewünschten Prozentsatz der Reduktion des Energieverbrauchs für den Fall voreinstellen, dass die thermische Sensor-Ablesung eine bestimmte Temperatur übersteigt. Der Energieverbrauch kann dann im Falle eines thermischen Notfalls entsprechend reduziert werden.
In einer Ausführungsform kann der Endnutzer eine Abschätzung des Energieverbrauchs von einem Server 107 und/oder des gesamten Energieverbrauchs in einem Rack 102 einschließlich der Server, der Lüfter und der Schalter usw. abschätzen. In dieser Ausführungsform hat der Domain-Controller 514 Zugriff auf aktuelle Sensor-Informationen von jedem Controller einschließlich des Knoten-Controllers 502 (für Messungen auf Server-Ebene) und des Energiemodul-Controllers 512 (für PDU Messungen). Demgemäß kann die gesamte Energie, die von einem Rack 102, einem Baugruppenträger 104 oder von einem Server 107 zu einer gegebenen Zeit verbraucht wird, berechnet werden. Zusätzlich kann der Endverbraucher die Script-fähige CLI 828 verwenden, um die Energieverbräuche von individuellen Servern 107 abzulesen und diese Ablesungen verwenden, um Berechnungen auf einem externen Server durchzuführen.
Nun der 9 zuwendend wird ein gemeinsam genutztes Energieversorgungssystem in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung im Allgemeinen mit dem Bezugszeichen 900 bezeichnet. In dieser beispielhaften Ausführungsform gibt es fünf Schlitten 106 pro Baugruppenträger 104. Wie jedoch von Fachleuten anerkannt werden wird, können mit den Vorteilen dieser Offenbarung die hierin offenbarten Verfahren und Systeme auf eine verschiedene Anzahl von Schlitten 106 pro Baugruppenträger 104 angewendet werden kann. In einer Ausführungsform ermöglicht das gemeinsam genutzte Energieversorgungssystem 900 das gemeinsame Nutzen von 12 V von einer PDU 902 zu einem oder mehreren Baugruppenträgern 104. Wie in den 2 und 3 gezeigt ist, können die Schlitten 106 mit einer gemeinsamen Rückwand 112 in dem Baugruppenträger 104 für Energie- und Managementzwecke verbunden sein. In einer Ausführungsform können zwei oder mehrere 4U Baugruppenträger 104 eine PDU 902 gemeinsam verwenden, einschließlich von 1 + N PSUs 904, wodurch eine Energie-Domain erzeugt wird. Jedes Rack 102 kann zwei oder mehr Energie-Domains einschließen. Ferner können Drittparteiprodukte (third party products) wie etwa Schalter vor der PDU 902 bereitgestellt werden.
In einer Ausführungsform kann eine Busschiene (bus bar) 906 pro Baugruppenträger 104 zum Verteilen elektrischer Energie bereitgestellt werden. Insbesondere können, da die Baugruppenträger 104 oben oder über anderen Baugruppenträgern 104 oder dem Energiemodul 510 angeordnet sind, die Busschienen 906 in der Rückwand des Baugruppenträgers 104 zum Verteilen der elektrischen Energie benutzt werden. In einer weiteren beispielhaften Ausführungsform können Kabel eine direkt verbundene Verteilung der elektrischen Energie von dem Energiemodul 510 zu jedem Baugruppenträger 104 bereitstellen.
Die 10 stellt die Verbindung eines Baugruppenträgers 104 an eine PDU 902 dar. Wie Fachleute anerkennen werden, kann mit den Vorteilen dieser Offenbarung mehr als ein Baugruppenträger 904 mit einer PDU 902 verbunden werden. Ferner kann eine PDU 902 eine oder mehrere PSUs 904 einschließen. In einer Ausführungsform kann die PDU 902 N + 1 PSUs 904 für Redundanzwecke einschließen, wobei N die Anzahl der Schlitten 106 ist, die von der Energieversorgung gespeist werden. Speziell ermöglicht das Verwenden von N + 1 PSUs 904 der PDU 902 die Lastanforderungen zu befriedigen, während gleichzeitig Redundanz bereitgestellt wird, so dass, wenn eine PSU 904 abstirbt, eine zusätzliche PSU 904 verbleibt, um die Last zu übernehmen. Wie in der 10 gezeigt ist, kann die Busschiene 906 der PDU 902 mit der Busschiene 908 des Baugruppenträgers 104 durch ein oder mehrere Stromkabel verbunden werden. Die Busschiene 908 kann dann elektrische Energie an den Schlitten 106 durch die Rückwand 112 liefern.
Obwohl beispielhafte Ausführungsformen in Verbindung mit Servern in einem Rack beschrieben werden, werden Fachleute anerkennen, dass die Vorteile dieser Offenbarung der vorliegenden Erfindung nicht auf Server beschränkt sind und in Verbindung mit anderen Informationsverarbeitungssystemen wie etwa Datenspeichergeräten eingesetzt werden können. Darüber hinaus sind das System und die hierin offenbarten Verfahren nicht auf Systeme beschränkt, die ein Rack einschließt und können in Verbindung mit zwei oder mehreren Racks verwendet werden. Wie Fachleute anerkennen werden, ermöglichen die Vorteile dieser Offenbarung in Mehr-Rack-Systemen dem Domain-Controller 514 die Skalierbarkeit und können Mehr-Rack-Managementfähigkeiten unterstützen indem Management-Schalter anderer Racks mit dem Aggregations-Schalter 516 verbunden werden.
Obwohl die vorliegende Offenbarung in Detail beschrieben worden ist, sollte verstanden werden, dass verschiedene Änderungen, Ersetzungen und Abänderungen hierzu gemacht werden können ohne von dem Geist und dem Geltungsbereich der Erfindung, wie er in den anhängenden Ansprüchen definiert ist, abzuweichen.

Claims

Ein modulares Informationsverarbeitungssystem-Framework aufweisend: ein Rack, das zumindest einen Baugruppenträger enthält; einen Schlitten, der in dem Baugruppenträger platziert ist; wobei der Schlitten zumindest ein Informationsverarbeitungssystem umfasst; einen Lüfter, der in dem Baugruppenträger platziert ist, um das Informationsverarbeitungssystem zu kühlen; einen Lüfter-Controller, der kommunikativ mit dem Lüfter verbunden ist; wobei der Lüfter-Controller den Betrieb des Lüfters managt; einen Knoten-Controller, der dem Schlitten zugeordnet ist; wobei der Knoten-Controller den Betrieb des Schlittens managt; ein Energiemodul zum Liefern elektrischer Energie an das Informationsverarbeitungssystem; einen Energiemodul-Controller zum Managen des Betriebs des Energiemoduls; und einen primären Domain-Controller, der kommunikativ mit zumindest einem Element aus der Gruppe des Lüfter-Controllers, des Knoten-Controller und des Energiemoduls verbunden ist; wobei der primäre Domain-Controller den Betrieb zumindest eines Elements aus der Gruppe des Lüfter-Controllers, des Knoten-Controllers und des Energiemoduls managt.
Das System gemäß Anspruch 1, wobei der primäre Domain-Controller eine Nutzerschnittstelle für das modulare Informationsverarbeitungssystem-Framework bereitstellt.
Das System gemäß Anspruch 2, wobei der primäre Domain-Controller betriebsfähig ist zum Anzeigen von Informationen, die sich auf das Leistungsverhalten des modularen Informationsverarbeitungssystem-Frameworks an den Nutzer beziehen.
Das System gemäß Anspruch 2, wobei der primäre Domain-Controller es einem Nutzer ermöglicht die Leistungsverhaltensparameter des modularen Informationsverarbeitungssystem-Frameworks zu kontrollieren.
Das System gemäß Anspruch 1, ferner aufweisend einen sekundären Domain-Controller, wobei der sekundäre Domain-Controller den Betrieb zumindest eines Elements aus der Gruppe des Lüfter-Controllers, des Knoten-Controllers und dem Energiemoduls managt, wenn der primäre Domain-Controller betriebsunfähig wird.
Das System gemäß Anspruch 5, ferner aufweisend eine Management-Vorrichtung, wobei die Management-Vorrichtung ein Element aus der Gruppe des primären Domain-Controllers, des sekundären Domain-Controllers und eines Management-Schalters umfasst.
Das System gemäß Anspruch 1, wobei der Domain-Controller kommunikativ mit zumindest einem Element aus der Gruppe des Energiemodul-Controllers, des Lüfter-Controllers und des Knoten-Controllers durch ein Management-Netzwerk verbunden Ist.
Das System gemäß Anspruch 7, wobei das Management-Netzwerk ein Ethernet-Netzwerk ist.
Das System gemäß Anspruch 1, wobei das Informationsverarbeitungssystem aus der Gruppe ausgewählt ist, die einen Server und ein Datenspeichergerät aufweist.
Das System gemäß Anspruch 1, ferner aufweisend einen oder mehrere Sensoren zum Überwachen von Betriebsbedingungen von zumindest einem Element aus der Gruppe des Schlittens, des Lüfters und des Energiemoduls.
Das System gemäß Anspruch 10, wobei der eine oder die mehreren Sensoren aus einer Gruppe ausgewählt werden, die einen Temperatursensor und einen Energieüberwachungssensor umfasst.
Das System gemäß Anspruch 1, wobei der primäre Domain-Controller einen oder mehrere Manager und eine oder mehrere Schnittstellen umfasst.
Das System gemäß Anspruch 10, wobei der primäre Domain-Controller umfasst: einen Gerätemanager, der kommunikativ mit einem oder mehreren Sensoren verbunden ist; wobei der Gerätemanager Sensordaten von dem einen oder den mehreren Sensoren empfängt; ein Domain-Controller-Manager zum Managen des primären Domain-Controllers; ein Sicherheitsmanager zum Authentifizieren von Verbindungen mit dem primären Domain-Controller; und einen Benachrichtigungs-Manager zum Überwachen von Sensordaten, die von dem Gerätemanager empfangen werden.
Das System gemäß Anspruch 13, wobei der Benachrichtigungs-Manager eine Benachrichtigung erzeugt, wenn Sensordaten das Auftreten eines interessierenden Ereignisses anzeigen.
Das System gemäß Anspruch 14, wobei das interessierende Ereignis aus der Gruppe ausgewählt wird, die Sensordaten zum Anzeigen einer Temperatur, die einen Schwellentemperaturwert übersteigt und Sensordaten zum Anzeigen eines Energieverbrauchs, der einen Schwellenwert übersteigt, umfasst.
Das System gemäß Anspruch 14, wobei der Benachrichtigungs-Manager die Benachrichtigung für einen Endnutzer durch eine Nutzerschnittstelle erzeugt.
Das System gemäß Anspruch 5, wobei der primäre Domain-Controller einen Redundanz-Manager umfasst, wobei der Redundanz-Manager Kommunikationen zwischen dem primären Domain-Controller und dem sekundären Domain-Controller ermöglicht.
Das System gemäß Anspruch 17, wobei der Betrieb des primären Domain-Controllers auf den sekundären Domain-Controller übertragen wird, wenn der sekundäre Domain-Controller unfähig zum Kommunizieren mit dem Redundanz-Manager ist.
Das System gemäß Anspruch 13, wobei der Gerätemanager einen Zwischenspeicher zum Puffern von Sensordaten einschließt, die von dem einen oder den mehreren Sensoren empfangen werden.
Das System gemäß Anspruch 19, wobei die Sensordaten mit einer vorgegebenen Frequenz von dem Zwischenspeicher in einen permanenten Speicher bewegt werden.
Das System gemäß Anspruch 1, wobei der Lüfter-Controller umfasst: einen Identifikationsdienst zum Identifizieren der physikalischen Position des Lüfter-Controllers in dem System; einen Benachrichtigungsdienst, der betriebsfähig ist zum Senden von Nachrichten von dem Lüfter-Controller an den primären Domain-Controller; einen Befehlsabhördienst zum Empfangen von Nachrichten von dem primären Domain-Controller; einen Überwachungsdienst; wobei der Überwachungsdienst Daten von einem oder mehreren Sensoren verfolgt, die dem Lüfter zugeordnet sind; eine dynamische Lüfterkontrolle zum Regeln der Geschwindigkeit des Lüfters auf der Grundlage von Informationen, die von dem Überwachungsdienst verfügbar sind; einen Logdienst, der betriebsbereit ist zum Empfangen und Speichern von Nachrichten von Komponenten des Lüfter-Controllers; und ein Herzschlagsignal zum Bestimmen, ob der Lüfter-Controller in Betrieb ist.
Das System gemäß Anspruch 21, wobei der Überwachungsdienst ein Signal für den Benachrichtigungsdienst erzeugt, wenn Daten von dem einen oder der mehreren Sensoren ein interessierendes Ereignis anzeigen.
Das System gemäß Anspruch 20, wobei die dynamische Lüfterkontrolle einen Proportional-Integral-Differenzial-Controller umfasst.
Das System gemäß Anspruch 21, wobei das Herzschlagsignal den Lüfter anleitet bei maximaler Geschwindigkeit zu arbeiten, wenn der Lüfter-Controller betriebsunfähig ist.
Das System gemäß Anspruch 1, wobei der Knoten-Controller elektrische Energie für den Schlitten managt.
Das System gemäß Anspruch 1, wobei der Knoten-Controller umfasst: einen Identifikationsdienst zum Identifizieren der physikalischen Position des Knoten-Controllers in dem System; einen Benachrichtigungsdienst, der betriebsbereit ist zum Senden von Nachrichten von dem Knoten-Controller an zumindest ein Element aus der Gruppe des primären Domain-Controllers und des Lüfter-Controllers; einen Befehlsabhörer zum Empfangen von Nachrichten von dem primären Domain-Controller; einen seriellen Konsolendienst zum Verbinden mit dem Informationsverarbeitungssystem; einen Überwachungsdienst; wobei der Überwachungsdienst Daten von einem oder mehreren Sensoren verfolgt, die dem Schlitten zugeordnet sind; und einen Logdienst, der betriebsfähig ist zum Empfangen und Speichern von Nachrichten von einer oder mehrerer Komponenten des Knoten-Controllers.
Das System gemäß Anspruch 26, wobei der Überwachungsdienst betriebsfähig ist zum Erzeugen eines Signals an den Benachrichtigungsdienst, wenn Daten von einem oder mehreren Sensoren ein interessierendes Ereignis anzeigen.
Das System gemäß Anspruch 1, wobei der Knoten-Controller kommunikativ mit dem Lüfter-Controller verbunden ist.
Das System gemäß Anspruch 1, wobei zumindest ein Element aus der Gruppe des Lüfter-Controllers und des Knoten-Controllers eine Konfigurationsdatei einschließt, die dessen Betriebsparameter beinhaltet.
Das System gemäß Anspruch 1, wobei der primäre Domain-Controller betriebsfähig ist zum Konfigurieren der Konfigurationsdatei des Lüfter-Controllers und der Konfigurationsdatei des Knoten-Controllers.
Ein modulares Rack-System aufweisend: eine Mehrzahl von Baugruppenträgern, die in einem oder mehreren Racks platziert sind; eine Mehrzahl von Schlitten, die in jedem Baugruppenträger platziert ist; wobei jeder Schlitten ein Informationsverarbeitungssystem umfasst; ein gemeinsam genutztes Lüftermodul zum Kühlen der Mehrzahl von Schlitten in jedem Baugruppenträger; ein gemeinsam genutztes Energiemodul zum Liefern elektrischer Energie an den einen oder die mehreren Schlitten in einem oder mehreren Baugruppenträgern; und ein gemeinsam genutztes Managementmodul zum Managen des Betriebs der Mehrzahl der Baugruppenträger.
Das System gemäß Anspruch 31, wobei das gemeinsam genutzte Lüftermodul einen oder mehrere Lüfter und einen Lüfter-Controller umfasst zum Kontrollieren des Betriebs des gemeinsam genutzten Lüftermoduls.
Das System gemäß Anspruch 32, wobei der Lüfter-Controller umfasst: einen Identifikationsdienst zum Identifizieren der physikalischen Position des Lüfter-Controllers innerhalb des Systems; einen Benachrichtigungsdienst, der betriebsfähig ist zum Senden von Nachrichten von dem Lüfter-Controller an den primären Domain-Controller; einen Befehlsabhördienst zum Empfangen von Nachrichten von dem primären Domain-Controller; einen Überwachungsdienst; wobei der Überwachungsdient Daten von einem oder mehreren Sensoren verfolgt, die dem Lüfter zugeordnet sind; eine dynamische Lüfterkontrolle zum Regulieren der Geschwindigkeit des Lüfters auf der Grundlage von Informationen, die von dem Überwachungsdienst verfügbar sind; einen Logdienst, der betriebsbereit ist zum Empfangen und Speichern von Nachrichten von Komponenten des Lüfter-Controllers; und ein Herzschlagsignal zum Bestimmen, ob der Lüfter-Controller in Betrieb ist.
Das System gemäß Anspruch 33, wobei der Überwachungsdienst betriebsfähig ist zum Erzeugen eines Signals an den Benachrichtigungsdienst, wenn Daten von dem einen oder den mehreren Sensoren ein interessierendes Ereignis anzeigen.
Das System gemäß Anspruch 31, wobei das gemeinsam genutzte Energiemodul eine Energieverteilungseinheit und einen Energiemodul-Controller umfasst zum Kontrollieren des Betriebs des gemeinsam genutzten Energiemoduls.
Das System gemäß Anspruch 35, wobei die Energieversorgungseinheit eine oder mehrere Energieversorgungseinheiten umfasst.
Das System gemäß Anspruch 31, wobei das gemeinsam genutzte Management-Modul einen primären Domain-Controller umfasst.
Das System gemäß Anspruch 37, wobei der primäre Domain-Controller eine Energiedeckelungsstrategie erzwingt.
Das System gemäß Anspruch 37, wobei der primäre Domain-Controller den Energieverbrauch eines oder mehrerer Komponenten des modularen Rack-Systems verfolgt.
Das System gemäß Anspruch 37, weiterhin aufweisend einen sekundären Domain-Controller, der den primären Domain-Controller ersetzt, wenn der primäre Domain-Controller betriebsunfähig wird.
Das System gemäß Anspruch 37, wobei der primäre Domain-Controller umfasst: einen Gerätemanager, der kommunikativ mit einem oder mehreren Sensoren verbunden ist; wobei der eine oder die mehreren Sensoren die Betriebsbedingungen von zumindest einem Element aus der Gruppe eines Schlittens, einer Komponente des gemeinsam genutzten Lüftermoduls und einer Komponente des gemeinsam genutzten Energiemoduls überwachen; wobei der Gerätemanager Sensordaten von dem einen oder den mehreren Sensoren empfangt; einen Domain-Controller-Manager, der betriebsbereit ist zum Managen des primären Domain-Controllers; einen Sicherheitsmanager, der betriebsbereit ist zum Authentifizieren von Verbindungen zu dem primären Domain-Controller; und einen Benachrichtigungs-Manager, der betriebsbereit ist zum Überwachen von Sensordaten, die von dem Gerätemanager empfangen werden.
Das System gemäß Anspruch 41, wobei der Benachrichtigungs-Manager betriebsbereit ist zum Erzeugen einer Benachrichtigung, wenn Sensordaten das Auftreten eines interessierenden Ereignisses anzeigen.
Das System gemäß Anspruch 37, weiterhin aufweisend einen Knoten-Controller, der einem Schlitten zugeordnet ist.
Das System gemäß Anspruch 43, wobei der Knoten-Controller umfasst: einen Identifikationsdienst zum Identifizieren der physikalischen Position des Knoten-Controllers innerhalb des Systems; einen Benachrichtigungsdienst, der betriebsbereit ist zum Senden von Daten von dem Knoten-Controller an zumindest ein Element aus der Gruppe des primären Domain-Controllers und des gemeinsam genutzten Lüfter-Controllers; einen Befehlsabhörer zum Empfangen von Nachrichten von dem primären Domain-Controller; einen seriellen Konsolendienst zum Verbinden mit dem Informationsverarbeitungssystem in dem Schlitten; einen Überwachungsdienst; wobei der Überwachungsdienst Daten von einem oder mehreren Sensoren verfolgt, die dem Schlitten zugeordnet sind; wobei der Überwachungsdienst betriebsbereit ist zum Erzeugen eines Signals an den Benachrichtigungsdienst, wenn Daten von dem einen oder den mehreren Sensoren ein interessierendes Ereignis anzeigen; und einen Logdienst, der betriebsbereit ist zum Empfangen und Speichern von Nachrichten von einer oder mehreren Komponenten des Knoten-Controllers.
Das System gemäß Anspruch 31, wobei das gemeinsam genutzte Lüftermodul, das gemeinsam genutzte Energiemodul und das gemeinsam genutzte Management-Modul kommunikativ über ein Management-Netzwerk verknüpft sind.
Das System gemäß Anspruch 45, wobei das Management-Netzwerk ein Ethernet-Netzwerk ist.
Das System gemäß Anspruch 31, wobei Energie an die Schlitten durch eine Baugruppenträgerrückwand verteilt wird.