Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
satellite:dnbd3_lokales_caching [2019/08/19 16:00 CEST] – [Konfiguration] srittersatellite:dnbd3_lokales_caching [2022/06/20 16:56 CEST] (aktuell) – [Client] Hinweis zur ID45 Größe simon
Zeile 1: Zeile 1:
-<note warning>**Experimentell** 
- 
-<wrap lo>Feature derzeit in Entwicklung und Test</wrap> 
-</note> 
- 
 ====== Lokales Caching ====== ====== Lokales Caching ======
  
-bwLehrpool überträgt alle zur Laufzeit benötigten Daten über Netzwerk. Das betrifft sowohl das Grundsystem (MiniLinux) als auch anschließend gestartete VMs. Allein beim Boot einer virtuellen Windows Maschine fallen dabei schnell mehrere hundert Megabyte an.+bwLehrpool überträgt alle zur Laufzeit benötigten Daten über Netzwerk. Das betrifft sowohl das Linux-Grundsystem (Mini-/MaxiLinux) als auch anschließend gestartete VMs. Allein beim Boot einer virtuellen Windows Maschine fallen dabei schnell mehrere hundert Megabyte an.
 In manchen Fällen kann dies im Vergleich zu lokal installierten Systemen zu verlängerten Bootzeiten führen - bspw. bei: In manchen Fällen kann dies im Vergleich zu lokal installierten Systemen zu verlängerten Bootzeiten führen - bspw. bei:
   * langsamer Netzanbindung   * langsamer Netzanbindung
Zeile 21: Zeile 16:
  
 Es muss mindestens der Satellitenserver in **Version 3.8b** und **MiniLinux 25** verwendet werden. Außerdem muss DNBD3 aktiviert sein. Es ist zu empfehlen mindestens einen DNBD3-Proxy zu verwenden, damit nicht der komplette Traffic vom VM-Storage über den Satellitenserver geleitet wird. Es muss mindestens der Satellitenserver in **Version 3.8b** und **MiniLinux 25** verwendet werden. Außerdem muss DNBD3 aktiviert sein. Es ist zu empfehlen mindestens einen DNBD3-Proxy zu verwenden, damit nicht der komplette Traffic vom VM-Storage über den Satellitenserver geleitet wird.
 +**Mini/Maxi-Linux 27** enthalten zudem eine verbesserte Caching-Mechanik, sodass hier noch einmal mit besserer Performance zu rechnen ist.
 ==== Client ==== ==== Client ====
  
 Clients benötigen eine lokale Festplatte sowie eine entsprechend eingerichtete Partition zur Speicherung der Daten. Für bwLehrpool-Clients empfehlen wir immer den Einsatz einer sogenannten [[wiki:id44|ID44-Partition]]. Diese wird für temporäre Schreibzugriffe verwendet und bei jedem Bootvorgang frisch formatiert.  Clients benötigen eine lokale Festplatte sowie eine entsprechend eingerichtete Partition zur Speicherung der Daten. Für bwLehrpool-Clients empfehlen wir immer den Einsatz einer sogenannten [[wiki:id44|ID44-Partition]]. Diese wird für temporäre Schreibzugriffe verwendet und bei jedem Bootvorgang frisch formatiert. 
  
-Für das lokale Caching muss daher eine weitere, persistente Partition eingerichtet werden. Diese benötigt bei MBR die ID "45" bzw. bei GPT das Label "OpenSLX-ID45". Diese Partition wird von bwLehrpool automatisch erkannt und unter "/opt/openslx/persistent" eingebunden. Dort gespeicherte Daten werden im Gegensatz zur ID44 beim Booten nicht gelöscht.+Für das lokale Caching sollte daher eine weitere, persistente Partition eingerichtet werden ([[wiki:id45|ID45-Partition]]), die auch nach einem Neustart die gecachten Daten enthält. 
 +Diese Partition wird von bwLehrpool automatisch erkannt und unter "/opt/openslx/persistent" eingebunden.
  
-Denken Sie daran, dass es auch von der Geschwindigkeit der Festplatte abhängt, ob lokales Caching überhaupt Vorteile bringt.+Für die ID44-Partition empfehlen wir i.d.R. eine Größe von 30-50GB, bei der ID45-Partition gilt "je mehr desto besser", besonders, wenn viele unterschiedliche VMs genutzt werden. Als Untergrenze empfiehlt sich hier 50GB, für das unten erwähnte "Hashblock-Verfahren" 120GB. 
 + 
 +<WRAP center round tip 60%> 
 +Denken Sie daran, dass es von der Geschwindigkeit der Festplatte abhängt, ob lokales Caching überhaupt Vorteile bringt. Erste Messergebnisse in einer 10G Uplink/1G Client-Umgebung scheinen darauf hinzuweisen, dass **nur bei Verwendung von SSDs** lokales Caching einen Geschwindigkeitszuwachs bedeutet. 
 +</WRAP>
  
  
Zeile 36: Zeile 36:
  
 | SLX_DNBD3_MIN_GB | Mindestgröße der ID45-Partition (in Gigabyte), damit ein Client überhaupt anfängt lokal zu cachen. | | SLX_DNBD3_MIN_GB | Mindestgröße der ID45-Partition (in Gigabyte), damit ein Client überhaupt anfängt lokal zu cachen. |
-| SLX_DNBD3_MIN_GB_HASH | Mindestgröße der ID45-Partition (in Gigabyte), damit angefragte Daten immer auf 16MB Blöcke aufgefüllt werden. |+| SLX_DNBD3_MIN_GB_HASH | Mindestgröße der ID45-Partition (in Gigabyte), damit angefragte Daten immer auf 16MB Blöcke aufgefüllt werden (Hashblock). |
  
  
Zeile 47: Zeile 47:
  
 Sie sollten SLX_DNBD3_MIN_GB_HASH daher auf einen relativ hohen Wert setzen oder ggf. komplett deaktivieren (Wert = 0), da bei der Verwendung unterschiedlicher VMs auf einem Client dessen ID45-Speicher sehr schnell voll laufen wird! Auf Grund der bisher noch sehr simplen Verdrängungsstrategie kann es dadurch passieren, dass das lokale Caching nur geringe Vorteile bietet oder sogar kontraproduktiv ist. Sie sollten SLX_DNBD3_MIN_GB_HASH daher auf einen relativ hohen Wert setzen oder ggf. komplett deaktivieren (Wert = 0), da bei der Verwendung unterschiedlicher VMs auf einem Client dessen ID45-Speicher sehr schnell voll laufen wird! Auf Grund der bisher noch sehr simplen Verdrängungsstrategie kann es dadurch passieren, dass das lokale Caching nur geringe Vorteile bietet oder sogar kontraproduktiv ist.
 +
 +<note tip>Momentan empfehlen wir SLX_DNBD3_MIN_GB_HASH nicht zu nutzen, also auf "0" zu setzen, da der erste Boot damit noch sehr zäh abläuft.</note>
  
  
Zeile 52: Zeile 54:
  
   * Gecachet werden derzeit ausschließlich VMs. Das MiniLinux wird daher momentan immer noch bei jedem Start komplett übers Netzwerk (~350MB) übertragen.    * Gecachet werden derzeit ausschließlich VMs. Das MiniLinux wird daher momentan immer noch bei jedem Start komplett übers Netzwerk (~350MB) übertragen. 
-  * Der erste Boot einer VM kann zunächst langsamer sein, da die Daten parallel auf die Festplatte geschrieben werden müssen. Bei weiteren Boots der gleichen VM sollte sich die Geschwindigkeit aber (in Abhängigkeit der Geschwindikeit der Festplatte) wieder normalisieren. +  * Der **erste Boot einer VM ist i.d.R. zunächst langsamer**, da die Daten parallel auf die Festplatte geschrieben werden müssen. Bei weiteren Boots der gleichen VM sollte sich die Geschwindigkeit aber (in Abhängigkeit der Geschwindikeit der Festplatte) wieder normalisieren. 
-  *  Derzeit gibt es noch keine intelligente Verdrängungsstrategie. Wenn der Speicher der ID45 voll ist und eine neue VM angefragt wird, werden alle Blöcke der am längsten nicht verwendeten VM verworfen, um Platz zu schaffen. Sie sollten den Speicherbereich der ID45 daher nicht zu stark begrenzen (vor allem nicht wenn auf 16MB Blöcke aufgefüllt wird).+  *  Derzeit gibt es noch keine intelligente Verdrängungsstrategie. Wenn der Speicher der ID45 voll ist und eine neue VM angefragt wird, werden alle Blöcke der am längsten nicht verwendeten VM verworfen, um Platz zu schaffen. Sie sollten den Speicherbereich der ID45 daher nicht zu stark begrenzen (vor allem nicht wenn wie Hashblock-Methode verwendet wird).
  
  
  
  

Zuletzt angesehen:

Drucken/exportieren