Hyper V - VM - Festplatte?

Apfel schrieb:
> Ich habe eine SQL Datenbank diese soll eigentlich immer auf einer
> eigenständigen Festplatte laufen.

Sagt wer? Obacht: Manche bezeichnen D: als Festplatte, egal wo und 
worauf es liegt, verwechseln das also mit einem Filesystem.

Ich würde es mal so formulieren: Eine intensiv genutzte Datenbank, die 
auf einer HDD platziert wird, sollte wenns geht nicht zusammen mit 
anderen intensiv auf Disk zugreifenden Anwendungen auf der gleichen HDD 
landen. Wenn die VM aber eine VDisk auf SSD verwendet, kannst du solche 
Tips von anno dunnemal getrost ignorieren.

Eine virtuelle Festplatte ist nichts weiter als eine Datei, die wiederum 
auf einem physischen Laufwerk des VM-Hostes liegt. Auf welchem 
Hostlaufwerk, läßt sich i.d.R. frei konfigurieren oder später auch 
verschieben, der virtuelle Server bekommt davon nichts mit. Es kann 
durchaus Sinn machen, die virtuellen Platten auf verschiedene physische 
Hostlaufwerke zu legen, wenn die virtuellen Server sehr plattenlastig 
arbeiten. Wie A.K. schon richtig bemerkt hat, spielen die Zugriffszeiten 
bei SSDs kaum eine Rolle, aber bei klassischen HDDs sieht das anders 
aus. Und wenn häufig sehr große Dateien bewegt werden müssen, rückt auch 
die Dauertransferrate ins Licht. Das Ganze ist extrem 
verwendungsabhängig, Pauschaltips sind eher schwierig.

svensson schrieb:
> Eine große, produktive Datenbank würde ich ohnehin niemals in einer VM
> laufen lassen, weil die VM leicht selbst ein Flaschenhals werden kann.
> Von Ausfallsicherheit und Managementproblemen ganz zu schweigen...

Was ist für dich "gross"? Zudem sind "gross" und "hoch belastet" 
unabhängige Parameter.

Ausfallsicherheit und Management kann in VMs einfacher implementiert 
sein, als direkt auf realer Hardware.

> Wenn die Datenbank langfristig gebraucht wird, dann würde ich von
> Virtualisierungen stark abraten, zumal die ganze Software meistens mehr
> kostet als ein zusätzlicher physischer Server.

Man sollte die Gesamtsituation betrachten. Hat man hunderte von VMs auf 
einer Handvoll Virtualisierungshosts laufen, mit VDisks auf NAS/SAN? 
Oder geht es um 2 Server insgesamt, mit lokalen Disks?

Wir haben mittlerweile sämtliche selbst gehosteten DBs auf einem 
zentralen hochverfügbaren Storage-System und sämtliche DB-Server in der 
Virtualisierung. Teils über VDisks auf NFS, teils über NFS direkt.

svensson schrieb:
> Eine große, produktive Datenbank würde ich ohnehin niemals in einer VM
> laufen lassen, weil die VM leicht selbst ein Flaschenhals werden kann.

Virtualisierung ist Stand der Technik und funktioniert mittlerweile sehr 
stabil und performant. Ich habe gerade erst ein konventionelles System 
aus mehreren (Blech-)Servern (1x DC/Fileserver, 1x SQL-Server, 4x 
Terminalserver) virtualisiert. Jetzt läuft alles auf einem einzigen 
physischen Server, ohne Performanceeinbußen. Im Gegenteil, die gefühlte 
Arbeitsgeschwindigkeit hat sich sogar verbessert, wozu die SSDs für 
System und Programme sicher beitragen. Als Datengrab dient aus 
Kostengründen ein RAID10 aus 8 klassischen HDDs.

> Von Ausfallsicherheit und Managementproblemen ganz zu schweigen...

Das ist eher ein Argument PRO Virtualisierung. Redundanz läßt sich 
wesentlicher einfacher realisieren und das Management erst recht. Mal 
schnell einen (virtuellen) Server sichern? Einfach die virtuellen 
Festplatten irgendwohin kopieren. Geht problemlos auch per Fernwartung. 
Keine Turnschuhadministration mit Imaging-Software oder Streß mit 
RAID-Controllern mehr. Hardwaretausch nötig? Virtuelle Maschinen und 
Platten sichern, Host neu aufsetzen, alles zurückkopieren, fertig. Kein 
Streß mit nicht booten wollenden Maschinen oder Treiberinstallationen.

> Wenn die Datenbank langfristig gebraucht wird, dann würde ich von
> Virtualisierungen stark abraten, zumal die ganze Software meistens mehr
> kostet als ein zusätzlicher physischer Server.

Siehe vorstehend, Performanceprobleme sind nicht zu befürchten. Und 
Kosten auch nicht. Hyper-V ist Bestandteil jeder Standard Windows-Server 
Lizenz. Mit einer einzigen Lizenz dürfen sowohl der Host als auch zwei 
virtuelle Server betrieben werden. Und eine weitere Lizenz kostet nicht 
mehr als ein Desktop-Rechner.

Apfel schrieb:
> Ich habe eine SQL Datenbank diese soll eigentlich immer auf einer
> eigenständigen Festplatte laufen.

Immer sinnvoll: Produktive potentiell wachsende Daten mitsamt ihrer 
Temp- und Logfiles sollten auf einem separaten Filesystem liegen. Also 
in Windows sowas wie C: fürs System und D: (oder mehr) für die Daten. 
Weil voll laufende Daten dann nicht zum Problem für die Wartung vom 
System werden.

A. K. schrieb:
> Immer sinnvoll: Produktive potentiell wachsende Daten mitsamt ihrer
> Temp- und Logfiles sollten auf einem separaten Filesystem liegen. Also
> in Windows sowas wie C: fürs System und D: (oder mehr) für die Daten.

Und das Ganze natürlich auch auf getrennten virtuellen Festplatten, 
nicht etwa als Partitonen auf einer.

Das wird sicherlich kein zentrales Argument von Virtualisierung sein, 
aber angenehm ist es: Ein virtueller Linux-Server legt in 20 Sekunden 
einen vollständigen Reboot hin. Der Virtualisierungshost selbst braucht 
dafür 5 Minuten, die meiste Zeit geht in Selbsttests und Firmware von 
I/O-Modulen drauf.

Das erspart so manche Überstunde. Etliche VM kann ich bei dieser kurzen 
Unterbrechung zu günstigen Zeiten tagsüber aktualisieren, ohne dass es 
gross auffällt. Um den Host selbst zu aktualisieren, schiebe ich seine 
VMs unterbrechungsfrei auf seine Kollegen und habe ihn dann frei.

svensson schrieb:
> die DC zu virtualisieren, wovon selbst M$ abgeraten hat.

Ja, aber das ist Vergangenheit. Heute kein Problem mehr. Einer der 
AD-Server liegt bei uns nur deshalb direkt auf übrig gebliebener alter 
Hardware, damit man im Extremfall kein Münchhausen sein muss. Bei AD/DNS 
und DHCP wärs besser, wenn man vorneweg rankommt. Wir werden diese 
redundanten Sekundärserver aber wahrscheinlich auf einen separaten und 
voll selbständigen kleinen Virtualierungshost konzentrieren.

> jedenfalls solange bis der berühmte Murphy den single-point-of-failure
> gefunden hat, dann gibt es aber lange Gesichter.

Mit Virtualisierung löst man die Verfügbarkeitsfrage einmal, indem man 
Virtualisierungsplattform bis runter zu Storage und Netzwerk 
entsprechend auslegt. Ohne Virtualisierung löst man sie für jeden Server 
erneut, und möglicherweise bei jedem auf andere Art. Ist natürlich eine 
Frage der Grösse der Umgebung.

svensson schrieb:
>> Wir werden diese Funktionen aber wahrscheinlich auf einen separaten und
>> voll selbständigen Virtualierungshost konzentrieren.

> Die Ironie in diesem Satz bleibt Dir hoffentlich nicht verborgen...

Wenn man mehrere ADCs und DHCPs hat, und jeweils einer davon auf Blech 
liegt, kann man dieses Blech auf einen separaten Virtualisierungshost 
mit lokalen Disks legen, ohne dass die Verfügbarkeit zu riskieren. 
Wichtig ist dabei nur, dass dieser Host unabhängig von NAS und der 
übrigen VMware-Infrastruktur ist.

> Da kann man eben auch gleich einen physischen Server nehmen, bei dem die
> Komplexität mit der Virtualisierung entfällt.

Wenn es bei einem einzigen bleibt...

> Und ich würde gerne sehen, wie die 50 TB eines Fileservers schnell von
> einer VM zur anderen transferiert werden.

Der Fileserver ist ein hochverfügbares NAS, das sich redundant auf 2 
getrennte Gebäude verteilt. Als Fileserver wird er direkt verwendet, die 
VDisks der VMs liegen dort via NFS. Crasht ein Virtualisierungshost, 
werden dessen kritische VMs automatisch auf den anderen Hosts neu 
gestartet.

Verschoben wird für Wartung eines Hosts nur der laufende Kontext einer 
VM, nicht deren Disks, so dass es bei einer laufenden VM je nach 
Aktivität nur Sekunden bis wenige Minuten dauert und dabei vom Anwender 
nicht bemerkt wird. Solche Migration findet zwecks Load Balancing auch 
automatisch im Normalbetrieb statt.

> Klingt nach Consultant, da ist immer alles kein Problem.

Bin Anwender seit VMware ESXi 1.5

>> Ist natürlich eine Frage der Grösse der Umgebung.
>
> Und vor allem eine Frage des Geldes.

Grösse und Geld gehen Hand in Hand. Neben Beschaffungs- und 
Wartungskosten spielen aber auch Gehälter eine Rolle. Virtualisierung 
spart Admins. In grösseren Umgebungen ist das günstiger als hunderte 
Server in Blech.

Zudem spielt natürlich auch eine Rolle, mit welcher Ausfallzeit man 
leben kann. Wenn einem Bäcker abends zentrale Geräte abrauchen und 
sämtliche Filialen tags drauf nix zum beissen anbieten können, fällt das 
unangenehm auf. Stellt man Streichhölzer her, kann man das gelassener 
angehen.

svensson schrieb:
> Ausfallsicherheit, Hochverfügbarkeit, Cluster. Alles schön und gut,
> jedenfalls solange bis der berühmte Murphy den single-point-of-failure
> gefunden hat, dann gibt es aber lange Gesichter.

Man kann die Systeme durchaus vollständig redundant auslegen, sodaß der 
Ausfall einer beliebigen Komponente nicht zur Beinträchtigung des 
laufenden Betriebes führt. Ja, das kostet Geld und ja, das kostet 
Hirnschmalz. Deswegen wird es nur in Umgebungen gemacht, wo 
Hochverfügbarkeit wirtschaftlicher ist als die Inkaufnahme von 
Ausfallzeiten. Alle anderen Systeme haben ganz zwangsläufig SPOFs. In 
einer virtualisierten Umgebung streikt die Hardware des VM-Hostes, 
System fällt aus. In einer konventionellen, nicht redundanten Umgebung 
streikt der Domänencontroller, System fällt aus. Der Datenbankserver 
streikt, alle darauf basierenden Anwendungen fallen aus (geht also nicht 
mehr viel außer im Internet surfen). Der Terminalserver streikt, System 
fällt aus, außer man hat mehrere TS. Macht für die Verfügbarkeit also 
keinen Unterschied, ob virtualisiert oder Blech. Interessant wird es bei 
der Wiederherstellung des Systems. Habe ich Carepacks für die 
Serverhardware, rufe ich beim Support an und die kümmern sich um die 
Reparatur. Habe ich keine Carepacks, muß ich bei klassischem Blech 
entweder Ersatzteile vorhalten oder diese kurzfristig beschaffen können. 
Letzteres kann schon nach wenigen Jahren zum Problem werden. Besorg mal 
Ersatz für ein drei Jahre altes Servermainboard. Inzwischen haben sich 
die CPU-Sockel geändert und meist sind auch die RAM-Module nicht 
kompatibel. Du mußt also neuere Hardware verbauen, die andere Treiber 
erfordert und hast oft Streß, den Server wieder zum Hochfahren zu 
überreden (ja, ich kenne das). Hast du obendrein keine 
Baremetal-Sicherung und es geht richtig schief, dann gute Nacht.
Mit virtualisierten Servern ist neue Hardware völlig unkritisch. 
Lediglich der Host muß installiert werden, das dauert im Normalfall 
keine Stunde. Danach die VMs wieder drauf und los gehts. Im Extremfall 
kann ich sogar einen Notbetrieb auf Desktophardware improvisieren.
Die technischen Vorteile der Virtualisierung überwiegen ganz klar. Und 
sie spart noch dazu Kosten. Denn ich brauche sowohl weniger physische 
Maschinen als auch weniger Lizenzen, denn auf Blech benötigst du für 
jeden Server eine separate Lizenz, bei VMs genügt eine für zwei 
virtuelle Server.
Mir fällt echt kein Argument ein, weshalb man heutzutage nicht 
virtualisieren sollte.

svensson schrieb:
> Falsch DC, DHCP und DNS existieren redundant als physische Maschinen.

Natürlich kann man auch in virtualisierter Umgebung noch einen 
physischen Backup-DC integrieren. Da sind wir aber schon auf dem Weg 
Richtung Redundanz.

> Ja, einzelne Dienste können ausfallen, aber die meisten bleiben
> funktionsfähig.

Bei den meisten meiner Kunden bewirkt schon der Ausfall nur eines 
wichtigen Servers annähernde Arbeitsunfähigkeit. Ohne Fileserver keinen 
Zugriff auf Userprofile und allgemeine Daten, ohne Datenbankserver keine 
Arbeit mit der Branchensoftware und ohne Terminalserver auch nicht. Mit 
einem Backup-DC können sich die Leute noch anmelden, es nützt ihnen aber 
nichts.

> Genau deshalb habe ich z.B. die Festplatten lagernd.

Festplatten sind nicht das Thema, da leicht beschaffbar. Größer als die 
alte geht immer. Aber hast du auch Mainboards, Speicherriegel und 
Controller auf Lager?

> Und dann ist die neue Hardware plötzlich nicht mehr für die alten
> Versionen zertifiziert (oder es fehlen gar Treiber)

Der Supportzeitraum für Betriebssysteme ist i.d.R. wesentlich länger als 
der Produktlebenszyklus von Hardware. CPU- und Mainboardgenerationen 
werden gewöhnlich nach 2-3 Jahren obsolet und baugleiche Mainboards sind 
oft schon nach wenigen Monaten nicht mehr erhältlich. Für Windows 
Betriebssysteme läuft die Unterstützung mindestens 5 Jahre, praktisch 
eher 10 Jahre. Für die virtuellen Maschinen spielt es außerdem keine 
Rolle, auf welcher Hardware und unter welchem OS der Hypervisor läuft, 
solange er die gleiche virtuelle Umgebung emuliert.

> Auch hier gibt es viele Fallstricke.

Nicht wirklich viele. Auf jeden Fall um Größenordnungen weniger als bei 
physischen Maschinen.

> Was zu beweisen wäre. Meist ist die "ausfallsichere Hardware" deutlich
> teurer als zwei Standardgeräte.

Was ist ausfallsicher? Redundante Netzteile und Festplatten sollten bei 
Servern selbstverständlich sein, alles andere ist ohnehin nur einmal da. 
Natürlich kommt ein fetter, als VM-Host geeigneter Server teurer als ein 
anwendungsspezifischer und weniger leistungsfähiger. Aber bei rein 
physischer Struktur brauchst du eben für jeden Server ein eigenes Blech. 
Und die werden in der Summe wieder teurer als der dicke Brummer.

> Lizenzen bekomme ich umsonst, das ist kein Argument.

Das ist für dich kein Argument, für den normalen Anwender schon. Siehe 
meinen oben beschriebenen Praxisfall. Für 6 physische Server müßte ich 6 
Lizenzen kaufen. Bei einem physischen Gerät und 6 VMs brauche ich nur 
drei. Ergibt eine Ersparnis von fast 2000€ allein bei den Lizenzen.

> Wenn womöglich noch "Externe" eingekauft werden müssen,
> dann wird das richtig teuer.

Firmen ohne eigenen Admin müssen das unabhängig von der Struktur 
sowieso. Die Zeiten, wo ein Mitarbeiter, "der was von Computern 
versteht", das System nebenbei administrieren konnte, sind schon lange 
vorbei. Da Virtualisierung den Administrationsaufwand verringert, ergibt 
sich auch hier Kostenreduzierung.

Icke ®. schrieb:
> Natürlich kommt ein fetter, als VM-Host geeigneter Server teurer als ein
> anwendungsspezifischer und weniger leistungsfähiger. Aber bei rein
> physischer Struktur brauchst du eben für jeden Server ein eigenes Blech.
> Und die werden in der Summe wieder teurer als der dicke Brummer.

Heutige Prozessoren sind sehr oft wesentlich leistungsfähiger als 
einzelne Server benötigen. Ob ADC oder DHCP auf 2 Cores oder 4 läuft 
merkt niemand, weshalb man auf einem Minimal-Host mit 4 Cores - kleiner 
gibts schon lange nicht mehr - etliche VMs betreiben kann. Dicker wird 
nur das RAM.

Wenn alle VMs einer nicht-trivialen Umgebung einzeln als Blech 
implementiert werden, dann steckt sehr viel mehr Geld drin als in einem 
diese Umgebung abdeckenden Virtualisierungshost (*). Jedes Stück Blech 
hat dann mindestens 4 sich meist langweilende Cores, 3 
Netzwerkanschlüsse (1x Management, 2x Anbindung), 2 Netzteile, genug 
Switches für die Netzwerk-Anschlüsse, Racks fürs Blech, Platz für die 
Racks, dicke Kabelbündel und Patchpanels, ...

Der Virtualisierungshost dafür hat 1-2 HEs, keine Bootdisk (µSD oder 
USB-Stick), 3-5x Netzwerk, dafür aber genug RAM. Als ich das letzte mal 
nachsah, kriegte man in einen normalen 1 HE Server 1,5 TB RAM rein. Als 
einzelnen Server kriegt man heute wohl kaum etwas unter 8 GB, ob man die 
braucht oder nicht. Dem DHCP-Server reichen aber 2 GB locker aus. Somit 
ist auch die Summe an RAM virtualisiert geringer als in Blech, noch 
völlig ohne Deduplication von RAM und Paging auf Hypervisor-Ebene 
gerechnet.

*: Betriebssystem-Kosten auch. Mit Windows als Datacenter-Edition sind 
alle VMs eines Hosts abgedeckt, und bei Linuxen wie Redhat oder Suse 
sieht es ähnlich aus. Nur Oracle sollte man grossräumig umfahren, deren 
Lizenzierung ist einfach nur grotesk.

svensson schrieb:
>> 3 Netzwerkanschlüsse (1x Management, 2x Anbindung)

> Na und? Die kosten doch nichts, weil auf dem Mainboard enthalten.

Auf der Server-Seite nicht. Dafür aber auf der anderen Seite, also in 
Form von Switch-Ports und Verkabelung. Das läppert sich.

> Wohingegen eine 4-Port-ESX-fähige schon einmal 1000 Euro kosten kann.

Wenn man unterhalb der oben beschriebenen Enterprise-Umgebung in der 
Zentrale bleibt, reicht das aus, was der Server mitliefert. In 
Aussenstellen steckt die kleinste Kiste, die damals verfügbar war: 4 
gelangweilte Cores und von 3 Ethernets onboard werden nur 2 genutzt.

Die in der Zentrale sind etwas besser ausgerüstet, aber wenn du einige 
hundert aktive VMs auf einer Handvoll Hosts laufen lässt, sind auch die 
Kosten für 2x 10Gb Ethernet pro Host drin.

> Der Serverraum ist ohnehin vorhanden.

Einer davon wurde vor ein paar Jahren halbiert, weil Platz knapp und 
dank Virtualisierung und zentralem Storage halb leer.

> Und ein managebarer Switch pro
> Rack ist selbst von CISCO aus der Portokasse bezahlbar. Und ein/zwei
> Kabel pro Server ist noch kein Kabelbündel...

Bei einigen hundert Servern?

> Und wenn dann alle drei Jahre die teure Hardware erneuert werden
> muß, weil ja kein Support mehr da ist

Gekauft mit 5 Jahren Support. Es gibt Firmen, die Hardware-Service 
darüber hinaus anbieten und das nutzen wir auch. Die älteren der 
zentralen Hosts haben CPUs von 2012. Dem geplanten Ersatz kam Spectre in 
die Quere, statt dessen kamen 2 in anderer Rolle ausgemusterte Altserver 
hinzu.

Bei den Servern der Aussenstellen lebte die letzte Generation 10 Jahre. 
Bei zweistelliger Anzahl hat man dann eben Reserve im Lager.

Ersatzteile und Erweiterungskomponenten für ältere Server gibts günstig 
bei Ebay und anderen Leichenfledderern, wenn nicht zu exotisch. Haben 
wir auch schon öfter genutzt.

> Maschine vereint zu gefählich sind, dann landet die ganze Matsche
> schließlich in der Cloud -> Admin überflüssig.

Yep. Kenne ich aus anderer Firma gleicher Branche und Grössenordnung. 
Wer braucht schon immer Festnetztelefonie (ist in der Cloud), notfalls 
wird halt gemailt oder gechattet. Und für den Fall, dass das auch in der 
Cloud ist gibts Mobiltelefone. Zum fairen Ausgleich ist das teuer als 
bei uns und wird mit grösserer Mannschaft betrieben. ;-)

> * Nur im SAN ist ein Mainboard kaputtgegangen, das dann wochenlang um
> den Globus unterwegs war = da standen dann die virtualisierten
> Maschinen.

Wie Icke schon beschrieb: Wenn Host FUBAR und es ist eilig, dann nimmt 
man einen anderen. Muss nicht identische Hardware sein. Egal ob Intel 
oder AMD, nur bei der Live-Migration ist das wichtig.

svensson schrieb:
> Ja, aber der "Virtualisierungsexperte" ist eben teurer als der normale
> Admin.

Kann ich nicht bestätigen. Ob ich ein AD auf einem physischen oder 
virtuellen Server aufsetze, nimmt sich vom Anspruch her nichts. Den 
Hypervisor zu installieren und die VMs anzulegen, ist jetzt auch nicht 
sooo kompliziert. Wer in der Lage ist, Netzwerke auf physischer Struktur 
zu administrieren, wird auch kein Problem damit haben, sich das für 
Virtualisierung nötige Zusatzwissen nebenbei autodidaktisch anzueignen. 
Jedenfalls sind die Stundensätze bei mir die gleichen, egal ob physisch 
oder virtuell.

> Und wenn dann alle drei Jahre die teure Hardware erneuert werden
> muß, weil ja kein Support mehr da ist und alle Dienste auf einer
> Maschine vereint zu gefählich sind, dann landet die ganze Matsche
> schließlich in der Cloud -> Admin überflüssig.

Wenn aus Kostengründen Dienste in die Cloud verlagert werden, ist 
bestimmt nicht die Virtualisierung schuld. Denn die ist im Endeffekt 
billiger als eine Blechfarm. Allerdings könnten sich Admins, die nicht 
mit der Zeit gehen, entbehrlich machen ;-)