Storj - Speicher vermieten

[Frieseba]

Das successrate-Script zeigt mir, dass die Anzahl der Fehler sich nicht nennenswert gesteigert hat. Denke, dass liegt aber auch an der sehr guten Leitung, hinter der ich die Knoten betreibe.

 

[luddi]

Ich werde es bei mir nochmals verfolgen und euch auch meine Erfahrung mitteilen.

Was heißt "gute Leitung" ausgedrückt in Zahlen?

--luddi

 

[Frieseba]

Glasfaseranschluss in der Firma meines Bekannten.

 

[Heidi]

Erfahrung mit SMR Platten

Hallo zusammen,

ich betreibe 2 Knoten auf ähnlicher Hardware mit ähnlichem Netzwerk an unterschiedlichen IPs. Beide Knoten sind mit ca. 4TB gefüllt und laden täglich mehr drauf und haben auch kräftig upstream. Bei beiden herrscht ein Raidverbund vor. Der eine Knoten ist jedoch mit SMR Festplatten bestückt, der andere mit Standard CMR Platten.
Wer nicht auf Anhieb weiß, was SMR-Platten sind, der kann sich diesen kleinen Artikel durchlesen https://www.heise.de/newsticker/meldung/Manche-WD-Red-Festplatten-fuer-NAS-verursachen-Probleme-4703116.html.
Der beschreibt auch gleich schön das Problem was ich mit meinen Platten habe. Bei meinen handelt es sich nämlich um die in dem Artikel erwähnten WD red 6TB (WD60EFAX).
Diese SMR-Platten sind top beim Lagern von Daten (als Archiv z.B.) und sind im normalen Desktop betrieb ebenso gut geeignet.
Sie zeichnen sich dadurch aus, dass beim Schreiben von einem einzelnen bit eine ganze Spur von 256MB neu gelesen und geschrieben werden muss. Die Platte legt in der Zwischenzeit die auflaufenden Daten in einer SMR-Spur ab. Ist der User dann fertig mit seiner Datenwurschtelei, dann räumt die Platte in Ruhe auf und schreibt die Spuren neu.

Im Betrieb mit dem STORJ-Knoten werden aber ständig viele kleine Dateien geschrieben (und gelesen). Es gibt also kaum Leerlauf. Diese SMR-Festplatten sind also in der Theorie gänzlich ungeeignet für den Storj-Knoten (ebenso wie für den generellen NAS Betrieb meiner Meinung und der der Fachzeitschriften nach).

In der Praxis bedeutet das, das der Knoten nur ca. 1/3 bis 1/2 an Daten vom Referenzknoten abhandeln kann. Die Festplatte als Bottle neck also. Furchtbar! Im Raid1 Verbund war das noch einigermaßen denkbar, weil sich beim Lesen die Platten gegenseitig helfen und die Datenpaket parallel hochschaufeln. Aber spätestens als ich meinen Raid-Verbund aufgelöst habe, geht kaum noch was. Als ich dann noch nebenher den Speicherpool reparieren wollte und wieder auf eine (SMR-)Platte gespiegelt habe, war die DSM kaum noch benutzbar und die Paritätsberechnung war nach 4 Tagen bei stolzen 3% angekommen.

Der Synology Support bestätigt mir das und rät vom Einsatz dieser SMR-Platten im NAS generell ab. Leider gelten diese Platten laut Synology als Kompatibel und sind auch von WD für den NAS Einsatz als geeignet deklariert.

Damit (aber spätestens wegen der Heimlichtuerei) ist WesternDigital bei mir endgültig durch und ich setze ab sofort auf den Eisenwolf (und nehme den Mehrstromverbrauch in Kauf).

Ende und Gute Nacht.

 

[synfor]

Leider gelten diese Platten laut Synology als Kompatibel und sind auch von WD für den NAS Einsatz als geeignet deklariert.

Inzwischen nicht mehr.

https://www.synology.com/de-de/comp...ilter_feature=SMR&not_recommend_mode=true&p=1

 

[DKeppi]

Endlich wurde upgedated auf 1.3.3 und jetzt funktioniert auch der Held Amount und die Payout Info richtig.
Darkmode ist ebenfalls verfügbar...

 

[Flipper92]

Hallo zusammen,

Ich hab am 05.04.2020 mein Node in betrieb genommen.

Jetzt funktioniert es.

Gestartet hab ich mit 500GB und hab dies bis zum 27.04. auf 1TB erhöht, der auch schnell voll war.
Am 30.04. stand im Dashboard das ich irgendwas um die 1USD bekommen würde. Am 01.05. wurde alles auf 0 gesetzt (für den April). Ist es normal, das es im ersten angefangenem Monat nichts gibt?


Laut etherscan.io ist auch nichts eingegangen.

 

[luddi]

Das Payout Dashboard ist noch ziemlich neu. Die Funktionalität ist sehr rudimentär und wächst von Version zu Version.

Ausbezahlt wird definitiv, du kannst dich noch ein paar Tage gedulden dann wird dein Wallet klingeln.
Meine letzte Auszahlung war am 10.April für den vorherigen Monat März.

Um die Payout Infos für den vorherigen Monat einzusehen kannst du das earnings Skript aus der Konsole heraus verwenden.

python3 PFAD_ZUM_SKRIPT/earnings.py PFAD_ZU_STORAJENODE/data/ 2020-04

Hinten an stellt man Jahr/Monat in dem Format "YYYY-MM".

--luddi

 

[Frieseba]

Auch im Hinblick auf das Synology-Paket hat sich was getan. Dieses steht zum Download bereit. Kann zum jetzigen Stand aber nur von abraten.
a) ist es bislang nicht möglich ddns+Port zu setzen. Weder den Dyndns-Anbieter noch eine mögliche feste IP --> somit gerade nutzlos

b) sollte man das Paket nicht für einen zweiten Knoten auf der DS installieren! Nachdem ich das Paket deinstalliert hatte, war im Docker mein alter Knoten verschwunden. Über pull-Befehl konnte ich ihn dann wieder neu aufziehen.

 

[Frieseba]

Damit (aber spätestens wegen der Heimlichtuerei) ist WesternDigital bei mir endgültig durch und ich setze ab sofort auf den Eisenwolf (und nehme den Mehrstromverbrauch in Kauf).

Sind die Seagates alle nicht davon betroffen, oder muss man auch hier wieder auf bestimmte Platten achten? Und was ist mit Toshiba ?

 

[luddi]

Sind die Seagates alle nicht davon betroffen [...]

Seagate gibt seit kurzem die Informationen zumindest für die Ironwolf Serie auch bekannt. Hier sind alle Ironwolf mit CMR aufgeführt (siehe Spalte "Festplattentyp und Schnittstelle") auf deren Homepage.

Bei Toshiba habe ich selbst noch keine offizielle Bekanntgabe gefunden.

--luddi

 

[Peppi81]

Hi!

Kann es sein, dass das Storj-Netzwerk eine Störung hat?!

Ich betreibe 2 Nodes an verschiedenen Standorten. Beide haben seit 23:59:59 Uhr kein Traffic mehr! Auch sind keine logs seitdem aufgezeichnet worden.

Status zeigt "Online" an.

Oder sind Wartungsarbeiten bekannt?

MfG
Thomas

 

[luddi]

Bei mir ist heute morgen auch weniger als die Tage zuvor auf dem Knoten los, dass aber überhaupt kein Traffic bzw. logs seit Mitternacht vorhanden sind kann ich nicht bestätigen.

Ich habe mal einen Auzug des logs mit dem Status "downloaded" erstellt... Ist zwar echt wenig und der heutige Egress zeigt im Dashboard gerade einmal ca. 11 MB an.
Zudem gab es viele Einträge mit piecestore "deleted". Und zu guter letzt gab es auch einige "updloaded" Einträge im Log. Auch das erscheint mir plausibel, denn gestern waren auf meinem Knoten noch etwa 300 MB frei, heute sind 2,5 GB frei. Ingress gab es am heutigen Tag ca. 70 MB.

In welchem Zustand befinden sich deine Knoten? Sind sie noch im "Vetting" Status?
Mein Knoten befindet sich nur von einem Satelliten im Status "OK", alle anderen sind noch im "Vetting". Mein Knoten z.B. läuft erst seit Mitte März 2020.

Aber ich habe gerade einen Blick in die Ausgabe des earning Skripts geworfen wo auch der Status/Vetting angezeigt wird. Hier ist zu erkennen, dass der neue Satellit "europe-north-1.tardigrade.io" online gegangen ist. Bei diesem sehe ich aktuell "Vetting: 0%".

Auch ein nslookup auf den Satelliten gibt nun eine IP Adresse zurück und auch ein ping des Servers ist möglich, welches beides vor einigen Tagen (ende April) noch nicht der Fall war.
Der neue Satellit war ja schon seit längerem im Dahboard zu sehen und ist vermutlich heute Nacht tatsächlich online gegangen.

Und jetzt kommen wir wieder zurück auf das logfile, als ich erwähnt habe es gäbe auch einige "uploads" zu verzeichnen. Bei einem genauen Blick bzw. einem grep nach dem neuen Satelliten zeigt, dass dieser tatsächlich aktiv ist und mit dem Knoten kommuniziert.

Das wäre jetzt aus meiner Sicht eine plausible Erklärung auf deine Frage ob Wartungsarbeiten bekannt sind.

Du könntest ja selbst einmal in deinem Log nach dem neuen Satelliten suchen, evtl. findest du auch etwas.

docker logs storagenode 2>&1 | grep 12rfG3sh9NCWiX3ivPjq2HtdLmbqCrvHVEzJubnzFzosMuawymB

--luddi

 

[DKeppi]

Ich kann das auch nicht bestätigen, bei mir ist wie bisher Traffic auf allen Satelliten, sowohl ein- als auch ausgehend.
Auch auf dem neuen north-europe Satelliten tut sich einiges, mit dem der Node am 18.4. das erste Mal Kontakt hatte.

Hatte gestern insgesamt 7 GB Egress & 11 GB Ingress, heute sind es auch bereits 1 bzw 2 GB, im Mai gesamt schon 26 bzw. 57 GB !!!

 

[luddi]

Auch auf dem neuen north-europe Satelliten tut sich einiges, mit dem der Node am 18.4. das erste Mal Kontakt hatte.

Okay danke für diese Info. Ich vermute dass die Knoten nach und nach mit dem neuen Satelliten verbunden werden. Sieht zumindest sehr stark danach aus.

Da sich mein Knoten auch noch in der Vetting Phase befindet, liegen auf meinem Speicherplatz ohnehin mehr Test- als Nutzdaten. Und gerade kann ich beobachten dass fleißig von einem Satelliten Dateien gelöscht werden um wieder Platz zu schaffen damit der (für mich neue) Satellit europe-north auch mal mit meinem Knoten spielen darf

--luddi

 

[Frieseba]

Viel interessanter ist, dass laut deren Forum, der Saltlake augenscheinlich Probleme hat, hinsichtlich der Aufzeichnung der übertragenen Datenmengen. Gibt da zumindest die ersten Spekulationen, dass sich das sehr negaativ auf die Auszahlung auswirken kann. --> https://forum.storj.io/t/disk-space-used-this-month-dropped/6455/24

Nachrit von Storj: "We are aware of the issue and working on the fix with Salt Lake Satellite. It’s an accidental slowness in accounting of the used storage. It shouldn’t affect any actual earnings and should be resolved soon."

 

[Heidi]

auch bei mir weniger Traffic

Dann gebe ich auch mal meinen beruhigenden Senf dazu:

Auch bei mir (fertig gevetteter Knoten und im vetting befindlicher Knoten) ist deutlich (!) weniger Traffic. Kaum Ingress, und ca. 50% weniger Egress. Auch sehe ich im Log viele deletes. Mehr als uploads! "Beruhigender Senf" deshalb, weil ich doch schon sehr schockiert war, was grade abgeht. Da zweifelt man immer gleich an sich und seinem Knoten ;-)

Dann zu einem vorherigen Post: Da ich grade meine Terrabyte wild im NAS umhergeschleudert habe (Raidverbund umgewandelt, Volumes migrierte, Platten rein, Platten raus) und mehrmals mit dem Knoten umgezogen bin, ist mir ein Fauxpas passiert. Ich hatte den Knoten auf dem neuen Volume für ein paar Sekunden (!) laufen lassen. Dann gestoppt und geistes-ungegenwärtig den finalen rsync_Befehl zum migrieren MIT --delete flag gemacht. Als der Knoten dann wieder ans Netz ging (und neue Daten gesammelt hat) fehlen diese paar Sekunden an Daten nun für immer. Ich bekomme schon Albträume von Disqualification (und glaubt man dem Storj Forum, dann sind die nicht unbegründet). Vorsorglich habe ich einen 2. Knoten aufgesetzt, der auf derselben Maschine mit Minimal-Speicher läuft und so schon mal schön vor sich hin-vetten kann.
Ich kann nun bestätigen, dass die beiden Knoten sich stören. Am ersten Tag brachten beide soviel Ingress zusammen wie vorher der Originalknoten. Die IP-Filtering Datenpaketzuweisung von Storj arbeitet also zuverlässig und gibt mir deshalb nicht mehr Daten. Einen 2. Knoten zu öffnen bringt also nichts an Mehrwert. So wie schon überall zu hören ist. Aber aktuell wird das ja überlagert durch diese Turbulenzen. Ich beobachte weiter.

Ein Multi-Node bringet im Gegenteil die Scherereien, dass man mehrere Knoten up-to-date halten muss. Im Forum liest man zwar, wie der watchtower Befehl dazu aussehen muss, aber irgendwie klappt das bei mir nicht.
So sieht der Befehl bei mir aus:

sudo docker run -d --restart=always --name watchtower -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower storagenode storagenode3 watchtower --stop-timeout 300s --interval 21600

Hinten stehen in einer Liste einfach alle Container drin, die der watchtower updaten soll (inkl. sich selbst). Mach ich was falsch? Wer hat Erfahrung mit Multiple-Nodes?

so sieht das log aus. Achade. Ade Daten!

 

[luddi]

Hallo Heidi,

welchen watchtower verwendest du? Ich persönlich verwende diesen containrrr/watchtower und bei mir sieht der Befehl wie folgt aus ohne explizite Angabe eines zu überwachenden Containers. Er soll schlicht alle laufenden Container überwachen und im Falle aktualisieren. Dies geschah in der Vergangenheit auch reibungslos.

docker run -d \
  --restart always \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e TZ="Europe/Berlin" \
  containrrr/watchtower \
  --schedule "0 32 */3 * * *" \
  --cleanup \
  --debug

EDIT:
Hier die Doku falls man nur bestimmte Container überwachen oder ignorieren möchte.

Dann müsste man dieses Argument im Startbefehl übergeben:

--label=com.centurylinklabs.watchtower.enable=true someimage

und für ignorieren:

--label=com.centurylinklabs.watchtower.enable=false someimage

--luddi

 

[Heidi]

@Luddi: Ich verwende den offiziellen von Storj angepriesenen watchtower mit Abbildname: storjlabs/watchtower:latest. Ich werde jetzt erstmal das nächste Update abwarten. Vielleicht werden meine Knoten auch zu unterschiedlichen Zeiten angesprochen. Ich hatte dann neulich manuell upgedated. Der Druck der update-notifications war dann doch zu hoch...

 

[Heidi]

Ether-Givaway: Gießkanne

Jeder Storj-Neuling kennt das: Bezahlt wird in Storj-Token, mit denen nix anzufangen sind. Man muss die irgendwie tauschen oder ausgeben. Zum Senden oder Tauschen muss man aber die Transaction-Fee in Ether bezahlen. Diese bekommt man aber meist nur an einer Fiat-Börse, bei der man registriert sein muss. Dort wiederum gibt es Mindest-Einzahl-Beträge.
Ist also alles nix.

Ich möchte da ein bisschen Starthilfe bzw. Start-Ether geben und spende den ersten 20 Usern Start-Ether. Grade soviel, wie man braucht um seine erste Transaktion auszuführen. Das sind je nach Auslastung der Blockchain 2-10 cent. Wer Interesse hat, schickt mir am besten eine pn mit einer recipiant-Adresse.