StorJ - Dezentraler Wolken (Cloud) Speicher
Angeregt durch gammasterns post: https://steemit.com/storj/@gammastern/storj-dezentralen-cloudspeicher-verpachten habe ich mich diese Woche mal mit dem Dezentralen Cloud Storage Dienst StorJ (https://storj.io) beschäftigt.
Es geht prinzipiell darum, dass Daten dezentral bei Endnutzern wie Du und ich abgelegt werden können. Vergütet wird dann ca. einmal pro Monat für den genutzten (nicht für den bereitgestellten) Speicher. Teilnehmen kann man recht einfach man braucht nur:
- Eine permanente Internetverbindung mit fester IP oder DynDns namen
- Freien Plattenplatz (am besten in mehrere TB Dimension)
- Einen Rechner - pro StorJ Knoten eine CPU core
- Eine ETH Wallet
Aktuell bekommt man ca. 15$/6? pro TB und Monat (durch 6? weil die Daten jeweils auf 6? Knoten abgelegt werden, wer hier eine belastbare Quelle zur Vergütung hat bitte als Kommentar hinterlegen) - d.h. es kann sich rechnen (dauert aber...). Aber erstens muss die Platte dann auch genutzt werden, zweitens den Strom etc. nicht vergessen. Wenn man freien Platz hat - nur zu probiert es aus.
Zur Nutzung unter Windows kann entweder die StorJ GUI Application nutzen - oder aber einen CLI daemon. Zum kurzen Probieren empfehle ich die GUI (https://github.com/Storj/storjshare-gui/releases). Das sieht dann so aus:
Monitoren könnt Ihr das Ganze sehr einfach unter: https://storjstat.com Ihr müsst dort einen Account anlegen und Eure Node-ID registrieren. Das sieht dann so aus:
bzw das Dashboard so:
Ihr seht schon ich habe mittlerweile 6 Nodes laufen mit je 5TB als Kapazität. Um die Datenmengen, Datenzuwachs etc. zu monitoren solltet Ihr noch ein kleines Skript laufen lassen (https://github.com/calxibe/StorjMonitor). Dazu die Zip herrunterladen und die API ID dort eintragen und einfach als Batch laufen lassen.
In der CMD sieht das dann z.B. so aus:
Sollte eine Fehlermeldung ala "Invalid farmer data.." kommen so ist das normal, wenn der Node noch keine Daten bekommen hat. Das sollte sich nach Erhalt der ersten Shares ändern.
Für Fortgeschrittene bietet sich die CLI-Daemon Lösung an, welche ohne GUI auf der Kommandozeile arbeitet:
Diese Knoten habe ich gerade erst eingerichtet von daher ist noch nicht allzuviel an Daten da (außer dem 14.2GB Knoten den ich von der GUI übernommen habe). Eine sehr ausführliche Anleitung wie man den Daemon einrichtet findet Ihr unter https://docs.storj.io/docs/storj-share-daemon-cli.
Zum realen Ertrag kann ich noch nichts sagen - hierzu werde ich in ca. einem Monat nochmals etwas posten. Bis dahin viel Spaß beim Sharen Eurer dahindümpelnden Plattenkapa.
Nachtrag: Logfile troubleshooting könnte Ihr mittels http://ssdynamite.com/ machen.
Nachtrag 2 :): Traffic check kann mittels script erfolgen https://docs.storj.io/v1.1/docs/check-nodes-uploads-and-downloads-paid-and-unpaid
- Mirrors downloads - Shards that have been downloaded by other nodes (the transfer is not paid, but the storage is, it is included in the GB calculation), GB (or Bytes)
- Shards downloads - Shards downloaded by renters (paid transfer), GB (or Bytes)
- Shards uploads - Shards uploaded to your node(s) by the renter, the transfer is not paid but the storage is (included in GBh calculation), GB (or Bytes)
Das sieht dann so aus:
Da Nodes für CLI neu aufgesetzt, noch kein bezahlter Nutztraffic
Kurzer Nachtrag in Form eines Kommentars:
Ob und wann man Daten bekommt ist Netzlast/Nutzer (oder auch Renter genannt) abhängig (man führt hier keinCoin Mining mit konstanter Hasrate durch).
Wenn nun ein Renter etwas in die Cloud lädt fragt die Bridge (welche mit unseres Nodes verbunden ist) die Nodes ob man Kappa hätte.
Die Bridge schickt Mirrorrequests an 36 Nodes mit Responsetime <9000 und an 9 >9000. D.h. einen kleine Responsetime ist positive (wird über die letzten 1000 requests ermittelt).
Für Mirror Shards wird auch die Reputation herangezogen - es weden nodes mit Reputation nahe 5000 bevorzugt.
*Minimum 0, maximum 5000
In Summe Responsetime <9000 und Reputation >3000 ergibt die besten Werte in der Nutzung. Dahin zu kommen kann schon Wochen dauern und Bedarf einer fast 100% online Zeit.
Wobei die letzten Tage hier bei mir wirklich unterirdisch liefen. Fast nur noch 200 MB reingekommen und der traurige Höhepunkt, dann fast 12 MB in den letzten 24 Stunden. Fang langsam wieder an zu Fragen, ob irgend etwas nicht richtig funktioniert. ;)
Das ganze soll ja zufällig verteilt werden bzw. nur beeinflusst durch Responsetime und Reputation.
Bei mir ganz unterschiedliche Verteilung - die ersten 5 Knoten sind auf dem gleichen Rechner/Platte (via ISCSI) - aber ganz andere Ergebnisse. Der Knoten 5 könnte evtl. hängen weil er keine eigene CPU mehr bekommen hat (normalerweise kann man nur eine Node pro core starten).
Die Responsetime geht bei mir zumindest konstant nach unten, je mehr Anfragen desto schneller wird es die reale Laufzeit.
Vielleicht bin ich zu ungeduldig. Aber es fehlen halt einfach relevante Infos wie z.B. eben auch zurückgewiesene Anfragen. Bei deinen aktuellen Gains hätte ich mich wohl auch noch nicht beklagt. Aber kein Shard in 24h, ist doch ein wenig traurig.
Auf dem großen Node steckt die Reputation seit 3 Tagen fest, weder nach oben noch unten. Der andere ist vor ein paar Tagen angeblich ausgefallen und wurde auf 0 runter gezogen... während er gleichzeitig Shards weggespeichert hat. Mal sehen wie sich das die Tage über weiterentwickelt.
Die letzten Tage lief es auch nicht so gut. Mit Glück ein GB dazu gekommen, die Tage davor kam halt ordentlich etwas zusammen. Der GUI stehe ich inzwischen skeptisch gegenüber, da diese doch manchmal ein wenig rumspinnt.
Aktuell komme ich von außen nicht an einen Knoten ran, obwohl die GUI sagt, dass dieser einwandfrei läuft. Vor 3 Tagen war der andere Knoten offline und hat mir die Response Time und Reputation völlig zerhauen. Der Knoten war aber online und auch ansteuerbar. Irgend etwas liegt da im argen.
Der kleine Pi läuft bisher recht problemlos dagegen. Für den operationellen Betrieb, wird daher die CLI wesentlich besser sein.
Ja bei mir ähnlich - was mir auch nicht einleuchtet ist, dass gleicher Rechner, gleiche Platte... teils komplett unterschiedliche Delta Zeiten kamen. Via CLI sieht das Ganze bisher deutlich besser aus (allerdings erst einen halben Tag am laufen). Die Peeranzahl bleibt bei der CLI bisher auch deutlich höher. GUI ist mir immer relativ schnell auf <<100 eingebrochen. Aber noch ist es zu früh hier wirklich zu vergleichen.
Das eigentliche Problem ist in die hohe Intransparenz/geringe Nachvollziehbarkeit. Ich gehe mal davon aus, dass meine Walletadresse nicht gefüllt wird. Wenn es doch klappt sehe ich das mal positiv...
Ja, die Peer-Anzahl ist mir auch noch ein Rätsel. Teilweise sind diese auf 14 Clients runter gebrochen, während es gleichzeitig aber noch alles einwandfrei funktionierte und auch Shards reinkamen.
Das mit der Transparenz, kann ich so nur unterschreiben. Es ist unglaublich schwer einen Fehler zu erkennen. Bei den einzelnen Werten hat man schon so ziemlich alles gesehen ;)