Service-Skalierung

Nach dem Veröffentlichen von GIS-Services empfiehlt es sich, diese – beispielsweise anhand der Service-Nutzungsstatistiken – zu überwachen, um die Nutzungsmuster zu verstehen und einen Überblick zu erhalten, wie Ressourcen basierend auf dem beobachteten Datenverkehr angepasst werden können. Wenn die Datenverkehrsmuster und Benutzeranforderungen an Ihre Services Schwankungen unterliegen, können Sie auf verschiedene Arten auf die Veränderungen reagieren. Um dem Bedarf und den Erwartungen an die Performance gerecht zu werden, haben Sie die folgenden Möglichkeiten zur Optimierung der Service-Ressourcen:

  • Passen Sie den Service-Modus an, um die dedizierten Ressourcen für einen Service zu maximieren.
  • Skalieren Sie Services manuell durch Angabe der Anzahl der Pods, die einem Service zugewiesen werden sollen.
  • Aktivieren Sie die automatische Skalierung, indem Sie einen Schwellenwert festlegen, auf dessen Grundlage einem Service automatisch Pods zugewiesen werden.

Berücksichtigen Sie bei der Entscheidung für eine der genannten Optionen die folgenden Szenarien.

Skalierungstypen

Sie können Services manuell oder mithilfe der entsprechenden Funktion automatisch skalieren. In beiden Fällen werden die Services horizontal (durch mehr oder weniger Pod-Instanzen) oder vertikal (durch mehr oder weniger Ressourcen) skaliert. Services können unabhängig davon skaliert werden, ob sie für den geteilten oder dedizierten Modus konfiguriert wurden.

  • Horizontale Skalierung: Einer Service-Bereitstellung werden weitere Pods hinzugefügt. Ein Beispiel hierfür wäre die Skalierung von einem Pod auf mehrere. Dies wird bei manueller und automatischer Skalierung unterstützt.
  • Vertikale Skalierung: Der aktuellen Pod-Gruppe in einer Bereitstellung wird CPU- oder Speicherkapazität hinzugefügt. Dies wird bei manueller Skalierung unterstützt.

Wenn Sie die Anzahl der verfügbaren Pods für einen Service erhöhen, werden durch den Kubernetes-Cluster zusätzliche Replikate von vorhandenen Pods der Service-Bereitstellung erstellt. Darunter fallen ebenfalls Service-Konfiguration und Service-Instanzen innerhalb der Pods.

Durch die Skalierung wird außerdem die Verfügbarkeit und der Gesamtdurchsatz der Instanzen für den Service, allerdings auch dessen Speicher- und CPU-Verbrauch, erhöht. Da es sich um eine Skalierung Ihrer Kubernetes-Infrastruktur handelt, ist diese Option fehlertolerant: Pods, die ausfallen, werden ohne Auswirkungen auf andere Pods automatisch wiederhergestellt. Zudem ermöglicht dies eine unabhängige und isolierte Skalierung ohne Auswirkungen auf andere Services oder Komponenten im System.

Hinweis:

Der Kubernetes-Cluster, in dem Ihre Organisation bereitgestellt ist, enthält eine endliche Anzahl von Computerknoten. Werden in Ihrer Organisation viele GIS-Services manuell oder automatisch skaliert, kann die maximale Anzahl an Computerressourcen für ArcGIS Enterprise on Kubernetes erreicht werden. Wenden Sie sich in diesem Fall an Ihren IT-Administrator, damit dem Kubernetes-Cluster weitere Knoten hinzugefügt werden. Auch Cluster Autoscaler kann in Ihrer Umgebung hier eine Lösung darstellen.

Horizontale Skalierung

Bei der horizontalen Skalierung werden einer Service-Bereitstellung weitere Pods hinzugefügt. Ein Beispiel hierfür wäre die Skalierung von einem Pod auf mehrere. Diese Methode wird sowohl bei manueller als auch bei automatischer Skalierung unterstützt.

Horizontale Skalierung für einen dedizierten Geoverarbeitungsservice

Das Beispiel oben veranschaulicht die horizontale Skalierung für einen im dedizierten Modus ausgeführten Geoverarbeitungsservice. Wenn zusätzliche Pods benötigt werden, wird die Service-Bereitstellung manuell oder automatisch entsprechend angepasst. In diesem Beispiel wird der Service-Bereitstellung ein zusätzliches Pod-Replikat hinzugefügt.

Im folgenden Beispiel wird eine geteilte Feature-Service-Bereitstellung horizontal skaliert, indem der Bereitstellung Pod-Replikate hinzugefügt werden. In der ursprünglichen Gruppe der geteilten Ressourcen werden drei Feature-Services von vier Pods unterstützt. Im Zuge der Zunahme des konstanten Bedarfs wurde die Anzahl der Pods in der Service-Bereitstellung auf acht erhöht.

Horizontale Skalierung für eine geteilte Feature-Service-Bereitstellung

Vertikale Skalierung

Bei der vertikalen Skalierung wird der aktuellen Pod-Gruppe in einer Bereitstellung CPU- oder Speicherkapazität hinzugefügt. Diese Methode wird bei manueller Skalierung unterstützt.

Vertikale Skalierung für einen dedizierten Image-Service

Das Beispiel oben veranschaulicht die vertikale Skalierung für einen im dedizierten Modus ausgeführten Image-Service. Wenn zusätzliche Kapazität benötigt wird, können ein oder mehrere dedizierte Pods manuell oder automatisch entsprechend angepasst werden. In diesem Fall werden dem Pod mehr Ressourcen (CPU, Speicher oder beides) zugewiesen.

In einem anderen Beispiel werden die Ressourcen vertikal herunterskaliert, wenn für einen Kartenservice im dedizierten Modus keine zusätzlichen Ressourcen mehr erforderlich sind.

Vertikale Skalierung für einen dedizierten Kartenservice

Im folgenden Beispiel wird eine geteilte Kartenservice-Bereitstellung vertikal skaliert. Wenn CPU- oder Speicherkapazität benötigt wird, können die dedizierten Pods entsprechend angepasst werden. In diesem Fall werden den drei beteiligten Pods mehr CPU- oder Speicherressourcen zugewiesen.

Vertikale Skalierung für eine geteilte Kartenservice-Bereitstellung

Szenarien

Um Performance-Anforderungen gerecht zu werden und gleichzeitig die Ressourcen der Organisation zu schonen, ist es entscheidend, Zeitpunkt sowie Art und Weise der Ressourcenskalierung sinnvoll zu wählen. Die folgenden Beispiele stellen hypothetische Szenarien dar, die Organisationsadministratoren bei der Skalierung der Ressourcen in Betracht ziehen sollten:

  • Bei einer Webkarte in einer öffentlichen Organisation hat das Datenaufkommen unerwartet zugenommen, und Benutzer stellen Performance-Verzögerungen fest. Der Organisationsadministrator prüft die Systemprotokolle und findet heraus, dass ein von der Webkarte genutzter Kartenservice überlastet ist. Zunächst ändert er möglicherweise den Service-Modus so, dass nicht mehr geteilte Ressourcen, sondern dedizierte Ressourcen verwendet werden. Als Nächstes kann er die Anzahl der Pod-Replikate für die Bereitstellung dieses Service erhöhen. Durch die Angabe dedizierter Ressourcen für den Kartenservice stellt der Administrator sicher, dass das hohe Datenaufkommen für den Service ohne Performance-Probleme verarbeitet wird.
  • Ein Vermessungsunternehmen hat Hunderte von Feature-Services in der Organisation angesammelt. Für alle Services ist der geteilte Modus festgelegt, daher werden sie von einer einzelnen Service-Bereitstellung unterstützt. Für keinen der Services wird starker Datenverkehr verzeichnet, aber die Gesamtnutzung von GIS-Inhalten in der Organisation überlastet die Service-Bereitstellung. Der Organisationsadministrator kann den Service manuell skalieren, indem er die Anzahl der Pod-Replikate in der Service-Bereitstellung erhöht. Durch weitere aktive geteilte Instanzen wird der Datenverkehr an die zahlreichen Feature-Services der Organisation ordnungsgemäß verarbeitet.
  • Im Rahmen eines Projekts zur Inhaltsmigration veröffentlicht die GIS-Abteilung einer Stadt zahlreiche Webkarten und -Layer erneut für ihre Organisation. Aufgrund zeitlicher Beschränkungen soll das Projekt schnell abgeschlossen werden. Da die Veröffentlichung der zugrunde liegenden Webkarten und -Layer mit dem Utility-Service "PublishingTools" durchgeführt wird, bestimmt sich die Geschwindigkeit der Veröffentlichung aus den Computerressourcen, die dem Utility-Service zur Verfügung stehen. Der Organisationsadministrator erhöht vorübergehende die Anzahl von Pod-Replikaten in der Bereitstellung des PublishingTools-Service, um im Rahmen des Projekts die Effizienz bei der Veröffentlichung zu steigern. Nach Projektabschluss wird die Anzahl an Pod-Replikaten in der Service-Bereitstellung gesenkt, um die Computerressourcen zu schonen.
  • In den ersten beiden oben beschriebenen Szenarien (überlasteter Kartenservice oder gleichzeitige Verwendung einer großen Anzahl von Feature-Services mit resultierender Überlastung des Systems) ist die manuelle Skalierung der dedizierten Kartenservice- bzw. der geteilten Feature-Service-Bereitstellung möglicherweise nicht die praktikabelste Methode. Eine manuelle Skalierung erfordert die ständige Überwachung der Last sowie Einblick in die Lastmuster zur Ermittlung der Anzahl von Pods, auf die skaliert werden muss. Bei zeitweilig auftretenden, unvorhersehbaren Lasten führt manuelles Hinzufügen einer großen Anzahl von Pods zu Ressourcenverschwendung, wenn das System keinen großen Lasten unterliegt. Umgekehrt soll eine Skalierung des Systems möglich sein, wenn für stärkere Lasten mehr Pods erforderlich sind.

    Hier kann die Nutzung der automatischen Skalierung die optimale Lösung darstellen. Mithilfe der automatischen Skalierung können Sie eine Mindestanzahl von Pods beibehalten und eine maximale Anzahl von Pods festlegen, auf die das System basierend auf den festgelegten CPU-Schwellenwerten skaliert wird. Mit dieser Methode wird automatisch erkannt, wann die Anzahl der Pods in Abhängigkeit von Laständerungen erhöht oder verringert werden muss. Dadurch entfällt die Notwendigkeit zur kontinuierlichen Überwachung eines Systems, und es können Ressourcen eingespart werden.

Anpassen des Service-Modus

Wenn ein Karten- oder Feature-Service, der geteilte Ressourcen verwendet, konstant Datenverkehr erhält, können Sie den Service-Modus anpassen und auf die Verwendung dedizierter Ressourcen umstellen. Dadurch wird ein neuer Service-Ressourcenpool geöffnet, der diesem Service zugewiesen ist.

Manuelle Skalierung

Wenn der Service-Bedarf vorhersehbar oder konstant ist, können Sie eine Service-Bereitstellung manuell skalieren, indem Sie die Anzahl der Pods angeben, die einem Service zugewiesen werden, oder indem Sie die für den Service verfügbaren Ressourcen (CPU/Speicher) erhöhen. Dies ist sinnvoll, wenn die Anzahl der dedizierten Ressourcen für den Service nicht ausreicht und Benutzer Performance-Verzögerungen feststellen.

Wenn Sie nach der Überwachung des Service feststellen, dass der Bedarf gestiegen ist oder wenn Leistungsprobleme für den Service gemeldet werden, können Sie die Anzahl der Pods bedarfsgerecht erhöhen. Wenn der Bedarf wieder sinkt, können Sie die Anzahl der Pods verringern.

Automatische Skalierung

Bei unvorhersehbarem oder zeitweiligem Service-Bedarf können Sie die automatische Skalierung aktivieren, um die Effizienz der Systemressourcen zu maximieren.

Bei Aktivierung der automatischen Skalierung für einen Service wird die Anzahl der Pod-Replikate in einer Service-Bereitstellung automatisch bedarfsgerecht erhöht oder verringert. Für die Service-Bereitstellung werden die von Ihnen vordefinierten Kriterien wie CPU oder Speicher herangezogen, um den Bedarf nach mehr oder weniger Pods zu berechnen, und die entsprechende Anpassung wird vorgenommen.

Hinweis:

Damit die automatische horizontale Podskalierung in ArcGIS Enterprise on Kubernetes genutzt werden kann, muss der Metrics Server Kennwerte zum Pod-Ressourcenverbrauch aus dem Kubelet-Prozess der einzelnen ausgeführten Knoten auslesen. Weitere Informationen hierzu finden Sie unter Kubernetes Metrics Server.

Rolle von Service-Instanzen

Service-Bereitstellungen, die nicht gehostet werden, beispielsweise Karten-, Image-, Geoverarbeitungs- oder Geokodierungsservices, enthalten Service-Instanzen, die in den einzelnen Pods einer Service-Bereitstellung ausgeführt werden. Diese repräsentieren die Kapazität der einzelnen Pods und bilden die zugrunde liegenden Prozesse für die Verarbeitung von Anforderungen bei einem dieser Services. Die Anpassung und Skalierung dieser Prozesse wird unterstützt. Es wird jedoch empfohlen, stattdessen eine Anpassung und Skalierung auf Pod-Ebene vorzunehmen, um die Vorteile (Fehlertoleranz, Isolation, Resilienz, automatische Skalierung usw.) zu nutzen, die Kubernetes bietet.