Configuration système requise pour un déploiement à cinq nœuds

Vérifiez la configuration système requise pour l' Standard Edition, hébergée en interne, sur un cluster à cinq nœuds.

Les spécifications suivantes représentent les exigences minimales pour un déploiement fonctionnel. Si la charge de travail du backend augmente, vous devrez peut-être ajouter des ressources supplémentaires afin de garantir des performances optimales et la stabilité du système.

Chaque environnement auto-hébergé a des limites supérieures quant à la charge qu'il peut traiter. Vos besoins réels en ressources peuvent varier en fonction de facteurs tels que :
  • Le nombre de serveurs sous observation.
  • Les technologies qui fonctionnent sur les serveurs observés, car certaines technologies sont plus gourmandes en métriques.
  • La charge sur un environnement observé, du point de vue des requêtes, est déterminée par la charge de trace, qui est directement proportionnelle à la fois au trafic entrant vers le système observé et à son trafic interne.
  • Architecture applicative et modèles de trafic : les microservices à fort trafic génèrent beaucoup plus de segments que les applications monolithiques.
  • En raison de la complexité de l'infrastructure, un nœud d' Kubernetes s comportant des centaines de pods peut générer beaucoup plus de métriques qu'une seule VM.
  • Les fonctionnalités activées, telles que la surveillance des utilisateurs finaux (EUM), la journalisation et la surveillance sans serveur, peuvent augmenter l'ingestion et le stockage des données.
  • Pics de trafic et événements saisonniers : tenez compte des périodes de forte affluence telles que le Black Friday ou les campagnes promotionnelles.
Remarque : contactez vos représentants IBM pour déterminer si votre environnement correspond à l'approche de déploiement sélectionnée. Pour les charges de travail plus importantes, vous pouvez augmenter les ressources au-delà des exigences minimales afin de garantir des performances optimales.

Hôtes

Pour les environnements à cinq nœuds, vous avez besoin de trois hôtes équipés du même système d'exploitation.

Les cinq nœuds d'un cluster à cinq nœuds ont des utilisations spécifiques :

  • Le premier nœud ( instana-0 ), qui est étiqueté comme node-role.instana.io: "backend" pendant l'installation, est utilisé pour exécuter les charges de travail backend qui nécessitent des volumes persistants. Le nœud exécute également la passerelle, les accepteurs et le backend de l'interface utilisateur.

  • Le deuxième nœud ( instana-1 ), qui est étiqueté node-role.instana.io: "datastore" pendant l'installation, est utilisé pour exécuter les magasins de données.

  • Le troisième nœud ( instana-2 ), qui est étiqueté comme node-role.instana.io: "other" pendant l'installation, est utilisé pour exécuter le reste des charges de travail d' Instana.

  • Le quatrième nœud ( instana-3 ), qui est étiqueté node-role.instana.io: "clickhouse" lors de l'installation, est utilisé pour exécuter le magasin de données ClickHouse.
  • Le cinquième nœud ( instana-4 ), qui est étiqueté comme node-role.instana.io: "agent-other" pendant l'installation, est utilisé pour exécuter les charges de travail backend et le reste des charges de travail d' Instana.

Plateformes et systèmes d'exploitation pris en charge

Assurez-vous de disposer d'un hôte sur lequel vous pouvez exécuter le programme d'installation d' Standard Edition.

Important : l'hôte peut être une machine virtuelle ou une machine physique dédiée. L'hôte doit être neuf et disposer d'un système d'exploitation fraîchement installé. Si vous souhaitez utiliser un hôte qui a déjà été utilisé à d'autres fins, vous devez réinstaller le système d'exploitation. Standard Edition auto-hébergé ne doit pas coexister avec une édition Classic auto-hébergée ( Docker ).

Instana prend en charge les plateformes et systèmes d'exploitation suivants pour l'hôte :

Tableau 1. Systèmes d'exploitation pris en charge
Plateforme Système d'exploitation
Linux® x86_64 Red Hat® Enterprise Linux® ( RHEL ) 10, 9 et 8
Ubuntu 24.04 et 22.04
Debian 13 et 12
CentOS Stream 9
Amazon Linux 2023
Oracle Linux 9
SUSE Linux Enterprise Server (SLES) 15 SP6 SP7
Linux® arm64

Prise en charge sur AWS Graviton

Le déploiement sur d'autres systèmes d'exploitation sur arm64 n'a pas été testé.

Configuration matérielle requise

Dans les clusters à cinq nœuds, seul le type production d'installation est pris en charge.

Processeur, mémoire et stockage

Chaque nœud nécessite un processeur et une mémoire tels que spécifiés dans le tableau suivant.

Les nœuds nécessitent, pour l'ensemble des machines virtuelles, une quantité de CPU, de mémoire et de stockage ne dépassant pas les limites spécifiées.

Tableau 2. Production - Petites machines virtuelles (totaux pour l'ensemble des machines virtuelles)
Nombre de coeurs d'UC Mémoire (Go) Stockage
44 176 5050

Chaque nœud peut nécessiter, dans la limite des ressources de processeur, de mémoire et de stockage indiquées dans le tableau ci-dessous.

Tableau 3. Production - Configuration minimale requise par nœud :
Nom de noeud Unité centrale (coeurs) Mémoire (Go) Disque (Go) Vitesse minimale du disque (IOPS) par seconde Débit minimal du disque (en MiB ) par seconde Fonction
instana-0 8 32 1270 3000 250 dorsal
instana-1 12 48 2470 3000 250 magasin de données
instana-2 8 32 270 3000 250 autre
instana-3 8 32 770 3000 250 Clickhouse
instana-4 8 32 270 3000 250 autre agent

Les nœuds nécessitent, pour l'ensemble des machines virtuelles, une quantité de CPU, de mémoire et de stockage ne dépassant pas les limites spécifiées.

Tableau 4. Production - Grandes machines virtuelles (totaux pour l'ensemble des machines virtuelles)
Nombre de coeurs d'UC Mémoire (Go) Stockage
132 528 10100

Chaque nœud peut nécessiter, dans la limite des ressources de processeur, de mémoire et de stockage indiquées dans le tableau ci-dessous.

Tableau 5. Production - Configuration système requise pour les nœuds de grande taille :
Nom de noeud Unité centrale (coeurs) Mémoire (Go) Disque (Go) Vitesse minimale du disque (IOPS) par seconde Débit minimal du disque (en MiB ) par seconde Fonction
instana-0 24 96 1270 3000 250 dorsal
instana-1 36 144 2470 3000 250 magasin de données
instana-2 24 96 270 3000 250 autre
instana-3 24 96 770 3000 250 Clickhouse
instana-4 24 96 270 3000 250 autre agent

Pour chaque fonctionnalité optionnelle que vous souhaitez utiliser, vous avez besoin de ressources supplémentaires.

Provisionnez les ressources supplémentaires, telles que la capacité du processeur et de la mémoire, sur node0 (instana-0), node2 (instana-2) et node4 (instana-4). Ne provisionnez pas les ressources sur node1 (instana-1) et node3 (instana-3) car node1 et node3 sont principalement utilisés pour les magasins de données. De plus, si vous activez la fonctionnalité de journalisation, vous aurez besoin de plus d'espace disque pour stocker les données du journal sur node3 (instana-3).

Configuration requise pour l'architecture du processeur ( x86‑64 )

Instana prend en charge l'installation sur les systèmes x86‑64 qui prennent en charge les processeurs x86‑64‑v2. Le jeu d'instructions « x86‑64‑v2 » est requis par plusieurs composants d' Instana (tels que Cassandra et Kafka ) ainsi que par la bibliothèque GNU C (glibc) utilisée lors de l'installation. La plupart des processeurs modernes (commercialisés vers 2008 ou après) prennent en charge l' x86‑64‑v2 Cependant, dans les environnements virtualisés, la configuration de la machine virtuelle peut masquer ou limiter les capacités du processeur, même lorsque le matériel sous-jacent les prend en charge.

Indicateurs d'instructions CPU requis

Le système d'exploitation doit disposer des indicateurs de processeur suivants :

  • sse3
  • ssse3
  • sse4_1
  • sse4_2
  • popcnt
  • cx16
  • lahf_lm
Remarque : la fonction « Instana » nécessite la configuration des indicateurs du processeur pour les environnements client. Selon le système d'exploitation et la version de glibc, le système peut nécessiter des options supplémentaires.

Espace de stockage requis

Les quatre répertoires de stockage de données sont requis sur les nœuds suivants. Vous devez ajouter des disques supplémentaires sur ces nœuds.

  • Répertoire des objets sur node0 (instana-0).
  • Répertoires de données, de mesures et d'analyses sur node1 (instana-1).

Aucun disque supplémentaire n'est nécessaire sur node2 (instana-2).

Le tableau suivant indique les besoins en volume de stockage de chaque nœud :

Tableau 6. Exigences en matière de volume de stockage en cluster pour l' node0 instana-0
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire d'objets /mnt/instana/stanctl/objects 1 000 Remplacer le chemin d'accès par--volume-objects
Répertoire racine / 100
Répertoire $HOME (isolé physiquement) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 pour le répertoire $HOME (air-gapped) et 20 Go pour l'espace disque séparé.
Répertoire $HOME (non isolé) /root ou le répertoire personnel des utilisateurs 10 Remplacer avec la variable d'environnement $HOME
Répertoire des données du cluster /var/lib 100 Remplacer par--cluster-data-dir
Tableau 7. Exigences en matière de volume de stockage en cluster pour l' node1 instana-1
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire de données /mnt/instana/stanctl/data 500 Remplacer le chemin d'accès par--volume-data
Répertoire des indicateurs /mnt/instana/stanctl/metrics 1 000
Répertoire analytique /mnt/instana/stanctl/analytics 1 200
Répertoire racine / 100
Répertoire $HOME (isolé physiquement) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 pour le répertoire $HOME (air-gapped) et 20 Go pour l'espace disque séparé.
Répertoire $HOME (non isolé) /root ou le répertoire personnel des utilisateurs 10 Remplacer avec l'environnement $HOME
Répertoire des données du cluster /var/lib 100 Remplacer par--cluster-data-dir
Tableau 8. Exigences en matière de volume de stockage en cluster pour l' node2 instana-2
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire racine / 100
Répertoire $HOME (isolé physiquement) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 pour le répertoire $HOME (air-gapped) et 20 Go pour l'espace disque séparé.
Répertoire $HOME (non isolé) /root ou le répertoire personnel des utilisateurs 10 Remplacer avec l'environnement $HOME
Répertoire des données du cluster /var/lib 100 Remplacer par-—cluster-data-dir
Tableau 9. Exigences en matière de volume de stockage en cluster pour node3 instana-3
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire analytique /mnt/instana/stanctl/analytics 1 200 Remplacer le chemin d'accès avec « --volume-data »
Répertoire racine / 100
Répertoire $HOME (isolé physiquement) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 pour le répertoire $HOME (air-gapped) et 20 Go pour l'espace disque séparé.
Répertoire $HOME (non isolé) /root ou le répertoire personnel des utilisateurs 10 Remplacer avec l'environnement $HOME
Répertoire des données du cluster /var/lib 100 Remplacer par-—cluster-data-dir
Tableau 10. Exigences en matière de volume de stockage en cluster pour node4 instana-4
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire racine / 100
Répertoire $HOME (isolé physiquement) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 pour le répertoire $HOME (air-gapped) et 20 Go pour l'espace disque séparé.
Répertoire $HOME (non isolé) /root ou le répertoire personnel des utilisateurs 10 Remplacer avec l'environnement $HOME
Répertoire des données du cluster /var/lib 100 Remplacer par-—cluster-data-dir
Remarque : dans un environnement isolé, vous avez besoin de 20 Go d'espace disque supplémentaire dans le répertoire où vous créez le package isolé, à la fois sur l'hôte bastion et sur l'hôte d' Instana. Pour plus d'informations sur le package, consultez Création du package d'installation air-gapped.
Important : pendant environ un mois, vous devez surveiller le volume de stockage que vous avez initialement attribué. Vous pouvez ensuite augmenter la capacité si nécessaire. De plus, si vous utilisez davantage d'agents ou activez davantage de fonctionnalités optionnelles, vous devez surveiller l'utilisation de la mémoire.

Un appareil dédié par répertoire

Chacun des quatre répertoires de données d' Instana (`data`, `metrics`, `analytics` et `objects`) doit se trouver sur son propre espace de stockage dédié.

Vous devez créer un répertoire pour chaque périphérique de stockage dédié.

L'isolation doit être maintenue de bout en bout, jusqu'à la couche physique.

Les répertoires ne doivent partager aucune des ressources suivantes :

  • Disque
  • Groupe de volumes
  • Pool SAN
  • Ensemble RAID
  • Toute autre couche qui utilise les mêmes broches, la même mémoire flash, le même cache ou le même contrôleur

La séparation au niveau de l'hôte — comme les points de montage distincts, les volumes logiques (LV) ou les LUN — est nécessaire, mais pas suffisante. Même si les ressources des couches inférieures sont finalement mappées sur le même matériel physique, les répertoires continueront de se disputer la capacité d'E/S.

L'isolation doit s'appliquer à l'ensemble de la pile de stockage, et pas seulement au niveau de la couche hôte. La seule exception à cette règle est le NVMe, qui fait l'objet d'un traitement distinct.

Isolation des performances

Instana Les répertoires de données génèrent un trafic d'E/S important, par intermittence et simultané. Chaque périphérique de stockage dispose d'une capacité d'E/S limitée qui comprend :

  • IOPS
  • Débit (bande passante)
  • Cache

Lorsque plusieurs répertoires partagent un périphérique :

Un pic de charge dans un répertoire peut réduire la capacité disponible pour les autres. Cela entraîne une latence imprévisible, qui peut se traduire par :

  • Délais d'expiration des requêtes
  • Traces perdues
  • Tableaux de bord lents
  • Contrôles de santé non réussis

Utilisez des appareils dédiés pour garantir des performances constantes et prévisibles.

Confinement des défaillances

Le stockage dédié attribue à chaque répertoire son propre domaine de défaillance. Si un périphérique est saturé, présente des dysfonctionnements ou n'est plus disponible, seul le répertoire associé est affecté.

Avec un stockage partagé, ce problème touche tous les répertoires qui partagent ce périphérique.

Bien que les banques de données d' Instana s soient interdépendantes et qu'il ne soit pas possible de garantir la disponibilité totale du service en cas de panne, l'isolation du stockage permet de limiter l'ampleur des répercussions et de simplifier les opérations de reprise.

Vérification de l'isolation du stockage

Vous devez vous assurer que chaque répertoire repose sur des ressources physiques indépendantes et qu'il n'y a aucun partage à aucun niveau.

L'hôte peut présenter plusieurs périphériques, même lorsqu'ils sont connectés à un stockage partagé. La validation au niveau de l'hôte ne suffit pas à elle seule.

Pour effectuer une validation au niveau de l'hôte, exécutez les commandes suivantes afin de vérifier les mappages des périphériques.

Pour afficher la liste des périphériques blocs et des points de montage :
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Pour les configurations LVM (suivi des LV, VG et PV) :

sudo pvssudo vgssudo lvdisplay -m

La configuration doit remplir les conditions suivantes :

  • Chaque point de montage utilise un périphérique bloc distinct
  • Aucun périphérique bloc n'est utilisé par plus d'un répertoire
  • Dans les configurations LVM, chaque groupe de volumes utilise uniquement ses propres volumes physiques, et aucun volume physique n'est partagé entre plusieurs groupes de volumes.

Valider au niveau du backend de stockage :

Pour les solutions SAN, NAS ou de stockage virtualisé, une validation supplémentaire est nécessaire, car l'hôte n'a pas de visibilité sur le partage des ressources en arrière-plan.

Vérifiez les conditions suivantes auprès de votre fournisseur de stockage ou de votre administrateur :

  • Ces volumes ne proviennent pas du même pool de stockage, du même ensemble RAID ou du même magasin de données.
  • Les ressources du contrôleur de stockage, telles que la mémoire cache, ne sont pas partagées.
  • Les chemins de tissu ou de connectivité sont indépendants
  • Les opérations d'E/S sur un volume n'ont aucune incidence sur un autre volume.
Exception : stockage NVMe

Cette exigence d'isolation repose sur les caractéristiques des disques traditionnels, telles que la latence de recherche et les files d'attente d'E/S sérialisées. Le stockage NVMe réduit considérablement ces contraintes. Dans les environnements NVMe, cette exigence peut être assouplie pour adopter un modèle basé sur la capacité.

Placement basé sur la capacité : plusieurs répertoires peuvent partager un seul périphérique NVMe si les conditions suivantes sont remplies :

  • Le dispositif offre un nombre suffisant d'IOPS et un débit soutenus.
  • La capacité dépasse la demande de pointe cumulée de tous les annuaires.

Prévoyez les pics de charge plutôt que la charge moyenne : les charges de travail peuvent connaître des pics soudains, et les pics simultanés peuvent saturer un équipement qui semble suffisant dans des conditions normales.

Isolation des pannes réduite : tous les répertoires situés sur le même périphérique partagent un seul domaine de défaillance. En cas de défaillance de l'appareil, tous les répertoires hébergés sur le même serveur sont affectés. N'utilisez les configurations NVMe partagées que si la perte de cette isolation est acceptable.

Répertoires par défaut

Instana utilise les répertoires suivants pour le stockage des données.

  • Répertoire de données : utilisé pour les magasins de données Elasticsearch, PostgreSQL, et Kafka. L'emplacement par défaut est /mnt/instana/stanctl/data.
  • Répertoire des métriques : utilisé pour les magasins de données Cassandra et BeeInstana. L'emplacement par défaut est /mnt/instana/stanctl/metrics.
  • Répertoire Analytics : utilisé pour le stockage des données d' ClickHouse. L'emplacement par défaut est /mnt/instana/stanctl/analytics.
  • Répertoire des objets : utilisé pour les spans bruts, la surveillance synthétique et la surveillance des utilisateurs finaux (EUM). L'emplacement par défaut est /mnt/instana/stanctl/objects.
  • Répertoire des données du cluster : utilisé pour les données du cluster.
  • $HOME répertoire : répertoire personnel de l'utilisateur root ou non root actuel.

En raison du débit de données élevé des différentes fonctionnalités d' Instana s et afin d'éviter les problèmes de performances, utilisez un stockage rapide et dédié, tel que des disques SSD (Solid State Drive). Utilisez des disques distincts pour chacun des répertoires de données, de métriques, d'analyses et d'objets.

Vous devez monter les répertoires suivants sur des disques distincts :

  • Répertoire de données du cluster : vous pouvez spécifier un répertoire personnalisé si vous ne disposez pas de suffisamment d'espace disque dans /var. Par exemple, /xyz/data. Veillez à spécifier ce répertoire à l'aide de la commande --cluster-data-dir lors de l'installation. Le --cluster-data-dir drapeau redirige uniquement le /var/lib/rancher/k3s répertoire vers le chemin personnalisé. K3s et kubelet continuent à écrire des données à d'autres /var emplacements, tels que /var/lib/kubelet/pods, les données temporaires du runtime du conteneur et les journaux des composants. Vous devez vous assurer que le /var disque dispose de suffisamment d'espace libre pour prendre en charge ces répertoires. Un espace insuffisant sur /var peut entraîner des échecs de planification des pods ou des avertissements de pression sur le disque kubelet. Si de tels problèmes surviennent, vous devez vérifier l'espace disponible dans /var/lib/kubelet et d'autres /var sous-répertoires.
  • $HOME répertoire : $HOME fait référence au répertoire personnel de l'utilisateur actuel. Par exemple, si l'utilisateur est un utilisateur root, $HOME serait /root; pour un utilisateur non root, $HOME serait /home/<username>.

Exigences en matière de réseau

Assurez-vous que vous répondez aux exigences suivantes en matière de ports et d'adresses IP. Pour plus d'informations sur l'ouverture de ces ports, consultez la section Règles de pare-feu.

Remarque : assurez-vous de disposer d'une connexion haut débit, à faible latence et stable sur le serveur backend afin de pouvoir télécharger les paquets nécessaires.

Ports requis

Les ports suivants doivent être ouverts et accessibles sur tous les nœuds.

Tableau 11. Ports à cinq nœuds
Numéro de port Direction Protocole Source Description
22 Entrant TCP Externe Port requis pour la connexion Secure Shell (SSH) (requis uniquement si vous souhaitez vous connecter via SSH)
22 Entrant TCP Interne Port SSH requis pour l'accès entre les nœuds backend
80 Entrant TCP Externe HTTP protocole pour l'interface utilisateur de la console d' Instana
443 Entrant TCP Externe HTTPS protocole pour l'interface utilisateur de la console Instana, console InstanaAPI, Instana EUM, OpenTelemetry, et Instana port d'acceptation d'agent
443 Sortant TCP Externe Requis uniquement dans les environnements en ligne. Pour plus d'informations, consultez la section Exigences d'accès au réseau sortant pour les déploiements Instana auto-hébergés.
53 Entrant TCP/UDP Interne (tous les nœuds) DNS port requis pour la résolution des noms de domaine
6443 Entrant TCP Interne (tous les nœuds) Port de service interne
8443 Entrant TCP Externe Instana port d'acceptation d'agent. Ce port est facultatif.
10250 Entrant TCP Interne (tous les nœuds) Port de service interne
2379 Entrant TCP Interne (tous les nœuds) Port de service interne
2380 Entrant TCP Interne (tous les nœuds) Port de service interne
5001 Entrant TCP Interne (tous les nœuds) Port de service interne
8472 Entrant UDP Interne (tous les nœuds) Port de service interne
9443 Entrant TCP Interne (tous les nœuds) Port de service interne
tous Entrant TCP/UDP 10.42.0.0/16 and10.43.0.0/16 Sous-réseaux des composants auto-hébergés d' Instana
tous Entrant TCP/UDP Bouclage Ouvrez les ports pour permettre à un serveur de messagerie ( VM ) d'envoyer et de recevoir ses propres paquets de données.

Tenez compte des remarques suivantes :

  • Une source externe signifie que le port doit être accessible depuis l'extérieur du réseau d'entreprise (privé) auto-hébergé d' Instana.
  • Une source interne signifie que le port d'un nœud doit être accessible par les deux autres nœuds du cluster à cinq nœuds.
  • Les adresses IP 10.42.0.0/16 et 10.43.0.0/16 doivent pouvoir accéder à tous les ports (1 à 65535) en interne.
  • Le pare-feu doit faire confiance à tout le trafic provenant de l'adresse de bouclage.
  • Le port 443 sortant est nécessaire pour accéder à certains référentiels. Pour plus d'informations, consultez la section « Exigences relatives à l'accès au réseau sortant ».

Adresses IP

Les cinq nœuds de votre cluster à cinq nœuds doivent répondre aux exigences suivantes en matière d'adresse IP :

  • Les cinq nœuds ont besoin d'une adresse IP privée sur le même VLAN privé pour pouvoir communiquer entre eux.
  • node0 (instana-0) doit également disposer d'une adresse IP pour la communication externe. L'adresse IP est également utilisée pour atteindre les hôtes depuis l'extérieur du cluster.