Vom einfachen Job Processing im Hintergrund bis zu High Performance Computing (HPC)

Hochskalierbare Batchverarbeitung mit Microsoft Azure
Kommentare

Für skalierbare Webanwendungen und Services gibt es eine Kernregel, die sich in der Praxis als wertvoll erwiesen hat: rechenintensive Aufgaben sollten Sie tunlichst nicht im Frontend Tier vornehmen. Diese lagern Sie am besten auf separate Compute Nodes aus, sodass ihr Frontend/Service für Anfragen von Kunden möglichst viele Ressourcen frei hat. Das klingt naheliegend. Damit ist allerdings jede Menge zusätzliche Arbeit verbunden, von Logging über sehr smarte Fehlerbehandlung bis hin zu Compute-Node-Management. Lernen Sie in diesem Artikel, welche Möglichkeiten Microsoft Azure als Cloud-Plattform für derartige Verarbeitungsmuster, kurz Batch-Processing, bietet.

Diejenigen unter uns, die schon etwas länger in der IT tätig sind, haben sicher schon mal etwas mit Batch-Processing im Kontext automatisierter File-Verarbeitung zu tun gehabt. Nun, so viel hat sich hier eigentlich nicht geändert, außer der Tatsache, dass Files nicht mehr das einzige sind, worum es beim Batch-Processing geht. Vielmehr können komplexe Aufgaben im Hintergrund auf separaten Compute Tiers ausgeführt werden, um Frontend Tiers zu entlasten. HPC (High Performance Computing) ist naiv ausgedrückt auch nichts anderes als Batch-Processing, man spricht hier eben von einer massiven Anzahl von sehr gut ausgestatteten Maschinen für die Verarbeitung und einer extrem hohen Anzahl von Prozessen bzw. Aufgaben. Zusätzlich können bei HPC eventuell Knoten noch miteinander kommunizieren, um die Verarbeitung effizienter zu gestalten (Stichwort Message Passing Interface, MPI). Das grundsätzliche Muster ist aber gleich. Bricht man das Ganze auf eine einfache, konzeptionelle Darstellung runter (für die Software Architekten unter uns), so gilt es, das in Abbildung 1 dargestellte, primitive Problem zu lösen.

Abb.1: Batch-Processing vereinfacht und schematisch dargestellt

Wer schon seit Jahren mit Microsoft Azure arbeitet und das Konzept der Web/Worker Roles kennt, wird sich sofort wiederfinden. HPC-Experten ersetzen einfach die Worte „Web“ durch „Head Node“ sowie „Worker“ durch „Compute Node““ und schon spielen wir alle im selben Spiel. Typische Anwendungsfälle für eine derartige Architektur sind:

  • Generierung von Dokumenten (vereinzelt oder massenhaft)
  • Verarbeitung von Bildern (z. B. Generierung von Thumbnails etc.)
  • Komplexe Algorithmen und Berechnungen (Monte-Carlo-Simulationen, Stressanalyse etc.)
  • Mediaaufgaben (Rendering, Transcoding etc.)

Grundsätzlich passt die Idee auch, und hat man sich an dieses Abenteuer gewagt, so hat es sich meiner Erfahrung nach immer ausgezahlt. Allerdings sind Verantwortung und Implementierungsaufwand damit definitiv größer. Neben Message Queues, Storage und der Aufteilung auf mehrere, physikalische Maschinen muss man sich darüber hinaus mit folgenden Themen beschäftigen:

  • Automatisches Deployment von Binaries und Ressourcen auf Compute Nodes
  • Clean-up von Compute Nodes nach der Beendigung von Prozessen
  • Protokollierung des Prozessfortschritts und Status
  • Scheduling von Jobs/Tasks im Falle von zeitgesteuerter Verarbeitung
  • Intelligente Aufteilung der Jobs/Tasks auf (nicht ausgelastete) Compute Nodes
  • Automatische Skalierung der Compute Nodes nach Anzahl der Jobs/Tasks
  • Priorisierung von Jobs/Tasks
  • Benachrichtigungen über Prozessfortschritt/Status/Fehler
  • Behandlung fehlerhafter Jobs/Tasks inklusive „Poison Messages“
  • Neustart von Jobs/Tasks, die nicht erfolgreich beendet werden konnten

Eigentlich ist eine Public Cloud mit Rechenzentren jenseits der 100 000 Server optimal für derartige Verarbeitungsmuster; bei so viel Implementierungsaufwand fragt man sich aber schnell, ob es nicht einfacher geht. Zu Beginn dieses Jahres 2014 hätte ich diese Frage noch einfach mit „Nein“ beantworten können. Mittlerweile sieht die Situation wirklich gut aus.

Optionen auf Microsoft Azure

Microsoft Azure als Cloud-Plattform bietet mehrere Möglichkeiten, um das Entwurfsmuster des Batch-Processings umzusetzen. Abbildung 2 gibt einen Überblick über die verschiedenen Optionen aus dem Blickwinkel der Compute-Umgebung, die eine Option primär zur Verfügung stellt.

Abb. 2: Batch-Processing-Optionen auf Microsoft Azure (im engeren Sinne)

Tabelle 1 beschreibt die Optionen detaillierter und gibt Ihnen einen Einblick, wer die primäre Zielgruppe für die jeweilige Batch-Processing-Option ist. Der Inhalt der Tabelle ist Voraussetzung für den Rest des Artikels, sehen Sie sich diese also unbedingt an.

Option Zielgruppe Wichtige Kommentare
HPC Pack 2012 (oder 2008) HPC und MPI Anwendungsentwickler Personen mit HPC Pack Erfahrung Personen, die Hybrid-Umgebungen (Private-/Public-Cloud) benötigen Das HPC-Pack ist eine kostenlose Erweiterung für den Windows-Server. Sie können das HPC-Pack auf Windows-Servern in Ihrem Rechenzentrum betreiben, Sie können es aber genauso gut in Virtual Machines (IaaS) in Microsoft Azure betreiben. Seit der Version 2008 bietet das HPC-Pack die Möglichkeit, auch PaaS Cloud Services von Microsoft Azure als Compute Nodes zu nutzen.
Cloud Services Web/Worker Development Softwareentwickler und Software-as-a-Service-Anbieter, die sich nicht mit Infrastrukturmanagement beschäftigen möchten Personen mit Erfahrung im Bereich Web/Worker auf Microsoft Azure Entwickler, die eine eigene Scheduling-Lösung gegenüber Plattformdiensten wie WebJobs SDK oder Azure Batch bevorzugen (um einen Lock-in in Azure zu vermeiden) Cloud Services Web/Worker Roles sind seit 2009 produktiv auf der Azure-Plattform. Sie stellen automatisch verwaltete, zustandslose und skalierbare virtuelle Maschinen dar, in denen entsprechend Ihres Servicemodells und Ihrer Cloud-Service-Deployment-Pakete ihre Anwendungen provisioniert werden. Obwohl die Compute-Container-Prinzipien eigentlich sehr nahe an dem in Abbildung 1 dargestellten Entwurfsmuster liegen, müssen Sie das Job Scheduling und alle damit verbundenen Aspekte selbst implementieren. Vor dem Release von Azure Batch (siehe weiter unten) hat Microsoft eine vereinfachte Open-Source-Implementierung für „höher skalierbare“ Batchverarbeitung in Form von GeRes2 (Generic Resource Scheduler for Azure) zur Verfügung gestellt. Wenn Sie sich ein Bild darüber machen möchten, was es bedeutet, einen generischen Batch-Processor auf Basis von Web/Worker Roles zu implementieren, dann werfen Sie einen Blick auf den Sourcecode. Microsofts Empfehlung ist allerdings ganz klar die Nutzung von Azure Batch, anstatt alles selbst mit Web/Worker Roles umzusetzen.

Azure Websites

Web Jobs SDK

Websiteentwickler, die asynchrone Hintergrundverarbeitung in ihre Website integrieren möchten Entwickler mit einfachen Batch-Processing-Anforderungen, die mit den Ressourcen der Websiteinfrastruktur klar kommen Web Jobs SDK wurde Ende 2013 das erste Mal vorgestellt und ist eine unglaublich einfache und komfortable Variante des Batch-Processings auf Azure. Die Idee war es, Websiteentwicklern eine simple Möglichkeit zur Verfügung zu stellen, mit der sie einfache Hintergrundprozesse wie etwa das Generieren eines Dokuments oder das Verkleinern eines Bilds von der Kernwebsitelogik webbekommen. Web Jobs bieten dabei neben einem simplen SDK ein Job Dashboard mit vollwertigem Logging und Diagnostics – ziemlich cool also. Der einzige Haken: Web Jobs laufen auf denselben Compute Nodes wie Websites selbst. Natürlich kann man die Web Jobs und die Websites in separaten „Azure Websites“ verteilen, das bedeutet aber etwas mehr Aufwand und Koordination beim Deployment und Release Management. Persönlich bin ich dennoch ein Fan von Web Jobs und empfehle deren Verwendung, solange man mit den maximalen Skalierungsfaktoren von Websites (Large Instance Size, max. zehn Instances/Website) klarkommt. Web Jobs sind einfach zu implementieren – nämlich als Consolen-Anwendungen mit ein paar Assembly-Referenzen (im Falle von .NET, auch für andere Sprachen werden Libraries zur Verfügung gestellt). Abgesehen davon laufen Web Jobs SDK Executables auch ohne Probleme außerhalb von Azure – man braucht lediglich einen Azure-Storage-Account, der die Logs enthält.
Mobile Services Scheduler Mobile-Services-Entwickler und …Mobile-Services-Entwickler Hierbei handelt es sich um Batch-Processing, das innerhalb von Mobile Services abläuft. Insofern sind Fokus und Zielgruppe klar definiert. Eine generische Verwendung des Mobile Service Schedulers außerhalb eines Mobile Service ist nicht sinnvoll – dafür sollte man eine der anderen Varianten benutzen.
Azure Batch HPC-Entwickler Entwickler mit allen Arten von Batch-Processing-Anforderungen Entwickler mit Microsoft-Azure-Fokus Auf der TechEd EMEA 2014 im Oktober wurde Azure Batch als neuer Compute-Dienst angekündigt. Vereinfacht ausgedrückt stellt Azure Batch „HPC as a Service“ oder „Batch Processing as a Service“ dar. Sprich, man provisioniert einen Batchaccount und bekommt HTTP-REST-APIs zur Verfügung gestellt, mit denen Jobs gescheduled werden können. Für .NET-Entwickler gibt es natürlich auch einen .NET SDK. Jobs werden als Executables aller Art Implementiert. Azure Batch kümmert sich um nahezu alle Aspekte, die ich zuvor im Artikel angeführt habe (Auto Scaling, Job Binary Deployment, Instance Clean-up etc.). Einzig eine Funktionalität fehlt – und das sind „Eventartige“ Notifications über Jobstatusveränderungen. Aktuell muss man dafür also die Batch-APIs via Polling verwenden, um Jobupdates zu bekommen. Nichtsdestotrotz – Azure Batch ist das umfassendste und skalierbarste Service in diesem Bereich auf Microsoft Azure.

Tabelle 1: Batch-Processing-Optionen auf Microsoft Azure

Wer rein mit Microsoft Azure arbeitet, dem würde ich immer empfehlen, Batch-Processing mit Web Jobs SDK (Simple) oder Azure Batch (Highly Scalable) umzusetzen. Möchte man sich allerdings nicht an Azure binden, so stehen noch immer Open-Source-Projekte (GeRes2) oder auch das Windows-Server-HPC-Pack zur Verfügung.

[ header = Seite 2: Azure Batch ]

Azure Batch

Nachdem Azure Batch das brandneue Service in der Familie darstellt, möchte ich auf dieses genauer eingehen. Azure Batch selbst ist längst keine Version 1 und wird Microsoft-intern schon seit Jahren für das Scheduling und die Ausführung komplexer Jobs verwendet. So werden etwa Azure Media Services Encoding Jobs über Azure Batch koordiniert. Auch Visual Studio Online Build und Visual Studio Online Testing verwenden intern Azure Batch zur Ausführung der Build- und Test-Prozesse, die Sie über Visual Studio manuell oder automatisiert starten.

Seit Oktober 2014 können Sie diesen Service nun selbst nutzen, um komplexe Aufgaben asynchron im Hintergrund zu verarbeiten. Batch skaliert dabei von einfachen Aufgaben, die auf Small-Instanzen ablaufen können, bis hin zu komplexen HPC-orientierten Aufgaben, die auf tausend von Knoten mit größeren Instanzen (etwa A8/A9) ablaufen können. Dabei wird Batch als Service mit einem HTTP-REST-API zur Verfügung gestellt. Sie erstellen dazu im Azure-Portal einen neuen Batchservice, erhalten dann API Credentials und können mit diesen über einen API-Compute-Pool, Jobs und Tasks managen und ausführen sowie deren Ausführung durch Batch überwachen (Abb. 3).

Abb. 3: Azure Batch im Microsoft-Management-Portal

Hinweis: Zum Zeitpunkt der Verfassung dieses Artikels war Azure Batch ein Previewservice. Das heißt also, Sie müssen sich für die Batch-Preview anmelden, bevor Sie den Service in Ihrem Azure-Portal nutzen können – unter https://account.windowsazure.com/PreviewFeatures.

Haben Sie einen Batchaccount erstellt, können Sie den Service sofort nutzen. Alles, was Sie dazu benötigen, ist ein Visual-Studio-Projekt mit den Azure Batch Access Keys und den jeweiligen NuGet Packages. Die Keys erhalten Sie im Azure-Management-Portal durch einen Klick auf den in Abbildung 3 rot markierten Button. Das Verständnis von ein paar Grundkonzepten ist auch noch von Vorteil – siehe Tabelle 2.

Begriff Erklärung
Account Ein Batchservice, der isoliert von anderen Batchservices agiert und funktioniert. Die Absicherung des Service erfolgt primär auf Accountebene.
Job Ein Arbeitspaket (Unit of Work), das aus mehreren Tasks besteht, die zu einem bestimmten Zeitpunkt ausgeführt werden sollen.
Task Eine einzelne Aufgabe, die auf einem Compute Node ausgeführt werden soll – primär gekennzeichnet durch einen Kommandozeilenbefehl.
WorkItem Beschreibt eine Klasse von Jobs mit übergreifenden Eigenschaften für alle Jobs dieser Klasse. Hier können beispielsweise Scheduling-Zeiten spezifiziert werden.
Pool (Compute Pool) Eine Gruppe von (vielen) Virtual-Maschine-Instanzen, die zur Ausführung von Jobs/Tasks herangezogen werden können.
Task Virtual Machine Eine einzelne Virtual Machine, welche zur Ausführung einer Task herangezogen wird. Tatsächlich handelt es sich dabei um Worker Roles, da Azure Batch selbst mit Web/Worker Roles umgesetzt wurde.

Tabelle 2: Azure-Batch-Grundbegriffe

Ein typisches Azure-Batch-Projekt benötigt primär zwei Komponenten, die Sie entweder entwickeln oder bereits parat haben: • Task Executable: eine Kommandozeilenanwendung, die die eigentliche Task kapselt, die auf Compute Nodes ausgeführt werden soll. Dabei kann es sich um jede mögliche Art von Konsolenanwendung handeln, die mit jeder beliebigen Entwicklungsumgebung und Programmiersprache entwickelt wurde. Einzige Voraussetzung: die Anwendung muss ohne User-Interaktion auf einer Windows-Maschine ausführbar sein. • Azure Batch Client: eine Anwendung, die Jobs und deren Tasks zur Ausführung in Azure Batch abschickt und Ergebnisse abfragt. Dabei kann es sich auch um jede Art von Anwendung handeln: etwa eine Web- oder Desktop-Anwendung, eine App auf einem mobilen Geräten oder ein anderer Backend-Service, der auf einem Server läuft. Egal, ob diese Anwendung in Ihrem Rechenzentrum oder in Azure selbst läuft, sie verwendet das Azure-Batch-REST-API, um Jobs und Tasks zur Ausführung in Azure Batch abzuschicken. Im Task Executable benötigen Sie normalerweise keine speziellen Bibliotheken oder Libraries. Sie sollten lediglich auf einige Umgebungsvariablen und Verzeichnisstrukturen Rücksicht nehmen, die Azure Batch in den Task Virtual Machines (TVMs) für Sie einrichtet. Batch-Clients können gegen das REST-API von Azure Batch entwickelt werden. Für .NET-Entwickler stellt Microsoft NuGet-Packages mit .NET-Klassen zur Verfügung. SDKs werden auch für andere Sprachen bald folgen und die Nutzung von Batch vereinfachen. Nachfolgend sehen Sie anhand von Auszügen aus einem Beispiel, wie Sie Azure Batch grundsätzlich nutzen können. Dieses Beispiel implementiert eine OCR-Erkennung in Bildern mithilfe von Tesseract, einer frei verfügbaren Open-Source-OCR-Software. Die zu erkennenden OCR-Dokumente müssen dabei in einem Azure BLOB Storage vorrätig sein. Um diese schnell in die Cloud zu bekommen, wird der CloudBerry Storage Explorer empfohlen.

Welches NuGet nun?

Um einen Batchclient zu entwickeln, benötigen Sie das SDK für .NET in Ihrem Visual-Studio-Projekt – dieses steht via NuGet zur Verfügung. Allerdings stehen drei Azure-Batch-Pakete zur Auswahl (Abb. 4).

Abb. 4: Welches NuGet-Package solls denn sein?

Für unsere Zwecke verwenden wir das Package „Microsoft Azure Batch“. Die anderen NuGet-Packages beziehen sich auf einen weiteren Service von Azure Batch, der Higher-Level-APIs sowie ein Managementportal für Batchanwendungen umfasst. Dieses nennt sich Batch-Apps. In diesem Artikel bleiben wir allerdings auf den Lower-Level-Azure-Batch-APIs und Services, da Batch-Apps den Rahmen sprengen würde.

[ header = Seite 3: Into the Code ]

Into the Code

Um eine Task aus unserer Console-Anwendung in Batch ausführen zu können, benötigen wir zuerst die Credentials (Account Name und Account Key). Diese bekommen Sie über das Managementportal (Abb. 3, in rot hervorgehobener Button im Portal). Unser Beispiel geht davon aus, dass diese Eigenschaften im App.Config unserer Anwendung konfiguriert sind. Mit AccountKey und AccountName können wir einen Batchclient erzeugen, der dann gegen das HTTP-REST-API von Azure Batch arbeitet. Für Tasks benötigen wir natürlich auch einen Compute Pool. Den erstellen wir mithilfe des .NET SDK und der zuvor instanziierten BatchClient-Proxyklasse gleich mit. In Listing 1 sehen Sie diesen Code im Überblick.

Console.WriteLine("Creating batch client to access Azure Batch Service...");
var credentials = new BatchCredentials(AccountName, AccountKey);
var batchClient = BatchClient.Connect(
                  "https://batch.core.windows.net", 
                  credentials
                  );
Console.WriteLine("Batch client created successfully!");

Console.WriteLine("Creating pool if needed...");
using (IPoolManager pm = batchClient.OpenPoolManager())
{
  var pools = pm.ListPools().ToList();
  if (pools.Select(p => p.Name).Contains(PoolName) == false)
  {
    Console.WriteLine("Creating the pool...");
    var newPool = pm.CreatePool
    (
      poolName: PoolName,
      osFamily: "3",
      vmSize: "small",
      targetDedicated: 5
    );
    newPool.StartTask = new StartTask()
    {
      ResourceFiles = binaryResourceFiles, 
      CommandLine = "cmd /c CopyFiles.cmd",
      WaitForSuccess = true
    };
    newPool.Commit();
    Console.WriteLine("Pool windevmagmarioszppool created!");
  }
}

Interessant dabei ist der in Fett hervorgehobene Abschnitt, mit welchem eine Start-up-Task für die Erstellung der TVM definiert wird. Diese wird automatisch mit dem ersten Boot ausgeführt und ermöglicht es, schon vor der Ausführung der ersten Tasks notwendige Dateien und Verzeichnisse auf den TVMs vorzubereiten. In diesem Fall wird eine Liste von ResourceFiles übergeben. Diese müssen vorher im Programm definiert werden. In unserem Beispiel handelt es sich um die Binaries, die zu Tesseract gehören. Der dafür notwendige Code liest eine Liste von Dateien in einem Azure-BLOB-Container und baut die ResourceFile-Liste auf, wie Listing 2 zeigt. Für die ResourceFiles generieren wir dabei BLOB Shared Access Signatures, anstatt direkt ungesicherte URLs zu spezifizieren. Als Kommandozeile geben wir einfach ein Batch-File an, das die Dateien im Anschluss in ein „Shared Task Directory“ auf den TVMs kopiert, auf das alle Tasks, die auf TVMs ausgeführt werden, Zugriff haben. Optimal für die Tesseract Binaries. Ein Tipp am Rande: Das Innenleben der TVMs lässt sich perfekt mit dem Azure Batch Explorer (Verfügbar als Open-Source-Beispiel) analysieren (Abb. 5). Bei allen Tasks ist es wichtig, die vorgegebenen Verzeichnisstrukturen wie in der Batchdokumentation angeführt, zu beachten.

Abb. 5: Batch Explorer in Aktion (ein Open-Source-Beispiel vom Azure-Batch-Team)

var binaryResourceFiles = new List();
foreach (var resFile in 
  blobTesseractContainer.ListBlobs(useFlatBlobListing: true))
{
  var sharedAccessSig = 
    CreateSharedAccessSignature(blobTesseractContainer, resFile);
  var fullUriString = resFile.Uri.ToString();
  var relativeUriString = 
    ullUriString.Replace(blobTesseractContainer.Uri.ToString() + "/", "");
  
  binaryResourceFiles.Add(
    new ResourceFile
    (
      fullUriString + sharedAccessSig, 
      relativeUriString.Replace("/", @"")
    ) 
  ); 
}

Nachdem der Pool erstellt wurde, können wir Jobs und Tasks im Compute Pool ausführen. Die notwendigen Dateien zur Ausführung unseres Jobs haben wir bereits mit der Start-up-Task auf den Instanzen vorbereitet. Der Code zum Scheduling eines Jobs mit mehreren Tasks ist vergleichbar einfach, wie Listing 3 darstellt.

using (IWorkItemManager wiMgr = batchClient.OpenWorkItemManager())
{
  var workItemName = string.Format("ocr-{0}", DateTime.UtcNow.Ticks);
  var ocrWorkItem = wiMgr.CreateWorkItem(workItemName);
  ocrWorkItem.JobExecutionEnvironment =
    new JobExecutionEnvironment
  {
    PoolName = PoolName
  };
  ocrWorkItem.CommitAsync().Wait();

  var taskNr = 0;
  const string defaultJobName = "job-0000000001";
  var job = wiMgr.GetJob(workItemName, defaultJobName);
  
  foreach (var ocrFile in filesToProcess)
  {
    var taskName = string.Format("task_no_{0}", taskNr++);
    var taskCmd = string.Format(
      "cmd /c %WATASK_TVM_ROOT_DIR%\
      shared\BatchTesseractWrapper.exe "{0}" "{1}"",
      ocrFile.BlobSource,
      Path.GetFileNameWithoutExtension(ocrFile.FilePath));
    ICloudTask cloudTask = new CloudTask(taskName, taskCmd);
    job.AddTask(cloudTask);
  }
  job.Commit();
}

Die Erstellung eines Jobs passiert implizit bei der Erstellung des WorkItems. Das WorkItem selbst kann man dazu verwenden, z. B. Jobs zeitgesteuert immer wieder auszuführen oder allgemeine Einstellung für alle Jobs eines WorkItems festzulegen. Wenn man das nicht benötigt, kann man einfach den standardmäßig erstellten Job job-0000000001 aus dem neu erstellten WorkItem für das Task-Scheduling verwenden. Was der Sourcecode in Listing 3 auch macht. Die Tasks selbst sind einfache Executables. Dabei wird in unserem Beispiel für jede Datei, die sich in einem bestimmtem Azure-BLOB-Storage-Container befindet, eine Task erstellt und zum Job hinzugefügt. Die Tasks nehmen die OCR-Erkennung einzelner Dateien vor, der Job nimmt somit die OCR-Erkennung einer Vielzahl von Dateien vor. Mit Job.Commit() beginnt schlussendlich die Ausführung der Tasks im Job. In meinem Beispielprogramm rufen wir dabei Tesseract zur OCR-Erkennung nicht direkt auf, wie anhand des Commands für die Tasks ersichtlich ist. Stattdessen habe ich einen Console-Wrapper um Tesseract entwickelt (BatchTesseractWrapper.exe), der die im ersten Parameter angegebene Datei vom Blob Storage herunterlädt, dagegen Tesseract aufruft und das Ergebnis mit einem im zweiten Parameter spezifizierten Namen wieder in einen Azure-BLOB-Storage-Container hoch lädt. Der Wrapper wird dabei aus dem mit den Start-up-Tasks aus Listing 1 vorbereiteten Verzeichnissen aus dem Task Root Directory aufgerufen (das von Azure Batch vorgegeben und durch die Environment Variable WATASK_TVM_ROOT_DIR abfragbar ist). Vom Azure BLOB Storage können die Ergebnisse zur Weiterverarbeitung abgeholt werden. Das entspricht also genau dem Vorgang aus Abbildung 1.

Fazit

Damit ist der erste Einblick in die Low-Level-APIs von Azure Batch auch schon abgeschlossen. Bedenkt man, was Azure Batch für alles tut (Compute Node Management, Binary Deployments auf Compute Nodes, Retry Logik, Scheduling entsprechend der Auslastung von Compute Nodes, Auto Scaling etc.), dann ist es unglaublich, mit wie wenig Zeilen Code man starten kann. Das vollständige Beispiel werde ich demnächst über meinen Blog zur Verfügung stellen. Wem die Low-Level-APIs zu kompliziert sind, der bekommt mit Azure-Batch-Apps ein noch einfacheres API mit einem Managementportal zur Verfügung gestellt. Abschließend bleibt noch zu sagen, dass neben Azure Batch auch noch andere Möglichkeiten zur Batchverarbeitung auf Microsoft Azure zur Verfügung stehen – manche einfacher wie etwa Web Jobs SDK, dafür allerdings nicht so hoch skalierbar wie etwa Batch. Andere erfordern mehr Infrastrukturmanagement (Stichwort HPC Pack), ermöglichen aber die Umsetzung von Hybrid-Deployments, die teilweise in Ihrem Rechenzentrum und teilweise in Azure laufen. Generell rate ich aber allen, Azure Batch zu bevorzugen, da es sich dabei um ein Managed Service, quasi Batch Processing as a Service, handelt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -