Configuration système requise pour un déploiement à nœud unique
Consultez la configuration système requise pour une instance auto-hébergée d' Standard Edition. sur un cluster à nœud unique.
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.
- Le nombre de serveurs sous surveillance.
- Les technologies qui tournent sur les serveurs surveillés, certaines technologies générant davantage de 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.
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.
Instana prend en charge les plateformes et systèmes d'exploitation suivants pour l'hôte :
| 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
L'hôte doit répondre aux exigences minimales d'unité centrale, de mémoire et de stockage.
Processeur, mémoire et stockage
Instana propose deux types d'installation que vous pouvez sélectionner lors de l'installation. Choisissez un type d'installation en fonction de votre environnement. Le type d'installation par défaut est demo.
- Utilisez le type d'installation
demouniquement pour les environnements de test et de démonstration. Ne l'utilisez pas dans un environnement de production. - Utilisez le type d'installation
productionpour les environnements de production.
demo installation et la convertir en une production installation sans perdre la configuration ni les données historiques. Pour mettre l'installation en production, renforcez votre infrastructure (processeurs, mémoire et stockage) afin de répondre aux exigences de production.Les tableaux suivants présentent les exigences en matière de processeur, de mémoire et de stockage pour un cluster à nœud unique.
| Type d'installation | 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 |
|---|---|---|---|---|---|
demo |
16 | 64 | 1 200 | 1 000 | 125 |
| production - Petites machines virtuelles (total pour l'ensemble des machines virtuelles) | 28 | 112 | 3700 | 3000 | 250 |
| production - Machines virtuelles volumineuses (total pour l'ensemble des machines virtuelles) | 56 | 224 | 7400 | 3000 | 250 |
Certaines fonctions facultatives peuvent nécessiter davantage d'UC et de mémoire. Si vous prévoyez d'activer ces fonctions facultatives, il est recommandé de fournir l'unité centrale et la mémoire dont ils ont besoin pour éviter les problèmes de performances.
Pour plus d'informations sur toutes les fonctionnalités optionnelles que vous pouvez installer, consultez la section « Activation des fonctionnalités optionnelles ».
Si vous activez l'autosurveillance de votre hôte Standard Edition, vous aurez besoin de ressources CPU et de mémoire supplémentaires, comme indiqué dans le tableau ci-dessous.
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 :
sse3ssse3sse4_1sse4_2popcntcx16lahf_lm
Espace de stockage requis
L'espace de stockage total requis dépend de manière significative de l'infrastructure et de la charge de travail que vous prévoyez de surveiller. De plus, les fonctions éventuellement utilisées, telles que la journalisation et les synthétiques, affectent la capacité de stockage requise.
Pour chaque type d'installation, le tableau suivant indique l'espace de stockage requis pour les répertoires utilisés dans l' Instana. Pour plus d'informations sur les répertoires, consultez la section « Répertoires par défaut ».
| Type d'installation | Répertoire racine (Go) | Répertoire de données (Go) | Répertoire de métriques (Go) | Répertoire d'analyse (Go) | Répertoire des objets (Go) | Répertoire de données du cluster (Go) | $HOME répertoire (GB) dans un environnement en ligne |
$HOME répertoire (GB) dans un environnement isolé physiquement |
Volume total de stockage (To) dans un environnement en ligne | Volume total de stockage (To) dans un environnement isolé physiquement |
|---|---|---|---|---|---|---|---|---|---|---|
demo |
100 | 150 | 300 | 500 | 250 | 100 | 10 | 40 | 1.45 | 1.48 |
production |
100 | 500 | 1 000 | 1 200 | 1 000 | 100 | 10 | 40 | 3.95 | 3.98 |
Pendant environ un mois, vous devez surveiller le volume de stockage que vous avez affecté initialement. Vous pouvez ensuite augmenter la capacité si nécessaire. En outre, si vous utilisez plus d'agents ou activez d'autres fonctions facultatives, 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 concerne 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, sporadiques 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é affecte 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.
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTPour les configurations LVM (suivi des LV, VG et PV) :
sudo pvssudo vgssudo lvdisplay -mLa 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 plusieurs répertoires
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 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 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.
$HOMEré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 en utilisant--cluster-data-dirlors de l'installation. L'indicateur--cluster-data-dirredirige uniquement le/var/lib/rancher/k3srépertoire vers le chemin personnalisé. K3s et kubelet continue d'enregistrer des données à d'autres/varemplacements, tels que les données temporaires/var/lib/kubelet/podsdu moteur d'exécution des conteneurs et les journaux des composants. Vous devez vous assurer que le/vardisque dispose de suffisamment d'espace libre pour accueillir ces répertoires. Un espace disque/varinsuffisant 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/kubeletet dans les autres/varsous-répertoires. $HOMErépertoire :$HOMEdésigne le répertoire personnel de l'utilisateur actuel. Par exemple, si l'utilisateur est un utilisateur root,$HOMEserait/root; pour un utilisateur non root,$HOMEserait/home/<username>.
Configuration réseau requise
Les ports suivants sur votre hôte doivent être ouverts et accessibles. Pour plus d'informations sur l'ouverture de ces ports, voir Règles de pare-feu.
| 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) |
| 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 ». |
| 8443 | Entrant | TCP | Externe | Instana port d'acceptation d'agent. Ce port est facultatif. |
| 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.
- Adresses IP
10.42.0.0/16et10.43.0.0/16doit 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 ».
Etapes suivantes
Passez à la configuration de votre environnement.