Service Fabric アプリケーションのアップグレードService Fabric application upgrade

Service Fabric アプリケーションは、サービスのコレクションです。An Azure Service Fabric application is a collection of services. アップグレードの際、Service Fabric は新しい アプリケーション マニフェスト を以前のバージョンと比較し、アプリケーション内でアップグレードの必要があるサービスを決定します。During an upgrade, Service Fabric compares the new application manifest with the previous version and determines which services in the application require updates. Service Fabric は、サービス マニフェスト内のバージョン番号を、以前のバージョンのバージョン番号と比較します。Service Fabric compares the version numbers in the service manifests with the version numbers in the previous version. サービスが変更されていない場合は、そのサービスはアップグレードされません。If a service has not changed, that service is not upgraded.

注意

ApplicationParameter は、アプリケーションをアップグレードすると保持されなくなります。ApplicationParameters are not preserved across an application upgrade. 現在のアプリケーション パラメーターを保持するには、まずパラメーターを取得して、次のようにアップグレード API 呼び出しに渡します。In order to preserve current application parameters, the user should get the parameters first and pass them into the upgrade API call like below:

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

ローリング アップグレードの概要Rolling upgrades overview

アプリケーションのローリング アップグレードでは、アップグレードは段階的に実行されます。In a rolling application upgrade, the upgrade is performed in stages. 各段階で、アップグレードは、更新ドメインと呼ばれる、クラスター内のノードのサブセットに適用されます。At each stage, the upgrade is applied to a subset of nodes in the cluster, called an update domain. その結果、アプリケーションはアップグレード全体を通して引き続き使用できます。As a result, the application remains available throughout the upgrade. アップグレード中に、クラスターに古いバージョンと新しいバージョンが混在することがあります。During the upgrade, the cluster may contain a mix of the old and new versions.

そのため、その 2 つのバージョンには上位互換性と下位互換性がある必要があります。For that reason, the two versions must be forward and backward compatible. 互換性がない場合は、アプリケーション管理者が複数フェーズのアップグレードを担当して可用性を維持します。If they are not compatible, the application administrator is responsible for staging a multiple-phase upgrade to maintain availability. 複数フェーズのアップグレードでは、最初に、以前のバージョンと互換性のあるアプリケーションの中間バージョンにアップグレードします。In a multiple-phase upgrade, the first step is upgrading to an intermediate version of the application that is compatible with the previous version. 次に、更新前のバージョンとの互換性を破る最終バージョンにアップグレードします。この最終バージョンは、中間バージョンに対応しています。The second step is to upgrade the final version that breaks compatibility with the pre-update version, but is compatible with the intermediate version.

更新ドメインは、クラスターを構成するときに、クラスター マニフェストで指定されます。Update domains are specified in the cluster manifest when you configure the cluster. 更新ドメインが更新を受け取る順序は特に決まってはいません。Update domains do not receive updates in a particular order. 更新ドメインは、アプリケーションのデプロイの論理単位です。An update domain is a logical unit of deployment for an application. 更新ドメインを使用すると、アップグレード中、サービスの可用性は高く維持されます。Update domains allow the services to remain at high availability during an upgrade.

アップグレードがクラスター内のすべてのノードに適用される場合 (アプリケーションに含まれている更新ドメインが 1 つのみの場合) は、非ローリング アップグレードを行うことができます。Non-rolling upgrades are possible if the upgrade is applied to all nodes in the cluster, which is the case when the application has only one update domain. このアプローチは推奨されません。サービスがダウンして、アップグレード時に利用可能にならないためです。This approach is not recommended, since the service goes down and isn't available at the time of upgrade. さらに、Azure では、クラスターが 1 つだけの更新ドメインでセットアップされた場合、一切保証しません。Additionally, Azure doesn't provide any guarantees when a cluster is set up with only one update domain.

アップグレードが完了したら、すべてのサービスおよびレプリカ (インスタンス) は同じバージョンに保管されます。つまり、アップグレードに成功すると、サービスおよびレプリカも新しいバージョンに更新されます。また、アップグレードに失敗してロールバックされると、これらも古いバージョンにロールバックされます。After the upgrade completes, all the services and replicas(instances) would stay in the same version-i.e., if the upgrade succeeds, they will be updated to the new version; if the upgrade fails and is rolled back, they would be rolled back to the old version.

アップグレード時の正常性チェックHealth checks during upgrades

アップグレードには、正常性ポリシーを設定する必要があります (既定値を使用することもできます)。For an upgrade, health policies have to be set (or default values may be used). 指定されたタイムアウト内にすべての更新ドメインがアップグレードされた場合や、すべての更新ドメインが正常であると判断された場合は、アップグレードが成功したことになります。An upgrade is termed successful when all update domains are upgraded within the specified time-outs, and when all update domains are deemed healthy. 正常な更新ドメインとは、その更新ドメインが、正常性ポリシーで指定されているすべての正常性チェックに合格したことを意味します。A healthy update domain means that the update domain passed all the health checks specified in the health policy. たとえば、正常性ポリシーでは、Service Fabric で正常性が定義されているように、アプリケーション インスタンス内のすべてのサービスが 正常であることが要求される場合があります。For example, a health policy may mandate that all services within an application instance must be healthy, as health is defined by Service Fabric.

アップグレード中の Service Fabric による正常性ポリシーと正常性チェックはサービスとアプリケーションに依存しません。Health policies and checks during upgrade by Service Fabric are service and application agnostic. つまり、サービス固有のテストは実行されません。That is, no service-specific tests are done. たとえば、サービスにスループット要件が必要になる場合がありますが、Service Fabric にはスループットを確認するための情報がありません。For example, your service might have a throughput requirement, but Service Fabric does not have the information to check throughput. 実行されるチェックについては、 正常性に関する記事 をご覧ください。Refer to the health articles for the checks that are performed. アップグレード中に実行されるチェックには、アプリケーション パッケージが正しくコピーされたかどうか、インスタンスが開始されたかどうかなどのテストが含まれます。The checks that happen during an upgrade include tests for whether the application package was copied correctly, whether the instance was started, and so on.

アプリケーションの正常性は、アプリケーションの子エンティティの集約です。The application health is an aggregation of the child entities of the application. つまり、Service Fabric では、アプリケーションで報告された正常性によってアプリケーションの正常性が評価されます。In short, Service Fabric evaluates the health of the application through the health that is reported on the application. また、アプリケーションのすべてのサービスの正常性もそのように評価されます。It also evaluates the health of all the services for the application this way. Service Fabric では、アプリケーション サービスの正常性が、サービスのレプリカなど、それらの子の正常性を集約することでさらに評価されます。Service Fabric further evaluates the health of the application services by aggregating the health of their children, such as the service replica. アプリケーションの正常性ポリシーが満たされると、アップグレードを続行できます。Once the application health policy is satisfied, the upgrade can proceed. 正常性ポリシーに違反すると、アプリケーションのアップグレードは失敗します。If the health policy is violated, the application upgrade fails.

アップグレード モードUpgrade modes

アプリケーションのアップグレードに推奨されるモードは、監視対象モードです。これは、よく使用されるモードです。The mode that we recommend for application upgrade is the monitored mode, which is the commonly used mode. 監視対象モードでは、1 つの更新ドメインでアップグレードを実行し、(指定されたポリシーに従って) すべての正常性チェックに合格すると、自動的に次の更新ドメインに移ります。Monitored mode performs the upgrade on one update domain, and if all health checks pass (per the policy specified), moves on to the next update domain automatically. 正常性チェックが失敗した場合やタイムアウトに達した場合は、更新ドメインのアップグレードはロールバックされるか、監視対象外手動モードに切り替えられます。If health checks fail and/or time-outs are reached, the upgrade is either rolled back for the update domain, or the mode is changed to unmonitored manual. アップグレードを構成するときに、この 2 つのモードのいずれかを、アップグレードが失敗した場合のモードとして選択できます。You can configure the upgrade to choose one of those two modes for failed upgrades.

監視対象外手動モードでは、更新ドメインですべてのアップグレードが行われた後、次の更新ドメインでアップグレードを開始するために、手動操作が必要になります。Unmonitored manual mode needs manual intervention after every upgrade on an update domain, to kick off the upgrade on the next update domain. Service Fabric の正常性チェックは実行されません。No Service Fabric health checks are performed. 管理者は、次の更新ドメインでアップグレードを開始する前に、正常性または状態のチェックを実行します。The administrator performs the health or status checks before starting the upgrade in the next update domain.

既定のサービスをアップグレードするUpgrade default services

アプリケーションのアップグレードの一環として、アプリケーション マニフェストで定義されている一部の既定のサービス パラメーターもアップグレードできます。Some default service parameters defined in the application manifest can also be upgraded as part of an application upgrade. アップグレードの一環として変更できるのは、Update-ServiceFabricService による変更がサポートされているサービス パラメーターのみです。Only the service parameters that support being changed through Update-ServiceFabricService can be changed as part of an upgrade. アプリケーションのアップグレード時に既定のサービス パラメーターを変更する動作は次のとおりです。The behavior of changing default services during application upgrade is as follows:

  1. クラスターに既に存在していない新しいアプリケーション マニフェストの既定のサービスは、作成されます。Default services in the new application manifest that do not already exist in the cluster are created.
  2. 以前のアプリケーション マニフェストと新しいアプリケーション マニフェストの両方に存在している既定のサービスは、更新されます。Default services that exist in both the previous and new application manifests are updated. 新しいアプリケーション マニフェストの既定のサービスのパラメーターによって、既存のサービスのパラメーターが上書きされます。The parameters of the default service in the new application manifest overwrite the parameters of the existing service. 既定のサービスの更新が失敗した場合、アプリケーションのアップグレードは自動的にロールバックされます。The application upgrade will rollback automatically if updating a default service fails.
  3. 新しいアプリケーション マニフェストに存在しない既定のサービスがクラスターに存在する場合は、削除されます。Default services that do not exist in the new application manifest are deleted if they exist in the cluster. 既定のサービスを削除すると、そのサービスの状態がすべて削除され、元には戻せないことに注意してください。Note that deleting a default service will result in deleting all that service's state and cannot be undone.

アプリケーションのアップグレードがロールバックされるときは、既定のサービス パラメーターがアップグレード開始前の古い値に戻されますが、削除されたサービスを以前の状態で再作成することはできません。When an application upgrade is rolled back, default service parameters are reverted back to their old values before the upgrade started but deleted services cannot be re-created with their old state.

ヒント

上記のルール 2) および 3) (既定のサービスの更新と削除) を有効にするには、EnableDefaultServicesUpgrade クラスター構成設定を true にする必要があります。The EnableDefaultServicesUpgrade cluster config setting must be true to enable rules 2) and 3) above (default service update and deletion). この機能は、Service Fabric バージョン 5.5 以降でサポートされています。This feature is supported starting in Service Fabric version 5.5.

HTTPS エンドポイントを持つ複数のアプリケーションのアップグレードUpgrading multiple applications with HTTPS endpoints

HTTPS の使用時は、同じアプリケーションの異なるインスタンスに対して同じポートを使用しないように注意する必要があります。You need to be careful not to use the same port for different instances of the same application when using HTTPS. その理由は、Service Fabric は任意の 1 つのアプリケーション インスタンスの証明書をアップグレードできないためです。The reason is that Service Fabric won't be able to upgrade the cert for one of the application instances. たとえば、アプリケーション 1 とアプリケーション 2 で証明書 1 を証明書 2 にアップグレードする必要があるとします。For example, if application 1 or application 2 both want to upgrade their cert 1 to cert 2. アップグレードが発生した場合、もう一方のアプリケーションが使用中であるのにもかかわらず、Service Fabric が http.sys により証明書 1 の登録をクリーンアップしてている可能性があります。When the upgrade happens, Service Fabric might have cleaned up the cert 1 registration with http.sys even though the other application is still using it. これを回避するために、Service Fabric は、証明書を持つポートに登録された他のアプリケーション インスタンスが既にあることを検出し (http.sys により)、その操作を失敗させます。To prevent this, Service Fabric detects that there is already another application instance registered on the port with the certificate (due to http.sys) and fails the operation.

そのため、Service Fabric では、異なるアプリケーション インスタンスで同じポートを使用して 2 つの異なるサービスをアップグレードすることはできません。Hence Service Fabric does not support upgrading two different services using the same port in different application instances. つまり、同じポート上の異なるサービスで同じ証明書を使用することはできません。In other words, you cannot use the same certificate on different services on the same port. 同じポートで証明書を共有する必要がある場合は、必ずサービスを配置の制約がある異なるコンピューターに配置するようにしてください。If you need to have a shared certificate on the same port, you need to ensure that the services are placed on different machines with placement constraints. または、各アプリケーション インスタンスの各サービスに対して、可能であれば、Service Fabric 動的ポートを使用することを検討してください。Or consider using Service Fabric dynamic ports if possible for each service in each application instance.

https でアップグレードが失敗した場合、"Windows HTTP Server API が、ポートを共有するアプリケーションに対して複数の証明書をサポートしていない" ことを示す警告が表示されます。If you see an upgrade fail with https, an error warning saying "The Windows HTTP Server API does not support multiple certificates for applications that share a port.”

アプリケーション アップグレードのフローチャートApplication upgrade flowchart

以下に示すフローチャートは、Service Fabric アプリケーションのアップグレード プロセスをわかりやすく示しています。The flowchart following this paragraph can help you understand the upgrade process of a Service Fabric application. 特に、このフローでは 1 つの更新ドメインのアップグレードが成功または失敗と見なされるときに、HealthCheckStableDurationHealthCheckRetryTimeoutUpgradeHealthCheckInterval などのタイムアウトが制御にどのように役立つかを説明します。In particular, the flow describes how the time-outs, including HealthCheckStableDuration, HealthCheckRetryTimeout, and UpgradeHealthCheckInterval, help control when the upgrade in one update domain is considered a success or a failure.

Service Fabric アプリケーションのアップグレード プロセス

次のステップNext steps

Visual Studio を使用したアプリケーションのアップグレード に関する記事では、Visual Studio を使用してアプリケーションをアップグレードする方法について説明します。Upgrading your Application Using Visual Studio walks you through an application upgrade using Visual Studio.

PowerShell を使用したアプリケーションのアップグレードに関する記事では、PowerShell を使用したアプリケーションのアップグレードについて説明します。Upgrading your Application Using PowerShell walks you through an application upgrade using PowerShell.

アップグレード パラメーターを使用して、アプリケーションのアップグレード方法を制御します。Control how your application upgrades by using Upgrade Parameters.

データのシリアル化の方法を学ぶことで、アプリケーションのアップグレードに互換性を持たせます。Make your application upgrades compatible by learning how to use Data Serialization.

高度なトピック」を参照して、アプリケーションをアップグレードするときの高度な機能の使用方法を学習します。Learn how to use advanced functionality while upgrading your application by referring to Advanced Topics.

アプリケーションのアップグレードのトラブルシューティング」の手順を参照して、アプリケーションのアップグレードでの一般的な問題を修正します。Fix common problems in application upgrades by referring to the steps in Troubleshooting Application Upgrades.