QTS und ZFS - richtige Blocksize

    Guten Morgen zusammen


    Ich habe ein NAS das ich mal auf QTS-Hero umgestellt habe um hoffentlich das 16TB Dateilimit von ext4 bei Qnap zu umgehen - in letzterem darf eine Datei im SMB share 16TB nicht überschreiten und da habe ich halt eine mit 32TB.


    Jetzt will QTS immer beim erstellen eines share die Blcksize wissen und da ist mir nciht ganz klar was ich nehmen sollte.


    Share 1: Backup einer Datenbank (260GB) und ca 1M kleinere Dateien zwischen 10kb und 6mb - die kleinen mit kleiner 1MB überwiegen - hier dachte ich eher 32kb als Blocksize!?

    Share 2: VM Backup (Altaro), das sind ja große Dateien - der default ist ja 128kb, aber wenn ich mich recht erinnere wird ja bei Veeam 64 oder 32kb empfohlen


    Danke

    Einmal editiert, zuletzt von blub ()

    Ich hab gerade mal auf Wiki nachgesehen und folgendes gefunden:

    Mod: Zitat ohne Quellenangabe ... gelöscht! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen


    da das Dateisystem bis zu 1024 PB groß werden darf, sehe ich keine Beschränkung auf 16TB?

    Da würde ich eher eine Einschränkung von CIFS annehmen, als von ext4


    Aus reiner Neugier, wie kommt man an eine 32TB große Datei? :/

    Jo, selbst QTS hat keine Beschränkung auf 16TB, es sei denn, man nutzt ein altes Cat1 NAS. Und auch dort können die meisten Modelle mehr als 16TB bei einer Neueinrichtung.

    Eine 32TB Datei? Das ist allerdings ziemlich ungewöhnlich.


    Gruss

    Zum Bearbeiten einer 32TB Datei braucht der Rechner auch den entsprechenden Arbeitsspeicher. Dies dürfte nicht bezahlbar sein, bzw. technisch nicht möglich.

    Ach hör auf... Das ist ein Witz wenn man bedenkt, dass die max. Dateigröße von ZFS 16EB ist :mcup:

    Gibt es auch ein NAS von QNAP dass dies kann ? :handbuch:

    Ist das ein Bqckup Container, der die Größe erreicht?

    Das ist sehr unpraktisch, denn bei einem Bitfehler muss die ganze Datei neu übertragen werden.


    Kann man das nicht in sagen wir mal 1TB oder 10/100G Dateien aufteilen, die lassen sich einfacher handhaben.

    Zitat von mad99

    Aus reiner Neugier, wie kommt man an eine 32TB große Datei?

    Zitat von Crazyhorse

    Ist das ein Bqckup Container, der die Größe erreicht?

    Ist ine VHDX einer VM, mit viiiiel Speicherbedarf, in unserem Fall der Betrieb eines PACS System wo Bilder gespeichert werden, altuell ca 180-200 Millionen.


    Wenn ich mich für eine VM um 32 einzelnde VHDx Dateien kümmern muss und bei 1TB pro Jahr 3 dazukämen würde es verdammt unübersichtlcih werden......


    Zitat von FSC830

    Jo, selbst QTS hat keine Beschränkung auf 16TB

    Das ist nicht korrekt, bzw muss differenziert werden, QTS verwendet ext4:

    Partition über 16TB - JA


    Einzelne Datei über 16TB: NEIN


    https://www.qnap.com/en/how-to…e-i-can-save-onto-the-qts (der Link wurde erstellt nach meiner Supportanfrage 2021 ;) )


    What are the file and file system size limitations for Red Hat Enterprise Linux? - Red Hat Customer Portal
    What are the file and file system size limitations for Red Hat Enterprise Linux? Are GFS2 file systems over 25 TB supported? Is it possible to use Ext3 for…
    access.redhat.com

    Zitat von Becker2020

    Zum Bearbeiten einer 32TB Datei braucht der Rechner auch den entsprechenden Arbeitsspeicher. Dies dürfte nicht bezahlbar sein, bzw. technisch nicht möglich.

    Ähh was?

    32TB bei PACS, das ja nix, die üblichen Archive Kisten lieben aktuell bei 96-128TB, doch selbst das reicht nicht für die komplette Vorhaltezeit bei dem aktuellen Zuwachsraten.


    Aber selbst mit 10GB dauert deine 32TB LUN bei etwa 4TB/h schon die ganze Nacht, wenn die weiter wächst rutscht du dann in den Tag rein.


    So 4TB LUNs stelle ich mir da ganz praktikabel vor, hast für jedes Jahr dann eine, das du die kompletten 20+ Jahre vorhalten willst glaube ich eh nicht, da wirst einen Archiv Anbieter für haben.


    Da es eine VHDX ist, kannst das mit dem RAM ignorieren, er ist davon ausgegangen, das es z.B. ein Video ist was man in einen Editor knallt um es zu schneiden oder zu vertonen. Aber das überlasse ich mal Linus und seiner Truppe.


    Aber vor allem stelle ich es mir schwer vor, eine 32TB Datei regelmäßig übers WAN weg zu schieben um eine Offsite Sicherung zu haben, bei GBit sind das um die 3 Tage.

    Jetzt komme mit nicht mit so einer Init7 Leitung, bei der ist aktuell vermutlich eher das LAN die Bremse.

    Ja, der RAM dürfte wohl nicht das Problem sein.


    Aber evtl. ist das unbekannte NAS doch eine Nummer zu klein für die große Aufgabe.

    Zitat von Crazyhorse

    32TB bei PACS, das ja nix, die üblichen Archive Kisten lieben aktuell bei 96-128TB, doch selbst das reicht nicht für die komplette Vorhaltezeit bei dem aktuellen Zuwachsraten.

    Die 32TB sind aktuell ca 10 Jahre, wir könnten also 20 Jahre locker abbilden ohne was auszulagern da wir nicht so "groß sind" - wenn ich an meinen alten Arbeitgeber denke der alles nach 3 Jahren ausgelagert hat und dann diese Altadten nicht mehr oder erst nach 3-5 Tagen wieder reinkamen wenn man sie "angefragt" hat ist dieses Auslagern ein Alptraum, das halte ich eher für Fluch als Segen - ich meine bei tiered storage, was sind schon 120TB?


    Man kann kleinere LUNs machen, klar, zumindest seitens der PACS Anbieter hiess es dass es sich nicht lohnt es klein zu machen wobei man die 64TB Grenze nicht ganz ausreizen sollte - Fakt ist dass wenn der HyperV crasht und man vom Backup wiederherstellen muss so oder so alles kopiert werden muss, ob das dann 10 x 4TB vhdx sind oder 1x 40TB ist da hinfällig - da man ja "boot from Backup hat" ist die Zeit für die wiederherstellung nicht so relevant


    Zitat von Crazyhorse

    Aber vor allem stelle ich es mir schwer vor, eine 32TB Datei regelmäßig übers WAN weg zu schieben um eine Offsite Sicherung zu haben, bei GBit sind das um die 3 Tage.

    Jetzt komme mit nicht mit so einer Init7 Leitung, bei der ist aktuell vermutlich eher das LAN die Bremse.

    Wenn ich 10 x 4TB vhdx habe muss initial so oder so alles kopiert werden, bei einem VM Backup wie wir es mit Veeam/Altaro es machen ist alles inkrementell, da wird auch nur am Anfang alles 1 Mal kopiert, da ist es doch vollkommen egal ob das 1 x 40TB oder 10 x 4 TB sind.... - dafür reicht aktuell unsere Glas 400/400 aus


    Fun Fact:

    Sowohl Veeam als auch Altaro benötigen für ein volles Backup 9-11 Tage mit einem 10GB Netzwerk - limitierend ist die Kompression und vor allem die Deduplication von Veeam/Altaro, die sind nicht so schnell...


    Zitat von Becker2020

    Aber evtl. ist das unbekannte NAS doch eine Nummer zu klein für die große Aufgabe.

    Das unbekannte NAS ist ein 873AU - das macht aber nix anderes als jede Nacht ein paar 100GB für unsere 8 VMs inkrementell entgegenzunehmen - für diese Aufgabe ist eigentlich kein NAS zu klein, wo siehst Du hier das Problem?


    Das einzige Problem war dass QTS mit ext4 die große VM nicht auf ein SMB share annehmen kann, das geht dann leider nur per iSCSI. Letzteres macht das Setup für VM Backups ein wenig komplexer da auch im Falle einer Widerherstellung das iSCSI extra eingebunden werden muss inkl. Zugriffrechte am NAS per IP usw - da ist es per SMB schon "schöner" und daher wollte ich auf QuTS HERO wechseln da es diese Limitation hier nicht gibt

    Einmal editiert, zuletzt von blub ()

    Zitat von blub

    Ist ine VHDX einer VM, mit viiiiel Speicherbedarf, in unserem Fall der Betrieb eines PACS System wo Bilder gespeichert werden, altuell ca 180-200 Millionen.

    Wäre es da nicht besser, man nimmt nur eine kleine VHDX, in der das Betriebssystem der VM liegt, nicht aber die Bilder des PACS-Systems? Die Bilder legt man stattdessen direkt auf SMB- oder NFS-Freigaben des NAS ab, welche von der VM gemounted werden.


    Das hätte den Vorteil, dass man nicht mit so einer riesigen Datei hantieren muss, und die Backup-Funktionen würden direkt auf der Ebene der Bilddateien arbeiten, wären also auch besser bedienbar.


    (Kann sein, dass ich völlig falsch liege. Ich kenne den technischen Hintergrund von euren PACS-Systemen nicht.)

    Zitat von Anthracite

    Wäre es da nicht besser, man nimmt nur eine kleine VHDX, in der das Betriebssystem der VM liegt, nicht aber die Bilder des PACS-Systems? Die Bilder legt man stattdessen direkt auf SMB- oder NFS-Freigaben des NAS ab, welche von der VM gemounted werden.

    Man kann das machen - das hat aber den eklatanten Nachteil das man auf BareMetal Ebene knapp 200 Millionen Dateien in größen zwischen 4kb-15mb dort rumliegen hat.

    Diese dann zu sichern/klonen oder nach X Jahren auf ein neue SAN zu kopieren ist ein absoluter Alptraum - schonmal 200M Dateien kopiert? - das Dauert Monate! Der Umzug vom alten Server damals dauerte ohne verifizierung schon 6 Wochen, bei meinem alten Arbeitgeber der ein größeres Archiv hatte dauerte der Umzug vom alten auf das neu SAN über 12 Monate (das war so zeitintensiv, auch in der Kontrolle, das es an ein externes Unternehmen ausgelagert wurde).


    Selbst ein inkrementelles Backup, also einmal kopieren und dann nur neue Dateien sichern ist ein Alptraum - da wird ja jedes Mal/abends die gesamte Ordnerstruktur nach neuen Dateien durchkämmt, alleine das dauert bei dieser Anzahl auf unseren SSD etwa 4-6 Stunden (wenn wir mal sehen wollen wieviele Dateien wir haben) - und dann stell die das mal auf drehendem Rost und mit Netzwerklatenz vor, da schaffts Du nicht mal 1 Backup pro Woche.... - und die ganze Zeit wenn das Läuft ist der Pool/San beschäftigt und die Latenz für die User geht den Bach runter


    Demgegenüber steht aktuell eine Kopiezeit von 10 Stunden für alles bei "nur" 10Gbs

    @blub

    Kann man es in eurem PACS System denn nicht hinbekommen, dass ihr die Archiv Daten / Voraufnahmen einfach auf ein SMB Share auslagert?


    Bei uns haben wir einen online und einen archiv Speicher für das Pacs System. Der Online Speicher hält die aktuellen Bilder und die dazu passenden Voruntersuchungen, die dann später / durch server getriggerte Prozesse geprefetched und vom Server dann aus dem Archiv geholt und ebenfalls in den Online Speicher gezogen werden. Das Archiv läuft auf einem ZFS Archiv mit 16 Platten und ist mit 10g angebunden. Der Online Storage liegt wie die Server in einer VMDK auf unserem DAS SSD Storagepool.


    Eine so große Backup Datei würde Mann glaube ich einfach nicht machen. Das Ganze fühlt sich irgendwie nicht korrekt und sinnvoll an.

    Für mich fühlt es sich so an als wenn eure Pacs Implementation nach dem vorhandenen Backup Muster eures System Designs gewählt wurde.
    Das kann man sicherlich alles machen... hat dann aber genau die Probleme die du beschreibst...

    JonnyRocket


    Klar kann man die abermillionen Einzeldateien auf ein SMB share legen, gehen tut das. Wie sichert Ihr das SMB share denn? - das wäre dann ja auf HW Ebene eine Kopier/Sync-Aktion von zig-millionen Dateien die alle sehr klein sind, so grob bei uns wären das 70 Millionen die man auslagern würde - das zu sichern, sagen wir mal von primären SMB auf ein zweites NAS dauert doch Wochen bis Monate. Auchein Sync alle X Tage würde sehr lange dauern da alle Ordner dann ja rekursiv verglichen werden müssten.


    Das letzte mal auf HW Ebene habe ich sowas vor 6-7 Jahren kopiert, das dauerte mit robocopy übers Netzwerk knapp 4 Wochen - wenn ich die Dateien in einem VHDX Container habe dauert das kopieren auf Hahrdwarebene keine 2 Tage, auch die täglichen backups incrementell sind nach 1 Stunde durch - ich sehe ein einer Speicherung von abermillionen Dateien auf einem SMB share keine Vorteile


    Das Problem mit der 16TB Grenze ist sicherlich bei ext4 gegeben, bei ReFS, ZFS und BTRFS nicht, auch bei NTFS nicht - ein so großer Nachteil ist das also nicht. Die Alternative wäre eben das Archiv in mehrere VHDX zu trennen, zb jede max 14TB - habe ich aber damals versäumt. Wurde vom PACS anbieter aber auch nicht empfohlen.