Dokumente zu Systemarchitektur und Performance Hardware-Empfehlungen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
AED-SICAD
Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
Autoren: Helmut Röhl, Dr. Martin Ameskamp
Status: Abgestimmt
Version: 6
Datum: 08.10.2020
Datei: DSP-Hardwareempfehlungen.docx
Seite 1 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
Änderungsübersicht
Version Datum Änderungsgrund betroffene Bearbeiter
Abschnitte
1 27.11.2014 Gemeinsames Hardware-Dokument alle Ameskamp, Röhl
für PS und UT
2 21.08.2016 Aktualisiert alle Ameskamp
3 11.11.2016 Ergänzt um weitere Komponenten und 1.5-1.8, 2 Ameskamp
Desktop
4 23.08.2016 Verweise Passmark 1.1, 2 Ameskamp
5 13.06.2019 Performanceanforderungen aktuali- 1.1, 1.8, 2 Röhl
siert
6 08.10.2020 Aktualisierung: Passmark Werte als Hernández (Input
Referenz Serfling, Röhl)
Seite 2 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
Inhalt
1 Hardware-Parameter und Technologien Server ............................................................................4
1.1 Anforderungen an die CPU ...................................................................................................4
1.2 Hyperthreading .....................................................................................................................5
1.3 Power Management ..............................................................................................................5
1.4 Virtualisierung .......................................................................................................................5
1.5 Hauptspeicher .......................................................................................................................6
1.6 Massenspeicher ....................................................................................................................6
1.7 LAN ......................................................................................................................................6
1.8 Betriebssysteme ...................................................................................................................6
2 Desktop/Mobil ..............................................................................................................................7
Seite 3 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
1 Hardware-Parameter und Technologien Server
Für eine Systemumgebung zum performanten Betrieb einer ArcGIS-basierten Installation inkl. Web-
Services (im Folgenden kurz als „GIS“ bezeichnet) sind für Server-Maschinen die folgenden Randbe-
dingungen zu beachten
1.1 Anforderungen an die CPU
Viele Anwendungen, z.B. im Office-Bereich, sind dadurch geprägt, dass die CPU-Last, die durch eine
Interaktion des Anwenders ausgelöst wird, ziemlich klein ist: Wenn in einem Textverarbeitungspro-
gramm ein Zeichen eingefügt oder ein Wort selektiert wird, sind die für die Verarbeitung dieser Aktion
benötigten CPU-Zeiten sehr klein, z.B. < 1 ms. Der Anwender empfindet die Reaktion als unmittelbar
und unterscheidet nicht, ob eine schnelle CPU 1 ms oder eine langsame CPU 4 ms gearbeitet hat. Im
GIS-Bereich (sowohl im Desktop als auch im Web) muss das System typischerweise deutlich mehr
arbeiten, um auf eine Benutzerinteraktion zu reagieren, z.B. einen Bildschirm neu aufbauen oder eine
neue Karte für eine Navigationsdarstellung erzeugen. Diese Reaktionszeiten liegen eher im Sekun-
den- als im Millisekundenbereich, und der Benutzer unterscheidet sehr wohl, ob eine schnelle CPU
1 s oder eine langsame CPU 4 s gearbeitet hat. Da bei den meisten Aktionen im GIS-Bereich der
Hauptteil der CPU-Arbeit in einem einzigen Thread liegt, ist die Geschwindigkeit, mit der eine CPU in
einem Thread arbeitet, entscheidend für die vom Anwender beobachteten Antwortzeiten. D.h. die
Antwortzeit (Performance) von ArcGIS wird maßgeblich von der Geschwindigkeit eines Cores und
nicht von der Anzahl der Cores beeinflusst. Ausschlaggebend für eine flüssige Bearbeitung ist dem-
nach eine hohe Single-Thread-Performance des verwendeten Prozessors.
Diese „Single-Thread“-Performance lässt sich u.a. aus den Ergebnissen des Benchmark-Programm
der Firma Passmark ableiten. Dieser Benchmark liefert eine Zahl (je höher desto schneller) Ergebnis-
se können hier eingesehen werden:
- Desktop-Prozessoren: http://www.cpubenchmark.net/singleThread.html
- Laptop-Prozessoren: https://www.cpubenchmark.net/singleThread.html#laptop-thread
- Server-Prozessoren: https://www.cpubenchmark.net/singleThread.html#server-thread
Diese Werte sind in der Regel relativ unabhängig vom Hersteller des Servers (z.B. Dell, IBM, HP,
Fujitsu, Bull, …). Weiter fällt auf, dass die Taktrate der CPU lediglich innerhalb von Baureihen direkt
einen Rückschluss auf die Performance zulässt.
Minimalanforderung:
Intel Core- oder Xeon-Prozessoren und kompatible AMD-Prozessoren
Minimum: Passmark Single Thread Performance >= 1800
Empfehlung:
Intel Core- oder Xeon-Prozessoren und kompatible AMD-Prozessoren
Empfohlen: Passmark Single Thread Performance >= 2400
Für einen performanten Betrieb empfehlen wir daher für alle Server mit signifikanter Last (Da-
tenbank-Server, Plot-Server, ArcGIS-Server) CPUs mit möglichst hoher Single-Thread-
Performance, der Single Thread Rating Wert sollte nicht unter 2400 liegen.
Hinweis: Wir stellen unseren Kunden inzwischen kostenfrei auf unserer Homepage den Passmark
Performance Test® zu Verfügung, mit dem man selbst die Single-Thread-Performance eines Compu-
ters (physisch oder virtuell, Client oder Server) messen kann.
Seite 4 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
1.2 Hyperthreading
Moderne CPUs bieten in der Regel die Möglichkeit, Hyperthreading oder „Simultaneous Multithrea-
ding“ (SMT) zu aktivieren. Dieses Feature erlaubt es einem physischen CPU-Kern, zwei Threads pa-
rallel auszuführen. Entsprechend werden im Windows Task Manager und vergleichbaren Werkzeugen
zwei „logische“ CPUs angezeigt, also werden z.B. für einen 2-Wege-Server mit einer Quadcore CPU
mit aktiviertem Hyperthreading im Windows Task Manager 16 CPUs angezeigt, ohne Hyperthreading
nur 8 CPUs. Die Aktivierung bzw. Deaktivierung von Hyperthreading erfolgt im BIOS (bei der Verwen-
dung von virtuellen Maschinen natürlich im BIOS des physischen ESX- oder Hyper-V-Servers, nicht
auf der einzelnen VM).
Die Aktivierung von Hyperthreading wird in der Regel den potentiellen Durchsatz eines Systems erhö-
hen, wir haben in verschiedenen Tests aber schon beobachtet, dass diese Setzung auf virtuellen Ma-
schinen auch bei niedrigen Lasten nachteilige Effekte hat. Zum Erreichen der bei einer gegebenen
CPU optimalen Performance empfehlen wir daher, beim Einsatz virtueller Maschinen Hyperth-
reading zu deaktivieren.
Da die Prozessorhersteller Hyperthreading über verschiedene Prozessorgenerationen weiterentwi-
ckeln, sollte ggf. durch eigene Untersuchungen festgestellt werden, welche Auswirkungen auf die
Performance in der eigenen Umgebung bestehen. Bei hochausgelasteten virtualisierten Umgebungen
können sich durchaus andere Ergebnisse als unter Teillast ergeben.
Hinweis: Bei aktiviertem Hyperthreading ist genau zwischen physischen CPUs bzw. CPU-Kernen,
logischen CPUs (zwei pro physischem CPU-Kern) und virtuellen CPUs (Konfiguration von VMs) zu
unterscheiden. Unsere Angaben zum CPU-Bedarf von Servern gehen prinzipiell davon aus, dass ei-
ner virtuellen CPU ein ganzer physischer CPU-Kern zur Verfügung steht.
1.3 Power Management
Die meisten aktuellen CPUs bieten verschiedene Power-Management-Optionen an, die bei niedrig
ausgelasteter CPU die Taktrate und damit den Energieverbrauch und die Wärmeabgabe verringern.
Das BIOS kann in der Regel so konfiguriert werden, dass diese Einstellungen dem Betriebssystem zur
Verfügung gestellt werden, gängige Virtualisierungslösungen (z.B. VMware oder Microsoft Hyper-V)
bieten diese Einstellungen in der Administrationsoberfläche an.
Eine Optimierung des Stromverbrauchs durch Reduzierung der Taktrate bei geringer Last auf dem
Server wirkt sich direkt auf die oben diskutierte Single-Thread-Performance aus. Für viele Anwendun-
gen (z.B. Office) ist das unerheblich, für GIS-Anwendungen ist es deutlich spürbar. Die Reduzierung
der Taktrate bei niedriger Last kann daher bedeuten, dass einem Web-Anwender u.U. eine deutlich
geringere Performance zur Verfügung steht, als von der nominellen CPU-Leistung her zu erwarten
wäre.
Bei virtuellen Maschinen können diese Einstellungen sowohl auf dem (physischen) Host- als auch auf
dem (virtuellen) Gast-Betriebssystem vorgenommen werden – beide sind zu beachten. Unsere Erfah-
rungen zeigen, dass es durchaus Situationen gibt, in denen voll ausgelastete größere virtuelle Ma-
schinen nicht ausreichen, um den physischen Server „hochzutakten“.
Wir empfehlen daher, vor allem bei Einsatz von virtuellen Maschinen, auf die Verwendung der
Taktratenreduzierung zu verzichten bzw. zumindest zu untersuchen, ob diese Einstellung spürbare
Veränderungen bei der Performance verursacht. Dies gilt natürlich für alle Wege zur Konfiguration
dieses Features, also sowohl für das BIOS als auch für Betriebssystem (z.B. Windows Energieoptio-
nen Höchstleistung statt Ausgeglichen) und ggf. Virtualisierungsverwaltung.
1.4 Virtualisierung
ArcGIS und die AED-SICAD Produktfamilien 3A und UT unterstützen Virtualisierung in allen
Komponenten. Bei Datenbankservern (z.B. Oracle) gibt es allerdings aufgrund der Lizenzierungsre-
geln der Datenbankhersteller strenge Restriktionen, die Einfluss auf die eingesetzte Hardware, Virtua-
lisierungslösung und sogar die Version der Virtualisierungssoftware haben. Hier ist im Einzelfall zu
prüfen, ob eine Virtualisierung wirtschaftlich sinnvoll ist, oder ggf. die Ausfallsicherheit mit Datenbank-
eigenen Mechanismen kostengünstiger erreicht werden kann.
Seite 5 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
Die Vor- und Nachteile der Virtualisierung sollen hier nicht im Detail diskutiert werden – für den GIS-
Bereich relevant sind u.a. die folgenden Aspekte:
Durch die Möglichkeiten der dynamischen Skalierung von virtuellen Maschinen (VMs) kann
der Hardwareaufwand für die Bereitstellung von separaten Servern für die verschiedenen
Aufgaben u.U. deutlich reduziert werden.
Eine Anpassung der VMs an die konkreten Lasten ist im laufenden Projekt einfach möglich,
auf Änderungen im Anwenderverhalten kann flexibel reagiert werden.
Der Auswirkungen des Ausfalls einer einzelnen Servermaschine können deutlich begrenzt
werden, nach ggf. nötigem Neustart von VMs kann das System mit geringerer Kapazität fast
unmittelbar weiter betrieben werden.
Auch bei virtuellen Maschinen gilt natürlich das weiter oben gesagte zur Single-Thread-Performance.
Allerding kommt hier neben Hyperthreading und Taktratenreduzierung durch Powermanagement eine
weitere „Gefahr“ für die Performance hinzu, nämlich das Overcommitment von CPU-Ressourcen, d.h.
die Konfiguration von mehr virtuellen CPUs als verfügbaren physischen CPU-Kernen auf einer gege-
benen Hardware. Bei vielen Applikationen ist diese Praxis unkritisch, im GIS-Bereich führt sie in der
Regel direkt zu spür- und messbaren Verlängerungen von Antwortzeiten.
Wir empfehlen hier daher dringend, beim Betrieb einer GIS-Umgebung auf Overcommitment zu
verzichten, z.B. durch den Betrieb der GIS-Maschinen in einem separaten Virtualisierungs-Cluster.
1.5 Hauptspeicher
Da Hauptspeicher keine teure Ressource mehr ist und Swapping bei Speichermangel zu deutlichen
Performanceeinbußen führt, sollte eher eine Überdimensionierung angestrebt werden.
1.6 Massenspeicher
Lokal im Server verbaute Festplatten sollten mit einem guten Raid-Controller mit batteriegepuffertem
Cache als Raid 10-Verbund betrieben werden. Eine Hot-Spare Festplatte ist vorzusehen. Viele kleine-
re Festplatten liefern in der Regel eine bessere Leistung als wenige große.
Wir empfehlen die Verwendung von SAS-Festplatten, da die I/O-Raten durchgängig mindestens dop-
pelt so groß wie die von SATA-Festplatten sind. Dies gilt insbesondere für Datenbankserver. Wenn es
um das Vorhalten großen Datenmengen geht und Performance nicht kritisch ist, können auch Raid-
Systeme aus (möglichst vielen) SATA-Festplatten benutzt werden.
Für optimale Performance sollte SSD-Storage eingesetzt werden. Da SSDs keine beweglichen Teile
enthalten, sind die Leistungsdaten gegenüber Festplatten je nach I/O-Parameter mindestens um den
Faktor 5-100 besser. Insbesondere Random-Zugriffe profitieren besonders stark. SSDs unterliegen
einer raschen Weiterentwicklung, sodass mit weiteren Leistungssteigerungen und fallenden Kosten zu
rechnen ist.
Bei Verwendung von zentralem Massenspeicher in einem SAN gilt sinngemäß das Gleiche wie bei
lokalem Storage. Da ein SAN (insbesondere bei einer SAN-Virtualisierung) ein „Shared Medium“ ist,
muss das SAN eine sehr hohe Performance bereitstellen können, damit es in Lastspitzen keine Per-
formanceeinbrüche gibt. Die Performance sollte bei längerem Betrieb und mit steigender Last für das
SAN regelmäßig überprüft werden. Auch im SAN ist der Einsatz von SSDs für optimale Performance
empfehlenswert.
1.7 LAN
Für die Kommunikation der Server untereinander sollte ein Gigabit-Netzwerk zur Verfügung stehen.
1.8 Betriebssysteme
Im Bereich Windows sollte durchgängig Windows Server 2012 R2 oder Windows Server 2016 ver-
wendet werden, solange dem keine Restriktionen von Seiten der Software entgegenstehen.
Für Datenbankserver stehen verschiedene Varianten zur Verfügung, hierbei sollten die Systemvo-
raussetzungen von Esri berücksichtigt werden. Auch wenn auf dem Datenbankserver kein ArcSDE-
Seite 6 von 7Dokumente zu Systemarchitektur und Performance
Hardware-Empfehlungen
Dienst installiert wird, ist zu beachten, dass bei Verwendung von ST_GEOMETRY als Geometrie-
Datenhaltung die Esri-Bibliotheken für geometrische Operationen unter SQL auf dem DB-Server aus-
geführt werden.
2 Desktop/Mobil
Hinweis: Hier geht es um den typischen „Windows-PC“, ob als Desktop oder als Notebook, auf dem
eine Lösung auf Basis von ArcGIS for Desktop- bzw. ArcGIS Engine läuft. Smartphones oder Tablets
(Android/iOS/Windows Phone etc.), auf denen ArcGIS Runtime oder eine „WebApp“ zum Einsatz
kommt, sind nicht Gegenstand dieses Abschnittes.
Für den GIS-Einsatz auf einem lokalen Arbeitsplatz gelten zunächst inhaltlich ähnliche Anforderungen
wie bei Server-Installationen: Wichtig ist vor allem eine schnelle CPU (im Sinne der Single-Thread-
Performance). Zur Beurteilung der Single-Thread-Performance der Desktop-CPUs eignen sich die von
der Firma Passmark® Software veröffentlichen Zahlen, die auf der Seite
http://www.cpubenchmark.net/singleThread.html zu finden sind. Auf Desktop-Seite in die Empfehlung,
CPUs mit einem Single-Thread-Performance-Wert > 2000 zu wählen.
Hinweis: Wir stellen unseren Kunden inzwischen den Passmark Performance Test kostenfrei zur
Verfügung, Details dazu hier1 auf unserer Homepage.
Das Thema Power Management/Energieoptionen spielt auch bei Arbeitsplatzrechnern eine Rolle: Ein
Heruntertakten der CPU spart Strom, reduziert ggf. Lüftergeräusche und sorgt bei mobilen Geräten für
eine längere Akku-Laufzeit. Andererseits kann diese Reduzierung auch zu deutlichen Performance-
einbußen im GIS-Betrieb führen, in Tests haben wir teilweise mehr als eine Verdopplung von Antwort-
zeiten beobachtet.
Eingesetzt werden sollten aktuelle Rechner des gehobenen Leistungsspektrums mit folgenden Kenn-
zahlen:
CPU: Aktuelle Intel Core-i5, i7 > 3,2 GHz
RAM: 8 GB
Grafik: Spezielle Grafikkarten sind in der Regel nicht erforderlich. Doppelbildschirmlösungen
werden unterstützt, auch für Terminalserver-Konfigurationen (RDP, Citrix).
Massenspeicher: SSD >= 250 GB
Betriebssystem: Windows 10 64 Bit.
Eine performante Anbindung des Clients an die Serverfarm, insbesondere an den Datenbank-Server,
ist nur über eine LAN-Verbindung (Latenzzeit < 1 ms) mit mindestens 100 Mbit – besser 1 Gbit – mög-
lich, bei WAN-Strecken ist eine Terminal-Server/Citrix-Lösung einzuplanen.
1
https://www.aed-sicad.de/index.php/neuigkeiten-details/aed-sicad-stellt-cpu-benchmark-programm-
bereit.html
Seite 7 von 7Sie können auch lesen
