Version actuelle en date du 24 octobre 2012 à 09:11

Se connecter sur la machine d'admin

admin.prod.allmyski.info

les Utilisateurs sont de la forme initale du prénom Nom (Julien Dupond => jdupond ). Ils sont dans le group "ams"

useradd -m -G ams USER -m
passwd USER

Ils se connectent en SSH avec leurs mots de passe

Ils ont accès via sudo à toutes les commandes. Le groupe ams à tout les droits.

ajouter un vhost pour les frontaux

Le plus simple est de copier un vhost existant.

sudo su -
(password user)
cd /home/config/front/etc/apache2/sites-available
cp skivoiturage.com.conf newvhost.conf

L'éditer et le configurer selon le besoin. Attention à la partie log qui permet d'envoyer sur la machine de centralisation des logs. (admin)

Il faut ensuite copier les configurations sur les frontaux.

scp newvhost.conf front01.prod.allmyski.info:/etc/apache2/sites-available/
scp newvhost.conf front02.prod.allmyski.info:/etc/apache2/sites-available/

Ensuite il faut devenir root pour utiliser sa clef afin d'aller sur les frontaux mettre le nouveau vhost en ligne.

sudo su -
(remettre son propre mot de passe )
ssh front01.prod.allmyski.info
a2ensite newvhost.conf
service apache2 reload

se déconnecté et répéter l’opération sur l'autre machine.

Si les DNS pointent bien sur la VIP ( 87.98.251.179 ) alors le site est en ligne.

créer une base de données et les utilisateurs

Se connecter sur phpmyadmin via l'url :

http://admin.ams.talevas.com/phpmyadmin/

user et mot de passe root fournis

les sauvegardes

les fichiers du NAS

Tout les jours à 3h30 on récupère le contenu de /var/www/upload dans /home/backup/. Toutes les semaines (le Lundi à 4h ) on archive une version.

dans /etc/cron.d/rsnapshot

30 3   * * *           root    /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf daily
0  4   * * 1           root    /usr/bin/rsnapshot -c /etc/rsnapshot-front.conf weekly

Ainsi les archives sont consultables dans /home/backup/ et s'ordonnent ainsi :

tree /home/backup/
.
└── front
    ├── daily.0
    │   └── var
    │       └── www
    │           └── upload
    └── daily.1
        └── var
            └── www
                └── upload

les bases de données

les sauvegardes base par base

On trouvera sur db02.prod.allmyslki.info (même procédure de connexion que pour les frontaux ci-dessus) dans /home/backup/ les sauvegardes unitaires de toutes les databases. Une toutes les 2 heures avec un délais de rétention de 48 heures. Cela est défini en variable au début du fichier /root/bin/mysql_backup_new.sh.

crontab -e (en root) pour changer la fréquence.

une sauvegarde complète est effectuée sur db02 toutes les 2 heures aussi cf 'crontab -l'

une autre est faite sur db01 dans /home/dump-all.sql

La synchro d'une mise à jour ou d'un projet vers les frontaux

l'ajout d'un projet GIT sur la machine d'admin

Il faut commencer par ajouter le projet sur la machine d'admin avant de pouvoir le pousser vers les frontaux.

par exemple :

cd /home/git
git clone  ssh://user@94.23.222.225/home/git/repositories/skiVoiturage.git
cd skiVoiturage/
git checkout -b prod remotes/origin/prod

on vérifie avec :

git branch -a

qui doit montrer :

  master
* prod
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/preprod
  remotes/origin/prod

Ensuite on peut utiliser le script de synchronisation

la synchronisation vers les frontaux

en root

sudo su - root
bash /root/bin/synchro.sh

Se laisser guider par le script. Bien répondre "oui" autrement ça ne part pas vers les frontaux. Ils sont tous à jour à la fin de l'exécution.

Principe de fonctionnement du Load Balancing

Une VIP est l'adresse de front qui peut se déplacer d'un frontal à l'autre. (IP FailOver OVH)

la VIP 87.98.251.179 est associée à l'une des machines par défaut et en fonctionnement nominal elle est configurée sur le serveur front01.

Keepalive

gestion de la VIP

Le service keepalive est démarré sur les 2 machines qui se surveillent ainsi l'une et l'autre. C'est ce service qui pilote le déplacement de la VIP en cas de panne du front01. Le front02 va la récupérer et savoir répartir la charge ou servir les pages en cas de perte totale de front01. Quand front01 est de nouveau opérationnel, front02 se déconfigure et front01 récupère la VIP.

Des mails sont envoyés par OVH (l'adresse contact tech et contact ????) pour chaque opération de déplacement de VIP.

Load Balancing

Keepalive gère les configurations de ipvs qui permet de faire le routage des paquets vers les services Apache de chacune des machines.

- Chacun des frontaux prend autant de requêtes
- il n'y a pas de persistance au niveau des connexions

Un test de vie est fait par keepalive pour valider le bon état de fonctionnement de chacun des 2 serveurs apache. Le test est fait sur le fichier index.html (c'est très simple à changer). En cas de disfonctionnement de l'un des deux serveurs apache c'est l'autre qui prendra toute la charge.

LA VIP NE SERA PAS DÉPLACÉE pour la perte d'un serveur apache, cela prend trop de temps (environ une minute) et n'est pas utile. On ne déplacera la VIP qu'en cas de perte de connexion (réseau ou test de vie keepalive) sur le front01 .

Un mail est envoyé par le service keepalive lors de la perte et de la récupération de l'un des services apache.

désactiver un frontal du Load Balancing

Le moyen le plus propre pour sortir un service apache du LB est de suprimer le fichier de test. Ainsi le connexion en cours se terminent et le apache n'en reçoit plus. On peut ensuite le couper.

mv /var/www/index.html /var/www/index_save.html

attendre qques secondes et couper le service.

service apache2 stop

Pour le remettre, en production bien penser à remettre le fichier index.html en place.

Un mail est envoyé par keepalive pour annoncé la perte d'un service apache.