Base de données Core : Stockage de base de données hiérarchisé

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

Cette rubrique décrit le stockage de base de données hiérarchisé et émet des recommandations pour le stockage hiérarchisé Hot, Warm et Cold.

À 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 Hot, qui est le stockage le plus rapide disponible sur le service Archiver.

Remarque : Tous les services utilisent le niveau Hot par défaut.

Le niveau suivant dit Warm est généralement moins cher et plus lent, tel qu'un stockage rattaché au réseau. Le niveau Warm contient des données plus anciennes. L'âge dépend de la quantité de stockage qui est allouée au niveau Hot et du taux d'acquisition moyen. Lorsque le niveau Hot atteint l'utilisation maximale, la progression normale est de déplacer les données les plus anciennes du niveau Hot vers le niveau Warm. 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 (Hot ou Warm). Cependant, il peut y avoir un impact sur les performances lors de l'accès aux données au niveau Warm par rapport au niveau Hot, car les temps d'accès au niveau Warm sont généralement plus lents.

En plus des niveaux Hot et Warm, il existe également un niveau Cold. Le niveau Cold est uniquement utilisé comme zone de transit pour la sauvegarde hors ligne. Les services de Security Analytics Core n’accèdent pas aux données du niveau Cold. Les services Security Analytics Core déplacent les données les plus anciennes vers le niveau Cold 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 Cold doivent être gérées en dehors des services Security Analytics Core via des scripts ou d'autres processus.

Attention : Si le niveau Cold est plein parce que les processus externes ne suppriment pas les données à temps, le service Security Analytics 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 Cold, 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 Warm, il est préférable, pour des raisons de performance, de définir le répertoire de niveau Cold 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 Cold, 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 Cold, 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 Hot (par défaut), Hot et Warm ou tous les trois (HotWarm et Cold). Tous les services doivent utiliser le niveau Hot. Vous ne pouvez pas configurer un service pour n'utiliser que le niveau Warm. Les données passent du niveau Hot au niveau Warm pour finir au niveau Cold. Vous pouvez également ignorer le niveau Warm pour passer directement du niveau Hot à Cold. Si le stockage Cold (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 Warm), 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 le déploiement, reportez-vous à Transfert asynchrone dans RollOver.

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