Virtualisierungstechniken -- Erfahrungen und Fragen

[#1]

Ein schöner Artikel, den Sie verfaßt haben.  Wird aber nicht jedem gefallen, weil doch schon sehr tiefgreifend.   Virtualisierung soll ja eigentlich die Sicht auf die Dinge vereinfachen, aber Sie haben jetzt einmal hineingeschaut.

Um andere Teilnehmer hier nicht zu inkommodieren, antworte ich nur ein Mal kurz, stehe aber gerne per Mail zur Verfügung.

---

@Timo_Witte  schrieb:

a) "Dateien" sind auch nur Blöcke auf einem Device mit ein paar Metadaten außenrum.. Meistens sogar zusammenhängende Bereiche.. Datenbanken schauen nicht jedes mal nach der file u.s.w. sondern "mappen" die Datei einmal beim starten per memmory mapped i/o typischerweise. Memory Mapped I/O mapped eine Datei z.B. in den virtuellen Adressraum des Prozesses der die Datei mapped.
Der Zugriff ist dann ein Speicherzugriff, erst das Betriebsystem kann dann relativ effizient (je nachdem was der Treiber / Blocklayer unterstützt) auf das physikalische Gerät schreiben.

Ja, aber nun befindet sich die 'gemapte' Datei wiederum in einer Datei.   RFC 1925 läßt schön grüßen,

It is always possible to add another level of indirection.

Und weil i.d.R viele Prozesse auf die "Datei" zugreifen, in der die "gemapten" DB-Tabellen enthalten sind, bedarf es richtig teurer Locking-Mechanismen.   Und bitte berücksichtigen:  Auch die Windows-Gäste haben es ja mittlerweile zu einer Art LVM gebracht, das macht noch einmal eine Indirektion extra.   Indirektionen mit geringer "referentieller Lokalität" trashen Ihnen leicht den Prozessorcache.

Async I/O

Moderne Speichergeräte sind zudem Multi-Queue fähig, sprich das Betriebsystem kann teilweise bis zu 128 lese und Schreibzugriffe gleichzeitig "in der Schwebe" haben.

Ja, unter AIX seit 1990.  Ist aber doof, wenn ein I/O auf den vorhergehenden warten muß.

Physikalisches Gerät direkt in die VM "mappen"

Würde ich nicht machen, da man damit die Vorteile der Virtualisierung verliert, da Resourcen hart einzelnen VMs zugeordnet werden und weder einfach zu skalieren sind noch backups durchzuführen.

Bei Netzwerkkarten ab 10 GBit/s ist das sehr schön, weil solche Dinge wie kompletter TCP-Offload quasi "am Netzwerkstack vorbei" vom Prozessor der Karte selbst gemanaged werden.  Ansonsten ist das "Bridging" zwischen den Partitionen doch sehr teuer.  Die IBM-Plattformen sind da sehr ehrlich und weisen die CPU-Last aus, die virtuelles Ethernet, virtuelles SCSI und virtueller Fibrechannel ausmachen.

Bei einer POWER8 mit etwa 180 Anwendern dran incl. Storage-Anbindung macht das bei 6 intensiv genutzen VMs etwa 1/8 der Systemleistung aus -- und das trotz "large send offload" nach außen.

Bei Maschinen, die viel Output machen, ist die direkte Zuordnung von Hardwareessourcen ein Segen.   Und wenn ich gut plane, brauche ich hinterher keine Flexibilität ...

Das die Festplatten in der Hardware stecken auf der der Hypervisor läuft ist zwar verbreitet aber auch nicht zwingend erforderlich / nicht optimal. Storage Virtualisierung ist ja auch ein Thema, warum nicht einen großen redundanten Blockstorage der zwei "Controller" hat und somit ausfallsicher ist? Dieser wird dann per 10/100GBit Ethernet redudant über Kreuz an die Hypervisor angebunden (im "Enterprise" Umfeld benutzt man da auch gerne FibreChannel).

Vorteil: Ausfallsicherheit.. Alle Hypervisor Server können jede VM starten, Live Migration erfordert kein migrieren des Storage, da ja beide Server Zugriff auf den gemeinsamen Storage haben.

Gegen diese Ihre Erkenntnis habe ich mich lange gewehrt, aber die Realität ist:

Sie haben recht.   Allerdings bitte "wenn schon, denn schon".   Also nix iSCSI, auch kein FCOE, sondern direkt Fibrechannel.   Dann aber bitte gleich ZWEI SANs mit SVC und schön gespiegelt.  Wir haben einige Kunden mit Storewize V7000, da kostet so eine "Grundausstattung" mit 150 TB in etwa so viel -- pro Controller natürlich.

Aber die Leistung ist schon erstaunlich und die Systeme sind sehr zuverlässig.

Dabei hilft Ihnen Virtualisierung, auf die aufwendige FC-Fabric zu verzichten, denn wenn Sie nur drei Server am SAN haben, können Sie die direkt in die Kiste stecken, redundant natürlich.  So sparen Sie sich die FC-Switche (die natürlich auch wieder doppelt vorhanden sein müßten) und das ganze Gefrickel mit dem Zoning.

Der Hypervisor, via NPIV, stellt dann den VM-Gästen, die sich als FC-Host ausgeben, die LUNs direkt zur Verfügung.

Für eine lokale Installation auch in einer großen Steuerberatungskanzlei ist das nicht mehr nur Over-, sondern Hyperkill.

Möchte man keine komplette eigene Storage Infrastruktur kann man auch mit bestehenden Hypervisorn mit eingebauten Platten Hochverfügbarkeit erreichen und zwar über DRBD, da werden praktisch die Schreibzugriffe auf Blockdevice Ebene über Netzwerk zwischen den beiden Kisten hin und her synchronisiert. Fällt einer der Knoten aus, kann der andere Knoten die VMs einfach automatisiert bei sich starten und nach ein paar Sekunden ist man wieder "online".

Eine hochinteressante Alternative, vielfach unterschätzt und Bestandteil des Linux-Kernels.

Unsere Kunden wollen das nicht, denn sie hätten gern die "Sicherheit des großen Namens".

Würde ich eine größere Virtualisierungsinfrastruktur aufbauen, würde ich vermutlich aber zu einem CEPH Cluster greifen. -> Das ist auch was die Hyperscaler tun, mit ihrer eigenen Implementierung so eines Clusters.

Das macht man genau ein Mal.

Für Ihre ganz spezielle Belustigung, gefällt nicht jedem:

https://www.heinlein-support.de/slac/2015/vortrag/60-minutes-of-openstack-hate

Der Herr Köhntopp weiß eigentlich immer, wovon er spricht.

Bei unserer Installation verwende ich ZFS im raidz2, für VM Blockdevices werden hier zvols verwenden, sprich keine Dateien. ZFS ist sehr flexibel und hat eine relativ ausgefeilte Caching infrastruktur lesend wie schreibend.

ZFS war seinen Artgenossen immer um Jahrzehnte voraus, ernstzunehmende Kollegen raten aber vehement davon ab, außer wenn es unter BSD läuft.  Ich habe da Angst vor einem Totalzusammenbruch.  Einmal durfte ich ein solches Szenario erleben, bei einem mittelgroßen Automobilzulieferer.   War nicht lustig.

Ich staune auch, daß man Sie in Ihrem Unternehmen "einfach so etwas machen läßt", da kann ich Sie nur beglückwünschen.   Normalerweise bekommen alle ein VMWare aufs Auge gedrückt und gut ist.

Die Netzwerkkarte wird vom Hypervisor so konfiguriert, dass Sie Pakete an bestimmte MAC-Adressen direkt per DMA in einen Speicherbereich ohne Beteiligung des Hauptprozessor schreibt. Die VM kriegt diesen Speicherbereich einfach in ihren reingemapped und kann direkt daraus lesen. Sprich der "Hypervisor" hat die Daten nie in der Hand.

Bei KVM (also auch bei Proxmox) machen das schon noch virtuelle "Switches" und vor allen Dingen virtuelle Ethernet Bridges.   Einer unserer jungen Kollegen hat sich da sehr hineingehängt, ursprünglich zu Proxmox tendiert, es dann aber wieder verworfen und auf Debian / KVM "pur" gesetzt.  Das mit dem Netzwerk habe ich mir zeigen lassen, trotz Hammer-Hardware läßt das zu wünschen übrig.   Vielleicht hat er ja auch etwas falsch konfiguriert, aber er hat die Original-RedHat - Dokumentationen gelesen.

Es gibt immer noch zu viele "teure" Kernel / Userspace - Übergänge.

In bestimmten Situationen schafft man es unter PowerVM, beim Verkehr "nach außen" über eine Messagebuffer-Implementierung mit dem Hypervisor und von dort aus per DMA mit der Netzwerkkarte zu sprechen, das kommt dem von Ihnen beschriebenen Ideal sehr nahe.  Aber da konfiguriert man sich die Finger wund.

UND:  Es gab bei IBM massive Probleme mit korrumpierten IP-Headern, wenn man so frech war und VLANs verwendete.  Klar gab es hastige Fixes, nur:  Wann wollen Sie die installieren, wenn weltweit 24/7 auf die Systeme zugegriffen wird ?   Mit viel Glück schafft man es am Sonntagvormittag, und wehe, wenn so ein Update dann schiefgeht.

Es gibt sogar Anwendungen bei denen RAM-Zugriffe auf entferne Maschinen ohne Betriebsystembeteiligung stattfinden können.. RoCE (RDMA over Converged Ethernet).

Ja, schon lange.  Auf den toooooooodlangweiligen, altmodischen IBM AS/400.

Natürlich mit einigen Restriktionen.  Habe ich aber noch nicht in der Hand gehabt.

Dazu braucht man aber natürlich ein "antwortfreudiges" OS, welches nur wenige Dutzend Taktzyklen für einen Kontextwechsel braucht.  Und nicht tausende wie bei den altmodischen Linux- und Windows - Kerneln.

Der Overhead für die Netzwerkvirtualisierung ist minimal, vor allem im Vergleich zu den Laufzeiten die man auf dem physikalischen Medium hat. Gerade "bessere" Netzwerkkarten können viel davon auch in Hardware abbilden

... wenn man sie läßt.

Open Source

Dank OpenSource Software und der Beteiligung der großen Hyperscaler, kann man heutzutage für um die 10-15k€ Hardware kaufen und kostenlose Software verwenden um einen Hoch verfügbaren Virtualisierungscluster zu bauen. Ich finde man kann sich nicht beklagen.

Wenn man sich auskennt und sowohl bereit als auch in der Lage ist, Verantwortung zu übernehmen:  OK.

Würde man das mit Enterprise Hardware / Software machen, also z.B. mit VMWare und den ganzen modulen die man für die Hochverfügbarkeit braucht + einem Storage Array, ist man eher bei 100k€+ denke ich..

---

Aber nix als Ärger damit.  Ist ja ein "de-facto-Standard" wie "Exchange", muß ja jeder haben.  Richtig teuer, stets klagen Anwender über massive Performanceprobleme trotz top-notch-Hardware, also nicht "Dell" oder "Wortmann", sondern HP.

Vom Feeling her ist es in manchen Umgebungen so, als stammte alle Anwendungssoftware von DATEV.

Für eine Steuerberatungskanzlei hören mit der Wirrtualisierung die Probleme nicht auf, sondern sie fangen an.

Um 2010 gab es schöne Bladecenter, die hatten ein eingebautes SAN mit konfigurierbarem Storage, eingebaute Hochleistungsswitches und ein zentrales Management.  DAS war eine tolle DATEV-Maschine.  Gibt es aber leider nicht mehr.

Nochmals vielen Dank für den sehr erhellenden Artikel, der mich noch zu einigen Recherchen veranlaßt.