Conditions requises et considérations relatives au déploiement d’Analysis Services

Les performances et la disponibilité d’une solution dépendent de nombreux facteurs, notamment les fonctionnalités du matériel sous-jacent, la topologie de votre déploiement de serveur, les caractéristiques de votre solution (par exemple, avoir des partitions distribuées sur plusieurs serveurs ou utiliser le stockage ROLAP qui nécessite un accès direct au moteur relationnel), des contrats de niveau de service et la complexité de votre modèle de données.

Configuration requise pour la mémoire et le processeur

Analysis Services a besoin de ressources de mémoire et de processeur supplémentaires dans les cas suivants :

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

• Lorsque le nombre de cubes au sein d’une base de données unique augmente.

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

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

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

La quantité de ressources mémoire et processeur disponibles pour Analysis Services varie en fonction de l’édition de SQL Server, du système d’exploitation, de la fonctionnalité matérielle et que vous utilisiez des processeurs virtuels ou physiques. Pour plus d’informations, suivez ces liens :

Configuration matérielle et logicielle requise pour l’installation de SQL Server 2014

Limites de capacité de calcul par édition de SQL Server

Fonctionnalités prises en charge par les éditions de SQL Server 2014

Spécifications de capacité maximale (Analysis Services)

Configuration requise pour l’espace disque

Différents aspects de votre installation d’Analysis Services et les tâches liées au traitement des objets nécessitent différentes quantités d’espace disque. La liste suivante décrit ces exigences.

Cubes
Les cubes qui ont de grandes tables de faits nécessitent plus d’espace disque que les cubes qui ont de petites tables de faits. De même, bien que dans une moindre mesure, les cubes qui ont de nombreuses dimensions volumineuses nécessitent plus d’espace disque que les cubes qui ont moins de membres de dimension. En règle générale, vous pouvez vous attendre à ce qu’une base de données Analysis Services nécessite environ 20 % de la quantité d’espace nécessaire pour les 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égations ajoutées, plus il y a d’agrégations, plus l’espace est nécessaire. Si vous évitez de créer des agrégations inutiles, l’espace disque supplémentaire nécessaire pour les agrégations ne doit généralement pas dépasser environ 10 % de la taille des données stockées dans la base de données relationnelle sous-jacente.

Exploration de données
Par défaut, les structures d'exploration de données enregistrent sur le disque le jeu de données avec lequel elles sont entraînées. Pour supprimer ces données mises en cache du disque, vous pouvez utiliser l’option de traitement Process Clear Structure sur l’objet structure d’exploration de données. Pour plus d’informations, consultez Exigences et considérations relatives au traitement (exploration de données).

Traitement des objets
Pendant le traitement, Analysis Services stocke les copies des objets qu’il traite dans la transaction de traitement sur le disque jusqu’à ce que le traitement soit terminé. Une fois le traitement terminé, les copies traitées des objets remplacent les objets d’origine. Par conséquent, vous devez fournir suffisamment d’espace disque supplémentaire pour qu’une deuxième copie de chaque objet soit traitée. Par exemple, si vous envisagez de traiter un cube entier dans une seule transaction, vous avez besoin d’un espace disque dur suffisant pour stocker une deuxième copie du cube entier.

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 l’interrogation en raison d’une défaillance matérielle ou logicielle. Un cube peut également être indisponible, car il doit être traité.

Disponibilité en cas de défaillance matérielle ou logicielle

Le matériel ou le logiciel peut échouer pour différentes raisons. Toutefois, la maintenance de la disponibilité de votre installation d’Analysis Services consiste non seulement à résoudre la source de ces défaillances, mais également à fournir d’autres ressources qui permettent à l’utilisateur de continuer à utiliser le système en cas de défaillance. Les serveurs d’équilibrage de charge et de clustering sont généralement utilisés pour fournir les autres ressources nécessaires pour maintenir la disponibilité lorsque des défaillances matérielles ou logicielles se produisent.

Afin d'assurer la disponibilité en cas de défaillance matérielle ou logicielle, envisagez de déployer Analysis Services dans un cluster de basculement. Dans un cluster de basculement, si le nœud principal échoue pour une raison quelconque ou s’il doit être redémarré, le clustering Microsoft Windows bascule vers un nœud secondaire. Après le basculement, qui se produit très rapidement, lorsque les utilisateurs exécutent une requête, ils accèdent à l’instance d’Analysis Services qui s’exécute sur le nœud secondaire. Pour plus d’informations sur les clusters de basculement, consultez Technologies Windows Server : Clusters de basculement.

Une autre solution pour les problèmes de disponibilité consiste à déployer votre projet Analysis Services sur deux serveurs de production ou plus. Vous pouvez ensuite utiliser la fonctionnalité d’équilibrage de charge réseau (NLB) des serveurs Windows pour combiner les serveurs de production en un seul cluster. Dans un cluster DLB, si un serveur du cluster n’est pas disponible en raison de problèmes matériels ou logiciels, le service DLB dirige les requêtes utilisateur vers ces serveurs qui sont toujours disponibles.

Disponibilité lors du traitement des changements structurels

Certaines modifications apportées à un cube peuvent entraîner l’indisponibilité du cube tant qu’il n’est pas traité. Par exemple, si vous apportez des modifications structurelles à une dimension dans un cube, même si vous retraitez la dimension, chaque cube qui utilise la dimension modifiée doit également être traité. Tant que vous ne traitez pas ces cubes, les utilisateurs ne peuvent pas les interroger, ni interroger des modèles d’exploration de données basés sur un cube qui a la dimension modifiée.

Pour assurer la disponibilité pendant que vous traitez des modifications structurelles susceptibles d'affecter un ou plusieurs cubes dans un projet Analysis Services, envisagez d'ajouter un serveur intermédiaire et d'utiliser l'Assistant Synchronisation de la base de données. Cette fonctionnalité vous permet de mettre à jour les données et les métadonnées sur un serveur intermédiaire, puis d’effectuer une synchronisation en ligne du serveur de production et du serveur intermédiaire. Pour plus d’informations, consultez Synchroniser les 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 de nouvelles données sources sans nécessiter de traitement manuel et sans affecter la disponibilité des cubes. Pour plus d’informations, consultez Mise en cache proactive (partitions).

Considérations relatives à l’extensibilité

Plusieurs instances de Microsoft SQL Server et Analysis Services sur le même ordinateur peuvent entraîner des problèmes de performances. Pour résoudre ces problèmes, une option peut être d’augmenter le processeur, la mémoire et les ressources de disque sur le serveur. Vous pourriez également avoir besoin d'étendre les instances de SQL Server et Analysis Services sur plusieurs ordinateurs.

Mise à l’échelle d’Analysis Services sur plusieurs ordinateurs

Il existe plusieurs façons de mettre à l’échelle une installation d’Analysis Services sur plusieurs ordinateurs. Ces options sont décrites dans la liste suivante.

• S’il existe plusieurs instances d’Analysis Services sur un seul ordinateur, vous pouvez déplacer une ou plusieurs instances vers un autre ordinateur.

• S’il existe plusieurs bases de données Analysis Services sur un seul ordinateur, vous pouvez déplacer une ou plusieurs des bases de données sur sa propre instance d’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 déplacer ces bases de données vers un ordinateur distinct. Avant de déplacer les bases de données, tenez compte de la vitesse réseau et de la bande passante qui existent entre la base de données Analysis Services et ses bases de données sous-jacentes. Si le réseau est lent ou ingéré, le déplacement des bases de données sous-jacentes vers un ordinateur distinct dégrade les performances de traitement.

• Si le traitement affecte les performances des requêtes, mais que vous ne pouvez pas traiter pendant des périodes de charge de requête réduite, envisagez de déplacer vos tâches de traitement vers un serveur intermédiaire, puis d’effectuer une synchronisation en ligne du serveur de production et du serveur intermédiaire. Pour plus d’informations, consultez Synchroniser les bases de données Analysis Services. Vous pouvez également distribuer le traitement sur plusieurs instances d’Analysis Services à l’aide de partitions distantes. Le traitement des partitions distantes utilise les ressources de processeur et de mémoire sur le serveur distant, au lieu des ressources sur l’ordinateur local. Pour plus d’informations sur la gestion des partitions à distance, consultez Créer et gérer une partition distante (Analysis Services).

• Si les performances des requêtes sont médiocres, mais que vous ne pouvez pas augmenter le processeur et les ressources de mémoire sur le serveur local, envisagez de déployer un projet Analysis Services sur deux serveurs de production ou plus. Vous pouvez ensuite utiliser l’équilibrage de charge réseau (NLB) pour combiner les serveurs en un seul cluster. Dans un cluster DLB, les requêtes sont automatiquement distribuées sur tous les serveurs du cluster d’équilibrage de charge réseau.