root/traduc/trunk/slony/plainpaths.xml

<?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 DSNs de &postgres; dans trois contextes pour établir
  ses accÚs aux bases de données :

<itemizedlist>

<listitem><para> <xref linkend="admconninfo"/> - contrÃŽle comment un script
<xref linkend="slonik"/> accÚde aux différents noeuds.</para>

<para> Ces connexions sont celles qui vont de votre <quote>poste d'administration</quote> 
  vers tous les noeuds 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 noeuds 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; DSN. </para>

<para> Le paramÚtre DSN passé à chaque &lslon; indique quel voie de communication
  doit être utilisée entre 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 noeuds 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 noeud abonné et son fournisseur; les autres voies sont facultatives.
  et ne seront utilisées que si un chemin dans la table 
   <xref linkend="table.sl-listen"/> est 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 noeud
  peut voir les autres via un ensemble d'adresses réseau <quote>global</quote>.
  En revanche, cela devient important pour celles qui ont des configurations de pare-feu
  complexes, des noeuds dans plusieurs lieux et le cas où les noeuds 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 noeuds

<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 noeud d'origine du systÚme de réplication.</para></listitem>

<listitem><para> DB3 se situe dans une <quote>DMZ</quote> du même site;
elle est considérée comme un <quote>fournisseur</quote> &slony1; pour les noeuds 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 noeuds abonnés.</para>

<para> En supposant qu'un désastre se produise sur le site <quote>primaire</quote>,
  le second site sera parfaitement équipé pour reprendre le service des applications
  qui utilise les données.</para>

<para> Les directeurs qui paient les factures sont souvent retissants 
  à laisser les machines du second site n'être que de simples  <quote>sauvegarde</quote>;
  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écessite 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 un 
    protection contre les pannes, il est plus rapide d'avoir de 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></para> 

<para> On pourrait également parler ici de tunnels SSH....</para>

</sect1>