2020-09-25 16:16

Virtuelle Server

In meinem Artikels über Homeserver hatte ich bereits angekündigt, noch etwas über (virtuelle) Server bei Hosting-Providern zu schreiben.

Bis 2003 diente ein alter, lauter und stromfressender PC im Flur meiner Wohnung als 24x7 laufender E-Mail Server. Um ihn abzulösen und die Wohnung auf einen höheren WAF (woman acceptance factor) anzuheben, schaute ich mich nach Mietangeboten für virtuelle Server um.

Xen

Schnell wurde ich fündig bei einem kleinen Provider im Südwesten Deutschlands, der Webhosting und virtuelle Server im Angebot hatte. Die Homepage wirkte freundlich und aufgeräumt, das öffentliche Kundenforum war voller hilfsbereiter Einträge, die Produkte des Anbieters wurden dort in hohen Tönen gelobt. An die genaue Ausstattung des Servers kann ich mich nicht mehr erinnern, aber das Angebot wirkte mit 5€ pro Monat bei Abschluss eines Jahresvertrags preiswert. Man konnte unter verschiedenen Distributionen wählen; ich entschied mich natürlich, wie auch bei allen späteren Mietservern, für Debian.

Über die Virtualisierungstechnologie machte der Provider auf seiner Homepage keine Angaben. Schnell stellte sich aber heraus, dass mein Server unter Xen betrieben wurde. Andere Kunden klagten im Forum teilweise über eine schlechte Performance und merkwürde Fehler, die ich auf meinem Server so nicht nachvollziehen konnte. Irgendwann wurde mir klar, dass der Provider unter der selben Produktbezeichnung unterschiedliche Virtualisierungstechnologien einsetzen musste, und ich eröffnete eine Diskussion im Forum darüber. Diese wurde jedoch schnell abgewürgt mit der Behauptung, dieses Thema gehöre nicht ins Forum, und nach kurzer Zeit ganz gelöscht, ebenso wie die Klagen über die Performance und Fehler.

Mit der Zeit eskalierte die Situation, immer mehr Kundenbeschwerden tauchten im Forum auf und wurden in immer kürzeren Zeitabständen gelöscht. Irgendwann traf es auch meinen Server. Während einer angekündigten “online” Storagemigration wurde er so unerträglich langsam, dass man sich nicht mehr einloggen konnte, weil die SSH Verbindungen alle in ein Timeout liefen. Gleichzeitig nahm er aber, wenn auch langsam, noch eingehende E-Mails entgegen, so dass diese für die Absender als zugestellt erschienen, ich jedoch nicht darauf zugreifen konnte. Nach einer Woche erholte sich die Performance aber wieder.

Ein weiteres Manko war das Fehlen von Netfilter/IPtables, obwohl das mit Xen damals schon möglich war. Der Provider hatte schlicht die entsprechenden Funktionen nicht in den DomU Kernel eincompiliert. Zwar braucht man auf einem einzelnen Server, der nur per SMTP und SSH zu erreichen ist, nicht zwingend eine Firewall. Allerdings wollte ich gerne das Logging von IPtables einschalten und zum Traffic-Accounting nutzen. Fast zeitglich zu meiner diesbezüglichen Anfrage kam eine Mail des Providers. Man hatte das Geschäft mit den Mietservern an einen Einzelunternehmer in NRW verkauft und konzentriere sich zukünftig auf das Webhosting. Der Vertrag ginge mit sofortiger Wirkung an den neuen Anbieter über. Auf die Frage zu IPtables kam keine Antwort.

Bei Ablauf des Jahresvertrags erwartete ich eigentlich ein Angebot des neuen Anbieters, aber es kam nichts. Stattdessen funktionierte der Server weiter, ohne dass Geld abgebucht oder eine Rechnung gestellt wurde. Nach mehreren Monaten wurde der Server dann plötzlich abgeschaltet. Per E-Mail verlange man eine Nachzahlung der offenen Beträge, andernfalls bliebe der Server aus und ich bekäme keine Möglichkeit zur Datensicherung. Ich wiederholte meine Frage nach der IPtables-Funktionalität und knüpfte daran meine Bereitschaft, den Vertrag zu velängern. Das wollte der Anbieter nicht. Wir einigten uns auf ein Vertragsende in wenigen Monaten und eine Nachzahlung der bis dahin angefallenen Monatsbeträge. Ich hatte Zeit, meine Daten zu sichern und einen neuen Anbieter zu suchen.

Wenige Monate nach meinem Weggang las ich in einem Diskussionsforum, dass der Anbieter Insolvenz angemeldet hatte und alle Hosts mit den virtuellen Servern abgeschaltet worden waren. Für eine einmalige Wieder-Inbetriebnahme zwecks Datensicherung müsste jeder Kunde 300€ bezahlen, da die Aktion mit einer Fahrt in das 200km entfernte Hosting-Rechenzentrum verbunden sei. Es kam wohl auch zu Rechtsstreitigkeiten deswegen.

Virtuozzo

Da die Suche nach einem neuen Anbieter einigermaßen eilig war, konnte ich nicht lange recherchieren und vergleichen. Nach den Erfahrungen mit Kleinfirmen und Einzelanbietern entschied mich für ein Angebot eines vergleichsweise großen Anbieters. Der virtuelle Server lag wieder in der Klasse um 5€/Monat bei 12 Monaten Vertragsbindung.

Dieses Mal basierte der Server auf Virtouzzo, einer kommerziellen Containertechnologie, von der es später auch eine Open Source Variante namens OpenVZ gab, die sogar eine kurze Zeit lang in Debian Linux verfügbar war. Virtuozzo war speziell für den Einsatz bei Providern auslegt und ermöglichte feingranulare Ressourcenlimits für zahlreiche Systemfunktionen. Der Server erfüllte im Wesentlichen unspektakulär seine Aufgaben als Mailserver. Auch ein Apache Webserver mit statischen Seiten und CGI-Skripten funktionierte klaglos. An seine Grenzen stieß das Angebot jedoch, als ich versuchte, für Web-Experimente eine MySQL Datenbank zu installieren. Trotz sorgfältigem Tuning stieß diese immer wieder gegen ein unerwartetes Ressourcenlimit und stürzte nach einigen Stunden bis Tagen ab.

Ansonsten gab es mit dem Server und dem Provider keine nennenswerten Schwierigkeiten oder Ereignisse. Das Ansinnen, dort auch dynamische Web-Applikationen zu betrieben, hatte ich schnell aufgegeben, aber als Mailserver behielt ich den Server mehrere Jahre lang.

In der Zwischenzeit hatte ich jedoch auch beruflich mit Linux-VServer, der wahrscheinlich ältesten Container-Technologie nach dem Chroot System Call, zu tun und war davon sehr angetan. Daher wuchs der Wunsch, Linux-VServer auch für meine privaten Zwecke einzusetzen.

Linux-VServer

Im Gegensatz zu Virtuozzo gab es nur wenige Provider, die virtuelle Server mit Linux-VServer anboten. Einer davon hatte einen sehr guten Ruf in der Community und wurde in Foren und im Usenet oft lobend erwähnt. Irgendwann wechselte auch ich zu diesem Anbieter.

Der Server, wieder in der Klasse um 5€/Monat, machte viele Jahre eine sehr gute Figur. Mailserver (Postfix), IMAP (Dovecot), Web (Apache), Datenbank (MySQL) und auch einige andere, zeitweise betriebenenen Anwendungen (z.b. Icecast2) hatten keine technischen Probleme; lediglich mit dem knappen RAM und Festplattenplatz musste man aufpassen.

Nach einigen Jahren voller Zufriedenheit kündigte sich eine Änderung an. Der Provider, ein Einzelunternehmer, trennte sich auf Überlastungsgründen von dem Providergeschäft und übergab es an ein Hosting-Unternehmen in NRW. Kurz nach dem Vertragswechsel folgte ein technischer Umzug, vermutlich eine Datenmigration mit rsync oder etwas ähnlichem, teilweise online. Dadurch wurde der Server längere Zeit quälend langsam und fiel mehrfach ganz aus.

Am Ende der Aktion funktionierten einige Dienste nicht mehr, z.B. Postfix. Bei näherer Analyse stellte ich fest, dass die Dateien und Verzeichnisse von Postfix plötzlich eine falsche UID und GID hatten. Aus meiner beruflichen Erfahrung kannte ich solche Probleme, die aus einer falsche Anwendung von rsync (fehlende Option --numeric-ids) oder tar (ohne --numeric-owner) entstehen. In diesem Fall konnte ich die Probleme selber beheben und Postfix wieder zum Laufen bringen. In der Folgezeit häuften sich aber kleinere Probleme, die nur der Provider beheben konnte, z.B. Ausfälle des Servers oder Netzwerkprobleme. Ich eröffnete jedes Mal einen Auftrag im Ticketsystem, der auch nach einigen Tagen bearbeitet wurde. Im Einzelnen waren es jeweils Kleinigkeiten, aber einfach zu viele.

Zudem gab es ein größeres Problem, dass der Provider nicht lösen konnte oder wollte. Zu Beginn lief der virtuelle Server, der Kernelversion nach zu urteilen, mit der gleichen Debian-Version wie der Host. Ich bin nicht mehr ganz sicher, aber es müsste Debian 5 gewesen sein. Als Debian 6 erschien, konnte ich selber upgraden, der Host-Kernel blieb jedoch gleich. Das Update auf Debian 7 konnte ich nicht mehr durchführen; dieses brachte eine neue libc-Version mit, die zu dem alten Kernel nicht mehr kompatibel war. Die Aussage des Providers war nur, dass die Linux-VServer basierenden Produkte abgekündigt seinen und ich auf sein neues Angebot wechseln sollte, das wieder auf Xen basierte.

OpenVZ

In der Zwischenzeit war ein anderer, in Thüringen beheimateter Provider einen damals ungewöhnlichen Schritt gegangen: er lud zu einem öffentlichen Betatest eines virtuellen Servers basierend auf OpenVZ ein. Der Anbieter hatte bis dahin nur physische Server im Angebot und wollte sein neues virtuelles Serverprodukt vor der offiziellen Markeinführung ausgiebig testen. Der Server war kostenlos und blieb es über ein Jahr, anschließend konnten die Betatester zu vergünstigen Konditionen den Server in der 5€ Klasse übernehmen, während er für Neukunden teurer angeboten wurde.

Nachdem ich einige Monate an dem Test teilgenommen hatte und meine Verbesserungsvorschläge, die ich im Forum niedergeschrieben hatte, tatsächlich umgesetzt wurden, wechselte ich direkt nach dem Ende des Betatests ganz zu diesem Anbieter. Damit war ich wieder mehrere Jahre lang zufrieden. Allerdings wurde die Performance langsam schlechter, vermutlich wegen stärker werdender Überbuchung des Hostsystems. Außerdem verblieb der Kernel auf einer immer älter werdenden Version, der Host war augenscheinlich auf einem in die Jahre gekommenen Fedora Linux stehen geblieben. Dies und der Wunsch nach mehr Leistung führen zu dem nächsten Wechsel, diesmal beim selben Provider.

Dedizierte Hardware

Dieser hatte nämlich angekündigt, einfache dedizierte Server zum Preis virtueller Server auf den Markt zu bringen. Es gab drei Modelle zu Preisen von ca. 6, 12 und 20 €/Monat. Ich entschied mich für den mittleren und bekam eine Intel Celeron J1800 CPU, 4 GB RAM und eine (allerdings relativ langsame) 1 TB SATA Festplatte; für die moderate Kostensteigerung also deutlich mehr Leistung als bei den typischen virtuellen Serverangeboten.

Der physische Server hat mehrere Vorteile gegenüber dem virtuellen. Die Leistung (CPU und I/O) kann nicht von anderen Kunden überbucht werden und ist damit sehr gut vorhersagbar. Auch muss ich mich nicht mit einem veralteten Host-Kernel und eingeschränken System Calls oder Ressourcenlimits herumschlagen.

Es gibt aber auch Nachteile; wenn der Server mal kaputt geht, muss ich mich zu einem unplanbaren Zeitpunkt mit dem Umzug der Daten auf ein Ersatzsystem herumschlagen; und mangels RAID droht ein Verlust der Daten bzw. Änderungen seit dem letzten Backup. Das ist in der Zeit, in der ich diesen Server hatte, nur einmal vorgekommen. Da war es sogar halbwegs planbar, weil sich der Ausfall der Festplatte durch S.M.A.R.T. Meldungen, Performancedegradierung und Defekte an einzelnen Dateien langsam ankündigte. Zudem habe ich die Leistung des Servers mit meinem Mailbetrieb nicht ansatzweise ausgelastet, vor allem die Kapazität der Festplatte. Letzlich ist ein virtueller Server für meinen Use Case ökonomisch und ökologisch sinnvoller.

KVM

So kam es zum bislang letzten Wechsel des Anbieters. Der aktuelle Server liegt wieder in der 5€ Klasse und läuft unter KVM. Die Leistungsdaten sind mit 1 CPU-Core und 40 GB Speicher eher klein, nur das RAM mit 4 GB durchaus üppig. CPU und RAM sind (angeblich) dediziert zugeordnet, können also auch bei Inaktivität nicht von anderen Kunden überbucht werden. Der Speicherplatz ist mit 40 GB zwar knapp, liegt aber auf einem Ceph Cluster aus NVME SSDs, so dass die Performance sehr gut ist und man sich um Datenverlust (hoffentlich) keine Gedanken machen muss.

Der Server läuft in einer Proxmox VE Virtualisierungsumgebung. Als Kunde erhält man Zugriff auf die KVM Konsole, so dass man sich selber helfen kann, wenn der Server nach einem Kernelupdate nicht mehr hochkommt oder man sich durch fehlerhafte IPtables Regeln vom SSH Login ausgesperrt hat.

Auf absehbare Zeit gibt es also keinen Grund, den Anbieter zu wechseln. Hoffentlich bleibt das noch eine Weile so.

Impressum