Zuverlässigkeit im Azure VM Image Builder

Azure VM Image Builder ist ein verwalteter Dienst, der VM-Images erstellt und anpasst und anschließend die resultierenden Images an Ziele wie Azure Compute Gallery oder virtuelle Festplatten (VHDs) in Azure Blob Storage verteilt. Für den Dienst ist es nicht erforderlich, eine langlebige Buildinfrastruktur aufrechtzuerhalten.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Azure VM Image Builder für verschiedene potenzielle Ausfälle und Probleme widerstandsfähig machen, einschließlich vorübergehender Fehler, Verfügbarkeitszonenfehler, regionsweite Fehler und Dienstwartung. Darüber hinaus werden Sicherungs- und Wiederherstellungsoptionen, benutzerdefinierte Multiregion-Lösungen und wichtige Informationen zum Azure Vm Image Builder Service-Level Agreement (SLA) beschrieben.

Bereitstellungsempfehlungen für die Produktion

Berücksichtigen Sie beim Entwerfen einer Pipeline zum Erstellen von Produktions-Images die folgenden Empfehlungen:

  • Definieren Sie Ihre Bildvorlagen mithilfe der Infrastruktur als Code, z. B. Bicep oder Terraform, und speichern Sie die Definitionen in der Quellcodeverwaltung.

  • Verteilen Sie fertige Images auf die Regionen, in denen Ihre Workloads ausgeführt werden, z. B. durch die Replikation von Azure Compute Gallery, um unnötige regionsübergreifende Abhängigkeiten bei der VM-Erstellung, beim Aufskalieren und bei Reimaging-Vorgängen zu vermeiden.

  • Speichern Sie Anpassungsskripts, Pakete und andere Buildabhängigkeiten in einem Speicher, der die Redundanzmerkmale aufweist, die Ihre Workload erfordert.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Wenn Sie vm Image Builder verwenden, stellen Sie eine Imagevorlage in einer einzelnen Azure Region bereit, die zur Heimatregion der Vorlage wird.

Nachdem Sie die Vorlage erstellt haben, führen Sie einen Build aus, der eine Reihe von Schritten ausführt, um das VM-Image zu erstellen. Diese Schritte können Skripts ausführen oder Pakete enthalten, die Sie in das Bild einbetten möchten.

Der Dienst erstellt oder verwendet eine Stagingressourcengruppe und stellt die Buildinfrastruktur in Ihrem Abonnement bereit. Nach dem Build entfernt der Dienst temporäre Ressourcen, einschließlich der Build-VM und der zugehörigen Netzwerkressourcen. Die Stagingressourcengruppe und die zugehörigen Speicherressourcen bleiben solange bestehen, wie die Bildvorlagenressource vorhanden ist.

Der VM Image Builder verteilt das fertige Image an ein oder mehrere von Ihnen angegebene Ziele. Zu den allgemeinen Zielen gehören:

  • Azure Compute Gallery (früher bekannt als Shared Image Gallery): Compute Gallery bietet die regionsübergreifende Replikation von VM-Images. Sie können z. B. ein Image in einer Region erstellen und die resultierende Azure Compute Gallery-Imageversion an mehrere Zielregionen verteilen.

  • Azure Blob Storage: Der Dienst kann die VHD im Speicherkonto speichern, das vom VM Image Builder bereitgestellt wird, oder in einem von Ihnen angegebenen Speicherkonto und BLOB-Container.

    Wenn Sie das vom Dienst verwaltete Speicherkonto als VHD-Verteilungsziel verwenden, speichert der Dienst die VHD in der Stagingressourcengruppe. Wenn Sie die Bildvorlage löschen, löscht der Dienst auch die VHD. Um die VHD unabhängig von der Bildvorlage beizubehalten, verteilen Sie sie an ein benutzerdefiniertes Speicherkonto, oder kopieren Sie sie an einen anderen Speicherort, bevor Sie die Vorlage löschen.

Azure Compute Gallery und Blob Storage sind separate Dienste vom VM Image Builder. Sie können Bilder an mehrere Ziele verteilen, einschließlich Der Ziele in verschiedenen Azure Regionen. Mit diesem Verteilungsmodell können Sie die Region, in der Sie ein Image erstellen, von den Regionen trennen, in denen Sie dieses Image nutzen.

Note

VM Image Builder unterstützt auch Managed Images, bei denen es sich um ein Legacy-Verteilungsziel handelt. In diesem Artikel werden keine verwalteten Bilder behandelt. Verwenden Sie für Produktionsszenarien Azure Compute Gallery.

Physische Architektur

VM Image Builder verwendet isolierte Imagebuilds , um die Kernabbildanpassung und den Validierungsprozess auszuführen. Der Dienst stellt eine dedizierte Azure Container Instances Ressource und eine Build-VM in der Stagingressourcengruppe in Ihrem Abonnement bereit. Die Container Instances Ressource führt HashiCorp Packer aus, um das Image anzupassen und zu überprüfen, und der VM Image Builder koordiniert den Build.

Um Imagebuilds auszuführen, registrieren Sie den Microsoft.ContainerInstance Ressourcenanbieter, und stellen Sie sicher, dass Ihr Abonnement über genügend Container Instances Kontingent verfügt. Weitere Informationen zur Dienstarchitektur, unterstützten Regionen und Buildprozess finden Sie unter Übersicht über Azure VM Image Builder.

Separate Azure-Dienste, z. B. Azure Compute Gallery und Blob Storage, speichern fertige Bilder. Konfigurieren Sie jedes Verteilungsziel, um Ihre Resilienzanforderungen zu erfüllen.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

In der Regel interagieren Sie mit Azure VM Image Builder mithilfe des Azure-Portals, Azure CLI, Azure PowerShell oder der Infrastruktur als Code wie Bicep. Ihre Buildpipeline ist für die Behandlung vorübergehender Fehler verantwortlich. Wenn Azure Resource Manager eine vorübergehende Fehlerantwort zurückgibt, wiederholen Sie die Anforderung mit dem entsprechenden Backoff.

Wenn ein Build fehlschlägt, überprüfen Sie dessen lastRunStatus, die Anpassungs- und Überprüfungsprotokolle sowie die Ausgaben der Verteilungsausführung, bevor Sie ihn erneut ausführen. Anhand dieser Details können Sie ermitteln, ob ein vorübergehender Fehlerzustand, ein Anpassungsschritt oder ein Vorgang zur Bildverteilung den Fehler verursacht hat. Weitere Informationen finden Sie unter Problembehandlung bei Buildfehlern des VM-Image-Generators.

Buildvorgänge können auch von externen Systemen abhängen, z. B. Speicherkonten, Paketrepositorys, Quellimagespeicherorte und Verteilungsziele. Entwerfen Sie Ihre Anpassungsschritte und Pipelines, um Wiederholungsversuche nach einem temporären Netzwerk-, Plattform- oder Abhängigkeitsproblem zu unterstützen.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Buildvorgänge und fertige Images verhalten sich bei Zonenfehlern unterschiedlich.

  • Builds: Vm Image Builder unterstützt keine Verfügbarkeitszonen und bietet keine Zonenresilienzgarantie für Imagevorlagen oder Buildvorgänge. Wenn sich ein Zonenfehler auf Ressourcen auswirkt, die von einem Build verwendet werden, kann der Build möglicherweise nicht gestartet oder unterbrochen werden. VM Image Builder verschiebt den Build nicht automatisch in eine andere Zone.

    Wenn Sie Imagebuilds während Zonenausfällen ausführen müssen, stellen Sie Ihre Imagevorlagen und unterstützende Ressourcen in mehreren Azure-Regionen bereit. Weitere Informationen finden Sie unter Benutzerdefinierte Multiregion-Lösungen zur Resilienz.

  • Bilder: Fertige Bilder bleiben verfügbar, wenn ihr Speicher zonensicher ist.

    • Azure Compute Gallery: Azure Compute Gallery-Bildversionen können zonenredundanten Speicher (ZRS) in Zielbereichen verwenden, die Verfügbarkeitszonen unterstützen. Wählen Sie für jede Zielregion ZRS als Replikationstyp des Speicherkontos aus. Der Standardwert ist lokal redundanter Speicher (LRS), der nicht widerstandsfähig für Zonenfehler ist. Weitere Informationen finden Sie unter Azure Compute Gallery high availability.

    • VHDs in Azure Blob Storage: Wenn Sie kein benutzerdefiniertes Speicherkonto verwenden, erstellt VM Image Builder standardmäßig ein ZRS-Speicherkonto in Regionen, die Verfügbarkeitszonen unterstützen. Wenn Sie ein benutzerdefiniertes Speicherkonto verwenden, sind Sie für die Konfiguration der Redundanz verantwortlich, um Ihre Anforderungen zu erfüllen. Verwenden Sie ZRS, um Kopien der VHD in mehreren Verfügbarkeitszonen zu speichern. Weitere Informationen zur Funktionsweise von ZRS finden Sie unter Zuverlässigkeit in Azure Blob Storage.

Widerstandsfähigkeit bei regionalen Ausfällen

Buildvorgänge und fertige Bilder verhalten sich bei regionalen Ausfällen anders.

  • Builds: Azure VM Image Builder ist ein Einzelregionsdienst und bietet kein integriertes Multiregion-Failover. Wenn die Region, in der Ihre Bildvorlage gehostet wird, nicht verfügbar ist, sind die Bildvorlage und buildvorgänge in dieser Region ebenfalls nicht verfügbar. Der Dienst schaltet nicht automatisch auf eine andere Region um.

    Wenn Sie Imagebuilds während Regionsausfällen ausführen müssen, stellen Sie Ihre Imagevorlagen und unterstützende Ressourcen in mehreren Azure-Regionen bereit. Weitere Informationen finden Sie unter Benutzerdefinierte Multiregion-Lösungen zur Resilienz.

  • Bilder: Fertige Bilder bleiben verfügbar, wenn ihr Speicher gegenüber regionenweiten Ausfällen widerstandsfähig ist.

    • Azure Compute Gallery: Sie können Azure Compute Gallery konfigurieren, um Bildversionen in mehrere Regionen zu replizieren. Die Replikation ist asynchron, und Sie können eine Imageversion in einer Zielregion nur verwenden, nachdem die Replikation für diese Region abgeschlossen wurde.

      Während eines Ausfalls in einer Region bleiben abgeschlossene Replikate für VM-Bereitstellungen in fehlerfreien Zielregionen verfügbar. Wenn die Region, die die Galerieressource enthält, jedoch nicht verfügbar ist, können Sie keine Galerieressourcen erstellen oder aktualisieren. Wenn Sie während eines Regionsausfalls weiterhin Imageversionen veröffentlichen müssen, verwalten Sie separate Kataloge in separaten Buildregionen. Weitere Informationen finden Sie unter Azure Compute Gallery-Replikation und bewährte Methoden.

    • VHDs in Azure Blob Storage: Das standardmäßige vom Dienst verwaltete VHD-Ziel bietet keine Georedundanz. In Regionen, die Verfügbarkeitszonen unterstützen, wird ZRS verwendet, was nicht vor einem regionalen Ausfall schützt.

      In einer Region mit einer gekoppelten Region können Sie die VHD an ein benutzerdefiniertes Speicherkonto verteilen, das georedundanten Speicher (GRS) oder geozonenredundanten Speicher (GZRS) verwendet. Read-Access GRS (RA-GRS) und Lesezugriff GZRS (RA-GZRS) bieten schreibgeschützten Zugriff über einen sekundären Endpunkt, führen jedoch kein Failover durch. Um den normalen Lese-/Schreibzugriff in der gekoppelten Region wiederherzustellen, initiieren Sie ein vom Kunden verwaltetes Failover, oder kopieren Sie die VHD vom sekundären Endpunkt in ein separates Speicherkonto. Georeplikation ist asynchron, sodass bei einem ungeplanten Failover möglicherweise Daten verloren gehen, die nicht repliziert wurden. Überprüfen Sie nach Möglichkeit vor einem Failover die Eigenschaft „Letzte Synchronisierungszeit“ des Speicherkontos.

      Weitere Informationen zum Blob Storage-Failoververhalten und alternativen Ansätzen zum Replizieren von Daten zwischen nicht gekoppelten Regionen finden Sie unter Zuverlässigkeit in Azure Blob Storage.

Benutzerdefinierte Multiregion-Lösungen für Resilienz

Wenn Sie während eines Regionsausfalls weiterhin Images erstellen müssen, sind Sie für die Bereitstellung und den Betrieb unabhängiger Buildumgebungen in mehreren Regionen verantwortlich.

Wählen Sie Regionen aus, die vm Image Builder unterstützen. Stellen Sie in jeder Buildregion eine Bildvorlage und ihre regionsspezifischen Abhängigkeiten vorab bereit, einschließlich verwalteter Identitäten und Rollenzuweisungen, Netzwerkkonfiguration, Anpassungsartefakte, Quellimage oder Imagereplikat und Verteilungsziele.

Wenn Sie Bilder veröffentlichen müssen, während die Region einer Gallery nicht verfügbar ist, verwenden Sie eine unabhängige Compute Gallery-Ressource in jedem Buildbereich. Das Replizieren von Bildversionen aus einer einzigen Galerie macht die Galerie nicht zu einer vollständigen Multiregionsressource.

Definieren Sie diese Ressourcen mithilfe der Infrastruktur als Code, und behandeln Sie diese Definitionen als Wahrheitsquelle. Halten Sie die regionalen Umgebungen synchronisiert, wenn sich die Konfiguration ändert, und testen Sie regelmäßig, dass jede Umgebung ein Image erstellen und verteilen kann.

Sichern und Wiederherstellen

Azure VM Image Builder ersetzt ihren Sicherungs- und Wiederherstellungsvorgang nicht. In den meisten Fällen ist das Artefakt, das für die Wiederherstellung wichtig ist, das fertige Bild, das Sie in Azure Compute Gallery oder VHD-Speicher veröffentlichen.

Befolgen Sie die folgenden Empfehlungen, um die Wiederherstellung nach Datenbeschädigung oder einem länger andauernden ungeplanten Ausfall zu verbessern:

  • Behalten Sie veröffentlichte Images in Azure Compute Gallery oder anderen Verteilungszielen gemäß Ihren Aufbewahrungsanforderungen bei.

  • Wenn Sie eine VHD erstellen und das Standard-VHD-Ziel verwenden, kopieren Sie die VHD in Ihren eigenen dauerhaften Speicher, bevor Sie die Bildvorlage löschen.

  • Verwenden Sie die Quellcodeverwaltung, um Imagevorlagendefinitionen zu speichern und zu versionieren.

  • Verwenden Sie die Quellcodeverwaltung oder einen anderen Typ dauerhaften Speichers, um Anpassungsskripts und -pakete zu speichern und zu versionieren.

  • Überprüfen Sie regelmäßig, ob jede vorab bereitgestellte Wiederherstellungsumgebung ein Image erstellen und verteilen kann.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft verwaltet die Wartung für Azure VM Image Builder. Der VM Image Builder dient zur Laufzeit nicht dem Anwendungsdatenverkehr. Daher wirkt sich die Wartung nicht auf VMs aus, die Sie bereits aus veröffentlichten Images erstellt haben. Wenn ein Build während der Wartung oder eines anderen Dienstereignisses verzögert oder unterbrochen wird, prüfen Sie den Status und die Protokolle, und führen Sie ihn erneut aus.

Verwenden Sie Azure Service Health, um geplante Wartungs- und Dienstvorfälle zu überwachen, die sich auf Ihre Buildregion auswirken können.

Service-Level-Vereinbarung

Azure VM Image Builder bietet keine Vereinbarung zum Servicelevel (SLA) für die Verfügbarkeit.

Jede SLA, die für ein Verteilungsziel oder einen Speicherdienst gilt, gilt separat und stellt keine Verfügbarkeitsverpflichtung für VM Image Builder-Vorlagen oder Buildvorgänge bereit.

Verwandte Inhalte

  • Zuletzt aktualisiert um