5ノード展開のシステム要件

5ノードクラスターにおけるセルフホスト型 Standard Edition のシステム要件を確認する。

以下の仕様は、機能的なデプロイメントの最小要件を表しています。 バックエンドの負荷が増加した場合、最適なパフォーマンスとシステムの安定性を確保するために、リソースを追加する必要が生じる可能性があります。

各セルフホスト環境には、処理可能な負荷の上限があります。 実際のリソース要件は、以下のような要因によって異なる場合があります:
  • 監視対象のサーバー数。
  • 監視対象サーバー上で稼働する技術のうち、一部の技術はより多くのメトリクスを必要とする。
  • リクエストの観点から見た監視対象環境への負荷は、トレース負荷によって決定される。このトレース負荷は、監視対象システムへの着信トラフィックとその内部トラフィックの両方に直接比例する。
  • アプリケーションアーキテクチャとトラフィックパターンにより、高トラフィックのマイクロサービスはモノリシックアプリケーションよりもはるかに多くのスパンを生成する。
  • インフラストラクチャの複雑さにより、数百のポッドを持つ Kubernetes ノードは、単一の VM よりもはるかに多くのメトリクスを生成する可能性があります。
  • 有効化された機能(エンドユーザー監視(EUM)、ロギング、サーバーレス監視など)は、データの取り込みと保存量を増やす可能性があります。
  • トラフィックの急増や季節イベント、ブラックフライデーやプロモーションキャンペーンなどのピーク時期を考慮に入れる。
注: お客様の環境が選択した導入アプローチに適合するか否かを確認するには、 IBM 担当者にお問い合わせください。 より大規模なワークロードでは、最適なパフォーマンスを確保するため、最小要件を超えるリソースの増強が可能です。

ホスト

5ノード環境では、同じオペレーティングシステムを搭載した3台のホストが必要です。

5ノードクラスタ内の5つのノードには、それぞれ特定の用途があります:

  • 最初のノード( instana-0 )は、インストール時に node-role.instana.io: "backend" としてラベル付けされ、永続ボリュームを必要とするバックエンドワークロードの実行に使用されます。 このノードはゲートウェイ、アクセプター、およびUIバックエンドも実行します。

  • インストール時に node-role.instana.io: "datastore" としてラベル付けされる2番目のノード( instana-1 )は、データストアの実行に使用されます。

  • インストール時に node-role.instana.io: "other" ラベル付けされる3番目のノード( instana-2 )は、残りの Instana ワークロードの実行に使用されます。

  • 4番目のノード( instana-3 )は、インストール時に node-role.instana.io: "clickhouse"としてラベル付けされ、 ClickHouse データストアの実行に使用されます。
  • インストール時に node-role.instana.io: "agent-other" ラベル付けされる5番目のノード( instana-4 )は、バックエンドワークロードおよび Instana の残りのワークロードの実行に使用されます。

対応プラットフォームおよびオペレーティングシステム

セルフホスト型 Standard Edition インストーラーを実行できるホスト環境を確保してください。

重要: ホストは仮想マシンまたは専用物理マシンである可能性があります。 ホストは新しく、オペレーティングシステムが新しくインストールされた状態でなければなりません。 以前に別の用途で使用されていたホストを使用したい場合は、オペレーティングシステムを再インストールする必要があります。 セルフホスト型 Standard Edition は、 セルフホスト型Classic Edition( Docker ) と共存させてはなりません。

Instana ホスト向けに以下のプラットフォームおよびオペレーティングシステムをサポートします:

表 1.サポートされているオペレーティング・システム
プラットフォーム オペレーティング・システム
Linux® x86_64 Red Hat® Enterprise Linux® ( RHEL ) 10、9、8
Ubuntu 24.04 および 22.04
Debian 13と12
CentOS Stream 9
Amazon Linux 2023年
Oracle Linux 9
SUSE Linux Enterprise Server (SLES) 15 SP6 SP7
Linux® arm64

AWS Graviton でサポートされています

arm64 における他のオペレーティングシステムへのデプロイメントはテストされていません。

ハードウェア要件

5ノードクラスタでは、インストール production タイプのみがサポートされます。

CPU、メモリ、およびストレージ

各ノードには、以下の表に指定されているCPUとメモリが必要です。

ノードは、すべてのVMにわたって、指定された上限値までのCPU、メモリ、およびストレージを必要とします。

表 2. 生産環境 - 小規模VM(全VMの合計)
CPU コアの数 メモリー (GB) ストレージ
44  176 5050

各ノードには、以下の表に示す範囲内で、指定されたCPU、メモリ、およびストレージが必要となる場合があります。

表 3. 本番環境 - ノードあたりの最小システム要件:
ノード名 CPU (コア) メモリー (GB) ディスク(GB) 1秒あたりのディスク速度(IOPS)の下限値 1秒あたりの最小ディスクスループット( MiB ) 目的
instana-0 8 32 1270 3000 250 バックエンド
instana-1 12 48 2470 3000 250 データストア
instana-2 8 32 270 3000 250 その他
instana-3 8 32 770 3000 250 clickhouse
instana-4 8 32 270 3000 250 エージェント(その他)

ノードは、すべてのVMにわたって、指定された上限値までのCPU、メモリ、およびストレージを必要とします。

表 4. 生産環境 - 大規模VM(全VMの合計)
CPU コアの数 メモリー (GB) ストレージ
  132   528 10100

各ノードには、以下の表に示す範囲内で、指定されたCPU、メモリ、およびストレージが必要となる場合があります。

表 5. 生産環境 - ノードあたりのシステム要件(大規模環境):
ノード名 CPU (コア) メモリー (GB) ディスク(GB) 1秒あたりのディスク速度(IOPS)の下限値 1秒あたりの最小ディスクスループット( MiB ) 目的
instana-0 24  96 1270 3000 250 バックエンド
instana-1 36 144 2470 3000 250 データストア
instana-2 24  96 270 3000 250 その他
instana-3 24  96 770 3000 250 clickhouse
instana-4 24  96 270 3000 250 エージェント(その他)

使用する各オプション機能ごとに、追加のリソースが必要です。

node0 (instana-0)、 node2 (instana-2)、および node4 (instana-4) 上で、CPU やメモリ容量などの追加リソースをプロビジョニングしてください。 node1 および node3 は主にデータストアとして使用されるため、 node1 (instana-1) および node3 (instana-3) 上ではリソースをプロビジョニングしないでください。 さらに、ログ機能を有効にした場合、 node3 (instana-3) にログデータを保存するための追加のディスク容量が必要になります。

CPUアーキテクチャの要件 ( x86‑64 )

Instana x86‑64‑v2 のCPUをサポートする x86‑64 システムへのインストールをサポートしています。 x86‑64‑v2 命令セットは、 Instana いくつかのコンポーネント( Cassandra や Kafka など)およびインストール時に使用されるGNU C ライブラリ(glibc)で必要とされます。 2008年頃以降に発売されたほとんどの現代のCPUは、 x86‑64‑v2 に対応しています。 しかし、仮想化環境では、基盤となるハードウェアが対応していても、仮想マシンの設定によってCPUの機能が隠されたり、制限されたりすることがあります。

必要なCPU命令フラグ

オペレーティングシステムでは、以下のCPUフラグが利用可能である必要があります:

  • sse3
  • ssse3
  • sse4_1
  • sse4_2
  • popcnt
  • cx16
  • lahf_lm
注:Instana では、顧客環境向けのCPUフラグが必要です。 オペレーティングシステムやglibcのバージョンによっては、さらにフラグが必要になる場合があります。

ストレージ要件

以下のノードには、4つのデータ保存ディレクトリが必要です。 これらのノードに追加のディスクを追加する必要があります。

  • node0 上のオブジェクトディレクトリ (instana-0)。
  • node1 (instana-1)上のデータ、メトリクス、および分析ディレクトリ。

node2 (instana-2) では追加ディスクは不要です。

以下の表は、各ノードのストレージ容量要件を示しています:

表 6. node0 のクラスター ストレージ ボリューム要件 instana-0
説明 デフォルト・ディレクトリー 最小サイズ (GB) コメント
オブジェクトディレクトリ /mnt/instana/stanctl/objects 1000 パスを上書きするには--volume-objects
ルート・ディレクトリー / 100
$HOMEディレクトリ(エアギャップ環境) /root またはユーザーのホームディレクトリ 60 $HOME環境変数で上書きします。 $HOMEディレクトリ(エアギャップ環境)に40GB、別途ディスク領域に20GB。
$HOMEディレクトリ(エアギャップなし) /root またはユーザーのホームディレクトリ 10 $HOME環境変数で上書きする
クラスタデータディレクトリ /var/lib 100 以下で上書きする--cluster-data-dir
表 7. node1 のクラスター ストレージ ボリューム要件 instana-1
説明 デフォルト・ディレクトリー 最小サイズ (GB) コメント
データ・ディレクトリー /mnt/instana/stanctl/data 500 パスを上書きするには--volume-data
メトリクスディレクトリ /mnt/instana/stanctl/metrics 1000
アナリティクスディレクトリ /mnt/instana/stanctl/analytics 1200
ルート・ディレクトリー / 100
$HOMEディレクトリ(エアギャップ環境) /root またはユーザーのホームディレクトリ 60 $HOME環境変数で上書きします。 $HOMEディレクトリ(エアギャップ環境)に40GB、別途ディスク領域に20GB。
$HOMEディレクトリ(エアギャップなし) /root またはユーザーのホームディレクトリ 10 $HOME環境変数で上書きする
クラスタデータディレクトリ /var/lib 100 以下で上書きする--cluster-data-dir
表 8. node2 のクラスター ストレージ ボリューム要件 instana-2
説明 デフォルト・ディレクトリー 最小サイズ (GB) コメント
ルート・ディレクトリー / 100
$HOMEディレクトリ(エアギャップ環境) /root またはユーザーのホームディレクトリ 60 $HOME環境変数で上書きします。 $HOMEディレクトリ(エアギャップ環境)に40GB、別途ディスク領域に20GB。
$HOMEディレクトリ(エアギャップなし) /root またはユーザーのホームディレクトリ 10 $HOME環境変数で上書きする
クラスタデータディレクトリ /var/lib 100 以下で上書きする-—cluster-data-dir
表 9. node3 のクラスタ・ストレージ・ボリュームの要件 instana-3
説明 デフォルト・ディレクトリー 最小サイズ (GB) コメント
アナリティクスディレクトリ /mnt/instana/stanctl/analytics 1200 --volume-data を使用してパスを上書きする
ルート・ディレクトリー / 100
$HOMEディレクトリ(エアギャップ環境) /root またはユーザーのホームディレクトリ 60 $HOME環境変数で上書きします。 $HOMEディレクトリ(エアギャップ環境)に40GB、別途ディスク領域に20GB。
$HOMEディレクトリ(エアギャップなし) /root またはユーザーのホームディレクトリ 10 $HOME環境変数で上書きする
クラスタデータディレクトリ /var/lib 100 以下で上書きする-—cluster-data-dir
表 10。 node4 のクラスタ・ストレージ・ボリュームの要件 instana-4
説明 デフォルト・ディレクトリー 最小サイズ (GB) コメント
ルート・ディレクトリー / 100
$HOMEディレクトリ(エアギャップ環境) /root またはユーザーのホームディレクトリ 60 $HOME環境変数で上書きします。 $HOMEディレクトリ(エアギャップ環境)に40GB、別途ディスク領域に20GB。
$HOMEディレクトリ(エアギャップなし) /root またはユーザーのホームディレクトリ 10 $HOME環境変数で上書きする
クラスタデータディレクトリ /var/lib 100 以下で上書きする-—cluster-data-dir
注記: エアギャップ環境では、エアギャップパッケージを作成するディレクトリにおいて、バスティオンホストと Instana ホストの両方で、20 GBの追加ディスク容量が必要です。 パッケージの詳細については、 「エアギャップ環境用インストールパッケージの作成」 を参照してください。
重要: 約1か月間、最初に割り当てたストレージ容量を監視する必要があります。 必要に応じて容量を増やすことができます。 また、より多くのエージェントを使用する場合や、より多くのオプション機能を有効にする場合は、メモリ使用量を監視する必要があります。

ディレクトリごとに1台の専用デバイス

Instana の4つのデータディレクトリ(`data`、`metrics`、`analytics`、および`objects`)は、それぞれ専用のストレージ上に配置する必要があります。

専用のストレージデバイスごとにディレクトリを設定する必要があります。

分離は、物理層に至るまでエンドツーエンドで維持されなければならない。

ディレクトリは、以下のリソースを一切共有してはなりません:

  • ディスク
  • ボリューム・グループ
  • SANプール
  • RAIDセット
  • 同じスピンドル、フラッシュ、キャッシュ、またはコントローラーにマッピングされるその他のレイヤー

ホストレベルの分離(マウントポイント、論理ボリューム(LV)、またはLUNの分離など)は必要ですが、それだけでは不十分です。 下位層のリソースが最終的に同じ物理ハードウェアにマッピングされる場合でも、各ディレクトリは依然としてI/O容量を奪い合うことになる。

分離は、ホスト層だけでなく、ストレージスタック全体にわたって確保されなければならない。 この規則の唯一の例外はNVMeであり、これについては別途説明します。

パフォーマンスの分離

Instana データディレクトリは、大容量かつ突発的で、同時アクセスによるI/Oを発生させます。 各ストレージデバイスには、以下の要素を含む有限のI/O容量があります:

  • IOPS
  • スループット(帯域幅)
  • キャッシュ

複数のディレクトリが 1 つのデバイスを共有している場合:

あるディレクトリでの処理負荷が急増すると、他のディレクトリで利用可能な容量が減少する可能性があります。 その結果、予測不可能な遅延が発生し、次のような症状が現れることがあります:

  • クエリのタイムアウト
  • 切断されたトレース
  • 動作の遅いダッシュボード
  • ヘルスチェックに失敗しました

専用のデバイスを使用することで、一貫性があり予測可能なパフォーマンスを確保します。

故障の封じ込め

専用ストレージでは、各ディレクトリが独自のフェイルドメインに割り当てられます。 デバイスが容量いっぱいになったり、性能が低下したり、利用できなくなったりした場合、影響を受けるのは関連するディレクトリのみです。

共有ストレージの場合、そのデバイスを共有しているすべてのディレクトリで同じ問題が発生します。

Instana のデータストアは相互に依存しているため、障害発生時にはサービスの完全な可用性を保証することはできませんが、ストレージを分離することで影響範囲を限定し、復旧作業を簡素化することができます。

ストレージの分離の確認

各ディレクトリが独立した物理リソースによって構成されていること、およびどのレイヤーにおいてもリソースの共有が存在しないことを確認する必要があります。

ホストは、複数のデバイスが共有ストレージに接続されている場合でも、それらを提示することができます。 ホストレベルでの検証だけでは不十分です。

ホストレベルで検証するには、以下のコマンドを実行してデバイスマッピングを確認してください。

ブロックデバイスとマウントポイントを一覧表示するには:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

LVM構成(LV、VG、PVのトレース)については:

sudo pvssudo vgssudo lvdisplay -m

設定は、以下の条件を満たす必要があります:

  • 各マウントポイントは、それぞれ固有のブロックデバイスを使用します
  • 1つのディレクトリに対して、複数のブロックデバイスが使用されることはありません
  • LVM構成では、各ボリュームグループは独自の物理ボリュームのみを使用し、ボリュームグループ間で物理ボリュームが共有されることはありません。

ストレージバックエンドで検証する:

SAN、NAS、または仮想化ストレージの場合、ホストはバックエンドのリソース共有状況を把握できないため、追加の検証が必要となります。

ストレージプロバイダーまたは管理者に、以下の条件を確認してください:

  • これらのボリュームは、同じストレージプール、RAIDセット、またはデータストアに由来するものではありません。
  • キャッシュなどのストレージコントローラのリソースは共有されません。
  • ファブリックまたは接続パスは独立している
  • あるボリュームでのI/O操作は、別のボリュームには影響しません。
例外:NVMeストレージ

この分離要件は、シーク遅延やシリアル化されたI/Oキューなど、従来のディスクの特性に基づいています。 NVMeストレージは、こうした制約を大幅に軽減します。 NVMe環境では、この要件を容量ベースのモデルへと緩和することができます。

容量ベースの配置:以下の条件が満たされる場合、複数のディレクトリが単一のNVMeデバイスを共有できます:

  • このデバイスは、十分な持続的なIOPSとスループットを提供します。
  • 容量は、すべてのディレクトリのピーク需要の合計を上回っています。

平均的な使用量ではなく、ピーク時の使用量を想定してください。ワークロードは突発的に増加し、同時アクセスが集中すると、通常時は十分な性能を持つように見えるデバイスでも処理能力が限界に達してしまうことがあります。

障害の特定範囲の縮小:同一デバイス上のすべてのディレクトリは、単一の障害ドメインを共有します。 デバイスが障害を起こした場合、同じ場所に配置されているすべてのディレクトリが影響を受けます。 その分離性が失われても問題がない場合にのみ、共有NVMe構成を使用してください。

デフォルト・ディレクトリー

Instana データ保存には以下のディレクトリを使用します。

  • データディレクトリ: Elasticsearch、 PostgreSQL,、および Kafka のデータストアに使用されます。 デフォルトのロケーションは /mnt/instana/stanctl/dataです。
  • メトリクスディレクトリ: Cassandra および BeeInstana のデータストアで使用されます。 デフォルトのロケーションは /mnt/instana/stanctl/metricsです。
  • アナリティクスディレクトリ:ClickHouse データストアに使用されます。 デフォルトのロケーションは /mnt/instana/stanctl/analyticsです。
  • オブジェクトディレクトリ: 生スパン、合成監視、およびエンドユーザー監視(EUM)に使用されます。 デフォルトのロケーションは /mnt/instana/stanctl/objectsです。
  • クラスタデータディレクトリ: クラスタデータに使用されます。
  • $HOME ディレクトリ: 現在のルートユーザーまたは非ルートユーザーのホームディレクトリ。

Instana の各種機能はデータ処理量が多いため、パフォーマンスの問題を回避するには、ソリッドステートドライブ(SSD)などの高速専用ストレージを使用してください。 データ、メトリクス、アナリティクス、オブジェクトの各ディレクトリには、それぞれ別のディスクを使用してください。

以下のディレクトリを別々のディスクにマウントする必要があります:

  • クラスタデータディレクトリ: ディスク容量が不足している場合、カスタム /varディレクトリを指定できます。 例えば、/xyz/data などです。 インストール時にこの --cluster-data-dir ディレクトリを指定することを忘れないでください。 フラグ --cluster-data-dir はディレクトリ /var/lib/rancher/k3s のみをカスタムパスにリダイレクトします。 K3s また、kubelet はコンテナランタイムの一時データやコンポーネントログ /var/lib/kubelet/podsなど、他の /var 場所へのデータ書き込みを継続します。 ディスク /var にこれらのディレクトリをサポートするのに十分な空き容量があることを確認する必要があります。 ディスク容量不足は、ポッドスケジューリングの失敗や /var kubeletディスク圧迫警告を引き起こす可能性があります。 このような問題が発生した場合は、および /var/var/lib/kubelet その他のサブディレクトリ内の空き容量を確認する必要があります。
  • $HOME ディレクトリ: 現在のユーザーの $HOME ホームディレクトリを指します。 たとえば、ユーザーが root ユーザーの場合、 $HOME は となります /root。非 root ユーザーの場合、 $HOME は となります /home/<username>

ネットワーキングの要件

以下のポートおよびIPアドレスの要件を満たしていることを確認してください。 これらのポートを開く方法の詳細については、 ファイアウォール規則を参照してください。

注: 必要なパッケージを取得するために、バックエンドサーバーで高速、低遅延、かつ安定した接続を確保してください。

必要なポート

すべてのノードにおいて、以下のポートが開いておりアクセス可能である必要があります。

表11. 5ノードポート
ポート番号 方向 プロトコル ソース 説明
22 インバウンド TCP 外部 Secure Shell (SSH) 接続に必要なポート(SSH でログインする場合のみ必要)
22 インバウンド TCP 内部 バックエンドノード間のアクセスに必要なSSHポート
80 インバウンド TCP 外部 HTTP Instana コンソールUIのプロトコル
443 インバウンド TCP 外部 HTTPS Instana コンソール UI のプロトコル、 Instana コンソール API、 Instana EUM、 OpenTelemetry, および Instana エージェントアクセプタポート
443 アウトバウンド TCP 外部 オンライン環境でのみ必要です。 詳細については、「 Instana のセルフホスト型展開におけるアウトバウンドネットワークアクセスの要件」 を参照してください。
53 インバウンド TCP/UDP 内部(全ノード) DNS ドメイン名解決に必要なポート
6443 インバウンド TCP 内部(全ノード) 内部サービスポート
8443 インバウンド TCP 外部 Instana エージェントアクセプタポート このポートはオプションです。
10250 インバウンド TCP 内部(全ノード) 内部サービスポート
2379 インバウンド TCP 内部(全ノード) 内部サービスポート
2380 インバウンド TCP 内部(全ノード) 内部サービスポート
5001 インバウンド TCP 内部(全ノード) 内部サービスポート
8472 インバウンド UDP 内部(全ノード) 内部サービスポート
9443 インバウンド TCP 内部(全ノード) 内部サービスポート
すべて インバウンド TCP/UDP 10.42.0.0/16 および10.43.0.0/16 自己ホスト型 Instana コンポーネントのサブネット
すべて インバウンド TCP/UDP ループバック VM が自身のデータパケットを送受信できるように、ポートを開く。

以下の注を参照してください。

  • 外部ソースとは、ポートが Instana のセルフホスト型エンタープライズ(プライベート)ネットワークの外部からアクセス可能でなければならないことを意味します。
  • 内部ソースとは、5ノードクラスタにおいて、あるノードのポートが他の2つのノードからアクセス可能でなければならないことを意味する。
  • IPアドレス 10.42.0.0/16 は内部で全てのポート(1~65535)にアクセス可能でなければなりません 10.43.0.0/16
  • ファイアウォールはループバックアドレスからのすべてのトラフィックを許可する必要があります。
  • 特定のリポジトリにアクセスするには、ポート443のアウトバウンド通信が必要です。 詳細については、 「アウトバウンドネットワークアクセスの要件」 を参照してください。

IP アドレス

5ノードクラスタの5つのノードは、以下のIPアドレス要件を満たす必要があります:

  • すべての5つのノードが相互に通信できるようにするには、同じプライベートVLAN上のプライベートIPアドレスが必要です。
  • node0 (instana-0)は外部通信のためにもIPアドレスを持つ必要がある。 IPアドレスは、クラスタ外からホストに到達するためにも使用されます。