Einleitung

Ende 2021 hat ITEG beschlossen das Hosting für Kunden nicht mehr zu bewerben, und beginnend mit dem Root-Hosting keine neuen Hosting-Kunden mehr anzunehmen.

Die permanente Ruf-Bereitschaft wurde für das kleine Hosting-Team von ITEG eine zu massive Belastung. Für eine Entlastung der Individuen müssten wir das Hosting-Geschäft massiv ausbauen, das ist aber angesichts von unendlicher Konkurrenz, DSGVO, ISO27001-Zertifizierung u.v.ä. weder realistisch noch sinnvoll.

Stattdessen werden wir unser Know-How über zugleich effizientes und verantwortungsvolles Hosting künftig als reine Beratungs- und Betreuungs-Dienstleistung anbieten, wobei Betreuung nicht 24x7 sondern eher 10-to-18 werktags versprochen wird.

D.h. wir wollen Kunden dabei unterstützen beim Hosting von der Stange etwas passendes auszuwählen und das sinnvoll aufzusetzen und zu betreiben (Monitoring, Sicherheitsupdates, Backups, Analyse und Optimierung von Flaschenhälsen).

Im folgenden finden Sie dazu die von uns besonders gut unterstützbaren Hosting-Konzepte in unseren Worten bzw. unserer “Fach-Grammatik”.

Physische Server (Hosts) vs. Cloud-Server

Es gibt am Markt physische Miet-Server und etliche teils grundsätzlich verschiedene vServer/VPS- und Cloud-Hosting-Produkte zur Auswahl, bis hin zu neueren Konzepten wie Kubernetes-Clustern für OCI-Images (Schlagwort “Docker”).

Der einzige Root-Hosting-Anbieter mit dem ITEG bislang einigermaßen zufrieden ist ist Hetzner, wir betrachten daher vorläufig nur Hetzner-Produkte im Detail, es gilt aber für Produkte z.B. von IPAX analog.
Mit AWS, Azure u.ä. hat sich ITEG noch zu wenig beschäftigt um das guten Gewissens beraten zu können. Die Mitbetreuung eines vom Kunden oder anderen Dritten gestellten Linux-Servers ist natürlich immer möglich.

Bei mehreren benötigten Servern: Eigenständige Server vs. Virtualisierung vs. Virtualisierung mit Dockerisierung

Virtualisierung macht erst ab etwa 6 bis 10 Applikationsservern Sinn.

Failover- bzw. Migrations-Ansätze: Floating IPs vs. vSwitch vs. LoadBalancer vs. CloudFlare

Um bei Ausfällen oder Migrationen (z.b. neue Software-Generationen) möglichst nahtlos zwischen verschiedenen Applikations-Servern umschalten zu können gibt es verschiedene Ansätze.

Hetzner’s Floating IPs

Floating IPs sind einzelne IPs die man zwischen Servern umschalten kann (per WebUI bzw. REST-API).

Hetzner’s vSwitches

vSwitches sind virtuelle Switches an die man mehrere Server “virtuell anstecken” kann, sodass IPs in dem zugehörigen dedizierten Subnetz ohne Hetzner-spezifische Scripts zwischen den eigenen Servern wandern können.
ITEG hatte mit den vSwitches aber schon Probleme.

Load-Balancing durch Housing-Anbieter (Hetzner o.ä.) oder CDN-Anbietern (CloudFlare u.a.)

Bei Load-Balancern (vom Housing-Anbieter oder von einem davon unabhängigen CDN-Anbieter) sind die öffentlichen IPs ganz in Händen des Anbieters. Die Umschaltung zwischen verschiedenen Applikations-Servern erfolgt ggfs. über deren Web-UIs bzw. REST-APIs.

Im Falle eines “unabhängigen” CDN-Anbieters wie CloudFlare kann auch zwischen Applikations-Servern bei verschiedensten Anbietern umgeschalten werden. Allerdings gibt es keinen relevanten CDN-Anbieter der nicht dem US Cloud Act unterliegt, und dank NOYB wissen wir das ein solcher Anbieter auch mit neuen Standardvertragsklauseln (SCC) nicht wirklich DSGVO-kompatibel ist.

Verfügbarkeit

Hetzner ohne SLA gut genug?

Hetzner hat sich zwar bewährt, hat Probleme immer zügig gelöst, und taugt sicher als preiswerte Lösung für den Hausgebrauch.

Aber Hetzner garantiert bzw. verspricht keine bestimmte Verfügbarkeit, es gibt schlicht kein echtes SLA (Service-Level-Agreement).
Daher muss man als Kunde entscheiden ob damit leben kann dass bei Ausfällen keine garantierte Wiederherstellungszeit versprochen wird.

Falls das zu riskant bzw. kein akzeptierbares Risiko ist müsste man zumindest wichtige Server bei einem Anbieter mit SLA hosten, z.b. AWS, Azure, evtl. bei einem der noch überlebenden mittelständischen Anbieter (die aber großteils inzwischen auch zu US-basierten Konzernen gehören).

24x7 oder 9-to-5 werktags?

Falls ein Server wirklich 24x7 laufen soll kommt man realistisch nicht um global verteilte Lösungen herum, die aber proprietäre Lösungen oder die Anpassung der Applikation an proprietäre APIs von Cloud-Anbieteren wie z.B. AWS erfordern.

Bei vielen Cluster-Lösungen wird vergessen dass Daten synchron gehalten werden müssen und es kein verteiltes Storage-System mit 100% Verfügbarkeit und 100% Synchronität gibt.

Sonstiges

Regelmäßige OS-Updates alle 2 bis 5 Jahre → Dockerisierung

Alle 2 bis 5 Jahre muß man Debian bzw. Ubuntu Upgraden, auf gleicher oder vorübergehend parallel betriebener neuer Hardware, Setup-Kosten fallen dann in etwa wieder ähnlich an wie bei der Erstinstallation.

ITEG’s Strategie ist hier möglichst alles zu dockerisieren, um die Applikationen von OS-Versionen unabhängig zu machen.

Paket-Umfang ITEG-Betreuung, Verrechnung Zusatzarbeiten

ITEG-Betreuung umfasst Security-Updates (monatlich bzw. nach 0-days bei Verfügbarkeit), Monitoring, automatische Bearbeitung von System-Fehlern 10h-18h werktags, sowie kleine Konfigurations-Handgriffe.

Darüber hinausgehende Aktivitäten müssen nach Stunden oder nach individuell vereinbarten Pauschalpreis verrechnet werden, wobei das üblicherweise im vorhinein klargestellt wird.