Freenas 9.2.1.8 auf neue Hardware umziehen

Status
Not open for further replies.

Semmelbrosel

Dabbler
Joined
Jul 5, 2013
Messages
12
Hallo Leute,

vielleicht hat einer der Profis eine Tipp für für folgendes Problem.
Ich will meine Daten vom jetzigen Server auf neue Hardware umziehen.
Es ist dedup eingeschaltet also fällt das kopieren auf den neuen Server weg, da gedupt etwa 4 TB Daten sind und der Kopiervorgang etwa 6 Wochen dauern würde.

Also schlau wie ich bin, dachte ich, dass geht doch bestimmt per ZFS Snapshot Replikation ja auch.
Eingerichtet und Transfer läuft auch, aber jetzt legt der Depp für jeden Tag ein komplettes Snapshot an.
So wollte ich das aber nicht, ich dachte er macht ein Snapshot und dann z.B. alle 1 Stunde nur die Änderungen.
Dann müsste er nur einmal die große ZFS kopieren und später nur noch die kleine.

Jetzt wollte ich erstmal wieder alle Snapshot löschen, aber das geht nicht es kommt:
cannot destory snapshot Data/..... : dataset is busy
Laut Google bin ich damit nicht alleine, ich habe versucht wie in vielen Lösung das der Shell zu machen aber nix wars. Ich bekomme die alten Snapshots einfach nicht gelöscht.

1. Wie kann ich diese alten Snapshots löschen?
2. Wie kann ich die Daten auf dem neuen Server replizieren?

Gruß Mario
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
Dedup... Das wird kompliziert.

Eigentlich sollte ZFS Replication genau so funktionieren: Erstmals das Ganze, dann nur die neue Snapshots, also nur die Änderungen.

Mit langsames GbE sollten 4TB eigentlich "nur" ~15 Stunden zum Übertragen brauchen, also ist da etwas nicht richtig.

Was für Hardware wird denn hier eingesetzt? Vom alten und vom neuen Server.
 

Semmelbrosel

Dabbler
Joined
Jul 5, 2013
Messages
12
Das stimmt da aber bei normalen Kopiervorgang müssen die Daten ja wieder reduped werden und das kostet CPU und I/O. Und da auch noch Compression eingeschaltet wird hat die CPU alle Hände voll zu tun.
So werden aus 4 TB geduped schon mal 30TB und mehr zum Transfer.

Der alle Server ist ein Pentium mit 3Ghz und 8GB Ram, SSD für Freenas und 8x1TB LSI Raid Kontroller für die Nutzdaten.
Der neue ist ein Xeon 3440 mit 24GB RAM, auch SSD für Freenas und 8x 2TB an LSI Kontroller + 120GB SSD als ZFS Cache. Ich denke das sollte genug Leistung sein.

Anbei mal die Snapshots + die Fehlermeldung die kommt wenn man den löschen will.
Ich habe alle ZFS Destroy ausprobiert die ich finden konnte, keiner ging aber.

Problem 1: Destroy Snaphots
Problem 2: Erstellen eines ZFS Snapshots + die Änderungen so das ich diesen übers LAN an den neuen Server sende. Dann kann die Zufuhr der Daten stoppen und nach der letzten Replizierung den neuen in Betrieb nehmen.

Danke

Gruß Mario
 

Attachments

  • ZFS.JPG
    ZFS.JPG
    104 KB · Views: 255

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
Das stimmt da aber bei normalen Kopiervorgang müssen die Daten ja wieder reduped werden und das kostet CPU und I/O. Und da auch noch Compression eingeschaltet wird hat die CPU alle Hände voll zu tun.
So werden aus 4 TB geduped schon mal 30TB und mehr zum Transfer.

Der alle Server ist ein Pentium mit 3Ghz und 8GB Ram, SSD für Freenas und 8x1TB LSI Raid Kontroller für die Nutzdaten.
Der neue ist ein Xeon 3440 mit 24GB RAM, auch SSD für Freenas und 8x 2TB an LSI Kontroller + 120GB SSD als ZFS Cache. Ich denke das sollte genug Leistung sein.

Anbei mal die Snapshots + die Fehlermeldung die kommt wenn man den löschen will.
Ich habe alle ZFS Destroy ausprobiert die ich finden konnte, keiner ging aber.

Problem 1: Destroy Snaphots
Problem 2: Erstellen eines ZFS Snapshots + die Änderungen so das ich diesen übers LAN an den neuen Server sende. Dann kann die Zufuhr der Daten stoppen und nach der letzten Replizierung den neuen in Betrieb nehmen.

Danke

Gruß Mario

Ach so, 4TB nach dedup.

Jetzt die sehr schlechte Nachricht: Dedup braucht sehr, sehr, sehr viel RAM. Typisch sind mindestens 5GB RAM pro TB speicher, ohne maximum. Es ist schon mal ein Wunder, dass alles hier halbwegs funktioniert.

Ich würde folgendes versuchen:

  • Mehr RAM, besonders im alten Server einbauen. Der neue wird für dedup auch mehr brauchen.
  • Alte Festplatten am neuen Server anschließen und von dort versuchen, Replication zu benutzen.
  • Wenn Replication nicht funktioniert, "per hand" kopieren.
  • Dedup vermeiden - meistens sorgt es nur für Probleme (Dedup wird fast nie benutzt, also kennen wenige die Details, die später für Probleme sorgen). Mit 8GB RAM ist das absoluter Masochismus. 24GB RAM is besser, aber wahrscheinlich noch nicht genug.
 

Semmelbrosel

Dabbler
Joined
Jul 5, 2013
Messages
12
Das habe ich auch gelesen, muss aber sagen der alte Server läuft schon ein paar Tage und hatte nie Probleme, auch mit 4GB nicht.
Mehr Ram geht nicht beide Boards können nicht mehr.
Den Festplattenumbau hatte ich auch schon im Auge Problem ich muss ja den Raidkontroller umstecken aber die Kabel sind keine 50cm lang. Ausserdem würden dann beide ZFS Volumes und Datasets gleich lauten. Darf das sein?
Die Replikation geht ja, aber er würde jetzt 4 Snapshots übertragen und das kann man vergessen, das dauert dann Wochen.
Dedup kann ich nicht ausschalten, da als Jail ein Backupsystem läuft das darauf angewiesen ist das geduped wird.

Werde hat in den sauern Apfel beißen müssen, und mich mal an ixsystems wenden die werden schon kein vermögen für Support verlangen.

Gruß Mario
 

Semmelbrosel

Dabbler
Joined
Jul 5, 2013
Messages
12
So hier die Lösung für Problem 1

zfs list -t snapshot
zfs holds -r Data/UrBackup@auto-20141105.0000-2w -> der Tag ist wichtig den braucht man nun
zfs release -r freenas:repl Data/UrBackup@auto-20141105.0000-2w

Und nun sind alle Snapshot gelöscht :smile:
 
Status
Not open for further replies.
Top