Dimensionnement des bases de données

Dans l'idéal, il est souhaitable de réaliser le dimensionnement des bases de données avant l'installation de Client Security. Si nécessaire, les bases de données peuvent être redimensionnées après l'installation.

Client Security utilise quatre bases de données SQL Server :

  • la base de données de rapports de SQL Server 2005 Reporting Services ;
  • la base de données de collecte (ou base de données OnePoint) ;
  • la base de données de rapports (ou base de données SystemCenterReporting) ;
  • la base de données WSUS (facultatif).

Après avoir installé Client Security, décidé de la méthode de déploiement des agents Client Security et déployé ceux-ci, vous commencerez à accumuler des données dans la base de données de collecte et, plus tard, dans la base de données de rapports. Il convient donc de définir la taille appropriée de ces bases de données en fonction du nombre d'agents Client Security que vous déployez et de la durée pendant laquelle vous souhaitez conserver les données dans la base de données de rapports.

Le tableau suivant décrit les valeurs de dimensionnement par défaut de ces bases de données.

Base de données Taille par défaut des données Taille par défaut des journaux Croissance automatique

Collecte (OnePoint)

15 gigaoctets (Go) de données

20 % des données

Non pris en charge

Rapports (System Center Reporting)

1 Go de données

50 % des données

Non pris en charge

Base de données ReportServer

Environ 30 mégaoctets (Mo) de données

Variable

Oui

Base de données ReportServerTempDB

Variable

Variable

Oui

WSUS

Variable

1 Mo

Oui

Durant l'installation du serveur, vous définissez les tailles des bases de données de collecte et de rapports. L'Assistant d'installation définit les tailles de journaux par défaut. Il est important de noter que la valeur Croissance automatique pour ces deux bases de données est définie sur Aucune, car la croissance automatique n'est pas prise en charge par MOM.

La base de données de collecte doit posséder une taille suffisante pour héberger les données recueillies pendant 10 jours, sans arriver à saturation. Ainsi, la procédure DTS (Data Transformation Services) peut-elle s'exécuter deux fois. Les données sont nettoyées (supprimées) de la base de données de collecte tous les quatre jours, mais pas avant leur transfert vers la base de données de rapports avec une tâche DTS. Par conséquent, les données résident dans la base de données de collecte pendant cinq jours avant d'être nettoyées de la base de données. Si, pour une raison quelconque, la tâche DTS échoue, un espace correspondant à 10 jours de données offre un espace de sauvegarde approprié.

Il est important de noter que les bases de données nécessitent de l'espace libre pour effectuer certaines actions. La base de données de collecte (ou base de données OnePoint) nécessite de conserver jusqu'à 40 % d'espace libre pour permettre aux tâches de maintenance de s'exécuter correctement. Si ces 40 % d'espace libre ne sont pas conservés, les tâches de maintenance telles que la réindexation peuvent échouer. Pour plus d'informations sur la taille approximative prévue pour la base de données de collecte en fonction du nombre d'ordinateurs gérés, reportez-vous à la section Facteurs de performances de disque de Conséquences sur les ressources système serveur.

La taille par défaut définie par l'installation de serveur pour la base de données de rapports est 1 Go. Vous devez ajuster cette valeur en fonction du nombre d'ordinateurs gérés de votre organisation et de la durée de rétention des données souhaitée. Pour plus d'informations sur la taille approximative prévue pour la base de données de rapports en fonction du nombre d'ordinateurs gérés et des valeurs de rétention de données, reportez-vous à la section Facteurs de performances de disque de Conséquences sur les ressources système serveur.

Plusieurs facteurs peuvent affecter la croissance des bases de données Client Security :

  • le nombre d'agents Client Security déployés ;
  • le nombre d'analyses effectuées ;
  • le type d'analyse effectué ;
  • la fréquence des analyses ;
  • la fréquence des événements d'épidémie.

Le tableau suivant décrit le nombre d'événements et d'alertes généré pour les situations standard diverses.

Action Nombre d'événements par agent Client Security

Analyse anti-programmes malveillants

Deux : un pour le début et un pour la fin de l'analyse.

Menace détectée

Deux : un pour l'événement de détection et un pour l'événement correspondant à l'action entreprise pour chaque menace détectée.

Analyses d'évaluation de l'état de la sécurité (SSA)

Un

Vulnérabilité SSA détectée

Un pour chaque vulnérabilité de score moyen ou élevé

Mise à jour des définitions

Un

Mise à jour de stratégie

Un

Évaluation de l'état

Un

Le clic sur le bouton Analyser maintenant de la console Microsoft Forefront Client Security Management Console provoque au total quatre événements par agent Client Security (deux événements pour l'analyse anti-programmes malveillants, un événement pour l'analyse SSA et un événement pour la mise à jour de définitions déclenchée par le bouton Analyser maintenant). En outre, chaque analyse anti-programmes malveillants programmée provoquera par défaut trois événements (deux événements pour l'analyse anti-programmes malveillants et un événement pour le comportement par défaut de mise à jour de définitions avant l'analyse).

Les analyses SSA peuvent potentiellement produire beaucoup plus d'événements que celui déclenché par l'analyse, chaque vulnérabilité de score moyen ou supérieur produisant un événement. Un agent Client Security obsolète avec des mises à jour peut potentiellement créer un grand nombre d'événements. En multipliant ceci par le nombre d'agents Client Security nécessitant des mises à jour, vous comprendrez avec quelle rapidité les bases de données de collecte et de rapports peuvent croître.

Les alertes sont déclenchées en fonction du niveau d'alerte configuré pour l'ordinateur géré au travers de la stratégie Client Security et de la sévérité de la menace découverte. Chaque alerte sera également stockée dans les bases de données et provoquera un accroissement de la taille des bases de données. Les alertes ont une taille plus importante que les événements mais se produisent moins fréquemment. Pour plus d'informations sur les liaisons entre les niveaux d'alerte et la sévérité des menaces, consultez Utilisation des alertes dans le Guide d'administration de Client Security (http://go.microsoft.com/fwlink/?LinkId=86813).

La durée de conservation des données dans la base de données de rapports dépend du nombre d'agents Client Security déployés, du volume des événements et des alertes configurés pour l'envoi par les agents Client Security, de la quantité d'espace disque disponible et de votre tolérance quant à la durée du nettoyage des données.

Vous pouvez calculer la croissance approximative future de votre base de données de rapports en utilisant les nombres d'événements indiqués dans la section précédente, Facteurs de croissance de base de données, et en les multipliant par le nombre d'ordinateurs gérés. Multipliez la valeur résultante par la taille moyenne d'événement et d'alerte de la section Facteurs de performances de disque de Conséquences sur les ressources système serveur.

La valeur par défaut pour la rétention des données dans la base de données de rapports est 395 jours. Après avoir été conservées dans la base de données pendant 395 jours, les données sont supprimées par une procédure stockée SQL Server créée par MOM. Pour modifier la valeur de rétention des données, vous devez modifier les paramètres de la procédure stockée. Pour plus d'informations sur la modification de la rétention de données dans la base de données de rapports (SystemCenterReporting), consultez l'article 887016 de la base de connaissances (http://go.microsoft.com/fwlink/?LinkId=86925).

Bb418778.note(fr-fr,TechNet.10).gifRemarque :
La réduction de la valeur de rétention des données après le transfert des données vers la base de données de rapports provoque la suppression des données lors de l'exécution suivante de la tâche de nettoyage. Celle-ci pourrait faire en sorte que cette tâche dure plus longtemps que la durée normale et dépasse son délai d'attente. Pour empêcher la tâche de nettoyage de dépasser son délai d'attente en raison du volume de données déjà présentes dans la base de données, il est recommandé de modifier la valeur de nettoyage de manière incrémentielle, par petites étapes, jusqu'à atteindre la valeur souhaitée.

Si la taille de vos bases de données de rapports devient trop importante pour le disque sur lequel elles résident, vous pouvez les déplacer à l'aide des procédures décrites dans l'article 224071 de la base de connaissances (http://go.microsoft.com/fwlink/?LinkId=87257). La version minimum de SQL Server 2005 requise pour Client Security est SQL Server 2005 Service Pack 1 (SP1). Il existe un problème connu de détachement et rattachement des bases de données SQL Server 2005 Service Pack 1. L'article de la base de connaissances 922804 (http://go.microsoft.com/fwlink/?LinkId=87279) décrit le problème et la solution à ce problème.

La rétention de données affecte la taille comme les performances des base de données des serveurs de collecte et de rapports. Les données sont déplacées de la base de données de collecte (base de données OnePoint) ou la base de données de rapports (System Center Reporting) pour le stockage à long terme via une tâche DTS SQL Server. Cette tâche s'exécute chaque jour à 01 h 00 et est plus qu'une simple copie; pour le stockage des données et l'analyse à long terme des tendances, les données sont lues depuis la base de données de collecte et insérées dans la base de données de rapports, enregistrement par enregistrement. Plus les données historiques seront accumulées dans la base de données de rapports et plus la tâche DTS sera longue.

En général, avec 2 000 ordinateurs gérés, la transaction DTS avec 395 jours de données dans la base de données de rapports devrait prendre environ deux heures. Avec 5 000 ordinateurs gérés, la transaction DTS devrait prendre environ trois heures et avec 10 000 ordinateurs gérés, la transaction DTS devrait prendre de quatre à six heures.

L'utilisation de SQL Server Enterprise Edition avec 8 Go de mémoire vive (ou davantage) et l'option AWE (Address Windowing Extensions) activée permet d'accroître de manière significative l'efficacité et la vitesse de la transaction DTS. Au cours des tests, l'activation de l'option AWE a réduit la durée de la transaction DTS avec 10 000 ordinateurs gérés et 395 jours de données de près de 50 %. Pour plus d'informations sur SQL Server Enterprise Edition avec l'option AWE, reportez-vous à la section ayant trait à l'activation de la mémoire AWE pour SQL Server (http://go.microsoft.com/fwlink/?LinkId=86918).

Bb418778.note(fr-fr,TechNet.10).gifImportant :
AWE n'est pas pris en charge dans SQL Server 2005 Standard Edition.
Bb418778.note(fr-fr,TechNet.10).gifImportant :
Windows Server 2003 Standard Edition prend en charge 4 Go de mémoire vive maximum. Pour tirer pleinement parti de l'option AWE de SQL Server 2005 avec Client Security et plus de 4 Go de mémoire vive, vous devez disposer de Windows Server 2003 Enterprise Edition ou Windows Server 2003 Datacenter Edition.

La durée des transactions DTS est fortement influencée par le matériel sur lequel s'exécute SQL Server. Le tableau suivant offre des recommandations pour le matériel en ce qui concerne les valeurs de rétention de données et le nombre d'ordinateurs gérés.

Les valeurs du tableau suivant correspondent uniquement au serveur hébergeant la base de données de rapports. Il est vivement recommandé de déployer les composants Client Security sur une topologie prise en charge différente d'un serveur unique, si vous devez gérer plus de 2 500 ordinateurs clients.

Ordinateurs gérés Édition de SQL Server Processeur Mémoire (en Go) Valeur de nettoyage

Jusqu'à 1 000

Standard ou Enterprise

Un double noyau

1

395 jours

1,000–2,000

Standard ou Enterprise

Un double noyau

2

395 jours

2,000–5,000

Enterprise

Deux double noyau

4

395 jours

5,000–10,000

Enterprise

Deux double noyau

4

180 jours

5,000–10,000

Enterprise

Deux double noyau

8

395 jours

Bb418778.note(fr-fr,TechNet.10).gifRemarque :
Pour 5 000 à 10 000 ordinateurs gérés avec seulement 4 Go de mémoire sur l'ordinateur exécutant SQL Server, la valeur de nettoyage est définie sur 180 jours en raison de la mémoire limitée disponible pour l'utilisation par SQL Server. Cet ensemble de données est fourni pour illustrer l'importance de l'augmentation de la mémoire disponible pour l'utilisation par SQL Server en activant l'option AWE.

Outre l'option SQL Server AWE décrite dans la section précédente, avec un grand nombre d'ordinateurs gérés, les ordinateurs exécutant SQL Server utilisés par Client Security peuvent tirer parti d'une option de réglage de la mémoire disponible dans Windows Server 2003. Le commutateur /3GB est une option ajoutée au fichier Boot.ini des ordinateurs exécutant Windows Server 2003. Il modifie la manière dont la mémoire virtuelle est allouée entre les processus en mode noyau et les processus en mode utilisateur exécutés sur le serveur. En temps normal, Windows utilise un espace d'adressage de 4 Go, quelle que soit la quantité de mémoire vive du système. Parmi ceux-ci, 2 Go sont alloués au processus en mode noyau et 2 Go aux processus en mode utilisateur. L'utilisation du commutateur /3GB modifie cette allocation et alloue 1 Go aux processus en mode noyau et 3 Go aux processus en mode utilisateur. Pour plus d'informations sur le commutateur /3GB, reportez-vous à l'article ayant trait à l'activation du commutateur de démarrage /3GB dans Windows (http://go.microsoft.com/fwlink/?LinkId=87335).

Afficher: