Wie ein tschechischer Mikro-MSP das AWS-Reselling durch Apache CloudStack ersetzte, um die Hosting-Margen von 5 % auf 60 % zu steigern

4

Lesen Sie 14 min.

Wenn ein Unternehmen nicht Server, sondern das Ergebnis verkauft – nämlich die funktionierenden Systeme seiner Kunden –, muss seine Infrastruktur vorhersehbare Kosten aufweisen und ohne unnötigen manuellen Aufwand verwaltet werden können. Diese Fallstudie zeigt, wie ein Anbieter von Managed IT Services aus der Tschechischen Republik die Systeme seiner Kunden von einem Hyperscaler auf einen einzigen gemieteten dedizierten Server mit einer privaten Apache CloudStack-Cloud umgestellt hat. Das Unternehmen profitierte von einer festen Abrechnung, einer Isolierung der Kunden und einer integrierten Nutzungserfassung und konnte gleichzeitig die Infrastrukturkosten um mehr als das Vier- bis Fünffache senken.

Hintergrund

Der Kunde ist ein Managed-IT-Services-Anbieter aus der Tschechischen Republik. Das Unternehmen betreut mehrere Dutzend B2B-Kunden in der Region und verwaltet deren gesamte IT-Umgebung: Workstation- und Server-Support, Backups, Überwachung, E-Mail, Buchhaltungssysteme, VPN und interne Anwendungen. Rechenressourcen sind eher ein Werkzeug als ein Produkt: Die Systeme der Kunden laufen auf virtuellen Maschinen, und der MSP ist im Rahmen von Supportverträgen für diese verantwortlich.

Die serverseitigen Systeme der Kunden wurden in der öffentlichen AWS-Cloud in der Region Frankfurt gehostet. Der MSP stellte die Infrastruktur für jeden Kunden separat bereit und bezog die Kosten dafür in die monatliche Supportgebühr ein, wobei er nach Angaben des Kunden im Durchschnitt einen Aufschlag von etwa 5 % berechnete.

Ziele und Ergebnisse

Die Ziele des Pilotprojekts waren:

Das Problem

Für den MSP stellte die Public-Cloud-Infrastruktur eine Durchlaufkostenposition dar. Die Rechnung umfasste Dutzende von Einzelposten und änderte sich von Monat zu Monat: Stundengebühren für CPU und Arbeitsspeicher, separate Gebühren für ausgehenden Datenverkehr, Speicherplatz und Snapshots. Es war unmöglich, dem Kunden vor Monatsende den genauen Betrag mitzuteilen. Preisänderungen wurden vom MSP aufgefangen, während die Erträge aus dem Infrastrukturanteil der Verträge auf einen Aufschlag von etwa 5 % begrenzt waren.

Das zweite Problem betraf die Verwaltung. Einige Kunden wollten ihre eigenen virtuellen Maschinen erstellen, stoppen und zurücksetzen, ohne Mitarbeiter des MSP zu kontaktieren. Den Kunden Zugriff auf die gemeinsam genutzte Cloud-Infrastruktur des MSP zu gewähren, war inakzeptabel, während separate Konten für jeden Kunden individuelle Berechtigungskonfigurationen, eine separate Abrechnung und eine separate Buchhaltung für jeden Kunden erforderten.

Der MSP wandte sich mit der Anfrage nach einem Pilotprojekt an INTROSERV: Anmietung eines dedizierten Servers in einem europäischen Rechenzentrum und Bereitstellung einer einsatzbereiten Private Cloud darauf als Ersatz für den Hyperscaler für typische Kundensysteme, mit der Option, später auf mehrere Knoten zu erweitern.

Infrastrukturkonfiguration

INTROSERV stellte einen dedizierten Server bereit, der in einem Tier-III-Rechenzentrum in den Niederlanden gehostet wird und eine garantierte Netzwerkverfügbarkeit von 99,99 % aufweist.

Hauptserver:

• CPU: 2x Intel Xeon Gold 6130 – 32 physische Kerne, 64 Threads, 2,10 GHz Basistakt, bis zu 3,70 GHz Turbo

• RAM: 256 GB REG ECC DDR4, erweiterbar auf 1 TB

• NVMe: 2x 3,84 TB im Software-RAID 1 – 3,84 TB lokaler Speicher für VM-Festplatten

• SATA: 4x 14 TB im Software-RAID 10 – 28 TB für Backups und sekundären Speicher

• Netzwerk: zwei 25-Gbit/s-Ports, unbegrenztes Datenvolumen; privates 10-Gbit/s-VLAN-Netzwerk

• Verwaltung: iDRAC

• DDoS-Schutz: 20 Gbit/s

• Redundante Stromversorgung

Ein Backup-Server für virtuelle Maschinen ist über ein privates 10-Gbit/s-VLAN-Netzwerk mit dem Hauptserver verbunden.

Der auf NAKIVO Backup & Replication basierende Backup-Service von INTROSERV kostet 49 € pro Monat für 5 TB. Der gesamte Server wird gesichert: das Host-Betriebssystem, die CloudStack-Konfiguration und die Datenbank des Verwaltungsservers. Bei einem Serverausfall wird das System anhand dieser Sicherung auf neuer Hardware bereitgestellt; anschließend werden die virtuellen Maschinen vom Backup-Server wiederhergestellt.

Die Konfiguration erfüllt die Anforderungen an die Fehlertoleranz auf Einzelmaschinenebene:

• Netzwerk: Zwei unabhängige 25-Gbit/s-Ports werden zu einer fehlertoleranten Verbindung gebündelt. Der Ausfall eines Ports oder einer Verbindung unterbricht den Betrieb der virtuellen Maschinen nicht.
• Stromversorgung: zwei Netzteile. Der Ausfall eines Netzteils führt nicht zum Herunterfahren des Servers.
• Festplatten: Alle Laufwerke sind in RAID-Arrays konfiguriert. Der Ausfall eines NVMe- oder eines SATA-Laufwerks führt weder zu Datenverlust noch zu Serverausfallzeiten.
• Speicher: Die Festplatten der virtuellen Maschinen werden auf einem lokalen NVMe-Array gespeichert, ohne dass Netzwerkspeicher zwischen dem Hypervisor und den Daten zum Einsatz kommt. Dies gewährleistet minimale E/A-Latenzzeiten für die Datenbanken und Buchhaltungssysteme der Kunden.
• Backups: Backups der virtuellen Maschinen werden über ein privates 10-Gbit/s-Netzwerk auf einen separaten physischen Server übertragen, ohne dass externe Schnittstellen genutzt werden oder Datenverkehrskosten anfallen. Ein vollständiges Server-Backup wird im 5-TB-Speicher des Backup-Dienstes gespeichert.

Die Serverrechnung umfasst alles, was von einem Hyperscaler separat in Rechnung gestellt würde: Datenverkehr, redundantes Netzwerk und Stromversorgung, Festplatten-Fehlertoleranz, lokaler Hochgeschwindigkeitsspeicher, ein privates Netzwerk zum Backup-Server sowie die Fernverwaltung über iDRAC. Die beiden backupbezogenen Posten sind Festkostenposten.

Die Lösung

Das INTROSERV-Team hat Apache CloudStack auf dem Server in einer Ein-Knoten-Konfiguration bereitgestellt: Der Verwaltungsserver und der KVM-Host laufen auf derselben Maschine. Die Arbeiten wurden im Rahmen eines stundenbasierten Systemadministrationsdienstes durchgeführt, woraufhin die Plattformverwaltung an den Kunden übergeben wurde.

Warum Apache CloudStack statt Proxmox VE

Beide Plattformen sind Open Source und laufen auf KVM. Proxmox VE wird unter der AGPLv3 vertrieben und ist kostenlos nutzbar; ein kostenpflichtiges Abonnement pro CPU-Sockel ist lediglich für den Zugriff auf das Enterprise-Update-Repository und den technischen Support des Anbieters erforderlich. Apache CloudStack wird unter der Apache-Lizenz 2.0 vertrieben, ohne Gebühren für Sockel, Kerne oder VMs. Die Lizenzierung war nicht der ausschlaggebende Faktor. Ausschlaggebend waren vier in CloudStack integrierte Funktionen, für die in Proxmox VE externe Tools erforderlich sind:

• Mandantenfähigkeit. Domänen, Konten und Projekte mit Ressourcenbeschränkungen und Kontingenten für jeden Kunden. Kunden, die ihre eigene VM-Flotte verwalten wollten, erhielten ein eigenes Konto mit einer dedizierten Rolle: Sie können nur ihre eigenen Ressourcen einsehen, VMs erstellen und stoppen sowie Snapshots und Rollbacks innerhalb ihrer zugewiesenen Quote durchführen. Die Durchsetzung der Quoten erfolgt durch die Plattform und nicht durch einen manuellen Prozess.
• Nutzungserfassung. Der integrierte Usage Server erfasst den CPU-, Speicher-, Festplatten- und Datenverkehrskonsum für jedes Konto; das Quota-Plugin verwaltet die Salden auf Basis der Preispläne. Daten für interne Kostenkalkulationen und die Kundenabrechnung werden direkt aus der Plattform bezogen und müssen nicht manuell erfasst werden.
• Kubernetes. Der CloudStack Kubernetes Service stellt Kubernetes-Cluster für Kunden über die Konsole oder per API bereit und aktualisiert diese. Dazu gehören die Skalierung der Knoten sowie die Möglichkeit, CloudStack-Festplatten als Cluster-Volumes anzuschließen. Kunden, die containerisierte Anwendungen ausführen, erhalten einen Cluster, ohne dass eine separate Plattform erforderlich ist.
• Netzwerkdienste. Isolierte Netzwerke mit einem virtuellen Router für jeden Kunden: Firewall, NAT, Lastenausgleich und VPN.

Das Hinzufügen eines neuen Kunden ist zu einem standardisierten Vorgang geworden: Erstellen einer Domäne und eines Kontos, eines isolierten Netzwerks mit einem virtuellen Router, einer Kontingentierung sowie virtueller Maschinen anhand einer vorgefertigten Vorlage. All dies lässt sich über die Konsole oder per API sowie über den Terraform-Provider in wenigen Minuten erledigen – statt stundenlanger manueller Konfiguration in einer Hyperscaler-Konsole. Snapshots dienen als Rollback-Punkte vor Aktualisierungen des Kundensystems, während Vorlagen identische Basis-Images für alle Kunden bereitstellen.

Fehlertoleranzstufe

Die Systemverfügbarkeit ist für die Kunden des MSP wichtig, doch die Workloads – Buchhaltungssysteme, E-Mail und interne Anwendungen – erfordern keine Hochverfügbarkeit mit automatischem Neustart der VMs auf einem anderen Host innerhalb von Minuten. Die erste Kundengruppe verfügt nicht über Systeme mit ununterbrochenem Betrieb, bei denen Ausfallzeiten von mehreren Stunden zu direkten Verlusten führen würden; ein geplantes Wartungsfenster oder eine Wiederherstellung aus einem Backup ist für sie akzeptabel.

Daher wurde ein Hochverfügbarkeitscluster für das Pilotprojekt als übertrieben angesehen: Er erfordert mehrere Knoten und gemeinsam genutzten Speicher. Es wurde ein einzelner Knoten mit Redundanz auf Maschinenebene ausgewählt, und diese Konfiguration erwies sich als ausreichend. Komponentenausfälle werden auf Hardwareebene abgedeckt: zwei gebündelte 25-Gbit/s-Ports, zwei Netzteile und alle Festplatten in RAID-Arrays. Eine Verschlechterung der Array-Leistung sowie unzureichende Host-Ressourcen werden proaktiv überwacht, und Laufwerke werden ausgetauscht, bevor ein Problem die virtuellen Maschinen beeinträchtigt.

Ein vollständiger Serverausfall wird durch zwei Ebenen von Backups abgedeckt: Das Host-Backup in NAKIVO stellt das Betriebssystem und CloudStack auf einem neuen Server wieder her, ohne dass eine Neukonfiguration erforderlich ist, während Backups der virtuellen Maschinen die Systeme der Kunden wieder betriebsbereit machen. Für die Expansionsphase, in der die Infrastruktur auf mehrere Knoten anwächst, ist Hochverfügbarkeit vorgesehen – zusätzliche Hosts werden demselben CloudStack hinzugefügt, ohne die Plattform zu ändern.

Abgeschlossene Arbeiten

1. Servervorbereitung: Installation des Betriebssystems, Software-RAID-Arrays (RAID 1 auf NVMe, RAID 10 auf SATA), Bündelung von zwei 25-Gbit/s-Ports zu einer fehlertoleranten Verbindung sowie Konfiguration eines privaten VLAN-Netzwerks zum Backup-Server.

2.Installation des CloudStack-Managementservers und des KVM-Agenten auf einem einzelnen Knoten sowie Konfiguration der Datenbank und der System-VMs.

3. Erstellung der Zone, des Pods und des Clusters; Primärspeicher auf dem NVMe-Array und Sekundärspeicher auf dem SATA-Array.

4. Netzwerkmodell: isolierte Netzwerke mit einem virtuellen Router für jeden Kunden, einem öffentlichen IP-Bereich, Firewall-Regeln und NAT.

5. Betriebssystemvorlagen (Ubuntu, Debian, AlmaLinux, Windows Server) und Serviceangebote für drei Standard-VM-Größen.

6. Sicherung virtueller Maschinen auf einem separaten Backup-Server über ein privates 10-Gbit/s-Netzwerk; Anbindung des Servers an den NAKIVO-basierten Backup-Dienst von INTROSERV mit einem Zeitplan für vollständige Serversicherungen.

7. Domains und Konten für MSP-Kunden, Rollen und Ressourcenbeschränkungen, Aktivierung des Usage-Servers und des Quota-Plugins; Aktivierung des CloudStack-Kubernetes-Dienstes und Registrierung von ISO-Images, die Kubernetes-Binärdateien enthalten.

8. Proaktive Überwachung: Status des Host-Betriebssystems (CPU, Arbeitsspeicher, Festplattenspeicher, Netzwerkschnittstellen, Systemdienste) und der Festplatten-Arrays (RAID-Status, SMART-Metriken der Laufwerke), mit Benachrichtigungen an die INTROSERV-Techniker.

9. Tests: Test-VMs in allen drei Größen, Snapshots und Rollbacks, Zugriff auf externe Netzwerke, Tests der VM-Sicherung sowie Tests der vollständigen Serversicherung.

10. Übergabe an den Kunden: CloudStack-Konsole, API-Schlüssel, Konfigurationsdokumentation und iDRAC-Zugriff.

Der Gesamtumfang der Arbeiten betrug 16 Stunden. Nach der Übergabe bietet INTROSERV Support auf Basis von Überwachungswarnungen oder Kundenanfragen an: Austausch von Laufwerken, Updates für Hypervisor und Verwaltungsserver sowie Konfigurationserweiterungen.

Platzierung virtueller Maschinen

Während des Pilotprojekts wurden 20 VMs, die Kundensysteme in drei Standardgrößen unterstützen, auf den Knoten migriert. Der Arbeitsspeicher wird ohne Überbelegung zugewiesen: 64 GB stehen weiterhin für den Verwaltungsserver, die System-VMs und die nächsten Kundensysteme zur Verfügung. Alle Festplatten der virtuellen Maschinen befinden sich auf dem lokalen NVMe-Array des Servers, wodurch jede VM die Festplattenleistung erhält, für die nach den Speicherpreisen des Hyperscalers für garantierte IOPS eine separate Gebühr angefallen wäre.

Virtuelle CPUs werden mit minimaler Überbelegung zugewiesen – 72 vCPUs für 64 Threads –, während die tatsächliche CPU-Auslastung während der Geschäftszeiten 50 % nicht überschreitet. Auf dem NVMe-Array bleiben etwa 700 GB frei. Da es sich um ein Pilotprojekt handelt, wurde diese Kapazitätsreserve bewusst vorgesehen: Weitere Kundensysteme können demselben Knoten hinzugefügt werden, ohne die Konfiguration zu ändern, während eine Erweiterung des Arbeitsspeichers auf 1 TB und das Hinzufügen weiterer Laufwerke die Kapazität des Knotens um ein Vielfaches erhöht.

Infrastruktur als strategischer Vorteil

Die vom INTROSERV-Team implementierte Lösung ersetzte den Hyperscaler als Anbieter von Rechenressourcen für die Kundensysteme des MSP. Ein einzelner gemieteter Server mit Apache CloudStack übernahm die erste Gruppe von 20 virtuellen Maschinen mit Raum für Wachstum und einer der Arbeitslast angemessenen Fehlertoleranz.

Der Kunde erhielt Funktionen, die in der Public Cloud nicht verfügbar waren: Kundenisolierung und Nutzungserfassung auf Plattformebene, Self-Service für Kunden mit eigenen Konten, Kubernetes-Cluster über dieselbe Konsole sowie proaktive Überwachung des Hosts und der Festplatten-Arrays. Netzwerk- und Stromredundanz, RAID-geschützte Festplatten, lokaler NVMe-Speicher, unbegrenzte 25-Gbit/s-Ports sowie DDoS-Schutz sind in den Serverkosten enthalten.

Wirtschaftlichkeit

Der Großteil des Datenverkehrs läuft über die VPN-Server der Kunden: Der ausgehende Datenverkehr des Knotens beträgt 20–35 TB pro Monat. Ein gleichwertiger Ressourcenumfang beim bisherigen Anbieter – 20 virtuelle Maschinen mit demselben Profil, Speicher, Snapshots und diesem Ausgehverkehrsvolumen zu den aktuellen Tarifen in der Region Frankfurt – kostet etwa 4.000–5.100 € pro Monat bzw. rund 54.000 € pro Jahr. Davon entfallen zwischen 1.500 € und 2.600 € auf den Datenverkehr: Beim Hyperscaler wird jedes Gigabyte, das über das VPN an die Mitarbeiter der Kunden übertragen wird, separat abgerechnet.

INTROSERV kostet 1.017 € pro Monat: 671 € für den Hauptserver, 157 € für den Backup-Server, 49 € für das vollständige Server-Backup; der Rest deckt die bedarfsorientierte Administration und die Amortisation der einmaligen Bereitstellung ab. Zwei 25-Gbit/s-Ports mit unbegrenztem Datenverkehr sind in der Servermiete enthalten, sodass der von den Kundensystemen erzeugte ausgehende Datenverkehr keinen Einfluss auf die Rechnung hat, egal ob es sich um 35 oder 50 TB pro Monat handelt.

Die Kostenbasis ist vier- bis fünfmal niedriger, der Betrag ist fest und bereits vor Monatsbeginn bekannt. Dies ermöglichte es dem Kunden, die Infrastruktur in eine feste Supportgebühr einzubeziehen, seinen Kunden günstigere Konditionen anzubieten und die Rentabilität des Infrastrukturanteils seiner Verträge zu steigern. Mit dem Wachstum des Kundenportfolios vergrößert sich der Abstand zum Hyperscaler – die Serverkosten hängen nicht vom Datenverkehr oder von Änderungen der Instanzpreise ab. Der Kunde war mit den Kosten der Lösung voll und ganz zufrieden.

Nächste Schritte

Die offene Plattform ohne Lizenzgebühren löste das Skalierungsproblem: Eine Erweiterung des Arbeitsspeichers auf 1 TB erhöht die Kapazität eines Knotens um ein Vielfaches, während ein zweiter Knoten zum bestehenden CloudStack-Cluster hinzugefügt werden kann, ohne dass ein Wechsel der Tools erforderlich ist. Kundendaten verbleiben auf dedizierten Servern in einem europäischen Rechenzentrum innerhalb eines vom Kunden kontrollierten Perimeters. Für ein Unternehmen, das Kunden in der EU gemäß den Anforderungen der DSGVO bedient, ist dies eine zwingende Voraussetzung. Im Anschluss an das Pilotprojekt wird der MSP entscheiden, ob weitere Gruppen von Kundensystemen auf CloudStack migriert werden sollen.

Sind Ihre Infrastrukturkosten bei einem Hyperscaler höher als nötig, während die Rechnung nach wie vor unvorhersehbar ist? Beauftragen Sie das INTROSERV-Team mit der Migration: Wir wählen die richtige Serverkonfiguration aus, stellen Apache CloudStack bereit und übergeben Ihnen eine einsatzbereite Private Cloud.