neuen Windows Server virtualisieren ja/nein? [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : neuen Windows Server virtualisieren ja/nein?

keats

2018-03-25, 14:37:20

Hallo,

vor einer Weile habe ich hier einen Thread verfolgt, in dem propagiert wurde, auch in simplen Szenarien auf Virtualisierung zu setzen. Wenn ich es richtig im Kopf habe, war das nicht das ursprüngliche Thema des Threads, sondern ein Nebenprodukt. Leider finde ich den nicht mehr.

Folgende Situation:

Neuer Server mit Xeon E3-1275v6 (4C/8T), 32 GB DDR4-2400 ECC und SSD. Darauf soll laufen Windows 2016 Standard und SQL Server 2017 Standard. Außerdem dient das Gerät als Dateiserver. Edit/Nachtrag: Mainboard Supermicro X11SSM-F, 2x Intel S4500 960GB SSD im RAID1, 2x WD RED 2GB im RAID1

Die SQL-Datenbank eines Warenwirtschaftssystems ist ca. 8 GB groß und wächst mäßig bis langsam. Es gibt 20 Clients, wobei nicht mehr als 50% gleichzeitig darauf arbeiten. Der Dateibestand ist ca. 30 GB groß, wobei es fast ausschließlich Archivmaterial ist, ansonsten nur diverse Office-Dateien der Nutzer.

Frage:

Ist es sinnvoll, in so einem Szenario den Server zu virtualisieren?

Ich sehe natürlich den Vorteil, dass man die VM bei einem Defekt schnell woanders anhängen kann. Auf der anderen Seite ist der Server keine Rakete, so dass sich Host und VM ggf. um die Ressourcen streiten. Gibt es irgendwelche Best Practices, wie man mit der Frage heute umgeht?

Danke
keats

Blase

2018-03-25, 21:25:01

N'abend!

Auch wenn die ursprüngliche Aussage bezüglich der Virtualisierung nicht von mir stammt - ich würde sie so unterschreiben. Ich kann mir kaum ein Szenario vorstellen (vielleicht einen zusätzlichen DC in Hardware?!), wo ich NICHT virtualisiere.

In deinem Szenario - ist das der einzige Server im Netzwerk? Keine Domäne? P2P Netz mit 20 Usern?

Grundsätzlich ist ein Hyper-V Host ja nur Hyper-V Host ist Hyper-V Host :wink:

Und mit einer Windows Server 2016 Standard Lizenz kannst/darfst du ja auf dem selben Host bis zu zwei virtuelle Maschinen - mit der selben Lizenz - betreiben.

Also er selbst braucht dann eigentlich kaum (eigene) Ressourcen. Vielleicht 4 GB RAM und die vCPUs können/dürfen ja sogar über allokiert werden - also hast du auch hier kein Problem. Und die SSD(s) (zwei im RAID 1, hoffe ich!) haben so oder so genügend Dampf. Zur Not wählst du die Datenträger nicht dynamisch sondern fix - damit hast du die SSD Performance dann quasi 1:1 in der VHDX zur Verfügung - und nur hier wird sie benötigt.

Also aufgrund der Vorzüge virtueller Maschinen - und weil die Einrichtung des Hyper-V Hosts vielleicht max. zwei Stunden dauert - würde ich auch in deinem Szenario virtualisieren...

Gruß
Blase

Joe

2018-03-25, 21:48:39

Es gibt ganz ganz wenig Szenarien, in denen ich nicht virtualisieren würde.
Beispielsweise wenn hochspezialisierte Hardware verbaut ist (ISDN Karten / Hardware Dongle etc.) oder wenn Du ein System hast, aus dem Du echt das letzte Promille an Leistung rauszutzeln willst.

In deiner Umgebung würde ich vermutlich sogar den SQL auf einer separaten VM installieren.
Die Richtige Stärke von VMs merkst Du halt erst, wenn die Kacke am dampfen ist. Eine VM vom Backup zu ziehen ist halt völlig stressfrei, sogar auf komplett andere Hardware. Und selbst wenn du ein System erneuerst, können VMs viel zeit sparen.
Sagen wir mal in sechs Jahren willst Du deinen Fileserver erneuern. Wenn Du jetzt schon so schlau bist, für die Daten eine separate VHD zu erstellen musst du später nicht terrabyte-weise Zug rumkopieren, sondern kannst die VHD einfach an die neue VM mounten.

Unter Hyper-V kann ich als Backup übrigens Altaro VM Backup sehr empfehlen. Ist bis zu zwei VMs praktischerweise kostenlos und macht genau das, was man erwartet. Wir machen inzwischen eigentlich alles mit VMware, dort ist Altaro leider nicht so stark :(

qiller

2018-03-25, 22:59:55

Kann Joe nur zustimmen. Imho ist die Hardwareunabhängigkeit DAS Hauptargument für Virtualisierung. Manche bringen noch das Thema Sicherheit auf den Plan. Nach Meltdown/Spectre sollte aber nun jedem einleuchten, dass Virtualisierung kein Sicherheitsfeature ist. Hardwareunabhängigkeit reicht mir allerdings vollkommen, denn Hardware geht immer irgendwann kaputt. Ein Recovery ist mit VMs schneller durchgeführt.

keats

2018-03-25, 23:16:13

Danke für die Rückmeldungen!

Ich habe oben die Hardware im Detail ergänzt. 2x Intel S4500 960GB SSD im RAID1 und 2x WD Gold 2GB im RAID1. Die Platten haben keinen ganz konkreten verplanten Zweck. Wenn ich virtualisiere, würde ich den Hyper-V auf zwei zusätzlichen Intel S3500 120GB SSD im RAID1 installieren, die hier noch mit wenigen Betriebsstunden liegen. Ist ein 4U Gehäuse, da ist genug Platz.

DC ist ein rund 5 Jahre alter Windows 2008 R2 Server. Der ist auch eines der Backup-Ziele des Hauptservers. Und dann gibt es noch einen alten Windows 7 "Server", auf dem Kerio Connect als Mailserver im Clientmodus läuft. Das wäre eigentlich ein lohnendes Ziel für die zweite VM-Lizenz und die Platten, dann als echter Mailserver.

Dongle gibt es zum Glück nicht mehr.

Altaro VM Backup hatte ich mir schon einen Link gespeichert. :)

Aber dann werde ich dem so folgen. Ich hatte hauptsächlich bzgl. der Performance bedenken und keine praktischen Erfahrungen zum Vergleich. Aber wenn das in dem Szenario kein Thema ist, würde ich schon gerne damit arbeiten. Alleine die Backups und schneller Umzug sind ja in der Tat handfeste Argumente.

Danke!

Brechreiz

2018-03-25, 23:22:45

Kann den anderen auch nur zustimmen. Pro Virtualisierung.
Lizenztechnisch ist es eh egal ob ihr nur 1x SRV2016 oder noch eine zweite Lizenz habt. Ihr müsst immer 16 Cores lizenzieren.
Hier werden eher die CALs für den SQL Server das teure werden.

Als Tip: 1x VM für das Warenwirtschaftsystem, ggf. mit dem SQL Server. 1 für den Fileserver. Den VM's nicht mehr wie 2 virtuelle CPUs geben und nur 80-90% des Ram des Host. Das lastet den Server so sogar besser aus.
Wenn alles auf das SSD Raid passt, dann alle VMs dort und das Raid-1 der Red als lokalen Backup-Store nutzen.

myMind

2018-03-25, 23:40:21

Neuer Server mit Xeon E3-1275v6 (4C/8T), 32 GB DDR4-2400 ECC und SSD. Darauf soll laufen Windows 2016 Standard und SQL Server 2017 Standard. Außerdem dient das Gerät als Dateiserver. Edit/Nachtrag: Mainboard Supermicro X11SSM-F, 2x Intel S4500 960GB SSD im RAID1, 2x WD RED 2GB im RAID1

Die HDD könnte größer sein :D
Nee, Hardware passt schon.

Die SQL-Datenbank eines Warenwirtschaftssystems ist ca. 8 GB groß und wächst mäßig bis langsam. Es gibt 20 Clients, wobei nicht mehr als 50% gleichzeitig darauf arbeiten. Der Dateibestand ist ca. 30 GB groß, wobei es fast ausschließlich Archivmaterial ist, ansonsten nur diverse Office-Dateien der Nutzer.

Frage:

Ist es sinnvoll, in so einem Szenario den Server zu virtualisieren?

Ich sehe natürlich den Vorteil, dass man die VM bei einem Defekt schnell woanders anhängen kann. Auf der anderen Seite ist der Server keine Rakete, so dass sich Host und VM ggf. um die Ressourcen streiten. Gibt es irgendwelche Best Practices, wie man mit der Frage heute umgeht?

Bei Virtualisierung sollte der Host sich gar nicht mit irgendwem streiten. Er sollte nur virtualisieren, dafür wenig Resourcen benötigen und diese aber mit Priorität erhalten. Wenn der Host was anderes macht als virtualisieren, dann bitte zurück auf Los und erstmal über Virtualisierungs-Grundlagen Informieren. IMO einer der großer Vorteil von VMware ESX, wo man gar nicht erst auf dumme Ideen kommt.

Die Hardware sollte locker ausreichen. RAM Steckplätze sind hoffentlich noch frei. Da würde ich irgendwann die ersten Bottlenecks erwarten. Bei den aktuellen Anforderungen sollte es aber passen.

IMO die größten Nachteile sind:
- Minimaler Overhead / Performancenachteile durch Virtualisierung
- Man muss die Virtualisierungs-Materie erlernen.
- Es gibt neue Fehlerquellen, die eben besonders dann zum tragen kommen, wenn man sich nicht auskennt.
- Laborsysteme an denen man die Virtualisierung üben kann, sind oft nicht mehr im Budget. Würde ich aber dringend empfehlen. Muss ja nichts dolles sein

Aber die Vorteile sind eben auch nicht zu verachten:
- Appliances, also ein Dienst pro System, machen Updates / Migrationen erheblich einfacher.
- Die Fehlersuche ist viel leichter, wenn weniger Dienste pro System laufen. Versuch mal ein sauberes Eventlog hinzubekommen, wenn viele Dienste auf deinem System laufen.
- Kritische Dienste werden nicht zu Downtimes gezwungen, weil irgendein anderer Dienst ein Update mit Reboot erzwingt.
- Skalierung ist in gewissen Grenzen viel einfacher. Neuer Recher > VM verschieben > fertig.
- Tests / Probeläufe bestimmter Dinge sind durch VM Kopien überhaupt erst möglich.
- Snapshots ermöglichen mehrfaches Ausprobieren / Proben.
- Man kann risikolos auch mal was Neues auf einer separaten VM probieren ohne extra Hardware anschaffen zu müssen.
- Neue Backup / Disaster-Recovery Optionen auf VM ebene. Wobei man bei Datenbanken u.ä. wo Datenkonsistenzen eine Rolle spielen vorsichtig sein muss.

Eine Best-Practice ist heute ein System, ein Dienst, wobei die nächste Stufe nach der Virtualisierung dann die Containerisierung darstellt. Aber die Windows-Welt ist da noch etwas hinten dran.

Wie man das jetzt scheidet, kann man sich von Fall zu Fall überlegen. Die wichtigsten Domänendienste würde ich immer isoliert betreiben und definitiv getrennt von einem SQL-Server, File-Server o.ä..

Gerade in kleineren Installationen kann man mit zwei VM-Hosts schon ein redundantes Active Directory hinbekommen, dass dann auch noch die eine oder andere Appliance in einer VM hostet. Das ist schon ein sehr effizientes Modell. Wenig Hardware plus viel Flexibilität und Ausfallsicherheit in gewissen Grenzen ist möglich.

Du hattest jetzt nur die Dienste "Dateiserver" und "Warenwirtschaftssystems / SQL Server" geschrieben. Wenn es wirklich nur um diese beiden Dienste geht, dann würde ich sagen die Virtualisierung müsste nicht unbedingt sein. Aber ich glaube das nicht so richtig. Keine Domäne? Kein Mailserver? Kein CMS / VCS / Wiki / Clientbackup ... Und dann wird es halt sehr schnell interessant.

Haarmann

2018-03-26, 05:40:58

keats

Nicht virtualisieren für so eine Aufgabe.

Weil laut Vorschrift kannst es eh nicht richtig machen mit nur 2 VMs.

1 VM DC
1 VM SQL
1 VM Fileserver

Damit hast eine zuviel und die Resourcenverteilung wird nicht optimal sein.

Ergo klassisches Setup mit einem "AllerweltDC" und einem soliden AD Backup nebst dem Rest.

Ich gehe davon aus, dass Du den SQL via die WaWi bekommst.

Ergo ist das wie SAP B1 und da hast mit dem Setup weit mehr Leistung - aber die Fragen, die ich mir stelle.

Wenn die DB so klein ist, warum sind die SSDs so gross und langsam?

Nutzt Du InMemory vom 2017?

Welches Backup ist vorgesehen?

keats

2018-03-26, 09:59:27

Die Platten sind natürlich 2TB und nicht 2GB. ;) RAM ist 2x 16GB und es sind noch zwei Slots frei für insgesamt maximal 64GB. Die SSD sind bewusst groß gewählt, um Reserve bei der Lebenszeit auch bei mehreren Jahren zu haben. Es müssen aber nicht unbedingt die sein. Im Gegensatz zum Rest sind die bisher nicht angekommen. Könnte ich zur Not sogar noch ändern.

Backups: Beim bisherigen Server werden mit Acronis Backup & Recovery Images erstellt und auf mehrere Ziele verteilt: Platte im Rechner, externe wöchentlich gewechselte Platten, auf den DC und eine lokal AES verschlüsselte Sicherung der reinen Daten ohne Dateiarchiv auf einen Webspeicher bei Strato. Beim neuen würde ich es entweder weiter mit Acronis handhaben oder bei Virtualisierung etwas wie das angesprochene Altaro VM Backup verwenden.

Das Warenwirtschaftssystem ist ein Access-Frontend, das auf den SQL-Server zugreift. Auf dem Server liegt ein Verzeichnis, von dem sich die Clients Updates holen. Im Prinzip ist es aber selber nur eine Client-Installation.

Was andere Server betrifft, gibt es wie gesagt noch einen 2008 R2 DC und ein Windows 7 "Server" mit Kerio Connect als Mailserver im Client-Modus. Auf den Arbeitsplätzen läuft Windows 8.1 Pro x64.

Die neue SQL-Server 2017 Lizenz gibt es nur, weil der Anbieter des Warenwirtschaftssystems offiziell nur noch alles ab 2012 unterstützt. Bestimmte Features waren dabei kein Aspekt, auch wenn ich die Idee von InMemory durchaus interessant finde. Wobei es dann wohl mehr RAM bräuchte oder den Verzicht auf VMs.

Der DC ist 5 Jahre alt und macht keine Probleme. Wir haben keine festen Updatezyklen. Es wird im Prinzip nur getauscht, was keine Sicherheitsupdates mehr bekommt, kaputt ist oder für die User fühlbar zu wenig Leistung hat. Wenn der aber fällig ist, würde er sicher durch etwas Vergleichbares wie der neue ersetzt. Das wäre dann mit VMs natürlich eine wirklich schöne Sache, wenn etwas ausfällt.

Der neue Server muss nicht so schnell wie möglich live sein. Der alte mit Lynnfield Xeon ist nur langsam und die letzten Reserveplatten für die 2 RAID sind aufgebraucht, er funktioniert aber noch. Ich kann auf dem neuen also durchaus erst mal testen. Echte Last kann ich zwar nicht erzeugen, aber schauen, ob ich selber mit der Virtualisierung klarkomme oder irgendwelche Probleme habe.

Joe

2018-03-26, 11:38:19

keats

Nicht virtualisieren für so eine Aufgabe.

Weil laut Vorschrift kannst es eh nicht richtig machen mit nur 2 VMs.

1 VM DC
1 VM SQL
1 VM Fileserver

Fileserver würde ich auf dem DC mitlaufen lassen.
Für eine Umgebung der Größe dürfte das keine Rolle spielen.
Neben dem DC müssen ja auch noch andere Dienste laufen wie z.B. DNS, der GC, die ganzen Betriebsmaster und vermutlich DHCP und WINS.

Noch so als Tipp am Rande: Die Data Dedup von Windows Server ist inzwischen echt klasse. Bekommst durch die Fileserver Rolle und ist so simpel, dass Fehlkonfiguration eigentlich ausgeschlossen ist. Wenn das durchgerödelt ist, schnappst Du Dir "SDelete" von Microsoft und lässt es den freien Speicher durch-nullen (-z). Dann Schrumpft die VHD Größe auf dem Host, wenn Du dynamische VHDs nutzt, was Du unbedingt solltest, weil es seit Server 2012 eigentlich kaum noch messbaren Unterschied in der Leistung gibt.

xiao didi *

2018-03-26, 13:29:54

WINS
Das hat hoffentlich heute keiner mehr in Betrieb.

PHuV

2018-03-26, 14:44:03

ravage

2018-03-26, 17:28:20

Joe

2018-03-26, 17:54:09

Wir hatten hier auch Fileserver, AD-Controller (mit DHCP, DNS, WSUS), DBs virtualisert, und wir devirtualsieren (nach 5 Jahren) wieder.
Gründe:

Update beim AD reißt eben auch alle anderen VMs mit (kein DNS verfügbar)
WSUS lastet Filesystem erheblich aus
Ohne DNS kein Online Update für XenServer möglich
Fileserver belastet Virtualsierer bzgl. File-IO und verlangsamt alle dort laufenden VMs
Produktive Datenbanken sollte man auf Blech laufen lassen, oder zumindest auf einem eigenen Dateisystem mit eigener Platte/SSD

Zuerst haben wir den Fileserver durch ein NAS ersetzt. Aktuell ist der AD dran, hier wird auch gerade ein eigener Server aufgebaut. Bei Spieldatenbanken oder kleine DBs ist eine VM ok, aber für produktiven Einsatz raten wir Kunden immer zu Hardware, und das hat sich auch bewährt.

So unterschiedlich können die Philosophien sein.
Wenn einer meiner Jungs bei einem Kunden Inventur macht und das was Du beschreibst vorfindet, wäre das ein Fall von "das baut man aber seit spätestens 2008 anders....."

XenServer hat IMHO auch nix in normalen Umgebungen verloren. Das Ding ist zu einem einzigen Zweck entwickelt worden: Um große Citrix VDI Umgebungen kostengünstig umsetzen zu können. Nicht mehr, nicht weniger.
Das eine Virtualisierte Umgebung mehr Hardware PS braucht, ist halt auch kein Geheimnis. Liegt ja nicht am riesigen overhead sondern schlicht da dran, dass wenn ein Server die Funktion von fünf Server übernehmen soll, halt auch entsprechend mehr Dampf braucht.
Wir machen Virtualisierte Umgebungen nur noch auf SSD Basis oder gleich dickes SAN. Als die SSDs noch nicht bezahlbar waren, nur auf RAID1+0 mit min. 10k SAS, besser 15k.
Heutzutage ist das eh ein Witz. schiebst einfach irgend eine Datacenter Grade NVMe PCIe SSD rein z.B. ne Optane und Ruhe ist. Brauchst kein RAID, kein Nix. Die MTBF von soner SSD ist gleich oder besser als die von nem RAID. Kann man sich den Käse auch gleich sparen.

ravage

2018-03-26, 18:27:17

Noch als kleinen Tipp aus der Praxis: Den Content Ordner vom WSUS kann man auch als VHD auf irgendeinen günstigen Speicher (NAS) packen. Ist zwar von der Performance echt lahm, interessiert bei Windows Updates aber keinen. Mit Windows 10 ziehen sich die Clients ihre Updates eh von dem der im lokalen Netzwerk am schnellsten antwortet, was dann meist ein anderer Windows 10 Client ist.

myMind

2018-03-26, 19:36:38

Wir hatten hier auch Fileserver, AD-Controller (mit DHCP, DNS, WSUS), DBs virtualisert, und wir devirtualsieren (nach 5 Jahren) wieder.
Gründe:

Update beim AD reißt eben auch alle anderen VMs mit (kein DNS verfügbar)

Ohne DNS kein Online Update für XenServer möglich

Wie behebt die Devirtualisierung dieses Problem? Wäre es nicht klüger einen zweite VM-Host aufzusetzen und dort den Backup-DC/DNS als VM zu betreiben?

WSUS lastet Filesystem erheblich aus

Fileserver belastet Virtualsierer bzgl. File-IO und verlangsamt alle dort laufenden VMs

Aber warum ist da die Virtualisierung das Problem? Scheint doch eher unterdimensionierte IO zu sein.

Produktive Datenbanken sollte man auf Blech laufen lassen, oder zumindest auf einem eigenen Dateisystem mit eigener Platte/SSD

Dedizierte Hardware ist halt teuer und vergleichsweise umständlich zu warten.

Zuerst haben wir den Fileserver durch ein NAS ersetzt. Aktuell ist der AD dran, hier wird auch gerade ein eigener Server aufgebaut. Bei Spieldatenbanken oder kleine DBs ist eine VM ok, aber für produktiven Einsatz raten wir Kunden immer zu Hardware, und das hat sich auch bewährt.
Für mich hört sich das eher so an, also ob es keine ausreichende Planung bezüglich der zu erwartenden Lasten gab oder einfach zu wenig Know-How.

Darf man fragen, warum ihr anstelle des NAS nicht einen zweiten VM-Host gekauft habt und die Lasten dann einfach verteilt habt? Vor 5 Jahren waren SSDs für VM-Hosts praktisch noch unbezahlbar. Heute geht das doch schon. Da kriegt man sogar die Schwuppdizität eines normalen Desktoprechners hin. Die Anwender sind von ihren echten Desktops da inzwischen einiges an Geschwindigkeit gewöhnt. Das ist in VMs ohne SSDs nicht so einfach möglich.

Ich hätte glaube ich auch die WSUS-Daten und Fileserver-Daten einfach auf separates RAID/HDDs gelegt oder separater VM-Host. Das muss nicht ultra-schnell sein nur groß.

Birdman

2018-03-26, 19:39:44

Wir nutzen Bare-Metal quasi nur noch dort wo IOPs zählen (disk sowie network) weil dort verliert man durch Virtualisierung mitunter sehr viel Performance.
Bei reinen Compute Sachen ist der Overhead tatsächlich kaum vorhanden und daher zu vernachlässigen. (ausser man hat durch den Virtualisierungs-Layer CPU flags inaktiv und die Software könnte diese grundsätzlich nutzen)

Exxtreme

2018-03-26, 19:52:16

Bei nicht IO-lastigen Dingen ist Virtualisierung sehr praktisch. Ist es aber sehr IO-lastig dann würde ich das mit der Virtualisierung lassen. Und nein, billiger wird es nicht wenn man statt HDDs SSDs benutzen muss weil die Leistung sonst nicht reicht. Kostenersparnis ist ja der Grund für Virtualisierung.

Joe

2018-03-26, 20:27:52

Bei nicht IO-lastigen Dingen ist Virtualisierung sehr praktisch. Ist es aber sehr IO-lastig dann würde ich das mit der Virtualisierung lassen.

Wir haben einen Kunden, der fährt jeden Morgen unendliche Mengen an VDIs hoch. Das SAN logt zwischen 08:00 und 08:15 in spitzen locker 50k IOPS und gähnt dabei nur.

Wiso sollte Virtualisierung da in irgend einer Form im Nachteil sein? Ich versteh nicht warum das ein Hypervisor Problem sein sollte und kein Storage Problem. Und gerade im Storage lohnt es sich doch, weil ein DC nur ein paar GB vom Storage nimmt und Du nicht 2x 200gb RAID1 in ein Blech schrauben musst, die dann nur zu 5% belegt sind. Das gleiche beim RAM, der CPU und den Netzwerkkarten. Da gibts schon einiges zu sparen. Dazu exzellente Backup Lösungen für kleines Geld.

Wo ich das Blech nachvollziehen kann, ist wie schon gesagt bei absoluten High End Performance Geschichten. Den Fall gibts aber in "normalen" Firmen nicht. Ich kenne keinen hier, der den Webshop von Amazon betriebt oder Hochfrequenzhandel oder eine Petabyte SQL Datenbank betreut mit der Zeitgleich 30k Leute arbeiten müssen.
Für die TUM haben wir ein Setup gebastelt für Genmutationssimulationen. Selbst dass läuft fröhlich auf VMware.

PHuV

2018-03-27, 00:53:44

XenServer hat IMHO auch nix in normalen Umgebungen verloren.
Warum nicht? Läuft kostenlos bis 7.1 und bisher einwandfrei. Dato gabs noch kein HyperV, und VMWare ESXi in der freien Version läuft auch nicht überall und die besten Features sind deaktivert.
Wir machen Virtualisierte Umgebungen nur noch auf SSD Basis oder gleich dickes SAN. Als die SSDs noch nicht bezahlbar waren, nur auf RAID1+0 mit min. 10k SAS, besser 15k.
Heutzutage ist das eh ein Witz. schiebst einfach irgend eine Datacenter Grade NVMe PCIe SSD rein z.B. ne Optane und Ruhe ist. Brauchst kein RAID, kein Nix. Die MTBF von soner SSD ist gleich oder besser als die von nem RAID. Kann man sich den Käse auch gleich sparen.
Klar, wenn Du das Budget hast, schön für Dich, wir haben es eben nicht. Und ich habe bereits eine NVMe SSD mit 1TB drin, aber der wird für einen virtualiserten Cloudera-Cluster mit 4 Nodes + Hauptnode benötigt, und einem DB-Server.
Für mich hört sich das eher so an, also ob es keine ausreichende Planung bezüglich der zu erwartenden Lasten gab oder einfach zu wenig Know-How.
Know How ist da, aber für ein kleines Unternehmen kein so großes Budget, ganz einfach.

Darf man fragen, warum ihr anstelle des NAS nicht einen zweiten VM-Host gekauft habt und die Lasten dann einfach verteilt habt?
Kosten?
Noch als kleinen Tipp aus der Praxis: Den Content Ordner vom WSUS kann man auch als VHD auf irgendeinen günstigen Speicher (NAS) packen. Ist zwar von der Performance echt lahm, interessiert bei Windows Updates aber keinen. Mit Windows 10 ziehen sich die Clients ihre Updates eh von dem der im lokalen Netzwerk am schnellsten antwortet, was dann meist ein anderer Windows 10 Client ist.
Hab ich probiert, lief ums verrecken nicht.

Joe

2018-03-27, 01:06:43

Warum nicht?

Vergleichsweise wenig unterstützte Hardware, wenig Features, kompliziertes Troubleshooting weil so wenig verbreitet und sehr schwierig zu sichern, wenn Du kein SAN hast.

Birdman

2018-03-27, 11:53:01

Wir haben einen Kunden, der fährt jeden Morgen unendliche Mengen an VDIs hoch. Das SAN logt zwischen 08:00 und 08:15 in spitzen locker 50k IOPS und gähnt dabei nur.
50k IOPs sind eigentlich ja auch nix, das schafft schon eine einzelne SATA3 SSD bei entsprechendem Workload. (QD >=4) ;)
Ja man kann auch IO lastigen Sachen sehr gut virtualisieren, es ist nur so dass man durch den V-Layer bei I/O im Vergleich zu Compute relativ viel verliert.
Bei Compute sind es einstellige Prozentzahlen und das wird von den Firmen (VMWare, Citrix, M$) ja auch immer wieder hergenommen, wenn es drum geht irgendwelche Benchmarks von physical vs virtual zu zeigen.

Dass man mit einem gescheiten Storage-Backend auch mit Virtualisierung immer noch genug I/O Performance hat, steht natürlich ausser Frage.

PHuV

2018-03-27, 17:08:43

So unterschiedlich können die Philosophien sein.
Wenn einer meiner Jungs bei einem Kunden Inventur macht und das was Du beschreibst vorfindet, wäre das ein Fall von "das baut man aber seit spätestens 2008 anders....."
Also wenn Du wirklich danach gehst, dann sage ich Dir, daß Du mit Hardware und eigener Infrastruktur heute allgemein so was von outdated bist, weil man heute alles in der Cloud macht (AWS, Azure, GCP). :cool: Hab einen Kunden erst mit vielen Server in die AWS migriert, wir haben Kunden mit Azure...
Vergleichsweise wenig unterstützte Hardware, wenig Features, kompliziertes Troubleshooting weil so wenig verbreitet und sehr schwierig zu sichern, wenn Du kein SAN hast.
Aber für uns ausreichend und zufriedenstellend. Klar wird wegen der neuen Politik und aufgrund der Mängel demnächst auf Hyper-V gewechselt, aber dafür brauchen wir erst einen neuen Server.

Haarmann

2018-03-28, 15:36:27

Joe

Dedup auf SSD = viele VMs fressen kaum Platz.

Nutze ich natürlich auch.

Aber bei DBs finde ich ist BareMetal ein Argument.

Birdman

Das kann einem richtig "umhauen" - ich hab für eine bestimmte Anwendung nen "Prototypen" erstellt mit einfach 2 Consumer NVMe als RAID1 - also kein Hexenwerk. Der Aufbau der DB, da sieht im Normalfall Niemand freiwillig zu, lief einfach durch. In den VMs mit normalen SSDs wartest da nach wie vor auf Godot.

Exxtreme

2018-03-28, 16:23:57

Wiso sollte Virtualisierung da in irgend einer Form im Nachteil sein? Ich versteh nicht warum das ein Hypervisor Problem sein sollte und kein Storage Problem. Und gerade im Storage lohnt es sich doch, weil ein DC nur ein paar GB vom Storage nimmt und Du nicht 2x 200gb RAID1 in ein Blech schrauben musst, die dann nur zu 5% belegt sind. Das gleiche beim RAM, der CPU und den Netzwerkkarten. Da gibts schon einiges zu sparen. Dazu exzellente Backup Lösungen für kleines Geld.

Virtualisierung ist zum Beispiel schon von Nachteil, dass auf SSDs kein Trim funktioniert. Microsoft probiert da schon was rum aber das Problem bleibt. Fehlendes Trim geht auf Schreibperformance und die SSD lebt nicht so lange wie sie könnte.

Klar kann man das mit "mehr Hardware" schon irgendwie ausgleichen, dass es dann schnell genug ist. Nur wirkt das wiederum recht konträr zum Zweck der Virtualisierung, dass man Hardware besser ausnutzen will. Deshalb würde ich Datenbanken durchaus auf bare metal lassen wenn einem die DB-Performance wichtig ist. Und das ist bei ERP-Systemen recht schnell der Fall.