Azure Service Fabric クラスターのアップグレードと更新

Azure Service Fabric クラスターはお客様が所有するリソースですが、一部は Microsoft によって管理されています。 この記事では、Azure Service Fabric クラスターをいつ、どのように更新するかの選択について説明します。

自動と手動のアップグレード

Service Fabric クラスターでサポートされているランタイム バージョンが常に実行されていることが重要です。 Microsoft が Service Fabric の新バージョン リリースをアナウンスするたびに、その日から最短で 60 日後には、以前のバージョンがサポート期間の終了として指定されます。 新しいリリースは、Service Fabric チーム ブログで発表されます。

現在クラスターで実行されているバージョンの有効期間が終了する 14 日前に、正常性に関するイベントが生成され、クラスターの正常性が "警告" 状態に移行します。 サポートされているランタイム バージョンにアップグレードするまで、クラスターは警告状態のままとなります。

クラスターの設定でMicrosoft からリリースされる Service Fabric の自動アップグレードを受信するようにできます。また、現在サポートされているバージョンの一覧から手動で選択することもできます。 これらのオプションは、Service Fabric クラスター リソースの [ファブリックのアップグレード] セクションにあります。

また、Resource Manager テンプレートを使用して、クラスターのアップグレード モードの設定とランタイム バージョンの選択をすることもできます。

自動アップグレードが推奨されるアップグレード モードである理由は、このオプションによってクラスターがサポートされている状態に維持され、最新の修正プログラムや機能を利用できるようになるためです。また、Wave デプロイ方式を使用して、ワークロードの中断を最小限にする方法で更新をスケジュールすることもできます。

Wave デプロイによる自動アップグレード

Wave デプロイでは、アップグレードの成熟度レベルをワークロードに応じて選択することで、アップグレードによるクラスターの中断を最小限に抑えることができます。 たとえば、"テスト" -> "ステージ" -> "運用" の Wave デプロイ パイプラインをさまざまな Service Fabric クラスターに設定することで、ランタイム アップグレードを運用ワークロードに適用する前に、その互換性をテストできます。

Wave デプロイをオプトインするには、次の Wave 値のいずれかをクラスターに (そのデプロイ テンプレート内で) 指定します。

• Wave 0: クラスターは、新しい Service Fabric ビルドがリリースされるとすぐに更新されます。 テストおよび開発クラスターが対象です。
• Wave 1: クラスターは、新しいビルドがリリースされてから 1 週間 (7 日) 後に更新されます。 運用前およびステージング クラスターが対象です。
• Wave 2: クラスターは、新しいビルドがリリースされてから 2 週間 (14 日) 後に更新されます。 運用クラスターが対象です。

クラスターのアップグレードが失敗した場合のヘルプへのリンクを含む電子メール通知を登録できます。 開始するには、「Wave デプロイによる自動アップグレード」を参照してください。

自動アップグレードのフェーズ

Microsoft は、Azure クラスターで実行される Service Fabric ランタイム コードと構成を管理します。 必要に応じて、ソフトウェアに対して自動監視付きアップグレードを実行します。 これらのアップグレードは、コード、構成、またはその両方で行うことができます。 これらのアップグレードによるアプリケーションへの影響を最小限に抑えるため、次のフェーズで行います。

フェーズ 1:アップグレードが、すべてのクラスター正常性ポリシーを使用して実行される

このフェーズ中、アップグレード ドメインは 1 つずつ処理され、クラスターで実行されていたアプリケーションはダウンタイムなしで実行され続けます。 クラスター正常性ポリシー (ノードの正常性とアプリケーションの正常性) は、アップグレード中、遵守されます。

クラスター正常性ポリシーが満たされていない場合、アップグレードはロールバックされ、サブスクリプションの所有者に電子メールが送信されます。 この電子メールには以下の情報が含まれています。

• クラスターのアップグレードをロールバックする必要があるという通知
• 推奨される対応策 (ある場合)
• フェーズ 2 を実行するまでの日数 (n)。

インフラストラクチャに関する理由でアップグレードに失敗した場合は、同じアップグレードが数回実行されます。 電子メールの送信日から n 日後に、フェーズ 2 に進みます。

クラスター正常性ポリシーが満たされた場合は、アップグレードが成功したと見なされ、完了としてマークされます。 この状況は最初のアップグレード中に起きることもあれば、このフェーズの何回目かのアップグレードで起きることもあります。 電子メールが過剰に送信されるのを回避するため、正常に実行されたことを確認する電子メールはありません。 電子メールが届いたということは、正常な動作ではなかったことを意味します。 クラスターのアップグレードの大半は、アプリケーションの可用性に影響することなく、成功すると思われます。

フェーズ 2:アップグレードが、既定の正常性ポリシーのみを使用して実行される

このフェーズでの正常性ポリシーは、アップグレードの開始時に正常だったアプリケーションの数が、アップグレード プロセス中も同じ数であり続けるように設定されています。 フェーズ 1 のように、フェーズ 2 のアップグレードではアップグレード ドメインが 1 つずつ処理され、クラスターで実行されていたアプリケーションはダウンタイムなしで実行され続けます。 クラスター正常性ポリシー (ノードの正常性と、クラスターで実行されているすべてのアプリケーションの正常性の組み合わせ) は、アップグレードの実行中、遵守されます。

有効なクラスター正常性ポリシーが満たされていない場合は、アップグレードがロールバックされます。 その後、サブスクリプションの所有者に電子メールが送信されます。 この電子メールには以下の情報が含まれています。

• クラスターのアップグレードをロールバックする必要があるという通知
• 推奨される対応策 (ある場合)
• フェーズ 3 を実行するまでの日数 (n)。

インフラストラクチャに関する理由でアップグレードに失敗した場合は、同じアップグレードが数回実行されます。 リマインダーの電子メールが、n 日の数日前に送信されます。 電子メールの送信日から n 日後に、フェーズ 3 に進みます。 フェーズ 2 で送信された電子メールは、真剣に受け止め、修復操作を実行する必要があります。

クラスター正常性ポリシーが満たされた場合は、アップグレードが成功したと見なされ、完了としてマークされます。 このフェーズの最初のアップグレードで成功することも、何回目かの再実行で成功することもあります。 実行が成功した場合、電子メールでの確認はありません。

フェーズ 3: アップグレードが、アグレッシブな正常性ポリシーを使用して実行される

このフェーズでのこれらの正常性ポリシーは、アプリケーションの正常性よりもアップグレードの完了のために調整されています。 このフェーズで終了するクラスター アップグレードは、ほとんどありません。 クラスターがこのフェーズに達すると、アプリケーションが正常な状態でなくなったり、可用性が失われたりするおそれが高くなります。

他の 2 つのフェーズと同様に、フェーズ 3 でもアップグレード ドメインが 1 つずつ処理されます。

クラスター正常性ポリシーが満たされていない場合は、アップグレードがロールバックされます。 インフラストラクチャに関する理由でアップグレードに失敗した場合は、同じアップグレードが数回実行されます。 その後、そのクラスターはサポートやアップグレードを受信しなくなるように固定されます。

この情報と修復操作が記載された電子メールが、サブスクリプションの所有者に送信されます。 クラスターがフェーズ 3 でも失敗する状態になることは、想定していません。

クラスター正常性ポリシーが満たされた場合は、アップグレードが成功したと見なされ、完了としてマークされます。 このフェーズの最初のアップグレードで成功することも、何回目かの再実行で成功することもあります。 実行が成功した場合、電子メールでの確認はありません。

手動アップグレードのカスタム ポリシー

手動でクラスターをアップグレードするためのカスタム ポリシーを指定できます。 これらのポリシーは、新しいランタイム バージョンを選択するたびに適用されます。これにより、システムによってクラスターのアップグレードが開始されます。 ポリシーをオーバーライドしていない場合、既定の設定が使用されます。 詳しくは、手動アップグレードのためのカスタム ポリシーの設定に関する記事を参照してください。

その他のクラスター更新

ランタイムのアップグレード以外にも、クラスターを最新の状態に保つために実行する必要がある、次のような多数の操作があります。

証明書の管理

Service Fabric では、クラスターの作成時に指定した X.509 server certificates を使用して、クラスター ノード間の通信をセキュリティで保護し、クライアントを認証します。 Azure Portal からか、PowerShell または Azure CLI を使用して、クラスターとクライアントに対して証明書を追加、更新、または削除することができます。 詳細については、証明書の追加または削除に関するページを参照してください。

アプリケーション ポートを開く

アプリケーション ポートは、ノードの種類に関連付けられた Load Balancer リソースのプロパティを変更することで変更できます。 Azure Portal を使用するか、PowerShell または Azure CLI を使用できます。 詳細については、クラスターのアプリケーション ポートを開くことに関するページを参照してください。

ノードのプロパティの定義

場合によっては、特定のワークロードが、クラスター内の特定のノードの種類だけで確実に実行されるようにしたいことがあります。 たとえば、ワークロードの中に GPU や SSD を必要とするものとしないものが混在している場合があります。 クラスター内のノードの種類ごとに、カスタム ノードのプロパティをクラスター ノードに追加できます。 配置の制約は、1 つまたは複数のノードのプロパティに選択される個々のサービスに接続されるステートメントです。 配置の制約で、サービスを実行する場所を定義します。

配置の制約、ノードのプロパティの使用、およびプロパティの定義方法の詳細については、「ノードのプロパティと配置の制約」を参照してください。

容量メトリックの追加

ノードの種類ごとに、アプリケーションで負荷をレポートするために使用するカスタム容量メトリックを追加できます。 負荷をレポートする容量メトリックの使用方法については、Service Fabric クラスター リソース マネージャー ドキュメントの クラスターの説明 および メトリックと負荷 に関するページをご覧ください。

クラスターの設定のカスタマイズ

クラスターとノードのプロパティの信頼性レベルなど、多くの異なる構成設定は、クラスター上でカスタマイズできます。 詳細については、Service Fabric クラスターのファブリック設定に関するページを参照してください。

クラスター ノードの OS イメージのアップグレード

Service Fabric クラスター ノードの OS イメージの自動アップグレードを有効にすることをお勧めします。 そのためには、いくつかのクラスター要件と実行手順があります。 もう 1 つのオプションは、パッチ オーケストレーション アプリケーション (POA) を使用することです。これは、ダウンタイムなしで、Service Fabric クラスターでのオペレーティング システムへのパッチの適用を自動化する Service Fabric アプリケーションです。 これらのオプションについて詳しくは、「Service Fabric クラスターでの Windows オペレーティング システムへのパッチの適用」を参照してください。

次のステップ

• Service Fabric のアップグレードの管理
• Service Fabric クラスター設定のカスタマイズ
• クラスターのスケールイン/アウト
• アプリケーションのアップグレード