[a-h-aide] Solution pour redéployer un serveur rapidement
Bonjour, Je souhaite savoir quelles sont les bonnes pratiques à prendre pour pouvoir redéployer un serveur rapidement. Cas typique : Panne matériel, j'ai une machine dans un coin, elle fera l'affaire le temps que je répare le tout. En gros, créer un clone à partir de backup. J'imagine qu'il faut passer par de la virtualisation. Avez-vous des pistes, retours d'expérience ? Y a t-il des spécificités à prendre en compte pour les backup ? Merci. -- François Boulogne.
Afficher les réponses par date
Hello !
Je souhaite savoir quelles sont les bonnes pratiques à prendre pour pouvoir redéployer un serveur rapidement. Cas typique : Panne matériel, j'ai une machine dans un coin, elle fera l'affaire le temps que je répare le tout. En gros, créer un clone à partir de backup.
Faire des backups réguliers (et fiables si possible...), disposer d'un serveur de secours prêt à l'emploi (si c'est possible). Il manque des infos pour être précis : OS, services utilisés, espace disque utilisé, etc.
J'imagine qu'il faut passer par de la virtualisation. Avez-vous des pistes, retours d'expérience ? Y a t-il des spécificités à prendre en compte pour les backup ?
La virtualisation simplifie grandement les opérations de migration : il suffit de remonter un serveur hôte (étape plutôt simple) et ensuite de restaurer les machines virtuelles. Ce qui prend le plus de temps, c'est de récupérer les backups s'ils sont stockés sur un serveur distant. Je bosse justement en ce moment sur des scripts permettant d'effectuer des sauvegardes/réplication/restauration de containers OpenVZ et d'ici peu de temps les scripts seront disponibles sous licence GPL v3. Pour la virtualisation j'utilise Proxmox : ça m'a changé la vie. :) Au début j'étais un peu réticent mais après pas mal de discussions avec d'autres personnes (dont Exca), aujourd'hui ça me parait impossible de revenir en arrière, la souplesse apportée est bien trop grande par rapport à un serveur "classique". A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Le 14/09/2012 20:56, tranxene50 a écrit : > Hello ! > >> Je souhaite savoir quelles sont les bonnes pratiques à prendre pour >> pouvoir redéployer un serveur rapidement. Cas typique : Panne >> matériel, j'ai une machine dans un coin, elle fera l'affaire le >> temps que je répare le tout. En gros, créer un clone à partir de >> backup. > Faire des backups réguliers (et fiables si possible...), disposer d'un > serveur de secours prêt à l'emploi (si c'est possible). Pas possible pour le moment. > > Il manque des infos pour être précis : OS, services utilisés, espace > disque utilisé, etc. Gnu Linux debian avec du web, git, dns. Très faible espace disque utilisé (qq % sur un To) > > Je bosse justement en ce moment sur des scripts permettant d'effectuer > des sauvegardes/réplication/restauration de containers OpenVZ et d'ici > peu de temps les scripts seront disponibles sous licence GPL v3. Pour > la virtualisation j'utilise Proxmox : ça m'a changé la vie. :) Je note, ça semble très intéressant, merci ! > Je ne vois pas trop ce que de la virtualisation apporterait > d'intéressant pour cela. C'est très simple, sauf dans le cas où la > panne concerne justement le disque dur. Dans ce second cas, il est > inutile de disposer d'une machine de rechange, ce qu'il faut c'est un > disque dure de rechange, y charger le système sauvegarder, installer > correctement un chargeur de démarrage, et démarrer. Dans le monde théorique, vrai. Dans mon monde pratique, ça l'est moins. Des raisons : * C'est de l'auto-hébergement, mais le serveur n'est pas chez moi mais chez des gens qui n'ont pas les compétences d'intervenir dessus. * Le système d’accueil est ce que je trouve (netbook, vieux trucs qui traînent... et pourquoi pas un serveur non accessible physiquement) > Tu as la possibilité de faire des images complètes de la machine à > sauvegarder mais ça peut rapidement générer des volumes très importants. > > On peut aussi utilisé des logiciels de gestion de configuration (cfengine, > puppet, ...) qui permettent de reproduire une configuration sur n serveurs > très rapidement. J'ai assisté ce week-end à une présentation sur python fabric qui va dans ce sens. Je vais explorer aussi cette piste. Merci. François.
Hello !
Faire des backups réguliers (et fiables si possible...), disposer d'un serveur de secours prêt à l'emploi (si c'est possible). Pas possible pour le moment.
Les backups c'est obligatoire. (Perdu 2 ans de boulot perso il y a 15 ans, je m'en souviens encore très bien, surtout les "sensations" qui remontent du bas du dos jusqu'à la nuque...) Concernant le serveur de secours, deux solutions : 1) un autre auto-hébergé partage son CPU, un peu de mémoire, de l'espace disque et surtout sa bonne humeur pour t'allouer une ou plusieurs machines virtuelles au sein de son serveur. Le principal problème, c'est IPV4 : les FAI n'allouent qu'une seule IPV4 par abonné donc si tu as besoin de faire tourner un serveur web, mail, ftp, etc. ça va pas être possible à moins d'utiliser sur le serveur hôte plusieurs reverse proxy pour rediriger les requêtes vers la bonne VM. (testé, ça marche mais disons que c'est un plutôt "chiant") Par contre, en IPV6, pas de souci, au final c'est du routage tout bête. 2) louer un VPS chez un hébergeur low-cost (ou plus sérieux) Pas testé. (Et ce n'est plus de l'auto-hébergement pur jus donc forcément c'est mal ! ^^) Plus sérieusement, attention aux offres low-cost, la plupart du temps les hébergeurs font de l'overselling comme des malades, c'est à dire qu'ils "bourrent" leurs serveurs en tablant, d'après leurs stats, qu'aucun client n'utilisera vraiment les ressources dont il a droit. Évidement, pour une bascule rapide, le VPS doit être loué avant la panne et être régulièrement synchronisé afin de disposer des backups récents. Sauf erreur, on ne peut pas installer un système de virtualisation sur ce genre de VPS (techniquement c'est possible mais, d'un point de vue commercial, cela revient à se tirer une balle dans le pied et comme les marketeux "dirigent" le monde, c'est mort, du moins pour l'instant).
Il manque des infos pour être précis : OS, services utilisés, espace disque utilisé, etc. Gnu Linux debian avec du web, git, dns. Très faible espace disque utilisé (qq % sur un To)
Un VPS (chez un autre auto-hébergé ou payant) fera largement l'affaire.
Je bosse justement en ce moment sur des scripts permettant d'effectuer des sauvegardes/réplication/restauration de containers OpenVZ et d'ici peu de temps les scripts seront disponibles sous licence GPL v3. Pour la virtualisation j'utilise Proxmox : ça m'a changé la vie. :) Je note, ça semble très intéressant, merci !
Les scripts fonctionnent mais j'ai un problème au niveau des IOPS générés sur le serveur distant, celui qui reçoit les backups. Je pensais dans un premier temps avoir résolu le problème mais en fait non. Du coup je teste autre chose. Comme d'hab cela semble prometteur mais je ne m'emballe pas pour autant car, même si les tests sont pour l'instant plutôt concluants, on va voir à l'usage. L'idée est de conserver un historique de 30 jours d'un serveur complet.
Dans le monde théorique, vrai. Dans mon monde pratique, ça l'est moins. Des raisons : * C'est de l'auto-hébergement, mais le serveur n'est pas chez moi mais chez des gens qui n'ont pas les compétences d'intervenir dessus. * Le système d’accueil est ce que je trouve (netbook, vieux trucs qui traînent... et pourquoi pas un serveur non accessible physiquement)
Contacte Exca, il est dans la même problématique : son serveur n'est pas accessible physiquement et pourtant son uptime est très bon.
J'ai assisté ce week-end à une présentation sur python fabric qui va dans ce sens. Je vais explorer aussi cette piste. Merci.
Il y a aussi Csync2 qui peut servir. A+ -- tranxene50 tranxene50@developpeur-neurasthenique.fr
Hello, Excerpts from tranxene50's message of mar. sept. 18 21:05:15 +0200 2012:
2) louer un VPS chez un hébergeur low-cost (ou plus sérieux)
Pas testé. (Et ce n'est plus de l'auto-hébergement pur jus donc forcément c'est mal ! ^^)
Pas forcement chez un gros hébergeur, il peut être intéressant de se tourner vers des hébergeurs associatifs dans notre cas. Je suis dans cette solution, à savoir une machine que j'auto-héberge, et une VM chez Tetaneutral qui est capable de prendre le relais si mon serveur/ma connexion est HS (enfin, c'est plutôt en projet on va dire ;-) ). Ce n'est serte pas de l'auto-hébergement, mais c'est à mon avis infiniment mieux que de prendre une VM chez Amazon, OVH ou autre, vu que l'asso milite en général pour la neutralité et la décentralisation du Net (en tout cas pour Tetaneutral). De mémoire, je crois qu'il y a aussi Toile-Libre qui avait ce projet de mettre à disposition des VM, mais je ne sais pas où ça en est. -- Romain Dessort Jabber ID : romain@univers-libre.net GnuPG : 3072D/724BC532
Ce n'est serte pas de l'auto-hébergement, mais c'est à mon avis infiniment mieux que de prendre une VM chez Amazon, OVH ou autre, vu que l'asso milite en général pour la neutralité et la décentralisation du Net (en tout cas pour Tetaneutral).
Bof, s'il s'agit d'une solution de secours en cas de problème, n'est-ce pas de l'auto-hebergement tout de même ? Le fait que le serveur de secours ou bien une sauvegarde soit chez OVH, ce n'est pas comme un cloud apple tout de même ! Thomas,
Olá !
Bof, s'il s'agit d'une solution de secours en cas de problème, n'est-ce pas de l'auto-hebergement tout de même ? Le fait que le serveur de secours ou bien une sauvegarde soit chez OVH, ce n'est pas comme un cloud apple tout de même !
Peut être un point important à considérer, nos serveurs à nous, auto-hébergés, contiennent souvent nos données personnelles (e-mails et autres documents) et/ou celles de nos proches. Une solution de secours, pour avoir une utilité, doit être régulièrement (voir constamment) à jour et synchronisée, y compris les données. Ma principale motivation pour l'auto-hébergement, est de pouvoir décider où sont mes données et comment elles sont accessibles. Sur l'hébergement gratuit ou non, chez une entreprise pour laquelle je ne maitrise ni l'emplacement de mes données, ni le moyen d'y accéder, ni l'usage qui en est fait (de manière transparente ou cachée, manuelle, ou automatique), j'évite d'y mettre mes données (pour le moins, les données que je ne peux pas chiffrer). Pour une solution de secours, j'appliquerais les mêmes préoccupations que pour mon propre matériel, tant d'un point de vue de la sécurité des accès, des données et de leur usage. Si je me pose des contraintes moi-même, je trouve qu'il est important de connaître les contraintes et les limites de ceux qui vont me fournir ce type de redondance. Pour la virtualisation, le plus gros blocage que j'ai trouvé, c'est la taille des backups des machines virtuelles. C'était un problème dans le cas de la virtualisation classique (VMWare, KVM, etc.), maintenant qu'il y a OpenVZ, je compte environ 200 Mo pour le système de base, le reste ne sont que des données utiles. En vrac, quelques trucs sympa sous Debian pour remettre facilement un serveur en fonctionnement :
Il est possible de lister l'ensemble des paquetages installés grâce à la commande : dpkg --get-selections
Grâce à cet outil il est ainsi possible d'exporter la liste des paquetages installés de la manière suivante : dpkg --get-selections > mes_paquetages
Puis de les installer avec la commande suivante sur une autre machine : Récupération de la liste précédente : dpkg --set-selections < mes_paquetages
Installation de la liste : apt-get dselect-upgrade
Après ça, il ne reste plus qu'à recopier les données (en remontant une partition /var complète par exemple, et sa configuration, idem avec /etc, ça parait un peu violent, mais ça devrait pouvoir fonctionner après un reboot). Je ne sais plus où, mais j'ai lu que "contrairement à Window$, Linux aime les changement d'environnement". Retirer un disque dur pour le mettre dans une machine différente n'est pas une idée déconnante. Il y a de grandes chances que tout se lance correctement au boot (enfin, pour tout ce qui concerne les services, après, le serveur X et les cartes réseau, c'est une autre histoire). Plus bourrin encore, le backup d'un système complet à partir de la racine "/" en ignorant seulement les dossier /mnt /tmp /proc et /sys. Les backups, c'est bon pour la santé mentale ! Enjoy, --- -- Exca -- http://www.sychlora.com
Exca Flounty, 2012-09-19 10:23-0300:
Plus bourrin encore, le backup d'un système complet à partir de la racine "/" en ignorant seulement les dossier /mnt /tmp /proc et /sys.
rsync --one-file-system rulez. Et avec LVM pour faire un copie cohérente, services coupés pendant dix secondes… -- . o . Tanguy Ortolo, internaute auto-hébergé . . o <http://www.auto-hebergement.fr/> o o o
Salut as tu vu turnkeylinux ? et sa solutions tklbam ? http://www.turnkeylinux.org/blog/announcing-tklbam http://www.turnkeylinux.org/docs/tklbam 2012/9/14 tranxene50 <tranxene50@developpeur-neurasthenique.fr>
Hello !
Je souhaite savoir quelles sont les bonnes pratiques à prendre pour pouvoir redéployer un serveur rapidement. Cas typique : Panne matériel, j'ai une machine dans un coin, elle fera l'affaire le temps que je répare le tout. En gros, créer un clone à partir de backup.
Faire des backups réguliers (et fiables si possible...), disposer d'un serveur de secours prêt à l'emploi (si c'est possible).
Il manque des infos pour être précis : OS, services utilisés, espace disque utilisé, etc.
J'imagine qu'il faut passer par de la virtualisation. Avez-vous des pistes, retours d'expérience ? Y a t-il des spécificités à prendre en compte pour les backup ?
La virtualisation simplifie grandement les opérations de migration : il suffit de remonter un serveur hôte (étape plutôt simple) et ensuite de restaurer les machines virtuelles.
Ce qui prend le plus de temps, c'est de récupérer les backups s'ils sont stockés sur un serveur distant.
Je bosse justement en ce moment sur des scripts permettant d'effectuer des sauvegardes/réplication/restauration de containers OpenVZ et d'ici peu de temps les scripts seront disponibles sous licence GPL v3.
Pour la virtualisation j'utilise Proxmox : ça m'a changé la vie. :)
Au début j'étais un peu réticent mais après pas mal de discussions avec d'autres personnes (dont Exca), aujourd'hui ça me parait impossible de revenir en arrière, la souplesse apportée est bien trop grande par rapport à un serveur "classique".
A+
-- tranxene50 tranxene50@developpeur-neurasthenique.fr _______________________________________________ auto-hebergement-aide mailing list auto-hebergement-aide@listes.auto-hebergement.fr http://listes.auto-hebergement.fr/listinfo/auto-hebergement-aide
François Boulogne, 2012-09-14 20:24+0200:
Je souhaite savoir quelles sont les bonnes pratiques à prendre pour pouvoir redéployer un serveur rapidement. Cas typique : Panne matériel, j'ai une machine dans un coin, elle fera l'affaire le temps que je répare le tout. En gros, créer un clone à partir de backup.
Si la panne ne concerne pas le disque dur et que la machine de rechange a la même architecture matérielle (amd64, arm…) que le serveur principal : ôter le disque dur de l'ancien, le mettre dans le nouveau, démarrer. Ajuster la configuration réseau parce que l'interface aura changé de nom (eth0 → eth1), à part ça rien de particulier à faire.
J'imagine qu'il faut passer par de la virtualisation.
Je ne vois pas trop ce que de la virtualisation apporterait d'intéressant pour cela. C'est très simple, sauf dans le cas où la panne concerne justement le disque dur. Dans ce second cas, il est inutile de disposer d'une machine de rechange, ce qu'il faut c'est un disque dure de rechange, y charger le système sauvegarder, installer correctement un chargeur de démarrage, et démarrer. -- . o . Tanguy Ortolo, internaute auto-hébergé . . o <http://www.auto-hebergement.fr/> o o o
* François Boulogne [14/09/2012 20:39] :
J'imagine qu'il faut passer par de la virtualisation. Avez-vous des pistes, retours d'expérience ? Y a t-il des spécificités à prendre en compte pour les backup ?
Tu as la possibilité de faire des images complètes de la machine à sauvegarder mais ça peut rapidement générer des volumes très importants. On peut aussi utilisé des logiciels de gestion de configuration (cfengine, puppet, ...) qui permettent de reproduire une configuration sur n serveurs très rapidement. Emmanuel
participants (8)
-
Emmanuel Seyman -
Exca Flounty -
François Boulogne -
Romain Dessort -
Tanguy Ortolo -
Thomas Bouchet -
Tonton -
tranxene50