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.

SCSI Reservations y VMware

Cuando nos ponemos a trabajar con almacenamiento compartido mas tarde o mas temprano sale el termino SCSI reservations: Estas reservas sirven para asegurar el acceso exclusivo a recursos de disco cuando éstos recursos son accedidos por multiples hosts. Es algo que suele salir a la luz con VMware VMFS, Microsoft Cluster Server, etc...

Las SCSI Reservations son solamente usadas para operaciones específicas en las cuales se realizan cambios en los metadatos y son necesarias para prevenir que varios hosts puedan escribir concurrentemente evitando de esta manera la corrupción de datos.

Una vez que la operación es completada, la reserva es desbloqueada y las demás operaciones pueden continuar. Es obvio que es importante minimizar el numero concurrente y la duración de las operaciones que necesiten SCSI Reservations debido a que usan un lock exclusivo que al final lo que hace es serializar las operaciones. Cuando se realizan demasiadas reservations a la vez, tendremos errores de I/O porque el host que estaba intentando bloquear el recurso (la LUN, el fichero...) no puede puesto que otro host la habra bloquedao previamente. Cuando un host no puede realizar uns reservation porque hay otro host escribiendo, el primero continuará reintentandolo en intervalos de tiempo aleatorios hasta que lo logre, sin embargo, si se realizan demasidos intentos sin exito, la operacion fallará.

En el entorno de VI3, se vuelve importante el tema de las SCSI Reservations y es un factor a considerar a la hora de hacer el diseño de una arquitectura.
Algunos ejemplos de opreaciones asociadas a VI3 que requieran escrituras en los metadatos son:

• Crear o borrar un volumen VMFS
• Expandir un volumen VMFS(para mi usar extents esta prohibido)
• Encender o Apagar una VM
• Bloquear o liberar el lock de un archivo
• Crear o borrar un fichero
• Crear una plantilla
• Desplegar una VM de una plantilla
• Crear una nueva VM
• Realizar un VMotion
• Crecimiento de un archivo (Snapshot o un Virtual Disk Thin Provisioned)
• Hacer Rescans de VMFS, hacer vdf en console...
  

Lo normal en una infraestructura VI3 es que haya un numero residual de conflictos de SCSI Reservations.(Se ve en /var/log/vmkernel). Esto no nos debe preocupar porque tiene poca influencia en el rendimiento. Lo que si hay que evitar es tener demasiados problemas de SCSI Reservations porque además de afectar el rendimiento, puede hacer que algunas VMs se paren: En el caso de Linux, en muchos kernels, hace que la VM se ponga en Read Only (se soluciona cambiando un valor de timeout de mptisci.h: un RPM) y en el caso de Windows puede parar completamente la maquina.(Se soluciona cambiando un valor de timeout del disco del Registry: HKEY_LOCAL_MACHINE\System\CurrentCOntrolSet\Services\Disk\TimeOutValue)

Para mimimizar estos problemas deberemos intentar que se produzcan las menos operaciones posibles y si es posible que no ocurran simultaneamente en la medida de lo posible, es decir, una best practice seria Verificar que ninguna otra operacion de Reserva de SCSI esta ocurriendo a nivel de archivo, LUN o grupo de LUNs antes de proceder.
Algunas acciones para reducirlas son:

• Usar un punto central de administracion (Virtual Center) para ver qué operaciones se estan realizando y serializarlas en la medida de lo posible. (También las que se hacen por console)
  
• Mirar el estado de los Backups puesto que estos hacen uso de las SCSI Reservations.
  
• Limitar el numero de Snapshots activos.(Los snapshots crecen de 16MB en 16MB y cada vez que crecen usan SCSI Reservations)
• Intentar que las VMs no tengan los discos en más de dos LUNs puesto que una VMotion (operacion de VM) de una VM que tenga un disco en una LUN y otro en otra se dividira en cuatro operaciones a nivel de LUN.
  
• Intentar no realizar VMotion simultaneamente de dos VMs que residen en la misma LUN.
• Intentar solo realizar una migracion cold(VM apagada) por cada LUN en cada momento.
• Intantar no apagar o encender muchas VMs a la vez.(Esto es más por rendimiento que por SCSI reservatiosn pues solo dura 7 microsegundos el lock de reinicio)
• Limitar las creaciones y desplieges a una VM por LUN en cada momento.
• Usar un host en concreto para realizar despliegues siempre. De esta forma es facil limitar la creacion de templates, importaciones, despliegues...
  
• Usar un tamaño de LUN adecuado (<600gb)
• Usar solo un FileSystem en cada LUN
• No correr scripts que afecten a las LUNs (Backup, permisos) desde varior ESX a la vez y sobre las mismas LUNs.
  

Estas son algunas acciones para limitar dichas operaciones. Lo primero de todo es ver en nuestros logs si hay una buena cantidad de SCSI Reservations y ver si tenemos problemas de rendimiento. Posteriormente podemos aplicar alguna o todas de las recomendaciones anteriores.

Adjunto una Tabla en la que se ve el numero de operaciones por LUN que se podrian realizar corriendo un determinado riesgo:

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....