Synology und Windows Server: SMB oder ISCSI

korrekt. Ich mache beides nicht, weil ich NAS normalerweise nicht einsetze. Hin und wieder "erbe" ich aber eine Synology oder schaue eine anlässlich von Beratungen an. Im Kleinunternehmens-Umfeld sehe ich iSCSI extrem selten, meist ist der Storage im Server und das NAS macht entweder Freigaben und/oder Backup (was natürlich schon ein Designfehler ist). Die Freigaben laufen imo im Großen und Ganzen recht ordentlich, mithin würde ich keinen Anlass dafür sehen, mit iSCSI einen weiteren Layer dazwischen zu legen. Andererseits hast Du dann natürlich die gesamte Verwaltung des Storage auf dem Server und das hat auch wieder Vorteile. Vielleicht ist sogar die Performance besser, obgleich mir nicht bekannt wäre, dass die Windows-SMB-Implementierung schneller wäre als Samba unter Linux.

Ich verstehe aber schon grundsätzlich nicht, wozu man den produktiven Storage auf ein NAS packt, wenn man einen Server hat. Klar, wenn der falsch dimensioniert ist oder nur für VMs gebaut, ist das was anderes. Ansonsten gehört der aktive Storage in den Server. Das NAS ist eher Kleinstserver für anspruchslose Miniunternehmen oder Hilfsgerät für spezifische Fälle (obgleich ich den Sinn nicht recht sehe, warum Admins das einsetzen).
Bedenke auch: Das NAS hat meist kein zweites Netzteil, also eine potentielle Ausfallquelle mehr. Dorthin kommen also z.B. Daten, die nicht im ständigen Zugriff sein müssen oder meinetwegen ein Target fürs Backup. Und auch wenn so eine Synology auf den ersten Blick einfach zu verwalten ist, ist es doch ein anderes Gerät, mit Spezifika und Macken. Wenn Linux, dann besser nativ. Dann gibt's auch seltener Zicken.

Viele Grüße, commodity

Edit:
Sehe ich nicht so. Wenn er nur per SMB Files damit shared, können diese auf normalem Wege gesichert werden, das würde ja bei der Nutzung von SMB direkt auf der Synology auch so geschehen (müssen). Eine spezifische Sicherung des Targets darüber hinaus ist imo nicht nötig. Anders natürlich, wenn das Target ein Systemlaufwerk o.ä. ist. Ob das bei Anwendung von FsLogix anders ist, weiß ich nicht, damit kenne ich mich nicht aus.

Hallo zusammen,
wir haben bei ein paar Kunden Synos als HA-Storage im Einsatz. OS-VHDs liegen auf einem NFS-Share. Größere Volumes sind via iSCSI angebunden. Funktioniert problemlos und ist sehr performant. Zudem kann man VMs zügig exportieren / importieren ohne die großen Datenmengen anzufassen.

Bei iSCSI solltest du aber darauf achten, dass die Netzwerkverbindung permanent stabil ist. Im Idealfall eigenes Storage-Netz oder direkt die Geräte verbinden.

Moin,
meine Gedanken dazu:
Wenn es um einen einzigen Hypervisor/Host geht würde ich die Platten intern verbauen.
Ist weniger Komplex und von der rechnerischen Verfügbarkeit deutlich besser.
In einer MS Welt dürftest du zudem mit nem Windows Filer deutlich performanter unterwegs sein, als SMB aufs NAS.

Geht es um mehrere Hosts würde ich das NAS als shared Storage per iSCSI dem Hypervisor unterjubeln.
Dann entfällt eine Replizierung und du fährst die VM einfach auf nem zweiten Host hoch (wenn denn einer da ist). Also ohne Umhängen der LUN zu einer anderen VM.

Ein Backupjob würde die VM dann einfach auf das zweite NAS ablegen

Eigenes Netzwerk/VLAN für iSCSI/Backup kann ich auch nur empfehlen

Gruß und viel Erfolg

Aus der VM heraus, da der Hypervisor das Volumen natürlich nicht kennt. Wenn das iSCSI am Hypervisor hängt, könnte man natürlich auch über diesen sichern.

Genau dies.

+1 für: Bei iSCSI darf das Netzwerk dazwischen niemals abbrechen.

Wenn ein Switch dazwischen ist und dieser neu bootet, ist das Dateisystem schon korrupt. Auch darf das NAS nicht vor dem Windows Server herunterfahren wegen Updates neu starten, dann ist das Dateisystem korrupt.

Ich wüsste nicht was an SMB verkehrt ist.

Denk daran, das Backup muss ein paar Wochen lang wiederherstellbar sein. Manchmal entdeckt man kleiner Fehler erst später. Wenn dann das Backup schon mit einem neuen Backup des fehlerhaften Systems überschrieben ist, hast du keine Chance mehr. Deswegen ist eine tägliche Synchronisierung zum zweite NAS auch kein richtiges Backup, weil du am nächsten Tag den Fehler auch schon auf dem zweiten NAS hast.

Guten Morgen,
SMB getestet (2023) mit DS1621+, DS923+ als Datenserver, Backup auf eine zweite, läuft.

Moin,

Man muß Bedenken, daß, wenn man die "Laufwerke" des Server per iSCSI einbindet und diese dann z.B. per share freigibt, die Daten zwei mal über das Netzwerk müssen. Einmal zu Server hin und von dort zum Client. Daher reduziet sich die maximale Übertragungsrate bei einem GBit-Ethernet auf maximal 50MB/s, das dann auf alles Clients aufgeteilt wird, Sinnvollerweise bindet man dann das NAS entweder über ein separates Interface an den Server an oder schneller als 1Gbps an.

Daher würde ich für normale File-Shares das NAS direkt nutzen. Sofern Du aber Disk-Images für VMs da drauf ablegen willst, würde ich eher direkt iSCSI für die VMs nutzen, weil das den overhead für SMB/CIFS vermeidet.

lks

Kann ich absolut nicht bestätigen. Schon x mal gemacht oder machen müssen und ggf. musste ich ISCSI neu einbinden, was dann schon ein Ausnahmefall war. Ansonsten wurde es nach einem Neustart neu verbunden und das Thema war durch. Korrupte Dateisysteme hatte ich bei ISCSI noch nie.

Das funktioniert nur, wenn ihr kein Schreibcache verwendet, z.B. wenn es nur einzelne kleine Dateien sind. Images von VMs mögen das gar nicht. Das ist wie die Bootplatte im Betrieb abzuziehen. Jedes Betriebssystem macht danach erst einmal ein Checkdisk und im Log findest du dementsprechende Fehler.

Nun wir machen das so:

User Home Files und alles was schnell benötigt wird wie z.B. FSLogix und co liegen direkt auf dem Datacore/ 3PAR Storage welcher dann per FC an die VMWare ESXis angebunden ist. Läuft gut. jetzt haben wir aber auch ein Laufwerk auf dem Images gesammelt werden ( Linux und Unix ) und einen Repository Ordner für verschiedenen Repo Versionen.
Das liegt alles auf dem NAS. Nebenbei gibt es noch einen Share Laufwerk Namens "Copy2". Das liegt auch auf dem NAS weil wenn hier was weg ist dann ists nicht schlimm.

Angebunden sind die NAS bei uns alle per iSCSI an die Server VM´s direkt um hier dann die Freigaben per NTFS und co verwalten zu können. Vorteil ist dann auch hier das wir die Kontingente des Windows Fileservers durchsetzen können.
Probleme mit der Performance habe ich jetzt noch keine erlebt ( bei 250 MA am Standort ) bzw. ich kopiere / lese / schreibe eigentlich immer mit irgendwas um die 90-110 MB/sec. Also annähern 1 GBit LAN. Auch beim Zugriff durch mehrere User gibts da keine Probleme.
Fürher hatten wir die NAS direkt auf dem Hypervisor eingebunden und dann darüber an die VM´s weitergereicht. Fanden wir jetzt nicht so doll.
Einziger Nachteil der Sache ist: Wenn der Server / die Server neu gestartet werden muss hinterher kontrolliert werden ob die iSCSI LUN´s alle wieder verbunden sind weil wenn nicht dann ist der Share(s) nicht da. Wenn es da Probleme gibt reicht es aber die LUNs zu Verbinden - geht ja über den iSCSI Manager ganz gut.

Fileserver auf dem NAS hatten wir auch ( AD Integriert ). War damals eine eigentlich recht gute NAS aber das lief nicht ansatzweise gut obwohl es eigentlich hätte super laufen sollen. Ständig gab es Probleme mit den Berechtigungen. Berechtigungen wurden nur über Gruppen bzw. gem dem von MS genannten Prinzip gesetzt. Wenn dann was mit den NTFS Rechten nicht gepasst hatte half meistens nur ein Neustart. Hatte teilweise das Gefühl das die LDAP(s) Abfragen da nicht wiklich gut liefen bzw. LDAP(s) irgendwie nur Notdürftig implemantiert war.

Hallo,

ich würde die Datacenter-Edition als Hyper-V installieren, den nötigen Speicher für die Fileserver-VM einbauen, die VMs mit Snapshots auf die eine Synology sichern und das Backup zur anderen replizieren.

Auch wenn alles unter bestimmten Bedingungen funktioniert: iSCSI ist ein Verfügbarkeits-Risiko und SMB für Nutzerordner ein Performance-Problem. Beides verkompliziert den Datenfluss und die Werkzeugauswahl beim Backup, hier vermutlich unnötig.

Grüße
Richard

Bekommst du das mit einer vernünftigen Kalkulation gebacken?