NetApp Deduplicacion y LUNs: Documento

Hacía tiempo que no escribia sobre NetApp y su deduplicación. Como ya sabeis NetApp(y otros fabricantes como EMC) nos ofrece la posibilidad de deduplicar nuestros datos para ahorrar espacio. (Algunos articulos relacionados que he escrito anteriormente).
Muchas veces me he visto con dificultades para saber qué opcion es la mejor a la hora de provisionar LUNs que van a ser deduplicadas.

Por casualidad hoy he encontrado este documento en las communities de NetApp, donde se necesita login (que deben usar el mismo motor que las de VMware porque son clavadas..):
Configuring NetApp Deduplication With LUNs
"Deduplication creates free space, but where does the free space go? The paper describes 5 basic LUN configurations and the different results that occur once space is reclaimed by deduplication."

Aqui dejo el link: Configuring NetApp Deduplication With LUNs
de mi espacio de google para que os lo bajeis sin registrarse.

La configuracion más común creo que es la D (La LUN sin espacio reservado y la garantia de espacio establecida en el Volumen) y E (La LUN sin espacio reservado y sin garantia de espacio ninguna). Lo logico es que nos guste ver como encoje la LUN después de aplicar la deduplicacion.

¿Cómo saber cuánto se deduplicará?

La principal pregunta a la hora de aplicar deduplicación o convencer a alguien de que es algo que le puede venir muy bien es precisamente ¿Cual es mi potencial de deduplicacion? Es decir, si aplico la deduplicacion a tal o cual volumen: ¿Cuánto se deduplicará? ¿Cuanto espacio me ahorraré? El 10%, el 40%...

Aqui os pongo un script (en python) que realiza (o intenta realizar) una estimación de lo que nos ahorraríamos usando la deduplicación de NetApp.

Como ya expliqué en este post la deduplicación de NetApp funciona en un 99% de esta forma:
En algun lugar hay un directorio que dice que el fichero A esta almacenado en los bloques 123-345, 500-510 y 12999-14090. Por el momento esto es lo normal para todos los FS. La diferencia entre el FS deduplicado y el normal es que pueden usar el mismo bloque más de un fichero. Si edito el fichero A y añado 10KB al final y lo guardo como B en algun momento (dedupe en tiempo real o dedupe diferida) el proceso de deduplicacion reconocerá (via hashes o por comparacion de bytes) que ambos ficheros tienen los mismos datos y creará una entrada en el directorio que dice que B utiliza los bloques 123-345, 500-510, 12999-14090 y 66666-66669(Por ejemplo los bloques son de 1K), de forma que la creacion del fichero B solo ocupa 10K(del 66666 al 66669).

¿Como funciona el script?
El script mira recursivamente en el directorio que le indiquemos leyendo cada archivo. Posterirormente va troceando cada archivo en chunks de 4 kB (ese es el tamaño de bloque que usa NetApp) y calcula un md5 de cada bloque de 4kB. Se mantiene una lista de los md5 calculados y comprueba si se trata o no de datos duplicados.
Cada vez que se procesa un archivo el script nos proporciona por un lado la deduplicacion que obtendria ese fichero y por otro cómo vamos en el total del directoriro en el que estamos intentando estimar el ahorro debido a la deduplicación:

Archivo /tmp/dedup/Archivos_Backup.txt: Tamano 286927441 bytes (70051 bloques)
Estadisticas del Archivo /tmp/dedup/Archivos_Backup.txt: Bloques Usados: 3728, Bloques del Archivo: 70051, Ratio 5.3%, Ahorro 94.7%.
Estadisticas Totales Recalculadas: Numero de Archivos: 12, Bloques Usados: 7073, Bloques Totales: 73396, Ratio 9.6%, Ahorro 90.4%.

Finalmente, cuando se ha terminado de procesar todo el directorio el script nos muestra los datos importantes:
=======================================================================================================================
Estadisticas Totales Finales: Numero de Archivos: 961, Bloques Usados: 268422, Bloques Totales: 401134, Ratio 66.9%.
Ahorro Final que obtendras con la deduplicacion 33.1%.
=======================================================================================================================

En este caso obtendríamos un 33% de ahorro de espacio si usasemos deduplicacion.
El script sólo da una aproximación de los ahorros que conseguiríamos aplicando la dedupliación puesto que
se necesitaría también espacio para mantener la base de datos de hash y algunos metadatos.
Por las pruebas que he hecho es bastante fiable, incluso a veces el tiempo que tarda en hacerlo es equivalente en la cabina y con el script. A ver que os sale a vosotros...

Ejemplo de uso: python estimar_dedup.py /tmp/dedup
(Podeis poner delante time para ver el tiempo que tarda: time python estimar_dedup.py /tmp/dedup)

Con los comandos df -h y df -s antes y despues de realizar la dedupliación con NetApp(sis on, sis start -s) podreis comprobar si el script ha resultado fiable o no.

Por favor, si obteneis resultados(buenos o malos) o mejoras o problemas con el script, ¡comentadmelo! Espero que sirva aunque sea para saber a priori si te compensa usar deduplicacion o no...

Nota: Los resultados más espectaculares de la dedup de NetApp se dan en los ficheros que no pierden su alignment de 4kB anque se modifiquen. Como los vmdks de VMware y no como los ficheros de texto.

[root@server ~]# more estimar_dedup.py
#!/usr/bin/python

import os, sys, md5
from stat import *

# Lee todos los ficheros del directorio y
# estima los ahorros de la dudup de NetApp haciendo el md5
# y comprobandolo para cada bloque de 4 kB. el paramentro importnate
# es el que da el ultimo Ratio (un ratio de 70% significa que te ahorras # un 30%)

if len(sys.argv) != 2:
  print "Uso: nombre.py "
  sys.exit(1)

workdir = sys.argv[1]

if not os.path.isdir(workdir):
  print "Problema: " + workdir + " no es un directorio"
  sys.exit(1)

print "Comprobando directorio: " + workdir

numfiles = 0

storage_blocks = 0

total_blocks = 0

current_file_storage_blocks = 0

fingerprint_index = {}


for root, dirs, files in os.walk(workdir):
 for f in files:
  filename = root + "/" + f
  print "Archivo " + filename + ": ",

  if f==".snapshot":
   continue

  if not os.access(filename, os.R_OK):
   print "No access, skip"
   continue

  if os.path.islink(filename):
   print "Symlink, skip"
   continue

  mode = os.stat(filename)[ST_MODE]
  if not S_ISREG(mode):
    print "No regular file, skip"
    continue

  file_size = os.stat(filename).st_size

  blocks = int( round( (file_size + 2048) / 4096.0) )

  print "Tamano " + str(file_size) + " bytes (" + str(blocks) + " bloques)"

  f = open (filename, "r")

  current_file_storage_blocks = 0

  for block_number in range(0,blocks):
    blockdata = f.read(4096)
    m = md5.new(blockdata)
    fingerprint = m.digest()

    if fingerprint_index.has_key( fingerprint ):
      pass
    else:
      fingerprint_index[fingerprint] = True
      storage_blocks = storage_blocks + 1
      current_file_storage_blocks = current_file_storage_blocks + 1

    total_blocks = total_blocks + 1

  f.close()

  print "Estadisticas del Archivo "+ str(filename) + ": Bloques Usados: "+str(current_file_storage_blocks)+ ", Bloques del Archivo: "+str(blocks)+ 
 ", Ratio "+str( round((100.0 *current_file_storage_blocks)/blocks,1) )+ 
 "%, Ahorro "+str( round(100 - (100.0 *current_file_storage_blocks)/blocks, 1 ) )+"%."
  numfiles = numfiles + 1
  print "Estadisticas Totales Recalculadas: Numero de Archivos: " +str(numfiles)+", Bloques Usados: "+str(storage_blocks)+ 
 ", Bloques Totales: "+str(total_blocks)+ ", Ratio "+str( round ( (100.0 *storage_blocks)/total_blocks, 1 ) )+ 
 "%, Ahorro "+str( round ( 100 - (100.0 *storage_blocks)/total_blocks, 1) )+"%."
  print "-"
  print

print
print "======================================================================================================================="
print "Estadisticas Totales Finales: Numero de Archivos: " + str(numfiles) + ", Bloques Usados: " + str(storage_blocks) + 
 ", Bloques Totales: " + str(total_blocks) + ", Ratio " + str ( round ( (100.0 *storage_blocks)/total_blocks, 1) ) + "%."
print "Ahorro Final que obtendras con la deduplicacion " + str ( round ( 100 - (100.0 *storage_blocks)/total_blocks, 1) ) + "%."
print "======================================================================================================================="

Deduplicacion de NetApp con LUNs

Sigo con la saga de posts sobre NetApp. Esta vez algo que no sé si es muy usado pero que nos puede venir muy bien:
Deduplicacion de NetApp con almacenamiento tipo bloque (LUNs presentadas al host por FC o iSCSI).
Por lo general todo lo referente de la deduplicacion de NFS es aplicable a la deduplicacion de LUNs:

• Necesitas la licencia de NearStore y dedupliacaion(A-SIS)
• Se sigue activando el proceso de deduplicacion con el comando "sis on" para el FlexVol que contiene las LUNs
• Las limitacions del tamaño del FlexVol siguen siedo las mismas.
• Con el comando "sis status" vemos el estado del porceso y con "sis config" vemos el calendario de la deduplicacion.

¿Qué es lo diferente? Lo diferente es que las LUNs están implementadas encima del sistema de ficheros WAFL. Dicho sistema de ficheros ve las LUNs como un sólo fichero y dicho fichero es tratado como "space reserved", lo que significa que durante la creacion de la LUN se reserva el maximo tamaño de dicha LUN. (Simplificando) Si creas una LUN de 50GB, se crea un fichero de 50GB.

Debido a que las LUNs son creadas de este modo, el espacio es reservado en su creacion y el dichero que representa la LUN no decrecerá jamás su tamaño y nunca refeljará los ahorros de la deduplicacion (no cambiará su tamaño). La deduplicacion no nos servirá para nada. Sí que funciona en dicha LUN, pero no nos sirve de nada.

¿Cómo resolverlo?
Es facil, simplemente cuando se crea la LUN desmarcaremos la casilla "Space Reserved" y dejaremos que Data ONTAP reserve bajo demanda el espacio que require la LUN en dicho FlexVol.
El fichero que representa la LUN puede crecer y decrecer en tamaño sin problemas. Por ello la deduplicación, además de funcionar como en el caso anterior, sí será efectiva y nos permitirá ahorrar espacio. Este espcacio nos permitirá provisionar otras LUNs en el mismo FlexVol teniendo un ojo encima...

En resumen:

• Instalar y configurar la deduplicacion para NFS y LUNs es lo mismo en esencia.
• Desmarcar la casilla "Space Reserved" cuando se crea la LUN que va a ser deduplicada.
• A diferencia de NFS , con LUNs el espacio ahorrado NO se verá desde el host (No hay comando SCSI que pueda pasar ésta informacion del array al filesystem del host). El comportamiento diferente del NFS se debe a que no hay otra capa de indireccion entre el array y el host, por eso, en NFS las caracteristicas del FS del array son vistas directamente por el host, en consecuencia en NFS, los bloques que se liberan en el dedupe estan disponibles inmediatamente para el host (ESX o servidor normal). Además, el host no podrá almacenar más datos que el tamaño máximo de la LUN (como es normal).
• Es importante el orden: (Si no, se te pueden llenar los snaps porque el proceso de dedupe cambia mucho los datos...)
  
• Desactivar los snapshosts,
• Deduplicar,
• Activar snapshost.

• Con el ahorro que se obtiene de la deduplicacion se puede provisionar otras LUNs en ese mismo FlexVol a otros servidores o usarlo para más snapshots....

Estado del Arte: Thin provisioning, Deduplication, SVI, NFS, FC

Uno se queda pensado cuando ve el pequeño boom que esta teniendo el viejo NFS con VMware y las soluciones tan vistosas que están saliendo al mercado para VDI..., para ahorrar espacio (duplicación, thin provisioning etc...). La confluencia de todas estas tecnologías está haciendo que a la mayoría de los usuarios se escape las implicaciones que tiene usarlas por lo poco que el mercado ayuda y lo mucho que nos confunden los comerciales:
¿Que hacer? Usar NFS? Usar VMFS? Usar deduplicación? Usar SVI?
Todo tiene sus pros y sus contras, pero al menos hay que saber lo que nos espera:

La historia suele comenzar con VDI o con las maquinas virtuales en VMFS y cuando nos damos cuenta de que no es tan barata la solución como la pintan, entonces vemos si hay algo en el mercado que nos pueda satisfacer y hacer que nos gastemos menos...

Bien, estos dos vídeos comerciales: Primero y Segundo nos pueden hacer pensar que todo es muy bonito y que la solución es trivial, barata y sencilla.

El primer vídeo nos muestra al campeón de la Fibra: EMC enseñándonos como de unos 10GB podemos realizar unos 1000 escritorios. Nos explica como metiendo una capa extra, con cinco "Fully realiced" copies (50GB) podemos escalar a 1000 escritorios usando snaps de la cabina "sin ocupar nada de espacio".
En fin, la única idea que me gusta del vídeo es que menciona que podemos dar servicio Silver, Gold etc, según de las copias full que realicemos y eso da la ligera impresión de que al menos suponen "cierta" pérdida de performance.
Al margen de que sea "solo pizarra" y de que no diga un solo detalle técnico, por lo que nos muestra, podemos pensar que se trata de LUNs de VMFS(en ningún momento lo dice y por lo que sabemos los snaps EMC basados en SAN son de tipo LUN), pero a nada que nos acordemos del limite (256 creo recordar) de LUNs que pueden ver nuestros ESX llegamos a la inevitable conclusión de que se trata de NFS, (a no ser que VMware, al ser muy amiguitos, les haya pasado las especificaciones de VMFS durante el café...).
Conclusión: Lo que nos propone EMC, gran defensor del FC, para VDI es claramente el uso de NFS: "Adiós FC, (o hasta luego)"
(Y eso que me encanta la fibra: Te hace ir al baño ;-) , No, en serio, vale que el inicio es complejo y que su precio, si te la puedes permitir, no es una ventaja, pero luego tiene una estabilidad muy buena, hay que decirlo).

El segundo vídeo, esta un poco más currado la verdad (faltaría mas, es NetApp!). Después de verlo te queda claro que no se pueden correr 1000 VMs con solo ese espacio de disco, pero ilustra bien la potencia que tiene NFS+NetApp y sus clones a nivel de fichero. Por algo su sistema de ficheros se llama WAFL ("Write Anywhere File Layout'") y nos permite ofrecer Thin Provisioning ("dedicate on write not on allocation") según instalamos la cabina.

Aquí llegamos al primer meollo de la cuestión:
Thin provisioning y VMware, es decir, Thin Provisioning en dos niveles: nivel VMware y nivel NFS(cabina).

Puede parecer una buena idea tener ambas capas pero esto lleva a pesadillas serias en la administración (sobretodo el primer punto):
1.- El tener el thin provisioning y el thin disk nos produce issues con Storage VMotion, Cold Migration, deploy de template...

Cuando creamos una VM en VMware, por defecto dicha VM es creada en el volumen NFS como thin disk, de hecho esto no es algo que lo determine VMware sino el propio servidor de NFS. Segun "ESX Configuration Guide":

Y mas tarde, el mismo documento, añade: "The virtual disks that you create on NFS‐based datastores use a disk format dictated by the NFS server, typically a thin‐disk format that requires on‐demand space allocation. If the virtual machine runs out of space while writing to this disk, the VI Client notifies you that more space is needed."

Posteriormente, cuando realizamos alguna de las acciones antes mencionadas (Storage VMotion, Cold Migration, deploy de template) el disco se vuelve thick. Se puede, como hemos visto (autobombo, jeje), clonar el disco a thin y volver a unirlo a la VM. Incluso se puede scriptear, pero no deja de ser un arreglo.

2.- Consideremos también la visibilidad y la administración dependiendo de si el disco es thin o thick:
2.1.- Desde la perspectiva del VC, siempre veremos el tamaño del disco thin en el datastore y si, como suele ocurrir, tienes multiples usuarios finales haciendo deploys de VMs , éstos no tendrán la visibilidad de la ocupacion actual para realizar el provisionamiento y el hecho de que las VM tengan la posibilidad de llenar X espacio puede llegar a ser un problema serio: Estamos infraprovisionando el almacenamiento y sobreprovisionando las VMs: Algo puede ir mal.

2.2.- ¿Que ocurre con nuestra Console ? Haciendo un "ls" veremos el disco thin ocupando la maxima capacidad de la que es capaz, sin embargo un "du" nos devuelve el tamaño thin del disco. Amazing.

Veo que puede dar menos problemas que el Thin Provisioning esté controlado en el sistema de almacenamiento que tengamos. Esto es totalmente discutible pero intuyo que sería mucho mas simple para todos. (Creo que 3PAR actualmente puede manejar correctamente el formato de vmdk "zero'ed thick" asi que probablemente por ahi vayan los tiros en un futuro. ¿Alguien sabe cómo decirle a nuestro NFS que por defecto provisione de forma thick y no thin?).

El otro tema candente que nos venden como la panacea es la Dedupliacion(Single Instancing).
La deduplicacion consiste en que los bloques de datos iguales no se repiten, si no que en su lugar hay un puntero que los señala.
Explicacion somera (esto es cierto en un 90% para NetApp):
En algun lugar hay un directorio que dice que el fichero A esta almacenado en los bloques 123-345, 500-510 y 12999-14090. Por el momento esto es lo normal para todos los FS. La diferencia entre el FS deduplicado y el normal es que pueden usar el mismo bloque más de un fichero. Si edito el fichero A y añado 10KB al final y lo guardo como B en algun momento (dedupe en tiempo real o dedupe diferida) el proceso de deduplicacion reconocerá (via hashes o por comparacion de bytes) que ambos ficheros tienen los mismos datos y creará una entrada en el directorio que dice que B utiliza los bloques 123-345, 500-510, 12999-14090 y 66666-66669(Por ejemplo los bloques son de 1K), de forma que la creacion del fichero B solo ocupa 10K(del 66666 al 66669).

Como se puede intuir esto no puede ser manejado por la cabina que esta detrás sin algo intermedio, un S.O o un FS que escanean los bloques duplicados y los enlazan con lo que significan más alto en la cadena y deciden que hacer si algo desde arriba necesita escribir en un bloque previamente deduplicado etc, etc...
Lo que choca de todo esto es que lo que les pedimos idealmente a nuestros diseños de almacenamiento (al menos en teoria) es precisamente NO hacer nada de esto pues idealmente debe hacerse mas arriba (en el File System ).
Por el momento VMFS no es capaz de hacer resto pero SVI(Scalable Virtual Image) sí parece que lo va a hacer de alguna forma quitando (o compitiendo con) la necesidad de la deduplicacion a nivel de cabina.

¿Que es SVI?
Explicacion muy somera porque hay poca info: Es una tecnología que esta basada en "linked clone" (VMware Workstation 6) que, segun VMware, reducirá en un 90% los requerimientos de almacenamiento en entornos de escritorios virtuales. Segun ellos, repito, mejora la gestion de imagenes de escritorios y facilita el provisioning. La idea es tener un disco stateless(o unos pocos) que lleven el SO (disco maestro) que sea el mismo para todos y luego un disco de personalización para cada usuario de forma que los parches etc sólo haya que aplicarlos en los discos maestros.

Seria muy interesante una comparacion de NetApp sis-clone y SVI, incluso trabajando juntos...

¿Que concluir de todo esto?

NFS mola, tiene sus cosillas pero mola, el elegirlo o no depende del entorno, como siempre.

• La primera conclusion de todo es que cada vez es menos cierto el paradigma de que la Fibra es la Reina. (Con lo que me gusta...jeje)
• Lo segundo es que VMware deberia meter muchas mas horas en el VMFS y hacer que sea algo realmente competitivo. Seria genial que integrasen la "deduplicacion" de SVI en VMFS. Y tema Thin Provisioning... Tiempo al tiempo.
• Lo tercero es que NFS te puede quitar bastantes dolores de cabeza si estas pensando en migrar en un futuro o tener un entorno heterogeneo (Citrix XenServer o Microsoft Hyper-V). Probablemente para ese momento los formatos de discos virtuales ya sean interoperables y cualquier cabina es capaz de presentar NFS y CIFs.
• Lo cuarto es que si pones soluciones de VDI basado en cabina como muestran los videos o VDI+SVI mejor si tienes cache de sobra para parar un tren. Como idea: Puede servir para dar diferentes niveles de servicio en escritorios(¿esto es util realmente?): GOLD, SILVER, BRONZE dependiendo del ratio (Escritorios)/(Full VM Copy)...
• Lo quinto es que la solucion de NetApp que incorpora un S.O y un File System precisamente para hacer cosas como la deduplicacion es muy buena aunque de forma "pura" la cabina no se debería de ocupar de la deduplicacion, es cosa del File System. Desde luego no hay que olvidar que la deduplicacion nos sirve también para todo lo demas que no sea vmdks(en una cabina no solo existe VMware...), por ello pienso que en global la solucion de NetApp es muy versatil y cómoda aunque también pienso que deberia ser el propio FS (VMFS en este caso) el que realizase la deduplicacion.

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

Cada vez es más usual trabajar con VMware sobre NFS. La combinacion con una NetApp y sus FlexVolumes hace que sea algo muy flexible y facil de provisionar y administrar. Con la capacidad de las cabinas NetApp de realizar Thin Provisioning somos capaces de dar grandes volumenes de datos pero ocupar solo lo necesario. El concepto se ve facilmente de forma grafica. Por defecto, cuando provisionamos VMDKs por NFS las cabinas NetApp lo administran como thin provisioned. Hasta el momento esto no habia dado problemas de ningun tipo, es mas, es una gran ventaja.

Las pruebas muestran que, aunque los VMDKs son provisionados como thin en su creacion, luego se pueden convertir a thick a lo largo de su vida por una serie de operaciones como son (Quiza haya mas):
:( Migracion de los VMDKs de un datastore a otro (aunque el destino tambien sea NFS) convierte los VMDKs a thick.
:( Realizar clones de los VMDKs thin hace que los clones sean thick.
:( Realizar Storage VMotion tambien provoca que los discos se vuelvan thick.

¿Como solucionarlo?

Si tenemos una NetApp con single file SnapRestore estamos de suerte. Bueno, al menos las dos primeras operaciones antes descritas sí que podemos conseguir que nos mantengan los VMDKs de forma thin. (Para la tercera Storage VMotion no sirve).

Pasos:

1. Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name ].
2. Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
3. Ahora podemos correr un SnapRestore para recuperar el .vmdk y el -flat.vmdk. [snap restore -t file -s snapshot-name -r new filename and path original filename and path]
4. Editaremos el .vmdk de la nueva VM para que apunte al nuevo -flat.vmdk. Y ya solo nos queda Edit Settings y añadir el disco.

la funcion Shadow Copies de NetApp sobre CIFS

El otro dia en Madrid asistimos a una demostración de NetApp. Hacía tiempo que tenía ganas, la verdad es que es una pasada, lo que no creo que sea igual es el precio....

Algo que muchos conocerán pero que me llamó muchisimo la atencion es la utilidad de acceder a las shadow copies de volumenes compartidos. Me explico, estas cabinas son capaces de presentar al usuario de la NAS que se ha conectado por CIFS una especie de historial (o versiones) de los archivos que almacena en los volumenes compartidos, es decir la funcion de snapshots de NetApp se integra con VSS(Microsoft Volume Shadow Copy Service) de tal forma que los usuarios pueden ver los snapshots tomados en la cabina via el cliente de VSS.
Es tan facil como pinchar en el menu contextual de un archivo (boton derecho), ir a propiedades y pichar la pestaña Versiones. La verdad es que es asequible para cualquier usuario y quitaría mucho trabajo a los administradores de sistemas que tienen que tirar de backup.