> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/de/modul-7-multi-tenancy/04-resource-allocation.md). # Ressourcenzuweisung & Skalierung ## Mandantenknoten: Virtuelle Hosts für virtuelle Rechenzentren Jeder VergeOS-Mandant läuft auf einem oder mehreren **Mandantenknoten** — virtuelle Server, die physische VergeOS-Hosts simulieren. Jeder Mandantenknoten stellt dem Mandanten dedizierte Rechenleistung (CPU-Kerne), Arbeitsspeicher (RAM) und Netzwerk bereit, während durch das gekapselte Netzwerk des Mandanten vollständige Isolation gewahrt bleibt. Zu verstehen, wie Mandantenknoten funktionieren, ist der Schlüssel zur richtigen Dimensionierung von Mandantenbereitstellungen und ihrer Skalierung im Laufe der Zeit. ### Eigenschaften von Mandantenknoten | Eigenschaft | Beschreibung | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Simulierte Hosts** | Mandantenknoten bilden die Funktionalität physischer VergeOS-Knoten innerhalb des Virtuellen Rechenzentrums des Mandanten nach | | **Sichere Kommunikation zwischen Hosts** | Mandantenknoten kommunizieren über das geschützte gekapselte Netzwerk des Mandanten, selbst wenn sie auf unterschiedlichen physischen Hosts laufen | | **Mobilität** | Mandantenknoten werden per Live-Migration zwischen physischen Hosts für Wartung, Lastenausgleich und automatisches Failover verschoben | | **Abgestimmte Ressourcenzuweisung** | Mandantenknoten können auf unterschiedliche Cluster mit verschiedenen Hardwareprofilen ausgerichtet werden (Standard, vGPU, speicherintensiv) | | **Unterbrechungsfreie Skalierung** | Kerne und RAM können auf einem laufenden Mandantenknoten erhöht oder verringert werden, ohne ihn neu zu starten | ### Grenzwerte für Mandantenknoten Standardwerte und Maximalwerte pro Mandantenknoten: | Ressource | Standard | Maximum | | --------- | -------- | ------------------- | | Kerne | 4 | 1,048,576 | | RAM | 16 GB | 5.242.880 MB (5 TB) | Cluster `Maximaler RAM pro Maschine` und `Maximale Kerne pro Maschine` Einstellungen können zusätzlich einschränken, was ein bestimmter Mandantenknoten tatsächlich verbrauchen kann. Auch das Netzwerk hat eine Obergrenze auf Mandantenebene: maximal **28 Host-Netzwerksegmente** können als Layer-2-Verbindungen in einen einzelnen Mandanten eingebunden werden (zulässige Typen: intern, extern, BGP, VPN und physisch gebrückt). ### Keine manuelle Berechnung des Overheads VergeOS berücksichtigt Hypervisor- und Speicher-Overhead automatisch. Der Speicher, den Sie einem Mandantenknoten zuweisen, steht dem **vollständig zur Verfügung** für die Verteilung auf seine eigenen Workloads — eine manuelle Berechnung des Overheads ist nicht erforderlich. ## Einzelknoten- vs. Mehrknoten-Mandanten Die erste Planungsentscheidung ist, ob ein Mandant einen Knoten oder mehrere benötigt. ### Einzelknoten-Mandanten (bevorzugter Standard) Ein einzelner Mandantenknoten ist die einfachste und am häufigsten verwendete Konfiguration. Er ist der empfohlene Ausgangspunkt, sofern die Anforderungen eines Mandanten an Rechenleistung und Speicher in einen einzelnen Knoten passen. Einzelknoten-Mandanten bieten dennoch Redundanz durch VergeOS' eingebauten **Watchdog-Mechanismus**: * Fällt der physische Host aus, auf dem der Mandantenknoten läuft, startet der Watchdog den Mandantenknoten automatisch auf einem anderen physischen Host neu * Bei geplanten Wartungsarbeiten wird ein temporärer Mandantenknoten erstellt, um Workloads per Live-Migration ohne Dienstunterbrechung zu verschieben * Zusätzliche Mandantenknoten können später, ohne Unterbrechung, hinzugefügt werden, wenn der Bedarf wächst {% hint style="success" %} **Einfach anfangen** Wenn die Anforderungen an RAM und Kerne mit einem einzelnen Mandantenknoten erfüllt werden können und keine Netzwerk- oder Geräteanforderungen mehrere physische Hosts erfordern, ist ein einzelner Knoten aus Gründen der Einfachheit vorzuziehen. {% endhint %} ### Wann Mehrknoten-Mandanten benötigt werden Mehrere Mandantenknoten werden in bestimmten Szenarien erforderlich: 1. **Der Bedarf an Rechenleistung übersteigt die Cluster-Maximalwerte** — Die Menge an Kernen und RAM, die einem einzelnen Mandantenknoten zugewiesen werden kann, ist durch die Clustereinstellungen begrenzt (*Maximaler RAM pro Maschine* und *Maximale Kerne pro Maschine*). Wenn ein Mandant mehr als die Kapazität eines Knotens benötigt, fügen Sie zusätzliche Knoten hinzu. 2. **Verteilte Anwendungen** — Webfarmen, Hadoop-Cluster, Datenbank-Primär-/Replikat-Paare und andere verteilte Anwendungen, die erfordern, dass Workloads für HA, Lastenausgleich oder parallele Verarbeitung auf verschiedenen physischen Hosts laufen. 3. **Gemischte Hardwarefähigkeiten** — Wenn ein Mandant sowohl Standard-Rechenleistung als auch spezialisierte Hardware (vGPU, PCI-Passthrough, USB-Geräte) benötigt, stellen Sie Mandantenknoten auf unterschiedlichen Clustern mit der passenden Hardware bereit. 4. **Regulatorische Trennung** — Compliance-Anforderungen können vorschreiben, dass bestimmte Workloads auf physisch getrennten Hosts ausgeführt werden. ## Strategie zur bedarfsgerechten Dimensionierung VergeOS-Mandanten unterstützen **unterbrechungsfreie Ressourcenskalierung** — Sie können einem laufenden Mandanten Kerne, RAM, Knoten und Speicher hinzufügen, ohne Workloads zu beeinträchtigen. Das bedeutet, dass Sie: * **Für den aktuellen und kurzfristigen Bedarf provisionieren**, nicht für spekulatives zukünftiges Wachstum * **Organisch skalieren** wenn die tatsächliche Nachfrage steigt * **Überprovisionierung vermeiden** — nicht genutzte Ressourcen, die einem Mandanten zugewiesen sind, können nicht für andere verwendet werden ```mermaid flowchart TD A["Arbeitslastanforderungen bewerten"] --> B{"Passen die Anforderungen\\nauf einen einzelnen Knoten?"} B -- Ja --> C["Einzelknoten-Mandant bereitstellen"] B -- Nein --> D{"Grund für Mehrknoten?"} D -- "Überschreitet Cluster-Maximum" --> E["Knoten zu demselben\\nCluster hinzufügen"] D -- "HA / Cluster-Anwendungen" --> F["Knoten mit\\nAnti-Affinität der HA-Gruppe hinzufügen"] D -- "Gemischte Hardware" --> G["Knoten auf\\nunterschiedlichen Clustern hinzufügen"] D -- "Regulatorisch" --> H["Knoten auf\\ngetrennten physischen Hosts hinzufügen"] C --> I["Überwachen & zunächst\\nvertikal skalieren"] E --> I F --> I G --> I H --> I I --> J{"Benötigt mehr\\nRessourcen?"} J -- "Passt in vorhandenen Knoten" --> K["Kerne/RAM auf\\nvorhandenem Knoten erhöhen"] J -- "Übersteigt Knotenkapazität" --> L["Einen weiteren\\nMandantenknoten hinzufügen"] K --> I L --> I style A fill:#e8f5e9,stroke:#2e7d32 style C fill:#e3f2fd,stroke:#1565c0 style I fill:#fff3e0,stroke:#e65100 ``` ## Beispielkonfigurationen Die folgenden Beispiele veranschaulichen reale Planungsentscheidungen für Mandantenknoten. ### Beispiel 1: Kleiner Einzelknoten-Mandant **Szenario:** 3 VMs, keine besonderen Anforderungen. Host-Cluster erlaubt max. 64 GB RAM, max. 16 Kerne. | Einstellung | Wert | | --------------- | -------------------------------------------------------------------------------- | | Mandantenknoten | 1 | | Kerne | 8 | | RAM | 16 GB | | Skalierungspfad | Kerne/RAM bis auf 64 GB / 16 Kerne erhöhen, dann einen zweiten Knoten hinzufügen | **Begründung:** Ein einzelner Knoten stellt ausreichende Ressourcen bereit. Das Watchdog-Failover sorgt für Redundanz ohne zusätzliche Komplexität. ### Beispiel 2: Mittlere HA-Webanwendungen **Szenario:** Kundenorientierte Web-Apps, die Multi-Instanz-HA erfordern. Host-Cluster erlaubt max. 128 GB RAM, max. 16 Kerne. | Einstellung | Wert | | --------------- | -------------------------------------------------------------------------------------------------- | | Mandantenknoten | 2 | | Knoten 1 | 64 GB RAM, 12 Kerne (2 Webserver + DB-Primärinstanz) | | Knoten 2 | 64 GB RAM, 12 Kerne (2 Webserver + DB-Replikat) | | HA-Gruppen | Anti-Affinitätsregeln sorgen dafür, dass Web-/DB-Instanzen auf getrennten physischen Hosts bleiben | **Begründung:** Obwohl ein Knoten alle Ressourcen aufnehmen könnte, stellen zwei Knoten sicher, dass Webserver und Datenbankkomponenten auf unterschiedlichen physischen Hosts laufen, um HA auf Anwendungsebene zu erreichen. ### Beispiel 3: Gemischte Workload mit GPU **Szenario:** Standard-Rechenleistung, leistungsstarkes Video-Rendering und GPU-beschleunigte Verarbeitung. Drei Host-Cluster verfügbar: Standard (max. 64 GB), vGPU (max. 64 GB), Premium (max. 128 GB). | Einstellung | Wert | | --------------- | ------------------------------------------------------------ | | Mandantenknoten | 4 | | Knoten 1 | 64 GB, 8 Kerne — Standard-Cluster (Dateiserver) | | Knoten 2 | 64 GB, 8 Kerne — Standard-Cluster (Verwaltungstools) | | Knoten 3 | 64 GB, 16 Kerne — vGPU-Cluster (Video-Rendering) | | Knoten 4 | 48 GB, 8 Kerne — Premium-Cluster (Bearbeitungsarbeitsplätze) | **Begründung:** Mehrere Knoten ermöglichen die Platzierung auf Clustern mit passenden Hardwarefähigkeiten. Jeder Mandantenknoten wird dem Cluster zugewiesen, der am besten zu seiner Workload passt. ### Beispiel 4: Verteilte Analyse im Unternehmensmaßstab **Szenario:** Verteilte Analyseplattform, die für Lastenausgleich und Redundanz eine Bereitstellung über mehrere Hosts erfordert. Host-Cluster erlaubt max. 96 GB RAM, max. 16 Kerne. | Einstellung | Wert | | --------------- | ------------------------------------------------------------------------------------------ | | Mandantenknoten | 4 | | Knoten 1–3 | Jeweils 64 GB, 12 Kerne (1 Anwendungsserver + 1 DB-Server pro Knoten) | | Knoten 4 | 32 GB, 8 Kerne (2 Server für die Datenverarbeitung) | | HA-Gruppen | Anti-Affinität stellt sicher, dass sich Anwendungsinstanzen über physische Hosts verteilen | **Begründung:** Vier Mandantenknoten gewährleisten, dass Anwendungsinstanzen auf mehreren physischen Hosts laufen, während gleichzeitig die Fähigkeit erhalten bleibt, alle Dienste innerhalb des Mandanten auszuführen. ## Erhöhen von Mandantenressourcen VergeOS bietet drei unterbrechungsfreie Methoden, um einem laufenden Mandanten Ressourcen hinzuzufügen. ### Kerne/RAM zu einem vorhandenen Knoten hinzufügen Änderungen werden **sofort** auf dem Mandantenknoten wirksam — kein Neustart erforderlich. 1. Navigieren Sie zum **Mandanten-Dashboard** → **Knoten** 2. Doppelklicken Sie auf den Zielknoten → klicken Sie auf **Bearbeiten** 3. Ändern Sie die **Kerne** und/oder **RAM** Felder 4. Klicken Sie auf **Übernehmen** {% hint style="info" %} **Cluster-Grenzwerte** Die maximalen Kerne und der RAM pro Mandantenknoten werden durch die *Maximaler RAM pro Maschine* und *Maximale Kerne pro Maschine* Einstellungen des Clusters bestimmt. Nutzen Sie vorhandene Knoten vollständig aus, bevor Sie neue hinzufügen, sofern die Workload-Verteilung nichts anderes erfordert. {% endhint %} {% hint style="info" %} **Validierung von Ressourcenänderungen** Wenn auf einem Mandantenknoten Kerne oder RAM geändert werden, führt VergeOS `validatecluster.gcs` gegen den Primärcluster aus (und `validateclusterfailover.gcs` gegen den Failover-Cluster, falls einer konfiguriert ist). Änderungen, die die pro Maschine zulässigen Grenzen eines der Cluster überschreiten würden — oder die der laufende Host nicht mit freiem RAM erfüllen kann — werden abgelehnt, um Überbelegung zu verhindern. {% endhint %} ### Einen neuen Mandantenknoten hinzufügen 1. Navigieren Sie zum **Mandanten-Dashboard** → **Knoten** → **Neu** 2. Konfigurieren Sie **Kerne**, **RAM**, **Cluster**, und **Failover-Cluster** 3. Wählen Sie **Bei Stromausfall** Verhalten (Letzter Zustand, Aus lassen oder Einschalten) 4. Klicken Sie auf **Übernehmen** {% hint style="warning" %} **Bevorzugter Knoten** Das Festlegen eines *bevorzugten Knotens* ist **nicht empfohlen** für Mandantenknoten. Eine falsche Konfiguration kann die eingebaute Redundanz beeinträchtigen. Wenden Sie sich bei Bedarf an den VergeOS-Support. {% endhint %} ### Zusätzlichen Speicher bereitstellen **Neuer Speicher-Tier:** 1. Mandanten-Dashboard → **Speicher hinzufügen** → wählen Sie **Tier** → geben Sie **bereitgestellte** Menge ein → **Übernehmen** **Vorhandenen Tier erweitern:** 1. Mandanten-Dashboard → zum **Speicher** Abschnitt scrollen → klicken Sie **Bearbeiten** auf den gewünschten Tier 2. Geben Sie die neue **Gesamt** bereitgestellte Menge ein (z. B. ändern Sie 50 GB auf 75 GB, um 25 GB hinzuzufügen) ## Reduzieren von Mandantenressourcen ### Kerne/RAM reduzieren Kerne und RAM können auf einem laufenden Mandantenknoten reduziert werden, ohne ihn auszuschalten. Wenn diese Ressourcen jedoch derzeit von Mandanten-VMs verwendet werden, wird die **tatsächliche Rückgewinnung verschoben** bis die VMs heruntergefahren werden. **Beispiel:** Sie reduzieren den RAM eines Mandantenknotens von 32 GB auf 28 GB, aber die VMs verwenden derzeit alle 32 GB. Die Einstellung ändert sich sofort, aber die Differenz von 4 GB wird erst zurückgewonnen, wenn die VMs diesen Speicher freigeben. ### Einen Mandantenknoten löschen 1. Schalten Sie alle VMs auf dem Knoten aus oder migrieren Sie sie 2. Schalten Sie den Mandantenknoten aus 3. Navigieren Sie zu **Mandanten-Dashboard** → **Knoten** → wählen Sie den Knoten → **Löschen** {% hint style="warning" %} **Mindestanforderung an Knoten** Ein Mandant muss immer mindestens einen Knoten haben. Bevor Sie einen Mandantenknoten löschen, stellen Sie sicher, dass mindestens ein anderer Knoten verbleibt und alle Workloads vom zu entfernenden Knoten migriert wurden. {% endhint %} ## Skalierungspfade: Zuerst vertikal, dann horizontal Die empfohlene Skalierungsstrategie für Mandanten folgt einer klaren Abfolge: ### Schritt 1: Vertikal skalieren Erhöhen Sie Kerne und RAM auf vorhandenen Mandantenknoten bis zum Cluster-Maximum. Dies ist der einfachste Weg ohne Unterbrechung. ### Schritt 2: Horizontal skalieren Wenn vorhandene Knoten ausgelastet sind, fügen Sie neue Mandantenknoten hinzu. Platzieren Sie sie für allgemeine Erweiterungen im selben Cluster oder für spezialisierte Hardware in unterschiedlichen Clustern. ### Schritt 3: Speicher hinzufügen Erweitern Sie den bereitgestellten Speicher unabhängig von der Rechenleistung. Fügen Sie Kapazität zu einem vorhandenen Tier hinzu oder stellen Sie einen neuen Speicher-Tier bereit. ### Schritt 4: Neu ausbalancieren Wenn die Ressourcenverteilung auf den Knoten ungleichmäßig wird, balancieren Sie RAM/Kerne zwischen den Knoten aus, statt einen maximal auszulasten und einen anderen nur minimal bereitzustellen. {% hint style="info" %} **Kommen Sie von VMware oder Nutanix?** Bei VMware und Nutanix bedeutet „einen Mandanten skalieren“ meist, ein Kontingent zu vergrößern und dem Scheduler zu vertrauen. In VergeOS dimensionieren Sie dedizierte Mandantenknoten direkt. {% endhint %} | Plattform | Isolationsmodell | Skalierungsaktion | | --------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | VergeOS | Jeder Mandant ist ein VDC mit dedizierten Mandantenknoten (gekapseltes Netzwerk + isolierte Speichervolumes) | Bearbeiten Sie die Kerne/RAM eines Mandantenknotens live oder fügen Sie einen Knoten hinzu — das System berücksichtigt den Overhead automatisch | ## Best Practices | Praxis | Empfehlung | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Mit einem Knoten beginnen** | Standardmäßig Einzelknoten-Mandanten verwenden; Knoten nur bei Bedarf hinzufügen | | **Für den aktuellen Bedarf richtig dimensionieren** | Für den aktuellen/kurzfristigen Bedarf provisionieren, nicht für spekulatives zukünftiges Wachstum | | **Vor dem Hinzufügen auslasten** | Vor dem Hinzufügen neuer Knoten die Ressourcen vorhandener Knoten erhöhen (sofern die Workload-Verteilung nichts anderes erfordert) | | **Ressourcen ausbalancieren** | Wenn zwei Knoten benötigt werden, die Ressourcen gleichmäßig verteilen, statt einen maximal und den anderen minimal zu dimensionieren | | **HA-Gruppen verwenden** | Bei Mehrknoten-Mandanten mit HA-Anforderungen Anti-Affinitätsregeln konfigurieren, damit VMs über physische Hosts verteilt werden | | **Cluster an Workloads anpassen** | Mandantenknoten auf Clustern mit Hardware platzieren, die zur Workload passt (GPU, speicherintensiv, Standard) | | **Überwachen und anpassen** | Mandanten-Dashboards und Nutzungsberichte verwenden, um zu erkennen, wann eine Skalierung erforderlich ist | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/learn-the-platform/de/modul-7-multi-tenancy/04-resource-allocation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.