|
⇤ ← Version 1 à la date du 2013-02-28 00:46:15
Taille: 763
Commentaire:
|
Taille: 3460
Commentaire: je dois aller manger…
|
| Texte supprimé. | Texte ajouté. |
| Ligne 12: | Ligne 12: |
= Au Cr@ns = == Baie de disque == Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. L'avantage de cette architecture == Recettes de cuisine Cr@nseuse == === Créer un nouveau DomU === Un tutoriel détaillé, allant de l'allocation de nouveaux volumes sur la baie de disque à la planification des sauvegardes est disponibe ici : [[/CreerUnDomu]] === Rattacher la console d'un DomU === Étant donné que le DomU ne possède pas réellement de périphérique de sortie, il est nécessaire de trouver un moyen d'interagir avec celui-ci lorsque la connexion réseau est défectueuse. On utilise pour cela une console série virtuelle, sur {{{/dev/hvc0}}}. Il faut indiquer au DomU d'afficher une interface de contrôle (type "tty") sur ce périphérique en modifiant le fichier le fichier {{{/etc/inittab}}} (voir tutoriel de création d'un DomU). Si cette modification est effectuée, il est possible de récupérer une console depuis le Dom0 correspond en tapant: {{{sudo xm console nom_du_DomU}}}. On peut alors voir : {{{ Debian GNU/Linux 7.0 nom_du_DomU hvc0 alice login: }}} NB: De part la nature du port série, il n'y a pas de détection d'une nouvelle connection au port série, il est donc nécessaire d'appuyer sur la touche entrée, pour rafraîchir l'écran. Pour se déconnecter, il faut appuyer sur la combinaison Ctrl+]. '''N'oubliez pas de fermer d'abord votre session, sinon, la prochaine personne à se connecter en série tombera sur votre session !'''. [TODO here] === Migration à chaud === Xen est censé permettre la migration à chaud, c'est-à-dire transférer '''Attention, la migration à chaud au crans est encore une science inexacte, réalisez les opérations ci-dessous lorsque c'est vraiment nécessaire, et préparez-vous à relancer le service critique concerné en cas de problème.''' Cependant, la méthode ci-dessous semble donner de bons résultats : Avant toute chose, il faut resynchroniser les volumes sur le Dom0 initial '''et''' sur le Dom0 de destination : {{{ fy$ sudo /usr/scripts/gestion/iscsi/update.sh fz$ sudo /usr/scripts/gestion/iscsi/update.sh }}} Puis lancer sur le Dom0 initial: on suppose ici une migration de {{{fy}}} vers {{{fz}}} {{{ fy$ sudo xm migrate nom_du_domU fz }}} Une latence d'une dizaine de seconde peut alors se faire se faire sentir, en effet, plusieurs opérations doivent être réalisées: * suspendre le système hôte (à la manière d'un {{{suspend to ram}}}) * transférer le DomU (ram, etc) * relancer le DomU sur le nouveau Dom0 * attendre que les tables de routage des switchs (en fait, chez nous, le backbone) |
Page en cours de réalisation !
Et oui, cette page n'a pas de WikiNom mais Bcfg2 non plus, et je pense pas que son auteur ait été brûlé, donc je prends le risque.
Sinon, cette page a pour objectif de vous apprendre tout ce qu'il faut savoir sur la virtualisation et sur la façon dont on procède au Crans. Quand quelqu'un l'écrira. 
Si cette page est toujours vide, vous pouvez la remplir. Et si vous savez pas quoi mettre dedans, demandez à une nounou de vous expliquer/montrer puis remplissez la page vous même !
Si vous n'avez pas compris ce qu'a dit la nounou/n'osez pas lui demander, vous pouvez frapper celui qui a fait un séminaire appelé "Virtualisation" et qui n'a pas daigné remplir cette page 
Au Cr@ns
Baie de disque
Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. L'avantage de cette architecture
Recettes de cuisine Cr@nseuse
Créer un nouveau DomU
Un tutoriel détaillé, allant de l'allocation de nouveaux volumes sur la baie de disque à la planification des sauvegardes est disponibe ici : /CreerUnDomu
Rattacher la console d'un DomU
Étant donné que le DomU ne possède pas réellement de périphérique de sortie, il est nécessaire de trouver un moyen d'interagir avec celui-ci lorsque la connexion réseau est défectueuse. On utilise pour cela une console série virtuelle, sur /dev/hvc0. Il faut indiquer au DomU d'afficher une interface de contrôle (type "tty") sur ce périphérique en modifiant le fichier le fichier /etc/inittab (voir tutoriel de création d'un DomU).
Si cette modification est effectuée, il est possible de récupérer une console depuis le Dom0 correspond en tapant: sudo xm console nom_du_DomU.
On peut alors voir :
Debian GNU/Linux 7.0 nom_du_DomU hvc0 alice login:
NB: De part la nature du port série, il n'y a pas de détection d'une nouvelle connection au port série, il est donc nécessaire d'appuyer sur la touche entrée, pour rafraîchir l'écran.
Pour se déconnecter, il faut appuyer sur la combinaison Ctrl+]. N'oubliez pas de fermer d'abord votre session, sinon, la prochaine personne à se connecter en série tombera sur votre session !.
[TODO here]
Migration à chaud
Xen est censé permettre la migration à chaud, c'est-à-dire transférer Attention, la migration à chaud au crans est encore une science inexacte, réalisez les opérations ci-dessous lorsque c'est vraiment nécessaire, et préparez-vous à relancer le service critique concerné en cas de problème. Cependant, la méthode ci-dessous semble donner de bons résultats : Avant toute chose, il faut resynchroniser les volumes sur le Dom0 initial et sur le Dom0 de destination :
fy$ sudo /usr/scripts/gestion/iscsi/update.sh fz$ sudo /usr/scripts/gestion/iscsi/update.sh
Puis lancer sur le Dom0 initial: on suppose ici une migration de fy vers fz
fy$ sudo xm migrate nom_du_domU fz
Une latence d'une dizaine de seconde peut alors se faire se faire sentir, en effet, plusieurs opérations doivent être réalisées:
suspendre le système hôte (à la manière d'un suspend to ram)
- transférer le DomU (ram, etc)
- relancer le DomU sur le nouveau Dom0
- attendre que les tables de routage des switchs (en fait, chez nous, le backbone)