Synology VMM Pro: Optimale Dimensionierung einer Produktions-VM mit KI (2026)

Die virtuelle Maschine, die diesen Shop betreibt, lief monatelang mit der doppelten Hardwarekapazität. Acht virtuelle CPUs, sechzehn Gigabyte Arbeitsspeicher und eine reale Arbeitslast, die nie mehr als ein Viertel davon beanspruchte. Das ist nicht ungewöhnlich. Man dimensioniert eine virtuelle Maschine am ersten Tag großzügig, weil man nicht weiß, was sie später benötigt. Die Website funktioniert, und niemand kommt wieder. Dieser Artikel ist die Dokumentation unserer Entscheidung, die virtuelle Maschine zu ändern. Wir haben die virtuelle Maschine mithilfe von Synology auf vier virtuelle CPUs und acht Gigabyte Arbeitsspeicher reduziert. VMM Pro, Mit einem KI-Assistenten, der die Shell steuerte, war der Shop zwei Minuten und sieben Sekunden lang nicht erreichbar. Die Größenänderung selbst ist der langweilige Teil – es handelt sich lediglich um zwei Felder in einem Dialog. Interessant sind die Messungen, die bewiesen, dass acht Gigabyte ausreichen, die Reihenfolge der Operationen, die verhindert, dass dem Gastsystem beim ersten Start der Speicher ausgeht, und der Snapshot, der all dies rückgängig macht. VMM Pro macht all das kostengünstig, und das ist das überzeugendste Argument dafür.

SynoPower Club-Punkt:Die richtige Dimensionierung ist die unglamouröseste Aufgabe beim Selfhosting, aber die lohnendste. Niemand schreibt einen Blogbeitrag über die acht Gigabyte, die er zurückgewonnen hat. Doch der ungenutzte Speicher in einem überdimensionierten Gastsystem spart nichts – auf einem Synology ist er fest reserviert und kann von keiner anderen Komponente des Systems genutzt werden. Wir haben acht Gigabyte auf einem Hostsystem zurückgewonnen, das langsam an seine Grenzen stieß, wodurch wir zwei weitere Gastsysteme betreiben können, für die wir keine zusätzliche Hardware kaufen müssen. Was die Sache sicherer und nicht beängstigend machte, war das darunterliegende VMM Pro: ein gesicherter Snapshot vor dem ersten Befehl und eine Maschine, die ich im Notfall innerhalb von 90 Sekunden in den ursprünglichen Zustand zurückversetzen konnte. Es ging nichts schief. Aber ohne diese Sicherheit hätte ich gar nicht erst angefangen.

Was ist Synology VMM Pro?

Virtual Machine Manager ist das Hypervisor-Paket für Synology. Es lässt sich über das Paketzentrum installieren, ist kostenlos und kann auf einem einzelnen NAS problemlos Linux-, Windows- und Virtual DSM-Gastsysteme mit lokalen Snapshots ausführen. VMM Pro ist das kostenpflichtige Upgrade, das diesen Einzelplatz-Hypervisor in einen kleinen Cluster verwandelt: mehrere NAS-Einheiten, die als ein Pool verwaltet werden, Gäste, die zwischen ihnen wechseln können, hohe Verfügbarkeit und Snapshot-Replikation von einem Host zum anderen.

Diese Unterscheidung ist für diesen Artikel wichtig, da die richtige Dimensionierung eine Kapazitätsentscheidung ist und die Kapazität erst dann relevant wird, wenn mehr als ein Gerät im Cluster vorhanden ist. Auf einem einzelnen NAS ist der freigegebene Speicher ungenutzter Speicher auf diesem NAS. In einem VMM Pro-Cluster hingegen handelt es sich um Speicher, den ein anderer Host im Falle eines Failovers nutzen oder in den ein neuer Gast ohne zusätzliche Kosten integriert werden kann.

A Virtueller DSM Der Gast – eine vollständige DSM-Installation, die als virtuelle Maschine läuft – ist die Workload, die wir hier skaliert haben. Er führt den Container Manager aus, der wiederum die beiden Docker-Container im Hintergrund dieses Stores steuert. Diese Schichtung ist bewusst gewählt und gewährleistet die Sicherheit des Vorgangs. Wir haben das Verschieben eines Docker-Stacks zwischen Gastsystemen bereits in [Link einfügen] behandelt. Unsere VDSM-Docker-Migrationsanleitung; In diesem Artikel geht es darum, dem Gast darunter die richtige Größe zu geben.

VMM Pro im Vergleich zur Gratis-Edition: Was das Upgrade tatsächlich bietet

Die kostenlose Version ist keine eingeschränkte Demoversion. Sie kann produktive Gastsysteme ausführen, Snapshots erstellen und bietet den meisten Anwendern für ein einzelnes NAS tatsächlich alles, was sie benötigen. Was Sie mit dieser Version erwerben VMM Pro Es handelt sich nicht um Funktionen eines Gastes, sondern um Funktionen, die über alle Hosts hinweg gelten.

Fähigkeit	Gratis-Ausgabe	VMM Pro
Gäste auf einem NAS ausführen	Ja	Ja
Lokale Snapshots	Ja	Ja
Mehrere NAS-Einheiten als ein Cluster	NEIN	Ja
Einen Gast zwischen Gastgebern verschieben	NEIN	Ja
Hochverfügbarkeits-Failover	NEIN	Ja
Snapshots auf einen anderen Host replizieren	NEIN	Ja

Prüfen Sie vor dem Kauf die offizielle Produktseite (Link in den Referenzen), da Synology die Aufteilung der Editionen zwischen den DSM-Versionen ändert. Der praktische Test ist einfacher als die Tabelle: Wenn Sie nur ein NAS besitzen und die Wiederherstellung aus einem Snapshot manuell durchführen können, reicht die kostenlose Edition aus. Sobald Sie jedoch ein zweites NAS besitzen und die Server des ersten NAS auch nach dessen Ausfall weiterverwenden möchten, benötigen Sie eine andere Edition. VMM Pro-Lizenz.

Unser Cluster besteht aus drei Knoten, von denen die meiste Zeit nur zwei eingeschaltet sind. Der dritte Knoten dient als Kaltstart-Knoten, der planmäßig aktiviert wird, um replizierte Snapshots zu empfangen, und anschließend wieder in den Ruhemodus wechselt. Dieses Vorgehen – Stromkosten fallen nur an, wenn die Redundanz benötigt wird – entspricht dem VMM Pro-Prinzip und ist der Grund dafür, dass die Konsole permanent eine Warnung über einen nicht erreichbaren Host anzeigt. Die Warnung ist ein Zeichen dafür, dass das Design funktioniert und kein Fehler.

Wie ein Gast in der Produktion am Ende doppelt so groß ist wie nötig

Drei Dinge treiben die Gäste dazu, ihr Limit zu erhöhen, und nichts hält sie davon ab. Erstens: Die anfängliche Größe ist eine Schätzung, und eine großzügige Schätzung kostet am ersten Tag nichts. Zweitens: Jeder Vorfall endet damit, dass jemand das Limit erhöht. Bei uns gab es innerhalb einer Woche zwei Speicherprobleme; beide wurden durch mehr Platz behoben, und keines musste jemals wieder angesprochen werden. Drittens: Ein Dashboard, das eine Speicherauslastung von 80 Prozent anzeigt, wirkt alarmierend, sodass niemand freiwillig Speicher freigibt. Nichts davon ist ein Problem von VMM Pro. Es ist ein menschliches Problem, und deshalb sind überdimensionierte Gäste die Norm.

Das ist die letzte Falle, und man muss es ganz klar sagen: Die Zahl, die die meisten Leute heranziehen, um zu entscheiden, ob ein Container noch Platz hat, ist die falsche. Unser System zeigte an, dass der Datenbankcontainer zu 81 Prozent ausgelastet war. Das stimmte nicht. Abschnitt fünf erklärt genau, warum das so ist und welche Messung die Größenänderung des VMM Pro-Containers zu einer sicheren, statt einer hoffnungsvollen Entscheidung machte.

Die richtige Größe für einen Live-Gast mit VMM Pro in 4 Schritten

Der gesamte Vorgang umfasst vier Schritte, wobei nur der dritte die Website offline nimmt. Die Gesamtausfallzeit betrug für uns zwei Minuten und sieben Sekunden, gemessen vom Stoppen der Container bis zum ersten HTTP-200-Statuscode nach der Rückkehr des Gastsystems. VMM Pro ist an den Schritten eins und drei beteiligt; der mittlere Schritt findet im Inneren des Gastes statt.

Warum Docker-Statistiken Sie von der richtigen Antwort abbringen werden

Vor der Größenänderung sah das Container-Dashboard aus wie eine Maschine, die keinen Platz zum Nachgeben hatte:

docker stats WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- sieht fast voll aus

Liest man das, schließt man daraus, dass die Datenbank ihre vier Gigabyte benötigt und der Gast nicht unter zwölf gehen kann. Beide Schlussfolgerungen sind falsch, denn die von diesen Tools gemeldete Speichernutzung beinhaltet den Seitencache, und der Seitencache wird automatisch freigegeben, sobald ein anderer Prozess Speicher benötigt. Der Wert, der darüber entscheidet, ob ein Abbruch aufgrund von Speichermangel erfolgt, ist der anonyme Speicher. Lesen Sie ihn direkt ab:

docker exec sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB Cache 1609 MB WordPress-DB rss 2553 MB Cache 1543 MB

Nun kehrt sich das Bild um. Der Anwendungscontainer belegt tatsächlich nur 1,3 GB, nicht 2,5 GB. Von diesen 1,3 GB entfallen 768 MB auf einen einzigen gemeinsam genutzten Opcode-Cache, den jeder Worker-Prozess abbildet, anstatt ihn zu kopieren. Somit benötigten zwanzig Worker-Prozesse jeweils etwa 27 Megabyte, nicht die 250 Megabyte, die eine einfache Berechnung des Prozessspeichers vermuten ließe. Die 2,5 GB der Datenbank bestanden fast vollständig aus einem 3 Gigabyte großen Pufferpool für eine 663 MB große Datenbank.

Eine weitere Falle derselben Art: Der historische Spitzenzähler zeigt bereitwillig einen Container an, der seine maximale Auslastung erreicht hat, da dieser Zähler auch den Seitencache berücksichtigt. Bei beiden unserer Container war dies der Fall. Keiner der Container war jemals aufgrund von Speichermangel beendet worden. Überprüfen Sie den Zähler für Speichermangel, nicht die maximale Auslastung.

Mit diesen beiden Fakten erwies sich die Größe von acht Gigabyte nicht mehr als riskant. Die Reduzierung des Pufferpools auf ein Gigabyte – immer noch deutlich größer als die gesamte Datenbank – gab mehr Arbeitsspeicher frei, als für die Größenänderung nötig war. Der schließlich in VMM Pro eingegebene Wert hatte sich bereits vor dem Herunterfahren des Gastsystems bewährt.

Wie ein kleines Team mit VMM Pro einen ganzen Server zurückgewinnt

Der Speicher eines Synology-Gastsystems ist fest reserviert. Der Hypervisor sperrt und reserviert ihn vorab, wodurch eine Überbelegung, wie sie auf manchen anderen Plattformen möglich ist, nicht möglich ist. 16 Gigabyte, die einem Gastsystem zugewiesen sind, stehen keinem anderen Gastsystem zur Verfügung, unabhängig davon, ob das Gastsystem ausgelastet ist oder nicht. Diese Einschränkung macht eine optimale Speicherdimensionierung auf diesem System sinnvoll. VMM Pro Konkret bedeutet das: Speicherplatz freizugeben ist die einzige Möglichkeit, zusätzliche Kapazität zu schaffen, ohne ein NAS zu kaufen.

Auf einem Host mit insgesamt 46,83 GB wurden acht Gigabyte Speicherplatz wiederhergestellt. Der verfügbare Speicher stieg von etwa 22 Gigabyte auf 30,29 GB. Praktisch bedeutet das, dass wir zwei zusätzliche Gastsysteme in der von uns tatsächlich verwendeten Größe ausführen können – allein durch die Messung. In einem Cluster mit drei Knoten bedeutet dies außerdem, dass die verbleibenden Hosts mehr Spielraum haben, um die Gastsysteme eines ausgefallenen Knotens zu übernehmen. Genau das ist ja der Sinn der Investition in VMM Pro.

Die CPU-Seite bestätigte dies noch deutlicher. Das Gastsystem verfügte über acht virtuelle CPUs und nutzte im Leerlauf etwa ein Sechstel eines Kerns. Vier virtuelle CPUs waren kein Kompromiss; vier sind immer noch großzügig bemessen, und VMM Pro setzte diese Größe in einem einzelnen Feld ein. Seit der Größenänderung liegt die durchschnittliche Systemlast des Gastsystems bei 1,36 für vier virtuelle CPUs, was etwa einem Drittel der Auslastung zur Tagesspitze entspricht.

Die Reihenfolge der Operationen, die eine Speichermangelschleife beim Systemstart verhindert

Hier liegt die Fehlerquelle, die schnell zu Problemen führen und teuer werden kann. Die in VMM Pro festgelegten Speichergrenzen für Container und Gastsystem stellen zwei separate Obergrenzen dar. Überschreitet die Summe der Containergrenzen den Speicher des Gastsystems, dürfen die Container mehr Speicher nutzen, als dem System zur Verfügung steht. Unter Last behebt der Kernel diese Diskrepanz, indem er Prozesse beendet.

Vor der Umstellung lagen unsere Limits bei sieben Gigabyte für den Anwendungscontainer und vier für die Datenbank – elf Gigabyte auf einem 16-Gigabyte-Gastsystem, was in Ordnung war. Auf einem 8-Gigabyte-Gastsystem hätte es beim ersten Lastanstieg zu einem Zwischenfall kommen können. Daher mussten die Container zuerst heruntergefahren werden.

Einstellung	Vor	Nach
Gast	8 vCPUs / 16 GB	4 vCPUs / 8 GB
Anwendungscontainer-Limit	7168 MB	4096 MB
Datenbankcontainer-Limit	4096 MB	2048 MB
Datenbank-Pufferpool	3 GB	1 GB
Maximale Datenbankverbindungen	300	100
Apache-Arbeiter-Obergrenze	50	35

In dieser Tabelle verbirgt sich eine Regel zweiter Ordnung. Man kann das Speicherlimit eines Containers nicht unter den aktuell genutzten Wert senken und erwarten, dass der Kernel dies problemlos akzeptiert. Der Anwendungscontainer nutzte weniger Speicher als sein neues Limit, daher wurde die Speicherbegrenzung live ohne Neustart und Ausfallzeit angewendet. Der Datenbankcontainer nutzte mehr Speicher, weshalb sein Pufferpool neu konfiguriert und der Container neu gestartet werden musste; erst dann konnte das niedrigere Limit angewendet werden. Keiner dieser Schritte entfällt in VMM Pro – beide müssen abgeschlossen sein, bevor der Dialog zum Ändern der Speichergröße geöffnet wird.

Die Begrenzung der Workeranzahl ist der einzige wirkliche Kostenfaktor des gesamten Projekts und sollte daher offengelegt werden. Durch die Reduzierung des Anwendungscontainers von sieben auf vier Gigabyte können weniger Anfragen gleichzeitig bearbeitet werden: von fünfzig auf fünfunddreißig, was einer Reduzierung der Spitzenlast um dreißig Prozent entspricht. Im Normalbetrieb laufen elf Worker auf der Website, daher hat sich nichts geändert. Während einer Werbeoffensive könnte sich dies jedoch ändern. Diesen Kompromiss haben wir bewusst eingegangen und ihn dokumentiert, damit er nicht erst bei einem Ausfall entdeckt wird.

Was der KI-Assistent tatsächlich tat und wo er falsch lag

Der Assistent erledigte die Aufgaben, die Geduld belohnen: Er erstellte den VMM Pro-Snapshot, bevor er irgendetwas änderte, las die Cgroup-Statistiken, anstatt sich auf das Dashboard zu verlassen, ermittelte die Reihenfolgebeschränkung für die Containerlimits und verifizierte das Ergebnis, indem er echte Seiten abrief und überprüfte, ob die Preise noch in der richtigen Währung angezeigt wurden. Das sind vielleicht vierzig Minuten sorgfältiger Arbeit, komprimiert auf wenige Minuten – und das ist wirklich nützlich.

Es lag außerdem dreimal in einer Sitzung falsch, was den nützlicheren Teil der Geschichte ausmacht.

• Das System empfahl zehn Gigabyte, obwohl der Benutzer acht angefordert hatte. Der Benutzer hatte Recht – allerdings nur, weil der überdimensionierte Pufferspeicher gleichzeitig angepasst wurde. Der Assistent hatte die Messwerte vor Augen und entschied sich dennoch für die sicherere Größe.
• Es benannte den Gast um, lesen Sie Erfolg: wahr Die API meldete die Umbenennung als abgeschlossen. Tatsächlich war die Umbenennung aber nicht erfolgt. Das verwendete Umbenennungsfeld diente der Identifizierung des Gastes, nicht der Namensänderung, und die API meldet in beiden Fällen Erfolg.
• Das System erkannte eine Warnung des VMM Pro-Clusters über einen nicht erreichbaren Host und kennzeichnete diesen als eingeschränkten Failover-Pfad. Der Host war ein absichtlich ausgeschalteter Kaltstandby-Host. Die Warnung war bereits seit Monaten systematisch aktiv.

Das Muster ist in allen drei Fällen dasselbe: ein sicheres Ergebnis nach einer plausiblen Prüfung. Die wirklich wichtigen Schutzmaßnahmen sind daher unspektakulär. Erstellen Sie immer zuerst einen Snapshot, und zwar vor dem ersten Befehl, nicht vor dem riskanten. Akzeptieren Sie niemals einen Rückgabewert als Beweis – lesen Sie den Zustand erneut und prüfen Sie das Feld, das Sie ändern wollten. Und überprüfen Sie das Verhalten, nicht die Einstellungen: Eine geladene Seite und ein korrekter Preis sind aussagekräftiger als jede Bestätigung, dass ein Befehl mit dem Wert Null beendet wurde.

Nichts davon ist spezifisch für KI. Es ist dieselbe Disziplin, die man sich von einem neuen Kollegen mit Root-Zugriff wünscht, der schnell, unermüdlich und gelegentlich von etwas überzeugt ist, das nicht stimmt.

Wo finde ich weitere offizielle Ressourcen?

Bevor Sie mit VMM Pro irgendetwas skalieren, sollten Sie sich unbedingt drei Videos ansehen. Das erste bietet den besten Überblick über das Paket selbst; die beiden anderen behandeln das Erstellen und Lizenzieren von Gästen, wo die meisten beim ersten Versuch scheitern.

Grenzen, die Sie kennen sollten, bevor Sie VMM Pro in der Produktion anvertrauen

Der Arbeitsspeicher kann nicht überbelegt werden. Jedes zugewiesene Gigabyte ist für alle anderen Daten auf dem NAS gesperrt, unabhängig davon, ob diese belegt sind oder nicht. Diese Einschränkung macht die richtige Dimensionierung so wichtig und ist auch der Grund, warum eine großzügige Schätzung zu Beginn hier teurer ist als auf Plattformen, die eine Überbelegung erlauben.

Um den Arbeitsspeicher zu reduzieren, ist ein Neustart erforderlich, da VMM Pro einem laufenden Gastsystem keinen Arbeitsspeicher entzieht. Die Vergrößerung einer virtuellen Festplatte und die Erweiterung einiger Ressourcen erfolgen im laufenden Betrieb, die Reduzierung des Arbeitsspeichers hingegen erfordert das Herunterfahren des Gastsystems. Planen Sie eine kurze Ausfallzeit ein; zwei Minuten sind machbar, aber nicht null.

Virtuelle Festplatten wachsen und schrumpfen nie. Wenn Sie Speicherplatz anstatt Arbeitsspeicher überbelegt haben, VMM Pro Ich werde es nicht zurückgeben. Der einzige Ausweg ist, einen neuen Gast zu erstellen und in diesen zu migrieren, was einen wesentlich längeren Nachmittag in Anspruch nehmen wird als dieser.

CPU-Limits innerhalb von Containern funktionieren möglicherweise gar nicht. Auf diesem Gastsystem verfügt der Kernel über keine CFS-Bandbreitenkontrolle, daher werden CPU-Quoten für Container direkt abgelehnt – und schlimmer noch: Der Versuch, eine CPU-Quote im selben Befehl wie eine Speicherbegrenzung festzulegen, führt zu einem unbemerkten Fehlschlag des gesamten Befehls. Speicherbegrenzungen und die Worker-Limitierung der Anwendung selbst sind die einzigen verfügbaren CPU-Schutzmaßnahmen.

Ein Snapshot ist kein Backup. Er befindet sich auf demselben Host und im selben Speicherpool wie das zu schützende System. VMM Pro kann Snapshots auf einen näher gelegenen Host replizieren, doch letztendlich übersteht nur das externe Backup der Daten einen Gebäudebrand.

Achten Sie abschließend auf die Konsolenausgabe. Container-Detailseiten zeigen Umgebungsvariablen im Klartext an, einschließlich Datenbankpasswörter. Das ist ein Zeichen von Ehrlichkeit seitens Docker und kein Fehler im Paket. Allerdings bedeutet es, dass ein einziger Screenshot der falschen Seite Zugangsdaten preisgibt. Wenn Sie das stört – und das sollte es –, speichern Sie die Zugangsdaten in einer Datei, die der Container liest, anstatt sie als Variablen zu übergeben.

Verweise

• SynoPower Club, Unsere Synology NAS-Ratgeber und Kameratests
• Synology — Virtual Machine Manager, der offizielle Feature- und Editionsvergleich
• Synology Wissenszentrum — Virtual Machine Manager Hilfe, Gasteinstellungen und Cluster-Konfiguration
• Docker – Docker-Container-Update, Änderung des Speicherlimits eines laufenden Containers
• Apache — MaxRequestWorkers, die in Abschnitt sieben besprochene Arbeitnehmerobergrenze

Häufig gestellte Fragen