Load Balancing

Definition

Load Balancing (Lastverteilung) ist ein Mechanismus, um Aufgaben von einem Server auf einen anderen Server innerhalb eines verteilten Systems (Cluster) zu verteilen. Ziel ist dabei die Arbeitslast auf (möglichst) alle Knoten eines Systems gleichmäßig zu verteilen. Load Balancing lässt sich einordnen in den Gesamtkontext von Traffic Control (Datenverkehrskontrollsysteme).

Alle Anfragen an einen Server laufen dabei über einen Load Balancer, der die Anfragen auf die Server verteilt. Dabei gibt es verschiedene Methoden. Ziel ist es, eine möglichst performante Server-Infrastruktur zu gewährleisten und die Überlastung eines Servers zu verhindern, um so eine höhere Verfügbarkeit zu gewährleisten. Je nach Vorgehensweise vereinfacht ein Load Balancer die Skalierbarkeit der verfügbaren Ressourcen und die Kommunikation zwischen den Servern. Trotzdem sollte der Mechanismus auch ein Mindestmaß an Fehlertoleranz aufweisen, sodass das System beim Ausfall einiger Server nicht arbeitsunfähig ist.
Load-Balancing-Lösungen können auf Software und/ oder Hardware Lösungen beruhen. Unterschieden wird außerdem in Shared Load Balancing und Dedicated Load Balancing. Load Balancing kann auf den gesamten Traffic angewandt werden, egal ob HTTP, TCP/SSL oder UDP. Load Balancing wird bei vielbesuchten Webseiten, Domain Name System Servern, Datenbanken, großen Internet Relay Chat Netzwerken und weiteren angewendet.

Hardware Load Balancing

Shared Load Balancing

Eine physische Ressource wir von mehreren Nutzern verwendet, logisch arbeiten sie jedoch getrennt voneinander und können auch ihre eigenen Compliance-Regeln verfolgen.

Dedicated Load Balancing

Jede Hardware Ressource wird nur von einem Nutzer verwendet.

Software Load Balancing

Methoden

Load Balancing Methoden, auch Scheduling Algorithmen genannt, werden genutzt, um die Anfragen der Clients zu den entsprechenden Back-End Servern mit freier Kapazität weiterzuleiten. Es gibt einfache (statische) und kompliziertere (dynamische) Methoden. Dynamische Methoden beziehen weitere Faktoren in die Bewertung bei der Entscheidung mit ein, an welchen Server die Anfrage weitergeleitet wird. Dadurch können sie aktuelle Parameter berücksichtigen.
Die Tabelle weiter unten gibt eine kurze Übersicht, wie Load Balancing Verfahren klassifiziert werden können. Es kann auch eine Unterscheidung bezüglich der Granularität vorgenommen werden, darauf möchte ich hier aber nicht weiter eingehen.

Statische Methoden beachten nicht die aktuelle Auslastung des Serverclusters und freien Kapazitäten eines Servers. Daher wird vorheriges Wissen über den globalen Status des Clusters, die Ausstattung bezüglich Ressourcen für die Jobverarbeitung und Kommunikationszeit vorausgesetzt.

Statische Methoden lassen sich außerdem allgemein unterteilen in einen deterministischen (reproduzierbaren) und einen probabilistischen (wahrscheinlichkeitstheoretischen) Ansatz. Bei dem deterministischen Ansatz gibt ein Knoten (Server) zusätzliche Aufgaben immer an einen bestimmten Knoten weiter. Bei einem probablistischen Ansatz schickt ein Knoten zusätzliche Aufgaben an unterschiedliche Knoten weiter mit unterschiedlichen Wahrscheinlichkeiten bezüglich der Abarbeitung der Aufgabe.

Statische Methoden haben den Nachteil, dass sie die Performanz im Gesamten beeinträchtigen, da sie nicht auf unterschiedliche Lasten reagieren können bzw. diese auch nicht vorhergesehen werden können.

Konkrete Konzepte

Präfixsumme

Die Präfixsumme ist eine Methode, um unabhängig voneinander und spaltbare Aufgaben, deren jeweilige Ausführungszeit bekannt ist, mit einem einfachen Algorithmus auf die Prozessoren zu verteilen, sodass jeder Prozessor den gleichen Rechenaufwand hat.

Die Präfix-Summe ist ein Algorithmus der in einer logarithmischen Zeit der Anzahl der Prozessoren berechnen kann, unter welchen die Aufgaben aufgeteilt werden.

Wenn sich die Aufgaben jedoch nicht unterteilen lassen, also eine atomare Einheit bilden, obwohl die Optimierung der Aufgabenzuweisung ein schwieriges Problem darstellt, ist es trotzdem möglich, sich an eine relativ faire Verteilung der Aufgaben anzunähern.

Meistens ist die Ausführungszeit einer Aufgabe unbekannt, und es gibt nur grobe Näherungswerte. Dieser Algorithmus ist zwar besonders effizient, aber für viele Szenarien nicht praktikabel.

Round Robin

Die Methode besteht aus einem einfachen Algorithmus, bei dem die Ausführungszeit der Aufgabe irrelevant bzw. nicht bekannt ist. Die erste Anfrage wird dabei an den ersten Server geschickt, die zweite an den zweiten Server und so weiter. Wenn der letzte Server eine Aufgabe zugeteilt bekommen hat, wird wieder bei dem ersten Server begonnen.

Diese Methode kann auch gewichtet werden und dadurch effizienter, in dem die Leistungsfähigkeit einzelner Server berücksichtigt werden. Dabei werden dem leistungsfähigsten Server die meisten Aufgaben zugeteilt.

Randomized static

Der Methode des willkürlichen statischen Load Balancing verteilt die Aufgaben zufällig auf die Server. Besonders effizient ist die Methode, wenn die Anzahl an Aufgaben vorher bekannt ist und die Permutation bereits berechnet werden kann. Dies erspart Kommunikation zwischen den Servern und macht die Methode performanter.

Je mehr Aufgaben zu verteilen sind, desto ungeeigneter ist die Methode im Hinblick auf Performanz.

Pseudo-willkürliche Methode der Anordnung/ Verteilung der Aufgaben, die allen Servern bekannt ist, kann auch bei unbekannter Anzahl von Aufgaben benutzt werden, um Kommunikation auf ein Minimum zu reduzieren.

Dynamische Methoden berücksichtigen bei der Lastverteilung die aktuelle Last auf den Servern und ihre freie Kapazität, weitere Aufgaben zu bearbeiten. Dynamische Methoden sind in der Lage, Aufgaben von überlasteten Servern auf solche mit noch verfügbarere Arbeitskapazität verlagern, um eine schnelle Abarbeitung zu ermöglichen. Dies ermöglicht eine bessere Performanz des gesamten Systems.

Funktionsweise

Kontrollmechanismen, die sich aus der dynamischen Lastverteilung ableiten, beeinflussen die Leistungsfähigkeit des Systems in zwei Bereichen: den Algorithmus eingeführten Overhead und die Fehlertoleranz. Ein Mechanismus der ein hohes Maß an Kommunikation erfordert ist nicht wünschenswert, ebenso wie ein Mechanismus der keine Vorsichtsmaßnahmen vorsieht, sobald ein Teil des Systems ausfällt.

Kontrollmechanismen werden unterschieden in zwei Konzepte, solche die die Verantwortung der Lastverteilung auf alle Knoten des Systems aufteilen und solche, bei denen die Verantwortung nicht verteilt wird, sondern bei einzelnen Knoten liegt. Bei einem Konzept mit verteilter Verantwortung ist mehr Kommunikation notwendig, da sich alle Server untereinander abstimmen müssen. Kommt es jedoch zu einem Ausfall einiger Knoten, kann dies bei der Lastverteilung berücksichtigt werden und beeinträchtigt nur teilweise die Performanz.
Das Konzept der Verteilten Verantwortung unterscheidet sich wiederum in solche mit einer kooperativen und nicht-kooperativen Wechselbeziehung zwischen Knoten. Bei einer kooperativen Wechselbeziehung zwischen Knoten arbeiten die Server zusammen, um ein gemeinsames Ziel zu erreichen. Bei einer nicht-kooperativen Wechselbeziehung arbeitet jeder Server für unabhängig und für lokale Ziele.

Bei dem Konzept einer nicht-verteilten Verantwortung des Kontrollmechanismus wird die Verantwortung von einem oder mehreren Knoten übernommen, aber keinesfalls von allen. Dabei wird wiederum unterschieden in semi-verteilte und zentralisierte Form.
Bei der zentralisierten Form des Konzepts ist für das gesamte Servercluster genau ein Knoten für die Kontrolle der Lastverteilung verantwortlich, auch Zentraler Knoten genannt. Alle anderen Knoten interagieren lediglich mit diesem zentralen Knoten, aber nicht untereinander. Das reduziert die Kommunikation auf ein Minimum und das System hoch performant. Fällt der zentrale Knoten allerdings aus, ist das gesamte System nicht mehr arbeitsfähig. Außerdem birgt dieses Schema die Gefahr, dass der zentrale Knoten zu einer Engpassstelle des Systems wird und so die Leistungsfähigkeit begrenzt.
Bei der semi-verteilten Form bilden die Knoten einzelne Gruppen, die jeweils einen zentralen Knoten haben. Die zentralen Knoten aller Gruppen kooperieren wiederum und sorgen so für eine Lastverteilung über das gesamte System. Der Ansatz bietet den Vorteil reduzierten Aufwands in der Kommunikation, gefährdet aber nicht die Arbeitsfähigkeit des gesamten Systems, falls ein Knoten ausfällt.

Konkrete Konzepte

“Master-Worker” Schema

Diese Methode basiert auf einem einfachen dynamischen Algorithmus, welcher durch Rollenverteilung funktioniert. Ein Server in der Rolle des „Masters“ empfängt Anfragen seiner „Workers“ und teilt ihnen dementsprechend Aufgaben zu. Wenn keine Aufgaben mehr zu verteilen sind, informiert der „Master“ seine „Worker“ darüber, sodass keine Anfragen mehr gesendet werden.

Vorteile dieser Methode sind, dass die Last der Aufgaben sehr fair verteilt werden und die Performanz des Systems hoch. Allerdings Ist der Aufwand der für die Kommunikation zwischen den Servern betrieben werden muss sehr hoch und führt insbesondere bei einer großen Anzahl an zu verteilenden Aufgaben zu Einbußen in der Leistungsfähigkeit des Systems, es ist daher schlecht skalierbar. Außerdem muss jede Aufgabe vom Master verteilt werden, dadurch wird der Mast zu einem Nadelöhr und bei hoher Last kann es hier zu Stau kommen.
Abhilfe kann durch eine Task List geschaffen werden, auf die verschiedenen Prozessoren zugreifen können.

“Work-Stealing” Schema

Jeder Prozessor bekommt willkürlich eine bestimmte Anzahl an Aufgaben zugewiesen. Inaktiven Prozessoren dürfen jedoch Arbeit von aktiven oder überlasteten Prozessoren „stehlen“, daher der Name der Methode. Es gibt verschiedene Versionen dieser Methode, die sich unterscheiden in der Art und Weise des Austauschs zwischen den Prozessoren und wie die Aufgaben verteilt werden. Diese Methode birgt allerdings das Risiko, dass der Aufwand der zu betreiben ist, um die Kommunikation zwischen den Prozessoren zu gestalten, den des eigentlichen Lösens der Aufgaben überschreitet.

Falls Aufgaben nicht aufgeteilt werden können, da sie eine atomare Einheit bilden, gibt es weitere zwei Varianten. Variante eins stellt den Prozessoren mit der höchsten Last, die Kapazität der am geringsten ausgelasteten Prozessoren zur Verfügung. In Variante zwei besteht darin, dass die am stärksten belasteten Einheiten, die die ihnen zugewiesene Arbeitslast verringern möchten, um Unterstützung bitten.

„Tree-Shaped computation” als Prinzip für nicht mehr zu herunterbrechende atomare Aufgaben

“Least-Connection” Schema

Es ist ein dynamisches Verfahren für die Beurteilung der Auslastung der Server. Eine neue Anfrage wird dem Server zugewiesen, der zu dem Zeitpunkt die wenigsten Verbindungen offen hat.

Least-Response-Time

Die Methode ist ebenfalls eine dynamische Vorgehensweise und leitet sich aus dem Least-Connection-Verfahren ab. Es zählt auch zu den Weight-Distribution Verfahren, da die Leistungsfähigkeit der Server mit in die Entscheidung einbezogen wird. Eine neue Anfrage wird dem Server zugewiesen, der die kürzeste Antwortzeit aufweist.

Eigenschaft	Schema	Beschreibung
Klassifizierung	Statisch	Ein neuer Datenfluss wird einem der verfügbaren Pfade anhand einiger fester Kriterien zugewiesen, z.B. durch Angaben in der Kopfzeile der Pakete. Dieser Ansatz ist einfach, aber unflexibel. Denn wenn bspw. zwei durchsatzorientierte Flüsse dem gleichen Pfad zugeordnet sind, können sie später nicht auf andere, weniger genutzte Pfade verschoben werden.
	Dynamisch (reaktiv)	Datenflüsse können über jeden der verfügbaren Pfade entsprechend der verfügbaren Bandbreite bewegt werden. Diese Methode bietet eine bessere Leistung im Allgemeinen, führt aber zu erhöhter Komplexität bezüglich der Messung von Verbindungsauslastungen, der Berücksichtigung von Strömen und dem entsprechend der besten Zuweisungen des Task.
	Dynamisch (proaktiv)	Nachdem ein Task nach einigen Kriterien einem der verfügbaren Pfade zugeordnet wurde, bleibt seine Zuordnung bestehen behoben. Die anfängliche Zuweisung wird entsprechend den Netzwerkbedingungen wie der verfügbaren Bandbreite durchgeführt. Diese Ansatz liegt in Bezug auf den Implementierungsaufwand, Flexibilität und Leistungsfähigkeit zwischen den beiden vorgenannten Aufgaben.
Granularität	Pro Paket	Am feinsten granulierter Lastausgleich (Load Balancing), kann aber zu hohen Nachjustierungen führen.
	Pro Flow	Gröberer Lastausgleich, aber minimale Umordnung
	Pro Flowlet	Die Größe eines Flowlets ändert sich dynamisch entsprechend der unterschiedlichen Latenzzeiten der Kandidatenpfade. Bei hohen Raten und/oder hoher Latenzdifferenz zwischen den verfügbaren Pfaden kann ein Flowlet signifikant groß werden. Dies kann sowohl zu einem fein- als auch zu einem grobkörnigen Lastausgleich führen (er liegt immer irgendwo zwischen pro Paket und pro Durchfluss). Flowlets haben sich als effektiv für den Lastausgleich über asymmetrische (d.h. mit unterschiedlichen verfügbare Bandbreite). Als Nachteil können Flowlets eine Umordnung kleiner Flüsse verursachen und deren Fertigstellungszeiten.
	Pro Flowcell	Eine Flowcell hat eine feste Größe, (ca. zehn Pakete). Die Verwendung von Flowcells vereinfacht den Lastausgleich im Vergleich zu Flowlets (keine Notwendigkeit, Pfad-Latenzen sorgfältig zu messen und entsprechend zu planen) und reduziert mögliche Umstrukturierung kleiner Ströme. Die Umordnung für größere Datenströme kann sich erheblich steigern, die dann in kleinere Flowcells herunter gebrochen werden.

Load Balancing in der Anwendung

Round – Robin DNS

Für die Methode wird keine spezielle Software oder Hardware benötigt. Mehrere IP-Adressen werden einer Single Domain zugeordnet. Anschließend wird den Clients nach dem Round-Robin-Prinzip eine dieser IP-Adressen zugewiesen. Die Zuweisung erfolgt hierbei in einem kurzen, begrenzten Zeitrahmen, damit die IP-Adresse wieder verwendet werden kann, sobald eine neue Anfrage eines anderen Clients kommt, nachdem der vorherige seine Session verlassen hat. Allerdings kann es bei dieser Methode zu Caching Problemen kommen, besonders bei großen DNS Caching-Servern, die die Verteilung verzerren. Bei Webservern besteht außerdem das Problem, dass wenn einer der Server unerwartet ausfällt, die meisten Webbrowser nicht automatisch einen anderen Server aus der Liste wählen und erneut versuchen eine Verbindung aufzubauen. Daher weist die Methode in diesem Bezug eine geringe Fehlertoleranz.

DNS Delegation

Diese Methode des Load Balancing funktioniert besonders gut, wenn die einzelnen Server geographisch verteilt sind. Es gibt eine Haupt-Domain über die die Webseite aufgerufen wird. Gleichzeitig gibt es aber mehrere Sub-Domains, welche die einzelnen Server ansteuern. Je nach Standort, wird die Anfrage über die entsprechende Sub-Domain weitergeleitet zum Server. Falls ein Server mal ausfällt, können die Anfragen eventuell von anderen Servern aufgefangen werden, auch wenn es die Performance des gesamten Konstruktes verschlechtert, da die Anfrage u. U. nicht mehr von dem geographisch günstigstem, sondern verfügbarem Server beantwortet wird.

Client-seitiges Load Balancing

Dabei wird eine Liste mit allen IP-Adressen über ein DNS an den Client gesendet, der willkürlich eine der IP-Adressen für eine Verbindung auswählt. Allerdings beruht dies auf der Annahme, dass alle Clients eine ähnliche Last erzeugen, um eine möglichst ausgeglichene Verteilung auf die Server zu gewährleisten. S.g. „Smart clients“ sind auch in der Lage zu erkennen, dass der ausgewählte Server ausgefallen ist und verbinden sich dann willkürlich mit einem anderen. Dies wird auch als Fehlertoleranz seitens des Clients bezeichnet.

Sever – seitiges Load Balancing

Server-seitiges Load Balancing wird meistens durch ein Software-Programm ermöglicht. Dieses hört ständig auf einem Port zu, an den externe Clients, die sich mit dem Server verbinden wollen, eine Anfrage schicken. Der Load Balancer leitet dann die Anfrage an einen der zur Verfügung stehenden Server weiter, welcher an den Load Balancer berichtet. So ist immer ein Load Balancer bzw. eine Tür zwischen dem Client und dem Backend-Server eingebaut, denn Client und Server kommunizieren nie direkt, sondern nur über den Load Balancer. Dies hat auch Vorteile für die Sicherheit der Architektur und erschwert Attacken auf die Server.

Load Balancer werden so konstruiert, dass sie in Paaren arbeiten und auf eine hohe Verfügbarkeit ausgelegt sind, sodass sie nicht zu einem Nadelöhr werden.

Persistenz – Problem

Bei der Anwendung von Load Balancern kann es zu einem Problem bei der persistenten Datenhaltung kommen, wenn Nutzerdaten über mehrere Anfragen des Clients innerhalb einer User Session erhalten bleiben sollen. Dies ist natürlich nur möglich, wenn die Daten zwischengespeichert werden, um anschließend durch den nächsten Backend-Server neu berechnet zu werden oder durch die Speicherung in einer gemeinsamen Datenbank auf die alle Server eines Clusters zugreifen können.

Wenn die Daten lokal auf den Servern, die gerade die entsprechende Anfrage bearbeiten, zwischengespeichert wird, führt das zur Reduktion der Leistungsfähigkeit. Deshalb wird meist eine gemeinsame Datenbank oder einer in-memory Session Datenbank als Lösung bevorzugt.

Eine in-memory- Session Datenbank kann erzeugt werden, in dem alle Anfragen eines Clients innerhalb einer User Session an denselben Backend-Server weitergeleitet werden. Die Zuweisung kann dabei abhängig von Nutzername, IP-Adresse des Clients oder willkürlich erfolgen. Falls die Zuweisung willkürlich erfolgt, muss der Load Balancer die Zuordnung zusätzlich in einer Tabelle abspeichern, um weitere Anfragen desselben Clients an denselben Backend-Server weiterleiten zu können. Nach einer Timeout-Periode werden die Einträge in der Tabelle wieder gelöscht, um Speicherplatz für neue User Sessions zur Verfügung zu stellen. Eine in-memory Session Datenbank gewährleistet eine persistente Datenhaltung ohne nennenswerte Einbußen der Performanz bei normaler Auslastung.

Falls jedoch der spezifische Backend-Server während einer User Session abstürzt, sind alle Daten verloren.

Eine gemeinsame Datenbank auf die alle Server zugreifen können, speichert die Daten der ebenfalls pro User Session. Allerdings führt die Nutzung einer gemeinsamen Datenbank zu einer geringeren Leistungsfähigkeit des Systems, da eine große Last beim Zugriff auf die Datenbank entsteht. Dieses Problem kann wiederum durch mehrere angebundene Datenbanken und einem eignen Load Balancer geregelt werden, um einen single point of failure (SPOF) zu verhindern. Die Einbindung mehrerer Datenbanken und einer entsprechenden Architektur des Systems ermöglicht auch eine bessere Skalierbarkeit. Für eine bloß vorübergehende Speicherung von Daten sind Datenbanken wegen Einbußen in der Performanz eher ungeeignet. Bei Absturz einer Datenbank, gehen alle Informationen verloren, außer es wurden Replica erzeugt und auf einem separaten Datenbank-Server gespeichert.

Eine weitere Lösung ist die Verwendung von Browser Cookies, um die per-session Daten direkt im Browser zu Speichern. Voraussetzung dafür ist, dass der Client ein Webbrowser ist. Wenn die User Session Daten auf dem Client gespeichert werden, kann der Load Balancer unabhängig von vorheriger Zuweisung eines Servers, die Anfrage des Clients an einen beliebigen Server weiterleiten. Dieser führt dann eine Neuberechnung mit den auf dem Client zwischengespeicherten Daten durch.

Dieses Szenario ist heutzutage gängige Praxis im Endkunden-Geschäft. Für komplexe B2B Lösungen ist dies jedoch ungeeignet, da eine ständige Neuberechnung der Daten aufgrund der Nutzlast nicht durchführbar ist.

Features

Die Hauptaufgabe eines Load Balancers ist die Verteilung von ankommenden Anfragen auf eine bestimmte Anzahl von Backend-Servern innerhalb eines Clusters. Dies geschieht auf der Basis eines Scheduling Algorithmus. Load Balancer unterscheiden sich aber nicht nur durch die Ausprägung des Scheduling Algorithmus, sondern auch durch zusätzliche Funktionalitäten. Diese sind meist herstellerspezifisch.

Asymmetrische Last

Die Last kann in einem bestimmten Verhältnis verteilt werden, sodass Backend-Server unterschiedlich viele Anfragen bearbeiten müssen. Dies kann sinnvoll sein, wenn die Server selbst unterschiedliche Kapazitäten haben.

Aktivierung von Standby-Servern

Standby-Server werden automatisch aktiviert, sobald die Last sich stark erhöht oder wenn die Anzahl der verfügbaren Server unter eine bestimmte Zahl fällt.

Transport Layer Security (TLS) Offload Beschleunigung

TLS Beschleunigung ist eine Methode, die das Auslagern kryptographischer Protokollberechnungen auf eine spezialisierte Hardware ermöglicht. Bei TLS Anfragen müssen Verschlüsselungs- und Authentifizierungsanforderungen verarbeitet werden. Der Webserver ist verantwortlich für die Bearbeitung des TLS Overheads und der Anfrage selbst. Je mehr TLS Anfragen mit erhöhten Sicherheitsanforderungen an einen Webserver gesendet werden, desto mehr belastet es die CPU des Webservers und verlangsamt damit seine Antwortzeit. Load Balancer können die TLS-Verbindungen beenden und Hypertext Transfer Protocol Secure (HTTPS) Anfragen als Hypertext Transfer Protocol (HTTP) Anfrage an den Webserver weiterleiten, um den Webserver zu entlasten.

Schutz vor Distributed Denial of Service (DDoS) Attacken

Load Balancers können Funktionalitäten wie SYN Cookies bereitstellen. Außerdem können sie dafür sorgen, dass eine Verbindung des Backend-Servers mit dem Client verzögert eintritt, nämlich erst nachdem der TCP-Handshake vollzogen wurde. Das Risiko einer SYN Flut soll so gemindert werden.

Transmission Control Protocol (TCP)

Offload: Mehrere HTTP Anfragen mehrer Clients werden zu einer TCP Socket Verbindung zusammengeführt. Normalerweise wird für jede HTTP Anfrage jedes Clients eine neue TCP Verbindung zum Backend-Server hergestellt.

Buffering: Buffering ermöglicht die schnellere Freigabe von Threads für andere Aufgaben, denn es wird nicht die gesamte Anfrage direkt an den Client gesendet. Stattdessen wird die Antwort verlangsamt an den Client weitergegeben.

Des weiteren sind Load Balancer in der Lage, HTTP Caching, Priority Queuing, etc. durchzuführen und mit weiteren implementierten Sicherheitsmaßnahmen wie Firewalls auf der Application Layer umzugehen.

Bewertung

Eine der wichtigsten Bewertungskriterien eines Load Balancing – Algorithmus ist seine Stabilität und die Performanz des Systems. Da viele Entscheidungen bei dynamischen Verfahren auf der Messung der aktuellen Last beruhen, ist es entscheidend, welche Kriterien dafür gewählt werden. Parameter können sein: Länge der CPU-Warteschlange, Ausnutzung der möglichen CPU-Kapazität, Anteil an Leerlauf der CPU (Zeit), Wechselrate der Jobs, Menge unvollständiger Jobs pro Knoten, etc.
Die Länge der CPU-Warteschlange gilt als guter Indikator für die Einschätzung der Antwortzeit bei Anfragen und somit der Auslastung des gesamten Systems.

Teilen mit: