Systemanforderungen

Nachfolgend werden die minimalen Hardware- und Infrastrukturanforderungen für die Ausführung der Version 10.9.1 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–4.8
• Verwaltete Kubernetes-Services in der Cloud
  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Microsoft Azure Kubernetes Service (AKS)

Container-Registry

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.

Abrufen von 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 unter My Esri, vorausgesetzt dass Sie über Berechtigungen zum Ausführen von Lizenzierungsaktionen verfügen. Gehen Sie wie folgt vor:

1. Melden Sie sich bei My Esri an.
2. Wählen Sie Eigene Organisationen > Lizenzierung aus.
3. Klicken Sie Esri Produkte lizenzieren auf Start.
4. Wählen Sie für Produkt ArcGIS Enterprise aus. Wählen Sie für Version die entsprechende 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 Umgebungen benötigt. Für die jeweiligen unterstützten Umgebungen werden die folgenden Kubernetes-Cluster-Versionen unterstützt:

ArcGIS Enterprise on Kubernetes-Version	Unterstützte Kubernetes-Cluster-Version
10.9.1	1.19–1.21

Hinweis:

Beim Erstellen eines Clusters in GKE müssen Sie den Standardmodus des Vorgangs verwenden. Der Autopilotmodus wird nicht unterstützt.

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.

CPU und Speicher

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.

Architecture profile	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.

Hinweis:

ArcGIS Enterprise on Kubernetes unterstützt keine Windows Server-Knoten-Images in GKE-Umgebungen.

Resource Quota-Objekt

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.

Hinweis:

Bei einem Upgrade auf Version 10.9.1 müssen Sie zunächst die Ressourcenkontingentwerte im Namespace gemäß den Anforderungen für Version 10.9.1 aktualisieren.

Am besten reservieren Sie mindestens 10 Prozent 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 Skalierbarkeitsanforderungen konfiguriert werden:

Profil für Standardverfügbarkeit:

spec: 
    hard: 
      limits.cpu: "128" 
      limits.memory: 228Gi 
      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: "96" 
      limits.memory: 164Gi 
      requests.cpu: "14" 
      requests.memory: 72Gi

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 arcgis-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
    

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. ArcGIS Enterprise-Pods nutzen den vollständig qualifizierten Domänennamen (FQDN) kubernetes.default.svc.cluster.local, um den API-Server abzufragen.

Hinweis:

cluster.local ist die Standarddomäne des Clusters.

Hinweis:

Pods im Cluster müssen mit der FSGroup- und SupplementalGroup-ID 117932853 ausgeführt werden können.

Netzwerk

Zu den Netzwerkanforderungen gehören ein FQDN und ein Load Balancer. Details zu den einzelnen Anforderungen finden Sie unten.

Vollständig qualifizierter Domänenname

ArcGIS Enterprise on Kubernetes erfordert einen FQDN, z. B. map.company.com. Zur Erstellung können Sie ein 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 LoadBalancer (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.

Geben Sie bei Verwendung eines selbstverwalteten Load Balancers oder Reverseproxys wie NGINX die folgende Verbindung an: proxy_set_header X-Forwarded-Host $host;. Dieser Header wird benötigt, um sicherzustellen, dass Traffic ordnungsgemäß an die URL Ihrer ArcGIS Enterprise-Organisation weitergeleitet wird.

Systemspeicher

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 geringer Latenz zu verwenden, wie etwa EBS-Volumes, Azure-Datenträger oder vSphereVolume.

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:

Hinweis:

Die aufgeführten Anforderungen an PVs gelten für Version 10.9.1 und können sich von vorherigen Versionen unterscheiden.

• 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": Speichert Protokolle und Indizes sowie gehostete Feature-Daten, um die Visualisierung und Analyse von Big-Data-Beständen in Echtzeit zu ermöglichen.
• 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 die unten beschriebenen Spezifikationen und Bezeichnungen empfohlen.

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

Volume	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

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

Volume	Größe in GiB (minimum)	Zugriffsmodus	Beschriftung
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

Dynamische PVs

Bei der dynamischen Bereitstellung ist eine StorageClass erforderlich.

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.

• Es folgt 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".

Anforderungen an den Speicher nach der Bereitstellung

Nach der Bereitstellung gelten zusätzliche Speicheranforderungen für die item-packages-PVs, um Upgrades durchzuführen und die Portal-API-Bereitstellung zu skalieren, wie im Folgenden beschrieben.

Die Anforderungen für Upgrades und die Skalierung sind abhängig vom Typ des bereitgestellten Speichers, den Sie bei der Bereitstellung konfigurieren:

• Dynamische PVs: Der Speicher wird durch die Software skaliert und angepasst, sofern genügend Speicher verfügbar ist und die Speicherklassenspezifikationen eingehalten werden.
• Statische PVs: Ein Administrator muss zusätzliche item-packages-PVs mit denselben Spezifikationen (Beschriftungen, Größe und Zugriffsmodus), die auch bei der Bereitstellung angegeben wurden, bereitstellen, damit Skalierung und Upgrades von Workflows unterstützt werden.

Upgrades

Vor einem Upgrade wurde für jeden Pod in der Portal-API-Bereitstellung der Organisation ein item-packages-PV konfiguriert. Bei der Vorbereitung eines Upgrades muss für jeden Pod in der Portal-API-Bereitstellung ein zusätzliches PV konfiguriert werden.

Wenn beispielsweise vor einem Upgrade drei ausgeführte Pods für eine Portal-API-Bereitstellung konfiguriert werden, müssen insgesamt sechs PVs bereitgestellt und Spezifikationen konfiguriert werden, die den während der Bereitstellung angegebenen Spezifikationen entsprechen.

Nachdem das Upgrade abgeschlossen ist, werden die neu bereitgestellten Persistent Volumes und Persistent Volume Claims in der Portal-API-Bereitstellung verwendet und der ursprüngliche Satz kann entfernt werden.

Skalieren der Portal-API

Zur Skalierung der Portal-API-Bereitstellung (Erhöhung der Anzahl der beteiligten Pods) wird ein zusätzliches item-packages-PV für jeden zusätzlichen Pod, der der Bereitstellung hinzugefügt wird, benötigt. Wenn die Organisation beispielsweise drei Pods für die Portal-API-Bereitstellung benötigt, müssen mindestens drei item-packages-PVs bereitgestellt und mit Spezifikationen konfiguriert werden, die den bei der Bereitstellung angegebenen Spezifikationen entsprechen.

Client-Workstation

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

Hinweis:

Die verwendete Client-Workstation muss zu den unterstützten Umgebungen gehören.

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
• GKE CLI
• OpenShift CLI

TLS certificate

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 ein von einer Zertifizierungsstelle signiertes Zertifikat empfohlen. Dies ist das Standard-TLS-Zertifikat 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.