2x Hyper-V Host mit angebundenen SAN
Hallo Community,
ich habe folgende Frage. Die derzeitige Situation, welche ersetzt werden soll ist folgende:
- 1. phy. Maschine mit Server 2016 als AD, DHCP,DNS, Fileserver und SQL Server
- 2. phy. Maschine mit Server 2016 mit Hyper-V Rolle (1x SRV DMS, 6x Win10 Client) und Printserver
Die Server sind in die Jahre gekommen und sollen ausgetauscht werden.
Meine erste Überlegung war folgende:
2x Hyper V-Host mit jeweils 2 Xeon Silver 8-Core, 256GB Ram und 6x NVME 1,92 TB mit VROC als RAID 1
Und dann als VM Aufteilung:
1er Host:
DC1 mit AD,DHCP und DNS
VM2 als File Server
VM3 als SQL Server
VM4 als DMS Server
2er Host:
DC2 mit AD,DHCP und DNS
VM2-7 als Windows 10 Clients
Untereinander sollten die dann via VEEAM hin und her gesichert werden sodas wenn ein Host ausfällt die VMs auf dem anderen nur gestartet werden müssten.
Nachteil an der Lösung ist ja der Speicherverbrauch der replizierten VM´s.
Jetzt habe ich bei HP die MSA 1060 oder 2060 gefunden welche als SAN ja relativ "günstig" sind.
Meine Überlegung war jetzt das ich wenn ich eine SAN einsetze ja die lokalen NVME spare und sich der Aufpreis damit relativiert und auch das FailOver optimiert wird.
Jetzt meine Fragen:
Eher die MSA 1060 mit ca 130000 IOPS oder doch besser die MSA 2060 mit bis zu 250000 IOPS. Preisunterschied zwischen beiden ist ja nicht so hoch. Machen sie die
unterschiedlichen IOPS bemerkbar?
Und die zweite Frage ist die Anbindung. FC fällt wegen des Aufwandes raus, also bleibt noch SAS oder iSCSI.
iSCSI nutzt ja das Netzwerk wo ich vielleicht trotz 10GbiT Switch einen Flaschenhals befürchte. SAS hat ja 12GBit, also etwas mehr als iSCSI. Welche Nachteile hat SAS ausser das ich je Server einen HBA brauchen würde? Die SAN wäre doch trotzdem von beiden Servern gleichzeitg erreichbar oder habe ich hier einen Denkfehler??
Vielen Dank für eure Hilfe und Anregungen schonmal.
ich habe folgende Frage. Die derzeitige Situation, welche ersetzt werden soll ist folgende:
- 1. phy. Maschine mit Server 2016 als AD, DHCP,DNS, Fileserver und SQL Server
- 2. phy. Maschine mit Server 2016 mit Hyper-V Rolle (1x SRV DMS, 6x Win10 Client) und Printserver
Die Server sind in die Jahre gekommen und sollen ausgetauscht werden.
Meine erste Überlegung war folgende:
2x Hyper V-Host mit jeweils 2 Xeon Silver 8-Core, 256GB Ram und 6x NVME 1,92 TB mit VROC als RAID 1
Und dann als VM Aufteilung:
1er Host:
DC1 mit AD,DHCP und DNS
VM2 als File Server
VM3 als SQL Server
VM4 als DMS Server
2er Host:
DC2 mit AD,DHCP und DNS
VM2-7 als Windows 10 Clients
Untereinander sollten die dann via VEEAM hin und her gesichert werden sodas wenn ein Host ausfällt die VMs auf dem anderen nur gestartet werden müssten.
Nachteil an der Lösung ist ja der Speicherverbrauch der replizierten VM´s.
Jetzt habe ich bei HP die MSA 1060 oder 2060 gefunden welche als SAN ja relativ "günstig" sind.
Meine Überlegung war jetzt das ich wenn ich eine SAN einsetze ja die lokalen NVME spare und sich der Aufpreis damit relativiert und auch das FailOver optimiert wird.
Jetzt meine Fragen:
Eher die MSA 1060 mit ca 130000 IOPS oder doch besser die MSA 2060 mit bis zu 250000 IOPS. Preisunterschied zwischen beiden ist ja nicht so hoch. Machen sie die
unterschiedlichen IOPS bemerkbar?
Und die zweite Frage ist die Anbindung. FC fällt wegen des Aufwandes raus, also bleibt noch SAS oder iSCSI.
iSCSI nutzt ja das Netzwerk wo ich vielleicht trotz 10GbiT Switch einen Flaschenhals befürchte. SAS hat ja 12GBit, also etwas mehr als iSCSI. Welche Nachteile hat SAS ausser das ich je Server einen HBA brauchen würde? Die SAN wäre doch trotzdem von beiden Servern gleichzeitg erreichbar oder habe ich hier einen Denkfehler??
Vielen Dank für eure Hilfe und Anregungen schonmal.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665843
Url: https://administrator.de/contentid/665843
Ausgedruckt am: 25.11.2024 um 20:11 Uhr
3 Kommentare
Neuester Kommentar
Moin,
finde doch erstmal den Ressourcenbedarf der Anwendung heraus.
So von dem Aufbau her wäre eine zentrale Storagelösung eigentlich vernünftiger. Und wenn man die als SAS nimmt, hat man die Chance, den Traffic zu separieren. A propos Traffic, bei so einer kleinen Anzahl an VMs wird es da im Betrieb wohl nie Engpässe geben, aber der Aha-Effekt eines lokalen VROC im Host selber ist dann halt auch nicht da. Aber wer braucht den schon?
Ein Windows 10 direkt von NVME gestartet oder über einen Infiniband ISCSI Connect mit 40 GBit ist in 2 Sekunden da. Aber schon der Loginprozeß dauert so zwischen 10 und 30 Sekunde, warum sollte man sich also Gedanken machen, wie schnell Windows bootet?
130.000 IOPS hören sich erstmal vollkommen überdimensioniert an, aber am Ende ist das nur eine Zahl... die Masterfrage ist hier wohl eher: Was für einen Streß verursacht der SQL Server wenn alle Benutzer irgendwelchen DB-lastigen Arbeiten erledIgen?
Ich selbst hab bei 30 Usern mal Peaks so in Richtung 5000 IOPS gesehen, bei einer datenintensiven CAE Software. Der Storage vom Kunden hatte 80.000 IOPS für die Anwendung und ihre Ressourcen reserviert.
Schneller beim Storageinterface geht bekanntermaßen immer, schraubt aber die Kosten gewaltig nach oben. Bei uns im Rechenzentrum war mal ein Storage bei 6 GBit SAS (an einem Windows Patchday) am Limit als es mehr als 200 Windows-VMs mit Festplattenimages versorgen mußte... der Nachfolger hatten dann 2x16 GBit FC und so eine Art Link Aggregation für 2 Ports.
finde doch erstmal den Ressourcenbedarf der Anwendung heraus.
So von dem Aufbau her wäre eine zentrale Storagelösung eigentlich vernünftiger. Und wenn man die als SAS nimmt, hat man die Chance, den Traffic zu separieren. A propos Traffic, bei so einer kleinen Anzahl an VMs wird es da im Betrieb wohl nie Engpässe geben, aber der Aha-Effekt eines lokalen VROC im Host selber ist dann halt auch nicht da. Aber wer braucht den schon?
Ein Windows 10 direkt von NVME gestartet oder über einen Infiniband ISCSI Connect mit 40 GBit ist in 2 Sekunden da. Aber schon der Loginprozeß dauert so zwischen 10 und 30 Sekunde, warum sollte man sich also Gedanken machen, wie schnell Windows bootet?
130.000 IOPS hören sich erstmal vollkommen überdimensioniert an, aber am Ende ist das nur eine Zahl... die Masterfrage ist hier wohl eher: Was für einen Streß verursacht der SQL Server wenn alle Benutzer irgendwelchen DB-lastigen Arbeiten erledIgen?
Ich selbst hab bei 30 Usern mal Peaks so in Richtung 5000 IOPS gesehen, bei einer datenintensiven CAE Software. Der Storage vom Kunden hatte 80.000 IOPS für die Anwendung und ihre Ressourcen reserviert.
Schneller beim Storageinterface geht bekanntermaßen immer, schraubt aber die Kosten gewaltig nach oben. Bei uns im Rechenzentrum war mal ein Storage bei 6 GBit SAS (an einem Windows Patchday) am Limit als es mehr als 200 Windows-VMs mit Festplattenimages versorgen mußte... der Nachfolger hatten dann 2x16 GBit FC und so eine Art Link Aggregation für 2 Ports.
Moin,
welche IOPS du benötigst, weisst nur du.
Der SQL-Server kann pennen, er kann aber auch eine lese-/ schreibintensive Anwendung mit Daten füttern.
Zur SAS-Anbindung:
ja, jeder Host brauch mindestens 2 SAS-Ports in Form von HBAs.
Dabei bindet man in aller Regel die Hosts redundant an das Storage an.
Bedenke aber, dass in deinem avisierten Konstrukt das Storage der SPOF ist - fällt die aus, kann kein Host aktiv werden.
Es gäbe noch folgendes Szenario:
Statte beide Hosts mit ausreichend Diskspace aus und verzichte auf ein SAN.
Mit HyperV und der STorage Replication hast du die Daten immer Live auf beiden Hosts: https://www.windowspro.de/marcel-kueppers/storage-replica-fuer-hyper-v-f ...
bei VMware nennt sich das vSAN und erfordert eine bestimmte Lizenzstufe - mit der Essentials klappt das glaube ich nicht. Das müsstest du aber selbst einmal verifizieren.
Edit:
Ich würde also zwei Hosts nehmen und dort
2 SSDs/ NVMes (kleinere Kapazität) für das Host-OS vorsehen, RAID 1
Dann ggf. 6 oder 8 Discs (als SSD oder NVMe) mit großer Kapazität verbauen und diese als distributed Array 5 oder 6 einrichten (sofern der RAID-Controller das kann). Kann auch sein, dass ein Distributed Array derzeit nur von IBM-Systemen unterstützt wird.
Vorteil in Summe:
Du hast keinen SPOF, benötigst keine SAS HBAs und eine Wartung für das Storage im SAN ist ebenfalls nicht erforderlich.
Nachteil: jeder Host muss ein paar TBs mehr vorhalten...
Edit2: schaue auch einmal hier. Ein ähnliches Thema würde letzten Monat dort behandelt:
Kleine HA Lösung ohne SAN
Edit3: Du warst doch auch hier schon der Hilfesuchende und hast dein Problem als gelöst markiert....
Ist dein Problem aus März also doch noch nicht gelöst?
Gruß
em-pie
welche IOPS du benötigst, weisst nur du.
Der SQL-Server kann pennen, er kann aber auch eine lese-/ schreibintensive Anwendung mit Daten füttern.
2er Host:
DC2 mit AD,DHCP und DNS
VM2-7 als Windows 10 Clients
Ich hoffe auch mit passenden VDI-Lizensierung DC2 mit AD,DHCP und DNS
VM2-7 als Windows 10 Clients
Zur SAS-Anbindung:
ja, jeder Host brauch mindestens 2 SAS-Ports in Form von HBAs.
Dabei bindet man in aller Regel die Hosts redundant an das Storage an.
Bedenke aber, dass in deinem avisierten Konstrukt das Storage der SPOF ist - fällt die aus, kann kein Host aktiv werden.
Es gäbe noch folgendes Szenario:
Statte beide Hosts mit ausreichend Diskspace aus und verzichte auf ein SAN.
Mit HyperV und der STorage Replication hast du die Daten immer Live auf beiden Hosts: https://www.windowspro.de/marcel-kueppers/storage-replica-fuer-hyper-v-f ...
bei VMware nennt sich das vSAN und erfordert eine bestimmte Lizenzstufe - mit der Essentials klappt das glaube ich nicht. Das müsstest du aber selbst einmal verifizieren.
Edit:
Ich würde also zwei Hosts nehmen und dort
2 SSDs/ NVMes (kleinere Kapazität) für das Host-OS vorsehen, RAID 1
Dann ggf. 6 oder 8 Discs (als SSD oder NVMe) mit großer Kapazität verbauen und diese als distributed Array 5 oder 6 einrichten (sofern der RAID-Controller das kann). Kann auch sein, dass ein Distributed Array derzeit nur von IBM-Systemen unterstützt wird.
Vorteil in Summe:
Du hast keinen SPOF, benötigst keine SAS HBAs und eine Wartung für das Storage im SAN ist ebenfalls nicht erforderlich.
Nachteil: jeder Host muss ein paar TBs mehr vorhalten...
Edit2: schaue auch einmal hier. Ein ähnliches Thema würde letzten Monat dort behandelt:
Kleine HA Lösung ohne SAN
Edit3: Du warst doch auch hier schon der Hilfesuchende und hast dein Problem als gelöst markiert....
Ist dein Problem aus März also doch noch nicht gelöst?
Gruß
em-pie