Clonage à chaud d'un service Linux vivant

14

Nous devons cloner à chaud un service Linux quand il est vivant, pas seulement parce que nous ne pouvons pas redémarrer ou quelque chose; c'est juste à cause de notre scénario spécial (ouais, j'ai déjà lu cette réponse, mais c'est un peu différent du mien Clone un serveur Linux qui fonctionne ).

Nous avons un nœud de calcul, vous pouvez dire un nœud de calcul NLP qui exécute certains modèles dessus. Lorsque nous démarrons le nœud (avec un service bien sûr), le calcul sera horriblement lent jusqu'à ce que nous le nourrissions plusieurs fois. Nous l'avons appelé échauffement.

Malheureusement, le travail d'échauffement prend beaucoup de temps à attendre (peut-être que notre calcul est terminé avant que le nœud ne se soit réchauffé).

Donc, le problème vient, existe-t-il un moyen stable de cloner à chaud un serveur Linux pour maintenir le nœud aux meilleures performances afin que nous puissions cloner et le mettre en ligne dans un temps plus court?

linux clone

— chen steven
source

La visualisation de la machine et la prise d'un instantané de l'état "échauffé" seraient-elles utiles?

— TripeHound

13

Comprenez-vous pourquoi cet échauffement se produit? Par exemple, cela pourrait être un effet secondaire du cache de fichiers. Mais certaines réponses aux machines de clonage ignorent le cache de fichiers, car un cache par définition peut être reconstruit à partir de l'original sous-jacent.

— MSalters

fork () est un moyen de créer plus de processus sur une machine donnée tout en économisant la surcharge de démarrage.

— Encore un autre utilisateur

merci les gens, @TripeHound, j'ai demandé à un de mes amis qui travaille dans VMWare, et il a dit qu'il leur semblait impossible de simplement prendre un instantané de l'état "échauffé", ni des miroirs. MSalters, je ne suis pas sûr à 100% de ce qui se passe pendant l'échauffement, mais il semble qu'après la fin du service, un travail de chargement paresseux fonctionne après le travail de calcul

— chen steven

2

Ignorant votre configuration d'arrière-plan, mais cela sent comme une situation où votre serveur ne doit jamais tomber en panne. Cela suggère que le noyau de votre hôte pourrait être ancien et que les mises à jour n'ont jamais été appliquées. C'est peut-être un indicateur d'un défaut de conception systémique qui doit être pris en compte.

— Criggie

28

Peut-être que vous ne pouvez pas "cloner à chaud" un serveur entier (vous pouvez, mais seulement s'il s'agit d'une machine virtuelle), mais vous pouvez geler et restaurer un seul processus, avec criu , Checkpoint / Restore in Userspace.

Cela vous permet d'enregistrer l'état interne du programme sur le disque et d'arrêter le programme, puis de restaurer le programme dans cet état à partir des fichiers enregistrés.

Pour prendre en charge l'opération souhaitée, vous pouvez copier les fichiers représentant le programme enregistré sur un autre serveur et y restaurer.

criu nécessite un noyau récent avec diverses fonctionnalités compilées, donc les anciennes distributions Linux pourraient ne pas fonctionner. Vous pouvez exécuter criu checksur une machine particulière pour déterminer si les prérequis pour criu sont présents.

— Michael Hampton
source

ça a l'air génial et je vais faire des tests à ce sujet, merci bro

— chen steven

D'après votre expérience, comment cela fonctionne-t-il dans la pratique? En regardant les limitations des listes criu (qui sont à peu près celles auxquelles je m'attendais - c'est un problème difficile), j'ai l'impression que cela ne fonctionnera probablement pas avec des applications qui n'ont pas été conçues avec ce cas d'utilisation à l'esprit.

— James_pic

@James_pic Cela fait peut-être un an que je l'ai regardé sérieusement, car je n'en ai actuellement aucune utilisation. Pour un démon qui accepte simplement les connexions et effectue des calculs (par exemple le travail d'apprentissage automatique de l'OP ou un serveur Web), cela fonctionne plutôt bien.

— Michael Hampton

12

Cela peut être un peu hors de portée de votre environnement actuel, mais la façon standard de procéder consiste à virtualiser votre serveur. De nombreux hôtes de virtualisation (VMware, virtualbox, etc.) autorisent des «instantanés» qui enregistrent l'état d'un serveur, qui peut ensuite être cloné dans de nouvelles instances. Ces nouvelles instances auront exactement le même état que l'original, jusqu'aux processus en cours d'exécution. Bien sûr, vous voudrez vous assurer que le logiciel que vous exécutez fonctionnera toujours correctement dans un environnement virtuel (le calcul CUDA / GPU vient à l'esprit).

— cawotte
source

La virtualisation est excellente, jusqu'à ce que le logiciel (ou ses dépendances) nécessite une mise à jour et ne fournisse pas de mécanisme de rechargement gracieux. Un instantané de machine virtuelle ou une migration en direct exécute l'ancien code.

— John Mahowald

C'est à la fois acceptable pour moi d'exécuter le projet sur une "vraie" machine ou un hôte de virtualisation, et nous pouvons prendre plusieurs façons de gérer les "anciens" trucs de code, peut-être un test A / B ou une mise à jour continue .etc. Mais êtes-vous sûr que les instantanés peuvent totalement cloner l'état de préchauffage de mon nœud de travail?

— chen steven

3

Lorsque vous "migrez en direct" une machine, elle doit être mise en pause. Pendant qu'il est en pause, sa mémoire est copiée 1: 1 sur une autre machine d'un cluster, où elle n'est pas suspendue - intacte. Cela peut prendre un certain temps en fonction de la quantité de mémoire utilisée et de la vitesse de la structure réseau. Vous pourrez peut-être utiliser cette méthode si le temps d'arrêt qu'elle invoque est suffisamment faible pour répondre à vos besoins.

— Spooler

@chensteven Je viens tout récemment d'un environnement de boîte virtuelle. C'était il y a quelque temps, mais d'après ce dont je me souviens, un instantané en cours d'exécution contient l'état exact du vm au moment où l'instantané a été pris, y compris les processus en cours d'exécution et le contenu de la mémoire. Cet instantané peut ensuite être cloné vers un nouveau vm, vous donnant deux machines exactement dans le même état.

— cawwot

3

La question que vous mentionnez fait référence à un lien, http://www.linuxfocus.org/English/March2005/article370.shtml , qui décrit toutes les façons dont j'avais imaginé faire vos demandes.

Que les options soient là ne signifie pas grand-chose à ce qui s'exécute sur le serveur. Vous devez considérer que tous les fichiers susceptibles de changer dans le processus de clonage peuvent être des fichiers incohérents sur la machine cible. Sur ce post, vous fournissez qu'ils parlent de bases de données, et le clonage comme ça ne donne aucune assurance de l'intégrité des données.

On ne sait pas exactement ce que vous vouliez dire par "jusqu'à ce que nous le nourrissions plusieurs fois" .

Mais si j'ai bien compris ce que vous demandez, vous devez considérer que pour cloner un système, il a besoin de temps pour copier et calculer les ressources.

Pour effectuer un "ON / OF" ou mieux appelé un environnement actif / de sauvegarde, le serveur doit être correctement configuré dans le cluster.

Je suis désolé si ce n'est pas la réponse que vous attendez, mais les options que vous obtenez sont celles-ci.

— AtomiX84
source

C'est ma faute de vous rendre un peu confus ici, le truc "feed" signifie, après le démarrage de mon service, nous devons invoquer les tâches de calcul plusieurs fois pour nous assurer que le nœud est "réchauffé" dans les meilleures performances. Donc, le problème ici est comme le clone dynamique ou l'expansion de nos emplois vivants, comme si le grand nombre de demandes frappant notre système, nous n'aurons pas assez de temps pour configurer de nouveaux nœuds de calcul (l'échauffement prend trop de temps) pour manipulez-les, vous savez, tout comme les vagues qui arrivent

— chen steven

1

Il existe de nombreux problèmes potentiels avec ce que vous essayez de faire, et bien sûr, comme vous le savez, il serait préférable de mettre le serveur hors ligne et de le cloner alors qu'aucune donnée n'est stockée dynamiquement.

Cependant, ce que vous cherchez à faire est tout à fait plausible, comme je l'ai déjà fait. Si vous utilisez, ddvous pouvez cloner le serveur complet au niveau du bloc sur un autre lecteur ou un autre serveur. Cependant, il faudra une configuration supplémentaire sur le nouveau serveur, et vous ne pourrez probablement pas simplement éteindre l'autre et activer le nouveau. Pour que nous comprenions cela, nous devons connaître quelques éléments sur le matériel et les logiciels de votre serveur.

Premièrement, afin de déterminer la meilleure stratégie de données, il serait utile de savoir ce qui est mis à jour régulièrement. Avez-vous un serveur SQL qui se met à jour dynamiquement mais a un contenu statique? Alternativement, avez-vous une équipe de développeurs sur un système de subversioning comme git qui envoie des mises à jour constantes de données à votre contenu? En fonction de ce qui est mis à jour déterminera la meilleure ligne de conduite complète.

Si, par exemple, seul le SQL est mis à jour régulièrement, vous pouvez migrer vers un nouveau serveur pendant que ce serveur est opérationnel de la manière suivante:

dd pour cloner toutes les données du nouveau serveur.
Commencez à configurer le nouveau serveur, cela peut prendre un certain travail, surtout s'il s'agit d'un matériel différent, mais cela peut être plus rapide que la configuration à partir de zéro.
Cela peut également prendre quelques modifications DNS, car vous ne pouvez pas utiliser le même DNS sur un autre serveur si vous devez travailler sur le deuxième serveur en direct pendant que le premier serveur est toujours en ligne.
Une fois le nouveau serveur terminé et exécuté indépendamment, effectuez une sauvegarde finale du serveur SQL sur le serveur d'origine et importez-le dans le nouveau serveur.

Vous devrez peut-être déconnecter temporairement votre serveur d'origine pour vous assurer de ne manquer aucune donnée. Alternativement, pour n'avoir aucun temps d'arrêt, vous pouvez rendre le second actif, pointer le DNS vers le nouveau serveur, puis mettre à jour manuellement toutes les entrées DNS sur le nouveau serveur, de sorte qu'il n'y a effectivement aucun temps d'arrêt. C'est plus compliqué que quelques minutes de temps d'arrêt pour sauvegarder le SQL et restaurer sur le nouveau serveur, mais cela peut être nécessaire pour aucun temps d'arrêt.

Bien sûr, ce n'est qu'un exemple de cas d'utilisation, et selon votre configuration et plusieurs variables, vous devrez peut-être créer votre propre stratégie de migration en fonction de votre cas spécifique.

L'autre problème concerne la configuration matérielle du serveur. Le nouveau serveur est-il 100% identique en matériel à l'ancien serveur? Si c'est le cas, la configuration est plus facile. Cependant, si d'un autre côté, il s'agit d'une configuration matérielle totalement, complètement différente, vous devrez peut-être implémenter une stratégie différente qui consiste à simplement configurer le deuxième serveur à l'avance, puis à sauvegarder toutes vos données et bases de données SQL sur le premier serveur et migrez-les manuellement, en changeant la configuration comme vous le souhaitez.

La migration des serveurs n'est en aucun cas triviale, et pour réussir votre déménagement, vous devez avoir une connaissance approfondie des serveurs ou du personnel disponible qui les possède. Dans tous les cas, il est fortement recommandé de prendre immédiatement une sauvegarde complète et de la stocker sur une troisième source, même sur votre ordinateur local, de sorte que si le pire des cas se produit (les deux serveurs se bloquent et meurent de manière irréparable), vous en avez encore un autre copie de vos données pour reconstruire vos serveurs avec.

J'espère que cela vous aidera et bonne chance avec le déménagement de votre serveur!

— serveraddict
source