DE60205539T2

DE60205539T2 - Verfahren und Vorrichtung zum Verwalten von mehreren Netzwerkgeräten

Info

Publication number: DE60205539T2
Application number: DE60205539T
Authority: DE
Inventors: Paul C. Seattle Sutton; Curt A. Redmond Steeb; Gang Issaquah Wang; Marin L. Bremerton Holladay; Zeyong Issaquah Xu
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-06-11
Filing date: 2002-06-10
Publication date: 2006-02-16
Anticipated expiration: 2022-06-11
Also published as: EP1267518A3; DE60205539D1; US7237243B2; JP2009205687A; JP2003099410A; US20030037177A1; JP5394123B2; EP1267518B1; ATE302512T1; EP1267518A2

Description

HINTERGRUND DER ERFINDUNG
Daten-Center stellen Rechenressourcen für viele Typen von Organisationen dar, einschließlich Unternehmen und verschiedenen, sich auf das Internet beziehenden Service-Providern, wie beispielsweise Speicher-Service-Providern, Hosting-Service-Providern und Anwendungs-Service-Providern. Ein typischer Daten-Center umfasst irgendwo von hunderten bis zu vielen tausenden Computern, die eine Vielfalt von Rollen für eine Vielfalt von Zwecken übernehmen.
Die Verwaltung einer großen Anzahl von Computern kann kostspielig, zeitaufwendig und fehleranfällig sein. Zum Beispiel finden viele Service-Provider, dass das Betreiben eines Daten-Centers ein arbeitsintensives Geschäft ist, da viele Programm-Vorgänge manuell durchgeführt werden. Anhand eines Beispiels besteht ein Vorgang, einen neuen Server online für einen neuen Kunden zu bringen, darin, dass ein Ingenieur die neue Bestellung eines Kunden ausdrucken muss, ein Betriebssystem installieren muss, irgendwelche Anwendungen installieren muss, das Betriebssystem und Anwendungen konfigurieren muss und die Server-Maschine in den Daten-Center bringen muss, um sie an das Netzwerk und an eine Energieversorgung anzuhängen. Der Vorgang, einen neuen Server online zu bringen, ist demzufolge ein langer und kostspieliger Vorgang und ist für einen Fehler anfällig.
Ähnliche, manuelle Vorgänge werden dann verwendet, wenn eine existierende Server-Konfiguration für einen neuen Kunden über eine Software „wieder vorgesehen werden soll" („reprovisioned"). Tatsächlich sind die Kosten eines Wiedervorsehens so groß, dass rd einige Service-Provider günstiger finden, dies nicht vorzunehmen. Ein Teil der Kosten ist so, dass nicht benutzte Systeme normalerweise über ein kostspieliges, manuelles Auditieren des Daten-Centers angeordnet werden können. Ähnlich kann es, im Gegensatz dazu, einem Computer, der nicht länger benötigt wird, umzugruppieren, kostengünstiger sein, den Server-Computer in dem Daten-Center zu belassen (laufenzulassen und Energie zu verbrauchen), oder vollständig den Computer zu zerlegen, im Gegensatz dazu, zu versuchen, ihn umzugruppieren.
In der Summe erfordert das Betreiben eines Daten-Centers, dass eine Anzahl von Kompromissen eingegangen wird, die aus praktischen Gründen notwendig sind, allerdings nicht sehr wünschenswert sind. Zum Beispiel kann es, anstelle davon, Computer umzugruppieren, billiger sein, dies nicht vorzunehmen, allerdings bedeutet dies, dass Daten-Center Computersysteme haben und laufenlassen (unter Verwendung von Energie, Klimaanlagen und Netzwerk-Ports), auch dann, wenn sie nicht länger für einen Dienst erforderlich sind.
Als ein anderes Beispiel ist, obwohl es teurer ist, ein manuelles Konfigurieren von verschiedenen Servern noch die Art und Weise, in der Daten-Center arbeiten. Allerdings ist ein Verringern solcher Kosten über eine Automatisierung ein solches Unterfangen, das bisher nicht erfolgreich gewesen ist, und zwar unter anderen Schwierigkeiten, da ein solcher Versuch eine Integration von mehreren, externen Produkten erfordert.
Die WO-A-98 09402 bezieht sich auf ein Verfahren zum Verwalten einer Vielzahl von Computer-Workstations, die miteinander über ein Netzwerk verbunden sind. Eine Verwaltung der Workstations wird als eine von aktualisierenden (lesen von oder schreiben auf) Datenbank-Zugängen und als eine Folge von/zu den realen Workstation-Agenten gesehen. Die Vielzahl von Nodes (Knoten) wird in Gruppen aufgeteilt und die Gruppen werden so verwaltet, als wären sie individuelle Workstations. Das bedeutet, dass eine Aktualisierung zu einer Gruppe eines (zum Beispiel) Parameters 5 auf einer Gruppe bewirken wird, dass das Verwaltungssystem eine Aktualisierungs-Anweisung zu allen Nodes, enthalten in dieser Gruppe, zum Beispiel eine Aktualisierung zu einem Parameter 5, sendet. Um zu definieren, welche Gruppierungen wesentlich sind, und um zu definieren, welche der Nodes zu welcher Gruppe gehören sollten, entscheidet ein Netzwerk-Administrator über die Gruppe-Mitgliedschaft-Bedingungen und konfiguriert seine Verwaltungsstation entsprechend. Dies wird dann in Scripten oder Programmen zusammengestellt, die zu allen Workstation-Agenten auf dem Netzwerk gesendet werden. Die Entscheidungen für eine Gruppenmitgliedschaft werden durch jede Workstation selbst und unabhängig von irgendwelchen anderen vorgenommen. An jeder Workstation wird, beim Empfangen einer neuen Gruppendefinition, der lokale Agent sie zu seiner Liste von aktiven Gruppenzustän den hinzufügen und wird periodisch die Workstation prüfen, um zu sehen, ob irgendwelche Änderungen stattgefunden haben, die die Mitgliedschaft-Bedingungen beeinflussen. Die Rate, unter der diese Prüfung (das Abrufen) stattfindet, wird durch das Script vorgegeben, da einige Zustände bzw. Bedingungen dynamischer als andere sind. Immer wenn eine Änderung erfasst wird, die die Mitgliedschaft von einer oder mehreren definierten Gruppe(n) beeinflusst, bewirkt der Agent, dass eine Trap-Nachricht zu der Verwaltungsstation geschickt wird, um dieses Ereignis zu signalisieren. Die Verwaltungs-Datenbank enthält eine Datenaufzeichnung für jede der Vorrichtungen, die auf dem Netzwerk vorgefunden werden. Das Trap wird dazu verwendet, die Datenbank-Eingänge bzw. -Eintritte für jede Gruppe zu aktualisieren und kann auch einen Alarmzustand für den Administrator erzeugen.
Die US-B1-6,220,768 bezieht sich auf ein Bestand-Feststellungs-System zum Zusammenstellen von Ausrüstungs- und Konfigurationsinformationen in einem Netzwerk. Typischerweise umfasst das Netzwerk 3 Level einer Hierarchie, das Netzwerk selbst, eine Vielzahl von Unternetzen und Nodes für jedes Unternetz. Die Eingabe zu dem Bestand-Feststellungs-System umfasst eine Liste von Unternetzen des Netzwerks, die mit der Netzwerkmaske für jedes Unternetz überblickt werden soll. Weiterhin kann eine Eingabe Netzwerk-Benutzer-IDs, Passworte und SNMP (Simple Network Management Protocol) Community-Namen für das Netzwerk umfassen. Das Bestand-Feststellungs-System führt Netzwerk-Überblick-Aufgaben durch. Ein typischer Schritt in einem Überblick-Verfahren ist derjenige, einen Dienst aufzurufen, um eine Nachricht, gerichtet zu einer bestimmten Adresse, über das Netzwerk zu senden. Der Dienst empfängt eine Antwort auf die Meldung, umfassend Node-Ausrüstungs- oder -Konfigurationsinformationen. Das Bestand-Feststellungs-System extrahiert diese Informationen von der Antwort und die Nachrichtenänderung wird für jede IP-Adresse in dem Bereich oder in Bereichen, die überblickt werden sollen, wiederholt. Die extrahierten Informationen werden in einer Bestand-Datenbank gespeichert. Die Bestand-Datenbank charakterisiert eine momentane Konfiguration von Beständen an dem Node, die die Antworten erzeugen. Weiterhin wird ein Verfahren für eine Fern-Software-Installation geschaffen. Ein erster Node in einem Netzwerk installiert ein Softwarepaket an einen zweiten Node in dem Netzwerk. Die Installation wird durch erneutes Aufsuchen von identifizierenden Informationen und unter Verwendung dieser Informationen durchgeführt, um das geeignete Softwarepaket auszuwählen, um es zu installieren. Wenn einmal ein Softwarepaket für eine Installation ausgewählt worden ist, wird eine Kopie des Softwarepakets zu dem zweiten Netzwerk-Node übertragen. Dies umfasst auch den Vorgang einer Installierung des Softwarepakets an dem zweiten Node. Das Softwarepaket, das ausgewählt ist, wird gewöhnlich eine Konfigurationsdatei umfassen. Diese Konfigurationsdatei wird Informationen umfassen, benötigt dazu, geeignet das Softwarepaket zu installieren.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist die Aufgabe der vorliegenden Erfindung, die Verarbeitungs- und/oder Speicherbelastung an den Node-Computern, benötigt dazu, zu prüfen, welche Node-Computer zu welcher Gruppe gehören, zu verringern. Dies wird durch die Erfindung, wie sie in den unabhängigen Ansprüchen definiert ist, gelöst. Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
Kurz gesagt schafft die vorliegende Erfindung ein Mehrfach-Vorrichtungs-Verwaltungsverfahren und ein -system, die, unter anderen Dingen, einen Mechanismus bereitstellen, um einen einzelnen Befehl auf einem Controller-Computer auszuführen, um eine Aktion (einen Vorgang bzw. eine Operation) an einem oder mehreren anderen, gesteuerten Computern, bezeichnet als Nodes, zu initiieren. Ein Vorgang kann eine Ausführung eines schriftlich ausgearbeiteten Satzes von Befehlen, eine Ausführung eines binären Programms, oder eine Anzahl von anderen Typen von Vorgängen aufweisen. Der Mechanismus arbeitet mit Sätzen von Computern, als seien sie ein einzelner Computer, wodurch, zum Beispiel, eine Verwaltung von Rechenvorrichtungen stark vereinfacht wird und die Kosten einer Verwaltung von Rechenvorrichtungen in einem Daten-Center wesentlich verringert werden.
In einer Ausführung schafft die vorliegende Erfindung eine Architektur, die einen Controller (z.B. ein Verfahren, oder dergleichen) auf einem Computer schafft, der mehrere andere Computer verwaltet, wobei jeder davon eine Agenten-Software enthält, die ihm ermöglicht, durch die Steuereinheit verwaltet zu werden. Allgemein schafft die Steuereinheit eine zentrale Darstellung von mehreren Nodes, die dadurch verwaltet werden, von denen Aktionen gegenüber den Nodes, die individuell ausgewählt werden können, oder durch Sätze, zu denen die Nodes zugeordnet sind, initiiert werden können. Der Controller kommuniziert mit den Nodes unter Verwendung eines Nachrichtenformats, wie beispielsweise ein solches, das von XML (eXtensible Markup Language) abgeleitet ist, unter Ver wendung einer ersetzbaren, unterlegenden Transportschicht für eine Netzwerkkommunikation.
Der Controller schafft eine definierte Art und Weise, um die verfügbaren Nodes in dem Daten-Center, deren Organisation in Sätzen und die Ergebnisse von weiterlaufenden und abgeschlossenen Operationen darzustellen. Zum Beispiel wird ein Schema verwendet, um die Darstellung der verfügbaren Nodes, und Sätzen von Nodes, bestehen zu lassen (z.B. wie sie zusammen durch einen Administrator gruppiert sind, typischerweise entsprechend bestimmter Kriterien, wie beispielsweise einer administrativen Übereinkunft, operationsmäßigen Zwecken oder anderen Kriterien). Das Schema kann auch dazu verwendet werden, eine Aufzeichnung der Ergebnisse jeder Aktion auf einer Speichervorrichtung, auf die durch die Steuereinheit zugreifbar ist, zusammen mit anhängigen und durchgeführten Operationen, und Aufgaben, zu speichern.
Andere Vorteile werden aus der nachfolgenden, detaillierten Beschreibung ersichtlich werden, wenn sie in Verbindung mit den Zeichnungen gesehen wird, in denen:
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Blockdiagramm, das ein Computersystem darstellt, in dem die vorliegende Erfindung eingesetzt werden kann;
2 zeigt ein Blockdiagramm, das einen Controller-Computer, verbunden mit einem Netzwerk, zum Verwalten einer Vielzahl von Nodes, gemäß einem Aspekt der vorliegenden Erfindung, darstellt;
3 zeigt ein Blockdiagramm, das verschiedene, beispielhafte Komponenten in dem Controller-Computer und in einem der Nodes, verwaltet dadurch, gemäß einem anderen Aspekt der vorliegenden Erfindung, darstellt;
4A–4I stellen ein geeignetes, definiertes Schema für die Beibehaltung der Darstellung von verfügbaren Nodes, Sätzen, Operationen und/oder Aufgaben, usw., gemäß einem Aspekt der vorliegenden Erfindung, dar;
5 zeigt ein Flussdiagramm, das eine allgemeine Logik zum Durchführen eines Vorgangs an einem oder mehreren ausgewählten Nodes gemäß einem Aspekt der vorliegenden Erfindung beschreibt;
6 zeigt ein Flussdiagramm, das eine allgemeine Logik zum Durchführen angeforderter Aktionen an einem Node gemäß einem Aspekt der vorliegenden Erfindung beschreibt; und
7 zeigt ein Flussdiagramm, das allgemein Ergebnisse eines Vorgangs, der erhalten wird, und einer Benutzerschnittstelle, eines Scripts oder eines Vorgangs, der eine Operation an dem Controller, die Ergebnisse einer Operation bestimmend, gemäß einem Aspekt der vorliegenden Erfindung, darstellt.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Beispielhafte Betriebsumgebung
1 stellt ein Beispiel einer geeigneten Rechensystemumgebung 100 dar, in der die Erfindung ausgeführt werden kann. Die Rechensystemumgebung 100 ist nur ein Beispiel einer geeigneten Rechenumgebung und ist nicht dazu vorgesehen, irgendeine Einschränkung des Umfangs der Benutzung oder der Funktionalität der Erfindung zu vermitteln. Die Rechenumgebung 100 sollte weder dahingehend interpretiert werden, dass sie irgndeine Abhängigkeit oder ein Erfordernis besitzt, die bzw. das sich auf irgendeine Kombination von Komponenten, dargestellt in der beispielhaften Betriebsumgebung 100, bezieht.
Die Erfindung ist in Verbindung mit zahlreichen anderen Umgebungen oder Konfigurationen von Computersystemen für allgemeine Zwecke oder spezielle Zwecke betreibbar. Beispiele von ausreichend bekannten Rechensystemen, Umgebungen und/oder Konfigurationen, die für die Verwendung der Erfindung geeignet sein können, umfassen, sind allerdings nicht darauf beschränkt: Personal-Computer, Server-Computer, in der Hand haltbare oder Laptop-Vorrichtungen, Tableau-Vorrichtungen, Multiprozessor-Systeme, auf einem Mikroprozessor basierende Systeme, Set-Top-Boxen, programmierbare Verbraucher-Elektroniken, Netzwerk-PCs, Minicomputer, Mainframe-Computer, Router, verteilte Rechenumgebungen, die irgendwelche der vorstehenden Systeme oder Vorrichtungen umfassen können, und dergleichen.
Die Erfindung kann in dem allgemeinen Zusammenhang von mittels Computer ausführbaren Instruktionen, wie beispielsweise Programm-Modulen, die durch einen Computer ausgeführt werden, beschrieben werden. Allgemein umfassen Programm-Module Routines, Programme, Objekte, Komponenten, Datenstrukturen, usw., die bestimmte Aufgaben durchführen oder bestimmte, abstrakte Daten-Typen umsetzen können. Die Erfindung ist allgemein dazu vorgesehen, in verteilten Rechenumgebungen praktiziert zu werden, wo Aufgaben durch Fernverarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetzwerk verknüpft sind. In einer verteilten Rechenumgebung können Programm-Module in lokalen und/oder entfernten Computer-Speichermedien, umfassend Speichervorrichtungen, angeordnet sein.
Wie 1 zeigt, umfasst ein beispielhaftes System zum Ausführen der Erfindung eine Computervorrichtung für allgemeine Zwecke in der Form eines Computers 110, der als ein Controller-Computer 210 der 2 zum Steuern von Nodes arbeiten kann. Komponenten des Computers 110 können eine Verarbeitungseinheit 120, einen Systemspeicher 130 und einen Systembus 121, der verschiedene Systemkomponenten, umfassend den Systemspeicher, mit der Verarbeitungseinheit 120 verbindet, umfassen, sind allerdings nicht darauf beschränkt. Der Systembus 121 kann irgendeiner von verschiedenen Typen von Busstrukturen sein, umfassend einen Speicherbus oder einen Speicher-Controller, einen peripheren Bus und einen lokalen Bus, unter Verwendung irgendeiner Vielzahl von Bus-Architekturen. Anhand eines Beispiels, allerdings nicht als Einschränkung, umfassen solche Architekturen einen Industry Standard Architecture (ISA) Bus, einen Micro Channel Architecture (MCA) Bus, einen Enhanced ISA (EISA) Bus, einen lokalen Video-Electronics Standards Association (VESA) Bus und einen Peripheral Component Interconnect (PCI) Bus, auch bekannt als Mezzanine Bus.
Der Computer 110 umfasst typischerweise eine Vielzahl von mittels Computer lesbaren Medien. Mittels Computer lesbare Medien können irgendwelche verfügbaren Medien sein, auf die durch den Computer 110 zugegriffen werden kann, und umfassen sowohl flüchtige als auch nicht flüchtige Medien, und entfernbare und nicht entfernbare Medien. Anhand eines Beispiels, und nicht als Einschränkung, können mittels Computer lesbare Medien Computer-Speichermedien und Kommunikationsmedien umfassen. Computer-Speichermedien umfassen sowohl flüchtige als auch nicht flüchtige, entfernbare als auch nicht entfernbare Medien, umgesetzt in irgendeinem Verfahren oder einer Technologie zum Speichern von Informationen, wie beispielsweise mittels Computer lesbare Instruktionen, Datenstrukturen, Programm-Module, oder andere Daten. Computer-Speichermedien umfassen, sind allerdings nicht darauf beschränkt, einen RAM, einen ROM, einen EEPROM, einen Flash-Memory oder eine andere Speichertechnologie, einen CD-ROM, digital-versatile Disks (DVD) oder einen anderen, optischen Plattenspeicher, magnetische Kassetten, ein Magnetband, einen Magnetplattenspeicher oder andere, magnetische Speichervorrichtungen, oder irgendein anderes Medium, das dazu verwendet werden kann, die erwünschten Informationen zu speichern, und auf die durch den Computer 110 zugegriffen werden kann. Kommunikationsmedien stellen typischerweise mittels Computer lesbare Instruktionen, Datenstrukturen, Programm-Module oder andere Daten in einem modulierten Datensignal, wie beispielsweise eine Trägerwelle, oder einen anderen Transportmechanismus, dar und umfassen irgendwelche Informationen liefernde Medien. Der Ausdruck „moduliertes Datensignal" bedeutet ein Signal, das eine oder mehrere seiner Charakteristika in einer solchen Art und Weise eingestellt oder geändert besitzt, um Informationen in das Signal zu codieren. Anhand eines Beispiels, und nicht als Einschränkung, umfasst ein Kommunikationsmedium verdrahtete Medien, wie beispielsweise einen verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung, und drahtlose Medien, wie beispielsweise akustische, HF-, infrarote und andere, drahtlose Medien. Kombinationen irgendwelcher davon sollten innerhalb des Umfangs von mittels Computer lesbaren Medien umfasst sein.
Der Systemspeicher 130 umfasst Computer-Speichermedien in der Form eines flüchtigen und/oder eines nicht flüchtigen Speichers, wie beispielsweise ein Read Only Memory (ROM) 131 und einen Random Access Memory (RAM) 132. Ein Basis-Eingabe/Ausgabe-System 133 (BIOS), enthaltend die Grund-Routines, die dabei helfen, Informationen zwischen Elementen innerhalb des Computers 110, wie beispielsweise während eines Hochfahrens, zu übertragen, sind typischerweise in dem ROM 131 gespeichert. Der RAM 132 enthält typischerweise Daten und/oder Programm-Module, auf die unmittelbar zugegriffen werden kann, und/oder momentan durch die Verarbeitungseinheit 120 betrieben werden. Anhand eines Beispiels, und nicht als Einschränkung, stellt 1 ein Betriebssystem 134, Anwendungsprogramme 135, andere Programm-Module 136 und Programmdaten 137 dar.
Der Computer 110 kann auch andere entfernbare/nicht entfernbare, flüchtige/nicht flüchtige Computer-Speichermedien umfassen. Anhand nur eines Beispiels stellt 1 ein Festplattenlaufwerk 141, das von nicht entfernbaren, nicht flüchtigen, magnetischen Medien liest, oder darauf schreibt, ein Magnetplattenlaufwerk 151, das von einer entnehmbaren, nicht flüchtigen Magnetplatte 152 liest oder darauf schreibt, und ein optisches Plattenlaufwerk 155, das von einer entnehmbaren, nicht flüchtigen, optischen Platte 156, wie beispielsweise einem CD-ROM oder anderen, optischen Medien, liest oder darauf schreibt, dar. Andere, entfernbare/nicht entfernbare, flüchtige/nicht flüchtige Computer-Speichermedien, die in der beispielhaften Betriebsumgebung verwendet werden können, umfassen, sind allerdings nicht darauf beschränkt, Magnetbandkassetten, Flash-Memory-Cards, digitale, versatile Disks, ein digitales Videoband, einen Solid-State-RAM, einen Solid-State-ROM, und dergleichen. Das Festplattenlaufwerk 141 ist typischerweise mit dem Systembus 121 über eine nicht entfernbare Speicherschnittstelle, wie beispielsweise eine Schnittstelle 140, verbunden, und das Magnetplattenlaufwerk 151 und das optische Plattenlaufwerk 155 sind typischerweise mit dem Systembus 121 durch eine entfernbare Speicherschnittstelle, wie beispielsweise die Schnittstelle 150, verbunden.
Die Laufwerke und deren zugeordnete Computer-Speichermedien, diskutiert vorstehend und dargestellt in 1, bilden einen Speicher für mittels Computer lesbare Instruktionen, Datenstrukturen, Programm-Module und andere Daten für den Computer 110. In 1 ist zum Beispiel das Festplattenlaufwerk 141 als Speicherbetriebssystem 144, Anwendungsprogramme 155, andere Programm-Module 146 und Programmdaten 147 dargestellt. Es ist anzumerken, dass diese Komponenten entweder dieselben sein können oder gegenüber dem Betriebssystem 134, den Anwendungsprogrammen 135, anderen Programm-Modulen 136 und Programmdaten 137 unterschiedlich sein können. Dem Betriebssystem 144, den Anwendungsprogrammen 145, anderen Programm-Modulen 146 und den Programmdaten 147 sind unterschiedliche Zahlen hier gegeben, um zu zeigen, dass, minimal, sie unterschiedliche Kopien sind. Ein Benutzer kann Befehle und Informationen in den Computer 20 über Eingabevorrichtungen, wie beispielsweise ein Tableau, oder einen elektronischen Digitalisierer, 164, ein Mikrofon 163, ein Tastenfeld 162 und eine Hinweisvorrichtung 161, üblicherweise bezeichnet als eine Mouse, einen Trackball oder einen Touchpad, eingeben. Andere Eingabevorrichtungen, die nicht in 1 dargestellt sind, können einen Joystick, ein Game-Pad, eine Satellitenschüssel, einen Scanner, oder dergleichen, umfassen. Diese und andere Eingabevorrichtungen sind oftmals mit der Verarbeitungseinheit 120 über eine Benutzereingabeschnittstelle 160 verbunden, die mit dem Systembus verbunden ist, die allerdings durch eine andere Schnittstelle und Bus-Strukturen, wie beispielsweise einen Parallel-Port, einem Game-Port oder einen Universal-Serial-Bus (USB), verbunden sein können. Ein Monitor 191 oder ein anderer Typ einer Anzeigevorrichtung ist auch mit dem Systembus 121 über eine Schnittstelle, wie beispielsweise eine Videoschnittstelle 190, verbunden. Der Monitor 191 kann auch mit einem Touch-Screen-Panel, oder dergleichen, integriert sein. Es ist anzumerken, dass der Monitor und/oder das Touch-Screen-Panel physikalisch mit einem Gehäuse verbunden sein kann, in dem die Rechenvorrichtung 110 eingesetzt ist, wie beispielsweise in dem Personal-Computer vom Tableau-Typ. Zusätzlich können Computer, wie beispielsweise die Rechenvorrichtung 110, auch andere, periphere Ausgabevorrichtungen, wie beispielsweise Lautsprecher 195 und einen Drucker 196, die über eine periphere Ausgabeschnittstelle 194, oder dergleichen, verbunden sein können, umfassen.
Der Computer 110 arbeitet allgemein in einer vernetzten Umgebung, um eine Anzahl von Fern-Server-Computern 180, alternativ als ein Node 204, oder Node 204₁ –204_n (2 und 3) bezeichnet, zu steuern. Typischerweise weisen solche Nodes einige oder alle der Komponenten des Computers 110, wie dies zuvor beschrieben ist, auf. Nodes können Benutzer-Schnittstellen-Mechanismen, wie beispielsweise ein Tastenfeld, eine Mouse, eine Anzeige, usw., umfassen. Solche Nodes können eine Vielzahl von Programmen laufen lassen, die typischerweise Dienste für andere Computer innerhalb der vernetzten Umgebung oder für Benutzer bereitstellen. Beispiele von solchen Programmen umfassen Programme, um Web-Seiten oder Seiten zu bedienen oder Datenbanken zu verwalten. Anhand eines Beispiels, und nicht als Einschränkung, stellt 1 Fern-Anwendungs-Programme 185 so dar, dass sie auf einer Speichervorrichtung 181 vorhanden sind. Es wird ersichtlich werden, dass die Netzwerkverbindungen, die dargestellt sind, beispielhaft sind, und andere Mittel zum Einrichten einer Kommunikationsverbindung zwischen den Computern können verwendet werden.
MEHRFACH-VORRICHTUNGS-VERWALTUNG
2 zeigt ein Blockdiagramm, das allgemein eine Architektur 200, umfassend einen Controller-Computer 202 (der entsprechend zu dem Computersystem 110 der 1 sein kann) und eine Vielzahl von verwalteten Rechenvorrichtungen, bezeichnet als Nodes 204₁ –204_n (die den Ferncomputern 180 der 1 entsprechen können), umfasst. Es ist allerdings anzumerken, dass, während Aspekte der vorliegenden Erfindung zur Verwendung in Daten-Centern geeignet sind, solche Aspekte in irgendeiner Umgebung anwendbar sind, wo eine oder mehrere Aufgaben auf einem oder mehreren Computern durchgeführt werden müssen. Zum Beispiel kann ein Benutzer, der mehrere Computer und Dienste (wie beispielsweise PDAs, mobile Computer, Desktop-Systeme, Home-Media-Center-Systeme, usw.) besitzt, die vorliegende Erfindung dazu verwenden, Operationen über solche mehrere Vorrichtungen hinweg durchzuführen. Demzufolge sollte die vorliegende Erfindung, obwohl sie allgemein in einer Daten-Center-Umgebung beschrieben ist, nicht auf irgendeine bestimmte Konfiguration oder auf Konfigurationen beschränkt sein, sondern sieht vielmehr die Verwendung mit praktisch irgendeiner Konfiguration einer Rechenvorrichtung vor, wie beispielsweise solche, die vorstehend angegeben sind, ebenso wie in Verbindung mit Personal-Computern, Servern, Routern, und verschiedenen Speichervorrichtungen.
Ein typischer Daten-Center weist viele unterschiedliche Computer auf. Um den Daten-Center einfacher zu verwalten, benennt ein Administrator, oder dergleichen, einen der Computer als den Controller-Computer 202 (oder Controller 202). Unter anderem behält, entsprechend einem Aspekt der vorliegenden Erfindung, der Controller-Computer 202 eine Master-Aufzeichnung von Computern in dem Daten-Center aufrecht dahingehend, wie sie angeordnet sind, und welche Operationen darauf durchgeführt werden können. Der Controller kann diese Daten in einem lokal verbundenen Datenspeicher (z.B. so, wie er allgemein in 3 dargestellt ist), oder auf einem entfernten Datenspeicher, speichern. Die Nodes 204₁ –204_n weisen Computer in dem Daten-Center auf, die dazu geeignet sind, durch den Controller 202 verwaltet zu werden. Nodes umfassen Node-Programme 206₁ –206_n , oder dergleichen, die die tatsächliche Arbeit des Daten-Centers durchführen, wie beispielsweise Bedienen von Web-Seiten oder Verwalten von Datenbanken.
Gemäß einem Aspekt der vorliegenden Erfindung wendet, um mit hunderten oder tausenden von Computern in einem Daten-Center zusammenzuarbeiten, der Administrator eine logische Organisation in Bezug auf die Computer an, das bedeutet, der Administrator gruppiert die verschiedenen Nodes 204₁ –204_n in Sätze, die die Nodes als logische Strukturen darstellen, anstelle einer Flat-Liste aller Nodes in dem Daten-Center. Sie können mehrere solcher Strukturen (Sätze) von Computern für einen einzelnen Daten-Center sein, z.B. für einen einzelnen Daten-Center, gruppiert durch einen Kunden oder durch eine Funktion, und ein Node kann zu mehr als einem Satz gehören. Die Satzinformationen werden durch einen Controller-Service 208, oder dergleichen, in einem Datenspeicher 302 (3) gespeichert, durch den Controller dadurch beibehalten, dass die Computer in benannte Sätze, z.B. in Unicode-Zeichen, platziert werden. Über Sätze kann der Administrator mit logisch organisierten Gruppen von Computern, als wären sie ein einzelner Computer, zusammenarbeiten. Es ist anzumerken, dass es auch möglich ist, Controller zusammen zu gruppieren, falls mehrere Controller in einem Daten-Center vorhanden sind.
Um Sätze einzurichten und beizubehalten, ermöglicht ein Administrationsprogramm 210, oder dergleichen, dass eine oder mehrere Anwendung(en), Prozesse, Threads, Objekte und/oder andere Software-Komponenten aufweist, einem Administrator, mit dem Controller-Service 208 zusammenwirken, wie beispielsweise über eine oder mehrere Benutzerschnittstelle(n). Das Administrationsprogramm 210 ermöglicht einem Administrator, einen Satz zu erzeugen, einen Node zu einem Satz hinzuzufügen, einen Node von einem Satz zu entfernen, einen Satz zu löschen, die momentanen Nodes in einem Satz aufzulisten und die Sätze, zu denen ein Node gehört, aufzulisten.
Zum Beispiel kann eine Daten-Center-Administration verschiedene, konzeptmäßige Strukturen auf die Anordnung der Node-Computer anwenden, wie beispielsweise eine solche, die dem physikalischen Layout entspricht, in dem Node-Computer durch deren physikalische Position in dem Daten-Center identifiziert werden (z.B. Gehäuse, Rack und Schlitz-Stelle). Diese Ansicht des Daten-Centers ermöglicht der Administration, die physikalische Stelle eines Nodes zu finden, falls, zum Beispiel, er ersetzt werden muss. Alternativ ermöglicht ein physikalischer Layout-Satz der Administration, die Installationsstelle eines neu erworbenen Computers (Nodes) zu spezifizieren.
Dabei sind andere Arten und Weisen zum Organisieren von Nodes in einem Daten-Center vorhanden, umfassend eine logische Struktur, die die Nodes durch den Kunden, der jeden Node verwendet, organisiert. Dies ermöglicht dem Administrator, zwischen einem Kunden und dem Node oder Nodes, die momentan durch diesen Kunden in Benutzung sind, aufzulisten, wie beispielsweise die Benutzung eines bestimmten Kundens nachzuvollziehen und zu überwachen, oder eine Änderung in Bezug auf alle Nodes dieses Kundens anzuwenden. Eine andere, logische Art und Weise eines Betrachtens des Daten-Centers ist diejenige, die Nodes durch eine Funktion zu organisieren, wobei die Funktion die Anwendung, die auf den Nodes läuft, ist. Zum Beispiel können bestimmte Nodes zusammen gruppiert werden, da sie Web-Server, Medien-Server oder Datenbanken sind. Ein Betrachten des Daten-Centers durch eine Funktion ermöglicht der Administration, bestimmte Aktionen (wie zum Beispiel Anwenden eines Musters (Patch) für eine bestimmte Anwendung) nur auf die Nodes, die dies erfordern, durchzuführen. Es ist anzumerken, dass dies nur Beispiele sind, da verschiedene andere Arten und Weisen vorhanden sind, die eine Administration eines Daten-Centers wünscht, um die Nodes in dem Daten-Center zu organisieren, z.B. durch eine Netzwerk-Topologie (Node, angehängt an bestimmte Schalter oder Load-Balancer) durch VLANs, durch einen Customer-Service-Level, durch Maschinenfähigkeiten, und/oder durch installiertes OS und Service-Patch-Level. Es ist anzumerken, dass irgendein gegebener Node in irgendeiner Anzahl von Sätzen gruppiert werden kann, wie dies in der beispielhaften Tabelle nachfolgend angegeben ist:
Unter Beibehalten dieses Aspekts der vorliegenden Erfindung vereinfacht die Fähigkeit, Nodes in Sätze zu gruppieren (z.B. unterschieden durch einfache Namen), die Funktionsweise der verschiedenen Operationen. Zum Beispiel kann ein Satz Node-Computer bei der Verwendung durch einen Kunden identifizieren, wenn dieser Kunde einen Vorgang berichtet, so dass der Status dieser Node-Computer schnell erhalten werden kann und der Vorgang aufgelöst werden kann. Ein Überwachen von Informationen, zusammengestellt für die Nodes, kann für einen bestimmten Kunden zusammengestellt werden, wie beispielsweise in eine Form, die über eine Web-Seite zu betrachten ist, so dass der Kunde den Status der Maschinen sehen kann. Nodes können hinsichtlich einer Ressource-Erschöpfung überwacht werden (z.B. Herauslaufen aus einem Disk-Raum), um für den Kunden eine Warnung zu erzeugen, diese Maschine zu verwenden. Die Warnung kann zu dem Kunden berichtet werden (zum Beispiel durch e-mail) und/oder durch die Verkaufsmannschaft verwendet werden, um den Kunden zu kontaktieren und ihm zu empfehlen, seine Konfiguration aufzurüsten, z.B. durch eine bessere Hardware oder einen zusätzlichen Server.
Gemäß einem anderen Aspekt der vorliegenden Erfindung werden, um den Daten-Center zu verwalten, Operationen gegenüber einem oder mehreren Nodes in dem Daten-Center dadurch durchgeführt, dass ein Vorgang auf dem Controller-Service 208 initiiert wird, wie beispielsweise ein initiierender Vorgang 304. Es ist anzumerken, dass in 3 der initiierende Vorgang 304 als Teil des Administrationsprogramms 210 dargestellt ist, allerdings kann dies getrennt von einem anderen sein, und, tatsächlich, kann der initiie rende Prozess ein Script oder ein anderer, ausführbarer Code sein. Weiterhin ist anzumerken, dass, zur Vereinfachung, 3 nur einen Node 204 darstellt, allerdings kann, wie verständlich wird, der Controller 202 mehrere Nodes steuern, z.B. auf einmal oder in einer bestimmten Reihenfolge.
Wie allgemein in 3 dargestellt ist, wird, an dem Controller-Computer 202, auf ein Controller-Programm 306 des Controller-Service 204 zugegriffen und über eine Schema-Schnittstelle 310 laufengelassen. Dieses Schema (allgemein dargestellt über die 4A–4I) liefert Darstellungen der verfügbaren Nodes in dem Daten-Center, die Sätze, die verfügbaren Operationen und die Ergebnisse eines Laufenlassens jeder Operation. Allgemein kann, auf dem Controller-Computer 202, der Controller-Service 208 so angesehen werden, dass er die Schema-Schnittstelle 310, das Steuerprogramm 306 und den Datenspeicher 302 aufweist. Irgendein Prozess, ein Script oder eine andere Benutzerschnittstelle, die wünscht, auf den Controller-Service 208 zuzugreifen, nimmt dies über die Schema-Schnittstelle 310 vor. Das Controller-Programm 306 bestimmt die Aktionen, die vorgenommen werden sollen, die ein Zugreifen auf den Datenspeicher 302 umfassen könnten, und/oder eine Kommunikation mit einem oder mehreren Nodes (wie beispielsweise dem Node 204) über die Transportschicht 212. Zum Beispiel werden die Ergebnisdaten und andere Informationen, die benötigt werden, um den Administrator mit den Darstellungen bereitzustellen, allgemein in dem Datenspeicher 302 aufrechterhalten, wobei ein Administrator über die Schema-Schnittstelle 310 zugreifen kann. In einer typischen Ausführung könnte die Schema-Schnittstelle von dem Common Information Model (CIM) Standard zum Repräsentieren eines Rechenvorgangs und Vorrichtungen abgeleitet werden, wie dies in der United States Patentanmeldung Serial No. 09/020,146, übertragen auf den Inhaber der vorliegenden Erfindung, beschrieben ist.
Allgemein werden, um eine Operation durchzuführen, ein oder mehrere Nodes, oder Sätze von Nodes, an denen die Operation durchgeführt werden soll, zuerst ausgewählt, wie beispielsweise über das Administrationsprogramm 210. Eine Auswahl kann einen einzelnen Computer, alle der Computer in einem Satz, alle Computer in mehreren Sätzen, oder eine Mischung von individuellen Computern und Computern in Sätzen, spezifizieren. Die Auswahl kann irgendwelche Duplikate, entfernt davon, haben, z.B. falls derselbe Node über zwei oder mehr ausgewählte Sätze spezifiziert ist. Es ist anzumerken, dass Auswahlen gegenüber Sätzen dahingehend unterschiedlich sind, dass ein Satz einer durch einen Administrator ausgewählten Darstellung einer Organisation des Daten-Centers ist, wogegen eine Auswahl allgemein eine Zusammenstellung von Computern, temporär spezifiziert zum Durchführen mindestens einer Operation darauf, ist. Mit anderen Worten sind, während sich Satzmitglieder (und Sätze selbst) über die Zeit ändern können, sie eine dauerhafte Darstellung der Organisation der Computer-Nodes, wogegen Auswahlen übergangsmäßige Sätze von Computer-Nodes sind, die das vorgesehene Ziel von spezifischen Operationen darstellen. Eine Auswahl wird dann erzeugt, wenn ein Bedarf vorhanden ist, eine Operation oder eine Reihe von Operationen gegenüber einer gegebenen, zusammengestellten Anzahl von Computern durchzuführen. Wenn der Vorgang oder eine Reihe von Vorgängen abgeschlossen ist, kann die Darstellung der Auswahl gelöscht werden, ohne Informationen über die Organisation von Computern in dem Daten-Center zu verlieren. Auswahlen können dahingehend angesehen werden, dass sie „temporäre" Sätze sind. In einigen Ausführungen können Auswahlen auf die degenerierten Fälle beschränkt werden, bei denen eine Auswahl nur entweder einen einzelnen Satz oder einzelne Nodes enthaften kann.
Die spezifischen Operationen, die der Administrator durchführen kann (z.B. über das Administrationsprogramm 210), umfassen ein Erzeugen einer Auswahl, ein Löschen einer Auswahl und ein Auflisten der Computer in einer Auswahl. In einer Ausführung werden die Auswahlen auf der Steuereinheit 202 gespeichert und jede Auswahl wird durch eine eindeutige, serielle Zahl, zugeordnet dann, wenn die Auswahl erzeugt wird, identifiziert. Auswahlen können Operationen in Daten-Centern, die tausende von Computern umfassen, unterstützen, und jede Auswahl kann irgendeine Anzahl von Computern, von einem bis zu der gesamten Anzahl der Elemente in dem Daten-Center, enthalten. Eine Aufzeichnung wird dazu beibehalten, um zu verfolgen, welche Operationen auf welchen Vorrichtungen laufen, um dadurch ein Audit zu erhalten, über das, was abläuft. Dieses Audit wird normalerweise auf einer regelmäßigen Basis erhalten und gelöscht.
Es ist anzumerken, dass in einer Umgebung eines Daten-Centers der Controller 202 der Steuerpunkt von (zumindest einem Teil) des Daten-Centers ist, und die Aufbewahrungsstelle von Informationen über den Daten-Center ist. Als eine Folge muss, in einer solchen Umgebung, der Controller sehr verfügbar und in dem Fall eines Problems wieder generierbar sein. Für eine Verfügbarkeit kann der Controller eine gemeinsam geteilte Disk-Cluster-Umgebung von mehreren, zusammenhängenden Maschinen aufweisen, wobei die zusammenhängenden Computer ohne Beeinflussen der Operation des Controllers 202 ausfallen können. Für die Beseitigung eines Problems kann der Zustand eines Controllers in einem Backup-Verfahren wiederhergestellt werden, umfassend Details von Gruppen, Scripts, einen Script-Code und Ergebnisse von zuvor zusammengestellten, sich in Arbeit befindenden Aufgaben. Ein Backup-Vorgang kann in ein Script dokumentiert und eingekapselt werden, das der Administrator oder ein anderer Dienst bzw. Service verwenden kann, um regelmäßig das Backup durchzuführen. Einem Backup folgend kann der Zustand des Controllers weiter auf einem neuen Controller wiederhergestellt werden, und, zusätzlich, muss der neue Controller in der Lage sein, eine Steuerung der Nodes, die zuvor durch den vorherigen Controller gesteuert wurde, zu übernehmen. Gleichzeitig kann eine Sicherheit so vorgesehen werden, dass ein findiger Controller nicht die Steuerung von Nodes übernehmen kann.
Die Scripts, die auf den Nodes ausgeführt werden können, können auf dem Controller 202 gespeichert sein (z.B. in einer Script-Datenbank in dem Datenspeicher 302, oder irgendwo sonst). Die Scripts können so geschrieben sein, um irgendeinen Script-Host, der an den Ziel-Knoten bzw. -Nodes verfügbar ist, zu verwenden. Die Script-Datenbank weist Informationen über die Scripts, die verfügbar sind, um auf entfernten Nodes ausgeführt zu werden, auf, und die Scripts selbst können auf einem Dateisystem der Steuereinheit gespeichert werden und die Datenbank enthält die Pfade zu den Scripts. In einer Ausführungsform können Scripts irgendwo auf dem Dateisystem des Controllers vorhanden sein. Das Administrationsprogramm 210, oder dergleichen, ermöglicht die Erzeugung oder die Editierung eines Scripts auf dem Dateisystem, eine Erzeugung eines Script-Eintritts in die Script-Datenbank, ein Editieren eines Script-Eintritts, ein Löschen eines Script-Eintritts, ein Erzeugen einer Aufgabe (beschrieben nachfolgend), die ein Script verwenden kann, ein Löschen einer Aufgabe, ein Editieren einer Aufgabe, eine Ausführung einer Aufgabe, ein Wiederaufsuchen des Status und der Ergebnisse einer Aufgabe.
Gemäß einem Aspekt der vorliegenden Erfindung erzeugt, um eine Operation oder eine Reihe von Operationen an einem oder mehreren ausgewählten Nodes durchzuführen, wenn einmal eine Auswahl vorgenommen ist, der Controller-Service 208 eine Nachricht (oder Nachrichten), die eine Aufgabe, die durchgeführt werden soll, enthält. Die Nachricht wird vorzugsweise unter Verwendung von XML formatiert, und wird zu jedem ausgewählten Ziel-Knoten bzw. -Node (z.B. der Node 204 in 3) unter Verwendung eines Nachrichten-Protokolls und eines Transport-Schicht-Protokolls 212 an dem Controller und einem entsprechenden Protokoll 214₁ –214_n an jedem Node oder den Nodes, spezifiziert in der Auswahl, gesendet. Zur Vereinfachung kann das Controller-Programm 306 als direkt mit einem Agent-Service 218, umfassend ein Agent-Programm 312 auf dem Node-Computer 204, unter Verwendung eines definierten XML Nachrichtenprotokolls 314 (3) kommunizierend, angesehen werden, während die Transportschicht 212 auf dem Controller 204 als direkt mit der Transportschicht 214 auf dem Node 204 unter Verwendung eines Transportprotokolls 316 (3) angesehen werden kann. Die Transportschicht 212 kann irgendein System aufweisen, das zuverlässig die Nachricht von der Steuereinheit zu mehreren Nodes 204₁ –204_n senden kann, und das einen Node 204 verwenden kann, um eine Nachricht zu dem Controller 204 zu schicken. Zum Beispiel kann ein Multicast verwendet werden, um eine Nachricht von dem Controller zu mehreren Nodes zu senden. Dort, wo ein Multicast nicht verfügbar ist, oder wenn das Ziel bzw. Target ein einzelner Node ist, kann ein Unicast verwendet werden. Eine alternative Transportschicht würde diejenige sein, das Standard-HTTP-Protokoll zu verwenden, um die Nachricht zu enthalten, und um Unicast zu verwenden.
In einer Ausführung verwendet eine Kommunikation zwischen dem Controller 202 und dem Node 204 ein Multiple Device Management (MDM) Protokoll, um Scripts zu dem Agent-Service 218 zu schicken, Ergebnisse über laufende Scripts zurückzuführen, dem Agent-Service 218 mitzuteilen, einen binär ausführbaren Code laufenzulassen, andere Operationen an dem Node 204 über den Agent-Service 218 durchzuführen, und Warn- und Ereignis-Informationen von dem Agent-Service 218 zu dem Controller 202 zu schicken. In dieser Ausführung arbeitet das MDM-Protokoll on top eines Transport-Schicht-Protokolls, das eine zuverlässige Netzwerkkommunikation zwischen dem Controller und einem oder mehreren Agent(en) bereitstellt, wie beispielsweise durch Verwendung eines senderseitig garantierten Multicast (Sender-Side Guaranteed Multicast – SGM). Es ist anzumerken, dass, während die Erfindung primär durch eine logische Kommunikation über das Nachrichtenprotokoll und/oder das Transportprotokoll beschrieben wird, verständlich wird, dass ein unterlegendes, physikalisches Netzwerk 216 (ob verdrahtet oder drahtlos) die Steuereinheit 204 und die Nodes (Knoten) 204₁ –204_n verbindet.
Anhand eines Beispiels eines üblichen Typs einer Operation kann der Administrator über den Controller-Computer 202 einen Satz von Befehlen (z.B. ein Script) an einem oder mehreren ausgewählten Nodes ausführen. Dies wird allgemein durch Auswählen der Nodes und Senden von Nachrichten zu den ausgewählten Nodes durchgeführt. Zusätzlich zu Scripts ist das Nachrichtenprotokoll 314 so erweiterbar, um alternative Typen von Operationen zu ermöglichen, wie beispielsweise die Ausführung von zuvor zusammengestellten Programmen, oder bestimmten anderen Operationen.
Gemäß anderen Aspekten der vorliegenden Erfindung umfasst der Node 204 den Agent-Service 218, das Agent-Programm 212 aufweisend. Allgemein ist der Agent-Service 218 zum Durchführen von Aktionen unter der Anforderung des Controllers 202 und zum Versenden von Warnungen und Ereignissen zu dem Controller 202 verantwortlich. Hierbei empfängt das Agent-Programm 312 Kommunikationen (Nachrichten) von dem Controller 202, bestimmt, wie eine erforderliche Aktion oder Aktionen, spezifiziert in der Nachricht (falls eine vorhanden ist), durchzuführen ist bzw. sind, und führt, so, wie dies benötigt wird, die Aktion weiter zusammen mit irgendwelchen Argumenten (Parametern) zu einer geeigneten Ausführungsmaschine 320. Anhand eines Beispiels würde, falls der Controller 202 das Agent-Programm 318 eines Scripts sendet, die Ausführungsmaschine 320 typischerweise ein entsprechender Script-Interpretierer sein. Das Agent-Programm ermöglicht auch bestimmte andere Operationen, die Teil des Protokolls zwischen dem Controller und den Computern sind, wie beispielsweise die Ausführung eines binär ausführbaren Codes auf dem Node 204. Es ist anzumerken, dass, anstelle eines Versendens des binär ausführbaren Codes, der Controller 202 vorzugsweise eine Netzwerkadresse für diesen Code für den Node 204 sendet, um ihn entweder von dieser Stelle aus laufenzulassen, oder ihn herunterzuladen und ihn laufenzulassen. Ein Node-Betriebssystem 220 ist zur Vervollständigung, ebenso wie ein Controller-Betriebssystem 222, dargestellt.
Zusätzlich zu einer Ausführung von Scripts oder Programmen können andere Ope rationen, wie beispielsweise ein Reboot, ein Shutdown oder ein Suspend (bewegen zu einem niedrigeren Leistungszustand), durch einen gesteuerten Knoten bzw. Node angefordert werden. Der Node 204 könnte, da solche Operationen unmittelbar durchgeführt wurden (wie beispielsweise über Scripts), nicht ein Ergebnis zu dem Controller zuführen. Anstelle davon werden solche Operationen durch eine eine spezielle Funktion handhabende Komponente 322, die zuerst ein Ergebnis zu dem Controller 202 kommuniziert, im Wesentlichen angebend, dass die Befehl-Nachricht empfangen und verstanden worden ist, durchgeführt. Nach Versenden des Ergebnisses nimmt der Node die geeignete Aktion, um die Anforderung zufriedenzustellen, vor.
Um zusammenzufassen, gibt das MDM Protokoll den Controller 202 frei, um anzufordern, dass einer oder mehrere Node(s) eine bestimmte Operation ausführen, wie beispielsweise Laufenlassen eines Scripts an dem Agent, unter Verwendung eines Standard-Scripting-Host, oder Laufenlassen eines binären Codes auf dem Agent. Das Protokoll muss kein Verständnis über die Operationen, die durchgeführt werden, haben, um dadurch das Protokoll einfach zu halten, und um irgendwelche Operationen eines speziellen Falls zu vermeiden. Allerdings haben einige Operationen Einflüsse auf die Operation des Protokolls selbst, und werden demzufolge in dem Protokoll ausgedrückt. Solche speziellen Operationen können ein Rebooting, ein Suspending oder ein Herunterfahren des Node-Computers umfassen. Auch ermöglicht das MDM-Protokoll, dass Management- Informationen ausgetauscht werden, wie beispielsweise dann, wenn ein Controller zuerst mit einem Node kommuniziert, um ihn so zu steuern.
Das MDM-Protokoll wird auch dazu verwendet, die Ergebnisse eines Laufenlassens eines Scripts, einer binären oder speziellen Operation, zurück zu dem Controller 202 zu senden. Node-Warnungen und -Ereignisse können über das MDM-Protokoll gesendet werden, ebenso wie Heartbeats (Herzschläge), um den Controller periodisch darüber zu informieren, dass der Node geeignet arbeitet. Die Intervall-Informationen sind konfigurierbar, und der Controller 202 kann die Intervall-Informationen zu den Nodes über das MDM-Protokoll senden.
Unter Empfang des Ergebnisses einer Operation hält der Controller 202 eine Aufzeichnung der Operation aufrecht. Hierbei werden, da die Ergebnisse von den Nodes 204₁ –204_n ankommen, die Ergebnisse von den zurückgeführten Nachrichten extrahiert und in der Datenbank 302 gespeichert. Dies liefert eine fortlaufende und vollständige Aufzeichnung jeder Operation, für jeden Node. Der Administrator oder ein Prozess (wie beispielsweise ein Script) kann diese Informationen an dem Controller 202 abfragen, um den Erfolg der Operation an jedem Node zu bestimmen, und, falls notwendig, Fehler zu untersuchen oder aufzulösen. Das Nachrichtenformat liefert auch eine Art und Weise für den Controller, Informationen über den Zustand jedes Node, aufweisend den Status von irgendwelchen Warnungen an den Nodes, beizubehalten.
Wie ersichtlich werden kann, geben die verschiedenen Agent-Service-Operationen, umfassend das Laufenlassen von Scripts und ein Durchführen von anderen Aktionen, einem Administrator eine wesentliche Flexibilität, um wahlweise Operationen auf dem Server in einem Daten-Center durchzuführen. Zum Beispiel können, mit vielen, typischen Managementoperationen, fertige und getestete Scripts mit dem Controller oder einem Node-Computer bereitgestellt werden, der ein vorkonfigurierter Server sein kann. Solche Scripts geben dem Daten-Center-Administrator die Fähigkeit, die Server in dem Daten-Center für übliche Operationen zu verwalten, und können mit dem Controller 202, bereit zur Verwendung, versehen sein. Zusätzliche Scripts können mit besonderen Anwendungsservern, oder dergleichen, kommen (umfassend neue Typen von Geräten, wie beispielsweise Cache-Geräte). In einem solchen Fall muss der Administrator nur die Scripts auf dem Controller 202 herunterladen und das Controller-Programm 306 konfigurieren, um Kenntnis über diese neuen Scripts zu haben. Weiterhin können die Node-Computer mit relevanten Scripts darauf versendet werden, z.B. basierend auf deren Funktion, und können dann automatisch diese Scripts zu dem Controller 202 zuführen. Für spezielle Situationen können Kunden-Scripts geschrieben, getestet und dann zu dem Controller 202 durch Konfigurieren des Controllers, um Kenntnis über das neue Script zu erlangen, hinzugefügt werden.
Wie vorstehend beschrieben ist, umfasst jeder Node-Computer den Agent-Service 218. Wie bei irgendeinem gegebenen Controller kann die Agent-Installation mit dem Node ankommen, z.B. dem Computer, versandt als ein Gerät, wodurch keine Installation erforderlich ist. Alternativ kann der Agent-Service eine separate Software aufweisen, die installiert werden muss, wie beispielsweise über ein geliefertes Installations-Script, das eine Installation an jedem Computer, der verwaltet werden soll, durchführt.
Um die Belastung zum Betreiben eines Daten-Centers zu verringern, kann, wenn ein Computer, der den Agent-Service 218 enthält, gebootet wird, der Agent-Service 318 automatisch seine Existenz über das Netzwerk über eine Discovery-Komponente 330 versenden, wie beispielsweise über ein Auto-Discovery-Protokoll, wie beispielsweise dasjenige, das durch Universal Plug-n-Play (uPnP, ein Standard für Auto-Discovering-Rechenvorrichtungen auf einem Netzwerk) geliefert wird. An Nodes, die mehrere Netzwerk-Schnittstellen-Karten (NICs) haben, können die NICs, verwendet dazu, zu senden, restriktiert werden, z.B. falls mehr als eine NIC verwendet wird, wird nur die erste eine, die einen antwortenden Controller enthält, für zukünftige Operationen, bis zu dem nächsten Reboot, verwendet werden.
Der Controller 202 erkennt das Senden über einen Discovery-Auflistungs-Prozess 332, und falls dieser Computer nicht bereits in der Darstellung von Computern des Controllers, über die er Kenntnis hat, existiert, wird der sendende Computer hinzugefügt, und der Controller wird auf diesen Computer als einen Node Bezug nehmen. Hierbei bestimmt, wenn der Controller 202 ein Auto-Discovery-Broadcast erkennt, der Computer, ob er bereits Kenntnis über diesen Node besitzt. Falls dies der Fall ist, ist der Node bereits zuvor innerhalb des Daten-Centers gebootet worden, und befindet sich entweder in der Liste von nicht gesteuerten oder gesteuerten Nodes. Falls er ein gesteuerter Node ist, richtet der Controller 202 wieder eine Steuerung des Nodes ein. In jedem Fall markiert er die Node-Aufzeichnung, um zu zeigen, dass der Node auf dem Netzwerk gebootet ist. Falls der Node nicht durch den Controller bekannt ist, wird der Controller 202 antworten und die Informationen über den Node zu seiner internen Datenbank 302 hinzufügen. Die Informationen, erhalten durch den Controller 202, werden den eindeutigen Identifizierer des Nodes (wie beispielsweise einen global eindeutigen Hardware-Identifizierer, wie beispielsweise die BIOS GUID oder MAC Adresse der Netzwerk-Schnittstellen-Karten) aufweisen. Wenn ein Node neu entdeckt ist, wird er zuerst als ein nicht gesteuerter Node angesehen, und der Administrator kann die Bestimmung vornehmen, ob dieser Node zu einem solchen gemacht wird, der durch den Controller 202 gesteuert wird.
Weiterhin dient, um die Steuerung zu vereinfachen, das Auto-Discovery weiterhin zur Verwendung einer automatischen Konfiguration von neuen Maschinen. Zum Beispiel kann ein Administrator spezifizieren, dass ein gegebener Satz von Befehlen gegenüber allen neuen Maschinen durchgeführt werden soll (z.B. um das neue System als Bestand aufzunehmen, oder momentan erforderliche Hotfixes anzuwenden, oder um sie für einen bestimmten Kunden zu konfigurieren). Der Administrator kann dann ein Script schreiben, um ein Ereignis, das dann entsteht, wenn der neue Computer an der Steuereinheit hinzugefügt wird, zu verbrauchen, und eine geeignete Aktion vorzunehmen. Wenn sie einmal entdeckt sind, kann der Administrator alle neuen Nodes in dem Daten-Center auflisten und sie entweder zu Sätzen so, wie dies erforderlich ist, hinzufügen, oder Operationen dagegen durchführen. Wie leicht ersichtlich werden kann, spart eine Verwendung eines Auto-Discovery-Mechanismus zum Auffinden von neuen Computern in dem Daten-Center die Administration dahingehend ein, manuell Informationen (z.B. Namen, serielle und IP-Informationen) für jeden neuen Computer einzugeben, und vermeidet demzufolge potenzielle Dateneingabefehler. Auf diese Art und Weise besitzt der Administrator eine Online-Referenz-Liste von verfügbaren Computer-Nodes, die dabei unterstützt, Bestandsinformationen über die Daten-Center-Inhalte aufrechtzuerhalten.
Um eine Sicherheit zu erreichen, schützt die vorliegende Erfindung gegen eine Controller-Software und eine Agent-Software, die nicht durch die Daten-Center-Administratoren autorisiert sind (jeweils ein „Rogue-Controller" und ein „Rogue-Agent"). Controller und Agents unter Kontrolle der Administratoren des Daten-Centers werden als „Trusted Controllers" („vertrauliche Controller") und „Trusted Agents" („vertrauliche Agenten") jeweils bezeichnet. Hierbei werden die Nodes, die Auto-Discovery-Informationen auf dem Netzwerk senden, wo mehrere Controller existieren können, nur so konfiguriert, um eine Antwort von dem ersten Controller anzunehmen, um zu antworten. Wenn der Node eine Antwort empfängt, unter Verwendung eines öffentlichen Schlüssels, einer Privat-Schlüssel-Technologie, wird der Node danach nur Steuerinformationen von diesem Controller und anderen, vertraulichen Controllern akzeptieren. Normalerweise würde dies nur der Controller sein, der zuerst den Node steuerte, allerdings ist vorgesehen, dass Controller ausfallen werden und ersetzt werden müssen, wobei allerdings solchen Ersatz-Controllern über den Privatschlüssel getraut wird. Es ist anzumerken, dass der erste Controller, um zu antworten, ein Rogue-Controller sein kann, wobei in diesem Fall der Node von einer Steuerung des Daten-Centers verlorengehen würde, allerdings kann dies dadurch vermieden werden, dass geeignete Zertifikat-Daten auf dem Agent, bevor er zum ersten Mal gebootet wird, aufgestellt werden. Falls ein neuer Node für einen Rogue-Controller verlorengeht, kann dies ein Verlust von Ressourcen für den Administrator des Daten-Centers verursachen, allerdings hat der Rogue-Controller keinen Zugang zu irgendwelchen Kundeninformationen an dem Node.
Wenn einmal eine Vertrauensbasis zwischen dem Controller und dem Node eingerichtet ist, wird dieser Node gesteuert und der Rogue-Controller kann nicht eine Steuerung des Nodes übernehmen, obwohl die vertraulichen Steuereinheiten eine Kontrolle des Nodes übernehmen können (zum Beispiel, um den originalen Controller zu ersetzen). Da Rogue-Computer auch das Netzwerk „beschnuppern" können, werden sensitive Informationen nicht über das Netzwerk unverschlüsselt verteilt, und die Verschlüsselung ist so, dass nur Ziel-Nodes einer gesicherten Nachricht diese entschlüsseln können. Wenn eine Operation aufgerufen ist, kann sie spezifizieren, ob die Kommunikation verschlüsselt werden muss. Dies könnte auf die Anforderung des initiierenden Prozesses erfolgen, oder das Script wird als eine erforderliche Verschlüsselung in der Script-Datenbank markiert.
Der Datenspeicher 302, aufrechterhalten durch den Controller 202, ist als ein definiertes Schema angeordnet. Allgemein hält der Controller Details der Nodes in dem Daten-Center, Einstellungsinformationen, verfügbare Operationen, Operationen, die momentan in Arbeit sind, und Ergebnisse von abgeschlossenen Operationen aufrecht. Obwohl es nicht notwendig ist, ist, zur Vereinfachung, dieses Datenbank-Schema ähnlich zu dem Objekt-Modell-Schema angeordnet, über das sich das Administrationsprogramm 304 schnittstellenmäßig (über eine Schema-Schnittstelle 310) mit dem Controller-Programm 306 und dem Datenspeicher 302 verbindet. Es ist anzumerken, dass, in einer Ausführung, das Objekt-Modell-Schema die Informationen in der Form von definierten Objekten darstellt, während, allgemein, das Datenbank-Schema Aufzeichnungen oder dergleichen, aufrechterhält, die dazu verwendet werden, die Objekte, wenn sie abgefragt werden, zu konstruieren. Das Schema ist allgemein in den 4A–4I dargestellt, und ist weiterhin in APPENDIX A beschrieben. Allerdings ist das beschriebene Schema nur ein Beispiel, und die vorliegende Erfindung ist nicht auf irgendeine bestimmte Art und Weise gerichtet, in der die Daten aufrechterhalten oder präsentiert werden.
Der Controller 202 hält demzufolge eine bestimmte Menge an Informationen über jeden Node in der Datenbank aufrecht. Zum Beispiel wird jeder Node durch eine Vorrichtungs-Daten-Struktur, aufweisend sich auf eine Kommunikation beziehende Daten (z.B. TCP-IP Hostname), einen eindeutigen Identifizierer, und andere, verschiedene Daten, aufweisen, dargestellt. Das meiste dieser Informationen ist eine cache-mäßige Darstellung des Zustands des Nodes, wie beispielsweise der Name des Nodes. Die cache-mäßigen Informationen können die Elemente, die in der nachfolgenden Tabelle angegeben sind, umfassen, die auch Details darüber umfassen, wie diese Informationen an dem Controller, falls sie sich an dem Node ändern, aktualisiert werden:
Andere Elemente von Informationen über einen Node, die an dem Controller beibehalten werden, umfassen:
Nodes werden an dem Controller durch verschiedene Informationen, wie beispielsweise den Node-Namen (eine Kurzform des Namens eines Nodes, z.B., „server07") und die MAC Adressen der NIC Karten an dem Node, identifiziert. Der Node-Name kann als der eindeutige Identifizierer für die Node-Aufzeichnung an dem Controller verwendet werden. Beide dieser Teile von Informationen werden von dem Node zu dem Controller unter Verwendung von Auto-Discovery zu jedem Zeitpunkt, zu dem der Node bootet, geschickt. Falls ein Auto-Discovery an dem Netzwerk nicht verfügbar ist, dann muss der Administrator manuell die Node-Aufzeichnung, enthaltend mindestens den Node-Namen, hinzufügen.
Der Node-Name kann auch durch den Controller 202 zum Kommunizieren mit dem Node verwendet werden. In einer Ausführung löst der Controller den Namen zu einer IP-Adresse unter Verwendung von DNS auf, das bedeutet, dass der Administrator sicherstellen muss, dass der Controller einen Zugang zu einem DNS-Server hat, der den Node-Namen zu der (oder einer) IP-Adresse an dem administrativen NIC auflistet. Der DNS-Server kann auf statistischen Daten basierend sein oder dynamische DNS verwenden, um aktuell mit dem Server-Namen und IP-Adressen zu bleiben. Es ist anzumerken, dass, falls das administrative Netzwerk nicht momentan einen DNS-Server besitzt, dann der Controller selbst als ein DNS-Server verwendet werden kann. Ähnliche Prozesse zu einem dynamischen DNS, wie beispielsweise das eine, das IP-Änderungen an dem Node überwacht und die Aktualisierungen zu dem Controller sendet, können verwendet werden. Wenn einmal ein Node gesteuert wird, richtet der Controller eine permanente Verbindung zu dem Node ein.
Auto-Discovery basiert auf dem Netzwerk zwischen dem Node und dem Controller, der das Weiterführen von Multicast-Discovery-Paketen unterstützt, z.B. die Pakete werden durch den Node zu einer vordefinierten (fixierten) Multicast-IP-Adresse und einem Port geschickt. Da nicht jede Daten-Center-Umgebung eine Multicast-Weiterleitung unterstützt (z.B. entweder aufgrund von Router-Beschränkungen oder einer Übereinkunft), kann der Daten-Center in anderen Moden arbeiten, wie beispielsweise die Verwendung eines Controllers pro Multicast-Domäne (typischerweise ein Controller pro Unternetz), oder kann ohne ein Auto-Discovery arbeiten. In diesem Fall werden einige Operationen, die ansonsten automatisch sein würden, manuell durchgeführt.
Wenn ein verwalteter Node einen Reboot-Vorgang vornimmt, verliert der Controller irgendeine permanente Verbindung zu dem Node. In einer derzeitigen Ausführung versucht der Controller 202 nicht, automatisch wieder eine Verbindung einzurichten, sondern wartet vielmehr auf ein Auto-Discovery-Paket von dem Node. Wenn der Controller 202 dieses Paket empfängt, weiß er, dass der Node verfügbar ist, und richtet wieder eine Verbindung mit dem Node ein. In dem Fall, dass ein Auto-Discovery nicht bei der Arbeit verfügbar ist, richtet der Administrator manuell wieder eine Kommunikation zwischen dem Controller und dem einem Reboot unterzogenen Node ein, wie beispielsweise über ein geeignetes Verfahren, z.B. ein Controller.RecoverManagedNode Verfahren. Es ist anzumerken, dass allgemein das Verfahren keinen Wert zurückführt, so dass, falls erwünscht, ein Anrufer ein sprachenspezifisches Verfahren benutzen muss, um zu bestimmen, ob ein Verfahren (oder eine andere Operation) fehlgeschlagen ist, wie dies in APPENDIX A beschrieben ist.
Das Objektmodell, das das Schema aufführt, weist drei Hauptmerkmale auf, nämlich Sätze, Vorrichtungen und Aufgaben. Sätze stellen Gruppen von Vorrichtungen dar. Jeder Satz besitzt einen eindeutigen Namen und kann keine, eine oder mehrere Vorrichtungen enthalten. Eine gegebene Vorrichtung kann in Mehrfachsätzen vorliegen. Sätze werden nur auf dem Controller dargestellt; in einer derzeitigen Ausführung besitzen die Vorrichtungen keine Kenntnis darüber, in welchen Sätzen sie sich befinden, und werden nicht darüber informiert, wenn sie zu Sätzen hinzugefügt oder von diesen entfernt werden. Sätze werden in dem Objekt „Sätze" („Sets") ausgeführt. Es ist anzumerken, dass in einer derzeitigen Ausführung nur Vorrichtungen Mitglieder eines Satzes sein können, allerdings können in anderen Ausführungen Sätze Mitglieder von anderen Sätzen sein.
Vorrichtungen sind die individuellen Server in dem Daten-Center, die durch den Controller verwaltet werden können. In einer derzeitigen Ausführung sind die einzigen Vorrichtungen, die verwaltet werden können, Computer, die die Agent-Software darauf installiert haben. Vorrichtungen werden durch deren Name identifiziert, und der Controller löst diesen Namen zu einer IP-Adresse unter Verwendung des DNS auf, um mit der Vorrichtung zu kommunizieren.
Vorrichtungs-Informationen werden in mehreren Objekten gespeichert. Ein Vorrichtungs-(Devices)-Objekt speichert die Grundinformationen, einschließlich des Namens, während die MAC Adressen in DeviceHWAddrs Objekten gespeichert werden, die mit dem Vorrichtungs-Objekt verknüpft sind. Andere Hardware-Informationen (wie beispielsweise SMBIOS GUID und Festplatten-Signaturen) können in Fällen dieses Objekts gespeichert werden. Um unter den unterschiedlichen Typen von Informationen zu unterscheiden, hält das DeviceTypes Objekt Definitionen der unterschiedlichen Typen von Hardware-Adressen. Jeder Fall von DeviceHWAddrs ist mit dem entsprechenden Fall von DeviceTypes verknüpft. Die IP-Adresse, die bestimmten MAC-Adressen zugeordnet ist, kann auch gespeichert werden, und zwar in Fällen von DeviceHWIPAddrs, die dem DeviceHWAddrs Fall, die bestimmte MAC-Adresse darstellend, zugeordnet sind. Derzeit werden die IP-Adressen-Informationen nicht für MAC-Adressen gespeichert.
Aufgaben beziehen sich allgemein auf zwei Typen von Aufgabe-Informationen, nämlich Aufgabe-Masken- bzw. Vorlagen, die Aufgaben sind, bereit, um zu laufen, und Aufgabe-Historiken, die zuvor gelaufene Aufgaben sind. Aufgabe-Masken werden in dem JobInstances Objekt gespeichert. Fälle dieses JobInstances Objekt sind durch eine Kombination von zwei Eigenschaften, einem Aufgabe-Namen und einem Aufgabe-Identifizierer, identifiziert. Aufgabe-Masken werden mit einem Aufgabe-Identifizierer von Null gespeichert und ein Name, der eindeutig unter den JobInvocations ist, wird mit einem Aufgabe- bzw. Job-Identifizierer von Null gespeichert. Die Properties (Eigenschaften) einer Aufgabe-Maske (neben dem Aufgabe-Identifizierer) können durch den Benutzer editiert werden. In einer derzeitigen Ausführung werden keine anderen Objekte verwendet, um Aufgabe-Masken zu speichern.
Aufgabe-Historiken werden in mehreren Objekten gespeichert. Ein JobInvocations Objekt speichert die Grundinformationen, einschließlich des Namens, des Aufgabe-Identifizierers und der Zeit, zu der die Aufgabe lief. Der Aufgabe-Identifizierer ist ein Wert anders als Null. Der Name kann leer sein und kann derselbe wie andere JobInvocations Fälle sein (da der Aufgabe-Identifizierer eindeutig eine Aufgabe-Historik identifiziert). Jeder JobInvocation, der eine Aufgabe-Historik darstellt, ist mit einem Fall des Jobs-Objekts verknüpft. Dies stellt den Status des Jobs dar, unabhängig der Zahl von Vorrichtungen, auf die er lief. Dies kann als „parent" für den Status der Aufgaben an jeder der individuellen Vorrichtungen angesehen werden. Der tatsächliche Status für die Aufgabe an jeder Vorrichtung wird in zusätzlichen Fällen der Jobs Klasse, einer pro Vorrichtung, gespeichert. Jeder dieser Fälle ist mit dem Parent Jobs Fall verknüpft, und kann als die „children" des Parent-Falls angesehen werden. Dies bildet eine zweistufige Parent-Child-Beziehung, die zu zusätzlichen Stufen bzw. Leveln erweitert werden kann. Es ist anzumerken, dass, falls die Aufgabe nicht auf irgendwelchen Vorrichtungen läuft (da der Satz, der gerade läuft, leer ist), dann der Parent Jobs Fall nicht mit irgendwelchen Children Jobs Fällen verknüpft sein wird.
Die Jobs Fälle, die dem Status einer Aufgabe bzw. Job auf einer individuellen Vorrichtung entsprechen, speichern nicht die tatsächliche Ausgabe der Aufgabe. Anstelle davon wird der Ausgang in einem dieser mehreren Fällen des JobLogs Objekts gespeichert. Jeder Fall von JobLogs speichert einen Teil der Ausgabe der Aufgabe. Die vollständige Ausgabe kann unter Verwendung der Sequenz-Eigenschaft dieses Objekts rekonstruiert werden, um die Teil-Ausgänge in Reihenfolge zu setzen. JobLogs speichert drei Typen eines Ausgangs bzw. einer Ausgabe, einschließlich der Standard-Fehler-Ausgabe, der Standardausgabe und des Exit-Status, wenn die Aufgabe tatsächlich endet. Die JobLogs Fälle werden erzeugt, wenn der Ausgang von der Aufgabe in den Controller gelangt. Es ist anzumerken, dass es dabei möglich ist, dass keine JobLogs, die einer gegebenen (Child) Jobs Aufzeichnung zugeordnet sind, vorhanden sind, da entweder die Aufgabe nicht an der Vorrichtung startete (wobei in diesem Fall die Jobs Aufzeichnung eine Fehleranzeige enthält) oder keine Ausgabe oder Beendigungsstatus bis jetzt von der Vorrichtung empfangen worden ist.
Wie anhand der 4A–4I, APPENDIX A und der vorstehenden Beschreibung ersichtlich werden kann, ermöglichen die Architektur, Strukturen und Protokolle der vorliegenden Erfindung eine wesentliche Flexibilität und Effizienz beim Verwalten eines Daten-Centers. Ein erstes Beispiel kann dann gesehen werden, wenn ein Upgrade oder ein Patch an einer Anzahl von Computern installiert wird. Anstelle davon, dass der Administrator zu jedem Computer (möglicherweise entfernt) gehen muss und das Upgrade-Paket laufen fassen muss, kann, mit der Architektur und den Strukturen der vorliegenden Erfindung, der Administrator zu dem Controller (möglicherweise entfernt) gehen, die Ziel-Nodes von den Sätzen und den Node-Listen, vorhanden an dem Controller, auswählen, und das Upgrade initiieren, möglicherweise zu einem Zeitpunkt in der Zukunft. Nachdem das Upgrade initiiert worden ist, kann der Administrator die Ergebnisse an dem Controller prüfen und sehen, welche (falls welche vorhanden sind) Nodes fehlschlugen, das Update abzuschließen. Dies verringert wesentlich den Aufwand, der erforderlich ist, um die Upgrades durchzuführen, und hält automatisch ein auditierbares Protokoll der Ergebnisse einer Durchführung der Upgrades aufrecht und verringert auch das Potenzial von Fehlern, falls (zum Beispiel) das Upgrade eine spezifische Verarbeitung an jedem Computer erfordert, was zuvor manuell an jedem Computer eingegeben werden musste. Weiterhin kann, unter Verwendung der Aspekte der vorliegenden Erfindung, die Operation in dem Controller gespeichert werden und an einem Testsystem getestet werden, bevor die identische Operation an den Produktionssystemen durchgeführt wird.
Ein zweites Beispiel dieser Flexibilität und Effizienz kann dann gesehen werden, wenn ein neuer Server für einen neuen Hosting-Kunden hinzugefügt wird. Anstelle eines Installierens des Betriebssystems manuell, dann Konfigurieren des Computers für den Kunden, kann, mit den verschiedenen Aspekten der vorliegenden Erfindung, der Administrator eine Anzahl von verfügbaren „Vorrats" Computern aufrechterhalten, die betrieben werden, allerdings nicht in unmittelbarer Benutzung sind. Wenn ein neuer Kunde unterzeichnet, kann ein Satz von Operationen eingeleitet werden (entweder automatisch oder manuell), um einen der Vorrats-Computer auszuwählen, wobei dann dieser für den bestimmten Kunden konfiguriert wird. Diese Konfiguration kann auch ein Konfigurieren irgendwelcher zusätzlichen Vorrichtungen (wie beispielsweise Schalter oder Load-Balancers), erforderlich dazu, den Kunden zu bedienen, umfassen. Da die Konfigurationsschritte durch Scripts, im Gegensatz zu manuell, durchgeführt werden, werden die Risiken von Fehlern wesentlich verringert. Zusätzlich können sie automatisch durchgeführt werden, was dem Administrator des Daten-Centers ermöglicht, das System (zum Beispiel) automatisch für den Kunden zu konfigurieren, nachdem der Kunde eine Kaufnachfrage auf der Web-Seite des Daten-Centers abgeschlossen hat.
Ein drittes Beispiel kann in dem Überwachen und Zusammenstellen von Daten über den Status einer Gruppe von Computern gesehen werden. Anstelle davon, Daten von einer Anzahl von Computern durch manuelles Einstellen eines Zusammenstellungssystems zusammenstellen zu müssen, kann eine Operation an jedem einer Anzahl von Computern laufen. Die Operation kann regelmäßig Benutzungsinformationen zurück zu dem Controller berichten, der dann diese Informationen in einen Speicher, wie beispielsweise dem Datenspeicher oder einem anderen, geeigneten Speicher, speichert. Die Informationen können zu einem späteren Punkt durch den Administrator analysiert werden, um zu verstehen, wie Computer arbeiten, um die Gründe für Fehler in einem Dienst bzw. Service zu untersuchen, oder für irgendeinen anderen Zweck.
Es wird sich nun einer Erläuterung der Betriebsweise der vorliegenden Erfindung unter besonderer Bezugnahme auf die 5–7 zugewandt, um eine Operation an einer Anzahl von Nodes durchzuführen, wobei die Ziel-Nodes zuerst ausgewählt werden und eine Aufgabe, die die Operationen aufweisen, um die Operationen, erzeugt dafür, durchzuführen, wie dies durch den Schritt 500 dargestellt ist, durchgeführt wird. Eine Auswahl kann ein Auswählen eines individuellen Nodes, mehrerer individueller Nodes, eines Satzes, mehrerer Sätze, oder irgendeine Kombination, aufweisen. Die Operation, die durchgeführt werden soll, kann ein Script, ein binäres Programm oder ein anderer Typ einer Aufgabe sein. Es ist anzumerken, dass der Initiator-Prozess 304 (der ein Benutzer über eine Anwendung, ein Web UI oder eine Befehlszeile, oder eine automatisierte Police in Script oder eine Regel sein kann) die Auswahl vornimmt und die Operation auswählt. Eine Aufgabe 404 wird in dem Datenspeicher für diese Operation bei der Auswahl erzeugt.
Zu dem Zeitpunkt, zu dem die Aufgabe laufengelassen wird, wird sie initiiert, mit irgendwelchen Argumenten, die bereitgestellt sind, wie dies durch Schritt 504 angegeben ist. Nachdem sie initiiert ist, erzeugt, am Schritt 506, der Controller 202 eine Nachricht bzw. Meldung, die Informationen über die Aufgabe aufweist (z.B. in dem Fall eines Scripts, das Script selbst und irgendwelcher Parameter). Diese Nachricht wird dann an dem Controller 202 zu den Ziel-Nodes zugeordnet.
Die Nachricht und die Darstellung der Ziel-Nodes werden durch den Controller verwendet, um die Operation einzuleiten, was, in einer Ausführung, durch Erzeugen einer geeigneten XML Nachricht am Schritt 508 und durch Senden der Nachricht zu den Ziel-Nodes unter Verwendung einer Transportschicht am Schritt 510 durchgeführt wird. An diesem Punkt sind der Transportschicht an dem Controller 202 die Informationen über die Ziel-Nodes gegeben worden, und die Nachricht, um zu diesen Nodes zu senden. Es ist anzumerken, dass die Steuerung zu dem einleitenden Prozess 304 zurückgeführt worden ist (Benutzerschnittstelle, Script oder Prozess, der die Operation an dem Controller 202 initiierte), der nicht auf die Operation warten musste, um an allen Nodes abzuschließen. Dies ermöglicht dem initiierenden Prozess 304, mehrere Operationen so, wie dies erwünscht ist, zu initiieren, und später die Ergebnisse dieser Operationen zusammenzustellen.
Die Nachricht wird zu der Transportschicht weitergeführt, die dafür verantwortlich ist, sicherzustellen, dass die Nachricht zu den korrekten Nodes hinführt, z.B. über ein TCP/IP Netzwerk. Die Aufgabe wird, wenn sie an den Ziel-Nodes empfangen wird, gestartet, wie dies durch Schritt 512 dargestellt ist.
6 stellt allgemein die Aufgabe, die an einem Node läuft, wie beispielsweise dem Node 204, beginnend an dem Schritt 600, wo die Nachricht empfangen wird, dar. In 6 stellt die linke Seite des vertikalen Balkens die Aktionen, durchgeführt durch das Agent-Programm oder den Service an dem Node, dar, während die rechte Seite die Aktion, durchgeführt durch das Betriebssystem des Nodes, darstellt. An dem Node empfängt die Transportschicht des Agent die Nachricht und führt die Nachricht weiter zu dem Agent-Service 218 für eine Interpretation. Allgemein bestimmt der Agent-Service 218, wie die Aktion durchzuführen ist, führt sie aus und Ergebnisse werden zurück zu dem Controller über die Transportschicht geführt.
Genauer gesagt stellt Schritt 602 ein Extrahieren der Operation von der Nachricht dar, und Schritt 604 stellt ein Bestimmen der Ausführungsmaschine, um sie zu verwenden, dar. Zum Beispiel erfordern unterschiedliche Typen eines Scripts unterschiedliche Ausführungsmaschinen, und ein binärer Code muss vor einer Ausführung heruntergeladen werden. In jedem Fall stellt Schritt 606 ein Versenden der Operation und irgendwelcher Argumente, die die Nachricht zu der Ausführungsmaschine weiterführte, die bestimmt wurde, dar, während Schritt 608 das Betriebssystem, das die Operation ausführt, darstellt.
Schritt 610 stellt die Ausgabe der Operation, die zusammengestellt wird und/oder in anderer Weise gespeichert wird, dar, die irgend etwas von einem einfachen Erfolg oder Fehler bis zu einer Zusammenstellung von operationsmäßig angeforderten Daten sein kann. Schritt 612 erzeugt eine Nachricht (z.B. in dem MDM Protokoll in dem XML Format), und Schritt 614 führt die Nachricht zu dem Controller 202 über die Transportschicht zurück. Auf diese Art und Weise werden irgendwelche Ergebnisse der Operation (wie beispielsweise die Ausgabe von einem Script oder Programm) in eine Nachricht formatiert und zu dem Controller unter Verwendung der Transportschicht zurückgeführt.
7 stellt eine Art und Weise dar, in der der initiierende Prozess 304, der die Operation an dem Controller 202 initiierte, die Ergebnisse der Operation an jedem Node bestimmen kann. Allgemein behält, über Schritt 700–704, der Controller eine Aufzeichnung über die Operation bei, z.B. werden, wenn die Ergebnisse von den Nodes am Schritt 700 ankommen, die Ergebnisse von den zurückgeführten Nachrichten auf einer Basis pro Operation am Schritt 702 extrahiert und in dem Datenspeicher 302 (oder einem anderen, geeigneten Speicher) an dem Controller 202 an dem Schritt 704 gespeichert. Diese Aktivität führt zu einer fortlaufenden und vollständigen Aufzeichnung der Operation, für jeden Node.
Wie über die Schritte 708–712 dargestellt ist, kann der Administrator oder ein Prozess (wie beispielsweise ein Script), der nicht notwendigerweise der initiierende Prozess 304 ist, diese Informationen von dem Controller 202 abfragen, um den Erfolg der Operation an jedem Node zu bestimmen, nach anderen Daten zu fragen, um, falls notwendig, Fehler zu untersuchen und aufzulösen.
Wie anhand der vorstehenden, detaillierten Beschreibung gesehen werden kann, wird ein Mehrfach-Vorrichtungs-Management-Verfahren und -System geschaffen, das ein Management von Rechenvorrichtungen, wie beispielsweise in einem Daten-Center, erleichtert. Das Verfahren und das System sind äußerst flexibel und effizient, und verringern wesentlich die Kosten, die einer Verwaltung von mehreren Rechenvorrichtungen zugeordnet sind.
APPENDIX A
In einer typischen MDM (Multiple Device Management) Ausführung kann die Schema-Schnittstelle von dem Common Information Model (CIM) Standard zum Darstellen eines Rechenprozesses und von Vorrichtungen abgeleitet werden. Eine solche Ausführung auf einem Betriebssystem Microsoft^® Windows^® würde, zum Beispiel, als ein WMI Schema bezeichnet werden. Die verschiedenen Informationen hier beschreiben ein solches Schema, und andere, dazu in Bezug stehende Daten, sollten allerdings nur als ein Beispiel angesehen werden.
Identifizierer-Definitionen
SET NAME
Der set name („Set-Name") identifiziert eindeutig einen Satz. Er ist in Sets.Name Property gespeichert und kann aus bis zu 256 Unicode Zeichen bestehen. Jedes Zeichen ist gültig, allerdings werden nicht-druckfähige Zeichen nicht empfohlen. Namen sind fall-unempfindlich, allerdings wird der Fall bewahrt. Der set name muss eindeutig über alle set names (Satz-Namen) sein.
DEVICE NAME
Der „device name" („Vorrichtungs-Name") identifiziert eindeutig eine Vorrichtung und wird dazu verwendet, die IP-Adresse der Vorrichtung zu finden, um mit ihr zu kommunizieren. Er ist in Devices.Name Property gespeichert. Er kann aus bis zu 256 Unicode Zeichen bestehen. Jedes Zeichen ist gültig, allerdings werden nicht-druckfähige Zeichen nicht empfohlen. Namen sind fall-unempfindlich, allerdings wird der Fall bewahrt. Es ist anzumerken, dass device name und set name dieselbe Zahl von Zeichen haben, da sie in einem einzelnen Feld in dem JobInvocations Objekt gespeichert sind.
JOB NAME
Der „job name" („Aufgabe-Name") wird dazu verwendet, eindeutig Job- bzw. Aufgabe-Masken, und als einen Teil von Identifikations-Informationen für Aufgabe-Historik-Aufzeichnungen, zu identifizieren. Er ist in JobInvocations.Name und Jobs.Name Properties gespeichert. Der Aufgabe-Name kann aus bis zu 50 Unicode Zeichen bestehen. Jedes Zeichen ist gültig, allerdings werden nicht-druckfähige Zeichen nicht empfohlen. Namen sind fall-unempfindlich, allerdings wird der Fall bewahrt. Aufgabe-Masken (Aufgaben, wo der Aufgabe-Identifizierer Null ist) müssen eindeutig sein. Allerdings kann derselbe Name auch, möglicherweise mehrere Male, in Aufgabe-Historik-Aufzeichnungen verwendet werden.
DEVICE TYPE NAME
Der „device type" („Vorrichtungs-Typ") Name wird dazu verwendet, den Typ einer Vorrichtung zu identifizieren. Er ist in Devices.Type Property gespeichert und ist in den Werten von DeviceTypes.Name Properties definiert. Er kann aus bis zu 50 Unicode Zeichen bestehen. Alle Zeichen sind gültig, allerdings werden nicht-druckfähige Zeichen nicht empfohlen. Namen sind fall-unempfindlich, allerdings wird der Fall bewahrt. Er muss nicht eindeutig über alle Fälle von DeviceTypes sein.
DESCRIPTIONS
„Descriptions" („Beschreibungen") sind typisch 256 Unicode Zeichen (siehe allerdings individuelle Objekt-Definitionen für spezifische Werte). Alle Unicode Zeichen sind gültig, einschließlich „carriage returns" und „newlines".
Objects
Jedes „object" („Objekt") kann Properties und Verfahren enthalten und Assoziationen zu anderen Objekten haben. In einer Ausführung werden die Objekte, Properties (Eigenschaften), Verfahren und Assoziationen durch WMI freigegeben. Zusätzilche Assoziations-Klassen werden verwendet, um Assoziationen umzusetzen, wie dies nachfolgend beschrieben ist.
Jede Objekt-Definition beginnt mit einer Zusammenfassung, wobei dann eine Definition in dem folgenden Format vorliegt:
Die Bedingungen, unter denen die Klasse erzeugt und gelöscht werden kann, werden nachfolgend, zusammen mit Informationen über die anderen Klassen, zu denen diese Klasse zugeordnet ist, beschrieben. Jede Property der Klasse ist auch aufgelistet, in diesem Format:
Jedes Verfahren wird so, wie dies nachfolgend angegeben ist, beschrieben:
Sets
Im Wesentlichen sind sets („Sätze") die Aufbau-Blöcke eines Mehrfach-Vorrichtungs-Managements, und weisen Objekte dieser Gruppen-Vorrichtungen entsprechend derselben logischen oder physikalischen Gruppierung auf. Dabei ist eine Eins-zu-Mehrfach-Beziehung zwischen einem Sets Object und Devices Objects vorhanden. Befehle können an jedem Element von Sets Object mittels des Execute-Verfahrens ausgeführt werden.
Fälle der Sets Klasse werden durch den Benutzer erzeugt (oder durch einen anderen Prozess). In einer Ausführung werden Fälle niemals automatisch durch das Objekt-Modell erzeugt. Die einzige Property, die für neue Fälle der Sets Klasse erforderlich ist, ist Name. Der Wert von Name muss eindeutig unter den Fällen von Sets an dem Controller sein.
Fälle der Sets Klasse können durch den Benutzer ausgewählt werden (oder einen anderen Prozess). Fälle werden niemals automatisch durch das Objekt-Modell in einer beschriebenen Ausführung gelöscht. Wenn ein Fall gelöscht ist, werden keine Änderungen bei anderen Fällen vorgenommen (einschließlich solchen Fällen, die sich auf die Klasse, die gelöscht wird, beziehen).
Fälle von Sets können Assoziationen zu Fällen von Devices (Vorrichtungen) haben; ein Fall von Sets (Sätzen) besitzt eine Zuordnung zu jedem Fall von Devices, was ein Mitglied des Satzes ist. Jeder Fall von Sets kann zu Null, einer oder mehreren Fällen von Devices, zugeordnet sein. Fälle von Sets können auch Assoziationen zu Fällen von JobInvocations haben. Falls der JobInvocations Fall eine Maske ist (RootJobID Property von JobInvocations ist Null), dann stellt die Zuordnung dar, dass die Job-Maske, dargestellt durch den JobInvocations Fall, an dem zugeordneten Satz laufen soll. Falls der JobInvocations Fall eine Historik-Aufzeichnung ist (RootJobID ist nicht Null), dann stellt die Zuordnung die Tatsache dar, dass der Job in JobInvocations an dem zugeordneten Satz lief.
Set Properties Name
Der Wert dieser Property kann unter Verwendung des Rename Verfahrens geändert werden. Der Wert muss eindeutig unter den Sets Fällen an dem System sein.
Description
Dies ist eine Freitext-Beschreibung des Set. Sie kann NULL oder leer sein und kann geerbt werden.
Unused Properties (nicht benutzte Properties)
Die Caption (Überschrift) InstallDate und Status Properties sind von den Parent-Klassen mitgenommen, werden allerdings momentan nicht in der momentanen Ausführung verwendet.
Verfahren
AddDevice
AddDevice wird dazu verwendet, eine gesteuerte oder nicht gesteuerte Vorrichtung zu einem Set hinzuzufügen.
RemoveDevice
Rename
Execute
Dieses Verfahren bewirkt, dass ein Job (Aufgabe) gegenüber den Mitgliedern des Satzes, auf dem er läuft, laufengelassen wird. Falls der Job (Aufgabe) erfolgreich erzeugt ist, verursacht er, dass JobInvocation Fälle für den Job erzeugt werden. Der Wert der. RootJobID Property des neuen JobInvocations Fall wird als der Rückführwert dieses Verfahrens zurückgeführt. Es ist anzumerken, dass die Job-Ausführung asynchron ist, so dass ein Erfolg dieses Verfahrens nicht bedeutet, dass die Aufgabe selbst erfolgreich an den Agents sein wird.
Das CommandType Argument spezifiziert, wie die Command und Parameters Felder interpretiert werden sollen:
Dies wird zu der Command Property der neuen JobInvocations Fälle geschrieben. Der Wert des Parameters Argument Feld wird stillschweigend ignoriert, falls CommandType den Wert 3 hat. Die maximale Länge des Description Arguments ist 256 Unicode Zeichen. Dies wird in der Description Property des neuen JobInvocations Falls gespeichert. Dies ist nicht ein Fehler für den Satz, so dass er leer ist. In diesem Fall wird ein JobInvocations Fall als normal erzeugt, zusammen mit dem Parent Jobs Fall. Allerdings sind dabei keine Child Jobs Fälle vorhanden. Benutzer des Objekt-Modells müssen für diese Situation vorbereitet sein.
Special Commands
Falls CommandType den Wert 3 hat, dann enthält das Command Argument einen der folgenden Werte:
Der Text ist fall-unempfindlich (das bedeutet, dass, zum Beispiel, „Reboot", „REBOOT" und „reboot" alle bewirken, dass der Server einen Reboot-Vorgang startet). Falls der Wert des Command Arguments nicht einer von diesen ist, führt das Verfahren einen Fehler zurück.
DEVICES
Devices sind Mitglieder von sets (Sätzen); sets (Sätze) sind Gruppen von devices. Devices stellen physikalische Computersysteme dar, die zum Beispiel typischerweise Server-Geräte sind. Mit einem Mehrfach-Vorrichtungs-Management ist ein Ziel dasjenige, ein Management bzw. eine Verwaltung an vielen Maschinen gleichzeitig durchzuführen. Allerdings können mit dem device object auch Befehle ausgeführt werden.
Creation
Fälle von Devices können unter einer Anforderung des Benutzers oder eines anderen Prozesses, oder automatisch durch den Controller, basierend auf dem Empfang eines Auto-Discovery-Pakets von einem Agent, erzeugt werden. Ein Fall der Devices Klasse kann manuell durch den Benutzer oder einen anderen Prozess erzeugt werden. Der neue Fall muss mindestens einen Wert für den Name Property haben, und dieser Wert kann nicht bereits als der Name eines anderen Falls der Devices Klasse an dem System existieren. Der Wert des Name Property muss ein Name sein, der an dem Controller zu der IP- Adresse der administrativen Schnittstelle an der Vorrichtung selbst aufgelöst werden kann. Typischerweise wird diese Auflösung unter Verwendung eines DNS Servers auftreten.
Die neuen Fälle können zu einer oder mehreren MAC Adressen assoziiert werden, und jede MAC Adresse zu einer oder mehreren IP-Adressen. Dies wird durch Zuordnen des neuen Falls der Devices Klasse zu Fällen von DeviceHWAddrs, und Assoziationen von DeviceHWAddrs mit DeviceHWIPAddrs, angezeigt. Allerdings muss nur der Name mit der Maschine kommuniziert werden. Der Controller verwendet DNS, um den Namen zu einer IP-Adresse aufzulösen. MAC und IP werden nicht für eine Kommunikation verwendet und dienen im Wesentlichen zur Information nur an dem Controller. Wenn der Fall erzeugt ist, schickt der Controller eine Anforderung zu dem Agent, um Node-Informationen zu erhalten, einschließlich der IP- und MAC-Adressen. Für alle manuell erzeugten Devices Fälle wird LastDiscoveryTime NULL sein. Falls an irgend einem späteren Punkt ein Auto-Discovery Paket empfangen ist, das diesen Devices Fall anpasst, wird dieses Feld mit der Zeit, zu der das Paket empfangen wurde, aktualisiert werden.
Das SMBIOS GUID kann alternativ in dem Controller gespeichert werden und dazu verwendet werden, um eindeutig die Vorrichtung (device) zu identifizieren. Dies kann ohne Modifikationen an dem Objekt-Modell vorgenommen werden, da es als ein neuer device type (in DeviceHWAddrs, verknüpft mit einem DeviceTypes, das SMBIOS GUID darstellend) gespeichert wird.
Deleting
Fälle der Devices Klasse können durch den Benutzer oder einen anderen Prozess gelöscht werden. Fälle können durch das System gelöscht werden, falls das Controller.RefreshDeviceList() Verfahren aufgerufen wird. Wenn ein Fall von Devices gelöscht wird, werden irgendwelche Fälle von DeviceHWAddrs, die sich auf dieselbe Vorrichtung beziehen, auch gelöscht (was auch ein Löschen der verknüpften DeviceHWIPAddrs verursachen könnte).
Assoziationen
Fälle von Devices können Assoziationen zu den folgenden Klassen haben:

– Zu Fällen von Sets Ein Fall von Devices besitzt eine Assoziation zu jedem Fall von Sets, von denen sie ein Mitglied ist. Jeder Fall von Devices kann zu Null, einem oder mehr Fällen von Sätzen zugeordnet werden.
– Zu Fällen von JobInvocations Ein Fall von Devices besitzt eine Assoziation zu JobInvocations. Falls der JobInvocations Fall eine Maske ist (die RootJobID Property von JobInvocations ist Null), dann stellt die Zuordnung dar, dass die Job-Maske, dargestellt durch den JobInvocations Fall, auf der zugeordneten Device (Vorrichtung) laufen soll. Falls der JobInvocations Fall eine Historik-Aufzeichnung ist (RootJobID ist nicht Null), dann stellt die Zuordnung die Tatsache dar, dass der Job (die Aufgabe) in JobInvocations auf der zugeordneten Vorrichtung lief.
– Zu Fällen von Jobs Ein Fall von Device besitzt eine Zuordnung zu Fällen von Jobs, die den Parent Job jedes Jobs (jeder Aufgabe), der auf dieser Vorrichtung läuft, darstellt.
– Zu Fällen von DeviceHWAddrs Ein Fall von Device besitzt eine Zuordnung zu einem Fall von DeviceHWAddrs für jede Hardware-Adresse an der device (Vorrichtung), über die der Controller Kenntnis hat. In einer derzeitigen Version sind nur Hardware-Adressen, gespeichert an dem Controller, MAC-Adressen von NIC-Karten.
– Zu einem einzelnen Fall von DeviceTypes Ein Fall von Devices besitzt eine Zuordnung zu einem Fall von DeviceTypes, was den Device-Typ angibt. In einer derzeitigen Version wird nur ein einzelner Device-Typ unterstützt, so dass alle Devices Fälle zu einem einzelnen Fall von DeviceTypes assoziieren.

Properties
Name
Dieser ist von der Parent-Klasse geerbt.
Der Wert dieser Property kann unter Verwendung des Rename Verfahrens geändert werden.
Alive
Falls die Device nicht kontrolliert ist, ist diese Property immer falsch. Ansonsten wird diese Property auf wahr dann gesetzt, wenn eine Vorrichtung (Device) gesteuert wird, und wird auf wahr gesetzt (falls momentan auf falsch gesetzt), zu jedem Zeitpunkt, zu dem ein Heartbeat von der Vorrichtung empfangen wird. Die Heartbeat-Zeitperiode ist eine globale Einstellung für den Controller. Der Agent sollte ein Heartbeat-Paket zu jeder Heartbeat-Zeitperiode schicken. Der Controller wird diese Property auf falsch setzen, falls sie nicht einen Heartbeat von der Vorrichtung innerhalb der Periode von eineinhalb Mal der Heartbeat-Zeitperiode empfängt. Die Heartbeat-Zeitperiode, die verwendet wird, ist die eine, die momentan an dem Controller eingestellt ist. Dies kann unterschiedlich zu der Heartbeat-Zeitperiode der Vorrichtung sein.
Controlled
Der Wert dieser Property wird durch Starten oder Beenden einer Steuerung der Device, unter Verwendung des Manage-Verfahrens, eingestellt.
HeartBeatTime
Falls die Vorrichtung nicht gesteuert ist oder dazu gelangt, nicht gesteuert zu werden, ist dies NULL. Ansonsten wird, wenn eine Vorrichtung gesteuert wird, diese auf die Zeit gesetzt, die für sie gesteuert wird. Während eine Vorrichtung gesteuert wird, wird die se auf die Zeit gesetzt, zu der der am kürzesten vorher liegende Heartbeat von der Vorrichtung empfangen wurde.
AlertStatus
Falls die Vorrichtung nicht gesteuert ist oder dazu gelangt, nicht gesteuert zu werden, wird diese immer auf Unavailable (nicht verfügbar) gesetzt. Ansonsten wird, wenn eine Vorrichtung gesteuert wird, diese zu Anfang auf „Status nicht bekannt" gesetzt. Nach einem Aufruf zu EnableAlerts() wird diese auf den Wert, zurückgeführt von dem Agent, der „verfügbar", „gesperrt" oder „freigegeben" sein kann, zurückgeführt.
Type
Description
LastDiscoveryTime
Zu jedem Zeitpunkt, zu dem ein Auto-Discovery-Paket empfangen wird, das diesen Devices Fall anpasst, wird das Datum auf das momentane Datum aktualisiert. Dies kann dazu verwendet werden, manuell eingegebene Aufzeichnungen zu identifizieren, die niemals an dem Netzwerk gesehen worden sind.
Die folgenden Properties (Eigenschaften) sind von den Parent Klassen geerbt, sind allerdings momentan nicht verwendet: Caption, CreationClassName, InitailLoadInfo, InstallDate, LastLoadInfo, NameFormat PowerManagementSupported, PowerManagementCapabilities, PowerState, PrimaryOwnerContact, PrimaryOwnerName, ResetCapability, Roles, Status und Time.
Verfahren EnableAlerts
Dieser Aufruf ist synchron. Falls Warnungen an einer Vorrichtung freigegeben werden, wird die Vorrichtung die momentanen Warnungen zurückführen. Falls Warnungen gesperrt sind, wird der Controller die Details von Warnungen für diese Vorrichtung löschen.
RecoverManagedDevice
Dieses Verfahren kann dann aufgerufen werden, wenn der Benutzer glaubt, dass die Konfiguration an einer Vorrichtung beschädigt bzw. unbrauchbar ist. Der Controller schickt die folgenden Informationen zu der Vorrichtung ab:

– Eine Anforderung nach den Vorrichtungs-Informationen.
– Eine Steuerungs-Anforderung, um diese Vorrichtung zu verwalten.
– Die momentanen Heartbeat-Konfigurations-Informationen (das Heartbeat-Intervall)
– Der momentane Warn-Status für diese Vorrichtung (freigegeben oder nicht freigegeben).

Dieser Aufruf kehrt zurück, nachdem alle davon verarbeitet worden sind, und könnte demzufolge eine gewisse Zeit benötigen.
Manage
Dies ändert den Zustand einer Steuerung für eine Vorrichtung, und kehrt zurück, wenn sie abgeschlossen ist. Der Wert von ControlFlag spezifiziert die Operation, die gegenüber der Vorrichtung durchzuführen ist:
Ein Fehler wird dann zurückgeführt, wenn ein Versuch, eine Vorrichtung zu steuern, aufgrund eines Protokoll-Version-Fehlers fehlgeschlagen ist.
Execute
Das SetPowerState Verfahren ist von den Parent Klassen geerbt, ist allerdings momentan bei dieser Ausführung nicht verwendet.
DeviceTypes
In einer Ausführung berichtet Devices demselben Device-Typ, „Microsoft Server Appliance".
Fälle von DeviceTypes können manuell oder automatisch erzeugt werden. Wenn sie manuell erzeugt sind, muss der Name eindeutig über existierende DeviceTypes Fälle sein. Eine manuelle Erzeugung kann an Netzwerken verwendet werden, wo ein Auto-Discovery nicht arbeitet.
Fälle von DeviceTypes können automatisch basierend auf ankommenden Auto-Discovery-Paketen, oder bei der Erzeugung von Fällen von Devices, erzeugt werden. Eine andere Art und Weise, in der Fälle von DevicesTypes erzeugt werden, basiert auf der Erzeugung von Devices Fällen. Jeder Devices Fall umfasst eine DeviceType String. Falls ein DeviceTypes Fall nicht entsprechend zu diesem String existiert, wird ein neuer Fall von DeviceTypes mit diesem String als sein Name, und einer leeren Description, erzeugt.
Deletion
Fälle von DeviceTypes können gelöscht werden, allerdings nur dann, wenn keine Fälle von Devices mit demselben Typ eines Strings wie der eine, der gelöscht wird, vorhanden sind. Falls ein Löschen aufgrund hiervon fehlschlägt, sollte das WMI DeleteInstance Verfahren mit einem Fehler WBEM_E_FAILED zurückkehren.
Associations
Ein Fall von DeviceTypes ist jedem Fall von Devices, der von demselben Typ ist, zugeordnet.
Properties Name
Der Name eines Vorrichtungs-Typs kann nicht geändert werden.
Description
Die Caption, InstallDate und Status Properties sind von den Parent-Klassen geerbt, werden allerdings momentan in der momentanen Ausführung nicht verwendet. Dabei sind keine Verfahren für dieses Objekt vorhanden.
HWADDRTYPES
Jede Device enthält typischerweise viele individuelle, identifizierbare Hardware-Teile. Jeder Hardware-Teil kann eine Adresse oder einen eindeutigen Identifizierer enthalten.
In einer Version ist der einzige Adressen-Typ, der intern verwendet wird, „MAC". Dies wird dazu verwendet, die MAC-Adressen von Devices zu speichern. Fälle von HWAddrTypes können manuell oder automatisch erzeugt werden. Ein Fall wird automatisch dann erzeugt, wenn ein Fall von DeviceHWAddrs erzeugt wird, wobei der Type Property Wert nicht die Name Property eines existierenden HWAddrTypes Falls anpasst. In diesem Fall wird der neue Fall von HWADDrTypes mit einem Name Property, der denselben Wert wie in dem DeviceHWAddrs Type Property besitzt, erzeugt, und die Description Property wird leer sein.
Deletion
Fälle von HWAddrTypes können gelöscht werden. Das Löschen wird dann fehlschlagen, wenn irgendwelche Devices Fälle dieselbe Type Property wie der Name Property an dem Fall, der gelöscht wird, enthalten.
Associations
Ein Fall von HWAddrTypes ist allen Fällen von DeviceHWAddrs zugeordnet, die Hardware-Adressen-Informationen für diesen Typ einer Hardware enthalten.
Properties Name
Description
Die Caption, InstallDate und Status Properties sind von den Parent-Klassen geerbt, werden allerdings derzeit nicht in der momentanen Ausführung verwendet. Dabei sind keine Verfahren für dieses Objekt vorhanden.
DEVICEHWADDRS
Die Device-Hardware-Adresse identifiziert eindeutig einen Teil einer Hardware, wie beispielsweise NIC.
In einer momentanen Ausführung ist der einzige Typ einer Hardware-Adresse, die intern verwendet wird, „MAC". Diese wird dazu verwendet, die MAC-Adressen von Devices zu speichern. Fälle von DeviceHWAddrs können automatisch oder manuell erzeugt werden. Eine automatische Erzeugung tritt basierend auf empfangenen Auto-Discovery-Paketen auf. Falls das Paket eine Hardware-Adresse enthält (einen Typ und eine Adresse) enthaltend, dann wird ein neuer Fall von DeviceHWAddrs für die Hardware-Adresse erzeugt (was auch ein Erzeugen eines Falls von HWAddrTypes erfordern kann).
Deletion
Fälle von DEviceHWAddrs können gelöscht werden. Fälle werden auch automatisch dann gelöscht, wenn der entsprechende Devices Fall gelöscht wird.
Associations

– Zu einem einzelnen Fall von Devices Ein Fall von DeviceHWAddrs ist dem Fall von Devices zugeordnet, der die Hardware-Adresse enthält.
– Zu einem einzelnen Fall von HWAddrTypes Ein Fall von DeviceHWAddrs ist dem Fall von HWAddrTypes zugeordnet, was den Typ einer Hardware-Adresse, gespeichert in diesem DeviceHWAddrs Fall, definiert.
– Zu Fällen von DeviceHWIPAddrs Ein Fall von DeviceHWAddrs ist zu null oder mehr Fällen von DeviceHWIPAddrs für jede IP-Adresse zugeordnet, die zu diesem Fall von DeviceHWAddrs zugeordnet ist. Diese Zuordnung wird nur für DeviceHWAddrs verwendet, die die Adresse einer NIC-Hardware enthält.

Properties HWAddr
DeviceName
Type
Unused Properties
Die Caption, InstallDate, Name und Status Properties sind von den Parent-Klassen geerbt, werden allerdings momentan nicht in der momentanen Ausführung verwendet. Dabei sind keine Verfahren für dieses Objekt vorhanden.
DEVICEHWIPADDRS
Dieses Objekt ist momentan nicht verwendet.
JOBINVOCATIONS
Es sind zwei Kategorien von Jobs Invocations vorhanden. Eine erste Kategorie sind Masken. Diese sind Jobs Invocations mit RootJobID gleich zu Null, was bedeutet, dass diese nur Masken sind und nicht zu einem bestimmten Lauf zugeordnet sind. Die zweite Kategorie von Jobs Invocations sind historisch, was bedeutet, dass sie eine historische Aufzeichnung einer Job Invocation sind.
Fälle von JobInvocations können manuell oder automatisch erzeugt werden. Aufgaben-Masken werden manuell erzeugt, während Aufgabe-Historik-Aufzeichnungen automatisch erzeugt werden. Fälle von JobInvocations können manuell durch den Benutzer (oder einen anderen Prozess) erzeugt werden. Nur Aufgabe-Masken können erzeugt werden (durch Definition, Fälle von JobInvocations, wo RootJobID Null ist), und es ist ein Fehler, zu versuchen, einen JobInvocations Fall mit einer RootJobID, anders als Null, zu erzeugen. Manuell erzeugte Fälle von JobInvocations können später irgendeine ihrer schreibfähigen Eigenschaften (Properties) geändert haben.
Automatic Creation (Job Histories)
Wenn eine Aufgabe (Job) ausgeführt wird (unter Verwendung von Devices.Execute oder Sets.Execute), wird ein Fall von JobInvocations erzeugt. Diesem wird ein neuer, ein deutiger Wert von RootJobID gegeben (der nicht Null ist). Die Properties Name, Command, Parameters und Description des neuen Falls werden mit Werten der JobInvocationName, Command, Paramters und Description Argumente zu den Devices.Execute oder Sets.Execute Verfahren, die die Aufgabe erzeugten, belegt. Die Properties TargetName und TargetType werden mit dem Namen des Satezs oder der Vorrichtung, auf der die Aufgabe ausgeführt wird, und dem Typ eines Satzes oder einer Vorrichtung, gefüllt werden. Properies eines automatisch erzeugten JobInvocations Fall können nicht geändert werden. In WMI wird ein Versuch, eine Property eines JobInvocation Falls zu ändern, bewirken, dass das PutInstance (Put_ von Script) Verfahren WBEM_E_FAILED (WbemErrFailed) von scriptOnly Aufgabe-Masken (Fällen, wo RootJobID Null ist) und Aufgaben-Historiken (wo RootJobID nicht Null ist) zurückführt, wobei beide gelöscht werden.
Falls eine Aufgabe-Historik gelöscht wird, werden alle zugeordneten Aufgaben und JobLogs Fälle auch gelöscht. Dies wird in WMI ausgeführt.
Associations

– Zu einem einzelnen Fall von Devices Ein Fall von JobInvocations wird zu einem Fall von Devices zugeordnet, wenn die Aufgabe-(Job) Maske so definiert ist, um auf dieser Vorrichtung zu laufen, oder falls die Aufgabe-Historik auf dieser Vorrichtung laufengelassen wurde. Diese Assoziation existiert nur dann, wenn der Wert von TargetType Devices ist, und falls dies der Fall ist, ist die Assoziation zu dem Devices Fall mit demselben Namen wie er in der TargetName Property gegeben ist, vorhanden.
– Zu einem einzelnen Fall von Sets Ein Fall von JobInvocations ist zu einem Fall von Sets zugeordnet, falls die Aufgabe-Maske so definiert ist, dass sie auf diesem Satz läuft, oder falls die Aufgabe-Historik auf diesem Satz laufengelassen wurde. Diese Assoziation existiert nur dann, wenn der Wert von TargetType Sets ist, und falls dies der Fall ist, ist die Assoziation zu dem Sets Fall mit demselben Namen, wie er in der TargetName Property vorhanden ist, vorhanden.
– Zu einem einzelnen Fall von Jobs Ein Fall von JobInvocations ist zu einem Fall von Jobs zugeordnet, was die Erggebnisse eines Laufenlassens der Aufgabe, dargestellt durch JobInvocations, liefert. Diese Assoziation existiert nur dann, wenn der JobInvocations Fall eine historische Aufzeichnung ist (das bedeutet RootJobID ist nicht Null).

Properties RootJobID
Eindeutige Identifizierer für Root-Job. Dies kann irgendein 64 Bit-Wert sein. Falls er nicht Null ist, zeigt dies an, dass dieser JobInvocations Fall eine Maske, im Gegensatz zu einer historischen Aufzeichnung, für eine zuvor ausgeführte Aufgabe, ist. Falls dieser Wert nicht Null ist, dann ist dieser Fall eine historische Aufzeichnung.
Name
Dies speichert den Namen der Aufgabe (Job), wie das JobInvocationName Argument zu Devices.Execute oder Sets.Execute geführt wurde.
TargetName
Target benennt die Aufgabe (Job), die lief auf: Devices oder Sets.
TargetType
Command
Der Befehl (Command), der an dem Target aufgerufen ist.
Parameters
Die Parameter zu dem Befehl, der aufgerufen ist.
Description
Unused Properties
Die nachfolgenden Properties sind von den Parent-Klassen geerbt, werden allerdings momentan nicht verwendet: Caption, ElapsedTime, InstallDate, Notify, Owner, Priority, StartTime, Status, TimeSubmitted, UntilTime
Verfahren Rename
JOBS
Das Jobs Objekt erfasst die Topologie einer Job Invocation. Zum Beispiel würde, falls der Benutzer ein Satz-Objekt besaß und Execute in Bezug auf diesen Satz aufrief, dann dabei ein Jobs Objekt, erzeugt als der Root Job, und auch ein Jobs Objekt, erzeugt für jede Vorrichtung (Device) des Satzes (Set), sein. Das Root Jobs Objekt wird als der Eintritt in die topologische Struktur der Jobs verwendet. In einer Ausführung wird nur die Parent-Child-Beziehung verwendet, allerdings ist das Modell in der Lage, in einem Baum mit einer Tiefe N realisiert zu werden.
Jobs werden automatisch durch das System erzeugt, wenn ein Job (eine Aufgabe) gestartet wird (zum Beispiel durch die Verfahren Sets.Execute oder Devices.Execute).
Fälle von Jobs können nicht aktualisiert werden. Falls ein Fall von Jobs, der einen Parent-Job darstellt, gelöscht ist, wird das Folgende auch gelöscht:

– Der zugeordnete JobInvocations Fall
– Die Child-Fälle von Jobs, zugeordnet zu dem Jobs Fall
– Die JobLogs Fälle, zugeordnet zu jedem Child Jobs Fälle

Dies löscht die Aufzeichnung des Job-Aufrufs, den Status des Jobs bzw. der Aufgabe an jeder Vorrichtung (Device) und die Ergebnisse der Aufgaben an jeder Vorrichtung.
Aufgaben, die momentan in Arbeit sind, können gelöscht werden. Falls dies auftritt, wird irgendeine weitere Ausgabe von der Aufgabe, empfangen an dem Controller, nicht gespeichert werden, und über keinen Fehler wird berichtet werden.
Associations

– Zu einem einzelnen Fall von JobInvocations Ein Fall von Jobs ist zu dem Fall von JobInvocations, der die Aufgabe darstellt, zugeordnet.
– Zu Fällen von JobLogs Ein Fall von Jobs ist zu Fällen von JobLogs zugeordnet, die die Ausgabe vom Laufenlassen dieser Aufgabe auf einer bestimmten Vorrichtung enthalten. Diese Assoziation existiert nur dann, falls der Fall von Jobs eine einzelne Vorrichtung darstellt, im Gegensatz zu einem Parent Fall.
– Zu Fällen von Jobs Ein Fall von Jobs ist zu Fällen von Jobs, die Child-Prozesse des Parent Jobs Falls darstellend, zugeordnet. In der momentanen Version wird nur ein Niveau einer Parent-Child-Beziehung unterstützt, wo Parent eine Aufgabe darstellt, die auf mehreren Vorrichtungen läuft, und Children die Ergebnisse von individuellen Vorrichtungen darstellt.
– Zu einem einzelnen Fall von Devices Ein Fall von Jobs ist zu einem Fall von Devices dann zugeordnet, wenn der Jobs Fall die Ergebnisse eines Laufenlassens einer Aufgabe an einer einzelnen Vorrichtung hält. Die Assoziation vermittelt der Vorrichtung, dass die Aufgabe weiterläuft.

Properties JobID
ParentJobID
DeviceName
StartTime
EndTime
JobStatus
Wenn das Sets.Execute oder Devices.Execute Verfahren zurückkehrt, wird der Wert des Status eines von 2, 3 oder 11 sein. Falls die Aufgabe nicht an irgendwelchen Vorrichtungen gestartet werden kann, wird der Status auf 2 gesetzt. Falls die Aufgabe nicht an einigen der Vorrichtungen gestartet werden kann, wird der Status auf 11 gesetzt. Ansonsten wurde die Aufgabe an allen Vorrichtungen gestartet und der Status wird auf 3 gesetzt.
Nachdem das Execute Verfahren zurückgekehrt ist, kann der Aufrufer den Wert des Status für den Parent-Jobs-Fall abrufen. Falls die Aufgabe noch an mindestens einer Vorrichtung läuft, wird der Status 3 oder 11 sein. Falls die Aufgabe an allen Vorrichtungen abgeschlossen ist, wird der Status 0 oder 1 sein. Falls die Aufgabe niemals an irgendwelchen Vorrichtungen startete, wird der Status 2 sein.
Für Child-Jobs sind gültige Werte 0 und 3 bis 10. Er wird zu Anfang auf 3 gesetzt, wenn das Child-Jobs-Objekt erzeugt wird. Falls ein Fehler auftritt, der die Aufgabe laufenlässt, wird JobStatus auf einen von 5 oder 7 bis 10 aktualisiert. Falls die Aufgabe erfolgreich zu der Vorrichtung übertragen ist, wird JobStatus auf 4 gesetzt. Falls die Aufgabe durch den Benutzer, der Jobs.Stop aufruft, gestoppt wird, wird JobStatus auf 6 gesetzt werden. Falls die Aufgabe erfolgreich abschließt, wird JobStatus auf 0 gesetzt werden.
Die nachfolgenden Properties sind von den Parent-Klassen geerbt, werden allerdings momentan nicht verwendet: Caption, Description, InstallData, Name und Status.
Verfahren Stop
Dies hält eine Aufgabe, die an einer Vorrichtung ausgeführt wird, an. Falls sie an einem Fall ausgeführt wird, der eine Parent-Aufgabe darstellt, werden alle Child-Chills, die gerade laufen, gestoppt. Eine Aufgabe, die durch den Benutzer gestoppt wurde, wird einen Status Property Wert von „Job Stopped by User" haben.
GetOutput
Die Werte für OutputType sind:

– 0 = erhalte Austritts-Status
– 1 = erhalte Standard-Ausgabe
– 2 = erhalte Standard-Fehler
– 3 = erhalte die gesamte Ausgabe (in einer Sequenz-Reihenfolge).

Dieses Verfahren ist nur für Child-Job-Fälle gültig. Falls OutputType den Wert 0 hat, wird der Austritts-Status zu der Output Folge zurückgeführt. Zum Beispiel würde ein Austritts-Status von 32 als der String „32" in Output zurückgeführt werden.
JOBLOGS
JobLogs erfasst den Ausgang der Ausführung eines Scripts oder einer Ausführbarkeit. Der JobLog ist zu Jobs zugeordnet. Dabei können N JobLogs für irgendwelche Jobs vorhanden sein.
JobLogs werden immer automatisch durch das System erzeugt, wenn eine Aufgabe gestartet wird (zum Beispiel durch die Verfahren Sets.Execute oder Devices.Execute).
Fälle der JobLogs Klasse können nicht aktualisiert werden, und Fälle von JobLogs können nicht in WMI gelöscht werden.
Assoziationen liegen zu einem einzelnen Fall von Jobs vor; ein Fall von JobLogs ist zu einem Fall von Jobs zugeordnet, der die Vorrichtung und die Aufgabe angibt, der diese Ausgabe erzeugte.
Properties JobID
Sequence
Beginnt bei 1, aufwärts laufend. Dieselbe Sequenz-Zahl, verwendet für stdout, stderr, exit status.
LogTime
OutputType
OutputData
Diese Properties sind von den Parent-Klassen geerbt, werden allerdings momentan nicht verwendet: Caption, Description, InstallDate, Name und Status. Dabei sind keine Verfahren für dieses Objekt vorhanden.
WARNUNGEN (ALERTS)
Die Vorrichtungs-Hardware-Adresse identifiziet eindeutig einen Teil einer Hardware, wie beispielsweise NIC.
Das Warn-(Alerts)-Objekt hält Kopien aller Warnungen (Alerts) von verwalteten Vorichtungen, die über Warnungen zu dem Controller berichten, aufrecht. Ob eine Vorrichtung über Warnungen berichtet oder nicht, wird unter Verwendung des Devices.EnableAlerts() Verfahren eingestellt. Jeder Fall des Alerts Objekts stellt eine einzelne Warnung von einer einzelnen Vorrichtung dar. Alert Fälle werden immer automatisch erzeugt, basierend auf Informationen, geliefert von Vorrichtungen. Sie können nicht manuell erzeugt werden (in WMI).
Fälle dieser Klasse können nicht aktualisiert werden, und ein Löschen eines Falls der Alerts Klasse verursacht, dass die Warnung an der Vorrichtung selbst gelöscht wird.
Assoziationen werden zu einem einzelnen Fall von Devices gegeben; zu dem Fall von Devices, der die Vorrichtung repräsentiert, auf der die Warnung erzeugt wurde.
Properties DeviceName
Diese enthält den Namen der Vorrichtung, an der die Warnung erzeugt wurde.
Cookie
AlertType
AlertID
AlertLog
AlertSource
AlertReplaceString
Diese wird in dem Format, wie es von der Vorrichtung empfangen wird, gespeichert. Derzeit ist dies eine Liste von Werten, separiert durch ein Linen- bzw. Zeilen-Zuführungs-Zeichen (Zeichen-Code 10, dezimal). Kein Escape wird in dem Fall durchgeführt, in dem die Werte Kommas enthalten.
ReceivedTime
Dies ist die Zeit, zu der der Controller den Warnungs-Hinweis von der Vorrichtung empfing.
Die folgenden Eigenschaften (Properties) sind von den Parent-Klassen geerbt, werden allerdings momentan nicht benutzt: Caption, Description, InstallDate, Name und Status. Dabei sind keine Verfahren für dieses Objekt vorhanden.
CONTROLLER
Die Controller Klasse wird dazu verwendet, den Controller zu konfigurieren und zu steuern. Der Controller besitzt mehrere, globale, konfigurierbare Parameter, wie beispielseweise ein Heartbeat Intervall. Zusätzlich können der Controller-Dienst und Unterdienste gestartet und gestoppt werden.
Dies ist eine Klasse einer einelementigen Menge (singleton) in Bezug auf ein Erzeugen und ein Löschen, und dieser Fall kann nicht aktualisiert werden. Dabei sind keine Assoziationen vorhanden.
Properties HeartbeatInterval
Falls nicht spezifiziert, wird der Wert 120 Sekunden (2 Minuten) verwendet. Das Minimum, das eingestellt werden kann, ist 60 Sekunden. Die nachfolgenden Eigenschaften werden von den Parent-Klassen geerbt, werden allerdings momentan nicht verwendet: Caption, Description und Name.
Verfahren RefreshDeviceList
Refresh Device Liste ist ein zweistufiger Prozess. Zuerst werden nicht gesteuerte Vorrichtungen von dem Datenspeicher entfernt. Dann wird eine angeforderte Ermittlung für Vorrichtungen mit dem Typ „Microsoft Server Appliance" initiiert. Das Verfahren kehrt dann zurück. An diesem Punkt können die Ergebnisse einer Initiierung der Ermittlung nicht durch den Controller empfangen worden sein, so dass die Devices Tabelle leer sein kann oder teilweise vollständig sein kann.
SetHeartbeatInterval
Dies aktualisiert das Heartbeat-Intervall in der Controller.HeartbeatInterval Property. Sie sendet dann dieses aktualisierte Intervall zu allen verwalteten Vorrichtungen ab. Das Verfahren kehrt dann zurück. Es wartet nicht auf einen Status zum Senden des aktualisierten Heartbeats zu den Vorrichtungen. Dieser Wert wird in Sekunden angegeben. Das Minimum, das eingestellt werden kann, ist 60. Falls ein Versuch vorgenommen wird, weniger als 60 einzustellen, wird der gespeicherte Wert auf 60 in einer Ausführung gesetzt werden.
Es ist anzumerken, dass dann, falls dieses erhöht wird, Vorrichtungen so erscheinen könnten, nicht nach 1,5·old-heartbeat-interval zu leben (die Devices.Alive Property wird auf falsch gesetzt werden). In WMI werden spezielle Klassen, bezeichnet als Assoziations-Klassen, verwendet, um Fälle von Objekten zu verknüpfen. Dieser Abschnitt definiert die Assoziations-Klassen, verwendet dazu, die WMI-Klassen, die das Objekt-Modell ausführen, zu verknüpfen.
Assoziations-Klassen werden von entweder CIM_Component oder CIM_Dependency abgeleitet.
CIM_Component enthält die Properties GroupComponent und PartComponent, um den Parent-Fall und den Child-Fall jeweils zu spezifizieren. CIM_Dependency enthält die Properties Antecedent und Dependent, um die Abhängigkeits-Beziehung zu spezifizieren. Wie nachfolgend beschrieben ist, wird die Parent-Klasse aufgelistet, dann werden die Werte der Properties (entweder GroupComponent und PartComponent, oder Antecedent und Dependent) beschrieben. Keine Klassen fügen zusätzliche Properties (Eigenschaften) hinzu oder überschreiben die Beschreibungen oder andere Attribute.
DEVICEHWADDRTODEVICEHWIPADDR
GroupComponent ist eine Referenz zu einem Fall von DeviceHWAddrs, PartComponent ist eine Referenz zu einem Fall von DeviceHWIPAddrs.
DEVICEHWADDRTOHWADDRTYPE
Antecedent ist eine Referenz zu einem Fall von DeviceHWAddrs, Dependent ist eine Referenz zu einem Fall von HWAddrTypes.
DEVICETOALERT
Antecedent ist eine Referenz zu einem Fall von Devices, Dependent ist eine Referenz zu einem Fall von Alerts.
DEVICETODEVICEHWADDR
GroupComponent ist eine Referenz zu einem Fall von Devices, PartComponent ist eine Referenz zu einem Fall von DeviceHWAddrs.
DEVICETODEVICETYPE
Antecedent ist eine Referenz zu einem Fall von Devices, Dependent ist eine Referenz zu einem Fall von DeviceTypes.
DEVICETOJOBINVOCATION
Antecedent ist eine Referenz zu einem Fall von Devices, Dependent ist eine Referenz zu einem Fall von JobInvocations.
SETTOJOBINVOCATION
Antecedent ist eine Referenz zu einem Fall von Sets, Dependent ist eine Referenz zu einem Fall von JobInvocations.
DEVICETOJOB
Antecedent ist eine Referenz zu einem Fall von Devices, Dependent ist eine Referenz zu einem Fall von Jobs.
JOBTOJOB
GroupComponent ist eine Referenz zu einem Fall von Jobs (die Parent darstellend), PartComponent ist eine Referenz zu einem Fall von Jobs (für die Children).
JOBINVOCATIONTOJOB
Antecedent ist eine Referenz zu einem Fall von JobInvocations, Dependent ist eine Referenz zu einem Fall von Jobs.
JOBTOJOBLOG
Antecedent ist eine Referenz zu einem Fall von Jobs, Dependent ist eine Referenz zu einem Fall von JobLogs.
SETTODEVICE
GroupComponent ist eine Referenz zu einem Fall von Sets, PartComponent ist eine Referenz zu einem Fall von Devices.

Claims

Verfahren zum Betrieb eines Computernetzwerkes, das mindestens einen Controller-Computer und mindestens einen Node- (Knoten) Computer enthält, wobei das Verfahren umfasst: Definieren eines Sets durch ein erstes computerausführbares Programm (135, 136, 145, 146, 185, 206 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330), das mit dem Controller-Computer interagiert, wobei das Set eine Gruppierung mindestens eines Node-Computers umfasst; Hinzufügen mindestens eines der Node-Computer zu dem Set durch ein zweites computerausführbares Programm (135, 136, 145, 146, 185, 206 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330), das mit dem Controller-Computer interagiert, wobei der mindestens eine der Node-Computer durch den Controller-Computer gesteuert wird; Speichern des Sets durch ein drittes computerausführbares Programm (135, 136, 145, 146, 185, 206, 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330), das mit dem Controller-Computer interagiert; und Benutzen des Sets durch den Controller-Computer, um jeden Node-Computer in dem Set zu steuern, dadurch gekennzeichnet, dass das Set nur auf dem Controller-Computer repräsentiert ist.
Verfahren nach Anspruch 1, weiterhin umfassend das Entfernen mindestens eines der Node-Computer aus dem Set.
Verfahren nach Anspruch 1 oder 2, wobei das Definieren des Sets ein Identifizieren eines Set-Objekts umfasst.
Verfahren nach Anspruch 3, wobei das Hinzufügen des Node-Computers zu dem Set ein Aufrufen einer Methode des Set-Objekts umfasst.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Benutzen des Sets zum Steuern jedes Node-Computers des Sets umfasst: Auswählen des Sets; und Instruieren des Controller-Computers, einen Vorgang (operation) an dem Set durchzuführen, wobei der Controller-Computer mit jedem Node-Computer in dem Set kommuniziert, um die Durchführung des Vorgangs anzufordern.
Verfahren nach Anspruch 5, weiterhin umfassend: Empfangen eines Ergebnisses des angeforderten Vorgangs an dem Controller-Computer von jedem Node-Computer in dem Set; und Speichern (704) des Ergebnisses.
Verfahren nach Anspruch 6, weiterhin umfassend das Organisieren der Node-Computer in logische Strukturen, die das Set enthalten.
Verfahren nach Anspruch 6 oder 7, weiterhin umfassend das Analysieren des Ergebnisses.
Verfahren nach Anspruch 8, wobei das Analysieren des Ergebnisses angibt, dass der Vorgang auf einem gegebenen Node-Computer in dem Set fehlgeschlagen ist; und wobei das Verfahren ferner das Anfordern umfasst, dass die Durchführung des Vorgangs auf dem gegebenen Node-Computer in dem Set wieder versucht wird.
Verfahren nach Anspruch 1 bis 4, weiterhin umfassend: das Pflegen (maintaining) des Sets durch den Controller-Computer; das Bereitstellen einer Auswahl, die mindestens einem der Node-Computer entspricht, durch den Controller-Computer; das Bereitstellen (500, 502) einer Aufgabe (job), die mindestens einem Vorgang entspricht, der auf der Auswahl durchgeführt werden soll, durch den Controller-Computer; das Senden (510) einer Nachricht durch den Controller-Computer an jeden Node-Computer in der Auswahl, wobei die Nachricht den Node-Computer, der die Nachricht empfängt, instruiert, die Aufgabe auszuführen; und das Speichern (704) von Ergebnissen der Aufgabe von jedem Node-Computer in der Auswahl durch den Controller-Computer.
Verfahren nach Anspruch 10, wobei der Controller-Computer mindestens ein Set pflegt und wobei das Bereitstellen der Auswahl durch den Controller-Computer das Bereitstellen von Daten, die mindestens einem Set von Node-Computern entsprechen, umfasst.
Verfahren nach Anspruch 10 oder 11, wobei das Bereitstellen der Aufgabe durch den Controller-Computer das Bereitstellen von Daten, die einem Skript entsprechen, das auf der Auswahl laufen soll, umfasst.
Verfahren nach Anspruch 10 oder 11, wobei das Bereitstellen der Aufgabe durch den Controller-Computer das Bereitstellen von Daten, die einem Binärprogramm entsprechen, das auf der Auswahl laufen soll, umfasst.
Verfahren nach Anspruch 13, wobei die Daten, die einem Binärprogramm, das auf der Auswahl laufen soll, entsprechen, eine Netzwerkadresse umfassen.
Verfahren nach Anspruch 10 oder 11, weiterhin umfassend: das Empfangen (600) der Nachricht bei einem Vermittler (agent)(218, 218₁ –218_n , 312) auf einem der in der Auswahl identifizierten Node-Computer; und die Ausführung (608) der Aufgabe in Erwiderung auf die Nachricht.
Verfahren nach Anspruch 15, wobei die Ausführung der Aufgabe in Erwiderung auf die Nachricht das Laufenlassen (running) eines Skripts umfasst.
Verfahren nach Anspruch 15, wobei die Ausführung der Aufgabe in Erwiderung auf die Nachricht das Laufenlassen eines Binärprogramms umfasst.
Verfahren nach Anspruch 17, wobei das Laufenlassen des Binärprogramms das Abrufen (retrieving) des Binärprogramms auf Basis einer Netzwerkadresse in der Nachricht umfasst.
Verfahren nach einem der Ansprüche 1 bis 18, weiterhin umfassend das Empfangen von Ermittlungsinformation (discovery information) am Controller-Computer, die angibt, dass einer der Node-Computer betriebsbereit ist, um durch den Controller-Computer gesteuert zu werden.
Verfahren nach Anspruch 19, weiterhin umfassend das Erkennen, dass der eine der Node-Computer bereits durch den Controller gesteuert wird.
Verfahren nach Anspruch 19, weiterhin umfassend: das Erkennen, dass der eine der Node-Computer nicht durch den Controller-Computer gesteuert wird; und das Steuern des einen der Node-Computer.
Verfahren nach Anspruch 21, weiterhin umfassend das Hinzufügen von Information, die den einen der Node-Computer identifiziert, zu einem Speichergerät, das durch den Controller-Computer gepflegt (maintained) wird.
Verfahren nach einem der Ansprüche 19 bis 22, weiterhin umfassend das automatische Konfigurieren des einen der Node-Computer auf Basis des Empfangens der Ermittlungsinformation.
Verfahren nach einem der Ansprüche 10 bis 23, wobei das Speichern der Ergebnisse der Aufgabe das Sammeln der Ergebnisse in einem Speicher (130, 131, 132, 141, 152, 156, 302) umfasst.
Verfahren nach einem der Ansprüche 10 bis 24, wobei das Speichern der Ergebnisse der Aufgabe das Fortbestehen (persisting) der Ergebnisse umfasst.
Verfahren nach Anspruch 2 oder 3, wobei das Speichern des Sets ein Speichern des Set-Objekts in einem Schema umfasst, wobei das Schema konfiguriert ist, um eine Vielzahl von Node-Computern dazu zu befähigen, durch den Controller-Computer gesteuert zu werden, wobei das Schema enthält: eine Vielzahl von Geräteobjekten, wobei jedes Geräteobjekt einen der Node-Computer, die in der Lage sind, durch den Controller gesteuert zu werden, identifiziert; mindestens ein Set-Objekt, wobei jedes Set-Objekt eine Gruppe von mindestens einem Node-Computer, der durch eines der Geräteobjekte identifiziert ist, identifiziert; und ein Aufgabenobjekt, wobei das Aufgabenobjekt Daten spezifiziert, die einem Vorgang entsprechen, der durch jeden der über ein Set-Objekt zusammen gruppierten Node-Computer ausgeführt werden soll.
Verfahren nach Anspruch 26, wobei die Datenstruktur weiterhin ein Aufgaben-Log-Objekt umfasst, wobei das Aufgaben-Log-Objekt Information umfasst, die einem Ergebnis eines Aufgaben-Objekt-Vorgangs entspricht, der durch mindestens einen der in dem Set-Objekt identifizierten Node-Computer ausgeführt wird.
Verfahren nach Anspruch 26 oder 27, wobei das Set-Objekt eine Methode zum Hinzufügen eines Geräts zu dem Set enthält.
Verfahren nach einem der Ansprüche 26 bis 28, wobei das Set-Objekt eine Methode zum Entfernen eines Geräts aus dem Set enthält.
Verfahren nach einem der Ansprüche 26 bis 29, wobei das Set-Objekt eine Methode zum Laufenlassen einer Aufgabe auf dem Set enthält.
Verfahren nach einem der Ansprüche 26 bis 30, wobei das Geräte-Objekt Verknüpfungen (associations) mit anderen Objekten enthält.
Verfahren nach einem der Ansprüche 26 bis 31, wobei die Datenstruktur weiterhin ein Aufgaben-Aufruf- (invocation) Objekt umfasst, das erstellt wird, wenn die Aufgabe ausgeführt wird.
Verfahren nach einem der Ansprüche 26 bis 32, wobei das Schema weiterhin ein Alarm- (alerts) Objekt zum Kommunizieren von Information von einem der Node-Computer an den Controller-Computer umfasst.
System, das in einem Computernetzwerk (100, 171, 173) enthalten ist und umfasst: einen Controller-Computer (110, 180, 202); mindestens einen Node- (Knoten) Computer (110, 180, 204, 204₁ –204_n ); ein erstes Speichergerät (130, 131, 132, 141, 152, 156, 302), auf dem ein erstes computerausführbares Programm (135, 136, 145, 146, 185, 206, 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330) gespeichert ist, das dazu konfiguriert ist, mit dem Controller-Computer zu interagieren, um ein Set zu definieren, das eine Organisation des Computernetzwerks darstellt; ein zweites Speichergerät (130, 131, 132, 141, 152, 156, 302), auf dem ein zweites computerausführbares Programm (135, 136, 145, 146, 185, 206, 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330) gespeichert ist, das dazu konfiguriert ist, mit dem Controller-Computer zu interagieren, um mindestens einen der Node-Computer zu dem Set hinzuzufügen, wobei der hinzugefügte mindestens eine der Node-Computer durch den Controller-Computer gesteuert wird; und ein drittes Speichergerät (130, 131, 132, 141, 152, 156, 302), auf dem ein drittes computerausführbares Programm (135, 136, 145, 146, 185, 206, 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330) gespeichert ist, das dazu konfiguriert ist, mit dem Controller-Computer zu interagieren, um das Set zu speichern; wobei der Controller-Computer dazu konfiguriert ist, das Set zu benutzen, um jeden Node-Computer in dem Set zu steuern, dadurch gekennzeichnet, dass das Set nur auf dem Controller-Computer repräsentiert ist.
System nach Anspruch 34, wobei der Controller-Computer dazu konfiguriert ist, eine Auswahl zu empfangen, die mindestens einem der Node-Computer entspricht; wobei die in der Auswahl identifizierten Node-Computer Vermittlersoftware (agent software)(218, 218₁ –218_n , 312) enthalten, die verbunden ist, um mit Controller-Software (208, 306) auf dem Controller-Computer zu kommunizieren; und wobei das System weiterhin umfasst: eine durch den Controller-Computer gepflegte (maintained) Aufgabe (job), wobei die Aufgabe mindestens einem Vorgang (operation) entspricht, der auf der Auswahl durchgeführt werden soll; einen Transport (212, 214, 214₁ –214_n , 216), der dazu konfiguriert ist, eine Nachricht von der Controller-Software an die Vermittlersoftware der Node-Computer zu kommunizieren, die Daten enthält, die der Aufgabe entsprechen, wobei die Nachricht die Vermittlersoftware instruiert, die Aufgabe auszuführen, die Vermittlersoftware der Node-Computer die Aufgabe ausführt (608) und Ergebnisse an den Controller-Computer in Erwiderung auf den Empfang der Nachricht zurücksendet (614); und ein viertes Speichergerät (130, 131, 132, 141, 152, 156, 302) beim Controller-Computer, wobei der Controller-Computer die Ergebnisse von der Vermittlersoftware in dem vierten Speichergerät speichert.
System nach Anspruch 35, weiterhin umfassend eine Schemaschnittstelle (310), die dazu konfiguriert ist, Zugang zu Information in dem vierten Speichergerät bereitzustellen.
System nach Anspruch 35 oder 36, weiterhin umfassend eine Ausführungsmaschine (execution engine)(320) bei den Node-Computern, wobei die Vermittlersoftware mit der Ausführungsmaschine kommuniziert, um den mindestens einen Vorgang, der der Aufgabe entspricht, durchzuführen.
System nach Anspruch 37, wobei die Ausführungsmaschine eine Skriptmaschine (320) umfasst und wobei die Vermittlersoftware mit der Ausführungsmaschine kommuniziert, um ein Skript laufen zu lassen (run).
System nach Anspruch 37, wobei die Ausführungsmaschine Software umfasst, um ein Binärprogramm auszuführen, und wobei die Vermittlersoftware mit der Ausführungsmaschine kommuniziert, um das Binärprogramm laufen zu lassen.
System nach einem der Ansprüche 34 bis 39, weiterhin umfassend Software (135, 136, 145, 146, 185, 206, 206₁ –206_n , 208, 210, 218, 218₁ –218_n , 220, 220₁ –220_n , 306, 312, 320, 322, 330) auf den Node-Computern, die ein Set von mindestens einem Vorgang durchführt, der den Betrieb der Software beeinflusst (affecting) und durch den Controller angefordert wird.
System nach Anspruch 40, wobei das Set von mindestens einem Vorgang, der den Betrieb der Software beeinflusst, einen Neustartvorgang (reboot operation) umfasst.
System nach Anspruch 40 oder 41, wobei das Set von mindestens einem Vorgang der den Betrieb der Software beeinflusst, einen Aussetzungsvorgang (suspend operation) umfasst.
System nach einem der Ansprüche 40 bis 42, wobei das Set von mindestens einem Vorgang, der den Betrieb der Software beeinflusst, einen Vorgang des Herunterfahrens (shutdown operation) umfasst.
System nach einem der Ansprüche 34 bis 43, weiterhin umfassend einen Ermittlungslausch- (discovery listening) Prozess beim Controller-Computer, der Ermittlungsinformation (discovery information) detektiert, welche durch die Node-Computer auf dem Netzwerk bereitgestellt wird.
System nach Anspruch 44, wobei der Controller-Computer Software zum automatischen konfigurieren eines der Node-Computer, der die Ermittlungsinformation bereitstellt, enthält.
System nach Anspruch 44 oder 45, wobei jeder Node-Computer eine Ermittlungskomponente zum automatischen Bereitstellen der Ermittlungsinformation enthält.
System nach Anspruch 46, wobei jeder Node-Computer automatisch die Ermittlungsinformation in der Folge auf einen Neustart dieses Node-Computers bereitstellt.
System nach Anspruch 34, das dazu konfiguriert ist, das Verfahren nach einem der Ansprüche 2 bis 33 durchzuführen.