Service Fabric クラスター リソース マネージャーは Service Fabric でアップグレードを実行しませんが、それに関係します。 クラスター リソース マネージャーが管理に役立つ第 1 の点は、クラスターとクラスター内のサービスの望ましい状態を追跡できることです。 クラスター リソース マネージャーは、クラスターを目的の構成に配置できない場合に正常性レポートを送信します。 たとえば、容量が不足している場合、クラスター リソース マネージャーは問題を示す正常性の警告とエラーを送信します。 統合のもう 1 つの利点は、アップグレードのしくみに関係があります。 クラスター リソース マネージャーは、アップグレード中、動作を若干変更します。
健康の統合
クラスター リソース マネージャーは、サービスの配置用に定義したルールを常に追跡しています。 また、ノードとクラスターの各メトリックと、クラスター全体のメトリックについて、残りの容量も追跡しています。 これらの規則を満たさない場合、または十分な容量がない場合は、状態警告とエラーが出力されます。 たとえば、ノードの容量が超過している場合、クラスター リソース マネージャーはサービスを移動することで状況の修正を試みます。 状況を修正できない場合、容量超過のノードとそのメトリックを示す正常性の警告を出力します。
リソース マネージャーの正常性に関する警告の例として、他には配置の制約違反があります。 たとえば、配置の制約 (“NodeColor == Blue” など) を定義してある場合に、リソース マネージャーによってその制約の違反が検出されると、正常性の警告が出力されます。 これには、カスタム制約と既定の制約 (障害ドメインの制約、アップグレード ドメインの制約など) が該当します。
こちらがそのような健康レポートの例の1つです。 このケースの正常性レポートは、システム サービスのパーティションの 1 つに関するものです。 この正常性メッセージは、このパーティションのレプリカが一時的に少数のアップグレード ドメインに詰め込まれていることを示しています。
PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'
PartitionId : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations :
Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.
ReplicaHealthStates :
ReplicaId : 130766528804733380
AggregatedHealthState : Ok
ReplicaId : 130766528804577821
AggregatedHealthState : Ok
ReplicaId : 130766528854889931
AggregatedHealthState : Ok
ReplicaId : 130766528804577822
AggregatedHealthState : Ok
ReplicaId : 130837073190680024
AggregatedHealthState : Ok
HealthEvents :
SourceId : System.PLB
Property : ReplicaConstraintViolation_UpgradeDomain
HealthState : Warning
SequenceNumber : 130837100116930204
SentAt : 8/10/2015 7:53:31 PM
ReceivedAt : 8/10/2015 7:53:33 PM
TTL : 00:01:05
Description : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
RemoveWhenExpired : True
IsExpired : False
Transitions : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM
この健康メッセージが私たちに伝えていることは次の通りです。
- すべてのレプリカは正常に動作しており、各々に
AggregatedHealthState : Okがあります。 - アップグレード ドメインの分配制約が現在違反されています。 これは、特定のアップグレード ドメインのレプリカ数が、そのパーティションの限度よりも多いことを示します。
- 違反を起こしているレプリカを含むノード。 この場合は、Node.8 という名前のノードです。
- このパーティションでアップグレードが現在実行されているかどうか ("Currently Upgrading -- false")
- このサービスの分散ポリシー:"Distribution Policy -- Packing"。 これは
RequireDomainDistributionの配置ポリシーで制御されます。 パッキング は、この場合 DomainDistribution がt_必要でなかったため、このサービスに配置ポリシーが指定されなかったことがわかっていることを示します。 - レポートの生成日時 (2015 年 8 月 10 日午後 7 時 13 分 2 秒)
この種の情報はアラートを生成します。 運用環境でアラートを使用することにより、何か問題が発生したことを把握できます。 不適切なアップグレードを検出して停止する際にもアラートが使用されます。 このケースでは、リソース マネージャーがアップグレード ドメインにレプリカをまとめる必要があったのはなぜなのか、理由を探ることができます。 通常、他のアップグレード ドメインのノードがダウンしていたためなどの理由で、パッキングは一時的なものです。
たとえば、クラスター リソース マネージャーが何らかのサービスを配置しようとしていて、うまくいくソリューションがないとします。 サービスを配置できない場合は、通常、次のいずれかの理由が考えられます。
- 一時的な状態によって、このサービス インスタンスまたはレプリカを正しく配置できない。
- サービスの配置要件は満たすことができません。
このような場合は、クラスター リソース マネージャーの正常性レポートから、サービスを配置できない理由を判断できます。 このプロセスを、"制約除外シーケンス" と呼んでいます。 このプロセスでは、サービスに影響する構成済み制約を確認して、その制約によって除外されたものを記録します。 このようにして、配置できないサービスがある場合は、どのノードがどのような理由で除外されたかを確認できます。
制約の種類
これらの健康レポートの各種制約について説明します。 レプリカを配置できない場合は、これらの制約に関連する正常性メッセージが表示されます。
- ReplicaExclusionStatic と ReplicaExclusionDynamic:これらの制約は、同じパーティションの 2 つのサービス オブジェクトを同じノードに配置する必要があったため、ソリューションが拒否されたことを示しています。 そのノードの障害はそのパーティションに過度に影響するため、これは許可されません。 ReplicaExclusionStatic と ReplicaExclusionDynamic はほぼ同じルールです。違いはあまり問題ではありません。 制約除外シーケンスに ReplicaExclusionStatic 制約または ReplicaExclusionDynamic 制約のいずれかが含まれている場合、クラスター リソース マネージャーによってノードが十分にないと認識されます。 この場合、許可されていないこれらの無効な配置を、残りのソリューションで使用する必要があります。 このシーケンスの他の制約で、通常、最初の段階でノードが除外された理由がわかります。
- PlacementConstraint:このメッセージが表示された場合、サービスの配置の制約に一致しなかったために、ノードが除外されたことを意味します。 現在構成されている配置の制約をこのメッセージの一部としてトレースします。 これは配置の制約を定義していれば正常です。 配置制約によってノードが誤って過度に除外されている場合、それがわかる方法は次のとおりです。
- NodeCapacity:この制約は、指定されたノードにレプリカを配置するとそのノードが容量超過になるため、クラスター リソース マネージャーがレプリカを配置できなかったことを意味します。
- Affinity:この制約は、影響を受けるノードにレプリカを配置すると、アフィニティ制約違反が発生するため、レプリカを配置できなかったことを示します。 アフィニティの詳細については、こちらの記事を参照してください。
- FaultDomain と UpgradeDomain: 指定されたノードにレプリカを配置することで、特定の障害ドメインまたはアップグレード ドメインに集約される場合、この制約によってそのノードが除外されます。 この制約に関するいくつかの例は、「 障害ドメインとアップグレードドメインの制約とそれに伴う動作」に関するトピックで紹介されています。
- PreferredLocation:この制約は既定で最適化として実行されるため、通常、ノードがソリューションから削除されることはありません。 優先される場所の制約は、アップグレード中にも適用されます。 アップグレード中は、アップグレードの開始時にサービスを元の場所に戻すために使用されます。
ノードをブロックリストに登録する
クラスター リソース マネージャーは、ノードがブロックリストに登録されたときにも、正常性メッセージを報告します。 ブロックリストの登録は、自動的に適用される一時的な制約と考えることができます。 そのサービスの種類のインスタンスを起動するときに、繰り返しエラーが発生する場合、ノードはブロックリストに登録されます。 ノードは、サービスの種類ごとにブロックリストに登録されます。 あるサービスの種類ではブロックリストに登録されているノードでも、別のサービスでは登録されていない可能性があります。
開発中にブロックリストの開始が頻繁に表示されます。一部のバグにより、起動時にサービス ホストがクラッシュし、Service Fabric がサービス ホストの作成を数回試行し、エラーが発生し続けます。 何度かの試行後に、ノードはブロックリストに登録され、クラスター リソース マネージャーは別のノードでサービスの作成を試行します。 複数のノードでそのエラーが発生し続けると、クラスター内のすべての有効なノードがブロックされる結果になる可能性があります。 ブロックリストの登録によって、多数のノードが削除され、目的の規模を満たすサービスを正常に起動できなくなる可能性があります。 一般的に、サービスが目的のレプリカ数またはインスタンス数を下回っていることを示す追加のエラーや警告、最初の段階でブロックリスト登録の原因となったエラーを示す正常性メッセージを、クラスター リソース マネージャーから受け取ります。
ブロックリストの登録は永続的な状態ではありません。 数分後にノードがブロックリストから削除され、Service Fabric がそのノードで再びサービスを有効にすることができるようになる可能性があります。 サービスが引き続き失敗する場合、そのサービスの種類についてそのノードはブロックリストに再登録されます。
制約の優先順位
警告
制約の優先順位を変更することは推奨されません。クラスターに大きな悪影響が及ぶ可能性があります。 既定の制約の優先順位とその動作については、以下の情報を参照してください。
これらの制約のすべてを考慮した時、「ねえ、障害ドメインの制約が私のシステムで最も重要なことだと思っているかもしれませんが」と考えていたかもしれません。 障害ドメインの制約に違反しないようにするために、他の制約に違反してもよい、と考えるかもしれません。
制約は、さまざまな優先度レベルで構成できます。 次のとおりです。
- "hard" (0)
- "ソフト" (1)
- "最適化" (2)
- “off” (-1)
ほとんどの制約は、既定で hard 制約として構成されます。
制約の優先順位の変更は一般的ではありません。 制約の優先順位を変更する必要がある場合もあります。通常は、環境に影響していた何か他のバグや動作を回避するためです。 一般に、制約優先度インフラストラクチャの柔軟性は良好に機能していますが、頻繁には必要ありません。 ほとんどの場合、すべて既定の優先順位のままです。
優先度レベルは、特定の制約に 違反する ことを示すものではなく、常に満たすものでもありません。 制約の優先順位で、制約を適用する順序を定義します。 優先順位は、すべての制約を満たすことが不可能な場合のトレードオフを定義します。 通常、環境内で何か他のことが起こっていない場合、すべての制約を満たすことができます。 制約違反につながるシナリオの例としては、制約の競合や多数の同時エラーがあります。
高度な状況では、制約の優先順位を変更できます。 たとえば、ノードの容量の問題を解決する必要があるときに、常にアフィニティが違反されるようにしたい場合があります。 アフィニティの制約の優先順位を "ソフト" (1) に設定して、容量の制約の設定を "ハード" (0) のままにしておきます。
さまざまな制約に関する既定の優先順位の値は、次の構成で指定します。
ClusterManifest.xml
<Section Name="PlacementAndLoadBalancing">
<Parameter Name="PlacementConstraintPriority" Value="0" />
<Parameter Name="CapacityConstraintPriority" Value="0" />
<Parameter Name="AffinityConstraintPriority" Value="0" />
<Parameter Name="FaultDomainConstraintPriority" Value="0" />
<Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
<Parameter Name="PreferredLocationConstraintPriority" Value="2" />
</Section>
スタンドアロン デプロイの ClusterConfig.json 経由または Azure でホストされたクラスターの Template.json 経由:
"fabricSettings": [
{
"name": "PlacementAndLoadBalancing",
"parameters": [
{
"name": "PlacementConstraintPriority",
"value": "0"
},
{
"name": "CapacityConstraintPriority",
"value": "0"
},
{
"name": "AffinityConstraintPriority",
"value": "0"
},
{
"name": "FaultDomainConstraintPriority",
"value": "0"
},
{
"name": "UpgradeDomainConstraintPriority",
"value": "1"
},
{
"name": "PreferredLocationConstraintPriority",
"value": "2"
}
]
}
]
障害ドメインとアップグレード ドメインの制約
クラスター リソース マネージャーは、障害ドメインとアップグレード ドメインにサービスを分散しようとします。 これは、クラスター リソース マネージャーのエンジン内の制約としてモデル化されます。 使用方法とその具体的な動作の詳細については、 クラスター構成に関する記事を参照してください。
クラスター リソース マネージャーは、アップグレード、障害、または他の制約違反に対処するために、いくつかのレプリカをアップグレード ドメインにまとめなければならない場合があります。 障害ドメインとアップグレード ドメインへのパッキングは、通常、適切な配置を妨げる障害やその他の問題がシステムに存在している場合にのみ行われます。 このような状況でもパッキングを回避するには、RequireDomainDistribution の配置ポリシーを利用します。 ただし、これを行うと、副作用としてサービスの可用性と信頼性に影響が及ぶ可能性があるため、慎重に検討してください。
環境が正しく構成されている場合、アップグレード中であってもすべての制約が完全に順守されます。 重要なのは、クラスター リソース マネージャーが制約を監視している点です。 違反が検出されると、すぐに報告し、問題の解決を試行します。
優先される場所の制約
PreferredLocation 制約は、2 つの用途があるため、少し異なります。 この制約の用途の 1 つは、アプリケーションのアップグレード中です。 クラスター リソース マネージャーは、アップグレード中に、この制約を自動的に管理します。 アップグレードの完了後に、レプリカを初期の場所に確実に戻すために使用されます。 PreferredLocation 制約のもう 1 つの用途は、PreferredPrimaryDomain 配置ポリシー用です。 これらの両方が最適化なので、PreferredLocation 制約だけが既定で "最適化" に設定されています。
アップグレード
クラスター リソース マネージャーは、アプリケーションとクラスターのアップグレード中にも役に立ちます。この間、クラスター リソース マネージャーは 2 つのジョブを実行します。
- クラスターのルールが損なわれないようにする
- アップグレードが円滑に進行するようサポートを試みる
ルール適用の維持
主に注意しなければならないのは、ルール、つまり配置の制約と容量などに関連する厳密な制御は、アップグレード中も適用されるという点です。 配置の制約により、アップグレード中であっても、ワークロードは許可されている場所でのみ実行されます。 サービスの制約が多い場合、アップグレードに時間がかかる可能性があります。 サービスまたはノードが更新のために停止される場合、移行先の選択肢は限られている可能性があります。
スマート置換
アップグレードが始まると、リソース マネージャーは、クラスターにおける現在の配置のスナップショットを取得します。 各アップグレード ドメインが完了すると、アップグレード ドメインにあったサービスを元の配置に戻そうとします。 この方法では、アップグレード中に行われるサービスの移行は最大 2 個です。 影響を受けたノードから移動する動きが1つあり、再びノードに戻る動きが1つあります。 アップグレード前の状態にクラスターまたはサービスを戻すと、アップグレードによるクラスターのレイアウトへの影響もなくなります。
動きの軽減
アップグレード中に、Cluster Resource Managerの負荷分散もオフになります。 分散を一時停止すると、アップグレード自体に対する不要な反応 (たとえば、アップグレード用に空にされたノードへのサービスの移動) を回避できます。 実行するアップグレードがクラスターのアップグレードである場合、アップグレード中はクラスター全体の分散が行われません。 制約チェックはアクティブなままで、メトリックの事前の負荷分散に基づいた移動のみが無効になります。
バッファー容量とアップグレード
一般に、クラスターが制約を受けたりいっぱいに近づいたりするとしても、ユーザーはアップグレードを完了したいと考えます。 アップグレード中は、クラスターの容量を管理できることが通常よりもいっそう重要になります。 アップグレード ドメインの数に応じて、容量の5％から20％がクラスターを通じてアップグレード中に移行する必要があります。 この作業は、どこかの場所で実行される必要があります。 このような場合、バッファーの容量の概念が役立ちます。 通常の操作では、バッファーの容量が遵守されます。 クラスター リソース マネージャーは、アップグレード中に必要に応じて合計容量までノードを使用する (バッファーを消費する) 可能性があります。