Freigeben über

Zuverlässigkeit in Azure Batch

  • Artikel

In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure Batch beschrieben, wobei sowohl intraregionale Resilienz mittels Verfügbarkeitszonen als auch Links zu Informationen zur regionsübergreifenden Wiederherstellung und Geschäftskontinuität behandelt wird.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Weitere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Was sind Verfügbarkeitszonen?.

Batch bietet die gleiche Unterstützung von Verfügbarkeitszonen wie Azure.

Voraussetzungen

  • Vergewissern Sie sich bei Batch-Konten im Modus „Benutzerabonnement“, dass für das Abonnement, in dem Sie Ihren Pool erstellen, keine Zonenangebotseinschränkung für die angeforderte VM-SKU gilt. Um festzustellen, ob Ihr Abonnement keine Einschränkungen aufweist, rufen Sie die API zum Auflisten von Ressourcen-SKUs auf, und überprüfen Sie die ResourceSkuRestrictions. Ist eine Zoneneinschränkung vorhanden, können Sie ein Supportticket erstellen, um die Zoneneinschränkung zu entfernen.

  • Da InfiniBand keine Kommunikation zwischen den Zonen unterstützt, können Sie keinen Pool mit einer zonalen Richtlinie erstellen, wenn die Kommunikation zwischen Knoten aktiviert ist und eine VM-SKU mit InfiniBand-Unterstützung verwendet wird.

  • Batch bietet die gleiche Unterstützung von Verfügbarkeitszonen wie Azure. Um die zonenbasierte Option verwenden zu können, muss Ihr Pool in einer Azure-Region mit Verfügbarkeitszonenunterstützung erstellt werden.

  • Damit Ihr Batch-Pool verfügbarkeitszonenübergreifend zugeordnet wird, muss die Azure-Region, in der der Pool erstellt wird, die angeforderte VM-SKU in mehreren Zonen unterstützen. Um zu überprüfen, ob die Region die angeforderte VM-SKU in mehr als einer Zone unterstützt, rufen Sie die API zum Auflisten von Ressourcen-SKUs auf, und überprüfen Sie das Feld locationInfo von resourceSku. Achten Sie darauf, dass für die angeforderte VM-SKU mehrere Zonen unterstützt werden. Sie können auch die Azure CLI verwenden, um alle verfügbaren Ressourcen-SKUs mit dem folgenden Befehl aufzulisten:

    
    az vm list-skus

Verfügbarkeitszonenübergreifendes Erstellen eines Azure Batch-Pools

Beispiele zum Erstellen eines Batch-Pools über Verfügbarkeitszonen hinweg finden Sie unter Erstellen eines Azure Batch-Pools über Verfügbarkeitszonen hinweg.

Weitere Informationen zum Erstellen von Batch-Konten mit dem Azure-Portal, der Azure-Befehlszeilenschnittstelle, PowerShell oder der Batch-Verwaltungs-API.

Zonenausfall

Während eines Zonenausfalls sind die Knoten innerhalb dieser Zone nicht mehr verfügbar. Knoten innerhalb desselben Knotenpools aus anderen Zonen sind nicht betroffen und weiterhin verfügbar.

Dass Azure Batch-Konto weist keine neuen Knoten zu und erstellt keine neuen Knoten, um Knoten zu kompensieren, die aufgrund des Ausfalls ausgefallen sind. Benutzer müssen dem Knotenpool weitere Knoten hinzufügen, die dann aus anderen fehlerfreien Zonen zugeordnet werden.

Fehlertoleranz

Um sich auf ausfallende Verfügbarkeitszonen vorzubereiten, sollten Sie die Kapazität des Diensts überdimensionieren, um sicherzustellen, dass die Lösung einen 1/3-Kapazitätsverlust tolerieren kann und weiterhin ohne Leistungseinbußen bei zonenweiten Ausfällen funktioniert. Da die Plattform VMs auf drei Zonen verteilt und Sie mindestens den Ausfall einer Zone abfangen können müssen, multiplizieren Sie die Instanzenanzahl des Spitzenworkloads mit dem Faktor „Zonen/(Zonen-1)“ oder „3/2“. Wenn Ihre typische Spitzenworkload beispielsweise vier Instanzen erfordert, sollten Sie sechs Instanzen bereitstellen: (2/3 * 6 Instanzen) = 4 Instanzen.

Migration der Verfügbarkeitszone

Sie können einen vorhandenen Batch-Pool nicht zur Verfügbarkeitszonenunterstützung migrieren. Wenn Sie Ihren Batch-Pool über Verfügbarkeitszonen hinweg neu erstellen möchten, lesen Sie Erstellen eines Azure Batch-Pools über Verfügbarkeitszonen hinweg.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Azure Batch ist in allen Azure-Regionen verfügbar. Wenn aber ein Batch-Konto erstellt wird, muss es einer spezifischen Region zugeordnet werden. Alle nachfolgenden Vorgänge für dieses Batch-Konto gelten nur für diese Region. Beispielsweise werden Pools und die zugehörigen virtuellen Computer (VMs) in der gleichen Region wie das Batch-Konto erstellt.

Beim Entwerfen einer Anwendung, die Batch verwendet, müssen Sie die Möglichkeit in Betracht ziehen, dass Batch in einer Region nicht verfügbar ist. In seltenen Fällen liegt ein Problem mit der Region als Ganzes, dem gesamten Batch-Dienst in der Region oder mit Ihrem spezifischen Batch-Konto vor.

Wenn die Batch verwendende Anwendung oder Lösung immer verfügbar sein muss, dann sollte sie entweder für ein Failover zu einer anderen Region konzipiert sein, oder der Workload sollte stets auf zwei oder mehr Regionen aufgeteilt sein. Beide Ansätze erfordern mindestens zwei Batch-Konten, und jedes Konto muss sich in einer anderen Region befinden.

Sie sind für die Einrichtung einer regionsübergreifender Notfallwiederherstellung mit Azure Batch verantwortlich. Wenn Sie mehrere Batch-Konten in bestimmten Regionen ausführen und Verfügbarkeitszonen nutzen, kann Ihre Anwendung Ihre Notfallwiederherstellungsziele erfüllen, wenn eines Ihrer Batch-Konten nicht mehr verfügbar ist.

Bei der Bereitstellung einer Option für ein Failover auf eine alternative Region müssen alle Komponenten der Lösung berücksichtigt werden. Es reicht nicht aus, lediglich ein zweites Batch-Konto einzurichten. Beispielsweise ist in den meisten Batch-Anwendungen ein Azure-Speicherkonto erforderlich. Das Speicherkonto und das Batch-Konto müssen sich in derselben Region befinden, um eine akzeptable Leistung zu erzielen.

Beim Entwerfen einer Failoverlösung sollten Sie folgende Punkte berücksichtigen:

  • Erstellen Sie vorab alle erforderlichen Dienste in jeder Region, z. B. das Azure Batch-Konto und das Speicherkonto. Für das Erstellen von Konten fallen oft keine Gebühren an. Es fallen lediglich Gebühren an, wenn das Konto verwendet wird oder Daten gespeichert werden.

  • Stellen Sie im Voraus sicher, dass die entsprechenden Kontingente für alle Batch-Konten des Benutzerabonnements festgelegt sind, um die erforderliche Anzahl von Kernen mithilfe des Batch-Kontos zuzuweisen.

  • Verwenden Sie Vorlagen und/oder Skripte zum Automatisieren der Bereitstellung der Anwendung in einer Region.

  • Halten Sie Binärdateien und Verweisdaten der Anwendung in allen Regionen auf dem neuesten Stand. Wenn die Region auf dem neuesten Stand bleibt, ist sichergestellt, dass sie ohne Warten auf das Hochladen und die Bereitstellung von Dateien schnell online geschaltet werden kann. Betrachten Sie beispielsweise den Fall, in dem eine benutzerdefinierte Anwendung zur Installation auf Poolknoten gespeichert und mithilfe von Batch-Anwendungspaketen referenziert wird. Wenn ein Update der Anwendung veröffentlicht wird, sollte es in jedes Batch-Konto hochgeladen und von der Poolkonfiguration referenziert werden (oder die neueste Version zur Standardversion machen).

  • Vereinfachen Sie den Wechsel von Clients oder das Laden in andere Regionen in der Anwendung, die Azure Batch, den Speicher und andere Dienste aufruft.

  • Ziehen Sie häufige Wechsel zu einer alternativen Region für den normalen Betrieb in Erwägung. Wechseln Sie beispielsweise mit zwei Bereitstellungen in separaten Regionen jeden Monat zur alternativen Region.

Die Dauer der Wiederherstellung nach einem Notfall hängt von der von Ihnen gewählten Konfiguration ab. Batch selbst agiert unabhängig davon, ob Sie mehrere Konten oder ein einzelnes Konto verwenden. In Aktiv-Aktiv-Konfigurationen, bei denen zwei Batch-Instanzen gleichzeitig Datenverkehr empfangen, ist die Notfallwiederherstellung schneller als bei einer Aktiv-Passiv-Konfiguration. Welche Konfiguration Sie auswählen, sollte auf geschäftlichen Anforderungen (unterschiedliche Regionen, Latenzanforderungen) und technischen Überlegungen basieren.

Notfallwiederherstellung für eine einzelne Region

Die Implementierung der Notfallwiederherstellung in Batch ist identisch, unabhängig davon, ob Sie in einer Region oder in mehreren Regionen arbeiten. Die einzigen Unterschiede bestehen in der SKU, die Sie für den Speicher verwenden, und ob Sie dasselbe oder ein anderes Speicherkonto für alle Regionen verwenden möchten.

Tests der Notfallwiederherstellung

Sie sollten Ihre eigenen Notfallwiederherstellungstests für Ihre Batch-fähige Lösung durchführen. Es gilt als bewährte Methode, einen einfachen Wechsel zwischen Client- und Dienstlast in verschiedenen Regionen zu ermöglichen.

Das Testen Ihres Notfallwiederherstellungsplans für Batch kann so einfach sein wie wechselnde Batch-Konten. Beispielsweise können Sie sich für einen Betriebstag auf ein einzelnes Batch-Konto in einer bestimmten Region verlassen. Am nächsten Tag können Sie dann zu einem zweiten Batch-Konto in einer anderen Region wechseln. Die Notfallwiederherstellung wird hauptsächlich auf der Clientseite verwaltet. Dieser Ansatz für die Notfallwiederherstellung mit mehreren Konten berücksichtigt die RTO- und RPO-Erwartungen in Regionen mit einer Region oder mehreren Regionen.

Kapazität und proaktive Notfallwiederherstellungsresilienz

Microsoft und seine Kunden arbeiten im Rahmen des Modells der gemeinsamen Verantwortung. Microsoft ist für plattform- und infrastrukturelle Resilienz verantwortlich. Sie sind für die Notfallwiederherstellung für jeden bestimmten Dienst verantwortlich, den Sie bereitstellen und steuern. So stellen Sie sicher, dass die Wiederherstellung proaktiv erfolgt:

  • Sie sollten sekundäre Replikate immer vorab bereitstellen. Die Vorabbereitstellung von Sekundärdateien ist erforderlich, da es keine Garantie für die Kapazität zum Zeitpunkt der Auswirkungen für diejenigen gibt, denen solche Ressourcen nicht vorab zugewiesen wurden.

  • Erstellen Sie alle erforderlichen Dienste in jeder Region im Vorfeld, z. B. Ihre Batch-Konten und zugehörigen Speicherkonten. Für das Erstellen neuer Konten fallen keine Gebühren an. Es fallen lediglich Gebühren an, wenn das Konto verwendet wird oder Daten gespeichert werden.

  • Stellen Sie sicher, dass die entsprechenden Kontingente für alle Abonnements vorab festgelegt werden, damit Sie die erforderliche Anzahl der Kerne mithilfe des Azure Batch-Kontos zuordnen können. Ebenso wie bei anderen Azure-Diensten gelten bei bestimmten Ressourcen in Verbindung mit dem Batch-Dienst Limits. Viele dieser Limits sind Standardkontingente, die von Azure auf Abonnement- oder Kontoebene angewendet werden. Bedenken Sie diese Kontingente beim Entwerfen und Hochskalieren Ihrer Batchworkloads.

Hinweis

Wenn Sie Produktionsworkloads in Batch ausführen möchten, müssen Sie möglicherweise ein oder mehrere Kontingente über den Standardwert erhöhen. Um eine Quote zu erhöhen, können Sie eine kostenlose Quotenerhöhung anfordern. Weitere Informationen finden Sie unter Anfordern einer Kontingenterhöhung.

Storage

Sie müssen Batch-Speicher konfigurieren, um sicherzustellen, dass Daten regionsübergreifend gesichert werden. Die Kundenverantwortung ist die Standardeinstellung. Die meisten Batch-Lösungen verwenden Azure Storage zum Speichern von Ressourcendateien und Ausgabedateien. In Ihren Batch-Tasks (einschließlich Standardtasks, Starttasks und Tasks zur Auftragsvorbereitung und -freigabe) werden beispielsweise in der Regel Ressourcendateien angegeben, die sich in einem Speicherkonto befinden. Speicherkonten speichern auch die Daten, die verarbeitet werden, sowie alle generierten Ausgabedaten. Es ist wichtig, mögliche Datenverluste in den Regionen Ihrer Dienstvorgänge zu verstehen. Außerdem müssen Sie überprüfen, ob Daten wiederbeschreibbar oder schreibgeschützt sind.

Batch unterstützt die folgenden Arten von Azure Storage-Konten:

  • Konten vom Typ „General Purpose v2“ (GPv2)
  • Konten vom Typ „General Purpose v1“ (GPv1)
  • BLOB-Speicherkonten (derzeit für Pools, in der VM-Konfiguration unterstützt)

Weitere Informationen zu Speicherkonten finden Sie unter Azure-Speicherkonto – Übersicht.

Sie können ein Speicherkonto mit Ihrem Batch-Konto verknüpfen – entweder im Zuge der Batch-Kontoerstellung oder zu einem späteren Zeitpunkt.

Wenn Sie ein separates Speicherkonto für jede Region einrichten, in der Ihr Dienst verfügbar ist, müssen Sie ZRS-Konten (zonenredundanter Speicher) verwenden. Verwenden Sie GZRS-Konten (geozonenredundanter Speicher), wenn Sie dasselbe Speicherkonto über mehrere Regionspaare hinweg verwenden. Für geografische Regionen, die eine einzelne Region enthalten, müssen Sie ein ZRS-Konto (zonenredundanter Speicher) erstellen, da GZRS nicht verfügbar ist.

Die Kapazitätsplanung ist ein weiterer wichtiger Aspekt beim Speicher und sollte proaktiv angegangen werden. Berücksichtigen Sie bei der Wahl eines Speicherkontos Ihre Kosten- und Leistungsanforderungen. Die Optionen für GPv2 und Blobspeicherkonto unterstützen beispielsweise höhere Kapazitäts- und Skalierbarkeitsgrenzwerte als GPv1. (Über den Azure-Support kann eine Erhöhung des Speicherlimits angefordert werden.) Diese Kontooptionen können die Leistung von Batch-Lösungen mit einer großen Anzahl paralleler Aufgaben verbessern, die aus dem Speicherkonto lesen oder in das Speicherkonto schreiben.

Wenn ein Speicherkonto mit einem Batch-Konto verknüpft ist, können Sie es sich als Konto für die automatische Speicherung vorstellen. Ein Konto für die automatische Speicherung ist erforderlich, wenn Sie die Funktion Anwendungspakete verwenden möchten, da es zum Speichern der ZIP-Dateien des Anwendungspakets verwendet wird. Das Konto für die automatisch Speicherung kann auch für Task-Ressourcendateien verwendet werden. Da das Konto für die automatische Speicherung bereits mit dem Batch-Konto verknüpft ist, ist es nicht mehr notwendig, SAS-URLs (Shared Access Signature) für den Zugriff auf die Ressourcendateien zu verwenden.

Nächste Schritte