Azure Stack Hub-Computekapazität

Die auf Azure Stack Hub unterstützten VM-Größen (Virtual Machine) sind eine Teilmenge der in Azure unterstützten. Azure erzwingt Ressourcengrenzwerte auf verschiedene Arten, um einen übermäßigen Ressourcenverbrauch (auf dem lokalen Server und auf der Dienstebene) zu vermeiden. Ohne einschränkungen für den Mandantenverbrauch zu erzwingen, leiden die Mandantenerfahrungen, wenn andere Mandanten Ressourcen überlasten. Für den Netzwerkausgang vom virtuellen Computer gibt es Bandbreitengrenzen auf Azure Stack Hub, die den Azure-Einschränkungen entsprechen. Für Speicherressourcen in Azure Stack Hub werden Speicher-IOPS-Grenzwerte verwendet, um beim Speicherzugriff grundsätzlich einen übermäßigen Ressourcenverbrauch durch Mandanten zu vermeiden.

Von Bedeutung

Der Azure Stack Hub Capacity Planner berücksichtigt oder garantiert keine IOPS-Leistung. Das Administratorportal zeigt eine Warnung an, wenn die Gesamtauslastung des Systemspeichers 85%erreicht. Diese Warnung kann behoben werden, indem sie mehr Kapazität hinzufügen oder virtuelle Computer entfernen, die nicht mehr benötigt werden.

VM-Platzierung

Das Azure Stack Hub-Platzierungsmodul platziert Mandanten-VMs auf den verfügbaren Hosts.

Azure Stack Hub verwendet beim Platzieren von VMs zwei Überlegungen. Eins, gibt es genügend Arbeitsspeicher auf dem Host für diesen VM-Typ? Und zwei, sind die virtuellen Computer Teil eines Verfügbarkeitssatzes oder sind sie VM-Skalierungssätze?

Um eine hohe Verfügbarkeit einer Multi-VM-Produktionsauslastung in Azure Stack Hub zu erreichen, werden virtuelle Computer (VMs) in einem Verfügbarkeitssatz platziert, der sie über mehrere Fehlerdomänen verteilt. Die Definition einer Fehlerdomäne in einer Verfügbarkeitsgruppe ist ein einzelner Knoten in der Skalierungseinheit. Azure Stack Hub unterstützt die Verwendung einer Verfügbarkeitsgruppe mit maximal drei Fehlerdomänen, um Konsistenz mit Azure zu erzielen. VMs, die in einem Verfügbarkeitssatz platziert werden, werden physisch voneinander isoliert, indem sie so gleichmäßig wie möglich über mehrere Fehlerdomänen (Azure Stack Hub-Knoten) verteilt werden. Wenn ein Hardwarefehler auftritt, werden VMs aus der fehlerhaften Fehlerdomäne in anderen Fehlerdomänen neu gestartet. Wenn möglich, werden sie in separaten Fehlerdomänen von den anderen virtuellen Computern im gleichen Verfügbarkeitssatz gespeichert. Wenn der Host wieder online ist, werden virtuelle Computer neu ausgeglichen, um eine hohe Verfügbarkeit aufrechtzuerhalten.

Für VM-Skalierungsgruppen werden Verfügbarkeitsgruppen auf dem Back-End verwendet, und es wird sichergestellt, dass jede Instanz der VM-Skalierungsgruppe in einer anderen Fehlerdomäne platziert wird. Dies bedeutet, dass hierfür separate Azure Stack Hub-Infrastrukturknoten verwendet werden. In einem Azure Stack Hub-System mit vier Knoten kann es z. B. eine Situation geben, in der eine Vm-Skalierungsgruppe von drei Instanzen bei der Erstellung fehlschlägt, da die Kapazität von vier Knoten fehlt, um drei VM-Skalierungsgruppeninstanzen auf drei separaten Azure Stack Hub-Knoten zu platzieren. Außerdem können Azure Stack Hub-Knoten vor der Durchführung der Platzierung auf verschiedenen Ebenen gefüllt werden.

Azure Stack Hub überbucht keinen Arbeitsspeicher. Bei der Anzahl von physischen Kernen ist dies aber zulässig.

Da Platzierungsalgorithmen nicht das vorhandene virtuelle zu physische Kernüberteilungsverhältnis als Faktor betrachten, könnte jeder Host ein anderes Verhältnis aufweisen. Als Microsoft bieten wir keine Anleitungen zum physischen zu virtuellen Kernverhältnis aufgrund der Variation von Workloads und Anforderungen auf Serviceebene.

Berücksichtigung der Gesamtzahl der virtuellen Computer

Es gibt einen Grenzwert für die Gesamtanzahl der virtuellen Computer, die erstellt werden können. Die maximale Anzahl von VMs auf Azure Stack Hub beträgt 700 und 60 pro Skalierungseinheitsknoten. Beispielsweise wäre ein Azure Stack Hub-VM-Grenzwert auf acht Servern 480 (8 * 60). Bei einer Azure Stack Hub-Lösung mit 12 bis 16 Servern läge das Limit bei 700. Dieser Grenzwert wurde mit allen Überlegungen zur Berechnungskapazität erstellt, z. B. die Resilienzreserve und das virtuelle zu physische Verhältnis der CPU, das ein Operator auf dem Stempel beibehalten möchte.

Wenn die Skalierungsgrenze des virtuellen Computers erreicht ist, werden die folgenden Fehlercodes als Ergebnis zurückgegeben: VMsPerScaleUnitLimitExceeded, . VMsPerScaleUnitNodeLimitExceeded

Hinweis

Ein Teil des Maximalwerts von 700 VM ist für VMs der Azure Stack Hub-Infrastruktur reserviert. Weitere Informationen finden Sie im Azure Stack Hub-Kapazitätsplaner.

Überlegungen zur Batchbereitstellung von virtuellen Computern

In Versionen vor und einschließlich 2002 bieten 2-5 VMs pro Batch mit 5 Minuten Abstand zwischen Batches zuverlässige VM-Bereitstellungen, um eine Skalierung von 700 VMs zu erreichen. Mit der 2005-Version von Azure Stack Hub können wir VMs zuverlässig in Batchgrößen von 40 mit 5 Minuten Abstand zwischen Batchbereitstellungen bereitstellen. Start-, Stop-Deallocate- und Updatevorgänge sollten mit einer Batchgröße von 30 durchgeführt werden, wobei 5 Minuten zwischen den einzelnen Batches verbleiben.

Überlegungen für GPU-VMs

Azure Stack hub reserviert Speicher für die Infrastruktur- und Mandanten-VMs, um ein Failover zu ermöglichen. Im Gegensatz zu anderen VMs werden GPU-VMs im Nicht-Hochverfügbarkeitsmodus (HA) ausgeführt und es erfolgt deshalb kein Failover. Daher ist reservierter Arbeitsspeicher für einen Stempel nur für GPU-VMs erforderlich, der von der Infrastruktur für das Failover benötigt wird, im Gegensatz zur Rechnung des VM-Arbeitsspeichers für den Hochverfügbarkeits-Mandanten.

Azure Stack Hub-Arbeitsspeicher

Azure Stack Hub ist so konzipiert, dass VMs ausgeführt werden, die erfolgreich bereitgestellt wurden. Wenn ein Host beispielsweise aufgrund eines Hardwarefehlers offline ist, versucht Azure Stack Hub, diese VM auf einem anderen Host neu zu starten. Im zweiten Beispiel wird das Patchen und Aktualisieren der Azure Stack Hub-Software durchgeführt. Wenn ein physischer Host neu gestartet werden muss, wird versucht, die virtuellen Computer, die auf diesem Host ausgeführt werden, auf einen anderen verfügbaren Host in der Lösung zu verschieben.

Diese VM-Verwaltung oder -bewegung kann nur erreicht werden, wenn reservierte Arbeitsspeicherkapazität vorhanden ist, um den Neustart oder die Migration zu ermöglichen. Ein Teil des gesamten Hostspeichers ist reserviert und für die Platzierung von VMs nicht verfügbar.

Sie können im Administratorportal ein Kreisdiagramm anzeigen, mit dem der freie und belegte Arbeitsspeicher in Azure Stack Hub angezeigt wird. Im folgenden Diagramm ist die Kapazität des physischen Arbeitsspeichers in einer Azure Stack Hub-Skalierungseinheit in Azure Stack Hub dargestellt:

Der verwendete Arbeitsspeicher besteht aus mehreren Komponenten. Die folgenden Komponenten beanspruchen den Arbeitsspeicher, der im entsprechenden Abschnitt des Kreisdiagramms angegeben ist:

• Hostbetriebssystemnutzung und -reserve: Der vom Betriebssystem (OS) auf dem Host verwendete Arbeitsspeicher, virtuelle Speicherseitentabellen, Prozesse, die auf dem Hostbetriebssystem ausgeführt werden, und der Spaces Direct-Speichercache. Dieser Wert kann schwanken, da er von dem Arbeitsspeicher abhängt, der von den verschiedenen, auf dem Host ausgeführten Hyper-V-Prozessen beansprucht wird.
• Infrastrukturdienste: Die Infrastruktur-VMs, aus denen Azure Stack Hub besteht. Wie bereits erwähnt, sind diese virtuellen Computer Teil des Maximalwerts von 700 VM. Wir arbeiten weiter an der Verbesserung der Skalierbarkeit und Resilienz unserer Infrastrukturdienste, weshalb sich die Arbeitsspeicherverwendung dieser Komponente noch ändern kann. Weitere Informationen finden Sie im Azure Stack Hub-Kapazitätsplaner
• Resilienzreserve: Azure Stack Hub reserviert einen Teil des Speichers, um die Mandantenverfügbarkeit während eines einzelnen Hostfehlers sowie während eines Patch- und Updatevorgangs zu ermöglichen, um eine erfolgreiche Livemigration von VMs zu ermöglichen.
• Mandanten-VMs: Die Mandanten-VMs, die von Azure Stack Hub-Benutzern erstellt wurden. Zusätzlich zur Ausführung von VMs wird Arbeitsspeicher von allen virtuellen Computern genutzt, die auf das Fabric gelandet sind. Das bedeutet, dass VMs im Zustand "Erstellen" oder "Fehlgeschlagen" oder VMs, die innerhalb des Gastes heruntergefahren werden, Speicher verbrauchen. VMs, die mit der Option stop deallocated von portal/powershell/cli freigegeben wurden, verbrauchen jedoch keinen Speicher von Azure Stack Hub.
• Wert-Add-Ressourcenanbieter (RPs): Virtuelle Computer, die für die Wert-Add-RPs wie SQL, MySQL, App Service usw. bereitgestellt werden.

Die beste Möglichkeit, den Arbeitsspeicherverbrauch im Portal zu verstehen, ist die Nutzung des Azure Stack Hub Capacity Planner. Hiermit können Sie die Auswirkungen der unterschiedlichen Workloads verfolgen. Die folgende Berechnung wird auch vom Planner verwendet.

Diese Berechnung führt zu dem gesamt verfügbaren Speicher, der für die Platzierung der VM des Mandanten verwendet werden kann. Diese Speicherkapazität gilt für die gesamte Azure Stack Hub-Skalierungseinheit.

Verfügbarer Speicher für die VM-Platzierung = Gesamthostspeicher - Resilienzreserve - Speicher, der von ausgeführten Mandanten-VMs verwendet wird – Azure Stack Hub Infrastructure Overhead ¹

• Gesamter Hostspeicher = Summe des Arbeitsspeichers von allen Knoten
• Resilienzreserve = H + R * ((N-1) * H) + V * (N-2)
• Von Mandanten-VMs verwendete Arbeitsspeicher = Tatsächlicher Speicher, der von der Mandantenarbeitsauslastung verbraucht wird, hängt nicht von der HA-Konfiguration ab.
• Azure Stack Hub Infrastructure Overhead = 268 GB + (4 GB x N)

Ort:

• H = Größe des Einzelnen Serverspeichers
• N = Größe der Skalierungseinheit (Anzahl der Server)
• R = Die Betriebssystemreserve für den Betriebssystemaufwand, der in dieser Formel² 15 ist.
• V = Größter virtueller Hochverfügbarkeits-Computer in der Skalierungseinheit

¹ Azure Stack Hub Infrastructure Overhead = 268 GB + (4 GB x # von Knoten). Ca. 31 VMs werden verwendet, um die Infrastruktur von Azure Stack Hub zu hosten und insgesamt etwa 268 GB + (4 GB x Anzahl von Knoten) des Arbeitsspeichers und 146 virtuelle Kerne verbrauchen. Der Grund für diese Anzahl von VMs besteht darin, die erforderliche Diensttrennung zu erfüllen, um die Sicherheits-, Skalierbarkeits-, Wartungs- und Patchinganforderungen zu erfüllen. Diese interne Dienststruktur ermöglicht die zukünftige Einführung neuer Infrastrukturdienste im Rahmen ihrer Entwicklung.

² Betriebssystemreserve für Overhead = 15% (.15) des Knotenspeichers. Der Wert der Betriebssystemreserve ist eine Schätzung und variiert je nach physischer Speicherkapazität des Servers und allgemeinem Betriebssystemaufwand.

Der Wert V, der größte HA-VM in der Skalierungseinheit, basiert dynamisch auf der größten Größe des VM-Speichers des Mandanten. Der größte HA-VM-Wert ist z. B. mindestens 12 GB (die Infrastruktur-VM) oder 112 GB oder eine andere unterstützte VM-Speichergröße in der Azure Stack Hub-Lösung. Das Ändern der größten HA-VM im Azure Stack Hub Fabric führt zu einer Erhöhung der Resilienzreserve und zur Erhöhung des Arbeitsspeichers der VM selbst. Denken Sie daran, dass GPU-VMs im Nicht-HA-Modus ausgeführt werden.

Beispielberechnung

Wir haben eine kleine Vier-Knoten Azure Stack Hub-Bereitstellung mit 768 GB RAM auf jedem Knoten. Wir planen, einen virtuellen Computer für SQL Server mit 128 GB RAM (Standard_E16_v3) zu platzieren. Was ist der verfügbare Arbeitsspeicher für die Platzierung des virtuellen Computers?

• Gesamtspeicher des Hosts = Summe des Arbeitsspeichers von allen Knoten = 4 * 768 GB = 3072 GB
• Resilienzreserve = H + R * ((N-1) * H) + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768 ) + 128 * (4 - 2) = 1370 GB
• Von Mandanten-VMs verwendete Arbeitsspeicher = Tatsächlicher Speicher, der von der Mandantenarbeitsauslastung verbraucht wird, hängt nicht von der HA-Konfiguration = 0 GB ab.
• Azure Stack Hub Infrastruktur-Overhead = 268 GB + (4GB x N) = 268 + (4 * 4) = 284 GB

Verfügbarer Speicher für die VM-Platzierung = Gesamthostspeicher - Resilienzreserve - Speicher, der von ausgeführten Mandanten-VMs verwendet wird – Azure Stack Hub Infrastructure Overhead

Verfügbarer Speicher für die Platzierung des virtuellen Computers = 3072 - 1370 - 0 - 284 = 1418 GB

Überlegungen zur Aufhebung der Zuweisung

Wenn sich ein virtueller Computer im Zustand "Deallocated " befindet, werden keine Speicherressourcen verwendet. Dadurch können andere VMs im System platziert werden.

Wenn die zugewiesene VM erneut gestartet wird, wird die Speicherauslastung oder -zuordnung wie eine neue VM behandelt, die in das System versetzt wird und der verfügbare Arbeitsspeicher verbraucht wird. Wenn kein Verfügbarer Arbeitsspeicher vorhanden ist, wird der virtuelle Computer nicht gestartet.

Aktuell bereitgestellte große VMs zeigen, dass der zugewiesene Speicher 112 GB beträgt, die Speichernachfrage dieser virtuellen Computer beträgt jedoch etwa 2-3 GB.

Name	Zugewiesener Arbeitsspeicher (GB)	Arbeitsspeicherbedarf (GB)	ComputerName
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508	112	2.2392578125	LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4	112	2.2392578125	LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84	112	2.2392578125	LISSA01P-NODE04

Es gibt drei Möglichkeiten, den Arbeitsspeicher für die VM-Platzierung mithilfe der Resilienzreserve-Formel = H + R * ((N-1) * H) + V * (N-2) freizugeben:

• Verringern der Größe des größten virtuellen Computers
• Erhöhen des Speichers eines Knotens
• Hinzufügen eines Knotens

Verringern der Größe des größten virtuellen Computers

Das Verringern der Größe des größten virtuellen Computers auf den nächstkleineren virtuellen Computer (24 GB) reduziert die Größe der Resilienzreserve.

Resilienzreserve = 384 + 172,8 + 48 = 604,8 GB

Gesamter Speicher	Infra GB	Mieter GB	Resilienzreserve	Reservierter Gesamtspeicher	Zur Platzierung verfügbare gesamte GB
1\.536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~344 GB

Hinzufügen eines Knotens

Durch das Hinzufügen eines Azure Stack Hub-Knotens wird Speicher freigegeben, indem er gleichmäßig zwischen den beiden Knoten aufgeteilt wird.

Resilienzreserve = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 GB

Gesamter Arbeitsspeicher	Infra GB	Mieter in Großbritannien	Resilienzreserve	Reservierter Gesamtspeicher	Zur Platzierung verfügbare gesamte GB
1\.536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~ 344 GB

Erhöhen des Arbeitsspeichers auf jedem Knoten auf 512 GB

Das Erhöhen des Arbeitsspeichers jedes Knotens erhöht den gesamten verfügbaren Arbeitsspeicher.

Resilienzreserve = 512 + 230,4 + 224 = 966,4 GB

Gesamter Arbeitsspeicher	Infra GB	Mieter GB	Resilienzreserve	Reservierter Gesamtspeicher	Zur Platzierung verfügbare gesamte GB
2048 (4*512) GB	258 GB	505,75 GB	966,4 GB	1730.15 GB	~ 318 GB

Häufig gestellte Fragen

F: Mein Mandant hat einen neuen virtuellen Computer bereitgestellt, wie lange dauert es für das Funktionsdiagramm im Administratorportal, die verbleibende Kapazität anzuzeigen?

A: Die Kapazitätsanzeige wird alle 15 Minuten aktualisiert, berücksichtigen Sie dies also.

F: Wie kann ich die verfügbaren Kerne und die zugewiesenen Kerne sehen?

A: Führen Sie in PowerShell den Befehl aus, der eine Ausgabe wie folgt erzeugt: test-azurestack -include AzsVmPlacement -debug

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

F: Die Anzahl der bereitgestellten virtuellen Computer auf meinem Azure Stack Hub hat sich nicht geändert, aber meine Kapazität schwankt. Warum?

A: Der verfügbare Arbeitsspeicher für die Platzierung von virtuellen Computern verfügt über mehrere Abhängigkeiten, von denen eine die Hostbetriebssystem-Reserve ist. Dieser Wert ist abhängig vom arbeitsspeicher, der von den verschiedenen Hyper-V Prozessen verwendet wird, die auf dem Host ausgeführt werden, was kein konstanter Wert ist.

F: In welchem Zustand müssen sich die Mieter-VMs befinden, um Speicher zu verbrauchen?

A: Zusätzlich zur Ausführung von VMs wird Arbeitsspeicher von allen virtuellen Computern verbraucht, die auf die Fabric gelandet sind. Dies bedeutet, dass VMs, die sich im Zustand "Erstellen" oder "Fehlgeschlagen" befinden, Arbeitsspeicher verbrauchen. VMs, die innerhalb des Gastes heruntergefahren werden, verbrauchen ebenfalls Speicher, im Gegensatz zu VMs, die von Portal/Powershell/Cli heruntergefahren werden.

F: Ich habe einen Azure Stack Hub mit vier Hosts. Mein Mandant verfügt über 3 VMs, die jeweils 56 GB RAM (D5_v2) verbrauchen. Nachdem die Größe eines der virtuellen Computer in 112 GB RAM (D14_v2) geändert wurde, wurde beim verfügbaren Arbeitsspeicher auf dem Kapazitätsblatt des Dashboards eine Spitzenauslastung von 168 GB gemeldet. Die anschließende Anpassung der Größe der beiden anderen VMs von D5_v2 zu D14_v2 führte zu einer Zunahme des RAMs von jeweils nur 56 GB. Warum ist das so?

A: Der verfügbare Speicher ist eine Funktion der Resilienzreserve, die von Azure Stack Hub verwaltet wird. Die Resilienzreserve ist eine Funktion der größten VM-Größe im Azure Stack Hub-Bereich. Zu Beginn lag der Arbeitsspeicherwert des größten virtuellen Computers bei 56 GB. Nach Änderung der Größe der VM lag der Arbeitsspeicherwert der größten VM bei 112 GB. Dadurch hat sich nicht nur der von dieser Mandanten-VM beanspruchte Arbeitsspeicher erhöht, sondern auch die Resilienzreserve. Diese Änderung führte zu einer Erhöhung von 56 GB (56 GB auf 112 GB Arbeitsspeicher für Mandanten-VM) + 112 GB Resilienz-Reservespeichererhöhung. Bei der späteren Größenänderung für die anderen virtuellen Computer lag die Größe des größten virtuellen Computers weiterhin bei 112 GB, sodass keine weitere Erhöhung der Resilienzreserve erforderlich war. Der Anstieg des Arbeitsspeicherverbrauchs war lediglich der Anstieg des Arbeitsspeichers der Mieter-VM (56 GB).

Hinweis

Die Kapazitätsplanungsanforderungen für Netzwerke sind minimal, da nur die Größe der öffentlichen VIP konfigurierbar ist. Informationen zum Hinzufügen weiterer öffentlicher IP-Adressen zu Azure Stack Hub finden Sie unter Hinzufügen öffentlicher IP-Adressen.

Nächste Schritte

Informationen zum Azure Stack Hub-Speicher