01/10/2009

NetApp Innovation 2009

Por tercer año consecutivo vamos a realizar en unas semanas nuestro evento anual para clientes, NetApp Innovation el 4 de Noviembre.

Este año contaremos con toda una ciudad dedicada a nuestos productos, soluciones, partners y clientes. Se podrán ver nuestra tecnología en acción, asistir a charlas y a demos de algunos de nuestros productos estrella.

El lema de este año es la Eficiencia, de la mano de nuestra tecnología y de alguna de las funcionalidades que ya hemos comentado en este blog como la deduplicación, los snapshots, thin-provisioning, etc.

Como ya es tradición tendremos algún premio a los que demostréis vuestro conocimiento en alguno de los Quiz y puede que hasta algún juego que mida vuestra habilidad ... eso sí, en un escritorio virtual que es lo que está de moda.

Si queréis más información o registraros tenéis esta página disponbile:

www.netapp-innovation.es

Innovation

27/09/2009

VDI con NetApp y Quest vWorkspace

En Junio hablábamos en este post sobre algunos ejemplos de entornos de escritorios virtuales (VDI) montados sobre diferentes virtualizadores y almacenamiento NetApp.

Hace unos días Quest Software ha anunciado su última versión del broker para VDI vWorkspace. Entre otras novedades, aparece una integración entre Quest y NetApp que permite que el broker sea capaz de provisionar nuevos escritorios virtuales utilizando la capacidad de clonado instantáneo (y sin consumo de espacio) de nuestras cabinas; posteriormente el software de Quest se ocupa de hacer que estas nuevas máquinas virtuales queden inventariadas y perfectamente disponibles para los usuarios.

Aquí tenéis la nota de prensa completa del anuncio de Quest.

Para los que queráis algún detalle más técnico, podéis ver este video que muestra como funciona la integración y como se pueden provisionar de forma muy muy rápida las máquinas virtuales gracias a nuestro flexclone.

Inicialmente era posible crear los clones de las máquinas virtuales a mano o mediante scripts. Posteriormente nuestra herramienta Rapid Clonning Utility (RCU) permitió automatizar el clonado y registro de las máquinas virtuales. Esta nueva integración permite ir un paso más lejos, permitiendo el control desde el broker de los clones que realiza la cabina.

10/09/2009

Rendimiento - Parte II - Los clientes

Como decíamos, los clientes (servidores) que acceden al almacenamiento son en muchas ocasiones el origen de los problemas de rendimiento, y no siempre es fácil identificar de dónde vienen las limitaciones.

Un ejemplo típico, que nos encontramos intentando medir el rendimiento de un equipo, es el de realizar lecturas o escrituras de uno de los discos con un programa que no es capaz de generar la carga suficiente, o que siendo mono-hilo, espera a que se procesen unas peticiones antes de lanzar más en paralelo. El caso más habitual es intentar hacer un "dd" contra un disco; en la mayoría de los casos un solo proceso no es capaz de sacar el máximo rendimiento de la cabina de discos o de la red de comunicaciones entre ella y el servidor. Lo que si nos da esta prueba es una medida de la latencia o tiempo de servicio que obtenemos en el acceso a disco.

La otra gran precaución al realizar pruebas de rendimiento es la de configurar el cliente para que no haga uso de su caché de acceso a disco (buffer caché), ya que puede trastor mucho los valores de rendimiento que medimos. Muchos programas no permiten configurar este comportamiento, por lo que es importante conocer si utilizan la caché o no.

Un ejemplo para sistemas operativos Unix es el comando SIO que está en nuestra página de soporte (now.netapp.com):

    http://now.netapp.com/NOW/download/tools/sio_ntap/

 Dentro de las opciones de ejecución tenemos:

Options:
  -noflock           :  prevents the files from being locked during access
  -output -filename  :  send all output from the command to 'filename'
  -direct            :  disable file system caching - available in aix, solaris and linux

Vemos la diferencia en un acceso NFS a 1 Gbps entre utilizar o no esta opción:

sio_ntap_linux 100 0 8192 10m 5 5 testfile
...
KB/s:           1926367

Es decir unos 1.9 GB/s sobre una conexión de 1 Gbps ... evidentemente algo está mal.

Con la opción direct le indicamos al programa que no utilice la buffer caché del servidor:

sio_ntap_linux 100 0 8192 10m 5 5 testfile -direct
...
KB/s:              37758

Unos 37MB/s, algo bastante más razonable.

Otra utilidad que me gusta mucho para hacer pruebas de rendimiento, en este caso desde Windows, es IOmeter. Esta utilidad permite generar patrones de acceso de varios tipos y mostrar tanto los datos en vivo como un report de la prueba realizada. La siguiente pantalla muestra el resultado de ejecución de una prueba de lectura/escritura sobre un disco iSCSI conectado por 1Gbps a una de nuestras cabinas:

Iometer

Como se puede ver se consiguen 143 MB/s (110 lectura + 33 escritura), con un tiempo medio de servicio de 2ms.

La columna de CPU también es importante, pues podría indicarnos un cuello de botella en la CPU del servidor que genera la carga, aunque este no es el caso de este ejemplo. 

06/09/2009

Rendimiento - Parte I - Generalidades

El rendimiento es uno de los temas preferidos para muchos de los que nos dedicamos al almacenamiento. Es también en muchas ocasiones fuente de dolores de cabeza y de nuevos conocimientos; la necesidad de investigar un posible cuello de botella, o de ver los límites de una plataforma te hace conocer mejor los equipos con los que trabajas.

Hay dos máximas respecto al rendimiento que aprendí hace tiempo:

-La respuesta a cualquier pregunta de rendimiento es "depende"

-El almacenamiento es el culpable de cualquier problema de rendimiento hasta que se demuestre lo contrario

Las respuestas "dependen" porque hay múltiples formas de medir el rendimiento, diferentes tipos de accesos, pruebas mal planteadas ... que hacen que las cosas nunca sean blancas o negras.

Respecto a la culpabilidad, supongo que por la falta histórica de monitores de rendimiento en acceso a disco en los sistemas operativos, o por la opacidad de los equipos de almacenamiento antiguos, es algo que hemos heredado y con lo que tenemos que vivir.

Afortunadamente los equipos actuales permiten "ver" el rendimiento con más detalle, si bien hay que saber dónde y qué mirar.

Lo primero por determinar es que queremos medir. Se pueden hacer pruebas para medir varios parámetros de cualquier sistema, y en ocasiones, no es fácil averiguar cuál es el factor limitante, que puede perfectamente no ser nuestra cabina de almacenamiento. Entre otros, los puntos más habituales que podemos medir o encontrar como limitantes son:

-Proceso que genera carga en el cliente

-CPU o ancho de banda (bus) del cliente

-Red de comunicaciones entre el cliente y la cabina (red SAN o IP)

-Caché de la cabina

-Buses de la cabina (internos y/o de acceso a disco)

-Discos físicos en la cabina (ejes o spindles)

En los siguientes posts veremos con más detalle estos factores.

29/06/2009

Algunos ejemplos de VDI y servidores virtuales con NetApp

En los siguientes links tenéis algunos documentos y videos sobre cómo utilizar nuestras cabinas de almacenamiento en diferentes proyectos de virtualización, con instrucciones más o menos detalladas de cómo realizar la implementación y de cómo aprovecharse de algunas de nuestras funcionalidades:

Microsoft Hyper-V:

http://blogs.technet.com/mattmcspirit/

... y videos explicativos:

http://virtualboytv.com/netapp1.aspx

http://virtualboytv.com/netapp2.aspx

http://virtualboytv.com/netapp3.aspx

http://virtualboytv.com/netapp4.aspx


VDI de VMware sobre un FAS2050:

http://www.vmware.com/files/pdf/resources/VMware_View_on_NetApp_Unified_Storage.pdf


Best Practices con Citrix VDI:

http://www.netapp.com/us/library/technical-reports/tr-3748.html


1000 puestos de VDI con VMware y NetApp NFS:

http://www.netapp.com/us/library/technical-reports/tr-3724.html


4000 puestos de VDI con VMware y NetApp NFS:

http://www.netapp.com/us/library/technical-reports/tr-3725.html


Ya lo hemos comentado en alguna ocasión, pero me gustaría volver a destacar cómo la deduplicación y el clonado son especialmente interesantes para este tipo de entornos, permitiéndonos reducir en gran medida la cantidad de espacio necesario en la cabina.

Otra de las cosas interesantes, que podéis ver en este caso en el documento de VMware, es cómo se plantea separar las imágenes de los sistemas operativos de los datos de los usuarios, y para éstos se plantea el que sean unidades de red accesibles mediante CIFS. Esto tiene grandes ventajas en ahorros de espacio y en políticas de copias de seguridad de esos datos.

El que nuestros equipos sean capaces de prestar sevicio de LUNs o NFS para los discos de las máquinas virtuales, y de CIFS para los datos de los usuarios, permite que podamos montar todo el servicio de escritorios virtuales con un solo equipo y una arquitectura muy sencilla, lo que permite por ejemplo plantear esta solución para oficinas o centros de trabajos pequeños y/o remotos.


21/05/2009

Backups sobre VTLs y deduplicación

Hola de nuevo:

En los post anteriores hemos hablado de deduplicación en nuestras cabinas de almacenamiento (FAS), que permiten eliminar datos redundantes, y por tanto ahorrar espacio, en el sistema que utilizamos para dar servicio de almacenamiento a servidores o usuarios.

En este post quiero revisar otra propuesta de ahorro de espacio, en este caso para las copias de seguridad realizadas con diferentes software de backup.

Es muy habitual en muchas organizaciones el disponer de una librería de cintas para realizar las copias de seguridad; durante años las cintas han sido el dispositivo por excelencia para realizar copias de seguridad. En determinados tipos de entorno, tambien se han utilizado durante mucho tiempo discos como repositorios, generalmente temporales, de copias de seguridad.

El utilizar discos para las copias de seguridad tiene algunas ventajas, ya que estos permiten mayores velocidades (y menores), se averían menos, permiten mayor número de grabaciones, los datos son accesibles inmediatamente, se evita la manipulación de cintas, etc.

Sin embargo, los discos utilizados como tales para realizar copias de seguridad tienen el problema de que la mayoría de los software de copia de seguridad funcionan mejor sobre cintas.

Para solventar este problema, hace unos pocos años se comenzaron a desarrollar los dispositivos de cintas virtuales (Virtual Tape Library), que permiten crear librerías de cintas y cintas virtuales al software de backup, pero utilizando un dispositivo basado en disco para almacenar las copias de seguridad.

Con la reducción de precio de los discos de gran volumen (ATA) y el aumento de la densidad de los mismos (acualmente los discos son de 1TB o más), en los últimos años (2-3) hemos visto un gran crecimiento en el interés por las VTLs como dispositivos temporales o permanentes para realizar copias de seguridad.

En este enlace podéis ver la información relativa a las VTLs que comercializamos en NetApp.

En la mayoría de los entornos las cintas no desaparecen, ya que los backups de larga duración (años) y los que hay sacar fuera del CPD se suelen mantener en cinta.

Lo que permiten las VTLs es que se realicen las copias de seguridad de forma más rápida, más paralela y más fiable. Adicionalmente, durante el tiempo que mantengamos esos backups en la VTL, las restauraciones son muchos más rápidas, ya que recuperar de una cinta requiere moverla físicamente (puede que manualmente desde un armario).

Lo que nos aporta la deduplicación en las VTLs es la capacidad de que almacenemos en "disco" un periodo mucho más largo de copias de seguridad, reduciendo más la cantidad de cintas a utilizar y extendiendo las ventajas en las restauraciones a periodos mucho más largos.

La explicación es sencilla, cada copia de seguridad completa (full) de un determinado entorno se parece mucho a otra copia completa realizada del mismo entorno con unos días de diferencia. Si la funcionalidad de deduplicación es capaz de encontrar esas similitudes, seremos capaces de almacenar muchos de esos backups ocupando solo la primera copia y las diferencias (si la deduplicación fuera perfecta).

En nuestro caso, la deduplicación que se implementa en las VTLs es diferente de las que se implementa en las cabinas de almacenamiento de propósito general, debido a la diferente naturaleza de los datos y del tipo de escrituras que se realizan sobre el dispositivo.

Para los que quieran más detalles, hablamos sobre el tema en este TechTalk reciente, que emitimos en directo, pero que podéis volver a ver como un video.

14/04/2009

Corrijo, deduplícate por casi 0

En el post anterior hablamos de la deduplicación, en este sólo quiero dar unas cuantas cifras de entornos reales de algunos de nuestros clientes locales.

 

Precisamente el saber cuánto me voy a ahorrar con funcionalidades avanzadas de las cabinas, como la deduplicación, los snapshots o el clonado, es una de las claves pare poder plantear su uso en cualquier organización y para que los proyectos sean viables.

 

Tomando prestados los datos de Autosupport (la funcionalidad de nuestros equipos que manda correos electrónicos para notificar incidencias e información de soporte) podemos ver algunos casos reales.

 

Si tomamos los entornos de virtualización de servidores, tenemos varios ejemplos de ahorros que varían entre el 65 y el 90% de ahorro, y en algunos casos incluso mayores. La mayoría de estos entornos que he visto tienen ahorros por deduplicación superiores al 80%.

 

Un ahorro del 90% supone que varias LUNs por un total de 5 TB consuman en la cabina 500 GB. Estos cálculos hay que realizarlos sobre los datos que se han escrito en disco, es decir, no estamos contando el efecto del thin-provisioning. En este mismo ejemplo, los servidores podrían tener visible 1 TB de LUNs adicional sin consumir ningún espacio en la cabina.

 

Esto quiere decir que con menos de 1 TB de almacenamiento podemos dar servicio para un entorno de este tipo, en el que los servidores tienen disponibles 6 TB de almacenamiento, almacenar todos los datos actuales y mantener un colchón para soportar los crecimientos y cambios del entorno.

 

En otras palabras, que multiplicando por 0.16 el tamaño del entorno, y por tanto el coste del mismo, somos capaces de prestar ese servicio.

 

Estos ahorros se pueden conseguir en equipos NetApp con discos propios y, mediante la familia V-Series, en equipos que “virtualicen” discos de otros fabricantes. Uno de los equipos cuyos datos he revisado consigue un 89 % de deduplicación, casualmente utilizando discos de una cabina de otro fabricante para almacenar varios TB de máquinas virtuales.

 

10/03/2009

Deduplícate por 0

Ya avanzamos en el post anterior que la deduplicación era una funcionalidad que nos permite ahorrarnos espacio en nuestro sistema de almacenamiento.

Ojo, por que como pasa con muchos otros términos en el mundo de la tecnología, la misma palabra la utilizamos los diferentes fabricantes con diferentes significados. En algunos casos se utiliza para hacer referencia a clientes de backup que permiten evitar transferir datos que ya han sido transferidos por otros clientes y también lo podemos utilizar para describir la funcionalidad de un sistema de archivado que solo guarda los ficheros o emails iguales de los distintos usuarios una sola vez.

En nuestro caso, con deduplicación nos referimos a una funcionalidad que implementan las cabinas de almacenamiento y que permite que se identifiquen y eliminen bloques de datos redundantes. Esto se hace de forma transparente para los servidores o usuarios clientes, que seguirán viendo la estructura de datos original, pero internamente la cabina estará ahorrándonos los bloques de 4KB que estén escritos varias veces.

Esto se puede hacer para cualquier tipo de protocolo de acceso: FC, iSCSI, NFS y/o CIFS.

En los dos últimos, dado que se exporta un sistema de ficheros, los ahorros de la deduplicación son mostrados directamente al cliente, que vera como sus datos ocupan menos espacio en el sistema de ficheros tras ejecutar el proceso de la deduplicación.

En los servicios de LUNs (FC o iSCSI), los clientes ven un disco SCSI virtual que típicamente formatearan con un sistema de ficheros propios. En estos casos los clientes no pueden ver ningún cambio en el espacio disponible, puesto que esto “volvería loco” al sistema de ficheros en el cliente. Lo que conseguimos en estos casos es que el espacio "deduplicado" sea espacio libre en la cabina, y que haciendo thin-provisioning (ver post anterior) ese espacio lo podamos reutilizar para otras LUNs o servicios.

La forma en que en NetApp implementamos la deduplicación está pensada para poderla utilizar en muchos conjuntos de datos productivos, ya que al realizarse la búsqueda de bloques redundantes como un proceso “batch”, que típicamente se ejecutará fuera de la ventana de máximo rendimiento del equipo, el habilitar la deduplicación no afecta en gran medida al rendimiento del equipo y es bastante probable que dado un equipo que está dando un determinado servicio, sin cambiar ni añadir nada de hardware podamos deduplicar parte o todos los datos de ese servicio/s.

Una consideración que si hay que tener en cuenta a la hora del rendimiento es que al deduplicar los datos perdemos secuencialidad en los mismos, por lo que las lecturas secuenciales de datos deduplicados pueden verse algo penalizadas, es decir, nuestros backups puede que tarden un poco más. Las lecturas aleatorias y las escrituras típicamente no sufren penalización o esta es muy baja.

Para los que lo quieran probar, la licencia es gratuita para cualquier FAS 2000, 3000 o 6000 (es decir, todos los equipos que vendemos actualmente) y es necesario tener una versión de ONTAP igual o posterior a la 7.2.5.1.

Más información en el siguiente documento.

27/01/2009

Discos flacos o “thin-provisioning” de LUNs: Parte II, como usarlos

En el post anterior presentamos el concepto del thin-provisioning. Veamos ahora que implicaciones tiene trabajar con este tipo de discos “flacos”.

Si presentamos una LUN a un servidor cliente, lo más habitual es que este servidor la formatee con un sistema de ficheros y sobre esta estructura almacene datos (ficheros). Lo que pasa con la mayoría de sistemas de ficheros que contienen diversos ficheros que se van creando y destruyendo, es que el sistema operativo decide donde almacenar los datos dentro del disco asignado, normalmente aplicando algoritmos que maximizan el rendimiento, intentando almacenar los ficheros en trozos de disco lo más contiguos posible. Una excepción a esto sería una LUN que contenga un fichero de una base de datos que se haya creado una vez y no se amplíe; todos los bloques del fichero de ese fichero serán los mismos a lo largo del tiempo. Para la mayoría del resto de casos, lo que sucede es algo parecido a lo que muestra el defragmentador de disco de mi portátil:

Defrag

A pesar de que mi disco siempre ha tenido espacio libre podemos ver que el sistema operativo ha utilizado bloques a lo largo de toda la extensión del mismo.

¿Qué supone esto para una LUN presentada por una cabina de almacenamiento que utiliza thin-provisioning? Pues que a lo largo del tiempo el sistema operativo cliente termina escribiendo en todos los bloques de la LUN y por lo tanto ocupándolos desde el punto de vista del sistema de almacenamiento, a pesar de que el sistema de ficheros nunca sobrepase un determinado nivel de ocupación.

El que los bloques de disco de la LUN se ocupen significa que en una LUN con thin-provisioning estaremos consumiendo ese espacio en la cabina de almacenamiento, precisamente lo que queríamos evitar.

En condiciones estándar, los sistemas de almacenamiento no saben nada de lo que pasa en el interior de los sistemas de ficheros, por lo que no tienen forma de saber que hay bloques que han sido borrados por el sistema de ficheros y que por tanto se podrían liberar.

Esta es la mayor limitación que podemos encontrar para montar sistemas de propósito general que utilicen thin-provisioning de forma permanente, ya que a lo largo del tiempo el uso de espacio de las LUNs “flacas” irá creciendo a pesar de que la cantidad de datos en las mismas no crezca tanto.

¿Qué supone esto para un entorno de cualquiera de nosotros?

Que asumimos cierto riesgo sobre la disponibilidad del servicio ya que si nos quedamos sin espacio para almacenar nuevos cambios el equipo para el servicio de esa LUN.

Esto puede tener sentido para entornos poco críticos y ser impensable para otros. Si utilizamos el thin-provisioning como una medida temporal (por que no tenemos más espacio disponible y estamos esperando a liberar o ampliar la cabina) el riesgo estará acotado y tendremos una medida temporal para solucionar problemas de previsión.

Otra posibilidad es que utilicemos alguna técnica para que la cabina sea capaz de ahorrar bloques de forma permanente. Actualmente tenemos tres posibilidades en nuestros equipos:

  1. Utilizar “space-reclamation”. Esto es una funcionalidad que hemos desarrollado, por ahora para plataformas Windows, que permite mediante la instalación de una aplicación en el servidor cliente (SnapDrive), que esta notifique a la cabina los bloques del sistema de ficheros que han sido borrados, permitiendo que la cabina libere esos bloques y por lo tanto consuma menos espacio; aquello que en condiciones normales no hacen los sistemas operativos.

  1. Utilizar clonado de datos. Cuando necesitamos varias copias de un conjunto de datos (por ejemplo la BBDD de nuestro SAP), podemos utilizar el clonado de nuestros equipos para crear esas copias. Esta operación es instantánea por que los datos no se copian, sino que se crean nuevos punteros a los bloques de datos existentes. Lo que conseguimos es que una nueva LUN clonada no consuma nada de espacio adicional puesto que todos sus bloques son compartidos con la original. Cualquier modificación sobre las LUNs generaría diferencias que si consumirían espacio en la LUN clonada, que a todos los efectos de uso es independiente de la original. Este es probablemente el uso más espectacular del thin-provisioning ya que es muy sencillo conseguir muchas copias de esas LUNs utilizando una cantidad de discos ínfima. La cantidad de espacio necesario para todas las copias nuevas será la de la cantidad de cambios que se generen durante el tiempo de vida de esas copias.

  1. Utilizar deduplicación. Esta funcionalidad se ocupa de correr un proceso dentro de un contenedor (volumen) de nuestras cabinas, de forma que se identifican bloques (de 4KB) que estén escritos varias veces, dejando una sola copia de los mismos y tantos punteros como sea necesario. Esto nos permite que si los datos que tenemos en la/las LUN/s tienen cierta duplicidad, el sistema de almacenamiento sea capaz de ahorrarnos ese espacio y aumentar el ahorro en nuestras LUNs con thin-provisioning y conseguir que estos ahorros perduren en el tiempo; todo esto es transparente para los servidores clientes.

En otros posts profundizaremos en el clonado y la deduplicación, por si alguno queréis  algo más de detalle.

En resumen, el thin-provisioning nos permite provisionar más espacio del que tenemos disponible en la cabina, su viabilidad depende del tipo de entorno, el tipo de datos y su criticidad, y mediante el uso de las funcionalidades de clonado y deduplicación pueden extenderse sus ventajas a lo largo del tiempo. Por supuesto intentaremos siempre trabajar con un colchón de espacio libre que nos permite soportar cierto nivel de crecimiento sobre las esas LUNs y deberíamos monitorizar el consumo de espacio de las mismas para detectar posibles problemas de llenado antes de que sucedan.

Por cierto, no se si lo he mencionado, pero el thin-provisioning es una funcionalidad gratuita en todas nuestras cabinas de almacenamiento.

26/12/2008

Discos flacos o “thin-provisioning” de LUNs: Parte I, el concepto

La verdad es que no conozco ninguna traducción buena para el concepto del thin-provisioning de almacenamiento y eso de los discos flacos no suena muy bien … intentaré explicarlo.

El thin-provisioning consiste en presentar más espacio de almacenamiento del que se está utilizando o incluso existe en el sistema de almacenamiento.

El caso más habitual consiste en poder crear una LUN (o disco SCSI virtual) que no consume todo el espacio que tiene la misma. Por ejemplo, creamos una LUN de 100GB que no consume 100GB en la cabina.

En los equipos de NetApp, adicionalmente podemos hacer thin-provisioning en los contenedores de LUNs o de sistemas de ficheros que llamamos volúmenes, y en ambos casos es algo que llevamos haciendo varios años como una funcionalidad incluida en todos nuestros sistemas de almacenamiento FAS.

Ahora bien, el que la funcionalidad sea gratis, no quiere decir que hacer thin-provisioning sea gratuito. Básicamente, estamos añadiendo cierta incertidumbre al servicio que presta esa LUN y en especial a su disponibilidad, ya que puede que en algún momento no tengamos espacio en la cabina para almacenar los datos de esa LUN. En la parte II veremos estas implicaciones y alguna forma de atajarlas.

Un ejemplo con la línea de comandos de nuestro equipo de como controlar el thin-provisioning de una LUN, una propiedad que podemos activar o desactivar para cada LUN de forma individual:

# Creamos una LUN

> lun create -s 2g -t linux /vol/test/lun0
> df -h test
Filesystem               total       used      avail capacity  Mounted on
/vol/test/                10GB     2052MB     8187MB      20%  /vol/test/

# Consume 2GB del volumen que la contiene

# Le quitamos la reserva de espacio, para que sea  "thin-provisioned"

> lun set reservation /vol/test/lun0 disable
> lun show -v /vol/test/lun0
        /vol/test/lun0                 2g (2147483648)    (r/w, online)
                Serial#: C4ifmJMYpfja
                Share: none
                Space Reservation:
disabled
                Multiprotocol Type: linux

> df -h

Filesystem               total       used      avail capacity  Mounted on
/vol/test/                10GB      128KB    10239MB       0%  /vol/test/

Tras quitar la reserva de espacio, la LUN solo consume unos pocos KB, por que todavía no tiene datos. Conforme se almacenen datos se irá consumiendo espacio del volumen hasta un máximo de 2GB que es el tamaño de ese disco virtual, tal y como lo ve el servidor cliente.

Desde el interfaz web es incluso más sencillo, puesto que lo único que hay que hacer es quitar la reserva de espacio en el momento de crear la LUN tal y como podemos ver en la siguiente imagen, o modificar este valor a posteriori:

Thinp 

Con una operación tan sencilla como esta podemos hacer que un volumen de 10GB como el del ejemplo contenga decenas de LUNs de 2GB para otros tantos servidores clientes. Cada servidor cliente tendrá la “ilusión” de ver una LUN completa de 2GB, pero en la cabina solo tendremos disponible (y consumiremos) 10GB para todos.

© NetApp, Inc.  |  "Safe Harbor" Statement  |  Privacy Policy