Risk-Grid-Computing-Lösung

Azure Batch
Microsoft Entra ID
Azure ExpressRoute
Azure VPN Gateway

Dieser Artikel liefert einen technischen Überblick über die Verwendung von Microsoft Azure zur Unterstützung und Erweiterung des Risk-Grid-Computings im Bankwesen. In diesem Artikel werden empfohlene Systeme und allgemeine Architekturen vorgestellt.

Das Dokument richtet sich an Lösungsarchitekten, aber auch an Entscheidungsträger mit technischem Hintergrund, die sich ausführlicher über die empfohlenen Risk-Computing-Lösungen informieren möchten.

Einführung

Modelle für die Finanzrisikoanalyse werden in der Regel als Batchaufträge verarbeitet. Sie verursachen eine hohe Computeauslastung. Daher stellen sie hohe Ansprüche an die Compute- und Analyseleistung und erfordern umfangreichen Datenzugriff. Wenn immer mehr Risikoberechnungen mittels Grid Computing ausgeführt werden, nimmt auch der Bedarf an Computeressourcen zu.

Dank dem umfangreichen Produkt- und Dienstangebot in Azure können viele Probleme häufig auf unterschiedliche Weisen angegangen werden. Dieser Artikel bietet eine Übersicht über die Technologien, Muster und Verfahren, die sich im Bereich Risk-Grid-Computing mit Microsoft Azure Batch als effektivste Lösungen für das Bankwesen erwiesen haben.

Azure Batch ist ein kostenloser Dienst, der kostengünstige und sichere Lösungen bietet. Die Lösungen sind sowohl für die Infrastruktur als auch für die verschiedenen Phasen der Batchverarbeitung konzipiert, die in der Regel für Modelle im Risk-Grid-Computing verwendet werden. Azure Batch kann bestehende lokale Computeressourcen mithilfe von Hybridnetzwerken oder durch die Verlagerung des gesamten Batchprozesses in die Azure-Umgebung ergänzen, erweitern oder sogar ersetzen. Daten können zwischen der Cloud und der lokalen Umgebung bidirektional übertragen oder lokal vorgehalten werden. Andere Daten können in einem Burst-to-Cloud-Modell von Computeknoten verarbeitet werden, wenn die lokalen Ressourcen knapp werden.

Anatomie einer Azure Batch-Ausführung

An einer Batchausführung sind normalerweise mindestens zwei Anwendungen beteiligt. Eine Anwendung, die in der Regel auf einem "Hauptknoten" ausgeführt wird, sendet den Auftrag an den Pool und orchestriert zeitweise die Computeknoten. Die Orchestrierung kann auch über das Azure-Portal konfiguriert werden. Die andere Anwendung wird von den Computeknoten als Task ausgeführt (siehe Abbildung 1).

Die Computeknotenanwendung führt die Task "Risikomodelldateien parallel verarbeiten" aus. Auf den Computeknoten können mehrere Anwendung installiert und ausgeführt werden.

Diese Anwendungen können über die Batch-API, direkt über das Azure-Portal oder über die Azure CLI-Befehle für Batch hochgeladen werden.

Ein Diagramm, das Azure Batch Grid Computing veranschaulicht.

Abbildung 1: Azure Batch-Grid Computing

Eine Azure Batch-Ausführung besteht aus mehreren logischen Elementen. Abbildung 2 zeigt das logische Modell eines Batchauftrags. Ein Pool ist ein Container für die an der Batchausführung beteiligten VMs und stellt die Computeknoten-VMs bereit. Ein Pool ist ebenfalls der Container für die auf den Computeknoten installierten Anwendungen. Aufträge werden innerhalb des Pools erstellt und ausgeführt. Tasks werden durch die Aufträge ausgeführt. Tasks werden von der Workeranwendung ausgeführt und durch eine Befehlszeilenanweisung aufgerufen.

Die Workeranwendung wird bei der Erstellung auf dem Computeknoten installiert.

Pool, Aufträge und Tasks

Abbildung 2: Logisches Modell des Batchkonzepts

Bei der Ausführung des Auftrags stellt der Pool alle benötigten Worker-VMs bereit und installiert die Workeranwendungen. Der Auftrag weist Tasks diesen Computeknoten zu, die wiederum eine Befehlszeilenanweisung ausführen. Das CLI-Skript ruft normalerweise die installierten Anwendungen oder Skripts auf.

Die Verwendung von Batch folgt üblicherweise einem prototypischen Muster, das sich wie folgt beschreiben lässt:

  1. Erstellen einer Ressourcengruppe, in der die Batch-Ressourcen enthalten sind
  2. Erstellen eines Batch-Kontos in der Ressourcengruppe
  3. Erstellen eines verknüpften Speicherkontos
  4. Erstellen eines Pools, in dem die Worker-VMs bereitgestellt werden können
  5. Hochladen der Computeknotenanwendung oder -skripts in den Pool
  6. Erstellen eines Auftrags, um den VMs im Pool Tasks zuzuweisen
  7. Hinzufügen des Auftrags zum Pool
  8. Starten der Batchausführung
  9. Der Auftrag stellt die auf den Computeknoten auszuführenden Tasks in die Warteschlange.
  10. Sobald VMs verfügbar sind, werden die Tasks von den Computeknoten ausgeführt.

Dieser Prozess wird in Abbildung 3 veranschaulicht.

Batchausführungsprozess

Abbildung 3: Logisches Modell des Batchkonzepts

Nachdem Tasks abgeschlossen sind, empfiehlt es sich u. U., die Computeknoten zu entfernen, damit keine Gebühren entstehen, während sie nicht in Gebrauch sind. Um sie über den Code oder im Portal zu löschen, kann der enthaltende Pool gelöscht werden, wodurch die Worker-VMs entfernt werden.

Ausführlichere exemplarische Vorgehensweisen zu den ersten Schritten mit Batch finden Sie in den mehrsprachigen fünfminütigen Schnellstarts, die Sie durch den Prozess führen und zudem die Verwendung des Azure-Portals veranschaulichen.

Zeitliche Planung des Batchprozesses

Da Azure Batch über einen integrierten Planer verfügt, kann jede Ausführung im Portal oder mithilfe von APIs geplant werden. Der Batch-Auftragsplaner kann mehrere Zeitpläne definieren, um mehrere Aufträge auszulösen. Jeder Auftrag verfügt über eigene Eigenschaften, beispielsweise, welche Aktion beim Starten und Beenden des Auftrags ausgeführt wird. Auftragszeitpläne können in regelmäßigen Abständen oder für eine einmalige Ausführung festgelegt werden.

Viele Grid Computing-Systeme für das Bankwesen verfügen bereits über einen eigenen Planungsdienst. Es ist möglicherweise nicht sofort erforderlich, den eigenen Planer in Azure zu übernehmen. Azure Batch unterstützt die nahtlose Zusammenarbeit und kann manuell oder über ein SDK aufgerufen werden. Auf diese Weise kann die Planung weiterhin lokal durchgeführt werden, während die Workloadverarbeitung in Azure erfolgt.

Die Batchverarbeitung kann nach einem zuvor festgelegten Zeitplan oder bedarfsgesteuert ausgeführt werden. In beiden Fällen müssen Computeknoten-VMs nicht weiter aktiv bleiben, wenn sie nicht in Gebrauch sind. Durch die Nutzung Hunderter und sogar Tausender VM-Computeknoten lassen sich erhebliche Kosten einsparen, indem die Bereitstellung der Server aufgehoben wird, sobald sie die in der Warteschlange enthaltenen Tasks abgearbeitet haben.

Computeknotenanwendungen

Auf Computeknoten muss eine Anwendung ausgeführt werden, wenn eine Task aufgerufen wird. Diese Anwendungen werden vom Unternehmen geschrieben, um nach der Installation auf den Workern Aufträge zu verarbeiten. Beim Risk-Grid-Computing für das Bankwesen wird diese Anwendung oftmals für die Umwandlung von Daten in Formate eingesetzt, die speziell für Downstreamanalysen oder andere Verarbeitungsaufgaben geeignet sind.

Wenn die Anwendung für den Pool bereitgestellt wird, damit sie an Computeknoten verteilt werden kann, wird sie in einem Anwendungspaket hochgeladen. Bei einem Anwendungspaket kann es sich um eine andere Version eines zuvor hochgeladenen Anwendungspakets handeln. Auf einem Computeknoten können auch mehrere Anwendungspakete installiert werden. Der Auftrag enthält die Anwendungspakete, die auf die Workercomputer geladen werden sollen.

Die Bereitstellung von Anwendungspaketen kann auch nach Versionen verwaltet werden. Wenn mehrere Versionen eines Anwendungspakets in einen Pool geladen wurden, kann eine bestimmte Version für die Verwendung in einer Batchausführung festgelegt werden, wie in Abbildung 4 veranschaulicht. Dies kann in Überwachungsumgebungen erforderlich sein oder wenn das Unternehmen eine vorherige Ausführung reproduzieren möchte, eignet sich jedoch auch für Rollbacks, falls die Workeranwendung fehlerhaft ist.

Batchausführungsprozess

Abbildung 4: Computeknotenanwendungen mit verschiedenen Versionen

Ein Anwendungspaket wird als ZIP-Datei in den Pool hochgeladen. Die Datei enthält die Binärdateien der Anwendung und die unterstützenden Dateien, die für Tasks zur Ausführung der Anwendung erforderlich sind. Es gibt zwei Bereiche für Anwendungspakete. Sie können für ein Anwendungspaket entweder den "Poolbereich" oder den "Taskbereich" festlegen.

Poolanwendungspakete

Diese Pakete werden auf jedem Computeknoten im Pool bereitgestellt. Wenn eine Computeknoten-VM bereitgestellt oder neu gestartet bzw. wenn dafür ein Reimaging durchgeführt wird, wird von jedem Poolanwendungspaket eine neue Kopie installiert, sofern eine aktualisierte Anwendung vorhanden ist. Einem Pool können eines oder mehrere Anwendungspakete zugewiesen werden. Das bedeutet, dass die Computeknoten alle festgelegten Pakete nutzen können.

Taskanwendungspakete

Anwendungspakete für die Taskebene werden nur auf Computeknoten installiert, für die eine Taskausführung geplant ist. Taskanwendungspakete sollten verwendet werden, wenn mehr als ein Auftrag in einem Pool ausgeführt wird.

Taskanwendungen sind hilfreich zum Aggregieren von Daten, die durch Aufträge auf der Poolebene erzeugt wurden. Diese Anwendungen können beim Risk-Grid-Computing von Bedeutung sein. Beispielsweise können von einer Taskanwendung Risikoberechnungen ausgeführt werden. Dabei werden Daten generiert, die später im Workflow für die Risikoberechnung verwendet werden sollen.

Skalieren von Batchaufträgen

Banken führen Risikoanalyse-Batchaufträge häufig am Wochenende oder nachts aus, wenn Computeressourcen weniger ausgelastet sind. Während dieses Modell für einige geeignet ist, kann es schnell an seine Grenzen stoßen, wodurch zusätzliche Investitionen in Workercomputer erforderlich werden, um das Grid zu erweitern.

Wenn Azure Batch-Aufträge zu lange dauern oder die Batch-Ausführung durch mehr Computeleistung verbessert werden soll, bietet Azure verschiedene Optionen.

  1. Verwenden Sie zusätzliche Computeknotencomputer, um horizontal hochzuskalieren.
  2. Verwenden Sie leistungsfähigere Computeknotencomputer, um zentral hochzuskalieren. Durch die Bereitstellung von Azure-Computern können höhere Leistungsanforderungen an Kerne, Arbeitsspeicher und sogar GPU-Computeleistung erfüllt werden.

Hinweis: Die Nutzung von Microsoft HPC Pack mit Batch ist ein komplexeres Thema und wird in diesem Artikel nicht behandelt.

In einem Batch-Verarbeitungscluster können möglicherweise nur zwei Verarbeitungs-VMs vorhanden sein. Oder es können Tausende gleichzeitige Tasks auf Tausenden VM-Computeknoten mit Zehntausenden Kernen ausgeführt werden. Jede VM ist jeweils für die Ausführung einer einzelnen Task zuständig. Die Anzahl von VMs in einem Pool lässt sich mit zunehmender oder abnehmender Auslastung je nach Konfiguration manuell oder automatisch skalieren.

Burst-to-Cloud-Modell

Wenn Computeressourcen in einem lokalen Grid aufgrund eines umfangreichen Analyseauftrags knapp werden, bietet "Burst-to-Cloud" eine Möglichkeit, die Ressourcenkapazität zu erweitern, indem die Anzahl der Computeknoten in Azure erhöht wird. Beim Burst-to-Cloud-Modell wird die Workload aus Private Cloud-Umgebungen oder privaten Infrastrukturen auf Cloudserver ausgelagert, wenn ein hoher Bedarf an lokalen Ressourcen besteht.

Diese Computeknoten können als Linux- oder Windows-VMs vorkonfiguriert und auf der IaaS-Plattform von Azure bereitgestellt werden. Darüber hinaus können Server bereitgestellt und automatisch konfiguriert werden, um mit vorhandenen IT-Investitionen wie Tibco Gridserver und IBM Symphony zusammenzuarbeiten.

Formeln für die automatische Skalierung

Die Elastizität kann im Azure-Portal oder mithilfe von Formeln für die automatische Skalierung konfiguriert werden. Formeln für die automatische Skalierung sind Skripts, die in den Batch-Verarbeitungsplaner hochgeladen werden, um das Verhalten von Batch präzise zu steuern. Bei der automatischen Skalierung eines Computeknotenpools werden den Knoten Formeln für die automatische Skalierung zugeordnet.

Das folgende Beispiel zeigt, wie die automatische Skalierung mithilfe einer Formel für die automatische Skalierung gesteuert wird. Dabei wird die anfängliche Anzahl von einer VM bei Bedarf auf 50 VMs hochskaliert. Werden Aufgaben abgeschlossen, werden VMs nacheinander frei, und der Pool wird durch die Formel für die automatische Skalierung verkleinert.

startingNumberOfVMs = 1;
maxNumberofVMs = 50;
pendingTaskSamplePercent = $PendingTasks.GetSamplePercent(180 * TimeInterval_Second);
pendingTaskSamples = pendingTaskSamplePercent < 70 ? startingNumberOfVMs : avg($PendingTasks.GetSample(180 * TimeInterval_Second));
$TargetDedicatedNodes=min(maxNumberofVMs, pendingTaskSamples);

Weitere Skalierungsverfahren

Die automatische Skalierung kann auch durch das PowerShell-Cmdlet Enable-AzureBatchAutoScale aktiviert werden. Das Enable-AzureBatchAutoScale-Cmdlet aktiviert die automatische Skalierung für den angegebenen Pool. Im Folgenden wird ein Beispiel aufgeführt.

  1. Der erste Befehl definiert eine Formel und speichert sie dann in der $Formula-Variablen.
  2. Der zweite Befehl aktiviert die automatische Skalierung für den Pool mit dem Namen RiskGridPool unter Verwendung der Formel in $Formula.
C:\> $Formula = ‘startingNumberOfVMs = 1;
maxNumberofVMs = 50;
pendingTaskSamplePercent = $PendingTasks.GetSamplePercent(180 * TimeInterval_Second?WT.mc_id=gridbanksg-docs-dastarr);
pendingTaskSamples = pendingTaskSamplePercent < 70 ? startingNumberOfVMs : avg($PendingTasks.GetSample(180 * TimeInterval_Second));
$TargetDedicatedNodes=min(maxNumberofVMs, pendingTaskSamples);’;

C:\> Enable-AzureBatchAutoScale -Id "RiskGridPool" -AutoScaleFormula $Formula -BatchContext $Context

Die Skalierung kann auch über die Azure CLI mit dem Befehl az batch pool resize und über das Azure-Portal ausgeführt werden.

Datenspeicherung und -aufbewahrung

Sobald Daten erfasst und von einem Computeknoten verarbeitet wurden, können die resultierenden Ausgabedaten in einer Datenbank gespeichert werden. Die Ausgabedaten können weiter verarbeitet und analysiert oder bei der Erfassung vor der Speicherung transformiert werden, um zu gewährleisten, dass die richtigen Formate für die Downstreamverarbeitung verwendet werden. Microsoft Azure bietet verschiedene Optionen für die Speicherung. Die Wahl der zu verwendenden Datenspeichertechnologie richtet sich größtenteils nach den Analyse- und Berichtsanforderungen in Downstreamprozessen.

Bei Verwendung eines Hybridnetzwerks kann sich das Ziel für die Datenspeicherung in der lokalen Umgebung befinden. Wenn Batch über ein Hybridnetzwerk verwendet wird, können Computeknoten Daten in einen lokalen Datenspeicher zurückschreiben, ohne dass ein Azure-basierter Speicherort verwendet wird. Worker können Daten auch in Azure File Storage schreiben. Dieser kann auf einem lokalen Computer als Datenträger eingebunden werden. Dieses Setup ermöglicht den einfachen Zugriff durch Prozesse, die für die lokale Verarbeitung von Dateien zuständig sind.

Überwachung und Protokollierung

Um die zukünftige Ausführung von Aufträgen in Batch zu optimieren, sollten Daten aufgezeichnet werden, um Verbesserungsmöglichkeiten zu identifizieren. Beispiel: Falls Worker die CPU-Kapazität fast völlig ausschöpfen, können Computeknoten durch zusätzliche Kerne erweitert werden. Auf diese Weise wird die CPU-Abhängigkeit verringert, und der Auftrag wird schneller abgeschlossen. Da jede im Batchauftrag ausgeführte Anwendung individuelle Merkmale aufweist, können sich die an den VMs in den Batchausführungen vorgenommenen Optimierungen unterscheiden. Speicherintensiven Tasks kann mehr Arbeitsspeicher zugeordnet werden, indem die Computer bei der nächsten Ausführung anders konfiguriert werden.

Die Protokollierung kann über die Computeknoten- und Grid-Hauptanwendungen oder über einen Auftrag mithilfe der Diagnoseprotokollierung für Batch erfolgen. Die Protokollierung von Leistungsdaten zur Ausführung von Batch ist konfigurierbar. So lassen sich Optimierungschancen besser erkennen, die Leistung verbessern und die Taskausführung beschleunigen.

Benutzerdefinierte Überwachung und Protokollierung für Batch

Die Controlleranwendung und die Computeknotenanwendungen können diese Daten generieren und zur weiteren Analyse speichern. Folgende Daten sind bei der Optimierung von Aufträgen in Batch hilfreich:

  • Start- und Beendigungszeit jeder Task
  • Die Dauer, die jeder Computeknoten aktiv ist und Tasks ausführt
  • Die Dauer, die jeder Computeknoten aktiv ist und keine Tasks ausführt
  • Die gesamte Ausführungszeit des Batchauftrags

Diagnoseprotokollierung für Batch

Neben den Controller- und Computeknotenanwendungen gibt es eine Alternative zur Ausgabe von Instrumentierungsdaten. Mit der Diagnoseprotokollierung für Batch können umfangreiche Ausführungsdaten erfasst werden. Die Diagnoseprotokollierung für Batch ist standardmäßig nicht aktiviert und muss für das Batch-Konto aktiviert werden.

Die Diagnoseprotokollierung für Batch stellt umfangreiche Daten zur Verfügung, die die Problembehandlung und Optimierung von Batchausführungen unterstützen. Dazu gehören die Start- und Beendigungszeiten von Aufträgen und Tasks, die Anzahl von Kernen, die Gesamtanzahl von Knoten und viele weitere Metriken.

Die Protokollierung für Batch erfordert ein Speicherziel für die ausgegebenen Protokolle und für die durch die Batchausführung generierten Speicherereignisse wie die Poolerstellung, Auftragsausführung, Taskausführung usw. Diagnoseprotokollereignisse können nicht nur in einem Azure Storage-Konto gespeichert werden. Die Protokollereignisse des Batch-Diensts können auch an eine Instanz von Azure Event Hubs gestreamt werden. Die Ereignisse können dann an Azure Log Analytics gesendet werden.

Anhand dieser Daten können zentrale Computing- und Hauptknotenanwendungen optimiert werden. Auf diese Weise lassen sich beispielsweise Kosten reduzieren, weil die Bereitstellung nicht mehr benötigter Worker-VMs schneller aufgehoben werden kann und nicht mehr darauf gewartet werden muss, bis die Batchausführung vollständig beendet wurde.

Batch-Verwaltungstools

Das Azure-Portal bietet ein Batch-Überwachungsdashboard, auf dem während der Auftragsausführung Informationen zu Batch und sogar zur Kontokontingentverwendung angezeigt werden. Dieses Tool ist für zahlreiche Anwendungen zur Batch-Auftragsverarbeitung ausreichend.

Zusätzlich zu den im Azure-Portal verfügbaren Verwaltungs- und Visualisierungstools von Batch steht das kostenlose Open-Source-Tool Batch Explorer für die Verwaltung von Batch zur Verfügung. Dieses eigenständige Clienttool bietet Unterstützung beim Erstellen, Debuggen und Überwachen von Azure Batch-Anwendungen. Laden Sie ein Installationspaket für Mac, Linux oder Windows herunter.

Netzwerkmodelle

Bei der Risikoanalyse müssen häufig Hunderte, wenn nicht Tausende Dokumente im Risk-Grid-Computing-Prozess erfasst werden. Diese Dateien befinden sich häufig in einem Dateispeicher, auf einer Netzwerkfreigabe oder in einem anderen Repository in der lokalen Umgebung. Wenn Azure-basierte VMs für den Dateizugriff und die Dateiverarbeitung verwendet werden, ist es oft hilfreich, wenn das lokale Netzwerk nahtlos mit dem Azure-Netzwerk verbunden ist, um einen einfachen und schnellen Dateizugriff zu ermöglichen. Bei diesem Ansatz sind u. U. noch nicht einmal Änderungen am Code erforderlich, der für die Verarbeitung auf den Computeknoten zuständig ist.

Azure bietet mit Microsoft Azure ExpressRoute und VPN Gateway zwei Modelle, über die vorhandene lokale Systeme sicher und zuverlässig mit Azure verbunden werden können. Beide unterstützen sichere, zuverlässige Verbindungen, obwohl es Unterschiede bei der Implementierung, der Leistung und bei anderen Attributen gibt.

Alternativ kann der Hauptknoten für das Risk-Grid-Computing lokal ausgeführt werden und den Batchauftrag über die REST-APIs oder SDKs in .NET und anderen Sprachen ausführen.

Es stehen weitere Lösungen zur Verfügung, um Azure und lokale Ressourcen auch ohne den Einsatz eines Hybridnetzwerks zu verbinden. Weitere Informationen finden Sie weiter unten.

ExpressRoute

ExpressRoute verbindet Ihr lokales oder Rechenzentrumsnetzwerk über eine private Verbindung mit Azure. Diese wird von einem Konnektivitätspartner wie Ihrem aktuellen Internetdienstanbieter bereitgestellt. Dadurch werden beide Netzwerke als dieselbe Netzwerkinstanz dargestellt und erkannt, was einen nahtlosen Zugriff zwischen Netzwerken gewährleistet. Wenn Sie vorhandene lokale Systeme in ein Azure-Netzwerk integrieren möchten, ist eine effiziente Netzwerkintegration unverzichtbar. Dabei bietet ExpressRoute die höchsten Verbindungsgeschwindigkeiten.

Zusätzliche Preisinformationen zu Azure ExpressRoute finden Sie hier.

VPN Gateway

VPN Gateway bietet eine weitere Möglichkeit, Ihr Netzwerk mit Azure zu verbinden. Dieses Modell hat den Nachteil, dass der Datenverkehr über das Internet geleitet wird. Folglich ist die Verbindung möglicherweise weniger resilient, und auch die Netzwerkgeschwindigkeiten erreichen nicht die von ExpressRoute. Dies ist u. U. aber kein Hindernis für ein Risk-Grid-Computing-Szenario, weil Datendateien in der Regel schnell gelesen werden.

Zusätzliche Preisinformationen zu VPN Gateway finden Sie hier.

Erläuterung der Verbindungsmodelle

Es gibt im Wesentlichen zwei Modelle für die Ausdehnung Ihres Netzwerks auf Azure, wie in Abbildung 5 dargestellt.

  • Virtuelles Gateway – Site-to-Site
  • ExpressRoute – Exchange oder ISP-Anbieter

Site-to-Site und ExpressRoute

Abbildung 5: Site-to-Site und ExpressRoute

Virtuelles Gateway – Site-to-Site-Integration

Ein Site-to-Site-VPN Gateway verbindet Ihr lokales Netzwerk mit einem Azure Virtual Network. So werden Netzwerke nahtlos verbunden und im Wesentlichen Teil desselben Netzwerks, das den bidirektionalen Zugriff auf Ressourcen, Server und Artefakte ermöglicht. Auf diese Weise können die Azure-Worker-VMs, die den Risk-Grid-Computing-Batchauftrag ausführen, direkt auf die Datendateien zugreifen.

ExpressRoute-Integration

Eine ExpressRoute-Verbindung, die von einem Azure-Partner (Netzwerkanbieter) bereitgestellt wird, bietet dieselben Vorteile wie eine Site-to-Site-Verbindung, weist allerdings eine höhere Geschwindigkeit und Zuverlässigkeit auf.

Weitere Informationen zu ExpressRoute-Konnektivitätsmodellen erhalten.

Batchverarbeitung ohne Azure-Hybridnetzwerk

Ein anderes Batch-Szenario könnte darin bestehen, alle Datendateien in Azure Storage hochzuladen und später durch Azure-basierte Compute-VMs verarbeiten zu lassen. Für die Speicherung von Risk-Grid-Computing-Daten kommen File Storage und Blob Storage infrage.

In diesem Szenario befinden sich der Auftragscontroller und alle Computeknoten in Azure, wie aus Abbildung 6 ersichtlich. Als Ziel für verarbeitete Daten bietet sich ein Azure-Datenspeicher an, der optimale Voraussetzungen für die weitere Verarbeitung durch Azure Machine Learning-Lösungen oder andere Systeme bietet. Diese zusätzlichen Verarbeitungsoptionen gehen über den Rahmen dieses Artikels hinaus.

Site-to-Site und ExpressRoute

Abbildung 6: Batchupload in den Ausführungslebenszyklus

Ressourcen für Hybridnetzwerkverbindungen

Auf Ihre Situation sind u. U. mehrere Konfigurationen anwendbar. Im Artikel Verbinden eines lokalen Netzwerks mit Azure von der Patterns and Practices Group finden Sie Entscheidungshilfen und Architekturleitfäden zum Verbinden von Netzwerken mit Azure.

Sicherheitshinweise

Es ist möglich, ein Azure Virtual Network (VNET) zu erstellen und die Computeknoten des Pools direkt in diesem Netzwerk zu erstellen. So wird nicht nur eine zusätzliche Isolationsstufe für Batchausführungen, sondern außerdem die Authentifizierung über Microsoft Entra ID unterstützt. Weitere Informationen finden Sie unter Konfiguration von Poolnetzwerken.

Es gibt zwei Möglichkeiten, eine Batchanwendung mithilfe von Microsoft Entra ID zu authentifizieren:

  • Integrierte Authentifizierung. Eine Batchanwendung erhält über Microsoft Entra-Konten Zugriff auf Ressourcen für Datenspeicher und andere Ressourcen.

  • Dienstprinzipal. Durch Microsoft Entra-Dienstprinzipale werden Zugriffsrichtlinien und Berechtigungen für Benutzer*innen und Anwendungen definiert. Ein Dienstprinzipal unterstützt die Benutzerauthentifizierung unter Verwendung eines geheimen Schlüssels, der mit der jeweiligen Anwendung verknüpft ist. So können Anwendungen, die im unbeaufsichtigten Modus ausgeführt werden, mit einem geheimen Schlüssel authentifiziert werden. Ein Dienstprinzipal definiert die Richtlinien und Berechtigungen für eine Anwendung, um die Anwendung darzustellen, wenn zur Laufzeit auf Ressourcen zugegriffen wird. Hier erhalten Sie weitere Informationen.

Weitere Informationen zur Sicherheit bei der Batchverarbeitung mit Microsoft Entra ID finden Sie in diesem Artikel.

Der Batch-Dienst kann auch mit einem gemeinsam verwendeten Schlüssel authentifiziert werden. Der Authentifizierungsdienst erfordert, dass der HTTP-Anforderung, den Daten und der Autorisierung zwei Headerwerte hinzugefügt werden. Weitere Informationen zur Authentifizierung mit einem gemeinsam verwendeten Schlüssel finden Sie hier.

Kostenoptimierung

Die Nutzung von Azure Batch ist kostenlos. Sie zahlen nur für die genutzten zugrunde liegenden Ressourcen, z. B. die Betriebszeit virtueller Computer sowie die Speicher- und Netzwerknutzung. Da die Computeknoten-VMs allerdings auch im Leerlauf immer noch Kosten verursachen, empfiehlt es sich, die Bereitstellung aufzuheben, wenn sie nicht mehr benötigt werden. Dazu wird häufig der Pool gelöscht, in dem sie enthalten sind.

Wenn Sie einen Pool erstellen, können Sie die gewünschte Art und Anzahl von Computeknoten angeben. Es gibt zwei Arten von Computeknoten:

Dedizierte Computeknoten sind für Ihre Workloads reserviert. Sie sind teurer als Knoten mit niedriger Priorität, aber sie werden garantiert nie zurückgestellt.

Computeknoten mit niedriger Priorität nutzen überschüssige Kapazität in Azure, um Batchworkloads auszuführen. Knoten mit niedriger Priorität sind pro Stunde kostengünstiger als dedizierte Knoten und erlauben Workloads, die eine umfangreiche Rechenleistung erfordern. Weitere Informationen finden Sie unter Use low-priority VMs with Batch (Verwenden von VMs mit niedriger Priorität mit Batch).

Dedizierte Knoten und Knoten mit niedriger Priorität können im selben Pool enthalten sein.

Informationen zu den Preisen für beide Arten von Serverknoten finden Sie unter Batch – Preise.

Bei Verwendung des Diagnoseprotokollierungsdiensts für Batch entstehen für die in Azure Storage ausgegebenen Daten Kosten. Speicherdaten werden wie jeder andere Datentyp behandelt. Die Preise richten sich nach der Menge der vorgehaltenen Diagnosedaten.

Erste Schritte

Ein komplexes Thema wie das Batchcomputing im Rahmen des Risk-Grid-Computings bietet viele Herangehensweisen. Folgende logische Ausgangspunkte sollen helfen, die Batchtechnologie besser zu verstehen.

Die Azure Batch-Dokumentation ist ein hervorragender Ausgangspunkt. Die Dokumentation enthält Portalbeispiele, API-Verweise und schrittweise Lernprogramme mit Codebeispielen. Die Azure Batch-Beispielanwendungen sind auch auf GitHub kostenlos erhältlich.

Nachfolgend einige kurze Tutorials, die Sie beim Erstellen einer einfachen Anwendung unterstützen, mit der Batchcomputeaufträge erstellt und ausgeführt werden können. Sie können folgende Optionen zum Erstellen der Anwendung nutzen:

Beispielsweise könnten Sie eine Proof of Concept-Initiative starten. Welchen Ansatz nutzen Sie für die Datenerfassung in Azure? Verwenden Sie ein Hybridnetzwerk, oder laden Sie Daten über ein SDK oder eine REST-Schnittstelle hoch? Falls Sie ein Hybridnetzwerk in Erwägung ziehen, starten Sie zur Einrichtung einen Pilotversuch.

Bestimmen Sie die Größe Ihrer Batch-Computeaufträge, und wählen Sie die richtige Skalierungslösung aus. Formeln für die automatische Skalierung unterstützen komplexe Planungsszenarien. Einfachere Szenarien lassen sich mithilfe des Azure-Portals umsetzen.

Komponenten

  • Azure Batch bietet Funktionen zum Ausführen umfangreicher Parallelverarbeitungsaufträge in der Cloud.

  • Microsoft Entra ID ist ein mehrinstanzenfähiger, cloudbasierter Verzeichnis- und Identitätsverwaltungsdienst, in dem zentrale Verzeichnisdienste, Anwendungszugriffsverwaltung und Identitätsschutz in nur einer Lösung vereint sind.

  • Formeln für die automatische Skalierung sind Skripts, die in den Verarbeitungsplaner für Batch hochgeladen werden, um das Skalierungsverhalten von Batch präzise zu steuern.

  • Die Diagnoseprotokollierung für Batch ist ein Feature von Azure Batch, das die Erstellung eines detaillierten Protokolls anhand der Batchausführungen und generierten Ereignisse ermöglicht. Protokolle werden in Azure Storage gespeichert.

  • Batch Explorer ist eine eigenständige Anwendung für die Batch-Überwachung und -Verwaltung. Sie ist für Windows, macOS und Linux verfügbar.

  • ExpressRoute ist eine hochleistungsfähige, zuverlässige Hybridnetzwerklösung für die Integration von lokalen und Azure-Netzwerken.

  • Azure VPN Gateway ist eine Hybridnetzwerklösung, die lokale und Azure-Netzwerke über das Internet verbindet.

Schlussbemerkung

Dieses Dokument bietet eine Übersicht über die technischen Lösungen und Überlegungen zur Verwendung von Azure Batch für das Risk-Grid-Computing im Bankwesen. Im Artikel wurden zahlreiche Themen behandelt, von der Definition von Azure Batch über Netzwerkoptionen bis hin zu Kostenaspekten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

  • David Starr | Leitende Fachkraft für Lösungsarchitekturen

Nächste Schritte

Wenn Sie die Eignung von Azure Batch für das Risk-Grid-Computing eingehender beurteilen möchten, bildet diese Seite einen guten Ausgangspunkt. Sie bietet angeleitete Beispieltutorials für die parallele Dateiverarbeitung, die eng mit dem Risk-Grid-Computing verknüpft ist. Tutorials sind über das Azure-Portal, die Azure CLI, .NET und Python verfügbar.

Produktdokumentation: