Hyper-V Cluster 2022 Netzwerkplannung

[stevenki 1]

Hallo zusammen,

 

bisher war ich immer in der VMWare Schiene unterwegs, aufgrund der aktuellen Lizenzproblematik und nur noch ABO-Modellen möchte ich im nächsten Projekt daher ein Hyper-V Cluster verwenden.

Hier bin ich allerdings die ganze Zeit auf der Suche nach den Best Practises bzgl. Networking und finde immer sehr unterschiedliche Aussagen.

 

Auf manchen Seiten wird geraten, ein SET Team zu erstellen und vNIC daran zu hängen für die verschiedenen Dienste.

Auf anderen Seiten wird wiederrum sämtlicher Traffic weiterhin getrennt.

 

Aktuell bin ich noch frei in der Netzwerkkonfiguration der Server , es soll ein Cluster aus 2 Hosts werden.

Storage wird über shared SAS angebunden, also keine Netzwerkbetrachtung notwendig.

Außerdem werden 2 Switches, welche gestackt werden, verwendet, um die Hosts ans Netzwerk zu bringen.

 

 

Für Live-Migration wollte ich die Hosts direkt miteinander verbinden (10 Gbit).

 

Hier die 1. Frage:

- eine Verbindung für Live-Migration (1* 10 Gbit)

- 2 Verbindungen für Live-Migration (2* 10 Gbit)

- 1 SET Team mit 2 Verbindungen für Live-Migration

 

Da es nur ein 2 Host-Cluster wird stellt sich auch die Frage für Cluster / CSV Traffic.

Oder reicht 1* SET Team mit 2*10 Gbit und dann verschiedene vNIC für die Dienste Livemigration, Clustertraffic,..?

 

Wie sieht es mit dem Mgmt des Hypervisors aus?

- eigene Verbindung via LFBO Team

- eigene Verbindung via SET Team?

- vNIC im Set-Team gemeinsam mit VM Traffic?

 

 

Wäre schön, wenn ich von euch ein paar Anregungen bekomme, welche Konstellation am besten und sinnvoll ist.

Vielen Dank

[NilsK 2.785]

Moin,

 

es fehlt die entscheidende Angabe, wie viele physische NICs die Hosts denn haben. Und natürlich ist auch wichtig, wie hoch denn die Last auf den Systemen sein wird, also am Ende, wie viele VMs in welchem Sizing dort laufen.

 

Die generelle Antwort ist "kommt drauf an", und worauf es ankommt, hängt insbesondere an den beiden genannten Faktoren. Eine 2-Node-Umgebung ist ja sehr klein, aber das muss erst mal nix heißen. Von "bei dem Szenario egal, mach einfach irgendwas" bis hin zu "nimm x mit viel y und schalte z ab" ist alles drin.

 

Gruß, Nils

 

[testperson 1.534]

Hi,

 

im Prinzip ja. Ich würde das davon abhängig machen, wie viele NICs mit welcher Bandbreite tatsächlich zur Verfügung stehen. Den / die Hyper-V Switch/es aber definitiv als SET Switch (, es sei denn du musst zwingend LACP nutzen).

 

Ggfs. müsstest du "Backup Traffic" noch mit betrachten.

 

Gruß

Jan

bearbeitet 9. April von testperson

[stevenki 1]

danke für eure Antworten,

 

wie ich bereits im Eingangs-Post schrieb, ich bin bei den pNICs noch flexibel, abhängig von der Best-Practice vom Hyper-V.

Ports im Switch-Stack habe ich genügend übrig, und die pNICs kann ich, da die Server noch in der Bestellphase sind, noch beliebig anpassen.

 

Die Umgebung wird eher eine relativ kleine Umgebung, wenig Last

(8-10 VMs, darunter 1 Exchange, 1 Datev Server, 2 RDS, 15 User)

 

Für Backup-Traffic wollte ich saperate NICs verwenden, um den Backupserver auch komplett zu trennen.

 

Also vom Prinzip her:

 

- Livemigration

- Cluster / CSV

(zusammen via vNIC oder getrennte pNICs?)

- Backup-Traffic 

- VM

- Mgmt

 

Alle Karten werden 10Gbit haben

[mwiederkehr 351]

Für eine Umgebung in dieser Grösse sollten 2 Ports pro Server reichen. Darauf einen SET-Switch und je einen vNIC für Management, Cluster und Backup. Cluster und Livemigration würde ich nicht auftrennen.

 

Mehr NICs gehen natürlich immer, aber ich denke, bei der Grösse wirst Du keine bessere Performance feststellen mit 4 statt 2 NICs pro Server. Andererseits wirst Du wegen der Ausfallsicherheit lieber zwei NICs pro Server haben statt eine mit zwei Ports und 2x 2 Ports sind nicht wesentlich teurer als 2x 1 Port...

[Nobbyaushb 1.359]

Kann mich meinem Vorredner anschließen

Ich würde nur die Switche nicht stacken - welcher Hersteller?

Und mit dem Shared SAS hast du einen Single-Point-of-Failure

 

Was möchtest du denn bestellen?

 

Schon mal überlegt sowas fertig zu kaufen, einfach nur LAN rein und los gehts?

Ich denke da an den Xaler von Terra...

Falls ja, trigger mich mal an

[stevenki 1]

Danke für die Antworten, 

tatsächlich war meine FRage weniger der Performance geschuldet , da wird die Umgebung kaum große Notwendigkeiten ans Netzwerk stellen.

Mir ging es nur um die Best Practise bei Hyper-V, da ich wie gesagt, in der Richtung eher aus dem VMWare Umfeld komme und mir die aktuellen

Best Practises einfach so nicht bekannt sind.

 

Warum nicht stacken? Ich habe sehr viele Uplinks, die via LACPs Links auf jeweils ein Switch des Switch-Stacks gehen, um Redundanz zu gewährleisten.

Ja, ich könnte stattdessen auch mit RSTP arbeiten, aber was spricht denn gegen Stacks?

 

Als Shared-SAS hatte ich eine DELL ME5024 geplant - relativ günstig für ein, für diese Umgebung, sehr performantes shared Storage.

Dieser Xaler ist doch ein S2D korrekt? Hatte ich auch überlegt, aber mMn steigert es die komplexität unnötig für gleiche Kosten und unwesentlich, nicht benötigter, mehr performance (wenn überhaupt). Aber kannst mich auch gern korrigieren...

 

[NilsK 2.785]

Moin,

 

grundsätzlich: Das ist eine sehr kleine Umgebung. Das ist völlig okay und soll nicht abfällig klingen. Aber behalte das eben im Hinterkopf, wenn du Know-how aufbaust. Viel von dem, was du liest, orientiert sich an großen oder sehr großen Umgebungen, und dadurch sind viele "Optimierungen" und scheinbare "Best Practices" für kleine Umgebungen oft übertrieben. Das gilt z.B. fast immer für die "Performance" bei Live Migration: Klar ist es toll, wenn auch riesige VMs in Sekundenbruchteilen von Host zu Host wechseln, aber wann braucht man das wirklich?

 

Der Einordnung von @mwiederkehr schließe ich mich an. Damit solltest du eine gute Basis haben.

 

Ach, und: ein dediziertes "VM-Netz" gibt es in Hyper-V nicht. Jede VM hat ihren eigenen vNIC, die bilden dann sozusagen alle zusammen das VM-Netzwerk. Ein vSwitch in Hyper-V hat immer so viele Ports, wie es tatsächlich vNICs gibt, die mit ihm verbunden sind. Mehr Logik ist da nicht drin. (Finden viele nicht gut, ist aber so und stört auch nur selten.)

 

Gruß, Nils

 

[stevenki 1]

Zitat

Ach, und: ein dediziertes "VM-Netz" gibt es in Hyper-V nicht. Jede VM hat ihren eigenen vNIC, die bilden dann sozusagen alle zusammen das VM-Netzwerk. Ein vSwitch in Hyper-V hat immer so viele Ports, wie es tatsächlich vNICs gibt, die mit ihm verbunden sind. Mehr Logik ist da nicht drin. (Finden viele nicht gut, ist aber so und stört auch nur selten.)

 

das ist mir bewusst ... mit "VM-Netz" meinte ich ja auch nur den vSwitch, an welchen die VMs angebunden sind.

 

Vielen Dank für eure Antworten,

wie gesagt, es ist klar, dass es eine Mini Umgebung ist. Trotzdessen wollte ich hier mal nachfragen, ob es Empfehlungen gibt, die ich bei der Netzwerkplannung unbedingt beachten sollte. Danke für eure Antworten

[testperson 1.534]

vor 6 Minuten schrieb stevenki:

Dieser Xaler ist doch ein S2D korrekt?

 

Der Xaler "realisiert HCI" per Datacore (und einem 2 Node Hyper-V Cluster). Zusätzlich hast du da ja auch noch ein, zwei zusätzliche coole Features, wie bspw. die isolierte Managementumgebung oder deren "TFOF" (eine Art Continuous Data Protection). Durch den lokalen Storage in den Nodes dürftest du _vermutlich_ auch bessere Performance erzielen.

[Nobbyaushb 1.359]

Xaler hat auch nur noch nVME als HDD - nur so...
Und das Konzept ist ein völlig anderes als S2D, wobei das HCI ja ähnlich ist (Storage und Hyper-V per Host..)

Aber das sprengt den Thread und war auch nicht deine Frage

 

Ich würde dann 2 10G Dualport Karten einbauen, dann hast du 4 * 10 Gbit und bist damit über dem SAS mit max. 12Gbit (SAS 24 ist zwar Public aber derzeit nicht zu bezahken