13
Optimale Konfig Synology ISCSI 10GBit an Windows Server
Hallo zusammen,
an einem Synology Storage habe ich einen Speicherpool, Raid 6 mit 100 TB erstellt.
Die 100 TB sollen als ein Gesamtvolume an einem Windows Server zur Verfügung gestellt werden,
anbindung erfolgt via ISCSI. Auf den 100 TB werden Backupdaten, immer zwischen 50GB - 1 TB groß, gespeichert.
Ich suche aktuell nach der optimalen Konfiguration zur Performance dieser Anbindung und freue mich über Tipps oder Erfahrungswerte dazu.
Im Prinzip habe ich zwei Optionen:
Option 1:
- 100 TB Speicherpool bereit stellen mit 2x 50 TB Volume
- via ISCSI je Volume mit 10 GBit Lune an Windows Server anbinden
- Beide 50 TB Volumes via übergreifendes Volume als ein 100TB Volume am Windows Server bereit stellen
Option 2:
- 100 TB Speicherpool bereit stellen mit 1x 100 TB Volume
- via ISCSI Volume mit 2x 10 GBit LACP Lune an Windows Server anbinden
- 100 TB Volume am Windows Server bereit stellen
Vielen Dank schonmal für alle Erfahrungswerte und Rückmeldungen!
an einem Synology Storage habe ich einen Speicherpool, Raid 6 mit 100 TB erstellt.
Die 100 TB sollen als ein Gesamtvolume an einem Windows Server zur Verfügung gestellt werden,
anbindung erfolgt via ISCSI. Auf den 100 TB werden Backupdaten, immer zwischen 50GB - 1 TB groß, gespeichert.
Ich suche aktuell nach der optimalen Konfiguration zur Performance dieser Anbindung und freue mich über Tipps oder Erfahrungswerte dazu.
Im Prinzip habe ich zwei Optionen:
Option 1:
- 100 TB Speicherpool bereit stellen mit 2x 50 TB Volume
- via ISCSI je Volume mit 10 GBit Lune an Windows Server anbinden
- Beide 50 TB Volumes via übergreifendes Volume als ein 100TB Volume am Windows Server bereit stellen
Option 2:
- 100 TB Speicherpool bereit stellen mit 1x 100 TB Volume
- via ISCSI Volume mit 2x 10 GBit LACP Lune an Windows Server anbinden
- 100 TB Volume am Windows Server bereit stellen
Vielen Dank schonmal für alle Erfahrungswerte und Rückmeldungen!
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: 1278029144
Url: https://administrator.de/contentid/1278029144
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
Frage: Hast du im Server keinen Platz für die Platten?
LG
Frage: Hast du im Server keinen Platz für die Platten?
LG
Hallo,
Wenn die Platten und die LUN im Synology existieren, ist es natürlich sinnvoll die gesamte Kapazität im Synology bereitzustellen und dann als 1 LUN einzubinden.
Ich habe hier auch eine VEEAM Server, welches ein 168TB LUN von einem QNAP eingebunden hat.
Die Verkabelung würde ich, wenn möglich direkt vornehmen, ohne Switch dazwischen.
Ich weiß nicht wie es bei synology aussieht, aber QNAP unterstütz mittlerweile auch FibreChannel statt iscsi
Wenn die Platten und die LUN im Synology existieren, ist es natürlich sinnvoll die gesamte Kapazität im Synology bereitzustellen und dann als 1 LUN einzubinden.
Ich habe hier auch eine VEEAM Server, welches ein 168TB LUN von einem QNAP eingebunden hat.
Die Verkabelung würde ich, wenn möglich direkt vornehmen, ohne Switch dazwischen.
Ich weiß nicht wie es bei synology aussieht, aber QNAP unterstütz mittlerweile auch FibreChannel statt iscsi
Moin,
würde ebenfalls alles als eine große LUN bereitstellen.
Sofern möglich dann mit ReFS formatieren - Läuft hier für unsere Veeam-Kiste (allerdings mit einem IBM-SAN drunter) auch hervorragend.
Die Idee mit FC ist gar nicht so verkehrt.
Synology bietet das auch an: https://www.synology.com/de-de/compatibility?search_by=category&cate ...
Vorteil hierbei: 16Gbit FC sind schneller als 10Gbit iSCSI, auch deswegen, weil IMHO das FibreChannel-Protokoll schlanker ist, als das iSCSI-Protokoll
https://www.elektronik-kompendium.de/sites/net/0905071.htm
Edit: Schneller im Sinne von: es können mehr Nutzdaten je Paket transportiert werden.
Der Idealausbau wäre dann:
zwei 2-Port-Karten im NAS
zwei 2-Port-Karten im Server
somit hast du die Maximal-Mögliche Redundanz geschaffen. Es können dann nur doch der gesamte Server/ das gesamte NAS ausfallen.
Gruß
em-pie
würde ebenfalls alles als eine große LUN bereitstellen.
Sofern möglich dann mit ReFS formatieren - Läuft hier für unsere Veeam-Kiste (allerdings mit einem IBM-SAN drunter) auch hervorragend.
Die Idee mit FC ist gar nicht so verkehrt.
Synology bietet das auch an: https://www.synology.com/de-de/compatibility?search_by=category&cate ...
Vorteil hierbei: 16Gbit FC sind schneller als 10Gbit iSCSI, auch deswegen, weil IMHO das FibreChannel-Protokoll schlanker ist, als das iSCSI-Protokoll
https://www.elektronik-kompendium.de/sites/net/0905071.htm
Edit: Schneller im Sinne von: es können mehr Nutzdaten je Paket transportiert werden.
Der Idealausbau wäre dann:
zwei 2-Port-Karten im NAS
zwei 2-Port-Karten im Server
somit hast du die Maximal-Mögliche Redundanz geschaffen. Es können dann nur doch der gesamte Server/ das gesamte NAS ausfallen.
Gruß
em-pie
Hi,
geteilte Meinung zwischen Veeam und M$.
Leider musste ich vor einem halben Jahr bei M$ einen Support Case öffnen in Bezug auf ISCSI und ReFS (remote Storage). - es war kein Zugriff mehr möglich (640 TB an Backupdaten)
M$ hat durch Prüfung mitgeteilt dass dies einfach nicht supported ist.
Nur für S2D sei ReFS (Platten im Bauch).
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
Hab dann darauf hingewiesen dass Veeam damit auf diese Weise arbeitet jedoch ist auch dies M$ egal.
War damals zum Glück gespiegelt aber falls jemand ein Single Node System betreibt sollte dies Mal prüfen lassen.
Solange es rennt top sobald ein Fehler Flopp.
Wer nun Recht hat oder nicht (vllt. Deppensupporter) kann ich nicht sagen jedoch im Zweifel der Hersteller des Filesystems.
Grüße
geteilte Meinung zwischen Veeam und M$.
Leider musste ich vor einem halben Jahr bei M$ einen Support Case öffnen in Bezug auf ISCSI und ReFS (remote Storage). - es war kein Zugriff mehr möglich (640 TB an Backupdaten)
M$ hat durch Prüfung mitgeteilt dass dies einfach nicht supported ist.
Nur für S2D sei ReFS (Platten im Bauch).
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overvi ...
Hab dann darauf hingewiesen dass Veeam damit auf diese Weise arbeitet jedoch ist auch dies M$ egal.
War damals zum Glück gespiegelt aber falls jemand ein Single Node System betreibt sollte dies Mal prüfen lassen.
Solange es rennt top sobald ein Fehler Flopp.
Wer nun Recht hat oder nicht (vllt. Deppensupporter) kann ich nicht sagen jedoch im Zweifel der Hersteller des Filesystems.
Grüße
@Fabezz
Ich muss bei meiner Aussage oben ergänzen, dass unser VEEAM der/ die/ das LUN via FC eingebunden hat.
Aber danke für en Hinweis. Das ist gut zu wissen!
Ich muss bei meiner Aussage oben ergänzen, dass unser VEEAM der/ die/ das LUN via FC eingebunden hat.
Aber danke für en Hinweis. Das ist gut zu wissen!
Moin zusammen,
danke für die vielen Rückmeldungen!
Ich werde das ganze dann als eine Lun einbinden, scheint also die optimale Option zu sein.
Tatsächlich wäre FC auch eine Option gewesen, aktuell wurde aber auf ISCSI gesetzt weil die HW teilweise schon vorhanden war.
Was teilweise immer mal bei den NAS Systemen auftritt sind Begrenzungen bei den Volumes,
bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Eine Möglichkeit ist es dann die beiden in Windows per ISCSI eingebundenen Volumes wieder via "übergreifendes" Volume zu einem zusammen zu führen. Hat hier jemand Erfahrung wie sich dies auf die Performance, Nutzbarkeit
oder andere Nachteile auswirkt?
Grüße
danke für die vielen Rückmeldungen!
Ich werde das ganze dann als eine Lun einbinden, scheint also die optimale Option zu sein.
Tatsächlich wäre FC auch eine Option gewesen, aktuell wurde aber auf ISCSI gesetzt weil die HW teilweise schon vorhanden war.
Was teilweise immer mal bei den NAS Systemen auftritt sind Begrenzungen bei den Volumes,
bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Eine Möglichkeit ist es dann die beiden in Windows per ISCSI eingebundenen Volumes wieder via "übergreifendes" Volume zu einem zusammen zu führen. Hat hier jemand Erfahrung wie sich dies auf die Performance, Nutzbarkeit
oder andere Nachteile auswirkt?
Grüße
Zitat von @em-pie:
@Fabezz
Ich muss bei meiner Aussage oben ergänzen, dass unser VEEAM der/ die/ das LUN via FC eingebunden hat.
Aber danke für en Hinweis. Das ist gut zu wissen!
@Fabezz
Ich muss bei meiner Aussage oben ergänzen, dass unser VEEAM der/ die/ das LUN via FC eingebunden hat.
Aber danke für en Hinweis. Das ist gut zu wissen!
So wie ich den Artikel verstanden und auch den Support betrifft dies jeglichen Remote Storage egal welches Protokoll in Verbindung mit ReFS.
Aber nochmal prüfen kann sich in Zwischenzeit geändert haben. Wir werden auf jeden Fall nicht mehr auf Remote verwenden.
Zitat von @em-pie:
Moin,
würde ebenfalls alles als eine große LUN bereitstellen.
Sofern möglich dann mit ReFS formatieren - Läuft hier für unsere Veeam-Kiste (allerdings mit einem IBM-SAN drunter) auch hervorragend.
Achtung!Moin,
würde ebenfalls alles als eine große LUN bereitstellen.
Sofern möglich dann mit ReFS formatieren - Läuft hier für unsere Veeam-Kiste (allerdings mit einem IBM-SAN drunter) auch hervorragend.
ReFs per ISCSI ist nicht supported. Ich hatte damit extreme Probleme, wenn ich davon auf eine Tape Library schreiben wollte (ich kam nicht über 25 MB/s.)
Zitat von @Fabezz:
Leider musste ich vor einem halben Jahr bei M$ einen Support Case öffnen in Bezug auf ISCSI und ReFS (remote Storage). - es war kein Zugriff mehr möglich (640 TB an Backupdaten)
Ich hatte wie erwähnt auch Probleme damit.Leider musste ich vor einem halben Jahr bei M$ einen Support Case öffnen in Bezug auf ISCSI und ReFS (remote Storage). - es war kein Zugriff mehr möglich (640 TB an Backupdaten)
M$ hat durch Prüfung mitgeteilt dass dies einfach nicht supported ist.
Nur für S2D sei ReFS (Platten im Bauch).
Eben....Nur für S2D und als Lokaler Datenträger ist die offiziell supported. Daher bin ich zurück zu NTFS.Nur für S2D sei ReFS (Platten im Bauch).
Was teilweise immer mal bei den NAS Systemen auftritt sind Begrenzungen bei den Volumes,
bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Das stimmt nicht ganz. Es kommt drauf an, was für ein Synology NAS man einsetzte. Die Mittelklasse Serien können nur 108TB.bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Die "besseren" Geräte können 200 TB
Siehe dazu auch:
kb.synology.com/de-de/DSM/tutorial/Why_does_my_Synology_NAS_have_a_single_volume_size_limitation
Eine Möglichkeit ist es dann die beiden in Windows per ISCSI eingebundenen Volumes wieder via "übergreifendes" Volume zu einem zusammen zu führen. Hat hier jemand Erfahrung wie sich dies auf die Performance, Nutzbarkeit
oder andere Nachteile auswirkt?
Ja das geht, aber da hast du wieder eine Fehlerquelle mehr drin...und zwar Windowsoder andere Nachteile auswirkt?
Dann nutze doch lieber bei Veeam die Scale-Out-Repository Funktion. Da kannst du mehrere Repository als ein Repo zusammenfügen.
So liegen die Daten wirklich physisch auf dem jeweiligen Volume / LUN und Veeam kümmert sich um die Verteilung
Hi tech-flare,
Das ist interessant, danke für den Link, in meinem Fall habe ich sogar ein "RS3621RPxs"
was laut des Links 200TB supporten sollte, mit BTRFS klappen aber aktuell nur max. 108 TB.
Zitat von @tech-flare:
Die "besseren" Geräte können 200 TB
Siehe dazu auch:
kb.synology.com/de-de/DSM/tutorial/Why_does_my_Synology_NAS_have_a_single_volume_size_limitation
Was teilweise immer mal bei den NAS Systemen auftritt sind Begrenzungen bei den Volumes,
bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Das stimmt nicht ganz. Es kommt drauf an, was für ein Synology NAS man einsetzte. Die Mittelklasse Serien können nur 108TB.bei Synology liegt die z.B. bei max. 108 TB pro Volume.
Wenn man dann z.B. ein Raid6 mit 160 TB hätte, müsste man zwei Volumes erstellen.
Die "besseren" Geräte können 200 TB
Siehe dazu auch:
kb.synology.com/de-de/DSM/tutorial/Why_does_my_Synology_NAS_have_a_single_volume_size_limitation
Das ist interessant, danke für den Link, in meinem Fall habe ich sogar ein "RS3621RPxs"
was laut des Links 200TB supporten sollte, mit BTRFS klappen aber aktuell nur max. 108 TB.
Eine Möglichkeit ist es dann die beiden in Windows per ISCSI eingebundenen Volumes wieder via "übergreifendes" Volume zu einem zusammen zu führen. Hat hier jemand Erfahrung wie sich dies auf die Performance, Nutzbarkeit
oder andere Nachteile auswirkt?
Ja das geht, aber da hast du wieder eine Fehlerquelle mehr drin...und zwar Windowsoder andere Nachteile auswirkt?
Das stimmt, ein Problem damit gab es schonmal wenn die Datenträger nach dem Neustart von Windows falsch erkannt werden, statt als dynamisches als unbekanntes Format, da kann es unschön werden wenn man nicht genau weiß was man tut
Aber Performanceseitig würde ich vermuten ist es fast egal ob einzelner Datenträger oder ein übergreifendes Volume?!
Dann nutze doch lieber bei Veeam die Scale-Out-Repository Funktion. Da kannst du mehrere Repository als ein Repo zusammenfügen.
So liegen die Daten wirklich physisch auf dem jeweiligen Volume / LUN und Veeam kümmert sich um die Verteilung
Veeam werde ich mir mit der Funktion mal ansehen, die verteilten Speicherorte und flexible Zusammenfassung von Speichern ist ja mittlerweile recht verbreitet, trotzdem bin ich bislang der Meinung wenn es geht dann lieber weniger logik on top packen. Bei den großen Speicheranforderungen wird es aber zunehmend interessant alle verteilten Ressourcen mit einzubinden.
Wenn du rein auf Backup mittels Veeam aus bist dann würde ich nicht ein "simples" Target empfehlen.
Schau dich Mal Richtung SDS mit object Lock um wie zum Beispiel Cloudian.
Backup ist das wichtigste des Unternehmens im Desasterfall.
Gruß
Schau dich Mal Richtung SDS mit object Lock um wie zum Beispiel Cloudian.
Backup ist das wichtigste des Unternehmens im Desasterfall.
Gruß
Zitat von @melters:
Veeam werde ich mir mit der Funktion mal ansehen, die verteilten Speicherorte und flexible Zusammenfassung von Speichern ist ja mittlerweile recht verbreitet, trotzdem bin ich bislang der Meinung wenn es geht dann lieber weniger logik on top packen. Bei den großen Speicheranforderungen wird es aber zunehmend interessant alle verteilten Ressourcen mit einzubinden.
Veeam werde ich mir mit der Funktion mal ansehen, die verteilten Speicherorte und flexible Zusammenfassung von Speichern ist ja mittlerweile recht verbreitet, trotzdem bin ich bislang der Meinung wenn es geht dann lieber weniger logik on top packen. Bei den großen Speicheranforderungen wird es aber zunehmend interessant alle verteilten Ressourcen mit einzubinden.
Ich würde da doch eher Veeam vertrauen Daten sinnvoll auf mehreren Volumes zu verwalten als unter Windows ein übergreifendes Volume über LUNs zu betreiben. Windows ist immer noch super darin ein Dateisystem zu schrotten.
Da deine Synology vermutlich nur einen Controller hat würde ich sagen eine große LUN, wenn alle Komponenten das unterstützen. Wenn nicht kann man aber auch mit Veeam und mehreren LUNs gut fahren. Wenn man eine SAN hat die eventuell mehrere Controller nutzt kann ein Split auf 2 LUNs durchaus Performance bringen.
