Beiträge von Phylax

    Alle Disks, wenn man nicht manuell welche aus dem System RAID wirft, was ich nicht empfehlen würde.

    Warum würdest Du das nicht empfehlen? Würde das den Systembetrieb nicht schneller und energieeffizienter machen? (Link genügt)


    Bei nem RAID10 gibts immer nur eine Platte die bei dem Rebuild beteiligt ist und zwar die Spiegelpartner Platte .. fällt die aus, dann ist's das gewesen.

    Richtig, nur sind es ja bei 4 Platten, *zwei* Spiegelplatten, die beide ausfallen könnten.
    1 ←spiegel→ 3
    2 ←spiegel→ 4
    Ausfallen dürften 1+4, oder 3+2, nicht aber 1+3 oder 2+4. Richtig?
    Hinzu kommt eben die größere Toleranz gegenüber Lesefehler, so dass das Kriterium für »Ausfall« weniger streng ist als bei RAID6. So wengistens verstehe ich die Erklärung oben.

    Backups Backups Backups !

    Ist mir bewusst und habe auch eine Lösung dafür.

    Erstmal vielen Dank für die vielen schnellen Antworten!


    Mod: Unnötiges Volltext-/Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Sieht aus, als sei es möglich, aber doch ein ziemlicher Act. Außerdem geht es dort um ein Raid1. Ich bekomme jedenfalls angesichts Eurer Kommentare den Eindruck, dass diese Möglichkeit aus der Sicht erfahrenerer NAS-User wenig relevant ist… das allein sagt mir bereits etwas. Insofern sollte ich vielleicht nicht gleich alles anders machen wollen (ein wenig experimentieren kann ich für den Anfang auch, da ich mein bisheriges System, einen Raspberry Pi 4 nicht gleich offline nehmen werde.)

    Wenn bei nem RAID10 die Spiegelplatte ausfällt (bei nem Rebuild) dann sind die Daten trotzdem hin (Ausfall des Stripe)

    Bei nem RAID6 kann während des Rebuilds noch eine weiter Platte ausfallen und das Rebuild geht immer noch weiter

    Mein Verständnis ist, dass auch bei einem RAID10 bis zu zwei Platten ausfallen können, nur eben nicht beliebige zwei. Außerdem ist der Rebuild-Prozess einfacher und sehr viel toleranter gegenüber Lesefehlern. Die Hürde dafür, was einen »Ausfall« darstellt liegt also höher. Ausschlaggebend für meine einstweilige Bevorzugung von RAID10 gegenüber RAID6 war folgende Erläuterung:

    URE's will not kill a R10 array, it may kill a file or two but not the array. No more than it would kill an entire drive in a single drive scenario. The URE's are fatal to parity based arrays because during the rebuild the data is being reconstructed, using parity calculations, across the entire array. If a URE is encountered during the calculation it has the same effect as a syntax error in a script, the whole thing crashes. In the case of a RAID 10 rebuild the recovery is purely a copy function, from the surviving half of the mirror to the new drive.

    →Quelle


    Wenn das stimmt, scheint mir bei vier Platten RAID10 attraktiver – ähnliche Ausfallsicherheit, gleicher Kapazitätsverlust und performanter.




    Wenn Du einen Pool hast, wird das auch unabhängig vom RAID nicht möglich sein, QNAP braut bei Thin und Thick sein eigenes Süppchen.

    Wichtige Info, danke. Spricht denn grundsätzlich was dagegen, dann auf den HDDs nur ein großes Static Volume mir RAID1 oder 10 anzulegen? Gefühlsmäßig wäre mir die Transparenz der Daten doch wichtig.

    Warum RAID10 ? .. Ausfallsicherheit ist bei RAID6 besser

    Ausfallsicherheit ist geringfügig besser, ja, insofern nicht entscheidend ist, welche Platte als zweite ausfällt. Aber: meine Platten sind groß, insofern ist bei einem Rebuild Lesefehler nicht ganz unwahrscheinlich. Wenn ich recht verstehe, sin die die bei Rais 1 und 10 sehr viel weniger gefährlich, weil dabei nur die Integrität einzelner Sektoren/Dateien gefährdet ist, nicht gleich die des ganzen RAID.

    Außerdem sagt mir die Möglichkeit zu, dass die Platten ggf. einfach in einem Linux-System mounten zu können. Oder geht das nur bei RAID1?

    Bei nem Pool geht nur Thick oder Thin .. Static klappt da nicht

    Also gibt es keine Möglichkeit, die Größe eine Volumes zu begrenzen, das innerhalb eines Pools erzeugt wird? Ich nehme an, dass ein Static volume dann immer das ganze Raid umfassen muss… hm…

    Verstehe ich nicht.. Warum laufen die Volumen voll weil deine VM's gehackt werden ?

    Ein Angreifer bekommt nicht zwangsläufig die volle Kontrolle über die VM. Nehmen wir an, ich habe eine API laufen, die bestimmte Dinge herunterlädt, ein Angreifer verschafft sich irgendwie die Login Daten und und fängt nun an Junk herunterzuladen, dann könnte das Volume auf diese Weise volllaufen.

    Ist egal, Alle internen Platten haben SystemRAID's drauf und drehen sich immer mit

    Da habe ich eben verschiedene Aussagen zu gehört, u.a. dass dies nur für jene Platten gilt, die bereits der Installation vorhanden sind.

    Servus zusammen,


    seit heute stolzer Besitzer meines ersten NAS (TS-653D), kann ich es kaum erwarten, das Schmuckstück einzurichten. Da aber gerade die Pool- und Volumeeinteilung gut überlegt sein will, wollte ich meinen diesbezüglichen Plan hier einmal zur Diskussion stellen:


    1. Pool aus zwei 1TB-SSDs, Raid 1

    - Thick Volume für System und Apps

    - Static Volume (~400GB) für VMs

    2. Pool aus vier 16TB-HDDs, Raid 10

    - nur ein Volume geplant


    Konkret möchte ich zunächst nur die SSDs einschieben und das System darauf einrichten. Erst wenn das abgeschlossen ist, kommen die HHDs rein. Auf diese Weise hoffe ich zu verhindern, dass das System auf den HDDs landet und diese ständig in Atem hält. Zur Frage, ob das aufgeht, habe ich verschiedenes gehört.


    Für die VMs (geplant sind ausschließlich Linux-Server ohne grafische Oberfläche) dachte ich deshalb an ein static Volume, weil diese u.U. direkt am Internet hängen werden und ich verhindern möchte, dass sie am Ende aufgrund einer Sicherheitslücke volllaufen und dem System den Speicherplatz abgraben.


    Soweit mein Plan. Macht das grundsätzlich Sinn? Begehe ich hier Denkfehler?


    Viele Grüße!

    Um die Sache mit dem Webspace aber eventuell doch auszuschließen, wäre es ggf. gut, wenn Du mal von wo anders die Daten runterlädst.

    Ich halte das für gänzlich unwahrscheinlich, da ich bereits Downloads von zwei Webspaces/Rechenzentren, einer DSL 100/40er Leitung und einer 250/er Kabel-Leitung mit jeweils dem gleichen Ergebnis durchgeführt habe.

    Ich weiß nicht, was sind das für Testdaten? Wenn Du einfach ich sag mal 10 GB "Datenmüll" hättest, könntest Du mir Deine IP bzw. die URL zu den Daten per PN senden.

    Die IP ändert sich eh nach ein paar Stunden (daher nicht die DynDNS) und, wie gesagt, wenn die Daten einfach nur 10 G random sind, könnte ich Dir sagen, "wie schnell" ein Download geht.

    Ein weiterer Test kann nicht schaden. Habe dir eine PM mit Link auf ein Video geschickt – also realistische Daten. Wenn nötig, kann ich auch noch Zufallsdaten generieren. In jedem Fall danke!

    Aber dass schliesst ja nicht aus, dass der Anbieter die Upload-Geschwindigkeit begrenzt. Ich würde die Ursache durchaus da vermuten. Je billiger der "Webspace", desto wahrscheinlicher.

    Danke. Ich bin aber recht sicher, dass es daran nicht liegt, zudem es ja hier um die Download-Geschwindigkeit der Webspaces geht – die ist bei beiden enorm. Gerade deshalb nehme ich sie zum Testen. Zudem habe ich das Problem auch bei Zugriff mit dem Handy oder letztens aus dem Haus meines Vaters. Dass ich jedesmal an das gleiche Maximum stoße (250–300 kB/s) ist sicher kein Zufall.

    Servus und danke für die schnelle Antwort!

    Warum sollte 1) auch einen Unterschied machen?

    Ich hatte einen solchen Unterschied auch nicht erwartet, wollte damit nur einem oft gelesenen Ratschlag zuvorkommen (habe nämlich gefühlt das ganze Internet ausrecherchiert):


    Das Problem scheint also zu sein, dass Du maximal 300 kB/s pro TCP-Session "rausbekommst".

    Wäre ich Netzwerktechniker und nicht nur Webentwickler, hätte ich das vielleicht auch so auf den Punkt bringen können danke!

    Wie ist der Roundtrip von Deinem Webspace zu Deinem Pi?

    Hier ein paar ping-Zeiten von Uberspace:


    Code
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=56 time=17.1 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=2 ttl=56 time=18.3 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=3 ttl=56 time=17.1 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=56 time=17.8 ms
    64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=56 time=22.7 ms

    Netcup stellt `ping` nicht zur Verfügung. Dort bekomme ich aber die gleichen Übertragungswerte.


    Hast Du auf dem Pi irgendwelche Beschränkungen zur WindowSize?

    Habe das erst überlesen. Der Begriff ist mir auch neu, so dass ich erstmal recherchieren muss. Aber: sowohl auf meinem Pi4 als auch auf meinem Hauptrechner habe ich nur wenig an Apache geschraubt, so dass ich die Default-Werte für Ubuntu 20.04 bzw. 22.04 annehmen würde.


    Sodale, habe mich grade mal eingelesen und mit iperf folgendes feststellen können:

    Code
    iperf -c 192.168.178.51 --window 8M
    ------------------------------------------------------------
    Client connecting to 192.168.178.51, TCP port 5001
    TCP window size:  416 KByte (WARNING: requested 8.00 MByte)
    ------------------------------------------------------------
    [  3] local 192.168.178.5 port 58068 connected with 192.168.178.51 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.0 sec  1.08 GBytes   932 Mbits/sec

    Mein Pi gestattet also 416 Kbyte window size. Bisher habe ich das nur lokal testen können, da iperf auf meinen Webspaces nicht installiert ist.

    Servus Allerseits,


    zwar bin noch nicht stolzer Besitzer eines NAS, habe aber die Anschaffung eines QNAP TS-653D in die Wege geleitet. Auch dank dieses Forums habe ich mir davon ein gutes Bild machen können, danke dafür. Vorab würde ich allerdings gerne ein Netzwerkproblem lösen, das ich bei meinem derzeitigen Arme-Leute-NAS feststelle: einem Raspberry Pi4. Diesen betreibe ich als Heimserver hinter einer Fritzbox 7490, in erster Linie als Datenspeicher mit SMB und NextCloud; auch eine selbst geschriebene ClojureScript-API läuft darauf.


    Bei Remote-Zugriffen plagt mich derzeit eine besonders langsame Datenübertragung. Im Heimnetz läuft alles annähernd mit Gigabit-Geschwindigkeit – ich kann mit 80MB/s und mehr vom Pi-Server herunterladen.


    Die Remote-Problematik erkläre ich am besten anhand eines Beispiels, das mit möglichst wenig Schnickschnack wie Gateways, Verschlüsselung, VPN, etc. auskommt, nämlich dem Download einer großen Datei mittels HTTP, serviert vom Apachen. Dieser horcht auf Port 81, der von der Fritzbox weitergeleitet wird.


    Mache ich einen CLI-Speedtest auf dem Pi4, komme ich annähernd auf die zugesicherten Geschwindigkeiten meiner 100/40er DSL-Leitung. Konkret messe ich ca. 35Mbit im Upload (interessanterweise auch einen ähnlichen Wert im Download, aber der ist hier nicht maßgeblich.).


    Um den externen Download zu prüfen (aus Sicht meines Pi4 also ein Upload), logge ich mich per SSH auf einem meiner Webspaces ein (z.B. Netcup) und lade die Datei mit `wget mein.heimserver.net/grosse_datei.ext` herunter. Die Anbindung des Rechenzentrums sollte über jeden Zweifel erhaben sein – die magere Geschwindigkeit von 250–300 kB/s (≈2 Mbit) muss also irgendwie in der Fritzbox oder bei meinem Provider (NetCologne) entstehen.


    Interessant finde ich außerdem dreierlei:

    1. Ob ich meinen Server über die derzeitige IP, oder aber über DynDNS identifiziere, macht keinen Unterschied.
    2. Das Problem tritt genauso auf, wenn ich probeweise meinen Hauptrechner (Thinkpad 580) anstelle des Pi4 einsetze. Ich erwarte daher mit dem QNAP das gleiche Problem.
    3. Wenn ich von demselben oder einem anderen Webspace parallel weitere Download-Instanzen anwerfe, so verlaufen diese ebenfalls mit 250–300 kB/s. Auf dem Monitor meiner FritzBox kann ich dabei nachverfolgen, wie mit jeder zusätzlichen Instanz die Upload-Auslastung entsprechend steigt. Die Hardware meines Heimnetzes scheint also nicht der Flaschenhals zu sein.

    Ich kann mir darauf keinen rechten Reim machen… warum kann nicht schon ein einzelner Download annähernd den vollen Upload meiner Leitung ausnutzen? Kann es am Ende sein, dass der Provider die maximale Geschwindigkeit pro externem Request drosselt?


    Wenn jemandem dazu etwas einfiele, könnte ich der Installation des QNAP sehr viel gelassener ins Auge sehen! Vielen Dank!