25
Fileserver auf Windows Server 2016 - wie einrichten?
Hallo an alle!
In unserem Unternehmen (20 - 30 Mintarbeiter und einige Servern im Bereich der Druckvorstufe) ist momentan ein Helios Fileserver auf einem Solaris 11 im Einsatz, der die Einbindung von Volumes via SMB(1.0) und AFP verwaltet.
→ Im Grunde ist es also so, dass wir gezwungen sind, auf einen Windows Dateiserver auszuweichen, um den vollen Support bei ESKO zu haben und nicht vor einer Wand zu stehen, falls Apple in einer der nächsten OS-Versionen den AFP-Strang abschneiden sollte.
Die zugrundeliegende Infrastruktur und die Rahmenbedingungen zusammengefasst:
Da ich bisher noch nichts in der Richtung Fileserver auf einem Windows Server eingerichtet habe, wüsste ich gerne, was man alles tun muss / sollte, damit sowas zuverlässig läuft.
Außerdem benötige ich die Information, ob das mit der Idee, das über ISCSI einzubinden, überhaupt läuft oder eher von sowas abzuraten ist.
Ferner wäre es interessant zu wissen, ob man das auf einem virtualisierten (VMWare) System laufen lassen kann, oder wie die Hardware aussehen sollte, damit es unter den beschriebenen Bedingungen performant funktionieren kann. Selbstverständlich wird eine Testphase eingeplant, um das mit reduziertem Datenvolumen und unter großer Last durch die Clients getestet werden wird.
Und schließlich wäre es gut zu wissen, mit welcher Software sowas vernünftig und automatisiert gebackupt / repliziert werden kann. Hier ist vor Allem auch an die relativ umfangreiche Gesamtgröße zu denken und dass es regelmäßig ein Fullbackup geben sollte, das die Dauer von 2 1/2 Tagen möglichst nicht überschreiten sollte.
Solltet Ihr noch Fragen haben, bitte einfach fragen. Ich würde mich sehr über Hilfe freuen.
Grüße,
Mondragor alias Christian
In unserem Unternehmen (20 - 30 Mintarbeiter und einige Servern im Bereich der Druckvorstufe) ist momentan ein Helios Fileserver auf einem Solaris 11 im Einsatz, der die Einbindung von Volumes via SMB(1.0) und AFP verwaltet.
- AFP wird seit ettlichen Jahren nicht weiter entwickelt und Apple wird den Support irgendwann ganz einstellen.
- SMB wird von Helios ebenfalls seit 9 Jahren nicht weiter entwickelt. Ich habe immer wieder nachgefragt aber es ist kein Fortschritt zu verzeichnen. Ich rechne nicht damit, dass sich da noch etwas tun wird. Der (einstige) DACH-Support von Helios hatte mir dazu vor Jahren bereits auch nicht viel Hoffnung gemacht, ebenso wie unser Supportpartner in diesem Bereich.
- Apple unterstützt seit Jahren SMB1 nicht mehr und auch unter Windws muss das erst nachinstalliert werden.
- Der Hersteller unserer Software (ESKO) unterstützt offiziell nur Windows Dateiserver.
→ Im Grunde ist es also so, dass wir gezwungen sind, auf einen Windows Dateiserver auszuweichen, um den vollen Support bei ESKO zu haben und nicht vor einer Wand zu stehen, falls Apple in einer der nächsten OS-Versionen den AFP-Strang abschneiden sollte.
Die zugrundeliegende Infrastruktur und die Rahmenbedingungen zusammengefasst:
- Raid-System ist ein QSAN XS3226 D, das mit SAS-SSDs (im Raid 6) bestückt ist und per ISCSI-Initiator an Windows Server 2016 als Datenträger angebunden werden soll. Mit dem Netzwerk ist dieses Gerät mit 2*10 GBit/s angebunden (LAG).
- Von der Last her werden ca. 50 gleichzeitige Verbindungen (Größenordnung) zu erwarten sein.
- Die Datenlast wird zwischen 15 und 40 TB betragen, also die Größe des Datenträgers max. 40 TB.
- Es arbeiten bis zu 25 Personen gleichzeitig mit den Daten, wobei konkurrierender Zugriff auf identische Dateien eher ausgeschlossen ist.
- Die tägliche Datenänderungsrate ist in einer Größenordnung von 20 - 40 GB.
- Es handelt sich um 1, maximal 2 Freitaben, die per SMB dann für alle zugreifbar sein soll, allerdings nicht sehr umständlich, was die Berechtigungen angeht, Es ist davon auszugehen, dass alle lesen und schreiben dürfen.
- Ein externer Zugriff etwa vom Homeoffice sollte per VPN-Zugang schon möglich sein.
- Die Freigaben sollen auf Apple und PC gleichzeitig verfügbar sein.
- Zugreifende Programme sind z.B. Adobe's PS, ID, AI und ESKO ArtPro (&ArtPro +) sowie die Automation Engine.
- Die Bandbreite der Clients ist je 1 GBit/s
Da ich bisher noch nichts in der Richtung Fileserver auf einem Windows Server eingerichtet habe, wüsste ich gerne, was man alles tun muss / sollte, damit sowas zuverlässig läuft.
Außerdem benötige ich die Information, ob das mit der Idee, das über ISCSI einzubinden, überhaupt läuft oder eher von sowas abzuraten ist.
Ferner wäre es interessant zu wissen, ob man das auf einem virtualisierten (VMWare) System laufen lassen kann, oder wie die Hardware aussehen sollte, damit es unter den beschriebenen Bedingungen performant funktionieren kann. Selbstverständlich wird eine Testphase eingeplant, um das mit reduziertem Datenvolumen und unter großer Last durch die Clients getestet werden wird.
Und schließlich wäre es gut zu wissen, mit welcher Software sowas vernünftig und automatisiert gebackupt / repliziert werden kann. Hier ist vor Allem auch an die relativ umfangreiche Gesamtgröße zu denken und dass es regelmäßig ein Fullbackup geben sollte, das die Dauer von 2 1/2 Tagen möglichst nicht überschreiten sollte.
Solltet Ihr noch Fragen haben, bitte einfach fragen. Ich würde mich sehr über Hilfe freuen.
Grüße,
Mondragor alias Christian
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: 32993313684
Url: https://administrator.de/contentid/32993313684
Ausgedruckt am: 23.11.2024 um 01:11 Uhr
25 Kommentare
Neuester Kommentar
Hört sich machbar und funktional an.
Ein Hypervisor schafft Flexibilität. Auch die Backups kannj eine VM machen auf dem SAN und dann noch zusätzlich Offsite, z. B. per S3, sichern. iSCSI ist völlig in Ordnung und up2date.
Ein Hypervisor schafft Flexibilität. Auch die Backups kannj eine VM machen auf dem SAN und dann noch zusätzlich Offsite, z. B. per S3, sichern. iSCSI ist völlig in Ordnung und up2date.
Moin @Mondragor
dein Fragenkatalog ist sehr umfangreich.
Zunächst: Wenn du eigentlich NUR SMB Brauchst, muss es kein Windows Server sein. Das bekommst du auch mit vielen anderen Produkten hin, die den Samba-Server beinhalten oder ggf. auch mit Windows Core Hypertonie-V 2019 kostenlos.
Nur wenn dir nach Active Directory (AD) ist, ist eben eher Windows Server die Wahl. Active Directory ist aber so umfangreich, dass man es an der stelle nicht erklären kann/will.
Windows server ihn AD ist schnell installiert, der Filierter-Dienst ist automatisch immer mitinstalliert und sofort nutzbar.
Man sollte aber NIE freigaben für User auf dem Systemvolume machen, sondern IMMER weitere Platten/Volumes dazu benutzen. Darüber hinaus NIE Freigaben direkt auf einem ROOT-Directory /Laufwerk machen. (also nicht sowas wie D:/ freigeben, sondern immer D:/Verzeichnisname)
Virtualisieren von Windows Server ist möglich. (Hypertonie-V, VM-Ware ESXi, etc....)
Dir jetzt aber mal ebenWindows server erklären ist wohl hier an der stelle ausgeschlossen.
Kreuzberger
dein Fragenkatalog ist sehr umfangreich.
Zunächst: Wenn du eigentlich NUR SMB Brauchst, muss es kein Windows Server sein. Das bekommst du auch mit vielen anderen Produkten hin, die den Samba-Server beinhalten oder ggf. auch mit Windows Core Hypertonie-V 2019 kostenlos.
Nur wenn dir nach Active Directory (AD) ist, ist eben eher Windows Server die Wahl. Active Directory ist aber so umfangreich, dass man es an der stelle nicht erklären kann/will.
Windows server ihn AD ist schnell installiert, der Filierter-Dienst ist automatisch immer mitinstalliert und sofort nutzbar.
Man sollte aber NIE freigaben für User auf dem Systemvolume machen, sondern IMMER weitere Platten/Volumes dazu benutzen. Darüber hinaus NIE Freigaben direkt auf einem ROOT-Directory /Laufwerk machen. (also nicht sowas wie D:/ freigeben, sondern immer D:/Verzeichnisname)
Virtualisieren von Windows Server ist möglich. (Hypertonie-V, VM-Ware ESXi, etc....)
Dir jetzt aber mal ebenWindows server erklären ist wohl hier an der stelle ausgeschlossen.
Kreuzberger
Hallo Kreuzberger,
also ich habe bereits Server 2016 auf ca. 15 virtualisierten (VMWare) Systemen laufen und entsprechende Datacenter-Lizenzen.
Einen AD-Server ist auch darunter. Nutzer und sinnvoll zusammengefasste Gruppen auf AD-Ebene sind ebenfalls vorhanden.
Allerdings hat keins dieser Systeme bisher die "Rolle" eines Dateiservers in diesem Sinne.
Grundsätzlich funktioniert SMB ja auch ohne irgendwelche großartigen Einstellungen, indem man ein Verzeichnis freigibt. Aber die Frage ist, ob es da spezifische Einstellungen (z.B. in der Registry) oder Dienste gibt, die sinnvollerweise noch vorzunehmen / zu aktivieren sind, um die Pereformance zu steigern und/oder nicht in irgendwelche Beschränkungen gleichzeitiger Zugriffe (...) zu laufen (im Rahmen der beschriebenen Bedingungen).
(Ich erinnere mich beispielsweise an ein System, bei dem die Net sessions regelmäßig gelöscht werden mussten, das war allerdings noch unter Windows Vista...)
Ich würde selbstverständlich die Freigabe auf Verzeichnisebene machen und das Storage wäre ja per ISCSI in ein laufendes Windows Server 2016 eingebunden und somit ohnehin kein System-/Root-Laufwerk in dem Sinne.
also ich habe bereits Server 2016 auf ca. 15 virtualisierten (VMWare) Systemen laufen und entsprechende Datacenter-Lizenzen.
Einen AD-Server ist auch darunter. Nutzer und sinnvoll zusammengefasste Gruppen auf AD-Ebene sind ebenfalls vorhanden.
Allerdings hat keins dieser Systeme bisher die "Rolle" eines Dateiservers in diesem Sinne.
Grundsätzlich funktioniert SMB ja auch ohne irgendwelche großartigen Einstellungen, indem man ein Verzeichnis freigibt. Aber die Frage ist, ob es da spezifische Einstellungen (z.B. in der Registry) oder Dienste gibt, die sinnvollerweise noch vorzunehmen / zu aktivieren sind, um die Pereformance zu steigern und/oder nicht in irgendwelche Beschränkungen gleichzeitiger Zugriffe (...) zu laufen (im Rahmen der beschriebenen Bedingungen).
(Ich erinnere mich beispielsweise an ein System, bei dem die Net sessions regelmäßig gelöscht werden mussten, das war allerdings noch unter Windows Vista...)
Ich würde selbstverständlich die Freigabe auf Verzeichnisebene machen und das Storage wäre ja per ISCSI in ein laufendes Windows Server 2016 eingebunden und somit ohnehin kein System-/Root-Laufwerk in dem Sinne.
Moin,
Windows Search sollte man installieren. Das ist auf dem Server im Standard nicht vorhanden.
Bei einem neu aufzusetzenden System würde ich auch immer über DFS nachdenken. Das macht die Sache flexibler und leichter zu skalieren (mal von der Redundanz abgesehen).
hth
Erik
Zitat von @Mondragor:
Allerdings hat keins dieser Systeme bisher die "Rolle" eines Dateiservers in diesem Sinne.
Grundsätzlich funktioniert SMB ja auch ohne irgendwelche großartigen Einstellungen, indem man ein Verzeichnis freigibt. Aber die Frage ist, ob es da spezifische Einstellungen (z.B. in der Registry) oder Dienste gibt, die sinnvollerweise noch vorzunehmen / zu aktivieren sind, um die Pereformance zu steigern und/oder nicht in irgendwelche Beschränkungen gleichzeitiger Zugriffe (...) zu laufen (im Rahmen der beschriebenen Bedingungen).
Allerdings hat keins dieser Systeme bisher die "Rolle" eines Dateiservers in diesem Sinne.
Grundsätzlich funktioniert SMB ja auch ohne irgendwelche großartigen Einstellungen, indem man ein Verzeichnis freigibt. Aber die Frage ist, ob es da spezifische Einstellungen (z.B. in der Registry) oder Dienste gibt, die sinnvollerweise noch vorzunehmen / zu aktivieren sind, um die Pereformance zu steigern und/oder nicht in irgendwelche Beschränkungen gleichzeitiger Zugriffe (...) zu laufen (im Rahmen der beschriebenen Bedingungen).
Windows Search sollte man installieren. Das ist auf dem Server im Standard nicht vorhanden.
Bei einem neu aufzusetzenden System würde ich auch immer über DFS nachdenken. Das macht die Sache flexibler und leichter zu skalieren (mal von der Redundanz abgesehen).
hth
Erik
@Mondragor
Also wenn du eh per iSCSI an vorhandene Systeme anbinden möchtest, die im AD Verwaltet sind, benötigst du dazu nicht zwingend ein Windows Server. Die Lizenz ist einsparbar, wenn du an der Stelle was anderes nimmst, was iSCSI-Target kann. Den iSCSI-Initiator hast du ja bereits.
Was die Netzwerkanbindung und -Hardware angeht würde ich bei sowas KEINE Vortualisierung empfehlen, sondern auf einem separaten Blech nativ installieren, um ungestörte Netzwerkperformance zu garantieren (auch für Backup). Du kannst zusätzlich dafür sofern passende Switch da sind auch mehrere Ethernet-Leitungen bündeln, was bei 20-30 Usern durchaus sinnvoll ist. (https://de.wikipedia.org/wiki/Link_Aggregation).
Ein per iSCSI eingebundenen Speicher erscheint ja auf dem Windows Server wie ein zusätzliches Laufwerk mit Buchstabe (z.B. X
. Das Laufwerk muss dann noch NTFS-Formatiert werden und kann dann wie ein Internes Laufwerk benutzt werden.
Die Freigaben legst du an wie sonst auch -> START - Verwaltung - Freigabe- und Speicherverwaltung. Das kennst du ja. Alternativ über Server-Manager.
Die Rechtezuteilung machst du über eingerichtete Gruppen aus dem AD. Einzelte Userrechte sollte man nicht machen, das führt dich in den Wahnsinn.
In der Registrie musst du nichts machen.
Bei aktuellen Windows-Servern ist SMB2 und SMB3 automatisch kombiniert aktiviert. SMB1 kann man nachtaktiveren, wenn man es braucht.
Kreuzberger
Also wenn du eh per iSCSI an vorhandene Systeme anbinden möchtest, die im AD Verwaltet sind, benötigst du dazu nicht zwingend ein Windows Server. Die Lizenz ist einsparbar, wenn du an der Stelle was anderes nimmst, was iSCSI-Target kann. Den iSCSI-Initiator hast du ja bereits.
Was die Netzwerkanbindung und -Hardware angeht würde ich bei sowas KEINE Vortualisierung empfehlen, sondern auf einem separaten Blech nativ installieren, um ungestörte Netzwerkperformance zu garantieren (auch für Backup). Du kannst zusätzlich dafür sofern passende Switch da sind auch mehrere Ethernet-Leitungen bündeln, was bei 20-30 Usern durchaus sinnvoll ist. (https://de.wikipedia.org/wiki/Link_Aggregation).
Ein per iSCSI eingebundenen Speicher erscheint ja auf dem Windows Server wie ein zusätzliches Laufwerk mit Buchstabe (z.B. X
. Das Laufwerk muss dann noch NTFS-Formatiert werden und kann dann wie ein Internes Laufwerk benutzt werden.Die Freigaben legst du an wie sonst auch -> START - Verwaltung - Freigabe- und Speicherverwaltung. Das kennst du ja. Alternativ über Server-Manager.
Die Rechtezuteilung machst du über eingerichtete Gruppen aus dem AD. Einzelte Userrechte sollte man nicht machen, das führt dich in den Wahnsinn.
In der Registrie musst du nichts machen.
Bei aktuellen Windows-Servern ist SMB2 und SMB3 automatisch kombiniert aktiviert. SMB1 kann man nachtaktiveren, wenn man es braucht.
Kreuzberger
Wenn es dir rein nur um einen Fileserver geht wäre dann nicht ein entsprechend potentes NAS der deutlich bessere, da performantere Ansatz?
AFP ist übrigens bei Apple schon seit Jahren tot. MacOS nutzt aktiv nur noch SMB, zumindestens in den MacOS Versionen der letzten Jahre.
AFP ist übrigens bei Apple schon seit Jahren tot. MacOS nutzt aktiv nur noch SMB, zumindestens in den MacOS Versionen der letzten Jahre.
Ist ja vielleicht außer Mode gekommen, aber wenn ich ein Projekt angehe, nehme ich erst einmal ein gutes Buch aus dem Schrankl: https://www.rheinwerk-verlag.de/windows-server-das-umfassende-handbuch/
Auch wenn das natürlich nicht alles en Detail abdeckt, ordnet es die Gedanken und bildet die Basis für weitere Fragen bzw. detailliertere Werke.
Wenn es nur um einen Fileserver geht, der per SMB angebunden ist, genügt, wie oben schon erwähnt, ein NAS oder besser ein Samba Fileserver. Der kann heutzutage auch mit den erweiterten Rechten von Windows umgehen und lässt sich über RSAT von Windows aus steuern. Auch dazu gibt's ein vorzügliches Buch: https://www.kania-online.de/fachbuecher/samba-4/
Wenn aber eh Windows-Lizenzen da sind, kann man das auch mit Windows umsetzen
Viele Grüße, commodity
Auch wenn das natürlich nicht alles en Detail abdeckt, ordnet es die Gedanken und bildet die Basis für weitere Fragen bzw. detailliertere Werke.
Wenn es nur um einen Fileserver geht, der per SMB angebunden ist, genügt, wie oben schon erwähnt, ein NAS oder besser ein Samba Fileserver. Der kann heutzutage auch mit den erweiterten Rechten von Windows umgehen und lässt sich über RSAT von Windows aus steuern. Auch dazu gibt's ein vorzügliches Buch: https://www.kania-online.de/fachbuecher/samba-4/
Wenn aber eh Windows-Lizenzen da sind, kann man das auch mit Windows umsetzen
Viele Grüße, commodity
Warum versucht ihr ihm ein nicht-Windows System zu verkaufen?
Analysiert nochmal diese zwei Zitate:
Nachdem Datacenter Lizenzen bereits vorhanden sind spricht nichts gegen einen Windows Server mal eben hoch zu ziehen, bis auf das, dass der Support von Server 2016 nicht mehr wirklich lange läuft. Dank AD wird es ein Kinderspiel einzurichten. Server in die Domain, Freigaben erzeugen, los gehts.
Als Backup kann ich Veeam empfehlen, dessen Community Edition bis zu 10 VMs pro Blech kostenlos ist. Das reicht für Dateibackups vollkommen aus, indem die ganze VM gebackupt wird und einzelne Dateien und Ordner granular restauriert werden können, oder auch die ganze VM. Möchtest du mehr Komfortfunktionen im Restore ganzer VMs haben, hat aber auch die kostenpflichtige Version ihre Charme, gerade, wenn du mehrere Bleche zu verwalten hast oder Cluster.
Replikation würde ich über DFS-R machen. Es ist bei Windows Server schon dabei, dafür benötigt es dann keine weitere Software.
iSCSI würde ich nur mit einer direkten Verbindung ohne Switch machen, oder mit einem Switch "nur" für iSCSI, der möglichst nie wegen Updates neu gebootet wird. Sonst gibt es gleich ein korruptes Dateisystem. Das weiss der TO aber mit Sicherheit, wenn er iSCSI bereits im Einsatz hat.
Ich kenne jetzt leider keine Tweaks, die man grundsätzlich an so einem System machen sollte, damit sie Vollgas geben. Mir persönlich kam es jedoch nicht auf die letzten 10% Performanceunterschied an, sodaß ich nie danach recherchiert habe.
Wenn du dir unsicher bist: Du muss ja nicht gleich alles umziehen, es reicht ja erst einmal nur die Freigabe für die ESKO Software zu bauen, bis alles läuft und den Rest kannst zu dann zeitnah hinterher ziehen. Auf jeden Fall solltest du hinterher ziehen, da SMB1 die Türen schon sehr weit offen hat. Da kann man quasi alle Session Logins ohne Hindernis mitlesen.
Analysiert nochmal diese zwei Zitate:
Der Hersteller unserer Software (ESKO) unterstützt offiziell nur Windows Dateiserver
um den vollen Support bei ESKO zu haben und nicht vor einer Wand zu stehen
Nachdem Datacenter Lizenzen bereits vorhanden sind spricht nichts gegen einen Windows Server mal eben hoch zu ziehen, bis auf das, dass der Support von Server 2016 nicht mehr wirklich lange läuft. Dank AD wird es ein Kinderspiel einzurichten. Server in die Domain, Freigaben erzeugen, los gehts.
Als Backup kann ich Veeam empfehlen, dessen Community Edition bis zu 10 VMs pro Blech kostenlos ist. Das reicht für Dateibackups vollkommen aus, indem die ganze VM gebackupt wird und einzelne Dateien und Ordner granular restauriert werden können, oder auch die ganze VM. Möchtest du mehr Komfortfunktionen im Restore ganzer VMs haben, hat aber auch die kostenpflichtige Version ihre Charme, gerade, wenn du mehrere Bleche zu verwalten hast oder Cluster.
Replikation würde ich über DFS-R machen. Es ist bei Windows Server schon dabei, dafür benötigt es dann keine weitere Software.
iSCSI würde ich nur mit einer direkten Verbindung ohne Switch machen, oder mit einem Switch "nur" für iSCSI, der möglichst nie wegen Updates neu gebootet wird. Sonst gibt es gleich ein korruptes Dateisystem. Das weiss der TO aber mit Sicherheit, wenn er iSCSI bereits im Einsatz hat.
Ich kenne jetzt leider keine Tweaks, die man grundsätzlich an so einem System machen sollte, damit sie Vollgas geben. Mir persönlich kam es jedoch nicht auf die letzten 10% Performanceunterschied an, sodaß ich nie danach recherchiert habe.
Wenn du dir unsicher bist: Du muss ja nicht gleich alles umziehen, es reicht ja erst einmal nur die Freigabe für die ESKO Software zu bauen, bis alles läuft und den Rest kannst zu dann zeitnah hinterher ziehen. Auf jeden Fall solltest du hinterher ziehen, da SMB1 die Türen schon sehr weit offen hat. Da kann man quasi alle Session Logins ohne Hindernis mitlesen.
Deshalb ist es Best Practice mindestens zwei Switches für iSCSI zu haben.
Deshalb ist es Best Practice mindestens zwei Switches für iSCSI zu haben.
Full ack... Aber selbst diese sind nicht in der Zentralen Verwaltung unseres Hausnetzes, damit nichts passieren kann
Ja, müssen ja auch nur Forwarden und die große weite Welt nicht kennenlernen.
@ erikro
Windows Search ist ein guter Punkt, danke. Dazu aber eine Verständnisfrage: Braucht man das nicht vor Allem auf Windows-Clients? Denn die meisten werden mit einem Mac verbunden sein. Warum ist das auf dem Fileserver hilfreich? Oder schleift der Server das quasi an die Clients egal welcher Natur durch??
@ NordicMike
Da das EOS für 2016 für den 12. Januar 2027 angekündigt ist, würde ich gerne noch warten, bis Server 2025 erscheint und dann das komplette Datacenter damit ausstatten wollen. ESKO rät nämlich auch dazu, dass der Fileserver und die Automation Engine auf der gleichen Windows Server - Version läuft.
Das war der Plan: Erst mal Phantasiedaten und Testjobs, um alle mal richtig Dampf aber am realen Anwendungsfall orientiert machen zu lassen. Als nächsten Step dann kundenweise umziehen, Neukunde zuerst, da hier der Umfang an vorhandenen Daten relativ klein, das Neuauftragsvolumen aber relativ groß ist.
Zu SMB1 hat mir der Helios-Support sowie unser diesbezüglicher Support-Partner bezüglich SMB1 damals zugesichert, dass diese Lücke nur auf Windows-Dateiservern existiert und Helios das anders implementiert hat, weswegen da diesbezüglich nichts zu befürchten sei.
Vielen Dank @NordicMike
@ kreuzberger
Sollte sich in der Testphase herausstellen, dass das Netzwerk den Flaschenhals bildet, wird darüber nachgedacht werden.
@ aqui
Meinen Infos nach wird das Protokoll nicht mehr weiter entwickelt seit 07/2012. Aber das Einbinden von afp:// auf neuen OS-Vresionen funktioniert offensichtlich noch, zumindest meldet unser HELIOS, dass auf dieser Basis (afpsrv) die entsprechenden Macs verbunden sind. Da sind einige mit neuestem OS dabei.
@ 400GBit
Zum Einsatz kommt ein ARUBA 5412R zl2
Alle Module doppelt und je mit einem Controller / Netzwerkkarte der Geräte verbunden, LAG aktiv.
Netzteil und Management sind ebenfalls jeweils doppelt vorhanden. Mehr Redundanz geht maximal über Switch-Stacking sauber, wobei ich auch schon erlebt habe, dass sich davon spontan eins verabschiedet hat und dann die anderen mit vertauschten Rollen wieder aufgestartet sind, ohne dass das von außen oder über das management ersichtlich wurde. Meine Erfahrungen mit den Aruba-Teilen sind da deutlich besser. Im zweiten Brandabschnitt kommt der 5406R zl2 zum Einsatz. Querverbindung ist 20 GBit Glas auf 150 m. Dort wird dann das Backup hängen.
@ alle anderen:
ESKO fordert explizit Windows Dateiserver! Natürlich kann das andere auch funktionieren, also etwa SynologyNAS oder SAMBA Fileserver. Aber wenn man mit ESKO ein Problem hat (und darauf kann man sich nach so ziemlich jedem Update verlassen) dann versuchen die natürlich, erst einmal die Anforderungen zu checken und jedes Mal heißt es "das wird nicht unterstützt". Aus diesem Sumpf will ich raus, auch weil der neue Support jetzt auf einen anderen Kontinent ausgelagert wurde und man dadurch schon genug Zeit verliert.
Storage ist vorhanden, kompatibele SSDs sind unterwegs und einen Windows Server im Datacenter zu installieren,
dauert knapp 1 Stunde. Das ist soweit gesetzt Da ISCSI meines Erachtens so ganz gut funktioniert und unser Veeam-Server auch damit arbeitet, wird das wohl auch gesetzt sein.
Über weitere Anmerkungen und Tipps wäre ich dankbar, im Rahmen dessen, was gesetzt ist. Also Stellschrauben, Stabilisierung, sowas.
Windows Search ist ein guter Punkt, danke. Dazu aber eine Verständnisfrage: Braucht man das nicht vor Allem auf Windows-Clients? Denn die meisten werden mit einem Mac verbunden sein. Warum ist das auf dem Fileserver hilfreich? Oder schleift der Server das quasi an die Clients egal welcher Natur durch??
@ NordicMike
Nachdem Datacenter Lizenzen bereits vorhanden sind spricht nichts gegen einen Windows Server mal eben hoch zu ziehen, bis auf das, dass der Support von Server 2016 nicht mehr wirklich lange läuft.
Damit hast Du Recht, allerdings wird Server 2012 mit der Begründung aus der Unterstützung genommen, dass es ab 10/2023 keine Updates mehr gibt.Da das EOS für 2016 für den 12. Januar 2027 angekündigt ist, würde ich gerne noch warten, bis Server 2025 erscheint und dann das komplette Datacenter damit ausstatten wollen. ESKO rät nämlich auch dazu, dass der Fileserver und die Automation Engine auf der gleichen Windows Server - Version läuft.
Als Backup kann ich Veeam empfehlen...
Das ist, lizenziert in Form von B&R sowieso im Einsatz. Werde mir dann über die dahinter liegende Infrastruktur Gedanken machen müssen, da die Zielgröße doch nicht ganz ohne ist.Wenn du dir unsicher bist: Du muss ja nicht gleich alles umziehen, es reicht ja erst einmal nur die Freigabe für die ESKO Software zu bauen, bis alles läuft und den Rest kannst zu dann zeitnah hinterher ziehen. Auf jeden Fall solltest du hinterher ziehen, da SMB1 die Türen schon sehr weit offen hat. Da kann man quasi alle Session Logins ohne Hindernis mitlesen.
Das war der Plan: Erst mal Phantasiedaten und Testjobs, um alle mal richtig Dampf aber am realen Anwendungsfall orientiert machen zu lassen. Als nächsten Step dann kundenweise umziehen, Neukunde zuerst, da hier der Umfang an vorhandenen Daten relativ klein, das Neuauftragsvolumen aber relativ groß ist.
Zu SMB1 hat mir der Helios-Support sowie unser diesbezüglicher Support-Partner bezüglich SMB1 damals zugesichert, dass diese Lücke nur auf Windows-Dateiservern existiert und Helios das anders implementiert hat, weswegen da diesbezüglich nichts zu befürchten sei.
Vielen Dank @NordicMike
@ kreuzberger
Was die Netzwerkanbindung und -Hardware angeht würde ich bei sowas KEINE Vortualisierung empfehlen, sondern auf einem separaten Blech nativ installieren, um ungestörte Netzwerkperformance zu garantieren (auch für Backup).
Sollte sich in der Testphase herausstellen, dass das Netzwerk den Flaschenhals bildet, wird darüber nachgedacht werden.
@ aqui
AFP ist übrigens bei Apple schon seit Jahren tot. MacOS nutzt aktiv nur noch SMB, zumindestens in den MacOS Versionen der letzten Jahre.
Meinen Infos nach wird das Protokoll nicht mehr weiter entwickelt seit 07/2012. Aber das Einbinden von afp:// auf neuen OS-Vresionen funktioniert offensichtlich noch, zumindest meldet unser HELIOS, dass auf dieser Basis (afpsrv) die entsprechenden Macs verbunden sind. Da sind einige mit neuestem OS dabei.
@ 400GBit
Deshalb ist es Best Practice mindestens zwei Switches für iSCSI zu haben.
Zum Einsatz kommt ein ARUBA 5412R zl2
Alle Module doppelt und je mit einem Controller / Netzwerkkarte der Geräte verbunden, LAG aktiv.
Netzteil und Management sind ebenfalls jeweils doppelt vorhanden. Mehr Redundanz geht maximal über Switch-Stacking sauber, wobei ich auch schon erlebt habe, dass sich davon spontan eins verabschiedet hat und dann die anderen mit vertauschten Rollen wieder aufgestartet sind, ohne dass das von außen oder über das management ersichtlich wurde. Meine Erfahrungen mit den Aruba-Teilen sind da deutlich besser. Im zweiten Brandabschnitt kommt der 5406R zl2 zum Einsatz. Querverbindung ist 20 GBit Glas auf 150 m. Dort wird dann das Backup hängen.
@ alle anderen:
ESKO fordert explizit Windows Dateiserver! Natürlich kann das andere auch funktionieren, also etwa SynologyNAS oder SAMBA Fileserver. Aber wenn man mit ESKO ein Problem hat (und darauf kann man sich nach so ziemlich jedem Update verlassen) dann versuchen die natürlich, erst einmal die Anforderungen zu checken und jedes Mal heißt es "das wird nicht unterstützt". Aus diesem Sumpf will ich raus, auch weil der neue Support jetzt auf einen anderen Kontinent ausgelagert wurde und man dadurch schon genug Zeit verliert.
Storage ist vorhanden, kompatibele SSDs sind unterwegs und einen Windows Server im Datacenter zu installieren,
dauert knapp 1 Stunde. Das ist soweit gesetzt Da ISCSI meines Erachtens so ganz gut funktioniert und unser Veeam-Server auch damit arbeitet, wird das wohl auch gesetzt sein.
Über weitere Anmerkungen und Tipps wäre ich dankbar, im Rahmen dessen, was gesetzt ist. Also Stellschrauben, Stabilisierung, sowas.
Das kann man so machen. Du scheinst ja das Thema zu verstehen. Updates gehen dann nur in bestimmten Momenten und eine Fehlkonfig sollte auch nicht vorkommen.
@Mondragor
nun, deine Zusammenfassung klingt erstmal nett. An ein Paar stellen würde ich es anders sehen/machen. Aber viele Wege führen nach Rom.
Was die Netzwerkanbindung angeht ist in der Tat abzuwarten, ob da ein Flaschenhals entsteht. Sofern aber das Blech es hergibt (viele Profi-Server haben ja mehrere Netzwerkkarten) würde ich das auch nutzen. Ich hab immer wieder erlebt, dass tolle Server vier Netzwerkports hatten/haben, aber nur einer angeschlossen war. Da verschenkt man was.
Wenn du den Fileserver als Windows im Hypes-V des Datacenters betreiben willst wäre eine Überlegung, das ressourensparend als Core-Server zu installieren. Das spart den massiven Ballast der Grafischen Oberfläche ein. Bringt wirklich was!
AFP wird zwar historisch in aktuellen Mac OS X Systemen noch immer mitgegeben, wird aber in der tat nicht weiterentwickelt. Man sollte wenn möglich darauf verzichten.
SMB1 ist löchrig, wenn irgend geht sollte man verzichten. SMB1 ist bei allen Systemen löchrig.
Wenn du iSCSI für Storage nutzen willst ist das Target-Betriebssystem egal. Auch wenn ESKO auf Windows besteht, „sieht“ ESKO nur den iSCSI Initiator. Und wenn der Windows ist, kann man als Target irgendwas nehmen, also auch z. B. ein SYNOLOGY. Wenn man SMB benutzt: Auf dem SYNOLOGY läuft ein Samba.
Solltest du aber den Fileserver als VM im Hyper-V des Dataceter betrieben wollen macht iSCSI kaum sinn. Dann ist ja die Netzwerkanbindung über den Virtuellen Switch.
Windows Search und Indizierung auf dem Windows Fileserver zu nutzen macht sinn. Es ist aber keine Client-Seinige Sache. Es wird an alle, die SMB nutzen zur Verfügung gestellt und beschleunigt das Auffinden von Daten auf den Windows-Server-Volumes, die mit Indiziert werden. Windows Search muss extra als Feature installiert werden.
Kreuzberger
nun, deine Zusammenfassung klingt erstmal nett. An ein Paar stellen würde ich es anders sehen/machen. Aber viele Wege führen nach Rom.
Was die Netzwerkanbindung angeht ist in der Tat abzuwarten, ob da ein Flaschenhals entsteht. Sofern aber das Blech es hergibt (viele Profi-Server haben ja mehrere Netzwerkkarten) würde ich das auch nutzen. Ich hab immer wieder erlebt, dass tolle Server vier Netzwerkports hatten/haben, aber nur einer angeschlossen war. Da verschenkt man was.
Wenn du den Fileserver als Windows im Hypes-V des Datacenters betreiben willst wäre eine Überlegung, das ressourensparend als Core-Server zu installieren. Das spart den massiven Ballast der Grafischen Oberfläche ein. Bringt wirklich was!
AFP wird zwar historisch in aktuellen Mac OS X Systemen noch immer mitgegeben, wird aber in der tat nicht weiterentwickelt. Man sollte wenn möglich darauf verzichten.
SMB1 ist löchrig, wenn irgend geht sollte man verzichten. SMB1 ist bei allen Systemen löchrig.
Wenn du iSCSI für Storage nutzen willst ist das Target-Betriebssystem egal. Auch wenn ESKO auf Windows besteht, „sieht“ ESKO nur den iSCSI Initiator. Und wenn der Windows ist, kann man als Target irgendwas nehmen, also auch z. B. ein SYNOLOGY. Wenn man SMB benutzt: Auf dem SYNOLOGY läuft ein Samba.
Solltest du aber den Fileserver als VM im Hyper-V des Dataceter betrieben wollen macht iSCSI kaum sinn. Dann ist ja die Netzwerkanbindung über den Virtuellen Switch.
Windows Search und Indizierung auf dem Windows Fileserver zu nutzen macht sinn. Es ist aber keine Client-Seinige Sache. Es wird an alle, die SMB nutzen zur Verfügung gestellt und beschleunigt das Auffinden von Daten auf den Windows-Server-Volumes, die mit Indiziert werden. Windows Search muss extra als Feature installiert werden.
Kreuzberger
Zitat von @kreuzberger:
@Mondragor
Wenn du iSCSI für Storage nutzen willst ist das Target-Betriebssystem egal. Auch wenn ESKO auf Windows besteht, „sieht“ ESKO nur den iSCSI Initiator. Und wenn der Windows ist, kann man als Target irgendwas nehmen, also auch z. B. ein SYNOLOGY. Wenn man SMB benutzt: Auf dem SYNOLOGY läuft ein Samba.
Solltest du aber den Fileserver als VM im Hyper-V des Dataceter betrieben wollen macht iSCSI kaum sinn. Dann ist ja die Netzwerkanbindung über den Virtuellen Switch.
Windows Search und Indizierung auf dem Windows Fileserver zu nutzen macht sinn. Es ist aber keine Client-Seinige Sache. Es wird an alle, die SMB nutzen zur Verfügung gestellt und beschleunigt das Auffinden von Daten auf den Windows-Server-Volumes, die mit Indiziert werden. Windows Search muss extra als Feature installiert werden.
Kreuzberger
@Mondragor
Wenn du iSCSI für Storage nutzen willst ist das Target-Betriebssystem egal. Auch wenn ESKO auf Windows besteht, „sieht“ ESKO nur den iSCSI Initiator. Und wenn der Windows ist, kann man als Target irgendwas nehmen, also auch z. B. ein SYNOLOGY. Wenn man SMB benutzt: Auf dem SYNOLOGY läuft ein Samba.
Solltest du aber den Fileserver als VM im Hyper-V des Dataceter betrieben wollen macht iSCSI kaum sinn. Dann ist ja die Netzwerkanbindung über den Virtuellen Switch.
Windows Search und Indizierung auf dem Windows Fileserver zu nutzen macht sinn. Es ist aber keine Client-Seinige Sache. Es wird an alle, die SMB nutzen zur Verfügung gestellt und beschleunigt das Auffinden von Daten auf den Windows-Server-Volumes, die mit Indiziert werden. Windows Search muss extra als Feature installiert werden.
Kreuzberger
Ich glaube wir missverstehen uns. Die Einbindung des Volumes am Windows Server, der den Fileserver bilden soll, ist per ISCSI initiator. Die Freigabe erfolgt dann ganz einfach über SMB. So ist der Plan.
@ commodity
Ich habe das Windows Server Buch gekauft, weil in einigen Jahren ja spätestens mit der Version 2025 wieder eine Migration des gesamten Datacenters ansteht und ich somit schon mal ein wenig tiefer in die neueren Technologien und überhaupt den Windows Server einblicken kann. Ich denke aber bis 2025 wird es eine neue Auflage für die entsprechende Version geben.
Jedenfalls gibt es in dem Buch in der Tat einige Anmerkungen und Kapitel... zum Bereich Dateiserver. Danke für den Link. Bin schon eifrig im Ebook vertieft. - Ist schon schön, wenn man das direkt bereitgestellt kriegt.
Danke für das Feedback. Ich finde das Buch auch recht ordentlich.
Ich würde Linux immer vorziehen, verstehe aber das Support-Thema.
Ansonsten bist Du ja sehr gut im Thema - und sehr vorausschauend obendrein. Beim Thema Storage und Performance ist IMO die Hardwarebasis entscheidend - und ist in der beschriebenen Struktur ja ausgezeichnet. Vielleicht verwöhnst Du uns bei Gelegenheit noch mit ein paar IOPS-Messungen. Geht wohl auch unter Windows mit fio.
Viele Grüße, commodity
Ich würde Linux immer vorziehen, verstehe aber das Support-Thema.
Ansonsten bist Du ja sehr gut im Thema - und sehr vorausschauend obendrein. Beim Thema Storage und Performance ist IMO die Hardwarebasis entscheidend - und ist in der beschriebenen Struktur ja ausgezeichnet. Vielleicht verwöhnst Du uns bei Gelegenheit noch mit ein paar IOPS-Messungen. Geht wohl auch unter Windows mit fio.
Viele Grüße, commodity
Zitat von @commodity:
Danke für das Feedback. Ich finde das Buch auch recht ordentlich.
Ich würde Linux immer vorziehen, verstehe aber das Support-Thema.
Ansonsten bist Du ja sehr gut im Thema - und sehr vorausschauend obendrein. Beim Thema Storage und Performance ist IMO die Hardwarebasis entscheidend - und ist in der beschriebenen Struktur ja ausgezeichnet. Vielleicht verwöhnst Du uns bei Gelegenheit noch mit ein paar IOPS-Messungen. Geht wohl auch unter Windows mit fio.
Viele Grüße, commodity
Danke für das Feedback. Ich finde das Buch auch recht ordentlich.
Ich würde Linux immer vorziehen, verstehe aber das Support-Thema.
Ansonsten bist Du ja sehr gut im Thema - und sehr vorausschauend obendrein. Beim Thema Storage und Performance ist IMO die Hardwarebasis entscheidend - und ist in der beschriebenen Struktur ja ausgezeichnet. Vielleicht verwöhnst Du uns bei Gelegenheit noch mit ein paar IOPS-Messungen. Geht wohl auch unter Windows mit fio.
Viele Grüße, commodity
Wenn die SSDs da sind, das RAID aufgebaut und die LUN angelegt ist und wenn die VM steht und das Volume eingebunden ist, kann ich das Server-seitig mal versuchen. Die QSAN ist ja recht kräftig, was das Gehäuse angeht und da das System (Enclosure) sonst nur die VMWARE Replicas fasst, die nur nachts Traffic verursachen, sollte diese Enclosure (wir haben 3) dann mittels JBOD um 26 Schächte erweitert und da kommt dann das neue RAID rein.
Tagsüber arbeitet die Replication nicht aktiv, nachts arbeitet der Fileserver nicht aktiv. Bin auch gespannt.
Ich hatte das oben so verstanden, dass das schon gebaut und RAID6 gesetzt ist. Wenn das noch nicht gebaut ist:
Ihr braucht wahrscheinlich das RAID6 wegen des Datenvolumens, aber da Du oben die Performance ansprichst, meine ich aus meiner Storage-"Lehrzeit" (autodidakt) zu erinnern, dass RAID10 besser performt als RAID6. Dies ist aber nicht für alle Fälle unumstritten:
https://www.partitionwizard.com/clone-disk/raid-6-vs-raid-10.html
https://www.reddit.com/r/homelab/comments/72dhrt/why_do_people_choose_ra ...
Viele Grüße, commodity
Ihr braucht wahrscheinlich das RAID6 wegen des Datenvolumens, aber da Du oben die Performance ansprichst, meine ich aus meiner Storage-"Lehrzeit" (autodidakt) zu erinnern, dass RAID10 besser performt als RAID6. Dies ist aber nicht für alle Fälle unumstritten:
https://www.partitionwizard.com/clone-disk/raid-6-vs-raid-10.html
https://www.reddit.com/r/homelab/comments/72dhrt/why_do_people_choose_ra ...
Viele Grüße, commodity
Moin,
Windows-Search legt die Indizes dort an, wo die Dateien liegen. Deshalb braucht der Fileserver die Funktion, wenn man die Vorteile der Indizierung nutzen will - und das will man.
Liebe Grüße
Erik
Zitat von @Mondragor:
@ erikro
Windows Search ist ein guter Punkt, danke. Dazu aber eine Verständnisfrage: Braucht man das nicht vor Allem auf Windows-Clients? Denn die meisten werden mit einem Mac verbunden sein. Warum ist das auf dem Fileserver hilfreich? Oder schleift der Server das quasi an die Clients egal welcher Natur durch??
@ erikro
Windows Search ist ein guter Punkt, danke. Dazu aber eine Verständnisfrage: Braucht man das nicht vor Allem auf Windows-Clients? Denn die meisten werden mit einem Mac verbunden sein. Warum ist das auf dem Fileserver hilfreich? Oder schleift der Server das quasi an die Clients egal welcher Natur durch??
Windows-Search legt die Indizes dort an, wo die Dateien liegen. Deshalb braucht der Fileserver die Funktion, wenn man die Vorteile der Indizierung nutzen will - und das will man.
Liebe Grüße
Erik
Zitat von @commodity:
Ich hatte das oben so verstanden, dass das schon gebaut und RAID6 gesetzt ist. Wenn das noch nicht gebaut ist:
Ihr braucht wahrscheinlich das RAID6 wegen des Datenvolumens, aber da Du oben die Performance ansprichst, meine ich aus meiner Storage-"Lehrzeit" (autodidakt) zu erinnern, dass RAID10 besser performt als RAID6. Dies ist aber nicht für alle Fälle unumstritten:
https://www.partitionwizard.com/clone-disk/raid-6-vs-raid-10.html
https://www.reddit.com/r/homelab/comments/72dhrt/why_do_people_choose_ra ...
Viele Grüße, commodity
Ich hatte das oben so verstanden, dass das schon gebaut und RAID6 gesetzt ist. Wenn das noch nicht gebaut ist:
Ihr braucht wahrscheinlich das RAID6 wegen des Datenvolumens, aber da Du oben die Performance ansprichst, meine ich aus meiner Storage-"Lehrzeit" (autodidakt) zu erinnern, dass RAID10 besser performt als RAID6. Dies ist aber nicht für alle Fälle unumstritten:
https://www.partitionwizard.com/clone-disk/raid-6-vs-raid-10.html
https://www.reddit.com/r/homelab/comments/72dhrt/why_do_people_choose_ra ...
Viele Grüße, commodity
Also geplant ist genau genommen Raid 6 mit 1 Hotspare. Da die Anzahl der Laufwerke, insgesamt 12 nutzbare + 2 Paritys + 1 HotSpare beträgt, ist hier meiner Erfahrung nach das Verhältnis an nutzbaren Volumen und Overhead in Verbindung mit der Datensicherheit optimal.
Sicher kann es bei Raid 10 theoretisch vorkommen, dass mehr als 2 SSDs ausfallen, ohne dass die Daten futsch sind, aber ich müsste ja 24 SSDs kaufen, um den Platz von 12 zu haben und das ist mir zu teuer. Vor Allem - auch wenn die Wahrscheinlichkeit minimal ist, wenn 2 SSDs, die untereinander gespiegelt sind, gleichzeitig oder in kurzer Folge ausfallen sollten, sind die Daten definitiv futsch.
Letzten Endes bleibt es glaube ich eine finanzielle und eine Phylosophie-Frage, zu was man greift.
QSAN bietet noch eine Option namens RaidEE an, das ist aber auch ähnlich zu Raid 10 in Bezug auf die Anzahl des nicht nutzbaren Speichervolumens.
Die SSDs haben laut Herstellerangabe jeweils höhere maximale IOPs als das ganze Storage.
Angefangen wird erst einmal mit 4 SSDs ohne Hotspare, reine Testphase. Da werde ich dann auch schonmal die IOPs messen.
Wenn uns das überzeugt, werden 10 weitere SSDs nachgekauft und Raid 6 +1 HotSpare gebastelt. Nach meinem Verständnis sollte durch mehr nutzbare SSDs die Performance nicht schlechter werden können.
Auf jeden Fall kann ich sagen, dass ich QSAN mit HP MSA vergleichen konnte. Während in QSAN aus über 70 HDDs nur 1 Ausfall statt fand, haben die HP MSAs locker 15 HDDs geschreddert (bei 48 im Einsatz befindlichen HDDs). Und die eine im QSAN war von Anfang an refurbished.
Meiner persönlichen Erfahrung nach aus über 11 Jahren Anwendung ist QSAN so ziemlich das zuverlässigste, was ich mir vorstellen kann. Eines lief 10 Jahre im Raid 6 durch, nie was damit gewesen - und läuft heute noch mit allerdings anderen HDDs. Und mit RAID 6 habe ich gute Erfahrungen.
Oder du kaufst ein SAN-Strorage, dass verschiedene RAID-Modis gleichzeitig über die Laufwerke macht. Das ist dann auch nciht so 1997 mäßig.
Zitat von @8585324113:
Oder du kaufst ein SAN-Strorage, dass verschiedene RAID-Modis gleichzeitig über die Laufwerke macht. Das ist dann auch nciht so 1997 mäßig.
Oder du kaufst ein SAN-Strorage, dass verschiedene RAID-Modis gleichzeitig über die Laufwerke macht. Das ist dann auch nciht so 1997 mäßig.
Mich ist egal wie "1997 mäßig" das ist. Es soll schnell sein, möglichst wenig Platten sollen an Parity oder was auch immer "verloren gehen" und möglichst viel des gekauften SSD-Speichers soll am Ende verfügbar sein, bei möglichst hoher Datensicherheit. Wenn Du wirklich eine Technologie empfehlen willst, die diese Voraussetzungen besser erfüllt, mach doch bitte konkrete Aussagen, vielleicht ein oder zwei Links. Was an Deiner Aussage soll denn jetzt hilfreich für mich sein?
Die SSDs haben je 3.2 TB, am Ende sollen 12*3.2 TB verfügbar sein. Bitte, was ist da optimaler als Raid 6 mit 1 Hotspare, bezogen auf die von mir genannten Punkte??
Da es die Dell SC Storages nicht mehr gibt, würde ich für einfache Aufgaben mir das Unity XT Hybrid angucken. Im Falle der Unity Dynamic Pools. https://www.delltechnologies.com/asset/en-us/products/storage/industry-m ...
So könnte das Aussehen und man hat ALLE Vorzüge ZUSAMMEN:
https://prod-care-community-cdn.sprinklr.com/community/687062f5-603c-4f5 ...
https://prod-care-community-cdn.sprinklr.com/community/687062f5-603c-4f5 ...
Andere OEMs können das auch, weiß aber nicht wie das heißt. Tiering heißt der Spaß.
So könnte das Aussehen und man hat ALLE Vorzüge ZUSAMMEN:
https://prod-care-community-cdn.sprinklr.com/community/687062f5-603c-4f5 ...
https://prod-care-community-cdn.sprinklr.com/community/687062f5-603c-4f5 ...
Andere OEMs können das auch, weiß aber nicht wie das heißt. Tiering heißt der Spaß.
ja, es ist immer eine Abwägung aus Datenmenge/Datensicherheit/Performance. RAID6 gewinnt (nur) bei der Datenmenge. Ich mische daher auch. RAID10 für VMs, Datenbanken uä., RAID6 für "normalen" Storage aka Fileserver. Also sicher die richtige Entscheidung. Tiering ist ja ohnehin angesagt, wenn man verschiedene Datenkategorien auf dem selben System vorhält.
Viele Grüße, commodity
futsch
ist bei beiden Typen eher im theoretischen Bereich (außer, man ist so smart und erhöht das Risiko durch seriengleiche Platten). Aber futsch können die Daten natürlich immer sein. Dafür gibt es dann ein Backup 12*3.2 TB verfügbar
bekommst Du mit 12 Platten à 3,2 TB im RAID6 aber nicht hin. Aber immerhin 10*.Viele Grüße, commodity
12*3.2 TB verfügbar
bekommst Du mit 12 Platten à 3,2 TB im RAID6 aber nicht hin. Aber immerhin 10*.Mit 15 SSDs bekomme ich 12*3,2 im Raid 6 inkl. 1 HotSpare hin...
Tiering ergibt m.e. auch und vor Allem dann Sinn, wenn das Zugriffsverhalten auf bestimmte Bereiche vorhersagbar unterschiedlich ist und / oder wenn man beispielsweise durch unterschiedliche Datenbeschaffenheit nur teilweise auf SSD zugreifen will. Ich denke aber, da die SSDs im Verbund den Fähigkeiten des SAS-Kontrollers deutlich überlegen sind, ist der Flaschenhals hier eher der Controller und weniger das RAID. Man wird sehen, die ersten 4 SSDs für die Testphase sind heute eingetroffen.
Schnittstelle: 24G SAS Dual-Port
Max. sequenzieller Durchsatz: 4200 MB/s (4005 MiB/s) lesend, 3650 MB/s (3481 MiB/s) schreibend
Max. zufällige IOPS (4KB): 720K lesend, 340K schreibend
