AED-SICAD. Dokumente zu Systemarchitektur und Performance. Hardware-Empfehlungen. Dokumente zu Systemarchitektur und Performance Hardware-Empfehlungen

Transkript

1 AED-SICAD Dokumente zu Systemarchitektur und Performance Dokumente zu Systemarchitektur und Performance Autoren: Dr. Martin Ameskamp, Helmut Röhl Status: Abgestimmt. Version: 3 Datum: 11. November 2016 Datei: DSP-Hardwareempfehlungen.docx Seite 1 von 7

2 Änderungsübersicht Version Datum Änderungsgrund betroffene Abschnitte Bearbeiter Gemeinsames Hardware-Dokument für PS und UT alle Ameskamp, Röhl Aktualisiert alle Ameskamp Ergänzt um weitere Komponenten und Desktop , 2 Ameskamp Seite 2 von 7

3 Inhalt 1 Hardware-Parameter und Technologien Server Anforderungen an die CPU Hyperthreading Power Management Virtualisierung Hauptspeicher Massenspeicher LAN Betriebssysteme Desktop/Mobil... 6 Seite 3 von 7

4 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 Randbedingungen 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 Textverarbeitungsprogramm 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 Sekunden- 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. Diese Single-Thread -Performance lässt sich u.a. aus den Ergebnissen der SPEC-Benchmarks 1 ableiten. Es gibt verschiedene Tests, relevant für den GIS-Bereich ist die Messung des Durchsatzes bei ganzzahligen Operationen, kurz CINT2006rate oder auch SRint06. Dieser Benchmark liefert eine Zahl (je höher desto schneller) für eine Server-Maschine; die Division dieser Zahl durch die Anzahl der CPU-Kerne des Systems liefert einen guten Anhaltspunkt für die Single-Thread-Performance der CPU. Konkrete Ergebnisse sind z.b. Werte um 58 für Intel Xeon E v4 (3,2 GHz, 8 Kerne pro CPU) oder 46 für Intel Xeon E v3 (2,6 GHz, 10 Kerne pro CPU). 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. Für einen performanten Betrieb empfehlen wir daher für alle Server mit signifikanter Last (Datenbank-Server, Plot-Server, ArcGIS-Server) CPUs mit möglichst hoher Single-Thread- Performance, der Wert SRInt06/Core sollte nicht unter 40 liegen. 1.2 Hyperthreading Moderne CPUs bieten in der Regel die Möglichkeit, Hyperthreading oder Simultaneous Multithreading (SMT) zu aktivieren. Dieses Feature erlaubt es einem physischen CPU-Kern, zwei Threads parallel 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 Verwendung 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 Maschinen auch bei niedrigen Lasten nachteilige Effekte hat. Wir empfehlen daher, beim Einsatz virtueller Maschinen Hyperthreading zu deaktivieren. 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 einer virtuellen CPU ein ganzer physischer CPU-Kern zur Verfügung steht. 1 Seite 4 von 7

5 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 Anwendungen (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 Erfahrungen zeigen, dass es durchaus Situationen gibt, in denen voll ausgelastete größere virtuelle Maschinen 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 Energieoptionen Höchstleistung statt Ausgeglichen) und ggf. Virtualisierungsverwaltung. 1.4 Virtualisierung ArcGIS und die AED-SICAD Produktfamilien 3A und ArcFM UT unterstützen Virtualisierung in allen Komponenten. Bei Datenbankservern (z.b. Oracle) gibt es allerdings aufgrund der Lizenzierungsregeln der Datenbankhersteller strenge Restriktionen, die Einfluss auf die eingesetzte Hardware, Virtualisierungslö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. 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 gegebenen 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. Seite 5 von 7

6 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 kleinere 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 doppelt 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 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 Performanceeinbrü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 verwendet werden, solange dem keine Restriktionen von Seiten der Software entgegenstehen. Für Datenbankserver stehen verschiedene Varianten zur Verfügung, hierbei sollten die Systemvoraussetzungen von Esri berücksichtigt werden. Auch wenn auf dem Datenbankserver kein ArcSDE- 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 ausgefü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). Bei Server-CPUs stehen in der Regel SPEC-Benchmarks zur Bewertung zur Verfügung, für Desktop-CPUs sind SPEC-Werte nur in Ausnahmefällen zu finden. Zur Beurteilung der Single-Thread-Performance der Desktop-CPUs eignen sich die von der Firma Passmark Software veröffentlichen Zahlen, die auf der Seite zu finden sind. Diese Zahlen sind anders skaliert als die SPEC-Werte, ein Vergleich der in beiden Listen geführten CPUs zeigt aber, dass beide Werte gut korreliert sind und mit einem Faktor von ca. 40 ineinander umgerechnet werden können. Die oben ausgesprochene Empfehlung, CPUs mit SRint06/Core > 40 zu verwenden, übersetzt sich also auf Desktop-Seite in die Empfehlung, CPUs mit einem Single- Thread-Performance-Wert > 1600 zu wählen. 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- Seite 6 von 7

7 einbußen im GIS-Betrieb führen, in Tests haben wir teilweise mehr als eine Verdopplung von Antwortzeiten beobachtet. Eingesetzt werden sollten aktuelle Rechner des gehobenen Leistungsspektrums mit folgenden Kennzahlen: 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 8.1, 64 Bit. Windows 10 wird aktuell (August 2016) von ArcGIS noch nicht unterstützt. 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öglich, bei WAN-Strecken ist eine Terminal-Server/Citrix-Lösung einzuplanen. Seite 7 von 7