ADMINISTRATEUR DE SYSTEME D`INFORMATION

VAE
VALIDATION DES ACQUIS DE L'EXPÉRIENCE
ADMINISTRATEUR
DE SYSTEME
D’INFORMATION
Curriculum vitae
IP1. Programmation Orientée
Objet
IP2. Systèmes d’Information
IP3. Internet
IP4. Systèmes d’Exploitation
et Réseaux
IP6. Bases de Données et
Internet
IP7. Programmation Orientée
Objet et Bases de Données
IP8. Programmation Orientée
Objet et Internet
Stéphane Gimenez
LICENCE
NOUVELLES
TECHNOLOGIES
INFORMATIQUES
2013
CV
ADMINISTRATEUR DE
SYSTEME D'INFORMATION
DIPLOMES
2008 Formation diplômante niveau III développeur informatique, AFPA, Marseille
1992 BEP Structures Métalliques, lycée Vauvenargues, Aix en provence
FORMATIONS PROFESSIONNELLES
Journées Développement Logiciel 2011 (2011, 2 jours, CNRS DR14)
✔ Atelier sur l'utilisation des patrons de conception (Design Pattern)
!
Langage Python (2010, 5 jours, CNRS DR12)
✔ Découverte de Python, initiation à la syntaxe et aux structures de données.
✔ Python Orienté Objet
✔ Interopérabilité de Python et modules scientifiques
!
Langage UML (2009, 4 jours, CNRS DR12)
✔! Diagramme de cas d'utilisation, modélisation statique et dynamique
✔! Mise en œuvre d'UML avec les méthodes agiles et Unified Process
AUTOCAD (1998, 10 jours, Acticad)
COMPETENCES INFORMATIQUES
Développement d'applications
✔ JAVA/J2EE, Perl, C, C++, Python
✔ Swing, Catalyst
✔ Eclipse, NetBeans, Padre
Développement web
✔ HTML5, CSS3, Javascript, JQuery, ExtJS, PHP, XML, JSP, Ajax
Base de données
✔ PostgreSQL, Oracle, MySQL
✔ Merise, SQL
Systèmes et Réseaux
✔ Linux, Windows, Apache (HTTP, Tomcat6), PgPool-II
EXPERIENCES PROFESSIONNELLES
Depuis janvier 2009, Laboratoire d'astrophysique de Marseille (LAM) – CNRS
Assistant ingénieur au Centre de données astrophysique de Marseille (CeSAM)
Mission : Assurer la maîtrise d’œuvre des systèmes d’information cosmologiques du CeSAM en
définissant les procédures informatiques permettant l’administration et l’exploitation des bases de
données, ainsi que le suivi et la sécurité des systèmes d'information.
Administrateur Bases de Données
• Migration de bases de données Oracle 10g vers PostgreSQL 9.0
• Analyse, conception et administration des bases de données cosmologiques du CeSAM (6 bases)
• Mise à jour des bases de données cosmologiques
• Mise en place d'une stratégie de sauvegarde des bases de données du CeSAM
!
Administrateur Systèmes d'information
• Conception, développement et administration des sites internet pour la mise à disposition des
données scientifiques cosmologiques du CeSAM (6 SI)
Développement
des outils de consultations et d'extraction des données
•
• Développement des outils de traitement d'images astronomiques et de visualisation de spectres
• Participation aux spécifications et débogage des versions bêta du logiciel SiTools2 (CNES)
• Développement de modules additionnels pour le logiciel SiTools2
• Gestion des accès sécurisés aux systèmes d'information
• Développement d’ANIS (Astronomical Information System), framework de mise en place d’un
système de recherche et d’accès aux données en astrophysique.
Systèmes et Réseaux
• Installation et administration de deux serveurs de base de données PostgreSQL 9.0 avec une
réplication en streaming.
• Administration d'un serveur PgPool-II pour la répartition de charge entre les serveurs de base de
données
• Installation et administration de deux serveurs pour la mise en production et le développement
des systèmes d'information
• Configuration des serveurs Apache et des accès aux SI par proxy
Publications et participation aux colloques internationaux
• ADASS (Astronomical Data Analysis Software and Systems) XXI (2011, Paris, 5 jours)
• Poster et article : « The Information Systems at CeSAM », co-auteur
ADASS
XX (2010, Boston, 5 jours)
•
• Poster et article : « The COSMOS Information Systems at LAM », co-auteur
• Poster et article : « HeDaM: The Herschel Database in Marseille », co-auteur
Octobre-Décembre 2008
, Laboratoire d'astrophysique de Marseille (LAM) – CNRS
Stage AFPA au Centre de données astrophysique de Marseille (CeSAM)
Développement d'un module additionnel de localisation des agents pour l'application BddP de
gestion du personnel du laboratoire (Applet JAVA/Oracle)
PROGRAMMATION
ORIENTÉE OBJET
Développement d’un
module additionnel JAVA
pour le logiciel SiTools2
IP1
ENVIRONNEMENT
TECHNOLOGIQUE
Sitools2 permettant l'ajout de
modules additionnels, j'ai
développé ce module d'export
en
Java
6
avec
l'environnement de
développement Eclipse. La
gestion du code source est
effectué par Subversion sur
un serveur au sein du service.
LANGAGE UTILISÉ
Java : version 6
LOGICIELS UTILISÉS
Eclipse : Indigo
Subversion : Eclipse subversive
1. Développement d’un
module additionnel JAVA
pour le logiciel SiTools2
CONTEXTE
Dans le cadre de l'utilisation du logiciel SiTools2 (plate-forme web
permettant de mettre en place un système de recherche et d'accès
aux données à partir d'une ou plusieurs bases de données existantes),
développé en Java http://sitools2.sourceforge.net), il manquait la
possibilité d'exporter le résultat d'une recherche au format standard
VOTable (Fichier xml avec les spécifications Observatoire Virtuel
http://www.ivoa.net/ ).
L’architecture de cette plate-forme est composée :
• d'un serveur de données exposant des ressources, • d'une interface web pour l'administrateur permettant de configurer
l'ensemble des fonctionnalités du serveur, • d'une interface web pour les utilisateurs comportant un portail qui
liste les projets, avec un bureau pour chaque projet qui expose
l'ensemble des services mis à disposition par l'administrateur, • d'un mécanisme de plugins permettant aux développeurs d'ajouter
des fonctionnalités métiers aussi bien au niveau du serveur qu'au
niveau du client et de les partager avec une communauté
d'utilisateurs. PHASE DE CONCEPTION
La mise en oeuvre de ce module additionnel d'Export des données au
format VOTable consiste à développer en Java un Service à Valeurs
Ajoutées (SVA) au sein de SiTools2.
SiTools2
Framework développ
é par le CNES,
dédié à la mise en pla
ce de Systèmes
d’Information scient
ifiques.
PROCESSUS DE DÉVELOPPEMENT
Développement de la classe principale
d’export
Extension de la classe principale d’export
pour la gestion des différents formats de sortie
Développement de la classe d’envoi du
résultat
PHASE DE RÉALISATION
Pour implémenter un module additionnel appelé
"ressource plugin" il faut une ressource
"implémentation" et une ressource "façade" qui
est la ressource attachée à l’application, c’est
donc celle qui sert d’entrée.
La ressource "façade" doit définir les différentes
méthodes autorisées et doit ensuite faire appel à
la classe TaskUtils qui gère les
appels
synchrones ou asynchrones et les tâches
d’exécutions.
La ressource "façade" est étendue par la
ressource "implémentation" qui va créer et
retourner un objet "Representation" de l'API
Restlet.
J'ai donc commencé par créer ces classes qui
per mettent d'implémenter un module
additionnel dans SiTools2.
Dans la classe ExportVoService, je récupère
l'objet Restlet "Context" qui contient des
paramètres du client qui ont permis d'obtenir les
résultats de la recherche. Ces paramètres
servent à instancier un objet
OutputRepresentationVOTable qui est retourné
dans l'objet Representation.
Dans la classe OutputRepresentationVOTable j'ai
codé les méthodes qui vont permettre de
récupérer les données, les mettre en forme au
format VOTable. Ces données sont renvoyées
dans un objet OutputStream.
Pour la récupération des données, j'ai créer une
classe RecordsRetriever qui contient les
méthodes pour relancer la requete et
transformer le fichier de résultat qui est
retourné au format Json en objets en utilisant la
bibliothèque Xstream. Les données sont
retournées dans une liste d'enregistrements.
J'ai ensuite créé une classe VOTable qui contient
les méthodes qui permettent de mettre en forme
un fichier au standard VOTable.
BILAN
A travers l’analyse et le développement de ces activités, j’ai pu acquérir les connaissances et compétences
nécessaires pour cette activité :
Java
Librairie xstream,
Restlet.
SYSTÈMES
D’INFORMATION
IP2
Analyse, conception
et administration du
S y s t è m e
d’Information
HST-COSMOS
ENVIRONNEMENT
TECHNOLOGIQUE
La version existante était
codée en Perl à mon arrivée
en 2009, j'ai conservé ce
langage pour le nouvelle
version de ce SI.
Les données et méta-données
sont stockées dans une base
de données PostgreSQL.
SGBD
1. Analyse, conception et
administration du Système
d’Information HST-COSMOS
CONTEXTE
Le projet HST-COSMOS est le plus important sondage du HST (Hubble
Space Telescope) avec 2 degrés carré d'imagerie à haute résolution
couplé avec des données multi longueurs d'onde, provenant des plus
grands observatoires mondiaux (CFHT,VLA, VLT, XMM, Spitzer).
L'objectif du Système d'Information HST-COSMOS est de combiner
l'ensemble de ces informations afin de pouvoir faire l’étude des
galaxies par la combinaison des données des télescopes spatiaux et
sol.
Oracle 10g
PHASE DE CONCEPTION
Postgresql 9.0
La base de donnée métier était à l’origine sous Oracle 10g. Pour des
raisons financières (achat de licences) et technologiques
(uniformisation de toutes les bases de données du CeSAM), j’ai
effectué la migration de la base métier d’Oracle vers Postgresql.
LOGICIELS UTILISÉS
Emacs
JMerise
MATÉRIEL UTILISÉ
serveur : centOS
Le SI devait être dynamique pour faciliter l'ajout de nouveaux
catalogues de données, j'ai donc décidé d'appuyer la structure du SI
sur une base de méta-données.
J’ai donc suivi une succession d’étapes :
• Expression du besoin : j’ai défini ce que l’on attend du Système
d’Information. J’ai donc fait l’inventaire des éléments nécessaires
au SI et pour le délimité.
• Modèle conceptuel : j’ai mis au point le Modèle Conceptuel de la
communication (MCC) et le Modèle Conceptuel de Données (MCD)
• Modèle logique : j’ai défini le choix logiciel pour le SI.
• Modèle physique : j’ai défini le choix matériel pour le SI.
• Modèle Opérationnel des traitements : j’ai crée les différents
formulaire de manipulation des données.
Afin de concevoir le MCD, j’ai dans un premier temps défini toutes les
entités et leurs attributs, puis dans un second temps les associations
qui lient de façon logique les entités entre elles et
leurs cardinalités.
COSMOS
COSMOlogical evolut
ion Survey (COSMOS
)
Etude de l’évolution
des Galaxies par la com
binaison des
données des télescop
es spatiaux (Hubble,
Spitzer, Galex, ...),
et sol (ESO- VLT, CF
HT, ...)
En exploitation depu
is 2005, 4 millions d’o
bjets, 150 Go
d’images, 32000 lign
es de code.
Les entités sidataset et siattributes
L’entité sidataset répertorie les catalogues de
données. Elle contient l’attribut nom_catalog qui
contient le nom de la table métier et des
attributs qui contiennent des informations pour
l'affichage du SI.
L’entité siattributes contient les informations
des colonnes des tables métiers. Un attribut est
identifié par le nom de colonne et le nom de la
table métier correspondante. Elle contient aussi
les informations VOTable (Fichier xml avec les
spécifications Observatoire Virtuel http://
www.ivoa.net/) sur la colonne ainsi que des
informations pour la construction dynamique
des formulaire du SI.
Un élément siattributes appartient à un seul
élément sidataset et un élément sidataset peut
avoir aucun ou plusieurs éléments siattributes.
Les entités dataset_files et images
Les entités dataset_files et images servent à
gérer les fichiers liés au catalogues. Les images
s o n t d e s fi c h i e r s q u i c o n t i e n n e n t d e s
informations supplémentaires qui sont stockées
dans l’entité images.
Un élément sidataset contient aucun ou
plusieurs fichiers associés, et un fichier associé
appartient à un seul élément de sidataset.
Les entités siniveau et siuser
Les entités siniveau et siuser servent à gérer
l'affichage d'un catalogue et de certaines de ses
colonnes suivant l'utilisateur connecté au SI.
Un utilisateur possède un niveau d'accès qui lui
permet de voir les catalogues correspondant à ce
niveau. Il est également possible de gérer
l'affichage des colonnes, pour que certaines
colonnes d'un catalogue soient visibles à un
niveau et d'autres au niveau supérieur.
Un élément sidataset a un niveau d’accès unique
et un élément siattributes est visible d’un seul
niveau d’accès.
Un élément siuser possède un seul niveau
d’accès.
Après la validation du MCD, j’ai pu déduire le
Modèle Logique des Données (MLD).
PHASE DE RÉALISATION
J’ai ensuite sous le SGBD Postgresql crée le Modèle Physique de Données (MPD) et suivi ces actions :
Création de la base de méta-données
Création des tables, des vues, ...
Création des index
Gestion des droits d’accès
Gestion des sauvegardes des données
J’ai ensuite développé les différents formulaires du SI en utilisant SQL comme langage de manipulation de
données.
BILAN
A travers l’analyse et le développement des bases de données métier et de méta-données, j’ai pu acquérir les
connaissances et compétences nécessaires pour cette activité :
SGBD : Oracle 10g, Postgresql 9.0
Méthode Merise
Langage de manipulation de données SQL
INTERNET
Conception, développement
et administration des sites
internet pour la mise à
disposition des données
s c i e n t i fi q u e s
cosmologiques
du CeSAM.
IP3
ENVIRONNEMENT
TECHNOLOGIQUE
Pour écrire la partie cliente
de ce système d'information
j'ai utilisé les standards
HTML5 et CSS3.
J'utilise également les
librairies jQuery, jQueryUI et
différents plugins pour les
script javascript.
Certaines fonctions javascript
utilise la méthode AJAX qui
s'appuie sur des scripts codé
en php dans le contrôleur et
qui utilisent le format JSON
pour l'échange de données
entre le client et le serveur.
J'utilise également le kit CSS
Bootstrap pour la mise en
forme des pages et régle
automatiquement les
différents formats d'affichage
(Tablettes, smartphone..)
1. Analyse, conception et
administration des sites
internet cosmologiques du
CeSAM.
CONTEXTE
Le centre de données astrophysique de Marseille (CeSAM) a mis en
place un ensemble de systèmes d’information pour mettre à
disposition les données à valeur ajoutée des projets scientifiques du
laboratoire d'astrophysique de Marseille (LAM). Les différents
systèmes d'information ayant des fonctionnalités communes, il a été
décidé de créer un système d'information générique afin de facilité le
déploiement et la maintenance des SI.
PHASE DE CONCEPTION ET ÉTUDE
HTML5, CSS3
Lors de la phase de conception nous avons clairement défini les
objectifs du SI générique et ses différentes fonctionnalités afin de
répondre aux besoins exprimés par les chefs de projets scientifiques
du LAM.
Nous avons dans un premier temps élaboré des scénarios, établit le
cahier des charges puis planifier les différentes étapes de la
réalisation.
JavaScript
Notre SI générique repose sur une architecture client/serveur.
LANGAGES
PHP
LOGICIELS UTILISÉS
NetBeans 7.2.1
ANIS
Framework dédié à
la mise en place
de Systèmes d ’
Information
scientifiques.
PHASE DE RÉALISATION
JavaScript, jQuery & Ajax
Pour la description de la phase de réalisation, je
vais explicitement vous décrire le formulaire de
recherche d’objets célestes autour d’une position
dans le ciel : ConeSearch appliqué au SI VUDS.
Pour gérer les différentes actions du formulaire,
j’utilise la bibliothèque jQuery qui porte sur
l’interaction entre JavaScript (comprenant Ajax)
et HTML et qui a pour but de simplifier des
commandes communes de JavaScript.
Afin de pouvoir utiliser la bibliothèque jQuery, on
ajoute son chargement :
HTML & CSS
<script src="scripts/jquery-1.8.3.min.js"></script>
J’ai dans un premier temps édité le formulaire
ConeSearch qui comprend une zone de sélection
du jeux de données (Datasets) , une zone
d’affichage des critères de recherche (Cone
Search), et une zone de sélection des paramètres
de sortie (Output) à l’aide de la balise HTML <div>
et de leur mise en forme à l’aide de feuille de style
CSS.
extrait HTML
<div class="frame">
<div class="row-fluid">
<h3>Datasets</h3>
</div>
...
</div>
extrait CSS
.frame{
font-size: 14px;
line-height: 20px;
border-radius: 10px;
border: 1px solid #91A9F7;
background-color: white;
}
et à la fin du téléchargement du DOM, j’agit sur le
document à l’aide de la fonction «ready»:
$(document).ready(function (){
...
});
La «<div>» Datasets est composée de radio boutons
sur lequel il y a le listener jQuery «.change()» dans
la fonction $(document).ready() qui me permet
d’exécuter une fonction au changement d'état du
formulaire. La fonction récupère le nom du jeu de
données sélectionné et le renvois dans un script
php par la méthode AJAX en utilisant la fonction
jQuery «.post()» :
$(document).ready(function (){
$('#dataset input[name=dataset]').change(function() {
loadConesearch($("#dataset input
[name=dataset]:checked").val());
});
});
function loadConesearch(datasetName){
$.post('data/conesearchDataset',{
dataset: datasetName
},function(data) {
formConesearch(data);
});
}
Le script php récupère dans la base de méta-données les informations du jeu de données et les renvois
sous forme de fichier au format JSON.
public function conesearchDatasetAction() {
$this->_view->setDisabledView(true);
$dataset = $this->_request->getParam('dataset');
....
$json = array('conesearch' => $criteria);
$this->_response->setHeader("content-type", "text/json");
$this->_response->printStream(json_encode($json));
}
J'utilise une fonction jQuery (formConesearch) pour parcourir le fichier JSON et récupérer les
informations du jeu de données qui me permettent d'écrire les formulaires de recherche.
function formConesearch(data){
....
var form_criteria = [];
form_criteria.push('<div class="row-fluid">');
form_criteria.push('<div class="span7 buttonrow">');
form_criteria.push('<button class="btn btn-warning btn-hms" type="button" id="btnhms" data-toggle="button">Enter HH:MM:SS</
button>');
form_criteria.push('</div>');
form_criteria.push('<div class="span4 info-dataset">');
form_criteria.push('<div class="row-fluid">' + data.conesearch.ra.label + ' between ' + (Math.floor(data.conesearch.ra.min*1000)/
1000).toFixed(3) + ' and ' + (Math.ceil(data.conesearch.ra.max*1000)/1000).toFixed(3) + '</div>');
form_criteria.push('<div class="row-fluid">' + data.conesearch.dec.label + ' between ' + (Math.floor(data.conesearch.dec.min*1000)/
1000).toFixed(3) + ' and ' + (Math.ceil(data.conesearch.dec.max*1000)/1000).toFixed(3) + '</div>');
form_criteria.push('</div>');
form_criteria.push('</div>');
form_criteria.push('<div class="row-fluid" id="degrees">');
form_criteria.push('<div class="span7">');
form_criteria.push('<div class="span5 offset1">' + data.conesearch.ra.label + ' <input class="span9 inputtext" type="text"
name="radeg" id="radeg" placeholder=""></div>');
form_criteria.push('<div class="span5">' +data.conesearch.dec.label + ' <input class="span9 inputtext" type="text" name="decdeg"
id="decdeg" placeholder=""></div>');
form_criteria.push('<div class="span1">Degrees</div>');
form_criteria.push('</div>');
form_criteria.push('</div>');
...
}
J'ai écrit une fonction qui convertit automatiquement des coordonnées saisies au format heures minutes
secondes et les transcrit en degrés. Cette fonction est associée à un listener jQuery .bind('keyup'), qui
permet de l'exécuter à chaque relâchement de touche :
$("#hms").bind('keyup',(function() {
var ra = (Number($('#rah').val()) + (Number($('#ram').val()) / 60) + (Number($('#ras').val()) / 3600)) * 15;
var dec = Math.abs(Number($('#decd').val())) + (Number($('#decm').val()) / 60) + (Number($('#decs').val()) / 3600);
if (Number($('#decd').val()) < 0){
dec = dec * -1;
}
$('#degrees input[name=radeg]').val(ra);
$('#degrees input[name=decdeg]').val(dec);
}));
jQueryUI & jQuery plugins
Sur l’ensemble de mes formulaires, j’ai utilisé jQuery UI qui offre des méthodes additionnelles appliquées à
la réalisation de l'interface utilisateur grace à des interactions et des widgets.
J'ai donc utilisé un «slider» qui permet d'afficher un intervalle de valeurs et d'en sélectionner une sous la
forme d'une réglette afin que l’utilisateur nous communique le rayon de recherche souhaité.
$("#slider").slider({
min: 0, max: 150, value : 2,
slide: function(event, ui){
$("#rad").html(ui.value);
$("#radius").val(ui.value);
}
});
Les onglets utilisés dans le choix des familles critères et les accordéons utilisés dans la selections des paramètres de
sorties sont générés en utilisants les classes et les scripts de Bootstrap.
Pour la mise en forme des résultats de la recherche, j'utilise le plugins jQuery DataTables, qui permet
l'affichage sous forme de tableau. Pour les fonctions de tri, de pagination ou de recherches des résultats,
j'utilise la méthode AJAX et un script php qui écrit et exécute une sous requête, puis renvois les résultats
avec le format JSON. Les nouveaux résultats sont affichés par le plugin.
BILAN
A travers l’analyse et le développement des sites internet cosmologiques, j’ai pu acquérir les connaissances
et compétences nécessaires pour cette activité :
HTML5, CSS3
Javascript, jQuery, AJAX
PHP
En plus de mes activités de développement au CeSAM, je suis intervenu en tant que formateur au cours de
trois formations CNRS «développement web pour Administrateur Système et Réseaux», pour différentes
délégations régionales.
J’ai dispensé le cours sur les plugins jQuery, ainsi que les TP jQuery & Ajax.
SYSTÈMES
D’EXPLOITATION ET
RÉSEAUX
Installation
et
administration de deux
serveurs de base de
données Postg reSQL 9.0
avec une réplication en
streaming
Administration d’un
serveur PgPool-II pour la
répartition de charge entre
les serveurs de bases de
données
Installation
et
administration de deux
serveurs pour la mise en
production
et
le
développement
des systèmes
d’information
IP4
ENVIRONNEMEN
T
TECHNOLOGIQUE
LES LOGICIELS UTILISÉS
Les deux serveurs de base
de données sont installés
avec la distribution
Scientific Linux 6.3 .
Les base de données sont
sous PostgreSQL 9.0 .
Un serveur vir tuel qui
héberge pgPool-II pour le
"pooling" de connexion et la
répartition de charge.
Un serveur utilisé pour
héberger la sauvegarde
hebdomadaire.
Le logiciel rsync pour
effectuer la sauvegarde
hebdomadaire.
Le programme cron pour
lancer automatiquement
des scripts.
CONTEXTE
Le centre de données astrophysique de Marseille (CeSAM) a mis en place
un ensemble de systèmes d’information pour mettre à disposition les
données à valeur ajoutée des projets scientifiques du laboratoire
d'astrophysique de Marseille (LAM). Ces données était majoritairement
stockées dans des bases de données Oracle et PostgreSQL 8.4, installées
sur différents serveurs.
Il a été décidé d'uniformiser et de centraliser les bases de données sur des
serveurs dédiés pour faciliter la maintenance et de mettre en place un
système de sauvegarde.
PHASE DE CONCEPTION
Pour offrir une haute disponibilité des données, nous avons décidé de
mettre en place un système de réplication du 2 serveurs physiques pour
palier à une panne matériel. Si une panne survient les données sont
toujours disponibles sur l'autre serveur. De plus le système de réplication
par "streaming" garanti d'avoir les données identiques sur les 2 serveurs.
Cette solution à comme inconvénient qu'en cas de panne du serveur
maitre, il faut reconfigurer l'adresse de connexion de toutes les
application et SI qui interroge les bases de données pour qu'ils se
connecte au serveur esclave. Nous avons donc décidé d'ajouter un pooler
de connexions qui permet de n'avoir qu'une adresse à configurer, le pooler
se chargeant de rediriger les connexions. De plus cela permet de répartir
les requêtes sur les 2 bases de données.
La réplication ne protégeant pas d'une erreur de manipulation de la base, puisque l'erreur est aussitôt
répliquée, nous avons décidé la mis en place un système de sauvegarde qui permet de récupérer une base
à jour du samedi précédent.
Pour finir, nous avons décidé d'ajouter un serveur de développement qui permet de développer et
d’effectuer des tests sur des bases de données séparées.
Processus de développement :
Installation et configuration de PostgreSQL 9.0 sur les serveurs maitre et esclave
Mise en place de la réplication
Création et migration des bases de données existantes sur les nouveaux serveurs
Gestion des utilisateurs et des accès au bases de données
Installation et configuration de pgPool-II sur le serveur virtuel et gestion des accès
Création des clusters de bases de données sur les serveurs de sauvegarde et de développement
Création des scripts de sauvegarde et de copie de base de données
Mise en place de l'automatisation de la sauvegarde avec cron
PHASE DE RÉALISATION
Pour la mise en place des bases de données, j'ai
d'abord installé postgreSQL sur les serveurs
maitre (master) et esclave (slave). J'ai ensuite
créé le répertoire ou sont stockés les fichiers
binaires et initialisé le cluster sur chacun des
serveurs.
yum install postgresql90.x86_64
mkdir /data/databases
initdb -D /var/lib/pgsql/9.0/master
La réplication ne protégeant pas d'une erreur de
manipulation de la base, puisque l'erreur est
aussitôt répliquée, j'ai mis en place un système de
sauvegarde qui permet de récupérer une base à
jour du samedi précédent. Pour cela j'ai installé
postgreSQL sur un serveur de sauvegarde et écrit
un script bash utilisant le logiciel rsync pour
effectuer la sauvegarde hebdomadaire par copie
des fichiers binaires.
#!/bin/sh
Le streaming réplication, ou réplication en flux est
un système de réplication asynchrone, en maitre/
esclave, qui fonctionne à partir des journaux de
transactions.
J'ai donc configuré le serveur maitre pour activer
l'archivage des journaux de transactions, le mode
de réplication et autoriser un serveur esclave à se
connecter.
wal_level = 'hot_standby'
archive_mode = 'on'
archive_command = 'cp %p /data/archives_xlog/%f'
max_wal_senders = 1
J'ai également configurer le serveur esclave, pour
lui indiquer de se mettre en mode attente et
comment se connecter au serveur maitre.
restore_command = 'cp /mnt/nfs/data/archives_xlog/%f %p'
archive_cleanup_command = 'pg_archivecleanup /mnt/nfs/data/
archives_xlog %r'
standby_mode = 'on'
primary_conninfo = 'host=172.20.110.173 port=5432 user=slave'
trigger_file = '/tmp/stopstandby'
Pour autoriser le serveur esclave à se connecter
au serveur maitre il faut également déclarer son
adresse CIDR dans le fichier de configuration des
accès distants (pg_hba.conf )
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host replication slave
172.20.110.174/32
md5
ssh postgres@save "pg_ctl -D /var/lib/pgsql/9.0/master_backup status"
psql -c "SELECT pg_start_backup('master_backup', true)"
rsync -e ssh -avz --delete-after --progress /data/databases/ save:/data/
databases/
rsync -e ssh -avz --delete-after --progress --exclude=*.conf -exclude=PG_VERSION --exclude=postmaster.pid -exclude=postmaster.opts /var/lib/pgsql/9.0/master/ save:/var/lib/pgsql/
9.0/master_backup/
ssh postgres@save "pg_ctl -D /var/lib/pgsql/9.0/master_backup
start </dev/null >/dev/null 2>&1"
ssh postgres@save "pg_ctl -D /var/lib/pgsql/9.0/master_backup status"
psql -c "SELECT pg_stop_backup();"
sleep 500
ssh postgres@save "pg_ctl -D /var/lib/pgsql/9.0/master_backup stop -m
fast"
Pour automatiser la sauvegarde hebdomadaire,
j'ai utilisé le programme cron.
0 1 * * 0 sh /var/lib/pgsql/master_backup.sh >>/tmp/log_backup.log
J'ai également installé postgreSQL sur un serveur
de développement et pour simplifier la mise en
production d'une base de données, j'ai écrit un
script bash qui copie une base ou une table du
serveur de développement vers le serveur de
production.
#!/bin/sh
J'ai mis en place le système de pooling et de
répartition de charge en installant pgPool-II sur
un serveur virtuel. Pour activer la répartition de
charge, j'ai indiqué dans le fichier de configuration
(pgpool.conf) l'adresse IP des serveurs, leur port
et le poids de la répartition.
# Host name or IP address to connect to for backend 0
backend_hostname0 = '172.20.110.173'
# Port number for backend 0
backend_port0 = 5432
# Weight for backend 0 (only in load balancing mode)
backend_weight0 = 0.5
backend_hostname1 = '172.20.110.174'
backend_port1 = 5432
backend_weight1 = 0.5
usage(){
name=`basename $0`
echo "Usage: $name [-t table_name] database_manager
database_name"
echo "
$name [-h]"
echo "
-t table to dump"
echo "
-h this help"
echo $nbParams
}
nbParams=$#
table=""
if [ $# -lt 2 ] ; then usage ; exit 1 ; fi
while getopts "t:h" arg; do
case $arg in
h) usage ; exit 1 ;;
t) table=$OPTARG ;;
esac
done
ssh postgres@dev "pg_ctl -D /var/lib/pgsql/9.0/master_backup start </dev/null >/dev/null 2>&1"
sleep 10
if [ -n "$table" ] ; then
#Restaure uniquement la table passée en parametre
pg_dump -h dev -p 5433 -U $3 -t $table -F c -v -f "/data/temp_backup_to_prod/$4.bak" $4
psql $4 -c "DROP TABLE IF EXISTS $table;"
pg_restore -d $4 -v "/data/temp_backup_to_prod/$4.bak"
rm "/data/temp_backup_to_prod/$4.bak"
ssh postgres@dev "pg_ctl -D /var/lib/pgsql/9.0/master_backup stop -m fast"
exit0;
else
#Restaure la totalité de la base de données
pg_dump -h dev -p 5433 -U $1 -F c -v -f "/data/temp_backup_to_prod/$2.bak" $2
psql template1 -c "DROP DATABASE IF EXISTS $2;"
psql template1 -c "CREATE DATABASE $2 TEMPLATE template0 OWNER cesamsi TABLESPACE databases;"
pg_restore -d $2 -v "/data/temp_backup_to_prod/$2.bak"
rm "/data/temp_backup_to_prod/$2.bak"
ssh postgres@dev "pg_ctl -D /var/lib/pgsql/9.0/master_backup stop -m fast"
exit 0;
fi
schéma global de l’ensemble des serveurs
BILAN
Connaissances/compétences nécessaires pour cette activité :
Installation de programmes sous linux
Configuration des accès réseau entre les serveurs
Configuration de postgreSQL et pgPool-II
rsync
Perspectives :
Migrer vers la version PostgreSQL 9.2 , pour bénéficier de la réplication avec les 2 serveurs en lecture
/écriture et de la répartition de charge intégré.
BASES DE DONNÉES
&
INTERNET
Au cours de ce module, je
vais vous montrer à partir
d’une recherche multicritère (formulaire) sur un
ensemble de dataset, les
c o n n e x i o n s e n t re d e s
bases de données (métier
et méta-données) et
Internet (client-serveur)
IP6
La page HTML possède des boutons radio, sur lesquels un listener jQuery est associé. Le changement de
dataset déclenche l'envoi d'une requête AJAX a un script PHP.
A partir des paramètres reçus, le script PHP va créer une requête SQL et l'envoyer vers la base de métadonnées, laquelle va lui renvoyer les résultats.
Le script va encoder ces résultats au format JSON et les renvoyer vers le client. Le client va ensuite
utiliser le JSON pour fabriquer un formulaire grâce à des fonctions javascript.
A la validation du formulaire, le client envoie les paramètres de recherche vers un script PHP.
Le script PHP va transformer le formulaire en requête SQL pour interroger la base de données métier.
Le script transforme les résultats reçus de la base de données en fichier au format JSON, lequel est
renvoyé au client. Le client met en forme le fichier en utilisant le plugin jQuery dataTables.
POO
&
BASES DE DONNÉES
Au cours de ce module,
je vais vous montrer les
connexions entres les
bases de données
(métier et métadonnées)
et
la
programmation orientée
objet.
IP7
Développement d’une classe étendue de PDO, afin d’ajouter la gestion des options du driver selon le type
de base utilisée.
class WPDO extends \PDO {
/**
* Add mandatories options to the PDO driver is the goal of this legacy
*
* @param string $dsn
* @param string $username
* @param string $password
* @param array $driver_options
*/
final public function __construct($dsn, $username = '', $password = '', $driver_options = array()) {
$driver_options += array(self::ATTR_ERRMODE => self::ERRMODE_EXCEPTION, self::ATTR_STATEMENT_CLASS => array
('Cesamsi\Model\PDO\Statement'));
Statement::setPDOInstance($this);
parent::__construct($dsn, $username, $password, $driver_options);
}
}
Utilisation du connecteur WPDO lors du chargement des pages du client.
// Activation autoload
(new SplAutoloader())->addAutoload(new Autoload('Cesamsi', '../../webtools/src/'))->register();
// Chargement de la configuration
$appConfig = ConfigFactory::getConfig('../application/config.yaml', ConfigFactory::YAML);
Registry::getInstance()->application = $appConfig;
// Chargement base de données default
$defaultConfig = $appConfig->model->databases->default;
if ($defaultConfig->rdbms == "pgsql") {
$dsn = $defaultConfig->rdbms . ":host=" . $defaultConfig->host . ";port=" . $defaultConfig->port . ";dbname=" . $defaultConfig>name;
$default = new WPDO($dsn, $defaultConfig->user, $defaultConfig->pass);
} else if ($defaultConfig->rdbms == "sqlite") {
$default = new WPDO($defaultConfig->rdbms, $defaultConfig->host);
}
// Chargement base de données meta
$metaConfig = $appConfig->model->databases->base_meta;
if ($metaConfig->rdbms == "pgsql") {
$dsnMeta = $metaConfig->rdbms . ":host=" . $metaConfig->host . ";port=" . $metaConfig->port . ";dbname=" . $metaConfig>name;
$meta = new WPDO($dsnMeta, $metaConfig->user, $metaConfig->pass);
} else if ($metaConfig->rdbms == "sqlite") {
$meta = new WPDO($metaConfig->rdbms . ':' . $metaConfig->host);
}
// Ajout des bases au Manager
Manager::getInstance()->addDatabase('default', $default);
Manager::getInstance()->addDatabase('base_meta', $meta);
// Lancement de l'application
FrontController::getInstance()->dispatch();
Diagramme de classes de l’objet SQLQuery qui permet la construction de tout type requête. L’objet
requête est ensuite envoyé à la base de données (métier ou meta-data) en utilsant PDO.
Modèle Conceptuel de Données de la base méta-données, qui permet de paramétrer et de piloter le
système d’information du projet scientifique.
exemple de fonctionnement pour le projet scientifique CFHTLS.
POO
&
INTERNET
Au cours de ce module,
je vais vous montrer la
c o n s t r u c t i o n
dynamique de pages
HTML en utilisant la
programmation
o ri e n t é e o b j e t e t
l'utilisation du design
pattern MVC.
IP8
Le traitement d'une demande d'un client se déroule selon les étapes suivantes :
Le client fait une demande au contrôleur qui est la porte d'entrée de l'application.
Le contrôleur traite cette demande en s'appuyant sur la couche métier.
Si besoin la couche métier récupère des données via la couche d'accès aux données.
Le contrôleur reçoit une réponse de la couche métier.
Le contrôleur traite la réponse et envoie les informations dynamiques à la page phtml correspondante.
La vue est envoyée au client.
Ce schéma représente l’organisation des différentes pages HTML qui composent le template ANIS
(Astronomical Information System) que j’ai développé pour les besoins du service. Ces pages sont
composées de plusieurs modules permettant à chaque projet de gérer le design de son système
d’information selon les objectifs scientifiques de celui-ci. Les modules sont construit dynamiquement par
l’ensemble des classes des contrôleurs qui font la liaison entre la vue et le modèle.
Module Dataset :
sélection du jeux de données.
Module Criteria :
sélection des critères de recherche.
Module d’Output :
sélection des informations à extraire.
STEPHANE GIMENEZ
141 Chemin de la Treille, 13320 Bouc-Bel-Air
tel : 06.89.30.56.91
email : [email protected]