Exporter (0) Imprimer
Développer tout

Configuration d'un haut niveau de disponibilité

Mis à jour : 5 décembre 2005

Cette section présente plusieurs solutions haute disponibilité Microsoft SQL Server 2005 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 2005 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 avec basculement
    Les clusters avec basculement garantissent une prise en charge de la haute disponibilité pour l'intégralité d'une instance de SQL Server. Un cluster avec basculement est une combinaison d'un ou de plusieurs nœuds, ou serveurs, avec plusieurs disques partagés. Les applications, telles que SQL Server et les Notification Services, 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 avec basculement. Une application peut se connecter à l'instance de cluster avec basculement en référençant le nom de l'instance de cluster avec basculement. Il n'est pas nécessaire que l'application sache quel nœud héberge l'instance de cluster avec basculement.
    Une instance de cluster avec 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 avec basculement de sorte qu'elle bascule vers n'importe quel autre nœud du groupe de disques.
    Un cluster avec basculement ne fournit aucune protection contre une défaillance de disque. Vous pouvez utiliser le clustering avec basculement pour réduire l'immobilisation du système et améliorer le niveau de disponibilité des applications. SQL Server 2005 Enterprise Edition, Developer Edition et, avec certaines restrictions, Standard Edition prennent en charge le cluster avec basculement. Pour plus d'informations sur le clustering avec basculement, consultez Clustering avec basculement et Installation d'un cluster avec basculement.
  • 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 dans 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é avec 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 quelques secondes.
    Les serveurs partenaires de mise en miroir de bases de données et les serveurs témoins sont pris en charge par SQL Server 2005 Standard Edition SP1 et versions ultérieures et par SQL Server 2005 Enterprise Edition SP1 et versions ultérieures. En revanche, les serveurs partenaires doivent utiliser la même édition et la mise en miroir asynchrone de bases de données (mode hautes performances) est prise en charge uniquement par SQL Server 2005 Enterprise Edition et versions ultérieures. Les témoins sont également pris en charge par SQL Server 2005 Workgroup Edition SP1 et versions ultérieures et par SQL Server 2005 Express Edition SP1 et versions ultérieures. Pour plus d'informations sur la mise en miroir de bases de données, consultez Database Mirroring.

  • Copie des journaux de transaction
    Comme la mise en miroir d'une base de données, l'envoi de journaux fonctionne au niveau de la base de données. L'envoi de journaux peut être utilisé pour gérer une ou plusieurs bases de données de secours actives, appelées base de donnes secondaires, pour une base de données de production correspondante qui est appelée base de données principale. 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 générée à des fins limitées de génération de rapports.
    Une configuration d'envoi de journaux 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 régulièrement à jour sa base de données secondaire à partir des sauvegardes des journaux de la base de données primaire. L'envoi de journaux implique un délai modifiable par l'utilisateur entre le moment où le serveur principal crée une sauvegarde de journal de la base de données primaire et le moment où le serveur secondaire restaure la sauvegarde du 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 journaux non restaurés.
    L'envoi de journaux 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 l'envoi de journaux seul 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 d'envoi de journaux.
    SQL Server 2005 Enterprise Edition, Standard Edition et Workgroup Edition prennent en charge l'envoi de journaux. Pour plus d'informations sur l'envoi de journaux, consultez copie des journaux de transaction.
  • Réplication
    La réplication utilise un modèle de publication-abonnement qui permet à un serveur primaire, 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 d'autres fonctions, sans requête de récupération. SQL Server offre trois types de réplication : capture instantanée, transactionnelle et de fusion. La réplication transactionnelle garantit le niveau de latence le plus bas, et elle est généralement utilisée pour offrir un haut niveau de 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 2005. La publication de réplication n'est pas disponible dans SQL Server 2005 Express Edition ou SQL Server Compact Edition. Pour obtenir la liste complète des fonctionnalités de réplication qui sont prises en charge par chaque édition, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2005.
    ms190202.note(fr-fr,SQL.90).gifImportant :
    Une stratégie de sauvegarde et de restauration bien conçue et implémentée est essentielle à 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.

Sélection d'une solution haute disponibilité

La liste suivante contient les éléments à prendre en compte pour sélectionner une solution haute disponibilité :

  • Le cluster avec basculement et la mise en miroir d'une base de données fournissent les éléments suivants :
    • Détection et basculement automatiques
    • Basculement manuel
    • Redirection transparente des clients
    Le clustering avec basculement impose les contraintes suivantes :
    • Fonctionne au niveau de la portée de l'instance du serveur
    • Nécessite un matériel signé
    • Ne fournit aucun rapport sur la base de données de secours
    • Utilise une seule copie de la base de données
    • N'offre aucune protection contre les défaillances de disque
    La mise en miroir de bases de données présente les avantages suivants :
    • Fonctionne au niveau de la portée de la base de données.
    • Utilise une seule copie dupliquée de la base de données
      ms190202.note(fr-fr,SQL.90).gifRemarque :
      Si vous avez besoin d'autres copies, vous pouvez utiliser l'envoi de journaux sur la base de données en complément de la mise en miroir des bases de données.

    • Utilise des serveurs standard
    • Fournit des rapports limités sur le serveur miroir en utilisant des captures instantanées de la base de données.
    • Utilisée de manière asynchrone, elle évite de perdre des données en différant la validation dans la base de données principale.
    La mise en miroir de bases de données permet d'améliorer substantiellement la disponibilité par rapport au niveau de disponibilité offert avec SQL Server et elle offre une alternative simple à gérer au clustering avec basculement.
    ms190202.note(fr-fr,SQL.90).gifRemarque :
    Pour plus d'informations sur la façon d'utiliser la mise en miroir de bases de données avec un cluster de basculement, consultez Mise en miroir de base de données et clustering avec basculement. Pour plus d'informations sur la façon d'utiliser le clustering avec basculement avec Notification Services, consultez Utilisation du clustering avec basculement avec Notification Services. Pour plus d'informations sur la façon d'utiliser Notification Services avec la mise en miroir de bases de données, consultez Utilisation de la copie des journaux de transaction ou de la mise en miroir de bases de données avec Notification Services.

  • Copie des journaux de transaction
    Cette opération peut offrir une alternative ou un complément à la mise en miroir de bases de données. Bien que similaires au niveau des concepts, la mise en miroir asynchrone de bases de données et l'envoi de journaux comportent des différences importantes. L'envoi de journaux fournit les fonctions distinctes suivantes :
    • Prise en charge de plusieurs bases de données secondaires sur plusieurs instances de serveur pour une base de données primaire unique.
    • Possibilité de spécifier un délai défini par l'utilisateur entre la sauvegarde du journal de la base de données principale par le serveur principal et la restauration de la sauvegarde du journal par les serveurs secondaires. Un délai plus long peut s'avérer utile en cas, par exemple, de modification accidentelle des données sur la base de données primaire. Si la modification accidentelle est remarquée rapidement, un délai peut vous permettre de récupérer à partir de la base de données secondaire les données n'ayant pas encore été modifiées, avant que la modification n'y soit reflétée.
      En revanche, comparé au délai le plus court nécessité par l'envoi de journaux pour refléter une modification dans une base de données secondaire, la mise en miroir des bases de données asynchrones offre l'avantage possible d'un délai plus court lorsqu'une modification est effectuée dans la base de données primaire et lorsque cette modification est reflétée dans la base de données miroir.
      La mise en miroir de bases de données offre un avantage par rapport à la copie des journaux de transaction, dans la mesure où le mode de sécurité élevée est une configuration sans perte de données qui est prise en charge sous la forme d'une stratégie de basculement simple.
      ms190202.note(fr-fr,SQL.90).gifRemarque :
      Pour plus d'informations sur la façon d'utiliser la copie des journaux de transaction avec la mise en miroir de bases de données, consultez Mise en miroir de base de données et copie des journaux de transaction. Pour plus d'informations sur la façon d'utiliser la copie des journaux de transaction avec Notification Services, consultez Utilisation de la copie des journaux de transaction ou de la mise en miroir de bases de données avec Notification Services.

  • Réplication
    La réplication offre les avantages suivants :
    • Elle permet le filtrage dans la base de données pour fournir un sous-ensemble des données sur les bases de données secondaires car elle fonctionne au niveau de la portée de la base de données.
    • Elle permet d'utiliser plusieurs copies redondantes de la base de données.
    • Elle fournit une disponibilité et une évolutivité en temps réel sur plusieurs bases de données et prend en charge les mises à jour partitionnées.
    • Elle garantit la disponibilité totale des bases de données secondaires pour la création de rapports ou d'autres fonctions, sans récupération de requête.
    ms190202.note(fr-fr,SQL.90).gifRemarque :
    Pour plus d'informations sur la façon d'utiliser la mise en miroir de bases de données avec la réplication, consultez Réplication et mise en miroir des bases de données.

Rubrique Description

Clustering avec basculement

Contient des informations sur le partage d'une combinaison constituée d'un ou de plusieurs nœuds (serveurs) avec au moins deux disques durs

Mise en miroir de bases de données

Contient des informations sur le fonctionnement de la mise en miroir d'une base de données et explique comment configurer et gérer une session de mise en miroir d'une base de données

copie des journaux de transaction

Contient des informations sur le fonctionnement de la copie des journaux de transaction et explique comment configurer et gérer une configuration de copie des journaux de transaction

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft