Cache SSD fuer ZFS - welche / wie anlegen

Errorsmith

Kompiliertier
Moin

Hier ist mal wieder ein Upgrade fällig.
Aus dem "handgeklöppelten" Storage wird ein "richtiger" Server.

Verbaut wird ein HP DL180 (1 XEON, 24GB RAM) mit (wenn fertig) folgender Plattenkofiguration:

1 x LSI Controller im IT Mode an der Backplane mit 12 Slots.
2 x 149GB SAS für OS als Spiegel
3 x 3 TB SATA RAIDZ für VM / HDD Images & Arbeitsdaten (NFS & iSCSI)
5 x 3 TB SATA RAIDZ2 als Ablage / Archiv (Nur NFS)

Angebunden wird das Teil mit 2x1GBit als lagg0-Trunk.

Max. 3 HDD Slots hab ich noch frei, da soll ein SSD Cache rein. Meine Fragen dazu:
1. Cache nur für das "Arbeitsraid" oder auch fürs Datengrab?
2. Welche Art Cache sollte man für o.g. Anwendungszweck einrichten (ZIL / SLOG / L2ARC?)
3. ... und wie groß?
4. Legt man die SSD im Spiegel an oder reicht eine einzelne (pro Array)?

Grüße,
errorsmith
 
Hallo Errorsmith,

wenn du es entbehren kannst würde ich für die VMs eher auf 2 x 2x3 TB Mirror gehen - da sollte die Leistung um einiges höher sein als beim RaidZ.

Ob du wirklich einen SSD-Cache brauchst ist dann die andere Frage. Das kommt erstens auf das genaue Schreibverhalten und 2. auf die Auslastung deines Arbeitsspeichers an.
Ich würde zunächst alles Geld in RAM stecken - dann brauchst du höchst wahrscheinlich keinen SSD-Cache.

Wenn du trotzdem willst würde ich das ZIL spiegeln und L2ARC kannst du einzeln lassen.

Gruß
Markus

PS: Hände weg von Deduplikation - das zerreist dir sämtliche Performance (mit obigen Angaben)
 
Hi
Danke für eure Anregungen.
Vorweg: Dedup habe ich nicht vor, das macht bei meinem Anwendungsfall auch nicht wirklich Sinn.
NFS und VM sind zwei paar Schuhe bei meinem Setup: Das NFS sind Dateifreigaben für die erwähnten Arbeitsdaten, Homeverzeichnisse etc. Die VMs sind "Images" die via iSCSI vom Virtualisierer eingebunden werden. Vermutlich nur ein oder zwei große.

@2x2x3T Mirror: Flaschenhals wird effektiv der 2x1G Link sein - ich denke nicht das ich wirklich bei den Platten ans Limit komme. Aber sicherheitshalber: Habe ich das richtig verstanden: Ich lege 2 Mirror an die zusammen ein Stripeset bilden?

@Ram: Ich habe ehrlich gesagt keine Ahnung ob 24G "genügend" sind. Ich gehe davon aus das bei 8x3T knapp ein GB/TByte zur Verfüung steht und dies ausreichen sollte. Andererseits habe ich bei der "alten" Kiste mit 32GB und 13TB Brutto mittlerweile arge Performance Probleme (einer der Gründe warum ich umbaue).

Zum Cache selber:
Meine Idee nach euren Anregungen wäre nun:
1. Mehr RAM einbauen (ich muss prüfen ob noch Slots frei sind) - 32GB gesamt sollte ausreichend sein, notfalls 48GB
2. Kein L2ARC, aber ein ZIL (ZIL = SLOG?) und den ZIL als Spiegel auslegen
3. Cache nur für das kleinere Array, das Datengrab bekommt keinen

Offen währen dann noch:
- wie groß sollte ich den ZIL anlegen? Oder gilt hier "je größer desto besser?
Vorschlag wäre hier nun 2x128GB zu nehmen, lieber etwas kleiner aber dafür bessere (=langlebige)

Grüße,
errorsmith
 
Ich sehe es ähnlich. Mehr RAM. Desweiteren würde ich gar nicht trennen und ein großes RAID-10 mit 4x2x3TB machen. "Tunen" kannst du ja auf ZFS-Ebene.

Rob
 
Ich persönlich halte es so, dass ich zwei Pools mache.

Einen Mirrored Pool mit x * 2xyTB und einen Flash-Only-Pool für wirklich performancekritische Anwendungsfälle.
Mit dem großen Arbeitsspeicher komme ich gut klar.

Lass erstmal Caching raus und teste deine Arbeitslast. Wenn du durchs Monitoring drauf kommst, dass ein ZIL oder auch L2ARC etwas bringt kannst du schnell nachsteuern.
Vorteil am Mirrored-Pool ist auch, dass du schneller wieder "online" bist, da das Resilvern schneller geht. Allerdings haut dir der Ausfall der falschen 2 Platten alles kaputt :)

Gruß
Markus
 
Hi

Zu Cache-Größe: 32GB oder 128GB ist vom Preis her nicht mehr wirklich ein großer Unterschied. Tatsächlich sind kleinere SSD eher teurer. Dann lieber die größeren SSD nehmen und nicht voll partitionieren (=mehr Reservesektoren)

Zu Flash Pool: Da ich auf dem "schnelleren" RAIDz VM's und Homeverzeichnisse haben will, bräuchte ich SSD in vergleichbarer Größe (3TB) - Das ist im Budget nicht drin und mangels wirklich schnellem Netzwerk auch nur bedingt sinnvoll. Performancekritisch im Sinne von viel I/O ist eigentlich nur die VM mit dem Fileserver. Aber selbst da hängen nur ein paar User drauf.

Eine allgmeine Trennung der Arrays ist notwendig, da die Daten in mehreren Schritten auf den neuen Server umziehen müssen: Im Ersten Schritt kommt das 3x3TB Array, welches einen großteil der Daten aus dem Archiv aufnimmt. Im zweiten Schritt werden die (dann leeren) 5x3TB Platten aus dem alten Server in den neuen Server gebaut. Ich habe also so oder so zwei Arrays. Im letzten Schritt werden die Archivdaten zurück auf das RAIDz2 Array im neuen Server geschoben und das kleinere Array mit den Homeverzeichnissen und den VM's befüllt.

Zu RAID10: Den essentiellen Nachteil hast du schon genannt: Wenn die falschen Platten sterben, stirbt das gannze Array. Ich priorisiere da Langlebigkeit / Stabilität vor Performance.

Zu RAM: 32GB? 48GB? Die Kiste kann natürlich vielmehr und ZFS nimmt was es kriegen kann, aber es sollte noch im Rahmen bleiben...


Grüße,
errorsmith
 
Vorteil am Mirror ist die Erweiterungsmöglichkeit ("Einfach 2 Platten dazu und gut ist").
Der Nachteil mit den "falschen" zwei Platten relativiert sich recht schnell, da die Zeit des Resilvern im Vergleich zu einem großen RaidZ2-Pool reduziert. Außerdem "könnten" bis zu "Anzahl" Spiegel ausfallen und du könntest immer noch an die Daten (außerdem fährst du ja auch noch Backups).
Wenn du etwas auf die Smart-Werte achtest und entsprechend reagierst kannst du das ganz gut im Blick haben.

Ich glaube ich würde mit 32 GB RAM mal starten und dann schauen, dass es bei Bedarf erweitert wird.

Bei mir reichte der gespiegelte Pool für 90% der Anwendungsfälle und nur ausgewählte VMs haben kleine Teile als Flash-Speicher bekommen (wo es sinnvoll war). Das hängt aber wie gesagt vom Anwendungsfall ab.

Gruß
Markus
 
mangels wirklich schnellem Netzwerk auch nur bedingt sinnvoll
Eine allgmeine Trennung der Arrays ist notwendig, da die Daten in mehreren Schritten auf den neuen Server umziehen müssen: Im Ersten Schritt kommt das 3x3TB Array, welches einen großteil der Daten aus dem Archiv aufnimmt. Im zweiten Schritt werden die (dann leeren) 5x3TB Platten aus dem alten Server in den neuen Server gebaut. Ich habe also so oder so zwei Arrays. Im letzten Schritt werden die Archivdaten zurück auf das RAIDz2 Array im neuen Server geschoben und das kleinere Array mit den Homeverzeichnissen und den VM's befüllt.
2 x 149GB SAS für OS als Spiegel
Ich mach dir mal einen Gegenvorschlag. Kauf dir noch drei von den 3TB Platten und bau einen Pool mit erstmal 6 Platten im RAIDZ2. Sobald die Daten vom alten Server kopiert sind, fügst du diese Platten als weiteres RAIDZ2 VDEV dem Pool hinzu (ggf. noch eine kaufen, damit du 2 VDEVs mit jeweils 6 Platten hast). Die SAS Platten für das OS kannste dir denke ich sparen, denn sind wir mal ehrlich, die werden eh den ganzen Tag nix zu tun haben. Damit hast du deine Daten auf möglichst viele Platten verteilt, was gut für I/O ist und du kannst den Speicherplatz so flexibel nutzen, wie du möchtest. Eine weitere Überlegung wäre, ein RAIDZ1 zu machen und eine Platte als Hot Spare zu verbauen. Gibt mehr Nettokapazität. Je nach dem hast du dann einen Pool aus 11 oder 12 Platten, das gibt einiges an I/O auch wenn du auf dem Fileserver viele kleine Dateien hast. Einen SSD Cache brauchst du dann für dein 1GBit Interface wirklich nicht.
 
Zur ZIL: Die Größe der ZIL ist nicht von dem gesamten Speicherplatz abhängig, sondern von der Anzahl Dateisystemoperationen pro Zeiteinheit. Je mehr das Dateisystem belastet ist, umso größer muss die ZIL sein, um alle Operatione fassen zu können. Allerdings braucht die einzelne Dateisystemoperation nur ein paar Kilobyte, eine ZIL von 500MB reicht selbst für hochbelastete Server - so einen baust du da definitiv nicht - völlig aus. Auch die Frage ob man die ZIL wirklich spiegeln muss, ist nicht mehr unbedingt mit "Ja" zu beantworten. Seitdem der Verlust der ZIL den Pool nicht mehr irreparabel zerstört, stattdessen lediglich die Änderungen der letzten Sekunden vor dem Ausfall verloren gehen, ist es durchaus eine Option sich das Geld für den Spiegel zu sparen und mit dem Datenverlust zu leben.

Zum L2ARC: ZFS wurde zu einer Zeit konzipiert, als RAM noch vergleichsweise teuer und Flash das neue, interessante Kind in der Stadt war. Die Idee des L2ARC ist einfach teuren RAM durch günstigeren, aber noch immer einigermaßen schnellen Flash zu ersetzen. In den letzten 10 Jahren ist RAM nun aber wesentlich günstiger geworden, was einen L2ARC oft uninteressant macht. Dazu kommt, dass der L2ARC einige größere Nachteile hat. Allein seine Anwesenheit verlängert die Latenz jeder Operation geringfügig. Eines der legendären ZFS-Projekte ist der "Persistent L1ARC". Solange es nicht implementiert ist, was vielleicht nie passieren wird, wird der L2ARC bei einem Reboot zurückgesetzt und muss komplett neu gefüllt werden. Das Füllen ist (in Standardeinstellung) aber ein konservativer Prozess, der viele bewegte Gigabytes benötigt. Und wenn der L2ARC irgendwann gefüllt ist, braucht man noch passende Zugriffsmuster, damit er überhaupt greift... Kurz gesagt, wenn man eh eine SSD für das Log-Device drin hat, tut es nicht weh auch noch eine Partition für 8 oder 16 Gigabyte L2ARC mit anzulegen. Mehr allerdings nicht, da die Verwaltung des L2ARC wieder wertvollen RAM benötigt. Extra Hardware für einen L2ARC zu kaufen, lohnt sich aber nur noch selten.

Zum RAM: Wie hier schon gesagt wurde, profitiert ZFS sehr von RAM. Allerdings ist es nicht endlos, stattdessen hängt die optimale Größe des im RAM gehaltenen Caches von der Menge der verwalteten Daten und vor allem der Zugriffsmuster ab. Wenn man z.B. 1TB Daten hat, aber nur auf 8GB arbeitet, wird ZFS kaum mehr als 8GB sinnvoll cachen können. Meiner Erfahrung nach brauchen so Pi mal Daumen nur sehr wenige Setups einen ARC von mehr als 24 Gigabyte. Bei kleineren Setups reichen oft auch 8 oder nur 4 Gigabyte locker aus, ohne das es zu einem nennenswerten Geschwindigkeitsverlust kommt. Wenn du RAMlastige VMs betreiben willst, kann es durchaus sinnvoll sein ZFS zu begrenzen und den RAM lieber deinem Hypervisor zu geben.
 
Hi

Vielen Danke für eure Antworten :-)
Ich konkretisiere mal etwas meinen Anwendungsfall:

Aktuell habe ich eine Reihe von mehr oder weniger handgestrickten Servern (- je nach Sichtweise 4 oder 5 Stück).
Einige davon sind in die Jahre gekommen, andere sind zickig (Consumer Hardware) und überhaupt: Es sind zu viele.
Ich habe daher damit begonnen die ganze Infrastruktur zu virtualisieren: Als VM Host dient ein HP DL380-G6 (2xXEON, 96GB RAM, 8x72GB SAS). Da ich nach Möglichkeit jeden Dienst (insbesonders extern erreichbare) einzeln in eine VM packe, reden wir von relativ vielen VM's, insgesamt ca 20 Stück.

Dazu kommt nun das Storage - diese Maschine soll keine weiteren Dienste fahren. es wird ein reiner Storage Server für NFS und iSCSI. Daher muss ich auch keinen RAM für den Virtualisierer reservieren. Der VM Host hat selber nicht genug Platz, ich möchte daher einige VM's dort ablegen. Auf dem VM Host bleiben nur VM's die auch laufen müssen wenn das Netzwerk Probleme macht (DHCP, DNS, DC) oder bei denen es auf die I/O ankommt.

Das Netzwerk selber besteht durchgehend aus GBit Verkabelung bzw 300Mbit WiFI Accesspoints. Der VM Host ist mit einem 2GBit Trunk angebunden sowie 2 x 1 Gbit einzeln (jeweils für unterschiedliche Netzwerkbereiche). Als Coreswitch habe ich einen HP Procurve, Edge/Distribution Switche sind DLink xStack bzw. Netgear ProSafe. Uplink ist für das ganze über eine 100Mbit Leitung mit einem umgebauten Igel Thin Client als Firewall. Den zu modernisieren wird mein nächstes Projekt - das gehört aber nur der Volltsändigkeit als Anmerkung hierher.

Die eigentliche Last besteht aus einer kompletten IT Infrastruktur, vom DNS Server über DHCP, Samba DC bis zum Mediacenter, Mumble, Webserver, Mailserver und privaten Gameserver. Der Userkreis ist überschaubar (ca 10 aus dem engeren Familien/Freundeskreis). Das ganze ist effektiv ein Hobbyprojekt. Bitte keine Kommentare über Sinn & Unsinn ;-) Ich lerne dadurch sehr viel das ich beruflich anwenden kann und überhaupt: Es ist mein Hobby. Die größte regelmäßige Last erzeugen der Webserver (da läuft eine Groupware drauf auf die alle zugreifen inkl. Sync auf Handy etc) und der Mailserver. Wenn "Spieleabend" ist, zieht der Gameserver auch ordentlich Last, das sind aber eher Spitzen, da der nicht regelmäßig in Betrieb ist.

Aus euren Anregungen ziehe ich nun folgendes vorläufiges Fazit:

1. Die Kiste hat 6 Slots / CPU Sockel für RAM und eine CPU. 8GB Riegel sind günstig zu haben -> Upgrade auf 48GB RAM.

2. halbwegs große SSD's sind nicht sehr teuer (kleine schon). Ich implementiere damit ein ZIL. Da dann noch Platz auf den SSD's ist, spendiere ich ihm optional noch einen L2ARC nachdem ich eine Weile beobachtet habe wie er läuft.

3. ZIL wird auf 2 SSD's gespiegelt.

Die SAS Platten für das OS kannste dir denke ich sparen, denn sind wir mal ehrlich, die werden eh den ganzen Tag nix zu tun haben.
OS & Nutzdaten sollen getrennt werden. Daher habe ich die beiden Platten, die schon drin waren, drin gelassen.

Einen SSD Cache brauchst du dann für dein 1GBit Interface wirklich nicht.
2 x 1GBit als Trunk. Für das Storage hab ich noch eine FC Adapter Karte rumliegen. Je nachdem wie sich das entwickelt wäre ein Upgrade des VM Hosts denkbar.

Über das Upgrade auf 6x3TB + 5x3TB denke ich nach, das wäre allerdings ziemlicher Overkill. Das Storage ist jetzt schon sehr reichlich ausgelegt. Vermutlich werden mir lange bevor der voll ist die Platten sterben.

Grüße,
errorsmith
 
OS & Nutzdaten sollen getrennt werden. Daher habe ich die beiden Platten, die schon drin waren, drin gelassen.
Warum? Ist es nicht besser, mehr Platten zu haben, die die Performance des Arrays steigern? Genau das willst du ja.
2 x 1GBit als Trunk. Für das Storage hab ich noch eine FC Adapter Karte rumliegen. Je nachdem wie sich das entwickelt wäre ein Upgrade des VM Hosts denkbar.
Wenn du dann mal irgendwann schnellere Interfaces hast, kannst du ja immer noch Flash Cache nachkaufen.
Über das Upgrade auf 6x3TB + 5x3TB denke ich nach, das wäre allerdings ziemlicher Overkill. Das Storage ist jetzt schon sehr reichlich ausgelegt. Vermutlich werden mir lange bevor der voll ist die Platten sterben.
Dann kaufe 6x2TB oder 6x1TB, je nach dem. Hauptsache du hast viele gleich große Platten. Das wird dir bei dem bisschen Storage mehr bringen als jeder Cache.

Nachdem du das ja für Zuhause machst, kann es ja durchaus trotzdem spannend sein, das mit Flash Cache etc. zu machen. Einfach damit man es mal gemacht hat :)
 
Warum? Ist es nicht besser, mehr Platten zu haben, die die Performance des Arrays steigern? Genau das willst du ja.

Kann sein das man das heutzutage anders macht, "traditionell" habe ich es so gelernt das man das OS auf einem Spiegel hält (und Daten auf einem anderen Array). Außerdem kann an so OS (oder Daten) relativ einfach austauschen ohne das jeweils andere "anzufassen".

Wenn du dann mal irgendwann schnellere Interfaces hast, kannst du ja immer noch Flash Cache nachkaufen.
Das ist durchaus ein Punkt. Ich ging davon aus das man bei einem derart großen Array mit Cache arbeiten sollte. Mittlerweile bin ich da schlauer.

Dann kaufe 6x2TB oder 6x1TB, je nach dem. Hauptsache du hast viele gleich große Platten. Das wird dir bei dem bisschen Storage mehr bringen als jeder Cache.
Macht keinen Sinn, da ich bereits 3x3TB gekauft habe und im alten Storage 5x3TB verbaut habe. Wenn Platten dazu kaufen dann 3TB...

Nachdem du das ja für Zuhause machst, kann es ja durchaus trotzdem spannend sein, das mit Flash Cache etc. zu machen. Einfach damit man es mal gemacht hat :)
Das ist auch einer der Gründe warum ich mich damit auseinanderseze. Sonst hätt ich vielleicht einfach ein "Fertig-NAS" gkauft...


Grüße,
errorsmith
 
Kann sein das man das heutzutage anders macht, "traditionell" habe ich es so gelernt das man das OS auf einem Spiegel hält (und Daten auf einem anderen Array). Außerdem kann an so OS (oder Daten) relativ einfach austauschen ohne das jeweils andere "anzufassen".
Ja das hat man früher schon so gemacht. Heute sind nur die Platten viel zu groß, als das man zwei davon nur für ein bisschen OS nehmen möchte. Außerdem kann man ja auch auf Hardware RAID Controllern mehrere Logical Volumes auf einem Array anlegen. Mit ZFS nimmt man natürlich Datasets.
 
Falls man auf den ZIL-Platten noch Platz über hat, kann man dieses auch als SWAP verwenden. Nur so als Tipp :)
 
Hallo,

2x 256GB SSD latenz Write: 20μs 30% OS 20% ZIL rest leer.
8 x 3 TB SATA RAIDZ2 für VM / HDD Images & Arbeitsdaten (NFS & iSCSI)

wäre unter deinen vorgaben die leistungsfähigste und 18 TB auch genug Platz für alles.

Viele Grüße

Jörg
 
Hi

Ich steigmal mit ein. Kann man L2ARC als Mirror einbinden? Und macht das Sinn? Ich meine wenn der Cache mal plötzlich ohne Vorwarnung weg sein sollte. Was macht man da?
 
hmm also dann bei zwei 250 GB SSD macht dann folgende Aufteilung eher Sinn?

2 x 1 GB für ZIL im mirror
2 x 239 GB für zwei mal Cache also 478 GB
10 GB lasse ich jeweils für defekte Blöcke frei
 
Ich würde sagen, dass kommt auf deinen Usecase drauf an. Für ein "allround" Setup würde ich eher 20GB ZIL nehmen. Das freilassen auf SSDs ist meines Wissens bei modernen SSDs nicht mehr nötig, das war nur bei den ersten Generationen "in".

LG
 
OK habe jeweils 20 GB als ZIL, 235 als Cache aber trotzdem 5 GB frei gelassen. Sicher ist sicher! Danke!
 
Mit "zfs-stats" kannst du dir im Betrieb verschiedene Werte anzeigen lassen, wenn du experiementierfreudig bist, kannst du später eventuell dein Setup noch tunen, damit es besser zu deinen konkreten Anforderungen passt.
 
Zur ZIL: Die Größe der ZIL hängt einzig von der Anzahl Transaktionen ab. Über den Daumen kann man sagen, dass dort 1GB dicke genug ist. Um die auszunutzen, muss schon einiges an Druck auf dem Storage sein, was man mit einer überschaubaren Anzahl an Festplatten schon mangels Durchsatz kaum hinbekommen kann. Andererseits schadet eine größere ZIL auch nicht. Ob man die ZIL spiegeln will, ist auch eine vom Szenario abhängige Frage. Wenn das ZIL-Device versagt und es keinen Spiegel gibt, sind die letzten paar Sekunden halt weg, was vollkommen egal oder eine Katastrophe sein kann.

Zum L2ARC: Sehr große Cache-Devices zu nehmen ist verlockend, aber nicht unbedingt sinnvoll. Denn die Verwaltung des Cache-Devices benötigt wiederum RAM. So als grobe Annäherung kann man sagen, dass alles über 10GB L2ARC pro 1GB RAM nicht mehr sinnvoll ist. Mit 24GB RAM wären das also 240GB L2ARC. Dazu kommt, dass der L2ARC prinzipbedingt weitere Latenzen einfügt. Aus RAM -> Storage wird RAM -> L2ARC -> Storage. Das kann wahre Wunder vollbringen, wenn der L2ARC wirklich greift. Hat man aber ein Szenario, in dem die Zugriffsmuster cacheunfreundlich sind und den L2ARC unterlaufen, kann man sich auch einen bedeutenden Nachteil einhandeln. Daher sollte man den L2ARC beobachten, also schauen, wie viele Cache-Hits man hat und wie schnell er sich füllt und anhand daran entscheiden, ob man ihn nutzen will und wir man ihn dimensionieren sollte.

Nachtrag: Beim L2ARC muss man sich immer vor Augen führen, dass ZFS zu einer Zeit konzipiert wurde, als RAM noch richtig teuer war. Flash war zwar auch teuer, aber schon eine Stufe günstiger. Es machte daher Sinn RAM durch Flash zu ersetzen. Da in den letzten 10 Jahren RAM aber bedeutend günstiger geworden ist und man sich mehr davon leisten kann, hat der L2ARC an Bedeutung verloren.
 
Hi

Sorry für die lange Pause, mich hats gesundheitlich etwas entshärft, aber nun bin ich wieder an meinem kleinen Projekt.
Eine Änderung ergab sich insofern daß ich zwei 160GB SSD geschenkt bekommen habe. Das heißt das ich auf jeden Fall einen OS Spiegel anlegen werde. Für die Aufgabe als reiner NFS / iSCSI Server schwebt mir daher nun folgendes vor:

1. Partitionierung beider SSD's in:
- 80GB mirror fürs OS
- 2 GB mirror fürs ZIL
- 32 GB mirror für swap
den Rest lasse ich frei, einerseits um optional den L2ARC dazu bauen zu können, andererseits als "Reserve"
(Kann ich einem Pool mehrere L2ARC's zuweisen?)

2. HDD / Datenpool:
- zu den 3 x 3 TB Platten werden noch 2 x 3 TB gekauft. Diese werden dann als 5 x 3 TB RaidZ2 eingerichtet, was mir erstmal Netto ca 8TB bringt, dies ist für den Umzug ausreichend (belegt aktuell ca 5TB). Nach dem Umzug kann ich die "alten" 5x3TB in den Server schrauben und erhalte entweder einen weiteren 8TB Pool oder ich baue ein Stripeset aus 2 x 8TB. (geht das nachträglich?) Alternativ kann ich die verbleibenden 5 Bays auch erstmal frei lassen und später Platten dazu kaufen (wenn größere Platten billiger sind).

3. RAM:
Hier sind 6 von 6 Slots belegt, ich müsste den Speicher für ein RAM Upgrade mehr oder weniger komplett neu kaufen. Da keine Dienste auf der Kiste laufen, werde ich zunächst abwarten ob 24G ausreichen.

Wie seht ihr das?


Grüße,
errorsmith
 
Zurück
Oben