Mein Docker Run Befehl sieht ähnlich aus:Ich habe das gleiche oder ein ähniches Problem:
sudo docker run -d --restart unless-stopped -p 28967:28967/tcp -p 28967:28967/udp -p :14002:14002 -e WALLET="xxxxx" -e EMAIL="xxxxx" -e ADDRESS="xxxxx:28967" -e BANDWIDTH="20TB" -e STORAGE="7.5TB" --mount type=bind,source="/volume1/docker/storj",destination=/app/identity --mount type=bind,source="/volume1/docker/storj/share",destination=/app/config --name storagenode storjlabs/storagenode:latest
docker run -d --restart unless-stopped --stop-timeout 300 -p 28967:28967/tcp -p 28967:28967/udp \
-p 14002:14002 \
-e WALLET="XXXXXX" \
-e EMAIL="XXXXXX" \
-e ADDRESS="XXXXXX:28967" \
-e STORAGE="15TB" \
--mount type=bind,source="/volume1/docker/storj/identity",destination=/app/identity \
--mount type=bind,source="/volume1/docker/storj/config",destination=/app/config \
--name storagenode storjlabs/storagenode:latest
docker run -d --restart unless-stopped --stop-timeout 300 \
-p 28967:28967/tcp \
-p 28967:28967/udp \
-p 14002:14002 \
-e WALLET="xxx" \
-e EMAIL="xxx" \
-e ADDRESS="xxx:28967" \
-e STORAGE="3000GB" \
--mount type=bind,source="/volume1/docker/storj/identity",destination=/app/identity \
--mount type=bind,source="/volume1/docker/storj/config",destination=/app/config \
--name storagenode storjlabs/storagenode:latest
Hab die Einstellungen in der Fritz nochmals neu eingegeben. Ändert nix. Lustig/Komisch ist, dass das Node auf dem Raspberry pi (hinter der gleichen Fritz) problemlos läuft und keinen Fehler anzeigt.hier funktioniert es aber mit dem Quic Status = OK. Bist du sicher, dass die Freigabe in der Fritz!Box hinhaut?
Ein Knoten benötigt nicht je eine eigene IP, aber jeder Dcoker Container bekommt automatisch eine eigene IP-Adresse.Da aber jeder Node ja eine eigene IP aus einem /24-Netz braucht....
Könntest du es genauer beschreiben wie du es gemacht hast pls ?Dyndns - und nichts anderes ist synology.me ja eigentlich, hat sich bei mir auch durchaus als etwas unzuverlässig herausgestellt.
Aber irgendwie hat mich das Projekt dann gepackt ))
Meine Lösung ist nun etwas komplizierter, sie funktioniert aber mittlerweile sehr zuverlässig:
Ich habe aktuell 20, bald 30 Nodes am laufen. 20 davon auf einem NAS, 10 auf einem anderen.
Alle Nodes haben ihren eigenen Port und laufen über ihren eigenen Docker-Container.
Da aber jeder Node ja eine eigene IP aus einem /24-Netz braucht, habe ich das mittels gemieteten VPS und einem dort jeweils installierten VPN-Server gelöst. Im Virtual-Maschine-Manager laufen jetzt 20 virtuelle Maschinen, die nichts anderes machen als eine VPN-Verbindung zu den VPS herzustellen und den Traffic über einen Proxy (Docker-Container) an meine Nodes zu verteilen
Aktuell ist ja ein enormer Peak beim Egress, also Upload von den Nodes. Meine Internetleitung ist durch meine Nodes aktuell komplett gesättigt, ich glaube hier ist mal Aufrüsten angesagt
Mein größtes Problem ist aktuell der Ärger mit meiner besseren Hälfte, wenn der Amazon-Bote wieder mit einer neuen Festplatte vor der Tür steht xD
Beste Grüße
Ein Knoten benötigt nicht je eine eigene IP, aber jeder Dcoker Container bekommt automatisch eine eigene IP-Adresse.
Es können mehrere Nodes auf einem Host laufen man muss die Container nur mit unterschiedlichen Ports konfigurieren auf denen sie lauschen und angesprochen werden können.
Als Beispiel...
Node #1 wird mit folgenden Parametern erstellt (gestartet)
docker run -d --restart unless-stopped \
-p 10021:28967/tcp \
-p 10021:28967/udp \
-p 14001:14002 \
-e ADDRESS="<SUB.MYDOMAIN.TLD>:10021" \
--name node1 storjlabs/storagenode:latest
Node #2 wird mit diesen Parametern erstellt (gestartet)
docker run -d --restart unless-stopped \
-p 10022:28967/tcp \
-p 10022:28967/udp \
-p 14002:14002 \
-e ADDRESS="<SUB.MYDOMAIN.TLD>:10022" \
--name node2 storjlabs/storagenode:latest
und das ganze kann dann bis auf n-Knoten erweitert werden.
docker run -d --restart unless-stopped \
-p 100xx:28967/tcp \
-p 100xx:28967/udp \
-p 140xx:14002 \
-e ADDRESS="<SUB.MYDOMAIN.TLD>:100xx" \
--name node[n] storjlabs/storagenode:latest
Somit laufen n Knoten auf einem Host die nur auf unterschiedliche Ports lauschen um von extern erreichbar zu sein (in diesem Beispiel blau markeirt).
Alle sind aber über die gleiche Domain erreichbar wie hier orange markiert.
Der grün markierte Port ist lediglich für das Webinterface der Statistik des jeweiligen Knoten von Nöten und ist nicht für die Kommunikation mit den Satelliten vorgesehen.
Die einzige Notwendigkeit ist es nun jeden dieser Ports für die Kommunikation nach Außen im Router auf diesen einen Host weiterzuleiten.
In diesem Bespiel müsste man lediglich folgende Ports (jeweils TCP und UDP) vom Router an den Host weiterleiten:
Deshalb kann ich den ganzen Aufwand deiner Konfiguration nicht nachvollziehen
- 10021
- 10022
- 100xx
"Verlangt" würde aber heißen dass dies zwingend vorgeschrieben ist. Funktioniert aber dennoch und es wird auch zugelassen.Aber das Storj-Netzwerk "verlangt" für jeden Node eine einzelne IP aus einem unterschiedlichen /24 IP-Netz.
Das kann ich sehr gut nachvollziehen.Ich möchte aber nartürlich so viel Traffic wie möglich, so als ob jeder Node unabhängig an einem anderen Anschluss laufen würde.
Daher habe ich das in Anführungszeichen gesetzt"Verlangt" würde aber heißen dass dies zwingend vorgeschrieben ist. Funktioniert aber dennoch und es wird auch zugelassen.
Wenn es wirklich vorgeschrieben wäre, dann könnten die Satelliten diejenigen Knoten sperren die an der gleichen physikalischen IP-Adresse angebunden sind, was sie aber nicht tun.
Ich habe mich tatsächlich im Rahmen von Skalierungsüberlegungen damit genauer auseinander gesetzt, meine Nodes ausführlich getrackt und konnte die Aussagen verifizieren.Das kann ich sehr gut nachvollziehen.
Und ich habe selbst noch nicht herausfinden können ob hier tatsächlich überprüft wird ob Knoten auf der gleichen IP-Adresse laufen.
Denn ich habe meine Knoten jeweils über eine eigene Subdomain erreichbar gemacht.
Jedenfalls kann ich mich über den Traffic meiner Knoten auch nicht beklagen. Ob es tatsächlich noch besser laufen würde wenn beide tatsächlich über eine eigene IP Adresse erreichbar wären ist leider aus meiner Sicht nicht zu beurteilen.
Wie sieht da das Kosten/Nutzen-Verhältnis aus? Könntest du da mal einen groben Abriss geben, was da an Kosten bei dir auflaufen? Lohnt sich das Ganze noch oder ist das nur wegen dem Spieltrieb bzw. der Machbarkeit?
Ich stimme dir auch hier zu, denn das ist die aktuelle Vorgehensweise im Betracht auf Dezentralisierung.Der Gesamttraffic (Download!) wird über /24-IP-Netze verteilt.
Wenn ich jetzt im Vergleich meine beiden Knoten heranziehe komme ich auf folgendes Ergebnis.Aktuell stelle ich dem Storj-Netzwerk gut 90TB zur Verfügung, wovon knapp 26TB belegt sind. Ich habe mit der Skalierung erst Anfang des Jahres begonnen. Mit den 26TB "verdiene" ich aktuell knapp 100 Dollar im Monat.
Genau so ist esIch stimme dir auch hier zu, denn das ist die aktuelle Vorgehensweise im Betracht auf Dezentralisierung.
Das Problem an dieser Stelle ist aber folgendes. Es wird nicht exakt die eine IP-Adresse deines ISP geprüft sondern ob die IP-Adressen der Nodes im gleichen Subnetz liegen sprich in der gleichen Region.
Das würde nämlich folgendes bedeuten... Wenn ich als User an meinem ISP Anschluss exakt einen Knoten betreibe und mein Nachbar (gleiche Geolocation und somit gleiches /24-Subnetz) auch einen Knoten an seinem Anschluss bem gleichen ISP betreibt dann teilen wir uns den Gesamttraffic obwohl jeder für sich berücksichtigt hätte nur einen einzigen Knoten an seinem Anschluss zu betreiben.
Das ist richtig, man muss darauf achten, dass man IPs aus unterschiedlichen /24-Netzen bekommt. Bei größeren Providern ist das aber eher die Regel aus die Ausnahme, aber klar, man muss das beachten.Im Betracht dessen, liegen alle VPS beim gleichen Provider und diese auch zufälligerweise im gleichen /24 Subnet, dann hast du damit wenig erreicht laut meinem Verständnis.
Hier muss ich widersprechen. Afaik gibt es bei Storj aktuell nichts was einer Art Reputation entspricht (und dafür spricht auch, dass alle Nodes in geographischer Nähe nahezu exakt den gleichen Traffic haben).Ein durchaus auch wichtiger Punkt für einen guten (bzw. hohen Traffic) ist nicht allein die geografische Isolierung durch unterschiedliche /24 Subnetze sondern auch eine hohe Reputation die man auch durch eine hohe Verfügbarkeit erreicht.
Definitiv. Ich bin ja das beste Beispiel. Meine Nodes sind alles andere als dezentralisiert, werden vom Storj-Netzwerk aber als dezentralisiert angesehen. Es ist immer nur ein Versuch der Annäherung.Sehr interessant ist dabei diese Diskussion zur IP Filterung im Bezug auf ein /24 Subnet: IP Filtering Clarification #2391
Solange die Filterung nicht explizit auf IP-Adresse angewandt wird, bleibt eben die grobe /24 Heuristik wenig brauchbar für eine echte Dezentralisierung der Daten.
Ja, da hast du Recht.Wenn ich jetzt im Vergleich meine beiden Knoten heranziehe komme ich auf folgendes Ergebnis.
Node #1--> 2.8/3.3TB
Node #2 --> 0.6/10TB
Summe: 3.4/13.3 TB
Somit sind aktuell gerade knapp 3.5 TB an effektiv an Daten in Summe verfügbar und erzeugen momentan einen Ertrag von 20$/mon.
Wenn ich nun einfach linear skaliere dann würde ich bei voll ausgelasteten Knoten hypothetisch auf etwa gut 75$/mon kommen.
Vergleicht man nun unsere beiden Setups kann man folgendes daraus ableiten.
26TB --> 100$/mon vs. 3.4TB --> 20$/mon welches einen Faktor der Daten von ca. 7.6 ausmacht. Rechnet man jetzt hoch (Vorsicht... alles lineare Milchmädchenrechnung ) würde mein Setup mit 26TB 140$/mon abwerfen... Was ich aber nicht erreichen würde weil mein Limit bei 13.3TB liegt Aber mein Ertragsfaktor pro TB liegt aktuell bei 5.8$ im Vergleich zu deinem bei 3.8$.
Man kann sich nämlich alles schön rechnen wenn man möchte...
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.