Wenn Sie VM-Arbeitslasten auf Knoten für einzelne Mandanten ausführen möchten, müssen Sie zuerst entscheiden, wie die Knoten für einzelne Mandanten bereitgestellt werden sollen. Sie müssen vor allem entscheiden, wie viele Knotengruppen Sie benötigen, und welche Wartungsrichtlinie die Knotengruppen verwenden sollen:
Knotengruppen: Zur Auswahl der richtigen Anzahl an Knotengruppen müssen Sie die Verfügbarkeit und die Ressourcennutzung abwägen. Eine kleine Anzahl von Knotengruppen optimiert zwar die Ressourcennutzung und -kosten, Sie sind dann aber auf eine einzige Zone beschränkt. Eine Bereitstellung von Knotengruppen über mehrere Zonen verbessert die Verfügbarkeit, kann jedoch zu einer geringeren Ressourcenauslastung führen.
Autoscaling und Wartungsrichtlinien: Abhängig von den Lizenzanforderungen der Betriebssysteme und Software, die Sie ausführen möchten, kann das Autoscaling von Knoten und die von Ihnen gewählte Wartungsrichtlinie sich auf Ihre Lizenzkosten und -verfügbarkeit auswirken.
Für die richtige Entscheidung bei der Verwendung von Knoten für einzelne Mandanten sollten Sie Ihre Anforderungen sorgfältig berücksichtigen.
Anforderungen prüfen
Im folgenden Abschnitt werden mehrere Anforderungen aufgeführt, die Sie berücksichtigen sollten, bevor Sie entscheiden, wie viele Knotengruppen Sie benötigen und welche Wartungsrichtlinie die Knotengruppen verwenden sollten.
BYOL-Lizenzierung und Lizenzierung pro Kern
Wenn Sie Ihre eigene Lizenz (BYOL) in Compute Engine verwenden möchten, können Knoten für einzelne Mandanten Sie dabei unterstützen, die Hardwareanforderungen oder -einschränkungen zu erfüllen, die durch diese Lizenzen auferlegt werden.
Einige Software- und Betriebssysteme wie Windows Server können von physischen CPU-Kernen lizenziert werden und definieren möglicherweise Limits für die Häufigkeit, mit der Sie die der virtuellen Maschinen zugrunde liegende Hardware ändern dürfen. Das Autoscaling von Knoten und die Standard-Wartungsrichtlinie können dazu führen, dass Hardware häufiger geändert wird, als Ihre Lizenzbedingungen zulassen. Dies kann zu zusätzlichen Lizenzgebühren führen.
Beachten Sie die folgenden Best Practices, um BYOL pro Kern zu optimieren:
Finden Sie ein Gleichgewicht zwischen der Optimierung der Infrastrukturkosten und Lizenzkosten: Zur Berechnung der Gesamtkosten für die Ausführung von BYOL-Arbeitslasten in Compute Engine müssen Sie sowohl die Infrastrukturkosten als auch die Lizenzkosten berücksichtigen. In einigen Fällen kann das Minimieren der Infrastrukturkosten zur Erhöhung des Lizenzierungsaufwands oder umgekehrt führen. Beispiel: Die Verwendung eines Knotentyps mit einer hohen Anzahl von Kernen kann für bestimmte Arbeitslasten das beste Kosten-/Leistungsverhältnis bieten. Es kann jedoch auch zu zusätzlichen Lizenzkosten führen, wenn die Lizenzen pro Kern berechnet werden.
Separate Knotengruppen für BYOL- und Nicht-BYOL-Arbeitslasten verwenden: Damit die Anzahl der zu lizenzierenden Kerne begrenzt wird, sollten Sie BYOL- und Nicht-BYOL-Arbeitslasten nicht in einer einzelnen Knotengruppe vermischen. Verwenden Sie stattdessen separate Knotengruppen.
Wenn Sie mehrere verschiedene BYOL-Lizenzierungsmodelle verwenden (z. B. Windows Server Datacenter und Standard), kann eine Aufteilung der Knotengruppen anhand des Lizenzmodells das Lizenz-Tracking vereinfachen und die Lizenzkosten senken.
CPU-Overcommit und Knotentypen mit hohem Kern-/Speicherverhältnis verwenden: Die Knotentypen unterscheiden sich in ihrem Verhältnis zwischen Sockets, Kernen und Arbeitsspeicher. Wenn Sie einen Knotentyp mit einem höheren Kern-/Speicherverhältnis verwenden und CPU-Overcommit aktivieren, können Sie die Anzahl der Kerne, die Sie lizenzieren müssen, reduzieren.
Autoscaling für die Herunterskalierung vermeiden: Mit dem Autoscaling für Knotengruppen können Sie eine Knotengruppe basierend auf dem aktuellen Bedarf automatisch vergrößern oder verkleinern. Das häufige Vergrößern und Verkleinern einer Knotengruppe bedeutet, dass Sie häufig die Hardware ändern, auf der Ihre VMs ausgeführt werden.
Wenn Sie Hardware häufiger ändern als das Verschieben Ihrer Lizenzen zwischen physischen Maschinen zulässig ist, können diese Hardwareänderungen dazu führen, dass Sie mehr Kerne lizenzieren müssen als Sie tatsächlich verwenden.
Wenn es Beschränkungen dafür gibt, wie häufig Sie zwischen physischen Maschinen wechseln dürfen, können Sie das Autoscaling deaktivieren und so übermäßige Lizenzkosten vermeiden. Alternativ können Sie das Autoscaling so konfigurieren, dass nur horizontal skaliert wird.
Keine Standard-Wartungsrichtlinie verwenden: Mit der Standard-Wartungsrichtlinie können Sie die VM-Verfügbarkeit optimieren, aber sie kann auch zu häufigen Hardwareänderungen führen. Verwenden Sie stattdessen die Wartungsrichtlinie Innerhalb der Knotengruppe migrieren oder Neustart vor Ort, um Hardwareänderungen zu reduzieren und die Lizenzkosten zu optimieren.
Beachten Sie für Arbeitslasten, die keine Lizenz pro Kern erfordern, die folgenden Best Practices:
- Standard-Wartungsrichtlinie verwenden: Durch die Verwendung der Live-Migration bietet die Standard-Wartungsrichtlinie eine bessere Verfügbarkeit als die Wartungsrichtlinie Neustart vor Ort und vermeidet die zusätzlichen Infrastrukturkosten der Wartungsrichtlinie Innerhalb der Knotengruppe migrieren.
Verwaltung
Wenn Sie mehr als eine Arbeitslast oder sowohl Entwicklungs- als auch Produktionsarbeitslasten, haben die auf Knoten für einzelne Mandanten ausgeführt werden müssen, sollten Sie die folgenden Best Practices berücksichtigen:
Separate Knotengruppen für Entwicklungs- und Produktionsumgebungen verwenden: Mit separaten Knotengruppen können Sie Umgebungen von anderen isolieren und Situationen wie die folgenden vermeiden:
- Eine Entwicklungs-VM kann sich auf die Leistung von Produktions-VMs auswirken, indem sie CPU-, Laufwerk- oder Netzwerkressourcen zu stark beansprucht („Problemnachbar”).
- Eine Entwicklungsarbeitslast kann die Kapazität einer Knotengruppe ausschöpfen, wodurch die Erstellung neuer Produktions-VMs verhindert wird.
Anzahl der Knotengruppen in jeder Umgebung begrenzen: Wenn Sie mehrere Knotengruppen ausführen, kann es schwierig sein, jede Knotengruppe vollständig zu nutzen. Zur Optimierung der Auslastung kombinieren Sie Arbeitslasten aus jeder Umgebung und planen sie für eine kleine Anzahl von Knotengruppen.
Dedizierte Projekte zum Verwalten von Knotengruppen verwenden: Erstellen Sie für jede Umgebung ein dediziertes Projekt zum Verwalten von Knotengruppen. Geben Sie dann die Knotengruppen für Projekte frei, die Arbeitslasten enthalten.
Mit diesem Ansatz können Sie die Zugriffssteuerung vereinfachen, indem Sie für jede Arbeitslast ein separates Projekt verwenden. Gleichzeitig können Sie die Ressourcennutzung optimieren, indem Sie Knotengruppen für mehrere Arbeitslasten freigeben.
Knotengruppen für einzelne Projekte freigeben: Anstatt eine Knotengruppe für eine gesamte Organisation freizugeben, geben Sie sie nur für einzelne Projekte frei. Wenn Sie Projekte einzeln auswählen, können Sie die Trennung zwischen den Umgebungen aufrechterhalten und Informationen zu Knotengruppen werden nicht an andere Projekte weitergegeben.
Prozess für die interne Kostenzuordnung einrichten: Die Kosten für die Ausführung einer Knotengruppe fallen in dem Projekt an, das die Knotengruppe enthält. Wenn Sie diese Kosten einzelnen Projekten oder Arbeitslasten zuordnen müssen, sollten Sie die Nutzung Ihrer VMs für einzelne Mandanten verfolgen und diese Daten zur internen Kostenzuordnung verwenden.
Verfügbarkeit
Ihre Arbeitslasten können sich in ihren Verfügbarkeitsanforderungen unterscheiden und darin, ob Hochverfügbarkeit auf Anwendungsebene erreicht werden kann oder ob sie auf der Infrastrukturebene implementiert werden muss:
Geclusterte Anwendungen: Einige Ihrer Arbeitslasten implementieren die Hochverfügbarkeit in der Anwendung möglicherweise mithilfe von Clustertechniken wie Replikation und Load-Balancing.
Beispiele für solche Arbeitslasten sind Active Directory-Domaincontroller, SQL Server-Failover-Clusterinstanzen und Verfügbarkeitsgruppen oder in IIS ausgeführte geclusterte Anwendungen mit Load-Balancing.
Geclusterte Anwendungen können in der Regel einzelne VM-Ausfälle aufrechterhalten, solange die Mehrheit der VMs verfügbar bleibt.
Nicht geclusterte Anwendungen: Einige Ihrer Arbeitslasten implementieren möglicherweise keinerlei Clustering-Funktionen und erfordern stattdessen, dass die VM selbst verfügbar bleibt.
Beispiele für solche Arbeitslasten sind nicht replizierte Datenbankserver oder zustandsorientierte Anwendungsserver.
Zur Optimierung der Verfügbarkeit einzelner VMs müssen Sie dafür sorgen, dass die VM bei einem bevorstehenden Knotenwartungsereignis live migriert werden kann.
Die Live-Migration wird von der Standard-Wartungsrichtlinie und der Wartungsrichtlinie Innerhalb der Knotengruppe migrieren unterstützt, jedoch nicht von der Wartungsrichtlinie Neustart vor Ort.
Nicht kritische Anwendungen: Batch-Arbeitslasten, Entwicklungs-/Testarbeitslasten und andere Arbeitslasten mit niedrigerer Priorität haben möglicherweise keine besonderen Verfügbarkeitsanforderungen. Für diese Arbeitslasten kann es akzeptabel sein, wenn einzelne VMs während der Knotenwartung nicht verfügbar sind.
Beachten Sie die folgenden Best Practices, um die Verfügbarkeitsanforderungen Ihrer Arbeitslasten zu erfüllen:
Knotengruppen in verschiedenen Zonen oder Regionen verwenden, um geclusterte Arbeitslasten bereitzustellen: Knoten für einzelne Mandanten und Knotengruppen sind eine zonale Ressource. Erstellen Sie zum Schutz vor zonalen Ausfällen mehrere Knotengruppen in verschiedenen Zonen oder Regionen. Verwenden Sie Knotenaffinität, um VMs so zu planen, dass jede Instanz der geclusterten Anwendung auf einem anderen Knoten in einer anderen Zone oder Region ausgeführt wird.
Wenn zwei oder mehr Knotengruppen die Standard-Wartungsrichtlinie oder die Wartungsrichtlinie Neustart vor Ort ausführen, konfigurieren Sie die Wartungsfenster so, dass sie sich nicht überschneiden.
Wenn mehrere Instanzen Ihrer geclusterten Anwendungen in einer einzigen Zone ausgeführt werden müssen, verwenden Sie Anti-Affinität, damit die VM-Instanzen auf verschiedenen Knoten oder Knotengruppen geplant werden.
Wartungsrichtlinie Neustart vor Ort für nicht geclusterte Arbeitslasten vermeiden, die eine hohe Verfügbarkeit erfordern: Da die Wartungsrichtlinie Neustart vor Ort VMs herunterfährt, wenn der zugrunde liegende Knoten eine Wartung erfordert, sollten Sie für Knotengruppen, die nicht geclusterte Arbeitslasten ausführen und für die Hochverfügbarkeit erforderlich ist, eine andere Wartungsrichtlinie verwenden.
Verwaltete Instanzgruppen verwenden, um die Ausfallsicherheit und Verfügbarkeit von Arbeitslasten zu erhöhen: Sie können die Ausfallsicherheit und Verfügbarkeit Ihrer Bereitstellung weiter erhöhen. Verwenden Sie dazu verwaltete Instanzgruppen, um den Zustand Ihrer Arbeitslasten zu überwachen und VM-Instanzen bei Bedarf automatisch neu zu erstellen. Sie können verwaltete Instanzgruppen sowohl für zustandslose als auch für zustandsorientierte Arbeitslasten verwenden.
Leistung
Die Arbeitslasten können sich in Bezug auf Leistungsschwankungen unterscheiden. Bei bestimmten internen Anwendungen oder Testarbeitslasten ist die Optimierung der Kosten möglicherweise wichtiger als die konsistente Leistung über den ganzen Tag. Bei anderen Arbeitslasten, z. B. bei nach außen gerichteten Anwendungen, kann die Leistung kritisch und wichtiger als die Ressourcennutzung sein.
Beachten Sie die folgenden Best Practices, um die Knoten für einzelne Mandanten optimal zu nutzen:
Dedizierte Knotengruppen und CPU-Overcommit für leistungsunabhängige Arbeitslasten verwenden: Mit einem CPU-Overcommit können Sie die VM-Dichte auf Knoten für einzelne Mandanten erhöhen und die Anzahl der erforderlichen Knoten für einzelne Mandanten reduzieren.
Zur Verwendung von CPU-Overcommit müssen Sie einen Knotentyp verwenden, der CPU-Overcommit unterstützt. Wenn Sie CPU-Overcommit für eine Knotengruppe aktivieren, fallen zusätzliche Gebühren pro Knoten für einzelne Mandanten an.
CPU-Overcommit kann kostengünstig sein, wenn Sie eine dedizierte Knotengruppe für Arbeitslasten verwenden, die für ein CPU-Overcommit geeignet sind, und nur für diese Knotengruppe das CPU-Overcommit aktivieren. Lassen Sie das CPU-Overcommit für alle Knotengruppen deaktiviert, die leistungsabhängige Arbeitslasten ausführen müssen.
Knotentyp mit hohem Kern/Speicherverhältnis für CPU-Overcommit verwenden: Mit CPU-Overcommit können Sie zwar Kerne zwischen VMs teilen, aber Arbeitsspeicher kann nicht zwischen VMs geteilt werden. Wenn Sie einen Knotentyp mit relativ viel Arbeitsspeicher pro CPU-Kern verwenden, können Sie dafür sorgen, dass der Arbeitsspeicher nicht zu einem begrenzenden Faktor wird.
Knoten-Autoscaling für leistungsabhängige Arbeitslasten verwenden: Wenn Sie verschiedene Ressourcenanforderungen für leistungsabhängige Arbeitslasten erfüllen müssen, konfigurieren Sie Ihre Knotengruppe für die Verwendung von Autoscaling.
Bereitstellungsmuster
Welches die beste Methode für die Verwendung von Knoten für einzelne Mandanten ist, hängt von Ihren individuellen Anforderungen ab. Im folgenden Abschnitt wird eine Auswahl von Mustern beschrieben, die Sie als Ausgangspunkt für den Aufbau einer Architektur verwenden können, die Ihren individuellen Anforderungen entspricht.
Mehrere Knotengruppen für gemischte Leistungsanforderungen
Wenn Sie eine Kombination aus Arbeitslasten haben, die leistungsabhängig sind (z. B. kundenorientierte Anwendungen) und leistungsunabhängig (z. B. interne Anwendungen), können Sie mehrere Knotengruppen mit unterschiedlichen Knotentypen verwenden:
- Eine Knotengruppe verwendet CPU-Overcommit und einen Knotentyp mit dem Verhältnis 1:8 zwischen vCPU und Arbeitsspeicher. Diese Knotengruppe wird für leistungsunabhängige Arbeitslasten verwendet.
- Eine zweite Knotengruppe verwendet einen leistungsoptimierten Knotentyp mit dem Verhältnis 1:4 zwischen vCPU und Arbeitsspeicher ohne CPU-Overcommit. Diese Knotengruppe wird für leistungskritische Arbeitslasten verwendet und wird nach Bedarf hoch- und herunterskaliert.
Hochverfügbarkeit mit mehreren Zonen für geclusterte, pro Kern lizenzierte Arbeitslasten
Wenn Sie geclusterte Arbeitslasten ausführen, die eine Lizenzierung pro Kern verwenden, und Hardwareänderungen minimieren müssen, können Sie ein Gleichgewicht zwischen Verfügbarkeit und Lizenzierungsaufwand erzielen. Dazu verwenden Sie mehrere Knotengruppen mit nicht überlappenden Wartungsfenstern:
- Mehrere Knotengruppen werden in verschiedenen Zonen oder Regionen bereitgestellt.
- Alle Knotengruppen verwenden die Wartungsrichtlinie Neustart. Die Knotengruppen verwenden nicht überlappende Wartungsfenster, sodass nur jeweils eine Knotengruppe einen wartungsbezogenen Ausfall haben sollte.
- VM-Instanzen, die geclusterte Arbeitslasten ausführen, verwenden Affinitätslabels, sodass jeder Clusterknoten in einer Knotengruppe in einer anderen Zone geplant wird.
Hochverfügbarkeit mit mehreren Zonen für gemischte, pro Kern lizenzierte Arbeitslasten
Wenn Sie die Lizenzierung pro Kern verwenden, aber nicht alle Arbeitslasten geclustert sind, können Sie das vorherige Muster mithilfe heterogener Wartungsrichtlinien erweitern:
- Die primäre Knotengruppe wird in der Zone
abereitgestellt und führt sowohl geclusterte als auch nicht geclusterte Arbeitslasten aus. Zur Minimierung von Ausfällen durch Hardwarewartungen verwendet die Knotengruppe die Wartungsrichtlinie Innerhalb der Knotengruppe migrieren. - Eine oder mehrere sekundäre Knotengruppen werden in zusätzlichen Zonen oder Regionen bereitgestellt. Diese Knotengruppen verwenden die Wartungsrichtlinie Neustart und Wartungsfenster, die sich nicht überlappen.
- VM-Instanzen, die geclusterte Arbeitslasten ausführen, verwenden Affinitätslabels, sodass jeder Clusterknoten in einer Knotengruppe in einer anderen Zone geplant wird.
- VM-Instanzen, die nicht geclusterte Arbeitslasten ausführen, verwenden Affinitätslabels, damit sie in der primären Knotengruppe bereitgestellt werden.
Durch das Planen von geclusterten Arbeitslasten in den sekundären Knotengruppen können Sie dafür sorgen, dass die vorübergehenden Ausfälle, die durch die Wartungsrichtlinie Neustart verursacht werden, nur minimale Auswirkungen auf die Gesamtverfügbarkeit haben. Gleichzeitig beschränken Sie die Lizenzierung und den Infrastrukturaufwand, wenn Sie die Wartungsrichtlinie Innerhalb der Knotengruppe migrieren nur für die primäre Knotengruppe verwenden.
Nächste Schritte
Weitere Informationen zum Overcommit von CPUs auf VMs für einzelne Mandanten