10. Voies de communication Slony-I
Slony-I™ utilise le DSN de PostgreSQL™ dans trois contextes pour établir ses accès aux bases de données :
-
SLONIK ADMIN CONNINFO(7) - contrôle comment un script slonik(1) accède aux différents nœuds.
Ces connexions sont celles qui vont de votre « poste d'administration » vers tous les nœuds du cluster Slony-I™.
Il est vital que vous ayez des connexions depuis l'emplacement central où les scripts slonik(1) sont exécutés vers chacun des nœuds du réseau. Ces connexions sont uniquement utilisées brièvement pour effectuer les quelques requêtes SQL nécessaire à l'administration du cluster.
Puisque ces voies de communications sont utilisées brièvement, il est raisonnable de « regrouper » les connexions temporaires en utilisant un tunnel SSH.
-
Le paramètre DSN passé à chaque slon(1) indique la voie de communication à utiliser par le processus slon(1) et la base qu'il gère.
-
SLONIK STORE PATH(7) - contrôle comment les démons slon(1) communiquent avec les nœuds distants. Ces chemins sont stockés dans la table sl_path.
Vous devez forcément avoir une voie de communication entre chaque nœud abonné et son fournisseur ; les autres voies sont facultatives et ne seront utilisées que si un chemin dans la table sl_listen nécessite d'utiliser cette voie particulière.
Normalement, les distinctions et la complexité potentielle des voies de communications ne sont pas un problème pour les personnes qui ont un réseau simple où chaque nœud peut voir les autres via un ensemble « global » d'adresses réseau. En revanche, cela devient important pour celles qui ont des configurations de pare-feu complexes, des nœuds dans plusieurs lieux et dans le cas où les nœuds ne sont pas capable de se parler via un ensemble d'adresses réseau uniforme.
Considérons le diagramme suivant, qui décrit un ensemble de six
nœuds : 
-
DB1 et DB2 sont des bases de données situées dans une « zone de base de données » sécurisée, protégée de l'extérieur par un pare-feu à l'exception d'adresses spécifiquement contrôlées.
Supposons que DB1 soit le nœud d'origine du système de réplication.
-
DB3 se situe dans une « DMZ » du même site ; elle est considérée comme un « fournisseur » Slony-I™ pour les nœuds distants.
-
DB4 est la contrepartie de DB3 dans une « DMZ » au sein du second site (site de reprise en cas de panne). Son rôle dans cette configuration est de « nourrir » les serveurs de la zone de base de données sécurisée du second site.
-
DB5 et DB6 sont les équivalents de DB1 et DB2, mais sont dans ce cas configurés comme des nœuds abonnés.
En supposant qu'un désastre se produise sur le site « primaire », le site secondaire sera parfaitement équipé pour reprendre le service des applications qui utilise les données.
Les directeurs qui paient les factures sont souvent réfractaires à laisser les machines du second site n'être que de simples « sauvegarde » ; ils préfèrent souvent les utiliser, ce qui est tout à fait possible. Si le site primaire est utilisé pour les « activités transactionelles », les répliques du site secondaires peuvent être utilisée pour produire des rapports qui ne nécessitent pas de données synchronisées à la seconde près.
-
La symétrie de cette configuration signifie que si vous avez deux applications transactionelles nécessitant une protection contre les pannes, il est plus rapide d'avoir un ensemble de réplication supplémentaire afin que chaque site soit le site « primaire » d'une application, et que la destruction d'un site soit compensée par la consolidation des services sur le site restant.
On pourrait également parler ici de tunnels SSH...
Voix
d'écoute
