Wählen Sie bei der Bereitstellung von ArcGIS Enterprise on Kubernetes ein für Ihre Organisation geeignetes Architektur-Profil aus. Ein Architektur-Profil ist ein Satz von vordefinierten Bereitstellungsprofilen, die verschiedenen Redundanzstufen in den Pods entsprechen. 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 Architektur-Profile Flexibilität für verschiedene bekannte Variablen, z. B. Hardwareanforderungen, Redundanz und organisatorische Verwendung.
Im Folgenden werden die vordefinierten Achitektur-Profile beschrieben. Die ersten beiden sind auf Hochverfügbarkeit ausgerichtet, während das dritte für die Entwicklung und den nicht produktionsbezogenen Einsatz bestimmt ist.
| Architektur-Profil | Anwendungsfall | Hardwareanforderungen | Vordefinierte Redundanz für Pods |
|---|---|---|---|
Erweiterte Verfügbarkeit | Konzipiert für den Einsatz in geschäfts- oder unternehmenskritischen Produktionsumgebungen. Dieses Profil ist auf höchste Verfügbarkeit ausgerichtet, da es erhöhte und erweiterte Redundanz für kritische Pods umfasst. | Maximum | Maximum |
Standardverfügbarkeit | Konzipiert für den Einsatz in Produktionsumgebungen. Durch Redundanz für viele Pods werden ungeplante Ausfallzeiten minimiert. Dies ist das Standardprofil. | Moderate | Moderate |
Entwicklung | 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 die Entwicklungsoption, wenn Sie ArcGIS Enterprise on Kubernetes in nicht produktionsbezogenen oder Testumgebungen bereitstellen. 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 erweiterte Profil erfordert jedoch zusätzliche Hardware.
Replizierte Pods pro Architektur-Profil
Wie oben beschrieben umfasst jedes Achitektur-Profil einen vordefinierten Satz replizierter Pods, um im Fall eines unerwarteten Fehlers kontinuierliche Workflows zu unterstützen. Für jedes Profil werden Beispiele für unterstützte Workflows angegeben.
- Erweitert: Replizierte Pods werden für Veröffentlichungswerkzeuge, Speicher, APIs und Eingangs-Controller mit erhöhter Redundanz bereitgestellt, um im Fall eines unerwarteten Fehlers oder bei Ausfallzeiten die unterbrechungsfreie Nutzung zu unterstützen.
- Standardverfügbarkeit: Replizierte Pods werden für Veröffentlichungswerkzeuge und andere wichtige Pods wie Speicher, APIs und Eingangs-Controller bereitgestellt, um im Fall eines unerwarteten Fehlers oder bei Ausfallzeiten die kontinuierliche Nutzung zu unterstützen.
- Entwicklung: Veröffentlichungswerkzeuge werden repliziert, um mehrere Publisher in einer Organisation zu unterstützen.
Im Folgenden finden Sie eine Beschreibung aller replizierten Pods pro Architektur-Profil.
| Replizierte Pods | Profil für erweiterte Verfügbarkeit | Profil für Standardverfügbarkeit | Entwicklungsprofil |
|---|---|---|---|
PublishingTools | 4 | 3 | 2 |
Privater Eingangs-Controller | 3 | 2 | 2 |
Eingangs-Controller | 3 | 2 | |
Administrator-API | 2 | 2 | |
Portal-API | 2 | 2 | |
Services-API | 2 | 2 | |
In-Memory-Speicher | 2 | 2 | |
Objektspeicher | 3 | 2 | |
Warteschlangenspeicher | 2 | 2 | |
Data Store vom Typ "spatiotemporal" und "Index": Gemischt | 3 | ||
Data Store vom Typ "spatiotemporal" und "Index": Koordinator | 3 | ||
Data Store vom Typ "spatiotemporal" und "Index": Daten | 2 |