Loadbalancer verrichten überall dort ihren Dienst, wo Datenverkehr auf mehrere Server oder Ressourcen zu verteilen ist. Waren physische Systeme lange Zeit das Mittel der Wahl, haben auch hier virtuelle Loadbalancer Einzug in die Rechenzentren gehalten. Der Virtual LoadMaster von Kemp will in diesem Umfeld mit einfacher Bedienung, verbesserter Sicherheit und einem moderaten Preis punkten.
Kemp gründete sich im Jahr 2000 in den USA und zählt mit über 25.000 Kunden und rund 100.000 Deployments weltweit zu einem der führenden Anbieter für Loadbalancer. Loadbalancer sind entscheidend, um die Leistung, Verfügbarkeit und Skalierbarkeit von Anwendungen oder Diensten zu verbessern. Die virtuelle Ausprägung solcher Werkzeuge bietet dabei eine bessere Skalierbarkeit und in den meisten Fällen eine verbesserte Hochverfügbarkeit. Ein derartiger Lastenausgleich fügt sich nahtlos in virtualisierten Umgebungen ein und verteilt den Datenverkehr auf mehrere Server oder Ressourcen. Ein Loadbalancer arbeitet auf der Vermittlungs- (Layer 4) oder der Anwendungsschicht (Layer 7) des OSI-Referenzmodells.
Layer-4-Loadbalancer verteilen den Datenverkehr basierend auf IP-Adressen und Portnummern. Sie ermöglichen eine gleichmäßige Verteilung des Datenverkehrs auf mehrere Server, um die Last zu reduzieren und die Gesamtleistung zu verbessern. Layer-7-Loadbalancer sind aufgrund ihrer Fähigkeit, den Datenverkehr anhand von Anwendungsprotokollen wie HTTP, HTTPS oder SMTP zu steuern, noch fortschrittlicher. Sie können Entscheidungen basierend auf Inhalten oder anderen spezifischen Merkmalen treffen und so den Datenverkehr umleiten. Kemp unterstützt das Layer-4-Konzept, wesentlich effizienter arbeitet aber das Layer-7-Loadbalancing.
Angebotsformen prüfen
Der Kemp Virtual LoadMaster (VLM) simuliert einen physischen Loadbalancer, läuft jedoch als virtuelle Appliance auf gängigen Virtualisierungsplattformen wie Hyper-V, VMware, XEN, KVM und VirtualBox. Durch die Bereitstellung als virtuelle Instanz bietet VLM Flexibilität und Skalierbarkeit, da er sich problemlos in bestehende virtuelle Infrastrukturen integrieren lässt.
Kemp gründete sich im Jahr 2000 in den USA und zählt mit über 25.000 Kunden und rund 100.000 Deployments weltweit zu einem der führenden Anbieter für Loadbalancer. Loadbalancer sind entscheidend, um die Leistung, Verfügbarkeit und Skalierbarkeit von Anwendungen oder Diensten zu verbessern. Die virtuelle Ausprägung solcher Werkzeuge bietet dabei eine bessere Skalierbarkeit und in den meisten Fällen eine verbesserte Hochverfügbarkeit. Ein derartiger Lastenausgleich fügt sich nahtlos in virtualisierten Umgebungen ein und verteilt den Datenverkehr auf mehrere Server oder Ressourcen. Ein Loadbalancer arbeitet auf der Vermittlungs- (Layer 4) oder der Anwendungsschicht (Layer 7) des OSI-Referenzmodells.
Layer-4-Loadbalancer verteilen den Datenverkehr basierend auf IP-Adressen und Portnummern. Sie ermöglichen eine gleichmäßige Verteilung des Datenverkehrs auf mehrere Server, um die Last zu reduzieren und die Gesamtleistung zu verbessern. Layer-7-Loadbalancer sind aufgrund ihrer Fähigkeit, den Datenverkehr anhand von Anwendungsprotokollen wie HTTP, HTTPS oder SMTP zu steuern, noch fortschrittlicher. Sie können Entscheidungen basierend auf Inhalten oder anderen spezifischen Merkmalen treffen und so den Datenverkehr umleiten. Kemp unterstützt das Layer-4-Konzept, wesentlich effizienter arbeitet aber das Layer-7-Loadbalancing.
Angebotsformen prüfen
Der Kemp Virtual LoadMaster (VLM) simuliert einen physischen Loadbalancer, läuft jedoch als virtuelle Appliance auf gängigen Virtualisierungsplattformen wie Hyper-V, VMware, XEN, KVM und VirtualBox. Durch die Bereitstellung als virtuelle Instanz bietet VLM Flexibilität und Skalierbarkeit, da er sich problemlos in bestehende virtuelle Infrastrukturen integrieren lässt.
Das LoadMaster-Angebot weist verschiedene Abonnements auf, die sich nach dem Durchsatz und den SSL-Transaktionen je Sekunde (SSL TPS) richten. Zur Wahl stehen LM-500 mit einem Durchsatz von bis zu 500 MBit/s und bis zu 500 SSL TPS, VLM-3000 mit 3 GBit/s und bis zu 4000 SSL TPS sowie der VLM-MAX mit einem unbegrenzten Durchsatz und unbegrenzten Sitzungen. Dazu kommt dann noch ein Supportabonnement in Form von "Standard", "Enterprise" oder "Enterprise Plus" – die Unterschiede zeigt [1]. Neben der reinen Unterstützungsleistung, die im Standard mit einem 10x5- Support startet und in der höchsten Stufe zu 24x7 wird, ändert sich der Leistungsumfang ebenfalls je nach Support-Level. Dies beinhaltet beim "Enterprise Support" ein Werkzeug zur "Intrusion Prevention" sowie das "Edge Security Pack" (ESP) und beim "Enterprise Plus Support" das "Global Server Load Balancing" und eine "Web Application Firewall".
Der Preis hierfür beginnt für VLM-500 bei 2000 Euro zuzüglich eines Supportvertrages. Daneben stehen auch Jahresabonnements zur Verfügung, die bereits die Support-Stufe "Enterprise Plus" enthalten und bei 1720 Euro für eine VLM-500 pro Jahr starten.
Systemanforderungen
Die virtuelle Appliance kann auf Hyper-V, VMware, XEN, KVM und VirtualBox zum Einsatz kommen. Die Voraussetzungen für die virtuelle Maschine liegen bei zwei virtuellen Prozessoren, zwei GByte Arbeitsspeicher, einer Netzwerkschnittstelle sowie einer Festplatte mit einer Speicherkapazität von mindestens 16 GByte.
Für Test- und Kleinstumgebungen steht darüber hinaus der "Free LoadMaster" zur Verfügung, der alle Kernfunktionen mitbringt, jedoch in Sachen Kapazität auf 20 MBit/s und bis zu 50 SSL TPS begrenzt ist. Er eignet sich primär für Umgebungen mit geringem Volumen, wie Entwicklung oder Pre-Production. In der Cloud von AWS, Azure oder der Telekom lassen sich darüber hinaus die VLMs auch direkt buchen.
Unkomplizierte Einrichtung
Für unseren Test werfen wir einen Blick auf den Virtual LoadMaster in der Version 7.2.59 unter Microsoft Hyper-V. Eine 30-Tage-Testversion steht über die Website zur Verfügung und es ist nur eine kurze Registrierung nötig. Danach mussten wir den Hypervisor und das Land auswählen und konnten den Download starten. Bei dem Download handelt es sich um die zu nutzende virtuelle Festplatte sowie eine ausführliche Beschreibung. Kemp stellt dabei auch auf der Homepage eine sehr umfangreiche Dokumentation für alle Virtualisierungsplattformen bereit und auch die einzelnen Funktionen sind sehr gut dargelegt.
Zur Konfiguration des VLM richteten wir zunächst in Hyper-V eine neue virtuelle Maschine ein. Die Mindestvoraussetzungen liegen dabei bei zwei virtuellen Prozessoren, 2 GByte Arbeitsspeicher, einer Netzwerkschnittstelle sowie einer Festplatte mit mindestens 16 GByte. Die Festplattenvoraussetzung wurden durch die virtuelle Festplatte selbst umgesetzt. Sie müssen beachten, dass eine virtuelle Maschine der Generation 1 erforderlich ist, da Generation 2 nicht unterstützt wird. Die virtuelle Festplatte wird während des Einrichtungsprozesses einfach mit eingebunden.
Danach starteten wir VLM und uns präsentierte sich das "LoadMaster Operating System" (LMOS) auf Linux-Basis. Zu konfigurieren war an dieser Stelle nichts und wir wurden direkt auf das Webinterface verwiesen. Sofern in der Umgebung ein DHCP-Server erreichbar ist, kommt eine IP-Adresse aus dem Netzwerkbereich zum Einsatz. Sofern kein DHCP-Server im Zugriff ist, stellt sich die Adresse automatisch auf "192.168.1.101". Die weitere VLM-Konfiguration erfolgt über eine webbasierte Benutzeroberfläche, die eine einfache Verwaltung und Überwachung ermöglicht.
Zentrale Admin-Konsole bietet Zugriff auf alle Funktionen
Nach dem Aufruf der Seite "https://10.75.0.11" erhielten wir zunächst eine Zertifikatsfehlermeldung, die wir nach Studium eines entsprechenden Hinweises im sehr ausführlichen Handbuch ignorierten. Anschließend galt es, das License Agreement zu bestätigen und eine Lizenz zu hinterlegen. Dies erfolgte durch die Onlineanmeldung mit den registrierten Zugangsdaten. Alternativ kann auch eine Offlineaktivierung erfolgen. Nach der Bestätigung wurde unsere "VLM-MAX" mit Enterprise Plus Subscription für 30 Tage aktiviert.
Im Anschluss mussten wir das Kennwort für den Standardadministrator setzen und danach war das Anmelden an der Appliance möglich. Zunächst änderten wir die DHCP-IP-Adresse über den Eintrag "System Configuration / Network Setup" auf eine statische Adresse. DNS-Server und Gateway ließen sich ebenfalls schnell anpassen. Auf der rechten Seite zeigte sich uns unter dem Menü das "Root-Certificate" der virtuellen Appliance, sodass nach der Einbindung am Client keine Zertifikatsfehlermeldung mehr auftauchte.
Die Startseite präsentiert dem Nutzer zunächst grundsätzliche Informationen wie IP-Adresse, LoadMaster-Version und Seriennummer. Darüber hinaus finden sich Statusinformationen zu virtuellen Diensten und realen Servern und im unteren Bereich auch Lizenzinformationen und der damit einhergehende Funktionsumfang (Bild 2).
Das Menü des LoadMaster auf der rechten Seite setzt sich aus den Einträgen "Virtual Services", "Global Balancing", "Statistics", "Real Servers", "Rules & Checking", "Certificates & Security", "Web Application Firewall", "System Configuration" sowie "Network Telemetry" und "Help" zusammen. Im Bereich "Virtual Services" lassen sich virtuelle Services einrichten und konfigurieren sowie Vorlagen für verschiedene Dienste einbinden. Im Unterpunkt "Manage SSO" lässt sich ein Single Sign-On einrichten und "Global Balancing" bietet eine Hochverfügbarkeit über mehrere Rechenzentren, was über Standard-HA hinausgeht. Dieser Funktion konnten wir uns aufgrund der begrenzten Testumgebung nicht weiter widmen. Die VLM-Standardeinstellungen erfolgen im Menüpunkt "System Configuration" und umfassen Netzwerk, Clustering und VLM selbst. Auf einige Punkte gehen wir innerhalb des Tests noch tiefer ein.
Im Bereich "Statistics" bereiten "Real Time Statistics" und "Historical Graphs" die Daten des VLM auf. Die Livedaten werden dabei nach "Global", "Real Servers", "Virtual Services" und "WAF" getrennt aufgeschlüsselt. Unter "Real Servers" erfuhren wir den Status der eingebundenen physischen Server, die sich hier zwar aktivieren beziehungsweise deaktivieren lassen, deren grundsätzliche Konfiguration aber am "Virtual Service" erfolgen sollte.
Unter "Rules & Checking" waren wir in der Lage, Regeln zu definieren, um spezifische Anfragen basierend auf dem Inhalt der angeforderten URL an bestimmte Server weiterzuleiten. Diese Policys wurden innerhalb des Tests von den Kemp-Vorlagen mitgebracht und in den virtuellen Diensten direkt eingebunden.
Im Bereich "Certificates & Security" werden unter anderem die externen Zertifikate verwaltet. Über das "Automated Certificate Management Environment" (ACME) lassen sich Zertifikate von Let's Encrypt und DigiCert automatisiert einbinden. Weiter gelingt hier der Fernzugriff und die Integration der LDAP-Endpunkte, die im Bereich des SSO zur Anwendung kommen. Ein "Intrusion Prevention System" (IPS) und "Intrusion Detection System" (IDS) sind ebenfalls mit an Bord und die zugehörigen Regeln lassen sich unter dem entsprechenden Menüeintrag importieren und bei den virtuellen Diensten aktivieren.
Die wenigen Grundeinstellungen zur "Web Application Firewall" erfolgen im gleichnamigen Menüpunkt. Eingebunden wird das OWASP ModSecurity Core Rule Set (CRS), das einen Satz generischer Angriffserkennungsregeln mitbringt. Das CRS zielt darauf ab, Webanwendungen vor einer breiten Palette von Angriffen zu schützen. Die aktuell genutzte Version ist in diesem Punkt einzusehen und eine tägliche Update-Routine lässt sich an dieser Stelle aktivieren.
Detaillierte Unterstützung bei der Diensteveröffentlichung
In Kemp VLM lassen sich virtuelle Dienste manuell über den Eintrag "Virtual Services" erstellen. Für sehr viele Anwendungen, wie zum Beispiel Citrix, Apache, Oracle, SAP, Sage X3, MobileIron, BMC Remedy oder verschiedene Microsoft-Produkte, gibt es ausführliche Deployment-Guides mit "Virtual Service Templates", die wir direkt in den VLM importieren konnten.
In unserem Test haben wir uns die Anbindung von Exchange 2016 etwas genauer angeschaut, für die uns eine sehr ausführliche Schritt-für-Schritt-Anleitung zur Verfügung stand. Für die Konfiguration gibt es, je nach Funktionsumfang der VLM, verschiedene Vorlagen und wir haben uns für das Template "ESP and WAF Services" auf der Kemp-Supportseite entschieden und dieses heruntergeladen. Hierdurch konnten wir auch einen Blick auf das Edge Security Pack und die WAF werfen. Zur Einbindung von Exchange mussten wir zunächst die Option "Subnet Originating Requests" aktivieren, damit VLM den Datenverkehr über das jeweilige Interface im Subnet des physichen Servers und nicht über das Default Gateway leitet, sofern sich die Server in unterschiedlichen Netzen befinden. Darüber hinaus mussten weitere Einstellungen erfolgen, die Probleme mit den Exchange-Webservices und Outlook for Mac umgehen.
Mit ESP konnten wir Anwendungen vor unerwünschten Zugriffen aus dem Internet schützen. Die Funktion wurde als Ersatz für Microsofts aufgekündigtes Threat Management Gateway (TMG) etabliert und bietet eine Vor-Authentifizierung und Single Sign-on. Zur Nutzung mussten wir zunächst die Verbindung zum Active Directory herstellen sowie unter "Virtual Sevices / Manage SSO" eine neue "Client Side Sigle Sign On Configuration" hinzufügen. Schließlich hinterlegten wir bei "Manage LDAP Configuration" den Domaincontroller als LDAP-Endpunkt inklusive IP-Adresse, Ports sowie Benutzerinformationen. Damit hatten wir die AD-Anbindung bereits abgeschlossen und die SSOKonfiguration stand uns zur Verfügung.
Im nächsten Schritt haben wir unser Exchange-Template im Eintrag "Manage Templates" eingebunden. Dieses haben wir dann über "Add New" genutzt, um die "Virtual Services" zu integrieren. Dies wiederum erforderte die Angabe der zu nutzenden virtuellen IP-Adresse und des Templates. Nachdem unser neuer Virtual Service fertig war, erschien sofort dessen Konfiguration. In den "SSL Properties" hinterlegten wir zunächst das Zertifikat des Exchange-Servers, damit es zukünftig nicht zu Fehlermeldungen kommt. Unter den Einstellungen "SubVSs" (SubVirtualServices) wurde danach über "Modify" der erste Eintrag angepasst. Im Bereich "Real Servers" hinterlegten wir über "Add New …" den physischen Server. Dabei trugen wir die IP-Adresse des Exchange-Servers ein und über das Häkchen "Add to all SubVSs" wurde dieser direkt zu allen SubVSs hinzugefügt. Anschließend waren die einzelnen SubVSs in der Übersicht mit einem grünen Häkchen versehen.
Nun startete die Konfiguration von ESP, wozu der Virtual Service mittels "Modify" wieder anzupassen war. Für alle SubVS mussten wir die "Allowed Virtual Hosts" sowie die "SSO Domain" festlegen, was Anpassungen an jeder einzelnen SubVS erforderte. Der "Allowed Virtual Host" entspricht dem öffentlichen Eintrag von Exchange und den virtuellen Verzeichnissen.
Im Anschluss konfigurierten wir auf unserem Testclient die DNS-Einträge in der HOSTS-Datei, um die Einstellung zu testen. Im Browser zeigte sich uns daraufhin die Kemp-Anmeldemaske und wir konnten auf OWA zugreifen. Wenn soweit alles funktioniert, können DNS- und Router-Anpassungen erfolgen sowie die IP-Adresse von Exchange auf die virtuelle IP-Adresse geändert werden.
Zusätzliche Sicherheit mittels WAF
Angesichts der Zunahme von Cyberangriffen sollten IT-Verantwortliche keine Dienste ohne zusätzliche Sicherheitsmaßnahmen im Internet veröffentlichen. Grundsätzlich muss für Anfragen, die die Backend-Anwendungsserver erreichen, die Sicherheit gewährleistet sein. Die Web Application Firewall trägt dazu bei, dies umzusetzen. Die WAF erweitert die vorhandenen Sicherheitsfunktionen des LoadMasters, um einen mehrschichtigen Schutz für Webanwendungen zu schaffen und so eine sichere Nutzung der veröffentlichten Dienste zu ermöglichen. Wenn WAF aktiviert ist, scannt die WAF-Engine jedes eingehende HTTP-Paket, durchläuft jede zugewiesene Regel einzeln und entscheidet, welche Aktion zur Anwendung kommt, wenn eine Regel ausgelöst wird. Grundsätzlich kann die WAF vor Angriffen wie zum Beispiel dem Einschleusen von SQL-Befehlen, Cross-Site-Scripting (XSS), nicht validierten Weiterleitungen oder fehlender Zugriffssteuerung auf Funktionsebene schützen.
Es lassen sich eigene WAF-Regeln schreiben oder Regeln von Drittanbietern importieren. Unser Exchange-Template brachte gleich sein Regelwerk mit und die WAF-Einstellungen lassen sich direkt am virtuellen Dienst aktivieren. Bei Exchange ist darauf zu achten, dass WAF auf Sub-VS-Ebene zu aktivieren ist und nicht bei den virtuellen Diensten. Sofern WAF auf ein Verzeichnis zielt, ändert sich die Abschnittsüberschrift in den Optionen für den virtuellen Dienst von "WAF" in "WAF (Enabled)". Bis auf den "Audit-Mode" ist durch die Templates bei der WAF nicht wirklich viel zu konfigurieren. Der Mehrwert des ModSecurity Core Rule Sets sollte aber enorm sein.
Hochverfügbarkeit im Handumdrehen
Mit VLM lassen sich Anwendungen und Dienste schnell hochverfügbar bereitstellen. Damit VLM aber nicht zum Single-Point-of-Failure wird, haben wir uns die High Availability (HA) des Systems einmal genauer angeschaut. Mehrere Load-Master lassen sich dabei zu einem Cluster zusammenschalten, was nicht nur die Ausfallsicherheit erhöht, sondern mit jedem zusätzlichen Cluster im Knoten auch den Durchsatz linear ansteigen lässt. Um die Leistung zu erhöhen und Leistungsspitzen zu bestimmten Zeiten abzufangen, reicht es, einfach neue Knoten hinzuzufügen (die sich auch genauso einfach wieder entfernen lassen). Denn alle Load-Master arbeiten parallel und sofern einer ausfällt, verteilt sich der Datenverkehr auf die anderen Knoten. Voraussetzung für das Clustering sind mindestens drei identische LoadMaster.
Da uns in unserem Test nur zwei VLM zur Verfügung standen, haben wir uns den HA-Mode einmal genauer angeschaut. Dieser garantiert ebenfalls die Verfügbarkeit der angeschlossenen Dienste. Dabei werden zwei VLMs in einem Cluster zusammengeschaltet und ein System arbeitet als Hot-Standby, das jederzeit die Last übernehmen kann. Beim Einrichten ist darauf zu achten, dass in den Hyper-V-VMs "Enable MAC address spoofing" aktiviert ist.
Das Aktivieren gelang auf dem ersten Node unter "System Configuration / HA and Clustering" und dem Cluster-Modus "HA Mode" über den Eintrag "HA (First) Mode". Damit haben wir den Knoten zum ersten Knoten gemacht und mussten im Anschluss noch die "HA Shared IP address" sowie die IP-Adresse des zweiten Knotens hinterlegen. Nach einem Reboot konnte wir den Cluster über die virtuelle IP-Adresse konfigurieren. Die Einrichtung des zweiten Knotens erfolgt über den gleichen Weg: Zunächst riefen wir VLM mit seiner lokalen IP-Adresse auf und wählten in den Cluster-Einstellungen den Modus "HA (Second) Mode". Dann hinterlegten wir über die GUI virtuelle und Partner-IP-Adresse und nach einem Neustart war der zweite Knoten bereits eingebunden.
Den Status des HA-Clusters erfuhren wir nach dem Login auf der Website über zwei grüne Quadrate oben rechts. Das "A" deutet dabei auf den aktiven Knoten hin. Per Maus-over über den Bereich erscheint ein kleines Pop-up und zeigt die lokale IP-Adresse des jeweiligen Knotens und dessen Status. Ein Klick auf den Knoten leitete uns zur lokalen Administration weiter, die aber an dieser Stelle nur noch eingeschränkte Konfigurationsmöglichkeiten enthielt. Getestet haben wir das Cluster durch den Neustart eines Knotens, was dazu führte, das der zweite Node direkt übernahm und als aktiv markiert wurde. Das Anhalten eines Knotens in Hyper-V bemerkte das System ebenfalls und kennzeichnete den Knoten über ein rotes Quadrat mit gelbem Kreuz als unerreichbar. Insgesamt war die Clusterfunktion sehr schnell einzurichten und vollzog in unserem Schnelltest tadellos ihren Dienst.
Gutes internes Monitoring
Der LoadMaster sollte nicht nur still seinen Dienst verrichten, sondern Administratoren über seinen Status informieren. Hierfür konnten wir eine E-Mail-Benachrichtigung aktivieren. Je nach Schweregrad eines Ereignisses lassen sich hier verschiedene Empfänger für Informationen, Hinweise, Warnungen, Fehler, kritische Fehler und Notfälle hinterlegen. Die virtuellen LoadMaster lassen sich ebenfalls über SNMP überwachen – hierfür ist der Dienst in den "Logging Options" zu aktivieren. Auf dem SNMP-Server können die zur Verfügung gestellten MIBs (Management Information Base) eingebunden und die Umgebung auf diesem Weg überwacht werden. In unserem Test hat dies problemlos funktioniert.
VLM kann darüber hinaus über das Syslog-Protokoll verschiedene Warn- und Fehlermeldungen erzeugen. Die Syslog-Meldungen entsprechen dabei RFC5424 und enthalten einen vollständigen Zeitstempel und den LoadMaster-Hostnamen. Per Default lagern diese zunächst lokal, lassen sich aber – nach Schweregrad gefiltert – an einen Syslog-Server weiterleiten. Es gibt also genügend Möglichkeiten, um auch den LoadMaster im Blick zu behalten.
Fazit
Insgesamt bietet der Kemp Virtual Load Balancer eine kostengünstige Variante für Unternehmen, um die Skalierbarkeit, Verfügbarkeit und Leistung ihrer Anwendungen zu verbessern, indem er den Datenverkehr intelligent verteilt und Serverausfälle abfängt. In unserem Test war das Produkt in der virtuellen Testumgebung sehr schnell eingerichtet und virtuelle Dienste veröffentlicht. Gerade die einfache Einrichtung und Veröffentlichung haben uns in dem Test überzeugt.
(jp)
So urteilt IT-Administrator
Bewertung
Veröffentlichung virtueller Dienste
8
Umfang der Vorlagen
8
Sicherheit
8
Hochverfügbarkeit
8
Inbetriebnahme
7
Dieses Produkt eignet sich
optimal
für Unternehmen jeglicher Größe, die Loadbalancing benötigen.
bedingt
wenn vorhandene Anwendungen ausreichend HA-Optionen bietet und der Mehrwert der VLMs gering ist.
nicht
sofern interne Mechanismen vorhanden sind oder Anwendungen nicht oder nur sehr selten und hohe Last geraten.