検索

5.7. リソース管理およびパフォーマンスに関する考慮事項

download PDF

ネットワーク監視に必要なリソースの量は、クラスターのサイズと、クラスターが可観測データを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を設定すると、最適なセットアップと可観測性のニーズを満たす可能性があります。

次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。

eBPF サンプリング
サンプリング仕様 spec.agent.ebpf.sampling を設定して、リソースを管理できます。サンプリング値が低いと、大量の計算、メモリー、およびストレージリソースが消費される可能性があります。これは、サンプリング比の値を指定することで軽減できます。値 100 は、100 ごとに 1 つのフローがサンプリングされることを意味します。0 または 1 の値は、すべてのフローがキャプチャーされることを意味します。値が小さいほど、返されるフローが増加し、派生メトリクスの精度が向上します。デフォルトでは、eBPF サンプリングは値 50 に設定されているため、50 ごとに 1 つのフローがサンプリングされます。より多くのサンプルフローは、より多くのストレージが必要になることにも注意してください。クラスターがどの設定を管理できるかを判断するには、デフォルト値から始めて実験的に調整することを検討してください。
インターフェイスの制限または除外
spec.agent.ebpf.interfaces および spec.agent.ebpf.excludeInterfaces の値を設定して、観測されるトラフィック全体を削減します。デフォルトでは、エージェントは、excludeInterfaces および lo (ローカルインターフェイス) にリストされているインターフェイスを除く、システム内のすべてのインターフェイスを取得します。インターフェイス名は、使用される Container Network Interface (CNI) によって異なる場合があることに注意してください。

Network Observability をしばらく実行した後、次の設定を使用してパフォーマンスを微調整できます。

リソース要件および制限
spec.agent.ebpf.resources および spec.processor.resources 仕様を使用して、リソース要件と制限をクラスターで予想される負荷とメモリー使用量に適応させます。多くの中規模のクラスターには、デフォルトの制限の 800MB で十分な場合があります。
キャッシュの最大フロータイムアウト
eBPF エージェントの spec.agent.ebpf.cacheMaxFlows および spec.agent.ebpf.cacheActiveTimeout 仕様を使用して、エージェントによってフローが報告される頻度を制御します。値が大きいほど、エージェントで生成されるトラフィックが少なくなり、これは CPU 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。

5.7.1. リソースの留意事項

次の表は、特定のワークロードサイズのクラスターのリソースに関する考慮事項の例を示しています。

重要

表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。

表5.2 リソースの推奨事項
 極小規模 (10 ノード)小規模 (25 ノード)中規模 (65 ノード) [2]大規模 (120 ノード) [2]

ワーカーノードの vCPU とメモリー

4 仮想 CPU| 16 GiB メモリー [1]

16 仮想 CPU| 64 GiB メモリー [1]

16 仮想 CPU| 64 GiB メモリー [1]

16 仮想 CPU| 64 GiB メモリー [1]

LokiStack サイズ

1x.extra-small

1x.small

1x.small

1x.medium

Network Observability コントローラーのメモリー制限

400 Mi (デフォルト)

400 Mi (デフォルト)

400 Mi (デフォルト)

400 Mi (デフォルト)

eBPF サンプリングレート

50 (デフォルト)

50 (デフォルト)

50 (デフォルト)

50 (デフォルト)

eBPF メモリー制限

800 Mi (デフォルト)

800 Mi (デフォルト)

800 Mi (デフォルト)

1600 Mi

FLP メモリー制限

800 Mi (デフォルト)

800 Mi (デフォルト)

800 Mi (デフォルト)

800 Mi (デフォルト)

FLP Kafka パーティション

該当なし

48

48

48

Kafka コンシューマーレプリカ

該当なし

24

24

24

Kafka ブローカー

該当なし

3 (デフォルト)

3 (デフォルト)

3 (デフォルト)

  1. AWS M6i インスタンスでテスト済み。
  2. このワーカーとそのコントローラーに加えて、3 つのインフラノード (サイズ M6i.12xlarge) と 1 つのワークロードノード (サイズ M6i.8xlarge) がテストされました。

5.7.2. メモリーと CPU の合計平均使用量

次の表は、3 つの異なるテスト (Test 1Test 2、および Test 3) について、サンプリング値が 1、50、400 であるクラスターの合計リソース使用量の平均を示しています。テストは次の点で異なります。

  • Test 1 では、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数を考慮し、eBPF エージェントに負荷をかけ、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表します。たとえば、Test 1 は、76 個の namespace、5153 個の Pod、および 2305 個の Service で構成されています。
  • Test 2 では、大量の Ingress トラフィックを考慮に入れます。
  • Test 3 では、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数を考慮し、Test 1 よりも大規模な規模で eBPF エージェントに負荷をかけ、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表します。たとえば、Test 3 は、553 個の namespace、6998 個の Pod、および 2508 個の Service で構成されています。

さまざまなテストでさまざまなタイプのクラスター使用例が例示されているため、この表の数値を並べて直線的に比較することはできませんが、個人のクラスター使用状況を評価するベンチマークとして使用することを目的としています。表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。

注記

Prometheus にエクスポートされたメトリクスは、リソースの使用状況に影響を与える可能性があります。メトリクスのカーディナリティー値は、リソースがどの程度影響を受けるかを判断するのに役立ちます。詳細は、関連情報セクションの「ネットワークフローの形式」を参照してください。

表5.3 リソース合計平均使用量
サンプリング値パラメーターテスト 1 (25 ノード)テスト 2 (65 ノード)テスト 3 (120 ノード)

Sampling = 1

Loki を使用する場合

 

NetObserv の CPU 合計使用量

3.24

3.42

7.30

NetObserv RSS (メモリー) の合計使用量

14.09 GB

22.56 GB

36.46 GB

Loki を使用しない場合

 

NetObserv の CPU 合計使用量

2.40

2.43

5.59

NetObserv RSS (メモリー) の合計使用量

6.85 GB

10.39 GB

13.92 GB

Sampling = 50

Loki を使用する場合

 

NetObserv の CPU 合計使用量

2.04

2.36

3.31

NetObserv RSS (メモリー) の合計使用量

8.79 GB

19.14 GB

21.07 GB

Loki を使用しない場合

 

NetObserv の CPU 合計使用量

1.55

1.64

2.70

NetObserv RSS (メモリー) の合計使用量

6.71 GB

10.15 GB

14.82 GB

Sampling = 400

Loki を使用する場合

 

NetObserv の CPU 合計使用量

1.71

1.44

2.36

NetObserv RSS (メモリー) の合計使用量

8.21 GB

16.02 GB

17.44 GB

Loki を使用しない場合

 

NetObserv の CPU 合計使用量

1.31

1.06

1.83

NetObserv RSS (メモリー) の合計使用量

7.01 GB

10.70 GB

13.26 GB

概要: この表は、ネットワーク可観測性 (エージェント + FLP + Kafka + Loki) のリソースの平均合計使用量を示しています。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.