13
Hyper-V Cluster Netzwerklayout-Frage
Guten Morgen in die Runde,
wir bauen gerade mit einem Systemhaus ein neues Cluster auf und ich habe momentan einige Fragezeichen zum aufgesetzten Grundsystem, da es doch von unserem vorherigen System abweicht. Zum Ausgangspunkt:
Momentanes Layout sieht folgendermaßen aus.
Aus dem 10G-Team haben wir einen vSwitch mit gemeinsamer Verwendung für das OS erstellt
Nun hatten wir vorher separate NICs für Livemigration und Cluster. Meine Frage wäre also ob dies so auch eine gängige Konfiguration darstellt, oder ob ich lieber das 1G-Team auflöse und dort Livemigration und Management separat aufsetze und auf die Redundanz verzichte. Eure Meinung würde mich mal interessieren, da es hier ja etliche Herangehensweisen gibt.
Gruß,
Peter
wir bauen gerade mit einem Systemhaus ein neues Cluster auf und ich habe momentan einige Fragezeichen zum aufgesetzten Grundsystem, da es doch von unserem vorherigen System abweicht. Zum Ausgangspunkt:
- 3x Hyper-V Hosts, 1x SAN per FC verbunden
- alle Hosts haben jeweils 2x 10Gbit und 2x 1Gbit (Intel X710)
- Windows Server 2022 Datacenter
Momentanes Layout sieht folgendermaßen aus.
- 10G NICs wurden per LACP geteamt (Hyper-V Lastenausgleich) => auf SET haben wir vorerst aufgrund fehlender Erfahrungen verzichtet
- 1G wurden per Switch Independent geteamt
Aus dem 10G-Team haben wir einen vSwitch mit gemeinsamer Verwendung für das OS erstellt
- der dadurch generierte vSwitch vEthernet-Adaper soll nun für Livemigration genutzt, damit diese auch auf 10G zurückgreifen kann => Cluster / Livemigration
- das 1G-Team übernimmt Management / Cluster
Nun hatten wir vorher separate NICs für Livemigration und Cluster. Meine Frage wäre also ob dies so auch eine gängige Konfiguration darstellt, oder ob ich lieber das 1G-Team auflöse und dort Livemigration und Management separat aufsetze und auf die Redundanz verzichte. Eure Meinung würde mich mal interessieren, da es hier ja etliche Herangehensweisen gibt.
Gruß,
Peter
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 4064952869
Url: https://administrator.de/contentid/4064952869
Printed on: April 26, 2024 at 15:04 o'clock
13 Comments
Latest comment
Moin Peter,
😱, nix gut, LBFO ist seit Server 2016 "deprecated" und ist seit dem auch nicht mehr supported.
Und SET kannste auch knicken, weil es selbst beim Server 2022 nicht anständig läuft.
Folgende Empfehlung.
Erste 10G --> vSwitch PROD --> VM's
Zweite 10G --> (möglichst kein vSwitch) Cluster / Livemigration
Erste 1G --> (vSwitch MGMT) --> Hyper-V Management
Zweite 1G --> vSwitch DMZ z.B. für eine DMZ
Gruss Alex
* 10G NICs wurden per LACP geteamt (Hyper-V Lastenausgleich) => auf SET haben wir vorerst aufgrund fehlender Erfahrungen verzichtet
😱, nix gut, LBFO ist seit Server 2016 "deprecated" und ist seit dem auch nicht mehr supported.
Und SET kannste auch knicken, weil es selbst beim Server 2022 nicht anständig läuft.
Folgende Empfehlung.
Erste 10G --> vSwitch PROD --> VM's
Zweite 10G --> (möglichst kein vSwitch) Cluster / Livemigration
Erste 1G --> (vSwitch MGMT) --> Hyper-V Management
Zweite 1G --> vSwitch DMZ z.B. für eine DMZ
Gruss Alex
1
Hallo Alex,
vielen Dank für den Vorschlag. Aber keine Redundanz für die VMs? Management sollte dann doch sicherlich auch keinen vSwitch haben - ich brauche die NIC ja für den lokalen IP-Zugriff und nicht in den VMs?!
vielen Dank für den Vorschlag. Aber keine Redundanz für die VMs? Management sollte dann doch sicherlich auch keinen vSwitch haben - ich brauche die NIC ja für den lokalen IP-Zugriff und nicht in den VMs?!
Moin Peter,
HA hast du doch durch deine 3 Nodes.
Mir wäre es auch lieber, wenn man die NIC's sauber "trunken" könnte,
leider geht das spätestens ab Server 2019 nicht mehr so wirklich.
Hab darüber schon einen längeren Roman geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Wenn keine der VM's etwas mit dem Hyper-V Management zu tun hat, wie z.B. eine Veeam VM,
dann kannst du selbstverständlich auf den vSwitch im Hyper-V Management-Netz verzichten.
Jedoch frage ich mich dann, wo die AD-Server von dem Hyper-V Cluster laufen?
Aber da gibt es ja auch mehr als ein duzend Rezepte.
Beste Grüsse aus BaWü
Alex
Aber keine Redundanz für die VMs?
HA hast du doch durch deine 3 Nodes.
Mir wäre es auch lieber, wenn man die NIC's sauber "trunken" könnte,
leider geht das spätestens ab Server 2019 nicht mehr so wirklich.
Hab darüber schon einen längeren Roman geschrieben.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Management sollte dann doch sicherlich auch keinen vSwitch haben - ich brauche die NIC ja für den lokalen IP-Zugriff und nicht in den VMs?!
Wenn keine der VM's etwas mit dem Hyper-V Management zu tun hat, wie z.B. eine Veeam VM,
dann kannst du selbstverständlich auf den vSwitch im Hyper-V Management-Netz verzichten.
Jedoch frage ich mich dann, wo die AD-Server von dem Hyper-V Cluster laufen?
Aber da gibt es ja auch mehr als ein duzend Rezepte.
Beste Grüsse aus BaWü
Alex
Servus Alex,
HA im Cluster ja, aber wenn das 10G-Modul auf dem Switch ein Problem hat, hilft mir das ja auch nicht weiter. Dann ist die VM auch nicht erreichbar. Dafür habe ich mir ja unter anderem eigentlich einen redundanten Core-Switch angeschafft.
Die Domain-Controller laufen jeweils lokal auf den Hyper-V Hosts außerhalb des Clusters. Veeam läuft auf dem physischen Backup-Server außerhalb der Domäne.
Gruß,
Peter
HA hast du doch durch deine 3 Nodes.
HA im Cluster ja, aber wenn das 10G-Modul auf dem Switch ein Problem hat, hilft mir das ja auch nicht weiter. Dann ist die VM auch nicht erreichbar. Dafür habe ich mir ja unter anderem eigentlich einen redundanten Core-Switch angeschafft.
Jedoch frage ich mich dann, wo die AD-Server von dem Hyper-V Cluster laufen?
Die Domain-Controller laufen jeweils lokal auf den Hyper-V Hosts außerhalb des Clusters. Veeam läuft auf dem physischen Backup-Server außerhalb der Domäne.
Gruß,
Peter
Moin Peter,
Wir haben auch Core-Switche bei einigen Kunden im Einsatz und vor ein paar Jahren,
haben wir die HV's bei diesen Kunden genau so angebunden wie du.
Leider hat sich dabei herausgestellt, dass SET selbst nach extremer Optimierung nicht optimal läuft.
Das hört sich sehr gut an, machen wir auch so. 😁
Die AD's sind aber nur für die Hyper-V Umgebung, oder?
warum nicht als VM?
Beste Grüsse aus BaWü
Alex
HA im Cluster ja, aber wenn das 10G-Modul auf dem Switch ein Problem hat, hilft mir das ja auch nicht weiter. Dann ist die VM auch nicht erreichbar. Dafür habe ich mir ja unter anderem eigentlich einen redundanten Core-Switch angeschafft.
Wir haben auch Core-Switche bei einigen Kunden im Einsatz und vor ein paar Jahren,
haben wir die HV's bei diesen Kunden genau so angebunden wie du.
Leider hat sich dabei herausgestellt, dass SET selbst nach extremer Optimierung nicht optimal läuft.
Die Domain-Controller laufen jeweils lokal auf den Hyper-V Hosts außerhalb des Clusters.
Das hört sich sehr gut an, machen wir auch so. 😁
Die AD's sind aber nur für die Hyper-V Umgebung, oder?
Veeam läuft auf dem physischen Backup-Server ...
warum nicht als VM?
Beste Grüsse aus BaWü
Alex
Moin moin,
Die sind schon auch für die Produktivumgebung. Du sprichst bestimmt von einer eigenen Management-Domäne. Das wäre für unsere Größe (1 Standort, 70 User) eventuell etwas zu viel Komplexität. Aber sicherlich aus Sicht des "Hardenings" die bessere Wahl.
Der Backup-Server soll ja auch im absoluten Katastrophenfall noch erreichbar sein! Wenn der erst wieder in einer Domäne hängt und zusätzlich auch noch der HV funktionieren muss sind das schon zwei mögliche Stolperstellen und Ransomware gibt es ja dann auch noch. Deswegen nur Arbeitsgruppe und physischer Server der sowieso gleich als primäres Storage dient. Zusätzlich dann noch Tape und Immutable Storage.
Gruß, Peter
Die AD's sind aber nur für die Hyper-V Umgebung, oder?
Die sind schon auch für die Produktivumgebung. Du sprichst bestimmt von einer eigenen Management-Domäne. Das wäre für unsere Größe (1 Standort, 70 User) eventuell etwas zu viel Komplexität. Aber sicherlich aus Sicht des "Hardenings" die bessere Wahl.
warum nicht als VM?
Der Backup-Server soll ja auch im absoluten Katastrophenfall noch erreichbar sein! Wenn der erst wieder in einer Domäne hängt und zusätzlich auch noch der HV funktionieren muss sind das schon zwei mögliche Stolperstellen und Ransomware gibt es ja dann auch noch. Deswegen nur Arbeitsgruppe und physischer Server der sowieso gleich als primäres Storage dient. Zusätzlich dann noch Tape und Immutable Storage.
Gruß, Peter
Mal so eine doofe Idee was die Redundanz angeht.....
Folgendes schwirrt mir im Kopf rum:
10G Nic 1 --vSwitch NET01 ( Subnet 10.1.2.x )
10G Nic 2 --vSwitch NET02 ( Subnet 10.1.2.x )
dann eine VM erstellen und dieser 2 Netzwerkkarten zuteilen
vNIC1 auf vSwitch NET01
vNIC2 auf vSwitch NET02
und dann auf der VM selber ein SET Trunking oder Failover / LACP oder was auch immer hinzufügen.....
Müsste doch gehen oder ?
Ich komme eher aus der VMWare Ecke daher ist es nur eine Idee und ich weiss nicht in wieweit man das
so machen kann.
Ansonsten würde ich es wie mxsticfoxde geschreiben hat machen.
Unter VMWare haben wir unsere 4 Netzwerkkarten zusammen gefasst und arbeiten nur mit VLAN´s bzw. den entsprechenden Portgruppen / vSwitchen.
Lediglich das Manageement läuft über eine 2 1Gbit Links.
Alles andere läuft wie gesagt über VLAN getrennt über alle 4 NIC´s ohne Trennung nach Cluster / Live / VM / etc....
DMZ Traffic oder direktes Internet haben wir nicht auf unseren Clustern von daher ist das kein Problem.
Ich würde jetzt aber ein DMZ Netz oder WAN nicht per VLAN über die NIC´s schicken da ich hier doch Sicherheitsprobleme sehe.
Folgendes schwirrt mir im Kopf rum:
10G Nic 1 --vSwitch NET01 ( Subnet 10.1.2.x )
10G Nic 2 --vSwitch NET02 ( Subnet 10.1.2.x )
dann eine VM erstellen und dieser 2 Netzwerkkarten zuteilen
vNIC1 auf vSwitch NET01
vNIC2 auf vSwitch NET02
und dann auf der VM selber ein SET Trunking oder Failover / LACP oder was auch immer hinzufügen.....
Müsste doch gehen oder ?
Ich komme eher aus der VMWare Ecke daher ist es nur eine Idee und ich weiss nicht in wieweit man das
so machen kann.
Ansonsten würde ich es wie mxsticfoxde geschreiben hat machen.
Zitat von @MysticFoxDE:
Folgende Empfehlung.
Erste 10G --> vSwitch PROD --> VM's
Zweite 10G --> (möglichst kein vSwitch) Cluster / Livemigration
Erste 1G --> (vSwitch MGMT) --> Hyper-V Management
Zweite 1G --> vSwitch DMZ z.B. für eine DMZ
Gruss Alex
Erste 10G --> vSwitch PROD --> VM's
Zweite 10G --> (möglichst kein vSwitch) Cluster / Livemigration
Erste 1G --> (vSwitch MGMT) --> Hyper-V Management
Zweite 1G --> vSwitch DMZ z.B. für eine DMZ
Gruss Alex
Unter VMWare haben wir unsere 4 Netzwerkkarten zusammen gefasst und arbeiten nur mit VLAN´s bzw. den entsprechenden Portgruppen / vSwitchen.
Lediglich das Manageement läuft über eine 2 1Gbit Links.
Alles andere läuft wie gesagt über VLAN getrennt über alle 4 NIC´s ohne Trennung nach Cluster / Live / VM / etc....
DMZ Traffic oder direktes Internet haben wir nicht auf unseren Clustern von daher ist das kein Problem.
Ich würde jetzt aber ein DMZ Netz oder WAN nicht per VLAN über die NIC´s schicken da ich hier doch Sicherheitsprobleme sehe.
Moin Mr-Gustav:
Damit hättest du dann einen Hypervisor auf einem Hypervisor laufen.
In der VM kannst du eigentlich nur LBFO benutzen, aber das ist seit Server 2016, seitens MS abgekündigt.
Daher bleibt ab Server 2019 eigentlich nur SET übrig was bei VM's nicht wirklich geht.
Zudem läuft SET auf dem Hyper-V Nodes, ohne grössere Optimierung auch alles andere als fehlerfrei. 😔
Nachdem uns die letzten > 10 Jahre weder eine NIC abgeraucht ist, noch ein Switch(Modul) und alle unserer Kunden mit nur einer 10G pro Node Richtung Clients mehr als zurechtkommen/zufrieden sind, habe ich das Thema "Trunken/Teaming" den Nerven zuliebe, vorerst an den Nagel gehängt.
Gruss Alex
und dann auf der VM selber ein SET
auf der VM selbst kannst du kein SET aktivieren, weil man dafür auf der VM die Hyper-V Rolle installieren müsste.Damit hättest du dann einen Hypervisor auf einem Hypervisor laufen.
Trunking oder Failover / LACP oder was auch immer hinzufügen.....
In der VM kannst du eigentlich nur LBFO benutzen, aber das ist seit Server 2016, seitens MS abgekündigt.
Daher bleibt ab Server 2019 eigentlich nur SET übrig was bei VM's nicht wirklich geht.
Zudem läuft SET auf dem Hyper-V Nodes, ohne grössere Optimierung auch alles andere als fehlerfrei. 😔
Nachdem uns die letzten > 10 Jahre weder eine NIC abgeraucht ist, noch ein Switch(Modul) und alle unserer Kunden mit nur einer 10G pro Node Richtung Clients mehr als zurechtkommen/zufrieden sind, habe ich das Thema "Trunken/Teaming" den Nerven zuliebe, vorerst an den Nagel gehängt.
Gruss Alex
N'Abend.
https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure- ...
https://learn.microsoft.com/en-us/windows-server/networking/windows-serv ...
SET ist sicherlich die Zukunft, für bestehende Systeme, selbst unter Server 2019, ist LBFO immer noch der kleinste, gemeinsame Nenner und sehr wohl noch durch MS supportet. Nicht jeder hat Bedarf an den Azure Stack HCI Funktionen, da ist klassisches NIC-Teaming immer noch ein probates Mittel.
Cheers,
jsysde
Zitat von @MysticFoxDE:
[...]LBFO ist seit Server 2016 "deprecated" und ist seit dem auch nicht mehr supported.[...]
Das hab' ich jetzt schon mehrfach (von dir?) gelesen - stimmt so nicht:[...]LBFO ist seit Server 2016 "deprecated" und ist seit dem auch nicht mehr supported.[...]
https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure- ...
https://learn.microsoft.com/en-us/windows-server/networking/windows-serv ...
SET ist sicherlich die Zukunft, für bestehende Systeme, selbst unter Server 2019, ist LBFO immer noch der kleinste, gemeinsame Nenner und sehr wohl noch durch MS supportet. Nicht jeder hat Bedarf an den Azure Stack HCI Funktionen, da ist klassisches NIC-Teaming immer noch ein probates Mittel.
Cheers,
jsysde
Moin jsysde,
https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure- ...
https://learn.microsoft.com/en-us/windows-server/networking/windows-serv ...
SET ist sicherlich die Zukunft, für bestehende Systeme, selbst unter Server 2019, ist LBFO immer noch der kleinste, gemeinsame Nenner und sehr wohl noch durch MS supportet. Nicht jeder hat Bedarf an den Azure Stack HCI Funktionen, da ist klassisches NIC-Teaming immer noch ein probates Mittel.
Hier steht alles sehr detailliert beschrieben, samt sämtlicher MS Links.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
ASHCI nutzt übrigens denselben Kernel wie auch Windows 11 oder Server 2022.
Bei ASHCI-Systemen wird dieser nur öfter aktualisiert und die entsprechende zertifizierte Hardware kostet saumässig viel Geld, obwohl deren Performance, insbesondere im Bereich des Storages (S2D), sehr dürftig ist.
By the Way, Server 2019 war gestern, beim aktuellen Server 2022 kannst du ein LBFO Team nur noch mit einem Trick als Uplink in einem vSwitch verwenden.
Wenn du WAC verwendest, dann hat dieses übrigens auch schon beim Server 2019 gemeckert, wenn du ein LBFO Team als Uplink in einem vSwitch benutzen wolltest.
Ich habe in dieses Thema übrigens mehrere Mannmonate investiert, mich bis zum Level 4 des Microsoft Supports durchgekämpft und habe mitunter auch deswegen, mit Dan Cuomo schon mehrfach persönlich gesprochen.
Teste es doch einfach mal selbst.
Nimm zwei Server die mit je mind. 2x10G NIC's bestückt sind, teame einmal mit SET und einmal mit LBFO und mache ein paar Lasttests dazwischen, und schon wirst du den Unterschied sehen.
Selbst beim teamen von 1G NIC's spürt man schon deutliche Performanceunterschiede zwischen LBFO und SET.
Gruss Alex
[...]LBFO ist seit Server 2016 "deprecated" und ist seit dem auch nicht mehr supported.[...]
Das hab' ich jetzt schon mehrfach (von dir?) gelesen - stimmt so nicht:https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure- ...
https://learn.microsoft.com/en-us/windows-server/networking/windows-serv ...
SET ist sicherlich die Zukunft, für bestehende Systeme, selbst unter Server 2019, ist LBFO immer noch der kleinste, gemeinsame Nenner und sehr wohl noch durch MS supportet. Nicht jeder hat Bedarf an den Azure Stack HCI Funktionen, da ist klassisches NIC-Teaming immer noch ein probates Mittel.
Hier steht alles sehr detailliert beschrieben, samt sämtlicher MS Links.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
ASHCI nutzt übrigens denselben Kernel wie auch Windows 11 oder Server 2022.
Bei ASHCI-Systemen wird dieser nur öfter aktualisiert und die entsprechende zertifizierte Hardware kostet saumässig viel Geld, obwohl deren Performance, insbesondere im Bereich des Storages (S2D), sehr dürftig ist.
By the Way, Server 2019 war gestern, beim aktuellen Server 2022 kannst du ein LBFO Team nur noch mit einem Trick als Uplink in einem vSwitch verwenden.
Wenn du WAC verwendest, dann hat dieses übrigens auch schon beim Server 2019 gemeckert, wenn du ein LBFO Team als Uplink in einem vSwitch benutzen wolltest.
Ich habe in dieses Thema übrigens mehrere Mannmonate investiert, mich bis zum Level 4 des Microsoft Supports durchgekämpft und habe mitunter auch deswegen, mit Dan Cuomo schon mehrfach persönlich gesprochen.
Teste es doch einfach mal selbst.
Nimm zwei Server die mit je mind. 2x10G NIC's bestückt sind, teame einmal mit SET und einmal mit LBFO und mache ein paar Lasttests dazwischen, und schon wirst du den Unterschied sehen.
Selbst beim teamen von 1G NIC's spürt man schon deutliche Performanceunterschiede zwischen LBFO und SET.
Gruss Alex
Okay, ja LBFO kann noch genutzt werden aaaabbbbeeeerrrr
du bekommst von MS KEINEN AKTIVEN Support mehr !
Wir haben eine Anwendung welche in einem MS Hyper V Cluster läuft ( insgesamt 4 Nodes ) und diese wird durch
den Hersteller / Dienstleister der Software gewartet bzw. der kümmert sich auch um die Fehlerbehebung.
Cluster ist ein S2D bzw. mit ext. Storage für die Anwendung(en).
Vor nicht all zu langer Zeit hatten wir massive Probleme mit der ganzen Cluster ( Netzwerkabbrüche / teilweise kein HA / Teilweise keine Failover / teilweise sind die VM´s abgeschmmiert wenn ein Host heruntergefahren wurde ). Der Dienstleister hat dann ein Ticket aufgemacht weil er selber nicht mehr weiter gekommen ist und dann hat sich das der MS Support angesehen und das erste was die gesagt haben war dann das LBFO nicht mehr supportet wird und das Sie das ganze NICHT anfassen bis das auf SET angepasst wurde.
Der DL hat das ganze dann Umgebaut und dann hat sich der MS Support auch an die Fehlerbehebung bzw. Support gemacht. Aussage war vom MS Support bezüglich des LBFO:
Wird nicht mehr supportet also KEINEN Service von uns. Wir haben erkannt das dass Mist ist und es deswegen abgekündigt. Wenn auf SET Umgebaut dann können wir weitermachen. Alternativ bauen wir das ganze auf SET um und das kostet dann.........
Nun ja wenn du dann eine Anwendung hast welche sehr wichtig ist dann bleibt dir nichts anderes........
das dazu.
Was ich aber auch sagen kann ist das mir in den letzten 10 Jahren nur einmal eine Optik in einer NIC gestorben ist und das die Switche bisher keine Ausfälle zu verzeichnen hatten welche nicht eingeplant waren. Wenn jetzt natürlich das ganze im LIVE umgebaut werden soll oder ihr da andere Sachen im Betrieb vor habt dann sind 2 Links auf 2 Switche natürlich erforderlich. Aber an und für sich ist die Hardware nicht mehr so schlecht das mit einem Ausfall wegen defekter HW gerechnet werden muss. Wenn jetzt natürlich einer das LWL Kabel knickt oder den Switch aus dem Strom zieht ist natürlich essig ......
Vondaher hat mysticFoxDE schon recht. Wenn du dir allerdings die Nerven aufreiben willst dann mach Trunking oder LACP oder was auch immer.......
Eventuell kann dein Switch ja was in die Richtung MESH oder vPC oder bei HP glaube ich Distributed Trunking eventuell ist das je eine Lösung für dich.
du bekommst von MS KEINEN AKTIVEN Support mehr !
Wir haben eine Anwendung welche in einem MS Hyper V Cluster läuft ( insgesamt 4 Nodes ) und diese wird durch
den Hersteller / Dienstleister der Software gewartet bzw. der kümmert sich auch um die Fehlerbehebung.
Cluster ist ein S2D bzw. mit ext. Storage für die Anwendung(en).
Vor nicht all zu langer Zeit hatten wir massive Probleme mit der ganzen Cluster ( Netzwerkabbrüche / teilweise kein HA / Teilweise keine Failover / teilweise sind die VM´s abgeschmmiert wenn ein Host heruntergefahren wurde ). Der Dienstleister hat dann ein Ticket aufgemacht weil er selber nicht mehr weiter gekommen ist und dann hat sich das der MS Support angesehen und das erste was die gesagt haben war dann das LBFO nicht mehr supportet wird und das Sie das ganze NICHT anfassen bis das auf SET angepasst wurde.
Der DL hat das ganze dann Umgebaut und dann hat sich der MS Support auch an die Fehlerbehebung bzw. Support gemacht. Aussage war vom MS Support bezüglich des LBFO:
Wird nicht mehr supportet also KEINEN Service von uns. Wir haben erkannt das dass Mist ist und es deswegen abgekündigt. Wenn auf SET Umgebaut dann können wir weitermachen. Alternativ bauen wir das ganze auf SET um und das kostet dann.........
Nun ja wenn du dann eine Anwendung hast welche sehr wichtig ist dann bleibt dir nichts anderes........
das dazu.
Was ich aber auch sagen kann ist das mir in den letzten 10 Jahren nur einmal eine Optik in einer NIC gestorben ist und das die Switche bisher keine Ausfälle zu verzeichnen hatten welche nicht eingeplant waren. Wenn jetzt natürlich das ganze im LIVE umgebaut werden soll oder ihr da andere Sachen im Betrieb vor habt dann sind 2 Links auf 2 Switche natürlich erforderlich. Aber an und für sich ist die Hardware nicht mehr so schlecht das mit einem Ausfall wegen defekter HW gerechnet werden muss. Wenn jetzt natürlich einer das LWL Kabel knickt oder den Switch aus dem Strom zieht ist natürlich essig ......
Vondaher hat mysticFoxDE schon recht. Wenn du dir allerdings die Nerven aufreiben willst dann mach Trunking oder LACP oder was auch immer.......
Eventuell kann dein Switch ja was in die Richtung MESH oder vPC oder bei HP glaube ich Distributed Trunking eventuell ist das je eine Lösung für dich.
1Zitat von @MysticFoxDE:
Moin Mr-Gustav:
Damit hättest du dann einen Hypervisor auf einem Hypervisor laufen.
In der VM kannst du eigentlich nur LBFO benutzen, aber das ist seit Server 2016, seitens MS abgekündigt.
Daher bleibt ab Server 2019 eigentlich nur SET übrig was bei VM's nicht wirklich geht.
Zudem läuft SET auf dem Hyper-V Nodes, ohne grössere Optimierung auch alles andere als fehlerfrei. 😔
Nachdem uns die letzten > 10 Jahre weder eine NIC abgeraucht ist, noch ein Switch(Modul) und alle unserer Kunden mit nur einer 10G pro Node Richtung Clients mehr als zurechtkommen/zufrieden sind, habe ich das Thema "Trunken/Teaming" den Nerven zuliebe, vorerst an den Nagel gehängt.
Gruss Alex
Moin Mr-Gustav:
und dann auf der VM selber ein SET
auf der VM selbst kannst du kein SET aktivieren, weil man dafür auf der VM die Hyper-V Rolle installieren müsste.Damit hättest du dann einen Hypervisor auf einem Hypervisor laufen.
Trunking oder Failover / LACP oder was auch immer hinzufügen.....
In der VM kannst du eigentlich nur LBFO benutzen, aber das ist seit Server 2016, seitens MS abgekündigt.
Daher bleibt ab Server 2019 eigentlich nur SET übrig was bei VM's nicht wirklich geht.
Zudem läuft SET auf dem Hyper-V Nodes, ohne grössere Optimierung auch alles andere als fehlerfrei. 😔
Nachdem uns die letzten > 10 Jahre weder eine NIC abgeraucht ist, noch ein Switch(Modul) und alle unserer Kunden mit nur einer 10G pro Node Richtung Clients mehr als zurechtkommen/zufrieden sind, habe ich das Thema "Trunken/Teaming" den Nerven zuliebe, vorerst an den Nagel gehängt.
Gruss Alex
Danke für die Antwort / Erklärung ...
mach ja durchaus Sinn das SET nur auf dem Hyper V Host funktioniert. Wird ja eigentlich sogesehn nur auf dem Hyper V host benötigt.
War wie gesagt nur eine Idee. Ich bin was Hyper V angeht eher nur User und nicht Designer. Ich weiß wie ich VM´ß verschieben kann und starten / beenden und das wars auch schon. Mehr brauche ich auch nicht machen denn wir haben nur einen Cluster und um den kümmert sich auch noch ein DL wenn es Probleme gibt da er darauf die Software welche wir gekauft haben ( mit Support ) betreibt. So gesehn ist der Cluster das Hoheitsgebiet des DL
Moin Peter,
Ja, ich meine eine Management-Domäne.
Aber so viel komplexer macht die die Umgebung auch nicht wirklich, dafür hast du dadurch jedoch sicherheitstechnisch einen wesentlich höheren Schutz.
Wenn die Bösewichte an deine Hyper-V's kommen, ist meistens komplett schluss mit Lustig.
Daher würde ich, bei einem Hyper-V Cluster, niemals ohne eine Management Domäne arbeiten,
dafür haben ich bei diversesten Incident-Response Einsätzen, schon zu viele Scherben gesehen.
Der Backup-Server soll ja auch im absoluten Katastrophenfall noch erreichbar sein! Wenn der erst wieder in einer Domäne hängt und zusätzlich auch noch der HV funktionieren muss sind das schon zwei mögliche Stolperstellen und Ransomware gibt es ja dann auch noch. Deswegen nur Arbeitsgruppe und physischer Server der sowieso gleich als primäres Storage dient. Zusätzlich dann noch Tape und Immutable Storage.
Auch hier gibt es wie überall unterschiedliche gute Rezepte.
Wir sichern bei den meisten Kunden noch mit Veeam und das läuft als VM mit auf dem Cluster, jedoch in der HV-MGMT-Domäne. Die Backupdaten der täglichen Sicherungen wandern per SMB auf ein Enterprise-NAS, deren Zugang nochmals mit anderen Zugangsdaten wie die HV-MGMT-Domäne gesichert ist.
Und am Wochenende wird bei den meisten Kunden noch ein Vollbackup auf eine oder zwei RDX-Platten gemacht, die am Montag dann in einem Banktresor landen.
Wenn der Veeam im Katastrophenfall mit abraucht, dann ist das so, solange die Backups selbst sicher sind,
mache ich mir da überhaupt keine Sorgen. Ein neuer Veeam ist in ~2 Stunden aufgesetzt und bisher war das
noch nie nötig.
Gruss Alex
Die sind schon auch für die Produktivumgebung. Du sprichst bestimmt von einer eigenen Management-Domäne. Das wäre für unsere Größe (1 Standort, 70 User) eventuell etwas zu viel Komplexität. Aber sicherlich aus Sicht des "Hardenings" die bessere Wahl.
Ja, ich meine eine Management-Domäne.
Aber so viel komplexer macht die die Umgebung auch nicht wirklich, dafür hast du dadurch jedoch sicherheitstechnisch einen wesentlich höheren Schutz.
Wenn die Bösewichte an deine Hyper-V's kommen, ist meistens komplett schluss mit Lustig.
Daher würde ich, bei einem Hyper-V Cluster, niemals ohne eine Management Domäne arbeiten,
dafür haben ich bei diversesten Incident-Response Einsätzen, schon zu viele Scherben gesehen.
warum nicht als VM?
Der Backup-Server soll ja auch im absoluten Katastrophenfall noch erreichbar sein! Wenn der erst wieder in einer Domäne hängt und zusätzlich auch noch der HV funktionieren muss sind das schon zwei mögliche Stolperstellen und Ransomware gibt es ja dann auch noch. Deswegen nur Arbeitsgruppe und physischer Server der sowieso gleich als primäres Storage dient. Zusätzlich dann noch Tape und Immutable Storage.
Auch hier gibt es wie überall unterschiedliche gute Rezepte.
Wir sichern bei den meisten Kunden noch mit Veeam und das läuft als VM mit auf dem Cluster, jedoch in der HV-MGMT-Domäne. Die Backupdaten der täglichen Sicherungen wandern per SMB auf ein Enterprise-NAS, deren Zugang nochmals mit anderen Zugangsdaten wie die HV-MGMT-Domäne gesichert ist.
Und am Wochenende wird bei den meisten Kunden noch ein Vollbackup auf eine oder zwei RDX-Platten gemacht, die am Montag dann in einem Banktresor landen.
Wenn der Veeam im Katastrophenfall mit abraucht, dann ist das so, solange die Backups selbst sicher sind,
mache ich mir da überhaupt keine Sorgen. Ein neuer Veeam ist in ~2 Stunden aufgesetzt und bisher war das
noch nie nötig.
Gruss Alex