13
Hyper-V Cluster S2D - Netzwerk (mit SET Switch?)
Hallo,
nachdem ich schon bei einem anderen Problem super Unterstützung bekommen habe versuche ich gleich nochmal.
Unsere 4 Nodes im (2-Site)Cluster haben jeweils folgende NICs: 2 x 10GBit und 4 x 25GBit
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
Gruppe 2(G2)
2 x 10GBit NICs (mit SET Switch)
- für die VMs
- Management
Nun meine Fragen:
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
- ist es notwendig G1 über Switche zu führen oder macht es Sinn ein MESH Netz zu bauen
Vielen Dank schon einmal.
nachdem ich schon bei einem anderen Problem super Unterstützung bekommen habe versuche ich gleich nochmal.
Unsere 4 Nodes im (2-Site)Cluster haben jeweils folgende NICs: 2 x 10GBit und 4 x 25GBit
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
Gruppe 2(G2)
2 x 10GBit NICs (mit SET Switch)
- für die VMs
- Management
Nun meine Fragen:
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
- ist es notwendig G1 über Switche zu führen oder macht es Sinn ein MESH Netz zu bauen
Vielen Dank schon einmal.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4944794132
Url: https://administrator.de/forum/hyper-v-cluster-s2d-netzwerk-mit-set-switch-4944794132.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
13 Kommentare
Neuester Kommentar
Moin Ostera,
gleich eines im Vorfeld. Wenn dir Performance wichtig ist, dann nimm das nächste Mal bitte kein S2D, sondern ein anständiges SAN. Die sind am Ende des Tages günstiger und auch schneller. 😉
das sieht gut aus und die vierte 25G, kannst du z.B. für ein performantes Backup verwenden.
Übrigens, um die volle Performance der 25G NIC's auch nur ansatzweise auszuschöpfen, müssen diese von Hand noch ordentlich nachoptimiert werden und du hast hoffentlich in den Servern, neben der Beanspruchung durch das S2D, auch genügend CPU Leistung für die ganzen NIC's vorgesehen. Denn 120 GBit bekommt man ganz sicher nicht mit einem 8-Kerner gebacken und selbst ein 16-Kerner würde alleine die CPU-Last die durch die NIC's anfällt, wahrscheinlich nicht ausreichend bedienen können, zumindest nicht alle NIC's gleichzeitig.
😮 ... SET ... 😬 ..., nix gut ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Nimm die eine 10G für die VM's und die andere fürs Management und gut ist.
Hier gilt übrigens dasselbe wie auch bei den 25G NIC's. Um die volle Performance der 10G NIC's auszuschöpfen, müssen auch diese von Hand noch ordentlich nachoptimiert werden und auch die entsprechenden vSwitche und auch die vmNIC's müssen zum Teil sehr kräftig nachoptimiert werden. 😔
Der Storage Traffic findet sowohl zwischen den Nodes derselben Site, als auch zwischen den Nodes der anderen Sites statt!
Sprich, alle Nodes der Site A müssen SMB technisch untereinander und auch mit alle anderen Nodes der Site B sprechen können und umgekehrt.
Das gilt übrigens auch für "Live Migration" & "Cluster-Kommunikation".
Meinst du jetzt von aussen über physikalische Switche, oder meinst du vSwitche auf den Nodes?
Was meinst du jetzt genau mit einem "MESH Netz"?
Beste Grüsse aus BaWü
Alex
gleich eines im Vorfeld. Wenn dir Performance wichtig ist, dann nimm das nächste Mal bitte kein S2D, sondern ein anständiges SAN. Die sind am Ende des Tages günstiger und auch schneller. 😉
Unsere 4 Nodes im (2-Site)Cluster haben jeweils folgende NICs: 2 x 10GBit und 4 x 25GBit
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
das sieht gut aus und die vierte 25G, kannst du z.B. für ein performantes Backup verwenden.
Übrigens, um die volle Performance der 25G NIC's auch nur ansatzweise auszuschöpfen, müssen diese von Hand noch ordentlich nachoptimiert werden und du hast hoffentlich in den Servern, neben der Beanspruchung durch das S2D, auch genügend CPU Leistung für die ganzen NIC's vorgesehen. Denn 120 GBit bekommt man ganz sicher nicht mit einem 8-Kerner gebacken und selbst ein 16-Kerner würde alleine die CPU-Last die durch die NIC's anfällt, wahrscheinlich nicht ausreichend bedienen können, zumindest nicht alle NIC's gleichzeitig.
Gruppe 2(G2)
2 x 10GBit NICs (mit SET Switch)
2 x 10GBit NICs (mit SET Switch)
😮 ... SET ... 😬 ..., nix gut ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
- für die VMs
- Management
- Management
Nimm die eine 10G für die VM's und die andere fürs Management und gut ist.
Hier gilt übrigens dasselbe wie auch bei den 25G NIC's. Um die volle Performance der 10G NIC's auszuschöpfen, müssen auch diese von Hand noch ordentlich nachoptimiert werden und auch die entsprechenden vSwitche und auch die vmNIC's müssen zum Teil sehr kräftig nachoptimiert werden. 😔
Nun meine Fragen:
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
Der Storage Traffic findet sowohl zwischen den Nodes derselben Site, als auch zwischen den Nodes der anderen Sites statt!
Sprich, alle Nodes der Site A müssen SMB technisch untereinander und auch mit alle anderen Nodes der Site B sprechen können und umgekehrt.
Das gilt übrigens auch für "Live Migration" & "Cluster-Kommunikation".
- ist es notwendig G1 über Switche zu führen
Meinst du jetzt von aussen über physikalische Switche, oder meinst du vSwitche auf den Nodes?
oder macht es Sinn ein MESH Netz zu bauen.
Was meinst du jetzt genau mit einem "MESH Netz"?
Beste Grüsse aus BaWü
Alex
Hallo,
das sieht gut aus und die vierte 25G, kannst du z.B. für ein performantes Backup verwenden.
Übrigens, um die volle Performance der 25G NIC's auch nur ansatzweise auszuschöpfen, müssen diese von Hand noch ordentlich nachoptimiert werden und du hast hoffentlich in den Servern, neben der Beanspruchung durch das S2D, auch genügend CPU Leistung für die ganzen NIC's vorgesehen. Denn 120 GBit bekommt man ganz sicher nicht mit einem 8-Kerner gebacken und selbst ein 16-Kerner würde alleine die CPU-Last die durch die NIC's anfällt, wahrscheinlich nicht ausreichend bedienen können, zumindest nicht alle NIC's gleichzeitig.
Wir haben in jedem Node 2 CPUs mit je 20 Kernen und 256GB RAM. Die vierte 25G fürs Backup würde dann nur dafür genutzt oder parallel auch noch für den SMB Traffic?
😮 ... SET ... 😬 ..., nix gut ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Nimm die eine 10G für die VM's und die andere fürs Management und gut ist.
Hier gilt übrigens dasselbe wie auch bei den 25G NIC's. Um die volle Performance der 10G NIC's auszuschöpfen, müssen auch diese von Hand noch ordentlich nachoptimiert werden und auch die entsprechenden vSwitche und auch die vmNIC's müssen zum Teil sehr kräftig nachoptimiert werden. 😔
Deinen verlinkten Artikel kannte ich schon, da ich schon andere deiner Beiträge "durchforstet" hatte - sehr interessant.
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Ich muss (soll aber wohl mittlerweile die Empfehlung sein) iWarp verwenden.
Die Einstellung "RDMA Mode" auf iWarp setzen ist dann wahrscheinlich nur ein Teil der Settings...(Max QPs Number, Delayed Ack, Recv Window....)
Der Storage Traffic findet sowohl zwischen den Nodes derselben Site, als auch zwischen den Nodes der anderen Sites statt!
Sprich, alle Nodes der Site A müssen SMB technisch untereinander und auch mit alle anderen Nodes der Site B sprechen können und umgekehrt.
Das gilt übrigens auch für "Live Migration" & "Cluster-Kommunikation".
Meinst du jetzt von aussen über physikalische Switche, oder meinst du vSwitche auf den Nodes?
Was meinst du jetzt genau mit einem "MESH Netz"?
Mit Mesh meine ich die direkte Verkabelung Node 1 zu Node 2/3/4, Node 2 zu Node 1/3/4 usw ohne dabei über einen Switch zu gehen. Alternative dazu alle NIC Ports auf (redundate) Switche zu führen.
Zitat von @MysticFoxDE:
Moin Ostera,
gleich eines im Vorfeld. Wenn dir Performance wichtig ist, dann nimm das nächste Mal bitte kein S2D, sondern ein anständiges SAN. Die sind am Ende des Tages günstiger und auch schneller. 😉
Das konnten wir leider nicht selbst festlegen ;-(Moin Ostera,
gleich eines im Vorfeld. Wenn dir Performance wichtig ist, dann nimm das nächste Mal bitte kein S2D, sondern ein anständiges SAN. Die sind am Ende des Tages günstiger und auch schneller. 😉
Unsere 4 Nodes im (2-Site)Cluster haben jeweils folgende NICs: 2 x 10GBit und 4 x 25GBit
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
Ich plane nun folgendes:
Gruppe 1(G1)
4 x 25GBit NICs (direkt, ohne SET-Switch/LBFO-Team) für:
- SMB(1-4) Traffic
- Live Migration
- Cluster-Kommunikation
das sieht gut aus und die vierte 25G, kannst du z.B. für ein performantes Backup verwenden.
Übrigens, um die volle Performance der 25G NIC's auch nur ansatzweise auszuschöpfen, müssen diese von Hand noch ordentlich nachoptimiert werden und du hast hoffentlich in den Servern, neben der Beanspruchung durch das S2D, auch genügend CPU Leistung für die ganzen NIC's vorgesehen. Denn 120 GBit bekommt man ganz sicher nicht mit einem 8-Kerner gebacken und selbst ein 16-Kerner würde alleine die CPU-Last die durch die NIC's anfällt, wahrscheinlich nicht ausreichend bedienen können, zumindest nicht alle NIC's gleichzeitig.
Gruppe 2(G2)
2 x 10GBit NICs (mit SET Switch)
2 x 10GBit NICs (mit SET Switch)
😮 ... SET ... 😬 ..., nix gut ...
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
- für die VMs
- Management
- Management
Nimm die eine 10G für die VM's und die andere fürs Management und gut ist.
Hier gilt übrigens dasselbe wie auch bei den 25G NIC's. Um die volle Performance der 10G NIC's auszuschöpfen, müssen auch diese von Hand noch ordentlich nachoptimiert werden und auch die entsprechenden vSwitche und auch die vmNIC's müssen zum Teil sehr kräftig nachoptimiert werden. 😔
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Ich muss (soll aber wohl mittlerweile die Empfehlung sein) iWarp verwenden.
Die Einstellung "RDMA Mode" auf iWarp setzen ist dann wahrscheinlich nur ein Teil der Settings...(Max QPs Number, Delayed Ack, Recv Window....)
Nun meine Fragen:
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
- ist die Aufteilung G1 mit 4 x 25GBit und G2 mit 2 x 10GBit OK, oder wäre es besser, für G2 25GBit mit zu nutzen
(dann G1 mit 2 x 25GBit und 2 x 10GBit)
- ich habe einen Artikel gelesen, in dem es um den SMB "Ost-West" und "Nord-Süd" Traffic geht
- ich dachte der Storage Traffic findet nur zwischen den Clustern (also "Ost-West") statt, was meint dann "Nord-Süd"?
Der Storage Traffic findet sowohl zwischen den Nodes derselben Site, als auch zwischen den Nodes der anderen Sites statt!
Sprich, alle Nodes der Site A müssen SMB technisch untereinander und auch mit alle anderen Nodes der Site B sprechen können und umgekehrt.
Das gilt übrigens auch für "Live Migration" & "Cluster-Kommunikation".
- ist es notwendig G1 über Switche zu führen
Meinst du jetzt von aussen über physikalische Switche, oder meinst du vSwitche auf den Nodes?
oder macht es Sinn ein MESH Netz zu bauen.
Was meinst du jetzt genau mit einem "MESH Netz"?
Mit Mesh meine ich die direkte Verkabelung Node 1 zu Node 2/3/4, Node 2 zu Node 1/3/4 usw ohne dabei über einen Switch zu gehen. Alternative dazu alle NIC Ports auf (redundate) Switche zu führen.
Beste Grüsse aus BaWü
Alex
Alex
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Das würde mich auch interessieren.
Bis auf die Einstellungen die ich für RocE und QoS machen muss, sind mir keine weiteren Einstellungen geläufig.
Zitat von @Ueba3ba:
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Das würde mich auch interessieren.
Bis auf die Einstellungen die ich für RocE und QoS machen muss, sind mir keine weiteren Einstellungen geläufig.
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Das würde mich auch interessieren.
Bis auf die Einstellungen die ich für RocE und QoS machen muss, sind mir keine weiteren Einstellungen geläufig.
Ich habe in der Microsoft Docu den folgenden Link gefunden
Windows Server 2016 and 2019 RDMA Deployment Guide
mal schauen ob mir das weiterhilft.
Mit diesem Guide hab ich RoCe ans laufen gebracht.
Moin Ostera,
die zwei CPU's bringen dir in dem Fall nicht wirklich etwas, weil die NIC's physikalisch entweder am Socket A oder Socket B hängen.
Natürlich kann eine NIC auch von einem NUMA bedient werden, an dem sie nicht direkt physikalisch dranhängt. Das ist jedoch mit zum Teil starken Performanceverlusten verbunden.
Und per default dürfen sich die NIC’s leider aller NUMA’s bedienen und das wiederum ist performancetechnisch einfach nur Blödsinn.
Siehe diesbezüglich folgenden Beitrag …
https://community.spiceworks.com/topic/post/8845561
Jain, das ist nicht ganz so einfach, weil die Einstellungen vom NIC-Hersteller zu NIC-Hersteller zum Teil unterschiedlich sind. Zudem müssen manche Parameter der NIC’s, abhängig von der jeweils verbauten CPU konfiguriert werden.
Wenn du mir jedoch ein paar Infos lieferst, dann kann ich dir ein für dein System passende Optimierung erstellen.
Zuerst benötige ich die folgenden Infos
Ja, aber soweit ich weiss, ist das nur auf der NIC wo SMB drüber läuft notwendig.
Ja, so ist das.
Wobei einige der Einstellungen nur für RDMA Betrieb nicht notwendig sind, weil die entsprechenden Features bei RDMA eh umgangen werden. Daher ist RDMA per default auch etwas effizienter.
Wenn man jedoch die entsprechenden TCP Features, wie z.B. auch das uralte und mittlerweile unnütze TCP-Delay, welches RDMA von Haus aus umgeht, von Hand bei normalem TCP-Datenverkehr deaktiviert, dann bleibt von dem Vorteil durch RDMA nur noch etwas Staub übrig. 😔
Siehe …
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
Beste Grüsse aus BaWü
Alex
Wir haben in jedem Node 2 CPUs mit je 20 Kernen und 256GB RAM. Die vierte 25G fürs Backup würde dann nur dafür genutzt oder parallel auch noch für den SMB Traffic?
die zwei CPU's bringen dir in dem Fall nicht wirklich etwas, weil die NIC's physikalisch entweder am Socket A oder Socket B hängen.
Natürlich kann eine NIC auch von einem NUMA bedient werden, an dem sie nicht direkt physikalisch dranhängt. Das ist jedoch mit zum Teil starken Performanceverlusten verbunden.
Und per default dürfen sich die NIC’s leider aller NUMA’s bedienen und das wiederum ist performancetechnisch einfach nur Blödsinn.
Siehe diesbezüglich folgenden Beitrag …
https://community.spiceworks.com/topic/post/8845561
Gibt es eine Zusammenstellung, welche Einstellungen an der NIC angepasst werden müssen?
Jain, das ist nicht ganz so einfach, weil die Einstellungen vom NIC-Hersteller zu NIC-Hersteller zum Teil unterschiedlich sind. Zudem müssen manche Parameter der NIC’s, abhängig von der jeweils verbauten CPU konfiguriert werden.
Wenn du mir jedoch ein paar Infos lieferst, dann kann ich dir ein für dein System passende Optimierung erstellen.
Zuerst benötige ich die folgenden Infos
Get-NetAdapterHardwareInfo
Get-NetAdapterAdvancedProperty | FT -AutoSize
Get-NetAdapterRss
Get-NetAdapterRsc
Get-NetAdapterSriov
Get-NetAdapterVmq
netsh int tcp show globalIch muss (soll aber wohl mittlerweile die Empfehlung sein) iWarp verwenden.
Ja, aber soweit ich weiss, ist das nur auf der NIC wo SMB drüber läuft notwendig.
Die Einstellung "RDMA Mode" auf iWarp setzen ist dann wahrscheinlich nur ein Teil der Settings...(Max QPs Number, Delayed Ack, Recv Window....)
Ja, so ist das.
Wobei einige der Einstellungen nur für RDMA Betrieb nicht notwendig sind, weil die entsprechenden Features bei RDMA eh umgangen werden. Daher ist RDMA per default auch etwas effizienter.
Wenn man jedoch die entsprechenden TCP Features, wie z.B. auch das uralte und mittlerweile unnütze TCP-Delay, welches RDMA von Haus aus umgeht, von Hand bei normalem TCP-Datenverkehr deaktiviert, dann bleibt von dem Vorteil durch RDMA nur noch etwas Staub übrig. 😔
Siehe …
https://community.spiceworks.com/topic/2328491-with-rdma-higher-cpu-load ...
Mit Mesh meine ich die direkte Verkabelung Node 1 zu Node 2/3/4, Node 2 zu Node 1/3/4 usw ohne dabei über einen Switch zu gehen.
Bitte ja nicht, damit tust du dir alles andere als einen Gefallen!Alternative dazu alle NIC Ports auf (redundate) Switche zu führen.
Gute Core-Switche auf beiden Seiten des Clusters und V-LAN sollten auch reichen.Beste Grüsse aus BaWü
Alex
Moin Ueba3ba,
Hier sind von MS selbst ein paar Dinge beschrieben ... das meiste davon ist jedoch meiner Ansicht nach viel zu oberflächlich.
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
Ich finde leider gerade auf die Schnelle die Dokus für die älteren Server nicht mehr.
Mist, in diesen ist nämlich deutlich mehr drin gestanden.
---
Kannst du auf deinem System mal im Vorfeld bitte das folgende testen.
Zuerst bitte die Performance der RDMA Strecke mit diskspd und den folgenden Parametern messen.
und dann auf dem Zielnode bitte auch nochmals lokal laufen lassen, um sicherzustellen das nicht das Storage selbst schon bremst.
Dann benötige ich dieselben Infos wie ich zuletzt auch bei Ostera angefragt habe und schon kann ich dir ein paar gezielte Tipps geben.
Gruss Alex
Bis auf die Einstellungen die ich für RocE und QoS machen muss, sind mir keine weiteren Einstellungen geläufig.
Hier sind von MS selbst ein paar Dinge beschrieben ... das meiste davon ist jedoch meiner Ansicht nach viel zu oberflächlich.
https://learn.microsoft.com/de-de/windows-server/administration/performa ...
Ich finde leider gerade auf die Schnelle die Dokus für die älteren Server nicht mehr.
Mist, in diesen ist nämlich deutlich mehr drin gestanden.
---
Kannst du auf deinem System mal im Vorfeld bitte das folgende testen.
Zuerst bitte die Performance der RDMA Strecke mit diskspd und den folgenden Parametern messen.
diskspd -t4 -o1 -b64k -si64k -w100 -d60 -Su -D -L \\xxx.xxx.xxx.xxx\TEST\IO20G.dat und dann auf dem Zielnode bitte auch nochmals lokal laufen lassen, um sicherzustellen das nicht das Storage selbst schon bremst.
diskspd -t4 -o1 -b64k -si64k -w100 -d60 -Su -D -L C:\TEST\IO20G.dat Dann benötige ich dieselben Infos wie ich zuletzt auch bei Ostera angefragt habe und schon kann ich dir ein paar gezielte Tipps geben.
Gruss Alex
Meine Frage dazu wäre, warum tut man sich S2D an und nicht einfach stattdessen Standalone Hosts ggf mit Replication und ggf. geclusterten Diensten innerhalb der VMs?
Die Komplexität bei Ausfällen wäre dadurch viel geringer, z.B. ein Stromausfallszenario mit Runterfahren per USV lässt sich mit nicht geclusterten Hosts viel einfacher realisieren. Updates laufen einfach automatisch nachts durch ohne irgendwas verschieben zu müssen.
Und ein besseres Preis-Leistungsverhältnis als Direct Attached SSD Storage im Server findest du wohl nicht.
Klar, Live Migration dauert bei Shared Nothing etwas länger, aber so oft muss man das nicht machen wenn von den Hosts nicht gerade einer rumzickt.
Die Komplexität bei Ausfällen wäre dadurch viel geringer, z.B. ein Stromausfallszenario mit Runterfahren per USV lässt sich mit nicht geclusterten Hosts viel einfacher realisieren. Updates laufen einfach automatisch nachts durch ohne irgendwas verschieben zu müssen.
Und ein besseres Preis-Leistungsverhältnis als Direct Attached SSD Storage im Server findest du wohl nicht.
Klar, Live Migration dauert bei Shared Nothing etwas länger, aber so oft muss man das nicht machen wenn von den Hosts nicht gerade einer rumzickt.
Moin rzlbrnft,
ganz einfach, weil das ab einer bestimmten Grösse viel aufwendiger ist als eine Bereitstellung über S2D.
Keineswegs, so kompliziert ist S2D jetzt auch nicht und das sage ich jetzt nicht als Freund von S2D, weil es alleine schon overheadtechnisch einfach nur Horror ist.
Doch, bei einem HA-SAN und da dieses nicht mit der doppelten oder dreifachen SSD's Kapazität bestückt werden muss, kommt es am Ende des Tages auch meistens nicht wirklich teurer raus, als dein Vorschlag.
Na ja, du verbrennst z.B. auch unnötige Kapazitäten für die Replikation, die noch nicht mal in Echtzeit sondern nur Zyklisch läuft.
Ferner wird die CPU-Last von der Storagebereitstellung auf denselben CPU's abgewickelt, die auch gleichzeitig die Leistung für deine VM's liefern sollten.
Du benötigst, für dieses Konzept, wie schon angesprochen, auch immer mindestens die doppelte Anzahl/Kapazität an SSD's.
U.s.w.
Beste Grüsse aus BaWü
Alex
Meine Frage dazu wäre, warum tut man sich S2D an und nicht einfach stattdessen Standalone Hosts ggf mit Replication und ggf. geclusterten Diensten innerhalb der VMs?
ganz einfach, weil das ab einer bestimmten Grösse viel aufwendiger ist als eine Bereitstellung über S2D.
Die Komplexität bei Ausfällen wäre dadurch viel geringer, z.B. ein Stromausfallszenario mit Runterfahren per USV lässt sich mit nicht geclusterten Hosts viel einfacher realisieren. Updates laufen einfach automatisch nachts durch ohne irgendwas verschieben zu müssen.
Keineswegs, so kompliziert ist S2D jetzt auch nicht und das sage ich jetzt nicht als Freund von S2D, weil es alleine schon overheadtechnisch einfach nur Horror ist.
Und ein besseres Preis-Leistungsverhältnis als Direct Attached SSD Storage im Server findest du wohl nicht.
Doch, bei einem HA-SAN und da dieses nicht mit der doppelten oder dreifachen SSD's Kapazität bestückt werden muss, kommt es am Ende des Tages auch meistens nicht wirklich teurer raus, als dein Vorschlag.
Klar, Live Migration dauert bei Shared Nothing etwas länger, aber so oft muss man das nicht machen wenn von den Hosts nicht gerade einer rumzickt.
Na ja, du verbrennst z.B. auch unnötige Kapazitäten für die Replikation, die noch nicht mal in Echtzeit sondern nur Zyklisch läuft.
Ferner wird die CPU-Last von der Storagebereitstellung auf denselben CPU's abgewickelt, die auch gleichzeitig die Leistung für deine VM's liefern sollten.
Du benötigst, für dieses Konzept, wie schon angesprochen, auch immer mindestens die doppelte Anzahl/Kapazität an SSD's.
U.s.w.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Doch, bei einem HA-SAN und da dieses nicht mit der doppelten oder dreifachen SSD's Kapazität bestückt werden muss, kommt es am Ende des Tages auch meistens nicht wirklich teurer raus, als dein Vorschlag.
Doch, bei einem HA-SAN und da dieses nicht mit der doppelten oder dreifachen SSD's Kapazität bestückt werden muss, kommt es am Ende des Tages auch meistens nicht wirklich teurer raus, als dein Vorschlag.
HA-SANs redundant auszulegen kostet in jedem Fall mehr als ein paar SSDs zusätzlich zu kaufen, die Dinger werden einem mittlerweile nachgeworfen. Zudem brauch ich davon auch mehr als eins, wenn ich Daten z.B. über verschiedene Brandabschnitte verteilen muss. 10Gb bzw. 25 Gb NICs und Switches sind auch nicht gerade billig.
Zitat von @MysticFoxDE:
Ferner wird die CPU-Last von der Storagebereitstellung auf denselben CPU's abgewickelt, die auch gleichzeitig die Leistung für deine VM's liefern sollten.
Ferner wird die CPU-Last von der Storagebereitstellung auf denselben CPU's abgewickelt, die auch gleichzeitig die Leistung für deine VM's liefern sollten.
Die CPU Last bei der Bereitstellung von Direct Storage ist aber verschwindend gering. Vor allem verglichen mit dem Overhead, der über die S2D Netzwerkkarten läuft.
//EDIT:
Mal zurück zum Stromausfall, der wohl immer wahrscheinlicher ist, ich musste schon defekte Raid 5 Volumes wiederherstellen, obwohl das ganze innerhalb eines Blechs stattgefunden hat. Controller abgeraucht auch schon ein paar Mal, da lief aber nichts über Netzwerke mit mehreren Komponenten dazwischen, die ausfallen könnten. Da halte ich einen Ausfall bei einer Technik die Windows Updates braucht für mehr als wahrscheinlich.
Hat das hier jemand auch wirklich produktiv im Einsatz?
Moin rzlbrnft,
Nein, HA-SAN bedeutet, dass das SAN mit Redundanten Controllern ausgestattet ist und nicht das es gespiegelt ist.
Und Enterprise SSD's kosten noch nach wie vor nicht wenig und etwas anderes gehört in einen Server/SAN sowieso nicht rein.
Na ja, von der die Idee mit einem gespiegelten SAN war ich noch nie besonders begeistert, weil viele nur daran denken das nach einer Katastrophe die Daten/Systeme so schnell wie möglich online gehen müssen. Dass das eventuell komplett Sinnlos ist, weil der einzige Hauptnetzwerkknoten Richtung der Clients, mit der primären Server/SAN Umgebung mitabgeraucht ist, berücksichtigen jedoch nur sehr wenige.
Auch das brauchst du, insbesondere bei kleineren Umgebungen nicht unbedingt.
Das SAN kommt per SAS oder FC direkt an die Server und gut ist.
Und selbst bei einer gespiegelten Umgebungen benötigst du je nach SAN Hersteller und oder Portkapazität des SAN's, nicht wirklich einen Switch dazwischen, da man viele SAN-Heads auch direkt per LWL untereinander verbinden/koppeln kann.
Wenn du das Direct Storage mit einem ordentlichen RAID-Kontroller realisiert hast, dann ist das vollkommen korrekt.
Jedoch bekommst du auf dem Markt aktuell keinen Server-RAID-Kontroller, der sich auch mit der Performance eines halbwegs erwachsenen SAN's anlegen kann.
Wir haben zudem mehrere Kunden, deren SAN's weit über 24 SSD's beherbergen und spätestens bei solchen Anforderungen, wars das mit dem Direct Storage Konzept.
👍👍👍 mitunter deshalb, kann ich S2D auch nicht wirklich leiden. 😁
Beste Grüsse aus BaWü
Alex
HA-SANs redundant auszulegen kostet in jedem Fall mehr als ein paar SSDs zusätzlich zu kaufen, die Dinger werden einem mittlerweile nachgeworfen.
Nein, HA-SAN bedeutet, dass das SAN mit Redundanten Controllern ausgestattet ist und nicht das es gespiegelt ist.
Und Enterprise SSD's kosten noch nach wie vor nicht wenig und etwas anderes gehört in einen Server/SAN sowieso nicht rein.
Zudem brauch ich davon auch mehr als eins, wenn ich Daten z.B. über verschiedene Brandabschnitte verteilen muss.
Na ja, von der die Idee mit einem gespiegelten SAN war ich noch nie besonders begeistert, weil viele nur daran denken das nach einer Katastrophe die Daten/Systeme so schnell wie möglich online gehen müssen. Dass das eventuell komplett Sinnlos ist, weil der einzige Hauptnetzwerkknoten Richtung der Clients, mit der primären Server/SAN Umgebung mitabgeraucht ist, berücksichtigen jedoch nur sehr wenige.
10Gb bzw. 25 Gb NICs und Switches sind auch nicht gerade billig.
Auch das brauchst du, insbesondere bei kleineren Umgebungen nicht unbedingt.
Das SAN kommt per SAS oder FC direkt an die Server und gut ist.
Und selbst bei einer gespiegelten Umgebungen benötigst du je nach SAN Hersteller und oder Portkapazität des SAN's, nicht wirklich einen Switch dazwischen, da man viele SAN-Heads auch direkt per LWL untereinander verbinden/koppeln kann.
Die CPU Last bei der Bereitstellung von Direct Storage ist aber verschwindend gering.
Wenn du das Direct Storage mit einem ordentlichen RAID-Kontroller realisiert hast, dann ist das vollkommen korrekt.
Jedoch bekommst du auf dem Markt aktuell keinen Server-RAID-Kontroller, der sich auch mit der Performance eines halbwegs erwachsenen SAN's anlegen kann.
Wir haben zudem mehrere Kunden, deren SAN's weit über 24 SSD's beherbergen und spätestens bei solchen Anforderungen, wars das mit dem Direct Storage Konzept.
Vor allem verglichen mit dem Overhead, der über die S2D Netzwerkkarten läuft.
👍👍👍 mitunter deshalb, kann ich S2D auch nicht wirklich leiden. 😁
Beste Grüsse aus BaWü
Alex
@MysticFoxDE
Danke für das Angebot.
Mein Lab ist erst mal down da ich auf 40Gbit umgestellt habe und erst noch alles zusammenbauen und installieren muss. Hab bald Urlaub, dann wird es angegangen. Danach würde ich mich gerne bei dir melden.
Bei mir im Lab setze ich S2D ein. Da ich nur SAS 6G Platten verbaut habe und mir im beruflichen Altag sonst noch kein S2D System untergekommen ist, kann ich leider keinen Vergleich zu anderen Systemen(SAN) anbieten.
Danke für das Angebot.
Mein Lab ist erst mal down da ich auf 40Gbit umgestellt habe und erst noch alles zusammenbauen und installieren muss. Hab bald Urlaub, dann wird es angegangen. Danach würde ich mich gerne bei dir melden.
mitunter deshalb, kann ich S2D auch nicht wirklich leiden.
Bei mir im Lab setze ich S2D ein. Da ich nur SAS 6G Platten verbaut habe und mir im beruflichen Altag sonst noch kein S2D System untergekommen ist, kann ich leider keinen Vergleich zu anderen Systemen(SAN) anbieten.
Hallo,
es gab leider auf Grund von HW-Problemen eine längere Pause - jetzt soll es aber mit der Konfiguration des S2D Clusters weiter gehen.
Hier mein aktueller Plan für die Netzwerkkonfiguration:
Kann mir vielleicht noch jemand bei der genauen Konfiguration der Karten weiterhelfen?
@MysticFoxDE hatte ja schon angedeutet, dass die Konfig etwas Nacharbeit erfordert.
Danke, Ostera
es gab leider auf Grund von HW-Problemen eine längere Pause - jetzt soll es aber mit der Konfiguration des S2D Clusters weiter gehen.
Hier mein aktueller Plan für die Netzwerkkonfiguration:
Kann mir vielleicht noch jemand bei der genauen Konfiguration der Karten weiterhelfen?
@MysticFoxDE hatte ja schon angedeutet, dass die Konfig etwas Nacharbeit erfordert.
Danke, Ostera
