Base de données Core : Techniques d'optimisation

Document created by RSA Information Design and Development on Feb 3, 2017
Version 1Show Document
  • View in full screen mode
  

Cette rubrique décrit les techniques d'optimisation de la base de données Security Analytics Core. La base de données Security Analytics Core est configurée pour gérer une grande variété de charges de travail par défaut. Cependant, comme n'importe quelle technologie de base de données, ses performances peuvent être très sensibles à la nature des données d'acquisition, et à la nature des recherches que l'utilisateur effectue dans la base de données.

Seuils

Les seuils sont une optimisation utile pouvant avoir un effet négatif sur la rapidité de renvoi des résultats dans l'outil de navigation de Security Analytics. Les seuils sont appliqués à l'appel des valeurs. Pour plus d'informations sur l'appel des valeurs, reportez-vous à la section Requêtes.

Le seuil définit la limite de la quantité de base de données récupérée du disque afin de produire un nombre. Pour la plupart des requêtes, le nombre de sessions correspondant à la clause where est très grand. Par exemple, la sélection de tous les événements du log pour une heure d'exécution à 30 000 événements par seconde correspond à 108 000 000 sessions.

RSA a introduit la fonction de seuil après avoir constaté que dans la plupart des cas où un nombre de sessions est nécessaire, aucun résultat précis n'est fourni avant la toute dernière session. Par exemple, en observant les 20 premières adresses IP présentes sur la dernière heure, il n'est pas très important de savoir si le rapport indique qu'une valeur IP correspond à 10 000 000 ou 10 000 001 sessions exactement. Ici, l'estimation est plutôt juste. Dans ces scénarios, nous pouvons faire une estimation de la valeur du nombre retourné lorsque notre nombre dépasse le paramètre de seuil. Si le seuil est atteint, le nombre restant est estimé et les résultats sont triés sur la base des chiffres estimatifs, si nécessaire.

Clauses complexes Where

La période nécessaire pour que la base de données {SA}} Core produise un résultat dépend de la complexité de la requête. Les requêtes qui correspondent directement aux index présents sur le méta peuvent être résolues rapidement, mais il est très facile d'écrire des requêtes qui ne peuvent pas être résolues rapidement. Parfois, les requêtes qui ne peuvent être renvoyées rapidement peuvent être traitées par la base de données et l'index Core différemment pour produire des résultats beaucoup plus satisfaisants pour le client.

Il est utile de connaître le coût relatif de chaque partie de la clause where. Une clause d'un coût élevé prend plus de temps à exécuter. Dans le tableau suivant, les opérateurs de requête sont classés en fonction de leur coût relatif, du plus bas au plus élevé.

                               
OpérationCost
exists, !existsConstante
=, !=Logarithme en termes de nombre de valeurs uniques pour la clé méta, linéaire en termes de nombre d'éléments uniques qui correspondent à une expression de plage
<, >, <=, >=Logarithme en termes de recherche de valeurs uniques, mais plus susceptibles d'être linéaires puisque l'expression correspond à une large plage de valeurs
begins, ends, containsLinéaire en termes de nombre de valeurs uniques pour la clé méta
regexLinéaire en termes de nombre de valeurs uniques pour la clé méta avec un coût par valeur élevé

AND et OR

Lors de la construction d'une clause where, gardez à l'esprit que la construction de nombreux termes avec l'opérateur AND peut avoir un effet bénéfique sur les performances d'une requête. Plus vous pouvez utiliser de critères pour réduire le nombre de sessions correspondant à la clause where, plus vous réduisez le travail de la requête. En revanche, chaque clause OR crée un nombre plus important de sessions à traiter pour chaque requête.

En règle générale, plus les clauses AND sont présentes dans la requête, plus vite elle s'exécute, mais plus il y a de clauses OR dans la requête, plus elle est lente à s'exécuter.

Exemple d’utilisation : Correspondance avec un grand sous-réseau

Il est courant pour les utilisateurs de construire des requêtes qui tentent d'inclure ou d'exclure un sous-réseau de classe A. Ce type de requête est courant car les utilisateurs tentent d'inclure ou d'exclure certaines grandes parties de leur réseau interne de leur procédure d'enquête.

Le moteur de recherche a du mal à résoudre cette requête en utilisant uniquement les index ip.src ou ip.dst. Le problème provient du fait qu'une clause where comme celle-ci :

 ip.src = 10.0.0.0/8 

Doit en réalité être interprétée en :

 ip.src = 10.0.0.0 || ip.src = 10.0.0.1 || ip.src = 10.0.0.2 || ... || ip.src = 10.255.255.255 

Ainsi, l'index peut avoir à créer une clause where, avec plus de 16 millions de termes.

La solution à ce problème est d'utiliser le service Decoder pour marquer les réseaux communs pertinents à l'aide de règles d'application. Par exemple, vous pouvez créer un méta avec une règle d'application qui ressemble à celle-ci :

 name=internal rule="ip.src = 10.0.0.0/8" order=3 alert=network 

Cette règle crée un méta sur le réseau des clés méta avec la valeur interne pour n'importe quelle adresse IP sur le réseau 10.0.0.0/8.

La clause where pourrait être exprimée comme suit :

 network = "internal" 

En supposant qu'il y ait un index de niveau de valeur sur le réseau méta, l'index n'a pas besoin de développer cette requête de manière complexe, et les sessions correspondant au sous-réseau souhaité sont mises en correspondance très rapidement.

Exemple d’utilisation : Correspondance de sous-chaînes

L'utilisation des opérateurs begins, ends, contains et regex dans une clause where peut être très lente s'il y a un grand nombre de valeurs uniques pour la clé méta. Chacun de ces opérateurs est évalué indépendamment par rapport à chaque valeur unique. Par exemple, si l'opérateur est regex, le regex doit être exécuté de façon indépendante par rapport à chaque valeur unique.

Pour contourner ce problème, la stratégie la plus efficace consiste à réorganiser le méta pour que l'utilisateur n'ait pas besoin d'utiliser une correspondance de sous-chaînes.

Par exemple, si les utilisateurs tentent de trouver le nom d'hôte dans une URL, quelque part dans la session. Les utilisateurs peuvent écrire une clause where comme suit :

 url contains 'www.rsa.com' 

Dans ce scénario, il est probable que la clé méta url contienne une valeur unique pour chaque session qui a été capturée par le Decoder, et renferme donc un grand nombre de valeurs uniques. Dans ce cas, l'opération contains est lente.

La meilleure approche est d'identifier la partie du méta que vous tentez de faire correspondre, et de déplacer la correspondance vers l'analyseur de contenu.

Par exemple, s'il y a un méta en cours de génération pour chaque URL, un analyseur peut aussi décomposer l'URL en ses composants constitutifs. Par exemple, si le Decoder génère le méta d'URL avec la valeur http://www.rsa.com/security_analytics, il est également possible de générer un méta alias.host avec la valeur www.rsa.com. Les requêtes peuvent être effectuées en utilisant :

 alias.host = 'www.rsa.com' 

Comme l'opérateur de chaîne n'est plus nécessaire, la requête est beaucoup plus rapide.

Sauvegardes d'index

L'index Core est subdivisé par points de sauvegarde, également connus sous le nom de tranches. Lorsque l'index est sauvegardé, toutes ses données sont vidées sur le disque, et cette partie de l'index est uniquement accessible en lecture seule. Les sauvegardes ont deux fonctions :

  • Chaque point de sauvegarde représente un lieu où l'index pourrait être récupéré en cas de panne de courant.
  • Une sauvegarde périodique peut faire en sorte que la partie de l'index qui est activement mise à jour ne soit pas plus grande que la mémoire vive (RAM).

Les points de sauvegarde ont pour effet de diviser l'index en segments indépendants qui ne se chevauchent pas. Lorsqu'une requête doit traiter plusieurs points de sauvegarde, il faut réexécuter les parties de la requête et en fusionner les résultats. Au final la requête prend plus de temps à s'exécuter.

Par défaut, pour les installations Security Analytics 10.5 ou de version ultérieure, une sauvegarde est effectuée sur l'index Core chaque fois que 600 000 000 sessions sont ajoutées à la base de données. Cet intervalle est défini par le paramètre de configuration d'index save.session.count. Pour plus d’informations, voir le Nœuds de configurations d'index.

Pour les versions antérieures de Security Analytics Core, ou les systèmes ayant été mis à niveau à partir de versions Security Analytics antérieures à la version 10.5, utilisez un planning de sauvegarde basé sur l'heure pour sauvegarder l'index toutes les 8 heures. Vous pouvez voir l'intervalle d'enregistrement actuel en utilisant l'éditeur du planificateur dans l'interface utilisateur de Security Analytics pour le service. L'entrée par défaut ressemble à ce qui suit :

 hours=8 pathname=/index msg=save 

En ajustant l'intervalle, vous pouvez contrôler la fréquence de création des sauvegardes.

Effets de l'augmentation de l'intervalle de sauvegarde

En augmentant l'intervalle de sauvegarde, les points de sauvegarde sont créés moins fréquemment, ce qui réduit le nombre de points de sauvegarde. Cela a un effet positif sur les performances des requêtes, car les tranches ne sont pas traitées par les requêtes. En revanche, cela fait moins de données à analyser par les requêtes.

Il y a néanmoins des inconvénients à augmenter l'intervalle. Premièrement, le Concentrator est plus susceptible d'atteindre la limite de valueMax définie sur l'un des index. Deuxièmement, le temps de restauration en cas d'arrêt ou de panne de courant forcée est accru. Et troisièmement, le taux d'agrégation peut en pâtir si la tranche d'index devient trop grande pour tenir dans la mémoire.

Effets de la réduction de l'intervalle de sauvegarde

En réduisant l'intervalle de sauvegarde, il est possible d'éviter d'atteindre les limites de ValueMax tout en conservant un index de valeur complète pour le méta qui contient un grand nombre de valeurs uniques. La diminution de l'intervalle de sauvegarde a un impact négatif sur les performances des requêtes, puisque plusieurs tranches sont créées.

Utilisation de Value Max

La limitation maximale de la valeur peut être frustrante pour les clients qui veulent indexer tous les méta uniques possibles. Malheureusement, ce n'est pas possible de manière générale. Les clés méta peuvent avoir des données aléatoires arbitraires partout sur Internet, et toutes les valeurs uniques ne peuvent pas être indexées.

Cependant, il est possible de contourner certaines limites de valeur maximale en utilisant des index de niveau clé au lieu des index de valeur. Les index de niveau clés ne sont pas influencés par value max.

Il est possible d'utiliser la vue Navigation sur une clé méta indexée au niveau clé. La base de données utilise des index de niveau de valeur dans la clause where lorsque cela est possible, mais l'analyse de la base de métadonnées permet de résoudre des valeurs uniques pour l'appel de valeurs. Cette approche fonctionne bien lorsque la clause where fournit un filtre efficace pour limiter la recherche à la portée d'un petit nombre de sessions, peut-être moins de 10 000 sessions.

Dans les cas où la valeur maximale est atteinte, les utilisateurs peuvent effectuer une analyse de base de données sur leurs requêtes afin de s'assurer qu'aucune valeur pertinente n'a été abandonnée. Cette fonctionnalité est accessible dans le client Investigator 9.8 via le menu du clic-droit de la vue Navigation. Bien que l'analyse de la base de métadonnées prend beaucoup de temps, elle permet au client de vérifier qu'il n'y a pas d'omissions dans son rapport.

Mise en parallèle des charges de travail

Si le client utilise de nombreux rapports, vérifiez qu'il exploite efficacement les options d'exécution parallèle disponibles dans Reporting Engine. De même, vérifiez que le nombre relatif à max.concurrent.queries est approprié pour le matériel.

La vue Security Analytics Navigator a la capacité d'exécuter les composants de la vue Investigator en parallèle, ce qui peut avoir un impact significatif sur la performance perçue du service Security Analytics Core.

Reconstruction d'index

Dans de rares cas, un service Core pourrait bénéficier d'une reconstruction d'index. Exemples :

  • Le service Security Analytics Core dispose de tranches d'index créées par une très vieille version du produit et n'a pas déployé les données en plus de six mois.
  • L'index a été configuré de manière incorrecte, et le client veut ré-indexer tous les méta avec une nouvelle configuration d'index.
  • La charge du trafic sur le service Core était très légère et l'intervalle de sauvegarde était grande, ce qui générait des tranches inutiles.

Dans chacun des cas, une reconstruction d'index peut améliorer les performances. Pour cela, vous devez envoyer le message reset avec le paramètre index=1 au dossier /decoder sur un Decoder, le dossier /concentrator sur un Concentrator, ou le dossier /archiver sur un Archiver.

Il faut savoir qu'une réindexation complète prend des jours pour s'exécuter sur un Concentrator entièrement chargé, et peut-être des semaines sur un Archiver plein.

Évolution de la rétention

Il existe plusieurs façons d'améliorer la conservation de la base de données Security Analytics Core. La rétention fait référence à la période de stockage des données dans la base de données.

La première étape dans l'analyse de la rétention est de déterminer quelle partie de la base de données est le facteur limitant en termes de rétention. Les bases de données de paquets, les bases de métadonnées et les bases de données de sessions fournissent les statistiques packet.oldest.file.time, meta.oldest.file.time et session.oldest.file.time dans le dossier /database/stats indiquant l'âge du fichier le plus ancien de la base de données. L'index fournit les statistiques /index/stats/time.begin pour indiquer l'heure de session la plus ancienne dans l'index.

Augmentation de la rétention des paquets et des métadonnées

Le principal mécanisme pour augmenter la rétention sur ces bases de données est d'ajouter plus de stockage. Si l'ajout de plus de stockage au service Security Analytics Core n'est pas possible, alors il peut être nécessaire d'utiliser les options de compression sur les bases de données de paquets et les bases de métadonnées en vue de réduire la quantité de données écrites sur chaque base de données.

Si la rétention des métadonnées présente un problème, vous pouvez éventuellement supprimer le contenu inutile du Decoder générant les métadonnées. De nombreux analyseurs génèrent des méta que le client n'a pas besoin de stocker à long terme.

Augmentation de la rétention de l'index

La rétention de l'index est généralement plus longue que celle des bases de données, mais avec un index personnalisé complexe, la rétention d'index peut être plus courte. Habituellement, il est plus facile de supprimer les index de niveau de valeur inutiles dans la configuration personnalisée, mais vous pouvez également remplacer certains index de niveau de valeur par défaut par des index de niveau clé.

Il est aussi possible de faire évoluer l'index en ajoutant un stockage d'index supplémentaire. Cependant, le stockage de l'index doit être étendu en utilisant des disques SSD uniquement.

Évolution à l'horizontale

À partir de la version 10.3, les Concentrators et les Archivers ont la capacité de se regrouper à l'aide de l'agrégation de groupes. L'agrégation de groupes permet à un seul Decoder de fournir des sessions à plusieurs Concentrators ou Archivers avec une charge équilibrée. L'agrégation de groupes permet à la charge applicative de la requête et de l'agrégation d'être répartie sur un large pool de matériel de manière arbitraire.

Pour plus d’informations, consultez la section Agrégation de groupes dans le Guide de déploiement.

Regroupement des charges applicatives

La base de données Security Analytics Core fonctionne beaucoup mieux lorsque tous les utilisateurs du système travaillent dans la même zone de la base de données. Étant donné que la base de données est alimentée en données par le Decoder sur la base du premier entré, premier sorti, les données dans la base de données sont généralement regroupées en fonction de l'heure de capture et de stockage. Par conséquent, la base de données fonctionne mieux lorsque tous les utilisateurs travaillent sur la même période de données.

Il n'est pas toujours possible pour tous les utilisateurs de travailler sur la même période simultanément. La base de données Security Analytics Core peut gérer ce cas d'utilisation, mais l'opération est lente, car elle doit alterner entre plusieurs périodes différentes dans la mémoire vive (RAM). Il est impossible d'avoir toutes les périodes de temps dans la RAM en même temps. Généralement, moins de 1 % de la base de données et moins de 10 % de l'index occupent la RAM.

Pour que Security Analytics puisse être efficace pour le client, il est important que le client organise ses utilisateurs en groupes qui ont tendance à travailler sur les mêmes plages horaires. Par exemple, les utilisateurs qui font un suivi quotidien des données les plus récentes peuvent constituer un groupe d'utilisateurs. Un autre groupe peut se former avec les utilisateurs qui émettent des requêtes par la suite dans le cadre d'une procédure d'enquête. Ou encore un autre groupe d'utilisateurs créent des rapports sur de grandes périodes de temps. Tenter de servir tous les groupes à partir d'une seule base de données peut générer une frustration et une longue attente avant que les résultats ne soient produits. Toutefois, si les différents cas d'utilisation peuvent être répartis sur plusieurs services Concentrator, les performances seraient bien mieux perçues. Dans ce cas, il peut être bénéfique d'utiliser plusieurs services Concentrator avec moins de RAM et CPU plutôt qu'un seul Concentrator volumineux et coûteux destiné à répondre à tous les besoins.

Période de cache

Prenons par exemple cette séquence d'événements :

  1. À 9h00, l'utilisateur « kevin » se connecte à un Concentrator et demande un rapport sur la dernière heure de collecte.
  2. Le Concentrator récupère les rapports pour la période comprise entre 08:00 et 09:00.
  3. À 09h02, l'utilisateur « scott » se connecte au même Concentrator et demande également un rapport sur la dernière heure de collecte.
  4. Le Concentrator récupère les rapports pour la période comprise entre 08:02 et 09:02.

Notez que même si les deux utilisateurs consultent les rapports à des plages de temps rapprochées, le travail effectué par le Concentrator pour produire les rapports pour Kevin ne permet pas de renvoyer les rapports à Scott, puisque les plages horaires sont légèrement différentes. Le Concentrator doit recalculer la plupart des rapports pour Scott.

Le paramètre cache.window.minutes sur le nœud / sdk vous permet d'optimiser cette situation. Lorsqu'un utilisateur se connecte, le point dans le temps représentant les données les plus récentes pour la collecte se déplace uniquement vers l'avant par incréments du nombre de minutes définies par ce paramètre.

Par exemple, supposons que le paramètre sdk/config/cache.window.minutes indique 10. Réévaluer l'action ci-dessus modifie la séquence des événements.

  1. À 9h00, l'utilisateur « kevin » se connecte à un Concentrator et demande un rapport sur la dernière heure de collecte.
  2. Le Concentrator récupère les rapports pour la période comprise entre 08:00 et 09:00.
  3. À 09h02, l'utilisateur « scott » se connecte au même Concentrator et demande également un rapport sur la dernière heure de collecte.
  4. Le Concentrator récupère les rapports pour la période comprise entre 08:00 et 09:00.
  5. À 09h00, l'utilisateur « scott » recharge les rapports sur la dernière heure de collecte.
  6. Le Concentrator récupère les rapports pour la période comprise entre 08:10 et 09:10.

Le rapport retourné à l'étape 3 tombe dans la période de cache, il est donc retourné instantanément. Cela donne à Scott l'impression que le Concentrator est très rapide.

Ainsi, de plus grands paramètres cache.window améliorent les performances perçues, même avec de petits retards qui n'empêchent pas de rendre les dernières données disponibles pour la recherche.

Limites de temps

Lorsqu'une requête est en cours d'exécution sur la base de données Security Analytics Core pour une longue durée, le service Core consacre de plus en plus de temps CPU et RAM à cette requête pour qu'elle se termine plus rapidement. Cela peut avoir un impact négatif sur d'autres requêtes et sur l'agrégation. Pour éviter que les utilisateurs avec des privilèges inférieurs utilisent plus de ressources que celles allouées par leur part du service Core, il est judicieux de limiter la durée d'exécution des requêtes par les utilisateurs normaux.

You are here
Table of Contents > Techniques d'optimisation

Attachments

    Outcomes