Übersicht über das Aktualisieren eines Windows Azure-Diensts

Die folgende Tabelle enthält die zulässigen Änderungen an einem Dienst während eines Updates:

Zulässige Änderungen an Hosting, Diensten und Rollen	Direktes Update	Staging (VIP-Swap)	Löschen und erneut bereitstellen
Betriebssystemversion	Ja	Ja	Ja
.NET-Vertrauensebene	Ja	Ja	Ja
Größe des virtuellen Computers	Ja Warnung Durch Ändern der Größe des virtuellen Computers werden lokale Daten zerstört. Hinweis Erfordert Windows Azure SDK 1.5 oder höher.	Ja	Ja
Lokale Speichereinstellungen	Ja Nur erhöhen. Hinweis Erfordert Windows Azure SDK 1.5 oder höher.	Ja	Ja
Rollen in einem Dienst hinzufügen oder entfernen	Ja	Ja	Ja
Anzahl der Instanzen einer bestimmten Rolle	Ja	Ja	Ja
Anzahl oder Typ der Endpunkte für einen Dienst	Ja Hinweis Erfordert Windows Azure SDK 1.5 oder höher. Wichtig Die Verfügbarkeit geht möglicherweise beim Aktualisieren der Endpunkte vorübergehend verloren.	Nein	Ja
Namen und Werte von Konfigurationseinstellungen	Ja	Ja	Ja
Werte (aber keine Namen) von Konfigurationseinstellungen	Ja	Ja	Ja
Neue Zertifikate hinzufügen	Ja	Ja	Ja
Vorhandene Zertifikate ändern	Ja	Ja	Ja
Neuen Code bereitstellen	Ja	Ja	Ja

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

• Ändern des Namens einer Rolle. Entfernen und anschließendes Hinzufügen der Rolle mit neuem Namen.
  
  
• Ändern der Anzahl der Upgradedomänen.
  
  
• Verringern der Größe der lokalen Ressourcen.
  
  

Wenn Sie andere Updates für die Definition des Diensts durchführen, wie z. B. das Verringern der Größe der lokalen Ressource, müssen Sie stattdessen ein VIP-Swap-Update durchführen. Weitere Informationen finden Sie unter Bereitstellen eines Dienstupgrades für die Produktion durch VIP-Swap in Windows Azure.

Windows Azure bietet Flexibilität bei der Verwaltung von Diensten während eines Updates durch Zulassen der Initiierung weiterer Vorgänge an einem Dienst, sobald die anfängliche Updateabfrage von Windows Azure Fabric Controller akzeptiert wurde. Ein Rollback kann nur durchgeführt werden, wenn ein Update (Konfigurationsänderung) oder Upgrade der Bereitstellung in Bearbeitung ist. Ein Update oder Upgrade gilt solange als "in Bearbeitung", bis alle Instanzen des Diensts auf die neue Version aktualisiert wurden. Sie testen, ob ein Rollback zulässig ist, indem Sie prüfen, ob der Wert des RollbackAllowed-Kennzeichens, der von den Vorgängen Get Deployment und Get Hosted Service Properties zurückgegeben wird, auf true gesetzt ist.

Hinweis
Der Aufruf eines Rollbacks für ein direktes Update oder Upgrade ist nur sinnvoll, da VIP-Swap-Upgrades das Ersetzen einer vollständigen ausgeführten Instanz des Diensts durch eine andere beinhalten. Weitere Informationen zum Austauschen von VIPs finden Sie unter Bereitstellen eines Dienstupgrades für die Produktion durch VIP-Swap in Windows Azure.

Das Rollback eines direkten Updates hat folgende Auswirkungen auf die Bereitstellung:

• Sämtliche noch nicht auf die neue Version aktualisierten Rolleninstanzen werden nicht aktualisiert, da diese Instanzen bereits unter der Zielversion des Diensts ausgeführt werden.
  
  
• Sämtliche bereits auf die neue Version aktualisierten Rolleninstanzen der Dienstpaket- (*.cspkg) und/oder der Dienstkonfigurationsdatei (*.cscfg) werden auf die Version dieser Dateien vor dem Upgrade zurückgesetzt.
  
  

Diese Funktion wird durch folgende Features bereitgestellt:

• Den Rollback Update Or Upgrade-Vorgang, der für ein Konfigurationsupdate (ausgelöst durch Aufrufen von Change Deployment Configuration) oder ein Upgrade (ausgelöst durch Aufrufen von Upgrade Deployment) aufgerufen werden kann, solange mindestens eine Instanz im Dienst vorhanden ist, die noch nicht auf die neue Version aktualisiert wurde.
  
  
• Das Locked-Element und das RollbackAllowed-Element, die als Teil des Antworttexts der Vorgänge Get Deployment und Get Hosted Service Properties zurückgegeben werden:
  
  
  1. Mit dem Locked-Element lässt sich erkennen, wenn ein mutierender Vorgang in einer bestimmten Bereitstellung aufgerufen werden kann.
     
     
  2. Mit dem RollbackAllowed-Element lässt sich erkennen, wenn der Rollback Update Or Upgrade-Vorgang in einer bestimmten Bereitstellung aufgerufen werden kann.
     
     
  Zur Durchführung eines Rollbacks müssen die Elemente Locked und RollbackAllowed nicht beide überprüft werden. Die Bestätigung, dass RollbackAllowed auf "true" gesetzt ist, reicht aus. Diese Elemente werden nur zurückgegeben, wenn diese Methoden bei einem auf folgende Version oder höher eingestellten Anforderungsheader aufgerufen werden: “x-ms-version: 2011-10-01”. Weitere Informationen zu diesem Versionsheadern finden Sie unter Service Management Versioning.
  
  

In folgenden Situationen werden Rollbacks von Updates oder Upgrades nicht unterstützt:

• Reduzierung der lokalen Ressourcen: Falls durch das Update die lokalen Ressourcen für eine Rolle erhöht werden, lässt Windows Azure Platform kein Rollback zu. Weitere Informationen zum Konfigurieren der lokalen Ressourcen für eine Rolle finden Sie unter Konfigurieren von lokalen Speicherressourcen.
  
  
• Kontingentgrenzen: Falls es sich beim Update um einen Vorgang des Abwärtsskalierens handelte, reicht möglicherweise das Serverkontingent für die Durchführung des Rollbackvorgangs nicht mehr aus. Jedem Windows Azure-Abonnement ist ein Kontingent zugeordnet, das die maximale Anzahl der Kerne angibt, die von allen gehosteten Diensten verbraucht werden können, die zu diesem Abonnement gehören. Wenn durch die Durchführung eines Rollbacks eines bestimmten Updates Ihr Abonnementkontingent überschritten würde, wird das Rollback nicht zugelassen.
  
  
• Racebedingung: Falls das anfängliche Update abgeschlossen ist, ist kein Rollback möglich.
  
  

Ein Beispiel dafür, wann ein Rollback eines Updates hilfreich sein kann, ist es, wenn Sie den Vorgang Upgrade Deployment im manuellen Modus verwenden, um die Rate zu steuern, mit der ein größeres Upgrade für den gehosteten Windows Azure-Dienst eingeführt wird.

Während der Veröffentlichung des Upgrades rufen Sie Upgrade Deployment im manuellen Modus auf und beginnen mit dem Durchlaufen der Upgradedomänen. Falls Sie beim Überwachen des Upgrades an einem bestimmten Punkt bemerken, dass Rolleninstanzen in den ersten geprüften Upgradedomänen nicht mehr reagieren, können Sie den Rollback Update Or Upgrade-Vorgang für die Bereitstellung aufrufen, der die noch nicht aktualisierten Instanzen unverändert lässt und bereits aktualisierte Instanzen auf die vorherige Version des Dienstpakets und der Konfiguration zurücksetzt.

In einigen Fällen ist es möglicherweise wünschenswert, mehrere mutierende Vorgänge in einer fortlaufenden Bereitstellung simultan zu starten. Sie können z. B. ein Dienstupdate durchführen und während der Einführung des Updates in Ihrem Dienst eine Änderung vornehmen, d. h. ein Rollback für das Update durchführen, ein anderes Update übernehmen oder sogar die gesamte Bereitstellung löschen. Dies ist möglicherweise erforderlich, wenn ein Dienstupgrade fehlerhaften Code enthält, der zu wiederholten Abstürzen einer aktualisieren Rolleninstanz führt. In diesem Fall macht Windows Azure Fabric Controller keine Fortschritte bei der Übernahme dieses Upgrades, da eine nicht ausreichende Anzahl Instanzen in der aktualisierten Domäne fehlerfrei ist. Dieser Status wird als aufgehängte Bereitstellung bezeichnet. Sie können die Bereitstellung lösen, indem Sie ein Rollback für das Update durchführen oder ein neues Update über das fehlgeschlagene installieren.

Wenn die anfängliche Anfrage für das Update oder Upgrade des Diensts vom Windows Azure Fabric Controller empfangen wurde, können nachfolgende mutierende Vorgänge aufgerufen werden. Daher muss nicht gewartet werden, bis der anfängliche Vorgang abgeschlossen ist, bevor Sie einen anderen mutierenden Vorgang aufrufen.

Das Starten eines zweiten Updatevorgangs während des ersten Updates hat ähnliche Auswirkungen wie der Rollbackvorgang. Falls sich das zweite Update im automatischen Modus befindet, wird die erste Upgradedomäne sofort aktualisiert, was möglicherweise dazu führt, dass Instanzen mehrerer Upgradedomänen gleichzeitig offline sind.

Die mutierenden Vorgänge sind: Change Deployment Configuration, Upgrade Deployment, Update Deployment Status, Delete Deployment und Rollback Update Or Upgrade.

Die beiden Vorgänge Get Deployment und Get Hosted Service Properties geben das Locked-Kennzeichen zurück, das geprüft werden kann, um zu bestimmen, ob ein mutierender Vorgang in einer bestimmten Bereitstellung aufgerufen werden kann.

Zum Aufrufen der Version dieser Methoden, von der das Locked-Kennzeichen zurückgegeben wird, müssen Sie den Anforderungsheader auf die folgende Version oder höher setzen: “x-ms-version: 2011-10-01”. Weitere Informationen zu diesem Versionsheadern finden Sie unter Service Management Versioning.

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

Wenn die Rolle beispielsweise über zehn Instanzen verfügt, enthält jede Upgradedomäne standardmäßig zwei Instanzen. Wenn die Rolle vierzehn Instanzen besitzt, enthalten vier der Upgradedomänen drei Instanzen, und die fünfte Domäne enthält zwei Instanzen.

Upgradedomänen werden mit einem nullbasierten Index identifiziert: Die erste Upgradedomäne besitzt die ID "0", die zweite Upgradedomäne die ID "1" usw.

Im folgenden Diagramm ist veranschaulicht, wie zwei einen Dienst umfassende Rollen verteilt werden, wenn der Dienst zwei Upgradedomänen definiert. Vom Dienst werden acht Instanzen der Webrolle und neun Instanzen der Workerrolle ausgeführt.

Hinweis
Beachten Sie, dass von Windows Azure gesteuert wird, wie Instanzen in Upgradedomänen zugeordnet werden. Sie können nicht angeben, welche Instanzen welcher Domäne zugeordnet werden.

Sie können auswählen, ob alle Rollen im Dienst oder eine einzelne Rolle im Dienst aktualisiert werden sollen bzw. soll. In beiden Fällen werden alle Instanzen der Rolle, die aktualisiert wird und zur ersten Upgradedomäne gehört, angehalten, aktualisiert und wieder online geschaltet. Sobald sie wieder online geschaltet sind, werden die Instanzen in der zweiten Upgradedomäne angehalten, aktualisiert und wieder online geschaltet.

Das folgende Diagramm veranschaulicht den Verlauf der Aktualisierung, wenn Sie ein Upgrade aller Rollen im Dienst durchführen:

Das folgende Diagramm veranschaulicht den Verlauf des Updates, wenn Sie ein Upgrade nur für eine Rolle durchführen: