Bestmöglicher Weg, um den Ethereum-Mainnet-Knoten auf AWS zu starten

Auf meinem lokalen System laufen mehrere Anwendungen. Ich möchte sie zum Leben erwecken, ich brauche meinen eigenen Ethereum-Hauptnetzknoten. Ich starte den Ethereum-Knoten auf dem AWS-Server im Überwachungsmodus, aber er funktioniert nicht so, wie ich denke. Kann jemand den richtigen, sicheren Weg vorschlagen, um den Knoten mit maximalem Durchsatz zu starten? Und was wird die beste Konfiguration des erforderlichen Servers sein?

Danke im Voraus

Antworten (2)

Folgendes verwende ich:

Einrichtung der AWS-Instanz Neue EC2-Instanz

  • Ubuntu Server 16.04 LTS (HVM), SSD-Volume-Typ – ami-10547475
  • t2.large: 2 vCPUs, 8 GB RAM
  • 250 GB (derzeit werden ca. 60gb verwendet)
  • nginx-Reverse-Proxy-Server: für SSL/https-Zugriff (für meine Site, die https ist)
  • tmux für Persistenz
  • Richten Sie die Parität als Daemon-Prozess ein

Ich verwende Parität anstelle von Geth. Parität synchronisiert schneller, ist innerhalb weniger Stunden nutzbar. Ich habe zuvor Geth verwendet, was Tage gedauert hat und bei der anfänglichen Synchronisierung häufig zu Fehlern führte. Parität ist für mich viel zuverlässiger. Ich hatte noch nie ein Problem beim Einrichten eines neuen Knotens/einer anfänglichen Synchronisierung.

Docker führte zu Verzögerungen : Ich habe auch einen Docker/Parity-Knoten erstellt, aber ich habe festgestellt, dass dies zu Verzögerungen führte. Es würde eine Verzögerung bei der Verbindung mit dem Knoten als Web3-Anbieter geben, was auch Ereignisbeobachter störte, die mit dem Knoten verbunden waren (d. h. Ereignisse wurden nicht erfasst; wenn der Knoten zurückfiel und aufholte, wurden die Ereignisse beim Aufholen nicht erfasst). von Ereignisbeobachtern erwischt).

Bisher läuft mein Setup ziemlich gut, aber meine App hat keine große Anzahl von Benutzern. Wir skalieren in den nächsten Monaten und werden daher ziemlich bald die Grenzen testen, wie viele Benutzer sich mit dem Knoten verbinden können. Wenn die Skalierbarkeit ein Problem darstellt, denke ich darüber nach, mehrere Knoten einzurichten und einen Load Balancer zu verwenden, falls dies jemals erforderlich sein sollte.

Halten Sie die neuen Ethereum-Vorlagen von Amazon für eine praktikable Option? Wir erwägen auch das Hosten eines Parity-Knotens zur Verwendung mit 0x.js, aber ich bin mir nicht sicher, ob wir mit den Vorlagen die gleiche Flexibilität erhalten wie mit unserem eigenen Knoten.
Wie sind Ihre Skalierbarkeitstests verlaufen? Wie viele Paritätsknoten haben Sie jetzt?
@wild_nothing Ich habe mich noch nicht allzu sehr mit den Vorlagen von Amazon befasst, aber das ist eine gute Idee, ich sollte mir das ansehen. Nachdem Sie also eine ganze Reihe von Knoten sowohl mit Parität/Geth als auch mit verschiedenen Anbietern (aws/google cloud/digital ocean) betrieben haben, einige Beobachtungen: (1) Die Hauptsache, die Knoten unzuverlässig macht, ist der Verlust von Peers/Verbindungen. Da alle ungefähr die gleichen Parameter haben (Min/Max-Peers), i) hat Geth im Allgemeinen weniger Peers und verliert ziemlich häufig alle, dh keine Verbindungen, ii) digitale Ozeanknoten scheinen im Allgemeinen immer mehr Peers als aws zu haben, und das Schlimmste ist Google Wolke.
(2) Knoten zu haben, die "zu nahe" sind (ich habe skalierbare, zustandsbehaftete Sätze in Kubernetes erstellt), verursacht ein Problem, das, wenn Ihre Knoten weiterhin miteinander verbunden sind, wenn einer von ihnen aus irgendeinem Grund schlechte Informationen hat, dies bringen kann alle diese Knoten herunterfahren -- andere Peers werden sie alle löschen (ich habe dies im Ropsten-Testnetz beobachtet, wo ich Testether auf allen Knoten abgebaut habe; sie landeten alle in einer Seitenkette und wurden gegabelt, was alle herunterbrach Knoten) (3) Knoten sind von Natur aus unzuverlässig. Daher ist es gut, Redundanzen und Backups zu haben.
Was das Beobachten von Ereignissen betrifft, so ist das Beobachten von Ereignissen in Echtzeit unzuverlässig; Der beste Weg, dies zu handhaben, besteht darin, Ereignisse ( contractInstance.getPastEvents()) über Intervalle abzuspielen. Und weitermachen, wo Sie aufgehört haben. Verfolgen Sie also bei der Wiedergabe den aktuellen Block, damit Sie beim nächsten Abruf vergangener Ereignisse fromauf den aktuellen Block der letzten Wiedergabe zurückgreifen können.
Vielen Dank. Klingt so, als ob es viel Overhead gibt, Ihre eigenen Knoten zu hosten. Es ist fast etwas, das ich als Failover bevorzugen und stattdessen einen Knotenanbieter verwenden würde. Solange dieser Knotenanbieter eine so reichhaltige API hat, wie ich selbst Parität erreichen würde.
Hallo @wild_nothing. Unser Unternehmen hatte genau den gleichen Denkprozess, nachdem es den größten Teil unserer Dev-Ops-Zeit damit verbracht hatte, unsere Knoten einzurichten und damit umzugehen, dass sie Kollegen verlieren. Wir wechselten zu Alchemy ( alchemyapi.io ), einem Ethereum-Knoteninfrastrukturdienst. Jetzt können wir unser Engineering-Team auf die Entwicklung unseres Produkts konzentrieren und nicht auf die Verwaltung unserer ETH-Knoten. FWIW: Sie bieten alle JSON-RPC-API-Aufrufe, die Sie hätten, wenn Sie Parity selbst ausführen würden.

Meine Konfigurationen und Erfahrungen:

  • Ubuntu Server 16.04 LTS (HVM), SSD-Volume-Typ.
  • 8+ GB RAM müssen unbedingt vorhanden sein. Gehen Sie nicht weniger oder Sie werden auf seltsame Probleme stoßen.
  • Der m5.large funktioniert gut. Verwenden Sie eine Instanz mit fester Leistung (z. B. M5, C5 und R5) und keine Burst-Leistungsinstanz (T2.* oder T3.*). Denn wenn Ihrer Instanz der Burst ausgeht, ist sie superlangsam. Ich habe dies bei anderen Anwendungen erlebt und es zerstört sie und es ist sehr schwer zu erkennen, was die periodische Langsamkeit verursacht. Nodes verbrauchen nicht viel CPU, also ist es vielleicht keine große Sache, aber wenn Sie sich für Produktionssoftware darauf verlassen, sollten Sie diese Möglichkeit für satte 2,30 US-Dollar mehr pro Monat entfernen (t2.large im Vergleich zu m5 .groß)
  • EBS Allzweck-SSD (gp2) ist sehr kostengünstig. Sie zahlen pro Monat für die Speicherung, sodass Sie nicht Hunderte von GB SSD-Speicherplatz zuweisen müssen, wenn Sie die Parität mit zu schnell eingestelltem Pruning verwenden. Sie können die Größe Ihres Volumes jederzeit erhöhen, aber Sie können es nicht bequem verringern. Meine Parity Nodes knacken im Moment noch nicht einmal die 40 GB Marke. Wenn Sie den Archivmodus verwenden, benötigen Sie Hunderte von GB.
Bestmöglicher Weg, um den Ethereum-Mainnet-Knoten auf AWS zu starten
AntwortenHierDatenschutz-Bestimmungen1y, 0v