Hyper-V SMB Netzwerkkommunikation Frage

[NilsK 2.958]

Moin,

 

entschuldige die klaren Worte, aber ich halte dein Design für Unsinn. Keine Redundanz, Abhängigkeit von einer IP-Adresse ... nee.

 

Gruß, Nils

[CoolAce 17]

Morgen,

 

ich kann Sie nachvollziehen deine klaren Worte aber nur mal um das Ganze für mich überhaupt gerade im Moment begreifbar zu machen.

Mann könnte hier natürlich auch ein Team aus 2 10G NIC machen und auf den gestackten Switch anschließen um eine Redundanz zu haben

und wenn ich es richtig verstanden habe wäre die bessere Variante es umzubauen auf Converged Network ?

 

Gruß

 

Coolace

[Doso 77]

Mein bisheriges Verständnis nach dachte ich das ich auf dem Adapter einfach die IP setze und auf dem SwitchPort VLAN 90, da ich zum einbinden der .vhd ja dann als ziel 10.3.0.2

angebe weiß der Hyper-V Server Routingtechnisch das er diesen Adapter nutzen soll oder lieg ich da komplett falsche ?

 

Nein, ein VSwitch, VLAN Tagging und VHD haben jetzt keine IP Adresse. Weiterhin macht Hyper-V kein Routing. Ich glaube du bist da gerade schwer auf dem Holzweg.

[CoolAce 17]

vielleicht hab ich mich da auch nicht komplett korrekt ausgedrückt, in der VM gebe ich ja ein Ziel für die .vdh an das wäre \\NamedesStorage\freigabe\vm\vm.vhdx und dahinter verbirgt sich

ja die IP aber vielleicht bin auch nur schwer auf dem Holzweg

[zahni 554]

Morgen,

 

ich kann Sie nachvollziehen deine klaren Worte aber nur mal um das Ganze für mich überhaupt gerade im Moment begreifbar zu machen.

Mann könnte hier natürlich auch ein Team aus 2 10G NIC machen und auf den gestackten Switch anschließen um eine Redundanz zu haben

und wenn ich es richtig verstanden habe wäre die bessere Variante es umzubauen auf Converged Network ?

 

Gruß

 

Coolace

 

Punkt 1: Das Storage- und das normale Netz sollten immer physikalisch getrennt sein.  Alles: Kabel und auch die Switche. Die Verbindung sollte redundant sein, so dass ein NIC-Port ein Switch und im Storage ein Node ausfallen kann.

SMB 3.0 kann Redundanz bzw Transparent failover, dass muss der Storage aber können (also z.B. mehr als einen Prozessor haben)  und auch entsprechend angeschlossen sein.

Wenn man darüber nachdenkt ist FC doch nicht mehr so teuer. Und FC ist in einer kleinen Umgebung nicht wirklich komplizierter als ISCSI. Was schöner ist? K.A. FC kann aktuell bis 32 GBit/s

 

Wobei ich einschränkend sagen muss, dass in VMWare-Umgebungen gern mal NFS genommen wird.  

[CoolAce 17]

OK, Danke für die Unterstützung. Ich werde mich mal mit dem Thema Converged Network und deren Konfiguration in einem Hyper-V Cluster beschäftigen.

[carnivore 10]

Allgemein werden die Vorteile von SMB 3.x oft über-, dafür die Voraussetzungen unterschätzt. In mittelständischen Umgebungen spricht m.E. nur selten etwas für SMB 3.x.

 

Nach meinem, mal wieder nur theoretischem Verständnis, haben iSCSI und FC kaum Security Features dabei. Hingegen ist SMB 3 state of the art in Bezug of Encryption and Signing.

[Reingucker 3]

Offtopic

 

Man kann noch einen drauf packen: Software-iSCSI über SMB3 ^^

 

scnr

[magheinz 110]

Kannst du mal kurz erklären was du hier in diesem Zusammenhang mit "converged network" meinst?

 

Ich denke du hast da eine eher simple Struktur.

Wenn du keine zusätzlichen Switche hast:

1. Hänge die Server über Kreuz per 10G an deine Coreswitche

2. Hänge deine EMC an die coreswitche

3. Trenne den Traffic per VLAN auf den 10G-Verbindungen.

 

wenn du extra storageswitche hast

1. hänge die 10G-Adapter über Kreuz an die Storageswitche

2. hänge die EMC an die Storageswitche

3. Hänge die 1G-Adapter über Kreuz an die Coreswitche

4. Schau ob du über die Storageswitche auch vmotion(wie auch immer das bei hyperv heisst) per VLAN getrennt laufen lassen kannst.

 

je nach EMC-Modell:

1. hänge die EMC direkt auf die 10G-Adapter (wenn genug Ports auf der EMC sind.)

2. Nutze ISCSI-Multipath für die Redundanz

3. Hänge die 1G-Adapter über Kreuz an die Coreswitche

[Doso 77]

Nach meinem, mal wieder nur theoretischem Verständnis, haben iSCSI und FC kaum Security Features dabei. Hingegen ist SMB 3 state of the art in Bezug of Encryption and Signing.

 

Stellt sich halt die Frage ob man in einem physisch sicheren Rechenzentrum in einem separaten und nicht geroutetem Netzwerk überhaupt Verschlüsselung braucht. iSCSI kann auch noch CHAP, oder man setzt Radius oder IPSec ein wenn man denn unbedingt möchte.

bearbeitet 6. Januar 2017 von Doso

[carnivore 10]

Stellt sich halt die Frage ob man in einem physisch sicheren Rechenzentrum in einem separaten und nicht geroutetem Netzwerk überhaupt Verschlüsselung braucht. iSCSI kann auch noch CHAP, oder man setzt Radius oder IPSec ein wenn man denn unbedingt möchte.

Das müssen die Security Policies bzw. die individuellen Gegebenheiten des Kunden beantworten. In meiner Company gilt beispielsweise die einfache Policy, dass jedweder Datenverkehr bestmöglich verschlüsselt sein muss. Kann CHAP oder  RADIUS Datenverkehr verschlüsseln? 

Ich würde den Aspekt bei einer Entscheidung pro/ contra SMB3 als Dienstleister auch eines mittelständischen Kunden jedenfalls nicht einfach zur Seite schieben. Was immer dann auch am Ende machbar und sinnvoll ist. 

bearbeitet 6. Januar 2017 von carnivore

[NilsK 2.958]

Moin,

 

huiuiui - nehmt es mir nicht übel, aber jetzt bekommt es doch einen esoterischen Touch.

 

Der TO ist offenbar mit Architektur und Einrichtung der Storage-Anbindung sowie des Netzwerkdesigns stark überfordert. Jetzt noch mit Befindlichkeiten in Bezug auf Verschlüsselung zu kommen, wenn in dem Thread offenbar geworden ist, dass die bisherigen Entscheidungen überhaupt nicht auf geschäftlichen Anforderungen beruhen, ist dann doch etwas weit hergeholt.

 

Ebenso weit hergeholt ist es, eine grundsätzliche Überlegenheit von SMB 3.x gegenüber iSCSI oder FC in Bezug auf Sicherheit konstruieren zu wollen.

 

Gruß, Nils