Azure Stack Hub-Computekapazität

Die für Azure Stack Hub unterstützten VM-Größen (virtuelle Computer) stellen eine Teilmenge der in Azure unterstützten VM-Größen dar. Azure erzwingt Ressourcengrenzwerte auf verschiedene Arten, um einen übermäßigen Ressourcenverbrauch (auf dem lokalen Server und auf der Dienstebene) zu vermeiden. Wenn keine Einschränkungen für die Nutzung durch Mandanten gelten würden, würde die Mandantenerfahrung beeinträchtigt, wenn andere Mandanten Ressourcen übermäßig nutzen. Für ausgehenden Netzwerkdatenverkehr des virtuellen Computers gelten Bandbreitenobergrenzen für Azure Stack Hub, die mit den Azure-Einschränkungen übereinstimmen. 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.

Wichtig

Mit dem Azure Stack Hub Capacity Planner wird die IOPS-Leistung nicht berücksichtigt oder garantiert. Im Administratorportal wird eine Warnung angezeigt, wenn die gesamte Arbeitsspeichernutzung des Systems 85 % erreicht hat. Diese Warnung kann behoben werden, indem zusätzliche Kapazität hinzugefügt wird oder die nicht mehr benötigten virtuellen Computer entfernt werden.

VM-Platzierung

Die Azure Stack Hub-Platzierungsengine verteilt Mandanten-VMs auf die verfügbaren Hosts.

Bei der Platzierung virtueller Computer werden von Azure Stack Hub zwei Aspekte berücksichtigt. Erstens: Steht auf dem Host genügend Arbeitsspeicher für den VM-Typ zur Verfügung? Zweitens: Gehören die VMs zu einer Verfügbarkeitsgruppe, oder handelt es sich bei Ihnen um VM-Skalierungsgruppen?

Zur Erreichung von Hochverfügbarkeit für eine Produktionsworkload mit mehreren virtuellen Computern (VMs) in Azure Stack Hub werden die VMs in einer Verfügbarkeitsgruppe platziert, um sie auf mehrere Fehlerdomänen zu verteilen. 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. In einer Verfügbarkeitsgruppe angeordnete VMs werden physisch voneinander isoliert, indem sie so gleichmäßig wie möglich auf mehrere Fehlerdomänen (Azure Stack Hub-Knoten) verteilt werden. Bei einem Hardwarefehler werden VMs aus der fehlerhaften Fehlerdomäne in anderen Fehlerdomänen neu gestartet. Sie werden nach Möglichkeit getrennt von den anderen VMs in separaten Fehlerdomänen in derselben Verfügbarkeitsgruppe gespeichert. Nachdem der Host wieder in den Onlinezustand versetzt wurde, wird für die VMs ein neuer Ausgleichsvorgang durchgeführt, um die Hochverfügbarkeit sicherzustellen.

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. Bei einem Azure Stack Hub-System mit vier Knoten kann es beispielsweise zu einer Situation kommen, in der für eine VM-Skalierungsgruppe mit drei Instanzen bei der Erstellung ein Fehler auftritt, weil bei einer Kapazität von vier Knoten nicht drei VM-Skalierungsgruppeninstanzen auf drei separaten Azure Stack Hub-Knoten platziert werden können. Außerdem können Azure Stack Hub-Knoten vor der Durchführung der Platzierung auf verschiedenen Ebenen gefüllt werden.

In Azure Stack Hub wird nicht mehr Arbeitsspeicher als nötig zugewiesen. Bei der Anzahl von physischen Kernen ist dies aber zulässig.

Da Platzierungsalgorithmen das vorhandene Verhältnis der Überbereitstellung von virtuellen Kernen im Vergleich zu physischen Kernen nicht als Faktor berücksichtigen, kann jeder Host ein anderes Verhältnis aufweisen. Microsoft gibt aufgrund der unterschiedlichen Anforderungen in Bezug auf Workloads und Servicelevel keine Empfehlung zum Verhältnis von physischen und virtuellen Kernen ab.

Überlegung zur Gesamtanzahl von VMs

Die Gesamtzahl der VMs, die erstellt werden kann, ist begrenzt. Die Höchstzahl der VMs in Azure Stack Hub beträgt 700 und 60 pro Skalierungseinheitsknoten. Beispielsweise wäre ein Azure Stack Hub-VM-Limit bei 480 Servern 8 (8 * 60). Bei einer Azure Stack Hub-Lösung mit 12 bis 16 Servern läge das Limit bei 700. Dieses Limit wurde unter Berücksichtigung aller Überlegungen hinsichtlich der Computekapazität eingerichtet, z. B. der Resilienzreserve und des CPU-Verhältnisses zwischen virtuell und physisch, die ein Operator bei dem Stamp beibehalten möchte.

Falls das VM-Skalierungslimit erreicht wird, werden die folgenden Fehlercodes als Ergebnis zurückgegeben: VMsPerScaleUnitLimitExceeded und VMsPerScaleUnitNodeLimitExceeded.

Hinweis

Ein Teil der maximal 700 VMs ist für virtuelle Computer der Azure Stack Hub-Infrastruktur reserviert. Weitere Informationen finden Sie im Azure Stack Hub-Kapazitätsplaner.

Überlegungen zur Batchbereitstellung virtueller Computer

In Releases bis einschließlich 2002 konnten mit zwei bis fünf virtuellen Computern pro Batch und einer fünfminütigen Pause zwischen Batches bis zu 700 virtuelle Computer zuverlässig bereitgestellt werden. Ab Azure Stack Hub-Version 2005 können virtuelle Computer zuverlässig in Batches mit bis zu 40 virtuellen Computern und einer fünfminütigen Pause zwischen Batchbereitstellungen bereitgestellt werden. Vorgänge zum Starten, Beenden der Aufhebung der Zuordnung und Aktualisieren sollten mit einer Batchgröße von 30 durchgeführt werden, wobei zwischen den einzelnen Batches 5 Minuten liegen sollten.

Überlegungen zu GPU-VMs

Azure Stack Hub reserviert Arbeitsspeicher für die Infrastruktur- und Mandanten-VMs für das Failover. Im Gegensatz zu anderen VMs werden GPU-VMs in einem Modus ohne Hochverfügbarkeit ausgeführt und führen daher kein Failover durch. 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 erfolgreich bereitgestellte VMs weiter ausgeführt werden. Wenn ein Host beispielsweise aufgrund eines Hardwarefehlers offline ist, versucht Azure Stack Hub, die VM auf einem anderen Host neu zu starten. Im zweiten Beispiel wird das Patchen und Aktualisieren der Azure Stack Hub-Software durchgeführt. Falls ein physischer Host neu gestartet werden muss, wird versucht, die auf diesem Host ausgeführten VMs auf einen anderen verfügbaren Host der Lösung zu verschieben.

Diese VM-Verwaltung oder -Verschiebung kann nur erreicht werden, wenn reservierte Speicherkapazität vorhanden ist, damit der Neustart bzw. die Migration durchgeführt werden kann. Ein Teil des gesamten Hostarbeitsspeichers ist reserviert und steht nicht für die Platzierung von virtuellen Mandantencomputern zur Verfügung.

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:

• Nutzung des Hostbetriebssystems bzw. Reserve: Dies ist der Arbeitsspeicher, der vom Betriebssystem auf dem Host, von Auslagerungstabellen des virtuellen Arbeitsspeichers, unter dem Hostbetriebssystem ausgeführten Prozessen und dem Arbeitsspeichercache von „Direkte Speicherplätze“ genutzt wird. 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: Dies sind die Infrastruktur-VMs, aus denen Azure Stack Hub besteht. Wie bereits erwähnt, sind diese virtuellen Computer Teil des Höchstwerts von 700 VMs. 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 Arbeitsspeichers, um die Mandantenverfügbarkeit während des Ausfalls eines einzelnen Hosts und beim Patchen und Aktualisieren sicherzustellen und so die erfolgreiche Livemigration von VMs zu ermöglichen.
• Mandanten-VMs: Dies sind die virtuellen Mandanten-VMs, die von Azure Stack Hub-Benutzern erstellt werden. Zusätzlich zur Ausführung von VMs wird Arbeitsspeicher von allen VMs verbraucht, die im Fabric angeordnet sind. Das bedeutet, dass virtuelle Computer mit dem Zustand „Wird erstellt“ oder „Fehler“ sowie virtuelle Computer, die über den Gast heruntergefahren werden, Arbeitsspeicher beanspruchen. VMs, deren Zuordnung mithilfe der entsprechenden Option über das Portal/mit PowerShell/über die Befehlszeilenschnittstelle aufgehoben wurde, beanspruchen allerdings keinen Arbeitsspeicher von Azure Stack Hub mehr.
• Ressourcenanbieter (RPs), die Mehrwert schaffen: Dies sind VMs, die für die Ressourcenanbieter bereitgestellt wurden, die Mehrwert schaffen (etwa SQL, MySQL, App Service usw).

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 ergibt den insgesamt verfügbaren Arbeitsspeicher, der für die Platzierung von virtuellen Mandantencomputern verwendet werden kann. Diese Speicherkapazität gilt für die gesamte Azure Stack Hub-Skalierungseinheit.

Verfügbarer Speicher für VM-Platzierung = Hostspeicher gesamt - Resilienzreserve - von ausgeführten Mandanten-VMs verwendeter Arbeitsspeicher - Azure Stack Hub-Infrastrukturmehraufwand ¹

• Gesamter Arbeitsspeicher des Hosts = Summe des Arbeitsspeichers aller Knoten
• Resilienzreserve = H + R * ((N-1) * H) + V * (N-2)
• Von Mandanten-VMs genutzter Arbeitsspeicher = Tatsächlich von der Workload des Mandanten beanspruchter Arbeitsspeicher ohne Anhängigkeit von der Konfiguration von Hochverfügbarkeit
• Azure Stack Hub-Infrastrukturmehraufwand = 268 GB + (4 GB × N)

Hierbei gilt:

• H = Größe des einzelnen Serverspeichers
• N = Größe der Skalierungseinheit (Anzahl der Server)
• R = Betriebssystemreserve für Mehraufwand des Betriebssystems (in dieser Formel 0,15)²
• V = Größter virtueller Hochverfügbarkeits-Computer in der Skalierungseinheit

¹ Azure Stack Hub-Infrastrukturmehraufwand = 268 GB + (4 GB * Anzahl von Knoten). Rund 31 virtuelle Computer werden für das Hosting der Infrastruktur von Azure Stack Hub verwendet und nutzen insgesamt etwa Speicher in Höhe von 268 GB + (4 GB x Anzahl von Knoten) und 146 virtuelle Kerne. Der Grund für diese Anzahl von VMs besteht darin, die erforderliche Diensttrennung zu erfüllen, um die Anforderungen an Sicherheit, Skalierbarkeit, Wartung und Patches zu gewährleisten. Diese interne Dienststruktur ermöglicht die zukünftige Einführung neuer Infrastrukturdienste im Rahmen ihrer Entwicklung.

² Betriebssystemreserve für Mehraufwand = 15 % (0,15) des Knotenspeichers. Der Wert der Betriebssystemreserve ist eine Schätzung und variiert je nach der physischen Speicherkapazität des Servers und dem allgemeinen Betriebssystemmehraufwand.

Der Wert V (größter virtueller Hochverfügbarkeits-Computer in der Skalierungseinheit) basiert dynamisch auf der VM-Speichergröße des größten Mandanten. Der größte Wert für virtuelle Computer mit Hochverfügbarkeit beträgt beispielsweise mindestens 12 GB (für die Infrastruktur-VM) oder 112 GB bzw. eine beliebige andere unterstützte VM-Arbeitsspeichergröße in der Azure Stack Hub-Lösung. Wenn die größte Hochverfügbarkeits-VM im Azure Stack Hub-Fabric geändert wird, führt dies zu einer Erhöhung der Resilienzreserve und auch zu einer Erhöhung des Arbeitsspeichers der VM selbst. Beachten Sie, dass GPU-VMs im Modus ohne Hochverfügbarkeit ausgeführt werden.

Beispielberechnung

Wir haben eine kleine Azure Stack Hub-Bereitstellung mit vier Knoten und 768 GB RAM auf jedem Knoten. Wir planen, eine VM für SQL Server mit 128 GB RAM (Standard_E16_v3) zu platzieren. Wie viel Arbeitsspeicher steht für die VM-Platzierung zur Verfügung?

• Gesamter Arbeitsspeicher des Hosts = Summe des Arbeitsspeichers aller Knoten = 4 x 768 GB = 3.072 GB
• Resilienzreserve = H + R x ((N-1) x H) + V x (N-2) = 768 + 0,15 x ((4 - 1) x 768) + 128 x (4 - 2) = 1.370 GB
• Von Mandanten-VMs genutzter Arbeitsspeicher = Tatsächlich von der Workload des Mandanten beanspruchter Arbeitsspeicher ohne Anhängigkeit von der Konfiguration von Hochverfügbarkeit 0 0 GB
• Azure Stack Hub-Infrastrukturmehraufwand = 268 GB + (4 GB × N) = 268 + (4 x 4) = 284 GB

Verfügbarer Speicher für VM-Platzierung = Hostspeicher gesamt - Resilienzreserve - von ausgeführten Mandanten-VMs verwendeter Arbeitsspeicher - Azure Stack Hub-Infrastrukturmehraufwand

Verfügbarer Arbeitsspeicher für die VM-Platzierung = 3072 - 1370 - 0 - 284 = 1.418 GB

Überlegungen zur Aufhebung der Zuweisung

Wenn sich eine VM im Status Zuweisung aufgehoben befindet, werden keine Speicherressourcen verwendet. Dadurch können andere VMs im System platziert werden.

Wenn die nicht zugewiesene VM dann noch mal gestartet wird, erfolgt die Speicherauslastung oder -belegung wie beim Platzieren einer neuen VM im System, und der verfügbare Speicherplatz wird verbraucht. Wenn kein Speicherplatz verfügbar ist, wird die VM nicht gestartet.

Die derzeit bereitgestellten großen VMs zeigen, dass der zugeordnete Speicher 112 GB beträgt, aber der Speicherbedarf dieser VMs liegt bei 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, Arbeitsspeicher für die VM-Platzierung mit der Formel Resilienzreserve = H + R * ((N-1) * H) + V * (N-2) freizugeben:

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

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

Die Verringerung der Größe der größten VM auf die nächstkleinere VM in der Skalierungseinheit (24 GB) verringert die Größe der Resilienzreserve.

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

Gesamter Speicher	GB für Infrastruktur	GB für Mandant	Resilienzreserve	Reservierter Gesamtarbeitsspeicher	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 Hinzufügen eines Azure Stack Hub-Knotens wird Arbeitsspeicher freigegeben, indem der Arbeitsspeicher gleichmäßig auf die beiden Knoten verteilt wird.

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

Gesamter Speicher	GB für Infrastruktur	GB für Mandant	Resilienzreserve	Reservierter Gesamtarbeitsspeicher	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

Durch die Vergrößerung des Arbeitsspeichers jedes Knotens wird der gesamte verfügbare Speicher erhöht.

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

Gesamter Speicher	GB für Infrastruktur	GB für Mandant	Resilienzreserve	Reservierter Gesamtarbeitsspeicher	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: Von meinem Mandanten wurde eine neue VM bereitgestellt. Wie lange dauert es, bis die verbleibende Kapazität im Funktionsdiagramm des Administratorportals angezeigt wird?

A: Das Kapazitätsblatt wird alle 15 Minuten aktualisiert.

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

A: Führen Sie in PowerShell- den Befehl test-azurestack -include AzsVmPlacement -debug aus, wodurch eine Ausgabe wie die folgende generiert wird:

    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: Meine Kapazität schwankt, obwohl sich die Anzahl bereitgestellter VMs in meiner Azure Stack Hub-Instanz nicht geändert hat. Warum?

A: Der verfügbare Arbeitsspeicher für die VM-Platzierung ist von verschiedenen Faktoren abhängig – unter anderem von der Reserve des Hostbetriebssystems. Der Wert hängt davon ab, wie viel Arbeitsspeicher von den verschiedenen auf dem Host ausgeführten Hyper-V-Prozessen beansprucht wird, was kein konstanter Wert ist.

F: In welchem Zustand müssen sich Mandanten-VMs befinden, damit sie Arbeitsspeicher beanspruchen?

A: Zusätzlich zur Ausführung von VMs wird Arbeitsspeicher von allen VMs verbraucht, die im Fabric angeordnet sind. Dies bedeutet, dass VMs mit dem Zustand „Wird erstellt“ oder „Fehler“ Arbeitsspeicher beanspruchen. VMs, die über den Gast heruntergefahren werden, beanspruchen im Gegensatz zu virtuellen Computern, deren Zuordnung mithilfe der entsprechenden Option über das Portal/mit PowerShell/über die Befehlszeilenschnittstelle aufgehoben wurde, ebenfalls Arbeitsspeicher.

F: Ich verfüge über eine Azure Stack Hub-Instanz mit vier Hosts. Mein Mandant umfasst drei VMs, die jeweils 56 GB RAM (D5_v2) beanspruchen. 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. Bei der späteren Änderung der Größe der anderen beiden VMs von „D5_v2“ in „D14_v2“ wurde dagegen nur ein RAM-Zuwachs von jeweils 56 GB verzeichnet. Woran liegt das?

A: Der verfügbare Arbeitsspeicher ist eine Funktion der von Azure Stack Hub verwalteten Resilienzreserve. 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 einem Anstieg von 56 GB (Arbeitsspeichererhöhung um 56 GB auf 112 GB für die Mandanten-VM) plus 112 GB Arbeitsspeichererhöhung für die Resilienzreserve. 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. Somit entsprach der Anstieg bei der Arbeitsspeichernutzung lediglich der Arbeitsspeichererhöhung für die Mandanten-VM (56 GB).

Hinweis

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

Nächste Schritte

Weitere Informationen zu Azure Stack Hub-Speicher