シングルノード展開のシステム要件

シングルノードクラスタでのセルフホスト型 Standard Edition のシステム要件を確認してください。

以下の仕様は、システムを正常に稼働させるための最低限の要件です。 バックエンドの負荷が増加した場合、最適なパフォーマンスとシステムの安定性を確保するために、リソースを追加する必要があるかもしれません。

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

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

「 Standard Edition 」のセルフホスト版インストーラーを実行できるホスト環境が整っていることを確認してください。

注: 重要:ホストは仮想マシンでも、専用の物理マシンでも構いません。 ホストは、OSを新規にインストールしたばかりの新しいものである必要があります。 以前別の用途で使用していたホストを使用する場合は、オペレーティングシステムを再インストールする必要があります。 Standard 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 以外のオペレーティングシステムへの展開については、テストされていません。

ハードウェア要件

ホストは、CPU、メモリ、およびストレージの最小要件を満たしている必要があります。

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

Instana インストール時に設定できる2種類のインストール方法を提供しています。 環境に応じてインストール タイプを選択します。 デフォルトのインストールタイプはdemo

  • 使用demoテストおよびデモ環境のみのインストール タイプ。 実稼働環境では使用しないでください。
  • 使用production実稼働環境向けインストール タイプ。
注: まず インストール demo から開始し、設定や履歴データを失うことなく、それを インストール production に変換することができます。 環境を本番環境に移行するには、本番環境の要件を満たすよう、CPU、メモリ、ストレージなどのインフラストラクチャをスケールアップしてください。

以下の表は、シングルノードクラスタのCPU、メモリ、およびストレージの要件をまとめたものです。

表 2. インストールタイプ別のCPU、メモリ、およびストレージの要件
インストール・タイプ CPU コアの数 メモリー (GB) ストレージ 1秒あたりのディスク処理速度(IOPS)の下限値 1秒あたりの最小ディスクスループット( MiB )
demo 16 64百万 1200 1000 125
生産環境 - 小規模VM(全VMの合計) 28 112 3700 3000 250
生産環境 - 大規模VM(全VMの合計) 56 224 7400 3000 250

一部のオプション機能では、より多くの CPU とメモリが必要になる場合があります。 これらのオプション機能を有効にする予定の場合は、パフォーマンスの問題を回避するために必要な CPU とメモリを用意することが理想的です。

インストール可能なすべてのオプション機能の詳細については、 「オプション機能の有効化」 を参照してください。

Standard Edition ホストのセルフモニタリングを有効にする場合は、次の表に示すように、追加のCPUとメモリが必要になります。

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のバージョンによっては、さらにフラグが必要になる場合があります。

ストレージ要件

合計ストレージ要件は、監視する予定のインフラストラクチャとワークロードによって大きく異なります。 さらに、ロギングや合成などのオプションで使用される機能は、必要なストレージ容量に影響します。

各インストールタイプについて、以下の表に Instana で使用されるディレクトリのストレージ容量要件を示します。 ディレクトリに関する詳細については、 「デフォルトのディレクトリ」 を参照してください。

表 3. ストレージ容量の要件
インストール・タイプ ルートディレクトリ (GB) データディレクトリ (GB) メトリクスディレクトリ (GB) アナリティクス ディレクトリ (GB) オブジェクトディレクトリ (GB) クラスタのデータディレクトリ(GB) $HOME オンライン環境におけるディレクトリ(GB) $HOME エアギャップ環境におけるディレクトリ(GB) オンライン環境における総ストレージ容量(TB) エアギャップ環境における総ストレージ容量(TB)
demo 100 150 300 500 250 100 10 40 1.45 1.48
production 100 500 1000 1200 1000 100 10 40 3.95 3.98
注: エアギャップ環境では、バスティオンホストと 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です。
  • 「Objects」ディレクトリ: 生のスパン、合成監視、およびエンドユーザー監視(EUM)に使用されます。 デフォルトのロケーションは /mnt/instana/stanctl/objectsです。
  • クラスタデータディレクトリ: クラスタデータ用に使用されます。
  • $HOME ディレクトリ: 現在のrootユーザーまたはroot以外のユーザーのホームディレクトリ。

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>

ネットワーキングの要件

ホスト上の次のポートが開いていてアクセス可能である必要があります。 これらのポートを開く方法の詳細については、ファイアウォールルール

注: 必要なパッケージを取得するために、バックエンドサーバーで高速かつ低遅延で安定した接続が確保されていることを確認してください。
表 4. 必要なポート
ポート番号 方向 プロトコル ソース 説明
22 インバウンド TCP 外部 セキュアシェル(SSH)接続に必要なポート(SSHでログインする場合のみ必要)
80 インバウンド TCP 外部 HTTP Instana コンソールUIのプロトコル
443 インバウンド TCP 外部 HTTPS Instana コンソールUIのプロトコル、 Instana コンソール、 API、 Instana EUM、 OpenTelemetry,、および Instana エージェントのアクセプタポート
443 アウトバウンド TCP 外部 オンライン環境でのみ必要。 詳細については、「 Instana のセルフホスト型展開におけるアウトバウンドネットワークアクセスの要件」 を参照してください。
8443 インバウンド TCP 外部 Instana エージェント受信ポート。 このポートは任意です。
すべて インバウンド TCP/UDP 10.42.0.0/16 および10.43.0.0/16 Instana のセルフホスト型コンポーネントのサブネット
すべて インバウンド TCP/UDP ループバック VM が自身のデータパケットを送受信できるように、ポートを開いてください。

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

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