In diesem Dokument werden Knoten für einzelne Mandanten beschrieben. Informationen zum Bereitstellen von VMs auf Knoten für einzelne Mandanten finden Sie unter VMs auf Knoten für einzelne Mandanten bereitstellen.
Die Einzelmandantenfähigkeit ermöglicht Ihnen exklusiven Zugriff auf einen Knoten für einzelne Mandanten, bei dem es sich um einen physischen Compute Engine-Server handelt, der ausschließlich für das Hosten der VMs Ihres Projekts vorgesehen ist. Verwenden Sie Knoten für einzelne Mandanten, um Ihre VMs physisch von VMs in anderen Projekten zu trennen oder auf derselben Hosthardware zu gruppieren, wie im folgenden Diagramm dargestellt. Sie können auch eine Knotengruppe für einzelne Mandanten erstellen und angeben, ob Sie sie für andere Projekte oder für die gesamte Organisation freigeben möchten.
VMs, die auf Knoten für einzelne Mandanten ausgeführt werden, können dieselben Compute Engine-Funktionen wie andere VMs nutzen, einschließlich transparenter Planung und Blockspeicher, allerdings mit einer zusätzlichen Ebene der Hardwareisolation. Damit Sie die vollständige Kontrolle über die VMs auf dem physischen Server haben, verwaltet jeder Knoten für einzelne Mandanten eine 1:1-Zuordnung zu dem physischen Server des Knotens.
Innerhalb eines Knotens für einzelne Mandanten können Sie mehrere VMs auf Maschinentypen unterschiedlicher Größe bereitstellen, sodass Sie die zugrunde liegenden Ressourcen der dedizierten Host-Hardware effizient nutzen können. Wenn Sie die Hosthardware nicht für andere Projekte freigeben, können Sie außerdem mit Arbeitslasten, die eine physische Isolierung von anderen Arbeitslasten oder VMs erfordern, die Sicherheits- oder Compliance-Anforderungen erfüllen. Wenn Ihre Arbeitslast nur vorübergehend Einzelmandantenfähigkeit erfordert, können Sie die VM-Mandanten nach Bedarf ändern.
Knoten für einzelne Mandanten können Ihnen helfen, dedizierte Hardwareanforderungen für das Konzept Eigene Lizenz verwenden (Bring your own License, BYOL) zu erfüllen, das Lizenzen pro Kern oder pro Prozessor erfordert. Wenn Sie Knoten für einzelne Mandanten verwenden, haben Sie einen Einblick in die zugrunde liegende Hardware, sodass Sie die Kern- und Prozessornutzung verfolgen können. Um diese Nutzung zu verfolgen, meldet Compute Engine die ID des physischen Servers, auf dem eine VM geplant ist. Anschließend können Sie mithilfe von Cloud Logging den Verlauf der Servernutzung einer VM aufrufen. Zur Optimierung der Nutzung der Hosthardware können SieOvercommit für VM-CPUs für einzelne Mandanten durchführen, Knotengruppen für einzelne Mandanten freigeben und VMs manuell live migrieren.
Über eine konfigurierbare Host-Wartungsrichtlinie können Sie das Verhalten von VMs für einzelne Mandanten steuern, während deren Host gewartet wird. Sie können angeben, wann die Wartung durchgeführt wird und ob die VMs die Affinität zu einem bestimmten physischen Server beibehalten oder zu anderen Knoten für einzelne Mandanten innerhalb einer Knotengruppe verschoben werden.
Überlegungen zu Arbeitslasten
Die folgenden Arten von Arbeitslasten können von der Verwendung von Knoten für einzelne Mandanten profitieren:
Gaming-Arbeitslasten mit Leistungsanforderungen.
Arbeitslasten im Finanz- oder Gesundheitswesen mit Sicherheits- und Complianceanforderungen.
Windows-Arbeitslasten mit Lizenzanforderungen.
ML-, Datenverarbeitungs- oder Image-Rendering-Arbeitslasten. Für diese Arbeitslasten sollten Sie GPUs reservieren.
Arbeitslasten, die erhöhte Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und eine geringere Latenz erfordern oder Arbeitslasten, die temporären Speicher in Form von Caches, Verarbeitungsspeichern oder Daten von geringem Wert verwenden. Für diese Arbeitslasten sollten Sie lokale SSDs reservieren.
Knotenvorlagen
Eine Knotenvorlage ist eine regionale Ressource, die die Attribute jedes Knotens in einer Knotengruppe definiert. Wenn Sie eine Knotengruppe aus einer Knotenvorlage erstellen, werden die Attribute der Knotenvorlage unveränderlich in jeden Knoten in der Knotengruppe kopiert.
Wenn Sie eine Knotenvorlage erstellen, müssen Sie einen Knotentyp angeben. Optional können Sie beim Erstellen einer Knotenvorlage Knotenaffinitätslabels angeben. Knotenaffinitätslabels können nur in einer Knotenvorlage angegeben werden. Sie können keine Knotenaffinitätslabels für eine Knotengruppe angeben.
Knotentypen
Geben Sie beim Konfigurieren einer Knotenvorlage einen Knotentyp an, der auf alle Knoten innerhalb einer Knotengruppe angewendet werden soll, die auf der Grundlage der Knotenvorlage erstellt wurde. Der Typ "Knoten für einzelnen Mandanten", auf den die Knotenvorlage verweist, gibt die Gesamtmenge der vCPU-Kerne und den Arbeitsspeicher für Knoten an, die in Knotengruppen erstellt wurden, die diese Vorlage verwenden. Der Knotentyp n2-node-80-640
hat beispielsweise 80 vCPUs und 640 GB Arbeitsspeicher.
Die VMs, die Sie einem Knoten für einzelne Mandanten hinzufügen, müssen denselben Maschinentyp haben wie der Knotentyp, den Sie in der Knotenvorlage angeben. n2
-Knoten für einzelne Mandanten sind beispielsweise nur mit VMs kompatibel, die mit dem Maschinentyp n2
erstellt wurden. Sie können einem Knoten für einzelne Mandanten VMs hinzufügen, bis die Gesamtzahl der vCPUs oder der Arbeitsspeicher die Kapazität des Knotens überschreitet.
Wenn Sie mit einer Knotenvorlage eine Knotengruppe erstellen, übernimmt jeder Knoten in der Knotengruppe die Knotentypspezifikationen der Knotenvorlage. Ein Knotentyp bezieht sich auf jeden einzelnen Knoten innerhalb einer Knotengruppe und nicht auf alle Knoten in der Gruppe als Einheit. Wenn Sie also eine Knotengruppe mit zwei Knoten vom Knotentyp n2-node-80-640
erstellen, werden jedem Knoten 80 vCPUs und 640 GB Arbeitsspeicher zugewiesen.
Abhängig von Ihren Arbeitslastanforderungen können Sie den Knoten auch mit mehreren kleineren VMs belegen, die auf Maschinentypen verschiedener Größen ausgeführt werden, einschließlich vordefinierte Maschinentypen, benutzerdefinierte Maschinentypen und Maschinentypen mit erweitertem Speicher. Wenn ein Knoten voll ist, können Sie auf diesem keine weiteren VMs planen.
In der folgenden Tabelle sind die verfügbaren Knotentypen aufgeführt. Führen Sie den Befehl gcloud compute sole-tenancy
node-types list
oder die REST-Anfrage nodeTypes.list
aus, um eine Liste der für Ihr Projekt verfügbaren Knotentypen aufzurufen.
Informationen zu Preisen für diese Knotentypen finden Sie unter Preise für Knoten für einzelne Mandanten.
Knotentyp | Prozessor | vCPU | GB | vCPU:GB | Sockets | Kerne:Socket | Kerne insgesamt |
---|---|---|---|---|---|---|---|
h3-node-88-352 |
Sapphire Rapids | 88 | 352 | 1:4 | 2 | 48 | 96 |
c3d-node-360-708 |
AMD EPYC Genoa | 360 | 708 | 1:2 | 2 | 96 | 192 |
c3d-node-360-1440 |
AMD EPYC Genoa | 360 | 1440 | 1:4 | 2 | 96 | 192 |
c3d-node-360-2880 |
AMD EPYC Genoa | 360 | 2880 | 1:8 | 2 | 96 | 192 |
c3-node-176-352 |
Sapphire Rapids | 176 | 352 | 1:2 | 2 | 48 | 96 |
c3-node-176-704 |
Sapphire-Rapids | 176 | 704 | 1:4 | 2 | 48 | 96 |
c3-node-176-1408 |
Sapphire-Rapids | 176 | 1408 | 1:8 | 2 | 48 | 96 |
c2-node-60-240 |
Cascade Lake | 60 | 240 | 1:4 | 2 | 18 | 36 |
g2-node-96-384 |
Cascade Lake | 96 | 384 | 1:4 | 2 | 28 | 56 |
g2-node-96-432 |
Cascade Lake | 96 | 432 | 1:4,5 | 2 | 28 | 56 |
m1-node-96-1433 |
Skylake | 96 | 1.433 | 1:14.9 | 2 | 28 | 56 |
m1-node-160-3844 |
Broadwell E7 | 160 | 3844 | 1:24 | 4 | 22 | 88 |
m2-node-416-11776 |
Cascade Lake | 416 | 11776 | 1:28.3 | 8 | 28 | 224 |
m3-node-128-1952 |
Ice Lake | 128 | 1952 | 1:15.25 | 2 | 36 | 72 |
m3-node-128-3904 |
Ice Lake | 128 | 3904 | 1:30.5 | 2 | 36 | 72 |
n1-node-96-624 |
Skylake | 96 | 624 | 1:6.5 | 2 | 28 | 56 |
n2-node-80-640 |
Cascade Lake | 80 | 640 | 1:8 | 2 | 24 | 48 |
n2-node-128-864 |
Ice Lake | 128 | 864 | 1:6.75 | 2 | 36 | 72 |
n2d-node-224-896 |
AMD EPYC Rome | 224 | 896 | 1:4 | 2 | 64 | 128 |
n2d-node-224-1792 |
AMD EPYC Milan | 224 | 1792 | 1:8 | 2 | 64 | 128 |
Mit allen Knoten können Sie verschiedene Formen von VMs planen. Knoten des n
-Typs sind Knoten für allgemeine Zwecke, auf denen Sie VMs des benutzerdefinierten Maschinentyps planen können. Empfehlungen zum Auswählen des Knotentyps finden Sie unter Empfehlungen für Maschinentypen.
Informationen zur Leistung finden Sie unter CPU-Plattformen.
Knotengruppen und VM-Bereitstellung
In Vorlagen für Knoten für einzelne Mandanten werden die Attribute einer Knotengruppe definiert. Eine solche Vorlage müssen Sie erstellen, bevor Sie eine Knotengruppe in einer Google Cloud-Zone erstellen. Geben Sie beim Erstellen einer Gruppe die Host-Wartungsrichtlinie für VMs in der Knotengruppe und die Anzahl der Knoten für die Knotengruppe an und legen Sie fest, ob die Gruppe für andere Projekte oder für die gesamte Organisation freigegeben werden soll.
Eine Knotengruppe kann null oder mehr Knoten enthalten. Beispielsweise können Sie die Anzahl der Knoten in einer Knotengruppe auf null reduzieren, wenn Sie keine VMs auf Knoten in der Gruppe ausführen müssen, oder Sie können das Knotengruppen-Autoscaling aktivieren, um die Größe der Knotengruppe automatisch verwalten zu lassen.
Bevor Sie VMs auf Knoten für einzelne Mandanten bereitstellen, müssen Sie eine Gruppe von Knoten für einzelne Mandanten erstellen. Eine Knotengruppe besteht aus einer Reihe gleichartiger Knoten für einzelne Mandanten in einer bestimmten Zone. Knotengruppen können mehrere VMs enthalten, die auf Maschinentypen unterschiedlicher Größe ausgeführt werden, solange der Maschinentyp zwei oder mehr vCPUs hat.
Aktivieren Sie Autoscaling, wenn Sie eine Knotengruppe erstellen, damit die Größe der Gruppe automatisch an die Anforderungen Ihrer Arbeitslast angepasst wird. Wenn Ihre Arbeitslastanforderungen statisch sind, können Sie die Größe der Knotengruppe manuell festlegen.
Nachdem Sie eine Knotengruppe erstellt haben, können Sie VMs in der Gruppe oder auf einem bestimmten Knoten innerhalb der Gruppe bereitstellen. Für noch mehr Kontrolle können Sie Knotenaffinitätslabels verwenden, um auf beliebigen Knoten VMs mit übereinstimmenden Affinitätslabels zu planen.
Nachdem Sie VMs in Knotengruppen bereitgestellt und optional Affinitätslabels für die Bereitstellung von VMs in bestimmten Knotengruppen oder auf Knoten zugewiesen haben, können Sie Ressourcen mit Labels versehen, um die VMs zu verwalten. Labels sind Schlüssel/Wert-Paare, mit denen Sie VMs kategorisieren können, um sie zusammengefasst anzeigen zu lassen, z. B. zu Abrechnungszwecken. Labels können Sie z. B. verwenden, um die Rolle einer VM, deren Mandanten, den Lizenztyp oder deren Standort zu kennzeichnen.
Hostwartungsrichtlinie
Abhängig von Ihren Lizenzierungsszenarien und Arbeitslasten können Sie die Anzahl der von Ihren VMs verwendeten physischen Kerne begrenzen. Die gewählte Host-Wartungsrichtlinie hängt beispielsweise von Ihren Lizenzierungs- oder Compliance-Anforderungen ab, oder möglicherweise möchten Sie auch eine Richtlinie auswählen, mit der Sie die Nutzung physischer Server einschränken können. Bei all diesen Richtlinien verbleiben die VMs auf dedizierter Hardware.
Wenn Sie VMs auf Knoten für einzelne Mandanten planen, können Sie zwischen den folgenden drei verschiedenen Host-Wartungsrichtlinien wählen, mit denen Sie festlegen können, wie und ob Compute Engine Live-Migrationen von VMs während Hostereignissen durchführt, die etwa alle vier bis sechs Wochen auftreten. Während der Wartung führt Compute Engine für alle VMs auf dem Host als einer Gruppe eine Live-Migration zu einem anderen Knoten für einzelne Mandanten durch. In einigen Fällen kann es auch vorkommen, dass Compute Engine die VMs in kleinere Gruppen unterteilt und für jede der kleineren VM-Gruppen eine Live-Migration zu separaten Knoten für einzelne Mandanten durchführt.
Standardrichtlinie für Hostwartung
Dies ist die Standard-Host-wartungsrichtlinie. VMs in Knotengruppen, die mit dieser Richtlinie konfiguriert sind, entsprechen dem traditionellen Wartungsverhalten für VMs ohne einzelne Mandanten. Das bedeutet, dass abhängig von der internen Wartungseinstellung des VM-Hosts vor einem Hostwartungsereignis eine Live-Migration der VMs auf einen neuen Knoten für einzelne Mandanten in der Knotengruppe ausgeführt wird und dieser neue Knoten für einzelne Mandanten nur die VMs des Kunden ausführt.
Diese Richtlinie eignet sich am besten für Lizenzen pro Nutzer oder Gerät, für die während Host-ereignissen eine Live-Migration erforderlich ist. Durch diese Einstellung wird die Migration von VMs nicht auf einen festen Pool physischer Server beschränkt. Sie wird für allgemeine Arbeitslasten empfohlen, für die keine physischen Server und keine vorhandenen Lizenzen erforderlich sind.
Da mit dieser Richtlinie VMs live zu einem beliebigen Server migriert werden, ohne die vorhandene Serveraffinität zu berücksichtigen, eignet sich diese Richtlinie nicht für Szenarien, in denen die Verwendung physischer Kerne während Host-ereignissen minimiert werden muss.
Die folgende Abbildung zeigt eine Animation der Host-Wartungsrichtlinie Standard.
![Animation der Standardrichtlinie für Hostwartungen.](https://cloud.google.com/static/compute/images/sole-tenancy/maintenance-policies/default.gif?hl=de)
Neustart vor Ort-Hostwartungsrichtlinie
Wenn Sie diese Host-Wartungsrichtlinie verwenden, beendet Compute Engine VMs während Host-Ereignissen und startet die VMs nach dem Host-ereignis auf demselben physischen Server neu. Sie müssen für die Einstellung "Bei Hostwartung" der VM TERMINATE
festlegen, wenn Sie diese Richtlinie verwenden.
Diese Richtlinie eignet sich am besten für fehlertolerante Arbeitslasten, die etwa eine Stunde Ausfallzeit tolerieren, wenn es zu Hostereignissen kommt, weiterhin für Arbeitslasten, die auf demselben physischen Server verbleiben müssen, für Arbeitslasten, die keine Live-Migration erfordern, sowie für Lizenzen, die auf der Anzahl der physischen Kerne oder Prozessoren basieren.
Mit dieser Richtlinie kann die Instanz der Knotengruppe mit dem Label node-name
, node-group-name
oder mit Knotenaffinität zugewiesen werden.
Die folgende Abbildung zeigt eine Animation der Wartungsrichtlinie Vor Ort neu starten.
![Animation der Host-Wartungsrichtlinie „Vor Ort neu“ starten.](https://cloud.google.com/static/compute/images/sole-tenancy/maintenance-policies/restart-in-place.gif?hl=de)
Wartungsrichtlinie "Innerhalb des Knotengruppenhost migrieren"
Bei Verwendung dieser Host-Wartungsrichtlinie migriert Compute Engine VMs während Host-ereignissen live innerhalb einer Gruppe physischer Server von fester Größe. Dadurch wird die Anzahl der eindeutigen physischen Server begrenzt, die von der VM verwendet werden.
Diese Richtlinie eignet sich am besten für Hochverfügbarkeits-Arbeitslasten mit Lizenzen, die auf der Anzahl der physischen Kerne oder Prozessoren basieren. Der Grund dafür ist, dass bei dieser Host-Wartungsrichtlinie jeder Knoten für einzelne Mandanten in der Gruppe mit einem festen Satz physischer Server verknüpft wird. Im Gegensatz dazu können VMs bei der Standardrichtlinie zu einem beliebigen Server migriert werden.
Damit die Kapazität für die Live-Migration gewährleistet wird, reserviert Compute Engine für 20 von Ihnen reservierte Knoten einen Holdback-Knoten. Die folgende Tabelle zeigt, wie viele Holdback-Knoten Compute Engine reserviert, je nachdem, wie viele Knoten Sie für Ihre Knotengruppe reserviert haben.
Gesamtzahl der Knoten in der Gruppe | Holdback-Knoten reserviert für Live-Migration |
---|---|
1 | Nicht zutreffend. Sie müssen mindestens zwei Knoten reservieren. |
2 bis 20 | 1 |
21 bis 40 | 2 |
41 bis 60 | 3 |
61 bis 80 | 4 |
81 bis 100 | 5 |
Bei dieser Richtlinie muss jede Instanz mithilfe des Affinitätslabels node-group-name
auf eine einzelne Knotengruppe ausgerichtet sein und darf keinem bestimmten Knoten node-name
zugewiesen werden. Dies ist erforderlich, damit Compute Engine die VMs bei einem Host-ereignis live zum Holdback-Knoten migrieren kann. Beachten Sie, dass die VMs beliebige benutzerdefinierte Knotenaffinitätslabels verwenden können, solange ihnen der node-group-name
und nicht der node-name
zugewiesen ist.
Die folgende Abbildung zeigt eine Animation der Host-Wartungsrichtlinie Innerhalb der Knotengruppe migrieren.
![Animation der Host-Wartungsrichtlinie „Innerhalb der Knotengruppe migrieren“.](https://cloud.google.com/static/compute/images/sole-tenancy/maintenance-policies/migrate-within-node-group.gif?hl=de)
Wartungsfenster
Wenn Sie Arbeitslasten verwalten, z. B. fein abgestimmte Datenbanken, die empfindlich auf die Auswirkungen der Live-Migration in Bezug auf die Leistung reagieren können, können Sie sofort feststellen, wann die Wartung für eine einzelne Datenbank an einer Knotengruppe für einzelne Mandanten beginnt. Dazu legen Sie ein Wartungsfenster fest, wenn Sie die Knotengruppe erstellen. Das Wartungsfenster kann nach der Erstellung der Knotengruppe nicht mehr geändert werden.
Wartungsfenster sind vierstündige Zeitblöcke, mit denen Sie angeben können, wann Google eine Wartung auf Ihren VMs für einzelne Mandanten durchführt. Wartungen werden etwa einmal alle 4 bis 6 Wochen durchgeführt.
Das Wartungsfenster gilt für alle VMs in der Knotengruppe für einzelne Mandanten. Es gibt nur an, wann die Wartung beginnt. Es wird nicht garantiert, dass die Wartung während des Wartungsfensters abgeschlossen wird, und es gibt keine Garantie für die Häufigkeit der Wartung. Wartungsfenster werden für Knotengruppen nicht unterstützt, wenn die Host-Wartungsrichtlinie Innerhalb der Knotengruppe migrieren festgelegt wurde.
Hostwartungsereignisse simulieren
Sie können ein Hostwartungsereignis simulieren, um zu testen, wie sich Ihre Arbeitslasten, die auf Knoten für einzelne Mandanten ausgeführt werden, während eines Hostwartungsereignisses verhalten. Dadurch können Sie die Auswirkungen der Hostwartungsrichtlinie der VM für einzelne Mandanten auf die Anwendungen sehen, die auf den VMs ausgeführt werden.
Hostfehler
Bei einem seltenen kritischen Hardwarefehler auf dem Host – ob bei einzelnen Mandanten oder mehreren Mandanten – führt Compute Engine folgende Schritte aus:
Der physische Server und seine eindeutige Kennzeichnung werden zurückgezogen.
Der Zugriff des Projekts auf den physischen Server wird entzogen.
Die ausgefallene Hardware wird durch einen neuen physischen Server mit einer neuen eindeutigen Kennzeichnung ersetzt.
Die VMs werden von der ausgefallenen Hardware auf den Ersatzknoten verschoben.
Die betroffenen VMs werden neu gestartet, wenn Sie sie für einen automatischen Neustart konfiguriert haben.
Knotenaffinität und Anti-Affinität
Mit Knoten für einzelne Mandanten ist sichergestellt, dass Ihre VMs keinen Host mit VMs aus anderen Projekten teilen, es sei denn, Sie verwenden freigegebene Knotengruppen für einzelne Mandanten. Mit freigegebenen Knotengruppen für einzelne Mandanten können andere Projekte innerhalb der Organisation VMs auf demselben Host bereitstellen. Sie können jedoch mehrere Arbeitslasten auf demselben Knoten für einzelne Mandanten gruppieren oder Ihre Arbeitslasten auf verschiedenen Knoten voneinander isolieren. Möglicherweise müssen Sie Affinitätslabels verwenden, um sensible Arbeitslasten von nicht sensiblen Arbeitslasten zu trennen, z. B. weil sie einige Compliance-Anforderungen erfüllen müssen.
Wenn Sie eine VM erstellen, fordern Sie Einzelmandantenfähigkeit an, indem Sie die Knotenaffinität oder Anti-Affinität festlegen und auf ein oder mehrere Knotenaffinitätslabels verweisen. Benutzerdefinierte Knotenaffinitätslabels geben Sie an, wenn Sie eine Knotenvorlage erstellen. Compute Engine fügt dann automatisch auf jedem Knoten einige Standardaffinitätslabels ein. Durch Festlegen der Affinität beim Erstellen einer VM können Sie VMs gemeinsam auf einem bestimmten Knoten oder auf mehreren Knoten in einer Knotengruppe planen. Wenn Sie beim Erstellen einer VM eine Anti-Affinität angeben, können Sie dadurch vermeiden, dass bestimmte VMs zusammen auf demselben oder mehreren Knoten in einer Knotengruppe geplant werden.
Knotenaffinitätslabels sind Schlüssel/Wert-Paare, die Knoten zugewiesen sind und von einer Knotenvorlage übernommen werden. Mit Affinitätslabels haben Sie folgende Möglichkeiten:
- Zuweisung einzelner VM-Instanzen zu Knoten steuern
- Zuweisung von VM-Instanzen, die mit einer Vorlage erstellt wurden, z. B. mithilfe einer verwalteten Instanzgruppe, zu Knoten steuern
- Gruppieren sensibler VM-Instanzen auf bestimmten Knoten oder Knotengruppen, getrennt von anderen VMs
Standardaffinitätslabels
Compute Engine weist jedem Knoten die folgenden Standardaffinitätslabels zu:
- Ein Label für den Namen der Knotengruppe:
- Schlüssel:
compute.googleapis.com/node-group-name
- Wert: Name der Knotengruppe.
- Schlüssel:
- Ein Label für den Knotennamen:
- Schlüssel:
compute.googleapis.com/node-name
- Wert: Name des einzelnen Knotens.
- Schlüssel:
- Ein Label für die Projekte, für die die Knotengruppe freigegeben ist:
- Schlüssel:
compute.googleapis.com/projects
- Wert: Projekt-ID des Projekts, das die Knotengruppe enthält.
- Schlüssel:
Benutzerdefinierte Affinitätslabels
Benutzerdefinierte Knotenaffinitätslabels können Sie beim Erstellen einer Knotenvorlage erstellen. Diese Affinitätslabels werden allen Knoten in Knotengruppen zugewiesen, die aus der Knotenvorlage erstellt wurden. Nachdem eine Knotengruppe erstellt wurde, können Sie keine weiteren benutzerdefinierten Affinitätslabels zu Knoten in einer Knotengruppe hinzufügen.
Weitere Informationen zur Verwendung von Affinitätslabels finden Sie unter Knotenaffinität konfigurieren.
Preise
Damit Sie die Kosten für Knoten für einzelne Mandanten minimieren können, bietet Compute Engine Rabatte für zugesicherte Nutzung und Rabatte für kontinuierliche Nutzung. Da Ihnen bereits die vCPUs und der Arbeitsspeicher für die Knoten für einzelne Mandanten in Rechnung gestellt werden, zahlen Sie auch keine zusätzlichen Gebühren für die VMs auf den Knoten für einzelne Mandanten.
Wenn Sie Knoten für einzelne Mandanten mit GPUs oder lokalen SSDs bereitstellen, werden Ihnen alle GPUs oder lokalen SSDs in Rechnung gestellt. Der Aufpreis für die Nutzung durch einen einzelnen Mandanten gilt nicht für GPUs oder lokale SSDs.
Verfügbarkeit
Knoten für einzelne Mandanten sind in ausgewählten Zonen verfügbar. Planen Sie VMs auf Knoten für einzelne Mandanten in verschiedenen Zonen, um eine hohe Verfügbarkeit zu gewährleisten.
Bevor Sie GPUs oder lokale SSDs auf Knoten für einzelne Mandanten verwenden, sollten Sie überprüfen, ob Sie in der Zone, in der Sie die Ressource reservieren, über ein ausreichendes Kontingent für GPUs oder lokale SSDs verfügen.
Compute Engine unterstützt GPUs für die Knotentypen
n1
undg2
für einzelne Mandanten, die sich in Zonen mit GPU-Unterstützung befinden. In der folgenden Tabelle sehen Sie, welche GPU-Typen Sie ann1
undg2
-Knoten anhängen können und wie viele GPUs Sie beim Erstellen der Knotenvorlage anhängen müssen.GPU-Typ GPU-Menge Knotentyp für einzelne Mandanten NVIDIA L4 8 g2
NVIDIA P100 4 n1
NVIDIA P4 4 n1
NVIDIA T4 4 n1
NVIDIA V100 8 n1
Compute Engine unterstützt lokale SSDs für die Knotentypen
n1
,n2
,n2d
undg2
für einzelne Mandanten, die sich in Zonen mit Unterstützung für lokale SSDs befinden.
Einschränkungen
Sie können VMs für einzelne Mandanten nicht mit T2D, T2A, E2 und C2D, A2 oder A3-Maschinenserie verwenden.
VMs für einzelne Mandanten können keine Mindest-CPU-Plattform angeben.
Sie können keine Migration einer VM zu einem Knoten für einzelne Mandanten ausführen, wenn für diese VM eine Mindest-CPU-Plattform angegeben ist. Wenn Sie eine VM zu einem Knoten für einzelne Mandanten migrieren möchten, entfernen Sie die Angabe der Mindest-CPU-Plattform. Legen Sie diese dazu auf „Automatisch“ fest, bevor Sie die Knotenaffinitätslabels der VM aktualisieren.
Knoten für einzelne Mandanten unterstützen keine VM-Instanzen auf Abruf.
Informationen zu den Einschränkungen bei der Verwendung lokaler SSDs auf Knoten für einzelne Mandanten finden Sie unter Datenpersistenz auf lokalen SSDs.
Informationen dazu, wie sich die Verwendung von GPUs auf die Live-Migration auswirkt, finden Sie unter Einschränkungen der Live-Migration.
Knoten für einzelne Mandanten mit GPUs unterstützen keine VMs ohne GPUs.
C3- und C3D-Knoten für einzelne Mandanten unterstützen kein Overcommit von CPUs.
C3-Knoten für einzelne Mandanten unterstützen keine verschiedenen C3-VM-Konfigurationen auf demselben Knoten für einzelne Mandanten. Sie können beispielsweise keine
c3-standard
-VM auf demselben Knoten für einzelne Mandanten alsc3-highmem
-VM platzieren.Sie können die Wartungsrichtlinie nicht für eine Live-Knotengruppe aktualisieren.
Nächste Schritte
Knoten für einzelne Mandanten erstellen, konfigurieren und nutzen
Weitere Informationen zum Overcommit von CPUs auf VMs für einzelne Mandanten
Lesen Sie unsere Best Practices für die Verwendung von Knoten für einzelne Mandanten zum Ausführen von VM-Arbeitslasten.