Base de données Core : Nœuds de configuration de la base de données

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 nœuds de configuration de la base de données. Les nœuds de configuration de la base de données suivants font partie des éléments de configuration de la base de données les plus avancés qui ne changent pas fréquemment pour la base de données Security Analytics Core.

packet.dir, meta.dir, session.dir

Il s'agit de l'entrée de configuration primaire pour chaque base de données (également connue comme niveau Hot). Elle contrôle l'endroit du système de fichiers où les bases de données respectives sont stockées. Cette entrée de configuration appréhende une syntaxe complexe pour spécifier un nombre important de répertoires comme les emplacements de stockage.

Syntaxe de configuration :

 config-value = directory, { ";" , directory } ; directory = path, [ ( "=" | "==" ) , size ] ; path = ? linux filesystem path ? ; size = number size_unit ; size_unit = "t" | "TB" | "g" | "GB" | "m" | "MB" ; number = ? decimal number ? ; 

Exemple :

 /var/netwitness/decoder/packetdb=10 t;/var/netwitness/decoder0/packetdb=20.5 t 

Les valeurs de taille sont facultatives : Si elles sont définies, elles indiquent la taille totale maximum des fichiers stockés à cet endroit avant le déploiement des bases de données. Si la taille n'est pas définie, la base de données n'est pas déployée automatiquement mais sa taille peut être gérée à l'aide d'autres mécanismes.

L'utilisation de = ou == est prépondérante. Le comportement par défaut des bases de données consiste à créer automatiquement des répertoires lorsque le service Core démarre. Cependant, ce comportement peut être modifié à l'aide de la syntaxe ==. En cas d'utilisation de ==, le service ne crée pas de répertoires. Si les répertoires n'existent pas lorsque le service démarre, celui-ci ne peut pas commencer le traitement. Cela apporte de la résilience au service face à des systèmes de fichiers manquants ou non montés lorsque l'hôte démarre.

Si vous modifiez la taille d'un répertoire en cours d'utilisation, la modification prend effet immédiatement dans le cas où la taille choisie est supérieure. Si la taille est inférieure, elle est ignorée si elle plus de 10 % inférieure à la taille actuelle. Cela permet d'éviter les erreurs de frappe qui engendreraient une perte énorme de données. Par exemple, si la base de données de paquets est configurée pour 12 TB et qu'une erreur de frappe indique 12 GB, la base de données devrait supprimer plus de 11 To de données pour arriver à 12 Go. En pratique, la base de données ignore le paramètre de 12 GB et consigne un avertissement afin que l'erreur soit repérée rapidement. Ainsi, si la taille indiquée est correcte et varie de plus de 10 % par rapport à la taille existante, la seule façon de la prendre en compte est de redémarrer le service. Lorsqu'il redémarre, le service assume que la taille est correcte et ajuste la base de données à la nouvelle taille en déployant les données les plus anciennes jusqu'à ce que la nouvelle taille soit atteinte. Si vous souhaitez ajuster la taille à la baisse de plus de 10 % sans redémarrer le service, vous devez modifier la taille plusieurs fois, de moins de 10 % chaque fois. Consultez les logs de service pour savoir quand la base de données s'est ajustée à la nouvelle taille, car la taille totale de la base de données ne s'ajuste que lorsque le dernier ficher écrit a été fermé.

Si de nouveaux répertoires sont ajoutés ou supprimés (séparés par des points-virgules), la modification n'est effective que lorsque le service redémarre.

packet.dir.warm, meta.dir.warm, session.dir.warm

Ces paramètres sont facultatifs et sont utilisés pour le niveau de stockage Warm dans Archiver. Par défaut, ils sont vides et inutilisés. S'ils sont configurés, ils suivent le même format et comportement que packet.dir, meta.dir et session.dir (voir packet.dir, meta.dir et session.dir ci-dessus). Lorsqu'ils sont configurés, le fichier le plus ancien du niveau Hot passe au niveau Warm lorsqu'il n'y a plus d'espace disponible dans le niveau Hot.

packet.dir.cold, meta.dir.cold, session.dir.cold

Ces paramètres sont facultatifs et sont utilisés pour déplacer les fichiers du niveau de système de stockage Hot ou Warm vers le répertoire de niveau Cold spécifié. En fait, ce paramètre n'est autre qu'un répertoire, sans spécificateur de taille. Toutefois, le nom du chemin défini dispose de quelques spécificateurs de format que vous pouvez utiliser pour nommer le répertoire en y incluant la date des données.

 %y = The year of the data being moved to the cold tier %m = The month of the data being moved to the cold tier %d = The day of the data being moved to the cold tier %h = The hour of the data being moved to the cold tier %##r = A block of time within a day. So %12r would create two blocks, 00 and 01. 00 for all data in the AM, 01 for all PM data 

Paramètre fourni à titre d'exemple :

 packet.dir.cold = /var/netwitness/archiver/database1/alldata/cold-storage-%y-%m-%d-%8r 

Pour le paramètre ci-dessus, si un fichier log de base de données est sur le point d'être déplacé vers le stockage à froid et qu'il a été créé le 2014-03-02 15:00:00, il sera déplacé vers le répertoire suivant de niveau Cold :

 /var/netwitness/archiver/database1/alldata/cold-storage-2014-03-02-01 

Expliquons le dernier nombre 01. Le spécificateur %8r sépare les heures de la journée en 24 / 8 = 3 parties. Les huit premières heures de la journée sont en mode bloc 00, soit 12 h 00 à 8 h 00. Les huit heures suivantes vont de 8 h 00 à 16 h 00 et sont attribuées en mode bloc 01. Les données déplacées vers le stockage à froid ont été créées à 15h00 : il s'agit donc du bloc 01. Le spécificateur de format %r est utile pour sauvegarder les fichiers avec une granularité comprise entre un jour %d et une heure %h. Le répertoire de stockage Cold est créé à la demande et défini par le déplacement des données lorsque les spécificateurs de format sont utilisés.

La possibilité d'ajouter une date au chemin de données est simplement une commodité ajoutée pour la sauvegarde et la restauration. C'est une façon de baliser les données à l'aide d'une date comprise dans le chemin.

packet.file.size, meta.file.size, session.file.size

Permet de contrôler la taille des fichiers créés dans chaque base de données. Généralement, il n'est pas nécessaire de modifier ces valeurs car les valeurs par défaut fonctionnent bien. Ce paramètre prend effet immédiatement pour les fichiers qui suivent.

packet.files, meta.files, session.files

Ce paramètre contrôle le nombre de fichiers que la base de données conserve ouverts. Vous pouvez augmenter cette valeur pour améliorer les performances. Toutefois, le système d'exploitation impose une limite générale dans le nombre de fichiers que le service peut conserver ouverts. Si cette limite est dépassée, une erreur est signalée et le service ne fonctionne pas. Ce paramètre prend effet immédiatement.

Dans Security Analytics 10.6 et versions supérieures, la valeur par défaut pour les packet.files, meta.files et session.files est auto et le service gère le nombre de fichiers ouverts en fonction des critères suivants :

  1. Nombre de collections
  2. Quantité de mémoire système

Lorsque le nombre est défini sur auto, il est dynamique et il s'affiche dans les logs lorsqu'il change. Pour Security Analytics 10.6, RSA recommande de définir cette valeur sur auto et de ne pas la remplacer par un nombre spécifique. 

packet.free.space.min, meta.free.space.min, session.free.space.min

Ce paramètre fournit une limite de sécurité en termes d'espace disponible minimum sur les chemins spécifiés par les répertoires packet.dir, meta.dir et session.dir, respectivement. Ce paramètre est utilisé pour empêcher le service de manquer d'espace dans l'éventualité où d'autres programmes occuperaient l'espace réservé à chacune des bases de données. Ce paramètre prend effet immédiatement.

packet.index.fidelity, meta.index.fidelity

Ce paramètre contrôle la fréquence à laquelle les emplacements d'ID de paquets et les emplacements d'ID de méta sont indexés. Ce paramètre peut être augmenté pour réduire la quantité d'espace nécessaire à chaque fichier nwindex de paquet ou de méta, mais l'augmentation de ce paramètre réduit la vitesse à laquelle chaque paquet individuel ou élément méta peut être localisé. Ce paramètre prend effet immédiatement.

La base de données de sessions ne dispose pas de paramètre de fidélité car elle ne génère pas de fichiers d'index.

packet.integrity.flush, meta.integrity.flush, session.integrity.flush

Ce paramètre contrôle si la base de données force un fonctionnement synchronisé sur le système de fichiers lorsque l'écriture d'un fichier est terminée. La valeur par défaut est sync, ce qui signifie que lorsqu'un fichier est fermé, il y aura un délai significatif pour que les données soient écrites sur un stockage non volatile. Il peut être nécessaire de définir cette valeur sur normal afin que le taux d'écriture reste supérieur, en particulier sur un Decoder. Ce paramètre prend effet à la création de fichier suivante. Ainsi, l'on peut s'attendre à une synchronisation de plus si la valeur vient de passer à normal.

Si des rejets de paquets se produisent et que la valeur packet.integrity.flush est définie sur sync, définissez-la sur normal et surveillez. Conservez les paramètres de la session et de vidage des méta sur sync. Si le problème de rejet des paquets persiste, définissez les trois valeurs sur normal et surveillez.

packet.write.block.size, meta.write.block.size, session.write.block.size

La taille de bloc représente la quantité de données allouée à la fois au sein de chaque fichier de base de données. Des blocs de plus grande taille peuvent proposer des débits et taux de compression plus élevés, et peuvent améliorer la vitesse à laquelle les éléments sont récupérés de la base de données sous forme séquentielle. Cependant, des blocs de grande taille ont un effet négatif sur la vitesse de lecture aléatoire des éléments de paquets et méta compressés. Ce paramètre prend effet immédiatement.

packet.compression, meta.compression

Ces paramètres contrôlent si les bases de données compressent les données. La compression réduit la quantité de stockage nécessaire pour chaque base de données, mais elle peut avoir un effet négatif majeur sur la vitesse à laquelle les éléments sont écrits dans la base de données, et la vitesse à laquelle les éléments sont récupérés de la base de données. Les modifications prennent effet immédiatement à la prochaine création de fichier.

À partir de la version 10.4 de Security Analytics, les valeurs valides pour ce paramètre sont gzip, bzip2, lzma ounone. gzip est l'algorithme utilisé de préférence avec la compression car il propose un bon équilibre entre performances et économies d'espace. bzip2 et lzma permettent de meilleures économies d'espace mais l'impact sur la vitesse est significatif et ils ne devraient être utilisés que pour les faibles vitesses de réception, et lorsque l'espace de stockage est précieux.

packet.compression.level, meta.compression.level

Vous pouvez utiliser ces paramètres pour affiner encore le comportement des algorithmes de compression. Ils n'ont aucun effet lorsque la compression est désactivée. Les valeurs valides se situent entre 0 et 9. La valeur par défaut de zéro indique que le logiciel choisit le meilleur paramètre pour la vitesse et la compression. Les valeurs entre 1 et 9 sont utilisées comme échelle à ajuster entre performances (1) et compression (9). La valeur 9 donne généralement la meilleure compression pour un algorithme donné, mais avec les plus mauvaises performances. Le meilleur paramètre se situe vers le milieu, ce qui correspond à la valeur choisie par 0.

hash.algorithm

Ce paramètre contrôle le hachage des fichiers de base de données. La valeur par défaut est none, c'est-à-dire qu'aucun hachage n'est effectué. Les valeurs valides sont none, sha256, sha1 ou md5. Les fichiers de base de données peuvent être hachés pour fournir la preuve qu'ils n'ont pas été manipulés depuis leur fermeture. Le hachage prend du temps et lorsqu'il est activé, il a un impact sur les performances de réception. Cette modification prend effet immédiatement.

hash.databases

Ce paramètre sélectionne les bases de données qui seront hachées. Les valeurs valides sont session, meta et packet, et elles sont séparées par une virgule lors du hachage de plusieurs bases de données. Cette modification prend effet immédiatement.

hash.dir

Ce paramètre est généralement vide, ce qui signifie que le fichier de hachage est créé dans le même répertoire que le fichier de base de données qui a été haché. Si ce paramètre est défini, le fichier de hachage est écrit dans le répertoire spécifié. Il peut être utilisé comme une forme de stockage à écriture unique pour la résilience contre la manipulation du hachage.

Les fichiers de hachage sont des fichiers XML de petite taille contenant le hachage encodé au format hex, ainsi que les métadonnées sur le fichier de base de données qui a été haché.

You are here
Table of Contents > Configuration avancée de la base de données > Nœuds de configuration de la base de données

Attachments

    Outcomes