-
Die
Erfindung betrifft eine Vorrichtung und ein Verfahren, bei der/dem
in einem Rechnersystem Energiezustände einzelner Komponenten
mitgeteilt werden und damit koordinierte Maßnahmen zur
Energieeffizienzsteigerung erfolgen.
-
Aus
der Patentschrift
US7334138B2 ist
ein Verfahren und eine Vorrichtung zur dynamischen Verwaltung des
Energieverbrauchs peripherer Einheiten bekannt, bei dem/der mit
Hilfe eines Hintergrundprogramms (daemon program) und einer Ruhezeit-Tabelle
(idle time table) nicht benötigte Einheiten feststellt
und Energiesparsignale an das Betriebssystem gesandt werden, damit
dieses daraufhin die entsprechenden Einheiten abschalten kann. Durch
diese, bei Web-basierten Anwendungen gerne auf http-Ebene durchgeführten,
meist periodischen Abfragen (Polling), kommen die Anwendungsprogramme
aber nicht zur Ruhe.
-
Aus
der Patentanmeldung
US5560022A1 ist ein
Power Management Coordinator System und eine entsprechende Schnittstelle
bekannt, bei dem es generell darum geht, dass einzelne Komponenten unterschiedliche
Energieverbrauchszustände (Power States) haben und diese
beschreiben und mitteilen können. Damit kann ein Power
Manager ein System allgemein zwischen Performance und Energie-Effizienz
ausrichten.
-
Verteilte
Systeme erstrecken sich immer öfter über Firmengrenzen
hinweg, z. B. für Software as a Service, System Management,
Remote Service, Business Process Mngt., und müssen damit
meist mehrere Firewalls passieren. Das Problem hierbei ist, dass
der Verwaltungsaufwand zur Verschaltung von VPN- oder SSH-Tunnel
mit den Firewall Administratoren zeit- und kostenintensiv bzw. langwierig
ist und deshalb soweit wie möglich gemieden wird.
-
Ein
Tunnel (Tunneling) bezeichnet hier den Gebrauch des Kommunikationsprotokolls
eines Netzwerkdienstes als Transportmittel für Daten, die nicht
zu diesem Dienst gehören. Auf diese Weise lassen sich,
z. B. in einem SSH-Tunnel, unsichere Netzwerkprotokolle eingebettet
in einem gesicherten und verschlüsselten Netzwerkprotokoll
abhör- und manipulationssicher transportieren. Tunnel,
z. B. VPN-Tunnel, können auch zur Einbindung von Geräten
eines benachbarten Netzes an das eigene Netz dienen, ohne dass die
Netzwerke zueinander kompatibel sein müssen.
-
Deshalb
setzen neuere Produkte auf http/https basierende Protokolle, teilweise
wird darüber hinaus auch noch auf Webservices aufgesetzt.
Entscheidend ist, dass ausschließlich über clientseitig ausstrahlenden
Verkehr (Outbound Traffic) mittels Polling eine 2-Wege Kommunikation über
eine zusätzliche Gatewayserver Komponente bereitgestellt wird.
Das bedeutet, der Client-Rechner muss permanent einen Polling-Zyklus
durchführen um Anfragen des Server-Rechners erkennen zu
können. Hierfür werden verschlimmernd noch „Reverse-Proxies” basierend
auf dieser Technik eingesetzt um herkömmliche IP-basierte
Anwendungen durch Firewalls zu schleusen. Dazu kommt noch der Trend,
dass immer mehr Anwendungen per https auf Updates prüfen oder
diverse Statusinformation, z. B. Präsenz, mitteilen. Um
gleichzeitig den Durchsatz und die Netzwerkbelastung abzustimmen,
gibt es teilweise recht ausgeklügelte Mechanismen zur Steuerung
der Polling Intervalle einzelner Anwendungen.
-
Da
sich unterschiedliche Applikationen nicht gegenseitig kennen, nutzen
sie die Power Management Fähigkeiten eines Betriebssystems
jedoch in der Regel nicht wirklich effizient.
-
Die
der Erfindung zu Grunde liegende Aufgabe besteht nun darin ein Verfahren
und Vorrichtung zur Energieeffizienzsteigerung in einem Rechnersystem,
vor allem in einem verteilten Rechnersystem, derart anzugeben, dass
die oben genannten Nachteile möglichst vermieden werden.
-
Diese
Aufgabe wird hinsichtlich des Verfahrens durch die Merkmale des
Patentanspruchs 1 und hinsichtlich der Vorrichtung durch die Merkmale
des Patentanspruchs 5 erfindungsgemäß gelöst.
Die weiteren Ansprüche betreffen vorteilhafte Ausgestaltungen
des erfindungsgemäßen Verfahrens.
-
Die
Erfindung liegt im Wesentlichen darin, dass Polling Anwendungen
die Kontrolle der Pollingzyklen an eine externe Komponente bzw.
eine zusätzlichen Betriebssystemkomponente abgeben, um eine
systemweite Optimierung mit möglichst langen Idle-Zeiten
zwischen Intervallen (Idleness Exploitation) unter Berücksichtigung
von dynamischen Power Management der Betriebssystemebene für
das Gesamtsystem erreichen zu können. Von besonderem Vorteil
ist hier, dass die Erfindung sowohl für bestehende Altanwendungen
bzw. Legacy Anwendungen, sowie für neue Anwendungen geeignet
ist. Zusätzlich wurde ein Verfahren beschrieben, welches
erlaubt Legacy Anwendungen nach bestimmten Kriterien als Polling
Application zu klassifizieren und automatisch mit Default Policies
in die Gesamtoptimierung mit einzubeziehen.
-
Nachfolgend
wird die Erfindung anhand der in der Zeichnung dargestellten Ausführungsbeispiele näher
erläutert. Dabei zeigt
-
1 eine
Darstellung eines Polling Coordinators als eine Zusatzkomponente
für ein Betriebssystem mit Applikationsschnittstelle für
neue zu entwickelnde Anwendungen,
-
2 eine
einfache Darstellung der Applikations- und Betriebssystemschnittstellen
des Polling Coordinators,
-
3 eine
Architektur des Polling Coordinators und dessen Integration in ein
Betriebssystem und
-
4 eine
Darstellung zur Erläuterung des Pollingverhaltens ohne
und mit Polling Coordinator.
-
Eine
bestimmte Kategorie von Web-Anwendungen weist Webservices als Client
und eine Kommunikation durch „http request-response”-Paare
auf. Da diese Kommunikation nicht mit dem OS Power Management abgestimmt
ist, kann der Rechner nicht in einen temporären Ruhezustand
oder Idle-Mode schalten, bzw. bei längeren Polling Intervallen „wacht der
Rechner nicht mehr auf”. Beim erfindungsgemäßen
Verfahren oder bei der erfindungsgemäßen Vorrichtung
ist jedoch ein sogenannter ”Polling Coordinator” vorhanden,
bei dem sich solche Anwendungen registrieren, ihre Polling Anforderungen
mitteilen, und der ihnen dann die nächsten Polling Zeitpunkte mitteilt
und für die optimierten Idle-Slots das Rechnersystem samt
externen Komponenten in einen Idle-Mode schaltet, oder einen vorhandenen
Betriebsystem Power Manager damit beauftragt. So eine Komponente
kann bspw. in die Java VM® oder
in die .net Runtime Library®, oder
in Betriebssysteme eingebaut werden.
-
Der
Polling Coordinator nimmt Power Management Policies der einzelnen
Polling Anwendungen, also bei der Koordinierung zu berücksichtigende Regeln
oder Bedingungen, entgegen und richtet die Polling-Wartezyklen derart
aus, dass möglichst lange Ruhezeiten bzw. Idle-Zeiten für
die Abschaltung von Systemkomponenten entstehen. Die Anwendungen beschreiben
mit diversen Polling Management Policies, wie lange Polling Intervalle
maximal sein dürfen und in wie weit sie maximal um den
gewünschten Pollingzeitpunkt verschoben werden dürfen.
-
1 zeigt
ein Ausführungsbeispiel einer erfindungsgemäßen
Vorrichtung, also eines Polling Coordinators P, quasi als eine Zusatzkomponente
für ein Betriebssystem OS die einerseits eine Applikationsschnittstelle
IN für neue zu entwickelnde Anwendungen PAN zur Verfügung
stellt aber auch eine Koordination von bestehenden Altanwendungen
ermöglicht. Für bestehende Altanwendungen PA1,
PA2 greift der Polling Coordinator in das Betriebssystem Scheduling
intern über I1, I2 ein, gesteuert durch ein zusätzliches
Konfigurationsfile, welches ihm die Polling Application Kandidaten
bzw. die zugehörigen Pol ling Management Policies mitteilt.
Der Polling Coordinator bildet eine Verbindung zwischen Betriebssystem
und Polling Anwendung und wird bei Neuentwicklungen per Bibliothek
von der Anwendung direkt kontaktiert, bei Altanwendungen (legacy
applications) hingegen holt er sich die notwendige Management-Information
vom Betriebssystem-Scheduler. Typischerweise wird der Polling Coordinator
als „Service” einer Windows Plattform oder als „Daemon” einer
Unix Plattform laufen.
-
Neue
Anwendungen die Polling verwenden, können die zusätzliche
Schnittstelle IN implementieren um ohne externe Konfiguration auszukommen. während
der Startphase registrieren sich die Polling Anwendungen hierzu
beim Polling Coordinator P. Dynamisch können die Anwendungen
für sich Policies zur Bestimmung des nächsten
Polling Zeitpunktes oder der nächsten Polling Zeitpunkte
einstellen. Sollte zu einem außergewöhnlichen
Zeitpunkt ein Polling Request notwendig werden, kann die Anwendung das
mit einem speziellen Polling Request gesondert mitteilen. Der Polling
Coordinator P versucht dann intern die einzelnen Polling Requests
der registrierten Anwendungen gemäß deren Randbedingen
so anzuordnen, dass sich möglichst lange Idle-Zeiten ergeben.
Mittels eines Polling Triggers bekommen die einzelnen Anwendungen
dann die Aufforderung ihren Polling Zyklus durchzuführen.
-
2 zeigt
eine erfindungsgemäße Vorrichtung, also einen
entsprechenden Polling Coordinator P, mit seinen wichtigsten Ein-
und Ausgängen, wobei dieser im Bereich zwischen dem Betriebssystem
OS und einer Anwendungsschnittstellenebene AI angesiedelt ist. Aus
der Ebene AI erhält der Polling Coordinator P ein „Subscribe/Unsubscribe”-Signal
SUB, ein „Set Policies”-Signal SP und ein „Polling
Request”-Signal REQ. Betriebssystemseitig besteht ein Interface
IPM zum Power Management PM des Betriebssystems, eine Verbindung
DPA zum Betriebssystemscheduler S zur Ermittlung von Polling Anwendungen
und deren schlafenden Prozessen oder Threads sowie ein „Polling
Trigger Manipulation”-Signal TM zur Beeinflussung eines
Sleep Timers ST im Betriebssystem.
-
3 stellt
die Architektur der erfindungsgemäßen Vorrichtung
und seine Integration in das Betriebssystem noch etwas detaillierter
dar. Der Polling Coordinator P erhält, für den
Fall einer bestehenden Altanwendung (legacy application), aus den
gestrichelt dargestellten Betriebssystemkomponenten Anwendungsladeprogramm
(Application Loader) SAL (zur Herstellung der Beziehung: Anwendung – Prozess-ID),
von einer Systemtabelle SPA gerade blockierte Prozesse oder Threads
(als Trigger zur Optimierung) und von einer weiteren Systemtabelle
SV „wait timer”-Werte bzw. „sleep”-Werte
zur Implementierung entsprechender Schlafzustände (als
Input und Output zur Optimierung).
-
Der
Polling Coordinator P greift sowohl bei Neuanwendungen als auch
bei bestehenden Altanwendungen auf ein Konfigurationsfile für
Polling Application Management zu. Das Konfigurationsfile enthält
Applikationsnamen IDs und die Polling Management-Regeln (Polling
Management Policies) MPIs.
-
3 zeigt
auch wie die Implementierung des Polling Coordinator-Schnittstellenadapters
für neue Anwendungen sich in das Gesamtkonzept einfügt.
Für die Subscribe/Unsubscribe Funktion SUB ist keine Information
vom Application Loader SAL notwendig und somit auch keine zusätzliche
Konfiguration erforderlich bzw. Policy Funktion SP werden in eine
mit erlaubten Polling Anwendungen (Polling Application White List)
PAWL von einer Anwendungsprogramm-Schnittstelle API entsprechend
eingefügt. Damit entstehen die Randbedingungen für
die Optimierungsfunktion in Summe zur Verfügung. Dedizierte
Polling Request Sleeps von entsprechenden Prozessen oder Threads
werden direkt mitgeteilt, wodurch eine entsprechende Suche entfällt.
-
Optional,
ist in 3 auch ein strichpunktiert dargestellter Automatischer
Polling Application Detector APAD vorhanden, welcher bei bestehenden Altanwendungen
selbstständig Polling Application Kandidaten identifiziert.
-
Diese
Komponente kennt die blockierten Prozesse (Threads) und schaut gleichzeitig
auf die zugehörigen Waittimer Zeiten, wenn vorhanden. Wenn
eine Anwendung typischerweise des Öfteren lange Wartezeiten
hinterlegt, ist sie ein potentieller Kandidat für eine
Polling Application Optimierung.
-
Optional
kann mit dem Detector APAD zusätzlich auch der Netzwerkverkehr
nach dem „bereit”-Werden durch ein entsprechendes
Interface M betrachtet werden, um z. B. noch exakter auf eine „Network
Polling Application” schließen zu können. Wenn
die Anwendung sich z. B. nach kurzer Aktivität sofort wieder
in den Schlafzustand begibt.
-
Optional
kann zusätzlich der Detector APAD mit einer Blacklist B
von Anwendungen konfiguriert werden. In der Blacklist B gelistete
Anwendungen werden nie Kandidaten als Kandidaten für den
Optimierungsprozess identifiziert. Kandidaten für den Optmierungsprozess
werden dann automatisch in die Polling Application Whitelist samt
voreingestellten Regeln bzw. default Policies eingefügt
und werden somit zu gesamten Optimierung automatisch miteinbezogen.
-
Der
interne Polling Intervall Optimierer des Polling Coordinators P
ist im Prinzip ein Scheduler und arbeitet nach ähnlichen
Algorithmen wie sie in einem heutigen Echtzeitbetriebssystem-Scheduler zum
Einsatz kommen. In dem Fall dass sich die Polling Request so anordnen
lassen, dass größere Idle-Zeiten entstehen, teilt
der Polling Coordinator diese Zeiten dem Betriebssystem sofort mit,
damit das dynamische Power Management einen Processor Step-Down
oder Idle-Sate Switch durchführen kann, bzw. einen Festplatten
spin-down. Bei längern Idle-Phasen ist sogar ein tiefer
Standby-Zustand mit vordefiniertem Wake-Up möglich.
-
Polling
Anwendungen sind meist dadurch gekennzeichnet, dass sie längere
Zeit im Ruhezustand also „idle” sind, nach einem
bestimmten Intervall wieder aktiv werden und dann Input-Information verarbeiten,
und wieder den Idle-Zustand anneh men. Die Idle-Zeit wird programmtechnisch
in der Regel durch Timerfunktionen oder Sleep Funktionen abgebildet.
return value sleep (idle time). Der Prozess-Scheduler des Betriebssystems
versetzt dadurch den Prozess in den Zustand blockiert und setzt einen
Timerwert im Hintergrund in einer internen Timertabelle SV. Ist
der Timerwert abgelaufen, versetzt eine Timerbetriebssystemfunktion
den Prozess wieder in den Zustand rechenbereit und er kommt wieder zur
Ausführung. Genau bei diesen beiden Tabellen „blockierte
Prozesse” (Threads) SPA bzw. zugeordnete „Wartetimerwerte
Tabelle” SV setzt die Anwendungsverwaltung des Polling
Coordinators P im Falle bestehender Polling-Altanwendungen (legacy
polling applications) ein.
-
Wird
eine beim Polling Coordinator P registrierte Polling Application
gestartet, meldet der Application Loader SAL die zugehörigen
Process-IDs oder Thread-IDs and den Polling Coordinator P. Die Intergration
soll derart sein, dass auch zur Laufzeit dynamisch gestartete Threads
sichtbar werden. Diese Process IDs oder Thread IDs werden dann zyklisch vom
Polling Coordinator P in den „blockiert Process Queues” SPA
des Schedulers gesucht in denen auf Ereignisse wartende Prozesse
oder Threads aufgeführt sind. Gibt es eine Übereinstimmung,
werden die hinterlegten Wartetimer-Werte betrachtet, falls solche
vorhanden sind. Liegen die Wartetimer Werte über der Schwelle,
sind sie Kandidaten für die Polling Intervall Optimierung.
Diese geschieht dann einfach durch eine Optimierung der Timerwerte
und einem Override der einzelnen Timervalues bei dem alle Polling
Applications im Wartezustand, gemäß ihrer Policies
dynamisch angepasst werden.
-
4 zeigt
das durch einen Polling Coordinator erreichbare Verhalten. Unkontrolliert
durchgeführte Pollingzyklen UPA von einzelnen Anwendungen
erlauben dem Betriebssystem keine effiziente Abschaltung von Systemkomponenten,
wie dies bei koordiniert durchgeführten Pollingzyklen CPA
der Fall ist.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - US 7334138
B2 [0002]
- - US 5560022 A1 [0003]