rpcpool.solana_rpc

Solana RPC Rolle

Eine Ansible-Rolle zum Bereitstellen eines Solana RPC-Knotens. Diese konfiguriert die Validator-Software im RPC-Modus, die unter dem Benutzer solana läuft. Der RPC-Dienst wird als Benutzerdienst unter demselben Benutzer installiert.

Updates

16/02 - Ab Solana 1.8.15 (Mainnet) und 1.9.6 (Testnet) müssen Sie solana_full_rpc_api: true angeben, damit diese Rolle tatsächlich einen vollständig offenen RPC-API-Knoten erstellt.

Hardware-Anforderungen

Ein RPC-Server benötigt mindestens dieselben Spezifikationen wie ein Solana-Validator, hat aber typischerweise höhere Anforderungen. Insbesondere empfehlen wir die Verwendung von 256 GB RAM, um Indizes zu speichern. Für weitere Informationen zu den Hardware-Anforderungen siehe https://docs.solana.com/running-validator/validator-reqs. Wir empfehlen dringend, einen Bare-Metal-Anbieter (nicht Hetzner) zu verwenden, es sei denn, Sie wissen, was Sie tun (und wenn ja, warum lesen Sie dann diese Seite?).

Vor der Bereitstellung sollten Sie den Host vorbereiten, damit das Verzeichnis, das Sie für Ihre Kontodatenbank und Ihren Ledger-Standort verwenden, korrekt konfiguriert ist. Dies kann die Einrichtung eines tmpfs-Ordners für Konten und eines separaten Dateisystems (idealerweise auf einer NVME-Festplatte) für den Ledger umfassen. Eine gängige Konfiguration könnte so aussehen:

/solana/tmpfs - eine 100-GB-tmpfs-Partition zur Speicherung des Kontostands
/solana/ledger - eine 2-TB-NVME-Festplatte zur Speicherung des Ledgers

Warum Bare Metal und nicht Cloud?

Cloud-Server (AWS, GCP usw.) sind aus mehreren Gründen generell ungeeignet für Solana:

Egress ist sehr teuer und Solana benötigt viel Egress.
Die Kernleistung ist im Allgemeinen zu gering und kann sich nicht so steigern wie Bare Metal.
Viele Cloud-Anbieter möchten nicht die Art von Arbeitslast, die Solana auf ihren kostengünstigen Instanzen erzeugt, was Sie dazu führt, sehr teure Bare-Metal-Instanzen zu nutzen.

Warum nicht Hetzner?

Hetzner hat entschieden, dass sie keine Solana RPC-Dienste in ihrem Netzwerk haben möchten. Sie blockieren aktiv Verbindungen zu Solana-Einstiegspunkten und drosseln den Solana-Verkehr. Ihr Solana-Knoten wird nicht in der Lage sein, mit dem Netzwerk Schritt zu halten (im Mainnet wird er wahrscheinlich nie aufholen), und Hetzner wird auch sehr wahrscheinlich Ihr Konto schließen.

Software-Anforderungen

Ansible >= 2.7 (hauptsächlich auf Ansible 2.8 getestet)
Ubuntu 18.04+ auf dem Ziel-Bereitstellungsrechner

Diese Rolle setzt ein gewisses Maß an Vertrautheit mit dem Bereitstellungsprozess der Solana-Validator-Software voraus.

Rollenvariablen

Die Bereitstellung stellt sicher, dass die Prüfziffer für die Version des heruntergeladenen solana-installers mit der in vars/main.yml angegebenen übereinstimmt. Falls Sie eine nicht dort aufgeführte Solana-Version installieren möchten, ist es gut, dass Sie zuerst das Skript solana-install-init.sh (https://raw.githubusercontent.com/solana-labs/solana/master/install/solana-install-init.sh) herunterladen und die sha256-Prüfziffer überprüfen.

Es gibt eine große Anzahl konfigurierbarer Parameter für Solana. Viele davon haben funktionale Standardwerte und Sie können diese Rolle verwenden, um einen Solana RPC-Knoten bereitzustellen, ohne die Standardwerte zu ändern. Wenn Sie diese Rolle ohne die Angabe von Parametern ausführen, wird ein Standard-RPC-Knoten für das mainnet konfiguriert.

Grundlegende Variablen

Dies sind die grundlegenden Variablen, die die Einrichtung der Validatoren konfigurieren. Sie haben Standardwerte, aber Sie möchten sie wahrscheinlich basierend auf Ihrer Einrichtung anpassen.

Name	Standardwert	Beschreibung
`solana_version`	stabil	Die zu installierende Solana-Version.
`solana_full_rpc_api`	`true`	Ob die vollständige RPC-API aktiviert werden soll oder nicht. Dies ist in der Regel der gewünschte Zustand.
`solana_root`	/solana	Hauptverzeichnis für das Solana-Ledger und die Konten
`solana_ledger_location`	/solana/ledger	Speicherort für das Solana-Ledger (sollte auf NVME sein)
`solana_accounts_location`	/solana/ledger/accounts	Speicherort für Informationen zu Solana-Konten. Wenn Sie tmpfs für Konten verwenden, sollte dies ein Unterverzeichnis Ihres tmpfs-Mount-Punkts sein (z.B. `/solana/tmpfs/accounts`, falls tmpfs auf `/solana/tmpfs` gemountet ist)
`solana_snapshots_location`		Speicherort für Solana-Snapshots. Kann nützlich sein, um ihn von Ihrem Ledger zu trennen.
`solana_keypairs`	`[]`	Liste der Schlüsselpaare, die auf den Validator-Knoten kopiert werden sollen. Jeder Eintrag in der Liste sollte einen `key` und einen `name`-Eintrag haben. Dies erstellt `/home/solana/<name>.json`, der den Wert von `key` enthält.
`solana_generate_keypair`	true	Ob ein Schlüssel-Paar generiert werden soll oder nicht. Wenn Sie `solana_keypairs` nicht angegeben haben und dies auf true setzen, wird ein neuer Schlüssel generiert und in `/home/solana/identity.json` platziert.
`solana_public_key`	`/home/solana/identity.json`	Speicherort der Identität des Validator-Knotens.
`solana_network`	mainnet	Das Solana-Netzwerk, dem dieser Knoten angehören soll.
`solana_environment`	siehe defaults/main.yml	Umgebungsvariablen, die für den Validator-Knoten angegeben werden sollen, insbesondere `RUST_LOG`.
`solana_enabled_services`	`[ solana-rpc ]`	Liste der Dienste, die beim Booten automatisch gestartet werden.
`solana_disabled_services`	`[ ]`	Liste der Dienste, die als deaktiviert gesetzt werden sollen.

Ports

Die folgenden Ports müssen für Ihren RPC-Server konfiguriert werden.

Name	Standardwert	Beschreibung
`solana_gossip_port`	8001	Port für Gossip-Verkehr (muss öffentlich sowohl für TCP als auch für UDP geöffnet sein)
`solana_rpc_port`	8899 (+8900)	Ports für eingehende RPC (und Websocket). Dies ist normalerweise nur auf localhost geöffnet. Platzieren Sie einen Proxy wie `haproxy` vor diesen Port(s) und exponieren Sie sie nicht öffentlich.
`solana_rpc_bind_address`	127.0.0.1	Adresse, an die RPC gebunden werden soll. Dies sollte normalerweise localhost sein. Platzieren Sie einen Proxy wie `haproxy` davor, um den öffentlichen Verkehr zu akzeptieren.
`solana_dynamic_port_range`	8002-8020	Port für eingehenden Solana-Verkehr. Möglicherweise muss dieser öffentlich für UDP im Firewall geöffnet werden.

Von dieser Liste können Sie sehen, dass Sie mindestens 8001-8020 in Ihrer Firewall für eingehenden Verkehr im Standardfall öffnen müssen.

Es könnte möglich sein, die TPU- und TPU-Forward-Ports für pure RPC-Knoten zu schließen. Diese Ports werden dynamisch zugewiesen und Sie können sie sehen, indem Sie Ihren Knoten in solana gossip betrachten. Wenn Sie sie firewallen möchten, können Sie dieses Tool verwenden: https://github.com/rpcpool/tpu-traffic-classifier. Mit diesem Tool können Sie eingehenden TPU- und TPU-Forward-Verkehr auf einem lokalen Knoten blockieren, indem Sie Folgendes ausführen:

./tpu-traffic-classifier -config-file config.yml -our-localhost -tpu-policy DROP -fwd-policy DROP -update=false

Setzen Sie dies in einen SystemD-Dienst und Sie können es beim Booten des Knotens starten und kontinuierlich laufen lassen.

Netzwerkspezifische Variablen

Die Standardwerte für diese Variablen sind in vars/{{ solana_network }}-default.yml angegeben (z.B. vars/mainnet-default.yml). Sie können auch Ihre eigenen angeben, indem Sie die Datei {{ solana_network }}.yml bereitstellen. Sie müssen alle diese Variablen angeben, es sei denn, Sie verlassen sich auf die Standardwerte.

Name	Standardwert	Beschreibung
`solana_network`	mainnet	Das Solana-Netzwerk, dem dieser Knoten beitreten soll.
`solana_metrics_config`	siehe vars/mainnet-default.yml	Der Metriken-Endpunkt
`solana_genesis_hash`	siehe vars/mainnet-default.yml	Der Genesis-Hash für dieses Netzwerk
`solana_entrypoints`	siehe vars/mainnet-default.yml	Einstiegspunkt-Hosts
`solana_known_validators`	siehe vars/mainnet-default.yml	Bekannte Validatoren, von denen bei Start Snapshots und Genesis-Bin abgerufen werden sollen
`solana_expected_bank_hash`	siehe vars/mainnet-default.yml	Erwarteter Bank-Hash
`solana_expected_shred_version`	siehe vars/mainnet-default.yml	Erwartete Shred-Version
`solana_index_exclude_keys`	siehe vars/mainnet-default.yml	Schlüssel, die aus Indizes aus Leistungsgründen ausgeschlossen werden sollen

RPC-spezifische Variablen

Name	Standardwert	Beschreibung
`solana_rpc_faucet_address`		Geben Sie eine RPC-Faucet-Adresse an
`solana_rpc_history`	true	Ob historische Werte über RPC bereitgestellt werden sollen
`solana_account_index`	program-id spl-token-owner spl-token-mint	Welche Indizes aktiviert werden sollen. Diese verbessern die Leistung erheblich, verlangsamen jedoch die Startzeit und können die Speicheranforderungen erhöhen.

Leistungsvariablen

Diese Variablen können Sie anpassen, um die Leistung zu verbessern.

Name	Standardwert	Beschreibung
`solana_snapshot_compression`		Ob Snapshots komprimiert werden sollen oder nicht. Geben Sie "none" an, um die Leistung zu verbessern.
`solana_snapshot_interval_slots`		Wie oft Snapshots erstellt werden sollen. Erhöhen, um die Leistung zu verbessern. Vorgeschlagener Wert ist 500.
`solana_pubsub_max_connections`	1000	Maximale Anzahl der zulässigen PubSub-Verbindungen.
`solana_bpf_jit`		Ob BPF JIT aktiviert werden soll. Standardmäßig aktiviert für Devnet.
`solana_banking_threads`	16	Anzahl der Banking-Threads.
`solana_rpc_threads`		Anzahl der RPC-Threads (maximale Threads/Kerne im System standardmäßig)
`solana_limit_ledger_size`	`solana default, 250 mio`	Größe des lokalen Ledgers zum Speichern. Für ein volles Epocheneinrichten, einen Wert zwischen 350 Millionen und 500 Millionen festlegen. Um die beste Leistung zu erzielen, setzen Sie auf 50 (minimaler Wert).
`solana_accounts_db_caching`		Ob das Caching der Kontodatenbank aktiviert werden soll.
`solana_accounts_shrink_path`		Sie möchten möglicherweise einen anderen Speicherort für den Schrumpfprozess der Konten angeben.

Bigtable

Sie können die Google Bigtable-Konto-Anmeldeinformationen zum Abfragen von Blöcken angeben, die nicht im lokalen Ledger vorhanden sind.

Name	Standardwert	Beschreibung
`solana_bigtable_enabled`	false	Bigtable-Zugriff aktivieren
`solana_bigtable_upload_enabled`	false	Bigtable-Upload aktivieren (die unten angegebenen Anmeldeinformationen benötigen Schreibzugriff)
`solana_bigtable_project_id`		Bigtable-Projekt-ID
`solana_bigtable_private_key_id`		Bigtable-Private-Key-ID
`solana_bigtable_private_key`		Bigtable-Privater Schlüssel
`solana_bigtable_client_email`		Bigtable-Client-E-Mail
`solana_bigtable_client_id`		Bigtable-Client-ID
`solana_bigtable_client_x509_cert_url`		Bigtable-Zertifikats-URL

Für weitere Informationen zu Bigtable siehe https://github.com/solana-labs/solana-bigtable .

Umgang mit Forks

Gelegentlich werden Devnet/Testnet Forks erleben. In diesen Fällen verwenden Sie die folgenden Parameter wie im Discord-Anweisungen beschrieben:

Name	Standardwert	Beschreibung
`solana_hard_fork`		Hard Fork
`solana_wait_for_supermajority`		Ob der Knoten auf die Supermehrheit warten soll oder nicht

CPU-Gouverneur & Sysctl-Einstellungen

Es gibt bestimmte Konfigurationen, die Sie vornehmen müssen, um Ihren RPC-Knoten ordnungsgemäß auszuführen. Diese Rolle kann Ihnen helfen, einige dieser Standardkonfigurationsänderungen vorzunehmen. Eine vollständige Optimierung hängt jedoch stark von Ihrer Hardware ab, sodass Sie sich Zeit nehmen sollten, um herauszufinden, wie Sie Ihre Hardware richtig konfigurieren.

Das wichtigste Element der Optimierung ist jedoch die CPU-Performance-Governance. Dies steuert das Boost-Verhalten und die Energieversorgung. Auf vielen Hosts in Rechenzentren sind sie für einen Ausgleich zwischen Leistung und Energieverbrauch konfiguriert. Im Falle von Solana müssen sie wirklich schnell arbeiten. Um den CPU-Gouverneur des Servers einzustellen, gibt es drei Optionen:

Sie haben Zugang zum BIOS und stellen die BIOS-CPU-Einstellung auf max performance ein. Dies scheint gut für HPE-Systeme zu funktionieren. Geben Sie in diesem Fall die Variable cpu_governor: bios an. Dies ist manchmal auch für AMD EPYC-Systeme erforderlich.
Sie haben Zugang zum BIOS und stellen die BIOS-CPU-Einstellung auf os control ein. Dies sollte die typischerweise standardmäßige Option sein. In diesem Fall können Sie die Variable cpu_governor als Standard belassen oder ausdrücklich auf cpu_governor: performance festlegen.
Sie haben keinen Zugriff auf BIOS oder CPU-Gouverneurseinstellungen. Falls möglich, versuchen Sie, cpu_governor: performance festzulegen. Andernfalls hat hoffentlich Ihr Anbieter dies für gute Leistung konfiguriert!

Die zweite Konfiguration, die Sie durchführen müssen, besteht darin, verschiedene Kernel-Parameter anzupassen, um den Solana RPC-Anwendungsfall anzupassen.

Eine Option besteht darin, solana-sys-tuner zusammen mit dieser Konfiguration bereitzustellen, um einige Variablen für Sie automatisch anzupassen.

Eine zweite Option, insbesondere wenn Sie neu im Tuning der Leistung sind, ist tuned und tune-adm von RedHat, wobei das Profil throughput-performance geeignet ist.

Schließlich können Sie, wenn Sie über diese Rolle bereitstellen, auch eine Liste von Sysctl-Werten für dieses Playbook angeben, um sie automatisch auf Ihrem Host einzurichten. Dies ermöglicht die vollständige Kontrolle und wird dauerhaft konfiguriert. Hier ist eine Liste von Sysctl-Werten, die wir bei rpcpool verwendet haben:

sysctl_optimisations:
  vm.max_map_count: 700000
  kernel.nmi_watchdog: 0
# Minimale Präemption-Granularität für CPU-gebundene Aufgaben:
# (Standard: 1 msec#  (1 + ilog(ncpus)), Einheiten: Nanosekunden)
  kernel.sched_min_granularity_ns: '10000000'
# SCHED_OTHER Wake-Up-Granularität.
# (Standard: 1 msec#  (1 + ilog(ncpus)), Einheiten: Nanosekunden)
  kernel.sched_wakeup_granularity_ns:  '15000000' 
  vm.swappiness: '30'
  kernel.hung_task_timeout_secs: 600
# das bedeutet, dass virtuelle Speicherstatistiken seltener erfasst werden, aber ein angemessener Kompromiss für niedrigere Latenz ist
  vm.stat_interval: 10
  vm.dirty_ratio: 40
  vm.dirty_background_ratio: 10
  vm.dirty_expire_centisecs: 36000
  vm.dirty_writeback_centisecs: 3000
  vm.dirtytime_expire_seconds: 43200
  kernel.timer_migration: 0
# Ein empfohlener Wert für pid_max ist 1024 * <# von CPU-Kernen/Threads im System>
  kernel.pid_max: 65536
  net.ipv4.tcp_fastopen: 3
# Von Solana Systuner
# Referenz: https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360
  net.core.rmem_max: 134217728
  net.core.rmem_default: 134217728
  net.core.wmem_max: 134217728
  net.core.wmem_default: 134217728

Beispiel-Playbooks

Mainnet-Knoten:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: mainnet }

Testnet-Knoten:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: testnet }

Devnet-Knoten:

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: devnet }

Starten des RPC-Knotens

Nach der Bereitstellung können Sie sich auf der Maschine anmelden und su -l solana ausführen, um der Solana-Benutzer zu werden.

Um die von Ihnen während der Bereitstellung generierte Solana-Validator-Befehlszeile zu sehen, können Sie einen Blick auf /home/solana/bin/solana-rpc.sh werfen. Denken Sie daran, dass Änderungen an dieser Datei das nächste Mal, wenn Sie diese Ansible ausführen, überschrieben werden.

Für den ersten Start sollten Sie --no-genesis-fetch und --no-snapshot-fetch in der Datei /home/solana/bin/solana-rpc.sh auskommentieren. Dies ermöglicht es Solana, die grundlegenden Dateien herunterzuladen, die es für den erstmaligen Start benötigt. Denken Sie daran, diese Zeilen wieder zu aktivieren, nachdem Sie den Validator zum ersten Mal gestartet haben.

Dann starten Sie den Solana-RPC-Prozess, indem Sie systemctl --user start solana-rpc ausführen. Sie können den Status des Prozesses überprüfen, indem Sie systemctl --user status solana-rpc ausführen. Der erste Start dauert einige Zeit. Sie können den Start überwachen, indem Sie solana catchup --our-localhost ausführen.

Schließlich, um die Protokolle für Ihren Solana RPC-Knoten anzuzeigen, führen Sie journalctl --user -u solana-rpc -f aus.

Wenn dies Ihr erstes Mal ist, dass Sie einen Solana-Knoten ausführen, finden Sie weitere Details zu dessen Betrieb unter https://docs.solana.com/running-validator/validator-start und https://github.com/agjell/sol-tutorials/.

Überprüfung des RPC-Knotens

Die grundlegende Überprüfung, nachdem Sie überprüft haben, dass der Knoten gestartet wurde, ist die Verfolgung des Catchup:

solana catchup --our-localhost

Danach können Sie überprüfen, ob er RPC-Anfragen korrekt bedient.

Testen des RPC-Zugangs

Sie können auch einige einfache Validierungsbefehle ausprobieren (danke an buffalu: https://gist.github.com/buffalu/db6458d4f6a0b70ac303027b61a636af):

curl http://localhost:8899 -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot", "params": [
      {
        "commitment": "processed"
      }
    ]}
'

curl http://localhost:8899  -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot"}
'

Testen des Websocket-Zugangs

Der einfachste Weg, Websockets zu testen, besteht darin, das Tool wscat zu installieren. Dazu müssen Sie NodeJS und NPM installieren und dann npm install wscat ausführen.

Sie können dann wie folgt eine Verbindung zu Ihrem Websocket herstellen:

wscat -c localhost:8900

Von dort aus erhalten Sie eine Eingabeaufforderung, in der Sie manuell Ihre Websocket-Abonnementanforderungen eingeben können:

> {"jsonrpc":"2.0", "id":1, "method":"slotSubscribe"}

Sie sollten nun regelmäßig Updates zu den Slots erhalten, während sie von Ihrem RPC-Knoten bestätigt werden.

RPC-Knoten fehlt/holt nicht auf

Das häufigste Leistungsproblem, mit dem ein RPC-Knoten konfrontiert sein kann, ist, dass er zurückbleibt und nicht in der Lage ist, aufzuholen.

Wenn es beim ersten Start nicht aufholen kann, liegt dies normalerweise an einer Fehlkonfiguration. Das häufigste Problem sind die Boost-Frequenzen Ihrer CPU (für weitere Details zur CPU-Konfiguration siehe oben):

Überprüfen Sie, ob Ihre CPU aktuell genug ist (alle Modelle < EPYC 2. Generation bei AMD oder < Cascade Lake bei Intel haben Schwierigkeiten).
Überprüfen Sie, ob Ihr CPU-Gouverneur nicht im Energiesparmodus im BIOS und in Ihren Kernel-Einstellungen konfiguriert ist.
Überwachen Sie die CPU-Frequenzen, während Sie Solana mit watch -n 1 grep MHz /proc/cpuinfo ausführen; Sie sollten in der Regel > 3 GHz auf allen Kernen benötigen (Faustregel). Sie wollen nie sehen, dass ein Kern auf 1,4-1,8 GHz zugeht.

Wenn es früher aufholen konnte, aber das nicht mehr kann (oder wenn das Beheben der CPU das Problem nicht gelöst hat):

Überprüfen Sie Speicher/CPU/Netzwerk - haben Sie gute CPU-Frequenzen, drosseln Sie in den Swap (nicht genügend Speicher) oder stellt Ihr Anbieter UDP-Pakete in der Drosselung ein?
- CPU: Beheben Sie die Einstellungen für Leistungsgouverneur/Boost, verwenden Sie einen aktuelleren CPU oder eine CPU mit besserem All-Core-Turbo (überprüfen Sie wikichip für Details). Denken Sie daran, dass MHz nicht über verschiedene Generationen hinweg vergleichbar sind. 3.0 GHz bei Broadwell ist nicht dasselbe wie 3.0 GHz bei Cascade Lake oder 3.0 GHz bei EPYC der 3. Generation.
- Netzwerk: Überprüfen Sie die Drosselung von UDP-Paketen und die Konnektivität. Sie benötigen mindestens eine Leitung von 500 Mbps ohne Drosselung bei UDP. Einige Anbieter blockieren gerne UDP oder drosseln es zu DDoS-Schutzmaßnahmen. Dies gilt sowohl für eingehende als auch für ausgehende Daten. Wenn Sie bei eingehenden Daten gedrosselt werden, erhält Ihr Knoten die Shreds nicht rechtzeitig vom Netzwerk. Überprüfen Sie Ihre Firewalls, dass Sie nicht ...
- Speicher: Besorgen Sie sich mehr RAM. Solana läuft nicht gerne im Swap-Speicher, also wenn Sie regelmäßig in den Swap gehen, müssen Sie das beheben. Eine vorübergehende Lösung kann sein, die Indizes spl-token-owner / spl-token-mint zu deaktivieren. Diese sind sehr groß gewachsen.
- Festplatte: Überprüfen Sie, ob Ihr NVME, das Ledger und/oder die Konten hält, nicht kaputt oder im Sterben ist. Ein einfacher dmesg oder SMART-Statusaufruf sollte Ihnen das sagen.
Es gibt einen Fehler, der besagt, dass der Knoten nach einem intensiven getBlocks-Aufruf über RPC dauerhaft zurückbleibt. Versuchen Sie, den Knoten neu zu starten. Wenn das hilft, könnte das Ihr Problem sein.
Haben Sie versucht, es auszustecken und wieder anzustecken? Manchmal kann es hilfreich sein, Ihr Ledger zu säubern und neu zu starten.
Überprüfen Sie Ihre Datenverkehrsmuster. Bestimmte RPC-Datenverkehrsmuster können Ihren Knoten einfach hinterherziehen. Vielleicht müssen Sie einen weiteren Knoten hinzufügen, um Ihren RPC-Verkehr zu splitten, oder Sie müssen Ihre Anfragen auf problematische Abfragen wie getProgramAccounts drosseln.

Zugriff auf historische Daten

Standardmäßig, wenn Sie den RPC-Knoten starten, beginnt dieser mit dem Aufbau seines lokalen Ledgers aus den Blöcken, die er über das Solana-Netzwerk erhält. Dieses lokale Ledger beginnt ab dem Punkt des Kontos-Snapshots, den Sie heruntergeladen haben, als Ihr Knoten gestartet ist. Wenn Sie --no-snapshot-fetch zu Ihrer solana-validator-Befehlszeile nicht hinzufügen, wird der Validator oft einen Snapshot vom Netzwerk beim Starten abrufen. Dies hinterlässt Löcher oder Lücken in Ihrem Ledger zwischen dem Zeitpunkt, an dem Sie Ihren RPC-Knoten gestoppt haben, und dem Zeitpunkt, an dem er den Konten-Snapshot heruntergeladen hat. Um dies zu vermeiden, geben Sie immer --no-snapshot-fetch nach dem ersten Mal, dass Sie den Knoten gestartet haben, an. Denken Sie daran, dass jedes Mal, wenn Sie einen Snapshot abrufen, Sie ein Loch im lokalen Ledger hinterlassen.

Die Größe des lokalen Ledgers wird durch den Parameter --limit-ledger-size festgelegt, der in Shreds gemessen wird. Ein Shred ist eine feste Dateneinheit. Die Umwandlung zwischen Shreds und Blöcken ist nicht festgelegt, da Blöcke variablen Größe haben können. Daher ist es sehr schwierig zu sagen, wie viel Geschichte in Bezug auf Zeit oder Anzahl der Blöcke Ihr Knoten speichern wird. Sie müssen es an Ihre Bedürfnisse anpassen. Ein guter Ausgangspunkt könnte 250-350 Millionen Shreds sein, was ungefähr ein Epoch bedecken sollte, was wiederum ungefähr 3 Tage bedeutet.

Die genaue Menge an Daten, die der RPC-Knoten speichern wird, hängt auch von den Parametern --enable-cpi-and-log-storage und --enable-rpc-transaction-history ab. Diese sind notwendig, damit der Knoten vollständige Block- und Transaktionsdaten speichern und bereitstellen kann.

Ihr Knoten kann nur Daten bereitstellen, die im lokalen Ledger gespeichert sind. Das bedeutet, dass Ihre Historie immer ab dem Punkt beginnt, an dem Sie den Knoten gestartet haben (tatsächlich: der Snapshot-Slot, mit dem Sie den Knoten gestartet haben). Wenn das Netzwerk sich derzeit im Slot N befindet und Sie einen Snapshot im Slot M gezogen haben, beginnt Ihr Knoten, seine Geschichte zwischen Slot M und Slot N neu aufzubauen. Das passiert während des catchup, der Knoten verarbeitet (wiederholt) alles, was zwischen M und N passiert ist, bis er mit dem Netzwerk aufholt und alle aktuellen eingehenden Daten verarbeiten kann.

Der Knoten kann (theoretisch) so viel Geschichte speichern, wie Sie auf Hochgeschwindigkeits-Speicher (z.B. wenn Sie --limit-ledger-size nicht angeben oder ihm einen riesigen Wert geben) passen. Allerdings kann dies nicht bis zum Genesis zurückskaliert werden. Um die gesamte Geschichte zu erhalten, können Sie die integrierte Unterstützung von Google BigTable nutzen. Sie können Ihren Knoten so konfigurieren, dass die Daten an eine Google BigTable-Instanz hochgeladen werden, wo sie dauerhaft für historische Abfragen verfügbar sein können. Sie können Ihren Knoten auch so konfigurieren, dass Abfragen an eine BigTable-Instanz unterstützt werden. In diesem Fall, für alle Abfragen, die der Knoten nicht in seinem lokalen Ledger hat, wird einer Anfrage an Google BigTable gesendet und wenn es dort gefunden wird, kann die Daten von da abgerufen werden.

Einige RPC-Anbieter und die Solana Foundation haben Kopien von BigTable, die bis zum Genesis zurückreichen. Für weitere Informationen dazu siehe https://github.com/solana-labs/solana-bigtable .

Indizes und Leistung: oder, warum ist mein RPC so langsam?

Es gibt drei Indizes, die der Solana-Validator generiert: program-id, spl-token-mint, spl-token-owner. Die letzten beiden werden verwendet, um Abfragen über getTokensByOwner, getTokenLargestAccounts oder über getTokensByDelegate zu unterstützen. Sie werden auch zur Unterstützung von Abfragen getProgramAccounts, die spezifische Filter verwenden, eingesetzt.

Diese Indizes sind sehr groß geworden. Wenn Sie diese Abfragen für Ihren RPC-Knoten nicht schnell benötigen, sollten Sie sie entfernen, da Sie den Speicherverbrauch Ihres Knotens erheblich reduzieren und die Startzeiten verbessern werden.

Wenn Sie diese RPC-Aufrufe BENÖTIGEN, müssen Sie die Indizes über das Konto-Index-Flag aktivieren, da ansonsten diese Aufrufe unerträglich langsam sein werden. Dies erfordert viel RAM - im Allgemeinen empfehlen wir nicht, diese mit weniger als 512 GB RAM bereitzustellen.

Eine Alternative dazu könnte die Verwendung von Geyser-Plugins sein, wie das Postgres-Plugin, das helfen kann, Abfragen zu beschleunigen, ohne sich auf In-Memory-Indizes zu verlassen: https://github.com/rpcpool/solana-geyser-park.

Sicherheitsbedenken

Sicherheit ist ein großes Feld und Sie können sich nicht auf einen kleinen Leitfaden in einem GitHub-Repo verlassen. Typischerweise sollten Sie sicherstellen, dass Ihr RPC-Server die Ports 8899 und 8900 nicht direkt ohne eine Art von Proxy und Zugangskontrolle exponiert. Eine einfache Möglichkeit, dies zu tun, ist die Verwendung von nginx oder HAproxy als Reverse-Proxy. Auf diese Weise können Sie SSL-Unterstützung und Authentifizierung über die integrierten Tools jedes dieser Systeme hinzufügen.

Um auf der sicheren Seite zu sein, können Sie sicherstellen, dass Ihre rpc-bind-Adresse auf 127.0.0.1 (dem Standard für diese Rolle) festgelegt ist, sodass sie nur auf lokale Anfragen reagiert.

Andere Playbooks

Normalerweise möchten Sie einen Reverse-Proxy vor dem Solana RPC bereitstellen. HAproxy ist eine großartige Option und wir haben ein Playbook zur Konfiguration von HAproxy für einen Solana RPC-Server hier.

Andere Leitfäden und Dokumente

Hier sind einige andere Leitfäden, Ressourcen und Dokumente, die über Solana RPC geschrieben wurden:

Wir übernehmen keine Verantwortung für die Genauigkeit oder Qualität irgendeiner dieser Dokumente. Bitte überprüfen Sie diese und entscheiden Sie selbst, welchen Dokumenten Sie folgen möchten.