Verfügbarkeitsprofile
Verfügbarkeitsprofile legen den Grad der Redundanz zwischen den Pods fest. Das ausgewählte Profil bestimmt, welche Pods während des Setups automatisch repliziert werden. Da einige Organisationen ein höheres Maß an Ausfallsicherheit und Verfügbarkeit benötigen als andere, bieten Verfügbarkeitsprofile Flexibilität für verschiedene bekannte Variablen, z. B. Hardwareanforderungen, Redundanz und organisatorische Verwendung.
Wählen Sie beim Erstellen Ihrer Organisation ein Verfügbarkeitsprofil aus, das Ihren Anforderungen an die Redundanz entspricht.
Im Folgenden werden die vordefinierten Verfügbarkeitsprofile beschrieben.
|
Verfügbarkeitsprofil |
Anwendungsfall |
Hardwareanforderungen |
Vordefinierte Redundanz für Pods |
|---|---|---|---|
|
Erweiterte Hochverfügbarkeit |
Konzipiert für den Einsatz in geschäfts- oder unternehmenskritischen Produktionsumgebungen. Dieses Profil ist auf höchste Verfügbarkeit ausgelegt, da es erhöhte und erweiterte Redundanz für kritische Pods umfasst. |
Maximum |
Maximum |
|
Standard-Hochverfügbarkeit |
Konzipiert für den Einsatz in Produktionsumgebungen. Durch Redundanz in vielen Pods werden ungeplante Ausfallzeiten minimiert. Dies ist das Standardprofil. |
Moderat |
Moderat |
|
Entwicklungs- und Testumgebungen |
Konzipiert für den Einsatz in nicht produktionsbezogenen Umgebungen, z. B. Test- und Auswertungsumgebungen. Dieses Profil wird für Produktionsumgebungen nicht unterstützt. |
Minimal |
Minimal |
Verwenden Sie bei der Bereitstellung von ArcGIS Enterprise on Kubernetes in Nicht-Produktionsumgebungen die Option "Entwicklungs- und Testumgebungen". Diese Option stellt die geringsten Anforderungen an Hardware und Ressourcen. Bei der Bereitstellung in Produktionsumgebungen stellen beide Hochverfügbarkeitsprofile im Fall eines Fehlers die kontinuierliche Nutzung und Verfügbarkeit sicher. Das Profil der erweiterten Hochverfügbarkeit bietet im Vergleich zum Standardprofil für Hochverfügbarkeit zusätzliche Ausfallsicherheit, erfordert jedoch zusätzliche Systemressourcen.
Replizierte Pods pro Verfügbarkeitsprofil
Wie oben beschrieben umfasst jedes Verfügbarkeitsprofil einen vordefinierten Satz replizierter Pods, um im Fall eines unerwarteten Fehlers die Kontinuität der Workflows zu unterstützen. Für jedes Profil wird ein unterstützter Beispiel-Workflow angegeben.
Erweiterte Hochverfügbarkeit: Replizierte Pods werden für Veröffentlichungswerkzeuge, Speicher, APIs und Ingress-Controller mit erhöhter Redundanz bereitgestellt, um im Fall eines unerwarteten Fehlers oder bei Ausfallzeiten die unterbrechungsfreie Nutzung zu unterstützen.
Standard-Hochverfügbarkeit: Replizierte Pods werden für Veröffentlichungswerkzeuge und andere wichtige Pods wie Speicher, APIs und Ingress-Controller bereitgestellt, um im Fall eines unerwarteten Fehlers oder bei Ausfallzeiten die kontinuierliche Nutzung zu unterstützen.
Entwicklungs- und Testumgebungen: Veröffentlichungswerkzeuge werden repliziert, um mehrere Publisher in einer Organisation zu unterstützen.
Im Folgenden finden Sie eine Beschreibung aller replizierten Pods pro Verfügbarkeitsprofil.
|
Replizierte Pods |
Profil für erweiterte Hochverfügbarkeit |
Profil für Standard-Hochverfügbarkeit |
Entwicklungs- und Testumgebungsprofil |
|---|---|---|---|
|
PublishingTools |
4 |
3 |
3 |
|
Data Store vom Typ "relational" |
2 |
2 |
2 |
|
Privater Ingress-Controller |
3 |
2 |
2 |
|
Ingress-Controller |
3 |
2 |
|
|
Administrator-API |
2 |
2 |
|
|
Portal-API |
2 |
2 |
|
|
Services-API |
2 |
2 |
|
|
JavaScript API |
2 |
||
|
Notebook-Automatisierungsservice |
2 |
||
|
Warteschlangenspeicher |
2 |
2 |
|
|
Objektspeicher: Gemischt |
3 |
||
|
Objektspeicher: Metadaten |
3 |
||
|
Objektspeicher: Datenserver |
5 |
||
|
Data Store vom Typ "spatiotemporal" und Indexspeicher: Gemischt |
3 |
||
|
Data Store vom Typ "spatiotemporal" und Indexspeicher: Koordinator |
3 |
||
|
Data Store vom Typ "spatiotemporal" und Indexspeicher: Daten |
2 |
||
|
Freigegebener Feature-Service |
2 |
2 |
|
|
Freigegebener Image-Service |
2 |
2 |
|
|
Freigegebener Kartenservice |
2 |
2 |
|
|
Freigegebener Kachelservice |
2 |
2 |
|
|
Enterprise-Portal |
2 |
||
|
Enterprise-Apps |
2 |
Empfohlene Speichergröße pro Verfügbarkeitsprofil
Um ausreichend Speicherplatz zu gewährleisten, hängt die empfohlene Speichergröße für jedes StatefulSet-Volume vom ausgewählten Verfügbarkeitsprofil ab, wie in der folgenden Tabelle dargestellt. Die bereitgestellte Größe muss mindestens so groß sein wie der im Entwicklungs- und Testumgebungsprofil angegebene Minimalwert. Sie können für den Objektspeicher, den Data Store vom Typ "relational" sowie für den Data Store vom Typ "spatiotemporal" und den Indexspeicher die Volume-Größe erhöhen, falls zusätzlicher Speicher benötigt wird.
|
StatefulSet |
Profil für erweiterte Hochverfügbarkeit (GiB) |
Profil für Standard-Hochverfügbarkeit (GiB) |
Entwicklungs- und Testumgebungsprofil (GiB) |
|---|---|---|---|
|
Speicher vom Typ "relational" |
300 |
150 |
16 |
|
Objektspeicher |
300 |
150 |
64 |
|
In-Memory-Cache |
16 |
16 |
16 |
|
Warteschlangenspeicher |
16 |
16 |
16 |
|
Speicher vom Typ "spatiotemporal" und Indexspeicher |
300 |
150 |
32 |
|
Elementpakete |
32 |
16 |
16 |
|
Prometheus |
120 |
60 |
30 |
Der empfohlene Gesamtspeicherplatz für jedes in der folgenden Tabelle aufgeführte Verfügbarkeitsprofil hängt sowohl von der Größe der einzelnen Volumes als auch von der Anzahl der Replikate ab:
|
Verfügbarkeitsprofil |
Empfohlene Gesamtspeichergröße (GiB) |
|---|---|
|
Profil für erweiterte Hochverfügbarkeit |
4.732 |
|
Profil für Standard-Hochverfügbarkeit |
1.340 |
|
Entwicklungs- und Testumgebungsprofil |
206 |