Hosting-Konzepte mit ITEG-Betreuungsmöglichkeit
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.
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.
Server-Art | Vorteile | Nachteile |
|---|---|---|
Hetzner Dedicated Root Server (physische Server) | Größere Flexibilität bei initialer Resourcen-Auswahl. Keine Einschränkungen bei eigener Virtualisierung, fast beliebig viele Applikationsserver betreibbar. Garantiert kein Ausbremsen durch andere Housing-Kunden am gleichen Hardware-Knoten. Einrichtung Applikationsserver weniger aufwendig, durch Verwendung von ITEG-eigenen Templates. | Nachträgliche Erweiterung von Resourcen praktisch unmöglich. Hardware muss selber überwacht werden, der Tausch von z. B. defekten HDs durch den Anbieter muss aktiv vom Kunden bzw. ITEG getriggert werden. Bei günstigen Modellen ist das mit Downtime verbunden (weil nicht “Hot-Swap”). Einrichtung Host deutlich aufwendiger wegen Beschäftigung mit Hardware (IPMI, RAID, …). |
Hetzner Cloud-Server | Anbieter kümmert sich vollständig um Hardware. Umstieg auf mehr cores / RAM / storage im Betrieb möglich (begrenzte Auswahl). Block-Storage kann beliebig dazugebucht werden. | Geringere Flexibilität bei Resourcen-Auswahl (oft fixe Kombination cores/RAM/storage) (evtl. bei anderen Anbietern flexibler). Virtualiserung bzw. Subvirtualisierung ist eingeschränkt auf Docker, weil der Anbieter ja schon eine Virtualisierungsebene der CPU verbraucht. |
Bei mehreren benötigten Servern: Eigenständige Server vs. Virtualisierung
Variante | Beschreibung | Vorteile | Nachteile |
|---|---|---|---|
Eigenständige Server | Jeder Server als individueller Host, evtl. gemischt physisch und Cloud. | Bei Hardware-Problem nur 1 Applikations-Server betroffen. | Etwas mühsamer zu pflegen. |
Virtualisierung | Nur physische Hosts, Applikations-Server als LXC-Container | Weniger Hosts, leichter zu pflegen (durch ITEG's LXC-Utils). Leichterer Wechsel von Applikations-Servern auf andere Host-Server. Verschiedene Distros möglich, z.B. Host Debian, Applikations-Server Ubuntu LTS. Evtl. gemeinsame Nutzung von teuren IPv4-Adressen. | Starke Bindung an ITEG’s Setup-Pattern.
|
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
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.
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.