Vergangene Woche wurde ich auf webh.pl aufmerksam, einen Internet Service Provider mit Standort Lodz, Polen. Nach kurzer Anfrage erhielt ich die Möglichkeit, eins ihrer VPS-Pakete für über eine Woche unter die Lupe zu nehmen. Generell bin ich hin und wieder auf der Suche nach kleinen, effizienten, zumeist virtuellen Systemen, auf denen unter anderem diese Webseite gespeichert und ausgeliefert werden kann. Bislang fuhr ich mit servercow.de, einem Dienst vom mailcow-Entwickler André Peters, sehr gut. Und auch weiterhin bin ich von seinem Service begeistert und werde ihm keineswegs den Rücken kehren. Dennoch schadet es sicher nicht, einmal einen Ausflug zu anderen Anbietern zu wagen und deren Benutzerfreundlichkeit und Leistungen in ein Verhältnis zu setzen.

Im weiteren Verlauf dieses Artikels werde ich die einzelnen Komponenten ausgiebig testen und versuchen, die Ergebnisse relativ mit früheren Tests vergleichen.

Sollte euch der Test gefallen haben und solltet ihr euch für webh.pl entscheiden, würde ich mich freuen, wenn ihr meinen Referral-Link oder -Code bei der Registration/Bezahlung verwenden würdet. Vorteil für euch: 20% Rabatt auf die erste Bezahlung:

Für den Referral-Link hier klicken oder den Promo-Code “PROMO46344” verwenden.

Intro

Bei dem Test-VPS handelt es sich um das Paket “KVM Standard” mit folgenden Leistungsmerkmalen:

• 4 vCPUs
• 8GB RAM
• 80GB SSD Speicher (500GB/1000GB HDD Speicher für 40/80 Zloty zubuchbar)
• keine Limitierung für Datentransfers

Der Preis liegt in dieser Ausstattung bei 90 Zloty pro Monat, derzeit sind das 19,64 Euro. Ist man mit 2 vCPUs zufrieden, drückte das den Monatspreis auf 60 Zloty pro Monat, etwa 13,09 Euro.

Zusätzliche Daten

• Standort Polen (Lodz)
• SLA von 99,9%
• Root-Zugriff
• Jederzeit Zugriff via VNC
• Installation von individuellen ISO-Dateien
• Skalierbarkeit (die Grundpakete können später im Webinterface beliebig skaliert werden)
• Automatische, stündliche Snapshots
• Snapshots werden 14 Tage rückwirkend aufbewahrt
• Snapshots können vom vmmanager aus wiederhergestellt werden
• Der Kunde erhält einen zusätzlichen virtuellen Server für die Wiederherstellung von Daten aus Snapshots
• Snapshots haben keinen Einfluss auf die Performance des Servers
• Angegebene Ressourcen werden garantiert
• Keine Einschränkungen für Gameserver oder andere netzwerkintensive Anwendungen, keine Blockade von Torrents

Bezahlmöglichkeiten

• EU-Banküberweisung
• PAYU (VISA und MasterCard)
• PayPal

Die Webinterfaces

Registration und Billing

Die Registration erfolgte unter https://ssl.webh.pro/ und war äußerst schnell und unkompliziert erledigt.

Das “ISPsystem billmanager“-basierte Interface ist übersichtlich, wirkt jedoch etwas altbacken. jedoch bietet es in übersichtlicher Form alle notwendigen Einstellungen und Übersichten. Einen sehr positiven Eindruck erhalte ich von der Geschwindigkeit des Interfaces.

VPS-Management

Die Steuerung des VPS ansich erfolgt im “ISPsystem vmmanager”-basierten Webinterface. Dieses passt designtechnisch zum Billing-Interface, dient jedoch explizit der Verwaltung von VPS.

Mein Test-VPS wurde bei Erstellung sofort mit CentOS 7 eingerichtet. Eine Neuinstallation ist über das Interface leicht zu erreichen, dabei konnte ich zwischen folgenden Presets wählen:

• CentOS 7
• CentOS 8
• Debian 8
• Debian 9
• Debian 10
• FreeBSD 11
• FreeBSD 12
• Ubuntu 16.04
• Ubuntu 18.04

Diese wiederum bieten unterschiedliche “Recipes”, also “Rezepte”, mit denen ich automatisiert bestimmte Anwendungen vorinstallieren lassen kann:

• Bitrix CRM
• Django
• ISPmanager Lite
• LAMP
• OpenVPN
• Redmine
• Teamspeak
• Tomcat
• VMmanager

Hier merke ich: Es wird sich Mühe gegeben, indem man aktuelle Betriebssysteme fertig zur Installation anbietet und dem Kunden so Zeit und Aufwand spart.

Zum Test entschied ich mich für ein aktuelles Ubuntu 18.04 “bionic”, da ich mir hiermit neben einem aktuellen Kernel auch aktuelle Versionen der Tools für Netzwerk- und Performancetests erhoffte. Leider stellte sich später heraus, dass diese Entscheidung einen teil meiner Netzwerk-Performancetests stören würde.

Bequeme Zusatzfunktion: Ich kann im vmmanager direkt meinen SSH-Pubkey angeben, sodass dieser direkt hinterlegt wird und ich mir somit einen lästigen Passwort-Login spare. Leider führt im Fall Ubuntu 18.04 diese Funktion dazu, dass eine Reinstallation sich aufzuhängen scheint – hier besteht noch Verbesserungsbedarf.

Nützlich: webh.pl erlaubt es dank entsprechender Virtualisierungstechnologie, Systeme mit individuellen vom Kunden hochladbaren ISO-Dateien zu installieren. Wollte ich also Fedora installieren, welches webh.pl nicht als fertiges Image anbietet, könnte ich dies über diese Funktion recht einfach tun. Mit entsprechender Konfiguration (Festplattentreiber, Netzwerktreiber) ließ sich im Test sogar ein uraltes Windows XP Pro SP3 installieren:

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Um von den nützlichen Logging-Funktionen, auch dem Performance-Logging, beider Interfaces gebrauch zu machen, empfiehlt es sich, die Zeitzone im Interface korrekt zu konfigurieren. Diese stand per default auf “Afrika/Windhoek”, was einen Zeitversatz bedeutet und unter Umständen für Verwirrung sorgen könnte.

Allgemeines

Reinstallationen

Ubuntu 18.04	53 Minuten (mit SSH-Key, abgebrochen)
Ubuntu 18.04	34 Minuten (mit SSH-Key, abgebrochen)
Ubuntu 18.04	6 Minuten (ohne SSH-Key)
Ubuntu 16.04	5 Minuten
CentOS 7	5 Minuten
CentOS 8	5 Minuten
FreeBSD 12	12 Minuten
FreeBSD 11	15 Minuten
Debian 10	5 Minuten
Debian 9	4 Minuten
Debian 8	5 Minuten

Die Reinstallationen funktionieren zuverlässig, sauber und schnell. Wird jedoch über das Webinterface ein SSH-Pubkey eingegeben, so hängt sich das System bei der Installation auf und reagiert nicht mehr. Startet man es dann manuell neu, wird man automatisch in die GRUB2-Kommandozeile eingeloggt, da GRUB nicht vollständig konfiguriert wurde.
Eine Reinstallation ohne vorher eingegebenem SSH-Key funktioniert fehlerfrei.

• 

• 

• 

Nach der erfolgten Installation kann ich nun also meinen SSH-Key unter Zuhilfenahme des Passworts auf die Maschine kopieren und mit der Einrichtung meines Servers fortfahren:

ssh-copy-id root@91.205.75.239
ssh root@91.205.75.239

IP-Adressen

Eine Recherche der mir zugewiesenen IPv4 ergab, dass die IP bereits von anderen vorherigen Kunden genutzt wurde. Ein Blacklist-Check lieferte jedoch ein sauberes Ergebnis. Eine entsprechende Bereinigung und Cooldown-Periode wird von entsprechend guten Internet Service Providern nach Kündigung vorgenommen.

Support

webh.pl bietet Support unter anderem in ihrer Muttersprache Polnisch, aber auch in Englisch und Deutsch an. 4 mal habe ich den Support unvermittelt kontaktiert und die Reaktionszeit aufgezeichnet.

Die Antworten kamen zügig und man kann in diesem Preissegment und ohne zugesicherte Support-Antwortzeiten wirklich nichts bemängeln:

27.03.2020 20:32 -> 20:34	2 Minuten
28.03.2020 07:54 -> 09:15	159 Minuten
29.03.2020 20:41 -> 20:45	4 Minuten
02.04.2020 08:58 -> 09:33	35 Minuten

Hostsystem und Virtualisierungslösung

Laut dmidecode kommt ein Red Hat Enterprise Linux 7 auf dem Hostsystem zum Einsatz. Zugewiesen sind der VM wie bereits erwähnt 4 vCPU-Kerne mit Taktraten von je 2793 MHz.

/proc/cpuinfo verrät in diesem Fall nicht den konkreten Typ der CPU, jedoch lässt sich erahnen, um welchen es sich handelt (Skylake Model 85, 4 MiB L2 Cache, 2793 MHz, Stepping 4):

4112 Xeon Silver $ 473.00 11 July 2017 4 8 2.6 GHz 3 GHz 85 W 4 MiB 8.25 MiB DDR4-2400 768 GiB

CPU-Vulnerability Mitigations

root@m:~# tail /sys/devices/system/cpu/vulnerabilities/*
==> /sys/devices/system/cpu/vulnerabilities/itlb_multihit <==
KVM: Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/l1tf <==
Mitigation: PTE Inversion

==> /sys/devices/system/cpu/vulnerabilities/mds <==
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown

==> /sys/devices/system/cpu/vulnerabilities/meltdown <==
Mitigation: PTI

==> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass <==
Vulnerable

==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <==
Mitigation: usercopy/swapgs barriers and __user pointer sanitization

==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <==
Mitigation: Full generic retpoline, STIBP: disabled, RSB filling

==> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort <==
Not affected

Konkret ist es so, dass die potenziellen Sicherheits- und Denial of Service-Lücken itlb_multihit, MDS und spec_store_bypass laut Gastsystem nicht abgeschaltet scheinen und daher potenziell ausgenutzt werden können. Da es sich jedoch um eine virtualisierte Lösung handelt, ist es durchaus denkbar, dass diese Lücken in Wirklichkeit umgangen werden, dies aber vom Gastsystem nicht feststellbar ist.

“I have received information that we’re not showing patches in /sys/devices/system/cpu/vulnerabilities/* for security reasons.”

webh.pl Support

Besonderheit ext4 reserved space bei vergleichsweise kleinen Festplattenspeichern

Aufgrund der per Standard knapp bemessenen 40/80G an Speicherplatz, ist es sinnvoll, Speicher zu sparen wo möglich. Empfehlenswert ist hierbei unter anderem, bei ext4-Dateisystemen den “Reserved Space” (normal 5%) zu verkleinern oder, wenn möglich, sogar komplett abzuschalten.

tune2fs -m 0.5 /dev/vda2 # Reservierter Speicher auf 0,5%
tune2fs -m 0 /dev/vda2 # Reservierter Speicher deaktiviert

Besonderheit Swapfile

Im neuesten Ubuntu LTS wurde begonnen, nicht mehr länger SWAP-Partitionen zu erstellen, sondern auf Swapfiles zu setzen. So auch im Standardsetup von webh.pl: Ein 2G großes Swapfile wird erstellt, welches selbstverständlich von dem zugesicherten Festplattenspeicher abgezogen wird. Möchte man diesen Speicher freigeben, kann man das Swapfile deaktivieren und entfernen. Es ist keine Rekonfiguration der Partitionstabelle mehr notwendig.

Routing

Das Routing spielt bei einem Server meist eine wichtige Rolle, da mit jedem Hop, der nicht passiert werden muss, die Latenz sinkt, was sich wiederum auf Anwendungen und deren Kommunikation auswirkt. Daher testete ich das Routing aus den Netzen unterschiedlicher Internetanbieter und von unterschiedlichen Standorten aus.

tkchopin.pl – webh.pl

servercow.de (meerfarbig Gmbh & Co. KG) – webh.pl

hetzner FSN1-DC1 (Falkenstein) – webh.pl

Vodafone DSL (Stuttgart) – webh.pl

Die Maps wurden generiert mit dem Leaflet Traceroute Mapper von Peter Thomson, welcher wiederum auf dem Traceroute Mapper von Stefan Sundin basiert, die Kartendaten stammen von OpenStreetMap.

Zumindest im Fall des Endkunden-Zugangs über tkchopin.pl, einem lokalen Internet- und Kabel-TV-Anbieter, erhielt man zum Zeitpunkt des Tests ein vergleichsweise direktes Routing. Für den Zugriff aus Deutschland war zweimal das Routing über Warschau und Stettin unumgänglich.

Das Routing von hetzner in Falkenstein nach webh.pl in Lodz war absurder, der fünfte Hop erfolgte über Großbritannien, was jedoch auch auf einen Fehler in der Datenbank von ipinfo.io zurückzuführen sein kann.

Netzwerkkonfiguration

Es handelt sich auf dem Server um eine statische Netzwerk-Konfiguration, welche im Fall von Ubuntu 18.04 nicht netplan/networkd-basierend ist, sondern auf die ältere ifupdown-Konfigurationsmethode in /etc/network/interfaces setzt.

auto ens3
iface ens3 inet static
address 91.205.75.239/24
gateway 91.205.75.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 1.1.1.1 8.8.4.4
dns-search webh.me

DNS

Ein Blick in die /etc/resolv.conf zeigt, da es sich um Ubuntu 18.04 handelt, dass systemd-resolved zum Einsatz kommt. Das war zu erwarten. Um also die wirklich genutzten DNS-Resolver herauszufinden, ist es notwendig, “systemd-resolve –status” auszuführen oder die /etc/systemd/resolved.conf oder die /etc/network/interfaces zu konsultieren.

Per default sind auf dem Testsystem die DNS-Resolver 1.1.1.1 (Cloudflare) und 8.8.4.4 (Google Public DNS Secondary) hinterlegt.

IPv6

Während des Tests fiel mir auf, dass das Testsystem über keine IPv6 verfügte. Auch der Versuch, eine solche über den vmmanager aufzuschalten schlug fehl. Eine Nachfrage bei webh.pl sorgte dann für Klarheit:

“We’re not offering ipv6 for now, but we’re going to offer it in the future.”

webh.pl Support

Demnach wird webh.pl IPv6 in Zukunft anbieten, was meiner Meinung nach im Jahre 2020 auch ein Muss darstellt.

Reverse-DNS

Im Test wurde nicht klar, wie Reverse-DNS-Einträge zu ändern sind. Zwar bietet der vmmanager eine solche Funktion, jedoch sorgte eine Anpassung dort nicht für das gewünschte Ergebnis. Auf Anfrage teilte der Support mit

“We’re using different IP subnets for our clients. For some of them, clients can change revdns using control panel, for rest we can change it upon request.”

webh.pl Support

Es handelt sich hierbei also offenbar um eine IP aus einem der Subnetze, für die eine Änderung der Reverse-DNS-Einträge nur aufschließlich über den webh.pl-Support erfolgen kann.

Performancetests

Netzwerk-Datentransferraten

Für die Datentransfers nutzte ich weiterhin speedtest-cli und wählte daher folgende Peers gewählt:

• 30907) Deutsche Telekom Technik GmbH (Berlin, Germany) [394.94 km]
• 4886) Stadtwerke Neumünster GmbH (Neumunster, Germany) [538.44 km]
• 18667) meerfarbig GmbH & Co. KG (Frankfurt, Germany) [818.46 km]
• 21514) Contabo GmbH (Munich, Germany) [855.26 km]

Diese werden im Abstand von 20 Minuten jeweils doppelt sequenziell getestet und die Ergebnisse mittels –csv Parameter und entsprechender Ausgabeumleitung als CSV in eine Tabelle zur späteren Verarbeitung geschrieben, etwa so:

30907,Deutsche Telekom Technik GmbH,Berlin,2020-03-28T07:17:20.127799Z,422.89016707081726,27.723,189797326.6667173,4150220.759736613,,91.205.75.239
30907,Deutsche Telekom Technik GmbH,Berlin,2020-03-28T07:17:41.287859Z,422.89016707081726,23.271,188071670.36669397,4150181.2915712413,,91.205.75.239
20478,Contabo GmbH,Nuremberg,2020-03-28T07:18:02.505737Z,646.0977991623539,35.526,182002432.52288514,4067378.244187205,,91.205.75.239

Leider birgt die von Ubuntu paketierte speedtest-cli einen Bug, welcher hier dokumentiert ist und dafür sorgt, dass Upload-Tests bei etwa 4 Mbit/s limitiert werden. Unglücklicherweise wurde ich auf diesen Umstand erst nach dem Test von einer Woche Testdauer aufmerksam. Aus diesem Grund beinhalten die folgenden Graphen lediglich Download-Datenpunkte.

Die Transferraten sind relativ stabil zwischen 192 und 177 Mbit/s jenach Peer. Vereinzelt gab es Streuung nach unten in den Abendstunden und einigen Ausreißern, welche hauptsächlich auf die Gegenstellen zurückzuführen sind.

Zuvorkommend: Bereits nach dem Testzeitraum bot mir webh.pl auf Nachfrage an, den Server zwei weitere Tage testen zu können, um zumindest einige Ergebnisse zu den Uploadraten zu sammeln.

RAM-Benchmark

Für den RAM-Benchmark mache ich mir wieder sysbench und dessen memory-Modul zunutze. Ich teste den Datendurchsatz von Schreib- als auch den von Lesevorgängen.

sysbench --threads=4 memory run

Pro Testdurchlauf erhalte ich damit folgenden Output:

Total operations: 39587238 (3958095.14 per second)
38659.41 MiB transferred (3865.33 MiB/sec)

Im Test zeigte sich, dass die Durchsatzraten lesend zwischen 16000 MiB/s und 18000 MiB/s lagen und nur sehr selten unter 16000 MiB/s fielen.
Die Durchsatzraten schreibend hingegen lagen meist bei 5000 MiB/s und fielen nur selten unter 4500 MiB/s.

Im Ranking liegt das Testsystem von webh.pl damit hinter meinem in die Jahre gekommenen ThinkPad T420 (wenn ausgestattet mit zwei DDR3-1333-Riegeln) und dem performantesten meiner Servercow-vServer. Absolut betrachtet bietet webh.pl jedoch trotzdem vernünftige und auch über längere Zeiträume stabile RAM-Durchsatzraten.

“All servers have ddr4 ecc ram bands.”

webh.pl Support

CPU-Benchmark

Der CPU-Test fiel kleiner aus, da ich hierzu diesmal nur die “events per second” aufnahm. Hier zeigte sich, dass dieser Wert über den gesamten Testzeitraum hinweg zwischen 3600 und 4400 Events lag. Während dieser Wert ansich keine Aussage über die absolute CPU-Leistung zulässt, zeigt er doch die Abweichungen in bestimmten Lastsituationen (beispielsweise nachts, wenn CPU-intensive Anwendungen wie zur Kompression von Logs laufen).

Da ich zu dieser Metrik derzeit keine weiteren Vergleichswerte habe, fällt es hier schwer, die Ergebnisse ins Verhältnis zu setzen. Mein mittelmäßig ausgelasteter i5-2520M im ThinkPad T420 schaffte im Schnitt 2500 events pro Sekunde.

Bessere CPU-Tests bietet beispielsweise die Phoronix Test Suite, indem sie echte Anwendungsfälle (beispielsweise das kompilieren einer bestimmten Kernel-Version) abdeckt und die benötigte Zeit misst und aufzeichnet.

“In our infrastructure we use different processors within Intel Xeon Scalable gen 1 and gen 2 series.”

webh.pl Support

IO-Benchmark

Auch für den IO-Benchmark habe ich Daten über mehrere Tage hinweg aufgezeichnet. Im Schnitt erreichte ich hier für die folgenden Modi die folgenden Performancewerte:

seq read cached/direct	5900/183
rnd read cached/direct	7500/171
seq write cached/direct	174/48
rnd write cached/direct	111/114

“We have infrastructure where our hosts and storage are on different nodes. We’re attaching our working nodes to storage nodes. We’re using both ssd and nvme drives within our storage nodes and we’re currently moving everything to nvme.”

webh.pl Support

Fazit

Für wen die Systeme von webh.pl geeignet sind

Wer auf der Suche nach einem VPS mit stabiler Internetanbindung, gutem Standort und äußerst schnellem, freundlichem und zuvorkommendem Support ist, ist mit webh.pl gut bedient. Die Angebote sind nicht die billigsten, aber das Preis/Leistungs-Verhältnis stimmt definitiv.

webh.pl kommt in meinem Fall für zukünftige Projekte definitiv in die engere Auswahl.

Anmerkungen

Derzeit wird die Webseite von webh.pl in die englische und russische Sprache übersetzt. Deutsch soll laut webh.pl anschließend auch folgen. Es zeigte sich jedoch auch, dass eine automatische Übersetzung mit Google Translator völlig ausreichend ist, da die anschließenden Webinterfaces in vielen unterschiedlichen Sprachen, darunter Deutsch, verfügbar sind.

Bis auf die hängende Installation mit vorab eingegebenen SSH-Keys, die Tatsache, dass es noch kein IPv6 gibt und in manchen Fällen die Änderung von Reverse-DNS-Einträgen nicht durch den Kunden möglich ist, bin ich positiv beeindruckt.

Während dieses Tests …

Für diesen Test wurden insgesamt circa 1810G an Daten herunter- und 90G an Daten hochgeladen. Ferner wurden 203296740 ms (~56h) CPU-Zeit verbraucht und 211.680.000 IOPS durchgeführt.