Todos estamos viendo como cada vez más empresas inician su viaje hacia el cloud, llevando sus aplicaciones y datos asociados, sus repositorios de datos, históricos, etc. a la nube, de forma que dispongan de un repositorio común y accesible para ser consumido por toda la empresa.
Estos datos, y ya centrándonos en Azure, se suelen almacenar en BlobStorage o en DataLake, y a pesar de ser muy barato el almacenamiento, cuando empezamos a tener un volumen de datos importantes, podemos encontrarnos con que la factura asociada al almacenamiento empiece a notarse.
Por ello en este post nos centraremos en cómo reducir la factura debida al almacenamiento de nuestros datos, y gestionar en qué estado o Tier se pueden encontrar, cuál es su uso, sus ventajas e inconvenientes, y por último veremos como definir reglas para que nuestros ficheros vayan pasando por los diferentes estados hasta su almacenamiento o incluso borrado, esto es lo que se conoce como el ciclo de vida de los datos.
Lo primero que tenemos que entender, son los diferentes estados o Tier en los que pueden estar nuestros datos, el cual define el ciclo de vida de los mismos.
En donde explicaremos a continuación cada una de estas capas
Este es el estado en el que debemos tener nuestros datos cuando están siendo utilizados de forma asidua, en este caso, los accesos tanto de lectura y escritura es la más rápida y barata, pero por otro lado el coste de almacenamiento es mayor, en la siguiente tabla vemos cuáles son los parámetros y coste de este estado para alguno de los parámetros.
Datos para:
Este es el formato de los datos en donde vamos a tener de pocos a infrecuentes accesos, es decir, no los necesitamos para el día a día, y por ello el coste de almacenamiento es menor, pero el coste de la operación será mayor, en la siguiente tabla vemos el detalle de algunos de los parámetros de coste o disponibilidades.
Datos para:
Aquí es importante recalcar que en las cuentas de almacenamiento V2, el objeto debe estar en este estado al menos durante 30 días (en Blob Storage no tenemos esta limitación), y en caso de no cumplirlo, es decir lo sacamos de este estado o lo borramos, tendremos una penalización que será el coste de todo el tiempo que quede pendiente hasta los 30 días, el cual se sumará al coste en el nuevo tier.
En este caso nos encontramos con datos que casi nunca son accedidos, por ejemplo, información histórica que por alguna necesidad legal se deben almacenar durante X años, en donde en caso de ser necesario su acceso, los tiempos de lectura se pueden medir en horas, y el coste se mide en euros, por lo que se debe tener muy claro que cuando se pase a este nivel, no pretendemos usar el dato en un tiempo razonable o para temas muy concretos (auditorías, temas legales, etc.)
Datos para:
Aquí también tenemos para las cuentas V2 una permanencia de 180 días, y en caso de no mantenerse, tendremos el mismo tipo de penalización, es decir, el restante de almacenamiento hasta cumplir los 180 días…
Por último, y aunque este no es un estado como tal, podremos borrar el dato, pero debemos tener en cuenta, que si tenemos activado el soft-delete, se almacenará como en la papelera de reciclaje de Azure durante el tiempo que hayamos configurado (entre 7 y 365 días), pero por el cual también se nos cobrará al precio en el que se encontraba en ese momento.
Hasta ahora hemos hablado sobre el dato, sobre información, el cual puede ser una imagen, un audio, una factura en PDF, un Word, etc. pero todos estos al final no dejan de ser ficheros almacenados en un DataLake o en un Blob Storage, por ello a partir de ahora hablaremos de la gestión de ficheros, ya que es el término general usado dentro de Azure.
Únicamente como inciso, si tenemos cargas delta o incrementales de datos en nuestro DataLake, o DeltaLake, ojo con esta alternativa de crear reglas, ya que deberemos estudiar su idoneidad con mucho cuidado, para asegurarnos que las reglas llegarán a ejecutarse, tipo de particionamiento de datos, y si no necesitaremos posteriormente ese dato.
Hasta ahora hemos visto los diferentes estados en los que puede estar un dato o fichero, y si lo sabemos manejar bien, y siendo consciente de sus ventajas e inconvenientes, podremos tener un ahorro importante en la factura pensemos simplemente que pasar de un Hot a un Cool, el coste de almacenamiento se reduce a la mitad.
Esto podemos hacerlo de forma manual de varias formas, en este post, nos centraremos en hacerlo a través del portal, pero también puede hacerlo con PowerShell, CLI y templates, e incluso a más bajo nivel a través de la capa de servicio Rest que proporciona Azure.
Centrándonos en el portal, si entramos en el contenedor y navegamos hasta la ruta en donde tenemos los ficheros, deberemos pulsar en los 3 puntitos y seleccionar “Cambiar de nivel” en el menú emergente, y en la nueva ventana seleccionar el nuevo nivel.
Pero, por otro lado, esta funcionalidad o estos cambios tendrán poco impacto cuando tengamos pocos ficheros y pequeños, y la rebaja vendrá cuando tengamos un volumen importante de ficheros, pero hacer esto de forma manual con miles de ficheros, puede llegar a ser muy tedioso, por ello Azure nos proporciona una funcionalidad que nos permite crear una serie de reglas para hacer esto de forma automática.
Esto lo tenemos en el menú lateral derecho del servicio, en donde en el apartado “Administración de dato” tenemos la opción de “Administración del ciclo de vida”, y nos lleva a una pantalla en donde podemos crear nuestras reglas de administración del ciclo de vida de nuestros ficheros.
Al pulsar en “agregar una regla” en la “administración del ciclo de vida”, nos solicitará los siguientes datos
-Nombre de la regla: Nombre único a la regla a crear.
-Ámbito de la regla
-Tipo de blob
Nota: Fijaros que no admite page blobs
-Subtipo de blob
Es importante notar que, tanto para tipo como para subtipo de blobs, las opciones NO SON EXCLUYENTES, es decir podemos marcar más de una para cubrir todas las casuísticas posibles.
Si queréis saber algo más al respecto sobre los tipos/subtipos de Blobs, aquí os dejo unos enlaces donde lo explican:
En caso de que hayamos marcado la opción de Blob Base definido.
Para definir la regla de movimiento por los Tier, nos basamos en la concatenación de varios IF-THEM.
De forma que definimos el número de días que deben haber pasado desde la última modificación del fichero, y en el Then, indicar que acción queremos realizar con el fichero:
En donde podemos marcarlo para pasarlo a acceso esporádico (Cool Tier), a almacenamiento (Archive Tier) o el borrado.
En caso de tener activado el “access time tracking” se crea una policy para llevar el registro del último acceso al fichero en lectura o escritura, y tendríais la opción de en lugar de seleccionar la fecha de modificación, seleccionar el de último acceso.
En ambos casos se aplican los mismos principios que el caso anterior, pero como las instantáneas o snapshots y las versiones son de solo lectura, se indica la fecha desde que se crearon.
Conjunto de Filtros
En este caso, se pueden definir la regla para indicar cuales son los blobs sobre los que se aplica esta regla, se pueden definir hasta 10 paths dentro del prefijo del Blob, y estos deben comenzar con el nombre del contenedor.
En caso de trabajar únicamente con Blobs Base y en Blob Storage (Esto no funciona en el DataLake, como vemos en la imagen de la izquierda que no nos da esa opción), tendremos la opción de definir sobre qué index tags queremos que se aplique la regla, y de nuevo podremos incluir hasta 10 pares clave-valor.
Para ver un ejemplo, se han creado he creado 3 carpetas “folder1”, “folder2” y “folder3”, en donde en cada una de ellas tenemos 4 ficheros de ejemplo, y todos ellos en estado hot.
En nuestro caso vamos a definir las siguientes reglas para blobs en bloque, limitados con filtro, y blobs base para los ficheros de más de 1 día de antigüedad.
1. Pasar todos los ficheros de la carpeta 2 al estado cool
Resultado: Todo el contenido de la carpeta esta en estado esporádico o cool.
2. Pasar a archive del folder1 que empiecen por f1_docu o f1_doc2
Resultado: Tenemos los tres ficheros en estado Archivado
3. Borrar todos los archivos de folder3 que empiecen por f3_documento
Resultado: han desaparecido los ficheros que empezaban por “f3_documento”
Un último punto que nos queda es el de la rehidratación, como vimos en la tabla asociada al modo Archive, los ficheros en este estado se encuentran en “Sin conexión”, es decir, no podemos acceder a ellos de forma inmediata, y es necesario pasarlos a un estado en línea, ya sea en Hot o en Cool, siendo este paso o proceso el conocido como Rehidratación.
Para ello hay dos posibles opciones
Este proceso es largo, puede tardar hasta 15 horas si le damos una prioridad estándar o menos si le damos una prioridad alta, ejecutándose antes que los de prioridad estándar.
Aquí es importante anotar que una rehidratación no modifica la fecha de creación del fichero, por lo que, si optamos un cambio de nivel en lugar de un copiado, y no cambiamos o eliminamos la regla de archivado, en cuanto se ejecute nos encontraremos de nuevo con el fichero en cuestión en Archive y empezaran a contar de nuevo los 180 días de permanencia… por ello la opción de copiado es la recomendada por Microsoft, ya que no afecta a los 180 días, ni se corre el riesgo de rearchivado por la regla, y una vez que no se necesite, se podrá borrar.
En el siguiente enlace se tiene más información al respecto:
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
