4 formas de sincronizar tus ficheros en la nube de Google.

Es habitual querer explotar las capacidades de la nube aún cuando nuestro core principal está aún on-premise y querer que sea lo más transparente posible. Entre los diferentes casos se encuentran, por ejemplo, el backup de ficheros on-premise, el archivado de logs o analítica que queramos hacer en base a esos ficheros.

En otro post vimos la sincronización de bases de datos a través de Datastream. Hoy toca el turno de sincronización de ficheros de entornos on-premise hasta Google Cloud Storage o Cloud Filestore.

¿Qué opciones veremos?

Siempre que nos planteamos un problema de este tipo nos solemos encontrar con varias opciones. En este post vamos a analizar los siguientes métodos para realizar la sincronización de ficheros:

• Cloud SDK + CRON.
• Cloud Storage Fuse.
• Transfer service for on-premises.
• Filestore.

Consideraciones previas.

Suponemos que existe comunicación entre los sistemas on-premise y GCP. Siempre y cuando haya conectividad, bien sea pública o privada, las siguientes técnicas son viables.

1 Cloud SDK + CRON

¿Qué necesito?

• Cloud SDK, el SDK que nos permite utilizar las utilidades de línea de comando de Google Cloud.
• Una service account con la que la máquina on-premise se identificará para subir los ficheros.
• Cron en sistemas Unix-like o Task Scheduler en Windows.

Es una solución bastante simple pero no por ello menos efectiva:

1. Crear un script que copie con gsutil desde el directorio de origen al bucket de cloud storage. Gsutil tiene muchas opciones, dependiendo de si quieres bidireccionalidad en la sincronización o no, si quieres paralelizar la subida de ficheros, etc. Un ejemplo sería:

gsutil -m rsync -rd $FOLDER_SRC_CRON $BUCKET
**-m** paraleliza la subida en caso de haber múltiples ficheros que no estén en el destino.

rsync sincroniza dos directorios, buckets.

-r recursivo.

-d Borra datos en el destino si no están presentes en el origen. Utiliza está opción con mucho cuidado.

2. Dar de alta en el crontab el script.

(crontab -l; echo "* * * * * $CRON_SCRIPT") | sort -u | crontab -

Puntos fuertes de esta solución:

• Simplicidad.
• Conexión de red menor de 300 Mbps.
• Poca cantidad de información para transferir (generalmente < 1TB).

2 Cloud Storage Fuse

Cloud Storage Fuse (gcsfuse en adelante) te permite montar un bucket de GCS sobre un directorio de una máquina y trabajar con comandos de sistema operativo, aislándote de conocer sobre qué está montando ese directorio.

Hay que mencionar que es una herramienta desarrollada por Google pero con soporte de la comunidad. Google no ofrece garantía de ningún tipo.

Estos son sus principales características:

• No es una herramienta de migración.
• El directorio sobre el que montar gcsfuse debe estar vacío inicialmente.
• No soporta buckets con versionado de objetos habilitado.
• Tiene capacidades de caché.
  • Aquí necesitamos entender qué ocurre cuando hacemos por ejemplo un ls sobre un directorio. En este caso, por debajo se llamará a la API de cloud storage con la operación list(). La caché permite reducir el número de llamadas al API de cloud storage. Hasta aquí suena genial, pero qué ocurre cuando alguien modifica el bucket en GCS y hacemos un ls. Pues que en función de la configuración, podríamos no ver el cambio.
  • Hay que tener cuidado y que el bucket sea solo modificado por el filesystem donde se ha montado para que el caching funcione correctamente.
  • Si tienes un bucket que está siendo modificado por diferentes canales, mejor deshabilitar el cacheo.
• Mantén el ojo en los costes. Dado que cualquier operación en el directorio se traduce en llamadas al API de cloud storage, hay que vigilar qué operaciones se realizan. Aquí puedes ver algunos ejemplos de equivalencia entre los comandos del SO y las llamadas al API.
• Como podrás intuir, el tiempo de respuesta al trabajar sobre este directorio que tiene un bucket montado será mucho mayor que si estuviese montado sobre un disco duro en la propia máquina.

Algunos casos de uso posibles:

• Backups en Cloud Storage desde directorios locales, aislando al creador del fichero de su ubicación. A diferencia del punto anterior, el dato escrito en el directorio estará disponible casi de inmediato en Cloud Storage sin tener que esperar a que salte un CRON.
• Tener disponible en un directorio de la máquina on-premise toda la información de un bucket.

3 Transfer service for on-premises

Es el servicio gestionado de Google para la transferencia de grandes cantidades de información.

Existen algunos conceptos que debemos conocer antes de ver la arquitectura:

• PosixDataSource: será el directorio on-premise sobre el que podremos sincronizar. Existen otros datasource que puede ver aquí.
• GcsDataSink: el bucket donde vamos a transferir la información del on-premise.
• Agent: software (es un contender de docker) instalado en tu datacenter.
• Agent Pool: es un conjunto de agentes que usan la misma configuración, con acceso homogéneo y visibilidad, tanto al datasource como al destino (Sink).
• Transfer Job: coordina y controla los agentes que están en el on-premise y cómo deben mover los datos.

Las flechas verdes representan el movimiento de datos y las flechas azules implican intercambio de metadatos.

Un punto que no hemos mencionado hasta ahora es cómo coordina el servicio a los agentes. Todo se hace de manera asíncrona por intercambio de mensajes en pubsub. Una cosa que podrás ver si utilizas este servicio es que Google crea bastantes topics en tu proyecto con un formato parecido a cloud-ingest-* y <nombre-de-tu-pool>-*

¿Qué otras posibilidades ofrece?

• Incrementar el throughput de subida de ficheros simplemente añadiendo más agentes al pool.
• Permite limitar el ancho de banda utilizado para la subida de ficheros.

Ventajas de la solución:

• Solución más corporativa para la transferencia de ficheros.
• Pensada para grandes volúmenes de información.

¿Qué aspectos podría mejorar?

• Los agentes sólo envían información al bucket cuando se lanza el transfer job y el intervalo mínimo para el scheduler es de 1 hora.
• Necesaria cierta infraestructura en tu proyecto (topics y subscripciones de pubsub) que no creadas por ti mismo.

4 Filestore

Filestore es la solución NFS totalmente gestionada para compartir disco en diferentes instancias. Te permite seleccionar capacidad y tipo de disco( HDD, SSD, High Scale SSD y Enterprise).

En el anterior diagrama vemos cómo podemos montar un directorio local sobre la instancia de Filestorage, de tal manera que cuando desde un sistema on-premise copiemos un directorio, estaría disponible en la instancia de Filestore y disponible para otras instancias que estén ya en GCP y que tengan ese disco montado.

El único punto a tener en cuenta es que el tamaño mínimo es de 1TB de aprovisionamiento. Independientemente de que uses 1GB, se te cobrará por 1TB reservado, no por 1GB utilizado. Tenlo presente en tu calculadora de costes.

Conclusiones

Ninguna opción es mejor que otra de manera absoluta. Cada una se adapta mejor según las necesidades:

• Tiempo en el que necesito tener la información disponible en GCP.
• Cantidad de información.
• Ancho de banda.
• Limitaciones en los entornos on-premise.