2

質問の元: https://groups.google.com/forum/#!topic/logstash-users/cYv8ULhHeE0

以下の logstash スケール アウト戦略を比較すると、トラフィックと CPU の負荷が分散されている場合、tcp ロード バランサーは最高のパフォーマンスを発揮します。ただし、logstash-forwarder <-> logstash tcp 接続の性質上、常にトラフィックのバランスをとるのは難しいようです。logstash ノード全体でトラフィック/CPU 負荷のバランスをより良くするためのより良いアイデアを思いついた人はいますか? アドバイスをありがとう:)

<私のシナリオ>

  • ログを中央のlogstashノード（クラスター）に転送するlogstash-forwarderを備えた10以上のサービスノード
  • 各サービスノードのログ平均スループット、スループットの日次分布、ログタイプのフィルターの複雑さは大きく異なります
    • ログの平均スループット: 例 service_1: 0.5k イベント/秒; service_2: 5k イベント/秒
    • スループットの毎日の分布: たとえば、service_1 のピークは朝、service_2 のピークは夜
    • ログ タイプのフィルターの複雑さ: 単一の logstash ノードの CPU を 100% 消費することにより、service_1 のログ タイプは 300 イベント/秒で処理できますが、service_2 のログ タイプは 1500 イベント/秒です。

<TCPロードバランサ>

tcp 接続は logstash-forwarder と logstash の間で永続化されるため、最終的に tcp 接続量がすべての logstash ノード間で最小の接続、最小の負荷によってバランスが取れているか分散されているかどうかを意味します。トラフィック/CPU 負荷がすべての logstash ノード間でバランスが取れていることを保証するものではありません。私のシナリオによると、各 tcp 接続のトラフィックは、時間の経過とともに毎日の平均で変化し、それはイベントの複雑さです。したがって、さらに悪いケースとして、logstash_1 と logstash_2 の両方に 10 の tcp 接続があるとしますが、logstash_1 の接続にはより高いトラフィックと複雑なイベントが含まれているため、logstash_1 の CPU 負荷は logstash_2 の 3 倍になる可能性があります。

< 手動で logstash-forwarders を logstash に割り当てる >

過去の日次平均トラフィックに基づいて負荷分散を計画できるため、TCP ロード バランサと同じ状況に直面する可能性がありますが、時間の経過とともに変化し、もちろん HA はありません。

< メッセージキュー >

アーキテクチャとして: logstash-forwarder を使用したサービス ノード -> キューアー: ウサギのログスタッシュへ -> インデクサー: ウサギのログスタッシュと ElasticSearch へ

  • すべてのノードで、キュー ブローカーとの間でメッセージを送受信する際の CPU オーバーヘッドの約 30%。
4

1 に答える 1

1

ご質問の 1 つの側面に焦点を当てます。これは、RabbitMQ クラスターの負荷分散です。RabbitMQ クラスターは、常に 1 つのマスター ノードと 0…n のスレーブ ノードで構成されます。したがって、ラウンドロビン、leastconn などを実装するよりも、強制的にマスター ノードに接続することをお勧めします。

ロード バランサーが別のノードにルーティングする場合でも、RabbitMQ は自動的にトラフィックをマスター ノードに直接ルーティングします。この投稿では、概念をより詳細に説明しています。

于 2014-11-18T15:26:19.680 に答える