Service Fabric クラスターでの Windows オペレーティング システムへのパッチの適用Patch the Windows operating system in your Service Fabric cluster

重要

2019 年 4 月 30 日の時点で、パッチ オーケストレーション アプリケーション バージョン 1.2.* はサポートされなくなりました。As of April 30, 2019, Patch Orchestration Application version 1.2.* is no longer supported. 必ず最新バージョンにアップグレードしてください。Be sure to upgrade to the latest version.

注意

仮想マシン スケール セットでの OS イメージの自動アップグレードの取得は、Azure でオペレーティング システムに修正プログラムが適用された状態を保つためのベスト プラクティスです。Getting automatic OS image upgrades on your virtual machine scale set is the best practice for keeping your operating system patched in Azure. 仮想マシン スケール セット ベースの OS イメージの自動アップグレードでは、スケール セットに Silver 以上の耐久性が必要です。Virtual Machine Scale Set based automatic OS image upgrades will require silver or greater durability on a scale set.

パッチ オーケストレーション アプリケーション (POA) は、Azure Service Fabric Repair Manager サービスのラッパーであり、Azure 以外でホストされるクラスターに対して構成ベースの OS 修正プログラム スケジュールを有効にします。Patch Orchestration Application (POA) is a wrapper around the Azure Service Fabric Repair Manager service, which enables configuration-based OS patch scheduling for non-Azure hosted clusters. POA は、Azure 以外でホストされるクラスターには必要ありませんが、更新ドメインによる修正プログラムのインストールのスケジュール設定は、ダウンタイムを発生させることなく Service Fabric クラスター ホストに修正プログラムを適用するために必要です。POA isn't required for non-Azure hosted clusters, but scheduling patch installation by update domain is required to patch Service Fabric cluster hosts without incurring downtime.

POA は、ダウンタイムを発生させることなく、Service Fabric クラスターでのオペレーティング システムへの修正プログラムの適用を自動化する Service Fabric アプリケーションです。POA is a Service Fabric application that automates operating system patching on a Service Fabric cluster without incurring downtime.

POA では次の機能が提供されます。POA provides the following features:

  • オペレーティング システムの更新プログラムの自動インストール:Automatic operating system update installation. オペレーティング システムの更新プログラムが自動的にダウンロードされ、インストールされます。Operating system updates are automatically downloaded and installed. クラスター ノードは、クラスターのダウンタイムを発生させることなく、必要に応じて再起動されます。Cluster nodes are rebooted as needed without incurring cluster downtime.

  • クラスター対応のパッチ適用と正常性の統合:Cluster-aware patching and health integration. POA が更新プログラムを適用している間に、クラスター ノードの正常性を監視します。While POA is applying updates, it monitors the health of the cluster nodes. クラスター ノードの場合、一度に 1 つのノード、または一度に 1 つの更新ドメインが更新されます。Cluster nodes are updated one node at a time or one update domain at a time. 修正プログラムの適用によってクラスターの正常性が低下した場合、問題の悪化を防ぐために修正プログラムの適用が停止されます。If the health of the cluster goes down because of the patching process, patching is stopped to prevent aggravating the problem.

POA の内部詳細Internal details of POA

POA は、次のサブコンポーネントで構成されます。POA is composed of the following subcomponents:

  • コーディネーター サービス:このサービスの役割は次のとおりです。Coordinator Service: This stateful service is responsible for:

    • クラスター全体における Windows Update ジョブを調整する。Coordinating the Windows Update job on the entire cluster.
    • 完了した Windows Update 操作の結果を保存する。Storing the result of completed Windows Update operations.
  • ノード エージェント サービス:このステートレス サービスは、すべての Service Fabric クラスター ノードで実行されます。Node Agent Service: This stateless service runs on all Service Fabric cluster nodes. このサービスは次の役割を担います。The service is responsible for:

    • ノード エージェント NTService をブートストラップする。Bootstrapping the Node Agent NTService.
    • ノード エージェント NTService の監視。Monitoring the Node Agent NTService.
  • ノード エージェント NTService:この Windows NT サービスは、上位の特権 (SYSTEM) で実行されます。Node Agent NTService: This Windows NT service runs at a higher-level privilege (SYSTEM). 一方、ノード エージェント サービスとコーディネーター サービスは、下位の特権 (NETWORK SERVICE) で実行されます。In contrast, the Node Agent Service and the Coordinator Service run at a lower-level privilege (NETWORK SERVICE). このサービスは、全クラスター ノードで次の Windows Update ジョブを実行する役割を担います。The service is responsible for performing the following Windows Update jobs on all the cluster nodes:

    • ノードでの Windows の自動更新を無効にする。Disabling automatic Windows updates on the node.
    • ユーザーが指定したポリシーに従って、Windows 更新プログラムをダウンロードしてインストールする。Downloading and installing Windows updates according to the policy the user has provided.
    • Windows 更新プログラムのインストール後にマシンを再起動する。Restarting the machine post-Windows updates installation.
    • Windows Update の結果をコーディネーター サービスにアップロードする。Uploading the results of Windows updates to the Coordinator Service.
    • 再試行回数の上限に達した後、操作が失敗した場合に正常性レポートを生成する。Reporting health reports if an operation has failed after it exhausts all retries.

注意

POA では Service Fabric Repair Manager サービスを使用して、ノードを無効または有効にし、正常性チェックを実行します。POA uses the Service Fabric Repair Manager service to disable or enable the node and perform health checks. POA によって作成される修復タスクでは、各ノードの Windows Update の進行状況を追跡します。The repair task created by POA tracks the Windows Update progress for each node.

前提条件Prerequisites

注意

最低限必要な .NET Framework バージョンは 4.6 です。The required minimum .NET Framework version is 4.6.

Repair Manager サービスを有効にする (まだ実行されていない場合)Enable the Repair Manager service (if it's not running already)

POA を使用するには、クラスターで Repair Manager サービスを有効にする必要があります。POA requires the Repair Manager service to be enabled on the cluster.

Azure クラスターAzure clusters

シルバー持続性層の Azure クラスターでは、Repair Manager サービスが既定で有効になっています。Azure clusters in the silver durability tier have the Repair Manager service enabled by default. ゴールド持続性層の Azure クラスターでは、クラスターが作成された時期に応じて、Repair Manager サービスが有効になっている場合となっていない場合があります。Azure clusters in the gold durability tier might or might not have the Repair Manager service enabled, depending on when those clusters were created. ブロンズ持続性層の Azure クラスターでは、既定では Repair Manager サービスは有効になっていません。Azure clusters in the bronze durability tier, by default, do not have the Repair Manager service enabled. サービスが既に有効になっている場合、Service Fabric Explorer のシステム サービス セクションでそれが実行されていることを確認できます。If the service is already enabled, you can see it running in the system services section in Service Fabric Explorer.

Azure ポータルThe Azure portal

クラスターを設定するときに、Azure portal から Repair Manager を有効にすることができます。You can enable Repair Manager from the Azure portal when you set up the cluster. クラスターの構成時に、 [アドオン機能] の下にある [Repair Manager を含める] オプションを選択します。When you're configuring the cluster, select the Include Repair Manager option under Add-on features.

Azure portal からの Repair Manager の有効化の画像

Azure Resource Manager デプロイ モデルThe Azure Resource Manager deployment model

Azure Resource Manager デプロイ モデルを使用して、新規および既存の Service Fabric クラスターで Repair Manager サービスを有効にすることもできます。Alternatively, you can use the Azure Resource Manager deployment model to enable the Repair Manager service on new and existing Service Fabric clusters. デプロイするクラスター用テンプレートを用意します。Get the template for the cluster that you want to deploy. サンプル テンプレートを使用することも、カスタムの Azure Resource Manager デプロイ モデル テンプレートを作成することもできます。You can either use the sample templates or create a custom Azure Resource Manager deployment model template.

Azure Resource Manager デプロイ モデル テンプレートを使用して Repair Manager サービスを有効にするには、次のようにします。To enable the Repair Manager service by using the Azure Resource Manager deployment model template, do the following:

  1. Microsoft.ServiceFabric/clusters リソースに対して、apiVersion2017-07-01-preview に設定されていることを確認します。Check to ensure that apiVersion is set to 2017-07-01-preview for the Microsoft.ServiceFabric/clusters resource. 異なる場合は、apiVersion2017-07-01.txt-preview 以降に更新する必要があります。If it's different, you need to update apiVersion to 2017-07-01-preview or later:

    {
        "apiVersion": "2017-07-01-preview",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        ...
    }
    
  2. fabricSettings セクションの後に次の addonFeatures セクションを追加して、Repair Manager サービスを有効にします。Enable the Repair Manager service by adding the following addonFeatures section after the fabricSettings section:

    "fabricSettings": [
        ...      
    ],
    "addonFeatures": [
        "RepairManager"
    ],
    
  3. これらの変更でクラスター テンプレートを更新した後、変更を適用して更新を完了させます。After you've updated your cluster template with these changes, apply them and let the update finish. これで、Repair Manager サービスがクラスターで実行されていることがわかります。You can now see the Repair Manager service running in your cluster. これは、Service Fabric Explorer のシステム サービス セクションでは fabric:/System/RepairManagerService と呼ばれます。It's called fabric:/System/RepairManagerService in the system services section in Service Fabric Explorer.

スタンドアロン オンプレミス クラスターStandalone on-premises clusters

新規または既存の Service Fabric クラスターで Repair Manager サービスを有効にする場合は、スタンドアロン Windows クラスターの構成設定を使用できます。To enable the Repair Manager service on a new or existing Service Fabric cluster, you can use the Configuration settings for standalone Windows cluster.

Repair Manager サービスを有効にするには、次のようにします。To enable the Repair Manager service:

  1. 次のように、一般的なクラスター構成apiVersion04-2017 以降に設定されていることを確認します。Check to ensure that apiVersion in General cluster configurations is set to 04-2017 or later, as shown here:

    {
        "name": "SampleCluster",
        "clusterConfigurationVersion": "1.0.0",
        "apiVersion": "04-2017",
        ...
    }
    
  2. 次のように、fabricSettings セクションの後に以下の addonFeatures セクションを追加して、Repair Manager サービスを有効にします。Enable the Repair Manager service by adding the following addonFeatures section after the fabricSettings section, as shown here:

    "fabricSettings": [
        ...      
    ],
    "addonFeatures": [
        "RepairManager"
    ],
    
  3. 更新されたクラスター マニフェストを使用して、新しいクラスターを作成するか、クラスター構成をアップグレードして、これらの変更でクラスター マニフェストを更新します。Update your cluster manifest with these changes by using the updated cluster manifest create a new cluster or upgrade the cluster configuration.

    更新されたクラスター マニフェストを使用してクラスターが実行された後、クラスターで実行されている Repair Manager サービスを確認できます。After the cluster is running with an updated cluster manifest, you can see the Repair Manager service running in your cluster. これは fabric:/System/RepairManagerService と呼ばれ、Service Fabric Explorer のシステム サービス セクションにあります。It's called fabric:/System/RepairManagerService, and it's in the system services section in Service Fabric Explorer.

すべてのノードの Windows 更新プログラムを構成するConfigure Windows updates for all nodes

Windows の自動更新では、複数のクラスター ノードが同時に再起動される可能性があるため、可用性が失われる場合があります。Automatic Windows updates might lead to availability loss, because multiple cluster nodes can restart at the same time. POA では、既定で、各クラスター ノードでの Windows の自動更新の無効化が試行されます。POA, by default, tries to disable the automatic Windows updates on each cluster node. ただし、管理者またはグループ ポリシーによって設定が管理されている場合は、"ダウンロードする前に通知する" ように Windows Update ポリシーを明示的に設定することをお勧めします。However, if the settings are managed by an administrator or a Group Policy, we recommend setting the Windows Update policy to “Notify before Download” explicitly.

アプリケーション パッケージをダウンロードするDownload the application package

アプリケーション パッケージをダウンロードするには、GitHub のパッチ オーケストレーション アプリケーションのリリース ページに移動します。To download the application package, go to the Patch Orchestration Application release page on GitHub.

POA の動作を構成するConfigure POA behavior

ニーズに合わせて POA の動作を構成することができます。You can configure POA behavior to meet your needs. アプリケーションを作成または更新するときにアプリケーション パラメーターを渡して、既定値をオーバーライドします。Override the default values by passing in the application parameter while you're creating or updating the application. Start-ServiceFabricApplicationUpgrade または New-ServiceFabricApplication コマンドレットに ApplicationParameter を指定することで、アプリケーション パラメーターを指定できます。You can provide application parameters by specifying ApplicationParameter to the Start-ServiceFabricApplicationUpgrade or New-ServiceFabricApplication cmdlets.

パラメーターParameter 種類Type 詳細Details
MaxResultsToCacheMaxResultsToCache longLong キャッシュする必要がある Windows Update の結果の最大数。The maximum number of Windows Update results that should be cached.

既定値は 3000 で、以下が前提となります。The default value is 3000, assuming that:
  - ノード数が 20 である。  - The number of nodes is 20.
  - 月あたりのノードの更新数が 5 である。  - The number of updates to a node per month is 5.
  - 操作あたりの結果の数を 10 にできる。  - The number of results per operation can be 10.
  - 過去 3 か月の結果を格納する必要がある。  - The results for the past three months should be stored.
TaskApprovalPolicyTaskApprovalPolicy 列挙型Enum
{ NodeWise, UpgradeDomainWise }{ NodeWise, UpgradeDomainWise }
TaskApprovalPolicy は、コーディネーター サービスが、Service Fabric クラスター ノードに Windows Update をインストールする際に使用するポリシーを示しています。TaskApprovalPolicy indicates the policy that is to be used by the Coordinator Service to install Windows updates across the Service Fabric cluster nodes.

使用できる値は、次のとおりです。The allowed values are:
NodeWise:Windows 更新プログラムは、一度に 1 つのノードにインストールされます。NodeWise: Windows updates are installed one node at a time.
UpgradeDomainWise:Windows 更新プログラムは、一度に 1 つの更新ドメインにインストールされますUpgradeDomainWise: Windows updates are installed one update domain at a time. (最大で、更新ドメインに属するすべてのノードに Windows 更新プログラムを適用できます)。(At the most, all the nodes belonging to an update domain can go for a Windows update.)

FAQ に関するセクションを参照してください。これは、クラスターに最適なポリシーを決定するのに役立ちます。To help decide which policy is best suited for your cluster, see the FAQ section.
LogsDiskQuotaInMBLogsDiskQuotaInMB longLong
(既定値:1024)(Default: 1024)
パッチ オーケストレーション アプリのログの最大サイズ (MB 単位)。このサイズまで、ノードでローカルに保存することができます。The maximum size of patch orchestration app logs in MB, which can be persisted locally on nodes.
WUQueryWUQuery stringstring
(既定値:IsInstalled=0)(Default: IsInstalled=0)
Windows 更新プログラムを取得するためのクエリ。Query to get Windows updates. 詳細については、WuQuery に関するページをご覧ください。For more information, see WuQuery.
InstallWindowsOSOnlyUpdatesInstallWindowsOSOnlyUpdates BooleanBoolean
(既定値: false)(default: false)
このフラグを使用して、どの更新プログラムをダウンロードしてインストールするかを制御します。Use this flag to control which updates should be downloaded and installed. 次の値が許可されていますFollowing values are allowed
true - Windows オペレーティング システムの更新プログラムのみをインストールします。true - Installs only Windows operating system updates.
false - マシンで使用可能なすべての更新プログラムをインストールします。false - Installs all the available updates on the machine.
WUOperationTimeOutInMinutesWUOperationTimeOutInMinutes intInt
(既定値:90)(Default: 90)
Windows Update 操作 (検索、ダウンロード、インストール) のタイムアウトを指定します。Specifies the timeout for any Windows Update operation (search or download or install). 指定したタイムアウト時間内に操作が完了しなかった場合は、操作が中止されます。If the operation is not completed within the specified timeout, it is aborted.
WURescheduleCountWURescheduleCount intInt
(既定値:5)(Default: 5)
操作が繰り返し失敗する場合に、サービスで Windows 更新プログラムの再スケジュールを行う最大回数。The maximum number of times the service reschedules the Windows update if an operation fails persistently.
WURescheduleTimeInMinutesWURescheduleTimeInMinutes intInt
(既定値:30)(Default: 30)
問題が解決しない場合に、サービスで Windows 更新プログラムの再スケジュールを行う間隔。The interval at which the service reschedules the Windows updates if failure persists.
WUFrequencyWUFrequency コンマ区切りの文字列 (既定値:Weekly, Wednesday, 7:00:00)Comma-separated string (Default: Weekly, Wednesday, 7:00:00) Windows 更新プログラムをインストールする頻度。The frequency for installing Windows updates. 形式と指定できる値は次のとおりです。The format and possible values are:
  - Monthly:DD, HH:MM:SS (たとえば、Monthly, 5,12:22:32)  - Monthly: DD, HH:MM:SS (for example, Monthly, 5,12:22:32)
DD (日) フィールドに使用できる値は、1 から 28 の数字と "last" です。Permitted values for field DD (day) are numbers from 1 through 28 and "last".
  - Weekly, DAY, HH:MM:SS (たとえば、Weekly, Tuesday, 12:22:32)  - Weekly, DAY, HH:MM:SS (for example, Weekly, Tuesday, 12:22:32)
  - Daily, HH:MM:SS (たとえば、Daily, 12:22:32)  - Daily, HH:MM:SS (for example, Daily, 12:22:32)
  - None は、Windows 更新プログラムが実行されないことを示します。  - None indicates that Windows updates shouldn't be done.

時刻は UTC 形式です。Times are in UTC.
AcceptWindowsUpdateEulaAcceptWindowsUpdateEula BooleanBoolean
(既定値: true)(Default: true)
このフラグを設定すると、コンピューターの所有者に代わって、アプリケーションが Windows Update の使用許諾契約に同意します。By setting this flag, the application accepts the End-User License Agreement for Windows Update on behalf of the owner of the machine.

ヒント

Windows 更新プログラムをすぐに実行する場合は、アプリケーションのデプロイ時間を基準として WUFrequency を設定します。If you want Windows updates to happen immediately, set WUFrequency relative to the application deployment time. たとえば、5 ノード テスト クラスターがあり、UTC 時刻の午後 5 時頃にアプリケーションをデプロイする予定であるとします。For example, suppose that you have a five-node test cluster and plan to deploy the app at around 5:00 PM UTC. アプリケーションのアップグレードまたはデプロイに最大 30 分かかると想定される場合、WUFrequency を Daily, 17:30:00 に設定します。If you assume that the application upgrade or deployment takes 30 minutes at most, set the WUFrequency as Daily, 17:30:00.

POA をデプロイするDeploy POA

  1. 前提条件となるすべての手順を実行してクラスターを準備します。Finish all the prerequisite steps to prepare the cluster.

  2. 他の Service Fabric アプリと同様に POA をデプロイします。Deploy POA like any other Service Fabric app. PowerShell を使用してデプロイする場合は、「PowerShell を使用してアプリケーションのデプロイと削除を実行する」を参照してください。To deploy it by using PowerShell, see Deploy and remove applications using PowerShell.

  3. デプロイ時にアプリケーションを構成するには、ApplicationParameterNew-ServiceFabricApplication コマンドレットに渡します。To configure the application at the time of deployment, pass the ApplicationParameter to the New-ServiceFabricApplication cmdlet. 利便性のために、アプリケーションと共に Deploy.ps1 スクリプトが用意されています。For your convenience, we’ve provided the script Deploy.ps1 along with the application. このスクリプトを使用するには、次の手順に従います。To use the script:

    • Connect-ServiceFabricCluster を使用して Service Fabric クラスターに接続します。Connect to a Service Fabric cluster by using Connect-ServiceFabricCluster.
    • 適切な ApplicationParameter 値を指定して、Deploy.ps1 PowerShell スクリプトを実行します。Execute the PowerShell script Deploy.ps1 with the appropriate ApplicationParameter value.

注意

スクリプトとアプリケーション フォルダー PatchOrchestrationApplication は同じディレクトリに保存しておいてください。Keep the script and the application folder PatchOrchestrationApplication in the same directory.

POA をアップグレードするUpgrade POA

PowerShell を使用して POA のバージョンをアップグレードするには、「PowerShell を使用した Service Fabric アプリケーションのアップグレード」の手順に従います。To upgrade your POA version by using PowerShell, follow the instructions in Service Fabric application upgrade using PowerShell.

POA を削除するRemove POA

アプリケーションを削除するには、「PowerShell を使用してアプリケーションのデプロイと削除を実行する」の手順に従います。To remove the application, follow the instructions in Deploy and remove applications using PowerShell.

参考までに、アプリケーションと共に Undeploy.ps1 スクリプトを提供しています。For your convenience, we've provided the Undeploy.ps1 script along with the application. このスクリプトを使用するには、次の手順に従います。To use the script:

  • Connect-ServiceFabricCluster を使用して Service Fabric クラスターに接続します。Connect to a Service Fabric cluster by using Connect-ServiceFabricCluster.
  • Undeploy.ps1 PowerShell スクリプトを実行します。Execute the PowerShell script Undeploy.ps1.

注意

スクリプトとアプリケーション フォルダー PatchOrchestrationApplication は同じディレクトリに保存してください。Keep the script and the application folder PatchOrchestrationApplication in the same directory.

Windows Update の結果の確認View the Windows Update results

POA では、結果の履歴をユーザーに表示するための REST API を公開しています。POA exposes REST APIs to display the historical results to users. 結果の JSON の例を次に示します。Here's an example of the result JSON:

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

JSON のフィールドについては、次の表で説明します。The JSON fields are described in the following table:

フィールドField Values 詳細Details
OperationResultOperationResult 0 - 成功0 - Succeeded
1 - 成功 (エラーあり)1 - Succeeded With Errors
2 - 失敗2 - Failed
3 - 中止3 - Aborted
4 - タイムアウトにより中止4 - Aborted With Timeout
操作全体 (通常は 1 つまたは複数の更新プログラムのインストールを含む) の結果を示します。Indicates the result of the overall operation, which ordinarily involves the installation of one or more updates.
ResultCodeResultCode OperationResult と同じSame as OperationResult このフィールドでは、個々の更新プログラムのインストール操作の結果が示されます。This field indicates the result of the installation operation for an individual update.
OperationTypeOperationType 1 - インストール1 - Installation
0 - 検索とダウンロード0 - Search and Download
既定では、インストールが、結果に表示される唯一の OperationType です。By default, Installation is the only OperationType that's shown in the results.
WindowsUpdateQueryWindowsUpdateQuery 既定値は "IsInstalled=0"Default is "IsInstalled=0" 更新プログラムの検索に使用された Windows Update クエリ。The Windows Update query that was used to search for updates. 詳細については、WuQuery に関するページを参照してください。For more information, see WuQuery.
RebootRequiredRebootRequired true - 再起動が必要true - reboot was required
false - 再起動は不要false - reboot was not required
更新プログラムのインストールを完了するのに再起動が必要だったかどうかを示します。Indicates whether a reboot was required to complete the installation of updates.
OperationStartTimeOperationStartTime DateTimeDateTime 操作 (ダウンロード/インストール) が開始した時刻を示します。Indicates the time at which operation(Download/Installation) started.
OperationTimeOperationTime DateTimeDateTime 操作 (ダウンロード/インストール) が完了した時刻を示します。Indicates the time at which operation(Download/Installation) was completed.
HResultHResult 0 - 成功0 - Successful
その他 - 失敗other - failure
updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6" で Windows 更新プログラムの失敗の理由を示します。Indicates the reason for the failure of the Windows update with updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

更新がまだスケジュールされていない場合、結果の JSON は空になります。If no update is scheduled yet, the result JSON is empty.

Windows Update の結果を照会するには、クラスターにサインインします。Sign in to the cluster to query Windows Update results. コーディネーター サービスのプライマリ アドレス用のレプリカ IP アドレスを見つけて、ブラウザーから http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults という URL を開きます。Find out the replica IP address for the primary address of the Coordinator Service, and open the following URL from the browser: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

コーディネーター サービスの REST エンドポイントには動的ポートがあります。The REST endpoint for the Coordinator Service has a dynamic port. 正確な URL を確認するには、Service Fabric Explorer を参照します。To check the exact URL, refer to Service Fabric Explorer. たとえば、 http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults で結果を入手できます。For example, the results are available at http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

REST エンドポイントの画像

クラスターでリバース プロキシが有効になっている場合は、クラスターの外部からも URL にアクセスできます。If the reverse proxy is enabled on the cluster, you can access the URL from outside the cluster as well.

ヒットする必要があるエンドポイントは、http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults です。The endpoint that you need to hit is http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

クラスターでリバース プロキシを有効にするには、「Azure Service Fabric のリバース プロキシ」の手順に従います。To enable the reverse proxy on the cluster, follow the instructions in Reverse proxy in Azure Service Fabric.

警告

リバース プロキシが構成された後、クラスター内の、HTTP エンドポイントを公開するすべてのマイクロサービスが、クラスターの外部からアドレス指定可能になります。After the reverse proxy is configured, all microservices in the cluster that expose an HTTP endpoint are addressable from outside the cluster.

診断および正常性イベントDiagnostics and health events

このセクションでは Service Fabric クラスターの POA を使用して、修正プログラムの問題をデバッグまたは診断する方法について説明します。This section discusses how to debug or diagnose issues with patch updates through POA on Service Fabric clusters.

注意

以下に示されている自己診断の機能向上の多くを得るには、POA バージョン 1.4.0 以降がインストールされている必要があります。To get many of the following called-out, self-diagnostic improvements, you should have POA version 1.4.0 or later installed.

ノード エージェント NTService では、ノードに更新プログラムをインストールするために修復タスクを作成します。The Node Agent NTService creates repair tasks for installing updates on the nodes. その後、各タスクは、タスク承認ポリシーに従って、コーディネーター サービスによって準備されます。Each task is then prepared by the Coordinator Service according to the task approval policy. 最後に、準備されたタスクは Repair Manager によって承認されますが、クラスターが異常な状態にある場合は、どのタスクも承認されません。Finally, the prepared tasks are approved by Repair Manager, which doesn't approve any task if the cluster is in an unhealthy state.

ノードでの更新プログラムの進行について理解できるように、段階的に見ていきましょう。To help you understand how updates proceed on a node, let's go step by step:

  1. すべてのノード上で実行されている NodeAgentNTService では、スケジュールされた時刻に使用可能な Windows 更新プログラムを検索します。NodeAgentNTService, running on every node, looks for available Windows updates at the scheduled time. 更新プログラムが使用可能な場合、それらをノード上にダウンロードします。If updates are available, it downloads them on the node.

  2. 更新プログラムがダウンロードされた後、ノード エージェント NTService では POS___<unique_id> の名前で、ノードの対応する修復タスクを作成します。After the updates are downloaded, the Node Agent NTService creates a corresponding repair task for the node with the name POS___<unique_id>. これらの修復タスクは、Get-ServiceFabricRepairTask コマンドレットを使用するか、ノードの詳細セクションで SFX を使用して表示できます。You can view these repair tasks by using the Get-ServiceFabricRepairTask cmdlet or using SFX in the node details section. 修復タスクが作成された後、すぐに要求済み状態に移ります。After the repair task is created, it quickly moves to Claimed state.

  3. コーディネーター サービスでは、定期的に要求済み状態の修復タスクを検索し、TaskApprovalPolicy に基づいてそれらを準備中状態に更新します。The Coordinator Service periodically looks for repair tasks in Claimed state and then updates them to Preparing state based on TaskApprovalPolicy. TaskApprovalPolicy が NodeWise になるように構成されている場合、現在、準備中承認済み実行中、または復元中の状態になっている他の修復タスクがない場合にのみ、ノードに対応した修復タスクが準備されます。If TaskApprovalPolicy is configured to be NodeWise, a repair task that corresponds to a node is prepared only if no other repair task is currently in Preparing, Approved, Executing, or Restoring state.

    同様に、UpgradeWise TaskApprovalPolicy の場合は、同じ更新ドメインに属しているノードに対してのみ、上記の状態でタスクが存在します。Similarly, in the case of UpgradeWise TaskApprovalPolicy, there are tasks in the preceding states only for nodes that belong to the same update domain. 修復タスクが準備中状態に移された後、対応する Service Fabric ノードが、再起動の意図で無効になります。After a repair task is moved to Preparing state, the corresponding Service Fabric node is disabled with the intent set to Restart.

    POA バージョン 1.4.0 以降では、CoordinatorService の ClusterPatchingStatus プロパティを使用してイベントをポストし、修正プログラムが適用されているノードを表示します。POA versions 1.4.0 and later post events with the ClusterPatchingStatus property on CoordinatorService to display the nodes that are being patched. 次の画像に示すように、更新プログラムは _poanode_0 にインストールされます。The updates are installed on _poanode_0, as shown in the following image:

    修正プログラム適用中状態のクラスターの画像Image of cluster patching status

  4. ノードが無効になった後、修復タスクは実行中状態に移されます。After the node is disabled, the repair task is moved to Executing state.

    注意

    無効状態でスタックしているノードでは、新しい修復タスクがブロックされる可能性があり、これにより、クラスターでの修正プログラムの適用操作が停止します。A node that's stuck in Disabled state can block a new repair task, which halts the patching operation on the cluster.

  5. 修復タスクが実行中状態になると、そのノードへの修正プログラムのインストールが開始されます。When the repair task is in Executing state, the patch installation on that node begins. 修正プログラムがインストールされた後、ノードは、修正プログラムに応じて、再起動される場合とされない場合があります。After the patch is installed, the node might or might not be restarted, depending on the patch. 次に、修復タスクが修復中状態に移され、これにより、ノードが再び有効になります。Next, the repair task is moved to Restoring state, which reenables the node. その後、修復タスクが完了済みとマークされます。The repair task is then marked as completed.

    POA バージョン 1.4.0 以降では、WUOperationStatus-<NodeName> プロパティを使用して NodeAgentService の正常性イベントを表示して、更新プログラムの状態を確認できます。In POA versions 1.4.0 and later, you can find the status of the update by viewing the health events on NodeAgentService with the WUOperationStatus-<NodeName> property. 下の画像で強調表示されたセクションには、ノード poanode_0 および poanode_2 での Windows 更新プログラムの状態が示されています。The highlighted sections in the following images show the status of Windows updates on nodes poanode_0 and poanode_2:

    Windows Update 操作の状態の画像Image of Windows Update operation status

    Windows Update 操作の状態の画像Image of Windows Update operation status

    PowerShell を使用して詳細を取得することもできます。You can also get the details by using PowerShell. これを行うには、クラスターに接続し、Get-ServiceFabricRepairTask を使用して修復タスクの状態を取り込みます。To do so, you connect to the cluster and fetch the state of the repair task by using Get-ServiceFabricRepairTask.

    次の例では、"POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" タスクは DownloadComplete 状態にあります。In the following example, the "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" task is in DownloadComplete state. これは、更新プログラムが poanode_2 ノードにダウンロードされており、タスクが実行中状態に移ったときにインストールが試みられることを意味します。It means that updates have been downloaded on the poanode_2 node, and the installation will be attempted when the task moves to Executing state.

     D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"
    
     D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
     {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}
    

    問題が解決しない場合は、ご利用の仮想マシン (VM) または複数の VM にサインインし、Windows イベント ログを使用して詳細を確認してください。If more issues remain to be found, sign in to your virtual machine (VM) or VMs and learn about them by using Windows event logs. 前述の修復タスクは、次の Executor の下位状態でのみ存在できます。The previously mentioned repair task can exist in only the following executor substates:

    ExecutorSubStateExecutorSubState 説明Description
    None=1None=1 ノードに実行中の操作がなかったことを意味します。Implies that there wasn't an ongoing operation on the node. 状態が遷移中である可能性があります。The state might be in transition.
    DownloadCompleted=2DownloadCompleted=2 ダウンロード操作が成功したか、一部失敗したか、失敗したかを示します。Implies that the download operation was completed with success, partial failure, or failure.
    InstallationApproved=3InstallationApproved=3 ダウンロード操作が以前に完了しており、Repair Manager でインストールが承認されたことを示します。Implies that the download operation was completed earlier and Repair Manager has approved the installation.
    InstallationInProgress=4InstallationInProgress=4 修復タスクの実行の状態に対応します。Corresponds to the state of execution of the repair task.
    InstallationCompleted=5InstallationCompleted=5 インストールが成功したか、一部成功したか、失敗したかを示します。Implies that the installation was completed with success, partial success, or failure.
    RestartRequested=6RestartRequested=6 修正プログラムのインストールが完了し、ノード上に保留中の再起動アクションがあることを示します。Implies that the patch installation was completed and there's a pending restart action on the node.
    RestartNotNeeded=7RestartNotNeeded=7 修正プログラムのインストールの完了後に再起動が必要なかったことを示します。Implies that the restart wasn't needed after the patch installation was completed.
    RestartCompleted=8RestartCompleted=8 再起動が正常に完了したことを示します。Implies that the restart was completed successfully.
    OperationCompleted=9OperationCompleted=9 Windows Update 操作が正常に完了しました。The Windows Update operation was completed successfully.
    OperationAborted=10OperationAborted=10 Windows Update 操作が中止されたことを示します。Implies that the Windows Update operation was aborted.
  6. POA バージョン 1.4.0 以降では、ノードの更新の試行が完了した場合、Windows 更新プログラムのダウンロードとインストールの次回の試行が開始されるときに通知するために、"WUOperationStatus-[NodeName]" プロパティを使用するイベントが NodeAgentService にポストされます。In POA versions 1.4.0 and later, when a node update attempt finishes, an event with the "WUOperationStatus-[NodeName]" property is posted on NodeAgentService to notify you when the next attempt to download and install the Windows updates will begin. これは次の画像のように表示されます。This is displayed in the following image:

    Windows Update 操作の状態の画像Image of Windows Update operation status

[診断ログ]Diagnostics logs

パッチ オーケストレーション アプリケーションのログは、Service Fabric のランタイム ログの一部として収集されます。Patch orchestration application logs are collected as part of the Service Fabric runtime logs.

ログは、任意の診断ツールまたはパイプラインを使用してキャプチャできます。You can capture logs by using the diagnostic tool or pipeline of your choice. POA では次の固定プロバイダー ID を使用して、イベント ソースを介してイベントをログに記録します。POA uses the following fixed provider IDs to log events via event source:

  • e39b723c-590c-4090-abb0-11e3e6616346e39b723c-590c-4090-abb0-11e3e6616346
  • fc0028ff-bfdc-499f-80dc-ed922c52c5e9fc0028ff-bfdc-499f-80dc-ed922c52c5e9
  • 24afa313-0d3b-4c7c-b485-1047fd964b6024afa313-0d3b-4c7c-b485-1047fd964b60
  • 05dc046c-60e9-4ef7-965e-91660adffa6805dc046c-60e9-4ef7-965e-91660adffa68

正常性レポートHealth reports

また、POA では、次のシナリオでノード エージェント サービスまたはコーディネーター サービスに対して正常性レポートを発行します。POA also publishes health reports against the Node Agent Service or the Coordinator Service in the following scenarios:

  • ノード エージェント NTService がダウンしている場合The Node Agent NTService is down

    ノードでノード エージェント NTService がダウンしている場合、ノード エージェント サービスに対して警告レベルの正常性レポートが生成されます。If the Node Agent NTService is down on a node, a warning-level health report is generated against the Node Agent Service.

  • Repair Manager サービスが有効になっていない場合The Repair Manager service is not enabled

    クラスターで Repair Manager サービスが見つからない場合、コーディネーター サービスに対して警告レベルの正常性レポートが生成されます。If the Repair Manager service is not found on the cluster, a warning-level health report is generated for the Coordinator Service.

よく寄せられる質問Frequently asked questions

Q:POA の実行中に、クラスターがエラー状態になるのはなぜですか?Q: Why do I see my cluster in an error state when POA is running?

A:インストール プロセス中に、POA ではノードを無効にするか再起動します。これにより、一時的にクラスターが異常な状態になる可能性があります。A: During the installation process, POA disables or restarts nodes, which can temporarily result in an unhealthy cluster.

アプリケーションのポリシーに応じて、修正プログラムの適用操作中にいずれか 1 つのノードがダウンするか、または更新ドメイン全体が同時にダウンすることがあります。Depending on the application's policy, either one node can go down during a patching operation or an entire update domain can go down all at once.

Windows 更新プログラムのインストールが完了するまでに、ノードは再起動後に再び有効になります。By the end of the Windows updates installation, the nodes are reenabled post-restart.

次の例では、2 つのノードがダウンし、MaxPercentageUnhealthyNodes ポリシーに違反しているため、クラスターが一時的にエラー状態になっています。In the following example, the cluster went to an error state temporarily because two nodes were down and the MaxPercentageUnhealthyNodes policy was violated. このエラーは、修正プログラムの適用操作を開始できるようになるまでの一時的なものです。The error is temporary until the patching operation can begin.

異常なクラスターの画像

問題が解決しない場合は、「トラブルシューティング」を参照してください。If the issue persists, refer to the Troubleshooting section.

Q:POA が警告状態にある場合はどうすればよいですか?Q: What can I do if POA is in a warning state?

A:アプリケーションに対してポストされた正常性レポートで根本原因が示されているかどうかを確認してください。A: Check to see whether a health report posted against the application indicates the root cause. 通常、警告には問題の詳細が含まれています。Usually, the warning contains details of the problem. 問題が一時的なものである場合、アプリケーションは自動的に回復することが予想されます。If the issue is transient, the application is expected to recover automatically.

Q:クラスターに異常があり、オペレーティング システムの更新をすぐに実行する必要がある場合はどうすればよいですか?Q: What can I do if my cluster is unhealthy and I need to do an urgent operating system update?

A:クラスターに異常がある間は、POA によって更新プログラムはインストールされません。A: POA does not install updates while the cluster is unhealthy. POA ワークフローのブロックを解除するために、クラスターが正常な状態になるようにしてみてください。Try to bring your cluster to a healthy state to unblock the POA workflow.

Q:クラスターの "NodeWise" または "UpgradeDomainWise" として TaskApprovalPolicy を設定する必要はありますか?Q: Should I set TaskApprovalPolicy as "NodeWise" or "UpgradeDomainWise" for my cluster?

A:"UpgradeDomainWise" 設定では、更新ドメインに属するすべてのノードに並列して修正プログラムを適用することで、クラスター全体の修復を高速化します。A: The "UpgradeDomainWise" setting speeds up overall cluster repair by patching in parallel all the nodes that belong to an update domain. このプロセス中は、更新ドメイン全体に属するノードを使用できません (無効状態になっている)。During the process, nodes that belong to an entire update domain are unavailable (in Disabled state).

これに対して、"NodeWise" 設定では、一度に 1 つのノードのみに修正プログラムが適用されます。これは、クラスター全体の修正プログラムの適用に時間がかかる可能性があることを意味します。In contrast, the "NodeWise" setting patches only one node at a time, which would imply that overall cluster patching might take longer. ただし、修正プログラムの適用プロセス中に利用不可 (無効状態) になるのは、最大でも 1 つのノードのみです。However, only one node at most would be unavailable (in Disabled state) during the patching process.

修正プログラムの適用サイクル中に、クラスターで N-1 個の更新ドメイン (N はクラスター上の更新ドメインの総数) 上での実行を許容できる場合は、ポリシーを "UpgradeDomainWise" として設定できます。If your cluster can tolerate running on an N-1 number of update domains during patching cycle (where N is the total number of update domains on your cluster) you can set the policy as "UpgradeDomainWise." それ以外の場合は、"NodeWise" に設定します。Otherwise, set it to "NodeWise."

Q:ノードに修正プログラムを適用するにはどのくらい時間がかかりますか?Q: How much time does it take to patch a node?

A:ノードへの修正プログラムの適用には、数分 (たとえば、Windows Defender 定義の更新プログラム) から数時間 (たとえば、Windows の累積的な更新プログラム) かかることがあります。A: Patching a node can take from minutes (for example, Windows Defender definition updates) to hours (for example, Windows Cumulative updates). ノードに修正プログラムを適用するために必要な時間は、主に以下によって異なります。The time that's required to patch a node depends mostly on:

  • 更新プログラムのサイズ。The size of the updates.
  • 修正プログラムの適用期間内に適用する必要がある、更新プログラムの数。The number of updates, which have to be applied in a patching window.
  • 更新プログラムのインストール、ノードの再起動 (必要な場合)、および再起動後のインストール手順の完了にかかる時間。The time it takes to install the updates, reboot the node (if required), and finish the post-reboot installation steps.
  • VM またはマシンのパフォーマンス、およびネットワークの状態。The performance of the VM or machine, and network conditions.

Q:クラスター全体に修正プログラムを適用するにはどのくらい時間がかかりますか?Q: How long does it take to patch an entire cluster?

A:クラスター全体に修正プログラムを適用するために必要な時間は、以下によって異なります。A: The time that's required to patch an entire cluster depends on:

  • ノードに修正プログラムを適用するために必要な時間。The time needed to patch a node.

  • コーディネーター サービスのポリシー。The policy of the Coordinator Service. 既定のポリシーである "NodeWise" では、一度に 1 つのノードのみに修正プログラムが適用されます。この方法では、"UpgradeDomainWise" を使用するよりも低速になります。The default policy, "NodeWise," results in patching only one node at a time, an approach that's slower than using "UpgradeDomainWise."

    例: ノードに修正プログラムを適用するのに最大 1 時間かかる場合、5 個の更新ドメインがあり、それぞれに 4 個のノードが含まれている、20 個のノード (同じ種類のノード) のクラスターに修正プログラムを適用する場合は、以下が必要です。For example: If a node takes ~1 hour to be patched, patching a 20-node (same type of nodes) cluster with 5 update domains, each containing 4 nodes, requires:

    • "NodeWise" の場合: 最大 20 時間。For "NodeWise": ~20 hours.
    • "UpgradeDomainWise" の場合: 最大 5 時間。For "UpgradeDomainWise": ~5 hours.
  • クラスターの負荷。The cluster load. 修正プログラムの適用操作ごとに、クラスター内の他の利用可能なノードに顧客のワークロードを再配置する必要があります。Each patching operation requires relocating the customer workload to other available nodes in the cluster. 修正プログラムが適用されているノードは、この間は無効化中状態になります。A node that's being patched would be in Disabling state during this time. クラスターがピーク時の負荷に近い状態で実行されている場合、無効化プロセスには時間がかかります。If the cluster is running near peak load, the disabling process would take longer. そのため、このような負荷状態では、修正プログラムの適用プロセス全体が遅く見えることがあります。Therefore, the overall patching process might appear to be slow in such stressed conditions.

  • 修正プログラムの適用中に発生したクラスターの正常性エラー。Cluster health failures during patching. クラスターの正常性低下した場合、修正プログラムの適用プロセスは中断されます。Any degradation in the health of the cluster would interrupt the patching process. この問題により、クラスター全体に修正プログラムを適用するために必要な全体的な時間が増えます。This issue would add to the overall time required to patch the entire cluster.

Q:Windows Update の結果で一部の更新プログラムが REST API 経由で取得されたと表示されますが、マシンの Windows Update 履歴に表示されないのはなぜですか?Q: Why do I see some updates in the Windows Update results that are obtained via REST API, but not under the Windows Update history on the machine?

A:一部の製品の更新プログラムは、独自の更新プログラムまたは修正プログラムの履歴にのみ表示されます。A: Some product updates appear only in their own update or patch history. たとえば、Windows Defender の更新プログラムは、Windows Server 2016 の Windows Update 履歴に表示される場合とされない場合があります。For example, Windows Defender updates might or might not be displayed in Windows Update history on Windows Server 2016.

Q:POA を使用して、自分の開発クラスター (1 ノード クラスター) に修正プログラムを適用できますか?Q: Can POA be used to patch my dev cluster (one-node cluster)?

A:いいえ、POA を使用して 1 ノード クラスターに修正プログラムを適用することはできません。A: No, POA can't be used to patch a one-node cluster. Service Fabric システム サービスまたはその他の顧客アプリでダウンタイムが発生するため、この制限は設計によるものです。This limitation is by design, because Service Fabric system services or other customer apps would incur downtime. したがって、修復ジョブへの修正プログラムの適用が Repair Manager によって承認されることはありません。Therefore, patching repair jobs would never get approved by Repair Manager.

Q:Linux 上のクラスター ノードに修正プログラムを適用するにはどうすればよいですか?Q: How do I patch cluster nodes on Linux?

A:Linux での更新プログラムのオーケストレーションの詳細については、「Azure 仮想マシン スケール セットによる OS イメージの自動アップグレード」を参照してください。A: To learn about orchestrating updates on Linux, see Azure virtual machine scale set automatic OS image upgrades.

Q:更新サイクルにこれほど時間がかかるのはなぜですか?Q: Why is the update cycle taking so long?

A:結果の JSON を照会し、すべてのノードの更新サイクルに入ってから、OperationStartTime と OperationTime(OperationCompletionTime) を使用してすべてのノードで更新プログラムのインストールにかかる時間を確認してみることができます。A: Query for the result JSON, enter the update cycle for all nodes, and then you can try to find out the time taken by update installation on every node by using OperationStartTime and OperationTime (OperationCompletionTime).

更新が行われていない大きな時間枠がある場合、クラスターはエラー状態にある可能性があるため、Repair Manager では POA の修復タスクを承認できません。If there's a large time window in which no update is taking place, the cluster might be in an error state and, consequently, Repair Manager can't approve any POA repair tasks. 任意のノードで更新プログラムのインストールに時間がかかる場合、そのノードはしばらくの間、更新されていない可能性があります。If the update installation is taking a long time on any node, that node might not have been updated in a while. 多くの更新プログラムのインストールが保留中である可能性があり、これにより、遅延が発生することがあります。A lot of updates might be pending installation, which can result in delays.

また、無効化中状態でスタックしているため、ノードへの修正プログラムの適用がブロックされている可能性があります。It might also be possible that node patching is blocked because it's stuck in Disabling state. これは通常、ノードの無効化により、クォーラムまたはデータ損失の状況が発生する可能性があるためです。This usually happens because disabling the node might lead to quorum or data loss situations.

Q:POA でノードに修正プログラムを適用するときに、そのノードを無効にする必要があるのはなぜですか?Q: Why must the node be disabled when POA is patching it?

A:POA では、ノード上で実行されているすべての Service Fabric サービスを停止または再割り当てする、再起動の意図でノードを無効にします。A: POA disables the node with a Restart intent, which stops or reallocates all the Service Fabric services that are running on the node. POA ではこれを行って、アプリケーションで新規および古い DLL を組み合わせて使用することにならないようにします。したがって、ノードを無効にせずに修正プログラムを適用することはお勧めできません。POA does this to ensure that applications don't end up using a mix of new and old DLLs, so we recommend not patching a node without disabling it.

免責事項Disclaimers

  • POA では、ユーザーに代わって、Windows Update の使用許諾契約書に同意します。POA accepts the End-User License Agreement for Windows Update on behalf of the user. 必要に応じて、アプリケーションの構成でこの設定をオフにすることもできます。Optionally, the setting can be turned off in the configuration of the application.

  • POA では、使用状況とパフォーマンスを追跡するためにテレメトリを収集します。POA collects telemetry to track usage and performance. アプリケーションのテレメトリの設定は、Service Fabric ランタイムのテレメトリ設定 (既定でオン) に従います。The application’s telemetry follows the setting of the Service Fabric runtime’s telemetry setting (which is on by default).

トラブルシューティングTroubleshooting

このセクションでは、ノードへの修正プログラムの適用に関する問題に対して考えられるトラブルシューティング ソリューションを提供します。This section provides possible troubleshooting solutions to problems with patching nodes.

ノードが稼働状態に戻らないA node is not coming back to up state

  • 以下の理由により、ノードが 無効中状態でスタックしている可能性があります。The node might be stuck in Disabling state because:

    • 安全性チェックが保留中になっています。A safety check is pending. この状況を改善するには、十分な数のノードが正常な状態で稼働するように対策を講じてください。To remedy this situation, ensure that enough nodes are available in a healthy state.
  • 次の理由により、ノードが無効状態でスタックしている可能性があります。The node might be stuck in Disabled state because:

    • 手動で無効にされた。It was disabled manually.
    • 進行中の Azure インフラストラクチャ ジョブによって無効にされた。It was disabled because of an ongoing Azure infrastructure job.
    • ノードに修正プログラムを適用するために POA によって一時的に無効にされた。It was disabled temporarily by POA to patch the node.
  • 次の理由により、ノードがダウン状態でスタックしている可能性があります。The node might be stuck in a down state because:

    • 手動でダウン状態にされた。It was placed in a down state manually.
    • 再起動されている (POA によってトリガーされる可能性がある)。It is undergoing a restart (which might be triggered by POA).
    • VM またはマシンに障害があるか、ネットワーク接続に問題がある。It has a faulty VM or machine, or it's having network connectivity issues.

一部のノードで更新がスキップされたUpdates were skipped on some nodes

POA では、再スケジュール ポリシーに従って、Windows 更新プログラムのインストールを試行します。POA tries to install a Windows update according to the rescheduling policy. サービスはアプリケーション ポリシーに従って、ノードを復旧し、更新をスキップします。The service tries to recover the node and skip the update according to the application policy.

このような場合、ノード エージェント サービスに対して警告レベルの正常性レポートが生成されます。In such a case, a warning-level health report is generated against the Node Agent Service. Windows Update の結果には、エラーの考えられる理由も含まれます。The Windows Update result also contains the possible reason for the failure.

更新プログラムのインストール中にクラスターの正常性がエラーになるThe health of the cluster goes to error while the update is being installed

Windows 更新プログラムの障害によって、特定のノードまたは更新ドメインでアプリケーションやクラスターの正常性が低下する場合があります。A faulty Windows update can bring down the health of an application or cluster on a particular node or update domain. POA では、クラスターが正常な状態に戻るまで、以降の Windows Update 操作を中断します。POA discontinues any subsequent Windows Update operation until the cluster is healthy again.

管理者が介入し、Windows Update によってアプリケーションやクラスターが異常な状態になった原因を特定する必要があります。An administrator must intervene and determine why the application or cluster became unhealthy because of Windows Update.

POA のリリース ノートPOA release notes

注意

POA バージョン 1.4.0 以降の場合、リリース ノートとリリースは、GitHub のパッチ オーケストレーション アプリケーションのリリース ページで確認できます。For POA versions 1.4.0 and later, you can find release notes and releases on the Patch Orchestration Application release page on GitHub.

バージョン 1.1.0Version 1.1.0

  • 公開リリースPublic release

バージョン 1.1.1Version 1.1.1

  • NodeAgentNTService をインストールできない NodeAgentService の SetupEntryPoint のバグを修正しました。Fixed a bug in SetupEntryPoint of NodeAgentService that prevented installation of NodeAgentNTService.

バージョン 1.2.0Version 1.2.0

  • システム再起動ワークフローに関連するバグを修正しました。Bug fixes around system restart workflow.
  • 修復タスクの準備中に正常性チェックが予定どおりに実行されないために発生する RM タスク作成時のバグを修正しました。Bug fix in creation of RM tasks due to which health check during preparing repair tasks wasn't happening as expected.
  • Windows サービス POANodeSvc のスタートアップ モードを auto から delayed-auto に変更しました。Changed the startup mode for Windows service POANodeSvc from auto to delayed-auto.

バージョン 1.2.1Version 1.2.1

  • クラスターのスケール ダウン ワークフローのバグ修正。Bug fix in cluster scale-down workflow. 導入された POA 用のガベージ コレクション ロジックは、存在しないノードに属するタスクを修正します。Introduced garbage collection logic for POA repair tasks belonging to non-existent nodes.

バージョン 1.2.2Version 1.2.2

  • 各種のバグ修正。Miscellaneous bug fixes.
  • バイナリが署名されるようになりました。Binaries are now signed.
  • アプリケーションの sfpkg リンクを追加しました。Added sfpkg link for the application.

バージョン 1.3.0Version 1.3.0

  • InstallWindowsOSOnlyUpdates を false に設定すると、使用可能なすべての更新プログラムがインストールされるようになりました。Setting InstallWindowsOSOnlyUpdates to false now installs all the available updates.
  • 自動更新を無効にするロジックを変更しました。Changed the logic of disabling automatic updates. これにより、Server 2016 以降で自動更新が無効にならないバグが修正されます。This fixes a bug where Automatic updates were not getting disabled on Server 2016 and above.
  • 高度なユース ケースのために POA の両方のマイクロサービスのデプロイ制約をパラメーター化しました。Parameterized placement constraint for both the microservices of POA for advanced use cases.

バージョン 1.3.1Version 1.3.1

  • 自動更新の無効化の失敗により、Windows Server 2012 R2 以前で POA 1.3.0 が動作しない回帰を修正しました。Fixing regression where POA 1.3.0 won't work on Windows Server 2012 R2 or earlier because of a failure in disabling automatic updates.
  • InstallWindowsOSOnlyUpdates の構成が常に True として選択されるバグを修正しました。Fixing bug where InstallWindowsOSOnlyUpdates configuration is always picked as True.
  • InstallWindowsOSOnlyUpdates の既定値を False に変更します。Changing default value of InstallWindowsOSOnlyUpdates to False.

バージョン 1.3.2Version 1.3.2

  • 現在のノード名のサブセットである名前を持つノードがある場合に、ノードでの修正プログラム適用のライフサイクルに影響する問題を修正しました。Fixing an issue that affects the patching lifecycle on a node, if there are nodes with a name that's a subset of the current node name. このようなノードでは、修正プログラムが適用されなかったか、再起動が保留中である可能性があります。For such nodes, it's possible that patching was missed or a reboot is pending.