Réglage des composants de base de données Client Security

Client Security utilise SQL Server pour les bases de données de collecte et de rapports. Lorsque vous choisirez l'édition de SQL Server et le matériel sur lequel elle devra s'exécuter, prenez les éléments suivants en considération.

Pour plus d'informations sur le réglage des performances de SQL Server, reportez-vous au guide ayant trait à l'analyse et au réglage pour les performances (http://go.microsoft.com/fwlink/?LinkID=85444) et aux 10 meilleures pratiques pour le stockage (http://go.microsoft.com/fwlink/?LinkId=85451).

Client Security prend en charge SQL Server 2005 Standard Edition et SQL Server 2005 Enterprise Edition.

La différence essentielle entre ces éditions est que SQL Server 2005 Enterprise Edition prend en charge une plus grande quantité de données. SQL Server 2005 Enterprise Edition a la capacité d'augmenter ses performances avec les bases de données de taille très importante en mettant en œuvre le partitionnement de table et d'index.

Pour la comparaison de ces éditions, reportez-vous à l'article ayant trait à la comparaison des fonctionnalités de SQL Server 2005 (http://go.microsoft.com/fwlink/?LinkId=85452).

Pour plus d'informations sur le partitionnement, reportez-vous à l'article ayant trait aux tables et index partitionnés dans SQL (http://go.microsoft.com/fwlink/?LinkId=85453).

Client Security prend en charge SQL Server Standard Edition pour un nombre d'ordinateurs gérés pouvant aller jusqu'à 3 000 machines. Pour gérer plus de 3 000 ordinateurs client, Client Security nécessite les capacités de partitionnement d'Enterprise Edition.

Client Security repose en grande partie sur SQL Server et il est important de prendre en compte les recommandations suivantes pour le réglage des performances de SQL Server.

Disque

Pour des performances maximales de lecture et d'écriture, ainsi qu'une réduction des conflits entre transactions de bases de données et accès aux fichiers système, il est généralement recommandé que les fichiers de données de SQL Server et les fichiers journaux de transactions soient placés sur des disques différents. Pour Client Security, il est recommandé de faire de même. Lors de l'installation de SQL Server, spécifiez les emplacements par défaut des fichiers de données et de journaux sur le serveur. L'installation de Client Security utilise ces chemins pour l'installation des bases de données de collecte et de rapports. Si nécessaire, les valeurs par défaut des bases de données et fichiers journaux SQL Server peuvent être modifiées après l'installation de SQL Server.

Pour modifier l'emplacement des bases de données et des fichiers journaux SQL Server
  1. Démarrez Microsoft SQL Server Management Studio.

  2. Dans Explorateur d'objets, cliquez avec le bouton droit sur NOMSERVEUR, puis sur Propriétés.

  3. Dans la boîte de dialogue Propriétés du serveur, sous Sélectionner une page, cliquez sur Paramètres de base de données.

  4. Sous Emplacements de la base de données par défaut, entrez les chemins des emplacements des données et des journaux, puis cliquez sur OK.

Le taux auquel les données peuvent être transférées vers et depuis le disque constitue un autre facteur affectant les performances. Il est recommandé d'installer les fichiers de données des bases de données SQL Server sur des disques rapides de type SCSI (Small Computer System Interface) ou SATA (Serial Advanced Technology Attachment), par opposition aux disques de lents tels que les périphériques IDE (Integrated Device Electronics). Si possible, utilisez dans ce but une baie de disques indépendants (RAID). Les configurations RAID offrent non seulement des gains de performances, mais permettent également la redondance des données.

Les journaux de transactions SQL Server sont utilisés pour stocker les transactions de données avant qu'elles soient écrites dans les fichiers de bases de données. Les fichiers journaux de transactions sont habituellement en lecture seule. Ils sont uniquement lus lorsqu'une récupération est nécessaire. Pour cette raison, les configurations RAID optimisées pour l'écriture sont préférables. Dans l'idéal, placez les journaux de transactions sur des disques RAID 1.

Pour une utilisation optimale, les fichiers de données des bases de données SQL Server doivent être stockés sur une baie de disques offrant redondance et vitesse pour les opérations de lecture comme d'écriture. Utilisez de préférence une configuration RAID 10.

Pour des raisons de performances, il est également recommandé de placer le fichier de données tempdb et les fichiers journaux sur des ressources disque différentes de celles des autres bases de données. Pour plus d'informations, reportez-vous aux 10 meilleures pratiques pour le stockage (http://go.microsoft.com/fwlink/?LinkId=87536).

Pour plus d'informations sur la configuration de disques SQL Server 2005, reportez-vous à l'Annexe A de l'article ayant trait à la conception du stockage physique des bases de données (http://go.microsoft.com/fwlink/?LinkId=85457).

MOM 2005 et SQL Server

Client Security utilise MOM 2005 pour la base de données de collecte (base de données OnePoint) et la base de données de rapports (SystemCenterReporting). Ces bases de données sont gérées par SQL Server. Lorsque des données sont transférées de la base de données de collecte vers la base de données de rapports, les données déplacées sont stockées temporairement dans la base de données système tempdb de SQL Server.

La base de données tempdb est une base de données système de SQL Server utilisée globalement par toutes les bases de données SQL Server sur un serveur unique. Elle est utilisée comme emplacement de stockage temporaire pour les opérations de base de données telles que les tables temporaires, les tables de travail et les index. La base de données tempdb doit être suffisamment grande pour contenir les données transférées durant la tâche DTS MOM de la base de données de collecte vers la base de données de rapports. Par défaut, tempdb est définie pour une croissance automatique jusqu'à l'espace disque maximum disponible. Son journal est configuré pour une croissance automatique jusqu'à une taille de 2 Go.

Pour permettre la réussite du transfert de données DTS, vous devez vous assurer que tempdb se situe sur un disque disposant de l'espace libre nécessaire à sa croissance durant ces transactions. Si tempdb ne dispose pas de l'espace disque nécessaire pour héberger les données temporaires des transactions DTS, la tâche DTS échouera.

Si nécessaire, tempdb peut être déplacée vers une autre ressource de disque. Pour plus d'informations sur le déplacement de tempdb, reportez-vous à l'article ayant trait au déplacement des bases de données système (http://go.microsoft.com/fwlink/?LinkId=87540).

Pour plus d'informations sur MOM et son utilisation de tempdb, reportez-vous à l'article ayant trait aux résultats pour le serveur de rapports (http://go.microsoft.com/fwlink/?LinkId=88044).

Tâche OnePoint-Reindex SQL Server

La tâche OnePoint-Reindex SQL Server, une tâche de maintenance de base de données standard de MOM, s'exécute chaque dimanche à 03 h 00. Elle nécessite que la base de données de collecte (base de données OnePoint) conserve 40 % d'espace libre pour que la réindexation n'échoue pas. La réindexation de la base de données de collecte provoque une utilisation importante du disque sur lequel elle réside. Ceci peut engendre une latence d'alertes et d'événements, car ceux-ci ne peuvent pas être écrits dans la base de données pendant la procédure de réindexation. Cette tâche prend habituellement 30 minutes.

Pour plus d'informations, reportez-vous à l'article ayant trait aux tâches par défaut des bases de données (http://go.microsoft.com/fwlink/?LinkId=87244).

Remise de rapport

Lorsqu'un administrateur Client Security demande un rapport du serveur de rapports en cliquant sur le nom du rapport dans la console Client Security, une demande est envoyée au serveur de rapports. Le résultat de cette requête est remis au serveur de gestion et le rapport est affiché à l'administrateur de Client Security.

Le temps nécessaire à la génération des rapports Client Security dépend principalement de la configuration du serveur de rapport et de la quantité de données devant être analysée pour chaque rapport particulier. Par exemple, au cours des tests, le rapport Résumé de la sécurité a nécessité environ 1,5 à 2 minutes pour être affiché avec 72 heures de données de 10 000 agents Client Security. À une moindre échelle, avec environ 2 500 agents Client Security, le rapport Résumé de la sécurité a nécessité moins d'une minute pour s'afficher.

Les rapports historiques de plus de quatre jours nécessitent l'analyse de données de la base de données de rapports (SystemCenterReporting). Plus la quantité de données à analyser est importante et plus le temps nécessaire à l'affichage du rapport sera long.

Afficher: