Installieren Sie SystemLink Enterprise mit Helm-Befehlen.

Bei der Installation von SystemLink Enterprise führen wir die Konfiguration in der Regel an drei primären Stellen durch:

  1. systemlink-values.yaml: Konfiguriert den größten Teil der Anwendung.
  2. systemLink-admin-values.yaml: Definiert globale Ressourcen im SystemLink Admin Helm Chart. Diese Ressourcen müssen von Helm installiert werden, bevor das SystemLink Helm Chart installiert werden kann.
  3. systemlink-secrets.yaml: Definiert Secrets in Helm. NI empfiehlt die Verwendung von sops zum Verschlüsseln der Datei oder der Secret-Werte in der Datei. Es ist optional, diese Datei zum Bereitstellen von Secrets zu verwenden. Wenn Sie mit dieser Datei keine Secrets bereitstellen möchten, setzen Sie global.deplySecrets in der systemlink-values.yaml auf false.

Erstellen von Namensräumen

Sie können Namensräume erstellen, um Ihren Cluster zu organisieren.

  • Erstellen Sie einen Namensraum für das SystemLink Helm-Chart:
    kubectl create namespace <namespace>
  • Erstellen Sie einen Namensraum für das SystemLink Admin Helm-Chart:
    kubectl create namespace <admin-namespace>

Vorbereiten von Zertifikaten

Konfigurieren Sie Zertifikate für die Transport Layer Security (TLS)-Kommunikation und Authentifizierung mit externen Ressourcen.

Hinweis SystemLink Enterprise-Endpunkte erfordern TLS. NI empfiehlt die Verwendung von TLS für die gesamte Kommunikation zwischen SystemLink Enterprise und externen Datenspeicher- und Identitätsanbietern. Erhalten Sie nur Zertifikate von vertrauenswürdigen Quellen.

Wenn Sie ein Zertifikat verwenden, um die Kommunikation mit Ihren PostgreSQL-Instanzen zu authentifizieren und zu verschlüsseln, lesen Sie PostgreSQL, um diese Zertifikate in Helm bereitzustellen und zu referenzieren.

Wenn Sie ein von einer privaten Zertifizierungsstelle signiertes Zertifikat für die SystemLink Enterprise Hostnamen, MongoDB oder S3 verwenden, lesen Sie Private Certificate Authorities, um diese Zertifikate in Helm bereitzustellen und zu referenzieren.

Installieren erforderlicher Cluster-Ressourcen

Installieren Sie die erforderlichen Ressourcen global auf dem Cluster.

Ein Benutzer mit den folgenden Berechtigungen muss die folgenden Schritte auf dem SystemLink Admin Helm-Chart ausführen:

  • Ein Cluster-Administrator mit vollen Zugriffsrechten
  • Ein Argo Workflows-Benutzer, der nur CustomResourceDefinition bereitstellt.
  • Ein Flink Operator-Benutzer, der ClusterRoles und ClusterRoleBindings bereitstellt. Der Flink Operator benötigt möglicherweise Berechtigungen zum Bereitstellen über mehrere Namespaces hinweg.

Weitere Informationen zu den für die Installation erforderlichen Kubernetes-Berechtigungen finden Sie unter Erforderliche Kubernetes-Berechtigungen.

SystemLink Admin Values-Datei herunterladen

Laden Sie eine Kopie von systemlink-admin-values.yaml herunter.

Wenn Sie Argo Workflows CRDs bereits als Teil einer anderen Bereitstellung installiert haben, setzen Sie argoworkflowscrds.crds.install auf false:
argoworkflowscrds:
  crds:
    install: false
Wenn Sie bereits Flink Operator in Ihrem Kubernetes-Cluster installiert haben, setzen Sie flinkoperator.enabled auf false:
flinkoperator:
  enabled: false

Voraussetzungen installieren

helm upgrade <admin-release> oci://downloads.artifacts.ni.com/ni-docker/ni/helm-charts/systemlinkadmin --install --version <version> --namespace <admin-namespace> --values systemlink-admin-values.yaml --values systemlink-values.yaml --values systemlink-secrets.yaml --wait --timeout 20m0s
Tabelle 8. Voraussetzungen für die Cluster-Installation
Parameter Beschreibung
admin-release Der Release-Name, der für die Installation des SystemLink Admin Helm-Charts verwendet wird.
downloads.artifacts.ni.com/ni-docker Die URL des Registrierungsdienstes. Wenn Sie mit einer lokalen Kopie arbeiten, ersetzen Sie diese URL durch die URL der Spiegel-Registry.
Version Die spezifische Version der Software, die installiert werden soll.
admin-namespace Der Namensraum, der für das SystemLink Admin Helm-Chart erstellt wurde.

Dieser Befehl wartet bis zum konfigurierten Timeout, bis die Installation abgeschlossen ist und alle Ressourcen in den Bereitschaftszustand übergehen. Die Standardeinstellung für den Timeout lautet 20 Minuten. Der Timeout ist konservativ berechnet; die tatsächliche Installationszeit kann jedoch aufgrund einer Vielzahl von Faktoren variieren. Passen Sie den Timeout bei Bedarf an.

Konfigurieren von SystemLink Enterprise

Vor der Installation von SystemLink Enterprise müssen Sie Ihre SystemLink-Wertedateien konfigurieren. Laden Sie die Vorlage für Konfigurationsdateien aus dem SystemLink Enterprise GitHub-Repository herunter, um zu beginnen.

Konfigurationsparameter für systemlink-values.yaml, systemlink-admin-values.yaml und systemlink-secrets.yaml sind in dieser Anleitung dokumentiert. Jedes Thema in dieser Anleitung verweist auf die spezifischen Helm-Werte, die für diesen Konfigurationsbereich gelten.

Konfigurieren einer Elasticsearch-Instanz

Konfigurieren Sie SystemLink Enterprise für den Zugriff auf eine entfernte Elasticsearch-Datenbank, um die Skalierbarkeit und Leistung zu verbessern.

Sie müssen diesen Schritten unter den folgenden Bedingungen folgen:

  • Sie führen ein Upgrade von einer SystemLink Enterprise Version vor 2025-07 durch.
  • Sie möchten Ihre Suchleistung verbessern.
Hinweis Diese Funktion ist derzeit nur für die FileIngestion- und Asset-Dienste verfügbar.

Auswählen einer Elasticsearch-Verteilung

SystemLink verwendet Elasticsearch, um die Suchleistung zu verbessern. Sie können eine Elasticsearch-Instanz im selben Kubernetes-Cluster wie Ihre SystemLink Enterprise-Installation oder eine externe Instanz verwenden.

Verwenden Sie die folgende Tabelle, um die Elasticsearch-Verteilung auszuwählen, die am besten zu Ihrem Anwendungsfall passt.
Tabelle 9. Bereitstellungsoptionen für Elasticsearch
Bereitstellung Anwendungsfälle Details
Helm-Diagramm für SystemLink Elasticsearch
  • Sie benötigen Ihre Datenbank im selben Kubernetes-Cluster wie Ihre SystemLink Enterprise-Installation.
  • Ihr Unternehmen ist mit der Verwaltung einer Elasticsearch-Instanz vertraut.
  • Sie möchten die automatische Bereitstellung und benutzerspezifische Konfigurationen für SystemLink Enterprise nutzen.

Sie können diese Instanz auf vorhandenen Kubernetes-Worker-Knoten oder dedizierten Worker-Knoten mithilfe von Taints und Toleranzen ausführen.

Weitere Informationen und empfohlene Ressourcen finden Sie unter Hinweise zur Größenanpassung bei der Verteilung einer Elasticsearch-Instanz.
Elastic Cloud Sie möchten die Bereitstellung, den Betrieb, die Sicherung und die Wiederherstellung von Datenbanken vereinfachen. Weitere Informationen und empfohlene Ressourcen finden Sie unter Hinweise zur Größenanpassung bei der Verteilung einer Elasticsearch-Instanz.

Konfigurieren des Helm-Diagramms für SystemLink Elasticsearch mit aktivierter automatischer Bereitstellung

Bei der initialen Konfiguration von Elasticsearch müssen Sie die Passwörter angeben.

  1. Öffnen Sie die Datei elasticsearch.yaml.
  2. Setzen Sie den Wert sl-elasticsearch.usersProvisioning.enabled auf True.
  3. Öffnen Sie die Datei elasticsearch-secrets.yaml.
  4. Legen Sie das Passwort für jeden Index fest.
    Tabelle 10. Indizes für aktivierte Autoprovisionierung
    Dienst Benutzer Passwort
    assetservicecdc assetscdc sl-elasticsearch.secrets.assetscdcPassword
    fileingestioncdc filecdc sl-elasticsearch.secrets.filescdcPassword
  5. Verteilen Sie Elasticsearch.

Konfigurieren einer Elasticsearch-Netzwerkinstanz oder des Helm-Diagramms für SystemLink Elasticsearch mit deaktivierter automatischer Bereitstellung

Bei der initialen Konfiguration von Elasticsearch müssen Sie die Indizes angeben.

  1. Öffnen Sie die Datei systemlink-secrets.yaml.
  2. Legen Sie das Passwort für jeden Index fest.
    Hinweis Manche Dienste erfordern Berechtigungen für mehrere Indizes. Wenn beispielsweise der Parameter files,files_* angegeben ist, erfordert der Dienst Berechtigungen für die folgenden Indizes:
    • Der Index für Dateien.
    • Alle Indizes, die dem Muster files_* entsprechen (wobei * ein Platzhalter ist).
    Tabelle 11. Indizes für deaktivierte Autoprovisionierung
    Dienst Datenbank Benutzer Passwort
    assetservice assets,assets_* assetscdc assetservice.secrets.elasticsearch.password
    assetservicecdc assets,assets_* assetscdc assetservicecdc.secrets.elasticsearch.password
    fileingestion files,files_* filecdc fileingestion.secrets.elasticsearch.password
    fileingestioncdc files,files_* filecdc fileingestioncdc.secrets.elasticsearch.password
  3. Verteilen Sie Elasticsearch.

Hinweise zur Größenanpassung bei der Verteilung einer Elasticsearch-Instanz

Der Ressourcenbedarf richtet sich nach der Nutzung des Dienstes. In der folgenden Tabelle finden Sie als Referenz getestete Konfigurationen für eine bestimmte Datenmenge, wenn Sie Ressourcen entsprechend Ihrer erwarteten Nutzung konfigurieren.

Konfigurieren Sie die Elasticsearch-Instanzen, um den Umfang Ihrer Daten zu verarbeiten.

Hinweis Dieser Ressourcenbedarf steigt mit zunehmender Nutzung von Elasticsearch.
Tabelle 12. Überlegungen zur Dimensionierung von Elasticsearch-Instanzen
Nutzungsgrad Achse Knoten CPU RAM Nachleuchten
Grundlinie 25000 Assets 2 1 4 GB 1 GB
Allgemein 25000 Assets und 25 Millionen Dateien 2 2 2 4 GB
Hoch 25000 Assets und 80 Millionen Dateien 4 2 4 GB 200 GB

Wählen und übernehmen Sie eine Konfiguration basierend auf Ihrem Umfang.

  1. Öffnen Sie die Datei elasticsearch.yaml.
  2. Setzen Sie den Wert sl-elasticsearch.elasticsearch.master.replicaCount auf die aufgeführten Knoten.
    Hinweis Für eine optimale Konfiguration darf die Anzahl der Knoten nicht kleiner sein als die höchste konfigurierte Anzahl primärer Shards.
  3. Setzen Sie den Wert sl-elasticsearch.elasticsearch.master.resources.requests.cpu auf die aufgelistete CPU.
  4. Setzen Sie den Wert sl-elasticsearch.elasticsearch.master.resources.requests.memory und den Wert sl-elasticsearch.elasticsearch.master.resources.limits.memory auf den aufgelisteten RAM.
  5. Setzen Sie den Wert sl-elasticsearch.elasticsearch.master.persistence.size auf die angegebene Größe des Persistenzspeichers.

Konfigurieren der Anzahl der primären Shards

Optimieren Sie Ihre SystemLink-Konfiguration, indem Sie sicherstellen, dass jeder Dienst weniger primäre Shards als die Anzahl der Knoten in Elasticsearch enthält.

Die folgende Tabelle enthält Konfigurationen, die NI bei bestimmten Skalierungen für die Dienste getestet hat.

Tabelle 13. Getestete Dienstkonfigurationen
Dienst Achse Primäre Shards
Asset Service 25000 Assets 1
FileIngestion Service 25 Millionen Dateien 2
FileIngestion Service 80 Millionen Dateien 4
  1. Öffnen Sie die Datei systemlink-values.yaml.
  2. Legen Sie die Anzahl der Shards für die folgenden Variablen fest:
    • assetservicecdc.job.connectors.sink.elasticsearch.index.primaryShardsCount
    • fileingestioncdc.job.connectors.sink.elasticsearch.index.primaryShardsCount
  3. Speichern Sie die Datei systemlink-values.yaml.
Hinweis Eine Shard-Konfiguration funktioniert nur bei der ersten Bereitstellung. Um die Konfiguration nach der ersten Bereitstellung zu ändern, müssen Sie das Datei-Index und das Asset-Index manuell aus Elasticsearch löschen. Anschließend können Sie die FileIngestionCDC-Anwendung oder die AssetServiceCDC-Anwendung erneut bereitstellen.

Installieren der Anwendung

Installieren Sie SystemLink Enterprise auf dem Cluster.

Der Benutzer, der die Installation vornimmt, benötigt keinen vollen Cluster-Zugriff. Der Benutzer muss aber vollen Zugriff auf den für die Anwendung erstellten Namensraum haben.

Weitere Informationen zu den für die Installation erforderlichen Kubernetes-Berechtigungen finden Sie unter Erforderliche Kubernetes-Berechtigungen.
Hinweis Dieses Thema geht davon aus, dass Sie das Datenbankzertifikat postgres.pem genannt haben, aber Sie können jeden beliebigen Namen verwenden. SystemLink Enterprise stellt das Zertifikat als ConfigMap-Ressource bereit.

SystemLink Enterprise installieren

helm upgrade <release> oci://downloads.artifacts.ni.com/ni-docker/ni/helm-charts/systemlink --install --version <version> --namespace <namespace> --values systemlink-values.yaml --values systemlink-secrets.yaml --set-file database.postgresCertificate=postgres.pem --wait --timeout 20m0s
Tabelle 14. Installationsparameter SystemLink Enterprise
Parameter Beschreibung
Release Der Name, den Helm der installierten Softwaresammlung zuweist.
downloads.artifacts.ni.com/ni-docker Die URL des Registrierungsdienstes. Wenn Sie mit einer lokalen Kopie arbeiten, ersetzen Sie diese URL durch die URL der Spiegel-Registry.
Version Die spezifische Version der Software, die installiert werden soll.
Namensraum Der Namespace für die Anwendung.

Dieser Befehl wartet bis zum konfigurierten Timeout, bis die Installation abgeschlossen ist und alle Ressourcen in den Bereitschaftszustand übergehen. Die Standardeinstellung für den Timeout lautet 20 Minuten. Der Timeout ist konservativ berechnet; die tatsächliche Installationszeit kann jedoch aufgrund einer Vielzahl von Faktoren variieren. Passen Sie den Timeout bei Bedarf an.

Hinweis Sie können auf ein und demselben Cluster auch mehrere Instanzen von SystemLink Enterprise installieren. Um mehrere Instanzen zu installieren, wiederholen Sie für jede Instanz die oben genannten Befehle mit einem anderen Namensraum und anderen Werten. Die erforderlichen Cluster-Ressourcen werden nur ein Mal für alle Instanzen installiert.

Validieren der Installation

Testen Sie, ob SystemLink Enterprise ordnungsgemäß installiert wurde.

Sie können eine erfolgreiche SystemLink Enterprise Installation überprüfen, indem Sie die Bereitschaftssonden für die vom SystemLink Enterprise Helm-Diagramm bereitgestellten Pods mit einer der folgenden Methoden überprüfen:

  • Verwenden einer Anwendung wie Lens.
  • Führen Sie den folgenden Befehl aus:
    kubectl describe pod <pod-name> -n <namespace>
Wenn ein Pod nicht in den Bereitschaftszustand eintritt und nach einigen Minuten kontinuierlich neu gestartet wird, empfiehlt NI die Fehlersuche am Pod. Sie können den Pod auf Fehler untersuchen, indem Sie das Protokoll für den Pod mit dem folgenden Befehl untersuchen:
kubectl logs <pod-name> -n <namespace>