Umzug von 4Bay auf 6Bay QNAP?

  • Moin!


    Wenn ich von einem TS-453A z.B. auf ein TS-653A umziehen würde, könnte ich ja die vier Platten (RAID-5) einfach so in das neue NAS stecken und es würde so weiterlaufen wie bisher.


    Den Umstieg würde ich aber deswegen machen, um die Firmware und auch die VMs (die sind bisher auf einer externen USB-SSD) von den eigentlichen RAID-5 Daten zu trennen. Ich würde also gerne 4 Slots mit den bisherigen Platten bestücken und die beiden anderen Slots mit zwei SSD, wovon die eine die Firmware enthält (was für eine Größe müßte man da so ca. nehmen?) und die zweite die VMs enthält.


    Könnte man also die Firmware irgendwie von dem bisherigen RAID-5 "entfernen" und den Platz auch durch das RAID nutzen?


    Oder muß man den steinigen Weg gehen und alles von neuem installieren mit Rückspielen des Backups etc.?

  • Hi,

    ich habe in meinem NAS 2x500 GB SSDs im RAID 1 laufen, funktioniert wunderbar mit 3 VMs(2 kleine Linux und 1 Windows 10).


    Firmware umziehen sollte auch gehen, stand vor einiger Zeit auch hier, finde es aber leider gerade nicht.

  • Hi,


    also zuerst die gute Nachricht. Ja eine Migration ist problemlos möglich.


    https://www.qnap.com/de-de/nas-migration/


    Schon paar Tage älter aber beschreibt den Prozess ganz gut.

    http://docs.qnap.com/nas/4.1/SMB/de/system_migration.htm


    Was allerdings nicht geht ist das entfernen der Firmware von den Platten. Man kann zwar das "System" umziehen mit etwas aufwand, damit ist aber nut der Speicherplatz für zusätzliche Apps/Logs usw... gemeint und nicht das System an sich.


    Wie komme ich nun auf die Idee... Ich habe mit das QNAP schon vor einer Weile etwas genauer angesehen. Aufgefallen ist mir, dass wohl jede eingebaute Festplatte mit 5 Partitionen formatiert wird, zumindest bei den X86 (Intel/AMD) Kisten. Kann bei ARM durchaus anders sein, kann ich nicht beurteilen.


    Was ich gesehen habe ist, das über die erste Partition aller internen Platten im System (auch SSD, M2 auch wenn sie als Cache genutzt werden) ein RAID 1 gespannt wird und das dann als MD9 unter /mnt/HDA_ROOT gemountet ist. Hier scheit mir das System draufzuliegen.


    Daher ist es nicht möglich das System auf spezielle Platten zu verschieben, da es wohl auf allen Platten gespiegelt wird. Was natürlich natürlich dazu führt dass das nach auch bei vermeindlich ausgefallenem RAID noch starten kann und eine einfache Migration in andere Geräte ermöglich. Smart!


    Allerding hat es auch den Nachteil, dass natürlich, auch beim Einsatz von SSDs der Bootvorgang nicht beschläunigt wird. Aber es geht ja um ein NAS, das für den Dauerbetrieb ausgelegt ist. Da sind kurze Bootzeiten dann doch eher Nebensache.


    Ich hoffe ich konnte helfen.

  • Damit das System auf der SSD läuft, müsstest du mit der SSD anfangen und die als erstes Volumen anlegen. Damit wird automatisch das System (ein Teil davon) auf die SSD geschrieben. Danach kannst du die alten HDD's in gleicher Reihenfolge wie bisher einbauen und das (hoffentlich) wieder gefundene Volumen neu aktivieren.


    Für die SSD gibt es normalerweise einen bevorzugten Slot, entweder die beiden linken, oder die beiden rechten, das kannst du in der Anleitung raussuchen ...


    PS.: Ich würde trotzdem die beiden SSD's als RAID1 anlegen und sowohl das System, als auch die VM's darauf laufen lassen. Damit hast du noch die Sicherheit, falls mal eine ausfällt, oder du im Laufe der Zeit den Platz vergrößern willst.

  • RedDiabolo: Nein, bitte so nicht vorgehen! Die Migration muss in einem leeren Gehäuse stattfinden! Bitte mitdenken und den Leuten keine fatalen Tipps geben! Ansonsten hast du 2 Systeme in Deinem NAS dann kommt es zu Konflikten und Du zerschießt das ganze NAS oder den Storage!

  • Das Szenario, das hier beschrieben wird ist so nicht umsetzbar! Das System wird per RAID1 auf alle Platten gespiegelt. Das einzige was du beeinflussen kannst st das speichern der zusätzlichen Dateien die im ersten angelegten Volumen gespechert werden.


    Das einizge was getan werden kann in der Situation ist die HDDs zu migrieren und dann ein SSD-Volumen bauen um da die VMs abzulegen.


    Zuerst das SSD Volumen anzulegen, was ja bedeutet das System einzurichten, würde bedeuten, das du eine Systempartition auf den SSDs anlegst die sich von der Systempartition der danach zu migrierenden Platten unterscheidet. Das halte ich für ein hohes Risiko. Und ja, so wie es den anschein macht sind auch die Konfigurationsdateien auf md9 gespeichert da. /etc/config gealiast ist und von /mnt/HDA_ROOT/.config kommt. Also wennn das NAS dann heruntergefahren wird um die 4 Platten einzustecken und dann neu gesatrte ist haben wir die Situation mit zwei verschiedenen MD9 mit unterschiedlichen Inhalt, sprich konfigs und verschiedenen Superblöcken. Sorry IMHO sehr hohes Risiko.


    Und jetzt Du!

  • Also wennn das NAS dann heruntergefahren wird um die 4 Platten einzustecken und dann neu gesatrte ist haben wir die Situation mit zwei verschiedenen MD9

    Die NAS sind Hotswap fähig. Wenn die Platten im laufenden Betrieb eingesetzt werden kommt es nicht zu dem Problem.

  • Richtig, heist aber im umkehrschluß, dass die erste Partition der alten Platten in das neue RAID1 array gerebuilded werden und damit alle Konfigs dahin sind. Auch die des DatenRAIDs bzw. des LVM2 (die ind im MD9 gespichert) /etc/config/raidtab bzw raid.conf und /etc/config/lvm, wobei ich mir letzteres nicht genau angesehen habe. Da ich nicht davon ausgehe, dass genug Kenntnisse bestehen die PVS, VGS und LVs in die neue konfiguration per Hand, also per Shell zu migrieren, würde ich dringend abraten. Auch das probieren und selbst versuchen... Ruck Zuck macht man was kaputt. So wie ich das sehe ist der der LVM2 durch QNAP modfiziert. Sieht man selten, das die LVs in einem unterliegenden Thinpool liegen. muss wohl was mit der Storagearchitektur zu tun haben. Ich schätze das ermöglicht die Snapshotfähigkeit. Aber da kann ich mich auch irren.

  • dass die erste Partition der alten Platten in das neue RAID1 array gerebuilded werden

    Du solltest dich mal mit RAID beschäftigen. Seit wann werden neue und aktuelle Superblocks von älteren und korrupten überschrieben?

  • Habe ich so nicht geschrieben. Wo steht denn was von koruppten Superblocks? Die Inhalte des in dem moment aktiven MD9 werden auf die neu hinzugefügren Partitionen geschrieben. DAs geht by the way auch von alt nach neu. Kommt drauf an welches Array gerade aktiv ist.



    Ich habe nur gesagt, dass soblad ein MD9 aktiv ist (was im Fall eines vorab konfigurierten SSD Volumes ja der Fall ist)und du Platten mit der QNAP Partitionierung (5 Pratitionen) im Hot-Swap verfahren einschiebst wird die Partition der eingeschobenen Platte in das RAID1 Array hinzugefügt per rebuild.


    Schau, hier ist der Auszug eines Superblocks eines meiner Geräte des MD9


    Wie man hier sehr schön sehen kann erwartet das Array 32 Disks

    Code
    Raid Devices : 32

    Besteht aber momentan nur aus 12 Disks

    Code
    Total Devices : 12
    Code
    State : clean, degraded


    Also was passiert wenn hier eine neue Disk mit QNAP Paritionierung einlegt und das RAID degraded ist da ja 32 Platten erwartet werden? Richtig, das RAID verhält sich so wie es soll und macht einen Rebuild auf die neue Platte. Und dein alter MD9 ist dahin. Und so geht das dann mit jeder Platte die Du in das Gerät einschiebst die eine QNAP Partitionierung hat.


    Um hier nochmal einen gegenbeweis anzutreten der Superblock der DatenRAIDS.


    Die Superblock stammen aus dem selben Gerät, auch hier schön zu sehen, das die Daten RAIDS aus genau der Anzahl von Platten besteht, die hinzugefügt wurden.


    Code
    Raid Devices : 8  
    Total Devices : 8
    Code
    Active Devices : 2
    Working Devices : 2
    Code
    Active Devices : 2
    Working Devices : 2

    Anbei noch meine /proc/mdstat


    Ahh jetzt sehe ich was evtl. zu zu irritationen geführt hat.


    in das neue RAID1 array gerebuilded

    Sollte heissen: zu Rebuild herangezogen werden.


    Sorry war schon spät gestern.

  • Moin!


    Vielen Dank für Eure Beiträge!

    So wie ich das sehe würde es also im Hinblick auf die Firmware selber nichts bringen, da die immer auf allen Laufwerken liegt (gespiegelt). Für die VM würde es nur insofern etwas bringen, daß man mit der neuesten Version der Virtualization Station neue VM anlegen kann, da die SSD dann intern ist.

    Also ist das nicht wirklich sinnvoll. Na gut.


    Danke!

  • Ahh jetzt sehe ich was evtl. zu zu irritationen geführt hat.

    Genau das im Zusammenhang mit den nachfolgenden Sätzen.

    Wo steht denn was von koruppten Superblocks?

    Für das aktive RAID md9 (und das neue md9 ist aktiv, solange das NAS mit diesem gestartet wurde und läuft) ist jeder neu hinzukommende Member korrupt, wenn

    - die UUID nicht stimmt

    - das Erstellungsdatum/Zeit nicht stimmt

    - die Events sich unterscheiden

    - die Laufwerksparameter unterschiedlich sind

    - ...


    Es wird also in jedem Fall vom aktiven (neuen) System-RAID auf den neuen Member gesynct was ja gewollt ist.

    Schau, hier ist der Auszug eines Superblocks eines meiner Geräte des MD9

    Ich kenne den Aufbau der Partitionierung der QNAP-NAS besser als meine Westentasche.;)


    Und dein alter MD9 ist dahin.

    So soll es ja sein. Du willst ja, dass das System von den SSD startet und auf diesen das Systemvolume liegt.

  • So soll es ja sein. Du willst ja, dass das System von den SSD startet und auf diesen das Systemvolume liegt.

    Ja aber genau hier liegt ja die Krux! Er möchte ja das alte System migrieren nachdem der SSD Pool aufgebaut wurde! Und das geht nicht! Da wir ja sehen, das der MD9 der alten Platten zerstört wird. Somit sind alle configs und Einstellungen des Systems dahin. Der Storagepool kann nur mit manuellem Aufwand wieder online genommen werden. Daher ist das vorgehen, zuerst die SSDs zu migrieren kein Performanceschub da der MD9 ja auf allen Platten liegt sondern auch nch destruktiv da das Altsystem nicht migiert werden kann.


    Also Katastophe!

  • Wenn ich von einem TS-453A z.B. auf ein TS-653A umziehen würde, könnte ich ja die vier Platten (RAID-5) einfach so in das neue NAS stecken und es würde so weiterlaufen wie bisher.

    Erster Post, erster Satz! Klassische migration. Aber auch das importeren eines Pool ist mit einem zerschossenen MD9 nur manuell möglich mit Handarbeit auf der Shell. Wenn so vorgegangen wir wie beschrieben (erst SSD RAID, dann altes RAID rein und ich zitiere "und das (hoffentlich) wieder gefundene Volumen neu aktivieren") ist der nächste Schritt ein Supportticket! Daher mein wehementes einschreiten.

  • Aber auch das importeren eines Pool ist mit einem zerschossenen MD9 nur manuell möglich mit Handarbeit auf der Shell.

    Es gibt kein "zerschossenes md9". Würde ja bedeuten, dass das NAS nicht mehr funktioniert.

    Es gibt eine vollkommen intakte neue Konfiguration, der vier weitere Platten hinzugefügt werden. Über eine QNAP-Signatur auf den Platten erkennt das NAS, dass diese schonmal in einem QNAP waren.

    Wenn der RAID-Verbund dieser Platten beim Ausbau sauber war und das Filesystem keine Fehler hatte, kann man über die Funktion "Wiederherstellen" im Speichermanager das RAID mit den Volumen wieder einbinden.

  • Es gibt kein "zerschossenes md9".

    Doch der alte MD9 ist zerschossen und das Ziel nicht erreicht!

    Wenn ich von einem TS-453A z.B. auf ein TS-653A umziehen würde, könnte ich ja die vier Platten (RAID-5) einfach so in das neue NAS stecken und es würde so weiterlaufen wie bisher


    Sehr viele Wenns, und was machst Du wenn die Flex-Signatur verlohren geht, was bei solchen umzügen doch gerne mal passiert?


    Dann hätten wir ein nicht brauchbares Legacy-Volumen! Und wieder manuellen Aufwand.


    Sorry aber die Gefahr das bei so einer Nummer was schiefgeht ist viel zu hoch für einen Benutzer der nicht so viel Wissen über den Storage Stack hat. Daher kann ich nur noch mehr dazu raten die dokumentierte vorgehensweise zu Nutzen. Sonst ist der Frust sehr schnell sehr groß!

  • Du kommst beim Lesen im ersten Post auch nur bis zum ersten Satz und nicht weiter. Willst oder kannst du nicht verstehen, dass das was du gebetsmühlenartig immer wieder zitierst, genau das ist, was der TE gar nicht will?

    Der von dir ständig zitierte Satz ist das Standardvorgehen bei einer Migration zu einem anderen NAS. Das hat carsten_h so auch erkannt und erklärt in den folgenden Sätzen, warum er es so eben nicht will.

    Doch der alte MD9 ist zerschossen und das Ziel nicht erreicht!

    Doch, Ziel erreicht! Es gibt eine neue Konfiguration auf den alten Platten.

    Im Übrigen schreibt er auch, dass ein Backup vorhanden ist. Selbst im Falle, dass etwas schief geht, hätte er dann nur einen Umweg zum Ziel eingelegt.

    Dann hätten wir ein nicht brauchbares Legacy-Volumen!

    Hauptsache mal mit Fachbegriffen werfen. Wo soll denn das Legacy-Volumen herkommen, wenn gar kein NAS beteiligt war, was solche erstellt.

  • nur die Daten des alten Pools übernehmen, ohne Backup neu einzuspielen

    Das möchte er, genau! :)


    Es geht mir ja nur darum herauszufinden, ob es irgendwie Sinn ergibt auf ein 6Bay umzusteigen.

    Da es aber nicht möglich ist, die Firmware auf einem Laufwerk, die VM auf einem zweiten Laufwerk und das Raid-5 auf den restlichen vier laufen zu lassen, hat es sowieso keinen praktischen Nutzen.

    Vielen Dank für Eure Antworten, meine Fragen sind geklärt!