Vue d'ensemble des solutions à haute disponibilité

Cette section présente plusieurs solutions haute disponibilité SQL Server qui améliorent la disponibilité des serveurs ou des bases de données. Une solution haute disponibilité masque l'impact d'un dysfonctionnement matériel ou logiciel et gère la disponibilité des applications pour réduire le temps d'immobilisation que perçoit l'utilisateur.

SQL Server fournit des options permettant de garantir un haut niveau de disponibilité pour un serveur ou une base de données. Les options de haute disponibilité sont les suivantes :

• Clustering de basculement

  Les clusters de basculement garantissent une prise en charge de la haute disponibilité pour l'intégralité d'une instance de SQL Server. Un cluster de basculement est une combinaison d'un ou de plusieurs nœuds, ou serveurs, avec plusieurs disques partagés. Les applications sont installées dans un groupe de clusters Microsoft Cluster Service (MSCS), appelé groupe de ressources. Chaque groupe de ressources est systématiquement détenu par un seul nœud du cluster à la fois. Le service d'application possède un nom virtuel indépendant des noms des nœuds, et il est désigné par les termes nom d'instance de cluster de basculement. Une application peut se connecter à l'instance de cluster de basculement en référençant le nom de l'instance de cluster de basculement. Il n'est pas nécessaire que l'application sache quel nœud héberge l'instance de cluster de basculement.

  Une instance de cluster de basculement SQL Server apparaît sur le réseau sous la forme d'un ordinateur unique, mais elle est en mesure de basculer d'un nœud vers un autre en cas d'indisponibilité du nœud actuel. Par exemple, au cours d'une défaillance d'un matériel autre qu'un disque, du système d'exploitation ou de la mise à niveau planifiée du système d'exploitation, vous pouvez configurer une instance de SQL Server sur un nœud d'un cluster de basculement de sorte qu'elle bascule vers n'importe quel autre nœud du groupe de disques.

  Un cluster de basculement ne fournit aucune protection contre une défaillance de disque. Vous pouvez utiliser le clustering de basculement pour réduire l'immobilisation du système et améliorer le niveau de disponibilité des applications. Le cluster de basculement est pris en charge dans SQL Server Enterprise et SQL Server Developer, et, avec certaines restrictions, dans SQL Server Standard. Pour plus d'informations sur le clustering de basculement, consultez Mise en route avec le clustering de basculement de SQL Server 2008 et Installation d'un cluster de basculement SQL Server 2008.

• Mise en miroir d'une base de données

  La mise en miroir de base de données est principalement une solution logicielle qui permet d'optimiser la disponibilité d'une base de données en utilisant presque instantanément le basculement. La mise en miroir de base de données peut être utilisée pour gérer une base de données de secours ou une base de données miroir pour une base de données de production correspondante désignée sous le nom de base de données principale.

  La base de données miroir est créée en restaurant une sauvegarde de base de données complète de la base de données principale sans récupération. Ainsi, la base de données miroir n'est pas accessible aux clients. Toutefois, il est possible de l'utiliser indirectement pour créer des rapports en créant une capture instantanée de base de données sur la base de données miroir. La capture instantanée de base de données fournit aux clients un accès en lecture seule aux données de la base de données, telles qu'elles existaient lors de la création de la capture instantanée.

  Chaque configuration de mise en miroir d'une base de données fait intervenir un serveur principal qui contient la base de données principale, et un serveur miroir qui contient la base de données en miroir. Le serveur miroir met régulièrement à jour la base de données miroir avec la base de données principale.

  La mise en miroir de base de données s'exécute de manière synchrone en mode haute sécurité, ou de manière asynchrone en mode hautes performances. En mode hautes performances, les transactions sont validées sans attendre que le serveur miroir écrive le journal sur le disque, ce qui contribue à optimiser les performances. En mode haute sécurité, une transaction validée est validée sur les deux partenaires, mais au détriment d'une latence accrue des transactions.

  Dans sa configuration la plus simple, la mise en miroir de bases de données implique uniquement les serveurs miroir et principal. Dans cette configuration, en cas de perte du serveur principal, le serveur miroir peut faire office de serveur de secours semi-automatique, avec une perte de données possible. Le mode haute sécurité prend en charge une autre configuration, le mode haute sécurité de basculement automatique. Cette configuration fait intervenir un troisième serveur, appelé témoin, qui permet au serveur miroir de faire office de serveur de secours à chaud. Le basculement de la base de données principale vers la base de données miroir dure généralement plusieurs secondes.

  Depuis SQL Server 2005 Service Pack 1 (SP1), les serveurs partenaires de mise en miroir de bases de données et les témoins sont pris en charge dans SQL Server Standard et SQL Server Enterprise. Les serveurs partenaires doivent néanmoins utiliser la même édition et la mise en miroir de bases de données asynchrone (mode hautes performances) est prise en charge uniquement dans SQL Server Enterprise. Les témoins sont également pris en charge dans SQL Server Workgroup et SQL Server Express.

  Pour plus d'informations sur la mise en miroir de bases de données, consultez Mise en miroir de bases de données.

• Copie des journaux de transaction

  Comme la mise en miroir d'une base de données, la copie des journaux de transaction fonctionne au niveau de la base de données. Vous pouvez utiliser la copie des journaux de transaction pour gérer une ou plusieurs bases de données de secours semi-automatique pour une base de données de production correspondante appelée base de données principale. Les bases de données de secours sont également appelées bases de données secondaires. Chaque base de données secondaire est créée en restaurant une sauvegarde de la base de données primaire sans récupération ou avec l'exécution de WITH STANDBY. La restauration avec l'exécution de WITH STANDBY permet l'utilisation de la base de données secondaire à des fins limitées de génération de rapports.

  Une configuration de la copie des journaux de transaction inclut un serveur principal qui contient la base de données primaire, un ou plusieurs serveurs secondaires qui possèdent chacun une base de données secondaire, et un serveur miroir. Chaque serveur secondaire met à jour sa base de données secondaire à intervalles définis à partir des sauvegardes de fichiers journaux de la base de données primaire. La copie des journaux de transaction implique un délai modifiable par l'utilisateur entre le moment où le serveur principal crée une sauvegarde de fichier journal de la base de données primaire et le moment où le serveur secondaire restaure la sauvegarde du fichier journal. Pour qu'un basculement puisse avoir lieu, une base de données secondaire doit être mise à jour complètement en appliquant manuellement toutes les sauvegardes de fichiers journaux non restaurés.

  La copie des journaux de transaction permet de prendre en charge plusieurs bases de données de secours. Si vous avez besoin de plusieurs bases de données de secours, vous pouvez utiliser la copie des journaux de transaction seule ou avec la mise en miroir de la base de données. Lorsque vous utilisez ces solutions ensemble, la base de données principale actuelle de la configuration de la mise en miroir de la base de données constitue également la base de données principale actuelle de la configuration de la copie des journaux de transaction.

  Les éditions SQL Server Enterprise, Standard et Workgroup prennent en charge la copie des journaux de transaction. Pour plus d'informations sur l'utilisation de la copie des journaux de transaction, consultez Vue d'ensemble de la copie des journaux de transaction et Administration de la copie des journaux de transaction.

• Réplication

  La réplication utilise un modèle publier/abonner. Ce modèle permet à un serveur principal, appelé serveur de publication, de distribuer les données à un ou plusieurs serveurs secondaires, appelés Abonnés. La réplication fournit une disponibilité et une évolutivité en temps réel sur ces serveurs. Elle prend en charge le filtrage pour fournir un sous-ensemble de données aux Abonnés et permet également de partitionner les mises à jour. Les Abonnés sont en ligne et disponibles pour la création de rapports ou autres fonctions, sans requête de récupération. SQL Server offre trois types de réplications : capture instantanée, transactionnelle et fusion. La réplication transactionnelle garantit le niveau de latence le plus bas, et elle est généralement utilisée pour offrir une haute disponibilité. Pour plus d'informations, consultez Amélioration de l'adaptabilité et de la disponibilité.

  La réplication est prise en charge dans toutes les éditions de SQL Server. La publication de réplication n'est pas disponible dans SQL Server Express ou SQL Server Compact 3.5 SP1.

  Important

  Une stratégie de sauvegarde et de restauration bien conçue et implémentée est importante pour une solution haute disponibilité. Pour plus d'informations, consultez Sauvegarde et restauration de bases de données dans SQL Server et Sauvegarde et restauration de bases de données répliquées.

• Bases de données partagées évolutives

  La fonctionnalité de base de données partagée évolutive vous permet de développer une base de données en lecture seule créée exclusivement pour générer des rapports. La base de données de rapports doit résider sur un ensemble de volumes dédiés en lecture seule dont le rôle principal est d'héberger la base de données. À l'aide du matériel de base pour les serveurs et les volumes, vous pouvez procéder au déploiement évolutif d'une base de données de création de rapports offrant le même aperçu des données de création de rapports sur plusieurs serveurs de rapports. Cette fonctionnalité permet également la mise à jour en douceur de la base de données de création de rapports. Pour plus d'informations, consultez Vue d'ensemble des bases de données partagées évolutives.