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

Vérifiez la configuration système requise pour une installation auto-hébergée d' Standard Edition. sur un cluster à trois nœuds.

Les spécifications suivantes correspondent aux exigences minimales pour un déploiement opérationnel. 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 maximales 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 surveillance.
  • Les technologies qui tournent sur les serveurs surveillés, certaines technologies étant plus gourmandes en métriques.
  • La charge d'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.
  • En raison de leur architecture et de leurs schémas de trafic, les microservices à fort trafic génèrent bien plus de segments que les applications monolithiques.
  • Complexité de l'infrastructure : un nœud d' Kubernetes comptant des centaines de pods peut générer un nombre de métriques nettement plus élevé qu'un simple VM.
  • Les fonctionnalités activées, telles que la surveillance des utilisateurs finaux (EUM), la journalisation et la surveillance sans serveur, peuvent entraîner une augmentation de l'ingestion et du stockage des données.
  • Les pics de trafic et les événements saisonniers : tenez compte des périodes de forte affluence, comme le Black Friday ou les campagnes promotionnelles.
Remarque : contactez vos représentants d' IBM s afin de déterminer si votre environnement correspond à l'approche de déploiement choisie. 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 à trois nœuds, vous avez besoin de trois hôtes équipés du même système d'exploitation.

Les trois noeuds d'un cluster à plusieurs noeuds ont des utilisations spécifiques:

  • Le premier noeud (instana-0), intitulé node-role.instana.io: "backend" lors de l'installation, est utilisé pour exécuter des charges de travail de back end qui nécessitent des volumes persistants. Le noeud exécute également la passerelle, les accepteurs et le système dorsal de l'interface utilisateur.

  • Le second noeud (instana-1), appelé node-role.instana.io: "datastore" lors de l'installation, est utilisé pour l'exécution des magasins de données.

  • Le troisième nœud ( instana-2 ), qui est désigné par node-role.instana.io: "other" lors de l'installation, sert à exécuter le reste des charges de travail d' Instana.

Plates-formes et systèmes d'exploitation pris en charge

Assurez-vous de disposer d'un serveur sur lequel vous pouvez exécuter le programme d'installation d' Standard Edition en mode autonome.

Remarque : Important : l'hôte peut être une machine virtuelle ou une machine physique dédiée. L'hôte doit être neuf et équipé d'un système d'exploitation fraîchement installé. Si vous souhaitez utiliser un serveur qui a déjà servi à autre chose, vous devez réinstaller le système d'exploitation. Standard Edition 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

Disponible 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 à plusieurs noeuds, seul le type d'installation production est pris en charge.

Processeur, mémoire et stockage

Les nœuds nécessitent, au maximum, la quantité de CPU, de mémoire et d'espace de stockage spécifiée pour l'ensemble des machines virtuelles.

Tableau 2. Production - Petites machines virtuelles (totaux pour l'ensemble des machines virtuelles)
Nombre de coeurs d'UC Mémoire (Go) Stockage Vitesse minimale du disque (IOPS) par seconde Débit minimal du disque (en MiB ) par seconde
36 144 4510 3000 250

Chaque nœud peut nécessiter, dans la limite des ressources de CPU, 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 12 48 1270 3000 250 dorsal
instana-1 12 48 2970 3000 250 magasin de données
instana-2 12 48 270 3000 250 autre

Les nœuds nécessitent, au maximum, la quantité de CPU, de mémoire et d'espace de stockage spécifiée pour l'ensemble des machines virtuelles.

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

Chaque nœud peut nécessiter, dans la limite des ressources de CPU, 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 2540 3000 250 dorsal
instana-1 32 128 5940 3000 250 magasin de données
instana-2 24 96 540 3000 250 autre

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

Allouez les ressources supplémentaires, telles que la capacité du processeur et de la mémoire, sur node0 (instana-0) et node2 (instana-2).

Remarque : ne provisionnez pas les ressources sur node1 (instana-1), car node1 est principalement utilisé 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 de journal sur node1 (instana-1).

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 doivent être présents sur les nœuds. Vous devez ajouter des disques supplémentaires sur ces noeuds.

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

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

Le tableau suivant indique les exigences de volume de stockage de chaque noeud:

Tableau 6. Exigences en matière de volume de stockage en cluster pour node0 instana-0
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire des objets /mnt/instana/stanctl/objects 1 000 Remplacer le chemin d'accès par--volume-objects
Répertoire racine / 100
Répertoire $HOME (en mode air-gapped) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 Go pour le répertoire $HOME (en mode air-gapped) et 20 Go d'espace disque supplémentaire.
Répertoire $HOME (sans isolation physique) /root ou le répertoire personnel des utilisateurs 10 Remplacer par la variable d'environnement $HOME
Répertoire de 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 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 des outils d'analyse /mnt/instana/stanctl/analytics 1 200
Répertoire racine / 100
Répertoire $HOME (en mode air-gapped) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 Go pour le répertoire $HOME (en mode air-gapped) et 20 Go d'espace disque supplémentaire.
Répertoire $HOME (sans isolation physique) /root ou le répertoire personnel des utilisateurs 10 Remplacer par la variable d'environnement $HOME
Répertoire de 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 node2 instana-2
Description Répertoire par défaut Taille minimale (Go) Commentaires
Répertoire racine / 100
Répertoire $HOME (en mode air-gapped) /root ou le répertoire personnel des utilisateurs 60 Remplacer par la variable d'environnement $HOME. 40 Go pour le répertoire $HOME (en mode air-gapped) et 20 Go d'espace disque supplémentaire.
Répertoire $HOME (sans isolation physique) /root ou le répertoire personnel des utilisateurs 10 Remplacer par la variable d'environnement $HOME
Répertoire de données du cluster /var/lib 100 Remplacer par-—cluster-data-dir
Remarque : Dans un environnement isolé physiquement, vous devez disposer de 20 Go d'espace disque supplémentaire dans le répertoire où vous créez le package isolé physiquement, tant sur l'hôte bastion que sur l'hôte Instana. Pour plus d'informations sur le package, consultez la section Création du package d'installation en mode air-gapped.

Pendant environ un mois, vous devez surveiller le volume de stockage que vous avez initialement attribué. Vous pourrez 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 des opérations d'E/S volumineuses, intermittentes et simultanées. 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é, défaillant ou indisponible, 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 en série. 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 stables.

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 bases 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 bases 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 segments bruts, la surveillance synthétique et la surveillance des utilisateurs finaux (EUM). L'emplacement par défaut est /mnt/instana/stanctl/objects.
  • Répertoire de données du cluster : utilisé pour les données du cluster.
  • $HOME répertoire : répertoire personnel de l'utilisateur actuel, qu'il s'agisse de l'utilisateur root ou d'un autre utilisateur.

En raison du débit de données élevé généré par diverses fonctionnalités d' Instana, et afin d'éviter tout problème de performances, utilisez un stockage rapide et dédié, tel que des disques SSD (Solid State Drives). Utilisez des disques distincts pour chacun des répertoires « data », « metrics », « analytics » et « objects ».

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

  • Répertoire de données du cluster : vous pouvez indiquer un répertoire personnalisé si vous ne disposez pas de suffisamment d'espace disque dans /var. Par exemple, /xyz/data. Veillez à indiquer ce répertoire à l'aide de l'option --cluster-data-dir lors de l'installation. L'indicateur --cluster-data-dir redirige uniquement le /var/lib/rancher/k3s répertoire vers le chemin personnalisé. K3s et kubelet continue d'enregistrer des données à d'autres /var emplacements, tels que les données temporaires /var/lib/kubelet/pods du moteur d'exécution des conteneurs et les journaux des composants. Vous devez vous assurer que le /var disque dispose de suffisamment d'espace libre pour accueillir ces répertoires. Un espace disque /var insuffisant peut entraîner des échecs de planification des pods ou des avertissements de pression sur le disque émis par kubelet. Si de tels problèmes surviennent, vous devez vérifier l'espace disponible dans /var/lib/kubelet et dans les autres /var sous-répertoires.
  • $HOME répertoire : $HOME désigne le 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>.

Configuration réseau requise

Vérifiez que vous respectez les exigences suivantes en matière de ports et d'adresses IP. Pour plus d'informations sur l'ouverture de ces ports, voir Règles de pare-feu.

Remarque : assurez-vous que le serveur backend dispose d'une connexion haut débit, à faible latence et stable pour télécharger les paquets nécessaires.

Ports requis

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

Tableau 9. Ports multi-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 en SSH)
22 Entrant TCP Interne Port SSH requis pour l'accès entre les nœuds du 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, Instana console API, Instana EUM, OpenTelemetry, et Instana port d'acceptation de l'agent
443 Sortant TCP Externe Exigé uniquement dans les environnements en ligne. Pour plus d'informations, consul tez la section « Exigences en matière d'accès réseau sortant pour les déploiements auto-hébergés d' Instana ».
53 Entrant TCP/UDP Interne (tous les nœuds) DNS port nécessaire à 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 « 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.
  • La source interne signifie que le port d'un nœud doit être accessible par les deux autres nœuds du cluster multi-nœuds.
  • Adresses IP10.42.0.0/16 et10.43.0.0/16 doit 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 sortant 443 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 trois noeuds de votre cluster multinoeud doivent répondre aux exigences d'adresse IP suivantes:

  • Les trois noeuds 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 les communications externes. L'adresse IP sert également à accéder aux hôtes depuis l'extérieur du cluster.