Gandi vous fournit un serveur virtuel adapté à vos besoins. Notez cependant que les nombreux avantages d'un tel serveur impliquent des responsabilités liées au bon fonctionnement du système. Gandi ne peut intervenir dans votre gestion du serveur, corriger des erreurs à votre place ou encore vous assister quant à sa configuration.
Attention :
Si une opération effectuée sur un de vos serveurs est en erreur, rendez vous dans la liste des opérations et cliquez sur l'icône 'relancer' en forme de flèche !Si cela ne passe toujours pas, l'arrêt / démarrage en deux temps qui permet à l'instance d'être réinitialisée est une procédure qui peut faire passer certaines opérations.
Si l'opération n'aboutit toujours pas, vous pouvez contacter notre support par le formulaire !
Voici un tableau vous permettant de consulter les solutions aux problèmes les plus fréquemment rencontrés.
Soit par FTP avec l'utilisateur associé au virtualhost configuré dans le serveur web, soit par SSH/SFTP avec l'utilisateur admin et le mot de passe de création du serveur.
Voici comment déposer des fichiers
Il est alors nécessaire de configurer de nouveau le serveur d'hébergement sur l'interface, dans la rubrique 'serveur web', déployez le virtualhost concerné et mettez à jour l'utilisateur FTP correspondant.
Vous devrez quitter Gandi AI pour ce faire, en effet, cela requiert les droits root. L'opération est irréversible, le serveur sera uniquement gérable en ligne de commande. Installez alors le certificat sur le serveur web Apache2.
Vous devez passer par le support qui activera le module pour vous ou bien vous demandera de passer en mode root pour faire la modification vous-même selon la complexité de la configuration. Typiquement, nous pouvons installer php-imap mais n'installerons pas les librairies complémentaires par PEAR.
Vous devez modifier certains paramètres sur le serveur en utilisant le compte système 'admin' en vous connectant par SSH ou par SFTP. Typiquement les valeurs des options post_max_size et upload_max_filesize. Cependant, l'import de bases de données en ligne de commande est plutôt conseillé.
Cette opération nécessite les droits root, vous perdrez donc l'avantage de Gandi AI définitivement et devrez gérer le serveur en ligne de commande et donc suivre la procédure suivante pour finaliser l'agrandissement. Sinon il faudra créer un nouveau serveur virtuel pour récupérer le quota disque attribué par erreur.
Vous avez plusieurs solutions pour tester les virtualhosts sans pointer le domaine en mode production :
http://123.123.123.123/site1/
http://123.123.123.123/site2/
…
Remplacez 123.123.123.123 par l'adresse IP de votre serveur virtuel.
Vous devrez migrer sur la nouvelle version de Gandi AI pour pouvoir mettre à jour les modules tel que PHP, l'ancienne version ne disposant que de vieilles versions des modules et ne peut proposer les versions supérieures.
Connectez vous par SSH à votre serveur
Utilisez alors la console d'urgence du mode expert
Sur Ubuntu ou Debian, utilisez Apt-get ou Aptitude - Sur CentOS ou Fedora, utilisez alors Yum au lieu d'Apt-get
ssh-keygen -R votre_adresse_IP
Mettez alors à jour les modules de votre noyau (kernel)
Corrigez les erreurs pour mettre à jour les paquets.
Il vous faut suivre la procédure d'agrandissement pour votre disque, attention, celle-ci diffère selon que le disque soit de type données ou système. Le paquet gandi-hosting-vm doit être à jour, si vous ne l'aviez pas mis à jour, effectuez l'opération et arrêtez votre serveur en deux temps sur l'interface.
En effet nous avons préparé l'image Debian 6 pour fonctionner avec notre nouvelle infrastructure de stockage, et les disques sont maintenant "flat", sans table de partition : votre disque est présenté au serveur virtuel comme xvda1.
L'avantage est que vous n'avez plus besoin d'editer la partition pour redimensionner le disque systeme (un resize2fs /dev/xvda1 fonctionne desormais "a chaud").
Comme vous le remarquez, l'inconvénient pour l'instant est que le swap a disparu également, seul le nouveau système de stockage sachant le gérer en disque supplémentaire : vous pouvez creer un fichier swap si besoin en attendant d'être migré (dans l'année) sur ce nouveau système.
Je vous invite à lire l'explication technique ici
Le package gandi-hosting-vm est installé sur toutes les images configurées par notre équipe technique. Il installe les fichiers directement dans les bons repertoires et vous disposez d'un fichier de configuration pour modifier son comportement au démarrage de la VM dans /etc/sysconfig/gandi. Plus d'information : http://lacuisinedegandi.net/post/2010/10/28/Modification-des-OS-standards-par-Gandi
Dans le cas d'un détachement de disque et en dehors d'un incident sur notre plate-forme d’hébergement, la cause principale est la présence en mémoire d'applications qui utiliseraient encore des fichiers sur le disque à détacher. Typiquement quand le noyau ne peut pas rendre le disque au sous-système Xen, il affichera un message d'erreur dans la sortie 'dmesg'.
En utilisant 'lsof' ou 'fuser' vous pourrez identifier quelle(s) application(s) utilisent encore la ressource.
Si le serveur virtuel ne démarre plus, détacher le disque principale pour le ré-attacher sur un autre serveur afin de vérifier le système de fichier par la commande fsck. Si le disque sur le deuxième serveur est sdf : fsck -nf /dev/sdf pour avoir une idée des erreurs puis fsck -f /dev/sdf. Pendant que le disque est encore attaché, regarder dans les fichiers de log dans /var/log (notamment kern.log, messages) pour avoir une idée du problème bloquant et de sa résolution.
En réattachant le disque sur le serveur initial et en passant une opération de démarrage, la situation devrait etre rétablie.
Les disques supplémentaires peuvent etre vérifié de la meme manière sur le serveur si il a démarré ou sur un deuxième serveur en détachant puis attachant le disque par la commande fsck. Vérifier que le disque est bien attaché au serveur mais pas monté. Si le disque est sdg, umount /dev/sdg démonte le disque et fsck -nf /dev/sdg permet d'avoir connaissance des problèmes puis fsck -f /dev/sdg permet de corriger le système de fichier en répondant au question.
Comment le message l'indique cette information est un warning qui tient au fait que la version locale de la commande expr est un peu vieille par rapport à la gestion des expressions régulières. Ce warning peux etre ignoré.
CentOS installe par défaut iscsi et iscsid, que vous pouvez arreter et/ou désinstaller, nous les utilisons pour la partie backend mais pas sur les serveurs virtuels, cela n'impactera pas le fonctionnement du serveur et évitera de remplir les logs.
Il est alors nécessaire de suivre la procédure suivante :
- installer et activer le repository EPEL - installer le package python-ctypes
Gsync fonctionne (Merci à Christophe Gimenez pour cette remontée).
Les nouveaux noyaux ne supportent pas XFS, il faudra créer un disque qui sera au format Ext4 sur notre plateforme puis y transférer les données.
Vous n'avez pas indiqué la bonne adresse IP, ou le serveur n'existe pas sur cette IP. Vérifiez le status de votre serveur sur la page d'administration
Les ressources monitorées le sont par notre infrastructure Xen, la mémoire vive devra être vérifiée par un programme fonctionnant dans le serveur virtuel, plus de détails ici
Le noyau utilisé par un serveur virtuel au démarrage est fournis par l'infrastructure Xen. Les noyaux installés par les distributions ou par une compilation locale ne peuvent être utilisés. L'équipe de Gandi fournit une liste de version de noyau associable avec votre serveur. Voir la question suivante pour choisir la version du noyau.
Le noyau utilisé pour démarrer un serveur virtuel est associé au disque 'principal'. Ce disque est indiqué comme 'Disque de boot' dans la page de détail du serveur virtuel dans le compte client rubrique hébergement. Dans la page détaillée de ce disque - accessible en cliquant sur le nom du disque - vous pouvez choisir la version du noyau associée. Après validation de l'opération il vous faudra stopper puis démarrer votre machine virtuelle.
Cela est dû au paramétrage du système de fichiers en ce qui concerne les options pour inotify, cela prévient le kernel d'un changement dans un dossier concernant Gsync, si ces options sont trop basses, Gsync ne fera pas la sauvegarde en entier. En Gandi AI, passez par le support pour que nous adaptions les valeurs, en mode expert, voici les directives à modifier dans le fichier /etc/sysctl.conf :
fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.inotify.max_queued_events = 16384
Note :
Pour appliquer les changements, entrez les options dans le fichier /etc/sysctl.conf, puis lancez la commande : sysctl -p /etc/sysctl.confLes "write barriers" font partie d'un mécanisme utilisé par les systèmes de fichiers journalisés pour garantir l'ordre d'arrivée de certaines requêtes vers le disque. L'implémentation actuelle est peu efficace et sur le point d'être améliorée. Leur impact sur les performances est fort pour de rares problèmes de corruption en cas de crash au mauvais moment. LVM ("device-mapper") et notre configuration Xen actuelle ne supportent pas cette fonctionnalité.
Votre FS détecte la capacité du disque à gérer cette fonction au montage, en tentant de poser un "write barrier". L'erreur (normale) retournée par le sous-système "disque" est enregistrée par le système de gestion des requêtes de manière "systématique" et provoque ce log ainsi qu'un message comme "JBD: barrier-based sync failed on XXX" qui peuvent être ignorés.
Si cette erreur apparaît en dehors de ce contexte (pendant le boot, a l'attachement de disque) ou accompagné d'un autre type de message, il faut bien sûr toujours s'inquiéter.
A partir d'avril 2011 Gandi a mis en place une nouvelle infrastructure de stockage en parallèle de l'ancienne basée sur LVM. Dans le nouveau modèle le disque principale de votre serveur ne contient plus de table de partition. Le système de fichier est directement dans le disque /dev/xvda1.
Si le fichier /proc/partitions ne contient plus xvda mais seulement xvda1 vous êtes dans ce cas. Il vous suffira de faire un resize2fs sur /dev/xvda1 pour redimensionner votre disque sans passer par l'étape de fdisk :
resize2fs /dev/xvda1
La commande peux retourner une erreur indiquant de vérifier le système de fichier.
Ce que vous voyez est en fait les processeurs de la machine physique, pour voir les processeurs virtuels, il est préférable d'utiliser la commande "top" puis d'appuyer sur la touche "1" pour voir les coeurs séparés.
En utilisant l'API hosting Gandi (http://doc.rpc.gandi.net) et en une interface supplémentaire sur votre serveur avec le service en 'maitre'. Vous pouvez ainsi monitorer votre serveur/service et avec l'API détacher votre interface supplémentaire de votre serveur (vm.iface_detach) puis attacher cette interface sur le 2eme serveur chez Gandi avec le service en 'esclave' que vous aurez préparer (vm.iface_attach). Une fois l'interface migrer en moins de quelques minutes (si tout va bien), vous pourrez pinguer la gateway par défaut pour demander un clear ARP.
Si votre serveur secondaire est chez un autre fournisseur de 'cloud', la solution DNS avec un TTL très bas peux être une solution en gardant en tête que les caches DNS des fournisseurs d’accès modifie le TTL des zones pour configurer leur valeur de TTL bas (ex Free/Proxad).
Une autre solution est d'utiliser un redirecteur devant vos services qui dispatchera vos visiteurs entre vos 2 instances suivant la disponibilité (failover) ou même en balance de charge. Par exemple : si votre service est accesible en HTTP, un simple reverse proxy tel que Varnish ou un Nginx sur une machine en amont pourra faire l'affaire.
Evidemment mettre cette machine sans redondance ne fait que déplacer le SPOF (Single point of failure).
Dernière modification: le 29/09/2011 à 17:45 par Emerick M. (Gandi)