PROCÉDURE
Bascule Expert Santé
Table des matières
Objectif ... 3
Panne du Serveur Applicatif ... 4
Arrêt du Serveur Applicatif ... 5
Retour à la normale : ... 6
Panne du serveur VIDAL ... 7
Panne du serveur de Base de données: ... 8
Principe de fonctionnement : ... 8
Action à exécuter ... 8
Retour à la normale ... 10
En cas de mise à jour ... 12
Pré-requis : ... 12
Objectif
L’objectif de ce document est de déterminer le niveau de panne d’Expert Santé et de pouvoir y répondre en activant les serveurs de secours
Schéma descriptif :
Panne du Serveur Applicatif
Le serveur Apache ne répond plus :
La page Web d’Expert Santé n’est plus accessible.
Le serveur ayant l’adresse IP http:// 192.168.1.180 ne répond plus.
Il s’agit du serveur Web Apache qui écoute sur le port 80.
Il faut donc vérifier :
- que la machine ayant l’IP 192.168.1.180 répond sur le réseau effectuer depuis plusieurs postes du réseau local de l’établissement : ping 192.168.1.180
Si la machine répond mais que la page Expert Santé ne s’affiche dans les navigateurs des postes de la clinique, il est possible que le service Apache soit arrêté.
- que le service Apache tourne sur cette machine
se connecter en ssh sur la machine 192.168.1.180 connexion Expertiz
sudo su – root
[sudo] password for expertiz: (retaper le mot de passe expertiz) relance_web
le mot de passe est demandé est celui du compte Expertiz Le script va redémarrer le service Apache.
Où se trouvent les logs Apache ? cd /var/logs/apache2/.
tail -f expert_sante_error
Arrêt du Serveur Applicatif
Le serveur Applicatif ne redémarre pas, ou reste à l’arrêt, il faut donc basculer sur le serveur de secours.
Attention, s’il est démarré mais que l’on bascule sur le serveur de secours, il faut
néanmoins l’éteindre ou le débrancher du réseau car son adresse IP va être réaffectée au serveur de secours.
- Connexion sur le serveur de secours ssh 192.168.1.182
avec le compte Expertiz (le mot de passe doit être connu) taper les commandes suivantes :
Attention il y a des espaces entre chacun des éléments :
sudo « espace » su « espace » « signe moins » « espace » root sudo su – root
[sudo] password for expertiz: (il faut re-taper le mot de passe du compte Expertiz). Ce dernier ne s’affiche pas quand on tape, c’est normal.
bascule_en_prod
la commande à taper se nomme « bascule_en_prod »
- doit être root pour exécuter le scipt sinon cela ne fonctionne pas - ping si adresse IP interne répond (192.168.1.180), on arrête le script - changement d’adresse IP
- activation des crons - démarrage Apache
- Recharger configuration Apache - remonter les partages
Une fois cette commande effectué, le serveur applicatif de secours (192.168.1.183) est devenu le serveur applicatif de production (192.168.1.180).
Il n’y a pas d’autres commandes à passer, juste prévenir les utilisateurs qu’il se trouvent sur un serveur de secours ( les performances peuvent être amoindries)
Situation à atteindre :
Retour à la normale :
Il faut prévenir les utilisateurs et planifier cette opération car une coupure du logiciel va intervenir de quelques minutes.
Si le serveur Applicatif de Production a pu repartir et qu’il doit de nouveau jouer le rôle de serveur « principal », il faut d’abord indiquer au serveur de secours qu’il doit reprendre son adresse IP initiale :
1. Se connecter sur le serveur de secours (qui a conservé l’IP 192.168.1.180 : - sur le compte Expertiz, taper :
sudo su – root
retour_a_la_normale
Le mot de passe demander pour passer en « super-utilisateur » est le mot de passe du compte Expertiz.
Le script va modifier son adresse IP (reprendre l’adresse 192.168.183), arrêter Apache, arrêter les CRONS, démonter les partages.
A cet instant Expert Santé n’est plus accessible.
2. Puis sur le serveur de production (qui a du re-démarré avec l’adresse 192.168.1.180), il faut se connecter avec le compte Expertiz puis taper : sudo su – root
retour_a_la_normale
Cela réactive les crons, remonte les partages et relance une synchronisation des documents avec le serveur de secours.
A la fin de cette opération Expert Santé est de nouveau accessible par les utilisateurs.
La durée de l’opération fluctue selon la quantité de documents à synchroniser (une dizaine de minutes devrait suffire).
Si le serveur de production a du être entièrement réinstallé, il convient de ne pas passer par cette commande mais de prévenir une bascule « manuelle » entre les 2 machines.
Panne du serveur VIDAL
Si le serveur VIDAL de Production (192.168.1.182) ne fonctionne plus (ne répond plus, est victime d’un disfonctionnement quelconque), il est possible de basculer sur un serveur VIDAL de secours (192,168,1,185).
Pour cela il faut se connecter sur le serveur Expert Santé Applicatif de Production : ssh [email protected]
taper la commande suivante : bascule_vidal
Cela va poser la question s’il fait vraiment effectuer cette bascule, puis modifier la configuration d’Expert Santé pour que le logiciel intègre la connexion au Serveur VIDAL de secours.
Une fois cette action effectuée, les utilisateurs peuvent se connecter à VIDAL.
Toutefois, il est préférable de prévenir par mail le Support Expert Santé de cette démarche ([email protected])
Panne du serveur de Base de données:
Schéma descriptif :
Principe de fonctionnement :
Le serveur de base de données Potsgresql fonctionne avec une système de réplication géré par Potsgresql qui permet la réplication des données en temps réel entre le serveur de production et un serveur de secours.
Le mécanisme est géré par le moteur Postgresql.
Il est basé sur un backup à l’identique à un instant « T » des 2 bases (production et secours) puis d’une lecture des « transactions » effectuées sur la production puis
« rejouée » sur le serveur de secours.
Par défaut la base de secours n’est pas ouverte en écriture mais uniquement en lecture.
En cas de crash du serveur de production, le serveur de secours peut prendre le relais.
Il s’agit d’un « failover » dans la terminologie PostgreSQL, lorsque le « maitre » ne peut plus jouer ce rôle est que l’esclave doit lui succéder.
Il faut pour cela créer un fichier système indiquant au serveur de secours qu’il passe
« maitre ».
Action à exécuter
Si le serveur est HS (et uniquement s’il ne peut plus redémarrer). L’arrêter proprement si possible.
Le débrancher du réseau.
Comment l’arrêter : se connecter en SSH avec le compte Expertiz puis sudo halt
un mot de passe va être demandé. Il s’agit du mot de passe du compte Expertiz.
1. Se connecter au serveur de Base de données de secours - Connexion sur le serveur de secours
ssh 192.168.1.184 avec le compte Expertiz
Attention il y a des espaces entre chacun des éléments :
sudo « espace » su « espace » « signe moins » « espace » root sudo su – root
[sudo] password for expertiz:
bascule_en_prod
la commande à taper se nomme « bascule_en_prod »
- doit être root pour exécuter le script sinon cela ne fonctionne pas - cela va récupérer les partages (/etc/fstab)
- cela va récupérer les crons (sauvegardes,etc...)
- script qui va tester si le serveur principal est actif mais non bloquant
- le script (exécuté en root), doit creer un fichier Trigger qui va donner l’accès en lecture / ecriture à base de données. Le serveur « esclave » devient alors le serveur
« maitre ».
- il faut modifier les fichiers de conf Expert Santé pour accès à la BDD sur le serveur Applicatif et serveur Applicatif de secours.. (xpz_config, ccam et cim10).
- remonter les partages de sauvegarde.
- relance postgresql
Une fois cette commande lancée sur le serveur de secours, celui-ci devient le serveur
« maitre ».
L’information est donnée aux serveurs applicatifs d’Expert Santé. Il faudra également
faire suivre cette information au Support Expertiz Santé ([email protected]) pour mise à jour des fichiers clients.
A la suite de cette action, Expert Santé est de nouveau accessible pour les utilisateurs.
Il faut néanmoins les prévenir que les performances peuvent être amoindries en utilisant la base de données sur une architecture de secours moins performante que celle initiale (de production).
Retour à la normale
Si les machines sont identiques, il n’est pas forcément nécessaire de revenir à la situation antérieure. Le serveur « esclave », devenu « maitre », peut continuer de jouer ce rôle.
Il faut cependant activer la réplication sur l’ancien serveur « maitre » afin qu’il devienne à son tour « esclave »
Néanmoins, si le serveur « esclave » n’a pas vocation à rester « maitre », il faut revenir à l’état antérieur.
Pour cela, une fois que l’ancien serveur « maitre » est réparé, il va falloir remonter une synchronisation dans le sens « nouveau maître » vers « ancien maître ».
Il va falloir réinstaller la même version de PostgreSQL (9.3), puis créer un compte
« replicator »
Modifier le fichier /etc/posgresql/9.3/main/pg_hba.conf :
#local replication postgres trust host replication replicator 192.168.1.181/32 trust
S’assurer que les comptes Postgres des 2 serveurs puissent se connecter l’un à l’autre en SSH.
Pour cela, on va initialiser une nouvelle base de données :
pg_basebackup -h 192.168.1.193 -D /home/postgres/data -U replicator -v -P --xlog Cette commande va être relativement longue car elle génère un backup complet de l’instance PostgresQL du nouveau maître vers l’ancien.
Il faut en outre créer le fichier « recovery.conf » qui indiquera les principes de la réplication :
cat /home/postgres/data/recovery.conf standby_mode = 'on'
recovery_target_timeline='latest'
# Connect to the master postgres server using the replicator user we created.
primary_conninfo = 'host=192.168..94 port=5432 user=replicator'
# Specifies a trigger file whose presence should cause streaming replication to trigger_file = '/home/postgres/pg_failover_trigger'
### Commandes pour la restauration des archives
restore_command = '/bin/cp /home/postgres/archive_xlog_mdSlave/%f %p >>
/var/log/postgresql/restorecmd_mdSlave.log 2>&1'
Avec cette configuration, l’ancien maître va donc pouvoir jouer le rôle d’esclave.
S’il doit passer de nouveau « maitre », il faut ;
- arrêter Postgresql sur le nouveau serveur maitre : sudo /etc/init.d/postgresql stop
- créer le fichier Trigger sur l’ancien serveur maitre pour lui indiquer qu’il passe en lecture écriture
sudo su – postgres
touch /home/postgres/pg_failover_trigger
- indiquer à Expert Santé que le serveur de base de données à changer : vi /home/expertiz/ajaccio/expert_ante/module/xpz_config.py
cfg_database_server = "192.168.1.183"
remplacer cette ligne par l’IP du nouveau serveur maitre.
Toutes ces actions doivent être exécutées « manuellement ».
A voir avec votre chef de projet Expert Santé s’il faut planifier l’intervention de l’éditeur sur ce point.
En cas de mise à jour
Pré-requis :
- il faut que le ssh-keygen soit en place sur chacune des machines pour que le rsync fonctionne
- il faut que les dossiers de montage soit crées à l’identique de la production sinon la commande mount ne fonctionnera pas. Si un nouveau montage doit être ajouté, il faut reprendre le nouvelles lignes présentes dans /etc/fstab et les ajouter au fichier
/root/lefstab. C’est ce fichier qui est synchronisé vers le serveur de secours.
- en cas d’installation de nouveaux composants sur le serveur maître, cela doit également être fait sur le serveur de secours (ex : wkhtmltopdf)
