Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
171 lines (142 sloc) 5.59 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="plainpaths">
<title> Voies de communication &slony1;</title>
<indexterm><primary>voies de communication</primary></indexterm>
<para>
&slony1; utilise le DSN de &postgres; dans trois contextes pour établir
ses accès aux bases de données&nbsp;:
<itemizedlist>
<listitem>
<para>
<xref linkend="admconninfo"/> - contrôle comment un script
<xref linkend="slonik"/> accède aux différents n&oelig;uds.
</para>
<para>
Ces connexions sont celles qui vont de votre <quote>poste
d'administration</quote> vers tous les n&oelig;uds du cluster &slony1;.
</para>
<para>
Il est <emphasis>vital</emphasis> que vous ayez des connexions depuis
l'emplacement central où les scripts <xref linkend="slonik"/> sont
exécutés vers chacun des n&oelig;uds du réseau. Ces connexions sont
uniquement utilisées brièvement pour effectuer les quelques requêtes
<acronym>SQL</acronym> nécessaire à l'administration du cluster.
</para>
<para>
Puisque ces voies de communications sont utilisées brièvement, il est
raisonnable de <quote>regrouper</quote> les connexions temporaires
en utilisant un <link linkend="tunnelling">tunnel SSH</link>.
</para>
</listitem>
<listitem>
<para>
Le paramètre DSN de &lslon;.
</para>
<para>
Le paramètre DSN passé à chaque &lslon; indique la voie de communication
à utiliser par le processus &lslon; et la base qu'il gère.
</para>
</listitem>
<listitem>
<para>
<xref linkend="stmtstorepath"/> - contrôle comment les démons &lslon;
communiquent avec les n&oelig;uds distants. Ces chemins sont stockés
dans la table <xref linkend="table.sl-path"/>.
</para>
<para>
Vous <emphasis>devez</emphasis> forcément avoir une voie de communication
entre chaque n&oelig;ud abonné et son fournisseur&nbsp;; les autres voies
sont facultatives et ne seront utilisées que si un chemin dans la table
<xref linkend="table.sl-listen"/> nécessite d'utiliser cette voie
particulière.
</para>
</listitem>
</itemizedlist>
</para>
<para>
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&oelig;ud peut voir les autres via un ensemble
<quote>global</quote> d'adresses réseau. En revanche, cela devient important
pour celles qui ont des configurations de pare-feu complexes, des n&oelig;uds
dans plusieurs lieux et dans le cas où les n&oelig;uds ne sont pas capable de
se parler via un ensemble d'adresses réseau uniforme.
</para>
<para>
Considérons le diagramme suivant, qui décrit un ensemble de six
n&oelig;uds&nbsp;:
<inlinemediaobject>
<imageobject>
<imagedata fileref="complexenv.png"/>
</imageobject>
<textobject>
<phrase>Sites multiples symétriques</phrase>
</textobject>
</inlinemediaobject>
</para>
<itemizedlist>
<listitem>
<para>
DB1 et DB2 sont des bases de données situées dans une <quote>zone de
base de données</quote> sécurisée, protégée de l'extérieur par un
pare-feu à l'exception d'adresses spécifiquement contrôlées.
</para>
<para>
Supposons que DB1 soit le n&oelig;ud d'origine du système de réplication.
</para>
</listitem>
<listitem>
<para>
DB3 se situe dans une <quote>DMZ</quote> du même site&nbsp;; elle est
considérée comme un <quote>fournisseur</quote> &slony1; pour les
n&oelig;uds distants.
</para>
</listitem>
<listitem>
<para>
DB4 est la contrepartie de DB3 dans une <quote>DMZ</quote> au sein du
second site (site de reprise en cas de panne). Son rôle dans cette
configuration est de <quote>nourrir</quote> les serveurs de la zone de
base de données sécurisée du second site.
</para>
</listitem>
<listitem>
<para>
DB5 et DB6 sont les équivalents de DB1 et DB2, mais sont dans ce cas
configurés comme des n&oelig;uds abonnés.
</para>
<para>
En supposant qu'un désastre se produise sur le site <quote>primaire</quote>,
le site secondaire sera parfaitement équipé pour reprendre le service des
applications qui utilise les données.
</para>
<para>
Les directeurs qui paient les factures sont souvent réfractaires à
laisser les machines du second site n'être que de simples
<quote>sauvegarde</quote>&nbsp;; ils préfèrent souvent les utiliser, ce
qui est tout à fait possible. Si le site primaire est utilisé pour les
<quote>activités transactionelles</quote>, 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.
</para>
</listitem>
<listitem>
<para>
La symétrie de cette configuration signifie que si vous avez
<emphasis>deux</emphasis> 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
<quote>primaire</quote> d'une application, et que la destruction d'un
site soit compensée par la consolidation des services sur le site
restant.
</para>
</listitem>
</itemizedlist>
<para>
On pourrait également parler ici de tunnels SSH...
</para>
</sect1>