Partager via


Configuration requise et considérations relatives au déploiement d'Analysis Services

Avant de déployer un projet MicrosoftSQL ServerAnalysis Services, vous devez tenir compte de certains éléments importants pour améliorer la fiabilité et les performances de l'installation Analysis Services. Par exemple, il peut être nécessaire d'augmenter les ressources matérielles si vous ajoutez des instances Analysis Services aux instances existantes sur le serveur, ou si vous allez traiter des cubes complexes dans le projet. Vous devez également prendre les mesures nécessaires pour garantir la disponibilité du projet en cas de défaillance matérielle ou logicielle, et pendant l'exécution de certaines tâches de traitement. Enfin, il peut s'avérer nécessaire de mettre à l'échelle les instances SQL Server ou Analysis Services sur plusieurs ordinateurs en fonction des exigence en matière de performances.

Conditions requises et éléments à prendre en compte

La configuration requise et les considérations relatives au déploiement sont traitées dans les sections suivantes :

  • Besoins en ressources

  • Considérations relatives à la disponibilité

  • Considérations relatives à la capacité à monter en charge

Besoins en ressources

Avant de déployer le projet Analysis Services, tenez compte des besoins en ressources de l'installation. Tenez compte notamment des besoins en mémoire, traitement et espace disque.

Besoins en mémoire et de traitement

Analysis Services nécessite plus de ressources de mémoire et de traitement dans les cas suivants :

  • Lors du traitement de cubes volumineux ou complexes. Ces cubes nécessitent plus de ressources mémoire et de traitement que les petits cubes et les cubes simples.

  • Lorsque le nombre de cubes dans une base de données augmente.

  • Lorsque le nombre de bases de données dans une instance Analysis Services augmente.

  • Lorsque le nombre d'instances Analysis Services sur un ordinateur augmente.

  • Lorsque le nombre d'utilisateurs qui accèdent simultanément aux ressources Analysis Services augmente.

La quantité de ressources mémoire et la capacité de traitement disponibles pour Analysis Services varient en fonction de la version de Microsoft Windows installée sur le serveur. Le tableau suivant répertorie les ressources mémoire et de traitement qu'Analysis Services peut gérer en fonction de la version de Windows installée.

Version de Windows

Quantité maximale de mémoire disponible pour Analysis Services

Nombre maximal de processeurs disponibles pour Analysis Services

Windows Server 2003, Enterprise, version 64 bits

64 gigaoctets (Go)

8

Windows Server 2003, Datacenter, version 64 bits

512 Go

32

Windows Server 2003, Standard

3 Go en utilisant le commutateur /3GB

4

Windows Server 2003, Enterprise

3 Go en utilisant le commutateur /3GB

8

Windows Server 2003, Datacenter

3 Go en utilisant le commutateur /3GB

32

Windows 2000 Server

2 Go

4

Windows 2000 Advanced Server

3 Go en utilisant le commutateur /3GB

8

Windows 2000 Datacenter Server

3 Go en utilisant le commutateur /3GB

32

Important

Analysis Services peut gérer jusqu'à 3 Go de mémoire sur une version de Windows 32 bits, quelle que soit la quantité de mémoire installée sur l'ordinateur. Pour plus d'informations, consultez l'article 283037 de la Base de connaissances Microsoft.

Espace disque requis

Différents éléments de l'installation Analysis Services et les tâches associées au traitement des objets nécessitent une quantité d'espace disque différente. Le tableau suivant décrit ces besoins.

  • Cubes
    Les cubes comportant de grandes tables de faits nécessitent plus d'espace disque que les cubes composés de petites tables de faits. De même, à un moindre degré, les cubes qui disposent d'un grand nombre de dimensions volumineuses nécessitent plus d'espace disque que les cubes ayant un nombre moindre de membres de dimension. En règle générale, une base de données Analysis Services nécessite environ 20 % de l'espace nécessaire aux mêmes données stockées dans la base de données relationnelle sous-jacente.

  • Agrégations
    Les agrégations nécessitent un espace supplémentaire proportionnel aux agrégation ajoutées ; plus les agrégations sont nombreuses, plus il convient d'ajouter de l'espace. Si vous évitez de créer des agrégations inutiles, l'espace disque supplémentaire nécessaire aux agrégations ne doit généralement pas dépasser 10 % environ de la taille des données stockées dans la base de données relationnelle sous-jacente.

  • Exploration des données
    Par défaut, les structures d'exploration de données placent dans le cache du disque le dataset utilisé pour leur apprentissage. Pour supprimer ces données du cache du disque, vous pouvez utiliser l'option de traitement Traiter l'effacement de la structure sur l'objet de structure d'exploration de données. Pour plus d'informations, consultez Traitement des objets d'exploration de données.

  • Traitement des objets
    Lors du traitement, Analysis Services copie sur le disque les objets qu'il traite dans la transaction de traitement jusqu'à la fin du traitement. Une fois le traitement terminé, les copies traitées des objets remplacent les objets d'origine. Par conséquent, vous devez disposer d'un espace disque supplémentaire suffisant pour une seconde copie de chaque objet à traiter. Si, par exemple, vous envisagez de traiter l'ensemble d'un cube dans une seule transaction, vous devez disposer d'un espace disque suffisant pour pouvoir stocker une seconde copie de l'ensemble du cube.

Retour en haut

Considérations relatives à la disponibilité

Dans un environnement Analysis Services, un cube ou un modèle d'exploration de données peut être indisponible pour effectuer des requêtes suite à une erreur matérielle ou logicielle. Un cube peut également être indisponible car il doit être traité.

Maintien de la disponibilité en cas d'erreurs matérielles ou logicielles

Le matériel ou le logiciel peut être défaillant pour diverses raisons. Toutefois, le maintien de la disponibilité de l'installation Analysis Services ne se limite pas à éliminer la source des problèmes, mais il vise également à fournir des ressources alternatives qui permettent aux utilisateurs de continuer à utiliser le système en cas d'erreur. Le clustering des serveurs et l'équilibrage de charge des serveurs sont généralement utilisés pour fournir les ressources alternatives nécessaires au maintien de la disponibilité en cas d'erreur matérielle ou logicielle.

Pour maintenir la disponibilité en cas d'erreur matérielle ou logicielle, déployez Analysis Services dans un cluster de basculement. Dans un cluster de basculement, le clustering Microsoft Windows bascule vers un nœud secondaire en cas de défaillance du nœud principal ou s'il est nécessaire de le redémarrer. Après le basculement, qui s'effectue très rapidement, les utilisateurs accèdent à l'instance Analysis Services qui est exécutée sur le nœud secondaire lorsqu'ils exécutent des requêtes.

Une autre solution pour maintenir la disponibilité consiste à déployer le projet Analysis Services sur au moins deux serveurs de production. Vous pouvez utiliser la fonction d'équilibrage de la charge réseau des serveurs Windows pour placer les serveurs de production dans un seul cluster. Dans un cluster avec équilibrage de la charge réseau, le service d'équilibrage de la charge réseau envoie les requêtes des utilisateurs aux serveurs toujours disponibles lorsqu'un serveur du cluster devient indisponible à la suite d'une erreur matérielle ou logicielle. Pour plus d'informations sur le clustering Windows et l'équilibrage de la charge réseau, consultez Clustering Services (en anglais) sous Technology Centers sur le site Web Microsoft Windows Server 2003.

Maintien de la disponibilité lors du traitement des modifications structurelles

Certaines modifications d'un cube peuvent rendre le cube indisponible jusqu'à ce qu'il soit retraité. Si, par exemple, vous apportez des modifications structurelles à une dimension d'un cube, les cubes qui utilisent la dimension modifiée doivent également être retraités, même si vous retraitez la dimension. Les utilisateurs ne peuvent pas interroger ces cubes, ni les modèles d'exploration de données basés sur un cube dont la dimension est modifiée jusqu'à ce que vous retraitiez les cubes.

Pour maintenir la disponibilité lorsque vous traitez des modifications structurelles qui peuvent affecter un ou plusieurs cubes d'un projet Analysis Services, intégrez un serveur de test et utilisez l'Assistant Synchronisation de la base de données. Cette fonction permet de mettre à jour les données et les métadonnées sur un serveur de test, puis de synchroniser en ligne le serveur de production et le serveur de test. Pour plus d'informations, consultez Synchronisation des bases de données Analysis Services.

Pour traiter de manière transparente les mises à jour incrémentielles des données sources, activez la mise en cache proactive. La mise en cache proactive met à jour les cubes avec les nouvelles données sources sans avoir à procéder à un traitement manuel et sans affecter la disponibilité des cubes. Pour plus d'informations, consultez Mise en cache proactive (partitions).

Retour en haut

Considérations relatives à la capacité à monter en charge

L'existence de plusieurs instances MicrosoftSQL Server et de Analysis Services sur un même ordinateur peut affecter les performances. Pour résoudre ce problème, vous pouvez augmenter les ressources de traitement, mémoire et disque sur le serveur. Toutefois, il se peut que vous deviez également faire monter en charge les instances SQL Server et Analysis Services sur plusieurs ordinateurs.

Montée en charge d'Analysis Services sur plusieurs ordinateurs

Vous pouvez procéder de différentes manières pour faire monter en charge une installation Analysis Services sur plusieurs ordinateurs. Ces options sont décrites dans le tableau suivant.

  • S'il existe plusieurs instances Analysis Services sur un même ordinateur, vous pouvez transférer une ou plusieurs instances vers un autre ordinateur.

  • S'il existe plusieurs bases de données Analysis Services sur un même ordinateur, vous pouvez transférer une, ou plusieurs, base de données vers sa propre instance Analysis Services sur un ordinateur distinct.

  • Si une ou plusieurs bases de données relationnelles fournissent des données à une base de données Analysis Services, vous pouvez transférer ces bases de données vers un ordinateur distinct. Avant de transférer les bases de données, tenez compte de la vitesse et de la bande passante réseau qui existent entre la base de données Analysis Services et les bases de données sous-jacentes. Si le réseau est lent ou encombré et que vous transférez les bases de données sous-jacentes vers un autre ordinateur, les performances s'en trouvent affectées.

  • Si le traitement affecte les performances des requêtes et que vous ne pouvez pas traiter les données lors de la réduction de la charge des requêtes, transférez les tâches de traitement vers un serveur de test, puis synchronisez en ligne le serveur de production et le serveur de test. Pour plus d'informations, consultez Synchronisation des bases de données Analysis Services. Vous pouvez également distribuer le traitement sur plusieurs instances Analysis Services en utilisant des partitions distantes. Le traitement des partitions distantes utilise les ressources de traitement et mémoire du serveur distant et non celles de l'ordinateur local. Pour plus d'informations sur la gestion des partitions distantes, consultez Gestion des partitions Analysis Services.

  • Si les performances des requêtes sont dégradées et que vous ne pouvez pas augmenter les ressources de traitement et mémoire de l'ordinateur local, déployez un projet Analysis Services sur au moins deux serveurs de production. Ainsi, vous pouvez utiliser l'équilibrage de la charge réseau pour placer les serveurs dans un cluster. Dans un cluster avec équilibrage de la charge réseau, les requêtes sont distribuées automatiquement vers tous les serveurs du cluster avec équilibrage de la charge réseau. Pour plus d'informations, consultez Clustering Services (en anglais) sous Technology Centers sur le site Web Microsoft Windows Server 2003.

Retour en haut