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 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>