Systemanforderungen

Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung der Version 10.9 von ArcGIS Enterprise on Kubernetes beschrieben.

Unterstützte Umgebungen

Die Systemanforderungen und Spezifikationen gelten für alle unterstützten Umgebungen, sofern nicht anders angegeben. Diese Version unterstützt die folgenden Umgebungen:

• Lokale Rechenzentren
  • Red Hat OpenShift Container Platform 4.6 oder höher
• Verwaltete Kubernetes-Services in der Cloud
  • Microsoft Azure Kubernetes Service (AKS)
  • Amazon Elastic Kubernetes Service (EKS)

Container-Registrierung

Container-Images für ArcGIS Enterprise on Kubernetes sind über ein privates Docker -Hub-Repository zugänglich. Esri bietet für die Benutzer Zugriff auf dieses Repository, die ArcGIS Enterprise on Kubernetes bereitstellen. Ausführlichere Informationen erhalten Sie bei einem Ansprechpartner bei Esri.

Esri-Lizenzen

Damit Sie Ihre ArcGIS Enterprise-Organisation während der Bereitstellung autorisieren können, benötigen Sie eine Lizenzdatei für Benutzertypen im JSON-Format (.json-Datei) und eine Serverlizenzdatei im ECP- oder PRVC-Format (.ecp- oder .prvc-Datei). Diese Lizenzdateien erhalten Sie mit den Berechtigungen zum Ausführen von Lizenzierungsaktionen unter My Esri.

• Melden Sie sich bei My Esri an.
• Wählen Sie Eigene Organisationen > Lizenzierung aus.
• Klicken Sie Esri Produkte lizenzieren auf Start.
• Wählen Sie für Produkt ArcGIS Enterprise aus. Wählen Sie für Version die gewünschte Version von ArcGIS Enterprise aus, und führen Sie in der Liste Lizenztyp die Schritte aus, um Lizenzdateien für ArcGIS Server und Portal for ArcGIS einschließlich der Serverrollen, Benutzertypen und Anwendungen zu generieren.

Kubernetes-Cluster

Für die Bereitstellung von ArcGIS Enterprise on Kubernetes wird ein Kubernetes-Cluster in einer der oben aufgeführten Plattformen benötigt. Der Kubernetes-Cluster für die einzelnen unterstützten Umgebungen muss in Version 1.19 oder höher vorliegen.

Namespace

Für ArcGIS Enterprise on Kubernetes ist ein eigener dedizierter Namespace erforderlich. Dieser muss vor der Ausführung des Bereitstellungsskripts erstellt werden. Jede Bereitstellung von ArcGIS Enterprise on Kubernetes erfordert zudem einen dedizierten Namespace.

Verarbeitung

ArcGIS Enterprise on Kubernetes wird mit einem von drei Architekturprofilen bereitgestellt. Die Empfehlungen für Ressourcenanforderungen und -beschränkungen (CPU und Speicher) sowie für die Compute-Anforderungen insgesamt sind je nach ausgewähltem Profil unterschiedlich. Die Empfehlungen für die einzelnen Profile werden im Folgenden aufgeführt.

Für die einzelnen Architekturprofile gelten die folgenden Mindestanforderungen für Knoten. Jeder Worker-/Agent-Knoten sollte über mindestens 8 CPUs und 32 GiB Speicher verfügen.

Architektur-Profil	Mindestens erforderliche Worker-/Agent-Knoten	Insgesamt mindestens erforderliche CPUs	Insgesamt mindestens erforderliche GiB
Standardverfügbarkeit	3	24	96
Erweiterte Verfügbarkeit	4	32	128
Entwicklung	2	16	64

Hinweis:

ArcGIS Enterprise on Kubernetes wird nur mit CPUs, die der x86_64-Architektur (64 Bit) entsprechen, unterstützt.

Die Pods in der ArcGIS Enterprise on Kubernetes-Bereitstellung werden auf die Worker-Knoten im Cluster verteilt. Wenn Sie die Bereitstellung skalieren oder eine weitere ArcGIS Enterprise-Bereitstellung zum Cluster hinzufügen, müssen Sie entsprechend mehr Hardware bereitstellen. Dadurch kann sich die maximale Standardanzahl von Pods je Knoten erhöhen. Die Anzahl der anfänglich erstellten Pods ist je nach Architekturprofil unterschiedlich. Wenn Sie horizontal skalieren oder neue Funktionalitäten hinzufügen, erhöht sich die Anzahl der Pods.

Ressourcenkontingent

Für ArcGIS Enterprise on Kubernetes-Pods bestehen vordefinierte Anforderungen und Beschränkungen für CPU und Arbeitsspeicher. Wenn der Namespace ein ResourceQuota-Objekt enthält, muss das Kontingent größer sein als die Summe der Anforderungen und Beschränkungen aller Pods. Wie im Folgenden beschrieben, sind diese Werte je nach ausgewähltem Architekturprofil unterschiedlich.

Am besten reservieren Sie mindestens 10 % der Anforderungsressourcen für das ordnungsgemäße Funktionieren der Cluster-Knoten.

Die folgenden Kontingentempfehlungen für die einzelnen Profile beruhen auf den oben genannten Reservierungen. Die angegebenen Grenzwerte sind Platzhalter und müssen entsprechend den tatsächlichen Skalierbarkeitsanforderungen konfiguriert werden.

Profil für Standardverfügbarkeit:

spec: 
    hard: 
      limits.cpu: "120" 
      limits.memory: 196Gi 
      requests.cpu: "22" 
      requests.memory: 86Gi

Profil für erweiterte Verfügbarkeit:

spec: 
    hard: 
      limits.cpu: "132" 
      limits.memory: 256Gi 
      requests.cpu: "28" 
      requests.memory: 108Gi

Entwicklungsprofil:

spec: 
    hard: 
      limits.cpu: "86" 
      limits.memory: 154Gi 
      requests.cpu: "14" 
      requests.memory: 58Gi

Sicherheit

Nachfolgend werden die Sicherheitsanforderungen für ArcGIS Enterprise on Kubernetes beschrieben.

Rollenbasierte Zugriffssteuerung

Im Kubernetes-Cluster muss die rollenbasierte Zugriffssteuerung (Role-based access control, RBAC) aktiviert werden. Sie benötigen für die Bereitstellung von ArcGIS Enterprise on Kubernetes keine Admin-Berechtigungen für den Cluster. Benutzer ohne Admin-Berechtigungen für den Cluster benötigen mindestens Administratorberechtigungen für den Namespace. Sie können dem Benutzer die defaultClusterRole "admin" zuweisen, indem Sie im Namespace eine RoleBinding erstellen.

Pod-Sicherheitsrichtlinie (eingeschränkter Sicherheitskontext in OpenShift) und virtueller Arbeitsspeicher

ArcGIS Enterprise on Kubernetes stellt Elasticsearch zur Unterstützung verschiedener Funktionen der ArcGIS Enterprise-Organisation bereit. Standardmäßig speichert Elasticsearch erforderliche Indizes im mmapfs-Verzeichnis. Die Standardbeschränkungen des Betriebssystems für die mmap-Anzahl sind möglicherweise unzureichend für die Bereitstellung. Elasticsearch empfiehlt für vm.max_map_count den Standardwert 262144. Die Änderung des Standardwerts erfordert eine höhere Berechtigung (Root-Berechtigung) für die einzelnen Knoten.

Je nachdem, ob im Kubernetes-Cluster Container mit oder ohne Berechtigungen ausgeführt werden können, sind folgende Maßnahmen erforderlich.

• Mit Berechtigungen: ArcGIS Enterprise on Kubernetes führt einen Init-Container mit Berechtigungen auf dem Elasticsearch-Knoten aus, und es sind keine weiteren Maßnahmen erforderlich.
• Ohne Berechtigungen: Wenn für den Kubernetes-Cluster Pod-Sicherheit definiert wurde und er die Ausführung von Containern mit Berechtigungen nicht zulässt, gelten folgende Optionen.
  • Option 1: Das Bereitstellungsskript für ArcGIS Enterprise on Kubernetes erstellt ein Dienstkonto für die Ausführung von Containern unter dem eigenen Namespace. Das Standarddienstkonto lautet rcgis-admin-serviceaccount. Wenn für den Cluster eine Pod-Sicherheitsrichtlinie definiert wurde, müssen Sie dem Dienstkonto die Ausführung von Containern mit Berechtigungen erlauben. Unter OpenShift können Sie dem eingeschränkten Sicherheitskontext mit Berechtigungen den Zugriff auf das Dienstkonto gewähren, indem Sie Folgendes zum Benutzerabschnitt hinzufügen.
    “-system:serviceaccount: <Namespace>:arcgis-admin-serviceaccount"
    

  • Option 2: Wenn Sie das Dienstkonto nicht so einrichten können, dass es als Container mit Berechtigungen ausgeführt wird, müssen Sie jeden Knoten manuell einrichten, indem Sie den folgenden Befehl als Root-Benutzer ausführen:
    sysctl -w vm.max_map_count=262144
    

Nach der Einrichtung der Knoten müssen Sie wie folgt die Anweisung in das Bereitstellungsskript einfügen, dass keine Container mit Berechtigungen ausgeführt werden sollen:

• Navigieren Sie zur /setup/.install/arcgis-enterprise/arcgis-enterprise.properties-Datei.
• Aktualisieren Sie die Zeichenfolge "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-true}" auf "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-false}".
• Speichern Sie die Datei.

Das Bereitstellungsskript führt den Init-Container nicht mit Berechtigungen aus.

Wenn Sie Kubernetes NetworkPolicies verwenden, stellen Sie sicher, dass im ArcGIS Enterprise-Namespace eine unterbrechungsfreie Kommunikation zwischen den Pods und zwischen Pods und Services erlaubt sind.

Stellen Sie zudem auch sicher, dass die Pods im Namespace Zugriff auf den Kubernetes-API-Server haben. Auf den API-Server kann über einen Service mit dem Namen Kubernetes im Standard-Namespace zugegriffen werden. Pods im Standard-Namespace verwenden den Hostnamen kubernetes.default.svc zum Abfragen des API-Servers.

Netzwerk

Zu den Netzwerkanforderungen gehören ein vollständig qualifizierter Domänenname und ein Load Balancer. Die jeweiligen ausführlicheren Informationen werden im Folgenden aufgeführt.

Vollständig qualifizierter Domänenname

ArcGIS Enterprise on Kubernetes erfordert einen vollständig qualifizierten Domänennamen (FQDN), z. B. map.company.com. Zur Erstellung können Sie Ihr vorhandenes Domain Name System (DNS) oder ein Cloud DNS wie Amazon Route 53 verwenden. Sie können den DNS-Datensatz nach der Bereitstellung erstellen, seinen Wert müssen Sie aber währenddessen definieren. In dieser Version kann der FQDN nach der Bereitstellung nicht mehr geändert werden.

Load Balancer

Ein Load Balancer ist erforderlich, um Datenverkehr auf die einzelnen Worker-Knoten zu verteilen. Wenn Sie AKS oder EKS verwenden, können Sie die folgenden Load Balancer ohne manuelle Konfiguration aus dem Bereitstellungsskript bereitstellen:

• Azure Load Balancer (öffentlich oder intern): Im Bereitstellungsskript kann eine vorab bereitgestellte öffentliche IP-Adresse und eine DNS-Bezeichnung angegeben werden.

• AWS Network und AWS Classic Load Balancer (mit Internetzugriff oder intern): Es können auch andere Load-Balancer-Dienste verwendet werden; diese müssen allerdings an jedem einzelnen Cluster-Knoten manuell konfiguriert werden.

Auf einer OpenShift-Containerplattform können Routen konfiguriert werden, wenn diese auf den Eingangs-Controller-Dienst verweisen.

Sie können einen selbstverwalteten Load Balancer verwenden, der auf die Worker-Knoten am NodePort des Eingangs-Controller-Diensts verweist. Näheres hierzu finden Sie in der Beschreibung der Parameter in der Bereitstellungsanleitung für den Load Balancer.

Hinweis:

Das Plug-in Azure CNI in AKS wird von dieser Version nicht unterstützt.

Speicher

ArcGIS Enterprise on Kubernetes erfordert persistente Datenträger (PVs) für den Systemspeicher. Diese können dynamisch oder statisch bereitgestellt werden. Für beide Arten von PVs können Sie benutzerdefinierte (größere) Größen und Bezeichnungen verwenden. Zu den zustandsbehafteten Workloads von ArcGIS Enterprise gehören sowohl relationale Datenbankmanagementsysteme als auch NoSQL-Datenbanken. Es wird empfohlen, Blockspeichergeräte mit einer geringer Latenz zu verwenden, wie etwa EBS-Volumes, Azure-Datenträger, vSphereVolume usw.

Da auf diesen persistenten Volumes Daten und Einstellungen gespeichert werden, sollten sie mit restriktiven Sicherheitsrichtlinien geschützt werden. Legen Sie bei persistenten Volumes, die auf einer dateibasierten Speicherung beruhen, wie etwa NFS, Azure File oder Gluster, die Berechtigungen für die Verzeichnisse so fest, dass ein unberechtigter Zugriff nicht möglich ist. Begrenzen Sie bei Blockspeichern wie EBS-Volumes, Azure-Datenträgern und iSCSI den Zugriff auf die Benutzer, die auf die Blockspeichergeräte zugreifen müssen.

Im Folgenden werden Speicher-Volumes und der jeweils vorgesehene Zweck beschrieben:

• In-Memory: Speichert temporäre Systemressourcen.
• Elementpakete: Speichert umfangreiche Uploads und Pakete im Rahmen von Veröffentlichungs-Workflows.
• Objekt: Speichert hochgeladene und gespeicherte Inhalte, gehostete Kachel- und Bild-Layer-Caches sowie Geoverarbeitungsausgaben. Für die Bereitstellung sind vier Datenträger erforderlich.
• Warteschlange: Speichert asynchrone Geoverarbeitungsaufträge.
• Relational: Speichert gehostete Feature-Daten und administrative Elemente wie Anpassungs- und Konfigurationseinstellungen. Für die Bereitstellung sind zwei Datenträger erforderlich.
• "Spatiotemporal" und "Index": Speicher für Protokolle und Indizes sowie für gehostete Feature-Daten, um die Visualisierung und Analyse von Big-Data-Beständen in Echtzeit zu ermöglichen.
• Viewer für Nutzungskennwerte: Speichert standardmäßige und benutzerdefinierte Dashboards, in denen die Nutzung von GIS-Services dargestellt wird.
• Nutzungskennwertdaten: Speichert Nutzungsdaten für GIS-Services.

Definieren Sie die Größe der einzelnen PVs anhand der Speicheranforderungen Ihrer Organisation.

Statische PVs

Wenn Sie statische PVs vor der Bereitstellung zur Verfügung stellen, werden folgende Spezifikationen und Bezeichnungen empfohlen.

Im Folgenden wird die Anzahl der für die einzelnen Architekturprofile erforderlichen PVs aufgeführt.

Volumen	Entwicklungsprofil	Profil für Standardverfügbarkeit	Profil für erweiterte Verfügbarkeit
in-memory-volume	1	1	1
item-packages-volume	1	2	2
object-volume-1	1	4	12
queue-volume	1	2	2
relational-volume	2	2	2
spatiotemporal-and-index-volume	1	3	5
usage-metric-volume	1	1	1
usage-metric-viewer-volume	1	1	1

Beim Konfigurieren einer Organisation mit dem Setup-Assistenten werden für die Volume-Bindung folgende Angaben (Volume-Name, Größe, App und Ebene) verwendet. Sie können diese jedoch nach Bedarf anpassen

Volumen	Größe in GiB (minimum)	Zugriffsmodus	Bezeichnung (Standard)
in-memory-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ignite
item-packages-volume	16	ReadWriteOnce	arcgis/tier=api, arcgis/app=sharing
object-volume-1	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=minio
queue-volume	16	ReadWriteOnce	arcgis/tier=queue, arcgis/app=rabbitmq
relational-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=postgres
spatiotemporal-and-index-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=elasticsearch
usage-metric-volume	30	ReadWriteOnce	arcgis/tier=storage, arcgis/app=prometheus
usage-metric-viewer-volume	1	ReadWriteOnce	arcgis/tier=storage, arcgis/app=grafana

Dynamische PVs

Bei der dynamischen Bereitstellung ist eine StorageClass erforderlich. Beim Konfigurieren der Organisation mit dem Setup-Assistenten lautet der Standardname für StorageClass arcgis-storage-default.

Der reclaimPolicy-Parameter für die StorageClass muss auf retain festgelegt werden.

Hinweis:

Premiumdatenträger in Azure werden nicht von allen VM-Typen unterstützt. Wenn der VM-Typ Premiumdatenträger unterstützt, verwenden Sie einen Premiumdatenträger.

• Im Folgenden ein Beispiel für eine StorageClass-Definition mit Azure Premium-Datenträger unter AKS:
  kind: StorageClass 
  apiVersion: storage.k8s.io/v1 
  metadata: 
    name: arcgis-storage-default 
  provisioner: kubernetes.io/azure-disk 
  parameters: 
    kind: Managed 
    storageaccounttype: Premium_LRS 
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

• Im Folgenden ein Beispiel für eine StorageClass-Definition mit EBS-Datenträgern vom Typ "GP2" unter EKS:
  kind: StorageClass 
  apiVersion: storage.k8s.io/v1 
  metadata: 
    name: arcgis-storage-default  
  provisioner: kubernetes.io/aws-ebs 
  parameters: 
    fsType: ext4 
    type: gp2 
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

Sie können auch die zusammen mit einem AKS- oder EKS-Cluster bereitgestellten Standardspeicherklassen verwenden. In AKS ist dies die Speicherklasse "default (azure disk)" oder "managed-premium". In EKS ist dies eine Speicherklasse vom Typ "GP2".

Client-Workstation

Die Bereitstellungsskripte sind Bash-Skripte, die von einer Bash-Shell aus über eine Remote-Client-Workstation ausgeführt werden können.

Für die Einrichtung Ihrer Client-Workstation benötigen Sie folgende Komponenten (Links für den Download anbei):

• Kubectl
• Eine umgebungsspezifische Befehlszeilenschnittstelle (CLI)

Kubectl ist für die Ausführung des Bereitstellungsskripts erforderlich. Laden Sie das Kubernetes-Befehlszeilenwerkzeug über Kubectl installation and setup herunter.

Zur Verwaltung Ihrer Bereitstellung können Sie umgebungsspezifische Befehlszeilenwerkzeuge verwenden. Links für den Download der umgebungsspezifischen Befehlszeilenschnittstelle:

• Azure CLI
• AWS CLI
• OpenShift CLI

TLS-Zertifikat

ArcGIS Enterprise on Kubernetes verwendet einen auf NGINX-basierenden Eingangs-Controller. Dieser ist Namespace-bezogen und wird bereitgestellt, um ausschließlich den eingehenden Datenverkehr für den ArcGIS Enterprise-Namespace abzuhören. Für den FQDN im allgemeinen Namen des Zertifikats und den alternativen Namen ist ein TLS-Zertifikat erforderlich. Hierbei kann ein von einer Zertifizierungsstelle signiertes Zertifikat oder ein selbstsigniertes Zertifikat verwendet werden. Aus Sicherheitsgründen wird jedoch dringend empfohlen, ein von einer Zertifizierungsstelle signiertes Zertifikat zu verwenden. Dies ist das TLS-Standardzertifikat für den Eingangs-Controller. Im Bereitstellungsskript stehen die folgenden Zertifikatoptionen für die Anwendung eines TLS-Zertifikats für eingehenden Datenverkehr zur Verfügung:

• Ein vorhandenes TLS-Secret mit einem privaten Schlüssel und einem Zertifikat
• Eine .pfx-Datei mit einem privaten Schlüssel und einem Zertifikat
• Ein PEM-formatierter privater Schlüssel und ein Zertifikat
• Ein selbstsigniertes Zertifikat

ArcGIS Enterprise on Kubernetes unterstützt die Verwendung eines TLS-Zertifikats für den Eingangs-Controller, das durch Kubernetes cert-manager ausgegeben und verwaltet wird. Diese Zertifikat muss in einem TLS-Secret im selben Namespace wie ArcGIS Enterprise gespeichert werden. Das TLS-Secret kann dann entweder während der Bereitstellung oder nach der Erstellung der ArcGIS Enterprise-Organisation referenziert werden.

ArcGIS Enterprise on Kubernetes und ArcGIS Pro

ArcGIS Pro 2.7 oder höher ist für die Nutzung von Services von ArcGIS Enterprise on Kubernetes erforderlich. Frühere Versionen werden nicht unterstützt.

ArcGIS Pro 2.8 oder höher ist für die Veröffentlichung von Services in ArcGIS Enterprise on Kubernetes erforderlich.

Beim Registrieren eines Data-Store-Elements aus einer Enterprise-Geodatabase muss die Geodatabase die Version 10.9.0.2.8 oder höher aufweisen. Die Geodatabase-Versionsnummer ist eine Kombination aus der ArcGIS Enterprise- und der ArcGIS Pro-Versionsnummer.

Über ArcMap erstellte Enterprise-Geodatabases können nicht als Datenelemente registriert werden.