Mittlerweile weiß ich gar nicht mehr, wie ich dazu gekommen bin, aber irgendwie muss es wohl über das Serversupportforum o.ä. zustande gekommen sein: Ich durfte mal wieder einen VPS- bzw. vServer-Anbieter und eines seiner Produkte testen.

Edit: Der Kontakt kam diesmal über das OSBN zustande, da dort der Blog “debinux.de” teilnimmt. Ich fand sein “mailcow.email“-Projekt ganz interessant und bin darüber auf “servercow.de” gestoßen.

Hier möchte ich meine Erfahrungen kurz (lang) schildern.

Es handelt sich um das Paket “vServer L” vom Anbieter “Servercow”. Folgende Leistungsmerkmale liegen zugrunde:

CPU 4 vCores
RAM 2 GB RAM
SSD 20 GB
HDD 150 GB via Storage-Server, RAID5, Samba+FTP

1 Monat für 9,50€

Im weiteren Verlauf dieses Artikels werde ich die einzelnen Komponenten testen und vergleichen.

Ganz nett finde ich die folgenden Fakten:

Alle KVM-Hostsysteme sind nach höchsten Ansprüchen ausfallsicher gestaltet.
Unsere persönlichen Anforderungen:

Stromversorgung durch mindestens 2 PSUs
Fail-Over Netzwerkbetrieb
lokale RAID60-Verbünde aus mindestens 16 SSDs.
reine SSD-Systeme
keine Überprovisionierung, keine Deklaration von Cache als RAM

Unsere Systeme, Soft- sowie Hardware, unterliegen einem dauerhaften Monitoring.
Servercow reagiert 24 Stunden, 7 Tage die Woche auf mögliche Ausfälle.

Und auch sehr gut gefällt mir, aufgrund meiner “Vertrags-Phobie”:

Ohne Gefahr, ohne Kündigungsfrist[1]

Die Webinterfaces

Zur Steuerung der virtuellen Server kommt auch bei servercow das SolusVM-Panel zum Einsatz. Das mag seine Nachteile haben (Links zu Sicherheitslücke von SolusVM), hat auch praktische Vorteile: Ich muss mich in der Bedienung nicht umgewöhnen.

Vor das SolusVM-Panel ist ein servercow-eigenes Panel geschalten, welches vermutlich mit Bootstrap realisiert wurde. Es ist aufgeräüumt und bietet einige nützliche Informationen sowie die komplette Billing-Funktion zum Verlängern oder zukaufen von vServern.

Das servercow-Interface

Das SolusVM-Interface

Als ewiger OpenVZ-Nutzer bin ich erfreut, welch umfangreiche Funktionen sich mir bei servercow mit den KVM-vServern offenbaren. Video-Einstellungen, vorbereitetes VNC, diverse virtuelle CDs zum mounten und noch einiges mehr.

Alles in allem also ein umfangreiches aber dennoch aufgeräumtes Webinterface zur Verwaltung des vServers.

Eine Besonderheit

Eingangs habe ich die Leistungsmerkmale der virtuellen Maschine aufgelistet. Dabei dürfte aufgefallen sein: Bei servercow gibt es vergleichsweise wenig Festplattenspeicher für den vServer, aber dafür einen 150 GB großen Platz auf einem “Storage-Server” den man via FTP oder Samba erreichen kann.

Um den Storage also mit normalen Anwendungen nutzen zu können, ist es wichtig, diesen möglichst sinnvoll zu mounten und die Anwendungen mit diesem gemounteten Storage kommunizieren zu lassen.

Da hier “nur” zwei Protokolle zur Verfügung stehen, die meines Erachtens nach nicht für diesen Zweck geeignet sind, ist dieser Punkt ein bisschen komplizierter.
Den FTP-Server könnte ich via curlftpfs mounten. Den Samba-Share würde ich mittels cifs mounten. Bei beiden Lösungen bin ich um die Performance leicht besorgt – aber eventuell werde ich positiv überrascht. Denn genau diese Performance gilt es nun zu testen.

FTP mounten via curlftpfs[2]

apt-get install curlftpfs https://wiki.ubuntuusers.de/curlftpfs

curlftpfs <user>:<pw>@<server>/<verzeichnis>/ /var/www

root@testserver:/var$ df -h
Filesystem                                                        Size  Used Avail Use% Mounted on
/dev/vda1                                                          19G 1016M   17G   6% /
udev                                                               10M     0   10M   0% /dev
tmpfs                                                             403M  5.4M  397M   2% /run
tmpfs                                                            1006M     0 1006M   0% /dev/shm
tmpfs                                                             5.0M     0  5.0M   0% /run/lock
tmpfs                                                            1006M     0 1006M   0% /sys/fs/cgroup
curlftpfs#ftp://<user>:<pw>@io.servercow.de/home/  954G     0  954G   0% /var/www

Und damit ist die Sache schon erledigt. Direkt auf den ersten Blick nicht so schön: Man sieht die Zugangsdaten des Shares in den gemounteten Devices.

Samba-Share mounten via cifs[3]

apt-get install cifs-utils

mount -t cifs -o username=<user>,password=<passwort>,uid=root,gid=root //<server>/<verzeichnis> /var/www

Performancevergleich

Testverfahren

Für die Tests der Latenz sowie der Lese- und Schreibgeschwindigkeit bin ich einer Empfehlung aus dem Thomas-Krenn-Wiki gefolgt [4][5]. Dabei wird mittels dd geschrieben und gelesen. Auch Latenztests sind hierbei möglich. Gemäß der Empfehlung nutzte ich das Attribut “oflag=dsync”.[6]

Diese Tests führte ich jeweils 10 mal in Folge aus, um daraus einen Mittelwert ableiten zu können. Aus diesen Mittelwerten, generierte ich in LibreOffice Calc letztlich die folgenden Diagramme.

Die “Logs” meiner Tests sowie das LibreOffice-Dokument hänge ich der Vollständigkeit halber an. (Logs, LO-Dokument)

Latenz (in ms)

Übertragungsgeschwindigkeit in MB/s

Performancefazit

Am liebsten wäre mir hier NFS. Das “Network File System” erfüllt genau die Anforderungen, die für solch Vorhaben von essentieller Bedeutung sind. Ich sage das gleich zum Anfang, da der versierte Leser bereits an den Diagrammen erkannt haben wird, dass die Performance nicht gerade berauschend ist. Die Latenzzeiten sind sowohl bei der Samba- als auch bei der FTP-Lösung merkwürdig gut. Eventuell spielt hier noch ein Cache mit dem ich jetzt nicht rechne hinein?

Die Übertragungsraten lassen zu wünschen übrig. Als Referenz habe ich die lokalen Übertragungsraten verwendet. Da das Schreiben auf die lokalen Speicher halb so schnell ist, wie das Lesen, schließe ich hier auf einen RAID-Verbund a la RAID1 auf dem Hostsystem.

Die Schreib- und Leserate von Samba liegt leicht unter 100 MB/s. Hier vermute ich als Flaschenhals die Verbindung zum Storage-Server.

Das Schreiben von größeren Dateien via curlftpfs war mir nicht möglich. Dabei zeigte sich kein wirkliches Muster: Mal stürzte die Verbindung bei 250, dann mal bei 650 geschriebenen Megabyte ab. “Kleine” Dateien unter 250 MB konnte ich in den meisten Fällen ohne Probleme schreiben.
Das Lesen der Dateien via curlftpfs funktionierte dabei einwandfrei, aber relativ langsam (25 – 35 MB/s)

Testverfahren CPU- und RAM-Benchmark

Für die CPU- und RAM-Benchmarks nutze ich sysbench. Hierbei kann ich auch bereits auf meine in der Vergangenheit erstellten Benchmarks[7][8] referenzieren, sodass eine gute Einschätzung der Leistung auch ohne genaue Teraflops-Angaben möglich ist (ich habe bis jetzt keinen Linux-Benchmark gefunden, der in der Lage ist, diese Einheiten auszugeben). Zu beiden Benchmarks hänge ich wieder meine “rohen” Logs und das LibreOffice-Dokument an, mit dem ich die Diagramme erstellt habe.

CPU-Benchmark

Obgleich der Raspberry Pi 2 die Statistik leicht verzogen hat, bin ich mit dem Ergebnis zufrieden. Die Leistung der unbekannten CPU liegt gut im Mittelfeld. Die Single-Thread-Performance liegt leicht unter dem Niveau meines 3 Jahre alten Notebooks. Wenn alle 4 Threads genutzt werden, kann der Server punkten und kommt nochmal etwas näher an das ThinkPad heran.

Eine Frage ist jedoch nicht geklärt: Um welche CPU es sich denn nun handelt.

Die rohen Logs und das LibreOffice-Dokument (Logs, LibreOffice-Dokument).

RAM-Benchmark

Der RAM-Benchmark lief nach dem bekannten Muster ab, jedoch habe ich nicht ganz so viele Referenzwerte.

Auch hier gilt wieder: Logs und LibreOffice-Dokument werden angehängt. Die Logs zum RAM-Benchmark sind in den Dateien der CPU-Tests enthalten. (LibreOffice-Dokument)

Anbindung

Der IP und den Aussagen auf der Webseite des Anbieters zufolge, befindet sich der Server bei der Firma meerfarbig GmbH & Co. KG in Frankfurt am Main (AS34549). Die genaue Position ist nur schwer auszumachen. Besagte Firma betreibt wohl Server bei InterXion und Equinix.[9]

Die Benchmarks zur Anbindung führte auf drei Wegen durch:

Zum einen Lade ich eine Testdatei von diversen ISP herunter. Das Ganze 10 mal um anschließend einen Mittelwert bilden zu können. Weiterhin messe ich mithilfe von iperf und eines anderen Servers. Im dritten und letzten Schritt beschäftigte ich mich mit “speedtest-cli”.[10][11]

Hier das LibreOffice-Dokument, welches alle Diagramme und die dazugehörigen Ergebnisdaten enthält (LibreOffice-Dokument).

speedtest-cli Besonderheit

Da in der Nähe um Frankfurt am Main sehr viel Serverinfrastruktur befindlich ist, fand ich es nicht gerade repräsentativ, den “nächstgelegenen Server” zum testen zu nutzen. Aus diesem Grund habe ich 4 geografisch völlig unterschiedlich positionierte Server zum testen gewählt:

• AS Dienstleistungen Falkenstein (5962)
• SoftLayer Technologies, Inc. Frankfurt am Main (5975) (automatisch gewählt)
• Emerging Markets München (3578)
• Stadtwerke Neumuenster Neumünster (4886)

Da das Ergebnis zu “Emerging Markets” nicht ganz zufriedenstellend war, bezog ich noch den Node von InterNetX aus München ein:

• InterNetX München (3932)

Die Ergebnisse lauteten wie folgt:

Bemerkung: Die Ergebnisse von speedtest-cli sind sehr durchwachsen, womit ich sagen will, dass sie teils enormen Schwankungen unterliegen. Auch spielt die Tageszeit sicher eine Rolle. Die IP-Performance-Tests habe ich an einem Sonntagmorgen durchgeführt.

Hier die “rohen” Logdateien von speedtest-cli. (Logs)

Dateitransfer

Besonderheiten gab es beim Dateidownload nicht, aber ich stellte fest, dass einige “Speedtest”-File-Anbieter nicht das halten, was sie versprechen. Aber vielleicht ist auch einfach die Verbindung/das Routing schlecht. Die Tele2-Testfiles eigenen sich gut, denn Tele2 hat den/die Testserver an einem 10 Gbps-Uplink hängen. Ich kam stets auf eine Downloadrate von 108 MB/s, was ca. einem Gigabit pro Sekunde entpricht.

Hier wieder die “rohen” Logdateien (Logs).

iperf3 Besonderheit

Für den Test mittels iperf3 zog ich die folgenden Anbieter[12] heran:

• online.net
• serverius
• scottlinux.com
• testdebit.info

Gemessen wurde in beide Richtungen, also sowohl mit dem Attribut “-R” als auch ohne.

Die Statistik sieht hier ganz gut aus. Anmerkung: Der scottlinux-Server ist zwar laut Liste mit 40 Gbit angebunden, steht aber nicht innerhalb Europas.

Im Rahmen dieses Tests hatte ich eine kurze Konversation mit Scott Miller, da sein iperf3-Server nicht lief. Es ist schön, wenn man so prompt und direkt kommunizieren kann. :)

Hier wieder die “rohen” Logdateien (Logs).

Fazit

Wirklich zuverlässige Ergebnisse kann man meiner Meinung nach erst nach längerer Benutzung liefern. Aber die durchgeführten Tests sind schonmal ein guter Vorgeschmack und eignen sich, auch in Zukunft bei weiteren Tests als Referenz herzuhalten.

Der Server ist leistungsmäßig gut bestückt und bewegt sich preislich im Rahmen. Die Umsetzung des “Netzwerkspeichers” ist, um es in Schulnoten auszudrücken, “ausreichend”. Zum mounten des Speichers empfehle ich Samba bzw. cifs anstatt FTP (siehe Testergebnisse). NFS in Verbindung mit dem Netzwerkspeicher wäre interessanter, allerdings auch etwas aufwendiger zu realisieren.

Da ich den Server noch eine Weile nutzen darf, habe ich mehrere verschlüsselte Container für Tests mit diversen Backup-Mechanismen installiert, was gerade im Hinblick auf den Netzwerkspeicher interessant scheint. Denn mit 150 GB zu (kleinstes Paket!) 7,50 Euro bei kompletter Administrierbarkeit ist der Speicher relativ günstig.

Während meinen Tests gab es keine Probleme was Konnektivität und Uptime angeht. Auch die Bestellung und der Kontakt zum Support gibt ohne Probleme und mit kurzen Antwortzeiten. Servercow machen daher auf mich einen verlässlichen Eindruck, was mir sehr wichtig ist.

Ich würde mich freuen, die Tests später mal wieder durchführen zu können, was impliziert, dass ich hoffe, dass servercow “am Markt” bleibt.

Eine letzte Anmerkung: Bei den Tests kam cifs und ausschließlich cifs zum Einsatz. Das Protokoll gilt mittlerweile als überholt und sollte, diversen Aussagen[13][14] zufolge, nicht mehr verwendet werden. Ich werde daher die Performancetests den Netzwerkspeicher betreffend, mit dem SMB-Protokoll wiederholen und in Kürze hier ergänzen.