root/traduc/trunk/slony/failover.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="failover">
  <title>Effectuer une bascule d'urgence avec &slony1;</title>
  <indexterm><primary>bascule d'urgence</primary>
             <secondary>reprise sur panne</secondary>
  </indexterm>

  <sect2><title>Avant-propos</title>

    <para>&slony1; est un systÚme de réplication asynchrone.  À cause de cela,
      il est presque certain qu'au moment ou le noeud origine d'un ensemble de réplication
      tombe en panne, la derniÚre transaction <quote>committée</quote> sur
      l'origine ne soit pas encore propagée aux abonnés. Les systÚmes qui tombent
      en panne souvent soumis à une forte charge; c'est une des corollaires de la
      loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal
      tombe en panne. La meilleur façon d'éviter cela est d'effectuer une 
      maintenance fréquente.</para>

    <para> Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut
      une façon <quote>professionelle</quote> d'assurer la maintenance d'un systÚme.
      En général, les utilisateurs qui ont besoin de réplication pour
      leur sauvegarde ou leur plan de reprise sur panne, ont également des critÚres
      trÚs stricts en matiÚre de  <quote> temps d'arrêt du systÚme</quote>.
      Pour répondre à ces critÚres, &slony1; ne se contente de fournir des
      méthodes de reprise sur panne, il intÚgre également la notion de 
      transfert d'origine.</para>

    <para> On suppose dans cette partie que le lecteur est familier avec l'utilitaire  <xref linkend="slonik"/>
      et qu'il sait comment mettre en place une systÚme de réplication &slony1; composé de deux noeuds.
    </para>
  </sect2>

  <sect2><title>Bascule contrÎlée</title>

    <indexterm>
     <primary>bascule contrÎlée</primary>
    </indexterm>

    <para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un 
      <quote>abonné</quote> appelé noeud2 (l'esclave).  Une application web, placée
      sur un troisiÚme serveur, accÚde à la base de données sur noeud1.
      Les deux bases sont actives et fonctionnelles, la réplication est 
      est à peu prÚs synchronisée. On contrÎle la bascule avec la commande
      <xref linkend="stmtmoveset"/>.</para>

    <itemizedlist>
<listitem><para> Au moment ou nous écrivons ces lignes, basculer
        vers un autre serveur nécessite que l'application se reconnecte
        à la nouvelle base de donnée. Donc pour éviter toute complication,
        nous éteignons le serveur web. Les utilisateurs qui ont installé
        <application>pg_pool</application> pour gérer les connexions peuvent 
        simplement éteindre le pool.</para>
        
        <para> Les actions à mener dépendent beaucoup de la configuration des applications qui utilisent
        la base de données. En général, les applications qui étaient connectées à 
        l'ancienne base doivent détruire leurs connexions et en établir de nouvelles
        vers la base qui vient d'être promue dans le rÎle du  <quote>/maître/</quote> rÎle.
        Il y a différentes façon de configurer cela, et donc différentes façon d'effectuer 
        la bascule :      
        <itemizedlist>
          <listitem><para> L'application stocke le nom de la base de donnée dans un fichier.</para>
            <para> Dans ce cas, la reconfiguration nécessite de changer la valeur dans ce fichier, d'arrêter
            puis de relancer l'application pour qu'elle pointe vers le nouvel emplacement des données.</para> 
          </listitem>
          
          <listitem><para> Une utilisation pertinente de DNS consiste à créer 
            <ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink> 
            CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud
            qui joue le rÎle du noeud <quote>maître</quote>.</para>
            
            <para> Dans ce cas, la reconfiguration nécessite de changer le CNAME
            pour point et vers le nouveau serveur, de plus il faut probablement relancer
            l'application pour rafraîchir les connexions à la base.</para>
          </listitem>
          
          <listitem><para> si vous utilisez <application>pg_pool</application> ou 
            un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration
            implique de modifier le paramÚtre de cet outil, à part cela  la procédure est similaire
            Ã  l'exemple DNS/CNAME ci-dessus.  </para> 
          </listitem>
        </itemizedlist></para>
        
            

      <para> Le nécessité de redémarrer l'application qui se connecte à la base dépend  
      de la maniÚre dont elle a été conçu et des mécanismes de gestion d'erreurs de 
      connexion qui ont été implémentés; si à la suite d'une erreur elle tente 
      d'ouvrir à nouveau un connexion, alors il n'est pas nécessaire de la relancer.</para>
</listitem>
      <listitem><para> Un petit script <xref linkend="slonik"/> exécute les commandes suivantes :
        <programlisting>
          lock set (id = 1, origin = 1);
          wait for event (origin = 1, confirmed = 2);
          move set (id = 1, old origin = 1, new origin = 2);
          wait for event (origin = 1, confirmed = 2);
        </programlisting></para>
        <para> AprÚs ces commandes, l'origine ( le rÎle du maître) de l'ensemble de réplication 1
        est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient
        un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé
        leurs rÃŽles respectifs.</para>
      </listitem>
      
      <listitem><para> AprÚs la reconfiguration de l'application web (ou
        de <application><link linkend="pgpool"> pgpool </link></application>) pour
        qu'elle se connecte à la base du noeud 2, le serveur web est redémarré et 
        reprend son activité normale.</para>
      
        <para> Lorsqu'on utilise un script shell, pour stopper l'application,
        lancer le script <application>slonik</application>, déplacer les fichiers de configuration
        et relancer l'ensemble, toute la procédure prend en général moins de 10
        secondes.</para>
      </listitem>
        
    </itemizedlist>
    
    <para> Vous pouvez désormais éteindre le serveur qui héberge le noeud 1 et 
      effectuer les opérations de maintenance requise. Lorsque le démon <xref
      linkend="slon"/> du noeud 1 est redémarré, il reprend la réplication,
      et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
      Ã  nouveau pour restaurer la configuration originale.</para>

    <para> Ceci est la meilleure méthode pour ce genre d'opération de maintenance;
      Elle s'effectue rapidement, sous le contrÃŽle d'un administrateur, et elle
      n'implique aucune perte de données.</para>

  </sect2>
  <sect2><title>Bascule d'urgence</title>

  <indexterm>
   <primary>Bascule suite à une panne du systÚme</primary>
  </indexterm>

  <para> Lorsque de graves problÚmes apparaissent sur le serveur 
  <quote>origine</quote>, il est parfois nécessaire d'effectuer une
  bascule ( <xref linkend="stmtfailover"/> ) vers le serveur de sauvegarde. 
  C'est cas de figure qui n'a rien de souhaitable, car les transactions
  <quote>committées</quote> sur le serveur mais pas sur les abonnés, seront 
  perdues. Certaines de ces transactions auront peut-être été annoncées 
  à l'utilisateur final comme <quote>validées</quote>. En conséquence, les
  bascules d'urgence doivent être considérées comme un 
  <emphasis>dernier recours</emphasis>.  Le serveur origine 
  qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps, il est 
  <emphasis>nettement</emphasis>
  préférable d'effectuer une bascule contrÎlée.</para>

  <para> &slony1; ne fournit pas de moyen de détection des pannes du systÚme.
    Abandonner des transactions <quote>committées</quote> est une décision 
    commerciale qui ne peut pas être prise par un systÚme de gestion de base de données.
    Si vous voulez placer les commandes ci-dessous dans un script exécuté
    automatiquement par un systÚme de surveillance, et bien .... ce sont 
    <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique
    de bascule d'urgence. </para>

  <itemizedlist>

  <listitem>
  <para>La commande <xref linkend="slonik"/> 
  <programlisting>
  failover (id = 1, backup node = 2);
  </programlisting>
  </para>

  <para>  ordonne au noeud 2 de se considérer comme le propriétaire 
    (l'origine) de tous les sets que le noeud 1 possédait. Si il 
    existe des noeuds supplémentaire dans le cluster  &slony1;
    Tous les noeuds abonnés au noeud 1 sont avertis du changement.
    <application>Slonik</application> va aussi envoyer une requête 
    à chaque abonné pour déterminer quel noeud à le plus haut niveau 
    de synchronisation (<emphasis>c'est à dire</emphasis> - la derniÚre
    transaction <quote>committée</quote>) pour chaque ensemble de réplication.
    et la configuration sera changé de façon à ce que le noeud 2 applique
    d'abord ces transactions finales, avant d'autoriser l'accÚs en écriture
    sur les tables.</para>

  <para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1
    considéreront désormais le noeud 2 comme leur fournisseur de données
    pour cet ensemble de replication. Cela signifie qu'une fois que la 
    commande de bascule d'urgence est complétée, plus aucun noeud du cluster ne 
    reçoit d'information de la part du noeud 1.</para>

  </listitem>

  <listitem>
  <para> Reconfigurer et relancer l'application ( ou
  <application>pgpool</application>) pour qu'elle se reconnecte
  au noeud 2.</para>
  </listitem>

  <listitem> <para> Purger le noeud abandonné </para>

  <para> Vous découvrirez, aprÚs la bascule, qu'il existe encore
    beaucoup de références au noeud 1 dans la table <xref linkend="table.sl-node"/>,
    ainsi que ses tables associées telle que <xref linkend="table.sl-confirm"/>;
    puisque des données sont toujours présentes dans <xref linkend="table.sl-log-1"/>,
    &slony1; ne peut pas purger immédiatement le noeud. </para>

  <para> Une fois que la bascule sera complÚte et que le noeud 2 accepte
    les opérations d'écriture sur les tables répliquées, il faut supprimer
    toutes informations de configuration rémanentes avec la commande 
     <xref linkend="stmtdropnode"/> :

  <programlisting>
  drop node (id = 1, event node = 2);
  </programlisting>
  </para>

  <para> Supposons que la panne résulte d'un problÚme matériel catastrophique
    sur le noeud 1, il est possible qu'il ne <quote>reste</quote> plus
    rien sur le noeud 1. Si la panne n'est pas <quote>totale</quote>,
    ce qui est souvent le cas lors d'une coupure réseau, vous découvrirez
    que le noeud 1  <quote>imagine</quote> toujours que rien n'a changé 
    et qu'il est dans le même état qu'avant la panne. Reportez-vous à la 
    section <xref linkend="rebuildnode1"/> pour plus de détails sur ce
    que cela implique.</para>

  </listitem>
  </itemizedlist>

  </sect2>

  <sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title>

  <indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>

  <para> Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
    il est important de le faire <emphasis>avec soin</emphasis>. Vous
    devez être sur que le noeud en panne est réellement en panne, et vous
    être capable de vous assurer que le noeud en panne ne redémarre pas, 
    ce qui entraînerait un conflit entre deux noeuds capables 
    de jouer le rÎle du <quote>maître</quote>. </para>

  <note> <para> Le fait de <quote>tirer une balle dans la 
        tête du serveur en panne</quote> ne pose pas directement
  de problÚme à la réplication ou à &slony1;; &slony1; supporte
  cela de maniÚre assez gravieuse, car une fois qu'une est marqué
  comme étant en panne, les autres noeuds <quote>l'oublier</quote>
  et l'ignorer. Le problÚme se situe plutÎt au niveau de
  <emphasis>votre application</emphasis>. 
  Supposons que le noeud en panne soit capable de répondre
  aux requêtes de votre application, <emphasis>cela</emphasis> 
  va certainement poser un problÚme qui n'a rien à voir avec &slony1;.
  Le problÚme est que deux bases de données sont en mesure de répondre
  en tant que <quote>maître</quote>. </para> </note>

  <para> Lorsqu'une bascule d'urgence est effectuée, il faut un 
    mécanisme pour dégager de force le noeud en panne hors du réseau
    afin d'éviter toute confusion au niveau des applications.
    Cela peut être fait via une interface SNMP qui effectue
    une partie des opérations suivantes :

  <itemizedlist>

  <listitem><para> Éteindre l'alimentation du serveur en panne. </para> 

  <para> Si l'on en fait attention, le serveur peut réapparaître dans le
    systÚme de réplication lorsque les administrateurs le rallume. </para>

  </listitem>

  <listitem><para> Modifier de rÚgles de pare-feu ou d'autres configuration
      pour exclure du réseau l'adresse IP du serveur en panne. </para>

  <para> Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
    cette approche permet de supprimer/désactiver les adresses utilisées l'application,
    tout en conservant les adresses <quote>administratives</quote> afin 
    que le serveur reste accessible par les administrateurs systÚmes.
  </para> </listitem>

  </itemizedlist>
  </para>
  </sect2>

  <sect2 id="rebuildnode1"><title>AprÚs la bascule d'urgence, reconfiguration
  de l'ancienne origine</title>

  <indexterm><primary>reconstruction aprÚs une bascule d'urgence</primary></indexterm>

  <para> Ce qui arrive au noeud en panne dépend beaucoup de la nature de la catastrophe
    qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud
    a été abandonné à cause de la destruction physique des disques de stockage,
    il n'y a plus grand-chose à faire. D'un autre coté, si un noeud a été abandonné
    à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal
    du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications 
    sont restaurées, le fait est que le commande <command>FAIL OVER</command> 
    rend obligatoire l'abandon du noeud qui était en panne.</para>

  <para> AprÚs ce genre de bascule d'urgence, les données stockées sur le 
    noeud 1 seront rapidement et de plus en plus désynchronisées. 
    par rapport aux autres noeuds. Elles doivent être considérées comme 
    corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans 
    le cluster de réplication et qu'il redevienne le noeud origine est de
    le reconstruire à partir de zéro comme un abonné, de le laisser rattraper
    son retard, puis d'effectuer la procédure de bascule contrÎlée.
    </para>

  <para> Une bonne raison de <emphasis>ne pas</emphasis> faire cela 
    automatiquement est que d'importante mises à jour ( d'un point de
    vue <emphasis>commercial</emphasis> ) ont pu être 
  <quote>committée</quote> sur le systÚme en panne.
  Vous souhaiterez probablement analyser les derniÚres transactions que 
  le noeud a réalisé avant de tomber en panne, afin de voir si certaines
  doivent être ré-appliquer sur le cluster <quote>actif</quote>.
  Par exemple, si quelqu'un réalisait des opérations bancaires impactant
  des comptes clients au moment de la panne, il est souhaitable de 
  ne pas perdre cette information.</para>

  <warning> <para> On a observé certains résultats étranges lorsqu'un 
      noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante,
      par opposition aux pannes du systÚme de stockage. Dans de tel scénarios,
      le noeud <quote>en panne</quote> dispose d'une base de données en 
      parfait état de marche; le fait est qu'ayant été coupé des autres noeuds,
      il <quote>crie en silence</quote>. </para>

  <para> Lorsque la connexion réseau est réparée, ce noeud peut réapparaître
    et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les 
    autres noeuds du cluster &slony1;. </para>

  <para> En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur 
    ce noeud. Les autres noeud du cluster ne sont pas du tout perturbés;
    ils savent que ce noeud est  <quote>mort</quote>, et qu'ils doivent 
    l'ignorer. Mais il est impossible de savoir cela en regardent le noeud 
    qui a était <quote>en panne</quote>.
  </para> 

  <para> Ceci nous ramÚne au fait que &slony1; n'est pas un outil de surveillance
    de réseau. Vous devez avoir des méthodes claires pour signaler aux applications et
    aux utilisateurs quels bases de données doivent être utilisées. En l'absence
    de telles méthodes, la réplication ne fera qu'empirer le potentiel de confusion,
    et les bascules d'urgence seront un énorme potentiel de confusion.
  </para>
  </warning>

  <para> Si la base de données est trÚs volumineuse, la construction du noeud 1 
    peut prendre plusieurs heures; ceci est une autre raison de considérer 
    les bascules d'urgence comme un <quote>dernier recours</quote> non souhaitable.
  </para>

  </sect2>

</sect1>