Copier l'hôte Linux sur un nouveau matériel

J'ai besoin de faire des migrations d'hôte à hôte de l'ancien matériel vers le nouveau matériel. Plus précisément, de HP BL460G7 à HP BL460G8. Les anciens et les nouveaux serveurs ont tous deux 2 disques de 600 Go de 2,5 pouces et sont configurés pour RAID1. Je peux me permettre 30 minutes de temps d'arrêt par serveur.

Il y a quatre serveurs à migrer, le plus petit a un total de 120 Go alloué en volumes logiques et le plus grand a 510 Go alloués. Trois serveurs exécutent RHEL5 et un exécute RHEL6.

J'ai creusé la tête sur la façon de le faire dans le délai imparti et sans détruire le système d'exploitation et les données critiques.

Ma seule pensée est la suivante:

• retirer un lecteur de l'ancien serveur (le serveur est sous tension)
• supprimer les deux lecteurs du nouveau serveur (le serveur est éteint)
• retirer le lecteur G7 du chariot et mettre de côté
• retirer le lecteur G8 du chariot et l'installer dans le chariot G7
• installer le lecteur G8 dans le chariot G7 sur l'ancien serveur
• attendre que le contrôleur RAID reconstruise la matrice RAID1
• une fois l'arrêt de l'ancien serveur terminé
• retirer le lecteur G8 du chariot G7
• installez le lecteur G8 dans le chariot G8 et insérez-le dans le G8 (lecteur unique installé)
• démarrer le serveur G8
• attendez que le système d'exploitation démarre
• lorsque le système d'exploitation a démarré, insérez le lecteur restant
• attendre que la matrice RAID soit reconstruite

Est-ce que cela semble sain d'esprit?

EDIT: Les RHEL5 sont RHEL5.10 et les RHEL6 sont RHEL6.6

J'aurais également dû noter que deux des systèmes font partie d'un cluster à quatre nœuds chaud qui réplique presque constamment les «événements» d'application (sa partie d'un système d'infrastructure critique). Nous avons des sauvegardes mais nous les utilisons uniquement en cas de panne totale du système.

Les tests précédents ont montré un «dd» maximum entre les systèmes d'environ 50 Mbps, ce qui est beaucoup trop lent.

EDIT: J'allais compter sur kudzu pour ramasser et gérer les changements matériels.

Il convient de noter que d'autres étapes peuvent être nécessaires, selon la distribution. Plus particulièrement les pilotes (merci de l'avoir souligné @ewwhite).

1. Démarrez le nouveau serveur à partir de livecd / usb.
2. Préparez les partitions et le bootblock sur les nouveaux disques.
   • Selon la configuration, cela peut être fait en copiant MBR / bootblock.
3. Faites les systèmes de fichiers.
4. Faites une rsync de l'ancien serveur au nouveau.
   • Vous voudrez peut-être recommencer pour voir combien de temps la rsync de suivi prendra - si elle dure moins de 30 minutes, continuez.
   • C'est le moment, vous pouvez réellement essayer, si un nouveau système démarre. Faites juste attention à ne pas provoquer de conflits IP (ou autres).
5. Arrêtez tous les services qui pourraient écrire dans le système de fichiers
   • Redémarrez de préférence sur livecd / usb
6. Rsync data from old server to new again
7. Redémarrez le nouveau serveur et utilisez-le

En procédant de cette façon, vous avez toujours le serveur d'origine intact, donc si quelque chose se passe mal, il existe un moyen facile de revenir en arrière. Mais cela nécessite certaines connaissances (grub / rsync / partitions), donc je suggère de faire un travail de préparation et de test à l'avance, avant de le faire en direct.

Deux choses:

• Je voudrais construire de nouvelles données et rsync.
• Votre allocation / fenêtre d'indisponibilité semble trop courte. 30 minutes peuvent fonctionner dans des situations spécifiques, mais NE devriez- VOUS PAS dicter l'exigence réaliste de temps d'arrêt en fonction de ce qu'il faut pour accomplir le travail?

En fonction des données contenues dans chaque serveur, de la quantité de données en désabonnement et de votre schéma d'approvisionnement, il peut être judicieux d'installer le système d'exploitation nécessaire sur le nouveau Gen8 ProLiant et de synchroniser les paramètres et autres parties de données à un point où vous pouvez suspendre la Les données.

Faites peut-être une copie de départ et dérivez vos besoins en temps d'arrêt du temps qu'il faut pour récupérer les modifications de fichier lors des rsyncs suivants. Si vous avez besoin d'accélérer le processus de transfert ou si vous avez beaucoup de petits fichiers, il existe des techniques qui peuvent vous aider .

Je fais souvent ces types de transitions. Avec des installations Linux similaires, vous avez rarement besoin de plus qu'une liste de packages précise (facilement accessible via Yum ou RPM), les répertoires de configuration (par exemple /etc) et vos partitions de données. Si vous n'avez pas encore de système de provisionnement kickstart, vous pouvez profiter du /root/anaconda-ks.cfgfichier pour avoir une idée de la façon dont le système G7 a été construit.

Pour répondre à votre question sur le simple déplacement des disques, en fonction des versions spécifiques de RHEL que vous avez mentionnées, cela est absolument possible. Vous pouvez déplacer les disques / caddies et les métadonnées HP Smart Array sont compatibles entre les contrôleurs P410 et P420 qui peuvent se trouver dans vos systèmes. Cependant, je ne ferais pas cela sans mettre à jour complètement le micrologiciel des lecteurs et composants du nouveau système.

Si votre version précédente du système d'exploitation est capable de gérer le nouveau matériel (principalement un contrôleur RAID), vous pouvez essayer CloneZilla .

Pour vérifier s'il est possible de passer d'un matériel à un autre, vous pouvez passer toutes les données de l'ancien au nouveau serveur en faisant quelques trucs avec dd.

Démarrez le nouveau serveur avec une distribution en direct comme SystemRescueCD , configurez avec une adresse IP et une commande dd comme celle-ci:

nc -l 8000 | dd of=/dev/sda

Sur le serveur actuel, effectuez

dd if=/dev/sda | nc ${newserverip} 8000

Cela fera une copie brute du / dev / sda de votre serveur vers le nouveau serveur / dev / sda. De cette façon, vous pouvez effectuer un test sans interruption sur votre serveur d'origine et prendre des risques presque nuls.

Le chef de projet a refusé ma demande d'une fenêtre d'interruption plus grande.

La procédure proposée décrite dans la question a bien fonctionné lors des tests. Le temps d'arrêt était inférieur à 20 minutes. J'ai utilisé l'utilitaire hpacucli pour suivre les progrès sur le G7 puis le Gen8, c'était très utile pour cela.

Je ne l'ai pas encore fait avec colère, mais comme indiqué, cela a bien fonctionné pour tester RHEL 5.10 sur BL460G7 à BL460 Gen8.

Je n'ai pas mis à jour le firmware.

La resynchronisation RAID1 initiale dans le G7 a pris un peu plus d'une heure. La resynchronisation dans le Gen8 a pris moins de 50 minutes. Cela m'inquiétait mais je n'ai pas trouvé de problème.

Merci encore pour tous les commentaires et suggestions utiles.