Réplication et topologie serveur

La quantité de réplication nécessaire pour distribuer les informations à travers le réseau se fait au même rythme que l'augmentation du nombre de serveurs HCL Domino® sur votre réseau. La réplication utilise de la mémoire et exige un certain temps de traitement. Il est donc nécessaire de planifier la réplication des serveurs. Si vous laissez les serveurs se répliquer de façon aléatoire (par exemple, un serveur donné réplique une base de documents sur plusieurs serveurs ou plusieurs bases sur plusieurs serveurs), les serveurs peuvent être tellement surchargés par les demandes de réplication que leur capacité à répondre aux demandes des clients risque d'en être affectée.

Pour garantir l'efficacité de la réplication, pensez à configurer certains serveurs en tant que serveurs de réplication. L'utilisation de serveurs dédiés pour gérer la réplication réduit drastiquement la quantité de travail que les serveurs doivent consacrer à la réplication. Les serveurs doivent en effet se répliquer uniquement sur les serveurs de réplication, et non sur tous les serveurs qui détiennent une copie de la base en question. Pour contrôler la réplication, vous pouvez créer des documents de connexion spécifiant sur quels serveurs et à quel moment la réplication doit avoir lieu.

La façon dont vous vous connectez aux serveurs pour la réplication dépend de nombreux facteurs, notamment l'organisation du réseau physique, la taille de votre organisation ainsi que la mesure dans laquelle vous souhaitez réutiliser les documents de connexion créés pour le routage du courrier. Il existe plusieurs configurations (ou topologies) différentes afin de contrôler la façon dont la réplication s'effectue entre les serveurs :

  • Pivot-satellites
  • D'égal à égal
  • En anneau

Choisissez la stratégie de réplication la plus efficace. Dans de nombreux cas, vous devrez utiliser plusieurs topologies pour les différentes parties du réseau.

Utilisation d'une topologie pivot-satellites pour gérer la réplication

La topologie pivot-satellites est la plus courante et la plus efficace dans les grandes organisations car elle minimise le trafic réseau. La réplication pivot-satellites définit un serveur central comme pivot, qui planifie et lance toutes les réplications avec tous les autres serveurs ou satellites. Les satellites mettent à jour le serveur pivot par réplication (et acheminement du courrier) et le pivot met à son tour à jour chaque satellite. Les serveurs pivot se répliquent entre eux ou avec les serveurs pivot principaux dans les organisations qui utilisent plusieurs pivots. En résumé, le serveur pivot joue le rôle de gestionnaire du trafic, en supervisant les ressources système, en s'assurant que les réplications s'effectuent correctement avec chaque satellite et en garantissant la réplication de l'ensemble des modifications sur tous les serveurs satellite.

Pour configurer la réplication dans un système pivot-satellites, il suffit de créer un seul document de connexion pour chaque connexion pivot-satellites. Pour vérifier que la tâche de réplication sur le pivot, et non sur les satellites, prend toujours en charge la plus grande partie du travail, chaque document de connexion indique le serveur pivot comme serveur source, le serveur satellite comme serveur de destination et la méthode Pull-Push comme méthode de réplication.

La topologie pivot-satellites est particulièrement adaptée aux sites étendus comportant de nombreux serveurs ou dans un bureau centralisé devant se connecter via des lignes téléphoniques ou spécialisées à des bureaux locaux plus petits. Si votre site est étendu, vous pouvez utiliser une combinaison de topologies, par exemple deux configurations pivot-satellites et une configuration d'égal à égal entre deux serveurs pivot.

Le principal inconvénient de la topologie pivot-satellites réside dans sa vulnérabilité : la défaillance d'un seul élément dans le pivot peut suffire à entraîner la paralysie de votre système. Ce petit problème peut être partiellement résolu par le déploiement d'un serveur de sauvegarde répliquant le pivot et susceptible d'être rapidement reconfiguré en serveur pivot si le principal pivot tombe en panne.

Avantages d'une topologie pivot-satellites

  1. Installation de plusieurs protocoles sur des serveurs pivot pour permettre les communications dans un système Domino® utilisant plusieurs protocoles. Ainsi, les serveurs pivot sont placés dans plusieurs réseaux nommés HCL Notes®, ce qui améliore encore l'efficacité du système. Les serveurs pivot peuvent connecter entre eux plusieurs réseaux nommés Notes®, alors qu'un seul serveur pivot et ses satellites ne constituent généralement qu'un seul réseau nommé Notes®.
  2. Liaison des différentes parties d'un réseau, par exemple un réseau local (LAN) et un réseau étendu (WAN).
  3. Centralisation de l'administration de la base Annuaire Domino®, standardisation des LCA de bases de documents et limitation de l'accès au pivot. Vous pouvez définir un accès Gestionnaire pour le serveur pivot et un accès Lecteur pour les serveurs satellite, afin d'effectuer ces changements dans une seule réplique sur le serveur pivot pour synchroniser les serveurs satellite.
  4. Attribution de rôles aux différents serveurs pivot, en définissant par exemple des serveurs pivot de réplication et des serveurs pivot de messagerie.
  5. Placement des programmes serveur, tels que les agents de transfert de messages, sur des serveurs pivot afin qu'ils soient plus accessibles.
  6. Connexion des sites distants en utilisant un serveur pivot.
  7. Trafic réseau minimal et optimisation du rendement du réseau.
  8. Centralisation des sauvegardes de données sur le serveur pivot. En ne sauvegardant les bases de documents que sur le pivot, vous conservez des ressources sur les serveurs satellite.
  9. Amélioration de l'équilibrage de la charge des serveurs. Cependant, le trafic réseau augmente sur le segment réseau local du serveur pivot. Si vous avez plus de 25 serveurs par pivot, créez des niveaux de serveurs pivot. Si un serveur pivot tombe en panne, la réplication est désactivée sur ce serveur et sur ses satellites jusqu'à ce qu'il soit réparé ou remplacé.
Remarque : N'utilisez pas la réplication pivot-satellites pour les bases de documents de plus de 100 Mo répliquées sur moins de quatre serveurs. Planifiez à la place une réplication de ces bases de documents séparément des autres réplications.

Utilisation d'une topologie d'égal à égal pour la gestion de la réplication

Dans une topologie d'égal à égal, la réplication est moins centralisée que dans une configuration pivot-satellites. Chaque serveur est connecté à tous les autres serveurs. La réplication d'égal à égal permet une diffusion rapide des modifications à tous les serveurs. Elle constitue donc généralement une bonne solution pour les petites organisations, ou pour le partage local de bases de données entre un petit nombre de serveurs. Elle est cependant parfois inefficace lorsqu'une base de documents réside sur un nombre important de serveurs.

Dans une topologie d'égal à égal, les problèmes de réplication potentiels sont réduits étant donné que pour chaque réplication, la communication se fait simplement entre deux serveurs, et ne nécessite ni serveur pivot, ni serveurs relais. Cependant, la réplication d'égal à égal nécessite un grand nombre de documents de connexion, augmente le travail d'administration dans la mesure où vous devez éviter les chevauchements en matière de planification des réplications et interdit la normalisation des spécifications des LCA.

Autres stratégies de réplication

La réplication de grappe constitue une autre méthode de gestion de la réplication. Elle garantit un accès constant aux données du serveur, celles-ci étant sont dupliquées sur une ou plusieurs grappes. Si le serveur principal n'est pas disponible, les données sont accessibles dans d'autres serveurs de la grappe.

Les autres topologies de réplication sont les suivantes :

  • La topologie de bout en bout (en chaîne) permet de connecter plusieurs serveurs en chaîne. Les informations sont acheminées dans un sens le long de la chaîne, puis reviennent dans l'autre sens. La réplication de bout en bout est moins efficace que la réplication en anneau, mais elle est utile dans les situations où les informations n'ont besoin d'être acheminées que dans une seule direction.
  • La topologie en anneau est similaire à la topologie de bout en bout mais connecte les serveurs en cercle. La réplication se fait donc en boucle fermée. La réplication en anneau peut être utile dans une grande organisation, afin de répliquer des informations entre des serveurs pivot.
  • Dans la topologie en arborescence binaire, le serveur placé au sommet est connecté aux deux serveurs inférieurs, lesquels sont eux-mêmes connectés aux deux serveurs inférieurs, et ainsi de suite. Les informations descendent, puis remontent dans la hiérarchie.

Utilisation pour la réplication de connexions de routage de courrier existantes

Lorsque vous planifiez la réplication, pensez à réutiliser les connexions que vous avez déjà configurées pour le routage du courrier Notes®. Si vous avez déjà créé un document de connexion pour le routage du courrier, vous pouvez facilement activer la tâche de réplication sur ce document.

Contrairement au routage du courrier, qui fonctionne dans une direction et nécessite une paire de documents de connexion pour activer le routage bidirectionnel, la réplication entre serveurs fonctionne dans deux directions et un seul document de connexion est nécessaire pour chaque paire de serveurs. Le serveur qui lance la réplication prend en charge la plus grande partie du travail de réplication. Par conséquent, si vous décidez d'ajouter la réplication aux documents de connexion déjà utilisés pour le routage du courrier entre deux serveurs, ajoutez la tâche de réplication au document qui se trouve sur le serveur le plus puissant.