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


8

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?

Réponses:


7

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)


C'est RHEL6. Peut-on le faire?
2014

RSYNC est conçu pour la mise en miroir et est disponible sur presque tous les systèmes. Vous pouvez l'utiliser.
Jeff Clayton

Cela dépend entièrement de l'application, je voudrais souligner. Si votre application est Websphere, par exemple, vous ne pouvez pas simplement récupérer tous les fichiers de configuration car ils font référence au nom du serveur.
mfinni

4
Qu'entendez-vous par « verrouillé »? C'est une vue assez Windows des choses. Le problème habituel avec la copie d'un FS en direct sous UNIX est que les fichiers changent sous vous pendant leur copie.
MadHatter

1
... un problème qui peut être évité avec les systèmes utilisant LVM en utilisant des instantanés LVM pour prendre une image cohérente du périphérique de bloc sous-jacent et en dupliquant cela, plutôt que d'exécuter des opérations de copie au niveau du système de fichiers.
Charles Duffy

17

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


J'ai bien peur que ce genre de modification soit hors de
propos

6
@ dK3 Je pense que vous vous méprenez. Vous ne modifieriez pas les serveurs de production (sauf si vous le souhaitez). Vous installeriez un petit outil sur l'un des serveurs de production pour laisser votre solution VM "l'explorer" et en créer une image. Vous installez la solution VM sur votre box de développement et la pointez sur l'image "convertie" de votre serveur prod. Donc, si vous n'avez pas encore d'environnement de développement, cette solution n'est pas un "changement" ...
svidgen

2
Google P2VPhysical to Virtual - Vmware: my.vmware.com/web/vmware/evalcenter?p=converter - HyperV: social.technet.microsoft.com/wiki/contents/articles/… - Virtualiser, sauvegarder, isoler (donc si ça pointe vers une base de données de production) et ensuite amusez
WernerCD

9

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.


1
copier un système via une restauration de sauvegarde ... probablement le meilleur car il accomplit plusieurs objectifs ...
Bart Silverstrim

1
J'ajouterais que le montage d'un système de développement à partir de zéro peut être un bon moyen de vérifier la documentation du système. S'il se produit que le montage d'un tel serveur ne peut pas être fait avec la documentation à portée de main, vous avez découvert un problème qui pourrait être critique pour le système de production (si vous avez besoin de le migrer, d'installer le système pour une autre branche ou de faire une catastrophe. récupération).
SJuan76

6

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.