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

Ü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
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

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

Beim Erstellen einer Knotengruppe können Sie eine Wartungsrichtlinie für VMs angeben, um unterschiedlichen Arbeitslastanforderungen gerecht zu werden. Mit der Wartungsrichtlinie für Knoten für einzelne Mandanten können Sie konfigurieren, wie und ob für VMs in Knotengruppen nach einem Wartungsereignis eine Migration durchgeführt wird. Die gewählte Wartungsrichtlinie hängt beispielsweise von Ihren Lizenzierungs- oder Compliance-Anforderungen ab, oder möglicherweise möchten Sie auch eine Konfiguration auswählen, mit der Sie die Nutzung physischer Server einschränken können. Bei allen diesen Wartungsrichtlinien verbleiben die VMs auf dedizierter Hardware. In der folgenden Liste werden diese Wartungsrichtlinien beschrieben:

  • Standard: VMs in Knotengruppen, die mit dieser Richtlinie konfiguriert sind, entsprechen dem traditionellen Wartungsverhalten für VMs auf Knoten für mehrere 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. 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.

  • Vor Ort neu starten: VM-Instanzen werden beendet und nach dem Wartungsereignis auf demselben physischen Host neu gestartet. Ziehen Sie diese Richtlinie in Betracht, wenn Ihre Arbeitslasten keine Live-Migration erfordern, etwa alle vier bis sechs Wochen ein Hostwartungsereignis mit einer Ausfallzeit von etwa einer Stunde tolerieren und Ihre VMs eine physische Serveraffinität zu einem einzelnen Host beibehalten müssen.

  • Innerhalb der Knotengruppe migrieren: Je nach der hostinternen Wartungseinstellung der VM wird vor einem Hostwartungsereignis eine Live-Migration der VMs auf einen anderen Knoten in der Knotengruppe ausgeführt. Im Gegensatz zur Standardeinstellung finden diese Migrationen auf einer festen Gruppe physischer Server statt, um die Anzahl der eindeutigen physischen Server zu begrenzen, die von der VM verwendet werden. Damit ausreichend Kapazität für die Migration von VMs vorhanden ist, wird von Compute Engine pro 20 Knoten für einzelne Mandanten ein Knoten reserviert. Ziehen Sie die Verwendung dieser Richtlinie in Betracht, wenn Sie eine Live-Migration Ihrer Arbeitslasten ausführen müssen, weil sie keine Ausfallzeiten tolerieren, für Ihre Arbeitslasten kern- oder prozessorbasierte Lizenzierungsanforderungen bestehen und Sie bereit sind, zusätzliche Knoten für einzelne Mandanten bereitzustellen.

Hardwarefehler

In seltenen Fällen kann es bei einem Server zu einem kritischen Hardwarefehler kommen. In diesem Fall nimmt Compute Engine den physischen Server und seine eindeutige Kennung zurück, widerruft den Zugriff auf den physischen Server, weist einem Ersatzknoten eine neue eindeutige Kennung zu und verschiebt Ihre VMs auf den Ersatzknoten. Abhängig von der Konfiguration der Knoten für einzelne Mandanten startet Compute Engine Ihre VMs möglicherweise neu.

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