Der Hosting-Anbieter Hetzner hat seit Kurzem ein flexibles und relativ preisgünstiges Hosting von virtuellen Servern im Angebot. Das Produkt nennt sich „Hetzner Cloud“. „Cloud“ deshalb, weil man nicht direkt fertige virtuelle Maschinen bekommt, sondern eine Umgebung, in der man flexibel seine VM konfigurieren kann. Man kann neben zehn Kombinationen von CPU Cores, RAM, HDD, Speicherart und Speicherart das Datacenter auswählen und die Linux Distribution auswählen. Die Konfiguration der Cloud geschieht in einer ansprechenden Web-Oberfläche. Wenn benötigt, ist die Konfiguration der Cloud auch per API möglich. Was mich positiv überrascht hat, ist die Geschwindigkeit, mit der ein neuer Server ausgerollt wird. Es dauert keine Minute, bis ein neuer Server online per SSH erreichbar ist. Ebenso schnell ist ein Server auch wieder zurückgebaut.

Mit Preisen zwischen 2,96€/Monat und 35,58€/Monat liegt das Angebot in einem attraktiven Rahmen. Um die Leistungsfähigkeit der Hetzner Cloud einschätzen zu können, wurden von sechs verschiedenen Serverkonfigurationen jeweils eine VM erstellt und verschiedene Benchmarks darauf ausgeführt.

Um die Ergebnisse der Benchmarks einordnen zu können, wurden zusätzlich zu den Hetzner Cloud VMs ein Strato vServer und ein Hardwareserver getestet.

Hier die getesteten Server (Stand 02/2018):

Die Hetzner Server cx11-cx51 unterscheiden sich nur in der unterschiedlichen CPU-, RAM- und HDD-Ausstattung. Die VMs basieren hier auf lokalen SSDs. Diese Konfigurationen sind auf Performance und weniger auf Hochverfügbarkeit ausgelegt. Im Gegensatz dazu bietet Hetzner alle Cloudserver auch noch als Konfiguration basierend auf dem verteilten Speichersystem CEPH an (cx41-ceph). Hier liegen die Dateien der VMs redundant im Netzwerk vor. Positiv fällt auf, dass die Inode Quota der Hetzner Cloud Server angemessen ist. Inodes braucht man z. B. bei einem rsnapshot Backup, bei dem jeder symbolische Link ein Inode verbraucht. Bei kleineren Strato vServern stößt man da schnell an Grenzen.

Auf den ersten Blick ist die Ausstattung der Server mit Festplattenspeicher schlechter als bei den Strato vServern. Dort hat ein Server für 14€/Monat 500GB Festplattenspeicherplatz. Bei Hetzner bekommt man dagegen für z. B. 18€ nur 160GB Speicherplatz. Das könnte für manche Anwendungen ein Problem sein, für die meisten kleineren Webserverprojekte etc. sollte dies aber keine Rolle spielen.

Alle Hetzner Server laufen mit Debian 9, PHP 7, Apache und MariaDB. Die Strato Server mit Debian 8, PHP 5, Apache und MySQL.

Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)

Mit ApacheBench werden von einem Remote Server Websites auf dem zu testenden Server aufgerufen. Für eine feste Zeitspanne – hier 30 Sekunden – wird ermittelt, wie viele Websites der Server ausliefern kann. Als Website dient bei den Hetzner Servern eine TYPO3 8.6 CMS mit dem Bootstrap Instroduction Package. Bei den Strato Servern dient als Website ein TYPO3 7.6 CMS.

Das Benchmark-Tool wird bei jedem zu testenden Server mit drei unterschiedlichen Anzahlen von gleichzeitigen Request pro Zeitpunkt (Concurrency Level) aufgerufen.

(ab -kc XXX -t 30 http:/WWW.SERVERNAME.TLD/)

	Concurrency Level 5	Concurrency Level 50	Concurrency Level 100
Strato vSserver	2451	3851	3696
cx11	3180	4590	4564
cx21	3509	4990	4603
cx31	4105	5531	5336
cx41	4202	10081	9417
Hardware	2702	10155	9609
cx41-ceph	4752	10888	10983
cx51	4453	14818	15379

Da ApacheBench einen Stresstest auf einen Webserver ausführt, kommt dieser Benchmark einem realen Workload sehr nahe. Alle Serverkomponenten spielen hier eine Rolle bei der Leistungsfähigkeit.

Was direkt auffällt, ist die sehr gute ApacheBench-Leistung der Hetzner Server, die ab dem Modell cx41 selbst mit einem dedizierten Hardwareserver, der wesentlich mehr kostet, mithalten können. Das cx51-Modell übertrifft sogar die Leistung des Hardwareservers. Ebenfalls fällt auf, dass der CEPH-basierte Cloudserver cx41-ceph sogar eine bessere Leistung hat als sein Pendant mit lokalem SSD Storage.

Hinten, weit abgeschlagen, liegt der Strato vServer, den sogar das kleinste Hetzner Modell cx11 übertrumpft – und das nur für einen Bruchteil der monatlichen Gebühr.

SysBench MySQL

Sysbench MySQL simuliert einen realen MySQL Workload mit Lese- und Schreiboperationen.

(sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=test –mysql-password=PASSWORD –max-time=60 –oltp-read-only=off –max-requests=0 –num-threads=[ANZAHL THREADS] run)

	1 thread	2 threads	8 threads	32 threads
cx11	730	1476	5516	8591
cx31	708	1521	6320	13358
cx21	712	1508	6246	14122
Strato vSserver	618	1557	5604	14189
cx41-ceph	521	1101	4256	14734
cx41	682	1468	6322	20869
cx51	703	1477	6300	25601
Hardware Server	892	1876	7522	29775

Was bei dem MySQL Sysbench Benchmark auffällt, ist, dass der Hardwareserver hier im Gegensatz zu dem Apache Benchmark leistungsmäßig an der Spitze steht. Die Anzahl der erreichten Transaktionen korreliert hier mit der Anzahl der CPU Cores. Bei zwei gleichzeitigen Threads liegen alle Server noch fast gleichauf. Bei höheren Anzahlen gleichzeitiger Threads sieht man hingegen die Auswirkung der CPU Core Anzahl immer deutlicher.

SysBench CPU Benchmark

Bei dem Sysbench CPU Benchmark wird Zeit gemessen, die benötigt wird, um eine bestimmte Anzahl (hier 10000) von Primzahlen zu verifizieren.

(sysbench cpu sysbench –test=cpu –cpu-max-prime=10000 –num-threads=XX run)

	1	2	4	8	16
Hardware Server	8,3	4,2	2,2	1,2	1,2
cx51	10,4	5,2	2,6	1,3	1,3
cx41-ceph	9,1	4,7	2,4	2,4	2,4
cx41	10,3	5,2	2,6	2,6	2,6
Strato vSserver	10,9	5,4	3,7	3,7	3,7
cx21	10,5	5,2	5,2	5,2	5,2
cx31	10,4	5,2	5,2	5,2	5,2
cx11	10,5	10,5	10,8	10,6	11,2

Wie zu erwarten, liegt hier der Hardwareserver mit seinen dedizierten CPU Kernen (und der höheren Taktfrequenz) bei dem Sysbench CPU Benchmark wieder an der Spitze. Das Verhältnis der Anzahl der CPU Cores zu der Ausführungszeit ist bei diesem Benchmark fast linear. Eine doppelte CPU Core Anzahl bedeutet eine halbierte Ausführungsdauer.

Fazit

Zusammenfassend betrachtet kann man sagen, dass die neuen Hetzner Cloud Server ein sehr gutes Bild abgeben – sowohl bei der IO-Leistung als auch bei der CPU-Leistung. Bei dem Apache Benchmark übertreffen die zwei größten Cloud Server Konfigurationen selbst den Hardwareserver. Dies hängt aber eventuell auch etwas mit der Leistungssteigerung von PHP 7 im Zusammenspiel mit TYPO3 8 zusammen. Auf den Strato Servern läuft noch Debian 8 mit TYPO3 7 und PHP5, da Strato Debian 9 für seine vServer immer noch nicht (02/2018) unterstützt.

Weiter kann man bei den durchgeführten Benchmarks keine Performance-Unterschiede zwischen den lokalen SSD Speichern und dem verteilten CEPH Speicher erkennen. Bei manchen Tests hatte der CEPH-basierte Server gegenüber seiner gleich konfigurierten Version mit lokalem SSD Speicher die Nase vorn.

Bleibt nur zu hoffen, dass die guten Benchmark-Werte nicht mit einem noch nicht voll ausgelasteten Virtualisierungs- und Speichersystem zu erklären sind. Sollten im Dauerbetrieb die Werte auf dem guten Niveau bleiben, dann wären die cx41 und cx51 Cloud Server eventuell eine Alternative zu einem wesentlich teureren Hardwareserver, bei gleichzeitig mehr Flexibilität und Featuren wie z. B. Snapshots.

Nach einem Patchday kann der Farmkonfigurationsassistent von SharePoint 2013 nicht ausgeführt werden, da angezeigt wird, dass der Patchstand auf den Servern der Farm nicht identisch ist und auf einem Server Updates fehlen würden. Auch die Integritätsanalyse in der SharePoint-Zentraladministration zeigt eine identische Fehlermeldung:

Eine Kontrolle der installierten Updates für SharePoint in der Systemsteuerung zeigt aber, dass die Updates bereits installiert sind. Auch schlägt eine manuelle Installation der Updates mit dem Hinweis fehl, dass diese nicht mehr benötigt werden.

Die Lösung brachte folgender Artikel: SharePoint Cumulative Updates „Error: Some farm products and patches were not detected“

Man soll auf dem betroffenen Server folgenden Powershell-Befehl: Get-SPProduct -Local ausführen. Dieser Befehl aktualisiert anscheinend des Status der installierten SharePoint Updates manuell.

Danach kann man mit dem Powershell-Befehl (Get-SpServer $env:ComputerName).NeedsUpgrade den aktuellen Status überprüfen. Wenn hier false zurückgeliefert wird, ist der Server auf dem aktuellen Stand.

Nach dem Ausführen von Get-SPProduct –Local verschwindet die Fehlermeldung in der SharePoint Integritätsanalyse und auch der Farmkonfigurationsassistent lässt sich wieder ausführen.