Zum Hauptinhalt springen

2-Knoten-Trennung Installation (Data Lake / Anwendung)

Übersicht​

Installation der PlantPulse Plattform auf zwei Servern als Data Lake-Knoten und Anwendungsknoten. Im Gegensatz zur Single-Box(FULL)-Installation werden die Speicher-, Messaging- und Analyseschicht und die Console- und Batch-Schicht auf unterschiedlichen Servern ausgeführt. Dadurch beeinflussen umfangreiche Batch-Arbeiten (Archivierung usw.) nicht die Console-Reaktionsfähigkeit, und der Speicherbedarf pro Knoten wird reduziert.

Wann sollte dies verwendet werden? Geeignet, wenn ein einzelner Server mit 128GB RAM oder weniger verfügbar ist, oder wenn Sie die Verarbeitungslast von Daten und Console-Service trennen möchten, um die Stabilität zu erhöhen. Wenn ein einzelner Server ausreichend ist (empfohlen 256GB), verwenden Sie die Standard(FULL)-Installation unter One-Line-Installation.

Tier-Konzept (PP_TIER)​

Bei der Installation geben Sie die Rolle des Knotens mit der Umgebungsvariable PP_TIER an.

PP_TIERRolleStartende Services
FULL (Standard)Single-Box All-in-OneAlle (bei Nichtangabe identisch mit bestehender Installation)
DATALAKEData Lake-KnotenCassandra · PostgreSQL · Kafka · MQTT · Redis · MinIO · Spark · Hive · TSE · CEP · Data Gateway · Temporal · Kestra · Monitor usw. Infrastruktur-Schicht
APPAnwendungsknotenServer(Console 80/443) · Batch · Warehouse · OPC-UA · AASX · HA usw. Anwendungsschicht
  • PP_TIER ist unabhängig von der Clustering-Variable PP_MODE(MASTER/WORKER).
  • Alle Data Lake-Zugriffe des APP-Knotens (Host-Variablen) werden automatisch mit PP_MASTER_IP (IP des Data Lake-Knotens) verbunden.

Knotenbezogene Konfigurationsdateien (Kopielziele vs. Knotenbezogen)​

In der 2-Knoten-Installation haben die Dateien in /etc/kopens/ unterschiedliche Rollen. Was kopiert werden soll und was nicht, ist am wichtigsten.

Datei/VerzeichnisInhaltTypKnoten-übergreifend kopieren
/etc/kopens/plantpulse-platform.envService-Secrets-Sidecar (DB/Messaging-Passwörter usw.)Cluster-gemeinsam✅ Kopielziel
/etc/kopens/ca/Gemeinsame Cluster-CA (CA.crt/CA.key) — TLS-Vertrauen zwischen KnotenCluster-gemeinsam✅ Kopielziel
/etc/kopens/platform.node.envKnoten-Topologie (PP_TIER, PP_MASTER_IP) — bei Installation automatisch erfasstKnotenbezogene Identität❌ Nicht kopieren

Pfade überprüfen — Das Original des Secrets-Sidecars ist /etc/kopens/plantpulse-platform.env (Berechtigung 0600). In älteren Installationen kann unter /opt/kopens/ ein gleichnamiger Rest vorhanden sein, wird aber nicht gelesen, und das Installationsskript setzt es auf das Original zurück → Umgebungsvariablen-Referenz

  • platform.node.env wird bei der Installation von stack-run.sh automatisch erstellt und erfasst. Dank dieser Datei merkt sich der Knoten seinen Tier nach Neustart und Upgrade.
  • Der Grund, warum die Topologie (PP_TIER) in einer separaten Datei und nicht im Secrets-Sidecar gespeichert wird: Der Sidecar wird als Ganzes zum App-Knoten kopiert. Wenn die Tier-Information darin enthalten wäre, würde die Tier des Data Lake-Knotens zum App-Knoten durchsickern und dieser würde fälschlicherweise als DATALAKE installiert.

Anforderungen pro Knoten​

KnotenMindestanforderungAnmerkung
Data Lake16 vCPU / 64GB RAM / 500GB+ SpeicherFestplatte je nach Datenspeichermenge erweitern
Anwendung8 vCPU / 48GB RAM / 100GB SpeicherGemessener lokaler Verbrauch ca. 35GB

Die beiden Knoten müssen sich im gleichen Netzwerk erreichen können (Portliste siehe Firewall-Abschnitt unten).

Installationsverfahren​

Schritt 1 — Data Lake-Knoten installieren​

Führen Sie dies auf dem Server aus, der als Data Lake verwendet wird.

sudo -i
export PP_TIER=DATALAKE
curl -fsSL https://product.kopens.io/plantpulse-platform/install.sh | bash
  • Das Boot-Gateway erkennt den Tier automatisch. Der Data Lake-Knoten muss warten, bis der Monitor-Health (:4950/api/health) OK/WARN erreicht, und dann die vollständige Stack-Bereitschaftsprüfung (bin/stack-verify-boot.sh) bestehen, um die Installation als erfolgreich zu betrachten.
  • Nach Abschluss der Installation wird automatisch ein Join-Bundle generiert:
    • /etc/kopens/plantpulse-platform.env — Service-Secrets (Cluster-gemeinsam)
    • /etc/kopens/ca/ — Gemeinsame Cluster-CA (TLS-Vertrauen zwischen Knoten)

Der Data Lake-Knoten ist die CA-Ausstellungsstelle des Clusters. Der Anwendungsknoten empfängt diese CA und verwendet sie erneut, sodass TLS zwischen den Knoten (CEP-Ereigniskanal) automatisch vertraut wird.

Schritt 2 — Join-Bundle kopieren​

Kopieren Sie die zwei Einträge vom Data Lake-Knoten zum Anwendungsknoten.

# 데이터레이크 노드에서 실행 (<app-ip> = 애플리케이션 노드 IP)
scp /etc/kopens/plantpulse-platform.env root@<app-ip>:/etc/kopens/
scp -r /etc/kopens/ca root@<app-ip>:/etc/kopens/

Wichtig: Die Datei /etc/kopens/platform.node.env darf nicht kopiert werden. Diese Datei enthält die Tier-Identität des Knotens (seine Rolle) und ist eine knotenbezogene Datei. Kopielziele sind nur die obigen zwei Einträge (Knotenbezogene Konfigurationsdateien beachten).

Wenn auf einem älteren Server installiert wurde, kann unter platform.env.generated noch die Zeile export PP_TIER=... vorhanden sein. Das neueste Installationsskript entfernt es automatisch (Migration), aber es ist sicherer, die Zeile vor dem Kopieren zu löschen.

Schritt 3 — Anwendungsknoten installieren​

Führen Sie dies auf dem Anwendungsknoten aus. Geben Sie in PP_MASTER_IP die IP des Data Lake-Knotens an.

sudo -i
export PP_TIER=APP
export PP_MASTER_IP=<datalake-node-ip>
curl -fsSL https://product.kopens.io/plantpulse-platform/install.sh | bash
  • stack-run.sh wendet die gemeinsame CA (/etc/kopens/ca/) aus dem Join-Bundle vor dem ersten Start automatisch auf das Volume pp-security an (seed). Nachdem die Zertifikatsvorbereitung die Zertifikate dieses Knotens mit der gemeinsamen CA signiert und den truststore konfiguriert hat, werden TLS-Services des Data Lake-Knotens (CEP-Ereigniskanal usw.) automatisch vertraut.
  • Alle Data Lake-Backend-Zugriffe (Cassandra/PostgreSQL/Kafka/Redis/MinIO/TSE/CEP usw.) werden automatisch auf PP_MASTER_IP gesetzt.
  • Da der App-Knoten keinen Monitor (:4950) hat, führt das Boot-Gateway basierend auf die Console-Antwort (:80/status) 200 aus.

Firewall (Data Lake-Knoten)​

Der Data Lake-Knoten muss Zugriff vom Anwendungsknoten erlauben. Die einfachste Methode ist, die IP des Anwendungsknotens zur firewalld trusted zone hinzuzufügen.

# 데이터레이크 노드에서 실행
firewall-cmd --permanent --zone=trusted --add-source=<app-ip>
firewall-cmd --reload

Wichtigste knotenübergreifende Ports: 9042(Cassandra) · 5432(PostgreSQL) · 9092/9093/9094(Kafka) · 1883/1884(MQTT) · 6379(Redis) · 9000(MinIO) · 7077(Spark) · 9083(Hive) · 10000(Kyuubi) · 19001(Gravitino) · 7800/7801(TSE) · 7400(CEP) · 5500(Data Gateway) · 7233(Temporal) · 4950(Monitor)

Installationsbestätigung​

# 데이터레이크 노드 — 인프라 헬스 (OK 또는 WARN 이면 정상)
curl -kfsS https://127.0.0.1:4950/api/health | jq .status

# 애플리케이션 노드 — 콘솔 상태
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:80/status   # 200 이면 정상

Web-Console-Zugriff: https://<app-node-ip> — erfolgreiche Anmeldung ist erforderlich für die abschließende Bestätigung (Standardkonto siehe Anmeldung).

Knotenübergreifende TLS (gemeinsame CA) überprüfen​

Geben Sie die CA-Fingerabdrücke auf beiden Knoten aus und überprüfen Sie, ob diese identisch sind. Wenn die Fingerabdrücke unterschiedlich sind, ist das TLS-Vertrauen zwischen den Knoten unterbrochen.

Die CA-Materialien befinden sich im Volume pp-security, und werden innerhalb eines Container gelesen, der dieses Volume eingebunden hat. Der zu fragende Container unterscheidet sich pro Knoten — der Data Lake-Knoten hat plantpulse-datalake, der App-Knoten hat keinen.

# 데이터레이크 노드에서
docker exec plantpulse-datalake \
  openssl x509 -in /var/security/plantpulse/CA.crt -noout -fingerprint -sha256

# 애플리케이션 노드에서 (앱 컨테이너면 무엇이든 같은 볼륨을 읽습니다)
docker exec plantpulse-server-web \
  openssl x509 -in /var/security/plantpulse/CA.crt -noout -fingerprint -sha256

Überprüfen Sie, ob das Application-Knoten-Protokoll 0 TLS-Vertrauensfehler (PKIX) enthält.

# 애플리케이션 노드에서 — 아무 것도 출력되지 않아야 정상
grep -Rl "PKIX" /opt/kopens/plantpulse-platform-docker/logs 2>/dev/null

Data Lake-Verbindung überprüfen​

Um die Data Lake-Verbindung vom Anwendungsknoten zu überprüfen:

Der App-Container hat keinen Renderer-Konfiguration des Data Lakes und liest nicht dessen env.sh. Die Quelle der vom App gesehenen Werte ist nur die Compose, daher überprüfen Sie die tatsächlich dem Container eingespritzte Umgebungsvariable direkt.

# 애플리케이션 노드에서 — 백엔드 호스트가 데이터레이크 IP 로 잡혀 있는지
docker exec plantpulse-server-web env | grep -E '_HOST=|MASTER_IP='

Wenn der Wert 127.0.0.1 ist, wurde ohne PP_MASTER_IP installiert.

Verhalten bei Neustart und Upgrade​

  • Die Tier-Identität wird in der jeweiligen /etc/kopens/platform.node.env des Knotens gespeichert und bleibt nach Neustart und Upgrade erhalten. Es ist nicht erforderlich, PP_TIER erneut anzugeben, es sei denn, Sie führen eine Neuinstallation durch.
  • Ein Container-Image-Upgrade pro Knoten folgt den gleichen bestehenden Verfahren (update.sh) wie zuvor.

Vorsichtsmaßnahmen bei Tier-Wechsel und Neuinstallation​

  • Bei Neuinstallation als Single-Box(FULL) muss /etc/kopens/platform.node.env zuerst gelöscht werden. Wenn diese Datei verbleibt, wird die Umgebungskonfiguration automatisch die Datei gelesen und mit dem vorherigen Tier (DATALAKE/APP) gebootet. Die Installation mit PP_TIER nicht angegeben (FULL) überschreibt diese Datei nicht.

    rm -f /etc/kopens/platform.node.env

  • Um einen APP-Knoten zu FULL(Single-Box) zu wechseln, ist eine saubere Neuinstallation erforderlich. Der APP-Knoten hat keine lokal initialisierten Infrastruktur (Datenbankschema usw.), daher entfernen Sie alle Container, Volumes und Konfigurationen und installieren Sie dann von Anfang an FULL (siehe Entfernungsschritte im Abschnitt „Vollständige Entfernung" unter Docker-Installation).

Fehlerbehebung​

SymptomUrsache/Abhilfe
APP-Knoten-Service versucht Zugriff auf 127.0.0.1Installation ohne PP_MASTER_IP — node.env überprüfen und Neuinstallation durchführen
Nach Neuinstallation boot mit vorherigem Tier/etc/kopens/platform.node.env vorhanden — löschen und neu installieren (Vorsichtsmaßnahmen bei Tier-Wechsel und Neuinstallation)
App-Knoten wird als DATALAKE installiertAlte Sidecar mit restlicher PP_TIER Zeile wurde kopiert — diese Zeile aus Sidecar entfernen und neu installieren
CEP-Ereignis TLS-Fehler (PKIX)Fehlende ca/ Kopie aus Join-Bundle (CA-Fingerabdrücke unterschiedlich) — Schritt 2 wiederholen und APP-Knoten neu installieren
APP-Knoten Kafka-Veröffentlichung fehlgeschlagen (Expiring records)APP-Knoten nicht in Data Lake-Firewall erlaubt, oder altes Installationsskript — Firewall überprüfen und Neuinstallation mit aktuellem Skript durchführen
Fehler auf AnmeldungsbildschirmVerzögerung der Data Lake-Verbindung beim APP-Knoten-Boot — Console-Container neu starten (docker compose -f compose/docker-compose.yml restart plantpulse-server-web)