La gestion des performances implique l'optimisation du temps de réponse du service réseau et la gestion de la cohérence et de la qualité de services réseau individuels et globaux. Le service le plus important est celui de mesurer le temps de réponse des utilisateurs et des applications. Pour la plupart des utilisateurs, le temps de réponse est l'indicateur de succès essentiel en ce qui a trait au rendement. Cette variable influence la perception du réseau par vos utilisateurs et les administrateurs des applications.
La planification des capacités est le processus par lequel vous déterminez les besoins en ressources réseau futures afin d'éviter un impact sur les performances ou la disponibilité des applications stratégiques de l'entreprise. Dans le domaine de la planification des capacités, la ligne de base du réseau (CPU, mémoire, mémoires tampon, octets entrants/sortants, etc.) peut affecter le temps de réponse. Par conséquent, gardez à l'esprit que les problèmes de performances sont souvent liés à la capacité. Dans les réseaux, il s’agit généralement de bande passante et de données qui doivent attendre dans les files d’attente avant de pouvoir être transmises via le réseau. Dans les applications vocales, ce délai d'attente affecte presque certainement les utilisateurs, car des facteurs tels que le délai et la gigue affectent la qualité de l'appel vocal.
Un autre problème majeur qui complique la gestion des performances est que, bien que la disponibilité élevée du réseau soit essentielle pour les réseaux des grandes entreprises et des fournisseurs de services, la tendance est de rechercher des gains économiques à court terme au risque d'une augmentation des coûts (souvent imprévus) à long terme. Au cours de chaque cycle budgétaire, les administrateurs réseau et le personnel chargé de la mise en oeuvre des projets ont du mal à trouver un équilibre entre les performances et une mise en oeuvre rapide. En outre, les administrateurs réseau sont confrontés à des défis tels que le développement rapide de produits afin de répondre à des créneaux commerciaux étroits, des technologies complexes, la consolidation commerciale, des marchés concurrents, des temps d'arrêt imprévus, un manque d'expertise et souvent des outils insuffisants.
À la lumière de ces défis, comment les performances s’intègrent-elles dans le cadre de gestion du réseau ? La principale fonction d’un système de gestion de réseau idéal est d’optimiser les capacités opérationnelles d’un réseau. Une fois que vous avez accepté cet objectif comme objectif ultime de la gestion du réseau, l'objectif principal de la gestion du réseau est de maintenir le fonctionnement du réseau à des performances optimales.
Un système d’administration réseau idéal inclut les opérations suivantes :
Informe l'opérateur de la détérioration imminente des performances.
Fournit un routage et des solutions de rechange faciles en cas de détérioration ou de défaillance des performances.
Fournit les outils permettant d'identifier les causes de détérioration ou de défaillance des performances.
Sert de station principale pour la résilience et la survie du réseau.
Communication des performances en temps réel.
En se basant sur cette définition pour un système idéal, la gestion des performances devient essentielle à la gestion du réseau. Ces problèmes de gestion des performances sont essentiels :
Performances utilisateur
Performances des applications
Planification de capacité
Gestion proactive des pannes
Il est important de noter que dans les applications plus récentes, telles que la voix et la vidéo, les performances sont la variable clé du succès et que si vous ne parvenez pas à obtenir des performances homogènes, le service est considéré comme de faible valeur et échoue. Dans d'autres cas, les utilisateurs souffrent simplement de performances variables avec des délais d'attente intermittents qui dégradent la productivité et la satisfaction des utilisateurs.
Ce document décrit en détail les problèmes les plus critiques en matière de gestion des performances, notamment les facteurs de réussite critiques, les indicateurs de performance clés et une feuille de route de haut niveau pour la gestion des performances. Il aborde également les concepts de disponibilité, de temps de réponse, de précision, d'utilisation et de planification de la capacité et propose une brève discussion sur le rôle de l'analyse proactive des pannes au sein de la gestion des performances et du système d'administration réseau idéal.
Les principaux facteurs de réussite identifient les exigences des meilleures pratiques de mise en oeuvre. Pour être considéré comme un facteur de succès critique, un processus ou une procédure doit améliorer la disponibilité ou l'absence de procédure doit diminuer la disponibilité. En outre, le facteur de succès critique doit être mesurable afin que l'organisation puisse déterminer l'étendue de son succès.
Note : Voir Indicateurs de gestion des performances pour des informations détaillées.
Voici les principaux facteurs de réussite de la gestion de la performance :
Collecte d'une ligne de base pour les données du réseau et des applications.
Effectuez une analyse de simulation sur votre réseau et vos applications.
Réaliser des rapports d'exception pour les problèmes de capacité.
Déterminez la surcharge de gestion du réseau pour tous les services de gestion de réseau proposés ou potentiels.
Analyser les informations de capacité.
Examiner périodiquement les informations de capacité pour le réseau et les applications, ainsi que les données de référence et les exceptions.
Disposer de procédures de mise à niveau ou de réglage pour gérer les problèmes de capacité de manière réactive et à long terme.
Les indicateurs de rendement fournissent le mécanisme par lequel une organisation peut mesurer les facteurs de succès critiques. Les indicateurs de rendement pour la planification du rendement comprennent :
Documenter les objectifs commerciaux de la gestion du réseau. Il peut s'agir d'un concept d'exploitation formel pour la gestion du réseau ou d'une déclaration moins formelle des fonctions et objectifs requis.
Créer des objectifs de niveau de service détaillés et mesurables.
Fournir la documentation des accords de niveau de service avec des graphiques ou des graphiques qui montrent le succès ou l'échec de la façon dont ces accords sont respectés au fil du temps.
Collecter une liste des variables de la ligne de base, telles que l'intervalle d'interrogation, la surcharge de gestion du réseau encourue, les seuils de déclenchement possibles, si la variable est utilisée comme déclencheur d'un déroutement et l'analyse des tendances utilisée pour chaque variable.
Organiser une réunion périodique qui passe en revue l'analyse des données de référence et des tendances.
Disposer d'une méthodologie d'analyse de simulation documentée. Cela devrait inclure la modélisation et la vérification, le cas échéant.
Lorsque les seuils sont dépassés, développez la documentation sur la méthodologie utilisée pour augmenter les ressources réseau. L'un des éléments à documenter est le délai nécessaire pour ajouter une bande passante WAN supplémentaire et un tableau de coûts.
Ces étapes fournissent un flux de processus de haut niveau pour la gestion des performances :
Avant de définir les variables de performances et de capacité détaillées d'un réseau, vous devez examiner le concept global d'exploitation de la gestion du réseau au sein de votre organisation. Lorsque vous définissez ce concept global, il fournit une base commerciale sur laquelle vous pouvez élaborer des définitions précises des fonctionnalités souhaitées dans votre réseau. Si vous ne parvenez pas à développer un concept opérationnel pour la gestion du réseau, cela peut conduire à un manque d'objectifs ou d'objectifs qui changent constamment en raison des demandes des clients.
En règle générale, vous créez le concept d'exploitation de la gestion du réseau comme première étape de la phase de définition du système du programme de gestion du réseau. L'objectif est de décrire les caractéristiques globales du système d'un point de vue opérationnel. Ce document sert à coordonner les objectifs commerciaux généraux (non quantitatifs) des opérations réseau, de l'ingénierie, de la conception, des autres unités commerciales et des utilisateurs finaux. Ce document a pour objet de constituer les activités de planification opérationnelle à long terme pour la gestion et l’exploitation du réseau. Il fournit également des orientations pour l'élaboration de tous les documents de définition ultérieurs, tels que les accords de niveau de service. Cet ensemble initial de définitions ne peut évidemment pas se concentrer trop étroitement sur la gestion de problèmes de réseau spécifiques, mais sur les éléments qui mettent l'accent sur l'importance pour l'ensemble de l'organisation et en relation avec les coûts qui doivent être gérés également. Certains objectifs sont les suivants :
Identifiez les caractéristiques essentielles à une utilisation efficace de l'infrastructure réseau.
Identifier les services/applications pris en charge par le réseau.
Lancer la gestion des services de bout en bout.
Lancer des mesures basées sur les performances pour améliorer le service global.
Collecter et distribuer des informations de gestion des performances.
Prendre en charge l'évaluation stratégique du réseau avec les commentaires des utilisateurs.
En d'autres termes, le concept d'exploitation de la gestion du réseau doit se concentrer sur les objectifs généraux de l'entreprise et votre philosophie pour atteindre ces objectifs. Les principaux ingrédients sont les définitions de plus haut niveau de la mission, des objectifs de la mission, des buts du système, de la participation de l'organisation et de la philosophie opérationnelle globale.
En tant qu'administrateur réseau, vous êtes en mesure d'unifier les attentes souvent incohérentes de vos utilisateurs en matière de performances. Par exemple, si la principale exigence du réseau est le transfert de fichiers volumineux d'un emplacement à un autre, vous voulez vous concentrer sur le haut débit et moins sur les temps de réponse des utilisateurs interactifs. Veillez à ne pas limiter votre vision des performances à moins de prendre en compte une variété de problèmes. Par exemple, lorsque vous testez un réseau, examinez les niveaux de charge utilisés. La charge est souvent basée sur de très petits paquets et le débit sur des paquets très volumineux. Ces deux tests de performances peuvent produire une image très positive, mais en fonction de la charge de trafic de votre réseau, les tests peuvent ne pas présenter une image réelle des performances. Étudiez les performances du réseau dans autant de conditions de charge de travail que possible et documentez les performances.
En outre, bien que de nombreuses organisations de gestion de réseau disposent de techniques d'alarme efficaces pour avertir les techniciens d'une défaillance de périphérique, il est beaucoup plus difficile de définir et de mettre en oeuvre un processus d'évaluation des performances des applications de bout en bout. Par conséquent, alors que le centre d’exploitation du réseau (NOC) peut réagir rapidement à un routeur ou à un commutateur mis hors service, les conditions réseau susceptibles de nuire aux performances du réseau et d’affecter la perception des utilisateurs risquent de passer inaperçues jusqu’à ce que cette perception devienne négative. Aussi difficile que cela puisse paraître, ce deuxième processus peut apporter d'énormes avantages à l'entreprise et à la gestion du réseau.
Enfin, assurez-vous de ne pas créer d'attentes irréalistes quant aux performances de votre réseau. Des attentes irréalistes sont généralement créées lorsque vous ne comprenez pas les détails des protocoles réseau ou des applications. Souvent, les performances médiocres ne sont pas la faute du réseau, mais plutôt le résultat d'une conception d'applications médiocre. La seule façon de documenter et de mesurer les performances des applications consiste à disposer d'une ligne de base des performances réseau avant l'installation des applications.
La première étape de la gestion des performances, de la planification continue des capacités et de la conception du réseau consiste à définir les fonctionnalités et/ou services requis. Cette étape nécessite que vous compreniez les applications, les flux de trafic de base, le nombre d'utilisateurs et de sites et les services réseau requis. La première utilisation de cette information est de déterminer l'importance de l'application pour les objectifs organisationnels. Vous pouvez également utiliser ces informations pour créer une base de connaissances à utiliser dans la conception logique afin de comprendre les besoins en bande passante, interface, connectivité, configuration et périphériques physiques. Cette étape initiale permet à vos architectes réseau de créer un modèle de votre réseau.
Créer des objectifs d'évolutivité de la solution afin d'aider les ingénieurs réseau à concevoir des réseaux qui répondent aux besoins de croissance futurs et à s'assurer que les conceptions proposées ne subissent pas de contraintes de ressources en raison de la croissance ou de l'extension du réseau. Les contraintes de ressources peuvent inclure :
Trafic global
Volume
Nombre de routes
Nombre de circuits virtuels
Nombre de voisins
Domaines de diffusion
Débit du périphérique
Capacité multimédia
Les planificateurs de réseau doivent déterminer la durée de vie requise de la conception, les extensions ou les sites attendus nécessaires tout au long de la durée de vie de la conception, le volume des nouveaux utilisateurs et le volume de trafic ou les changements attendus. Ce plan permet de s'assurer que la solution proposée répond aux exigences de croissance pendant la durée de vie prévue de la conception.
Si vous n'étudiez pas l'évolutivité de la solution, vous serez peut-être contraint de mettre en oeuvre des modifications majeures de conception réactive. Cette modification de conception peut inclure une hiérarchie supplémentaire, des mises à niveau de support ou des mises à niveau matérielles. Dans les entreprises qui comptent sur des cycles budgétaires assez précis pour les achats de matériel majeur, ces changements peuvent constituer un obstacle majeur à la réussite globale. En termes de disponibilité, les réseaux peuvent connaître des limitations de ressources inattendues qui provoquent des périodes de non-disponibilité et des mesures réactives.
Les tests d'interopérabilité et d'interopérabilité peuvent être essentiels au succès des nouveaux déploiements de solutions. L'interopérabilité peut faire référence à différents fournisseurs de matériel, ou à différentes topologies ou solutions qui doivent se combiner pendant ou après une mise en oeuvre réseau. Les problèmes d'interopérabilité peuvent inclure la signalisation matérielle via la pile de protocoles pour résoudre les problèmes de routage ou de transport. Des problèmes d'interopérabilité peuvent survenir avant, pendant ou après la migration d'une solution réseau. La planification de l'interopérabilité doit inclure la connectivité entre différents périphériques et les problèmes de topologie qui peuvent survenir lors des migrations.
La comparaison de solutions est la pratique dans laquelle vous comparez les différentes conceptions potentielles par rapport aux autres pratiques de besoins de solutions. Cette pratique permet de s'assurer que la solution est la meilleure adaptée à un environnement particulier et que les préjugés personnels ne conduisent pas le processus de conception. La comparaison peut inclure différents facteurs tels que le coût, la résilience, la disponibilité, le risque, l'interopérabilité, la facilité de gestion, l'évolutivité et les performances. Tous ces éléments peuvent avoir un effet majeur sur la disponibilité globale du réseau une fois la conception mise en oeuvre. Vous pouvez également comparer les supports, la hiérarchie, la redondance, les protocoles de routage et les fonctionnalités similaires. Créez un graphique avec les facteurs de l'axe des X et les solutions potentielles de l'axe des Y afin de résumer les comparaisons de solutions. La comparaison détaillée des solutions dans un environnement de laboratoire permet également d'étudier objectivement les nouvelles solutions et fonctionnalités par rapport aux différents facteurs de comparaison.
Dans le cadre du concept d'exploitation de la gestion du réseau, il est essentiel de définir les objectifs du réseau et des services pris en charge d'une manière que tous les utilisateurs puissent comprendre. Les activités qui suivent l'élaboration du concept opérationnel sont fortement influencées par la qualité de ce document.
Voici les objectifs de performances standard :
Temps de réponse
Utilisation
Débit
Capacité (débit maximal)
Bien que ces mesures puissent être insignifiantes pour un LAN simple, elles peuvent être très difficiles sur un réseau de campus commuté ou un réseau d'entreprise multifournisseur. Lorsque vous utilisez un plan d'opérations bien pensé, chacun des objectifs de performance est défini de manière mesurable. Par exemple, le temps de réponse minimal pour la demande « x » est de 500 Ms ou moins pendant les heures de pointe. Cela définit les informations permettant d'identifier la variable, la manière de la mesurer et la période de la journée pendant laquelle l'application de gestion de réseau doit se concentrer.
Les objectifs de disponibilité définissent les exigences de niveau de service ou de niveau de service pour un service réseau. Cela permet de s'assurer que la solution répond aux exigences de disponibilité finale. Définissez différentes classes de service pour une organisation particulière et détaillez les exigences réseau pour chaque classe qui sont adaptées aux exigences de disponibilité. Différentes zones du réseau peuvent également nécessiter différents niveaux de disponibilité. Un objectif de disponibilité plus élevée pourrait nécessiter une redondance et des procédures d'assistance accrues. Lorsque vous définissez un objectif de disponibilité pour un service réseau particulier et mesurez la disponibilité, votre organisation réseau peut comprendre les composants et les niveaux de service nécessaires pour atteindre les SLA prévus.
Définir des objectifs de facilité de gestion afin de s'assurer que la gestion globale du réseau ne manque pas de fonctionnalités de gestion. Afin de définir des objectifs de facilité de gestion, vous devez comprendre le processus d'assistance et les outils de gestion de réseau associés pour votre organisation. Les objectifs de facilité de gestion doivent inclure la connaissance de la manière dont les nouvelles solutions s'intègrent dans le modèle d'assistance et d'outil actuel avec des références à toute différence potentielle ou à de nouvelles exigences. Cela est essentiel à la disponibilité du réseau, car la capacité à prendre en charge de nouvelles solutions est essentielle au succès du déploiement et à la réalisation des objectifs de disponibilité.
Les objectifs de facilité de gestion doivent permettre de découvrir toutes les informations importantes de la base MIB ou de l'outil réseau requises pour prendre en charge un réseau potentiel, la formation requise pour prendre en charge le nouveau service réseau, les modèles de dotation en personnel pour le nouveau service et toute autre exigence d'assistance. Souvent, ces informations ne sont pas découvertes avant le déploiement et la disponibilité globale souffre du manque de ressources affectées à la prise en charge de la nouvelle conception de réseau.
Les SLA de performances et les métriques permettent de définir et de mesurer les performances des nouvelles solutions réseau pour s'assurer qu'elles répondent aux exigences de performances. Les performances de la solution proposée peuvent être mesurées à l’aide d’outils de surveillance des performances ou d’une simple commande ping sur l’infrastructure réseau proposée. Les SLA de performances doivent inclure le volume de trafic attendu moyen, le volume de trafic maximal, le temps de réponse moyen et le temps de réponse maximal autorisés. Ces informations peuvent ensuite être utilisées plus tard dans la section de validation de la solution et, en fin de compte, elles permettent de déterminer les performances et la disponibilité requises du réseau.
Un aspect important de la conception du réseau est lorsque vous définissez le service pour les utilisateurs ou les clients. Les entreprises appellent ces accords de niveau de service tandis que les fournisseurs de services les appellent gestion de niveau de service. La gestion des niveaux de service inclut généralement des définitions des types de problèmes et de la gravité et des responsabilités du centre d'assistance, telles que le chemin d'escalade et le temps avant l'escalade à chaque niveau d'assistance, le temps de début du travail sur le problème et le temps de fermeture des cibles en fonction de la priorité. D'autres facteurs importants sont les services fournis dans les domaines de la planification de la capacité, de la gestion proactive des pannes, de la notification de gestion des changements, des seuils, des critères de mise à niveau et du remplacement du matériel.
Lorsque les organisations ne définissent pas les niveaux de service à l'avance, il devient difficile d'améliorer ou d'obtenir les ressources requises identifiées ultérieurement. Il devient également difficile de comprendre les ressources à ajouter afin de prendre en charge le réseau. Dans de nombreux cas, ces ressources ne sont appliquées qu'après la découverte de problèmes.
La gestion de la performance est un terme général qui englobe la configuration et la mesure des différents domaines de performance. Cette section décrit les six concepts suivants de gestion de la performance :
La plupart des intranets d'entreprise ont une bande passante suffisante. Cependant, sans données adéquates, vous ne pourrez peut-être pas exclure l'encombrement du réseau en tant que facteur de performances des applications médiocres. L'un des indices de congestion ou d'erreurs est si les performances médiocres sont intermittentes ou dépendent de l'heure de la journée. Un exemple de cette condition est quand la performance est adéquate tard dans la soirée, mais très lente le matin et pendant les heures de pointe.
Une fois que vous avez défini le concept d'exploitation de la gestion du réseau et défini les données de mise en oeuvre nécessaires, il est nécessaire de collecter ces données au fil du temps. Ce type de collecte constitue la base de la ligne de base du réseau.
Effectuer une ligne de base du réseau actuel avant un déploiement de nouvelle solution (application ou changement IOS) et après le déploiement afin de mesurer les attentes définies pour la nouvelle solution. Cette ligne de base permet de déterminer si la solution répond aux objectifs de performances et de disponibilité et à la capacité de référence. Un rapport de base type routeur/commutateur inclut des problèmes de capacité liés au CPU, à la mémoire, à la gestion de la mémoire tampon, à l'utilisation des liaisons/supports et au débit. Il existe d'autres types de données de base que vous pouvez également inclure, en fonction des objectifs définis dans le concept d'exploitation. Par exemple, une base de disponibilité démontre une stabilité/disponibilité accrue de l'environnement réseau. Effectuer une comparaison de référence entre les anciens et les nouveaux environnements afin de vérifier les exigences de la solution.
Une autre ligne de base spécialisée est la ligne de base des applications, qui est utile lorsque vous réglez les besoins en réseau des applications. Ces informations peuvent être utilisées à des fins de facturation et/ou de budgétisation dans le cycle de mise à niveau. Les niveaux de référence des applications peuvent également être importants dans le domaine de la disponibilité des applications par rapport aux services ou aux qualités de service préférés par application. Les informations de base des applications se composent principalement de la bande passante utilisée par les applications par période. Certaines applications de gestion de réseau peuvent également établir des performances de base pour les applications. Une ventilation du type de trafic (Telnet ou FTP) est également importante pour la planification. Dans certaines entreprises, les zones du réseau où les ressources sont limitées sont surveillées pour les principaux intervenants. Les administrateurs réseau peuvent utiliser ces informations pour budgétiser, planifier ou régler le réseau. Lorsque vous ajustez le réseau, vous pouvez modifier les paramètres de qualité de service ou de file d'attente pour le service ou l'application réseau.
L’une des principales mesures utilisées par les administrateurs réseau est la disponibilité. La disponibilité est la mesure du temps pendant lequel un système ou une application réseau est disponible pour un utilisateur. Du point de vue du réseau, la disponibilité représente la fiabilité des composants individuels d’un réseau.
Par exemple, afin de mesurer la disponibilité, vous pouvez coordonner les appels téléphoniques du centre d'assistance avec les statistiques collectées à partir des périphériques gérés. Cependant, les outils de disponibilité ne peuvent pas déterminer toutes les raisons de l'échec.
La redondance du réseau est un autre facteur à prendre en compte lorsque vous mesurez la disponibilité. La perte de redondance indique une dégradation du service plutôt qu'une panne totale du réseau. Il peut en résulter un temps de réponse plus lent et une perte de données due aux paquets abandonnés. Il est également possible que les résultats se manifestent dans d'autres domaines de la mesure du rendement tels que l'utilisation et le temps de réponse.
Enfin, si vous effectuez une livraison avec un contrat de niveau de service, vous devez tenir compte des pannes planifiées. Ces pannes peuvent être le résultat de déplacements, d'ajouts et de modifications, de fermetures de sites ou d'autres événements que vous ne souhaitez peut-être pas signaler. Il ne s'agit pas seulement d'une tâche difficile, mais aussi d'une tâche manuelle.
Le temps de réponse du réseau est le temps nécessaire au trafic entre deux points. Les temps de réponse plus lents que la normale, vus par une comparaison de ligne de base ou qui dépassent un seuil, peuvent indiquer un encombrement ou une défaillance du réseau.
Le temps de réponse est la meilleure mesure de l'utilisation du réseau du client et peut vous aider à évaluer l'efficacité de votre réseau. Quelle que soit la source de la réponse lente, les utilisateurs sont frustrés par le retard du trafic. Dans les réseaux distribués, de nombreux facteurs affectent le temps de réponse, tels que :
Emcongestion du réseau
Route inférieure à la route souhaitable vers la destination (ou aucune route du tout)
Périphériques réseau sous-alimentés
Des pannes réseau telles qu’une tempête de diffusion
Erreurs de bruit ou de CRC
Dans les réseaux qui utilisent la mise en file d’attente liée à la qualité de service, la mesure du temps de réponse est importante pour déterminer si les types de trafic corrects transitent par le réseau comme prévu. Par exemple, lorsque vous mettez en oeuvre le trafic vocal sur des réseaux IP, les paquets vocaux doivent être livrés à temps et à un rythme constant afin de maintenir une bonne qualité vocale. Vous pouvez générer du trafic classé comme trafic vocal afin de mesurer le temps de réponse du trafic tel qu'il apparaît aux utilisateurs.
Vous pouvez mesurer le temps de réponse afin de résoudre les conflits entre les serveurs d'applications et les gestionnaires de réseau. Les administrateurs réseau sont souvent présumés coupables lorsqu'une application ou un serveur semble lent. L’administrateur réseau doit prouver que le réseau n’est pas le problème. La collecte de données sur le temps de réponse fournit un moyen indiscutable de prouver ou de réfuter que le réseau est la source des problèmes d'application.
Dans la mesure du possible, vous devez mesurer le temps de réponse tel qu'il apparaît aux utilisateurs. Un utilisateur perçoit la réponse comme l'heure à partir de laquelle il appuie sur Entrée ou clique sur un bouton jusqu'à ce que l'écran s'affiche. Ce temps écoulé comprend le temps nécessaire à chaque périphérique réseau, à la station de travail utilisateur et au serveur de destination pour traiter le trafic.
Malheureusement, la mesure à ce niveau est presque impossible en raison du nombre d'utilisateurs et du manque d'outils. En outre, lorsque vous incorporez le temps de réponse des utilisateurs et des serveurs, cela n'apporte que peu de valeur lorsque vous déterminez la croissance future du réseau ou que vous résolvez des problèmes de réseau.
Vous pouvez utiliser les périphériques réseau et les serveurs pour mesurer le temps de réponse. Vous pouvez également utiliser des outils comme ICMP pour mesurer les transactions, bien qu'il ne prenne pas en compte les retards introduits dans un système au fur et à mesure que les couches supérieures le traitent. Cette approche résout le problème des connaissances sur les performances du réseau.
À un niveau simpliste, vous pouvez chronométrer la réponse aux requêtes ping de la station de gestion du réseau vers les points clés du réseau, tels qu'une interface mainframe, le point d'extrémité d'une connexion du fournisseur de services ou les adresses IP des utilisateurs clés, afin de mesurer le temps de réponse. Le problème avec cette méthode est qu'elle ne reflète pas fidèlement la perception de l'utilisateur du temps de réponse entre sa machine et la machine de destination. Il collecte simplement des informations et génère des rapports sur le temps de réponse du point de vue des stations de gestion du réseau. Cette méthode masque également les problèmes de temps de réponse saut par saut sur l'ensemble du réseau.
Une alternative à l'interrogation centrée sur le serveur consiste à distribuer l'effort plus près de la source et de la destination que vous souhaitez simuler pour mesure. Utilisez des interrogateurs de gestion de réseau distribués et implémentez la fonctionnalité SAA (Service Assurance Agent) de Cisco IOS. Vous pouvez activer SAA sur les routeurs afin de mesurer le temps de réponse entre un routeur et un périphérique de destination tel qu'un serveur ou un autre routeur. Vous pouvez également spécifier un port TCP ou UDP, qui force le trafic à être transféré et dirigé de la même manière que le trafic qu'il simule.
Grâce à l'intégration de la voix, de la vidéo et des données sur les réseaux multiservices, les clients mettent en oeuvre la hiérarchisation QoS dans leur réseau. Les mesures ICMP ou UDP simples ne reflètent pas fidèlement le temps de réponse puisque les différentes applications reçoivent des priorités différentes. En outre, avec la commutation de balises, le routage du trafic peut varier en fonction du type d’application contenu dans un paquet spécifique. Ainsi, une requête ping ICMP peut recevoir des priorités différentes dans la manière dont chaque routeur la gère et recevoir des routes différentes et moins efficaces.
Dans ce cas, la seule façon de mesurer le temps de réponse est de générer du trafic qui ressemble à l'application ou à la technologie particulière qui présente un intérêt. Cela force les périphériques réseau à gérer le trafic comme pour le trafic réel. Vous pouvez atteindre ce niveau avec SAA ou en utilisant des sondes tierces prenant en compte les applications.
La précision est la mesure du trafic d’interface qui ne génère pas d’erreur et peut être exprimée en pourcentage qui compare le taux de réussite au taux total de paquets sur une période donnée. Vous devez d'abord mesurer le taux d'erreur. Par exemple, si deux paquets sur 100 entraînent une erreur, le taux d'erreur est de 2 % et le taux de précision est de 98 %.
Avec les technologies de réseau antérieures, en particulier dans le domaine étendu, un certain niveau d'erreurs était acceptable. Cependant, avec les réseaux haut débit et les services WAN actuels, la transmission est considérablement plus précise et les taux d'erreur sont proches de zéro, sauf en cas de problème réel. Les causes les plus courantes des erreurs d’interface sont les suivantes :
Câblage non conforme aux spécifications
Interférence électrique
Matériel ou logiciel défectueux
Utiliser un taux de précision réduit pour déclencher une enquête plus approfondie. Vous pouvez découvrir qu’une interface particulière présente des problèmes et décider que les erreurs sont acceptables. Dans ce cas, vous devez ajuster le seuil de précision de cette interface afin de refléter où le taux d'erreur est inacceptable. Le taux d'erreur inacceptable a peut-être été signalé dans une ligne de base antérieure.
Les variables décrites dans ce tableau sont utilisées dans les formules de précision et de taux d'erreur :
Notation | Description |
---|---|
ΔifInErrors | Delta (ou différence) entre deux cycles d'interrogation qui collectent l'objet ifInErrors snmp, qui représente le nombre de paquets entrants avec une erreur. |
ΔsiInUcastPkts | Le delta entre deux cycles d'interrogation qui collectent l'objet ifInUcastPkts snmp, qui représente le nombre de paquets de monodiffusion entrants. |
ΔsiInNUcastPkts | Le delta entre les deux cycles d'interrogation qui collectent l'objet ifInNUcastPkts snmp, qui représente le nombre de paquets entrants non monodiffusion (multidiffusion et diffusion). |
La formule du taux d'erreur est généralement exprimée en pourcentage :
Taux d'erreur = (ΔifInErrors) *100
—
(ΔifInUcastPkts + (ΔifInNUcastPkts)
Notez que les erreurs sortantes ne sont pas prises en compte dans les formules de taux d'erreur et de précision. En effet, un périphérique ne doit jamais placer sciemment des paquets avec des erreurs sur le réseau et les taux d'erreur de l'interface sortante ne doivent jamais augmenter. Par conséquent, le trafic entrant et les erreurs sont les seules mesures d'intérêt pour les erreurs d'interface et la précision.
La formule de précision prend le taux d'erreur et le soustrait de 100 (encore une fois, sous forme de pourcentage) :
Précision = 100 - (ΔifInErrors) *100
—
(ΔifInUcastPkts + (ΔifInNUcastPkts)
Ces formules reflètent les erreurs et la précision en termes de compteurs génériques d'interface MIB II (RFC 2233). Le résultat est exprimé en pourcentage qui compare les erreurs au nombre total de paquets vus et envoyés. Le taux d'erreur qui en résulte est soustrait de 100, ce qui produit le taux de précision. Un taux de précision de 100% est parfait.
Puisque les variables MIB II sont stockées en tant que compteurs, vous devez prendre deux cycles d'interrogation et calculer la différence entre les deux (d'où le Delta utilisé dans l'équation).
L'utilisation mesure l'utilisation d'une ressource particulière au fil du temps. La mesure est généralement exprimée sous la forme d'un pourcentage dans lequel l'utilisation d'une ressource est comparée à sa capacité opérationnelle maximale. Grâce aux mesures d'utilisation, vous pouvez identifier les encombrements (ou les encombrements potentiels) sur l'ensemble du réseau. Vous pouvez également identifier les ressources sous-utilisées.
L’utilisation est la mesure principale permettant de déterminer l’intégralité des canaux (liaisons) du réseau. Mesurez le processeur, l'interface, la mise en file d'attente et d'autres mesures de capacité liées au système afin de déterminer dans quelle mesure les ressources du système réseau sont consommées.
Une utilisation élevée n'est pas nécessairement mauvaise. Une faible utilisation peut indiquer des flux de trafic dans des endroits inattendus. À mesure que les lignes deviennent surexploitées, les effets peuvent devenir significatifs. La surutilisation se produit lorsqu'il y a plus de trafic mis en file d'attente pour passer sur une interface qu'il ne peut gérer. Des sauts soudains dans l'utilisation des ressources peuvent indiquer une condition de panne.
Lorsqu’une interface devient encombrée, le périphérique réseau doit stocker le paquet dans une file d’attente ou le supprimer. Si un routeur tente de stocker un paquet dans une file d’attente complète, le paquet est abandonné. Les paquets abandonnés se produisent lorsque le trafic est transféré d’une interface rapide à une interface plus lente. Ceci est indiqué dans la formule Q = u / (1-u) où u est l'utilisation, et Q est la profondeur moyenne de la file d'attente (trafic aléatoire supposé). Ainsi, les niveaux d'utilisation élevés sur les liaisons produisent des profondeurs de file d'attente moyennes élevées, ce qui est une latence prévisible si vous connaissez la taille des paquets. Certains fournisseurs de rapports réseau indiquent que vous pouvez commander moins de bande passante et payer moins cher pour votre WAN. Cependant, des implications de latence apparaissent lorsque vous exécutez des liaisons WAN à 95 % d'utilisation. En outre, lorsque les réseaux sont migrés vers VoIP, les administrateurs réseau peuvent avoir besoin de modifier leurs politiques et d'exécuter des liaisons WAN avec une utilisation d'environ 50 %.
Lorsqu’un paquet est abandonné, le protocole de couche supérieure peut forcer une retransmission du paquet. Si plusieurs paquets sont abandonnés, un trafic de nouvelle tentative excessif peut en résulter. Ce type de réaction peut entraîner des sauvegardes sur les périphériques plus bas dans la ligne. Afin de résoudre ce problème, vous pouvez définir différents degrés de seuils.
La principale mesure utilisée pour l’utilisation du réseau est l’utilisation des interfaces. Utilisez les formules décrites dans ce tableau selon que la connexion que vous mesurez est bidirectionnelle non simultanée ou bidirectionnelle simultanée :
Notation | Description |
---|---|
ΔifInOctets | Delta (ou différence) entre deux cycles d'interrogation qui collectent l'objet ifInOctets snmp, qui représente le nombre d'octets entrants du trafic. |
ΔifOutOctets | Le delta entre deux cycles d'interrogation qui collectent l'objet ifOutOctets snmp qui représente le nombre d'octets sortants du trafic. |
ifSpeed | Vitesse de l'interface telle que rapportée dans l'objet ifSpeed snmp. Notez que ifSpeed peut ne pas refléter fidèlement la vitesse d'une interface WAN. |
Les connexions LAN partagées ont tendance à être bidirectionnelles non simultanées, principalement parce que la détection des conflits exige qu’un périphérique écoute avant de transmettre. Les connexions WAN sont généralement bidirectionnelles simultanées, car la connexion est point à point ; les deux périphériques peuvent transmettre et recevoir en même temps puisqu’ils savent qu’il n’y a qu’un seul autre périphérique qui partage la connexion.
Puisque les variables MIB II sont stockées en tant que compteurs, vous devez prendre deux cycles d'interrogation et calculer la différence entre les deux (d'où le Delta utilisé dans l'équation).
Pour les supports semi-duplex, utilisez cette formule pour l'utilisation de l'interface :
(ΔifInOctets + ΔifOutOctets) * 8 * 100
—
(nombre de secondes en Δ) * ifSpeed
Pour les supports bidirectionnels simultanés, le calcul de l'utilisation est plus complexe. Par exemple, avec une connexion série T-1 complète, la vitesse de la ligne est de 1,544 Mbits/s. Cela signifie qu’une interface T-1 peut à la fois recevoir et transmettre 1,544 Mbits/s pour une bande passante possible combinée de 3,088 Mbits/s.
Lorsque vous calculez la bande passante de l'interface pour les connexions bidirectionnelles simultanées, vous pouvez utiliser cette formule dans laquelle vous prenez la plus grande des valeurs entrantes et sortantes et générez un pourcentage d'utilisation :
max(ΔifInOctets, (ΔifOutOctets) * 8 * 100
—
(nombre de secondes en Δ) * ifSpeed
Cependant, cette méthode masque l'utilisation de la direction qui a la valeur la moins élevée et fournit des résultats moins précis. Une méthode plus précise consiste à mesurer séparément l'utilisation des entrées et des sorties, par exemple :
Utilisation des entrées = ΔifInOctets *8 * 100
—
(nombre de secondes en Δ) * ifSpeed
ET
Utilisation de la sortie = ΔifOutOctets *8 * 100
—
(nombre de secondes en Δ) * ifSpeed
Bien que ces formules soient quelque peu simplifiées, elles ne prennent pas en compte les frais généraux associés à un protocole particulier. Il existe des formules plus précises pour gérer les aspects uniques de chaque protocole. Par exemple, la RFC 1757 contient des formules d'utilisation Ethernet qui prennent en compte la surcharge de paquets. Cependant, l'équipe de haute disponibilité a constaté que les formules générales présentées ici peuvent être utilisées de manière fiable sur les interfaces LAN et WAN dans la plupart des cas.
Comme indiqué précédemment, la planification des capacités est le processus par lequel vous déterminez les besoins futurs en ressources réseau probables pour éviter un impact sur les performances ou la disponibilité des applications stratégiques de l'entreprise. Reportez-vous à la section Gestion des capacités et des performances : Livre blanc sur les meilleures pratiques pour plus d'informations sur ce sujet.
Une analyse proactive des pannes est essentielle à la gestion des performances. Le même type de données collectées pour la gestion des performances peut être utilisé pour l'analyse proactive des pannes. Cependant, le timing et l'utilisation de ces données sont différents entre la gestion proactive des pannes et la gestion des performances.
La gestion proactive des pannes est la manière dont le système de gestion de réseau idéal peut atteindre les objectifs que vous avez définis. La relation avec la gestion des performances passe par la ligne de base et les variables de données que vous utilisez. La gestion proactive des pannes intègre des événements personnalisés, un moteur de corrélation d'événements, des rapports d'incidents et l'analyse statistique des données de base afin de lier la gestion des pannes, des performances et des changements dans un système d'administration réseau idéal et efficace.
Lorsque l'interrogation des données de performances est normalement effectuée toutes les 10, 15 ou même 30 minutes, la reconnaissance d'une condition de panne doit être beaucoup plus courte. Une méthode de gestion proactive des pannes est l'utilisation d'alarmes RMON et de groupes d'événements. Vous pouvez définir des seuils sur vos périphériques qui ne sont pas sondés par des périphériques externes, de sorte que les seuils sont beaucoup plus courts. Une autre méthode, qui n'est pas traitée dans ce document, est l'utilisation d'un système de gestion distribué qui permet l'interrogation au niveau local avec agrégation des données dans un gestionnaire de gestionnaires.
Le seuil est le processus dans lequel vous définissez des points d'intérêt dans des flux de données spécifiques et générez des événements lorsque des seuils sont déclenchés. Utilisez vos données de performances réseau pour définir ces seuils.
Il existe plusieurs types de seuils, dont certains sont plus applicables à certains types de données. Les seuils ne s'appliquent qu'aux données numériques, donc convertissez les données textuelles en valeurs numériques discrètes. Même si vous ne connaissez pas toutes les chaînes de texte possibles pour un objet, vous pouvez quand même énumérer les chaînes « intéressantes » et affecter toutes les autres chaînes à une valeur définie.
Il existe deux classes de seuils pour les deux classes de données numériques : continu et discret. Les seuils continus s'appliquent aux données de série temporelle ou continue telles que les données stockées dans des compteurs ou des jauges SNMP. Des seuils distincts s'appliquent aux objets énumérés ou à toute donnée numérique distincte. Les objets booléens sont des valeurs énumérées avec deux valeurs : vrai ou faux. Des données distinctes peuvent également être appelées données d'événements car les événements marquent la transition d'une valeur à l'autre.
Les seuils continus peuvent déclencher des événements lorsque l'objet de série temporelle dépasse la valeur spécifiée du seuil. La valeur de l'objet monte au-dessus du seuil ou tombe en dessous. Il peut également être utile de fixer des seuils distincts pour les seuils de hausse et de baisse. Cette technique, appelée mécanisme d'hystérésis, permet de réduire le nombre d'événements générés à partir de cette classe de données. Le mécanisme d'hystésis vise à réduire le volume d'événements générés par les seuils sur des données de séries chronologiques à variation rapide. Ce mécanisme peut être utilisé avec n'importe quelle technique de seuil sur les données de séries chronologiques.
Le volume des événements est réduit par une alarme générée pour suivre la valeur d'un objet. Des seuils en hausse et en baisse sont affectés à cette alarme. L'alarme n'est déclenchée que lorsque le seuil ascendant est franchi. Une fois ce seuil franchi, une alarme ascendante n'est pas générée de nouveau tant que le seuil descendant n'est pas franchi. Et le même mécanisme empêche la génération de seuils en baisse jusqu'à ce que le seuil en hausse soit de nouveau franchi. Ce mécanisme peut réduire considérablement le volume des événements et n'élimine pas les informations requises pour déterminer si une panne existe.
Les données de séries temporelles peuvent être représentées sous forme de compteurs, où chaque nouveau point de données est ajouté à la somme des points de données précédents, ou sous forme de jauge, où les données sont représentées sous forme de taux sur un intervalle de temps. Il existe deux formes différentes de seuils continus applicables à chaque type de données : seuils absolus continus et seuils relatifs continus. Utiliser des seuils absolus continus avec des jauges et des seuils relatifs continus avec des compteurs.
Afin de déterminer les valeurs de seuil de votre réseau, procédez comme suit :
Sélectionnez les objets.
Sélectionnez les périphériques et les interfaces.
Déterminez les valeurs de seuil pour chaque objet ou objet/type d'interface.
Déterminez la gravité de l'événement généré par chaque seuil.
Il faut faire un travail considérable pour déterminer les seuils à utiliser sur quels objets (et pour quels périphériques et interfaces). Heureusement, si vous avez collecté une base de données de performances, vous avez déjà effectué une grande partie de ce travail. En outre, NSA et le programme HAS (High Availability Service) peuvent formuler des recommandations qui vous aident à définir des objets et à créer des plages. Cependant, vous devez adapter ces recommandations à votre réseau particulier.
Comme vous avez collecté des données de performances pour le réseau, le programme HAS vous recommande de regrouper vos interfaces par catégories. Cela simplifie la définition des seuils car vous devrez peut-être déterminer des seuils pour le type de support de chaque catégorie plutôt que pour chaque périphérique et objet de ce périphérique. Par exemple, vous devez définir différents seuils pour les réseaux Ethernet et FDDI. On pense généralement que vous pouvez exécuter des réseaux FDDI à une utilisation plus proche de 100 % que vous ne pouvez le faire avec un segment Ethernet partagé. Cependant, l'Ethernet en mode full duplex peut être exécuté beaucoup plus près de l'utilisation à 100 %, car ils ne sont pas sujets aux collisions. Vous pouvez définir vos seuils de collisions très bas pour les liaisons bidirectionnelles simultanées, car vous ne devriez jamais voir de collision.
Vous pouvez également considérer la combinaison de l'importance de l'interface et de la catégorie/gravité du type de seuil. Utilisez ces facteurs pour définir la priorité de l'événement et, par conséquent, l'importance de l'événement et son attention par le personnel d'exploitation du réseau.
Le regroupement et la catégorisation des périphériques et des interfaces réseau ne peuvent être trop soulignés. Plus vous pouvez regrouper et catégoriser les événements de seuil, plus vous pouvez intégrer facilement les événements de seuil dans votre plate-forme de gestion de réseau. Utilisez la ligne de base comme ressource principale pour cette information. Reportez-vous à la section Gestion des capacités et des performances : Livre blanc sur les meilleures pratiques pour plus d'informations.
L'organisation doit disposer d'un système de gestion de réseau mis en oeuvre capable de détecter les valeurs de seuil définies et de générer des rapports sur les valeurs pour des périodes spécifiées. Utilisez un système de gestion de réseau RMON qui peut archiver des messages de seuil dans un fichier journal pour une révision quotidienne ou une solution de base de données plus complète qui permet de rechercher des exceptions de seuil pour un paramètre donné. Les informations doivent être mises à la disposition du personnel et du responsable des opérations du réseau de manière continue. La mise en oeuvre de la gestion du réseau doit inclure la capacité à détecter les pannes ou les retraits logiciels/matériels, la fiabilité de l'interface, le CPU, l'utilisation des liaisons, les erreurs de file d'attente ou de tampon, le volume de diffusion, les transitions de porteuse et les réinitialisations d'interface.
Les mesures des opérations réseau constituent un dernier domaine de la gestion proactive des pannes qui chevauche la gestion des performances. Ces indicateurs fournissent des données précieuses pour l'amélioration des processus de gestion des pannes. Au minimum, ces indicateurs devraient comprendre une ventilation de tous les problèmes survenus au cours d'une période donnée. La ventilation doit inclure des informations telles que :
Nombre de problèmes qui se produisent par priorité d'appel
Temps minimum, maximum et moyen de fermeture dans chaque priorité
Répartition des problèmes par type de problème (matériel, panne logicielle, configuration, alimentation, erreur utilisateur)
Temps de fermeture pour chaque type de problème
Disponibilité par groupe de disponibilité ou SLA
Fréquence à laquelle vous avez satisfait ou manqué les exigences SLA
Le centre d'assistance dispose souvent d'un système de création de rapports permettant de générer des indicateurs ou des rapports. L'utilisation d'un outil de surveillance de la disponibilité est un autre moyen de recueillir ces données. Les indicateurs généraux devraient être disponibles tous les mois. L'amélioration des processus basée sur la discussion devrait être mise en oeuvre afin d'améliorer les exigences des contrats de niveau de service manqués ou afin d'améliorer la façon dont certains types de problèmes sont traités.
Les indicateurs de rendement fournissent le mécanisme par lequel une organisation mesure les facteurs de succès critiques.
Ce document pourrait être un concept d'exploitation officiel pour la gestion du réseau ou un énoncé moins formel des fonctions et objectifs requis. Cependant, le document doit aider le gestionnaire de réseau à mesurer le succès.
Ce document est la stratégie de gestion du réseau de l'organisation et doit coordonner les objectifs commerciaux généraux (non quantitatifs) des opérations réseau, de l'ingénierie, de la conception, des autres unités commerciales et des utilisateurs finaux. Cette orientation permet à l'entreprise de former des activités de planification à long terme pour la gestion et l'exploitation du réseau, qui incluent le processus de budgétisation. Il fournit également des conseils pour l'acquisition d'outils et le chemin d'intégration requis pour atteindre les objectifs de gestion du réseau, tels que les contrats de niveau de service.
Ce document stratégique ne peut pas se concentrer trop étroitement sur la gestion de problèmes spécifiques de réseau, mais sur les éléments importants pour l'organisation dans son ensemble, qui incluent les questions budgétaires. Exemple :
Identifier un plan complet avec des objectifs réalisables.
Identifier chaque service/application d'entreprise nécessitant une assistance réseau.
Identifier les mesures basées sur les performances nécessaires pour mesurer le service.
Planifier la collecte et la distribution des données de mesure des performances.
Identifier l'assistance requise pour l'évaluation du réseau et les commentaires des utilisateurs.
Avoir des objectifs de niveau de service documentés, détaillés et mesurables.
Afin de documenter correctement les SLA, vous devez définir complètement les métriques d'objectif de niveau de service. Cette documentation doit être mise à la disposition des utilisateurs pour évaluation. Il fournit une boucle de rétroaction pour s’assurer que l’organisation de gestion de réseau continue à mesurer les variables nécessaires pour maintenir le niveau de contrat de service.
Les contrats de niveau de service sont des documents « actifs » car l'environnement commercial et le réseau sont dynamiques par nature. Ce qui fonctionne aujourd'hui pour mesurer un SLA pourrait devenir obsolète demain. Ce n'est que lorsqu'ils établissent une boucle de rétroaction des utilisateurs et agissent sur ces informations que les opérations réseau peuvent maintenir les numéros de haute disponibilité requis par l'organisation.
Cette liste inclut des éléments tels que l'intervalle d'interrogation, la surcharge de gestion du réseau, les seuils de déclenchement possibles, l'utilisation ou non de la variable comme déclencheur d'un déroutement et l'analyse des tendances utilisée pour chaque variable.
Ces variables ne se limitent pas aux mesures nécessaires pour atteindre les objectifs de niveau de service mentionnés ci-dessus. Au minimum, elles doivent inclure ces variables : état du routeur, état du commutateur, informations de routage, données spécifiques à la technologie, utilisation et délai. Ces variables sont interrogées périodiquement et stockées dans une base de données. Des rapports peuvent ensuite être générés à partir de ces données. Ces rapports peuvent aider le personnel chargé des opérations et de la planification de la gestion du réseau de la manière suivante :
Les problèmes réactifs peuvent souvent être résolus plus rapidement grâce à une base de données historique.
Les rapports sur les performances et la planification des capacités nécessitent ce type de données.
Les objectifs de niveau de service peuvent être mesurés en fonction de celui-ci.
Le personnel de gestion du réseau doit organiser des réunions pour passer périodiquement en revue des rapports spécifiques. Cela fournit des commentaires supplémentaires, ainsi qu'une approche proactive des problèmes potentiels du réseau.
Ces réunions devraient comprendre à la fois du personnel opérationnel et du personnel de planification. Les planificateurs ont ainsi l'occasion de recevoir une analyse opérationnelle des données de référence et des tendances. Il met également l'état-major opérationnel dans la boucle pour une partie de l'analyse de planification.
Les objectifs de niveau de service constituent un autre type d'élément à inclure dans ces réunions. À mesure que des seuils objectifs sont approchés, le personnel de gestion du réseau peut prendre des mesures pour éviter de manquer un objectif et, dans certains cas, ces données peuvent être utilisées comme justification budgétaire partielle. Les données peuvent indiquer où les objectifs de niveau de service vont être violés si des mesures appropriées ne sont pas prises. En outre, comme ces objectifs ont été définis par les services et les applications de l'entreprise, ils sont plus faciles à justifier sur une base financière.
Mener ces examens toutes les deux semaines et tenir une réunion analytique plus approfondie toutes les six à douze semaines. Ces réunions vous permettent d'aborder des questions à court et à long terme.
Une analyse de simulation implique la modélisation et la vérification des solutions. Avant d'ajouter une nouvelle solution au réseau (soit une nouvelle application, soit une modification de la version de Cisco IOS), documentez certaines des alternatives.
La documentation de cette analyse inclut les principales questions, la méthodologie, les ensembles de données et les fichiers de configuration. Le point principal est que l'analyse de simulation est une expérience que quelqu'un d'autre devrait être capable de recréer avec les informations fournies dans le document.
Cette documentation inclut une bande passante WAN supplémentaire et un tableau de coûts qui permet d'augmenter la bande passante pour un type de liaison particulier. Ces informations permettent à l'entreprise de réaliser combien de temps et d'argent il en coûte pour augmenter la bande passante. La documentation officielle permet aux experts en performances et en capacités de découvrir comment et quand améliorer les performances, ainsi que le calendrier et les coûts d'une telle entreprise.
Examiner périodiquement cette documentation, peut-être dans le cadre de l'examen du rendement trimestriel, afin de s'assurer qu'elle demeure à jour.
La seule façon d'atteindre les objectifs du système de gestion de réseau idéal est d'intégrer activement les composants de la gestion des performances dans le système. Cet objectif doit inclure l'utilisation de mesures de disponibilité et de temps de réponse liées à un système de notification lorsque les seuils sont dépassés. Il devrait inclure l'utilisation d'une ligne de base pour la planification des capacités qui aurait des liens avec un modèle heuristique pour le provisionnement et les rapports d'exception. Il peut comporter un moteur de modélisation ou de simulation intégré qui permet de mettre à jour le modèle en temps réel et de fournir un niveau de planification et de dépannage par le biais de simulations logicielles.
Bien qu'une grande partie de ce système puisse sembler un idéal impossible qui ne pourrait jamais être atteint, chacun des composants est aujourd'hui disponible. De plus, les outils d'intégration de ces composants existent également dans des programmes comme MicroMuse. Nous devons continuer à oeuvrer en faveur de cet idéal, car il est plus réaliste aujourd'hui que jamais.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
02-Dec-2013 |
Première publication |