Taille: 3460
Commentaire: je dois aller manger…
|
Taille: 7284
Commentaire:
|
Texte supprimé. | Texte ajouté. |
Ligne 2: | Ligne 2: |
'''Page en cours de réalisation !''' | '''Cette page est dépassée ! Le système de virtualisation utilisé n'est plus Xen mais Proxmox.''' |
Ligne 13: | Ligne 13: |
= Intérêts de la virtualisation = * Création simple d'un nouveau serveur * Flexibilité des ressources allouées * Séparation des services (facilite les màj) * Tolérance aux pannes matérielles * … À compléter ! |
|
Ligne 16: | Ligne 23: |
Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. L'avantage de cette architecture | Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. Celle-ci est à la fois connectée au vlan adm pour permettre son administration, et à un réseau dédié à l'export des volumes, grâce au protocole [[http://fr.wikipedia.org/wiki/ISCSI|iSCSI]]. L'avantage de cette architecture est de permettre le partage des volumes virtuels entre plusieurs serveurs de virtualisation, ce qui permet de virtualiser sur l'un ou l'autre des serveurs physiques tout ou partie des serveurs virtuels. Cela autorise ainsi la maintenance d'un des serveurs physique sans arrêt des services (au coût d'une perte de performance). La baie de disque (actuellement {{{nols}}}) possède une interface web de gestion des disques autorisant de nombreuses opérations (réplication, snapshots, etc), mais aussi une interface telnet permettant de réaliser des API (voir par exemple {{{/usr/scripts/gestion/iscsi/nolslib.py}}}) Actuellement, trois serveurs sont connectés à la baie de disque pour exporter les volumes: * {{{daath}}}, pour le partage des home et {{{/usr/scripts/}}} * {{{fy}}} et {{{fz}}} pour la virtualisation L'export des volumes fournis sur chacun des serveurs fournit tout un lot de périphériques {{{/dev/sdXX}}}. Les scripts dans {{{/usr/scripts/gestion/iscsi}}} se chargent, notamment au démarrage, de créer des liens symboliques entre ces fichiers et des noms "user-friendly" du type {{{/dev/nom_de_la_partition}}}. == Serveurs de virtualisation == Actuellement, deux serveurs réalisent la virtualisation : {{{fy}}} et {{{fz}}}. [TODO] |
Ligne 19: | Ligne 39: |
Ligne 39: | Ligne 58: |
[TODO here] | Cette opération permet notamment de récupérer un problème de configuration réseau du DomU, ou de finir sa configuration lors de l'installation. NB: « Que faire si c'est le Dom0 qui devient injoinable ?! » Eh bien, nos deux Dom0 sont des serveurs HP possédant chacun un iLO (integrated Light Out) qui autorise des connexions ssh: [[CransTechnique/LesServeurs/ConnexionILO|Voir les détails ici]]. |
Ligne 59: | Ligne 80: |
== Les problèmes == Toute technologie vient aussi avec son lot de problèmes et/ou inconvénients. === Entrées/Sorties === Étant donné l'abstraction matérielle réalisée par le système de virtualisation, il ne faut pas espérer obtenir au final des bêtes de courses des accès disques. En particulier, il est peu conseillé de se servir d'un DomU comme d'un serveur de sauvegarde, ou comme base de données. === Manque de place === En raison de la duplication des systèmes d'exploitation (chaque DomU a son propre /), on évite généralement de stocker trop de données sur le DomU. Ceci nous a donc motivé (avec la latence des entrées-sorties) [[CransTechnique/CentralisationDesLogs|à centraliser les logs]]. === Gestion du temps === L'utilisation de Xen semble poser des problèmes de synchronisation d'horloge entre le Dom0 et les DomU. En particulier, celle-ci semble inefficace et on observe une dérive temporelle importante des DomU, qui doit être corrigée, sous peine de plantage des services (beaucoup sont dépendants de l'heure courante). Malheureusement, ntp semble parfois nous jouer des tours. (Les nounous s'étant penchées sur le sujet pourront compléter et préciser le problème) Bref, il s'agit là d'un problème ouvert … === Gestion des sauvegardes === Ceci n'est pas vraiment un problème, mais la sauvegarde des DomU sollicite à la fois la machine hôte et la baie de disque. Il serait intéressant d'utiliser les fonctionnalités de snapshot de la baie de disque au lieu d'une backup traditionnelle via [[CransTechnique/ServicesMineurs/BackupPc|BackupPc]] ---- CatégoriePagePublique |
Cette page est dépassée ! Le système de virtualisation utilisé n'est plus Xen mais Proxmox.
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
Intérêts de la virtualisation
- Création simple d'un nouveau serveur
- Flexibilité des ressources allouées
- Séparation des services (facilite les màj)
- Tolérance aux pannes matérielles
- … À compléter !
Au Cr@ns
Baie de disque
Au Cr@ns, les disques durs des serveurs virtuels sont centralisés sur la baie de disque. Celle-ci est à la fois connectée au vlan adm pour permettre son administration, et à un réseau dédié à l'export des volumes, grâce au protocole iSCSI. L'avantage de cette architecture est de permettre le partage des volumes virtuels entre plusieurs serveurs de virtualisation, ce qui permet de virtualiser sur l'un ou l'autre des serveurs physiques tout ou partie des serveurs virtuels. Cela autorise ainsi la maintenance d'un des serveurs physique sans arrêt des services (au coût d'une perte de performance).
La baie de disque (actuellement nols) possède une interface web de gestion des disques autorisant de nombreuses opérations (réplication, snapshots, etc), mais aussi une interface telnet permettant de réaliser des API (voir par exemple /usr/scripts/gestion/iscsi/nolslib.py)
Actuellement, trois serveurs sont connectés à la baie de disque pour exporter les volumes:
daath, pour le partage des home et /usr/scripts/
fy et fz pour la virtualisation
L'export des volumes fournis sur chacun des serveurs fournit tout un lot de périphériques /dev/sdXX. Les scripts dans /usr/scripts/gestion/iscsi se chargent, notamment au démarrage, de créer des liens symboliques entre ces fichiers et des noms "user-friendly" du type /dev/nom_de_la_partition.
Serveurs de virtualisation
Actuellement, deux serveurs réalisent la virtualisation : fy et fz. [TODO]
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 !.
Cette opération permet notamment de récupérer un problème de configuration réseau du DomU, ou de finir sa configuration lors de l'installation.
NB: « Que faire si c'est le Dom0 qui devient injoinable ?! » Eh bien, nos deux Dom0 sont des serveurs HP possédant chacun un iLO (integrated Light Out) qui autorise des connexions ssh: Voir les détails ici.
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)
Les problèmes
Toute technologie vient aussi avec son lot de problèmes et/ou inconvénients.
Entrées/Sorties
Étant donné l'abstraction matérielle réalisée par le système de virtualisation, il ne faut pas espérer obtenir au final des bêtes de courses des accès disques. En particulier, il est peu conseillé de se servir d'un DomU comme d'un serveur de sauvegarde, ou comme base de données.
Manque de place
En raison de la duplication des systèmes d'exploitation (chaque DomU a son propre /), on évite généralement de stocker trop de données sur le DomU. Ceci nous a donc motivé (avec la latence des entrées-sorties) à centraliser les logs.
Gestion du temps
L'utilisation de Xen semble poser des problèmes de synchronisation d'horloge entre le Dom0 et les DomU. En particulier, celle-ci semble inefficace et on observe une dérive temporelle importante des DomU, qui doit être corrigée, sous peine de plantage des services (beaucoup sont dépendants de l'heure courante). Malheureusement, ntp semble parfois nous jouer des tours. (Les nounous s'étant penchées sur le sujet pourront compléter et préciser le problème) Bref, il s'agit là d'un problème ouvert …
Gestion des sauvegardes
Ceci n'est pas vraiment un problème, mais la sauvegarde des DomU sollicite à la fois la machine hôte et la baie de disque. Il serait intéressant d'utiliser les fonctionnalités de snapshot de la baie de disque au lieu d'une backup traditionnelle via BackupPc