21. Scripts d'administration

Un certain nombre de scripts ont été développés tout au long de l'histoire de Slony-I™ pour aider les utilisateurs à gérer leurs clusters. Cette section ainsi que celle sur le Section 5, « Surveillance » et la Section 6, « Maintenance » décrit leur utilisation.

21.1. Les scripts altperl

Il existe un ensemble de scripts qui simplifie l'administration de plusieurs instances Slony-I™. Ces scripts supportent une nombre variable de nœuds. Ils peuvent être installés pendant le processus d'installation :

./configure --with-perltools

Ceci va produire un certain nombre de scripts avec le préfixe slonik_. Ils éliminent les risques de confusion en se référençant à un fichier central de configuration qui contient les détails de la configuration de votre site. Un exemple documenté de ce fichier est fourni dans altperl/slon_tools.conf-sample. La plupart dispose également d'une aide en ligne grâce à l'option "--help", ce qui les rend plus facile à prendre en main et à utiliser.

La plupart des scripts de génération Slonik utilise la sortie STDOUT. Pendant un temps, les commandes étaient passées directement à slonik(1) pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop « agressive » car de légères coquilles dans la ligne de commande peuvent conduire, dans certains cas, à des situations calamiteuses. Tout administrateur qui se respecte doit relire le script avant de l'envoyer à slonik(1).

21.1.1. Gestion de multiples clusters

La variable d'environnement SLONYNODES est utilisée pour déterminer le fichier de configuration Perl qui sera utilisé pour contrôler les nœuds du cluster Slony-I™. Si elle n'est pas fournie, le fichier slon_tools.conf situé dans l'emplacement par défaut sera utilisé.

Voici la liste des variables qui peuvent être configurées :

$CLUSTER_NAME=orglogs; # Quel est le nom du cluster de réplication ?
$LOGDIR='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire des logs ?
$APACHE_ROTATOR="/opt/twcsds004/OXRS/apache/rotatelogs"; # Si ce paramètre est défini, il indique où trouver le gestionnaire de gestion des traces d'Apache
foldCase # Si la valeur est 1, les noms d'objet (y compris les noms de schéma) sont transformés en minuscule. Par défaut, les noms d'objets restent inchangés. Notons que PostgreSQL™ lui-même transforme les noms d'objets en minuscule. Si vous créez une table avec la commande CREATE TABLE MA_TABLE (Id INTEGER, MoNChamp text);, le résultat sera équivalent à create table ma_table (id integer, monchamp text);, le nom de la table et celui de ses champs seront transformés en minuscule.

Vous pouvez ensuite définir un ensemble de nœuds qui participeront à la réplication en utilisant plusieurs appels à la fonction add_node().

add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437, user => 'postgres', node => 4, parent => 1);

Les paramètres de la fonction add_node() sont les suivants :

my %PARAMS =   (host=> undef,                # nom de l'hôte
                        dbname => 'template1',       # nom de la base
                      port => 5432,          # numéro du port
                      user => 'postgres',    # utilisateur de la connexion
                      node => undef,         # numéro du nœud
                      password => undef,     # mot de passe de l'utilisateur
                      parent => 1,           # l'identifiant du nœud père
                      noforward => undef     # ce nœud doit-il retransmettre les modifications ?
                      sslmode => undef        # mode SSL - détermine la priorité 
                                              # d'utilisation de la couche SSL
                                              # = disable,allow,prefer,require
);

21.1.2. Configuration d'un ensemble de réplication

La variable d'environnement UNIX SLONYSET est utilisée pour déterminer le fichier de configuration à lire pour connaître les objets qui sont contenus dans un ensemble donné.

Contrairement à SLONYNODES, qui est essentielle pour tous les scripts de génération slonik(1), celle-ci n'est nécessaire que lorsqu'on exécute create_set car il s'agit du seul script qui contrôle le placement des tables dans les différents ensembles de réplication.

21.1.3. slonik_build_env

Cette commande interroge la base de données et produit un résultat qui peut être utilisé dans slon_tools.conf, notamment :

une série d'appel à add_node() pour configurer le cluster
les tableaux @KEYEDTABLES, @SERIALT et @SEQUENCES

21.1.4. slonik_print_preamble

Cette commande produit simplement le « préambule » qui est nécessaire à chaque script slonik. En fait, elle fournit un « squelette » de script slonik qui ne fait pas d'action particulière.

21.1.5. slonik_create_set

Cette commande nécessite que les variables SLONYSET et SLONYNODES soient configurées. Elle permet de produire le script slonik qui configure un ensemble de réplication en décrivant les tables et les séquences qui seront répliquées.

21.1.6. slonik_drop_node

Cette commande produit un script Slonik qui supprime un nœud du cluster Slony-I™.

Ceci représente un risque potentiellement très dangereux car cela élimine un ensemble de réplication complet en une commande. Une erreur de saisie qui indiquerait un mauvais ensemble serait dévastateur. À comparer avec Section 21.1.25, « slonik_unsubscribe_set » et Section 21.1.6, « slonik_drop_node » ; avec ces deux-là, tenter de supprimer un abonnement ou un nœud vital à vos opérations sera bloqué (via une constrainte de clé étrangère) s'il existe un abonné qui pourrait être affecté. En contraste, il n'y aura pas de messages d'avertissements ou d'erreurs si vous supprimez un ensemble ; l'ensemble disparaitra tout simplement de la réplication.

21.1.7. slonik_drop_set

Cette commande produit un script Slonik qui supprime un ensemble de réplication (c'est-à-dire un groupe de tables et de séquences).

21.1.8. slonik_drop_table

Cette commande produit un script Slonik qui supprime une table de la réplication. Elle nécessite en entrée l'identifiant de la table (disponible dans la table sl_table).

21.1.9. slonik_execute_script

Cette commande produit un script pour effectuer des changements DDL sur un ensemble de réplication.

21.1.10. slonik_failover

Cette commande produit un script qui demande une bascule d'urgence entre un nœud mort et une nouvelle origine.

21.1.11. slonik_init_cluster

Cette commande produit un script Slonik qui intialise un cluster Slony-I™ tout entier, y compris les nœuds, les voies de communications et les voies d'écoute.

21.1.12. slonik_merge_sets

Cette commande produit un script Slonik qui fusionne deux ensembles de réplication.

21.1.13. slonik_move_set

Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de réplication vers un autre nœud.

21.1.14. réplication_test

Ce script vérifie que Slony-I™ réplique correctement les données.

21.1.15. slonik_restart_node

Cette commande produit un script Slonik qui demande le redémarrage d'un nœud. Elle était particulièrement utile avant la version 1.0.5, lorsque les nœuds étaient bloqués suite à la mort du démon slon.

21.1.16. slonik_restart_nodes

Cette commande produit un script Slonik qui redémarre tous les nœuds du cluster. Elle n'est pas très utile.

21.1.17. slony_show_configuration

Cette commande affiche la configuration de l'environnement (c'est-à-dire la variable SLONYNODES).

21.1.18. slon_kill

Cette commande tue le chien de garde slony et tous les démons slon pour un ensemble de réplication donné. Elle ne fonctionne que si ces processus fonctionnent sur l'hôte local, bien sûr !

21.1.19. slon_start

Cette commande démarre le démon slon pour un cluster et un nœud donnés, elle utilise le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.

21.1.20. slon_watchdog

Processus utilisé par slon_start.

21.1.21. slon_watchdog2

Ce script est un chien de garde plus malin ; il surveille un nœud donné et relance le processus slon s'il constate qu'aucune modification ne s'est produite depuis 20 minutes ou plus.

Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon s'arrête sans crier gare.

21.1.22. slonik_store_node

Cette commande ajoute un nœud dans un cluster.

21.1.23. slonik_subscribe_set

Ce script génère un script Slonik script pour abonner un nœud donné à un ensemble donné.

21.1.24. slonik_uninstall_nodes

Cette commande parcourt le cluster et supprime le schéma Slony-I™ sur tous les nœuds. Vous pouvez utiliser cet outil si vous souhaitez détruire la réplication sur l'ensemble du cluster. Comme ce script détruit des informations, il s'agit d'un script TRÈS dangereux !

21.1.25. slonik_unsubscribe_set

Cette commande produit un script Slonik qui désabonne un nœud d'un ensemble de réplication.

21.1.26. slonik_update_nodes

Cette commande produit un script Slonik qui incite tous les nœuds à mettre à jour les fonctions Slony-I™. Elle est utile lorsque l'on effectue un changement de version de Slony-I™.

21.2. mkslonconf.sh

Ce script shell est conçu pour parcourir un cluster Slony-I™ et produire un ensemble de fichiers slon.conf qui pourront être utilisés via l'option slon -f slon.conf.

Lorsque toute la configuration est placée dans un fichier pour chaque slon(1), on peut alors facilement les invoquer, sans risquer d'oublier l'option -a, ce qui peut provoquer le crash d'un nœud en mode log shipping.

Pour lancer le script, il faut configurer l'environnement de la manière suivante :

Tout d'abord, l'environnement doit être configuré avec les paramètres adéquats pour que libpq puisse se connecter à une des bases de données du cluster. Vous devez donc définir une combinaison parmi les variables d'environnement suivantes :
- PGPORT
- PGDATABASE
- PGHOST
- PGUSER
- PGSERVICE
SLONYCLUSTER - le nom du cluster Slony-I™ qui doit être « parcouru ».
MKDESTINATION - un répertoire qui accueillera la configuration ; le script crée un dossier MKDESTINATION/$SLONYCLUSTER/conf pour les fichiers de configuration des démons slon(1) et un dossier MKDESTINATION/$SLONYCLUSTER/pid pour que slon(1) y stocke les fichiers PID.
LOGHOME - un répertoire qui accueillera les fichiers de log ; un dossier nommé $LOGHOME/$SLONYCLUSTER/node[numéro] sera créé pour chaque nœud.

Pour chaque « nouveau » nœud qu'il découvre, ce script va créer un nouveau fichier de configuration slon(1).

Avertissement

Il est important de préciser que ce script présente quelques particularités qu'il faut connaître, mais aucune n'est vraiment surprenante.

Le DSN est positionné à la plus petite valeur trouvé pour chaque nœud dans le table sl_path. Vous devrez probablement modifier cette valeur.
Plusieurs paramètres sont initialisés avec leur valeur par défaut ; Vous devrez probablement les réajuster à la main.
Si vous exécutez les processus slon(1) sur de multiples nœuds (par exemple - si vous utilisez Slony-I™ à travers un réseau WAN), ce script va joyeusement créer des fichiers de configuration pour des slon(1)s que vous comptez lancer sur un hôte différent.

Vérifiez bien les nœuds configurés avant de redémarrer les slon(1)s.

En général, cela provoque des inconvénients mineurs comme, par exemple, un slon(1) fonctionnant de manière inapproprié, échouant suite à un problème de connectivité (ce qui ne provoque pas de dégâts !), ou fonctionnant moins efficacement vu qu'il se trouve du mauvais coté du « tuyau ».

D'un autre côté, si vous faites fonctionner un nœud en mode log shipping sur le site distant, l'arrivée d'un slon(1) qui ne collecte pas les logs peut ruiner une semaine complète d'activité.

Les fichiers produits par mkslonconf.sh sont spécifiquement conçus pour gérer des slon(1)s sur de multiples clusters avec le script décrit dans la section suivante...

21.3. start_slon.sh

Ce script du style rc.d est disponible à partir de la version 2.0 de Slony-I™ ; il fournit un moyen automatique de :

Démarrer slon(1), via la commande start_slon.sh start

Il essaie de démarrer slon(1), en vérifiant au préalable qu'il n'est pas déjà en cours d'exécution, que la configuration existe et qu'il dispose des droits pour écrire sur le journal applicatif associé. Voici les échecs possibles :

Il n'y a pas de fichier de configuration slon.
Un processus slon(1) est trouvé avec le PID indiqué via la configuration.
L'emplacement spécifié via SLON_LOG n'est pas disponible en écriture.
Arrêt du slon(1), via start_slon.sh stop

Ceci échoue (ne fait rien) si le PID (indiqué via le fichier de configuration) n'existe pas.
Surveiller le statut de slon(1), via start_slon.sh status

Ceci indique si le processus slon(1) est en cours d'exécution et, dans ce cas, affiche l'identifiant du processus.

Les variables d'environnement suivantes sont utilisées pour contrôler la configuration de slon(1) :

SLON_BIN_PATH

Ceci indique où trouver le programme slon(1).

SLON_CONF

Ceci indique l'emplacement du fichier de configuration slon contrôlant le comportement de slon(1).

Notez que ce fichier doit contenir la valeur de l'option log_pid_file ; c'est nécessaire pour permettre à ce script de détecter si slon(1) est en cours d'exécution.

SLON_LOG

Cette option indique l'emplacement où les journaux applicatifs de slon(1) sont stockés. Il existe une option slon_conf_syslog pour que slon(1) utilise syslog pour gérer ses journaux applicatifs ; dans ce cas, vous pouvez configurer SLON_LOG à /dev/null.

Notez que ces variables d'environnement peuvent être configurées soit dans le script soit dans les valeurs passées dans l'environnement. Ce dernier rend l'utilisation de ce script plus simple lorsqu'il combine Section 25, « Banc d'essai Slony-I » pour être régulièrement testé.

21.4. launch_clusters.sh

Voici un autre script shell qui utilise la configuration produite par mkslonconf.sh et qui a pour but de supporter une approche sur l'exécution de Slony-I™ consistant à vérifier régulièrement (c'est-à-dire avec un cron) que les processus slon(1) sont en cours d'exécution.

Il utilise les variables d'environnement suivantes :

PATH qui doit contenir, de préférence au début, le chemin vers les binaires slon(1) qui doivent être exécutés.
SLHOME indique le répertoire « home » qui contient les fichiers de configuration de slon(1) ; ces fichiers doivent être rangés en sous-répertoires, un pour chaque cluster, avec un nom de fichier du type node1.conf, node2.conf et ainsi de suite.

Le script utilise la commande find $SLHOME/$cluster/conf -name "node[0-9]*.conf" pour trouver les fichiers de configuration slon(1).

Si vous déplacez ces fichiers ou si vous les renommez, ils ne seront pas trouvés ; c'est une façon très simple de supprimer des nœuds.
LOGHOME indique le répertoire « home » pour le stockage des journaux applicatifs.

Ce script ne nécessite pas l'utilisation du gestionnaire de journaux applicatifs d'Apache, sachant que PostgreSQL™ version 8 gère lui-même la rotation des journaux applicatifs, il semble inopportun de garder une dépendance à une « technologie » de rotation spécifique.
CLUSTERS est la liste des clusters Slony-I™ qui sont gérés.

En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il relancera tous les processus slon(1) manquants.

21.5. slony1_extract_schema.sh

Si vous souhaitez créer un nouveau nœud, après la création du cluster, le script slony1_extract_schema.sh vous aidera dans cette tache.

La commande d'exécution peut ressembler à la ligne suivante :

PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll

Elle réalise les actions suivantes :

Elle fait un dump du schéma du nœud origine, y compris les informations du schéma du cluster Slony-I™.

Notons que les variables d'environnement PGPORT et PGHOST fournissent des informations additionnelles sur l'emplacement de la base de données.
Ces informations sont chargées dans une table temporaire fraîchement créée : temppayroll.
Les OID de table et de séquence dans les tables Slony-I™ sont corrigées pour pointer vers la configuration de la base temporaire.
Un script slonik est lancé pour effectuer l'action SLONIK UNINSTALL NODE(7) sur la base temporaire. Ceci élimine toutes les tables et le schéma spécifique à Slony-I™, et supprime les triggers Slony-I™ des tables répliquées.
Enfin, la commande pg_dump est lancée sur la base temporaire, et produit une copie nettoyée du schéma sur la sortie standard.

21.6. slony-cluster-analysis

Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters Slony-I™, il peut devenir pénible de suivre et de documenter votre architecture. L'outil suivant peut vous y aider.

slony-cluster-analysis.sh est un script shell conçu pour fournir une analyse à long terme de la configuration d'un cluster Slony-I™. Vous passez les variables d'environnement libpq habituelles (PGHOST, PGPORT, PGDATABASE et ainsi de suite) pour se connecter à un membre du cluster Slony-I™, et passer le nom du cluster comme argument.

Le script effectue alors les actions suivantes :

Lancement d'une séries de requêtes sur les tables Slony-I™ pour obtenir la liste des nœuds, des voies de communication, des ensembles de réplication et des tables.
Ces données sont stockées dans un fichier temporaire situé dans /tmp.
Une comparaison est effectuée entre la configuration présente et la configuration trouvée lors de la dernière exécution du script. Si la configuration a changé, un courriel contenant les différences (produit avec diff) est envoyée à l'adresse spécifiée.
Si la configuration a changé, l'ancien fichier de configuration est renommé pour indiquer quand le script a remarqué le changement.
Finalement, la configuration courante est stockée dans le dossier LOGDIR dans un fichier nommé cluster.last.

Il existe un exemple de script « d'encapsulation », slony-cluster-analysis-mass.sh, qui permet de pointer vers un ensemble de clusters Slony-I™.

Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans :

la documentation de l'état courant du système
la surveillance des changements de configuration.

21.7. Génération de scripts slonik avec configure-replication.sh

Le script configure-replication.sh, situé dans le répertoire outil, est conçu pour automatiser la génération de scripts slonik de configuration de la réplication. La configuration de ce script reprend la même approche que le Section 25, « Banc d'essai Slony-I ».

Ce script utilise beaucoup (peut-être énormément, si votre configuration est particulièrement complexe) de variables d'environnement pour déterminer la forme de la configuration du cluster. Il utilise massivement les valeurs par défaut et, dans la plupart des cas, peu de valeurs doivent être positionnées afin d'obtenir une configuration viable.

21.7.1. Valeurs globales

Certaines valeurs sont utilisées universellement partout sur le cluster :

CLUSTER: Nom du cluster Slony-I
NUMNODES: Nombre de nœuds à configurer
PGUSER: Nom du super-utilisateur qui contrôle la réplication
PGPORT: Numéro du port par défaut
PGDATABASE: Nom de la base de données par défaut
TABLES: Liste de noms complets de tables (par exemple - un nom incluant le schéma tel que public.ma_table)
SEQUENCES: Liste de noms complets de séquences (par exemple - un nom incluant le schéma tel que public.ma_sequence)

Des valeurs par défauts sont fournies pour chacune de ces valeurs, si bien que si vous lancez configure-replication.sh sans configurer aucune variable d'environnement, vous obtiendrez un ensemble de scripts slonik. Bien sûr, ils ne correspondront pas aux bases que vous voudrez configurer...

21.7.2. Valeur spécifique à un nœud

Pour chaque nœ, il y a également quatre variables d'environnement ; pour le nœud 1 :

DB1: La base de données à laquelle les scripts doivent se connecter
USER1: Le super-utilisateur utilisé pour la connexion
PORT1: Le port
HOST1: L'hôte

Il est très probable que DB*, USER* et PORT* correspondent aux variables globales PGDATABASE, PGUSER et PGPORT décrites précédemment ; conserver cette correspondance est souvent une bonne chose.

En revanche, les valeurs HOST* doivent être définies explicitement pour HOST1, HOST2, ... car il n'est pas très malin de mettre en place un système de réplication si toutes les bases redondantes se trouvent sur le même serveur !

21.7.3. Les scripts slonik générés

Les scripts de configuration slonik sont générés dans un répertoire temporaire à l'intérieur de /tmp. Leur usage est le suivant :

preamble.slonik est un fichier « préambule » contenant les informations de connexion utilisées par les autres scripts.

Vérifier attentivement celui-ci ; vous pourrez le réutiliser pour les futures opérations de maintenance que vous effectuerez sur le cluster.
create_nodes.slonik

Ce script est le premier qu'il faut lancer ; il configure les nœuds spécifiés en nœud Slony-I™, en y ajoutant les tables et les autres objets spécifiques de Slony-I™.

Vous pouvez/devez lancer les processus slon juste après cette étape.
store_paths.slonik

Le second script à exécuter ; il indique comment les slon(1) doivent communiquer entre eux. Ce script suppose que tous les slon(1) peuvent parler à tous les nœuds, ce qui n'est peut-être pas exact dans un environnement peuplé de pare-feu complexes. Si cette supposition n'est pas correcte, vous devez modifier ce script pour corriger les voies de communications.
create_set.slonik

Ce script configure l'ensemble de réplication composé de toutes les tables et les séquences présentes dans le schéma de la base de données de votre application.

Lorsque vous lancez ce script, la seule action menée est l'ajout de triggers sur le nœud origine (nœud #1) qui vont commencer à collecter les mises à jours. La réplication ne commencera qu'à l'étape #5...

Il y a deux suppositions dans ce scripts qui peuvent ne pas être valides dans certaines circonstances :
- que toutes les tables et les séquences soit répliquées
  
  Ceci n'est pas valide lorsque de nouvelles tables sont ajoutée dans votre schéma et qu'elles ne sont pas ajoutées dans la liste TABLES.
- que toutes les tables sont définies avec des clefs primaires
  
  La bonne pratique est de toujours créer et utiliser de vraies clefs primaires. Si vous avez des tables qui nécessitent de choisir une clef primaire candidate ou qui nécessite la création d'une clef additionnelle avec la commande SLONIK TABLE ADD KEY(7), vous devez modifier ce script à la main pour l'accommoder.
subscribe_set_2.slonik

et 3, 4, 5, si vous configurez d'autres nœuds...

Ceci est l'étape qui « déclenche » la réplication.

Ce script fait la supposition que tous les nœuds abonnés voudront s'abonner directement au nœud origine. Si vous souhaitez mettre en place des « sous-clusters » avec peut-être un nœud maître dans chaque centre de données, vous devez modifier ces scripts.

Les processus slon doivent fonctionner au moment où vous réalisez cette étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.

21.8. slon.in-profiles

Dans le répertoire tools, le script slon.in-profiles permet de lancer des instances slon(1) lors du démarrage du système. Il est conçu pour interagir avec le système des ports de FreeBSD.

21.9. duplicate-node.sh

Dans le répertoire tools, le script duplicate-node.sh aide à créer un nouveau nœud en dupliquant un des nœuds du cluster.

Ce script attend les paramètres suivants :

le nom du cluster ;
le numéro du nouveau nœud ;
le nœud origine ;
le nœud répliqué ;
le nouveau nœud ;

Pour chaque nœud spécifié, le script permet de préciser les paramètres de type libpq pour PGHOST, PGPORT, PGDATABASE et PGUSER. Le fichier .pgpass peut être utilisé pour le stockage des mots de passe, ce qui est généralement considéré comme une bonne pratique. Lorsqu'elles ne sont pas définies, ces valeurs peuvent hériter des variables d'environnement libpq, ce qui est pratique quand on réalise des tests. Toutefois, lorsque que ce script est utilisé « de manière brutale », il est souvent nécessaire de définir les 14 paramètres disponibles.

Ce script prépare des fichiers, placés dans /tmp, et annonce le nom du répertoire qu'il a créé pour les scripts SQL et slonik(1) de configuration du nouveau nœud.

schema.sql

Ce script est tiré du nœud origine et contient le schéma de données « originel » qui doit être appliqué au départ.
slonik.preamble

Ce fichier « preambule » est utilisé par l'ensemble des scripts slonik ci-dessous.
step1-storenode.slonik

Un script slonik(1) qui configure le nouveau nœud.
step2-storepath.slonik

Un script slonik(1) qui met en place des voies de communication entre le nœud fournisseur et le nouveau nœud.
step3-subscribe-sets.slonik

Un script slonik(1) qui demande la souscription à tous les ensembles de réplication.

Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner un nouveau nœud. La configuration ne doit pas forcément correspondre à une configuration finale, notamment :

Il est souhaitable de construire des voies de communication supplémentaires afin d'assurer leur redondance.
Les scripts générés supposent que le nouveau nœud doit être un nœud transmetteur (« forwarding »), ce qui n'est pas forcément vrai.
Il est parfois souhaitable, une fois que le processus d'abonnement est réalisé complètement, de modifier les abonnements.

Documentation Slony-I 1.2.21 -

Administration Slony-I