私は複数のデータセンターにまたがる Docker Swarm を使用しています。Swarm は「仮想プライベート クラウド」で実行されます。
セットアップに参加しているデータ センターの 1 つは、他のデータ センターよりもリンクがやや遅いです。そのデータ センターでは、特に遅延の影響を受けやすいサービスをスケジュールしないようにしたいと思います。
- 配置制約を使用することもできますが、可用性に影響します。何らかの理由で「遅い」データ センターのみが稼働している場合、制約により、制約されたサービスがそのデータ センターでスケジュールされないようになります。可用性に影響します。
- 配置設定を使用できますが、これは単なる設定です。「低速」データ センター内のノードを除くすべてのノードにラベルを追加した場合
lowlatency、サービスは引き続きそこにスケジュールされる可能性があります。結局のところ、これは単なる設定です。
サービスを特定のノードに制限しながら、優先ノードが利用できない場合に Docker が他のノードでサービスをスケジュールできるようにする方法はありますか?
答え1
いいえ、これは Swarm Mode に組み込まれた機能ではありません。
現在利用可能な唯一の配置設定は、ラベルの値全体にワークロードを分散することです。これは、すべてのレプリカが単一のアベイラビリティ ゾーンにスケジュールされるのを回避するために使用されます (たとえば、すべてのワークロードが同じラック、データセンターなどにあるなど)。ソフト制約のように機能する配置設定はありません。
スウォーム スケジューリングで利用できるもう 1 つのオプションは制約であり、これは厳格な制限です。制約に一致しないノードではワークロードはスケジュールされません。これは、ワークロードがどこにもスケジュールできず、サービスがダウンしたままになることを意味します。
目的に最も近い方法は、他のすべてのデータセンターの停止を検出し、サービスの制約を調整する追加プロセスを実行することですが、それには 2 つの関連する問題が発生すると思われます。まず、他のデータセンターが停止すると、マネージャーとのクォーラムが失われる可能性が高く、スケジュール アクティビティは発生せず、実行中のマネージャーへのコマンドはリーダーの喪失により失敗します。次に、クォーラムがある場合、残りのデータセンターのノードは、再スケジュールされている他のワークロードによって過剰にプロビジョニングされる可能性があります。これは、コンテナーに CPU とメモリの要件を設定する必要がある、サンダーリング ハード問題として知られています。これらの要件により、ノードでの新しいジョブのスケジュールがブロックされ、さらなる停止が回避され、変更されたサービスが容量のあるノードを見つけられなくなります。