Aktualisieren eines Azure Cloud Service (klassisch)

Der Prozess zum Aktualisieren eines Clouddiensts, einschließlich seiner Rollen und des Gastbetriebssystems, umfasst drei Schritte. Zuerst müssen die Binär- und Konfigurationsdateien für den neuen Clouddienst oder die Version des Betriebssystems hochgeladen werden. Als nächstes reserviert Azure Compute- und Netzwerkressourcen für den Clouddienst, je nach den Erfordernissen der neuen Clouddienstversion. Und zuletzt führt Azure ein paralleles Update aus, um den Mandanten inkrementell auf die neue Version oder das Gastbetriebssystem zu aktualisieren und Ihre Verfügbarkeit dabei beizubehalten. Dieser Artikel behandelt die Details dieses letzten Schritts – das schrittweise Upgrade.

Aktualisieren eines Azure-Diensts

Azure organisiert Ihre Rolleninstanzen in logischen Gruppen, die als Upgradedomänen (UD) bezeichnet werden. Upgradedomänen (UD) sind logische Sätze von Rolleninstanzen, die als Gruppe aktualisiert werden. Azure aktualisiert einen Clouddienst mit je einer UD. Dadurch können Instanzen in anderen UDs den Datenverkehr weiter bearbeiten.

Die Standardanzahl von Upgradedomänen ist 5. Sie können eine andere Anzahl von Upgradedomänen festlegen, indem Sie das Attribut „upgradeDomainCount“ in die Dienstdefinitionsdatei (.CSDEF) einschließen. Weitere Informationen zum Attribut upgradeDomainCount finden Sie unter Azure Cloud Services-Definitionsschema (.CSDEF-Datei).

Wenn Sie ein direktes Update einer oder mehrerer Rollen in Ihrem Dienst durchführen, aktualisiert Azure Sätze von Rolleninstanzen je nach der Upgradedomäne, der sie angehören. Azure aktualisiert alle Instanzen in einer bestimmten Upgradedomäne (beendet sie, aktualisiert sie und schaltet sie wieder online) und fährt dann mit der nächsten Domäne fort. Dadurch, dass nur die Instanzen beendet werden, die in der aktuellen Upgradedomäne ausgeführt werden, stellt Azure sicher, dass sich die Aktualisierung so wenig wie möglich auf den ausgeführten Dienst auswirkt. Weitere Informationen finden Sie unter Vorgehensweise bei der Aktualisierung weiter unten in diesem Artikel.

Damit eine Rolle im laufenden Betrieb ohne Ausfallzeiten aktualisiert werden kann, muss Ihr Dienst mindestens zwei Instanzen dieser Rolle definieren. Wenn der Dienst aus nur einer Instanz einer Rolle besteht, ist Ihr Dienst nicht verfügbar, bis das direkte Update abgeschlossen ist.

In diesem Artikel werden die folgenden Informationen zu Azure-Updates behandelt:

• Zulässige Dienständerungen während einer Aktualisierung
• Vorgehensweise beim Upgrade
• Rückgängig machen eines Updates
• Einleiten mehrerer mutierender Operationen während einer laufenden Bereitstellung
• Verteilung von Rollen über Upgradedomänen

Zulässige Dienständerungen während einer Aktualisierung

Die folgende Tabelle zeigt die zulässigen Änderungen an einen Dienst während einer Aktualisierung an:

¹Größenänderung beschränkt auf die Teilmenge der Größen, die für den Clouddienst verfügbar sind.

²Erfordert Azure SDK 1.5 oder höher.

Die folgenden Elemente werden während eines Update nicht unterstützt:

• Ändern des Namens einer Rolle Entfernen Sie die Rolle und fügen Sie sie dann mit dem neuen Namen hinzu.
• Änderung der Anzahl der Upgradedomänen
• Verringern der Größe der lokalen Ressourcen

Wenn Sie andere Updates an der Definition Ihres Dienstes vornehmen, wie z. B. die Größe der lokalen Ressourcen verringern, müssen Sie stattdessen ein VIP-Swap-Update durchführen. Weitere Informationen finden Sie in Swap Deployment.

Vorgehensweise beim Upgrade

Sie können entweder alle oder eine einzelne Rolle in Ihrem Dienst aktualisieren. In beiden Fällen werden alle Instanzen jeder Rolle, die aktualisiert wird und der ersten Upgradedomäne angehört, beendet, aktualisiert und dann wieder online geschaltet. Wenn sie wieder online sind, werden die Instanzen in der zweiten Upgradedomäne beendet, aktualisiert und wieder online geschaltet. In einem Clouddienst kann höchstens eine Aktualisierung gleichzeitig aktiv sein. Das Upgrade erfolgt immer auf die letzte Version des Clouddiensts.

Die folgende Abbildung zeigt, wie das Upgrade durchgeführt wird, wenn Sie alle Rollen im Dienst aktualisieren:

Die nächste Abbildung zeigt, wie das Update durchgeführt wird, wenn Sie nur eine Rolle aktualisieren:

Während einer automatischen Aktualisierung wertet der Azure Fabric Controller in regelmäßigen Abständen die Integrität des Clouddiensts aus, um zu bestimmen, wann die nächste UD durchlaufen werden kann. Diese Gesundheitsbewertung erfolgt pro Rolle und berücksichtigt nur Instanzen in der neuesten Version, d. h. Instanzen von aktualisierten Domänen, die bereits durchlaufen wurden. Überprüft wird, ob für jede Rolle eine Mindestanzahl von Rolleninstanzen einen zufriedenstellenden Endzustand erreicht hat.

Starttimeout für Rolleninstanz

Der Fabric-Controller wartet bei jeder Rolleninstanz 30 Minuten darauf, dass der Zustand „Gestartet“ erreicht wird. Nach Ablauf des Zeitlimits geht der Fabric Controller zur nächsten Rolleninstanz über.

Auswirkung auf Laufwerksdaten während eines Clouddienstupgrades

Wenn Sie einen Dienst von einer einzelnen Instanz auf mehrere Instanzen aktualisieren, führt Azure Ihre Dienste herunter, während das Upgrade ausgeführt wird. Die Vereinbarung zum Servicelevel mit gewährleisteter Dienstverfügbarkeit gilt nur für Dienste, die mit mehr als eine Instanz bereitgestellt werden. In der folgenden Liste wird beschrieben, wie sich jedes Upgradeszenario eines Azure-Diensts auf die Daten auf den einzelnen Laufwerken auswirkt:

In der vorherigen Liste stellt das Laufwerk „E:“ das Root-Laufwerk der Rolle dar und sollte nicht fest kodiert werden. Verwenden Sie stattdessen die Umgebungsvariable % RoleRoot% , um das Laufwerk darzustellen.

Stellen Sie einen neuen Dienst mit mehreren Instanzen auf dem Staging-Server bereit, und führen Sie einen VIP-Austausch aus, um die Ausfallzeit bei der Aktualisierung eines Einzelinstanzdiensts zu minimieren.

Zurücksetzen eines Updates

Azure ist bei der Verwaltung von Diensten während eines Updates flexibel, da Sie weitere Vorgänge für einen Dienst initiieren können, nachdem die ursprüngliche Updateanforderung vom Azure Fabric-Controller akzeptiert wurde. Eine Zurücksetzung kann nur ausgeführt werden, wenn sich ein Update (Konfigurationsänderung) oder ein Upgrade für die Bereitstellung im Status In Bearbeitung befindet. Ein Update oder Upgrade gilt als in Bearbeitung, wenn mindestens eine Instanz des Diensts noch nicht auf die neue Version aktualisiert wurde. Um zu testen, ob ein Rollback zulässig ist, überprüfen Sie, ob der Wert des RollbackAllowed-Flags TRUE lautet. Die Vorgänge Bereitstellung abrufen und Clouddiensteigenschaften abrufen geben das RollbackAllowed-Flag zurück.

Das Zurücksetzen einer Aktualisierung in Bearbeitung wirkt sich folgendermaßen auf die Bereitstellung aus:

• Alle Rolleninstanzen, für die noch kein Update/Upgrade auf die neue Version durchgeführt wurde, werden nicht aktualisiert, da diese Instanzen bereits die Zielversion des Diensts ausführen.
• Rolleninstanzen, für die bereits ein Update oder Upgrade auf die neue Version der Dienstpaketdatei (*.cspkg) und/oder der Dienstkonfigurationsdatei (*.cscfg) durchgeführt wurde, werden vor dem Upgrade auf die Version dieser Dateien zurückgesetzt.

Die folgenden Features bieten diese Funktionalität:

• Der Vorgang Rollback-Operation für Update oder Upgrade kann bei einem Konfigurationsupdate (ausgelöst durch Aufrufen von Bereitstellungskonfiguration ändern) oder bei einem Upgrade (ausgelöst durch Aufrufen von Bereitstellung upgraden) aufgerufen werden, solange mindestens eine Instanz im Dienst noch nicht auf die neue Version aktualisiert wurde.

• Als Teil des Antworttexts der Vorgänge Bereitstellung abrufen und Clouddiensteigenschaften abrufen werden die Elemente „Locked“ und „RollbackAllowed“ zurückgegeben:

  1. Das „Locked“-Element ermöglicht es Ihnen, zu erkennen, wann ein Änderungsvorgang für eine bestimmte Bereitstellung aufgerufen werden kann.
  2. Das Element „RollbackAllowed“ gib an, wann der Vorgang Zurücksetzen der Aktualisierung oder des Upgrades für eine bestimmte Bereitstellung aufgerufen werden kann.

  Zum Durchführen eines Rollbacks müssen Sie nicht die beiden Elemente „Locked“ und „RollbackAllowed“ überprüfen. Es ist ausreichend, wenn Sie sicherstellen, dass „RollbackAllowed“ auf „true“ festgelegt ist. Diese Elemente werden nur ausgegeben, wenn diese Methoden mithilfe des Anforderungsheaders aufgerufen werden und dieser auf „x-ms-version: 2011-10-01“ oder höher festgelegt ist. Weitere Informationen zu Versionsverwaltungsheadern finden Sie unter Versionsverwaltung im klassischen Bereitstellungsmodell.

In den folgenden Situationen wird ein Rollback eines Updates oder Upgrades nicht unterstützt:

• Verringerung lokaler Ressourcen: Wenn das Update die lokalen Ressourcen für eine Rolle vergrößert, ermöglicht die Azure-Plattform keinen Rollback.
• Kontingentgrenzen – Wenn die Aktualisierung ein Vorgang zum Herunterskalieren war, ist Ihr Rechenkontingent für den Rücksetzungsvorgang unter Umständen nicht mehr ausreichend. Jedem Azure-Abonnement ist ein Kontingent zugeordnet. Das Kontingent gibt die maximale Anzahl Kerne an, die alle gehosteten Dienste dieses Abonnements nutzen können. Wenn durch das Rollback eines Updates das Kontingent für Ihr Abonnement überschritten wird, ist kein Rollback nicht möglich.
• Racebedingung: Wenn das ursprüngliche Update abgeschlossen wurde, ist kein Rollback möglich.

Ein Rollback eines Updates ist beispielsweise nützlich, wenn Sie den Vorgang Upgrade für Bereitstellung durchführen im manuellen Modus ausführen, um die Rate zu steuern, mit der ein umfangreiches direktes Upgrade für Ihren von Azure gehosteten Dienst zurückgesetzt wird.

Rufen Sie während des Rollouts des Upgrades im manuellen Modus Upgrade-Bereitstellung auf, und arbeiten Sie die Upgradedomänen ab. Wenn Sie beim Überwachen des Upgrades feststellen, dass einige Rolleninstanzen in den ersten Upgradedomänen nicht reagieren, können Sie den Vorgang Rollback-Update oder -Upgrade für die Bereitstellung aufrufen. Dieser Vorgang hat keine Auswirkungen auf Instanzen, die nicht aktualisiert werden, sondern er führt ein Rollback der aktualisierten Instanzen auf das vorherige Dienstpaket und die vorherige Konfiguration durch.

Initiieren mehrerer Änderungsvorgänge für eine laufende Bereitstellung

In einigen Fällen könnten Sie möglicherweise mehrere Änderungsprozesse gleichzeitig bei einer aktuellen Bereitstellung initiieren. Sie können z. B. ein Dienstupdate ausführen, und während des Rollouts des Updates für Ihren Dienst einige Änderungen vornehmen, z. B. ein Rollback des Updates durchführen, ein anderes Update anwenden oder sogar die Bereitstellung löschen. Ein Fall, in dem dieses Szenario eintreten könnte, ist, wenn bei einem Dienstupgrade fehlerhafter Code enthalten ist, der dazu führt, dass eine aktualisierte Rolleninstanz wiederholt abstürzt. In diesem Fall macht der Azure Fabric-Controller keine Fortschritte beim Anwenden des Upgrades, da keine ausreichende Anzahl Instanzen in der aktualisierten Domäne fehlerfrei ist. Dieser Status wird als eine unterbrochene Bereitstellung bezeichnet. Sie können die Bereitstellung lösen, indem Sie die Aktualisierung zurücksetzen oder eine neue Aktualisierung über die fehlerhafte anwenden.

Nachdem der Azure Fabric-Controller die ursprüngliche Update- oder Upgradeanforderung des Diensts erhalten hat, können Sie Änderungen vornehmen. Sie müssen also nicht warten, bis der erste Vorgang abgeschlossen ist, bevor Sie einen anderen Änderungsvorgang starten.

Wenn Sie einen zweiten Updatevorgang initiieren, während das erste Update noch ausgeführt wird, dann wird dies ähnlich wie beim Rollbackvorgang ausgeführt. Wenn Sie das zweite Update im automatischen Modus ausführen, wird die erste Upgradedomäne sofort aktualisiert. Dadurch sind Instanzen mehrerer Upgradedomänen möglicherweise gleichzeitig offline.

Verfügbare Änderungsvorgänge: Bereitstellungskonfiguration ändern, Upgrade für Bereitstellung durchführen, Bereitstellungsstatus aktualisieren, Bereitstellung löschen und Zurücksetzen der Aktualisierung oder des Upgrades.

Die beiden Vorgänge Bereitstellung abrufen und Clouddiensteigenschaften abrufen geben das Locked-Flag zurück. Sie können das Locked-Flag überprüfen, um zu bestimmen, ob Sie einen Änderungsvorgang für eine bestimmte Bereitstellung aufrufen können.

Wenn Sie die Version dieser Methoden aufrufen möchten, die das Locked-Flag ausgibt, müssen Sie den Anforderungsheader auf „x-ms-version: 2011-10-01“ oder höher festlegen. Weitere Informationen zu Versionsverwaltungsheadern finden Sie unter Versionsverwaltung im klassischen Bereitstellungsmodell.

Verteilung von Rollen über Upgradedomänen

Azure verteilt Instanzen einer Rolle gleichmäßig über eine festgelegte Anzahl von Upgradedomänen, die als Teil der Dienstdefinitionsdatei (.csdef) konfiguriert werden können. Die maximale Anzahl von Upgradedomänen ist 20, der Standardwert ist 5. Weitere Informationen zum Ändern der Dienstdefinitionsdatei finden Sie unter Azure-Dienstdefinitionsschema (CSDEF-Datei).

Wenn Ihre Rolle z. B. zehn Instanzen umfasst, enthält jede Upgradedomäne standardmäßig zwei Instanzen. Wenn Ihre Rolle 14 Instanzen umfasst, dann enthalten vier Upgradedomänen drei Instanzen, und eine fünfte Domäne enthält zwei.

Upgradedomänen werden anhand eines nullbasierten Index identifiziert: Die erste Upgradedomäne hat die ID „0“, die zweite Upgradedomäne hat die ID „1“ und so weiter.

Die folgende Abbildung zeigt, wie ein Dienst mit zwei Rollen verteilt wird, wenn der Dienst zwei Upgradedomänen definiert. Der Dienst führt acht Instanzen der Web-Rolle und neun Instanzen der Worker-Rolle aus.

Nächste Schritte

Verwalten von Clouddiensten
Überwachen von Clouddiensten
Konfigurieren von Clouddiensten