Schlagwort: Kommentar

Die Ausgangslage

Nachdem ich mir einen neuen VPS (Virtual Private Server) angemietet habe, der ausschließlich auf SSDs setzt, ist die Schreib- / Leseperformanz zwar deutlich besser als vorher mit HDD aber SSD Speicherplatz ist nach wie vor teurer als klassische Festplatten. Somit sind VPS Server die auf SSD basieren teurer bzw. andersrum gibt es für das gleiche Geld deutlich weniger Speicherplatz. Bei Contabo ist der angebotene Speicherplatz ca. halb so groß wie bei den HDD Servern.

Somit hat sich mir die Frage gestellt, wie ich von dem alten Server mit 1,4 TB Speicherplatz auf einen Server mit 800GB umziehen kann ohne zu viel Sicherheit / Komfort zu verlieren.  Voll war der Server nicht aber es waren über ca. 950 GB belegt.

Ein guter Teil des Speicherplatzes auf dem Server ist von Backups belegt, die man auf einem Server unweigerlich benötigt, gerade auch wenn man mal etwas testet / ausprobiert. Neben dem Buchblog sind auf dem Server auch diverse andere Dienste. Der Blog nimmt eher den kleinsten Teil ein. Oft fallen Fehler auch nicht direkt auf, weil man nicht jede Funktion täglich nutzt. Somit schadet es nicht auch mal einen alten Stand einsehen zu können? War das schon immer so? Wie war es wann?

Backups aber wie?

Tägliche Backups speichern in der Regel von Tag zu Tag das gleiche (es ändert sich ja kaum was, wenn man zum Beispiel auf dem Blog ein oder zwei Beiträge verfasst). Viele Backuplösungen in Linux basieren auf Rsync. Rsync ist ein sehr gutes Tool zum synchronisieren zwischen zwei Verzeichnissen und bietet Funktionen wie Resuming / Checksummenprüfung usw. mit. Für Backups ist es aber nur bedingt geeignet, weil es die Daten einfach x Mal neu anlegt.

D.h. es werden bei einem Backupsystem (z.B. Daten der letzten 3 Tage, vorherigen 2 Wochen, letzten 2 Monate, letzte 2 Jahre = 3+2+2+3 = 10 facher Platz der Daten). Wenn man 50GB sichert, dann sind das mal eben 500GB nur für Backups. Dafür ist SSD Speicherplatz eigentlich zu schade.

Alternativ bieten sich Backuplösungen an, die Daten komprimieren. Diese lassen sich jedoch schlechter lesen. Einige Varianten müssen erst entpackt werden. Auf Linux gibt es z.B. Tar in Kombination mit einem Packverfahren. Das ist mit einer SSD und nicht zu großen Files ganz erträglich. Ein direkter Zugriff auf einzelne Dateien ist aber ziemlich unpraktisch, weil die ganze Datei gelesen werden muss (das ist der Teil wo die SSD durch höhere Leseraten den Prozess halbwegs erträglich macht). Wenn so eine große Datei beschädigt wird, kann es aber auch sein, dass das ganze Backup nicht mehr lesbar ist.

In einer grafischen Umgebung dauert das Öffnen zwar eine Weile ist aber von der Bedienung ansonsten erträglich. Wenn man auf der Kommandozeile arbeitet, wird es aber ziemlich unschön, weil es nicht einfach möglich ist Verzeichnisse zu entpacken oder ähnliches durchzuführen. Im schlimmsten Fall muss man also alles auspacken. Das benötigt Zeit und Speicherplatz.

Es gibt auch weitere Lösungen wie z.B. Bacula, was aber recht aufgebläht ist (ein Webfrontend – das benötigt also einen Webserver – für eine Backuplösung finde ich zum Beispiel ziemlich unglücklich). Im Zweifelsfall kommt man nur noch mit einer Rescuecd an den Server und dann sollte das Restore einfach sein.

Zusätzlich ist die Lösung halbkommerziell. Man kann sich also soweit ich das gesehen habe nicht einfach die aktuelle Version per apt install ziehen ohne einen Key dafür zu haben. Bei der 9.4er Version hat bei mir die Installation in Ubuntu 20.04 nicht funktioniert. Auch das ist nicht vertrauensbildend aber Ubuntu 20.04 holpert eh noch an so einigen Stellen aktuell.

Filesystem zur Backupunterstützung?

Ich hatte schon vor einer Weile von Dateisystemen wie BTRFS / ZFS angesehen aber die Guides zu dem Thema sahen nicht so einfach aus und die diversen Anmerkungen dies oder jenes ist nicht stabil oder “ich würde es nicht produktiv verwenden”, haben mich immer wieder abgehalten.

Für Btrfs spricht, dass es Komprimierung unterstützt. Das heißt die Dateien werden zum Teil deutlich kleiner, als im Original, sind aber transparent zugreifbar. Man benötigt keine extra Werkzeuge und kann direkt per Kommandozeile die Dateien zugreifen, ohne mit zusätzlichen Programmen / Befehlen zu hantieren (so als wenn sie nicht komprimiert wären). Zusatznutzen ohne Komforteinbußen hört sich immer gut an.

Weiterhin beherrscht Btrfs die Deduplizierung. In Obigem Fall von 10 Kopien wird also nur 1/10 des Platzes belegt, wenn sich die Daten nicht geändert haben. Wenn sich die Daten drei mal geändert haben dann eben 3/10 (ausgehend von ca. gleicher Gesamtgröße). Man steht also in Kombination mit der Komprimierung immer noch deutlich besser da.

Mein Backup mache ich mit Timeshift / Backintime. Beides sind Werkzeuge, die auf RSYNC basieren. In Kombination mit einem Filesystem wie BTRFS oder ZFS führ das aber in der Theorie zu einer deutlichen Verringerung des belegten Speicherplatzes. Die Komprimierung liegt ca. bei dem Faktor 2,5 bis 3. Allerdings werden nur bestimmte Datentypen komprimiert.

Ein weiterer Vorteil, der mich aktuell nicht interessiert ist die Snapshotfunktion. Diese Funktion hat mein Server über die SSDs bereits eingebaut. Ich kann also über den VPS 3 Snapshots erzeugen und zu diesen Ständen zurückkehren.

Diese Funktion werde ich ggf. Später testen. Die Snapshotfunktion ist z.B. interessant, wenn man ein neues Betriebssystem installiert und dabei geht etwas schief. Man kann damit sehr leicht und schnell zu einem vorherigen Stand zurückkehren. Beim Test von Ubuntu 20.04 hätte mir die Funktion wohl einen Tag Arbeit erspart. Mittlerweile habe ich es installiert aber ohne Snapshots (in meinem Fall direkt auf dem SSD Server, hätte ich das definitiv nicht gemacht).

Welches darf es den sein ZFS oder Btrfs?

Die oben genannten Funktionen bieten sowohl ZFS als auch Btrfs. Btrfs ist allerdings bei meinem VPS anbietet bereits in der Rescue CD integriert. Weiterhin bietet das auf der Rescue CD integrierte Pratitionierungswerkzeug Btrfs an und Btrfs bietet eine Migration von Ext4 nach Btrfs an. Besonders letzterer Aspekt klang reizvoll.

Da ich vorher einen Snapshot erstellt hatte, habe ich die Migration gestartet und nach grob 4-5 Stunden (auf einer SSD! – nur ca. 30-40MB pro Sekunden und nur ein Kern der CPU benutzt) war die Migration durch. Danach habe ich das Laufwerk gemountet und dann beim Boot diverse Fehlermeldungen bekommen. Scheinbar ist das mit dem Migrieren doch nicht so einfach wie versprochen. Die Warnung vorher Backups durchzuführen ist also absolut ernst zu nehmen.

Das Vertrauen in Btrfs und die Migrationsfunktion war bereits gesunken aber dank Snapshot habe ich einen zweiten Versuch gestartet. Der ist schon viel früher abgebrochen. Somit stand für mich fest, die Migration kann man vergessen. Theoretisch soll man die auch rückgängig machen können aber da ich einen Snapshot hatte, habe ich das gelassen.

Somit bin ich zu Ansatz zwei übergegangen. Eine neue Partition mit Btrfs zusätzlich zur vorhandenen

Nach den obigen Migrationsversuchen war das Vertrauen in Btrfs deutlich geschrumpft aber ganz ehrlich: Ich habe noch nie eine erfolgreiche Migration von einem Dateisystem in ein andres gesehen.

Backup mit Btrfs

Mein Hauptfokus lag auf der Verkleinerung der Backups also lag es nahe einen Teil der 800GB als Bbtrfs Partition anzulegen. Somit habe ich über das Rettungsystem Gparted gestartet und 200GB in Btrfs umgewandelt. Dort habe ich mehrere Subvolumes angelegt (Backintime, Timeshift, Root – für einen späteren Boottest, Snapshot – für spätere Snapshottests), dort kann man wiederum ein weiteres Subvolume für jedes Subvolume anlegen, von dem man Snapshots erstellen will).

Die Trennung der Snapshots hat damit zu tun, dass man die beim Zurücksetzen eines anderen Snapshots nicht verlieren möchte. Somit sollten man die separat halten.

Wichtig ist, dass man beim Mounten (ich habe direkt die Variante über die fstab Einbindung genutzt) die Komprimierung aktiviert. Die Daten werden dann während des Schreibens gepackt. Das komprimieren geht auch nachträglich, ist aber aufwendiger. Das Aktivieren der Komprimierung auf oberster Ebene hat sich auf die Subvolumes vererbt.

Anschließend kann man die Daten ganz normal auf das Laufwerk schreiben, dass in das Dateisystem eingebunden wird (in meinem Fall Verzeichnis btrfs mit den o.g. Unterverzeichnissen / Subvolumes).

Das Ergebnis vom Packen war bereits vielversprechend. Die Daten werden deutlich geschrumpft. Allerdings packt Btrfs mit den Standardeinstellungen nur die Daten, bei denen es eine deutliche Einsparung erwartet. Dateien bei denen das nicht der Fall ist, werden nicht gepackt. Man kann das erzwingen aber das habe ich bisher nicht getestet.

Der zweite Schritt ist das Deduplizieren. Das macht Btrfs nicht beim Schreiben, sondern man kann es nachträglich ausführen. Interessant ist dabei, dass man für jedes Subvolume einzelne Snapshots erstellen kann aber das Deduplizieren volumeübergreifend funktioniert.

Was bringt’s?

Bei obigem Beispiel würde also bei moderater Datenänderung zwischen 1/10 (Bester Fall fast ohne Änderungen der Daten) und 1/2 (bei deutlich mehr Änderungen) der Daten übrig bleiben. Wie sich in meinem Fall gezeigt hat sind es etwas mehr als 1/4.

Die o.g. Zahlen verstehe ich so:

Ursprünglich wurden durch die Daten 314GB belegt. Fast die Hälfte der Daten wurde komprimiert (152GB). Die komprimierten Daten hatten nach der Komprimierung noch ca. 1/3 der vorherigen Größe (das passt auch zu den Messungen die ich im Netz gefunden habe).

Der zweite Effekt ist die Deduplizierung, die in einem Backupszenario extrem gut funktioniert. Effektiv werden die vorher 314GB auf 86GB gespeichert. Das ist nicht schlecht dafür, dass ich den geringsten Kompressionslevel (ZSTD1) verwendet habe ohne erzwungene Komprimierung.

Es kann sein, dass man noch etwas mehr rausholen kann allerdings steigt die Rechenzeit dafür überproportional an. Sollten über die Komprimierung noch mal 5GB eingespart werden können, wird das ziemlich lange dauern bzw. zu sehr geringen Schreibraten führen. Den Effekt der erzwungenen Komprimierung kann ich nicht abschätzen.

Die Performanz beim Schreiben kann ich nicht wirklich bewerten, weil es sich um ein VPS handelt und die Performanz dort naturgemäß geteilt ist. Teilweise waren es 200MB, teilweise auch nur 50MB/s. Die Schreibgeschwindigkeit mit Komprimierung ist natürlich nicht so hoch wie z.B. bei ext4 ohne Komprimierung.

Die Frage ist was limitierend ist (wenn es die Schreibleistung der SSD / HDD ist, dann kann Btrfs schneller sein als ext4, wenn es die Rechenleistung des Prozessors ist, dann wird eher das Gegenteil der Fall sein, wenn man die Komprimierung verwendet).

Man möge mich korrigieren, wenn ich mit obigen Annahmen falsch liege aber meine Einschätzung der Daten oben deckt sich ca. mit der Ersparnis, sollte also richtig sein.

Ist Btrfs stabil?

Das wird die Zeit zeigen. Ich gehe im schlimmsten Fall das Risiko ein meine Backups zu verlieren. So lange ich nicht gleichzeitig die Originale kaputt mache, ist das Risiko begrenzt. Zumal ich bei dem SSD Server nun zusätzlich Snapshots anfertigen kann und somit (sofern ich denn vorher einen Snapshot erzeugt habe) auf diesen Stand zurückkehren kann. Das Risiko sollte also begrenzt sein.

Die Funktionen, die nicht stabil waren scheinen aber bereits vor zwei Jahren angepasst worden zu sein. Die Probleme bezogen sich auch primär auf Raid 5 / 6. Ich benutze kein Raid.

Aktuell konnte ich aber auch nicht erkennen, dass die Entwicklung voran getrieben wird oder zumindest kommunizieren die Entwickler das nicht. Die arbeiten offenbar eher im stillen Kämmerlein für sich selbst.

Somit sind die Guides alle nicht aktuell und vieles von dem was man dort findet ist veraltet. Einige Einstellungen sind überholt oder werden nicht mehr unterstützt.

Andersrum sind Werkzeuge wie die Deduplizierung nicht direkt integriert, sondern funktionieren über zusätzliche Tools, die oft auch mit nicht vertrauenserweckenden Kommentaren versehen sind (sollte funktionieren, sollte fehlerfrei sein). Der typische Informatikerkonjunktiv. Die Versionsstände sind oft alles andere als hoch 0.1x. Aber das muss alles nichts bedeuten. Bisher läuft es rund aber nach einer Woche ist das noch nicht viel Wert. 😉

Ein detailliertes How to zur Einrichtung von Btrfs in Kombination mit Luks Verschlüsselung habe ich ein einem separaten Blogpost erstellt.

Nachtrag 02.05.2020 – 22:00

Ich habe jetzt auch den Boot von Btrfs hinbekommen. Dafür habe ich mithilfe des Grubcustomizer einen neuen Booteintrag erzeugt und dort einfach die ID der Btrfs Partition angegeben und das entsprechende Subvolume. Die UUID bleibt immer die der Partition (auch wenn man Subvolumes adressiert!).

Beispieleinträge in der fstab:

UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs btrfs defaults,ssd,compress=zstd:1 0 0
UUID=f8fcb1ae-51b1-4ab2-b79d-66cf34ad77d9 /btrfs/ROOT/.snapshots btrfs defaults,ssd,compress=zstd:1,subvolid=422,subvol=/snapshots/ROOT_snaps 0 0

Was bedeutet das? Der Hauptknoten wird unter btrfs eingehängt. Alle untergeordneten Subvolumes werden dadurch automatisch gemountet. Der Zweite Eintrag mountet ein spezielles Subvolume auf /btrfs/ROOT/.snapshots. In der Subvolumehierarchie befindet sich das aber unter /snapshots/ROOT_snaps. Man muss immer aufpassen was Subvolumes und was Verzeichnisse sind. Im Verzeichnisbaum sieht das gleich aus.

Auch die Snapshotfunktion (zumindest das Anfertigen von Snapshots habe ich erfolgreich getestet).

Nachtrag 03.09.2020

Ich habe mittlerweile 2 Server komplett auf Btrfs umgestellt einschließlich dem ROOT Verzeichnis / Laufwerk. Somit spart man sich natürlich noch mal eine Kopie der Dateien und die Speicherung wird effizienter. Das setzt allerdings volles Vertrauen ins Dateisystem voraus.

Bisher hatte ich noch keine Probleme (auf Holz klopf), obwohl ich besonders den lokalen Sever auch schon mehrfach hart runtergefahren habe. Bei beiden Servern nutze ich keine Zusatzsoftware wie Timeshift / Backintime, sondern verwende die automatischen btrfs Snapshots über Snapper. Bei einem Server habe ich das Bootlaufwerk nicht umgestellt und nutze Btrfs nur für Backups mit Backintime und täglicher Deduplizierung.

Ich habe zwischenzeitlich auch noch Mal über ZFS nachgedacht aber die Deduplizierung funktioniert dort leider nur online und benötigt dann immens viel Speicher. Dazu kommt, dass Ubuntu zwar den Support eingebaut hat aber Tools wie gparted nach wie vor ZFS nicht anbieten. Das könnte man natürlich in der Kommandozeile lösen aber so lange mir Btrfs keinen Grund liefert, werde ich ZFS wohl nicht testen.

Weiterhin hat btrfs den Ruf nachträgliche Änderungen einfacher zu Unterstützen (z.B. Raidlevel), während bei ZFS ein Neuaufbau erforderlich ist. Bleibt noch die Aussage ZFS ist stabiler Aussage von einigen Leuten im Netz, die sich aber nicht objektiv untermauern lässt. Das hängt wohl auch immer von Versionen und Setup (z.B. Raid ja oder nein und wenn ja welcher Level) ab.

Strato Linux V40 vs. Contabo VPS 1400 vs. Contabo S SSD vs. Contabo VPS M und L

Man sollte meinen ein VPS Server ist ein VPS Server aber weit gefehlt.

Da ich in der letzten Zeit ziemlich viele Performanzprobleme mit einem meiner beiden VPS-Server bei Contabo hatte (mangelnde IO also Lese- und Schreibleistung der Festplatten, die dazu führt, dass der Server oft temporär nicht erreichbar ist bzw. nicht antwortet), habe ich mir die aktuellen Angebote des Wettbewerbs angeschaut.

Dabei bin ich auf ein Angebot von Strato gestoßen.

Die Eckdaten:

VPS 1400 von Contabo

6 CPU Kerne
20 GB RAM
1,4 TB HDD (angeblich SSD beschleunigt aber davon merkt man nichts)
1 GBit Netzanbindung
13€ pro Monat

Da ich Plesk nicht brauche, ist das Angebot eigentlich unnötig teuer aber trotzdem noch ziemlich gut in der Preisleistung.

Contabo VPS S SSD

4 CPU Kerne
8 GB RAM
0,2 TB HDD
200 MBit Netzanbindung
5€ pro Monat

Linux V40 von Strato

8 CPU Kerne
16 GB RAM
1,2 TB SSD
500 MBit Netzanbindung
17€ pro Monat mit Plesk (letzteres brauche ich nicht auf dem Server – Plesk vereinfacht den Einstieg in einen Linux VPS gerade für Anfänger deutlich. Man bekommt faktisch kaum mit, dass ein Linux drunter ist – mal abgesehen von der Geschwindigkeit)

Ich dachte bisher, dass sich die VPS Anbieter grundsätzlich gleichen aber ich wurde eines Besseren belehrt. Im Folgenden führe ich einige Punkte auf, bei denen sich die beiden Anbieter unterscheiden.

Anmerkungen

Contabo VPS 1400

• VNC Zugang (das bedeutet, man hat vollen Zugang auch wenn der Server bootet) und kann selbst dann darauf zugreifen, wenn der Internetzugang / SSH nicht funktioniert. Wenn man ihn gerade nicht benötigt, sollte man den VNC Zugriff aus Sicherheitsgründen im Kundenpanel deaktivieren, da die Verbindung unverschlüsselt ist. Es kann also jeder auf dem weg vom eigenen Rechner zum Server mitlauschen.
• Es gibt ein Rettungssystem mit Orignalsystem als separates Laufwerk, das manuell eingebunden werden muss. Das ist nicht komfortabel aber Linux Standard.
• Es werden keine Backups abseits dessen was man selbst auf dem Server einrichtet angefertigt (d.h. die gehen von dem Platz ab, den man auf dem Server hat). Empfehlen kann ich für den Zweck zum Beispiel Timeshift und Backintime.
• Eine Neuinstallation dauert bei Contabo ein paar Minuten, weil sie automatisiert durchgeführt wird und somit primär von der Geschwindigkeit des Systems abhängt
• Man hat die Auswahl zwischen diversen Betriebssystemen / Versionen und jeweils mit Webmin, mit Plesk, mit Datenbank usw. – das Ubuntu ist vollständig und keine kastrierte Sparversion
• Die Performanz des Festplatten schwankt im Schnitt zwischen 15 MB/s bis nichts und das meine ich durchaus wörtlich (letzteres kommt leider regelmäßig vor). Lt. mehreren Technikern von Contabo ist das bei shared Hosting normal. BEi meinem zweiten Contabo Server mit SSD habe ich das Problem allerdings noch nicht festgestellt. Zusätzlich gibt es noch regelmäßig Festplattenprüfläufe, die es noch schlimmer machen. Moderne Festplatten sollten Probleme mit S.M.A.R.T. eigentlich automatisch melden.
• Die Doku ist vergleichbar gut wie bei Hosteurope (da hatte ich vorher meinen Server, bis sie ins Ausland gegangen sind). Im Ausland gelten andere Rechte – beispielsweise gibt es in Frankreich (da ist Hosteurope mit seinen Servern zu großen Teilen gezogen) andere Terrorismusgesetze. Im Namen des Schutzes werden aber auch gerne andere Rechte ausgehebelt.
• Deutsches Rechenzentrum

Contabo VPS S SSD

• Es gilt weitgehend das was ich bereits zum VPS 1400 geschrieben habe.
• Der VPS S SSD bietet deutlich höhere IO Leistung und es arbeitet sich deutlich flüssiger an dem Server. Das fängt teilweise schon mit simplen Sachen an, wie dem Start eines Dateiexplorers wie zum Beispiel Nano. Der Dauert auf dem HDD Server mal ein oder 2 Sekunden aber auch mal 20 oder 30. Auf dem SSD Server geht das immer schnell.
• Man kann einen Snapshot erstellen. D.h. man hat ein Backup des Servers, dass man in wenigen Sekunden zurückspielen kann. Dabei wird der ganze Server wieder auf den vorherigen Stand gesetzt. Diese Art Backup wird aber “nur” einen Monat aufbewahrt. Anfangs habe ich das für nicht sinnvoll befunden aber andererseits ist es sinnvoller Snapshots nur Zeitnah zurück zu spielen.

Strato Linux V40

• Es gibt keinen VNC Zugriff (das ist eine extreme Einschränkung und es war mir nicht bewusst, dass es überhaupt Anbieter gibt, die einen derartigen Zugriff nicht ermöglichen). Das wird aber damit zusammen hängen, dass man auch keinen Zugriff auf den Bootlevel hat (sprich der Bootvorgang / Bootmanager wird nicht emuliert). Dieser Aspekt wiegt um so schwerer, da es selbst nach dem Bootvorgang nicht möglich ist, einen Zugang einfach nachzurüsten. Selbst die Installation von einem aktuellen Gnome war nicht möglich. Somit lässt sich auch nicht einfach X2GO oder ein Remotedesktopzugriff nachrüsten.
• Es gibt einen Rettungszugriff der bequem aber seltsam realisiert ist. Das Originalsystem wird in einem Ordner (Repair) des Rettungssystems eingehängt. Man kann sich so nicht die Orignial UUID des Datenträger anzeigen lassen, weil der überhaupt nicht erscheint. Offenbar macht das aber bei Strato eh keinen Sinn, weil man auf diesem Level überhaupt keinen Zugriff hat.
• Backups werden täglich automatisch erstellt (10 Stück rollierend) und können vollständig zurückgespielt werden. Wie / welches Backupverfahren genutzt wird ist unklar. Snapshots scheinen es nicht zu sein lt. Beschreibung, da die Wiederherstellung “stunden” oder bis “zu drei Tage” dauern soll. Es ist auch unklar, ob wirklich alles gesichert wird, da man selber offenbar nicht auf alle Daten Zugriff hat (siehe weiter unten) bzw. diverse Dateien durch die Strato Visualisierung eh überschrieben werden. Da die Backups nach Lust und Laune von Strato angefertigt werden (beliebige Uhrzeit) und die Rückspielung offenbar ewig dauert (auch manuell?!), ist die Idee zwar nett aber eigentlich nur für für einen Totalausfall brauchbar, bei dem man anders nichts mehr retten kann. Selbst dann sind bis zu 4 Tage Ausfallzeit selbst für einen VPS Anbieter ziemlich heftig, um ein simples Backup zurück zu spielen. Bei einem Totalausfall hat man immerhin den Stand vom Vortag bzw. von vor 4 Tagen, wenn Strato so lange benötigt um das Backup zurück zu spielen. Zusätzlich ist auch in diesem Fall die Doku mal wieder falsch. Es ist weder möglich bestimmte Snapshots als permanent zu markieren, noch kann man manuell Backups erstellen, wie es in der Doku beschrieben wird.
• Bei Strato dauert eine Neuinstallation Stunden (offenbar muss jemand per Hand installieren?! – bei mir hat das simple neu installieren des kastrierten Ubuntu 12 Stunden gedauert). Ich war zumindest sehr überrascht, dass es so extrem lange dauert. Sobald man eine Neuinstallation angefordert hat, kann man auch kein Backup mehr zurückspielen. Der Prozess scheint für einen derart großen Anbieter ziemlich vorsintflutlich zu sein. Vor allem wenn es eh so wenige unterschiedliche Images gibt, sollte die Neuinstallation in wenigen Minuten automatisiert erfolgen.
• Die Auswahl der Installationsimages ist sehr übersichtlich und nicht kundenfreundlich. Das Ubuntu 18.04 ist nicht vollständig installiert. Es fehlen diverse Pakete. Es gibt keine Datenbank und keinen kostenlosen Webzeugang wie z.B. Webmin. Offenbar geht Strato fest davon aus, dass man Plesk verwendet (weil es eh im Preis enthalten ist). Selbst Standardkomponenten wie z.B. Netplan bei Ubuntu fehlen. D.h. aus meiner Sicht ist das System überhaupt nicht dafür vorgesehen es abseits von einem Plesk zu betreiben. Das wird aber an den im folgenden erklärten Abbildungsvarianten liegen. Bei Contabo hat man vollen Zugriff und dementsprechend kann dem Anbieter egal sein was man auf dem Server installiert.
• Offenbar hat man keinen vollständigen Zugriff auf alle Ordner wie bei Contabo. Beispielsweise ist es mir nach einem vollständigen RSYNC nicht gelungen die vorher genutzte Betriebssystemversion zu starten. Der Server versucht trotzdem die Kernelversion des ursprünglich installierten Linux zu verwenden (ich gehe aktuell von einem versteckten boot Ordner aus, der abgearbeitet wird – offenbar auch eine Besonderheit der Virtualisierung bei Strato). Der Boot Ordner ist leer. Scheinbar wird Grub von außerhalb des Laufwerks gestartet auf das man Zugriff hat. Für mich ist das ein no go. Das erschwert den Umzug nach Strato und weider weg erheblich. Weiterhin bleibt der Server zum Teil eine Black Box (Stichwort überschriebene und generierte Dateien), da man weder einsehen noch steuern kann was Strato im Boot Verzeichnis macht, noch welche Dateien überschrieben werden. Für Server mit echtem Root Zugriff ist das nicht.
• Die zweite Partition wie ich sie bei Contabo habe (für Boot siehe vorheriger Punkt) und die Möglichkeit eines abgesicherten Starts oder den Wechsel auf eine vorherige Kernelversion – nebenbei Standardfunktionen von Linux oder auch Windows – existiert nicht.
• Die Dokumentation ist bescheiden (teilweise vollkommen veraltet) oder nicht vorhanden. Oft werden in der Doku andere Varianten beschrieben (Verzeichnisse anders, andere Adapternamen z.B. beim Netzwerkadapter) oder verschiedene Varianten beschrieben, bei denen vollkommen untransparent ist welche davon für den eigenen VPS Server relevant bzw. noch aktuell ist. Ohne Support kann man sich wegen der diversen Sonderlocken nicht selber helfen bzw. es fehlt die Doku. Ich unterstelle, dass ein paar Kundendienstmitarbeiter in einer Woche so viel Doku erstellen könnten, dass danach 50% der Supportanfragen überflüssig wären.
• Deutsches Rechenzentrum
• Diverse Dateien werden automatisch überschrieben beim Boot (interfaces, fstab) – bei Contabo passiert das nicht (voller Root Zugriff). Lt. Strato Support erfolgt das über die Virtualisierungsumgebung. Eine Doku darüber gibt es nicht. An einer Stelle ist beispielsweise in einer Readme dokumentiert, dass die Konfiguration durch ein Template erfolgen soll. Wenn man das Template anlegt, wird die Konfiguration der Originaldatei beim Boot trotzdem nach eigenem Gutdünken verändert.
• Die SSD scheinen erwartungsgemäß schnell zu sein. Wirklich testen konnte ich das nicht, da ich mein System auf dem Server nicht zum Laufen bekommen habe. Abseits von einigen Kernelfehlemeldungen bootet der Server zwar aber Netzzugriff bekommt man nicht. Ich vermute, dass es an der nicht vorgesehen Unterstützung von Netplan liegt evtl. aber auch daran, dass mein Linux 2 Jahre aktueller als der Stand von Strato ist. Das harmoniert nicht sonderlich gut zusammen. Da ich auch nicht die vollständige Konfiguration des Servers im Zugriff habe, kann ich das Problem auch nicht beheben. Ich müsste das Hostsystem neu installieren und dann auf den aktuellen Stand updaten. Das geht aber nicht, da Strato Updates des Hostsystems unterbindet. Ich werde aber sicher nicht das gesamte Linux neu installieren, nur weil Strato offenbar den Linux Standard neu auslegt bzw. allergisch gegen aktuelle Versionen ist. Stattdessen wird bei Strato eine 2 Jahre alte Version ohne Sicherheits(updates) verwendet.

Benchmarks / Performance

Kurz zur Erklärung. Die virtuellen Server basieren auf physischen CPUs. Die geben die VPS Anbieter in der Regel an. Somit lässt sich errechen welche Leistung einem theoretisch zur Verfügung stehen müsste. Wenn man zum Beispiel 6 Kerne gebucht hat und die Server CPU 10 Kerne hat, muss man schlicht durch 10 mal 6 rechnen, um die theoretische Leistung zu errechnen.

Contabo VPS 1400

Echte CPU Leistung des Prozessors:

Geekbench – Entspricht der CPU des Contabo VPS 1400 – theoretisch sollte man fast die volle Leistung erreichen, wenn man 6 Kerne gebucht hat. Vermutlich bekommt man aber eher Threads und nicht Kerne. Somit bekommt man reale 3 physische Kerne, die 6 virtuellen Kernen entsprechen.

Und im Vergleich die Werte auf dem VPS

Geekbench – Wie man erkennt liegt man bei ca. 55% der Leistung der physischen CPU – zu einer lastarmen Zeit am Wochenende. Das entspricht also ungefähr 6 der 12 Threads. Der wert liegt 15% über dem Anteil der zu erwarten wäre. Allerdings liefen auf dem Server auch diverse Anwendungen wie zum Beispiel Webserver. Die Grundlast ist aber ziemlich gering. Somit dürften das die 5% Differenz zum Contabo VPS S sein.

Sysbench – CPU

Sysbench Memory

Sysbench IO

Contabo VPS S

Geekbench – Da die CPU 10 Kerne hat, würden 4 davon der Rechnung durch 10 mal 4 entsprechen. Auch hier bekommt man aber eher Threads, also virtuelle Kerne. Bei einer echten CPU entspricht das also 2 physischen Kernen.

Geekbench – Man liegt bei 24% der realen CPU Leistung. Das ist 20% über dem was das Marketing verspricht. Es ist aber nicht garantiert.

Sysbench – CPU

Sysbench – Memory

Sysbench IO – Wie man unschwer erkennt ist die SSD 4x so schnell wie die Platten des Contabo 1400. Der gefühlte Unterschied ist aber größer. Bei der Latency ist es Faktor 7!. Das entspricht eher den realen Erfahrungen.

Strato Linux V40

Geekbench – Da die CPU 10 Kerne hat, würden 8 davon der Rechnung durch 10*8 entsprechen. Auch hier bekommt man aber wie bei Contabo eher Threads bzw. vrtuelle Kerne. Bei einer echten CPU entspricht das also eher 4 physischen Kernen.

Geekbench – Obwohl der Strato Linux V40 2 CPU Kerne mehr hat als der Contabo 1400 ist der Strato nicht schneller. Zusätzlich muss noch angemerkt werden, dass auf dem Strato abseits des kastrierten Ubuntu nichts lief. Der Strato V40 hatte also deutlich bessere Rahmenbedingungen. Man liegt bei ungefähr 38% der Leistung der realen CPU. Man bekommt also 95% der angepriesenen Leistung. Das geht i.O., wenn es denn zu laststarken Zeiten auch gehalten wird.

Sysbench lies sich auf dem Strato nicht installieren, wie auch so ziemlich nichts anderes. Sobald man Bibliotheken benötigt, die nicht in einer 2 Jahre alten Betriebssystemversion zurecht kommen bzw. andere Bibliotheken benötigen, die sich nicht updaten lassen, kann man die Installation vergessen. Somit viel der Test der IO Leistung leider aus. Der Bereich wäre wohl am ehesten der gewesen, wo der Strato hätte punkten können.

Benchmarkergebnis:

Die Benchmarks unterstreichen meinen bisherigen Eindruck der Leistungen. Man bekommt im Optimum 50% dessen was eine physische CPU leistet. Das erklärt auch den deutlichen Preisunterschied zwischen einem dedicated und einem VPS Server.

Es ist offensichtlich das eine SSD extrem viel schneller ist als eine HDD. Da man sich bei virtuellen Servern die Festplatten auch noch mit anderen teilen muss, ist zu Hochlastzeiten der Unterschied noch viel größer.

Zusammenfassung:

Generell gilt für VPS-Server: Die Angaben zu den CPU Kernen kann man vergessen. VPS Systeme werden überbucht (d.h. auf einen echten Kern kommen mindestens zwei virtuelle).

Erfahrungsgemäß ist die reale Leistung eher im Bereich 25-50% der Angaben von einem Rechner mit echten physischen Kernen, die einem zu 100% zur Verfügung stehen. Bei der IO Leistung sieht es bei Festplatten eher noch schlimmer aus. Da fühlt man sich teilweise an Transferraten von vor 20-25 Jahren erinnert.

Trotz der guten Eckdaten gibt es bei Strato erhebliche Einschränkungen, die aus dem Marketing der beiden Anbieter nicht ersichtlich sind. Das Marketing liest sich auf den ersten Blick relativ gleich.

Aufgrund der eingeschränkten Patchmöglichkeiten sind die Server von Strato aus meiner Sicht ein Sicherheitsrisiko und leider uninteressant und entgegen der Werbeversprechen ist bei Strato alles andere als voller Rootzugang gegeben.

Selbst beim Installieren der Pakete von meinem anderen Server gab es schon diverse Fehlermeldungen wegen eingeschränkter Rechte (das Werbeversprechen zur Administrationsfreiheit halte ich für eine Falschaussage). Es konnte nur ein Bruchteil der Pakete installiert werden.

Auch das Anpreisen von Ubuntu halte ich für sehr gewagt, da man bestenfalls ein sehr kastriertes Ubuntu bekommt. Mit einem vollwertigen Ubuntu hat das nicht viel zu tun. Etwas positiver kann man den Server als Plesk Server sehen, da auch Plesk sehr viel in das System eingreift, kann man den Server eh nicht mehr frei verwenden, ohne Gefahr zu laufen, dass eigene Konfigurationen durch Plesk überschrieben werden oder man selbst Probleme bei Plesk verursacht. Die von Strato verwendete Virtualisierung verstärkt diesen Effekt von Plesk lediglich zusätzlich.

Die Dauer einer Neuinstallation und des Rückspielens von Backups bei Strato wären schon vor 10 Jahren überholt gewesen. Heute sind sie völlig realitätsfern. Umso erstaunlicher ist, dass einem 10 Backupslots kostenlos zur Verfügung stehen, die nicht vom Platz auf dem Server abgezogen werden. Das ist wiederum als sehr positiv einzustufen. Allerdings wäre eine Snapshotfunktion bei SSDs viel sinnvoller. Die lässt sich in Sekunden zurückspielen und nicht stunden bis Tagen.

Fazit

Für mich gilt trotz der aktuell bescheidenen Performanz auf dem HDD System von Contabo, dass Strato keine bessere Alternative ist, auch wenn man Anhand der Eckdaten den Eindruck hat. Allerdings muss man auch sehr klar betonen, dass die offensichtliche Überbuchung der HDD Server bei Contabo, die teilweise zu erheblichen Leistungseinbußen führen, alles andere als akzeptabel sind.

Man muss immerhin bedenken, dass ich das größte HDD System gebucht habe und das zweite Paket das kleinste SSD System ist. Letzteres läuft trotzdem deutlich runder. Somit kann ich die HDD Server von Contabo nicht mal als Webserver empfehlen.

Der Unterschied bei der IO Leistung sich besonders gut anhand der oben gemessenen Latenzen darstellen. Dabei stellt der Faktor 7 wohl eher den Optimalzustand dar.

Empfehlen lässt sich nach diesem Test nur der Contabo mit SSD. Wenn es einem egal ist, wenn der Webserver zwischendurch mal für längere Zeit (Minuten bis Stunden) nicht oder nur extrem schlecht erreichbar ist, dann kann man auch einen VPS HDD Server von Contabo nutzen.

Der Strato ist aus meiner Sicht nur geeignet, wenn man ihn so nimmt wie er ist (mit Plesk) und nichts zusätzlich installiert. Unter Sicherheitsaspekten ist er aber auch dann ein nogo.

Update 08.03.2020:

Nachdem ich nun mehrfach (vermutlich in Summe so ca. 20 mal) wegen der miserablen IO Performance Kontakt zum Support von Contabo hatte, kann ich nur dringend von den Contabo HDD Servern abraten. Der Support erzählt einem gebetsmühlenartig, dass entweder gerade irgendwelche Tests auf den HDDs durchgeführt werden oder es zu einer temporären Lastspitze gekommen ist. Das passiert allerdings so häufig, dass die reale Verfügbarkeit der HDD Server ziemlich gering ist.

Wenn man also einen zuverlässig erreichbaren Server will, dann sollte man die SSD Server von Contabo buchen, sofern man dort mit dem Preisleistungsverhältnis zufrieden ist. Bei den HDD Servern muss man damit rechnen, dass die Minuten oder Stunden nicht antworten und zwar jederzeit.

Mein Eindruck ist, dass dem Support die Thematik sehr bewusst ist. Auf meine Argumente ist man dort nie eingegangen. Heute war der HDD Server bei der Zugriffszeit von minimalen Datenpaketen um Faktor 500 – 1000 Langsamer als der SSD Server (ein Zugriff 1,x Sekunden statt ein paar hundert us).

Update 14.05.2020:

Ich habe einen Contabo VPS einem Raspberry Pi gegenübergestellt. Der Pi behauptet sich ziemlich gut.

Zu dem VPS 1400 ist noch anzumerken, dass der noch langsamer geworden ist. Aufgrund einer Beschwerde wurde mein VPS dann auf ein anderes Hostsystem umgezogen. Der o.g. Benchmark ist von 20MB/s auf 150MB/s gestiegen und somit von der Übertragungsrate auf Werte, die man bei Contabo sonst nur mit SSD erreicht.

Weiterhin habe ich den VPS M auf VPS L migrieren lassen. Danach erfolgte auch ein Wechsel des Hostsystems. Die Schreibrate ist dann von ca. 80MB/S im Schnitt auf ca. 20MB/S im Schnitt eingebrochen, Auf meine Beschwerde wurde auch dieses System auf einen anderen Host migriert. D.h. o.g. Fazit muss ich korrigieren. Die IO Performanz ist bei Contabo nicht von dem gebuchten Technologie (SSD oder HDD) abhängig und auch nicht von der Größe des Systems, sondern einfach nur Glück. Sowohl bei SSDs sind 20 – 150MB/s Schreibrate möglich, als auch bei HDD Systemen. Bei letzteren ist lediglich die Latenz höher.

Sobald der Benchmark deutlich unter 50 MB/s sinkt steigen auch die Latenzen selbst bei SSD Servern teilweise in den Sekundenbereich und das System reagiert extrem lahm.

Update 19.06.2022:

Mittlerweile bin ich auf 2 VPS Servern mit SSD von Contabo unterwegs und beide laufen mittlerweile auf AMD EPYC 7282 Prozessoren. Man muss sich bewusst machen, dass man nach wie vor nur halbe physische Kerne bekommt. 8 Kerne bei einem VPS Anbieter entsprechen somit 4 physischen Kernen.

Cloud VPS L (single core und somit grob * 8):

sysbench --num-threads=1 --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1402.36

General statistics:
    total time:                          10.0013s
    total number of events:              14027

Latency (ms):
         min:                                    0.62
         avg:                                    0.71
         max:                                   25.15
         95th percentile:                        0.83
         sum:                                 9974.55

Threads fairness:
    events (avg/stddev):           14027.0000/0.00
    execution time (avg/stddev):   9.9745/0.00

Cloud VPS M (single core und somit grob * 6):

sysbench --num-threads=1 --test=cpu --cpu-max-prime=10000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1538.58

General statistics:
    total time:                          10.0004s
    total number of events:              15388

Latency (ms):
         min:                                    0.62
         avg:                                    0.65
         max:                                    8.80
         95th percentile:                        0.69
         sum:                                 9980.77

Threads fairness:
    events (avg/stddev):           15388.0000/0.00
    execution time (avg/stddev):   9.9808/0.00

Wie man sieht hat sich CPU Leistung gegenüber den alten Intel Systemen deutlich spürbar gesteigert. D.h. die VPS sind nach wie vor keine Performanzwunder – aber immerhin mittlerweile ungefähr so schnell wie ein passables NAS – siehe hier. Für einen privaten virtuellen Server sollten die Systeme ausreichen.

Bei der Datenbankperformanz schneidet Contabo aber selbst mit “SSD Speicher” ziemlich schlecht ab im Vergleich zu einem Odroid H2+ Kleinstrechner.

Contabo Server VPS L – gute CPU Leistung, miserable Datenbankperformance

Odroid H2+ Kleinstrechner mit SATA SSD

Und zur Bestätigung der obigen Werte zur Datenbankperformanz der VPS M

sysbench --test=fileio --file-test-mode=rndrw run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      1624.80
    writes/s:                     1083.20
    fsyncs/s:                     3477.30

Throughput:
    read, MiB/s:                  25.39
    written, MiB/s:               16.93

General statistics:
    total time:                          10.0434s
    total number of events:              61999

Latency (ms):
         min:                                    0.00
         avg:                                    0.16
         max:                                   61.46
         95th percentile:                        0.51
         sum:                                 9948.06

Threads fairness:
    events (avg/stddev):           61999.0000/0.00
    execution time (avg/stddev):   9.9481/0.00

Und der VPS L

sysbench --test=fileio --file-test-mode=rndrw run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Extra file open flags: (none)
128 files, 16MiB each
2GiB total file size
Block size 16KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...

Threads started!


File operations:
    reads/s:                      299.26
    writes/s:                     199.51
    fsyncs/s:                     650.70

Throughput:
    read, MiB/s:                  4.68
    written, MiB/s:               3.12

General statistics:
    total time:                          10.0237s
    total number of events:              11395

Latency (ms):
         min:                                    0.00
         avg:                                    0.88
         max:                                  106.22
         95th percentile:                        5.18
         sum:                                 9978.73

Threads fairness:
    events (avg/stddev):           11395.0000/0.00
    execution time (avg/stddev):   9.9787/0.00

Man sieht, dass die Storage Performanz bei Contabo nach wie vor ein Glücksspiel ist. Wie kann der Leistungsfähigere VPS 1/6 der Storage Leistung des schwächeren VPS haben?!

Update 03.11.2022: Neben der reinen Performanz, ist ein gewisser Grundlevel an Support bei einem Hoster sehr wichtig. In der Vergangenheit war Contabo trotz sehr günstiger Preise diesbezüglich vorbildlich. Aktuell hat man nun massiv die Preise erhöht und der Service ist mittlerweile nach meiner Erfahrung schlecht. Man bekommt oft erst nach mehreren Tagen Antworten und die sind qualitativ auch deutlich schlechter als früher. Es werden teilweise auch 30 oder 40€ für Tätigkeiten verlangt, die früher als Standardgeschäft durchgelaufen sind.

Es gibt aber nach meinem Stand wenig Alternativen mit einem echten Root Zugang, bei dem man frei jede Datei des Betriebssystems tauschen und jedes beliebige Betriebssystem aufspielen kann. Netcup ist eine davon, hat aber andere Macken (Snapshot belegt Speicherplatz auf dem Server) und ist teurer.

Die neuen Contabo Angebote – z.B. Storageserver sind preislich meiner Meinung nach nicht attraktiv, einen SSD Server mit Snapshotfunktion will man nicht mehr missen, wenn man mal einen hatte. Genau diese Funktion fehlt aber bei den Storageservern. Gegenüber den vorherigen HDD basierten Storageservern sind die SSD Varianten deutlich teurer.