Bei jedem Softwarepaket oder -system ist die Planung von Upgrades, Wartung und Patches ein wichtiger Teil des Architekturentwurfsprozesses. Sie können zwar eine bestimmte Version eines Systems bereitstellen, aber wenn Aktualisierungen vorgenommen und Sicherheitsprobleme entdeckt werden und Benutzer mit dem System interagieren, müssen unweigerlich Patches, Aktualisierungen oder Upgrades auf das System angewendet werden.
Selbst bei vollständig verwalteten SaaS-Systemen wie ArcGIS Online müssen Sie Patches und Upgrades berücksichtigen. Auch wenn die Aktualisierung von ArcGIS Online möglicherweise keine Aktionen von Benutzern des Systems erfordert, sind die ordnungsgemäße Planung der angekündigten neuen Funktionen, die sorgfältige Überwachung von Inhalten und Workflows nach einem Upgrade und das Melden von Problemen, falls sie auftreten, Bestandteile eines erfolgreichen Upgrade- und Patch-Fensters.
Der Begriff “Patches” kann auf fast jede Software angewendet werden, aber in ArcGIS bezieht er sich im Allgemeinen auf bestimmte Software-Aktualisierungen, die zwischen offiziellen Softwareversionen oder für eine frühere Version bereitgestellt werden, um eine Funktionslücke, einen identifizierten Softwarefehler oder ein Problem zu beheben. Im Allgemeinen werden mit Patches keine neuen Funktionen eingeführt, und sie werden nur für eine gewisse Zeit nach der Softwareveröffentlichung geprüft, erstellt und angeboten, wie im Produktlebenszyklus der Software angegeben. Ein Beispiel finden Sie unter ArcGIS Enterprise-Produktlebenszyklus.
Die Ansätze für Patches variieren für die verschiedenen Kategorien von ArcGIS-Produkten, einschließlich ArcGIS Online, ArcGIS Enterprise und anderen Client-Apps.
Für ArcGIS Online werden Patches für alle Probleme angewendet, die in dem Zeitraum direkt nach dem Veröffentlichungsdatum einer neuen Softwareversion identifiziert werden. Nach dieser Anfangsphase werden bis zur nächsten regulären, geplanten Version von ArcGIS Online keine Patches mehr angewendet. Da es sich um ein SaaS-Produkt handelt, sind in Bezug auf Patches keine Benutzeraktionen erforderlich. Die Patches werden direkt und unsichtbar für Benutzer angewendet. Zudem gibt es keine Patches für ältere Versionen, da den Benutzern jeweils nur eine Version von ArcGIS Online zur Verfügung steht: die aktuelle Version.
Für ArcGIS Enterprise werden Patches als herunterladbare, installierbare Dateien für Windows und Linux bereitgestellt. In Kubernetes werden sie direkt von der Software angewendet. Patches können über die Esri Support-Website gefunden, heruntergeladen und angewendet werden. Sie können auch mit dem Werkzeug Auf ArcGIS Enterprise-Updates überprüfen, das in ArcGIS Enterprise enthalten ist, gesucht und direkt auf das System angewendet werden. Weitere Informationen zu diesem Vorgang finden Sie in der ArcGIS Enterprise-Dokumentation.
Das Anwenden von Patches auf ArcGIS Enterprise-Komponenten sollte im Hinblicke auf Ausfallzeiten des Zielsystems sorgfältig geplant werden. Die meisten Patches erfordern einen Neustart der Softwarekomponente, die gepatcht wird. Dies führt zu einer kurzen Ausfallzeit, während der Service oder die Komponente neu gestartet wird. Informationen zu hoch verfügbaren Systemen finden Sie unter Anwenden von Patches und Aktualisierungen auf hoch verfügbare Komponenten. Patches können nach einer ersten Softwareinstallation (sofern bereits veröffentlicht) oder über Automatisierungswerkzeuge wie Chef oder PowerShell DSC bereitgestellt werden.
In jedem Fall sollte das Patchen geplant und gezielt sein und in Abstimmung mit den IT-Patching-Verfahren für andere Softwarekomponenten oder das Betriebssystem erfolgen. Das Patchen einer Komponente wirkt sich häufig auf andere Komponenten aus. Es ist im Allgemeinen von Vorteil, Patches in einem Fenster oder Zeitraum zu kombinieren, um Ausfallzeiten für Benutzer zu reduzieren. Geplantes Patchen bedeutet, die Reihenfolge der zu patchenden Komponenten sorgfältig zu überdenken und sicherzustellen, dass der Patching-Mechanismus, entweder ein automatisierter oder ein von Mitarbeitern verwalteter Prozess, diesem Design und Plan folgt.
Patches können in der Regel rückgängig gemacht oder deinstalliert werden, wenn Probleme festgestellt werden, sie sind aber so konzipiert, dass sie kumulativ sind. Es können also mehrere Patches auf ein System angewendet werden, sobald sie veröffentlicht werden, ohne eine bestimmte, definierte Reihenfolge oder eine Definition der Wichtigkeit. In einigen Fällen beziehen sich Patches auf bestimmte Funktionen, in anderen können sie allgemeine Sicherheitsaktualisierungen bereitstellen. Daher wird empfohlen, alle ArcGIS Enterprise-Patches anzuwenden, sobald sie veröffentlicht werden.
Aktualisierungen für ArcGIS Pro, insbesondere Patches für eine bereits installierte Version, die mit dem Nummerierungsansatz “Haupt.Neben.Patch” gekennzeichnet sind, werden regelmäßig veröffentlicht. Dies gilt in der Regel jedoch nur für die neueste Version der Software, mit Ausnahme bestimmter Versionen, die sich auf die Versorgungsbranche oder außergewöhnliche Szenarien für Sicherheitspatches konzentrieren. Patches werden in der Regel direkt in der Anwendung angewendet. Dadurch werden Benutzer, die bei einem ArcGIS Online-Konto angemeldet sind, über die Verfügbarkeit einer Aktualisierung informiert. Aktualisierungen erfordern in der Regel die entsprechenden Berechtigungen für die Installation von Software, können aber ansonsten von Benutzern nach Bedarf und eigenem Ermessen installiert werden.
ArcGIS Pro-Patches können auch mithilfe von Softwareautomatisierung wie Microsoft System Center automatisiert und bereitgestellt werden. Aktualisierungen von ArcGIS Pro sollten für große ArcGIS Pro-Organisationsbereitstellungen sorgfältig geplant werden, damit die Benutzer die Versionskonsistenz in der gesamten Organisation aufrechterhalten können, da dies die Kompatibilität fördert und den technischen Support unterstützt.
Aktualisierungen für andere Client-Anwendungen jenseits von ArcGIS Pro werden je nach Anwendung unterschiedlich gehandhabt. Beispielsweise wird ArcGIS Experience Builder Developer Edition kurz nach jeder Version von Experience Builder für ArcGIS Online veröffentlicht, und in der Regel werden keine Patches bereitgestellt. Für mobile ArcGIS-Anwendungen wie Field Maps oder Survey123 werden Patches direkt im entsprechenden App Store bereitgestellt. Die Benutzer erhalten die Aktualisierung in der Regel automatisch, da mobile Betriebssysteme meist Anwendungen automatisch und im Hintergrund aktualisieren. Bei Anwendungen, die in ArcGIS Enterprise konfiguriert sind, können Patches für die ArcGIS Enterprise-Software Änderungen an diesen Funktionen enthalten, sie werden jedoch außerhalb des Portal for ArcGIS-Patching-Prozesses nicht einzeln gepatcht.
Das Patchen von Betriebssystemen liegt in der Regel außerhalb der Kontrolle oder der Verantwortung eines GIS-Softwareteams. Da Unternehmenssysteme jedoch zunehmend auf IT-Standards abgestimmt sind, ist ein klarer Plan für das Patchen von Betriebssystemen eine Voraussetzung für ein gut durchdachtes Design. Die meisten IT-Organisationen von Unternehmen verfügen bereits über einen Standardansatz für Patches. Daher besteht der erste Schritt darin, die wahrscheinlichen Auswirkungen auf ein ArcGIS-System zu untersuchen und herauszufinden, wie etwaige Auswirkungen möglicherweise abgemildert werden können.
Das Patchen des Betriebssystems erfolgt normalerweise regelmäßig, z. B. einmal pro Woche, einmal im Monat oder in einem anderen Intervall. Einige Patching-Ansätze sind störend und erzwingen eine Aktualisierung des Betriebssystems durch einen plötzlichen Neustart. Andere weisen Programme und Services dagegen eleganter an, herunterzufahren und dann neu zu starten und Patches anzuwenden oder sogar Patches ohne Neustart auf das System anzuwenden. In allen Fällen wird empfohlen, das System ordnungsgemäß herunterzufahren, bevor Aktualisierungen angewendet werden, da der störendere Ansatz zu Problemen mit Komponenten für Datenpersistenz in der Software führen oder laufende Aufträge wie Geoverarbeitungs-Tasks unerwartet beenden kann.
Betriebssystemaktualisierungen können auch unerwartete Probleme mit Software verursachen, die im System bereitgestellt wurde. Sie sollten sorgfältig nachverfolgt und aufgezeichnet werden, damit eine Aktualisierung zurückgesetzt werden kann, wenn Probleme entdeckt werden. Esri überprüft und implementiert Betriebssystem-Patches, um die Kompatibilität sowie potenzielle Konflikte oder Probleme zu verstehen, und gibt Warnhinweise für problematische Betriebssystemaktualisierungen oder -konfigurationen heraus, sobald diese identifiziert werden.
Ein Upgrade bezieht sich speziell auf das Upgrade auf eine neue Haupt- oder Nebenversion von Software, statt eine vorhandene Version zu patchen. Upgrades können nahtlos sein, z. B. in einem SaaS-System, oder etwas störend, wenn lokale Software verwendet wird. In der Regel sind sie ein sorgfältig geplanter, verwalteter und getesteter Prozess. Upgrades sind jedoch unerlässlich, um Benutzern Zugriff auf die neuesten Technologien, Funktionen und Angebote zu verschaffen. In den meisten Unternehmenssystemen, die mit ArcGIS erstellt wurden, sollten sie regelmäßig durchgeführt werden.
Das Upgrade von ArcGIS Enterprise ist ein gut dokumentierter und sorgfältig getesteter Prozess, der in der offiziellen Dokumentation beschrieben wird. Das Thema Überlegungen behandelt wichtige Entscheidungen im Zusammenhang mit Upgrades und sollte zu Beginn des Planungsprozesses für ein Upgrade durchgesehen werden. Wenn Ihre Organisation ein Upgrade nur langsam durchführt oder es vorzieht, über einen längeren Zeitraum bei einer einzigen Version zu bleiben, stellen Sie sicher, dass Sie Long-Term-Support-Versionen von ArcGIS Enterprise bereitstellen.
Upgrades für ArcGIS Enterprise-Komponenten sollten immer eine Sicherung des Systems umfassen, entweder über VM-Snapshots, das Werkzeug webgisdr oder einen anderen Mechanismus, damit das System wiederhergestellt werden kann, wenn erhebliche Probleme festgestellt werden.
Upgrades der meisten spezifischen ArcGIS-Webanwendungen, wie z. B. Experience Builder oder Instant Apps, sind für Benutzer weitgehend unsichtbar, da sie entweder Teil des ArcGIS Online- oder des ArcGIS Enterprise-System-Upgrades sind (und daher automatisch als Teil des größeren Upgrades angewendet werden) oder automatisch vom Betriebssystem durchgeführt werden (im Fall von mobilen Anwendungen).
Aufgrund der Beziehung zwischen ArcGIS Pro, räumlichen Datenbanken, die als Enterprise-Geodatabases aktiviert sind, und ArcGIS Enterprise oder ArcGIS Online verdient ArcGIS Pro eine besondere Beachtung. Während die meisten Versionen von ArcGIS Pro eine Verbindung mit den meisten Versionen von ArcGIS Enterprise herstellen können und ältere Versionen von ArcGIS Pro für die Veröffentlichung in ArcGIS Online verwendet werden können, gibt es einige wichtige Details:
Eine weitere Komponente, die zusammen mit der Desktop- und Enterprise-Software aktualisiert werden muss, sind die Geodatabase-Systemtabellen, die in einer relationalen Datenbank erstellt werden, wenn eine Enterprise-Geodatabase erstellt oder aktiviert wird. Geodatabase-Upgrades werden für jeden einzelnen Datenbankanbieter dokumentiert und über ArcGIS Pro oder ein Python-Werkzeug durchgeführt. Sie sind in der Regel schnell abgeschlossen, können aber störend sein, da sie erfordern, dass alle Benutzer- und Systemverbindungen während des Upgrades unterbrochen oder von der Datenbank getrennt werden, damit relevante Tabellen und Funktionen geändert werden können. Es wird empfohlen, eine Enterprise-Geodatabase vor einem Geodatabase-Upgrade auf Datenbank- oder Schemaebene zu sichern.
Upgrades des Betriebssystems verdienen besondere Aufmerksamkeit, da sie zunehmend von IT-Abteilungen angefordert oder implementiert werden, die sowohl Clients (Laptops oder Desktop-Computer von Benutzern) als auch Server auf neuere Versionen von Betriebssystemen bringen, wenn ältere Versionen nicht mehr unterstützt oder eingestellt werden. Aktualisierungen des Betriebssystems eines aktiven, funktionierenden Systems sind möglich und können erfolgreich sein, gelten jedoch als riskanter als das Bereitstellen neuer VMs mit einer gewünschten Betriebssystemversion und das Migrieren einer Bereitstellung zu diesem System.
Obwohl Benutzer mit direkten Upgrades des Betriebssystems erfolgreich waren, besteht das mögliche Hauptrisiko darin, dass alle auftretenden Probleme wahrscheinlich speziell mit dem Upgrade des Betriebssystems zusammenhängen und in einer einfachen Bereitstellung möglicherweise nicht reproduzierbar sind. Daher kann es schwieriger sein, effektive Hilfe vom technischen Support von Esri zu erhalten, da die Probleme außerhalb der Esri Komponenten auftreten. Arbeiten Sie eng mit dem IT-Support zusammen, um die Auswirkungen sowie die Sicherungs- und Wiederherstellungsmöglichkeiten im Zusammenhang mit einem Upgrade des Betriebssystems zu verstehen.