Réglage de la base de données : Stockage de base de données hiérarchisé

Document created by RSA Information Design and Development on Apr 19, 2018
Version 1Show Document
  • View in full screen mode
 

Cette section décrit le stockage de base de données hiérarchisé et émet des recommandations pour le stockage hiérarchisé Chaud, Actif et Inactif.

À partir de la version 10.4, le service Archiver peut être configuré pour utiliser le stockage hiérarchisé. Le concept du stockage hiérarchisé consiste à placer les données les plus récentes sur un niveau Chaud, qui est le stockage le plus rapide disponible sur le service Archiver.

Tous les services utilisent le niveau Chaud par défaut.

Le niveau suivant dit Actif est généralement moins cher et plus lent, tel qu'un stockage rattaché au réseau. Le niveau Actif contient des données plus anciennes. L'âge dépend de la quantité de stockage qui est allouée au niveau Chaud et du taux d'acquisition moyen. Lorsque le niveau Chaud atteint l'utilisation maximale, la progression normale est de déplacer les données les plus anciennes du niveau Chaud vers le niveau Actif. Dans le cas d'une configuration correcte, cela se produit automatiquement et est transparent pour l'utilisateur final. L'accès aux requêtes et aux données s'effectue automatiquement, quel que soit le niveau (Chaud ou Actif). Cependant, il peut y avoir un impact sur les performances lors de l'accès aux données au niveau Actif par rapport au niveau Chaud, car les temps d'accès au niveau Actif sont généralement plus lents.

En plus des niveaux Chaud et Actif, il existe également un niveau Inactif. Le niveau Inactif est uniquement utilisé comme zone de transit pour la sauvegarde hors ligne. Les services NetWitness Core n'accèdent pas aux données du niveau Inactif. Les services NetWitness Core déplacent les données les plus anciennes vers le niveau Inactif et les considèrent comme étant abandonnées (le service n'utilisera plus les données). Ces données peuvent ensuite être sauvegardées sur un stockage à long terme, comme une bande, durant des mois, voire des années à des fins de restauration éventuelle, en fonction des besoins. La sauvegarde et la suppression ultérieure des données au niveau Inactif doivent être gérées en dehors des services NetWitness Core via des scripts ou d'autres processus.

Si le niveau Inactif est plein parce que les processus externes ne suppriment pas les données à temps, le service NetWitness Core peut ne plus réceptionner les nouvelles données jusqu'à ce que le problème soit corrigé.

Lors du déplacement des données du niveau Inactif, RSA recommande que le répertoire reste sur le même point de montage dans le nouvel emplacement. Par conséquent, si les fichiers proviennent du niveau Actif, il est préférable, pour des raisons de performance, de définir le répertoire de niveau Inactif sur le même système de fichiers. Cela s'explique par le fait que le service tente de déplacer simplement le fichier et le répertoire vers le niveau Inactif, ce qui est une opération quasiment instantanée sur le même système de fichiers. Si le déplacement échoue, l'action de secours consiste à copier les données au niveau Inactif, ce qui engendre plus de temps de traitement et provoque un conflit d'accès E/S supplémentaire sur le niveau à partir duquel il est copié.

Archiver

Les niveaux de stockage sont également utilisés par le service Archiver. Vous pouvez configurer le service Archiver pour utiliser uniquement le stockage Chaud (par défaut), Chaud et Actif ou tous les trois (Chaud, Actif et Inactif). Tous les services doivent utiliser le niveau Chaud. Vous ne pouvez pas configurer un service pour n'utiliser que le niveau Actif. Les données passent du niveau Chaud au niveau Actif pour finir au niveau Inactif. Vous pouvez également ignorer le niveau Actif pour passer directement du niveau Chaud à Inactif. Si le stockage Inactif (hors ligne) n'est pas configuré, les données les plus anciennes sont supprimées au dernier niveau configuré, ce qui est la procédure de fonctionnement standard.

Le déploiement classique du service Archiver définit une taille illimitée pour toutes les bases de données (packet.dir, meta.dir, session.dir, index.dir et éventuellement les variantes de niveau Actif), ce qui signifie que l'indicateur de taille n'est pas pris en compte ou mis à zéro. Cela permet aux bases de données et à l'index de croître sans limite. Au lieu que chaque base de données gère sa propre taille et se déploie uniquement lorsqu'elle dépasse la taille configurée, Archiver les déploie toutes en même temps à l'aide de la commande /index sizeRoll . Cela permet aux bases de données et à l'index de se déployer de manière cohérente. Pour plus d'informations sur la commande sizeRoll, reportez-vous à « Transfert asynchrone » dans Transfert .

Archiver est généralement configuré pour placer les bases de données d'index, les bases de données de sessions, les bases de métadonnées et les bases de données de paquets (log) sur le même volume, et non sur plusieurs volumes, comme pour le Concentrator ou le Decoder. Même si cela risque de causer plus de conflits d'accès E/S lorsqu'une lecture simultanée se produit sur plusieurs bases de données, le transfert permet malgré tout d'optimiser la rétention globale. Parce que toutes les bases de données sont sur le même volume, elles sont configurées pour se déployer conjointement, ce qui minimise les données orphelines. Les services Decoder et Concentrator sont configurés pour une vitesse maximale d'E/S, mais peuvent faire l'objet d'une mauvaise estimation du dimensionnement du volume.

Par exemple, si la base de données des sessions est trop grande, il peut y avoir suffisamment de stockage pour six mois de rétention, alors que la base des métadonnées et l'index n'auront que quatre mois de rétention. Parce que la base de données des sessions, la base des métadonnées et l'index sont étroitement liés, la période de rétention la plus courte pour les trois définit la période de conservation globale (dans ce cas, quatre mois). La conservation des bases de données individuelles est principalement affectée par des facteurs hors de contrôle, tels que le trafic capturé, les méta générés (analyseurs, feeds, règles) et le filtrage. Les bases de données sont facilement redimensionnées par un simple changement de configuration, mais cela implique généralement des changements au niveau du matériel et du système de fichiers pour ajuster les partitions, ce qui complique le redimensionnement dynamique. Archiver permet d'éviter ces problèmes en utilisant un seul volume pour tout, avec pour compromis un ralentissement de la vitesse d'E/S.

You are here
Table of Contents > Configuration basique de la base de données > Stockage de base de données hiérarchisé

Attachments

    Outcomes