Saltar al contenido

san

VAAI y VASA de VMWare

Hace ya algún tiempo que VMWare se decidió a desarrollar y mejorar las APIs de conexión con terceros y algunas de estas APIS son VAAI y VASA. Aunque no estamos hablando de un nuevo lanzamiento de la 6.5 (por ejemplo VAAI lleva entre nosotros desde la 4.1), no deja de sorprenderme que aún son desconocidas por gran número de personas.

¿Qué es VAAI?

VAAI (VMware vSphere API for Array Integration) es una API ofrecida por vSphere para integración con fabricantes de almacenamiento. Por decirlo de una manera sencilla (por favor, los puristas, no sigan leyendo 😉 ), esta API permite que vSphere sea consciente del almacenamiento que tiene por detrás y hable con el, no solo a través de los protocolos estándar como iSCSI, FC o FCoE.

En realidad VAAI es una parte de la API vStorage que engloba entre otras cosas:

  • vStorage API for Site Recovery Manager
  • vStorage API for Data Protection
  • vStorage API for Multipathing
  • vStorage API for Array Integration

 

<original de la imagen aquí>

¿Para que sirve VAAI?

Pues básicamente nos permite que operaciones que son muy costosas para el host, como por ejemplo hacer un snapshot de una VM, pedírselo directamente a nuestra cabina y que lo haga ella.

En operaciones de snapshot por ejemplo, se pueden obtener reducciones de un 20% en consumo de CPU (según VMWare).

Si acudimos a la página oficial de VMWare podemos leer:

The goal of VAAI is to help storage vendors provide hardware assistance to speed up VMware I/O operations that are more efficiently accomplished in the storage hardware.

Generalmente el fabricante del Storage suele suministrar un plugin para nuestro vCenter que nos permite implementar esta funcionalidad.

Podéis comprobar si vuestro almacenamiento soporta VAAI aquí.

¿Qué es VASA?

 

VASA es otra API, (en este caso VMware vSphere API for Storage Awareness) cuya finalidad es la de permitir integrar nuestro storage con el vCenter para funcionalidades de management. Es algo más nueva que VAAI, ya que se libero con la versión 5.

<imagen cortesía de VMWare>

¿Para que sirve VASA?

Se trata de ofrecer funcionalidades de management en el vCenter y las funcionalidades dependerán del fabricante. Por ejemplo una muestra podría ser:

  • Disk Type (SSD, SATA, SAS, FC)
  • Snap space reserved
  • Dedupe –
  • VV Type

Por tanto el vCenter accederá las funcionalidades VASA ofrecidas por nuestro storage, a través del “VASA Provider”.

Espero haber podido aclarar un poco mejor estos conceptos.

Jumbo Frames, ¿qué son y donde usarlas?

Diseñando con uno de nuestros clientes su nueva arquitectura de servidores/virtualización y almacenamiento, le han surgido una serie de dudas sobre el uso de Jumbo frames. En realidad es un tema, que aunque sencillo, no es muy conocido y es habitual ejemplos de uso (o no) inadecuado.

Un poco de teoría:

La mayoría de nuestras redes a nivel de CPD se construyen sobre los protocolos ethernet para L2 e IP para L3.

modelo OSI

 

el tamaño de trama por defecto para ethernet es de 1500bytes (fijaos que digo trama y no paquete. En ethernet lo que se transmiten son tramas de datos y en IP paquetes que a su vez se alojaran en las tramas ethernet). Este valor, que es modificable, es lo que convierte una trama ethernet normal en un Jumbo Frame cuando ampliamos su tamaño.

 

Es importante remarcar que las Jumbo Frames, están fuera del estándar 802.3 que define ethernet. El tamaño máximo es de 9.000Bytes

 

¿Debo usar Jumbo Frames en mi red?

Pues depende… activar el uso de Jumbo Frames reduce la carga de gestión de las tramas y paquetes (si paquetes ip también, luego veremos la razón) y puede mejorar el rendimiento a la hora de transferir grandes volúmenes de información, (por eso las SAN son escenarios donde usar Jumbo Frames), por contra aumentan la latencia de la red (especialmente en redes lentas).

En general se puede decir que el uso de Jumbo Frames mejora la eficiencia de nuestra red.

Eficiencia_Jumbo_Frames

<Fuente Wikipedia>

Lo que no debes hacer bajo ningún concepto es mezclar dispositivos con Jumbo Frames activos y otros desactivos, eso es una fuente potencial de problemas.

 

¿Entonces por qué no las usa todo el mundo?

Fundamentalmente porque no toda la electrónica de red (sobre todo la antigua) la soporta. El aumento de tamaño de trama reduce el nº de tramas a transmitir, pero al ser estas de mayor tamaño también se incrementa el esfuerzo necesario para calcular los CRC y esto puede tener un impacto importante en el rendimiento de nuestra red. También es necesario ampliar la cantidad de memoria asiganada a los buffers de los dispositivos de red.

Como comentaba unas lineas más arriba, no debemos mezclar dispositivos con y sin Jumbo Frame activo, esto limita su uso a redes donde nos podemos permitir que todos los dispositivos lo tengan activo. Un ejemplo de este tipo de redes serían las redes de almacenamiento SAN (iSCSI). Para otro tipo de redes el estándar sigue siendo 1500, después de todo no es casualidad que todos los S.O. vengan configurados con una MTU de 1500 (El que la MTU de S.O. y el tamaño de trama coincidan, aumentan la eficiencia del uso de la red).

 

¿Hay alguien pensando en tamaños distintos a las Jumbo Frames?

La respuesta es sí. Ya podemos encontrar al menos:

  • Baby Jumbo Frames: son más pequeñas que las Jumbo (en realidad solo un poco más grandes que las ethernet) y se usan en entornos de carrier encapsuladas en protocolos como MPLS.
  • Super Jumbo Frames: esto como imagináis va de grande, porque grande es mejor. 64.000Bytes

 

¿Tiene aplicación a la virtualización?

Por supuesto, ya os comentaba antes que las redes SAN basadas en iSCSI son un escenario claro para el uso de Jumbo Frames.

¿VMware soporta Jumbo Frames?

Si, os enseñare a configurarlo en un próximo artículo.

 

Recursos Virtual SAN de VMware para presentaciones

Soy un firme defensor del uso de herramientas audiovisuales a la hora de presentar conceptos más o menos complejos (como a menudo ocurre con lo referente a tecnología I.T.), porque creo que ayudan a “simplificar” conceptos a la hora de transmitirlos a un interlocutor, que no necesariamente comparte nuestros skills técnicos.

 

Recientemente y fruto de algunos de los proyectos en los que estamos involucrados y que se apoyan en tecnología Virtual SAN de VMware, me vi en la necesidad de seleccionar algunos recursos audiovisuales para apoyar mis presentaciones.

Espero que os resulten de utilidad:

 

[youtube=https://youtu.be/jS7Kiu8nHUE]

[youtube=https://youtu.be/pjU4EnG1mWc]

[youtube=https://youtu.be/MxLrM3erecE]

 

y un pequeño esquema con posibles casos de uso:

 

VMware-VSAN-use-cases-Tier-Two-Production

 

Todos los recursos e imágenes, son cortesía de VMware.

ViPR de EMC pasa a ser Software Libre

Una gran noticia (podéis ver el anuncio aquí) para el mundo del softwar libre y para todas aquellas personas que trabajamos y diseñamos entornos SDN.

 

ViPR es la solución orientada a SDN (Software Define) de EMC, para abstraer el HW que hay por debajo y permitir servir almacenamiento tanto bloque como ficheros.

logo_EMC_ViPR

 

<logo Vipr de EMC>

Si bien ya existen algunas alternativas en SL, no deja de ser una noticia muy importante que seguramente pondrá las cosas un poco más dificiles a alternativas como vSan de VMware.

 

El nuevo proyecto se llamará “Project CoprHD” y no implica el abandono de ViPR por parte de EMC, que seguirá desarrollando y soportando una versión comercial, que se dinamizará gracias a la aportación de la comunidad.

10396_ViPR-Controller-OpenSource-765x265<logo CoprHD>

 

Switching Fabric for Dummies

A raíz del artículo de ayer sobre el nuevo switch SDN de Facebook, en el que mencionaba que disponía de dos tarjetas Fabric (puedes leerlo aquí), he recibido algunas consultas preguntando que es un Fabric y como funciona, así que voy a tratar de explicarlo de manera sencilla (puristas este no es un ariculo para vosotros).

Bien, lo primero que hay que indicar es que Fabric es una palabra que está siendo usada de manera asidua por distintos fabricantes para referenciar a determinadas características avanzadas de sus dispositivos y que no siempre son comunes entre marcas.

 

En esencia un Fabric en una red está conformado por una serie de nodos (típicamente switches) y una inteligencia o control del Fabric (que puede estar alojada en los propios nodos o fuera de ellos) que se encargara de la gestión del Fabric.

¿Qué función realiza cada uno?

Los nodos, serán los encargados de mover los datos de un punto a otro. El control del Fabric será el encargado de elegir por ejemplo la ruta más óptima (en caso de tener múltiples caminos).

¿Y esto para que sirve?

Fundamentalmente permite mejorar la escalabilidad y el rendimiento de los elementos de networking, facilitando además su gestión. Por ejemplo en el caso de un Fabric típico sobre ethernet (podemos implementar Fabric sobre otros tipos de buses), el disponer de esa “inteligencia”, permite eliminar las limitaciones del SpanningTree en cuanto a gestión de múltiples caminos, permitiendo en cada caso la elección de la mejor ruta posible.

En el siguiente vídeo de Cisco podéis encontrar una pequeña explicación muy visual de como funciona el Fabric de sus Nexus.

 

¿Es algo innovador?

En realidad los que llevamos más tiempo en esto, ya manejábamos el concepto de Fabric sobre redes SAN, lo único que de  un tiempo a esta parte es cada vez más común verlo sobre otros tipos de redes y asociado a conceptos como convergencia (pronto os  prepararé un pequeño artículo sobre tecnologías convergentes en la red).

Spots, expectaculares (I): SAN Bulletproof

Después de una interesante conversación con un arquitecto de SAN acerca de las opciones en almacenamiento que hay en la actualidad con sus Pros y Contras, terminamos recordando un anuncio de la serie de cabinas Hitachi (customizadas por distintos fabricantes), en la cual la cabina recibía un disparo de gran calibre sin dejar de dar servicio.

El vídeo en cuestión gusto mucho en el mundillo, por lo que me he decidido a realizar una serie de artículos recogiendo aquellos anuncios o spots que me parecieron interesantes, ya sea por su creatividad, por suponer un gran avance o simplemente por resultarme divertidos.

Aquí os dejo el anuncio de esta SAN Bulletproof

Redes de almacenamiento (I) – Introducción a SAN

Articulo de nivel básico (aunque no lo parezca):

¿Qué es una SAN?: Una SAN (del ingles storage area network), es básicamente una red cuyo fin es conexionar almacenamiento disponible en uno o más dispositivos. Al tratarse de una red para un uso específico (aunque esto no es del todo cierto), usa protocolos específicos para la transmisión de la información (Fiber channel, frente a ethernet por ejemplo de las redes más comunes).

El dispositivo que tengo en casa y que me permite compartir un disco duro entre varios ordenadores windows (o incluso linux), ¿es una SAN ?: No, ese dispositivo es una NAS. La diferencia entre una NAS y una SAN (simplificando mucho), es que una NAS ofrece el almacenamiento a través de protocolos como el NFS, CIFS, (que serán los encargados de gestionar el acceso a la información) etc y que viajan generalmente sobre redes ethernet estándar. Una SAN ofrece el almacenamiento en RAW, realizándose el acceso a la información mediante comandos SCSi que se encapsulan en el protocolo FC antes de viajar por la red hasta los dispositivos. En cuanto a la red, normalmente en una SAN y sobre todo en entornos empresariales estará basada en switches y cables de fibra (en entornos mas modestos podemos encontrarlas sobre cobre e iSCSI).

¿Por que merece la pena usar un protocolo de nivel de bloques frente a uno más cómodo como NFS o CIFS?, pues muy sencillo, a igualdad de velocidad en los links de conexión a la red, la eficiencia en la transmisión de información de los protocolos de bloque como FC es mayor, lo cual se traduce en mayores anchos de banda.

Como cualquier protocolo de red FC, tiene su propia pila de protocolos estructurados en capas: FC-0, FC-1, FC-2, FC-3, FC-4 , donde cada uno de los niveles define una parte de como se comunican los dispositivos.

El protocolo FC usa 2 tipos de control de flujo (para manejar la congestión):

  • buffer-to-buffer
  • end-to-end

Es muy importante tener claro que aunque cuando pensamos en una SAN, lo hacemos generalmente en términos de comandos scsi sobre FC, realmente este protocolo puede encapsular otros (IP,ATM,etc).

En cuanto al medio que se usa para la transmisión de los datos (aunque pueden ser otros, incluso cobre), generalmente sera fibra óptica (monomodo o multimodo dependiendo de requerimientos como la distancia), que se conectaran a la SAN a rtavés de un switch. A un switch o o conjunto de switches interconectados (una vez más simplificando), los solemos llamar fabric.

La imagen siguiente corresponde a un switch de la compañía Brocade:

¿qué hacen los fabric por nosotros?: Los fabric ofrecen servicios a los nodos que se conectan a el:

  • Name Server: BBDD que guarda información sobre los dispositivos conectados al fabric y que contesta a las peticiones de información sobre direcciones.El Name Server esta siempre en una dirección bien conocida (FFFFFC)
  • Time Server: Sincronización horaria. Escucha en la dirección FFFFFB
  • Alias Server: Como su nombre indica, se encarga de manejar los alias.
  • Managemente Server: Es el punto de acceso único para la gestión del fabric y a su vez ofrece 3 servicios (que veremos en artículos posteriores)
  • Fabric / Switch controller: Su dirección es la FFFFFD y se encarga de avisar a los dispositivos conectados al fabric de cualquier cambio que se produzca en el.
  • Login Server: Todos los dispositivos que se conectan al fabric deben registrarse antes de poder comunicarse con nadie del fabric. El Login Server esta siempre en una dirección bien conocida (FFFFFE)