Knoten für einzelne Mandanten


Auf dieser Seite werden Knoten für einzelne Mandanten erläutert. 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.

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.

Die Einzelmandantenfähigkeit eignet sich für bestimmte Arten von Arbeitslasten. Beispielsweise können sich für Spielarbeitslasten mit hohen Leistungsanforderungen Vorteile ergeben, da sie auf ihrer eigenen Hardware isoliert sind. Finanz- oder Gesundheitsarbeitslasten können wiederum aufgrund der Sicherheits- und Compliance-Anforderungen und Windows-Arbeitslasten aufgrund der Lizenzanforderungen profitieren.

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. Da Sie die Host-Hardware 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. Um die Nutzung der Hosthardware zu optimieren, können Sie einen Overcommit von VM-CPUs für einzelne Mandanten verwenden.

Über eine konfigurierbare Wartungsrichtlinie können Sie mit Knoten für einzelne Mandanten das Verhalten von VMs bei Hostwartungsereignissen steuern. Mit der Wartungsrichtlinie können Sie angeben, ob VMs, die auf Knoten für einzelne Mandanten bereitgestellt werden, die Affinität zu einem bestimmten physischen Server beibehalten oder ob VMs innerhalb einer festen Gruppe physischer Server verschoben werden.

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, geben Sie einen Knotentyp und optional Knotenaffinitätslabels an. Sie können Knotenaffinitätslabels nur für eine Knotenvorlage angeben, aber nicht für Knotengruppen.

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. Knoten dieses Typs können mehrere VMs unterschiedlicher Form aufnehmen, die jeweils auf potenziell unterschiedlichen Maschinentypen ausgeführt werden, bis die Gesamtzahl der VM-Formen 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 Instanzen planen.

In der folgenden Tabelle sind alle 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
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36
m1-node-96-1433 Skylake 96 1.433 1:14.9 2 28 56
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
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128

Mit allen Knoten können Sie verschiedene Formen von VMs planen. n-Knoten sind Knoten für allgemeine Zwecke, auf denen Sie Instanzen vom benutzerdefinierten Maschinentyp planen können. Empfehlungen zum Auswählen des Knotentyps finden Sie unter Empfehlungen für Maschinentypen. Informationen zur Leistung finden Sie unter CPU-Plattformen.

Es kann vorkommen, dass Compute Engine einen älteren Knotentyp durch einen neueren Knotentyp ersetzt. Wenn Compute Engine einen Knotentyp ersetzt, können Sie keine zusätzlichen Knotengruppen aus Vorlagen erstellen, in denen der ersetzte Knotentyp angegeben ist. Ist dies der Fall, müssen Sie alle vorhandenen Knotenvorlagen prüfen und ändern, wenn sie nicht mehr verfügbare Knotentypen enthalten.

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 Wartungsrichtlinie für VM-Instanzen in der Knotengruppe und die Anzahl der Knoten in der Knotengruppe an. 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 VM-Instanzen 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.

Wartungsrichtlinien

Abhängig von Ihren Lizenzierungsszenarien und Arbeitslasten können Sie die Anzahl der von Ihren VMs verwendeten physischen Kerne begrenzen. Die gewählte 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 Wartungsrichtlinien wählen, mit denen Sie festlegen können, wie und ob Compute Engine Live-Migrationen von VMs während Hostwartungsereignissen 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.

  • Standard: Dies ist die Standardwartungsrichtlinie. 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. Außerdem gilt:

    • Diese Richtlinie eignet sich am besten für Lizenzen pro Nutzer oder Gerät, für die während Wartungsereignissen 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 vorhandene 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 Wartungsereignissen minimiert werden muss.

  • Vor Ort neu starten: Wenn Sie diese Wartungsrichtlinie verwenden, beendet Compute Engine VMs während Wartungsereignissen und startet die VMs nach dem Wartungsereignis auf demselben physischen Server neu. Sie müssen für die Einstellung "Bei Hostwartung" der VM TERMINATE (Beenden) festlegen, wenn Sie diese Richtlinie verwenden. Außerdem gilt:

    • Diese Richtlinie eignet sich am besten für fehlertolerante Arbeitslasten, die etwa eine Stunde Ausfallzeit tolerieren, wenn es zu Hostwartungsereignissen 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 muss der Instanz nur das Affinitätslabel node-group-name zugewiesen werden, das Sie entweder direkt angeben können oder festlegen, indem Sie die VM auf der Knotengruppe mithilfe des Namens der Knotengruppe planen.

  • Innerhalb der Knotengruppe migrieren: Bei Verwendung dieser Wartungsrichtlinie migriert Compute Engine VMs während Wartungsereignissen 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. Außerdem gilt:

    • 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 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.

    • Um die Kapazität für die Live-Migration zu gewährleisten, reserviert Compute Engine dafür je einen von zwanzig bereitgestellten Knoten.

    • Mit dieser Richtlinie muss der Instanz nur das Affinitätslabel node-group-name zugewiesen werden, das Sie entweder direkt angeben können oder festlegen, indem Sie die VM auf der Knotengruppe mithilfe des Namens der Knotengruppe planen.

Ungeplante Wartung

Im seltenen Fall eines kritischen Hardwarefehlers wird Compute Engine Folgendes tun:

  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 keine Host-Hardware mit VMs aus anderen Projekten teilen. 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 zwei 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.

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.

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 sicherzustellen.

Beschränkungen

Weitere Informationen