Managed oder Unmanaged Cloud Server: Was Sie bekommen und wann sich Managed lohnt

Zu jedem Cloud Server gehört eine Entscheidung, die man beim Bestellen leicht übergeht: Wer kümmert sich um die Maschine, sobald sie läuft? Bei einem Unmanaged Server sind das Sie. Bei einem Managed Server übernimmt jemand anderes einen Teil dieser Aufgabe.

Pauschal besser ist keine der beiden Varianten. Unmanaged bietet Ihnen volle Kontrolle und eignet sich für alle, die bereits Linux-Server betreiben. Managed eignet sich für Server, die für das Unternehmen wichtig sind, für die sich im Team aber niemand zuständig fühlt. Dieser Leitfaden erklärt, was die beiden Optionen bei WebGee tatsächlich abdecken, was Sie selbst in der Cloud Console erledigen können und wie Sie entscheiden, welche zu Ihnen passt.

Was „unmanaged“ wirklich bedeutet

WebGee Cloud Server sind standardmäßig unmanaged, und das gilt für alle VPS und dedizierten Server. Die Aufgabenverteilung ist einfach:

• WebGee stellt die Plattform bereit: Netzwerkverfügbarkeit und Konnektivität, die physische und virtualisierte Infrastruktur sowie die Cloud Console, mit der Sie Server neu aufsetzen, Backups erstellen, auf die Konsole zugreifen und das Netzwerk verwalten.
• Alles innerhalb des Servers liegt bei Ihnen: das Betriebssystem, seine Updates, die Sicherheitshärtung, die installierte Software und deren Konfiguration.

Der Support für einen Unmanaged Server umfasst die VPS-Plattform und Netzwerkprobleme außerhalb Ihres Servers. Die Administration dessen, was darauf läuft, gehört nicht dazu. Außerdem greift WebGee nur auf einen Unmanaged Server zu, wenn Sie ausdrücklich darum bitten. Soll sich das Support-Team etwas ansehen, können Sie vorübergehend einen WebGee Support-SSH-Schlüssel installieren und ihn nach Abschluss des Tickets wieder entfernen. So müssen Sie nie ein Root-Passwort weitergeben. Die Schritte finden Sie unter WebGee Support Zugriff auf Ihren Server gewähren.

Warum die Kontrolle echt ist: KVM

WebGee Cloud Server laufen auf KVM, einem Hypervisor für vollständige Hardwarevirtualisierung. In der Praxis bedeutet das:

• Ihr eigener Kernel. Sie können Module laden, Kernel-Parameter setzen und einen eigenen Kernel booten.
• Ihre eigene Firewall. iptables und nftables funktionieren ganz normal.
• Echte Isolation. Arbeitsspeicher und Speicherplatz sind Ihrem Server fest zugewiesen, sodass ein ausgelasteter Nachbar nichts davon abzweigt.
• Alles läuft. Docker, Swap, VPN-Software, eigene Dateisysteme und alternative Kernel funktionieren problemlos.

Die Kehrseite: Kernel-Updates spielen Sie selbst ein, und sie werden erst nach einem Neustart wirksam. Das ist der Kern des Unmanaged-Kompromisses: volle Kontrolle, volle Verantwortung.

Was das Managed-Add-on umfasst

Mit dem Management kommt die Administration des Servers selbst hinzu, nicht nur der darunterliegenden Plattform. Laut der Dokumentation zum Servermanagement umfasst es:

• Technischen Support an 365 Tagen rund um die Uhr für den Server, nicht nur für die Plattform.
• Betriebssystem-Updates, die für Sie eingespielt werden.
• Sicherheitshärtung.
• Optionales proaktives Monitoring von Diensten.
• Bis zu 3 Stunden technische Unterstützung oder Beratung pro Monat.

Das Kontingent von drei Stunden deckt die übliche Administration und Beratung ab. Größere Aufgaben wie eine Migration oder ein umfangreicher Aufbau werden separat angeboten. Managementleistungen gibt es nur für Linux Cloud Server. Die aktuellen Preise für das Managed-Add-on finden Sie auf der Bestellseite.

Es lohnt sich, klar zu sehen, was Managed nicht ändert. Einige Aufgaben bleiben in jedem Fall bei Ihnen, und genau sie verursachen die meisten Probleme, wenn sie vergessen werden:

Für wen sich welche Option eignet

Unmanaged passt gut, wenn

• Sie oder jemand in Ihrem Team sicher in der Linux-Administration ist und den Server tatsächlich aktuell hält.
• Sie einen bestimmten Stack, einen eigenen Kernel, Container oder ein selbst gepflegtes Control Panel nutzen möchten.
• Sie entwickeln und testen und es zu Ihrem Alltag gehört, den Server komplett neu aufzusetzen.

Managed passt gut, wenn

• auf dem Server etwas läuft, von dem das Unternehmen abhängt, etwa eine Kundenwebsite, ein Shop oder eine interne Anwendung.
• sich auf Ihrer Seite niemand im Alltag um den Server kümmert oder die Person, die ihn eingerichtet hat, nicht mehr da ist.
• Sie möchten, dass jemand anderes Betriebssystem-Updates und Härtung übernimmt und Ihnen jeden Monat einige Stunden Expertenhilfe zur Verfügung stehen.

Ein hilfreicher Test: Fragen Sie sich, wer das nächste Sicherheitsupdate einspielt und wann. Gibt es dafür einen Namen und eine feste Routine, funktioniert Unmanaged. Lautet die Antwort „wahrscheinlich ich, irgendwann“, ist Managed die sicherere Wahl.

Wenn Sie mehr als Servermanagement brauchen

Servermanagement kümmert sich um die Maschine. Manche Teams brauchen Unterstützung bei allem, was drumherum anfällt: CI/CD-Pipelines, Terraform, Kubernetes und Rufbereitschaft bei Störungen. Genau das deckt DevOps as a Service ab, mit Paketen von der Einrichtung von Pipelines und Monitoring bis hin zu einem dedizierten DevOps- und SRE-Team. Das ist eine Dienstleistung in anderer Größenordnung, gedacht für Teams, die Software ausliefern, statt für eine einzelne Website.

Schnellstart: So schnell ist ein Server bereitgestellt

Egal, für welche Option Sie sich entscheiden: Die Inbetriebnahme eines Servers läuft gleich ab und dauert nur wenige Minuten. Die Website verspricht eine Bereitstellung in nur 20 Sekunden, und laut Dokumentation ist die Installation in der Regel in unter 20 Sekunden abgeschlossen.

1. Gehen Sie im WebGee Kundenbereich zu Services, wählen Sie Ihren Cloud Server aus und klicken Sie auf Open Cloud Console.
2. Legen Sie den Servernamen, einen vollqualifizierten Hostnamen wie server1.example.com und die Zeitzone fest.
3. Wählen Sie eine Betriebssystemvorlage.
4. Hinterlegen Sie optional einen SSH-Schlüssel, wählen Sie dann Install und bestätigen Sie.

Sobald der Server eingerichtet ist, verbinden Sie sich mit ssh root@your-server-ip. Haben Sie einen Schlüssel hinterlegt, gelangen Sie direkt hinein. Andernfalls erhalten Sie das Root-Passwort per E-Mail und sollten es bei der ersten Anmeldung ändern.

Dieser Artikel bleibt bei der Übersicht. Die vollständige Schritt-für-Schritt-Anleitung, einschließlich erster Anmeldung, Schlüsseln, Backups und DNS, finden Sie in Ihre erste Stunde mit einem WebGee Cloud Server.

Was Sie in der Cloud Console selbst steuern

Unmanaged heißt nicht, dass Sie allein vor einem leeren Terminal sitzen. Die Cloud Console bietet Ihnen die Werkzeuge, um den Server aufzubauen, wiederherzustellen und zu schützen, ohne ein Ticket zu eröffnen. Hier sehen Sie, wofür die einzelnen Bereiche da sind.

Betriebssystemvorlagen und Neuaufsetzen

Sie können den Server jederzeit anhand einer Vorlage neu aufsetzen: AlmaLinux, Rocky Linux und CentOS, Debian und Ubuntu, Fedora, Alpine Linux und FreeBSD sowie Images mit vorinstalliertem Hosting Control Panel. Beim Neuaufsetzen wird die primäre Festplatte gelöscht, erstellen Sie also vorher ein Backup. Auch Firewall-Regeln bleiben dabei nicht erhalten, richten Sie sie anschließend also erneut ein. Details finden Sie unter Server neu aufsetzen.

Wenn Sie lieber ein kostenloses Panel nutzen, das Sie selbst pflegen, finden Sie in der Dokumentation Installationsanleitungen für aaPanel, CyberPanel und CentOS Web Panel. Alle drei sind Unmanaged-Installationen: Das Panel, seine Updates und seine Sicherheit liegen bei Ihnen.

Rescue-Modus und VNC

Wenn SSH nicht mehr reagiert, finden Sie unter Options vier Werkzeuge. VNC zeigt Ihnen Bildschirm und Tastatur des Servers in einem Browserfenster, selbst wenn Netzwerk oder SSH nicht funktionieren. Rescue bootet eine kleine Wiederherstellungsumgebung, in der Sie Ihre Festplatte einbinden können, etwa bei einer fehlerhaften fstab oder einem missglückten Kernel-Update. Mit Password setzen Sie das Root-Passwort zurück, und unter Settings finden Sie Optionen auf Serverebene wie den Bootloader.

Boot-Medien

Für ein Betriebssystem, das nicht als Vorlage angeboten wird, können Sie im Tab Media ein CD/DVD-Image einbinden, auch ein eigenes per URL, und die Bootreihenfolge zwischen HDD und CD/DVD festlegen. Den Installer bedienen Sie über VNC. Denken Sie daran, die Bootreihenfolge danach wieder auf HDD zu stellen, sonst startet der Server beim nächsten Neustart erneut den Installer. Siehe Boot-Medien und Bootreihenfolge.

Backups mit Slots und Zeitplan

Der Tab Backups kopiert die primäre Festplatte des Servers, entweder bei Bedarf über Create Backup Now oder nach einem täglichen oder wöchentlichen Zeitplan zu einer Uhrzeit Ihrer Wahl. Ihnen steht eine feste Anzahl an Backup-Slots zur Verfügung; sind alle belegt, wird das älteste Backup ersetzt. Zwei Dinge sollten Sie wissen: Zusätzlich eingebundener Speicher ist nicht enthalten, und ein Backup bei laufendem Server kann eine Datenbank mitten im Schreibvorgang erfassen. Fahren Sie den Server also vorher herunter, wenn Sie das Backup wirklich wiederherstellen wollen.

Diese Backups schützen Sie vor einer misslungenen Änderung oder einem fehlgeschlagenen Upgrade. Für alles, was Sie keinesfalls verlieren dürfen, sollten Sie zusätzlich eine eigene Kopie an einem anderen Ort aufbewahren. Die vollständige Referenz finden Sie unter Server sichern.

SSH-Schlüssel

Speichern Sie öffentliche Schlüssel unter SSH Keys und hinterlegen Sie sie beim Erstellen oder Neuaufsetzen eines Servers. Der Schlüssel wird während des Builds für root installiert, und es wird kein Passwort per E-Mail verschickt. Jeder gespeicherte Schlüssel lässt sich aktivieren oder deaktivieren, teilen, umbenennen oder löschen. Erzeugen Sie Ihren Schlüssel nach Möglichkeit auf Ihrem eigenen Rechner, damit der private Teil diesen nie verlässt:

ssh-keygen -t ed25519 -C "[email protected]"
cat ~/.ssh/id_ed25519.pub   # paste this public key into the Console

Netzwerk und Reverse DNS

Der Tab Network zeigt die Schnittstelle, die MAC-Adresse, die IPv4-Adressen mit Gateway und Netzmaske sowie die DNS-Resolver (standardmäßig 1.1.1.1 und 1.0.0.1 von Cloudflare). Die wichtigste Schaltfläche ist Reverse DNS. Stellen Sie hier den vollqualifizierten Hostnamen des Servers mit einem passenden A-Record ein, bevor der Server E-Mails versendet. Fehlendes Reverse DNS ist der häufigste Grund, warum E-Mails von einem neuen Server nicht ankommen. Siehe Netzwerk und Reverse DNS.

Zugriff teilen, ohne Ihr Konto zu teilen

Wenn ein Entwickler oder eine Agentur an einem einzelnen Server arbeiten muss, können Sie im Tab Sharing mit deren Cloud-Console-Sharing-Token Zugriff gewähren. Die Person sieht nur diesen Server, nicht Ihre Abrechnung oder andere Dienste, und Sie können den Zugriff jederzeit widerrufen. Geteilter Zugriff umfasst auch destruktive Funktionen wie Neuaufsetzen und Wiederherstellen, teilen Sie ihn also nur mit Personen, denen Sie diese anvertrauen. Das Widerrufen des Konsolenzugriffs entfernt keine SSH-Schlüssel oder Passwörter, die auf dem Server selbst eingerichtet wurden, ändern Sie diese also ebenfalls. Siehe Serverzugriff teilen.

Die Entscheidung treffen

Die Cloud Console deckt die Plattformseite gut ab: Aufbauen, Neuaufsetzen, Wiederherstellen, Sichern und Teilen. Was sie nicht kann, ist die Entscheidung zu treffen, Ihren Server zu patchen. Genau das ist der eigentliche Unterschied zwischen den beiden Optionen.

• Wenn Sie das Know-how und die Routine haben, bietet Ihnen ein Unmanaged KVM Server vollen Root-Zugriff, Ihren eigenen Kernel und eine leistungsfähige Konsole für alles Weitere.
• Wenn der Server wichtig ist und sich niemand dafür zuständig fühlt, buchen Sie Management hinzu und überlassen Sie Betriebssystem-Updates, Härtung und Routinefragen jemand anderem.
• Wenn Ihr Team Pipelines, Infrastructure as Code und Rufbereitschaft braucht, sehen Sie sich stattdessen DevOps as a Service an.

Sie können auch mit Unmanaged starten und später Unterstützung hinzubuchen. Die Aufgaben, die in jedem Fall bei Ihnen bleiben – Backups, Reverse DNS und SSH-Schlüssel –, sollten Sie gleich am ersten Tag einrichten.