Sommaire
Les serveurs F*, à savoir fz, ft et stitch (ben quoi ?) sont des serveurs de sous Proxmox VE qui permettent de créer des machines virtuelles.
Les accès disques se faisant par iscsi sur la baie SAS nols, il est aisé de migrer à chaud les guests (KVM/OVZ) d'un host à un autre. Ils se trouvent au 0B.
Les KVM
Il y a deux types de virtualisation par proxmox :
- la virtualisation matérielle (ou complète), on parle alors de KVM (Kernel-based Virtual Machine), de vm, ou de guest.
- la virtualisation par container, on parle alors de Serveurs Privés Virtuels (VPS), d'Environnements Virtuels (VE) ou Containers.
C'est le premier type qui est utilisé au Cr@ns, mais il n'est pas exclu qu'on fasse usage du second en cas de besoin.
Utilisés
Serveur de secours, MX secondaire et DNS récursif secondaire sur la vm titanic
Serveur DNS récursif secondaire sur la vm nem (Point daniel : nemserver)
Serveur pour les install-parties (accès à l'extérieur) sur la vm ytrap-llatsni
Serveur web, pour le wiki et les autres sites statiques sur la vm niomniom
L'intranet sur la vm o2
Serveur POP/IMAP sur la vm owl:
pop et imap sont deux services pour pouvoir relever son mail. IMAP sait gérer plusieurs dossiers et laisse le courrier sur le serveur. Attention alors à ne pas dépasser les quotas. POP est plus simple, les mails sont tous rapatriés sur la machine de l'utilisateur. Dans les deux cas, préférez les connexions sécurisées (cf. VieCrans/ParamètresConnexion). Ce sont d'ailleurs les seules à être disponibles depuis l'extérieur.
Le nom du serveur POP est pop.crans.org, port 995 avec SSL
Le nom du serveur IMAP est imap.crans.org, port 993 avec SSL
Serveur d'authentification radius filaire pour les switchs sur la vm radius
Serveur d'authentification radius WiFi (eap) secondaire sur la vm pea (eap à l'envert, au départ, je voulais juste parler de petit pois -- PeBecue 2014-03-26 11:26:00 )
Serveur LDAP et hébergement principal de cranspasswords sur la vm vert (nom datant de l'époque où le Crans avait trois serveurs, rouge (démantelé en août 2012), vert et bleu (zamok))
Serveur d'authentification centralisée sur la vm cas
Serveur d'édition collaborative (gobby, etherpad) sur le guest kenobi (On a voulu l'appeler Kenobby, puis on s'est ravisés)
Serveur d'édition collaborative ethercalc (pour faire de la spreadsheet googledocs like) sur le guest ethercalc (original)
Serveur d'hébergement de vidéos et d'enregistrement audios sur la vm mediadrop
Serveur MX principal et de mailing-liste sur la vm redisdead (qui a été créé bien avant le démantèlement de rouge)
Routeur entre différents sous-réseaux (accueil, isolement, v6) sur le guest routeur
Serveur centralisant les dépôts bare git, et accueillant également le GitLab du Crans, qu'on devrait commencer à remplir sous peu, sur la vm geet
En test
[en test] Serveur SIP via le guest asterisk abandonné -> migrer vers le panthéon
[en test] Serveur de translation d'adresse ipv6<->ipv4 via le guest nat64 abandonné -> migrer vers le panthéon
[en test] Bac à sable pour nounous sur lequel tourne limesurvey: alice (aucune connivence avec la mascotte d'un BdE)
[en test] Serveur pour tester le message broker Rabbitmq : civet
Les autres
[en playground] Serveur bac à sable pour les apprentis, la vm apprentis
[FedeRez] Forge (hébergement des repositories de FedeRez), la vm baldrick
[Rezosup] Nœud IRC pour rezosup sur la vm rezosup
Sous Proxmox
Comment installer un virtualiseur Proxmox ? -> InstallerUnVirtualiseurProxmox
Matériel actuel
Il y a actuellement trois virtualiseurs, fz, ft et stitch :
ft
- 24 cœurs (un double hexacore hyperthreadé)
- 32 Gio de RAM
- Quatre interfaces réseau (dont une pour l'iscsi)
Accès aux disques des baies slon et nols
/usr/scripts over nfs.
stitch
- 32 cœurs (double octocore hyperthreadé)
- 32 Gio de RAM
- Quatre interfaces réseau (dont une pour l'iscsi)
Accès aux disques de la baie slon et de la baie nols
/usr/scripts over nfs.
fz
- 16 cœurs (double quadcore hyperthreadé)
- 16 Gio de mémoire
- deux interfaces réseau (une pour l'iscsi)
- Accès en iscsi sur les disques durs présents dans la baie SAS slon
/usr/scripts over nfs.
Vieux
kdell
- 8 cœurs (quadcore hyperthreadé)
- 16 Gio
- deux interfaces réseau (une pour l'iscsi)
- Accès en iscsi sur les disques durs présents dans la baie SAS slon
/usr/scripts over nfs.
Sous Debian Wheezy, avec le noyau 3.2.0-4, avant.
Fy
- 8 cœurs
- 16 Go de mémoire
- deux interfaces réseau (une liée à l'iscsi pour l'instant)
/usr/scripts over nfs.
Why did you leave, fy ?
Nous avons découvert récemment la cause probable des problèmes de migration entre fy et fz sous Xen. Ce comparatif proposé par Intel recense les processeurs des quatre machines ft, fz, fy et kdell.
Pour être aptes à virtualiser, les processeurs ont besoin de technologies relativement anciennes, et sont tous quatre aptes à cet usage. Cependant, et il était relativement impossible de le savoir, que ça soit pour notre fournisseur, ou nous, lors de l'achat, le processeur de fy, un Xeon E5450, ne dispose pas des technologies VT-d (pas critique), ni VT-x, with extended page tables. Cette seconde technologie est une amélioration de la tech VT-x, qui sert à mapper la mémoire virtuelle des VM vers la mémoire physique de la machine par le biais du processeur (nécessaire pour faire tourner des guests KVM). Cette extension permet un gain de performance (par réduction de l'overhead engendré par le mapping de la mémoire virtuelle) relativement élevé. Son coût est qu'une migration d'un guest lancé en « real mode » (en bénéficiant de ladite tech) ne peut être migré sur un host ne supportant pas cette technologie.
S'il semble que Proxmox soit (à moitié) protégé contre ce genre de problème (le guest est récupérable, mais inutilisable tant qu'il n'est pas remigré sur une machine avec VT-x with extended page tables), il semblerait que Xen ne savait pas récupérer ce genre d'erreur, ce qui menait au crash du domU migré.
fy ne pouvant être ajouté au cluster, il est parti faire du monitoring.