Amélioration de la disponibilité et de l'évolutivité

  • Article

Dans de nombreuses applications, il est indispensable d'offrir à la fois une disponibilité supérieure et une plus grande évolutivité de lecture ; la réplication peut être utilisée comme un élément essentiel pour une solution offrant ces deux avantages. Pour certaines applications, l'objectif pourrait être d'améliorer soit la disponibilité soit l'évolutivité au moyen de la réplication. Si vous n'avez besoin de résoudre que l'un de ces deux points, étudiez l'un des scénarios suivants :

Les diagrammes qui suivent illustrent deux applications qui tirent avantage de la réplication pour accroître la disponibilité et l'évolutivité. Dans les deux cas, les trois bases de données des diagrammes sont égales entre elles : elles contiennent des schémas et des données identiques. L'activité d'écriture de ces bases de données doit être partitionnée : si la base de données contenait un catalogue de produits, vous pourriez par exemple diriger les mises à jour vers la première base de données pour les produits dont les noms commencent par les lettres A-I, vers la deuxième pour J-R et vers la troisième pour S-Z. Les mises à jour seraient ensuite répliquées vers les autres bases de données.

Le premier diagramme présente une configuration dans laquelle chaque serveur d'application et chaque serveur Web utilise des données en provenance d'un serveur de mise en cache particulier. Les lectures et les mises à jour pour un utilisateur donné sont dirigées vers un serveur d'application spécifique puis vers un serveur de mise en cache spécifique. Le serveur d'application mettant directement à jour le cache, aucun serveur source central n'est nécessaire. Les mises à jour de chaque cache sont propagées vers les autres caches.

Utilisation de la réplication pour l'échelle d'activité de lecture

Le deuxième diagramme présente trois serveurs géographiquement dispersés avec des données circulant entre eux trois et permettant à chacun des serveurs de lire les requêtes et d'améliorer la disponibilité.

Réplication d'égal à égal vers des emplacements dispersés

Exemple Adventure Works Cycles

Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples et exemples de base de données.

Adventure Works Cycles dispose de plusieurs bureaux à travers le monde, à Los Angeles, Londres et Taipei. Les informations des commandes clients sont collectées dans chaque bureau puis répliquées vers les autres.

Les informations de commandes peuvent être lues à partir de chaque lieu ; ainsi, si le bureau de Londres connaît une surcharge d'activité de lecture, les applications internes peuvent distribuer une partie de cette activité entre les deux autres bureaux.

Si un serveur est arrêté pour maintenance à Londres, par exemple, les commandes peuvent être récupérées à partir d'un autre bureau et les employés londoniens peuvent continuer à lire et saisir les données. Lorsque le serveur de Londres se reconnecte, les changements reçus durant son arrêt sont propagés vers lui et il demeure ainsi à jour.

Conditions communes pour ce scénario

Les applications qui utilisent la réplication pour l'évolutivité et la disponibilité ont en général les exigences suivantes, auxquelles doit répondre une solution de réplication appropriée :

  • Le système doit autoriser l'introduction des modifications sur n'importe quel serveur, qui les réplique ensuite vers tous les autres serveurs.
  • Le système doit assurer la cohérence des transactions.
  • Le système doit avoir une faible latence : les mises à jour effectuées sur un serveur doivent atteindre rapidement les autres serveurs.
  • Le système doit avoir un débit élevé : il doit assurer la réplication d'un grand nombre de transactions.
  • Le traitement des réplications ne doit nécessiter qu'une charge minimale.

Type de réplication à utiliser pour ce scénario

Microsoft SQL Server utilise une métaphore du secteur de l'édition pour décrire les composants du système de réplication. Ces composants sont le serveur de publication, les Abonnés, les publications et articles et les abonnements.

Dans les diagrammes ci-dessus, tous les serveurs de mise en cache sont des serveurs de publication et des Abonnés. Toutes les données de la base de données répliquée sont incluses dans la publication, chaque table de données étant un article (les articles peuvent aussi être d'autres objets de bases de données, tels que des procédures stockées). Chaque serveur est Abonné aux publications des autres serveurs, et reçoit comme abonnement des schémas et des données. Pour plus d'informations sur les composants de ce système, consultez Présentation du modèle de publication de réplication.

SQL Server offre différents types de réplication pour différents besoins des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La plus adaptée à ce scénario est la réplication d'égal à égal, qui convient bien pour prendre en compte les conditions exposées dans la section qui précède. Pour plus d'informations sur la réplication d'égal à égal, consultez Réplication transactionnelle d'égal à égal.

ms151244.note(fr-fr,SQL.90).gifRemarque :
Si l'application nécessite que des modifications dans une ligne donnée soient effectuées simultanément au niveau de plusieurs nœuds, des conflits de données peuvent se produire. Dans ce cas, utilisez la réplication de fusion, bien adaptée pour gérer les conflits. Pour plus d'informations sur la réplication de fusion, consultez Présentation de la réplication de fusion.

De par sa conception, la réplication transactionnelle satisfait les principales conditions de ce scénario :

  • Les changements peuvent être effectués sur n'importe quel serveur
  • Homogénéité des transactions
  • Faible latence
  • Débit élevé
  • Charge minimale

L'option d'égal à égal pour la réplication transactionnelle permet aux serveurs de publier et de s'abonner aux mêmes données. Tous les nœuds d'une topologie d'égal à égal sont égaux : chaque nœud publie et s'abonne aux mêmes schémas et données. Les modifications (insertions, mises à jour et suppressions) peuvent être effectuées sur tout nœud puis répliqués sur tous les autres.

Procédure de mise en œuvre de ce scénario

Pour mettre en œuvre ce scénario, vous devez tout d'abord créer des publications et des abonnements, puis initialiser chaque abonnement. Pour plus d'informations, consultez :

Après initialisation des abonnements, lorsque les données circulent entre serveurs égaux, peut-être aurez-vous besoin de consulter les rubriques qui suivent pour vous informer sur les tâches d'administration et de surveillance courantes  :

Voir aussi

Autres ressources

Réplication des données dans un environnement de serveur à serveur

Aide et Informations

Assistance sur SQL Server 2005