|
Taille: 7284
Commentaire:
|
← Version 18 à la date du 2019-08-06 11:05:44 ⇥
Taille: 7243
Commentaire: Comment réparer le réseau d'une vm après avoir cassé le bridge entre icelle et son virtualiseur parent.
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| {{{#!wiki caution '''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 :) |
## page was renamed from CransTechnique/Virtualisation #acl +All:read |
| Ligne 20: | Ligne 10: |
| <<TableOfContents>> |
|
| Ligne 23: | Ligne 15: |
| Ligne 24: | Ligne 17: |
| 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). | 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. |
| Ligne 26: | Ligne 19: |
| 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}}}) | La baie de disque (actuellement {{{nols}}}) possède une [[http://nols.adm.crans.org | 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}}}) |
| Ligne 28: | Ligne 21: |
| 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 |
Actuellement, quatre serveurs sont connectés à la baie de disque pour exporter les volumes: * {{{zbee}}}, pour le partage des home et {{{/usr/scripts/}}} * {{{fz}}}, {{{ft}}} et {{{stitch}}} pour la virtualisation |
| Ligne 32: | Ligne 25: |
| 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}}}. | 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}}} (enfin, quand ça marche bien…) |
| Ligne 35: | Ligne 28: |
| Actuellement, deux serveurs réalisent la virtualisation : {{{fy}}} et {{{fz}}}. [TODO] |
Actuellement, trois serveurs de virtualisation : {{{fz}}}, {{{ft}}}, et {{{stitch}}}. |
| Ligne 40: | Ligne 32: |
| === 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]] |
=== Accéder à l'interface web de Proxmox === |
| Ligne 43: | Ligne 34: |
| === 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). |
Le parc est manageable depuis https://stitch.adm.crans.org:8006 (ça marche aussi pour {{{fz}}} et {{{ft}}}) |
| Ligne 47: | Ligne 36: |
| 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}}}. | === Créer une nouvelle VM === Un tutoriel détaillé, allant de l'allocation de nouveaux volumes, l'installation de base de Debian et des services principaux: [[/CreerUneVM]] |
| Ligne 49: | Ligne 39: |
| On peut alors voir : {{{ Debian GNU/Linux 7.0 nom_du_DomU hvc0 |
=== Rattacher la console d'une VM === |
| Ligne 53: | Ligne 41: |
| 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. |
Un script dans {{{/usr/scripts/gestion/virtualisation/}}}, appelé {{{connect-qm}}} permet de rattacher les machines configurées correctement. Les VM n'ayant en effet pas d'interface de connexion par défaut, on leur fait simuler une connexion console/série. |
| Ligne 56: | Ligne 43: |
| 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 !'''. | === Migration à chaud sous Xen === |
| Ligne 58: | Ligne 45: |
| 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. | Sous Xen, on aurait dû pouvoir migrer les DomU à chaud, c'est-à-dire transférer l'ensemble de l'espace de la machine virtuelle vers un autre virtualiseur, sans la couper. Cependant, à cette époque, où on avait deux virtualiseurs, {{{fy}}} et {{{fz}}}, cela ne fonctionnait pas bien : la plupart des DomU envoyées de {{{fz}}} vers {{{fy}}} mourraient en route, et on devait les relancer. On a pas réussi à trouver à l'époque l'origine du problème. C'est en passant de Xen à Proxmox qu'on a trouvé la source du problème. |
| Ligne 60: | Ligne 47: |
| 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]]. | === Migration à chaud sous Proxmox === |
| Ligne 62: | Ligne 49: |
| === 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 |
Lorsqu'on est sur un hôte, il suffit d'utiliser la commande qm migrate en mettant l'option --online. {{{#!wiki caution Si corosync fonctionne mal, il se peut que vous ayez l'impression que la migration se soit bien passée alors que non. Pensez quand même à vérifier sur le virtualiseur d'arrivée ou sur l'interface web de proxmox. Si la migration n'est pas totalement terminée, vous ne pourrez pas récupérer le lock pour faire autre chose avec la vm. Si le problème vient de corosync, le relancer sur le virtualiseur fautif permet de réparer la situation : '''sudo systemctl restart corosync.service''' |
| Ligne 69: | Ligne 55: |
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) |
|
| Ligne 85: | Ligne 60: |
| === Les migrations foireuses === http://ark.intel.com/compare/75790,37103,33083 : le processeur de {{{fy}}} ne contient pas la technologie VTx with extended page table. Cela signifie que la RAM de la VM était mappée d'une façon ingérable par {{{fy}}} quand elle venait d'une machine avec ladite technologie. D'où les foirages. |
|
| Ligne 86: | Ligne 65: |
| É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. | Étant donné l'abstraction matérielle réalisée par le système de virtualisation, il y a une perte de perfs au niveau des IO. Cependant, les dernières technologies (disques VIRTIO, etc) ont permis de récupérer une partie de ces pertes. |
| Ligne 89: | Ligne 68: |
| 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]]. | 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/Services/CentralisationDesLogs|à centraliser les logs]]. |
| Ligne 93: | Ligne 72: |
| Bref, il s'agit là d'un problème ouvert … | Bref, il s'agit là d'un problème ouvert … Heureusement qu'on est passés à Proxmox. |
| Ligne 98: | Ligne 77: |
| === Migration mal terminée === Voir l'encadré plus haut. === J'ai pété le bridge sur le virtualiseur === Bon, partons du principe que le bridge est réparé sur le virtualiseur. Donc de votre côté tout a l'air d'aller. Mais attention, les vm n'auront plus de connexion. C'est fâcheux. Alors la méthode bourrine consiste tout simplement à redémarrer la vm et basta. Mais vous allez me dire, comment faire si je n'ai pas envie de redémarrer la vm (Par exemple, j'ai joué avec le virtualiseur qui porte la vm irc et j'ai '''pas''' envie de rebooter ce serveur). * Première chose à faire, vérifiez que vous arrivez à avoir un shell dessus. Si vous avez juste redémarré le bridge, la console sur l'interface web ne fonctionnera probablement pas. En revanche, vous pouvez vous connecter en [[CransTechnique/Services/Virtualisation/ConnexionLocaleVm#Directement_depuis_le_virtualiseur|en émulant une connexion série]]. Attention, vu que vous aurez cassé sa connexion, elle ne pourra pas parler au ldap et donc il faudra vous connecter en root dessus. * Si tout va bien dessus, c'est que le problème est entre le virtualiseur et la vm. Il suffit alors de lancer une migration sur un autre virtualiseur du cluster et pouf, c'est réparé et vous n'avez pas rebooté la vm! |
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 !
Sommaire
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.
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, quatre serveurs sont connectés à la baie de disque pour exporter les volumes:
zbee, pour le partage des home et /usr/scripts/
fz, ft et stitch 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 (enfin, quand ça marche bien…)
Serveurs de virtualisation
Actuellement, trois serveurs de virtualisation : fz, ft, et stitch.
Recettes de cuisine Cr@nseuse
Accéder à l'interface web de Proxmox
Le parc est manageable depuis https://stitch.adm.crans.org:8006 (ça marche aussi pour fz et ft)
Créer une nouvelle VM
Un tutoriel détaillé, allant de l'allocation de nouveaux volumes, l'installation de base de Debian et des services principaux: /CreerUneVM
Rattacher la console d'une VM
Un script dans /usr/scripts/gestion/virtualisation/, appelé connect-qm permet de rattacher les machines configurées correctement. Les VM n'ayant en effet pas d'interface de connexion par défaut, on leur fait simuler une connexion console/série.
Migration à chaud sous Xen
Sous Xen, on aurait dû pouvoir migrer les DomU à chaud, c'est-à-dire transférer l'ensemble de l'espace de la machine virtuelle vers un autre virtualiseur, sans la couper. Cependant, à cette époque, où on avait deux virtualiseurs, fy et fz, cela ne fonctionnait pas bien : la plupart des DomU envoyées de fz vers fy mourraient en route, et on devait les relancer. On a pas réussi à trouver à l'époque l'origine du problème. C'est en passant de Xen à Proxmox qu'on a trouvé la source du problème.
Migration à chaud sous Proxmox
Lorsqu'on est sur un hôte, il suffit d'utiliser la commande qm migrate en mettant l'option --online.
Si corosync fonctionne mal, il se peut que vous ayez l'impression que la migration se soit bien passée alors que non. Pensez quand même à vérifier sur le virtualiseur d'arrivée ou sur l'interface web de proxmox. Si la migration n'est pas totalement terminée, vous ne pourrez pas récupérer le lock pour faire autre chose avec la vm. Si le problème vient de corosync, le relancer sur le virtualiseur fautif permet de réparer la situation : sudo systemctl restart corosync.service
Les problèmes
Toute technologie vient aussi avec son lot de problèmes et/ou inconvénients.
Les migrations foireuses
http://ark.intel.com/compare/75790,37103,33083 : le processeur de fy ne contient pas la technologie VTx with extended page table. Cela signifie que la RAM de la VM était mappée d'une façon ingérable par fy quand elle venait d'une machine avec ladite technologie. D'où les foirages.
Entrées/Sorties
Étant donné l'abstraction matérielle réalisée par le système de virtualisation, il y a une perte de perfs au niveau des IO. Cependant, les dernières technologies (disques VIRTIO, etc) ont permis de récupérer une partie de ces pertes.
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 … Heureusement qu'on est passés à Proxmox.
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
Migration mal terminée
Voir l'encadré plus haut.
J'ai pété le bridge sur le virtualiseur
Bon, partons du principe que le bridge est réparé sur le virtualiseur. Donc de votre côté tout a l'air d'aller. Mais attention, les vm n'auront plus de connexion. C'est fâcheux. Alors la méthode bourrine consiste tout simplement à redémarrer la vm et basta. Mais vous allez me dire, comment faire si je n'ai pas envie de redémarrer la vm (Par exemple, j'ai joué avec le virtualiseur qui porte la vm irc et j'ai pas envie de rebooter ce serveur).
Première chose à faire, vérifiez que vous arrivez à avoir un shell dessus. Si vous avez juste redémarré le bridge, la console sur l'interface web ne fonctionnera probablement pas. En revanche, vous pouvez vous connecter en en émulant une connexion série. Attention, vu que vous aurez cassé sa connexion, elle ne pourra pas parler au ldap et donc il faudra vous connecter en root dessus.
- Si tout va bien dessus, c'est que le problème est entre le virtualiseur et la vm. Il suffit alors de lancer une migration sur un autre virtualiseur du cluster et pouf, c'est réparé et vous n'avez pas rebooté la vm!