シングルノード展開のシステム要件
シングルノードクラスタでのセルフホスト型 Standard Edition のシステム要件を確認してください。
以下の仕様は、システムを正常に稼働させるための最低限の要件です。 バックエンドの負荷が増加した場合、最適なパフォーマンスとシステムの安定性を確保するために、リソースを追加する必要があるかもしれません。
- 監視対象のサーバー数。
- 監視対象のサーバー上で稼働している技術。一部の技術はメトリクスの使用量が多いため。
- リクエストの観点から見た観測対象環境への負荷は、トレース負荷によって決定されます。このトレース負荷は、観測対象システムへの着信トラフィックとシステム内部のトラフィックの両方に正比例します。
- アプリケーションのアーキテクチャやトラフィックの傾向により、トラフィックの多いマイクロサービスは、モノリシックなアプリケーションよりもはるかに多くのスパンを生成します。
- インフラストラクチャの複雑さにより、数百のポッドを抱える Kubernetes ノードは、単一の VM よりもはるかに多くのメトリクスを生成する可能性があります。
- エンドユーザー監視(EUM)、ロギング、サーバーレス監視などの有効化された機能は、データの取り込み量や保存容量を増やす可能性があります。
- トラフィックの急増や季節的なイベント、ブラックフライデーやプロモーションキャンペーンなどの繁忙期も考慮に入れてください。
対応プラットフォームおよびオペレーティングシステム
「 Standard Edition 」のセルフホスト版インストーラーを実行できるホスト環境が整っていることを確認してください。
Instana ホストとして、以下のプラットフォームおよびオペレーティングシステムに対応しています:
| プラットフォーム | オペレーティング・システム |
|---|---|
| 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、メモリ、およびストレージの要件をまとめたものです。
| インストール・タイプ | 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フラグが利用可能である必要があります:
sse3ssse3sse4_1sse4_2popcntcx16lahf_lm
ストレージ要件
合計ストレージ要件は、監視する予定のインフラストラクチャとワークロードによって大きく異なります。 さらに、ロギングや合成などのオプションで使用される機能は、必要なストレージ容量に影響します。
各インストールタイプについて、以下の表に Instana で使用されるディレクトリのストレージ容量要件を示します。 ディレクトリに関する詳細については、 「デフォルトのディレクトリ」 を参照してください。
| インストール・タイプ | ルートディレクトリ (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 |
約 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ディスクにあることを確認してください。 の空き容量が不足すると、ポッドのスケジューリングに失敗したり、/varkubeletからディスク容量不足の警告が表示されたりする可能性があります。 このような問題が発生した場合は、およびその他の/var/var/lib/kubeletサブディレクトリの空き容量を確認する必要があります。 $HOMEディレクトリ: 現在のユーザーのホーム$HOMEディレクトリを指します。 たとえば、ユーザーがrootユーザーの場合、$HOMEは となります/root。root以外のユーザーの場合、$HOMEは となります/home/<username>。
ネットワーキングの要件
ホスト上の次のポートが開いていてアクセス可能である必要があります。 これらのポートを開く方法の詳細については、ファイアウォールルール。
| ポート番号 | 方向 | プロトコル | ソース | 説明 |
|---|---|---|---|---|
| 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 が必要です。 詳細については、 「アウトバウンドネットワークアクセスの要件」 を参照してください。
次の作業
環境の準備を進めてください。