> 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/knowledge-base/de/tenants/tenant-node-planning-guide.md). # Planungsleitfaden für Mandantenknoten ## Überblick Dieser Leitfaden beschreibt die wichtigsten Überlegungen zur Bestimmung einer optimalen Anzahl von Mandantenknoten, zur Zuweisung von Rechenressourcen und zu Platzierungsstrategien für VergeOS-Mandantenbereitstellungen. Ein effektives Design von Mandantenknoten unterstützt optimale Leistung und Ressourcennutzung und bewahrt gleichzeitig die Isolations- und Sicherheitsvorteile von Mandantenumgebungen. ## Voraussetzungen Bevor Sie diesen Leitfaden verwenden, sollten Sie ein grundlegendes Verständnis der Mandantenkonzepte haben; siehe [Mandantenübersicht](/run-the-platform/tenants/overview.md) wenn Sie neu bei VergeOS-Mandanten sind. ## Zweck und Umfang Dieser Leitfaden hilft Administratoren, fundierte Entscheidungen zu treffen über: * Eine geeignete Anzahl von Mandantenknoten basierend auf den Anforderungen des Mandanten * Strategien zur Ressourcenzuweisung über Mandantenknoten hinweg * Überlegungen zur physischen Platzierung von Mandantenknoten *** ## Was sind Mandantenknoten? **Mandantenknoten simulieren physische Hosts** Mandantenknoten sind virtuelle Server, die physische VergeOS-Knoten simulieren und die gleiche Funktionalität eng nachbilden, um eine private Mandantenumgebung zu schaffen. Jeder Mandant besteht aus einem oder mehreren Mandantenknoten, die gemeinsam Compute-, Speicher- und Netzwerkinfrastruktur für die Workloads des Mandanten bereitstellen und dabei mithilfe des gekapselten Mandantennetzwerks Trennung und Privatsphäre wahren. ## Eigenschaften von Mandantenknoten **Sichere Kommunikation zwischen Hosts** * Der Mandant kann sicher über mehrere physische Hosts skaliert werden * Das geschützte gekapselte Netzwerk des Mandanten ermöglicht seinen Knoten eine sichere Kommunikation miteinander **Mobilität** * Für Portabilität über physische Infrastruktur hinweg ausgelegt * Migration zwischen physischen Hosts für Wartung oder Lastenausgleich * Automatisches Failover auf andere physische Knoten bei Hardwareausfällen * Live-Migrationsfunktionen ohne Unterbrechung des Dienstes **Abgestimmte Ressourcenzuweisung** * Mandantenknoten können über Cluster oder Hosts mit unterschiedlichen Hardwarekonfigurationen (einschließlich spezialisierter Hardware wie vGPUs) bereitgestellt werden, um den unterschiedlichen Workload-Anforderungen innerhalb des Mandanten zu entsprechen. **Horizontale und vertikale Skalierung** * Die Ressourcen eines Mandantenknotens können ohne Neustart erhöht oder verringert werden * Mandantenknoten können hinzugefügt werden, um Rechenressourcen über mehrere physische Hosts hinweg zu skalieren * Die bestehende Mandantenarchitektur wird nahtlos um neue Mandantenknoten erweitert *** ## Ein-Knoten-Mandanten {% hint style="info" %} **Wichtige Punkte** * Ein-Knoten-Mandanten bieten Redundanz durch automatisches Failover * Ein einzelner Mandantenknoten wird bevorzugt, wenn er die Ressourcenanforderungen erfüllen kann * Zusätzliche Mandantenknoten können bei Bedarf ohne Unterbrechung hinzugefügt werden, um die Ressourcen eines Mandanten zu skalieren {% endhint %} Ein Mandant kann auf einem einzelnen Mandantenknoten ausgeführt werden und dennoch Redundanz bieten, da das System einen "Watchdog"-Mechanismus verwendet, der einen Mandantenknoten auf einem neuen physischen Host automatisch neu startet, wenn sein physischer Server ausfallen sollte oder der virtuelle Mandantenknoten für einen bestimmten Zeitraum nicht reagiert. Für Wartungsarbeiten wird automatisch ein temporärer Mandantenknoten erstellt, um die Workloads des Mandanten nahtlos live zu migrieren. Wenn RAM- und Kernanforderungen mit einem einzelnen Mandantenknoten erfüllt werden und keine Netzwerk- oder Geräteanforderungen bestehen, die Mandantenknoten auf mehreren Hosts erfordern, ist aus Gründen der Einfachheit oft ein einzelner Knoten vorzuziehen. ## Skalierungsflexibilität VergeOS-Mandanten ermöglichen eine störungsfreie Ressourcenskalierung; Sie können Ihrem Mandanten Ressourcen hinzufügen, ohne laufende Workloads zu beeinträchtigen. Mandantenknoten sollten in der Regel auf Grundlage des aktuellen oder kurzfristigen Workload-Bedarfs geplant und bereitgestellt werden, wobei die Ressourcen bei Bedarf erhöht werden. Dieser Ansatz vermeidet die Verschwendung zugewiesener, ungenutzter Ressourcen. **Nicht störende Skalierungsoptionen:** * Ressourcen zu vorhandenen Mandantenknoten hinzufügen * Zusätzliche Mandantenknoten hinzufügen, um die Last zu verteilen * Mandantenknoten auf andere physische Hosts migrieren * Speicher unabhängig von Rechenressourcen skalieren Detaillierte Anleitungen zum Erhöhen von Mandantenressourcen finden Sie in der [Mandantenressourcen erhöhen](/run-the-platform/tenants/add-tenant-resources.md) Dokumentation. ## Mehrknoten-Mandanten Für größere Mandantenbereitstellungen oder solche mit unterschiedlichen Hardwarespezifikationen kann mehr als ein Mandantenknoten erforderlich sein. Die folgenden Abschnitte erläutern Bedingungen, die mehrere Knoten erforderlich machen. **1. Rechenressourcenbedarf, der die maximalen Workload-Werte übersteigt** Mehrere Mandantenknoten werden benötigt, wenn ein Mandant mehr Rechenressourcen benötigt, als der Cluster innerhalb einer einzelnen Maschine zulässt. Die Menge an Speicher und die Anzahl der Kerne, die einem einzelnen Mandantenknoten zugewiesen werden können, ist durch die Clustereinstellungen begrenzt: [***Maximaler RAM pro Maschine***\_ und \_***Max. Kerne pro Maschine***](/run-the-platform/system-administration/cluster-settings.md). **2. Anforderungen an Mandanten-Workloads** Einige Anwendungsanforderungen machen mehrere Mandantenknoten erforderlich, um Workloads auf physische Server zu verteilen: * **Geclusterte Anwendungen**: Mandanten, die geclusterte Anwendungen verwenden (z. B. Web-Farmen, Hadoop, Datenbank-Cluster), haben häufig die Anforderung, mehrere Instanzen auf unterschiedlichen physischen Hosts für Hochverfügbarkeit, Lastenausgleich oder parallele Verarbeitung auszuführen. * **Gemischte Hardwarefunktionen**: Um einem Mandanten unterschiedliche Leistungsprofile oder spezialisierte Passthrough-Hardware (vGPU-, PCI-, USB-Geräte) bereitzustellen, kann es erforderlich sein, mehrere Mandantenknoten auf unterschiedlichen physischen VergeOS-Knoten oder Clustern bereitzustellen. * **Regulatorische Anforderungen**: Einige Mandanten können Compliance-Anforderungen für eine Hardware-Trennung zwischen Workloads haben. ## Ermittlung der Ressourcenanforderungen eines Mandanten **CPU-Anforderungen** * Ermitteln Sie die gesamte Anzahl an CPU-Kernen, die für alle geplanten Workloads benötigt werden * Berücksichtigen Sie Spitzenlastmuster und Leistungsanforderungen * Berücksichtigen Sie unterschiedliche Workload-Typen (CPU-intensiv vs. I/O-gebunden), bei denen es sinnvoll sein könnte, sie auf unterschiedlichen Knoten oder Clustern mit spezialisierten Hardwarefunktionen bereitzustellen. **Speicheranforderungen** * Berechnen Sie den gesamten RAM-Bedarf für alle geplanten virtuellen Maschinen * Berücksichtigen Sie den Speicherbedarf für geplante Mandanteninfrastrukturdienste wie NAS, KI usw. * Das System behandelt den Speicher-Overhead durch integrierte Prozesse. **Keine manuelle Berechnung des Overheads erforderlich** Das VergeOS-System berücksichtigt Hypervisor- und Speicher-Overhead automatisch bei der Zuweisung von Ressourcen an Mandantenknoten. Der zugewiesene Speicher steht dem Mandanten vollständig zur Verfügung, um ihn auf seine eigenen Workloads zu verteilen. **Right-Sizing-Strategie** Es wird allgemein empfohlen, die Rechenressourcen von Mandanten passend zu den tatsächlichen Workload-Anforderungen zu dimensionieren, anstatt überschüssige Kapazität für zukünftiges Wachstum zuzuweisen. Dieser Ansatz optimiert die Ressourcennutzung und ermöglicht ein organisches Skalieren, wenn sich die Anforderungen weiterentwickeln. ## Beispielkonfigurationen Die folgenden Beispiele veranschaulichen unterschiedliche Mandantenknoten-Konfigurationen, um wichtige Planungsaspekte und Anforderungen zu demonstrieren. ### Beispiel 1 - Kleiner Ein-Knoten-Mandant **Szenario:** * Ein Mandant mit nur 3 VMs, ohne besondere Anforderungen * Die Host-Cluster-Einstellungen erlauben *Maximaler RAM pro Maschine*: 64 GB RAM und *Max. Kerne pro Maschine*: 16 * Die Host-Umgebung umfasst mehrere physische Knoten, die jeweils dieselben Passthrough-Geräte enthalten, die für Mandanten-Workloads verfügbar sind **Anforderungen:** * Insgesamt 16 GB RAM und 8 Kerne für die aktuellen Mandanten-Workloads * Einige Mandanten-Workloads erfordern vGPU-Geräte **Konfiguration:** * Mandantenknoten: 1 * Ressourcen: 16 GB RAM, 8 Kerne **Begründung:** Ein einzelner Knoten bietet genügend Ressourcen für den Workload und sorgt gleichzeitig für Einfachheit. Das automatische Failover von Mandantenknoten gewährleistet Redundanz ohne zusätzliche Komplexität. **Skalierungspfad:**\ Fügen Sie dem Mandantenknoten mehr RAM/Kerne hinzu, wenn der Ressourcenbedarf wächst (weitere 48 GB RAM und 8 Kerne können diesem ursprünglichen Knoten hinzugefügt werden), oder fügen Sie einen zweiten Mandantenknoten hinzu, wenn der Ressourcenbedarf 64 GB/16 Kerne übersteigt. ### Beispiel 2 - Mittelgroßer Mandant mit hochverfügbaren Webanwendungen **Szenario:** * Ein mittelgroßer Mandant, der kundenorientierte Webanwendungen mit einem Multi-Instanz-, Load-Balanced-/Hochverfügbarkeits-Setup betreibt * Die Host-Cluster-Einstellungen erlauben *Maximaler RAM pro Maschine*: 128 GB RAM und *Max. Kerne pro Maschine*: 16 **Anforderungen:** * 4 Webserver (2 pro Host für HA) * 2 Datenbankserver (Primär/Replikat auf getrennten Hosts) **Konfiguration:** * Mandantenknoten: 2 * Knoten 1: 64 GB RAM, 12 Kerne (Host für 2 Webserver + primäre Datenbank) * Knoten 2: 64 GB RAM, 12 Kerne (Host für 2 Webserver + Datenbankreplikat) * Mandanten-VMs verwenden HA-Gruppeneinstellungen, um eine Anti-Affinität der Knoten beizubehalten und so die Verteilung der Workloads auf separate Hosts zu unterstützen {% hint style="success" %} [**Dieser KB-Artikel**](/knowledge-base/de/automation-api/determine-node-where-vm-runs.md) **enthält Informationen zur Verwendung von HA-Gruppen für die Knoten-Anti-Affinität** {% endhint %} **Begründung:** Obwohl die Host-Cluster-Einstellungen genügend Ressourcen innerhalb eines einzelnen Mandantenknotens zulassen, stellen mehrere Knoten sicher, dass die Webserver und Datenbankkomponenten des Mandanten auf verschiedenen physischen Hosts ausgeführt werden, um die HA-Anforderungen der Mandantenanwendung zu erfüllen. **Skalierungspfad:** Fügen Sie den vorhandenen Knoten mehr RAM/Kerne hinzu, wenn der Rechenbedarf wächst, oder fügen Sie zusätzliche Mandantenknoten hinzu, wenn die Anforderungen beginnen, 256 GB/32 Kerne zu überschreiten oder eine weitere physische Trennung der Workloads erforderlich wird. ### Beispiel 3 - Mandant mit gemischten Workloads und spezialisierter Hardware **Szenario:** * Der Mandantenkunde benötigt Standard-Rechenressourcen, Hochleistung für Videorendering und GPU-Beschleunigung für Videoverarbeitungs-Workloads * Die Host-Umgebung verfügt über mehrere Cluster mit unterschiedlichen Hardwarekonfigurationen und Leistungsprofilen * Anwendbare Host-Cluster: * Standard (Prozessoren der mittleren Leistungsklasse, Standard-Verhältnis von Prozessoren zu Kernen); *Maximaler RAM pro Maschine*: 64 GB RAM und *Max. Kerne pro Maschine*: 16 * vGPU-Cluster (High-End-Prozessoren, vGPU-Geräte); *Maximaler RAM pro Maschine*: 64 GB RAM und *Max. Kerne pro Maschine*: 16 * Hochleistungs-Cluster (High-End-Prozessoren, speicherintensiv) *Maximaler RAM pro Maschine*: 128 RAM und *Max. Kerne pro Maschine*: 16 **Anforderungen:** * 128 GB/16 Kerne für Standard-VMs (Dateiserver und Verwaltungstools) * 64 GB/16 Kerne für GPU-beschleunigte VMs für das Videorendering * 48 GB/12 Kerne für einen Hochleistungs-Host für Bearbeitungs-Workstations **Konfiguration:** * Mandantenknoten: 4 * Knoten 1: 64 GB RAM, 8 Kerne (Standard-Cluster für Dateiserver) * Knoten 2: 64 GB RAM, 8 Kerne (Standard-Cluster für Dateiserver/Verwaltungstools) * Knoten 3: 64 GB RAM, 16 Kerne (vGPU-Cluster für Videobearbeitungs-/Rendering-Workstations) * Knoten 4: 48 GB RAM, 8 Kerne (Premium-Cluster für Bearbeitungs-Workstations) **Begründung:** Mehrere Knoten ermöglichen die Platzierung auf verschiedenen Clustern mit unterschiedlichen Hardwarefunktionen: Standard, mit GPU-Ausstattung und Hochleistung. Im Standard-Cluster werden zwei Knoten benötigt, um die erforderlichen 128 GB RAM für Dateiserver und Verwaltungstools bereitzustellen. **Hardware-Zuordnung:** Jeder Mandantenknoten wird auf physischer Infrastruktur platziert, die seinen Workload-Anforderungen entspricht (Einstellung für Mandantenknoten *Cluster* ), wodurch sowohl Leistung als auch Kosten optimiert werden. **Skalierungspfad:** Für jeden Knoten/Cluster: Fügen Sie dem vorhandenen Knoten mehr RAM/Kerne hinzu, wenn die maximalen Clustereinstellungen dies zulassen, oder fügen Sie zusätzliche Mandantenknoten hinzu. ### Beispiel 4 - Mandant mit Anforderungen an eine geclusterte Anwendung **Szenario:** * Unternehmensmandantenkunde, der eine verteilte Analyseplattform betreibt, die für Funktionen des Anwendungs-Load-Balancings und der Redundanz eine Bereitstellung über mehrere Hosts erfordert. * Die Host-Cluster-Einstellungen erlauben *Maximaler RAM pro Maschine*: 96 GB RAM und *Max. Kerne pro Maschine*: 16 **Anforderungen:** * Unterstützung für 3 Anwendungsserver über 3 physische Hosts hinweg (je 48 GB RAM/8 Kerne) * Unterstützung für 3 Datenbankserver (je 16 GB RAM/4 Kerne) * Unterstützung für 2 Datenverarbeitungsserver (je 16 GB RAM/8 Kerne) **Konfiguration:** * Mandantenknoten: 4 * Knoten 1: 64 GB RAM, 12 Kerne (1 Anwendungsserver + 1 Datenbankserver) * Knoten 2: 64 GB RAM, 12 Kerne (1 Anwendungsserver + 1 Datenbankserver) * Knoten 3: 64 GB RAM, 12 Kerne (1 Anwendungsserver + 1 Datenbankserver) * Knoten 4: 32 GB RAM, 8 Kerne (2 Datenverarbeitungsserver) * Mandanten-VMs verwenden HA-Gruppeneinstellungen, um eine Anti-Affinität der Knoten beizubehalten und so die Verteilung der Workloads auf separate Hosts zu unterstützen {% hint style="success" %} [**Dieser KB-Artikel**](/knowledge-base/de/automation-api/determine-node-where-vm-runs.md) **enthält Informationen zur Verwendung von HA-Gruppen für die Knoten-Anti-Affinität** {% endhint %} **Begründung:** Vier Mandantenknoten stellen sicher, dass Anwendungsinstanzen über mehrere physische Hosts hinweg ausgeführt werden, während gleichzeitig die Fähigkeit erhalten bleibt, alle Dienste auszuführen. **Skalierungspfad:** Fügen Sie den vorhandenen Mandantenknoten mehr RAM/Kerne hinzu, sofern es die maximalen Clustereinstellungen zulassen; konfigurieren Sie zusätzliche Knoten, wenn der Ressourcenbedarf mit den ursprünglichen vier nicht gedeckt werden kann. --- # 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/knowledge-base/de/tenants/tenant-node-planning-guide.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.