NAS - ZFS Umzug

[bbott]

Hallo,

ich darf den Umzug von ZFS Z1 (Raid 5) Volumens durchführen. Es sollen erst bei einem FreeNAS (HP MicroServer Gen8) die HDDs durch größere ersetzt werden. Im zweiten Schritt die NAS Platten in ein zweites FreeNAS wandern.

Das Szenario ist weicht etwas vom normal Fall ab:

1. NAS No1 - ZFS Pool1 -> soll neue größere HDDs bekommen.
2. NAS No2 - ZFS Pool2 -> Soll HDDs von Pool1 bekommen.

Das Standard vorgehen, wäre eine HDD zu ersetzen und rebuild anstoßen.

8. Storage — FreeNAS User Guide 9.3 Table of Contents

www.ixsystems.com

Also müsste ich diesen Vorgang acht mal wiederholen.


Jetzt dachte da an folgende (alternative) Möglichkeiten:

1. HDD per SATA anschließen und vorgehen nach Referenz., aber der SATA-Anschluss ist eher unzugänglich. Nachteil dauter sehr lange.

2. HDD(s) per USB anschließen, ist das bei ZFS überhaupt möglich? Also da die HDD ID richtig erkannt? Ist es auch möglich z. B. zwei HDDs parallel zu ersetzen?

3. Alle Platten per USB anschließen und neuen Pool bauen, nach dem Build und Daten kopieren mit alten Platten tauschen. Da der ProLiant nur zwei USB 3.0 Ports hat ist ein USB hab wohl pflicht. USB 2.0 wird zu langsam sein oder?

4. Im zweiten NAS die Platten ausbauen und mit neuer SD-Karte die neuen Platten einrichten und Daten von NAS No1 auf NAS No2 mit neuen HDDs kopieren. Langsamer Datentransfer wegen 1 GBit LAN. Anschließend die Platen vom zweien in erste NAS umbauen. Dann wäre noch die Frage welche SD-Karte ich im NAS No1 nutzen sollte? Alt oder Neu?

Analog würde ich dann die Platten vom NAS No1 in das NAS No2 migrieren.

Welche ist die sicherste und schnellste, bzw. überhaupt mögliche Variante? Oder gibt es eine noch bessere?!


Danke schon mal für die Antworten und Ideen

 

[Digi-Quick]

Bei deinem Vorgehen hast du 8x die Chance den Pool zu Schrotten, weil bei jedem Rebuild erstmal die Redundanz weg ist und dauert in Summe mit Sicherheit länger als der richtige Weg! Je Nach dem wie groß die Platen im alten NAS sind, wie alt diese sind und welche URE die haben kann die Wahrscheinlichkeit, daß dein Weg in die Hose geht gegen 100 % tendieren! Dann müßtest du das hoffentlich vorhandene Backup einspielen.

Richtiger Weg:
Neuen Pool im neuen NAS einrichten und die Daten übers Netz übertragen, am sinnigsten mit ZFS SEND.
RSYNC wäre da nur die zweitbeste Möglichkeit

 

[asche77]

Dito - kein rebuild! Kein USB2, zfs send über GBit Ethernet ist (etwas) schneller.

 

[gea]

Wenn man zum Platten ersetzen eine neue Platte zusätzlich einbaut und dann ersetzt, bleibt die Redundanz erhalten. Gefährlicher wirds nur wenn man die alte Platte herausnimmt, die neue einsetzt und dann resilvered. Die sicherste und wohl auch schnellste Methode ist aber tatsächlich den Pool in der neuen Machine Nr2 importieren und per zfs send übers Netz replizieren.

 

[konfetti]

Nach dem Move der Daten vom NAS1 ins NAS2 mit neuen großen Platten, würde ich aber nicht nochmal umbauen... - da kann ja auch wieder was schief gehen!

Was hindert daran, das NAS2 danach als primäres System zu verwenden?

 

[bbott]

Das NAS 2 hat weniger RAM (kein Problem, geht Umbauen), aber NAS2 habe ich manchmal Problem beim Booten, es hängt dann muss ich hart rebooten. Das Bootdevice wird nicht immer erkannt.

EDIT:
Da beide NAS zwei GB LAN Port haben wäre eine Link Aggegation interessant. Aber das geht nur mit geeignetem Switch und eine synchronen Verkabelung, oder? Also die NAS einmal direkt (Crossover) zu verbinden, und einmal über das Netzwerk. Oder ist dies inzwischen möglich?

 

[Gen8 Runner]

Link aggregation geht theoretisch schon, sofern von beiden Servern, deren Software und dem Switch unterstützt. Aber selbst bei nur Gbit: Nach vier Tagen roundabout (sofern es nicht unendlich viele winzige Files sind) wäre der komplette Umzug doch durch.

Da würde ich mir gar keine große Platte machen, wie lange das denn dauern könnte etc. Starten, laufen lassen, nach vier Tagen glücklich sein.

 

[Ceiber3]

Mit Link Aggregation steigt aber nicht der Durchsatz von Server zu Server oder von Server und PC usw...
Bei Link Aggregation hast du nur ein Vorteil, wenn ein Server 1 Gbit ausnutzt und ein weiterer PC auch irgendwas vom Server lädt, dann können beide 1 Gbit nutzen. Oder halt als Ausfallsicherheit.
Wenn du Speed haben magst, lieber SMB3 Multichannel.

 

[tolga9009]

Sehe das genauso, wie @Gen8 Runner. Einfach über Gigabit rüberziehen und gut ist. Du kriegst durchschnittlich ca. 7 - 9TB pro Tag über Gigabit bewegt. So kannst du dir ausrechnen, wie lange der Transfer ca. dauern wird. Das gute ist: du führst einen einzigen Command aus und kannst dich dann in der Zwischenzeit voll und ganz anderen Themen widmen.

Das mit dem NAS2 hört sich ja überhaupt nicht gut an. Um was für ein System handelt es sich?

 

[TCS]

Ich hätte jetzt die Platten in NAS2 eingebaut den Pool importiert, neue Platten in NAS1 rein und dann via zfs send syncen (Vorteil - wenig basteln und Daten landen auf NAS1 wenn die Hardware schon stable ist)- wenn man mehrere Datasets nutzt könnte man auch die beiden NICs auslasten, hängt aber von der Belegung ab ob das Sinn macht - bei mir warns 8TiB netto - Direktverbindung der NICs und laufen lassen.

 

[bbott]

Link Aggregation steigert sehr wohl den Durchsatz. Zum Client (Zielrechner) der in der Regel kein Link Aggregation unterstützt natürlich nicht. Aber wenn Quelle, Ziel und Switches Link Aggregation unterstützen funktioniert es. ;-)
Quelle:

Link Aggregation und LACP Grundlagen – Thomas-Krenn-Wiki

Link Aggregation nach IEEE 802.1AX-2008 (früher IEEE 802.3ad) ist ein Standard zur parallelen Bündelung von mehreren Netzwerkverbindungen. Vorteile einer Link Aggregation gegenüber einer herkömmlichen Verbindung über ein einzelnes Kabel sind eine höhere Verfügbarkeit sowie eine höhere mögliche...

www.thomas-krenn.com

@tolga, Digi-Quick
Die vierte Option wäre auch meine Wahl gewesen. Nur die USB 3.0 Variante Pool per USB erstellen und dann Platten tauschen hätte ich mir als Option evtl. bessere vorstellen können. Unter anderem weil dann das BS den neuen Pool kennt

Nach dem Booten wird wird häufiger das NAS nicht über das Netzwerk erreichbar (Soft Shutdown per Power-Schalter). Teilweise war es nach Stunden nimmer noch nicht erreichbar. Ich hatte dann schon mal einen Monitor dran und nach der Ursache geschaut, kann mich nicht leider mehr sicher daran erinnern. Ich glaube das Netzwerk Interface kommt dann nicht hoch. per Konsolen Command konnte ich das beheben. Ist natürlich schlecht wenn das NAS nicht im Netzwerk erreichbar ist ;-)
Ein Hard-Reset ist bisher sehr selten notwendig gewesen.

Auch hatte der SD-CardReader schon mal die Installation geschrottet, deshalb nutze ich nun einen USB-Stick. Das BS auf dem Sick wurde zumindesten bisher nicht geschrottet ;-)

Deswegen würde ich gerne die neuen Platten dann im NAS1 nutzen, weil es bisher unauffällig war. Ist mit einem Problem zu rechnen, wenn ich um NAS2 ein neues BS aufsetze samt neuen HDDs und dann im NAS1 umstecke? Werden noch andere IDs gecheckt? Der RAM ist mit 6GB und 16GB auch größer.
Wenn ich nur die neuen HDDs in das NAS1 mit "altem" BS starte führt das zum rebulid/resilvern, oder? Vorteil wäre aber das Dienste, Konfig usw. behalten werden könnten.

Beitrag automatisch zusammengeführt: 19.05.2020

Ich hatte unterschätzt wie viel TB am Tag das Gbit LAN schafft. Da lohnt sicher der Aufwand mit Link Aggregation usw. nicht.

Beitrag automatisch zusammengeführt: 19.05.2020

Wenn ich die Platten ins NAS2 einbaue und den Pool importiere muss doch dort erstmal resilvert werden, oder?! Damit würde ich die "alten" Platten stressen. Ich bevorzuge die Belastung der neuen, um Transport oder Herstellungsfehler frühzeitig aufzudecken. Ich formatiere Platten auch erst einmal vollständig (kein Quick Format) bevor ich diese nutze.

 

[ludwinator]

Wenn du schon schlaue Grundlagen Artikel postest, solltest du sie wenigstens auch lesen.
Zitat:

• Alle Frames, die zu einer bestimmten Datenkommunikation gehören, werden aber über dieselbe physische Verbindung (Kabel) übertragen. Das gewährleistet die Zustellung der einzelnen Frames einer Datenkommunikation in der richtigen Reihenfolge (verhindert mis-ordering).

Ergo du kannst keine einzelne SSH-Verbindung (Standardverfahren füt zfs send/receive) zw. zwei Servern auf 2GBit beschleunigen mit LACP.
Du müsstest schon mehrere parallele Verbindungen per Hand aufbauen und verschiedene Streams schicken.

Wie schon einige Vorredner rate ich dringend davon ab, Disk-Jockey zu spielen.

 

[Ceiber3]

Wenn du schon schlaue Grundlagen Artikel postest, solltest du sie wenigstens auch lesen.
Zitat:

• Alle Frames, die zu einer bestimmten Datenkommunikation gehören, werden aber über dieselbe physische Verbindung (Kabel) übertragen. Das gewährleistet die Zustellung der einzelnen Frames einer Datenkommunikation in der richtigen Reihenfolge (verhindert mis-ordering).

Ergo du kannst keine einzelne SSH-Verbindung (Standardverfahren füt zfs send/receive) zw. zwei Servern auf 2GBit beschleunigen mit LACP.
Du müsstest schon mehrere parallele Verbindungen per Hand aufbauen und verschiedene Streams schicken.

Danke. Ich habe meine beiden Nas: Haupt-Nas und Backup-Nas in einer Link Aggregation. Nicht um den Speed zu verdoppeln, sondern für den Ausfallschutz.

 

[tolga9009]

Nur die USB 3.0 Variante Pool per USB erstellen und dann Platten tauschen hätte ich mir als Option evtl. bessere vorstellen können.

Würde ich die Finger von lassen. Wenn du einen guten USB 3.0 Controller hast, der nur als reines UASP dient und sonst nichts macht, funktioniert das schon. Aber wenn das nicht der Fall ist (z.B. bei externen WD Festplatten) und die hinter den Kulissen Verschlüsselung, geschützte Bereiche usw. betreiben, wirst du damit Probleme bekommen. Kann also sein, dass die Platten im USB Gehäuse putz und munter laufen, sobald du sie aber im NAS drin hast, werden die Festplatten nicht gefunden oder die Daten sind einfach "schrott". Musst also bei diesem Ansatz definitiv ein Scrub durchführen und schlimmstenfalls die Daten nochmal rüberziehen (dieses Mal über Gigabit). Deshalb: einfach direkt über Gigabit.

Wenn du das häufiger machst / machen möchtest, lohnt es sich vielleicht, 2x 10Gbit NICs im Schrank zu haben. Die werden mittlerweile bei eBay fast verschenkt.

 

[bbott]

10G war schon längst geplant, leider sind die Preise noch uninteressant (NIC + Switch). Auch der Stromverbrauch sollte langsam mal besser werden. Aber es wird ständig nur WLAN schneller, ohne das es Sinnvoll wäre ohne das Kabel zu beschleunigen.

 

[Gen8 Runner]

Die Meinung vieler ist sowieso, dass man 1x pro Monat den ganzen Pool scrubben sollte. Das ist auch Stress für die Platten, aber sollten sie dabei abrauchen, haben sie es auch nicht verdient im NAS zu sein. So zumindest meine Meinung zu RaidZ2 mit NAS Festplatten (und Backup mittlerweile gottseidank).

Bis jetzt habe ich immer die Option des Resilverings genutzt. Beim letzten Switchen von 14x 4TB auf 7x 8TB hatte ich einen Pool komplett resilvert (Platte raus, Platte rein -> Resilver -> Platte raus, Platte Platte rein -> Resilver) und keine einzige ist dabei ausgefallen (obwohl es billige Seagate Barracuda aus externen Festplattengehäusen waren).
Beim letzten Resilvering von den Ironwolf auf die Hitachi Ultrastar auch keine Probleme beim Resilvern. Mit RaidZ2 + Backup kann man da aber auch ziemlich entspannt rangehen m.M.n.

Ansonsten aber ist Netzwerk schon die super Lösung. Bei Gbit (die ja auch im Heimnetzwerk bei großen Dateien definitiv ankommen) geht das auch alles fix von der Hand. Gbit schafft da auch schon einiges weg, bei 10 Gbit sind dann ja wieder irgendwo die Platten der begrenzende Faktor (außer SSD's mit entsprechender Anbindung und Poolgestaltung).

 

[bbott]

Zitat (meiner Quelle):
Die Qualität wie gut die einzelnen Frames verteilt werden und wie hoch der praktische mögliche Datendurchsatz steigt, hängt somit von der konkreten Implementierung der Link Aggregation in einem Switch bzw. Treiber ab. FreeBSD verwendet dazu beispielsweise eine Hash des Protokoll Headers. Der Hash beinhaltet dabei Ethernet/MAC Quell- und Zieladressen, falls verfügbar ein VLAN-tag, sowie IPv4/IPv6 Quell- und Zieladressen.[6]
Weitere Informationen dazu finden Sie im Artikel Link Aggregation Lastverteilungs-Algorithmen.

Es hängt von der Implementierung, ab einfache könne nur ein Link für eine Verbindung nutzen. Andere können n-Links zu einem Virtuellen zusammen fassen und die Bandbreite um n-steigern.


@Gen8 Runner
HDDs schaffen inzwischen bis zu 260MB/s (7.200 upm) macht bei 4x 260 schon 1040MB/s, da muss schon eine M2 SSD her um das weg zu schreiben, Eine einziele Platte kann bei großen Daten schon massiv von GB LAN ausgebremst werden.

 

[TCS]

.

Beitrag automatisch zusammengeführt: 19.05.2020

Wenn ich die Platten ins NAS2 einbaue und den Pool importiere muss doch dort erstmal resilvert werden, oder?! Damit würde ich die "alten" Platten stressen. Ich bevorzuge die Belastung der neuen, um Transport oder Herstellungsfehler frühzeitig aufzudecken. Ich formatiere Platten auch erst einmal vollständig (kein Quick Format) bevor ich diese nutze.

Nein - einer der Vorteile von ZFS 😁
Alle Infos zum Auslesens des Pools sind auf dem HDDs vorhanden. Anstöpseln - importieren - sofort ready

Hatte das 2x gemacht, einmal mit 4x1TB und einmal 4x4TB - stresst die alten HDD gleich wie der Transfer über Netzwerk - der Vorteil ist du kannst dei neuen in ihrem endgültigen Zuhause einbauen - burn in nach Wahl fahren und dann die Daten replizieren

 

[underclocker2k4]

bbott, wenn man schon Quellen hat und diese hier auch zitiert, sollte man sich auch die Zeit nehmen und sich das ganze zum einen durchlesen und zum anderen auch verstehen.

Eine LAG funktioniert nur in den seltentens Fällen so, wie sich das nichtFachleute vorstellen.

Nehmen wir mal an du hast einen Server und einen PC, beide sind per LACP an ein Switch angebunden. Jetzt entscheidetd das sendende Gerät anhand des Hashalgorithmus, ob und wie es die LACP nutzen mag.

Ein MAC Hash verteilt die Pakete anhand der verschiedenen Quell und/oder Ziel MAC der NIC.
Jetzt ist es so, das bei einer solchen einfachen Konstellation es nur eine Ziel und eine Quell MAC gibt. Daher sieht jedes Paket für den Hash gleich aus (er schaut immer nur in Quell/Ziel MAC und da steht immer das selbe drin) und daher verteilt der Algorithmus nicht und nimmt z.B. immer Link 1. Da du auf keiner der NICs zwei MACs laufen lassen kannst, kommst du aus der Nummer nicht raus.

Ein IP Hash verteilt die Pakete anhand der verschiedenen Quell und/oder Ziel IP der NIC.
Jetzt ist es so, das bei einer solchen einfachen Konstellation es nur eine Ziel und eine Quell IP gibt. Daher sieht jedes Paket für den Hash gleich aus (es schaut immer nur Quell/Ziel IP und da steht immer das selbe drin) und daher verteilt der Algorithmus nicht und nimmt z.B. immer Link 1. Jetzt kann man beiden NICs jeweils zwei IPs geben. Wenn man aber einen Filetransfer anschiebt, dann sagt man ja, kopiere bitte von IP1.1 nach IP 1.2. Das kann nicht aufgeteilt werden, da jedes Paket gleich aussieht, siehe ein paar Zielen weiter oben. Jetzt muss man also auch von IP1.3 nach 1.4 kopieren, damit er dann den 2. Link benutzt, das würde er auch machen, da ja der IP-Bereich im Frame anders aussieht wie der erste IP-Bereich. Das ist aber ein zweiter Filetransfer, der auch auf einen komplett anderen Filebereich arbeiten muss, da sonst doppelt kopiert wird.
Um sowas zu machen, braucht man aber kein LACP. Dazu nimmt man einfach zwei getrennte Strippen und macht dann das gleiche. Strippe 1 macht immer Filetransfer A und Strippe 2 immer B. Problem gelöst.
Am Ende läufts also bei der Situation immer darauf hinaus, dass du dann zwei Datastreams hast.
PS: Hinzu kommt das Problem, wenn die beiden IPs auf einer Seite aus dem selben Subnetz sind, wird nur eine IP und als Quelle genommen, und daher braucht man also min. Hash mit ZielIP...

VLAN selbes Thema. Du kannst also auf der NIC zwei VLANs machen. Dazu gehören dann aber auf Systemseite zwei virtuelle NICs, die wieder unterschiedliche IPs haben. Jetzt verteilet der Algorithmus anhand der VLAN, die zu bedienen sind, die Pakete. VLAN 1 kann also über Link 1 gehen und VLAN2 über Link 2. Nur, wie kommen diese Pakete in die VLANs rein? Da kommen die virtuelle NICs zum Tragen.
Du hast also auf Betriebssystemseite wieder 2 vNICs und diese vNICs haben wieder unterschiedliche IPs. Und damit bist du wieder bei der selben Problematik wie beim IP-Hash. Sprich, du hast zwei Datastreams, die initiert werden müssen mit den selben Problemen. Kann man sich aber auch schenken, man nimmt einfach wieder zwei separate Strippen und macht das ohne den Kram.

Jetzt kann man das sogar noch auch Layer4 ausdehnen, sprich also auf TCP/UDP-Ports. Da hat man aber das Problem, dass man zwei unterschiedliche Ports braucht. Da aber eine Verbindung eines Datastreams nur einen Quell- bzw. einen Ziel-Port hat, läuft es wieder darauf hinaus, dass man zwei Streams braucht, die dann mindestens 1 (oder 2, je nach Implementierung) unterschiedliche(n ) Port(s) haben. Jetzt kommt wieder der Standardssatz mit den 2 Strippen...

Das kann man jetzt 1000x noch hin und her denken. Am Ende läuft es immer darauf hinaus, dass man bei zwei verbundenen Systemem und einem Dienst immer irgendwie gezwungen wird einen 2. Datastream aufzumachen.

Zurück zum 2. Satz des Posts:
LACP funktioniert also selten so, wie es sich nichtFachleute denken.
LACP insbesondere mit den verschiedenen Hash Algorithmen macht besonders dann Sinn, wenn man Switche miteinander verbinden will und der Linkspeed nicht mehr reicht oder man aber einen Server anbinden will, der mehrere (min. 2) Clients gleichzeitig bedienen soll.
In einer einfachen 1:1 Konstallation bringt LACP leider garnichts.
Hinzukommt, dass FreeBSD zwar z.B. VLAN LACP kann, dies aber nur seltenst von den Switches unterstützt wird. Das muss also abgestimmt sein sonst bringt das auch nichts.

Wir haben uns vor einiger Zeit für eine komplett neue Switchgeneration eines großen Herstellers entschieden. Die Softwareplattform ist sehr mächtig und entsprechend modern und gut gefeaturet als TOR/AGG-Switch. Aber für runde 15k Listenpreis bekommt man bei LACP lediglich L2/3 und sonst nichts. Sprich also ein VLAN LACP könnte man damit nicht machen.
Sowas braucht man aber auch nur in extrem seltenen Fällen (wir zumindest) und ist daher nicht relevant.
Dient aber ganz gut einer Einordnung in die Relalität.

Am Ende kann man sagen, wenn @home nicht gerade nen total Bekloppter ist (siehe aktuelle Situation im Bilderthread ) kommt LACP eigentlich nicht als Bandbreitenerhöhung zum Tragen und dient allenfalls als Redundanz. (und da fällt mir ein, dass mir noch NIE auch nur ein einziger Port, weder Switch noch NIC, hops gegangen ist, ich wäre also auf eine solche Redundanz nicht angewiesen gewesen)
Und genau das ist auch das, wofür man LACP in Produktivumgebungen gerne hernimmt. Es liefert dann in erster Linie eine relativ einfache Redundanz, die schon unterhalb der MAC greift, und es bietet einem zusätzlich noch den Mehrwert, dann man Lastspitzen über 1x Linkspeed einfach wegschluckt. Zusätzlich kann man sowas auch easy skalieren, bzw. kann man damit auch eine LACP über mehrere NICs spannen (sofern der Treiber das kann) und kann damit sogar den Tod einer NIC/Chip oder gar PCI(e)-Slot abfangen.
Richtig spannend wird LACP bei einer MultichassiLACP, wo man das dann noch über zwei physisch getrennte Switche aufbaut und einem selbst nen Switchtod kalt lässt (zumindest was die Verfügbarkeit angeht).

Merke: Vergiss LACP.
Merke2: Es hat schon einen Grund, warum MS in SMB3 das Multichannel eingebaut hat. (nur um das klarzumachen, das Problem ist, dass LACP bei SMB zwischen 2 Systemen nicht greift)

 

[konfetti]

Naja, in Produktivumgebungen, nutzt man LAG doch auch nur, um verschiedene Hardwareports (dedizierte NIC + Mobo z.B.) entweder auf 1 Switch zu stecken und damit den Ausfall einer Komponente zu kompensieren, oder gar dank VSC (virtual switching) auf mehrere Switche zu verteilen.

 

[underclocker2k4]

Konfetti, meinste das das wirklich so ist?

Am Ende kann man sagen, wenn @home nicht gerade nen total Bekloppter ist (siehe aktuelle Situation im Bilderthread ) kommt LACP eigentlich nicht als Bandbreitenerhöhung zum Tragen und dient allenfalls als Redundanz.

Und genau das ist auch das, wofür man LACP in Produktivumgebungen gerne hernimmt. Es liefert dann in erster Linie eine relativ einfache Redundanz, die schon unterhalb der MAC greift, und es bietet einem zusätzlich noch den Mehrwert, dann man Lastspitzen über 1x Linkspeed einfach wegschluckt. Zusätzlich kann man sowas auch easy skalieren, bzw. kann man damit auch eine LACP über mehrere NICs spannen (sofern der Treiber das kann) und kann damit sogar den Tod einer NIC/Chip oder gar PCI(e)-Slot abfangen.
Richtig spannend wird LACP bei einer MultichassiLACP, wo man das dann noch über zwei physisch getrennte Switche aufbaut und einem selbst nen Switchtod kalt lässt (zumindest was die Verfügbarkeit angeht).

Und natürlich nimmt man auch den Bandbreitengewinn mit. Warum sollte ich mir für teuer Geld 40GBE einbauen, wenn einem 2x 10GBE für weniger Geld auch reichen. (mit den entsprechenden Feinheiten des Loadbalancing)

 

[konfetti]

Natürlich nimmt man den Bandbreitengewinn mit, aber das ist wie das Thema mit 2 Netzteilen an 1 USV - warum macht man das?

@Lan haben wir alle Interfaces der ESXi (4x onboard + Quad 1Gbit NIC) auf alle Karten des Cisco 4507Rer Chassi aufgeteilt

@work habe ich im 10G "Backbone" ein VSC laufen, wo dann die Server und Switche entsprechend einen LAG als Uplink haben.
Hatte das auch bei meinem vorherigen AG so aufgebaut, allerdings mit anderen Switchen - war Top und dadurch hat der Wegfall eines Serverraums durch Anbaggern der Leitung auch kaum Einfluß auf den Betrieb gehabt.

@home brauch ich das aber nicht, da ich mit den 1G der Clients den 10G Uplink halt einfach nicht ausgelastet bekomme, das passiert nur beim Backup auf den Server mit der anderen 10G NIC

dennoch würde ich hier nicht Disk-Jokey spielen, wie oben schon erwähnt.
Ggf. kann man das NAS2 ja aufrüsten, bzw. für den Betrieb fitter machen und einfach die Rollen tauschen, wozu hat man sonst 2 NAS? - eins als Hauptsystem und eins fürs Backup, oder?

 

[bbott]

Da ich mit zfs send noch nicht gearbeitet habe, wollte ich mich hier vergewissern, ob ich nur aus:

zfs send tank/dana@snap1 | ssh host2 zfs recv newtank/dana


Shell NAS1: zfs send PoolName/dataset@snap1 | ssh IP_NAS2 zfs recv PoolName/dataset

machen muss. Den neuen Pool auf NAS2 hätte ich vorher angelegt.

Die Logindaten werden dann beim Verbindungsaufbau abgefegt, oder?


Quelle:

https://docs.oracle.com/cd/E19253-01/820-2313/gbchx/index.html

 

[martingo]

Verwende lieber netcat (nc). Das ist unverschlüsselt, aber deutlich weniger rechenintensiv.

 

[ludwinator]

Mag sein, aber dafür muss er auf der Empfängerseite was tun und den listener starten.
Wesentlich interessanter dürften für ihn Kommandozeilenparameter wie send -w oder -c und natürlich -v sein.

 

[bbott]

Also ich hätte zwei Fragen:
1. Die Parameter w,c und v habe ich jetzt nicht gefunden nur R,i und l - da brauch ich hilfe. Danke.
2. Kann ich ZFS schlankter machen? Weil von 1TB bleiben nur 870,4 GB, bei anderen Dateisysteme bleiben je TB ca. 931GB. Es sollen zu 99,9% nur große Files gespeichert werden. Da ich Snaphots etc. nicht nutze und Duplizierung bei den Daten leider nicht funktioniert..

 

[gea]

Für ein einfaches erstmaliges Replizieren eines Dateisystems reicht ein einfaches send -> receive ohne Paremeter. Netcat ist die schnellste und einfachste Option, https://blog.yucas.mx/2017/01/04/fast-zfs-send-with-netcat/

Die zfs send Parameter hängen vom jeweiligen Betriebsystem ab. Ein "man zfs" auf der Konsole zeigt die jeweils gültigen Parameter. Das gibt als Ausgabe sowas wie https://illumos.org/man/1M/zfs bei einem aktuellen Illumos/OpenIndiana/OmniOS

Zur Kapazität
Die erste Anmerkung dazu ist, dass ZFS die Kapazität nicht z.B. in TB (Terabyte) sondern in T (Tebibyte) angibt. Das sind ca 10% kleinere Angaben allein aufgrund der Maßeinheit, https://www.umrechnung.org/masseinh...e-mb/datenmenge-filegroesse-speicherplatz.htm

Tatsächlich reduzieren könnte man die Beleging wenn man die Prüfsummen auf Daten und Metadaten deaktiviert - aber wer will das schon. Ist wie ESP und ABS abschalten beim Auto. Auch setzt ZFS eine kleine interne Reservierung damit das ZFS Dateisystem nicht unkontrolliert mit CopyonWrite vollläuft. Das kann und sollte man nicht abschalten.

LZ4 Komprimierung kann man dagegen fast bedenkenlos aktivieren. Dedup ist wegen den RAM Verbrauch problematisch sofern man dafür kein special vdev einsetzt. Das verlagert die Dedup Tabelle aus dem RAM auf ein vdev im Pool z.B. einen NVMe Mirror.