Die folgenden Überlegungen drehen sind um die Grundpfeiler der Architektur des ArcGIS Well-Architected Framework. Die angemessene Anwendung der Best Practices und der Architekturstrategien in jedem dieser technischen Bereiche trägt wesentlich zum erfolgreichen Design und der erfolgreichen Implementierung von gut strukturierten Systemen bei.
Weitere Empfehlungen finden Sie unter diesen Überlegungen zum physischen Design.
Die Entscheidung, beim Design Wert auf eine Trennung der Arbeitslasten zu legen, wurde getroffen, um eine optimale Verteilung der Compute-Ressourcen im gesamten System zu erreichen. In der Teststudie dauerte die Verarbeitung von Bearbeitungsanforderungen im Allgemeinen länger als die von Standardkartenanforderungen, sodass Bearbeitungs-Workloads mit dedizierten Compute-Ressourcen in Form einer separaten ArcGIS GIS Server-Site isoliert wurden.
Darüber hinaus trägt die Isolierung der Systemkomponenten selbst auf verschiedene Computer dazu bei, dass sie nicht um Systemressourcen konkurrieren, und bietet die Möglichkeit, Computertypen und -größen an die Systemanforderungen der einzelnen Komponenten anzupassen.
Die Auswahl der richtigen GPU (Graphics Processing Unit) ist wichtig, um die Performance von ArcGIS Pro in einer virtualisierten Umgebung sicherzustellen. Tests haben ergeben, dass das Hinzufügen einer dedizierten GPU zu ArcGIS Pro-VMs die Produktivität der Endbenutzer erheblich verbessert und bei Berücksichtigung der Betriebskosten, z. B. Arbeitskosten, zu einer Nettokostensenkung geführt hat.
Beim Treffen von Designentscheidungen ist es wichtig, das Verhältnis von virtueller CPU (vCPU) zu physischer CPU zu verstehen, damit Systemkomponenten geeignete Ressourcen zugewiesen werden können. Die meisten Instanzen im Schema weisen ein 2:1-Verhältnis zwischen vCPU und CPU auf, ausgenommen davon sind Desktop-Instanzen mit einem Verhältnis von 1:1.
Beachten Sie, dass verschiedene Virtualisierungsoptionen unterschiedliche Verhältnisse aufweisen können. Dies kann nicht nur Auswirkungen auf die Performance haben, sondern auch auf die Lizenzierung von Esri. Beispiele für Public-Cloud-Verhältnisse finden Sie in den folgenden Ressourcen:
Die ordnungsgemäße Konfiguration von GIS-Services ist entscheidend für die Systemleistung und die Zufriedenheit der Benutzer. Eine fehlerhafte Konfiguration von GIS-Service-Instanzen kann zu Problemen oder Herausforderungen bei der Zuverlässigkeit eines Systems führen. Wenn z. B. die Anzahl der Instanzen für einen Karten- oder Feature-Service zu niedrig festgelegt ist, kann dies zu langen Client-Wartezeiten und Timeout-Fehlern führen. Das Konfigurieren von zu vielen Instanzen führt jedoch zu einem übermäßigen Verbrauch von Computerressourcen, wodurch die Anzahl der Services eingeschränkt wird, die auf einer festen Hardwarekonfiguration bereitgestellt werden können.
Wenn die Einstellung der maximalen Instanzen höher als die für die minimalen Instanzen ist, kann das System bei Bedarf automatisch neue Instanzen hinzufügen. Dies kann jedoch auch als Performance-Problem wahrgenommen werden, da eingehende Anforderungen auf den Start der Instanz warten müssen. Für jedes System ist es wichtig, die Nutzung der Services zu verstehen, damit Instanzanzahl und Serverressourcen zum Erzielen einer optimalen Leistung angepasst werden können.
Zu Testzwecken wurde das Verhältnis von Service-Instanzen zu virtuellen CPUs (vCPUs) für jeden Service auf 1:1 festgelegt, wobei die Einstellungen für minimale und maximale Instanzen gleich konfiguriert wurden. Da die GIS- und Hosting-Server-Sites jeweils über zwei Instanzen mit 8 vCPUs verfügten, waren somit 16 Instanzen pro Server-Site vorhanden. Die Instanznutzung wurde überwacht, um festzustellen, wie das System die Last verarbeitete. Wenn zu einem beliebigen Zeitpunkt alle Instanzen auf einem GIS-Server ausgelastet sind, wäre mit hohen Wartezeiten für diesen Service zu rechnen.
Hierbei handelte es sich um die optimale Konfiguration der Service-Instanzen für das Testsystem, die Konfiguration Ihrer Organisation kann jedoch davon abweichen. Überwachung und Telemetriedatenerfassung sind erforderlich, um fundierte Entscheidungen bezüglich der Konfiguration Ihrer Service-Instanz-Einstellungen treffen zu können. Anleitungen finden Sie unter The Art and Science of ArcSOC Optimization.
In dieser Teststudie wurden die Bearbeitungsservices für Parcel Fabrics wie folgt konfiguriert:
Die Hosting-Server (Nur-Anzeigen-Workflows) wurden wie folgt konfiguriert:
Die angegebenen Service-Timeouts wurden wie folgt konfiguriert:
Unsere Timeout-Konfiguration wurde iterativ angepasst, um Timeouts zu beheben, die während des Testprozesses aufgetreten sind. Da diese Einstellungen je nach spezifischen Anforderungen variieren können, wird empfohlen, eigene Tests durchzuführen, um die optimale Konfiguration zu ermitteln.
Sicherungen sind für Flurstücksverwaltungssysteme von entscheidender Bedeutung, wie für die meisten Datenbearbeitungs- und -managementsysteme. Obwohl es sich bei dem getesteten Design nicht um ein Produktivsystem handelte, wurden Maschinen-Snapshots und Datenbanksicherungen für jeden Testlauf und vor Änderungen am System erstellt. Snapshots virtueller Maschinen wurden vor und nach jeder Änderung in der Umgebung erstellt (z. B. Ändern der Größe einer Maschine, Installieren eines Patches oder Aktualisieren von Windows). Die Snapshots wurden dann katalogisiert, um Folgendes zu ermöglichen:
Beachten Sie, dass Snapshots möglicherweise nicht für die Wiederherstellung der Umgebung ausreichen. Einen Überblick über den Sicherungsprozess in ArcGIS Enterprise finden Sie unter Sicherungen und Notfallwiederherstellung.
Weitere Informationen finden Sie unter Referenzarchitektur für Land-Informationsmanagementsysteme.
Die Entscheidung, dieses System mit einer Hochverfügbarkeitskonfiguration von ArcGIS Enterprise-Komponenten zu entwerfen, wurde auf der Grundlage der geschäftlichen und technischen Anforderungen an das System sowie anderer organisatorischer Ziele getroffen, wie z. B. das Erreichen eines unterbrechungsfreien Betriebs und die Minimierung von Ausfallzeiten. Diese Konfiguration wird im Design mit redundanten Systemkomponenten und einem cloudnativen, hochverfügbaren Dateispeicher für das Speichern der Dateien verdeutlicht. In dieser Teststudie wurde keine hochverfügbare Datenbank zu Testzwecken konfiguriert, obwohl Anbieter relationaler Datenbanken über eine Vielzahl von Methoden verfügen, um Hochverfügbarkeit zu erreichen, einschließlich cloudnativer Services.
Denken Sie daran, dass Hochverfügbarkeitskonfigurationen die Infrastruktur- und Betriebskosten des Systems erheblich erhöhen können und zum Sichern des Erfolgs spezielle Fähigkeiten erfordern. Weitere Informationen zu Entscheidungen und Überlegungen zum Design in Bezug auf Hochverfügbarkeit für ein Flurstücksverwaltungssystem.
Um eine erfolgreiche Systemprüfung durchzuführen und aussagekräftige Ergebnisse zu liefern, waren Systemüberwachung und Telemetriedatenerfassung Schlüsselaspekte der Teststudie.
ArcGIS Monitor und IT-Überwachungswerkzeuge für Unternehmen wie Windows Performance Monitor wurden verwendet, um die Performance des Systems zu überwachen und Telemetriedaten zu seinem Verhalten unter bestimmten Bedingungen zu erfassen. Die Protokolle wurden über verschiedene Systemkomponenten hinweg gesammelt, darunter:
Kennwerte auf Computerebene wie CPU-Auslastung, RAM-Verbrauch, Festplattenaktivität und Netzwerkaktivität wurden auf allen Computern in der Umgebung erfasst. Weitere Informationen finden Sie in den Testergebnissen.
Darüber hinaus wurden Bildschirmaufzeichnungen von durchgeführten Workflows aufgenommen, um die User Experience und Produktivität zu beobachten und zu bewerten.
Da sich der Umfang der Teststudie in erster Linie auf Lasttests konzentrierte, wurden die meisten Arten der Automatisierung, die für ein Produktivsystem empfohlen sind, z. B. die Skripterstellung für Verwaltungs-Tasks, nicht verwendet. In Ihrer Umgebung können Verwaltungsskripts jedoch einen erheblichen Mehrwert für Workflows und Abläufe haben. Alle Automatisierungsskripts sollten vor der Bereitstellung im Produktivsystem in einer “niederen” Umgebung getestet werden.
In dieser Teststudie bestand die primäre Anwendung der Automatisierung darin, Anforderungen während Lasttests zu simulieren. Mehrere Workflows wurden mit virtuellen Benutzern in großem Umfang ausgeführt, mit der Möglichkeit, sie auf unterschiedliche Lastgrößen anzuwenden, wie in den Testergebnissen veranschaulicht.
Python-Skripte wurden verwendet, um Analysen durchzuführen und Muster in den Wartezeiten von Services, der Auslastung von Service-Instanzen, den Antwortzeiten und fehlgeschlagenen Anforderungen zu identifizieren, um über erforderliche Systemänderungen zu informieren. Python-, PowerShell- und SQL-Skripte wurden auch verwendet, um die Datenbank nach Abschluss eines Lasttests in den ursprünglichen Zustand zurückzusetzen.
Sicherheit ist ein wesentlicher Aspekt für alle Enterprise-IT-Systeme, einschließlich Authentifizierung und Autorisierung, Filterung, Verschlüsselung, Überwachung sowie Härtung. Die ArcGIS-Software ist für die effektive Arbeit in sicheren Netzwerken konzipiert, auch in solchen, die vollständig vom Internet getrennt sind. Es ist wichtig, die Sicherheitsanforderungen für jedes Produktivsystem frühzeitig beim Design zu berücksichtigen.
Auch wenn der Fokus bei dieser Teststudie nicht auf Sicherheit lag, wurde ein Identity-Provider verwendet, um eine ordnungsgemäße Benutzerauthentifizierung und -autorisierung zu gewährleisten, wie im Schema der physischen Architektur ersichtlich ist. Die Subnetzsegmentierung ist eine weitere grundlegende Sicherheitsmaßnahme, die in dieser Teststudie angewendet wurde und auf den Prinzipien der geringsten Berechtigung und der Netzwerkisolation beruht.
Zugehörige Ressourcen:
Obwohl die Integration nicht im Rahmen der Teststudie lag, erfordert ein Flurstücksverwaltungssystem häufig die Integration mit anderen Unternehmenssystemen wie CAMA-Systemen (Computer Aided Mass Appraisal). Weitere Informationen zu Überlegungen zur Integration mit ArcGIS.