[Sammelthread] ZFS Stammtisch

Aber zu der Sache wegen pydio auf nen anderes Verzeichnis legen: können sich die Festplatten dann überhaupt noch schlafen legen oder wuselt da dann immer irgendwas rum ? Also kann ja sein dass das Verzeichnis dann immer Durchsucht wird nach Änderungen. Wäre das daher überhaupt klug ? Da ich das os auf nem 16gb Stick habe wäre mein Cloudspeicher ja ansonsten recht klein

Es handelt sich bei Pydio primär um eine File-Sharing-Software, nicht um eine Sync-Software. Es gibt zwar Sync-Clients als iOS und Android-Apps (auch einen Desktop-Client für Windows), aber hier werden nach meinem Kenntnisstand nur dann Daten auf den Server übertragen wenn es Neuzugänge, Änderungen oder Löschungen gibt. Es werden also keine Sync's in vorher festgelegten Intervallen durchgeführt.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Moin,

ich plane einen Server mit Linux, Debian, Proxmox von 2 SSDs mit ZFS im Mirror starten zu lassen. Auf den SSDs sollen nur das OS und die VMs liegen.

ZFS kann nun leider noch kein Trim (Quellen: hier im Forum, Open ZFS, GitHub ZFSonLinux). Genügt es 20% für Overprovisioning frei zu lassen oder ist es sinnvoller HDDs einzusetzen?

Vielen Dank schonmal!
 
Durch fehlendes Trim geht doch nur ein bisschen Schreibperformance verloren. Dürfte aber so oder so bei ner SSD auch ohne Trim höher sein als bei ner HDD
 
Man benötigt auf SSDs bei ZFS nicht unbedingt den TRIM Befehl, dass daran liegt das ZFS ein Copy-on-write FS ist. Außerdem sollte der Pool sowieso nicht voller als 80% werden, da ansonsten die Defragmentierungsalgorythmus im Pool nicht mehr genügend Freie Zusammenhängende Sektoren findet und der Pool Fragmentiert. Das ist bei SSDs eher zweitrangig, da dort keine Kopfneupositionierung stattfindet.

Also es reicht aus 20% auf der SSD Freizulassen oder auf einem ZFS Volume wo die VMs liegen eine Quota von 80% der SSD Kapazität einzustellen.

Der TRIM Befehl wird hauptsächlich bei Filesystemen benötigt die nur READ-WRITE-MODIFY(RWM) unterstützten also NTFS, extFS, FAT usw. Welches FS du in den VMs letzlich die auf dem ZFS Pool liegen einsetzt ist egal, da ZFS das Verhalten abstrahiert, so wird aus RWM auch COW, das GastOS bekommt davon nichts mit und sieht trotzdem RWM. Nur im unterschied das sich mit ZFS so konsistente Snapshots der VMs anfertigen lassen.
 
Zuletzt bearbeitet:
Man benötigt auf SSDs bei ZFS nicht unbedingt den TRIM Befehl, dass daran liegt das ZFS ein Copy-on-write FS ist

Das hat damit nix zutun.

Außerdem sollte der Pool sowieso nicht voller als 80% werden, da ansonsten die Defragmentierungsalgorythmus im Pool nicht mehr genügend Freie Zusammenhängende Sektoren findet und der Pool Fragmentiert.

ZFS beherscht keine Defragmentierung

Der Trim Befehlt löscht nicht mehr benötigte Blöcke. Diese gibts auch bei ZFS. Ein für das Dateisystem freier Block ist ohne Trim nicht auch automatisch für eine SSD ein freier Block, daher kommt es schon zu Performance Einbußen mit der Zeit. Man ist aber immer noch schneller unterwegs als mit ner HDD.

Denke bei ner SSD fürs OS wird das alledings mit gefühlten minimalen Performanceeinbußen nur einher gehen.

Eine moderner schnelle SATA6G SSD wird auch ohne Trim noch schneller sein als eine zu SATA3G Zeiten mit Trim
 
Zuletzt bearbeitet:
hallo,

wir sind evtl am ueberlegen uns ein Storage aufzubauen was mit ZFS befeuert wird, vorab gibts dazu aber ein paar fragen laufen soll dort VMware evtl auch ein paar SMB-freigaben:
- welches OS? ein BSD derivat oder ein Illumos-derivat? (und wenn ja welches, hab da omniOS oder SMartOS im auge)
- NetApp, Eql etc sind alle ausfallsicher, das heisst es kann ein controller/kopf ausfallen. ist das hier auch moeglich? quasi ein active-active verbund?
- und wie muesste ich ausgehen von 2jbods a 24 platten das konfigurieren das ein JBOD ausfallen kann ich dann aber immer noch ausfallsicherheit innerhalb eines jbods habe..
- ZIL und L2ARC wuerden auf jeweils 2SSDs im RAID1 fungieren. wo sollte ich diese hinbauen? jeweils eine ueber die JBODS?
- und sollte ich das per iSCSI oder per NFS machen?

schonmal danke fuer die hilfe!
 
Alle Welt spricht momentan von "converged infrastructure" und das aus gutem Grund. Kosten und Skalierbarkeit um ein paar davon zu nennen.
Zu deinen Fragen:
- wenn es um Virtualisierung geht, dann ganz klar Smartos. Dann auch keine VMWare sondern KVM.
- active-active nicht out of the box, aber activ-passiv sehr wohl. Stichwort zfs send/recv in genügend kurzem Abstand.
- jeder Node bekommt seine eigenen SSDs und Platten
- weder noch, der Storage wird direkt am Node angeschlossen.


cu
 
Zuletzt bearbeitet:
Hallo und danke für die Antwort.
Aber VMware ist erstmal gesetzt und wenn dann solls ein reines storage sein.
Wie würde des denn mit aktive-aktive gemacht werden? Denn wenn ein Kopf ausfällt soll es ohne probleme und Unterbrechung weitergehen.
Wenn man sich die Lösung von Thomas-Krenn mit Nexanta an guckt muss es dort ja auch irgendwie gehen..
 
Bei mir steht in der Konsole: NAS smbsrv: NOTICE: smbd[NT Authority\Anonymous]: movies access denied: IPC only

Was heißt das?

Und weiß jemand was man da macht mit Serviio und den Umlauten? Offenbar erkennt er Dateien mit Umlauten im Namen nicht
 
Zuletzt bearbeitet:
ZFS beherscht keine Defragmentierung

Tut es doch und zwar mithilfe eines Online-Defragmentierungs-Algorithmus während des Schreibens, schon bestehende Blöcke werden natürlich nicht umgeschrieben wie bei einer herkömmlichen Defragementierung, allerdings werden die Bits so über die Platten verteilt geschrieben das die Seek Zeit klein bleibt, was auch eine Art der Defragmentierung darstellt. Bspw. wandelt ZFS Random Writes in Sequential Writes um. Nützt einem leider nur am meisten bei HDDs.

Kann man natürlich sehen wie man will, ob man das Defragmentierung nennt oder nicht.

Quelle hier:
ZFS - Filesystem einer neuen Generation - Developer Garden TechTalk (01.12.2011) - YouTube

Zu Trim:

Der Trim Befehl löscht die Blöcke nicht, er markiert diese nur als Frei. Bitte einmal lesen: TRIM

Durch den ATA-Befehl TRIM[2] wird dem Laufwerk beim Löschen von Dateien mitgeteilt, dass es die davon betroffenen Blöcke als ungültig markieren kann, anstelle deren Daten weiter vorzuhalten. Die Inhalte werden nicht mehr weiter mitgeschrieben, wodurch die Schreibzugriffe auf das Laufwerk beschleunigt und zudem die Abnutzungseffekte verringert werden. Die ungültig markierten Blöcke werden dann beim nächsten Löschen ihres Erasable Blocks frei.

In Anwendung auf ZFS ergibt sich das: http://youtu.be/2iCLaFaMzJw?t=1h22m23s

Also ergibt sich für ZFS ohne Trim folgendes:

Wenn der Mirror ZPOOL auf SSDs nicht voller als 80% wird, dann wird der Pool immer annähernd die gleiche Performance haben, da ZFS dank des Integrierten Volume Managers die Struktur der Daten auf der SSD kennt und daher auch die freien Bereiche.
 
Zuletzt bearbeitet:
Du machst da einen Denkfehler: Ohne Trim wird die SSD irgendwann "voll" sein. Völlig egal zu wieviel Prozent der Pool belegt ist. Wenn du eine 20GB SSD hast und insgesamt 20GB geschrieben hast (auch wenn du zwischendurch immer was gelöscht hast und der Pool nie über 50% gefüllt war) so ist die SSD nach den 20GB "voll" weil die SSD ja versucht alle Blöcke gleichmäßig zu nutzen. Das Problem ohne Trim ist dass die Zellen dann erst gelöscht werden müssen bevor sie wieder beschrieben werden können und daher wird es dann langsammer. Das hat aber nichts mit dem Füllstand des Pools an sich zu tun.

Zu Trim:

Der Trim Befehl löscht die Blöcke nicht, er markiert diese nur als Frei. Bitte einmal lesen: TRIM
Das ist jetzt Haarspalterei. Ich denke man weiß was ich meinte...

Tut es doch und zwar mithilfe eines Online-Defragmentierungs-Algorithmus während des Schreibens, schon bestehende Blöcke werden natürlich nicht umgeschrieben wie bei einer herkömmlichen Defragementierung, allerdings werden die Bits so über die Platten verteilt geschrieben das die Seek Zeit klein bleibt, was auch eine Art der Defragmentierung darstellt. Bspw. wandelt ZFS Random Writes in Sequential Writes um. Nützt einem leider nur am meisten bei HDDs.

Kann man natürlich sehen wie man will, ob man das Defragmentierung nennt oder nicht.

Es gibt einige Berichte über Leute deren Pool nach einiger Zeit immer langsammer wurde eben weil es keine echte Deframentierung gibt. Es lässt sich nicht vermeiden dass die Dateien irgendwann "ungünstig" liegen. Es mag vllt nicht so extrem sein wie bei anderen Dateisystemen aber auch ein ZFS Pool bekommt man so fragmentiert dass er am Ende lahm ist. Das ist durchaus ein Problem, über die Gewichtung kann man streiten, aber es ist auf jedenfall vorhanden

da ZFS dank des Integrierten Volume Managers die Struktur der Daten auf der SSD kennt und daher auch die freien Bereiche.
Freie Bereiche im Dateisystem sind ohne Trim nicht gleichzeitig auch freie Bereiche in den Flashzellen einer SSD.
Das ist doch grade das Problem: Die SSD/HDD versteht das Dateisystem nicht. Bei der HDD ist das aber egal weil man Blöcke direkt überschreiben kann, bei ner SSD muss man sie aber erst löschen. Egal wievoll dein Pool ist, oder dein NTFS Partition. Wenn du soviele Daten geschrieben hast wie die SSD groß ist sind alle Flashzellen erstmal belegt (ohne Trim)
 
Zuletzt bearbeitet:
Natürlich sind deine Aussagen auf eine gewisse Art und Weise richtig.
Klar ist auch das wenn ich eine SSD (SLC, MLC, TLC) voll schreibe ist sie voll, aber nur sichtbar.

Warum erwähne ich jetzt die Speichertechnologien von SSDs? Weil SSDs nur begrenzte Schreibvorgänge verkraften und der TRIM Befehl reduziert diese. Und die geschätzte Anzahl möglicher Schreibvorgänge auf die unterschiedlichen Speicherzellen. Die Speicherzellen ( SLC, MLC, TLC ) unterscheiden sich dadurch das die Datendichte bei MLC (Doppelt so hoch wie bei SLC) und TLC ( dreifach so hoch wie bei SLC) ist und das führt nunmal leider zu bestimmten Problemen wenn man Daten löschen möchte.

Zellzuordnung:
TypBits/Zelle
SLC1
MLC2
TLC3
Anmerkung: Je mehr Bits pro Zelle gespeichert werden, desto niedriger ist die Lebensdauer derselbigen, da der Aufwand höher ist die geschriebenen Daten zu Modifizieren oder neue Daten zu schreiben.

Möchte ein Betriebssystem eine Datei auf einer SSD löschen, löscht es nicht die Daten durch überschreiben, sondern markiert den Bereich im Dateisystem als Frei. Auf einer HDD funktioniert das natürlich super gut, da überschreiben hier das gleiche wie schreiben ist. Ein SSD Flashpeicher kann die Daten allerdings nicht direkt überschreiben, da sich mehrere verschiedene Datenfragmente in einer Speicherzelle befinden können. Ein Flashspeicher macht hier folgendes. Soll bei einer SSD überschrieben werden, werden als erstes alle Daten in dem zu überschreibenden Block in einen neuen Block geschrieben, der Block der überschrieben werden soll dann gelöscht und zuletzt in den eben gelöschten Block die Daten geschrieben. Natürlich füllen sich so von Zeit zu Zeit die Blöcke der SSD, die Geschwindigkeit bricht irgendwann ein, obwohl das Betriebssystem freien Speicherplatz auf dem Dateisystem anzeigt. Und zwar deshalb weil dieser hier eben beschriebene Prozess dann dauernd abläuft wenn das Laufwerk Daten annehmen und speichern soll, allerdings währenddessen durch die Firmware prüfen muss (ohne Feedback vom Betriebssystem) ob die Blöcke wirklich frei sind. Und so hat eine SSD dann ohne Trim nachher etwa die 4x Schreibzyklen wie mit Trim. Und das ist die einzige Daseinsberechtigung die Trim hat. Nämlich die Anzahl erforderlicher Schreibzyklen zu reduzieren.

Ich verweise hier jetzt auf eine Erklärung von Kingston SSD-Laufwerke | Over-Provisioning leicht verständlich gemacht
 
Zuletzt bearbeitet:
- welches OS? ein BSD derivat oder ein Illumos-derivat? (und wenn ja welches, hab da omniOS oder SMartOS im auge)

Je nach dem wie das Storage VMware zur Verfügung gestellt wird, nicht alle Betriebssysteme unterstützen z.B. iSCSI-Target Mode. Je nach Hardware solltest du auch gucken ob entsprechende Treiber existieren.

- NetApp, Eql etc sind alle ausfallsicher, das heisst es kann ein controller/kopf ausfallen. ist das hier auch moeglich? quasi ein active-active verbund?

Mir ist keine Active/Active Möglichkeit mit einer freien ZFS-Distribution bekannt. Wenn du Active/Active haben möchtest, wirst du wohl um Nexenta, DataCore SANSymphony-V oder einem anderen Enterprise Storage nicht herum kommen.

- und wie muesste ich ausgehen von 2jbods a 24 platten das konfigurieren das ein JBOD ausfallen kann ich dann aber immer noch ausfallsicherheit innerhalb eines jbods habe..

Doppelte Ausfallsicherheit wird dich ordentlich an Platz kosten:

* RAID Volumes auf jedem Shelf erstellen (bei JBODs auf dem Raid-Controller des Hosts, alternativ Plattenshelfs nehmen die selber RAID beherrschen)
* ZFS RAID1 VDEV Pärchen erstellen über jeweils eine LUN von jedem Shelf.

- ZIL und L2ARC wuerden auf jeweils 2SSDs im RAID1 fungieren. wo sollte ich diese hinbauen? jeweils eine ueber die JBODS?
ZIL sollte RAID1 sein, L2ARC kann RAID0 sein. Wenn dein System den Ausfall eines kompletten Shelfs verkraften soll, sollten auch die SSDs auf die Shelfs verteilt werden.

- und sollte ich das per iSCSI oder per NFS machen?

Hat alles Vor- und Nachteile, wenn es dir um Performance geht würde ich sagen iSCSI mit richtigen iSCSI-HBAs (oder gleich FC).
Anbei ein White-Paper von VMware, die haben die verschiedenen Protokolle verglichen: http://www.vmware.com/files/pdf/perf_vsphere_storage_protocols.pdf

Deinen Anforderungen nach zu urteilen (hohe Ausfallsicherheit / Active-Active Cluster / etc.) handelt es sich um sehr business kritische Daten. Hier solltest du dir gut überlegen ob eine selbstgebaute Lösung das richtige ist. Wer hilft dir wenn die Kiste steht oder der Pool aus irgend einem Grund nicht mehr importiert werden kann?
 
Zuletzt bearbeitet:
Hi,

ich habe ein paar Dell Poweredge T20 Server und würde darauf gerne irgendein Solaris-Derivat zum laufen bekommen.

Meine Test haben ergeben, dass irgendetwas mit den oberen SATA-Ports nicht stimmt. Eine Installation mit den 2 unteren Anschlüssen (zfs-mirror) klappt immer fehlerlos, aber sobald eine weitere Platte oben hinzukommt (zfs-raidz1) bekomme ich immer Fehler auf der oberen Platte.

Ich habe es auf drei Rechnern getestet (mit Bios A03 und A04) und mit insgesamt 9 Platten (3x500 GB, 3x1 TB, 3x3 TB, jeweils dasselbe Modell). Platten gemischt, und die obere ist immer fehlerhaft. Mal wird sie nicht erkannt, SMART Fehler oder Fehler beim scrub. Verschiedene Einstellungen im Bios ATA, AHCI habe ich auch getestet.

Ich habe OpenIndiana, OmniOS und SmartOS getestet. SmartOS wäre meine erste Wahl, da es von USB-Stick läuft und ich eigentlich von ESXi (napp-it all-in-one) wegkommen will.

Jetzt weiss ich nicht mehr weiter und vielleicht hat hier jemand einen Tipp. Die "beste" Fehlermeldung kommt bei OpenIndana:

WARNING: /pci@0,0/pci-ide@16,2/ide@0 (ata0)
timeout: reset bus, target=0 lun=0

Bei SmartOS lief das erste Mal die Installation durch und er hat den raidz-zones Pool erzeugt. Beim erneuten Booten hängt es dann wieder. Ich muss den zones-Pool dann immer in einem anderen System löschen, bevor ich erneut testen kann.
 
Teste es mal mit Windows, einfach kurz eine Installation durch laufen lassen um mal irgendwelche Solaris spezifische Probleme auszuschließen. Da es sich aber um einen ganz normalen Intel-Controller handelt ist das sehr unwahrscheinlich. Ich tippe mal eher auf physikalisch defekten Port oder Kabel. AHCI wäre der Modus in dem du den Controller betreiben wollen würdest.
 
Zuletzt bearbeitet:
@phlowx: Noch nicht kontaktiert, Die werden aber agen, dass Solaris nicht supported ist.
@GrafikTreiber: Ja, Win8.1 und Windows Server 2012R2 ohne Probleme, auch nicht mit 3 Platten. Mehere GB hin und herkopiert und MD5-Summen verglichen.
 
Und so hat eine SSD dann ohne Trim nachher etwa die 4x Schreibzyklen wie mit Trim.


Also wenn ich die Zellen nicht jetzt lösche sondern später hab ich 4x soviel Schreibzyklen? ;) Ist klar...

Ich weiß auch nicht ob man hier jetzt in aller Ausführlichkeit eine SSD erklären muss da reicht eine Verlinkung. Es ging doch ursprünglich um SSDs um Zusammenhang mit ZFS. Man sollte daher jetzt nicht schon wieder andere Dinge anschneiden.

Ansonsten wurde alles gesagt: ZFS hat kein Trim unter OmniOS und daher hat man theoretisch und auch praktische etwas weniger Schreibperformance mit der Zeit. Bei ner OS SSD ist das aber eher weniger wichtig wenn sie eine HDD ersetzen soll da immer noch schneller.

Und ob die SSD die Blöcke über den Trim Befehl überschreibt oder erst wenn diese mit neuen Daten gefüllt werden sollen hat für die Lebensdauert keine Bedeutung sondern nur für die Performance.

Ob das Dateisystem ZFS, ext4 oder NTFS oder sonstwas ist hat damit aber nix zu tun.

Beschränke dich bitte bei deiner Diskussion auf das wesentliche. Wieso hier nun SLC, MLC, TLC erklärt wird erschließt sich mir auch nicht im Zusammenhang mit ZFS. Was hat ZFS damit zu tun?

Zurück zum Thema:

Habe mal das MediaTomb, AMP und Serviio Script laufen lassen. Habe nun einen neuen USB Stick (Sandisk Extreme 16GB, kann ihn wirklich empfehlen für das OS auf USB Stick. Er passt auch in den internen USB Slot des Microservers, wenn auch nur so eben. Gea hatte mal den adata s102 pro erwähnt. Habe auch zwischen diesem und dem Sandisk Extreme geschwankt allerdings ist letzterer grade bei 4K DEUTLICH schneller). Klappte alles problemlos. Problem lag vllt mit an meinen alten doch sehr langsammen Stick. Auch das Webinterface ist jetzt durch den neuen Stick richtig flott.

Allerdings habe ich auch das Problem dass Serviio keine Umlaute zu mögen scheint
 
Zuletzt bearbeitet:
Und weiß jemand was man da macht mit Serviio und den Umlauten? Offenbar erkennt er Dateien mit Umlauten im Namen nicht

Das Problem ließ sich bei mir wie folgt lösen:

In der Datei /opt/local/share/serviio/bin/serviio.sh folgende Zeilen einfügen
LANG=de_DE.UTF-8;
export LANG;

anschließend
svcadm disable serviio
svcadm enable serviio

abschließend Medienordner refreshen.
 
Zuletzt bearbeitet:
Jo stimmt wohl ergibt Sinn. Aber naja es gibt ja auch noch andere Sprachen mit weiteren Sonderzeichen.

Mal ne generelle Frage: Wenn ich mir nen Backup von dem USB Stick ziehe mit dem OS drauf und hinterher zurückspiele sind alle Änderungen bei den SMB Freigaben doch nicht weg oder? Die sind dann immer noch so wie ich sie gesetzt habe auch wenn ich nen altes Backup zurückspiele?
 
Zuletzt bearbeitet:
Also wenn ich die Zellen nicht jetzt lösche sondern später hab ich 4x soviel Schreibzyklen? ;) Ist klar...

Natürlich sind es 4 mal so viele, wenn ohne Trim der Block erstmal wieder kopiert wird, bevor in den Block, in den geschrieben werden soll, geschrieben wird. Mit Trim ist es nicht nötig beim schreiben von Blöcken diese Blöcke erst zu duplizieren, bevor in diese geschrieben werden kann, da ja der Controller der SSD darüber informiert ist das der Block frei ist.

Das war halt als einfache Verständniserklärung gemeint und sollte auch keine Belehrung darstellen, ich habe nur zum Thema SSDs schon einige Schulungen bei Herstellern wie Kingston usw. mitgemacht wo das auch so erklärt worden ist.

Aber ich denke es gibt auch wichtigeres als so eine Grundlagendiskussion.
 
So oder so - TRIM-Unterstützung innerhalb illumos wäre toll. Ich denke So mehr leute in der Mailing-liste von zfs-illumos danach fragen, desto mehr widmen sich die Entwickler diesem Thema. :)
Auch wenn TRIM für die OS-SSD vielleicht nicht so wichtig ist, wäre TRIM gerade wichtig wenn man eine SSD als Cache/Log Device benutzt, da hier Performanceverschlechterung der SSD ohne TRIM schon grosse Auswirkungen haben kann. Oder liege ich falsch?
 
Zuletzt bearbeitet:
Für ein einfaches Aufzeichnungssystem, auf der Arbeit habe ich ein Storage System auf Omnios Basis aufgebaut. Da werden Aufzeichnungen wie Live Sendungen, Live Übertragungen vom Satelliten Downlink usw.. darauf Aufgezeichnet, der Workflow läuft hier so das alles was reinkommt erstmal ohne Umweg direkt auf diesem System landet was auch sehr gut funktioniert. Statt auf teuere 15k Platten zu setzen habe ich hier im Wissen das Omnios noch kein Trim unterstützt SSDs dort eingebaut. Insgesamt stehen hier dann 15 TB zur Verfügung. Das ist allerdings schon etwas zu wenig, da hier mit einer Videodatenrate von bis zu 150 Mbit/s gearbeitet wird. Jedes Aufzeichnungssystem ist mit einem 10 Gigabit Port mit einem Extreme Networks Summit X670 verbunden. Das Storagesystem ist mit 4x10Gbit Interfaces angebunden.

Das System skaliert super und man hat keine merklichen Performanceeinbußen beim Schreiben. Allerdings sobald 75 % belegt sind merkt man das die Datenrate um 20 Mbit absinkt. Das konnte ich beheben in dem ich die Filesystem Quota auf 75% gesetzt habe und seitedem bleibt auch die Schreibdatenrate konstant. Es sind zwar nur noch um die 11 TB nutzbar, aber dafür werden so auch die Aufzeichnungen früher aufs Producer Storage kopiert an dem die Schnittarbeitsplätze angebunden sind.

Bestückt ist das System mit Kingston HyperX 3K SSDs allerdings nicht die Enterprise Version, da auf diese SSDs nur geschrieben wird und sollten die kaputt gehen habe ich noch einen ganzen Satz neuer hier rum liegen. Das war letztlich günstiger als die Enterprise SSDs.

Das System läuft jetzt schon seit knapp 1,5 Jahren immernoch mit dem ersten SSD-Satz. Trotzalledem echt eine gute Leistung dafür das das System Täglich mindestens 3x fast vollgeschrieben wird.
 
Zuletzt bearbeitet:
Bestückt ist das System mit Kingston HyperX 3K SSDs allerdings nicht die Enterprise Version, da auf diese SSDs nur geschrieben wird und sollten die kaputt gehen habe ich noch einen ganzen Satz neuer hier rum liegen. Das war letztlich günstiger als die Enterprise SSDs.
Du meinst wohl "nur gelesen"? Lesen nutzt die SSD nicht ab, sondern das Schreiben.

Du weißt aber schon was passiert wenn du so viele SSDs hast und du in Richtung Lebensende kommst? Die fallen alle relativ gleichzeitig aus, sei da also sehr vorsichtig und reagiere sofort und nicht Tage später. Solltest auf jeden Fall die SMART-Werte (Total_LBAs_Written...) monitoren.
 
Zuletzt bearbeitet:
Falls du die 480GB Version hast sollte die laut Hersteller eine TBW von 1785TB. Wenn jede SSD ca. 3x vollgeschrieben wird am Tag dann bist du nach 1,5 Jahren also "erst bei" 788TB.

Wie hast du eigentlich dein pool konfiguriert? Mirror? raidz?
 
Der Pool ist im Mirror konfiguriert, RaidZ1 hatte ich am Anfang da war das Problem allerdings das bei 2 Aufzeichnungsstreams die Datenrate öfters schon eingebrochen ist. Lesen war dort kein Problem.

Um dieser Problem zu umgehen ist der Pool jetzt so konfiguriert, dass immer jeweils 2 der SSDs in einem Mirror sind.

Wie ich oben schon geschrieben habe wird eben auf diesem Pool sehr viel geschrieben. Und da die Abnutzung dadurch auch sehr hoch ist habe ich mich eben für die Desktop SSDs entschieden. Da diese einfach günstiger sind. In dem Pool sind insgesamt 64 der 480GB Variante. Das Shelfs: XJ3000-2242S Specification

Von dieser Version werden für dieses Storage System 3 Stück eingesetzt. Und da noch 8 Rahmen frei waren, habe ich diese ebenfalls mit SSDs bestückt und diese als HotSpare konfiguriert.

Monitoring ist hier mit SNMP gelöst der Sendet die Daten alle an einen Nagios Server. Und mir jeden Tag eine Report E-Mail.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh