'''Participants''' : Darko et Alexandre

'''Objectifs''' : Préparation Crash-Test 2007

=== Virtualisation ===

Sur le serveur de Secours :

 * Achat 2 Go de RAM (4 au total)
 * Achat de 2 HD de 200 Go
 * Vérifier le stock de pièces détachées (matrice critique)


Darko présente :

 * Un tableau de comparaison des images PQI  vs GHOST et restauration en VM (Taille des images et durée de sauvegarde et de restauration)
 * La procédure de restauration des images en VM
  .
  . Machine physique --> Image Ghost--> CD boot ou Disquette boot --> Machine Virtuelle
  . Machine physique --> Image PQI--> Disquette boot --> CD boot --> Machine Virtuelle

Le problème de l'« Ecran Bleu » à la restauration doit être traité avec le CD Bart-pe qui insère les bon drivers utilisés par VMWARE. Darko devra faire la procédure détaillée.

__Conclusion__ : préférence pour PQI (meilleure interface), mais la restauration en VM doit se faire en deux étapes, d'abord avec la disquette, puis le CD, pour éviter l' « Ecran Bleu ». Ce produit si le driver VMWARE est en SCSI. En IDE, ça fonctionne avec AD/TSE (pas d'écran bleu) 

=== Architecture ===

__Optique__ : cohérence, performance et sécurité. Dans la perspective de fonctionner quelques jours en production sur le serveur de secours. Donc, plutôt une VM à la fois. En tenir compte dans l'architecture physique du serveur (en sachant, que le sinistre totale sera probablement traité différemment. Certainement en reprise délocalisée)

Darko ferra un test pour  attacher un disque physique sur la VM, en ajoutant un disque supplémentaire. Mais attention, un message d'alerte (« système expérimental ») est signalé à la création de cette opération dans VMWARE. Donc, pas forcement pertinent pour la prod.

Afin de valider l'architecture physique des disques et définir l'emplacement des VM. Les tests suivants devront être effectues :

 * RAID1a 80Go : Host OS
 * RAID1b 80Go: VM TSE/CA0/AD

__Test__ : 

 * 1 VM à la fois
 * 2 et 3 VM en // sur RAID1b
 * Si la dégradation est trop forte, il faut ajouter 2 HD IDE branchés sur les connecteurs IDE de la carte mère. Ce qui donnerait : 

  * RAID1a 80Go : Host OS
  * RAID1b 200Go: VM CA0
  * IDE : 80Go: VM AD 
  * IDE : 80Go : VM TSE

  . ou 

  * RAID1a 2x80Go : Host OS
  * RAID1b 2x200Go: VM CA0
  * RAID1 2xSATA XGo: VM AD et TSE (pour exploiter le RAID SATA sur la carte mére, si les performances le permettent)


=== OS Host ===

Choix de Windows dans un premier temps, pour les raisons suivantes :

 *  Intégration plus simple dans l'environnement actuel Windows (accès aux VM différent sous Linux)
 *  Maintenance et maniabilité mieux maîtrisées sous Windows par l'administrateur local
 *  Pas de différence de performance constatée entre Linux et Windows à l'issu des tests

Cependant, Alex fait remarquer que les tests sous un « Host » Windows ont révélés des erreurs sur les services VMWARE au démarrage du serveur. 
Des tests supplémentaire devront être effectués par Darko sur son environnement de tests, afin de contrôler que cette erreur ne se produit pas sur ses serveurs. Ce qui serait rédhibitoire et exclurait de fait cette configuration. 


=== Optimisation serveur CA-0 ===

Darko propose de réfléchir sur l'optimisation du stockage des données sur CA-0. Ce qui apporterait plus de sécurité.

Aujourd'hui toutes les DB sont sur le disque H (Master et CODA) :

 * HD 1 : système
 * HD 2 : données DB

__Optimisation proposée__ :

 * HD 1 : système, Db Master et log
 * HD 2 partition 1 : données Db CODA
 * HD 2 partition 2 : sauvegardes des Db et des logs 

__Avantages__ : si le HD 2  est endommagé, MS-SQL peut fonctionner car le Master est disponible. Donc, une restauration des Db Coda peut être engagée directement sur le HD1 (rapide). De plus, si une partition est créée pour le stockage des sauvegardes local, les Db CODA pourront être sauvegardées plus facilement avec une Image ou le serveur Veritas sans prendre tout le volume de données actuel (optimisation de stockage et rapidité de sauvegardes et restaurations). 

Il faudrait profiter de la mission et de la présence du consultant pour faire un compactage des bases.  Car Darko fait remarqué que le fichier log est anormalement gros. Il pourrait donc être réduit à la suite de cette opération.

=== Prochaine réunion ===

Schéma de reprise (priorité) et intégration de la virtualisation.
Scénarios des tests