Retour : Page Principale > sommaire serveurs & domaines

Serveurs Gandi (cloud)


Instances actives


Serveurs virtuels "cloud public"

À compter du 25 octobre 2017, Tela Botanica possède un espace client "cloud public" chez Gandi, dans le but d'héberger le MOOC 2018 : la possibilité d'augmenter les ressources en payant en conséquence (élasticité) permet de réagir facilement aux potentiels pics d'utilisateurs.
L'avantage par rapport aux précédentes instances d'OVH est la meilleure élasticité, une offre plus lisible et (semble-t-il) de biens meilleures perfs à config égale.
Il faut noter que la facturation se fait à l'heure, il ne faut pas oublier de réduire les caractéristiques du serveur. À ce propos, le volume du disque dur ne peut être réduit dans la GUI, attention à ne pas l'augmenter de façon exagérée.

Durant la durée de diffusion d'un MOOC, il faut augmenter le nombre de CPU de 2 à 6 afin de faire face à la surcharge de fréquentation, et bien penser à remodifier à 2 à la fin.

TODO : finir la rédaction


Se connecter aux serveurs

En SSH :
L'accès en root avec mot de passe n'est pas possible
Il faut nécessairement avoir une clé ssh autorisée pour se connecter aux comptes admin et root
Pour autoriser une clé :
  • Activer la console d'urgence depuis la console Gandi : Cloud -> choix du serveur -> onglet Console d'urgence
  • Se connecter en SSH au compte "admin" après ajustĂ© le mot de passe de la console d'urgence au besoin
  • Ajouter votre clĂ© SSH au fichier /home/admin/.ssh/authorized_keys (une clĂ© par ligne)
  • Tester la connexion (ssh admin@mooc.tela-botanica.org devrait se rĂ©soudre automatiquement)
  • !!! Bien penser Ă  couper la console d'urgence !!!


RĂ©duire la taille d'un disque

On peut augmenter facilement la taille d'un disque en utilisant l'interface, mais impossible de faire machine arrière sans éteindre le serveur et toucher à la ligne de commande.
Ça se décompose comme ça :
  • Commencer par lire cette doc jusqu'Ă  la fin (oui oui)
  • CrĂ©er une copie du disque Ă  rĂ©duire (temporaire)
  • CrĂ©er un disque cible de la taille voulue
  • Copier les fichiers avec rsync entre les deux disques prĂ©cĂ©demment crĂ©Ă©s
  • Éditer la conf du grub pour changer le UUID du disque de dĂ©marrage
  • Couper le serveur et y monter le nouveau disque

Créer une copie du disque
Depuis la vue Disques, copier le disque à réduire en cliquant sur le bouton "dupliquer dans un disque" (si absent, l'ajouter à l'interface depuis les paramètres).
Créer ce disque dans la même localisation que celle du serveur.

Créer un disque cible de la taille voulue
Depuis la vue Disques, créer un nouveau disque d'une taille suffisante pour accueillir les fichiers à transférer. (Pour 24 Go à transférer j'ai créé un disque de 27 Go).
Créer ce disque dans la même localisation que celle du serveur.

Copier les fichiers avec rsync entre les deux disques précédemment créés
Faut commencer par monter le disque copié temporaire et le disque cible sur la même machine, de préférence dans la même localisation que les disques.
La commande df permet d'identifier les disques pour pouvoir adapter la commande rsync suivante :
(voir https://wiki.archlinux.org/index.php/Rsync#Full_system_backup pour l'explication)
rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /srv/disquetemporaire/ /srv/disquedestination/

Éditer la conf du grub pour changer le UUID du disque de démarrage
On va remplacer le UUID de l'ancien disque de boot par le nouveau dans la conf du grub sinon la machin voudra pas démarrer.
Faut commencer par trouver le UUID du disque de destination :

blkid | grep /dev/xvdX
X étant l'identifiant du disque de destination. La sortie ressemble à ça :
/dev/xvdd: LABEL="copie" UUID="bd0ff43f-6d57-46bb-b971-dd1f41b5b148" TYPE="ext3"

Ensuite on va Ă©diter le grub.cfg pour faire correspondre le UUID
vim /srv/disquedestination/boot/grub/grub.cfg
:%s/ancienUUID/nouveauUUID/g

Et hop !

Faut aussi Ă©diter le fstab pour faire correspondre le champs LABEL.

Couper le serveur et y monter le nouveau disque
Bon, le mieux c'est de tester sur un serveur différent créé pour l'occasion histoire de vérifier que ça marche.

Depuis la page d'édition des propriétés du disque, le passer en mode disque système et sélectionner le mode de grub approprié (dans mon cas c'est grub-x86_64 (xen)).
Faut attacher le disque de destination au serveur, puis bien cocher la case "Boot" depuis la vue détaillée du serveur et lancer le démarrage du serveur !

Si ça foire
Si ça foire genre le serveur est démarré mais pas accessible en SSH, faut démarrer la console d'urgence depuis la vue détaillée du serveur. Une fois loggué on peut voir les messages d'erreurs de boot et corriger ce qui ne va pas en recommençant les longues étapes d'attachement/détachement et démontages de disques et redémarrage de serveurs.
Donc vaut vraiment mieux tester sur un serveur différent et couper celui de prod seulement à la fin, le plus tard possible, quitte à repasser un coup de rsync (en excluant les fichiers de confs qu'on a modifié). Enfin ça dépend, faut voir, c'est au cas par cas.
Genre, pour le serveur du mooc le mieux c'est de tout monter sur le serveur (la copie et la destination), rsync la copie dans la destination, éditer la conf, mettre Moodle en maintenance, repasser un coup de rsync seulement sur les dossiers de moodle, couper le serveur et relancer sur le disque de destination. Ça minimise le temps de down, et en cas de foirage suffit de changer de disque de boot sans attendre les attaches/détaches.