2
SoFS: JBODs über Entfernung verbinden
Guten Morgen!
Bez. auf den Post von Gestern, möchte ich meine Fragen zu einem möglichen Konzept genauer stellen und habe daher den alten Post geschlossen:
Hyper-V Core HDD erweitern oder SAN?
Ich beschäftige mich genauer mit einer SoFS Lösung auf Windows 2016 Server Basis mit angeschlossenen JBODs.
Geräte wie Fujitsu's Eternus Serie oder DataOn DNS kommen hierbei ins Spiel, werden aber noch genau eroiert.
Meine Frage:
Da mein Konzept 2 SoFS + JBOD in 2 Brandabschnitten umfasst, stellt sich mir die Frage wie ich die beiden JBODs über Kreuz verbinden kann.
SAS 12G schient ja nur auf kurzen Strecken zu funktionieren. Habe ich hier die Chance über knapp 50m OLM4 Glasfaser zu gehen?
Oder gibt es die Möglichkeit in jeden Brandabschnitt 2 10G Switches zu machen und die per 2x10G Trunk zu verbinden um den Durchsatz zu bekommen?
Danke
M.
Bez. auf den Post von Gestern, möchte ich meine Fragen zu einem möglichen Konzept genauer stellen und habe daher den alten Post geschlossen:
Hyper-V Core HDD erweitern oder SAN?
Ich beschäftige mich genauer mit einer SoFS Lösung auf Windows 2016 Server Basis mit angeschlossenen JBODs.
Geräte wie Fujitsu's Eternus Serie oder DataOn DNS kommen hierbei ins Spiel, werden aber noch genau eroiert.
Meine Frage:
Da mein Konzept 2 SoFS + JBOD in 2 Brandabschnitten umfasst, stellt sich mir die Frage wie ich die beiden JBODs über Kreuz verbinden kann.
SAS 12G schient ja nur auf kurzen Strecken zu funktionieren. Habe ich hier die Chance über knapp 50m OLM4 Glasfaser zu gehen?
Oder gibt es die Möglichkeit in jeden Brandabschnitt 2 10G Switches zu machen und die per 2x10G Trunk zu verbinden um den Durchsatz zu bekommen?
Danke
M.
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: 366409
Url: https://administrator.de/forum/sofs-jbods-ueber-entfernung-verbinden-366409.html
Ausgedruckt am: 25.12.2024 um 16:12 Uhr
2 Kommentare
Neuester Kommentar
Hallo!
Die einzig mir bekannte Lösung hier wäre eine ATTO Bridge (FC<->SAS).
Sonst eben ein Metro-Cluster, der repliziert und nicht direkte SAS-Verbindungen nutzt.
Bei Dir wäre eventuell Starwind eine Option.
Phil
Die einzig mir bekannte Lösung hier wäre eine ATTO Bridge (FC<->SAS).
Sonst eben ein Metro-Cluster, der repliziert und nicht direkte SAS-Verbindungen nutzt.
Bei Dir wäre eventuell Starwind eine Option.
Phil
Ich denke, das Du hier ein paar Dinge auseinander halten solltest, denn so wie du das Problem skizzierst, funktioniert es nicht.
1. Hyper-V Storage Spaces Direct.
Ist die "Converged Storage" Lösung von Microsoft, welche direkt auf HDDs, SSD und NVMe Disks zugreift. Also änlich der von Dir slizzierten Lösung.
Aber: Hier werden die Storages NICHT untereinander verbunden. Der "Traffik" läuft über eine "Monster RDMA >10Gbit LAN Backbone" Verbindung, über der auch der gesamte übrige Traffik abgewickelt wird. Der Storage wird hierbei gespiegelt.
Imho bei nur zwei Knoten eine sehr aufwändige und kostspielige Lösung die, wie viele Posts in diesem Forum belegen, nur bei hohem Hardwareaufwand und großem MS Server Know How des Admin, stabil und performant läuft .
2. "Klassische" Block Storage Lösung. Beispielsweise mit "Eternus DX Storage Cluster"
Zwei, per FC oder 10Gbit iSCSI über Switche angeschlossene Storages, synchron gespiegelt und mit einem Path Failover ausgestattet
99,9999% Verfügbarkeit! (Jede 9 ist gleich einer 0 auf der Rechnung vor dem Komma...
)
3. "Software defined Storage" (SDS)
Lokale Festplatten in den Hyper-V Servern, werden duch eine Software die als VM auf den Servern läuft, virtualisiert und über eine eigene 10Gbit iSCSI Verbindung miteinander synchronisiert.
Gibt es beispielsweise von Datacore (HVS) HPE (StoreVirtual VSA) oder DELL EMC (ScaleIO)
Letzteres halte ich in kleinen Umgebungen für die Beste und preiswerteste Lösung...
1. Hyper-V Storage Spaces Direct.
Ist die "Converged Storage" Lösung von Microsoft, welche direkt auf HDDs, SSD und NVMe Disks zugreift. Also änlich der von Dir slizzierten Lösung.
Aber: Hier werden die Storages NICHT untereinander verbunden. Der "Traffik" läuft über eine "Monster RDMA >10Gbit LAN Backbone" Verbindung, über der auch der gesamte übrige Traffik abgewickelt wird. Der Storage wird hierbei gespiegelt.
Imho bei nur zwei Knoten eine sehr aufwändige und kostspielige Lösung die, wie viele Posts in diesem Forum belegen, nur bei hohem Hardwareaufwand und großem MS Server Know How des Admin, stabil und performant läuft .
2. "Klassische" Block Storage Lösung. Beispielsweise mit "Eternus DX Storage Cluster"
Zwei, per FC oder 10Gbit iSCSI über Switche angeschlossene Storages, synchron gespiegelt und mit einem Path Failover ausgestattet
99,9999% Verfügbarkeit! (Jede 9 ist gleich einer 0 auf der Rechnung vor dem Komma...
)3. "Software defined Storage" (SDS)
Lokale Festplatten in den Hyper-V Servern, werden duch eine Software die als VM auf den Servern läuft, virtualisiert und über eine eigene 10Gbit iSCSI Verbindung miteinander synchronisiert.
Gibt es beispielsweise von Datacore (HVS) HPE (StoreVirtual VSA) oder DELL EMC (ScaleIO)
Letzteres halte ich in kleinen Umgebungen für die Beste und preiswerteste Lösung...
