Hallo Martin,
Für mein Verständnis beduetet Virtualisierung auch, dann jede VM ein in sich abgeschlossenes System mit nur wenigen eindeutig definierten Schnittstellen ist.
Ja, das ist schon so, aber das SAN dient dazu, die Harddisks zu virtualisieren. Wenn die Speicherpartition der VM auf einer HDD im ESX Host liegt, ist die VM an diesen Host gebunden und kann nicht verlegt werden, ohne die virtuelle Platte umzukopieren. Hinzu kommt, dass eine virtuelle Festplatte, die in einer Datei steckt, ineffizienter ist als ein SAN.
Das ist natürlich schon was für Monster-Szenarien:
Links steht ein Schrank voller Terabyte Platten, die schön gleichmäßig und gekühlt vor sich hin eiern.
Rechts steht der Schrank voller Blade Server mit vier Sockeln pro Server, 8 Kernen pro Sockel und 128GB RAM pro Blade. Oder so. Auch schön gekühlt.
Und in der Mitte steht der Managementschrank. Alles schön mit Glasfasern und 10GBit++ gekoppelt.
Anforderung kommt rein: Virtuelle Maschine mit 4 Kernen, 16GB RAM und einer 40GB Harddisk soll eingeschaltet werden? Gehört dem Team XY, das 48 Kerne nutzen darf und derzeit 44 verwendet? Aaaalso gut, gerade noch. Blade 19, für Dich, schnapp die die blub18sfx VM und schmeiß sie an.
Der dort laufende Hypervisor reserviert 4 Kerne und 16GB für diese VM. Oder auch weniger, wenn man overcommitted. Die virtuelle 40GB Harddisk, ja, lieber Hypervisor, für die frag mal mit der Kennung foo17bar3 beim SAN Controller an.
Der SAN Controller weiß dann, dass er dafür die Sektoren 512124ff der Harddisk 413 bereitstellen muss. Oder so ähnlich 😉. Die VM liest nun keine Dateien von dieser virtuellen Platte, sondern Sektoren. Die Kommunikation erfolgt low-level, ähnlich wie auf einer SATA Schnittstelle.
Im SAN wird dann fleißig geRAIDed und upgebackt, so dass ein Rauchwölkchen über einem der Datengräber keine besonderen Schäden auslöst.
Schlecht ist es nur, wenn das SAN gelegentlich mal ein Päuschen einlegt. So ein bis zwei Sekunden lang. Weil die redundanten SAN Controller sich gerade resynchronisieren. Oder weil 267 VMs gleichzeitig 37GB an Daten schreiben wollen. Egal. Das SAN beschäftigt sich einen Moment lang mit sich selbst.
Die VM will aber nun einen Sektor von einer Platte lesen. Schlimmstenfalls nicht irgendeinen. Sondern einen vom Paging File. Man kann ein Windows ja heutzutage nicht mehr im Real RAM Modus laufen lassen, es will unbedingt ein Pagefile haben und irgendwelchen Schmutz dahin auslagern. Es ist aber Päuschen im SAN. Und dann hält die VM an. Gnadenlos. Bis das Päuschen rum und die Page da ist. Dass auf dem Windows Server eine Realtime Software läuft, ist dann schade. Die merkt nicht mal, dass sie gerade einen Zeitreise von 2s in die Zukunft gemacht hat. Weil nicht mal mehr die virtuelle Uhr getickt hat. Nur die Telefone und die Telefonanlage, die in Realtime SIP Messages an die Callcenter-Software geschickt haben, die aber leider dem zeitreisenden Empfänger entgangen sind, schmollen nun.
„Hey Management, diese Software funktioniert auf unserer Virtualisierungsplattform nicht. Wir brauchen für diese Server physische Platten!“ - „Schnauze, Operator, VM+SAN ist Strategie. Das machen wir so. Denken verboten!“. So ging das bei uns mehr ein Jahr lang. Bis der wirklich jede Hersteller-Eskalation bei SAN, VMWare und Callcenterhersteller im Sande verlaufen ist. Die schoben sich das schön gegenseitig zu.
Die Server sind immer noch virtuell. Aber die ESX Hosts, in denen sie stecken, haben wieder richtige Festplatten drin. Und siehe da, das Problem war weg.
Rolf
--
sumpsi - posui - obstruxi
Der Martin
Rolf B
dedlfix
