Se está poniendo de moda usar NFS para albergar nuestras VMs con VMware. La principal desventaja que suelen esgrimir sus detractores es que no puedes usar Virtual Consolidated Backup (VCB).
Aqui tenemos un metodo para poder hacer Backup tanto de los VMDKS(image level) como de los ficheros que estén en los discos duros de nuestros servidores virtuales (ficheros dentro de los vmdk para entendernos) (llamado file level). Con este metodo tambien se puede hacer Restore, incluso provisionning:
El metodo consiste en utilizar un servidor de backup Linux con la distribucion a la que más acostumbrados estemos y montar el volumen NFS o un snapshot del mismo (via cabina, de NetApp, IBM o EMC).
Una vez que nuestro servidor de backup Linux tiene acceso al volumen NFS o a un snapshot del mismo, tendremos que instalar en el Linux, si queremos realizar backup o restore de VMs windows, el soporte de NTFS (si es que no viene instalado, que la mayoria de veces viene).
Lo siguiente es montar el export de NFS en el servidor:
# mount direccion_IP_de_la Cabina:/vol/nfs_de_pruebas /mnt/vm_nfs
Ahora mismo ya podriamos hacer backup de los ficheros VMDK (Image Level Backup) . En NetApp se puede encontrar los snapshots en el directorio .snapshot.
El siguiente paso es realizar backup de los ficheros que queramos que estan dentro de los VMDKs(File Level Backup). Para ello montamos el VMDK en el que estén los archivos que nos interesen.
En el caso de que queramos montar un VMDK de una VM Windows, (es decir el VMDK está formateado en NTFS):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(NTFS), que el acceso es de sólo lectura(dado que es un VMDK de NTFS), el offset del disco y el dispositivo loop.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_windows-flat.vmdk /mnt/disco_vmdk_con_NTFS -o ro,loop=/dev/loop2,offset=32256 -t ntfs
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_NTFS
¿Cómo sabemos el offset?
Pues bien , en nuestra maquina virtual Windows (de la cual queremos hacer algunos file level backups), ejecutaremos msinfo32.exe, luego vamos a Components, a Storage y a Disks.
Anotamos el Partition Starting Offset(Desplazamiento Incial de Particion) y lo ponemos en el comando mount antes descrito.
Se necesita especificar cada offset de cada particion para montarlas. Por ejemplo si tensmos un VMDK formateado en NTFS que tiene dentro la unidad C: y D: . Anotaremos los offsets de ambas particiones y usaremos dos comandos mount para montarlas.
En el caso de que queramos montar un VMDK de una VM Linux, (es decir el VMDK está formateado en ext3 o ext2):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(ext3), que el acceso es de lectura/escritura(dado que es un VMDK de ext3), el offset del disco y el dispositivo loop.
Es muy importante saber que para montar un VMDK que tenga ext3 o ext2 debajo es NECESARIO que el volumen en el que está sea de acceso r/w. Por ejemplo con un snapshot de NetApp, no nos valdría, tendría que ser un FlexClone.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_linux-flat.vmdk /mnt/disco_vmdk_con_EXT3 -o loop,offset=32256 -t ext3
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_EXT3
¿Cómo sabemos el offset?
Podemos usar fdisk -lu en nuestra maquina virtual Linux (de la cual queremos hacer algunos file level backups) para tener el starting sector de cada partition.
Multiplicando este valor por 512 bytes tendremos el valor del offset en bytes que lo colocaremos en la opcion del mount.
En el comando mount especificamos que el FS es ext3. Podemos ver el tipo de FS que es con #df -T
En el caso de una VM linux, existe un caso más: Que se use LVM:
Para montar las particiones no valdrá el metodo anterior. Deberemos usar un FlexClone(un snapshot de lectura/escritura) como en el caso de ext2 ó 3 y usar los comandos:
#mount direccion_IP_de_la Cabina:/vol/vmnfsXXXbk /mnt/vm_nfs
#losetup /dev/loop0 /mnt/vm_nfs/SERVIDORWEB/SERVIDORWEB-flat.vmdk
#kpartx -av /dev/loop0
#vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
#vgchange -ay VolGroup00
2 logical volume(s) in volume group "VolGroup00" now active
#lvs
LogVol00 VolGroup00 -wi-a- 10.0G
LogVol01 VolGroup00 -wi-a- 10.0G
#mount /dev/VolGroup00/LogVol00 /mnt/disco_vmdk_con_LVM
Espero que os resulte útil!
Mostrando las entradas con la etiqueta NFS. Mostrar todas las entradas
Mostrando las entradas con la etiqueta NFS. Mostrar todas las entradas
viernes, 11 de julio de 2008
martes, 6 de mayo de 2008
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:
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:
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.
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....
miércoles, 30 de abril de 2008
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.
¿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":
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.
viernes, 11 de abril de 2008
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:
- Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name
]. - Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
- 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
] - 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.
Suscribirse a:
Entradas (Atom)
Entradas
