cache

vFlash Deepdive

Que tal gente, continuando con los artículos sobre lo nuevo que nos trajo VMworld (muchas cosas además de vSphere) es turno de meternos de lleno a lo que nos ofrece VMware con vFlash. Esta nueva funcionalidad nos permite acelerar operaciones de lectura a nivel de VMDK de máquina virtual, por lo cual dependiendo del caso de uso y tipo de aplicación puede ser de bastante interesante.

Debemos comenzar por definir algunos términos que estaremos manejando en el articulo:

  • Memoria Flash – este tipo de memoria no es volátil (a diferencia de la memoria RAM) y es de tipo electrónica por lo que no maneja ninguna parte móvil se tienen dos tipos principales de memoria flash, NOR y NAND siendo la última la mas común y utilizada ampliamente hoy en día.
  • SSDs – Tomando un fragmento de mi articulo “vSAN Deepdive” :

    “Solid State Drive”, este tipo de disco a diferencia del tradicional o mecánico no tiene partes móviles lo que permite tener tiempos de acceso mucho mas rápidos y menor latencia. Si lo comparamos con una memoria USB estos dos comparten algo en común, el hecho que ambos almacenan información en memoria flash, claramente los discos de estado solido tienen una estructura semejante a un disco tradicional y son mucho mas sofisticados que una simple memoria USB. La  cantidad de IOPS en un SSD se encuentra en el orden de los miles y a diferencia de un disco mecánico estos son mucho mejores en operaciones de lectura que en escritura, esto debido a que no se puede sobre escribir información sin que se ejecute un proceso llamado “garbage collection” lo que permite la escritura en esa ubicación cosa que no sucede en un disco mecánico de cualquier manera generalmente tienen mejor rendimiento que los discos mecánicos. Existen distintos tipos de SSDs, tenemos SSDs con interfaz SATA, SAS o tarjetas PCIe que contienen SSD o memoria Flash para poder acelerar operaciones de I/O a nivel del servidor. Cabe destacar que este pequeño intro a los SSDs no es tantito la vista completa de como trabaja un SSD, recuerden investigar mas sobre el tema.

  • Cache –el cache es memoria designada específicamente para la aceleración y almacenamiento temporal de operaciones de I/O, puede ser memoria RAM o disco (SSD) (hablando de operaciones a nivel de almacenamiento, claramente el término cache tiene distintos usos), en el caso de vFlash nos apoya a poder acelerar operaciones de lectura unicamente, esto debido a que se trata de cache “write through” por lo que no puede reducir los tiempos de respuesta en escritura como lo haría el cache de tipo “writeback”. vFlash en el espacio designado almacena los bloques de información que son accedidos con mayor intensidad, permitiendo así servir a las operaciones de lectura desde cache lo cual evita una consulta de estos bloques en el almacenamiento o backend (donde se encuentran los discos). Para tener una mejor idea de como trabaja el cache a nivel de almacenamiento (desde una perspectiva general y no especifica para algún fabricante) les recomiendo leer mi articulo “EMCISA – Intelligent Storage System”.
  • VFFS se trata de un sistema de archivos que deriva del afamado VMFS, en este caso VFFS esta pensado para agrupar todos los discos de estado solido SSD como una única entidad o grupo de recursos y optimizado para poder trabajar con este tipo de disco.

¿Que es vFlash?

Lo se, bastantes términos e introducción pero debemos sentar las bases para poder platicar de manera mas profunda sobre la funcionalidad… vFlash es una solución 100% basada en el hipervisor, es decir, existe como parte del core del hipervisor (ESXi) por lo que no depende de ningún appliance virtual u otro enfoque, nos permite acelerar operaciones de lecturas a nivel de VMDK de VM a través de SSDs locales que hacen las veces de cache y sin necesidad que estos sean exactamente iguales en cuanto a modelo, tamaños y demás. El administrador de la infraestructura deberá configurar el pool de recursos de vFlash (que estará construyendo el sistema de archivos VFFS) a partir de discos de estado solido conectados directamente a los servidores ESXi, esto lo podemos notar en la siguiente imagen:

SSDVFFS Aquí podemos notar que en mi laboratorio seleccione un SSD de 55GB (en realidad son 60GB) para ser formar parte de VFFS, una vez que dejamos listo el o los distintos discos de estado solido que conformaran nuestro pool de recursos solo es cuestión de repartir de manera individual este espacio disponible para cada VMDK de VM, es importante saber que nosotros tenemos la opción incluso de solo acelerar un disco de una VM que tenga mas discos o VMDKs esto nos da la posibilidad de tener un control mucho mas granular en la entrega de este cache basándonos en el perfil de I/O que presenta nuestras VMs. Una herramienta que nos puede ayudar en poder conocer que perfil de I/O manejan nuestras VMs es el ya confiable y ampliamente utilzado vscsiStats donde podemos conocer todo tipo de información como el tamaño de operaciones, latencia,entre otras, aquí les dejo algunos artículos de mi blog donde pueden leer mas sobre vscsiStats:

VCAP – Sección 3 – utilizar herramientas avanzadas para el monitoreo de performance

VCAP – Sección 6 – Troubleshooting de almacenamiento

Paso-a-paso – vscsiStats

Es importante conocer el patrón de I/O que presentan nuestras VMs debido a que en la configuración de vFlash a nivel de VDMK definiremos tamaño del cache y bloque del mismo (lo mejor es que sea el mismo que el utilizado por la aplicación/servicio):

vFlashconf

En cuanto a requerimientos para poder habilitar este cache a nivel del VMDK de nuestras VMs solo tenemos los siguientes:

  • VM compatibility (Hardware virtual) versión 10
  • SSD local en el host ESXi

La configuración de esta funcionalidad es únicamente a través del vSphere Web client, al igual que todas las funcionalidades nuevas que se han ido agregando a vSphere solo están y estarán disponibles desde el cliente basado en web. Una vez configurado el cache este es transparente para la VM pero tiene ciertas consideraciones de diseño que estaremos revisando más adelante.

Arquitectura

vFlash introdujo algunos nuevos componentes a ESXi y de igual manera al stack de I/O de la VM (solo en caso del VMDK que esta habilitado con vFlash) se tienen dos componentes nuevos:

  • vFlash infrastructure – aquí tenemos la librería (vFlashlib) con la cual trabaja el vmx para poder interactuar con el cache, de igual manera se encuentra un módulo de hipervisor interesante llamado FDS (File System Switch)  que esta colocado entre el adaptador vSCSI de la VM y el módulo de cache del hipervisor que permite la abstracción de los distintos SSDs que constituyen el pool de recursos de tal manera que se tiene una interacción común aún teniendo distintos dispositivos y por último tenemos el sistema de archivos VFFS como parte de este “vFlash infrastructure”
  • vFlash cache module – módulo del hipervisor encargado de manejar el cache y la interacción con el VFFS, este cache es transparente para VMs y aplicaciones.

El flujo  de información se vería mas o menos de esta manera:

flujovflashCada vez que se enciende una VM se crea su cache, es decir, este no es persistente a reincios y demás, vFlashlib lo crea una vez que el proceso de VM (VMM) comienza, el pool de recursos que a su vez construye el sistema de archivos VFFS es un sistema de archivos que existe a todo momento e incluso tiene un punto de montaje en /vmfs/devices/vflash/.

Interoperabilidad

En el momento que consideramos integrar vFlash en nuestros diseños de infraestructura la primera pregunta sería ¿Como afecta y/o como trabaja con otras funcionalidades como HA, vMotion,DRS, etc?, vamos a revisar cada una de las funcionalidades mas relevantes de vSphere:

  • vMotion, Storage vMotion y XvMotion (enhanced vMotion) todas estas operaciones son soportadas, nosotros como administradores decidiremos si es que queremos migrar el cache o recrearlo en el host destino, para el caso en especifico de Storage vMotion no tiene impacto esto debido a que no migramos de host. Claramente la decisión de migrar o no el cache impactara en la carga que se tendrá a nivel de red y el tiempo de migración debido a que se deberá copiar el cache en uso y si tomamos la decisión de migrar la VM sin su cache se tendrá un impacto en el rendimiento debido a que el cache será reconstruido con el tiempo (se deberá esperar tiempo para que se tenga información “caliente” en el cache”. Podemos ver en la imagen la migración con vFlash activado:

opcionesmigracionvflash

  • HA claramente en el momento de tener un evento de failover al reiniciarse de manera forzosa la VM en otro servidor del cluster el cache no viaja con ella y deberá ser reconstruido. Acá entra una decisión importante en cuanto a diseño se refiere y es el control de admisión, es decir, si tenemos nuestros SSDs 100% utilizados en cada host o no existen recursos suficientes de vFlash en el momento de requerir un reinicio de VM por un evento de HA esta simplemente no se reiniciará en otro host, por lo que debemos considerar cierto espacio libre en nuestros SSDs para eventos de HA.
  • DRS – DRS funciona sin ningún problema con vFlash, en este caso estará ocupado XvMotion para migrar la VM y copiar a la vez el cache. Aquí entramos a una consideración de diseño similar al caso de HA, y básicamente es que DRS al estar realizando el análisis del cluster para poder determinar recomendaciones y así realizar migraciones para el balanceo del cluster (dependiendo claramente de el nivel de automatización) sino encuentra los recursos suficientes de manera “continua” o en un mismo host (no fragmentados entre todo el cluster las VMs no serán candidatas a poderse migrar ya que no se puede satisfacer la cantidad de vFlash entregado.

Consideraciones extra

Acá podemos encontrar algunas consideraciones y limites de vFlash en esta versión:

  • El tamaño máximo de SSD soportado es de 4TB
  • Se soportan hasta 8 SSDs por VFFS lo cual nos da un total de 32TB para VFFS
  • Solo se soporta un VFFS por host ESXi
  • Se tiene un máximo de 400GB de cache por VM con un tamaño mínimo de bloque de 1KB hasta 1024KB
  • No se soporta SSDs compartidos (solo una partición)
  • No se soporta SSDs remotos
  • No se soporta FT
  • No se puede compartir un SSD entre vSAN y vFlash

Casos de uso

Podemos ver que esta versión inicial de vFlash puede cubrir ciertos requerimientos de aplicaciones, en general aplicaciones con muchas lecturas. vFlash nos permite agregar mayor cantidad de aplicaciones críticas, pero un caso de uso que a mi me llama mucho la atención es VDI, y ¿Porque VDI? pues es simple, podemos descargar bastantes operaciones de I/O (lecturas) del almacenamiento y que estas sean servidas a partir del mismo SSD local (mejorando drásticamente el rendimiento de dichas operaciones) esto se vería bastante claro en la carga que recibe la replica si estuviéramos hablando de horizon view.  En este punto Horizon View 5.2 no esta soportado para  vFlash, aunque técnicamente no tendría problema para funcionar esto no será soportado oficialmente por servicios de soporte VMware (Global Support Services, GSS).

Conclusión

vFlash nos permite reducir la carga a nivel de nuestro almacenamiento centralizado (sería bueno incluso hablar de vSAN :D) a través de disco “barato” porque al final del día es mas costoso adquirir mayor cantidad de IOPS a nivel de una SAN/NAS que entregándolos a partir de disco SSD local. Existen distintas soluciones allá afuera que ofrecen este tipo de funcionalidades con otras ventajas, como por ejemplo, PernixData FVP y Proximal Data AutoCache

Estén atentos a mis siguientes artículos, donde estaré cubriendo el monitoreo de vFlash, a través de linea de comando y de los distintos indicadores de rendimiento que fueron agregados a nivel de vCenter.

De igual manera les recomiendo leer los links que estaré actualizando en este articulo sobre vFlash:

FAQs por Duncan Epping (Yellow Bricks) Frequently asked questions about vSphere Flash Read Cache

EMCISA – Intelligent Storage System

Que tal gente, el día de hoy vamos a continuar con otro punto del temario de la certificación EMCISA v2, es momento de hablar de los componentes y características que conforman un sistema de almacenamiento inteligente.

En el articulo pasado platicamos sobre lo que es un RAID, sus tipos y las ventajas que nos ofrecen, pero debe de quedar claro que un simple RAID no cubre las necesidades en cuanto a I/O y alta disponibilidad de los datos se refiere. Los sistemas de almacenamiento inteligentes incluyen tecnologías para el manejo de los datos o la manera que llegan estos datos al sistema de una manera optimizada, aprovechando distintos caminos o “paths” hacia el mismo almacenamiento; de igual manera estos integran “cache” en forma de memoría DRAM esto para poder almacenar de manera temporal aquella información que es altamente requerida con lo que se logra que cada vez que se requiera un acceso a dicha información esta sea servida a partir de esta memoria o “cache” obteniendo una latencia menor y acelerando las operaciones de I/O.
Claramente no solo estaremos hablando de cache y optimización de paths, si no estaremos conociendo distintos métodos y tecnologías que nos permiten tener un manejo y acceso a la información optimizado.

¿Cuales son los componentes de un sistema de almacenamiento inteligente?

Se tienen 4 componentes principales en un almacenamiento inteligente (claramente no es la totalidad de componentes), “frontend”, cache backend y discos.

Almacenamientointeligente

Revisemos cual es el rol de cada uno de estos componentes en el procesamiento y manejo de la información:

  • Front End – este componente se encarga de manejar la interacción directa con el host que esta pidiendo acceso de cualquier tipo a la información, sea lectura o escritura. Generalmente consiste de dos o mas controladoras que a su vez tienen múltiples puertos para poder permitir la conexión de muchos servidores a la vez. La controladora es la encargada de manejar el protocolo utilizado en la comunicación, por ejemplo, iSCSI, FC, FCoE, NFS, etc; esta controladora se comunica con el cache mediante un bus de información interno, a través del cual envía escrituras y lecturas, una vez que el cache da acceso a la información (sea entregándola a partir de su memoria o acceso directo al backend) se envía un “acknowledge” o se reconoce que la operación ha sido satisfactoria.
  • Cache – el cache generalmente esta compuesto por memoria DRAM, aunque almacenamientos avanzados pueden llegar a combinar distintos niveles o “tiers” de cache, por ejemplo, DRAM, SSD, etc Este componente es critico para poder acelerar las operaciones a nivel de almacenamiento, esto se logra almacenando aquella información “caliente” o que ha mostrado una actividad (I/O) alta en la memoria propia de este cache para que los servidores que tienen acceso al sistema de almacenamiento reciban dicha información a partir de este cache y así prevenir el acceso a los discos duros mecánicos que tienen un tiempo de acceso mucho mayor a este cache hablando de tiempos en ms (de seek time) en el caso de los discos duros cuando DRAM esta por debajo del ms.El cache esta constituido por dos componentes principales “data store” y “tag ram”, donde la función del “data store” es básicamente almacenar la información en unidades llamadas “páginas” mientras que la función de “tag ram” es la darle seguimiento o saber donde se encuentra la información para poder utilizarla (parecido a lo que es un metadata), de igual manera identificar que información ha sido enviada a disco a través de un indicador “dirty bit” y por último mantener los tiempos de acceso a dicha información para poder ir determinando que información debe estar en el cache (basándose en las políticas definidas para el cache, que estaremos viendo mas adelante)Es importante saber que en el momento que un servidor pide información al sistema de almacenamiento se busca dicha información en el “tag ram” para determinar si será servida o no desde cache, en el caso que esta sea servida desde cache se le conoce como un “Read Hit”, si la información no se encuentra en cache esta tendrá que ser servida a partir de los discos en el backend y esto es conocido como “Read Miss”. En el momento que se detecta un acceso secuencial puede darse que el sistema de almacenamiento cuente con la tecnología de prefetch (este puede ser de tamaño fijo o variable) o “read ahead” a partir de la cual se definirá un conjunto de bloques o información secuencial a la información que se esta accediendo para ser transferido de los discos hacia el cache para que en el caso que el host los requiera se pueda acelerar el acceso a esta información. A mayor Read Hits mejor rendimiento se tendrá en las operaciones de lectura hacia nuestro sistema de almacenamiento.El cache no solo optimiza las operaciones de lectura, tenemos dos distintos modos de cache para las operaciones de escritura, “write-back cache” y “write-through cache” donde el primero permite tener tiempos de respuesta mas rápidos debido a que en el momento que llega una operación de escritura esta es almacenada en el cache e inmediatamente se envia un “acknowledge” o se reconoce que dicha operación de escritura ya fue realizada y mas adelante es escrita a disco o “de-staged” el segundo modo de escritura con cache o write-through cache recibe la escritura la almacena temporalmente en memoria y la escribe inmediatamente a disco después de esto por lo que el “acknowledge” o reconocimiento que la operación sucedió tiene una latencia mayor. Las operaciones que son almacenadas en ambos modos de cache será determinada por el tamaño máximo de I/O  configurado a través del cual se decide si este estará siendo almacenada en cache o enviada directamente a disco.Claramente la cantidad de cache en cualquier sistema de almacenamiento inteligente es mucho menor de el espacio disponible en disco, por lo que el cache debe de ser utilizado de manera óptima y solo almacenar la información que “merece” o debe de estar ahí para poder optimizar las operaciones de I/O, para esto se cuentan con distintos algoritmos que evitan la saturación de este componente y permite manejar los ciclos de vida de información según el uso que esta presentando, se manejan los siguientes algoritmos:Least Recently Used (LRU) – Este algoritmo se encuentra constantemente monitoreando el último acceso a la información identificando paginas almacenadas en cache que no han sido utilizadas por mucho tiempo, en el momento que dichas páginas son identificadas se marcan para ser reutilzadas o en el caso de que estas contengan información de escritura que no ha sido enviada a disco (ej. write-back cache) esta es primero enviada a disco para después marcar dichas páginas para reutilizarse.Most Recently Used (MRU) – Este algoritmo es exactamente lo opuesto a LRU, básicamente se definen las páginas del cache que han sido utilizadas recientemente tomando como premisa que debido que la información fue accedida hace poco tiempo esta no será requerida pronto.

    Independientemente de el algoritmo para mantener almacenada o no la información en cache se requiere definir en que puntos de utilización (espacio de cache consumido) se deberá realizar un “flush”  de toda aquella información que se encuentra en cache y no ha sido escrita a disco para poder gestionar el espacio disponible en cache y no saturarlo. Basadandose en la cantidad de espacio consumido del cache se definirá el ritmo de flush o escritura de información a partir del cache a disco, se tienen 3 estados, “High Watermark”, “Idle flushing” y “Forced Flushing”
    Flushes El flush de tipo “idle” sucede a un ritmo moderado debido a que esta por debajo o en el nivel de utilización marcado como “Low Watermark”, el Flush de tipo High Watermark sucede a un ritmo mas rápido debido a que ya se superó o se encuentra en uso la cantidad de páginas de cache marcadas como “High Watermark” y para el último tipo de flush que es llamado “Forced Flushing” básicamente el cache ha llegado a un 100% de consumo de espacio por lo que se requiere un ritmo de escritura de la información en cache hacia el disco muy rápida, a mayor ritmo de escritura el sistema de almacenamiento dedica mayor cantidad de recursos para poder cumplir con el ritmo.

    Algo que pueden estar pensando en este momento es, “Esta bastante interesante todo este tema de cache, su funcionamiento, etc, ¿Pero acaso no tenemos información en el cache que no ha sido escrita o flushed a discos? ¿Que hay de la protección para el cache y/o la información que vive en el?” y esto es justamente lo que estaremos comentando a continuación, debemos de considerar que al tratarse de manejo de información siempre debemos de tener en mente nuestros SPOFs o “Singe Points of Failure” por lo que se manejan dos principales métodos para proteger aquella información que continua en el cache y no ha sido escrita a disco, Cache Mirroring y Cache Vaulting.

    Cache Mirroring – Con este método básicamente lo que se esta realizando es tener una copia exacta de todas aquellas operaciones de I/O que son escrituras y que están viviendo en el cache (básicamente información que no ha sido escrita a disco) por lo que contamos con distintas unidades de memoría donde la información es copiada por si se da el caso de tener una falla en alguna de las unidades de memoria, esto lo podríamos ver como un nivel de RAID 1. Cabe destacar que en ambas copias se lleva un seguimiento puntual de la estructura y la información que vive en ellas debido a que debemos de contar con la misma información y que esta este integra, a este proceso se le conoce como “cache coherency”.

    Cache Vaulting – Este método logra proteger la información que vive en el cache a través de discos dedicados a almacenar la información que este activa en el cache, por lo que cuando se tiene un problema de energía eléctrica la información es copiada a estos discos dedicados como “vault” donde la información deja de ser volátil, en el momento que la energía eléctrica regresa esta información es copiada de nuevo al cache y es escrita a los discos donde debía de ser escrita en un principio.

  • Back End – Este componente de el sistema de almacenamiento inteligente sirve como interfaz de comunicación entre el cache y los discos físicos, en este  se encuentra los distintos algoritmos para permitir una configuración de RAID. El flujo de información sucede de la siguiente manera, una vez que la operación de escritura es enviada a escribirse a disco desde el cache, llega al backend donde puede ser almacenada por una breve ventana de tiempo para después ser ruteada hacia el o los discos donde debe de estar viviendo. En el backend también se cuenta con mecanismos para detectar errores y corregirlos además de los mecanismos para controlar el o los niveles de RAID, estas controladoras están conectadas a los discos a través de puertos que tiene cada controladora generalmente hablamos de dos o mas controladoras para brindar alta disponibilidad y múltiples paths de acceso a los discos físicos
  • Discos Físicos – básicamente aquí estamos hablando de discos como los conocemos, generalmente este tipo de sistemas de almacenamiento tienen soporte para distintos tipos de discos, desde SAS, SATA, EFD, FC, etc. Aquí es donde sucede todo la asignación y reservación de espacio según distintas políticas definidas donde podemos estar hablando de alta disponibilidad, rendimiento, capacidad, etc. este proceso es conocido como “storage provisioning” o asignación de almacenamiento.Para asignar espacio primero debemos segmentar o agrupar los discos físicos en grupos lógicos a los cuales se les asigna un nivel de RAID, a este grupo lógico se le conoce como RAID Set, dependiendo de la cantidad de discos y el tipo de los mismos (claramente tomando en cuenta el nivel de RAID aplicado) se contará con cierta cantidad de espacio utilizable, cierto rendimiento y disponibilidad de los datos.
    Provisioning
    Una vez creado el RAID Set este es particionado con lo que se crean las unidades lógicas que estarán siendo entregadas a los servidores que requieren acceso a disco, estas unidades se les conoce como LUNs o Logical Unit Number, a cada unidad se le asigna un número único. Estos LUNs son básicamente una porción de espacio del total con el que se cuenta en el RAID Set, los sistemas de almacenamiento tradicionales entregan estos LUNs en formato “thick” o con asignación completa del espacio configurado, mientras que los sistemas de almacenamiento avanzados pueden entregar los LUNs en un modo “virtual” o “thin” en la imagen podemoslunthin notar que básicamente la entrega de almacenamiento en modo virtual o “thin” es presentar al servidor que requiere acceso a espacio en disco un LUN que desde la perspectiva del Sistema Operativo es reconocido como el espacio en su totalidad (en este ejemplo 80GB) pero en el sistema de almacenamiento solo estará ocupando aquel espacio que haya sido escrito a dicho LUN, la ventaja de este método de asignación es que podemos contar con “overcommitment” o asignar mayor cantidad de espacio en disco de la cual tenemos en realidad en nuestro sistema de almacenamiento (existen múltiples consideraciones al entregar LUNs en thin Provision). Thin Provision permite entregar el espacio bajo demanda y no asignar desde el inicio la totalidad de el espacio.

    Algunas de las consideraciones que debemos tener en el momento de decidir si estaremos asignando el espacio de manera tradicional o “thick” o lo estaremos haciendo a través de Thin Provision o “virtual” son:

    1. Si la aplicación requiere un rendimiento esperado lo mas recomendable es Thick provision.
    2. Contamos con aplicaciones o servicios con información que es modificada constantemente o que incrementa de manera sustancial, para esto de igual manera se recomienda thick provision.
    3. Se tiene aplicaciones o servicios que no cambiarán su información de manera constante, no escribirán a disco o básicamente tienen contenido estático, para esto podemos utilizar thin provision

    Claramente estas no son todas las consideraciones que existen pero es un claro ejemplo que debemos planear que tipo de LUNs estaremos asignando según los requerimientos que se presenten.

    Una vez que el espacio de un LUN fue definido contamos con distintos métodos para poder incrementar el espacio vamos a echarle un vistazo:
    MetaLUN – es la manera que tenemos para poder expander un LUN existente ya sea para darle mejor rendimiento o agregar espacio. Un MetaLUN básicamente es la construcción lógica a partir de dos o más LUNs, se tiene el LUN inicial que es llamado LUN Base y una o más LUNs componentes, una vez que agregamos una o mas LUNs como resultado tenemos un “MetaLUN” que nos brindará espacio extra o un rendimiento mayor. Se cuenta con dos métodos para crear un MetaLUN, concatenación de dos o más LUNs o stripe.

    METALUN En el caso de tener un MetaLUN debemos comprender que al concatenar 2 o mas LUNs no estaremos teniendo ninguna ganancia en cuanto a rendimiento se refiere ya que no se estará realizando un stripe de la información en la nueva LUN (recordemos que el proceso de Stripping es distribuir la los datos en varios discos, en este caso al referirnos de LUNs sería la distribución de la información en varios LUNs). Claramente cuando creamos un MetaLUN con stripping además de incrementar el espacio también estaremos beneficiándonos de un mejor rendimiento debido a que estaremos sirviendo la información de todos los discos que han sido asignados a cada uno de los LUNs que constituyen el MetaLUN.

    Para poder presentar los LUNs disponibles a nuestros servidores debemos definir que hosts tienen acceso a los LUNs, esto se le conoce como LUN Masking. En el momento de realizar LUN masking debemos definir los LUNs y los identificadores de los Hosts según el protocolo que estemos utilizando, ej. iSCSI, FC, etc. (IQNs para iSCSI, WWNs para FC). Esto es controlado del lado del sistema de almacenamiento, por lo que en el momento que un servidor quiere acceder al LUN se verificará si el identificador del servidor esta permitido para acceder y que tipo de permiso tiene (ej. escritura/lectura o solo lectura).

Tipos de almacenamientos inteligentes

Los sistemas de almacenamiento son clasificados en dos tipos, High-end y Midrange:

  • High-End Storage Systems – este tipo de sistemas están pensados para cargas altamente transaccionales y/o críticas, cuentan con múltiples controladoras en modo activo-activo para brindar acceso a los distintos LUNs, en este caso cualquier controladora permite acceso a los LUNs. Generalmente este tipo de almacenamientos ofrecen mayor cantidad de espacio, de cache, arquitecturas tolerantes a fallos, etc. Un ejemplo claro de este tipo de almacenamientos inteligentes es Symmetrix de EMC.
  • Midrange Storage Systems – este tipo de sistemas cuentan generalmente con dos controladoras en un esquema activo-pasivo, es decir, una controladora es dueña de ciertas LUNs, lo que quiere decir es que cualquier actividad de I/O debe de llegar a través de la controladora dueña de la LUN, mientras que la otra controladora permanece pasiva. En el caso de tener una falla en alguna controladora se puede dar un “trespassing” de la controladora fallida a la controladora que permanece funcional con esto dicha controladora se vuelve dueña de los LUNs que eran controlados por la otra controladora que falló. Un ejemplo de almacenamiento midrange es VNX de EMC.