すべてのDockerSwarmノードをマネージャーとして実行することの長所と短所は？

Question

DockerSwarmクラスターの構築を検討しています。物事をシンプルかつ比較的フォールトトレラントに保つために、私は単に3つのノードをマネージャーとして実行することを考えました。

専用のワーカーノードを使用しない場合のトレードオフは何ですか？はっきりしないかもしれないことを私が知っておくべきことはありますか？

私はこれを見つけました Githubの問題これは同様の質問をしますが、答えは私には少しあいまいです。パフォーマンスが低下する可能性があると記載されています。また、コンセンサスに達するまでに時間がかかることにも言及しています。実際には、どの機能が遅くなりますか？そして、「コンセンサスに達するまでに時間がかかる」ことは実際に何に影響しますか？

Bret Fisher · Accepted Answer

TL;スウォームの労働者としてのすべてのマネージャーのDRの長所と短所：

長所：

サーバーが3台または5台しかない製品品質のHA
設計/管理のシンプルさ
デフォルトでも安全です（シークレットはディスク上で暗号化され、相互TLS認証とコントロールプレーン上のネットワーク暗号化）
どのノードでもSwarmを管理できます

短所：

マネージャーの飢餓を防ぐために、リソースのより厳密な管理が必要です
安全な姿勢を低くし、アプリサーバーに保存されている秘密/鍵
侵害されたノードは、Swarm全体が簡単に侵害される可能性があることを意味します
サーバーの奇数に制限され、通常は3または5

あなたの質問への完全な回答

専用ワーカーノードを使用しない場合のトレードオフは何ですか？はっきりしないかもしれないことを私が知っておくべきことはありますか？

ワーカー専用ノードを使用するための厳しい要件はありません。必要なリソースがわかっていて、サービス/タスクの数が通常同じであるソリューションを展開している場合、これら3つを考慮している限り、3人のマネージャーだけがすべての作業を行うSwarmに問題はありません。影響を受ける領域：

セキュリティ。完璧な世界では、マネージャーはインターネットにアクセスできず、バックエンドサブネット上にのみ存在し、マネージャーの作業のみを行います。管理者は、Swarmのすべての権限を持ち、暗号化されたすべてのシークレットを保持し、暗号化されたRaftログを保存し、（デフォルトで）暗号化キーをディスクに保存します。労働者は必要な秘密のみを（そして記憶にのみ）保存し、リーダーから指示された以外の作業をスウォームで行う権限はありません。労働者が危険にさらされたとしても、必ずしも「群れを失った」わけではありません。この権力分立は難しい要件ではなく、多くの環境はこのリスクを受け入れ、サービスを一般に公開するメインサーバーとしてマネージャーを配置するだけです。これは、セキュリティ/複雑さ対コストの問題です。
ノード数。冗長性のためのマネージャーの最小数は3であり、ほとんどの場合3または5が推奨されます。常に1人のマネージャーだけがリーダーであり、マネージャーの仕事をするのは1人だけなので、マネージャーの数が増えても、キャパシティの数は増えません。リーダーのリソース容量は、リーダーが同時に実行できる作業量を決定するものです。マネージャーもアプリの作業を行っており、3つのノードが処理できるよりも多くのリソース容量が必要な場合は、4番目以降のノードは単なるワーカーであることをお勧めします。
パフォーマンス/スケール。理想的には、マネージャーは、リーダーの選出、タスクスケジューリング、ヘルスチェックの実行と対応など、物事を迅速に行うために必要なすべてのリソースを持っています。リソースの使用率は、ノードの総数、サービスの総数、および新規の割合が大きくなるほど大きくなります。彼らが実行しなければならない作業（サービス/ネットワークの作成、タスクの変更、ノードの変更、ヘルスチェックなど）。サーバーの数とサービス/レプリカの数が少ない場合は、アプリ（特にデータベース）が不足しないように注意している（サービスのリソース制限を使用する）限り、マネージャーもワーカーになる可能性があります。リソースのdockerデーモンが非常に悪いため、Swarmはその仕事を行うことができません。リーダーのランダムな変更またはエラー/失敗が発生し始めたら、トラブルシューティング手順の短いリストで「利用可能なリソースについてマネージャーを確認する」必要があります。

その他の質問：

実際には、どの機能が遅くなりますか？そして、「コンセンサスに達するまでに時間がかかる」ことは実際に何に影響しますか？

より多くのマネージャー=マネージャーがダウンしたときに新しいリーダーを選出するのに時間がかかります。リーダーがいない間、Swarmは読み取り専用状態にあり、新しいレプリカタスクを起動できず、サービスの更新は行われません。 Swarmマネージャーは作業を実行できないため、失敗したコンテナーは自動回復されません。アプリ、入力ルーティングメッシュなどを実行していますが、すべて機能します。マネージャーの健全性とリーダー選出のパフォーマンスの大部分は、マネージャーの数と同様に、すべてのマネージャーノード間のネットワーク遅延に関係しています。これが、Dockerが一般に、単一のSwarmsマネージャーがすべて同じリージョンにいることを推奨しているため、相互に低遅延のラウンドトリップを取得します。ここにはハードセットルールはありません。マネージャー間の200ミリ秒の遅延とテストの失敗をテストし、リーダー選出の結果と速度に問題がない場合は、かっこいいです。

背景情報：

Ben Schmeltzer · Answer

それはすべて、クラスターを構築する目的に依存します。開発目的では、ワーカーノードをマネージャーとして使用できます。本当の懸念はスケールアウトです。マイクロサービスインフラストラクチャが成長し続けると思われる場合は、簡単にスケールアウトできるようにワーカーノードとマネージャーノードを分離することを検討してください。

あなたのセットアップの長所は次のとおりです。

管理のしやすさ
セットアップは高可用性です-3ノードは1のフォールトトレランスを意味します

短所は次のとおりです。

スケールアウトには適していません。コンテナの計算要求は、ワーカーノードを追加することを意味します。
より多くのノードがスウォーム状態を更新するための提案を確認する必要があるため、追加のマネージャーノードは書き込みパフォーマンスを低下させます。これは、ネットワークのラウンドトリップトラフィックが増えることを意味し、サービスのパフォーマンスの問題を引き起こします。ドッキングされたアプリケーションがホストシステムを混乱させると、マネージャーサービスに影響します。スウォームタスクは引き続き実行されますが、スウォームノードを追加、更新、または削除することはできません。また、新規または既存のタスクを開始、停止、移動、または更新することはできません。管理者と労働者のサービスの分離はより安全です。