Bewährte Methoden für große Bereitstellungen von Azure-Knoten mit Microsoft HPC Pack

Ab HPC Pack 2008 R2 mit Service Pack 1 können Windows HPC-Clusteradministratoren und -Entwickler die Leistungsfähigkeit des lokalen Clusters erhöhen, indem sie Rechenressourcen bei Bedarf in Azure hinzufügen. Dieses HPC-Clusterszenario mit Azure-Workerrolleninstanzen ermöglicht größere HPC-Workloads, die manchmal Tausende von Kernen zusätzlich oder anstelle von lokalen Clusterressourcen erfordern. Dieses Thema enthält Empfehlungen zu Anleitungen und bewährten Methoden zur Unterstützung bei der Planung und Implementierung einer großen Bereitstellung von Azure-Knoten aus einem lokalen HPC Pack-Cluster. Diese empfohlenen bewährten Methoden sollten dazu beitragen, das Auftreten von Azure-Bereitstellungstimeouts, Bereitstellungsfehlern und Verlust von Liveinstanzen zu minimieren.

Hinweis

• Zu diesen bewährten Methoden gehören Empfehlungen für die Azure-Umgebung und die Konfiguration des lokalen Head-Knotens. Die meisten Empfehlungen verbessern auch das Verhalten kleinerer Bereitstellungen von Azure-Knoten. Ausnahmen von diesen Richtlinien sind Testbereitstellungen, bei denen die Leistung und Zuverlässigkeit der Head node-Dienste möglicherweise nicht kritisch und sehr kleine Bereitstellungen sind, bei denen die Head node-Dienste nicht stark betont werden.
• Viele der Überlegungen zum Konfigurieren eines lokalen Head-Knotens für eine große Azure-Bereitstellung gelten auch für Cluster, die eine vergleichsweise große Anzahl von lokalen Computeknoten enthalten.
• Diese Empfehlungen ergänzen den Cluster, das Netzwerk und andere Anforderungen, um Azure-Knoten zu einem Windows HPC-Cluster hinzuzufügen. Weitere Informationen finden Sie unter Anforderungen für Azure Nodes.
• Diese allgemeinen Empfehlungen können sich im Laufe der Zeit ändern und müssen möglicherweise für Ihre HPC-Workloads angepasst werden.

Anwendbare Versionen von HPC Pack und Azure SDK für .NET

Diese Empfehlungen basieren im Allgemeinen auf HPC Pack 2012 R2 und HPC Pack 2012, sind aber auch nützlich für große Bereitstellungen, die mit HPC Pack 2008 R2 durchgeführt werden.

In der folgenden Tabelle sind die Versionen von HPC Pack und die zugehörigen Versionen von Azure SDK für .NET aufgeführt, für die diese Richtlinien gelten.

HPC Pack	Azure SDK
HPC Pack 2012 R2	Azure SDK für .NET 2.2
HPC Pack 2012 mit Service Pack 1 (SP1)	Azure SDK für .NET 2.0
HPC Pack 2012	Azure SDK für .NET 1.8
HPC Pack 2008 R2 mit Service Pack 4 (SP4)	Azure SDK für .NET 1.7
HPC Pack 2008 R2 mit Service Pack 3 (SP3)	Azure SDK für .NET 1.6

Schwellenwerte für große Bereitstellungen von Azure-Knoten

Eine Bereitstellung von Azure-Knoten für einen HPC-Cluster gilt als "groß", wenn es erforderlich wird, die Konfiguration des Kopfknotens zu berücksichtigen, und wenn die Bereitstellung einen erheblichen Prozentsatz des Azure-Clusters von Ressourcen erfordert, die von einem einzelnen Clouddienst verwendet werden könnten. Eine größere Bereitstellung riskiert Bereitstellungstimeouts und verliert Liveinstanzen.

Wichtig

Jedem Azure-Abonnement wird ein Kontingent von Kernen und anderen Ressourcen zugewiesen, was sich auch auf ihre Fähigkeit auswirkt, große Anzahl von Azure-Knoten bereitzustellen. Um eine große Anzahl von Azure-Knoten bereitstellen zu können, müssen Sie sich möglicherweise zuerst an den Microsoft-Support wenden, um eine Kernkontingenterhöhung für Ihr Abonnement anzufordern. Beachten Sie, dass ein Kontingent ein Kreditlimit und keine Garantie für die Verfügbarkeit von Ressourcen ist.

In der folgenden Tabelle sind praktische Schwellenwerte für häufig verwendete Rolleninstanzen für eine große Bereitstellung von Azure-Knoten in einem einzelnen Clouddienst aufgeführt. Der Schwellenwert hängt von der Größe des virtuellen Computers (vordefiniert in Azure) ab, die für die Azure-Rolleninstanzen ausgewählt wird.

Rolleninstanzgröße	Anzahl der Rolleninstanzen
A9 (unterstützt ab HPC Pack 2012 R2)	125
A8 (unterstützt ab HPC Pack 2012 R2)	250
A7 (unterstützt ab HPC Pack 2012 mit SP1)	250
A6 (unterstützt ab HPC Pack 2012 mit SP1)	250
Extra groß	250
Kgrösste	500
Mittel	800
KKleinste	1000

Ausführliche Informationen zu jeder Größe des virtuellen Computers, einschließlich der Anzahl der CPU-Kerne und des Arbeitsspeichers für jede Größe, finden Sie unter Größen für Cloud Services.

Um mehr als diese Schwellenwerte für Rolleninstanzen in einem Dienst mit hoher Zuverlässigkeit bereitzustellen, ist in der Regel die manuelle Einbindung des Azure Operations-Teams erforderlich. Um dies zu initiieren, wenden Sie sich an Ihren Microsoft-Vertriebsmitarbeiter, Ihren Microsoft Premier Support-Kontomanager oder den Microsoft-Support. Weitere Informationen zu Supportplänen finden Sie unter Azure-Supportpläne.

Obwohl es kein hartes, erzwingbares Limit gibt, das für alle Azure-Knotenbereitstellungen gilt, ist 1000 Instanzen pro Clouddienst ein praktischer Produktionsgrenzwert.

Bewährte Methoden für die Verwendung von Azure für große Bereitstellungen

Es folgen allgemeine Richtlinien zum erfolgreichen Erstellen und Verwenden großer Azure-Bereitstellungen mit Ihrem HPC-Cluster.

Bereitstellen frühzeitiger Signale für das Azure-Betriebsteam

Sofern Sie keine Vorkehrungen für die Bereitstellung in einem dedizierten Azure-Cluster in einem Rechenzentrum getroffen haben, empfiehlt es sich, dem Azure-Betriebsteam (über einen Microsoft-Supportkanal) eine große Menge an Kapazität vorab mitzuteilen und Bereitstellungen entsprechend zu planen, um die Kapazität als Engpass zu beseitigen. Dies ist auch eine Möglichkeit, zusätzliche Anleitungen zu Bereitstellungsstrategien zu erhalten, die über die in diesem Thema beschriebenen hinausgehen.

Verteilen von Bereitstellungen auf mehrere Clouddienste

Es wird empfohlen, große Bereitstellungen in mehrere kleinere Bereitstellungen aufzuteilen, indem sie mehrere Clouddienste verwenden, aus den folgenden Gründen:

• Um Flexibilität beim Starten und Beenden von Knotengruppen zu ermöglichen.

• Um das Beenden von Leerlaufinstanzen nach Abschluss von Aufträgen zu ermöglichen.

• Um die Suche nach verfügbaren Knoten in den Azure-Clustern zu erleichtern, insbesondere, wenn extra große Instanzen verwendet werden.

• So aktivieren Sie die Verwendung mehrerer Azure-Rechenzentren für Notfallwiederherstellung oder Geschäftskontinuitätsszenarien.

Es gibt keinen festen Grenzwert für die Größe eines Clouddiensts, aber allgemeine Anleitungen sind weniger als 500 bis 700 Instanzen virtueller Computer oder weniger als 1000 Kerne. Größere Bereitstellungen risken Bereitstellungstimeouts, Verlust von Liveinstanzen und Probleme beim Austauschen virtueller IP-Adressen.

Die maximale getestete Anzahl von Clouddiensten für einen einzelnen HPC-Cluster insgesamt beträgt 32.

Hinweis

Möglicherweise treten Einschränkungen in der Anzahl der Clouddienste und Rolleninstanzen auf, die Sie über HPC Pack oder das Azure-Verwaltungsportal verwalten können.

Flexibel mit Standort

Abhängigkeiten von anderen Diensten und anderen geografischen Anforderungen können unvermeidlich sein, aber es kann hilfreich sein, wenn Ihre Azure-Bereitstellung nicht an eine bestimmte Region oder Region gebunden ist. Es wird jedoch nicht empfohlen, mehrere Bereitstellungen in verschiedenen geografischen Regionen zu platzieren, es sei denn, sie verfügen über externe Abhängigkeiten in diesen geografischen Regionen oder es sei denn, Sie verfügen über hohe Verfügbarkeits- und Notfallwiederherstellungsanforderungen.

Seien Sie flexibel mit der Größe des virtuellen Computers

Die strikte Abhängigkeit von einer bestimmten Größe eines virtuellen Computers (z. B. "Extra Large") kann sich auf den Erfolg von Bereitstellungen im großen Maßstab auswirken. Wenn Sie die Flexibilität haben, die Größe virtueller Computer anzupassen oder sogar zu kombinieren, um Instanzenanzahlen und Kerne auszugleichen, kann dies hilfreich sein.

Verwenden mehrerer Azure-Speicherkonten für Knotenbereitstellungen

Es wird empfohlen, verschiedene Azure-Speicherkonten für gleichzeitige große Azure-Knotenbereitstellungen und für benutzerdefinierte Anwendungen zu verwenden. Verwenden Sie für bestimmte Anwendungen, die durch E/A eingeschränkt sind, mehrere Speicherkonten. Darüber hinaus sollte ein Speicherkonto, das für eine Azure-Knotenbereitstellung verwendet wird, nicht für andere Zwecke als die Knotenbereitstellung verwendet werden. Wenn Sie beispielsweise Azure Storage zum Verschieben von Auftrags- und Aufgabendaten in den Kopfknoten oder von den Azure-Knoten verwenden möchten, konfigurieren Sie hierfür ein separates Speicherkonto.

Hinweis

Es entstehen Gebühren für die Gesamtmenge der gespeicherten Daten und für die Speichertransaktionen auf den Azure-Speicherkonten, unabhängig von der Anzahl der Azure-Speicherkonten. Jedes Abonnement beschränkt jedoch die Gesamtanzahl der Speicherkonten. Wenn Sie zusätzliche Speicherkonten in Ihrem Abonnement benötigen, wenden Sie sich an den Azure-Support.

Anpassen der Anzahl der Proxyknoteninstanzen zur Unterstützung der Bereitstellung

Proxyknoten sind Azure-Workerrolleninstanzen, die automatisch jeder Azure-Knotenbereitstellung aus einem HPC-Cluster hinzugefügt werden, um die Kommunikation zwischen lokalen Kopfknoten und den Azure-Knoten zu erleichtern. Die Nachfrage nach Ressourcen auf den Proxyknoten hängt von der Anzahl der in Azure bereitgestellten Knoten und den Aufträgen ab, die auf diesen Knoten ausgeführt werden. In der Regel sollten Sie die Anzahl der Proxyknoten in einer großen Azure-Bereitstellung erhöhen.

Hinweis

• Die Proxyrolleninstanzen verursachen Gebühren in Azure zusammen mit den Azure-Knoteninstanzen.
• Die Proxyrolleninstanzen nutzen Kerne, die dem Abonnement zugeordnet sind, und verringern die Anzahl der Kerne, die für die Bereitstellung von Azure-Knoten verfügbar sind.

HPC Pack 2012 hat HPC-Verwaltungstools eingeführt, mit denen Sie die Anzahl der Proxyknoten in jeder Azure-Knotenbereitstellung (Clouddienst) konfigurieren können. (In HPC Pack 2008 R2 wird die Zahl automatisch auf 2 Proxyknoten pro Bereitstellung festgelegt.) Die Anzahl der Rolleninstanzen für die Proxyknoten kann auch mithilfe der Tools im Azure-Verwaltungsportal nach oben oder unten skaliert werden, ohne Knoten erneut bereitzustellen. Die empfohlene maximale Anzahl von Proxyknoten für eine einzelne Bereitstellung beträgt 10.

Größere oder stark verwendete Bereitstellungen erfordern möglicherweise mehr als die Anzahl der in der folgenden Tabelle aufgeführten Proxyknoten, die auf einer CPU-Auslastung unter 50 Prozent und Bandbreite unter dem Kontingent basieren.

Azure-Knoten pro Clouddienst	Anzahl der Proxyknoten
<100	2
100 - 400	3
400 - 800	4
800 - 1000	5

Weitere Informationen zu Konfigurationsoptionen für Proxyknoten finden Sie unter Festlegen der Anzahl von Azure-Proxyknoten.

Bewährte Methoden zum Konfigurieren des Kopfknotens für große Bereitstellungen

Große Bereitstellungen von Azure-Knoten können erhebliche Anforderungen an den Kopfknoten (oder Die Kopfknoten) eines Clusters stellen. Der Kopfknoten führt mehrere Aufgaben aus, um die Bereitstellung zu unterstützen:

• Greift auf Proxyknoteninstanzen zu, die in einer Azure-Bereitstellung erstellt werden, um die Kommunikation mit den Azure-Knoten zu erleichtern (siehe Anpassen der Anzahl der Proxyknoteninstanzen zur Unterstützung der Bereitstellungin diesem Thema).

• Greift auf Azure-Speicherkonten für Blobs (z. B. Laufzeitpakete), Warteschlangen- und Tabellendaten zu.

• Verwaltet das Taktintervall und die Antworten, die Anzahl der Proxys (beginnend mit HPC Pack 2012), die Anzahl der Bereitstellungen und die Anzahl der Knoten.

Da Azure-Bereitstellungen in Größe und Durchsatz wachsen, erhöht sich der Stress auf den HPC-Clusterkopfknoten. Im Allgemeinen sind die wichtigsten Elemente, die erforderlich sind, um sicherzustellen, dass Ihr Kopfknoten die Bereitstellung unterstützen kann:

• Genügend RAM

• Ausreichender Speicherplatz

• Eine entsprechend große, gut gepflegte SQL Server-Datenbank für die HPC-Clusterdatenbanken

Hardwarespezifikationen für den Kopfknoten

Im Folgenden werden Mindestspezifikationen für einen Kopfknoten zur Unterstützung einer großen Azure-Bereitstellung vorgeschlagen:

• 8 CPU-Kerne

• 2 Datenträger

• 16 GB RAM

Konfigurieren von SQL Server-Remotedatenbanken

Für große Bereitstellungen wird empfohlen, die Clusterdatenbanken auf einem Remoteserver zu installieren, auf dem Microsoft SQL Server ausgeführt wird, anstatt die Clusterdatenbanken auf dem Kopfknoten zu installieren. Allgemeine Richtlinien zum Auswählen und Konfigurieren einer Edition von SQL Server für den Cluster finden Sie unter Datenbankkapazitätsplanung und Optimierung für Microsoft HPC Pack.

Konfigurieren Sie den Kopfknoten nicht für zusätzliche Clusterrollen.

Als allgemeine bewährte Methode für die meisten Produktionsbereitstellungen empfehlen wir, dass Head-Knoten nicht mit einer zusätzlichen Clusterrolle (Computeknotenrolle oder WCF-Brokerknotenrolle) konfiguriert sind. Wenn der Kopfknoten mehreren Zwecken dient, kann dies verhindern, dass er seine primäre Verwaltungsrolle erfolgreich ausführt. Um die vom Kopfknoten ausgeführten Rollen zu ändern, führen Sie zuerst den Knoten offline, indem Sie die Aktion in Ressourcenverwaltungs- (in einigen Versionen von HPC Pack als Knotenverwaltung bezeichnet) im HPC Cluster Manager verwenden. Klicken Sie dann mit der rechten Maustaste auf den Kopfknoten, und klicken Sie auf Rolle ändern.

Darüber hinaus sorgt das Verschieben des Clusterspeichers aus dem Kopfknoten dafür, dass der Kopfknoten nicht mehr Platz hat und effektiv funktioniert.

Verwenden der HPC-Client-Dienstprogramme, um remote eine Verbindung mit dem Kopfknoten herzustellen

Wenn der Kopfknoten unter einer hohen Last arbeitet, kann die Leistung negativ beeinträchtigt werden, indem viele Benutzer mit Remotedesktopverbindungen verbunden sind. Anstatt benutzer über Remotedesktopdienste (RDS) eine Verbindung mit dem Kopfknoten herzustellen, sollten Benutzer und Administratoren die HPC Pack Client Utilities auf ihren Arbeitsstationen installieren und mithilfe dieser Remotetools auf den Cluster zugreifen.

Deaktivieren der Leistungsindikatorauflistung und Ereignisweiterleitung

Bei großen Bereitstellungen kann die Leistungsindikatorauflistung und die Ereignisweiterleitung einen großen Aufwand für den HPC-Verwaltungsdienst und SQL Server verursachen. Für diese Bereitstellungen kann es wünschenswert sein, diese Funktionen mithilfe der HPC-Clusterverwaltungstools zu deaktivieren. Legen Sie beispielsweise die CollectCounters- Clustereigenschaft auf "false" fest, indem Sie das cmdlet Set-HpcClusterProperty HPC PowerShell verwenden. Es kann ein Kompromiss zwischen verbesserter Leistung und Sammeln von Metriken geben, die Ihnen dabei helfen können, Probleme zu beheben, die auftreten.

Nicht benötigte Kopfknotendienste deaktivieren

Um einen minimalen Hardwarebedarf vom Betriebssystem und als allgemeine bewährte Methode für HPC-Cluster sicherzustellen, deaktivieren Sie alle Betriebssystemdienste, die für den Betrieb des HPC-Clusters nicht erforderlich sind. Wir empfehlen insbesondere, alle desktoporientierten Features zu deaktivieren, die möglicherweise aktiviert wurden.

Nat nicht auf dem Kopfknoten ausführen

Obwohl HPC Pack eine schnelle Konfiguration des Routing- und Remotezugriffsdiensts (RRAS) ermöglicht, der auf dem Kopfknoten ausgeführt wird, um die Netzwerkadressenübersetzung (NETWORK Address Translation, NAT) bereitzustellen und Rechenknoten das Erreichen des Unternehmensnetzwerks zu ermöglichen, kann dies dazu führen, dass der Kopfknoten zu einem erheblichen Engpass für die Netzwerkbandbreite wird und sich auch auf die Leistung auswirken kann. Als allgemeine bewährte Methode für größere Bereitstellungen oder Bereitstellungen mit erheblichem Datenverkehr zwischen Computeknoten und dem öffentlichen Netzwerk empfehlen wir eine der folgenden Alternativen:

• Stellen Sie eine direkte öffentliche Netzwerkverbindung zu jedem Computeknoten bereit.

• Stellen Sie einen dedizierten NAT-Router bereit, z. B. einen separaten Server, auf dem ein Windows Server-Betriebssystem ausgeführt wird und auf den beiden Netzwerken dual verwaltet wird und RRAS ausgeführt wird.

Sicherstellen eines angemessenen Speicherzeitraums für abgeschlossene Aufträge

Die TtlCompletedJobs Eigenschaft des Befehls cluscfg und die Set-HpcClusterProperty HPC-Cmdlet steuern, wie lange abgeschlossene Aufträge in der SQL Server-Datenbank für den HPC-Cluster verbleiben. Das Festlegen eines großen Werts für diese Eigenschaft stellt sicher, dass Auftragsinformationen für längere Zeit im System verwaltet werden, was für Berichtszwecke wünschenswert sein kann. Eine große Anzahl von Aufträgen im System erhöht jedoch die Speicher- und Speicheranforderungen des Systems, da die Datenbank (und Abfragen dafür) im Allgemeinen größer ist.

Konfigurieren einer angemessenen Anzahl verpasster Takte, bevor Knoten nicht erreichbar sind

HPC Pack verwendet ein Taktsignal, um die Verfügbarkeit von Knoten zu überprüfen. Die fehlende Antwort eines Computeknotens auf diese regelmäßige Integritätssonde durch den HPC-Auftragsplanungsdienst bestimmt, ob der Knoten als nicht erreichbar markiert wird. Durch Konfigurieren von Taktoptionen in der Auftragsplanungskonfiguration im HPC Cluster-Manager oder mithilfe des befehls cluscfg oder des Set-HpcClusterProperty HPC-Cmdlets kann der Clusteradministrator die Häufigkeit der Takte (HeartbeatInterval) und die Anzahl der Takte festlegen, die ein Knoten verpassen kann (InactivityCount), bevor er als nicht erreichbar markiert wird. Beispielsweise kann die standardeinstellung HeartbeatInterval- von 30 Sekunden auf 2 Minuten erhöht werden, wenn der Cluster eine große Azure-Bereitstellung enthält. Die Standardeinstellung InactivityCount- ist auf 3 festgelegt, das für einige lokale Bereitstellungen geeignet ist, es sollte jedoch auf 10 oder mehr erhöht werden, wenn Azure-Knoten bereitgestellt werden.

Hinweis

Ab HPC Pack 2012 mit SP1 wird die Anzahl der verpassten Takte separat für lokale Knoten und Azure-Knoten konfiguriert. Die InactivityCountAzure Clustereigenschaft konfiguriert die Anzahl der verpassten Takte, nach denen Arbeitsknoten, die in Azure bereitgestellt werden, vom Cluster als nicht erreichbar angesehen werden. Der Standardwert von InactivityCountAzure ist auf 10 festgelegt. Ab HPC Pack 2012 mit SP1 gilt die InactivityCount-Eigenschaft ausschließlich für lokale Knoten.

Wenn der Hauptknoten oder WCF-Brokerknoten für hohe Verfügbarkeit in einem Failovercluster konfiguriert sind, sollten Sie auch das Taktsignal berücksichtigen, das von jedem Failoverclustercomputer verwendet wird, um die Verfügbarkeit des anderen Computers (oder Computers) im Failovercluster zu überwachen. Wenn ein Computer fünf Takte verpasst, gilt die Kommunikation mit diesem Computer standardmäßig einmal pro Sekunde als fehlgeschlagen. Sie können den Failovercluster-Manager verwenden, um die Häufigkeit von Takten zu verringern oder die Anzahl der verpassten Takte in einem Cluster mit einer großen Azure-Bereitstellung zu erhöhen.

Wenn Sie dienstorientierte Architekturaufträge (SOA) auf den Azure-Knoten ausführen, müssen Sie möglicherweise die Überwachungstimeouteinstellungen in der Dienstregistrierungsdatei anpassen, um große Sitzungen zu verwalten. Weitere Informationen zur SOA-Dienstkonfigurationsdatei finden Sie unter SOA-Dienstkonfigurationsdateien in Windows HPC Server 2008 R2.

Konfigurieren eines Registrierungsschlüssels zur Verbesserung der Leistung von Datei-Stagingvorgängen

Ab HPC Pack 2008 R2 mit SP2 können Sie einen Registrierungsschlüssel auf dem Kopfknotencomputer festlegen, um die Leistung von Diagnosetests zu verbessern, clusrun--Vorgänge und das hpcfile Hilfsprogramm für große Bereitstellungen von Azure-Knoten zu verbessern. Fügen Sie dazu einen neuen DWORD-Wert namens FileStagingMaxConcurrentCalls- in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPChinzu. Es wird empfohlen, einen Wert zwischen 50% und 100% der Anzahl der Azure-Knoten zu konfigurieren, die Sie bereitstellen möchten. Um die Konfiguration abzuschließen, müssen Sie nach dem Festlegen des FileStagingMaxConcurrentCalls Wert den HPC-Auftragsplanungsdienst beenden und dann neu starten.

Vorsicht

Die fehlerhafte Bearbeitung der Registrierung kann Ihr System erheblich beschädigen. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie alle wertigen Daten auf dem Computer sichern.

Siehe auch

Burst to Azure Worker Instances mit Microsoft HPC Pack
bewährte Methoden für den Entwurf von Large-Scale Services in Azure Cloud Services
technische Anleitungen für Windows Azure Business Continuity