NetApp - El blog de Jamarmu

Imagine Virtually Anything

Esta semana hemos tenido una sesión doble de colaboración con nuestros colegas de Cisco.

Por un lado, acaba de terminar el evento Networkers at Cisco Live!, donde hemos participado con un stand en el que hemos podido contar nuestras soluciones de almacenamiento unificado a los visitantes y  constatar el creciente interés por redes de almacemiento convergentes,es decir, aquéllas que utilizan las redes de comunicaciones Ethernet, ya sea mediante protocolos que permiten el acceso al almacenamiento por IP (iSCSI, NFS o CIFS) o el más novedoso FCoE.


Por otro lado, el pasado día 26, VMware, Cisco y NetApp hemos anunciado un acuerdo de colaboración, ingeniería y soporte conjuntos que permite a nuestros clientes desplegar infraestructuras dinámicas en sus centros de procesos de datos. Más información aquí:

www.imaginevirtuallyanything.com

Como parte del anuncio hemos publicado un whitepaper conjunto en el que se detalla una configuración (Design Guide - Cisco Validated Design) de lo que en inglés llamamos Secure Multitenancy Infraestructure y que yo traduzco como una infraestructura multi-cliente (o multi-servicio) segura; éste es el enlace al documento en cuestión:

Designing Secure Multi-Tenancy into Virtualized Data Centers

Si revisáis el documento, cosa que recomiendo por que es muy interesante como ejemplo de arquitectura virtualizada, podéis ver cómo se plantea una infraestrucutra que utiliza VMware como hypervisor, la nueva plataforma de computación de Cisco (UCS), la tecnología de red Nexus de Cisco y nuestras cabinas de almacenamiento FAS.

Centrándome en la parte de almacenamiento y la conectividad al mismo, vemos que el diseño utiliza la tecnología de tarjetas CNA (Converged Network Adapters) que incorpora UCS, y que permite que con sólo dos cables desde cada servidor se pueda tener todo tipo de conectividad (FC, NFS, CIFS, iSCSI y por supuesto cualquier otra comunicación IP que forme parte del servicio de ese servidor). Esto simplifica en gran medida la conectividad en el lado de los servidores y es una de las ventajas de la tecnología UCS.

En nuestro lado, el del almacenamiento, nuestras cabinas hace ya mucho tiempo que permiten el acceso multiprotocolo (SAN y NAS) en el mismo dispositivo, y desde hace más de un año tenemos también disponible FCoE.

En este caso se ha optado por presentar el almacenamiento de las máquinas virtuales mediante el protocolo NFS utilizando las conexiones de 10GbE que hay en todos los extremos. NFS permite disponer de servicios de almacenamiento más flexibles y fáciles de usar; por ejemplo se pueden redimensionar los sistemas de ficheros, tanto para crecer como para decrecer, en caliente, sin riesgos y con un solo comando; se pueden utilizar repositorios de varios TB con decenas o centenas de máquinas virtuales sin problemas de rendimiento o escalabilidad; etc. Gracias a la infraestructura de 10 GbE el rendimiento, que en algunos casos era el interrogante que pesaba sobre NFS para este tipo de entornos, deja de ser una incógnita.

Por último, la arquitectura es novedosa por que permite desplegar servicios independientes de forma segura y aislada entre ellos, utilizando vShield, VLANs y nuestro MultiStore. Esto permite compartir de forma más segura la misma infraestructura hardware y software para diferentes servicios, departamentos o clientes.

Os pego el diagrama lógico de la solución como referencia:

Overbooking y thin-provisioning

Tras mi presentación en nuestro evento anual NetApp Innovation varios me habéis pedido explicar o repetir un ejemplo que puse sobre el thin-provisioning en los servicios de almacenamiento.

La idea es comparar el overbooking de las compañías aéreas con el thin-provisioning que realizamos en los sistemas de almacenamiento, y en este caso, usado junto a la deduplicación para poder mantener los ahorros de forma permanente.

En principio la analogía es clara, con el overbooking las compañías venden más billetes que asientos tienen en un avión. Con el thin-provisioning nosotros estamos mostrando más GB de información de los que podemos almacenar en la cabina. Para ayudarme a la descripción, en mi presentación utilicé la siguiente foto del sistema de reservas de un avión:

El overbooking o thin-provisioning consiste en vender 60 billetes, cuando es evidente que solo podemos sentar a 40 pasajeros. Esto podemos hacerlo (es lo que hacen las compañías aéreas) si sabemos que por la naturaleza de ese servicio es difícil que llegen 40 o más pasajeros a la vez. Curisosamente eso tambien pasa en el mundo de los discos ... en muchas ocasiones sabemos que en determinado entorno los discos nunca se van a utilizar completamente o no durante los primeros meses del sistema.

Para ayudarnos a mejorar la utilidad de este thin-provisioning, la deduplicación nos permite mantener ahorros permanentes y seguir presentando más espacio del que tenemos (o gastamos). Esto afortunadamente no lo pueden hacer las compañías aéreas, pero en mi presentación comparé el proceso de deduplicación con llevar a determinados pasajeros a la bodega de carga del avión, donde tenemos mucho más espacio.

La idea sería mover los pasajeros (o datos) redundantes a la bodega del avión. Con los datos es fácil, deduplicamos los bloques de 4KB que estén repetidos; con los pasajeros sería más complicado, pensemos por ejemplo que solo dejamos sentado al primer miembro de cada familia, quedando algo como la siguiente imagen:

Y esto nos permite, que donde tengamos datos duplicados (o con pasajeros que viajen con su familia) podamos tener de forma permanente un servicio mayor (más GB o más asientos) del que tenemos físicamente (en la cabina de discos o del avión).

Uno de los peligros del overbooking es llegar al mostrador de facturación y encontrarte con la desagradable sorpresa de que no tienes asiento por que el avión esté lleno. Esto también nos puede pasar haciendo thin-provisioning con discos, por lo que es importante monitorizar el espacio disponible y sobre todo aplicar el thin-provisioning donde tiene sentido (por ejemplo donde los datos son muy deduplicables o donde hay mucho espacio vacío).

En el ejemplo del avión podemos pensar en que en determinadas clases (business y primera) no vendamos más billetes que asientos, lo mismo que haremos en la cabina con determinados servicios, aplicando thin-provisioning solo donde podamos asumir ese riesgo.

 Pensando en sistemas de almacenamiento, muchos servicios productivos tendrán su espacio reservado (sin thin-provisioning), aquellos en los que podamos deduplicar (como los entornos de servidores virtuales) o cualquier entorno de desarrollo y test podrán tener thin-provisioning.

En nuestras cabinas no hay bodega para los datos duplicados, pero si que hay que tener ciertas consideraciones a la hora de planificar entornos con deduplicación, como el espacio para el fichero de índices, el momento en el que se lanzará el proceso de deduplicación y los posibles impactos en rendimiento.

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

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.

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:

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. 

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.

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.

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.

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.

 

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.