Téléchargez le rapport Magic Quadrant de Gartner, qui évalue 18 fournisseurs selon des critères tels que la vision complète et la capacité de mise en œuvre.
Selon Gartner, « le XDR est une technologie émergente capable de renforcer l'efficacité de la prévention, de la détection et de la neutralisation des menaces ».
As of May 14, 2024, Knowledge Base (KB) articles will only be published and updated in our new Trellix Thrive Knowledge space.
Log in to the Thrive Portal using your OKTA credentials and start searching the new space. Legacy KB IDs are indexed and you will be able to find them easily just by typing the legacy KB ID.
Meilleures pratiques en matière de performances et de stabilité de votre environnement ePolicy Orchestrator
Articles techniques ID:
KB90961
Date de la dernière modification : 13/07/2022
Environnement
ePolicy Orchestrator (ePO) 10.x , 5.9.x
Synthèse
Les meilleures pratiques suivantes sont divisées en trois groupes.
Contenu :
Cliquez pour développer la section que vous souhaitez afficher :
Evolutivité
Le nombre de systèmes gérés par votre serveur ePO détermine le nombre et la taille des gestionnaires de l'agent supplémentaires et des référentiels nécessaires. Il est conseillé d'utiliser un gestionnaire d'agents pour chaque tranche de 50 000 systèmes.
Pour les environnements gérant plus de 10 000 nœuds, l’installation d’ePO et de SQL sur des systèmes physiques est recommandée pour des performances optimales. La principale limitation est la performance SQL Server, en particulier les performances du disque. (IOPS-10 par seconde). Au fur et à mesure que le nombre de nœuds augmente, vous pouvez rencontrer des performances de disque plus lentes. Consultez le Guide d’installationdes recommandations pour le déploiement d’ePO sur les plates-formes virtuelles.
Pour installer le serveur ePO sur une machine virtuelle (VM) et résoudre ce problème de performances de disque, vous devez effectuer les actions suivantes :
Dédiez des disques physiques au serveur ePO dans la machine virtuelle.
Affectez une priorité aux processeurs au serveur ePO.
Recommandations pour le calibrage :
Moins de 10 000 systèmes managés : vous pouvez installer le serveur de commande d’achat et la base de données SQL sur le même serveur physique ou sur la même machine virtuelle. Vous pouvez utiliser la base de données Microsoft SQL Server Express si vous disposez de moins de 1 500 systèmes managés.
10000 à 25 000 systèmes managés : Installez les serveurs ePO et SQL sur des serveurs distincts.
25000:75 000 systèmes managés : installez ePO, un gestionnaire d'agents et des référentiels distribués, ainsi qu’un SQL Server physique distinct.
75 000 – 150000 + systèmes managés : Installez le serveur ePO, un SQL Server physique distinct, trois gestionnaires de l'agent et les référentiels distribués correctement placés.
Configuration système requise
Le nombre de systèmes managés détermine également la taille de serveur recommandée nécessaire à la gestion de ces systèmes. "
Remarque : La configuration requise décrite dans la documentation est la configuration minimale requise. Cependant, votre serveur ePO (ou SQL) devra peut-être être plus puissant que ces exigences. Cela dépend de la taille et de la complexité de l’environnement ou du nombre de produits installés et managés. Nous vous recommandons de dépasser les recommandations minimales, dans la mesure du possible.
processeur du serveur ePO
Nombre de nœuds
Cœurs de processeur
< 10000
4
De 10 000 à 25 000
4
De 25 000 à 75 000
8
De 75 000 à 150 000
8
150,000+ 16
16
mémoire du serveur ePO
Ajoutez 16 Go de RAM pour chaque 25 000 nœuds.
La machine virtuelle Java (JVM) exécute le serveur d’applications ePO. La JVM représente l’ensemble de mémoire que le serveur d’applications ePO peut utiliser. Les mesures décrivent l’utilisation du tas (objets d’exécution) et non du tas (métadonnées et objets de méthode locaux).
Remarque : Après avoir ajouté de la mémoire RAM supplémentaire à ePO, examinez l’allocation de JVM et apportez les modifications nécessaires pour augmenter l’allocation de JVM. Le paramètre de mémoire JVM se trouve dans le Registre Windows : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2. 0\MCAFEETOMCATSRV530\Parameters\Java\JvmMx.
Avant d’augmenter la mémoire d’allocation à la machine virtuelle JVM, assurez-vous que le système d’exploitation dispose de suffisamment de mémoire. Il doit conserver environ 10% des ressources mémoire disponibles. Pour plus d’informations sur les paramètres de mémoire recommandés pour JVM, reportez-vous à la section KB71516 - Memory allocated to the ePolicy Orchestrator Application Server needs to be increased .
SQL Server
La base de données SQL, où sont stockées les données du serveur ePO, ainsi que la SQL Server déterminent les performances de votre serveur ePO. Cette base de données est la principale façon d’être protégée par le serveur ePO. Les trois éléments qui ont un impact sur les performances de SQL sont les performances du processeur, de la RAM et du disque. Ces trois éléments contrôlent la réactivité du serveur ePO à partir d’un point de vue SQL. Nous vous recommandons de dépasser les recommandations minimales, dans la mesure du possible.
N’installez pas la base de données SQL du serveur ePO sur un SQL Server partagé si vous gérez plus de 25 000 nœuds. Le serveur ePO est censé effectuer des milliers de lectures et d’écritures sur le disque de la base de données SQL toutes les quelques secondes. Par conséquent, les performances peuvent être affectées de manière négative sur un SQL Server en surutilisation.
Vous pouvez partager votre environnement SQL entièrement organisé en clusters, redondant et managé de manière centralisée si les critères ci-dessous sont satisfaits :
La SQL Server partagée n’est pas déjà utilisée.
Votre serveur ePO gère moins de 25 000 nœuds.
Les autres fonctions de base de données SQL ne sont pas à l’origine de pics qui ralentissent la lecture et l’écriture de la base de données SQL du serveur ePO.
Si une solution antivirus, telle que VSE ou ENS, est installée sur le SQL Server hébergeant la base de données ePO, veillez à appliquer les exclusions AV requises. Ces exclusions empêchent les pertes de performances potentielles lors de l’analyse. Définissez ces exclusions pour les analyses à l’accès et toutes les analyses à la demande planifiées.
Référentiels distribués
Les référentiels distribués fonctionnent comme des partages de fichiers qui stockent et distribuent le contenu de sécurité pour vos systèmes clients managés. Utilisez-les pour vous aider à charger le serveur ePO lui-même. Le serveur ePO fait toujours Office de référentiel maître. Il conserve la copie principale de l’ensemble du contenu requis par vos agents et ePO, et réplique le contenu dans chacun des référentiels de votre environnement. Par conséquent, vos agents peuvent récupérer du contenu mis à jour à partir d’une source différente et plus proche.
SuperAgent type de référentiel est le type de référentiel distribué le plus efficace, car il peut être configuré pour utiliser LazyCaching . La fonctionnalité de mise en cache différée permet aux SuperAgents de récupérer des données du serveur ePO uniquement lorsqu’un nœud agent local le demande. La création d'une hiérarchie de SuperAgent et la mise en cache différée permettent d'économiser davantage de bande passante et de réduire le trafic sur le réseau étendu.
En règle générale, vous pouvez créer un référentiel pour chaque emplacement géographique de grande taille. Toutefois, vous devez éviter d’avoir trop ou trop peu de référentiels et de surcharger la bande passante de votre réseau.
Client : n’est pas conseillé d’ajouter un référentiel distribué sur un gestionnaire d'agents. Le gestionnaire d'agents met déjà en cache une copie du contenu du référentiel maître. Si un agent managé contacte le gestionnaire d'agents pour les packages logiciels, le gestionnaire d'agents récupère les package à partir du référentiel maître du serveur ePO.
Gestion des arborescence des systèmes
Dans la mesure du possible, utilisez Active Directory (AD) pour synchroniser la Arborescence des systèmes. Cette fonctionnalité permet de s’assurer que tous les systèmes de votre domaine sont soumis à la gestion ePO. Dans les paramètres de synchronisation AD, vous pouvez choisir de configurer Agent déploiement sur le système découvert lors de la synchronisation.
Cette fonctionnalité fonctionne tant que vous disposez d’une structure de AD parfaitement gérée. Si ce n’est pas le cas, vous vous retrouvez avec des systèmes ou des espaces réservés non managés dans votre Arborescence des systèmes. Ces systèmes ou espaces réservés non managés sont ceux qui ont été importés à partir de votre serveur AD, mais qui n’ont jamais reçu de McAfee Agent (MA). Vous pouvez filtrer les systèmes non managés dans vos rapports. Toutefois, il est beaucoup plus facile de s’assurer que votre environnement ePO inclut uniquement les systèmes managés. Supprimez régulièrement les systèmes non managés à l’aide d’une tâche serveur ePO.
Il est conseillé d’ajouter également l’agent de MA à votre image d’entreprise. L’ajout de MA au cours du processus de création d’images est une bonne stratégie de conformité. Cela permet de s’assurer que tous les nouveaux systèmes disposent d’un agent MA installé. Elle permet également de fournir une couverture de sécurité maximale pour tous les systèmes de votre environnement.
Remarque : Reportez-vous au Guide produit de l’MA pour connaître votre version de l'agent à installer sur une image virtuelle non persistante ou dans le mode d’infrastructure de postes de travail virtuels (VDI).
Instructions relatives à l’intervalle de communication Agent-serveur (ASCI)
Nombre de nœuds
Intervalle de communication agent-serveur recommandé
100–10,000
entre 60 et 120 minutes
10,000–50,000
120 à 240 minutes
50000 +
entre 240 et 360 minutes
Lors de la configuration du paramètre ASCI, la principale considération consiste à réduire la charge sur le serveur ePO à chaque communication à partir de chaque agent dans des environnements de plus grande taille.
Pour les organisations de moins de 10 000 nœuds, le paramètre ASCI par défaut n’est pas un problème à 60 minutes. Cependant, pour les organisations disposant de plus de 10 000 nœuds, définissez le paramètre par défaut de 60 minutes sur environ 3 à 4 heures. Pour les organisations disposant de plus de 60 000 nœuds, le paramètre ASCI est beaucoup plus important. Si votre serveur ePO ne présente pas de problèmes de performances, vous pouvez utiliser l’intervalle ASCI de quatre heures. En cas de problème de performances, envisagez d’augmenter votre intervalle ASCI à 6 heures, voire plus. Cette augmentation permet de réduire le nombre d’agents qui se connectent simultanément au serveur ePO et améliore les performances du serveur.
Mise en miroir de base de données-paramètres serveur
La fonctionnalité de mise en miroir de la base de données permet d’améliorer l’efficacité des recherches LDAP sur ePO et les gestionnaires de l'agent en relation avec les stratégies basées sur l’utilisateur. Cette fonctionnalité fonctionne avec la tâche de synchronisation LDAP. Lorsque la tâche de synchronisation LDAP est exécutée, elle extrait les informations des serveurs LDAP enregistrés et les stocke dans la base de données ePO.
Lorsqu’un client est configuré pour utiliser une stratégie basée sur l’utilisateur, le serveur ePO ou le gestionnaire d'agents doit effectuer une recherche LDAP. Cela permet de déterminer l’appartenance à un groupe de l’utilisateur pour voir si une stratégie basée sur l’utilisateur s’applique.
L’exécution de la requête LDAP peut prendre un certain temps. Ainsi, il est possible de réduire le temps de session et de provoquer des problèmes de connexion au maximum sur le gestionnaire d'agents. La mise en miroir de la base de données peut s’avérer utile dans cette situation.
Lorsque la fonctionnalité de mise en miroir de base de données est activée, le gestionnaire d'agents modifie les requêtes LDAP en requêtes de base de données SQL. Le gestionnaire d'agents suit le même algorithme que lorsque la fonctionnalité de mise en miroir de la base de données est désactivée. Cependant, au lieu d’interroger LDAP, il interroge les tables de base de données remplies par la tâche de synchronisation LDAP pour rechercher des informations sur les utilisateurs. La requête SQL pour les informations utilisateur se termine généralement plus rapidement que la recherche LDAP. Pour plus d’informations, voir KB84683-explication du fonctionnement de la fonctionnalité de mise en miroir de la base de données ePolicy Orchestrator.
Conservation des stratégies et des tâches-paramètres serveur
La conservation des stratégies et des tâches est une fonctionnalité de prévention de défaillance qui peut être activée avec les paramètres du serveur ePO. Activez cette fonctionnalité pour aider à préserver les données de configuration des stratégies et des tâches dans les rares cas où un problème fatal survient avec un extension de gestion spécifique.
Cette fonctionnalité doit être utilisée en plus de l’exécution des sauvegardes SQL et ePO recommandées :
Conservation de la base de données SQL
Vos bases de données ePO nécessitent une maintenance régulière pour stimuler les performances optimales et protéger vos données. Réalisez ces tâches de manière régulière, chaque semaine ou chaque jour. Ces tâches ne sont pas les seules tâches de maintenance disponibles. Pour plus d'informations sur les autres tâches de maintenance de votre base de données, consultez la documentation SQL Server.
Sauvegardez régulièrement la base de données SQL ePO et son journal des transactions. Si le serveur ePO doit être reconstruit ou restauré, les sauvegardes actuelles garantissent qu’une copie sûre est disponible.
Remarque : Le contenu référencé est uniquement disponible pour les utilisateurs de ServicePortal consignés. Pour afficher le contenu, cliquez sur le lien et connectez-vous lorsque vous y êtes invité.
Purgez les événements anciens à l'aide de tâches serveur. Purgez régulièrement les anciens événements, par exemple tous les événements de plus de trois mois, à l’aide de la tâche serveur purge des événements ePO pour réduire la croissance de la taille de la base de données. Pour plus d’informations, consultez la section KB76720 - How to identify why the ePolicy Orchestrator database is very large .
Utilisez le mode de récupération simple pour votre base de données. Le mode de récupération simple permet à SQL de gérer le journal des transactions pour vous, évitant ainsi la croissance du journal des transactions. Passez en revue les détails dans ce document Microsoft.
Planification d’exécution de tâche client maintenant et de tâche
Le serveur Apache présente une limitation de 245 connexions simultanées. Les scénarios suivants peuvent contribuer au nombre maximal de connexions atteintes sur le serveur ePO, ce qui entraîne une panne :
Tâches de déploiement de produits configurées pour s’exécuter trop fréquemment sur plusieurs systèmes
Utilisation de "tâche exécuter le client maintenant" sur un groupe de systèmes de grande taille (plus de 245)
Configuration d’un intervalle ASCI faible pour un environnement de plus grande taille
Configurez les planifications de tâche client de manière à ne pas surcharger la capacité des systèmes qui hébergent le contenu du référentiel. Par exemple, si une tâche client est affectée à tous les systèmes, assurez-vous d’inclure l’exécution aléatoire suffisante pour faire varier l’heure de début de la tâche sur le réseau. Une exécution aléatoire suffisante évite un problème de déni de service sur le serveur ePO ou le système hébergeant le référentiel distribué.
La fonctionnalité exécuter une tâche client maintenant n’est pas destinée à être utilisée à la place des tâches planifiées pour les déploiements de produits ou les projets de déploiement de produits. La fonctionnalité exécuter une tâche client maintenant est particulièrement utile pour exécuter une tâche spécifique sur un seul système ou un petit groupe de systèmes à la fois.
Gestion des comptes
Evitez d’utiliser le compte d’administrateur global pour la gestion quotidienne d’ePO.
La définition d’un utilisateur et l’affectation d’un ensemble d’autorisations pour chaque utilisateur de l’administrateur ePO améliorent la journalisation des audit. Il facilite également le suivi des modifications apportées par l’utilisateur.
Configurez au moins un autre compte d’administrateur global ePO avec le mot de passe stocké en toute sécurité pour empêcher le verrouillage d’ePO.
Dans le cas où le mot de passe administrateur est perdu, ePO Pre-Installation Auditor 2.0.0 vous permet de modifier votre mot de passe administrateur ePO. Vous êtes invité à entrer les informations du compte d’utilisateur de la base de données SQL Server pour terminer la réinitialisation du mot de passe. Pour plus d’informations, voir la section KB60112-Comment réinitialiser un mot de passe dans ePolicy Orchestrator 5.x.
Désactivez les connexions au lieu de supprimer les utilisateurs.
Dans ePO, tous les objets appartenant à un utilisateur sont supprimés lorsque le compte est supprimé d’ePO. Les objets détenus incluent des tâches serveur, car les tâches serveur s’exécutent dans le contexte d’autorisation de l’utilisateur qui les crée. Si ePO autorise le transfert de propriété pour les tâches serveur, les résultats de ces tâches serveur peuvent différer. Cela s’explique par le fait que les autorisations du propriétaire actuel peuvent ne pas correspondre aux autorisations de l’utilisateur qui a créé la tâche serveur. Pour plus d’informations, voir KB65775-comptes d’utilisateur supprimés d’ePolicy Orchestrator supprimez les tâches serveur associées créées par ces comptes.
Le contenu du présent article a été rédigé en anglais. En cas de divergences entre la version anglaise et sa traduction, la version en anglais prévaut. Certaines parties de ce contenu ont été traduites par le moteur de traduction automatique de Microsoft.
