Hot clone un servicio vivo de Linux

14

Necesitamos clonar en caliente un servicio de Linux cuando está vivo, no solo porque no podemos reiniciar o algo así; es solo por nuestro escenario especial (sí, ya he leído esta respuesta, pero es un poco diferente de la mía Clone un servidor Linux en funcionamiento ).

Tenemos un nodo de cálculo, puede decir un nodo de cálculo de PNL que ejecuta algunos modelos en él. Cuando comenzamos el nodo (con un servicio, por supuesto), el cálculo será muy lento hasta que lo alimentemos varias veces. Lo llamamos calentamiento.

Desafortunadamente, el trabajo de calentamiento tarda mucho en esperar (tal vez nuestro cálculo finalizó antes de que el nodo se calentara).

Entonces, surge el problema, ¿hay una manera estable de clonar en caliente un servidor Linux para mantener el nodo con el mejor rendimiento para que podamos clonarlo y ponerlo en línea en menos tiempo?

Chen Steven
fuente
¿Sería útil visualizar la máquina y tomar una instantánea del estado "calentado"?
TripeHound
13
¿Entiendes por qué ocurre este calentamiento? Por ejemplo, podría ser un efecto secundario de la caché de archivos. Pero algunas respuestas a las máquinas de clonación descartan la memoria caché del archivo, porque una memoria caché por definición se puede reconstruir a partir del original subyacente.
MSalters
fork () es una forma de crear más procesos en una máquina determinada mientras se guarda cualquier sobrecarga de inicio.
Otro usuario más el
gracias amigos, @TripeHound, le pregunté a un amigo mío que trabaja en VMWare, y dijo que parece imposible para ellos simplemente capturar el estado "calentado", ni algunas cosas espejo. MSalters, no estoy 100% seguro de lo que sucede durante el calentamiento, pero parece que después del servicio, algún trabajo de carga diferida funciona después de que el trabajo de cálculo involucra
cheven steven
2
Desconoce su configuración en segundo plano, pero esto huele a una situación en la que su servidor nunca debe fallar. Esto sugiere que el núcleo de su host podría ser antiguo y que las actualizaciones nunca se han aplicado. Quizás este es un indicador de un defecto de diseño sistémico que debe considerarse.
Criggie

Respuestas:

28

Tal vez no pueda "clonar en caliente" un servidor completo (puede hacerlo, pero solo si es una máquina virtual), pero puede congelar y restaurar un solo proceso, con criu , Checkpoint / Restore en Userspace.

Esto le permite guardar el estado interno del programa en el disco y detener el programa, y ​​luego, restaurar el programa a ese estado desde los archivos guardados.

Para admitir la operación deseada, puede copiar los archivos que representan el programa guardado en otro servidor y restaurarlo allí.

criu requiere un kernel reciente con varias características compiladas, por lo que las distribuciones de Linux más antiguas podrían no funcionar. Puede ejecutar criu checken una máquina en particular para determinar si los requisitos previos para criu están presentes.

Michael Hampton
fuente
se ve impresionante y voy a hacer algunas pruebas en esto, gracias bro
chen Steven
Según su experiencia, ¿qué tan bien funciona esto en la práctica? Al observar las listas de limitaciones de las limitaciones (que son más o menos las que esperaría, este es un problema difícil), tengo la sensación de que es poco probable que funcione con aplicaciones que no fueron diseñadas teniendo en cuenta este caso de uso.
James_pic
@James_pic Ha pasado quizás un año desde que lo vi seriamente, ya que actualmente no lo uso. Para un demonio que solo acepta conexiones y hace algunos cálculos (por ejemplo, el trabajo de aprendizaje automático del OP o un servidor web) funciona bastante bien.
Michael Hampton
12

Puede estar un poco fuera del alcance de su entorno actual, pero la forma estándar de hacerlo es virtualizar su servidor. Muchos hosts de virtualización (VMware, virtualbox, etc.) permiten "instantáneas" que guardan el estado de un servidor, que luego se puede clonar en nuevas instancias. Estas nuevas instancias tendrán exactamente el mismo estado que el original, hasta los procesos en ejecución. Por supuesto, querrá asegurarse de que el software que está ejecutando seguirá funcionando correctamente en un entorno virtual (me viene a la mente el cálculo de CUDA / GPU).

zanahoria
fuente
La virtualización es excelente, hasta que el software (o sus dependencias) requiera una actualización y no proporcione un mecanismo de recarga elegante. Una instantánea de VM o una migración en vivo está ejecutando el código anterior.
John Mahowald
Es a la vez aceptable para mí ejecutar el proyecto en una máquina "real" o en un host de virtualización, y podemos tomar varias formas de manejar el código "antiguo", tal vez una prueba A / B o una actualización continua .etc. ¿Pero está seguro de que las instantáneas pueden clonar totalmente el estado calentado de mi nodo de trabajo?
Chen Steven
3
Cuando "migra en vivo" una máquina, debe pausarse. Mientras está en pausa, su memoria se copia 1: 1 a otra máquina en un clúster, donde está sin pausa, intacta. Esto puede llevar algo de tiempo dependiendo de la cantidad de memoria en uso y de la rapidez de la estructura de red. Es posible que pueda usar este método si la cantidad de tiempo de inactividad que invoca es lo suficientemente baja para sus necesidades.
Cola
@chensteven Recientemente he venido de un entorno virtualbox. Eso fue hace algún tiempo, pero por lo que recuerdo, una instantánea en ejecución contiene el estado exacto de la máquina virtual en el momento en que se tomó la instantánea, incluidos los procesos en ejecución y el contenido de la memoria. Esta instantánea se puede clonar en una nueva máquina virtual, lo que le brinda dos máquinas exactamente en el mismo estado.
zanahoria 01 de
3

La pregunta que menciona se refiere a un enlace, http://www.linuxfocus.org/English/March2005/article370.shtml , que describe todas las formas en que había imaginado hacer sus solicitudes.

Que las opciones estén ahí no significa mucho lo que se está ejecutando en el servidor. Debe tener en cuenta que todos los archivos que podrían cambiar en el proceso de clonación podrían ser archivos inconsistentes en la máquina de destino. En esa publicación, proporcione que hablen sobre bases de datos, y clonarla de esa manera no ofrece ningún seguro de integridad de datos.

No está exactamente claro a qué se refería con "hasta que lo alimentemos varias veces" .

Pero si entendí bien lo que pides, debes considerar que para clonar un sistema necesita tiempo para copiar y calcular recursos.

Para realizar un "ENCENDIDO / APAGADO" o mejor denominado entorno activo / de respaldo, el servidor debe configurarse correctamente en el clúster.

Lo siento si no es la respuesta que esperas, pero las opciones que obtienes son esas.

AtomiX84
fuente
Es mi culpa confundirlo un poco, lo que significa "alimentar" significa que, después de iniciar mi servicio, necesitamos invocar las tareas de cálculo varias veces para asegurarnos de que el nodo se "calienta" al máximo rendimiento. Entonces, el problema aquí es como el clon dinámico o la expansión de nuestros trabajos vivos, como si la gran cantidad de solicitudes que llegaran a nuestro sistema no tuviéramos suficiente tiempo para configurar nuevos nodos de cálculo (el calentamiento lleva demasiado tiempo) para manejarlos, u saber, al igual que las olas que vienen
chen Steven
1

Hay muchos problemas potenciales con lo que está tratando de hacer, y, por supuesto, como sabe, sería mejor desconectar el servidor y clonarlo mientras no se almacenan datos dinámicamente.

Sin embargo, lo que busca hacer es totalmente plausible, como lo he hecho antes. Si lo usa dd, puede clonar el servidor completo en el nivel de bloque a otra unidad u otro servidor. Sin embargo, requerirá una configuración adicional en el nuevo servidor, y probablemente no podrá simplemente apagar el otro y encender el nuevo. Para que podamos entender esto, necesitamos saber algunas cosas sobre el hardware y software de su servidor.

En primer lugar, para determinar la mejor estrategia de datos, sería útil saber qué se actualiza regularmente. ¿Tiene un servidor SQL que se actualiza dinámicamente pero tiene contenido estático? Alternativamente, ¿tiene un equipo de desarrolladores sobre un sistema de subversión como git enviando actualizaciones constantes de datos a su contenido? Dependiendo de lo que se actualice, se determinará el mejor curso de acción completo.

Si, por ejemplo, solo el SQL se actualiza regularmente, puede migrar a un nuevo servidor mientras ese servidor está activo de la siguiente manera:

  • dd para clonar todos los datos del nuevo servidor.
  • Comience a configurar el nuevo servidor, puede tomar algo de trabajo, especialmente si es un hardware diferente, pero aún puede ser más rápido que la configuración desde cero.
  • También puede tomar algunos cambios de DNS, ya que no puede usar el mismo DNS en otro servidor si necesita trabajar en el segundo servidor en vivo mientras el primer servidor aún está activo.
  • Una vez que el nuevo servidor esté completo y se ejecute de forma independiente, realice una copia de seguridad final del servidor sql en el servidor original e impórtelo al nuevo servidor.

Es posible que deba desconectar temporalmente su servidor original para asegurarse de no perder ningún dato. Alternativamente, para tener un tiempo de inactividad cero, puede activar el segundo en vivo, apuntar el dns al nuevo servidor y luego actualizar cualquier entrada de dns manualmente en el nuevo servidor, para que efectivamente haya un tiempo de inactividad cero. Sin embargo, esto es más complicado que unos pocos minutos de tiempo de inactividad para hacer una copia de seguridad del sql y restaurarlo en el nuevo servidor, pero puede ser necesario para cero tiempo de inactividad.

Por supuesto, este es solo un ejemplo de caso de uso, y dependiendo de su configuración y varias variables, es posible que necesite crear su propia estrategia para la migración en función de su caso específico.

El otro problema está relacionado con la configuración del hardware del servidor. ¿El nuevo servidor es 100% idéntico en hardware al antiguo servidor? Si es así, entonces la configuración es más fácil. Sin embargo, si, por otro lado, es una configuración de hardware totalmente diferente, entonces es posible que deba implementar una estrategia diferente, que es simplemente configurar el segundo servidor con anticipación y luego hacer una copia de seguridad de todos sus datos y bases de datos sql en el primer servidor y migrarlos manualmente, cambiando la configuración según lo desee.

La migración del servidor no es en absoluto trivial, y para tener un movimiento exitoso, debe tener un conocimiento profundo de los servidores, o del personal disponible que tenga el mismo. En cualquier caso, se recomienda encarecidamente que realice una copia de seguridad completa y la almacene en una tercera fuente, incluso en su computadora local, de modo que si ocurre el peor de los casos (ambos servidores se bloquean y mueren irreparablemente), todavía tiene otro copia de sus datos para reconstruir sus servidores.

Espero que esto ayude, ¡y buena suerte con tu servidor!

serveraddict
fuente