Problembehandlung bei AnwendungsupgradesTroubleshoot application upgrades

In diesem Artikel werden einige bekannte Probleme beim Upgrade einer Azure Service Fabric-Anwendung und ihre Behebung behandelt.This article covers some of the common issues around upgrading an Azure Service Fabric application and how to resolve them.

Problembehandlung bei einem fehlgeschlagenen AnwendungsupgradeTroubleshoot a failed application upgrade

Wenn ein Upgrade fehlschlägt, enthält die Ausgabe des Befehls Get-ServiceFabricApplicationUpgrade zusätzliche Informationen zum Debuggen des Fehlers.When an upgrade fails, the output of the Get-ServiceFabricApplicationUpgrade command contains additional information for debugging the failure. Die folgende Liste gibt an, wie die zusätzlichen Informationen verwendet werden können:The following list specifies how the additional information can be used:

  1. Identifizieren des FehlertypsIdentify the failure type.
  2. Identifizieren der FehlerursacheIdentify the failure reason.
  3. Isolieren fehlerhafter Komponenten zur weiteren UntersuchungIsolate one or more failing components for further investigation.

Diese Informationen sind verfügbar, sobald Service Fabric einen Fehler erkennt, unabhängig davon, ob die FailureAction darin besteht, das Upgrade per Rollback rückgängig zu machen oder anzuhalten.This information is available when Service Fabric detects the failure regardless of whether the FailureAction is to roll back or suspend the upgrade.

Identifizieren des FehlertypsIdentify the failure type

In der Ausgabe von Get-ServiceFabricApplicationUpgrade gibt FailureTimestampUtc den Zeitstempel (in UTC) an, bei dem ein Upgradefehler von Service Fabric erkannt und die FailureAction ausgelöst wurde.In the output of Get-ServiceFabricApplicationUpgrade, FailureTimestampUtc identifies the timestamp (in UTC) at which an upgrade failure was detected by Service Fabric and FailureAction was triggered. FailureReason gibt eine der drei potenziellen allgemeinen Ursachen des Fehlers an:FailureReason identifies one of three potential high-level causes of the failure:

  1. UpgradeDomainTimeout : Gibt an, dass der Abschluss einer bestimmten Upgradedomäne zu lange dauerte und dass "UpgradeDomainTimeout" abgelaufen ist.UpgradeDomainTimeout - Indicates that a particular upgrade domain took too long to complete and UpgradeDomainTimeout expired.
  2. OverallUpgradeTimeout : Gibt an, dass das gesamte Upgrade zu lange dauerte und dass "UpgradeTimeout" abgelaufen ist.OverallUpgradeTimeout - Indicates that the overall upgrade took too long to complete and UpgradeTimeout expired.
  3. HealthCheck: Gibt an, dass die Anwendung nach dem Upgrade einer Updatedomäne entsprechend den angegebenen Integritätsrichtlinien fehlerhaft ist und dass HealthCheckRetryTimeout abgelaufen ist.HealthCheck - Indicates that after upgrading an update domain, the application remained unhealthy according to the specified health policies and HealthCheckRetryTimeout expired.

Diese Einträge werden in der Ausgabe nur angezeigt, wenn das Upgrade fehlschlägt und ein Rollback ausgeführt wird.These entries only show up in the output when the upgrade fails and starts rolling back. Weitere Informationen werden je nach Art des Fehlers angezeigt.Further information is displayed depending on the type of the failure.

Untersuchen von Timeouts bei UpgradesInvestigate upgrade timeouts

Timeoutfehler bei Upgrades sind am häufigsten auf Probleme mit der Dienstverfügbarkeit zurückzuführen.Upgrade timeout failures are most commonly caused by service availability issues. Die Ausgabe im Anschluss an diesen Absatz ist typisch für Upgrades, bei denen beim Starten von Dienstreplikaten oder -instanzen in der neuen Codeversion Fehler auftreten.The output following this paragraph is typical of upgrades where service replicas or instances fail to start in the new code version. Im Feld UpgradeDomainProgressAtFailure wird eine Momentaufnahme der ausstehenden Upgradevorgänge zum Zeitpunkt des Fehlers erfasst.The UpgradeDomainProgressAtFailure field captures a snapshot of any pending upgrade work at the time of failure.

Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName                : fabric:/DemoApp
ApplicationTypeName            : DemoAppType
TargetApplicationTypeVersion   : v2
ApplicationParameters          : {}
StartTimestampUtc              : 4/14/2015 9:26:38 PM
FailureTimestampUtc            : 4/14/2015 9:27:05 PM
FailureReason                  : UpgradeDomainTimeout
UpgradeDomainProgressAtFailure : MYUD1

                                 NodeName            : Node4
                                 UpgradePhase        : PostUpgradeSafetyCheck
                                 PendingSafetyChecks :
                                     WaitForPrimaryPlacement - PartitionId: 744c8d9f-1d26-417e-a60e-cd48f5c098f0

                                 NodeName            : Node1
                                 UpgradePhase        : PostUpgradeSafetyCheck
                                 PendingSafetyChecks :
                                     WaitForPrimaryPlacement - PartitionId: 4b43f4d8-b26b-424e-9307-7a7a62e79750
UpgradeState                   : RollingBackCompleted
UpgradeDuration                : 00:00:46
CurrentUpgradeDomainDuration   : 00:00:00
NextUpgradeDomain              :
UpgradeDomainsStatus           : { "MYUD1" = "Completed";
                                 "MYUD2" = "Completed";
                                 "MYUD3" = "Completed" }
UpgradeKind                    : Rolling
RollingUpgradeMode             : UnmonitoredAuto
ForceRestart                   : False
UpgradeReplicaSetCheckTimeout  : 00:00:00

Bei diesem Beispiel ist das Upgrade bei der Upgradedomäne MYUD1 fehlgeschlagen, und die beiden Partitionen (744c8d9f-1d26-417e-a60e-cd48f5c098f0 und 4b43f4d8-b26b-424e-9307-7a7a62e79750) sind hängen geblieben.In this example, the upgrade failed at upgrade domain MYUD1 and two partitions (744c8d9f-1d26-417e-a60e-cd48f5c098f0 and 4b43f4d8-b26b-424e-9307-7a7a62e79750) were stuck. Die Partitionen sind hängen geblieben, da die Laufzeit die primären Replikate (WaitForPrimaryPlacement) nicht auf den Zielknoten Node1 und Node4 platzieren konnte.The partitions were stuck because the runtime was unable to place primary replicas (WaitForPrimaryPlacement) on target nodes Node1 and Node4.

Mit dem Befehl Get-ServiceFabricNode kann überprüft werden, ob sich diese beiden Knoten in der Upgradedomäne MYUD1befinden.The Get-ServiceFabricNode command can be used to verify that these two nodes are in upgrade domain MYUD1. Die UpgradePhase gibt PostUpgradeSafetyCheck aus, was bedeutet, dass diese Sicherheitsprüfungen nach dem Aktualisieren aller Knoten in der Upgradedomäne stattfinden.The UpgradePhase says PostUpgradeSafetyCheck, which means that these safety checks are occurring after all nodes in the upgrade domain have finished upgrading. Alle diese Informationen lassen auf ein mögliches Problem mit der neuen Version des Anwendungscodes schließen.All this information points to a potential issue with the new version of the application code. Die häufigsten Probleme sind Dienstfehler im Vordergrund oder bei der Heraufstufung auf primäre Codepfade.The most common issues are service errors in the open or promotion to primary code paths.

PreUpgradeSafetyCheck als UpgradePhase bedeutet, dass vor der Durchführung des Upgrades Probleme bei der Vorbereitung der Upgradedomäne aufgetreten sind.An UpgradePhase of PreUpgradeSafetyCheck means there were issues preparing the upgrade domain before it was performed. In diesem Fall sind die häufigsten Probleme Fehler im Hintergrund oder bei der Herabstufung von primären Codepfaden.The most common issues in this case are service errors in the close or demotion from primary code paths.

Der aktuelle UpgradeState ist RollingBackCompleted, d.h., das ursprüngliche Upgrade muss mit einer Rollback-FailureAction durchgeführt worden sein, sodass nach dem Fehler automatisch ein Rollback des Upgrades ausgeführt wurde.The current UpgradeState is RollingBackCompleted, so the original upgrade must have been performed with a rollback FailureAction, which automatically rolled back the upgrade upon failure. Wenn das ursprüngliche Upgrade mit einer manuellen FailureAction durchgeführt worden wäre, befände sich das Upgrade stattdessen in einem angehaltenen Zustand, um das Livedebuggen der Anwendung zuzulassen.If the original upgrade was performed with a manual FailureAction, then the upgrade would instead be in a suspended state to allow live debugging of the application.

In seltenen Fällen kann das Feld UpgradeDomainProgressAtFailure leer sein, wenn das gesamte Upgrade gerade in dem Moment ein Zeitlimit erreicht, in dem das System alle Aufgaben für die aktuelle Upgradedomäne erledigt hat.In rare cases, the UpgradeDomainProgressAtFailure field may be empty if the overall upgrade times out just as the system completes all work for the current upgrade domain. Versuchen Sie in diesem Fall, die Werte der Upgradeparameter UpgradeTimeout und UpgradeDomainTimeout zu erhöhen und dann das Upgrade zu wiederholen.If this happens, try increasing the UpgradeTimeout and UpgradeDomainTimeout upgrade parameter values and retry the upgrade.

Untersuchen von Fehlern bei der IntegritätsprüfungInvestigate health check failures

Fehler bei der Integritätsprüfung können durch eine Vielzahl von Problemen ausgelöst werden, die auftreten können, nachdem alle Knoten in einer Upgradedomäne aktualisiert und alle Sicherheitsprüfungen erfolgreich durchgeführt wurden.Health check failures can be triggered by various issues that can happen after all nodes in an upgrade domain finish upgrading and passing all safety checks. Die Ausgabe im Anschluss an diesen Absatz ist typisch für einen Upgradefehler aufgrund fehlerhafter Integritätsprüfungen.The output following this paragraph is typical of an upgrade failure due to failed health checks. Im Feld UnhealthyEvaluations wird entsprechend der angegebenen Integritätsrichtlinieeine Momentaufnahme aller fehlgeschlagenen Integritätsprüfungen zum Zeitpunkt des Upgradefehlers erfasst.The UnhealthyEvaluations field captures a snapshot of health checks that failed at the time of the upgrade according to the specified health policy.

Get-ServiceFabricApplicationUpgrade fabric:/DemoApp
ApplicationName                         : fabric:/DemoApp
ApplicationTypeName                     : DemoAppType
TargetApplicationTypeVersion            : v4
ApplicationParameters                   : {}
StartTimestampUtc                       : 4/24/2015 2:42:31 AM
UpgradeState                            : RollingForwardPending
UpgradeDuration                         : 00:00:27
CurrentUpgradeDomainDuration            : 00:00:27
NextUpgradeDomain                       : MYUD2
UpgradeDomainsStatus                    : { "MYUD1" = "Completed";
                                          "MYUD2" = "Pending";
                                          "MYUD3" = "Pending" }
UnhealthyEvaluations                    :
                                          Unhealthy services: 50% (2/4), ServiceType='PersistedServiceType', MaxPercentUnhealthyServices=0%.

                                          Unhealthy service: ServiceName='fabric:/DemoApp/Svc3', AggregatedHealthState='Error'.

                                              Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.

                                              Unhealthy partition: PartitionId='3a9911f6-a2e5-452d-89a8-09271e7e49a8', AggregatedHealthState='Error'.

                                                  Error event: SourceId='Replica', Property='InjectedFault'.

                                          Unhealthy service: ServiceName='fabric:/DemoApp/Svc2', AggregatedHealthState='Error'.

                                              Unhealthy partitions: 100% (1/1), MaxPercentUnhealthyPartitionsPerService=0%.

                                              Unhealthy partition: PartitionId='744c8d9f-1d26-417e-a60e-cd48f5c098f0', AggregatedHealthState='Error'.

                                                  Error event: SourceId='Replica', Property='InjectedFault'.

UpgradeKind                             : Rolling
RollingUpgradeMode                      : Monitored
FailureAction                           : Manual
ForceRestart                            : False
UpgradeReplicaSetCheckTimeout           : 49710.06:28:15
HealthCheckWaitDuration                 : 00:00:00
HealthCheckStableDuration               : 00:00:10
HealthCheckRetryTimeout                 : 00:00:10
UpgradeDomainTimeout                    : 10675199.02:48:05.4775807
UpgradeTimeout                          : 10675199.02:48:05.4775807
ConsiderWarningAsError                  :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices             :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap              :

Die Untersuchung von Fehlern bei der Integritätsprüfung erfordert zunächst ein umfassendes Verständnis des Service Fabric-Integritätsmodells.Investigating health check failures first requires an understanding of the Service Fabric health model. Aber auch ohne diese detaillierten Kenntnisse können wir sehen, dass zwei Dienste fehlerhaft sind: fabric:/DemoApp/Svc3 und fabric:/DemoApp/Svc2. Wir sehen auch den Fehlerintegritätsbericht (in diesem Fall „InjectedFault“).But even without such an in-depth understanding, we can see that two services are unhealthy: fabric:/DemoApp/Svc3 and fabric:/DemoApp/Svc2, along with the error health reports ("InjectedFault" in this case). In diesem Beispiel sind zwei von vier Diensten fehlerhaft. Dies liegt unter dem Standardziel von 0% Fehlern (MaxPercentUnhealthyServices).In this example, two out of four services are unhealthy, which is below the default target of 0% unhealthy (MaxPercentUnhealthyServices).

Das Upgrade wurde nach dem Fehlschlagen angehalten, indem die FailureAction „Manual“ beim Starten des Upgrades angegeben wurde.The upgrade was suspended upon failing by specifying a FailureAction of manual when starting the upgrade. Dieser Modus ermöglicht uns, das Livesystem im fehlerhaften Zustand zu untersuchen, bevor eine weitere Aktion erfolgt.This mode allows us to investigate the live system in the failed state before taking any further action.

Wiederherstellen eines angehaltenen UpgradesRecover from a suspended upgrade

Wenn als FailureAction„Rollback“ angegeben ist, ist keine Wiederherstellung erforderlich, da nach dem Fehler automatisch ein Rollback für das Upgrade ausgeführt wird.With a rollback FailureAction, there is no recovery needed since the upgrade automatically rolls back upon failing. Wenn als FailureAction"Manual" angegeben ist, gibt es mehrere Möglichkeiten zur Wiederherstellung:With a manual FailureAction, there are several recovery options:

  1. Auslösen eines Rollbackstrigger a rollback
  2. Manuelles Durchlaufen des restlichen UpgradesProceed through the remainder of the upgrade manually
  3. Fortsetzen des überwachten UpgradesResume the monitored upgrade

Der Befehl Start ServiceFabricApplicationRollback kann jederzeit verwendet werden, um einen Rollback für die Anwendung auszuführen.The Start-ServiceFabricApplicationRollback command can be used at any time to start rolling back the application. Wenn der Befehl erfolgreich zurückgegeben wird, wurde die Rollbackanforderung im System registriert und wird bald darauf gestartet.Once the command returns successfully, the rollback request has been registered in the system and starts shortly thereafter.

Mit dem Befehl Resume-ServiceFabricApplicationUpgrade kann das restliche Upgrade manuell fortgesetzt werden. Dabei werden die einzelnen Upgradedomänen nacheinander durchlaufen.The Resume-ServiceFabricApplicationUpgrade command can be used to proceed through the remainder of the upgrade manually, one upgrade domain at a time. In diesem Modus werden vom System nur Sicherheitsprüfungen durchgeführt.In this mode, only safety checks are performed by the system. Weitere Integritätsprüfungen erfolgen nicht.No more health checks are performed. Dieser Befehl kann nur verwendet werden, wenn UpgradeState den Wert RollingForwardPending aufweist, was bedeutet, dass das Upgrade der aktuellen Upgradedomäne abgeschlossen ist, die nächste Upgradedomäne jedoch noch nicht gestartet wurde (ausstehend ist).This command can only be used when the UpgradeState shows RollingForwardPending, which means that the current upgrade domain has finished upgrading but the next one has not started (pending).

Der Befehl Update-ServiceFabricApplicationUpgrade kann zum Fortsetzen des überwachten Upgrades mit Sicherheits- und Integritätsprüfungen verwendet werden.The Update-ServiceFabricApplicationUpgrade command can be used to resume the monitored upgrade with both safety and health checks being performed.

Update-ServiceFabricApplicationUpgrade fabric:/DemoApp -UpgradeMode Monitored
UpgradeMode                             : Monitored
ForceRestart                            :
UpgradeReplicaSetCheckTimeout           :
FailureAction                           :
HealthCheckWaitDuration                 :
HealthCheckStableDuration               :
HealthCheckRetryTimeout                 :
UpgradeTimeout                          :
UpgradeDomainTimeout                    :
ConsiderWarningAsError                  :
MaxPercentUnhealthyPartitionsPerService :
MaxPercentUnhealthyReplicasPerPartition :
MaxPercentUnhealthyServices             :
MaxPercentUnhealthyDeployedApplications :
ServiceTypeHealthPolicyMap              :

Das Upgrade wird ab der Upgradedomäne fortgesetzt, in der es zuletzt angehalten wurde. Dabei werden die gleichen Upgradeparameter und Integritätsrichtlinien wie zuvor verwendet.The upgrade continues from the upgrade domain where it was last suspended and use the same upgrade parameters and health policies as before. Bei Bedarf können beim Fortsetzen des Upgrades alle in der vorstehenden Ausgabe angegebenen Upgradeparameter und Integritätsrichtlinien im gleichen Befehl geändert werden.If needed, any of the upgrade parameters and health policies shown in the preceding output can be changed in the same command when the upgrade resumes. In diesem Beispiel wurde das Upgrade im überwachten Modus mit unveränderten Parametern und Integritätsrichtlinien fortgesetzt.In this example, the upgrade was resumed in Monitored mode, with the parameters and the health policies unchanged.

Weitere ProblembehandlungenFurther troubleshooting

Service Fabric befolgt nicht die angegebenen IntegritätsrichtlinienService Fabric is not following the specified health policies

Mögliche Ursache 1:Possible Cause 1:

Service Fabric übersetzt für die Integritätsevaluierung alle Prozentsätze in die tatsächliche Anzahl der Entitäten (z. B. Replikate, Partitionen und Dienste) und rundet immer auf ganze Zahlen auf.Service Fabric translates all percentages into actual numbers of entities (for example, replicas, partitions, and services) for health evaluation and always rounds up to whole entities. Wenn für MaxPercentUnhealthyReplicasPerPartition beispielsweise maximal 21 % angegeben wurde und fünf Replikate vorhanden sind, lässt Service Fabric bis zu zwei fehlerhafte Replikate zu (d.h. Math.Ceiling (5*0.21)).For example, if the maximum MaxPercentUnhealthyReplicasPerPartition is 21% and there are five replicas, then Service Fabric allows up to two unhealthy replicas (that is,Math.Ceiling (5*0.21)). Integritätsrichtlinien müssen also entsprechend festgelegt werden.Thus, health policies should be set accordingly.

Mögliche Ursache 2:Possible Cause 2:

Integritätsrichtlinien werden als Prozentsätze aller Dienste und nicht für bestimmte Dienstinstanzen angegeben.Health policies are specified in terms of percentages of total services and not specific service instances. Angenommen, vor einem Upgrade umfasst eine Anwendung beispielsweise die vier Dienstinstanzen A, B, C und D, wobei Dienst D fehlerhaft ist, jedoch mit nur geringen Auswirkungen auf die Anwendung.For example, before an upgrade, if an application has four service instances A, B, C, and D, where service D is unhealthy but with little impact to the application. Der bekanntermaßen fehlerhafte Dienst D soll beim Upgrade ignoriert werden. Also legen wir den Parameter MaxPercentUnhealthyServices auf 25 % fest und setzen voraus, dass nur A, B und C fehlerfrei sein müssen.We want to ignore the known unhealthy service D during upgrade and set the parameter MaxPercentUnhealthyServices to be 25%, assuming only A, B, and C need to be healthy.

Allerdings kann während des Upgrades D fehlerfrei und C fehlerhaft werden.However, during the upgrade, D may become healthy while C becomes unhealthy. Das Upgrade wäre immer noch erfolgreich, da nur 25 % der Dienste fehlerhaft sind.The upgrade would still succeed because only 25% of the services are unhealthy. Dies kann jedoch zu unvorhergesehenen Fehlern führen, wenn unerwarteterweise C anstatt D fehlerhaft ist. In diesem Fall sollte D als anderer Diensttyp als A, B und C modelliert werden. Da Integritätsrichtlinien pro Diensttyp angegeben werden, können unterschiedliche Fehlerschwellenwerte in Prozent auf verschiedene Dienste angewendet werden.However, it might result in unanticipated errors due to C being unexpectedly unhealthy instead of D. In this situation, D should be modeled as a different service type from A, B, and C. Since health policies are specified per service type, different unhealthy percentage thresholds can be applied to different services.

Ich habe keine Integritätsrichtlinie für das Anwendungsupgrade angegeben, beim Upgrade treten jedoch Fehler aufgrund einiger Timeouts auf, die ich nie angegeben habeI did not specify a health policy for application upgrade, but the upgrade still fails for some time-outs that I never specified

Wenn der Upgradeanforderung keine Integritätsrichtlinien bereitgestellt werden, werden diese aus der Datei ApplicationManifest.xml der aktuellen Anwendungsversion übernommen.When health policies aren't provided to the upgrade request, they are taken from the ApplicationManifest.xml of the current application version. Wenn Sie beispielsweise Anwendung X von Version 1.0 auf Version 2.0 aktualisieren, werden die für Anwendung X in Version 1.0 angegebenen Richtlinien zur Anwendungsintegrität verwendet.For example, if you're upgrading Application X from version 1.0 to version 2.0, application health policies specified for in version 1.0 are used. Wenn für das Upgrade eine andere Integritätsrichtlinie verwendet werden soll, muss die Richtlinie als Teil des API-Aufrufs für das Anwendungsupgrade angegeben werden.If a different health policy should be used for the upgrade, then the policy needs to be specified as part of the application upgrade API call. Die Richtlinien, die als Teil des API-Aufrufs angegeben werden, gelten nur für die Dauer des Upgrades.The policies specified as part of the API call only apply during the upgrade. Nach Abschluss des Upgrades werden wieder die in der Datei ApplicationManifest.xml angegebenen Richtlinien verwendet.Once the upgrade is complete, the policies specified in the ApplicationManifest.xml are used.

Es werden falsche Timeouts angegebenIncorrect time-outs are specified

Sie haben sich vielleicht gefragt, was passiert, wenn Timeouts uneinheitlich festgelegt sind.You may have wondered about what happens when time-outs are set inconsistently. Angenommen, Sie haben ein UpgradeTimeout, das kleiner als das UpgradeDomainTimeout ist.For example, you may have an UpgradeTimeout that's less than the UpgradeDomainTimeout. Die Antwort ist einfach: Es wird ein Fehler zurückgegeben.The answer is that an error is returned. In den folgenden Fällen werden Fehler zurückgegeben: UpgradeDomainTimeout ist kleiner als die Summe aus HealthCheckWaitDuration und HealthCheckRetryTimeout, und UpgradeDomainTimeout ist kleiner als die Summe aus HealthCheckWaitDuration und HealthCheckStableDuration.Errors are returned if the UpgradeDomainTimeout is less than the sum of HealthCheckWaitDuration and HealthCheckRetryTimeout, or if UpgradeDomainTimeout is less than the sum of HealthCheckWaitDuration and HealthCheckStableDuration.

Die Upgrades dauern zu langeMy upgrades are taking too long

Die Dauer eines Upgrades hängt von den angegebenen Integritätsprüfungen und Timeouts ab.The time for an upgrade to complete depends on the health checks and time-outs specified. Integritätsprüfungen und Timeouts hängen davon ab, wie lange es dauert, die Anwendung zu kopieren, bereitzustellen und zu stabilisieren.Health checks and time-outs depend on how long it takes to copy, deploy, and stabilize the application. Wenn Timeouts zu kurz angesetzt werden, führt dies möglicherweise zu einer größeren Zahl fehlerhafter Upgrades. Daher empfiehlt sich eine konservative Vorgehensweise mit längeren Timeouts.Being too aggressive with time-outs might mean more failed upgrades, so we recommend starting conservatively with longer time-outs.

Eine kurze Erinnerung dazu, wie Timeouts und Upgradezeiten interagieren:Here's a quick refresher on how the time-outs interact with the upgrade times:

Upgrades für eine Upgradedomäne können nicht schneller abgeschlossen werden als HealthCheckWaitDuration + HealthCheckStableDuration.Upgrades for an upgrade domain cannot complete faster than HealthCheckWaitDuration + HealthCheckStableDuration.

Upgradefehler können nicht schneller auftreten als HealthCheckWaitDuration + HealthCheckRetryTimeout.Upgrade failure cannot occur faster than HealthCheckWaitDuration + HealthCheckRetryTimeout.

Die Upgradezeit für eine Upgradedomäne wird durch UpgradeDomainTimeoutbegrenzt.The upgrade time for an upgrade domain is limited by UpgradeDomainTimeout. Wenn HealthCheckRetryTimeout und HealthCheckStableDuration ungleich null sind und die Integrität der Anwendung wechselt, wird für das Upgrade schließlich bei UpgradeDomainTimeout das Timeout überschritten.If HealthCheckRetryTimeout and HealthCheckStableDuration are both non-zero and the health of the application keeps switching back and forth, then the upgrade eventually times out on UpgradeDomainTimeout. UpgradeDomainTimeout zählt rückwärts ab dem Moment, an dem das Upgrade für die aktuelle Upgradedomäne gestartet wird.UpgradeDomainTimeout starts counting down once the upgrade for the current upgrade domain begins.

Nächste SchritteNext steps

Ihre Anwendung mit Visual Studio upgraden beschreibt das Upgraden von Anwendungen mit Visual Studio.Upgrading your Application Using Visual Studio walks you through an application upgrade using Visual Studio.

Ihre Anwendung mit PowerShell upgraden beschreibt das Upgraden von Anwendungen mit PowerShell.Upgrading your Application Using Powershell walks you through an application upgrade using PowerShell.

Steuern Sie die Upgrades von Anwendungen mithilfe von Upgradeparametern.Control how your application upgrades by using Upgrade Parameters.

Machen Sie Ihre Anwendungsupgrades kompatibel, indem Sie sich mit der Datenserialisierungvertraut machen.Make your application upgrades compatible by learning how to use Data Serialization.

Erfahren Sie, wie Sie erweiterte Funktionen beim Upgrade Ihrer Anwendung nutzen, indem Sie sich mit den weiterführenden Themenbeschäftigen.Learn how to use advanced functionality while upgrading your application by referring to Advanced Topics.