Einzelne Mandanten

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.

Mehrmandantenfähiger Host im Vergleich zu einem Knoten für einen einzelnen Mandanten.
Abbildung 1: Mehrmandantenfähiger Host im Vergleich zu einem Knoten für einen einzelnen Mandanten

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.
Abbildung 2: Animation der Standardrichtlinie für Hostwartungen.

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.
Abbildung 3: Animation der Host-Wartungsrichtlinie Vor Ort neu starten.

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“.
Abbildung 4: Animation der Host-Wartungsrichtlinie Innerhalb der Knotengruppe migrieren.

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:

  1. Der physische Server und seine eindeutige Kennzeichnung werden zurückgezogen.

  2. Der Zugriff des Projekts auf den physischen Server wird entzogen.

  3. Die ausgefallene Hardware wird durch einen neuen physischen Server mit einer neuen eindeutigen Kennzeichnung ersetzt.

  4. Die VMs werden von der ausgefallenen Hardware auf den Ersatzknoten verschoben.

  5. 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.
  • Ein Label für den Knotennamen:
    • Schlüssel: compute.googleapis.com/node-name
    • Wert: Name des einzelnen Knotens.
  • 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.

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 und g2 für einzelne Mandanten, die sich in Zonen mit GPU-Unterstützung befinden. In der folgenden Tabelle sehen Sie, welche GPU-Typen Sie an n1 und g2-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 und g2 für einzelne Mandanten, die sich in Zonen mit Unterstützung für lokale SSDs befinden.

Einschränkungen

Nächste Schritte