Les serveurs RHEL6 peuvent-ils être «copiés»?

Mon entreprise doit configurer un serveur de développement et nous avons déjà 2 serveurs de production RHEL 6 fonctionnant sous un commutateur L4.

L'une des solutions pour configurer le serveur de développement était de copier simplement tous les fichiers depuis l'un des serveurs de production et de le modifier un peu.

Je ne l'ai jamais fait auparavant, mais cela ressemble à l'imagerie fantôme ... peut-il être fait? Est-ce recommandé? Serait-il sujet à des erreurs?

La copie de tous les fichiers peut fonctionner. Cela dépendra du système d'exploitation et du type de méthode de copie.

Un problème général est d'essayer de copier le système en cours d'exécution. En règle générale, au moins certains des fichiers seront verrouillés et ne seront donc pas copiés correctement. L'utilisation d'une sorte de logiciel d'imagerie alors que le système est arrêté est généralement la plus sûre (vous avez mentionné Ghost qui en est un exemple)

Pourquoi ne pas convertir les systèmes en cours d'exécution en machines virtuelles? La plupart des hyperviseurs comme VMware ou Hyper-V disposent d'un outil pour convertir facilement un système en cours d'exécution en une machine virtuelle.

Vous pouvez ensuite travailler avec un système hors production comme vous le souhaitez avant de faire quoi que ce soit sur un serveur de production.

Merci à @WernerCD

Vmware

Hyper-V

Peut-on le faire?

Définitivement oui. J'ai copié un serveur Linux entier en emballant simplement les fichiers avec taret en les extrayant à nouveau sur le serveur cible. La seule mise en garde dont je me souvienne était de ne pas oublier de l'utiliser --numeric-ownerlors de l'extraction. Je ne peux pas parler pour d'autres systèmes d'exploitation et d'autres outils, mais j'imagine que c'est faisable avec tous les principaux systèmes d'exploitation.

Faut-il le faire?

Cette question est un peu plus compliquée à répondre. Je ne recommanderai pas simplement le clonage d'un système de production à des fins de développement. Il peut très bien contenir de nombreuses données utilisateur ainsi que des éléments clés que vous ne souhaitez pas avoir sur les systèmes de développement.

Mais le clonage de votre système de production peut être une bonne idée à d'autres fins.

L'approche que je recommanderais pour créer un clone du système de production est de restaurer à partir d'une sauvegarde. Vous pouvez éviter un impact sur les performances du système de production en effectuant une restauration à partir d'une sauvegarde et vous pouvez tester votre procédure de restauration, ce qui est une bonne chose.

Il est important de garder le clone que vous avez restauré à partir d'une sauvegarde isolé du reste du monde. Puisqu'il a été restauré à partir d'une sauvegarde d'un système de production, il peut contenir des travaux automatisés, qui communiqueront avec d'autres systèmes de production, et il aura les informations d'identification pour le faire.

Vous pourriez potentiellement causer beaucoup de dégâts si le clone communiquait avec de vrais systèmes de production.

Mais si vous le gardez isolé, cela vous donne la possibilité de tester que le système restauré fonctionne comme prévu. De plus, un tel système restauré pourrait être un environnement utile pour le dernier test de nouveau code avant son déploiement en production. Cela peut être votre seule opportunité de tester le code sur des données utilisateur réelles, avant qu'il ne soit réellement en mesure de casser le système de production.

Faisabilité

Bien sûr, c'est possible, car il n'est pas difficile «d'installer» Linux en utilisant des moyens non conventionnels. Vous pouvez, par exemple, répliquer le serveur à l'aide de rsync sur SSH.

1. Démarrez la machine cible dans une image de «sauvetage», que vous utilisiez un DVD Red Hat, un démarrage en direct Ubuntu, Knoppix, peu importe.
2. Partitionnez et formatez la machine cible et montez les systèmes de fichiers sous a /target.
3. rsync tous les systèmes de fichiers pertinents sur SSH (sauter /proc, /sys, swap).
4. Corrigez /target/etc/fstab, surtout si les partitions sont référencées par UUID.
5. Ajustez le nom d'hôte et la configuration du réseau, le cas échéant.
6. Installez le chargeur de démarrage.

L'étape 3 peut consister en plusieurs passes rsync, éventuellement aidées par des instantanés LVM sur la machine source, la dernière passe avec tous les services sur la machine source arrêtés pour garantir la cohérence des données.

Souhaitabilité et meilleures pratiques

Ce n'est pas parce que vous le pouvez que vous le devriez. J'ai recommandé le processus ci-dessus comme une façon de faire une migration de centre de données. Cependant, votre cas d'utilisation est assez différent. Le recours au clonage met en évidence certaines lacunes:

• La virtualisation serait une bonne capacité à avoir et rendrait la réplication facile.
• Avez-vous des sauvegardes de vos serveurs de production? Pourquoi ne pas simplement les restaurer? Ce serait un bon test de votre procédure de restauration de sauvegarde.
• Avez-vous une documentation sur la façon de tout reproduire à partir de zéro? Finalement, vous devrez probablement installer à partir de zéro, peut-être lorsque vous mettez à niveau le système d'exploitation. Ce serait une bonne validation de votre documentation.
• Mieux encore, avez-vous une automatisation qui vous aide à reproduire votre configuration? Un script shell pourrait fonctionner; une solution de gestion de configuration telle que CFengine, Puppet, Chef ou Ansible serait encore mieux.

Si vous clonez aveuglément le serveur de production, vous perdrez une précieuse opportunité de clarifier exactement ce qui fonctionne dessus.