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.
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 die Entscheidung getroffen wurde, Bearbeitungs-Workloads mit dedizierten Compute-Ressourcen in Form einer separaten ArcGIS GIS Server-Site zu isolieren. 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 (Arbeitskosten) zu einer Nettokostensenkung geführt hat. Weitere Informationen zur Auswahl der GPU-Hardware und zur ArcGIS Pro-Virtualisierung finden Sie im ArcGIS Architecture Center.
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. Es gibt ein Verhältnis von 2:1 von vCPU:CPU für alle Maschinen im Schema, aber einige Virtualisierungsoptionen können andere Verhältnisse haben, z. B. 1:1. Diese Entscheidungen können sich auch auf die Lizenzierung von Esri auswirken. Einige Beispiele für Public-Cloud-Verhältnisse umfassen AWS, Azure und GCP.
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.
Wenn Sie die Instanzanzahl jedoch zu hoch einstellen, kann dies zu einem übermäßigen Verbrauch von Computerressourcen führen, 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 problematisch sein, 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.
In dieser Teststudie wurde das Verhältnis von Service-Instanzen zu physischen CPU-Kernen für jeden relevanten Service auf 2:1 festgelegt, wobei die Einstellungen für minimale und maximale Instanzen auf denselben Wert konfiguriert wurden. Die Instanznutzung wurde überwacht, um festzustellen, wann das System überlastet war. Bei einer 8-mal höheren Auslegungslast wurden beispielsweise die Service-Instanzen für einen Service auf dem Hosting-Server für 99 % des Testzeitraums als aktiv beobachtet, was zu hohen Wartezeiten bei schreibgeschützten Services führte. Die Services in diesem Test wurden für dedizierte Instanzen konfiguriert. Weitere Informationen zum Konfigurieren von Service-Instanz-Einstellungen.
In dieser Teststudie wurden die Versorgungsnetzservices wie folgt konfiguriert:
Die Gesamtzahl der verfügbaren Instanzen betrug 16, da die Site zwei ArcGIS-GIS-Server umfasst hat. Die Hosting-Server wurden wie folgt konfiguriert:
Die Gesamtzahl der verfügbaren Instanzen betrug 12, da die Site zwei ArcGIS-GIS-Server umfasst hat.
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 Netzwerk-Informationsmanagementsysteme von entscheidender Bedeutung. Weitere Informationen finden Sie unter Referenzarchitektur. 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:
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 Netzwerk-Informationsmanagementsystem.
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. 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 ArcSOC-Auslastung, 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.
Obwohl die Sicherheit nicht im Mittelpunkt der Teststudie stand, ist es wichtig, die Sicherheitsanforderungen für jedes Produktivsystem frühzeitig beim Design zu berücksichtigen. Die ArcGIS-Software wurde für die effektive Arbeit in sicheren Netzwerken entwickelt, auch in solchen, die vollständig vom Internet getrennt sind. Das Design der Teststudie umfasst die Verwendung eines Identity-Provider, um eine ordnungsgemäße Authentifizierung und Autorisierung zu gewährleisten.
Zugehörige Ressourcen:
Obwohl Integrationen nicht im Rahmen der Teststudie lagen, erfordert ein Netzwerk-Informationsmanagementsystem häufig die Integration mit anderen Unternehmenssystemen wie Enterprise Asset Management (EAM), Customer Relationship Management (CRM) und Advanced Distribution Management (ADMS). Zusätzlich zu den standardmäßigen Überlegungen zur Integration in ArcGIS sind für die ArcGIS Utility Network-Funktion weitere Anforderungen zu berücksichtigen. Abhängig von den Integrationsanforderungen können unterschiedliche APIs und/oder SDKs unterstützt werden. Weitere Informationen finden Sie unter Journey to the Utility Network: Integrations Overview.