Hybride Infrastruktur: Kombination aus dedizierten Servern und Cloud

Warum die reine Cloud bei anspruchsvollen Workloads versagt

Das Abrechnungsmodell der Cloud ist ein Vorteil, wenn das Datenaufkommen unvorhersehbar ist, und ein Nachteil, wenn es konstant bleibt. Eine SaaS-Anwendung, die täglich 50.000 Nutzer bedient, benötigt keine elastische Skalierung – sie benötigt eine zuverlässige Grundkapazität zu vorhersehbaren Kosten. Wenn man diese Arbeitslast auf Cloud-Rechenressourcen ausführt, bedeutet das, dass man On-Demand- oder Reservierungspreise für Ressourcen zahlen muss, die kontinuierlich genutzt werden – jede Stunde, jeden Tag.

Der Preisrechner von AWS selbst zeigt, dass dauerhafte Workloads auf EC2-Reserved-Instances bei vergleichbaren Spezifikationen oft das 3- bis 4-Fache der Preise für entsprechende dedizierte Server kosten. Für die „Extreme“-Dedicated-Server-Konfiguration – 16-Kern-AMD-EPYC-4545P, 192 GB DDR5-RAM, 2×3,84 TB NVMe ist es nicht einfach, eine Cloud-Instanz mit vergleichbaren Spezifikationen und 500 GB Backup-Speicher, Malware-Schutz sowie rund um die Uhr verfügbarem Managed Support zu einem Pauschalpreis von 349,99 $/Monat zu finden.

Was die Cloud wirklich besser kann: den Datenverkehr bewältigen, der deine festgelegte Basislast für kurze Zeiträume überschreitet, selten genutzte Daten kostengünstig speichern und geografisch verteilte Workloads in Regionen ausführen, in denen du keine Rechenzentren unterhältst.

Das Hybrid-Architekturmodell

In einer gut durchdachten Hybrid-Konfiguration werden Workload-Typen anhand ihrer Eigenschaften bestimmten Infrastruktur-Typen zugeordnet:

Ein dedizierter Server bietet:

• Kernanwendungslogik und APIs
• Primäre Datenbank (MySQL, PostgreSQL, Redis)
• Sitzungs- und Authentifizierungsdienste
• Speicherort der statischen Assets
• Dauerhaft gespeicherte Benutzerdaten

Cloud-Handles:

• Spitzenauslastung bei Traffic-Spitzen
• Warm-Standby für die Notfallwiederherstellung
• Cold-Backup-Speicher (S3-kompatibler Objektspeicher)
• Geografische Redundanz bei CDN-Origin-Servern
• Nicht-Produktionsumgebungen (Entwicklung, Staging, Qualitätssicherung)

Die wichtigste Erkenntnis ist, dass die meisten Anwendungsanfragen auf dem dedizierten Server landen, wo die Kosten pro Anfrage am niedrigsten sind. Die Cloud-Infrastruktur ist die meiste Zeit im Leerlauf oder nur gering ausgelastet, was bedeutet, dass du für den Basisverkehr keine Spitzenpreise für die Cloud zahlst.

Spitzenkapazität: Skalierung über den dedizierten Server hinaus

Wenn dein dedizierter Server bei einem Traffic-Anstieg – etwa bei einer Produkteinführung, einem viralen Moment oder einer geplanten Werbeaktion – an seine CPU- oder Speichergrenzen stößt, sorgt die zusätzliche Kapazität aus der Cloud dafür, dass die Anwendung reaktionsschnell bleibt, ohne dass eine dauerhaft überdimensionierte dedizierte Konfiguration erforderlich ist.

Die Implementierung nutzt einen Load Balancer (HAProxy oder Nginx, der auf dem dedizierten Server oder als Cloud-Dienst läuft), um den Überlauf-Traffic an Cloud-Instanzen weiterzuleiten, die bei Bedarf hochgefahren werden.

Grundlegende HAProxy-Konfiguration für Hybrid-Routing:

Frontend http_front

    bind *:80

    default_backend dedicated_pool

Backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    server cloud_burst1 10.0.1.20:80 check weight 1 backup

    server cloud_burst2 10.0.1.21:80 check weight 1 backup

frontend http_front

    bind *:80

    default_backend dedicated_pool

backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    server cloud_burst1 10.0.1.20:80 check weight 1 backup

    server cloud_burst2 10.0.1.21:80 check weight 1 backup

Die Backup-Anweisung hält die Cloud-Server im Leerlauf, bis der primäre dedizierte Server nicht mehr erreichbar oder überlastet ist. In der Dokumentation von HAProxy wird die queuenbasierte Überlaufkonfiguration behandelt, bei der Anfragen kurzzeitig in einer Warteschlange stehen, bevor sie an die Spitzenkapazität weitergeleitet werden, anstatt fehlzuschlagen.

Cloud-Burst-Instanzen funktionieren am besten, wenn deine Anwendung auf der Rechenebene zustandslos ist – der Sitzungsstatus wird in Redis auf dem dedizierten Server gespeichert, sodass jede Cloud-Instanz jede Anfrage bearbeiten kann. Zustandsbehaftete Anwendungen erfordern eine Konfiguration der Sitzungsaffinität, was das Burst-Routing erheblich erschwert.

Konfiguration des Auto-Scaling-Triggers auf AWS:

# Erstelle einen CloudWatch-Alarm, der eine Skalierung auslöst, wenn die dedizierte CPU ausgelastet ist

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

# Create a CloudWatch alarm to trigger scaling when dedicated is saturated

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

Notfallwiederherstellung mit Cloud-Warm-Standby

Ein dedizierter Server ohne Notfallplan ist ein Single Point of Failure. Cloud Warm Standby bietet Wiederherstellungskapazitäten, ohne dass ein zweiter dedizierter Server zu vollen Kosten unterhalten werden muss.

Das DR-Modell basiert auf drei Prinzipien:

Die Datenreplikation läuft kontinuierlich. Durch die MySQL-Binlog-Replikation auf eine in der Cloud gehostete Replik bleibt die DR-Datenbank nur wenige Sekunden hinter der Primärdatenbank zurück. Konfiguriere die Replikation in der Datei „my.cnf“ auf dem Primärserver:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

Auf der Cloud-Replik:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

Der Anwendungscode wird im Cloud-Objektspeicher gespeichert. Dank einer mit S3 synchronisierten Kopie deines Anwendungsverzeichnisses kann die Cloud-DR-Instanz während des Failovers die aktuelle Codebasis abrufen, ohne dass der Primärserver erreichbar sein muss.

Das DNS-Failover ist bereits vorkonfiguriert. Die Zustandsprüfungen Cloudflarekönnen den DNS-Verkehr innerhalb von 30 Sekunden nach Feststellung eines Ausfalls der primären Verbindung automatisch von der IP-Adresse deines dedizierten Servers auf die IP-Adresse deiner Cloud-Instanz umleiten. Konfiguriere dies im Voraus, bevor du es brauchst – nicht erst während eines Ausfalls.

Der DR-Warm-Standby läuft bis zum Failover mit minimalen Cloud-Kosten (eine angehaltene Instanz oder eine kleine laufende Instanz für die Replikation) und skaliert dann, um den Produktionsdatenverkehr zu bewältigen.

Netzwerkarchitektur: Die beiden Umgebungen verbinden

Eine hybride Infrastruktur erfordert eine private Verbindung zwischen dedizierten und Cloud-Umgebungen. Eine Verbindung über das öffentliche Internet funktioniert zwar, bringt aber Latenzzeiten und Sicherheitsrisiken mit sich. Zwei Optionen:

VPN-Tunnel: Ein WireGuard- oder OpenVPN-Tunnel zwischen dem dedizierten Server und der Cloud-VPC sorgt für eine private Verbindung zu vernachlässigbaren Kosten. Die Konfiguration von WireGuard ist deutlich einfacher als die von OpenVPN und bietet bei hohem Durchsatz eine bessere Leistung.

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

AWS Direct Connect / Azure ExpressRoute: Bei Hybridarchitekturen mit hohem Durchsatz sorgt eine dedizierte Netzwerkverbindung zwischen dem Rechenzentrum InMotion Hostingund dem Cloud-Anbieter dafür, dass das öffentliche Internet komplett umgangen wird. Das verursacht zwar zusätzliche Kosten (Direct Connect kostet ab 0,02 $/GB für die Datenübertragung), beseitigt aber Schwankungen bei der Latenz und bietet garantierte, konstante Durchsatzraten.

Für die meisten Hybrid-Bereitstellungen reicht WireGuard über das öffentliche Internet mit ausreichender Bandbreite aus. Direct Connect kommt ins Spiel, wenn das Volumen der Datenbankreplikation oder der Datenverkehr zwischen den Diensten regelmäßig 1 Gbit/s übersteigt.

Kostenmodell: Wo Hybrid punktet

Wirtschaftlich gesehen ist ein Hybrid-Server die bessere Wahl, wenn deine Basisauslastung für einen dedizierten Server ausreicht und deine Spitzenauslastung nur sporadisch auftritt. Bedenke Folgendes:

• Dedizierter Server (Essential-TarifInMotion Hostingfür 99,99 $/Monat): bewältigt kontinuierlich 90 % des Datenverkehrs
• Kapazität für Spitzenauslastungen (2x EC2 t3.xlarge, On-Demand zu ca. 0,17 $/Stunde pro Instanz): 40 Stunden/Monat aktiv bei Traffic-Spitzen
• Cloud-DR-Warm-Standby (angehaltene EC2-Instanz): 0 $/Monat, bis ein Failover erforderlich ist; S3-Replikationsspeicher ~5–20 $/Monat
• WireGuard VPN: keine zusätzlichen Kosten

Gesamtkosten pro Monat: ca. 130–140 $/Monat im Vergleich zu einer vollständigen Cloud-Lösung mit gleicher Kapazität, die bei vergleichbarer Basisleistung und Burst-Fähigkeit wahrscheinlich 400–600 $/Monat kosten würde.

Die Einsparungen schwinden, wenn deine Traffic-Spitzen häufig auftreten und lange anhalten. Ab einem bestimmten Punkt ist ein größerer dedizierter Server günstiger als die häufige Nutzung von Cloud-Burst-Kapazitäten.

Der dedizierte Server InMotion Hostingals Hybrid-Kern

Das Dedicated-Server-AngebotInMotion Hosting ist genau auf diese Architektur zugeschnitten: hohe Leistung, Flatrate-Preise, eine skalierbare Bandbreite von 10 Gbit/s zur Bewältigung von Spitzenauslastungen ohne Gebühren pro GB für ausgehenden Datenverkehr sowie Managed Services im Rahmen des „Premier Care“-Pakets, damit die Kerninfrastruktur keine technische Betreuung erfordert.

Die 192 GB DDR5-RAM des Extreme-Servers bieten genügend Speicherreserven, sodass viele Anwendungen ihren gesamten Arbeitsdatensatz direkt im Arbeitsspeicher des dedizierten Servers verarbeiten können. Nur bei echtem Überlauf wird auf die Cloud zurückgegriffen – nicht bei routinemäßigen Datenbankabfragen, die einen kleineren Server an seine Grenzen bringen würden.