Die Anforderungen an Ihren Server können sich ändern. Ein Projekt wächst, zusätzliche Anwendungen kommen hinzu, der Speicherbedarf steigt, oder eine großzügig dimensionierte Umgebung wird nach Abschluss einer Aktion schlicht nicht mehr in vollem Umfang benötigt.
Bisher bedeutete eine solche Anpassung: Up- oder Downgrade bestellen, Termin mit dem Support abstimmen und die technische Umstellung durchführen lassen.
Für Managed Server und Managed vServer wird dieser Prozess jetzt deutlich einfacher: Up- und Downgrades lassen sich ab sofort automatisiert und eigenständig planen. Sie wählen die gewünschte Ressourcenausstattung und legen fest, wann die Änderung durchgeführt werden soll. Der Rest passiert ganz von allein.
Damit erhalten Sie mehr Planungssicherheit und Flexibilität. Insbesondere dann, wenn Änderungen nicht sofort, sondern gezielt zu einem späteren Zeitpunkt erfolgen sollen.
Die neue Funktion ist darauf ausgelegt, dass Sie Ihre Ressourcenanpassungen selbst in Ihren Betriebsablauf integrieren können. Statt für jede Änderung einen Termin mit dem Support abzustimmen, können Sie den gewünschten Zeitpunkt eigenständig festlegen.
Eine Planung ist dabei bis zu 30 Tage im Voraus möglich. Das eignet sich beispielsweise für geplante Projekte, saisonale Lastspitzen, bevorstehende Kampagnen oder bereits absehbare Änderungen beim Speicher- und Ressourcenbedarf.
Ein typisches Szenario: Für einen zeitlich begrenzten Zeitraum benötigt eine Anwendung zusätzliche CPU-, RAM- oder Speicherressourcen. Statt die Infrastruktur kurzfristig manuell anpassen zu lassen, kann das Upgrade bereits im Vorfeld für den gewünschten Termin eingeplant werden. Nach Abschluss der Phase kann anschließend ein Downgrade folgen.
So lassen sich Änderungen an der Servergröße besser mit Release-, Projekt- und Wartungsplänen koordinieren.
Nicht jede Änderung passt in den normalen Arbeitsalltag. Gerade bei produktiven Websites und Anwendungen kann es sinnvoll sein, Wartungsarbeiten in ein möglichst lastarmes Zeitfenster zu legen.
Deshalb können Up- und Downgrades nun auch außerhalb unserer regulären Geschäftszeiten (Montag bis Freitag, 9 bis 18 Uhr) geplant werden. Für die Durchführung außerhalb der Geschäftszeiten fällt eine Pauschale von 100 Euro an. So stellen wir sicher, dass zu jeder Zeit einer unserer erfahrenen Systemadministratoren eingreifen kann, falls es zu unerwarteten Auffälligkeiten kommen sollte.
Damit lässt sich insbesondere bei produktiven Systemen ein Wartungsfenster wählen, das zum tatsächlichen Nutzungsverhalten der jeweiligen Anwendung passt. Bei einer stark frequentierten Website kann ein nächtlicher Termin beispielsweise sinnvoller sein als eine Änderung während des Tagesbetriebs.
Mit der Automatisierung ändert sich auch die bisherige Kostenstruktur für die technische Durchführung. Der berechnete Arbeitsaufwand für das Up- und Downgrade entfällt künftig. Die bislang standardmäßig angesetzten Support-Einheiten werden für die automatisierte Durchführung nicht mehr berechnet.
Das bedeutet: Die technische Anpassung der gebuchten Server-Ressourcen wird zu einem deutlich planbareren Bestandteil des normalen Betriebs. Lediglich bei einer Durchführung außerhalb der Geschäftszeiten fällt die genannte Pauschale von 100 Euro an.
Die Automatisierung reduziert damit nicht nur den Abstimmungsaufwand, sondern macht die Kosten einer geplanten Ressourcenänderung transparenter.
Die automatisierten Up- und Downgrades sind aktuell ausschließlich für Managed Server und Managed vServer vorgesehen.
Nicht unterstützt werden:
Der Grund liegt in den unterschiedlichen technischen Voraussetzungen der jeweiligen Plattformen. Die automatisierten Abläufe setzen bestimmte Möglichkeiten bei der Verwaltung und Größenanpassung des zugrunde liegenden Systems voraus. Die neue Funktion ist deshalb bewusst auf die Plattformen beschränkt, bei denen diese Abläufe zuverlässig und kontrolliert automatisiert werden können.
Ein Up- oder Downgrade ist mehr als eine reine Änderung eines Eintrags in der Tarifverwaltung. Je nach Art der Änderung müssen Ressourcen und gegebenenfalls Speicherstrukturen des Systems angepasst werden.
Besonders relevant ist dabei der Unterschied zwischen einem Upgrade und einem Downgrade auf ein Paket mit weniger Speicherplatz. Bei einem Upgrade steht nach der Änderung zusätzlicher Speicher zur Verfügung. Bei einem Downgrade muss dagegen sichergestellt werden, dass die vorhandenen Daten überhaupt in den kleineren verfügbaren Speicherbereich passen.
Bei einem Downgrade auf ein Paket mit weniger Speicherplatz musste die Infrastruktur bisher mit zwei getrennten Downtimes arbeiten. Insbesondere die erste Unterbrechung – das Verkleinern des Dateisystems – ließ sich zeitlich nur schwer zuverlässig vorhersagen.
Das neue Verfahren reduziert diesen Ablauf auf eine Downtime. Gleichzeitig lässt sich deren Dauer wesentlich besser anhand der tatsächlichen Belegung des Systems einschätzen.
Entscheidend ist dabei nicht nur, wie viele Gigabyte Daten gespeichert sind, sondern insbesondere, wie viele Dateien beziehungsweise Inodes auf dem System vorhanden sind.
Inodes sind vereinfacht gesagt die Dateisystemeinträge, die für Dateien und Verzeichnisse benötigt werden. Ein Server mit wenigen großen Dateien kann deshalb trotz hoher Speicherauslastung vergleichsweise wenig Aufwand verursachen. Umgekehrt kann ein System mit sehr vielen kleinen Dateien eine hohe Anzahl an Inodes aufweisen und dadurch mehr Zeit für die technische Anpassung benötigen.
Das führt zu einer wichtigen Verbesserung: Die Dauer der Downtime ist beim neuen Verfahren stärker an einen konkreten technischen Faktor gekoppelt und damit besser einschätzbar.
In der Regel sollte die Downtime bei einem Up- oder Downgrade zwischen etwa 10 und 30 Minuten liegen.
Das ist jedoch keine garantierte Maximaldauer. Die tatsächliche Dauer hängt von der individuellen Systemkonfiguration ab. Bei einem Downgrade auf weniger Speicherplatz ist insbesondere die Anzahl der vorhandenen Dateien relevant.
Die Formulierung „reduzierte Downtime“ bedeutet daher nicht, dass jeder einzelne Vorgang zwangsläufig kürzer dauert als früher. Es gibt Fälle, in denen die neue Downtime länger ausfallen kann. Der entscheidende Unterschied: Die Dauer der bisherigen ersten Downtime war teilweise nur schwer vorhersehbar und damit effektiv zufällig. Das neue Verfahren sorgt für einen technisch nachvollziehbareren Ablauf mit nur einer geplanten Unterbrechung.
Bei einem Downgrade auf ein Paket mit weniger Speicherplatz spielt neben dem belegten Speicher vor allem die Anzahl der vorhandenen Dateien (Inodes) eine Rolle. Je mehr Dateien auf dem System liegen, desto länger kann die notwendige Anpassung des Dateisystems dauern.
Als Orientierung gilt: Bei Inode-Zahlen im zweistelligen Millionenbereich sollten Sie mit einer längeren Downtime rechnen. In solchen Fällen empfehlen wir, den Termin möglichst nachts oder in ein anderes nutzungsarmes Wartungsfenster zu legen.
Die Anzahl der belegten Inodes können Sie auf einem SSH-Zugang ohne Jailkit beispielsweise mit folgendem Befehl prüfen:
df --output=iused /
Die Ausgabe zeigt die aktuell belegten Inodes des Root-Dateisystems. Nutzen Sie unsere Anleitung zur Einrichtung eines SSH-Benutzers ohne Jailkit.
Extrem hohe Inode-Zahlen sind im Normalfall eher ungewöhnlich. Falls Ihr Server eine auffällig große Anzahl an Dateien aufweist, lohnt sich deshalb ein genauerer Blick. Es gibt beispielsweise einige bekannte Konstellationen in Webanwendungen, bei denen sich unbemerkt sehr viele kleine oder auch leere Dateien ansammeln. Wenn Sie unsicher sind, können Sie sich gerne an unseren Support wenden – wir schauen uns die Situation gemeinsam mit Ihnen an.
Die reine Angabe des belegten Speicherplatzes ist für die Planung eines Downgrades nicht ausreichend: Zwei Server mit ähnlich viel belegtem Speicher können aufgrund einer unterschiedlichen Anzahl von Dateien deutlich unterschiedlich lange für die Umstellung benötigen.
Neben den Inodes gibt es einen weiteren Faktor, der sich unmittelbar auf die Dauer der Wartung auswirkt: die Anzahl der auf dem Server betriebenen Websites.
Vor der eigentlichen technischen Änderung muss für die Websites auf dem System ein Wartungsmodus aktiviert werden. Das ist eine bewusste Sicherheitsmaßnahme und dient dazu, während der Umstellung kontrollierte Zustände herzustellen.
Der Hintergrund ist pragmatisch: Ohne diese Absicherung besteht die Gefahr, dass während der laufenden Umstellung Änderungen an den Websites vorgenommen werden. Solche parallelen Änderungen können den automatisierten Ablauf stören oder sogar zu Fehlern führen.
Mit der neuen Automatisierung wurde nicht nur der eigentliche Up- und Downgrade-Prozess überarbeitet. Auch die Prüfung der virtuellen Maschine nach der Änderung wurde verbessert.
Nach der technischen Anpassung wird kontrolliert, ob das System wieder ordnungsgemäß funktioniert. Dabei ist insbesondere das Verhalten der auf dem Server betriebenen Dienste relevant.
Ein häufiger Stolperstein sind Anwendungen oder Websites, die einen Neustart des Servers nicht sauber verkraften. Ein Server muss im Rahmen des Vorgangs gegebenenfalls neu gestartet werden können. Anwendungen, die nach einem Reboot nicht automatisch oder nicht korrekt wieder starten, können Probleme verursachen.
Das betrifft beispielsweise Dienste, die zwar vor dem Neustart manuell gestartet wurden, deren automatischer Start beim Booten aber nicht korrekt konfiguriert ist.
Für die neue automatisierte Funktion bedeutet das: Websites und Anwendungen müssen reboot-fest sein.
Eine reboot-feste Anwendung ist so eingerichtet, dass sie nach einem Neustart des Servers selbstständig wieder in einen funktionsfähigen Zustand gelangt. Das klingt selbstverständlich und ist auch im Alltag (z.B. bei Wartungsarbeiten wie einem Hardwaretausch oder Updates) von Vorteil, um den Mehraufwand des manuellen Neustartens zu vermeiden.
In der Praxis ist das aber nicht bei jeder individuellen Installation garantiert. Gerade bei manuell installierten Anwendungen, eigenen Services oder speziellen Konfigurationen kann es vorkommen, dass ein Dienst zwar im laufenden Betrieb funktioniert, nach einem Neustart aber nicht automatisch gestartet wird.
Deshalb sollte vor einem geplanten Up- oder Downgrade geprüft werden, ob alle relevanten Dienste korrekt für den automatischen Start eingerichtet sind.
Die verbesserte Prüfung nach dem Vorgang hilft dabei, Probleme schneller zu erkennen. Sie ersetzt allerdings nicht die Verantwortung für individuell auf dem Server betriebene Anwendungen.
Die Automatisierung kümmert sich um die technische Anpassung der Server-Infrastruktur – sie kann keine fehlerhafte Anwendungskonfiguration reparieren.
Damit ein geplanter Up- oder Downgrade möglichst reibungslos abläuft, empfehlen wir einige einfache Vorbereitungen.
Mit den automatischen Up- und Downgrades erhalten Kunden von Managed Servern und Managed vServern mehr Eigenständigkeit bei der Verwaltung ihrer Server-Ressourcen.
Termine können bis zu 30 Tage im Voraus selbst geplant werden. Die bisher für den Arbeitsaufwand angesetzten Support-Kosten entfallen. Außerhalb der Geschäftszeiten ist die Durchführung gegen eine Pauschale von 100 Euro möglich.
Shopware 6.7.13.1 und 6.6.10.23 schließen zahlreiche Sicherheitslücken. Wir zeigen, welche Schwachstellen behoben wurden und warum Shopbetreiber jetzt handeln sollten. Erfahren Sie außerdem, welche technischen Änderungen beim Update zu beachten sind.
HTTP/3 lässt sich auf unseren Servern komfortabel über ISPConfig aktivieren. Unsere neue Anleitung zeigt Ihnen, welche Voraussetzungen erfüllt sein müssen, wie Sie HTTP/3 für einzelne Webseiten einschalten und die erfolgreiche Aktivierung anschließend überprüfen.
Testen Sie uns 14 Tage kostenlos Jetzt testen
