Lokales Caching

bwLehrpool überträgt alle zur Laufzeit benötigten Daten über Netzwerk. Allein beim Boot einer virtuellen Windows Maschine fallen dabei schnell mehrere hundert Megabyte an. Durch die Verwendung von DNBD3-Proxys können auch schlechter angebundene Räume bwLehrpool nutzen und die Abhängigkeit von schnellem Netzwerkzugang sinkt.

Der nächste logische Schritt ist die Umsetzung von lokalem Caching. Clients speichern angefragte Blöcke auf der lokalen Festplatte und müssen diese bei späteren Bootvorgängen nicht mehr neu über das Netzwerk übertragen.

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.

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 ID44-Partition. Diese wird bei jedem Bootvorgang frisch formatiert und für temporäre Schreibzugriffe verwendet.

Für das lokale Caching muss daher eine weitere 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 eingebunden. Dort gespeicherte Daten werden im Gegensatz zur ID44 beim Booten nicht gelöscht.

Im Satellitenserver finden Sie zwei Konfigurationsvariablen. Diese steuern die Aktivierung und das Verhalten des lokalen Cachings. Die Variablen lassen sich wie üblich pro Raum überschreiben.

Standardmäßig wird zwischengespeichert, was der Client vom Server beim Start oder Betrieb einer VM anfragt. Werden 100KB angefragt, werden genau diese lokal gespeichert.

DNBD3 arbeitet intern aus Performanzgründen allerdings mit 16MB großen Blöcken über die jeweils Hashsummen für Integritätschecks gebildet werden. Wird nun eine Datei mit 100KB angefragt, die auf mehrere logische 16MB Blöcke verteilt gespeichert wurde, kommt es darauf an, ob

Mit SLX_DNBD3_MIN_GB_HASH gibt an, wie groß die erkannte ID45-Partition sein muss, damit angefragte Daten immer auf 16MB Blöcke aufgefüllt werden. Der Vorteil ist, dass DNBD3 die Blöcke mit den Hashes auf dem Server vergleichen kann und somit sichergestellt ist, dass bei der Übertragung nichts schief gelaufen ist. Nachteil ist aber, dass lokal deutlich mehr Speicherplatz benötigt wird und alles erstmal übers Netzwerk laufen muss. Wenn beispielsweise 100KByte aus 10 verschiedenen Blöcken angefragt werden, werden eben nicht nur 100KB gecachet, sondern gleich 10*16MByte. Außerdem haben Tests gezeigt, dass die Daten, die zum Start einer VM benötigt werden, häufig ziemlich verteilt im Image liegen.

• Gecachet werden derzeit nur VMs. Das MiniLinux kommt daher momentan immer noch bei jedem Start komplett übers Netzwerk (~350MB).
• Der erste Boot einer VM ist 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.
• 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).