Migración completa desde un VPS a otro


(Jorge) #1

Hola a tod@s.

Tengo una duda en la que a pesar que hay documentación y aparenta ser sencilla, no está muy claro y prefiero evitar catástrofes. Tengo elasticsearch en un VPS con una instalacion sencilla (un solo nodo, un solo cluster) y muchos datos almacenados. Ahora necesito migrar todo mi VPS a un dedicado, incluyendo elasticsearch y todos sus datos. Qué opción me recomiendan para migrar? debo tener algo en cuenta?

Hasta ahora planeé 2 opciónes)

  1. instalar la misma version de ELK en el dedicado, y luego copiar por completo /var/lib/elasticsearch desde el vps hacia el dedicado (idem con el archivo /etc/elasticsearch).

  2. La otra es utilizar snapshots, entiendo que debo instalar la misma version de ELK en el dedicado y con la misma configuración, luego restauro el snapshot que tenía en el VPS y listo, aunque ésto ultimo no me queda claro si es tan así. No entiendo si puedo hacer la restauración sobre un ELK vacío, o si primero debo crear todos los indices y luego restaurar, y/o si hay "algo mas".

Alguna sugerencia o corrección? agradesco enormemente cualquier aporte de experiencia, ya que soy nuevo en ELK.

Gracias.


(Ismael Hasan Romero) #2

Hola Jorge,

básicamente, copiar-pegar los índices es una receta para tener problemas :). Hay dos opciones recomendables:

  • Como dices, utilizar Snapshost/restore. Cuando creas un snapshot los mappings y los settings de los índices son copiados también, así que al restaurarla serán copias exactas.
  • Otra opción sería usar la Reindex API. Esta permite indexar documentos en un cluster que vienen de un cluster remoto. Sin embargo, esta opción NO copia los settings y los mappings, así que los índices deberían de ser creados antes de empezar la indexación.

Básicamente, la opción más sencilla sería Snapshot/restore: no te preocupas de crear índices/mappings...
Fíjate también que puedes seleccionar qué índices quieres incluír en una snapshot: como todavía no has usado esta funcionalidad, te recomendaría testear primero con un índice de prueba, pequeño, y familiarizarte con el proceso.

Respecto a los ficheros de configuración, como bien dices, sí tendrías que recrearlos en el segundo cluster (aquí sí se puede hacer copiar-pegar, simplemente cambiando los parámetros para el nuevo cluster).

Un saludo,
Ismael.


(Gabriel Moskovicz) #3

@kriter Cabe destacar que Reindex esta disponible unicamente comenzando de la version 2.3, mientras que Snapshot y Restore funciona desde la version 1.x inclusive.

Completamente de acuerdo que Snapshot/Restore es la forma mas sencilla y la que consume menos recursos tambien, ya que no mantiene un "context" abierto para buscar y enviar la informacion al otro cluster, simplemente la informacion esta en un disco y alli vivira.

Saludos!

--Gabriel


(Jorge) #4

Gracias! , con ésto me exclarecieron por completo mis dudas.

Por otra parte, creo que queda claro que la mejor opción es la restauración de Snapshots.

Saludos


(Gabriel Moskovicz) #5

Exactamente!

Incluso, si son indices diarios o que siguen un patron de un nombre especifico, hasta puedes automatizar esto con Curator :slight_smile:

Saludos y buen fin de semana,

--Gabriel


(Jorge) #6

Gracias nuevamente por responder. Viendo esto me queda una ultima duda respecto a los snapshots:

Existe alguna forma de transferir en forma remota un snapshot? o debo copiar la carpeta del repositorio al servidor remoto y luego utilizar el comando de restaurar snapshot?
Vi que ésto está en la documentación aunque no me queda claro del todo y quizás ambas opciónes sean válidas?

Gracias y saludos!


(Gabriel Moskovicz) #7

Hola @kriter,

Generalmente se monta el disco del repositorio remoto en cada uno de los nodos, y luego se configura el path.repo a ese mounted point. Luego tomas los snapshot y estos seran guardados en el remoto.

Si no puedes montar el repositorio remoto como un folder, entonces la unica opcion es copiar y pegar el repositorio completo en un lugar externo y luego transferirlo.

Saludos!
--Gabriel


(system) #8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.