Continuamos hoy con la segunda parte a la entrevista de nuestro amigo George Teixeira, CEO de DataCore.

JMG: ¿Por lo que se puede intuir, el mundo del Storage va a tener una gran importancia en el futuro próximo, es así?

GT: El software de virtualización y los hipervisores de storage ocuparán el centro de atención en 2012 llevando a los usuarios hacia un nuevo nivel de intercambiabilidad y comodity “buying power” a nivel de hardware.

“Más hardware al problema” sigue siendo el mantra del proveedor de storage; sin embargo, el ritmo de crecimiento y la complejidad de gestión del storage están cambiando el modelo. Las teorías “más hardware” no funcionan. La virtualización y las clouds son básicamente software. Con el alto ritmo de crecimiento en storage, virtualización y Cloud computing cada vez queda más claro que un modelo de storage basado en hardware no es práctico. Una “mentalidad hardware” restringe la eficiencia y la productividad, mientras que el software que hace posible la intercambiabilidad del hardware elimina estas características críticas.

El modelo de hardware va en cotra de las tendencias de mercantilización, apertura y pool de recursos que han dirigido la indústria de las IT a lo largo de la útima década. El software es la solución para automatizar e incrementar la gestión de la producción, al mismo tiempo que añade la flexibilidad y la inteligencia para aprovechar, agrupar e incentivar el total uso de las inversiones en hardware.

Como el mundo se mueve hacia la Cloud y entornos de IT virtualizados, los modelos de software que permiten la intercambiabilidad del hardware, las compras “open market” y mejor gestion de recursos para storage, serán los ganadores.

JMG: Y sobre el “Big Data”

GT: “Big Data” continuará acaparando la mayor parte de la atención, pero “Small Data” continuará siendo donde estará “la acción real” en 2012.

Sí, “Big Data” está acaparando la atención y sí, “Big Data” necesita “Big Storage”, así que cualquier proveedor de storage hará el “buzz” en 2012. “Big Data” tiene muchas definiciones, pero lo que es obvio es que los ritmos de crecimiento y la cantidad de datos almacenados siguen creciendo. “Big Data” requiere mejores soluciones para que sus costes sean gestionados efectivamente. La firma IDC cree que la información mundial se duplica cada dos años. Hacia finales de 2011, de acuerdo con IDC, el mundo ha creado la sorprendente cifra de 1.8 zettabytes de datos. En el 2020, el mundo habrá creado 50 veces ésta cantidad de datos, y los departamentos de IT tendrán que gestionar 75 veces el número de “containers de información” que hospedan estos datos.

Claramente, las compañías más grandes que gestionan petabytes, exabytes y más allá son el principal foco, pero las pequeñas y medianas empresas que trabajan con terabytes de información comprenden la vasta mayoría de la realidad. Y son estas pequeñas y medianas empresas las que necesitan soluciones de storage y gestión HOY. Estos negocios no pueden esperar hasta mañana, ni pueden permitirse malgastar sus inversiones en almacenamiento de datos existentes. En vez de eso, necesitan soluciones que instaladas en los dispositivos actuales, los hagan mas eficientes, más altamente disponibles, y fácilmente gestionables.

Las tecnologías de software como el thin provisioning, el auto-tiering, la virtualización de storage y los hipervisores de storage que posibilitan a los usuarios una fácil gestión de todas las bazas que requieren (estando alojadas en local, en remoto o en la Cloud) serán claves en 2012. “Big Data” será “the industry noise” y generará muchas nuevas innovaciones. “Big Data” también se beneficiará enormemente de estos habilitadores basados en software, pero la oportunidad del “Small Data” es extremadamente grande, y hacia ahí es donde va mi apuesta para 2012.

JMG: ¿Cuales son vuestras ideas en Datacore para el mercado español?

GT: DataCore ha implementado cerca de 20.000 licencias en Europa y la compañía está haciendo del mercado español un foco para expandirse en 2012. DataCore ya tiene una fuerte presencia en el mercado español con clientes como Grup Perelada y sus Casinos o el Parlamento Vasco o el Ajuntament de Terrassa, y continuará incrementando sus inversiones en personas y recursos para aumentar el negocio.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola! ¿Qué tal, como estáis?. Todos bien después de estas navidades, supongo. Algún kilo de más que supondrá alguna ensalada de más, pero bueno.

Empezamos nuevo año, un año que va a ser especial. Si algo no va a ser 2012 va a ser “un año más” de ésta década “no prodigiosa…”. Tanto si se demuestra que los Mayas tenían razón como si no, quedará grabado. Pero no nos hace falta los Mayas, nosotros solos ya la “liamos parda”, tanto a nivel internacional como a nivel nacional….

Y he pensado que sería bueno empezar el año preguntando a ciertas personas relevantes en este mundo de las TIC cuál es su visión o bien, cuáles son sus predicciones para este año en cuanto a tecnología se refiere y más especialmente a las tecnologías de la virtualización. Hoy estamos en contacto con mi buen amigo George Teixeira, CEO de Datacore Software, empresa líder en Virtualización de Storage. Sus comentarios no tienen desperdicio.

JMG: George, ¿Como ves en general el sector de las TIC a nivel global?

GT: 2012 será un año clave en TI. La recesión global a frenado proyectos de “actualización y puesta al día,  muchas nuevas adquisiciones en IT ya no pueden esperar para actualizarse o modernizarse, por lo tanto, habrá una fuerte demanda de soluciones centradas en el ahorro de costes, especialmente en el ámbito de la virtualización en 2012. Gartner, IDC y la mayoría de los analistas de la industria han puesto de relieve para el año 2012 han puesto de relieve el cambio a “fully virtual”, incremento del uso de los servicios de la “Cloud Pública” y la necesidad de abordar los problemas del “unstructured Big Data” como las principales fuerzas en el 2012.

Estas son las principales tendencias y problemas especialmente en las grandes empresas pero para muchos departamentos de IT pequeños y medianos hay una visión del mundo real diferente y algunos puntos importantes son claros:

1. El mundo real no es 100% virtual.
2. El ahorro de costes y la flexibilidad del software son fundamentales en tiempos económicos impredecibles.
3. El uso de la “Cloud Pública” se incrementará, pero las “Cloud Privadas” desarrolladas con inversiones existentes redefinirán la IT y los CPD.
4.  “Big Data” recibirá el “Gran Premio”, pero en el “Small Data” seguirá siendo donde está la acción en 2012.
5. Los Hipervisores han permitido la “Hardware interchangeability” para los servidores y ahora es el momento para que los Hipervisores de almacenamiento hagan lo mismo con el storage.

JMG: ¿Y como ves el mundo de la virtualización para este año que viene?

GT: El mundo real no es 100% virtual. Aun siendo virtual un “tema candente”, el mundo real requiere software que trascienda tanto los mundos físicos y virtuales.

Tanto VMware, la compañía de virtualización líder en el mundo, como la mayoría de los analistas, prevén que en 2012 más del 50% de la cargas de trabajo de la arquitectura de servidores x86 será virtual. Diferentes reportes señalan que sólo el 25% de las PYME se ha virtualizado, y otros ponen de relieve los numerosos retos de la virtualización de aplicaciones de misión crítica, los nuevos dispositivos de propósito especial y los sistemas heredados.

El punto clave es que el mundo no es 100% virtual y el mundo físico no puede ser ignorado. Los clientes no pueden tirar todas sus inversiones existentes, con el fin de ser orientados al “coste-efectivo” necesitan construir sus nuevos entornos de TI con una mezcla de antiguos y nuevos.

Me parece interesante tener en cuenta el gran número de nuevos proveedores que han saltado de lleno en la tendencia de la virtualización y han diseñado sus soluciones únicamente para abordar el mundo virtual. Asumen que los clientes van a comprar “todo nuevo” despreciando sus inversiones existentes.

Por lo tanto, muchos de ellos no tratan con la gestión de dispositivos físicos o el soporte a la migración de un tipo de dispositivo a otro o el soporte a la migración de “ida y vuelta” entre entornos físicos y virtuales. Algunos fabricantes de virtualización nouveau van más allá y hacen asunciones simplificando a los físicos teóricos, sin tener en cuenta las capacidades del mundo real como Fiber Channel, asumiendo que el mundo está perfectamente ordenado y todo funciona entre sí en un mundo perfecto.

El punto de vista es que todas las infraestructuras de IT operan en un mundo virtual usando sólo tráfico IP virtual entre máquinas virtuales. Estos fabricantes “virtualization-only” tienden a hablar de un Nirvana el que todo el mundo y todo lo relacionado con este mundo es virtual, “open” y ordenado, careciendo de los detalles sucios del mundo físico. ¿Le recuerda de algún modo a su comercial de IT?

Las soluciones de virtualización deben trabajar y proveer una experiencia de usuario unificada a través de entornos virtuales y físicos. Las soluciones deben lidiar también con la realidad de los dispositivos físicos, o no será de utilidad en el mundo real donde la flexibilidad, complejidad, constantes cambios y migraciones son la norma.

(Continúa…. (2) )

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Esta semana desgranaremos los requerimientos y prerrequisitos hardware en la nueva versión de VMware vSphere 5.x

A día de hoy, es posible instalar VMware vSphere™ ESXi 5 en cualquier tipo de servidor de nueva generación. Asimismo, la lista de compatibilidad de hardware para VMware vSphere™ ESXi 5 ha aumentado considerablemente en esta última versión, debido principalmente a que ESXi es la única versión disponible en vSphere™ 5.

Estos son los requerimientos de hardware mínimos para poder instalar VMware vSphere™ ESXi 5:

• Procesador: Solo CPUs de 64-bit x86, Intel o AMD, máximo 160 CPUs (cores o hyperthreads).
• Memoria: 2GB de RAM mínimo, 1TB máximo.
• Red: Una o más tarjetas Gigabit Ethernet. Las tarjetas Ethernet de 10Gb también están soportadas. El número máximo de tarjetas de 1Gb Ethernet (tg3 de Broadcom) por servidor es de 32.
• Controladora de disco: Controladora SCSI, controladora FC (Fibre Channel), controladora iSCSI, controladora RAID interna, SAS y SATA.
• Almacenamiento: disco SCSI, LUN (Logical Unit Number) FC, disco iSCSI o RAID LUN con espacio disponible sin particionar.

Es posible instalar VMware vSphere™ ESXi 5 en una LUN de la SAN, método conocido con el nombre de Boot from SAN (BFS). BFS está soportado en Fibre Channel SAN, en iSCSI (iniciadores de software iSCSI y dependent hardware iSCSI) y en FCoE – de las siglas en inglés Fibre Channel over Ethernet – para aquellas cabinas de almacenamiento que estén incluidas en la matriz de compatibilidad. VMware vSphere™ ESXi 5 puede configurarse con un máximo de 256 LUNs de FC (Fibre Channel).

Asimismo, si necesitas hacer BFS es necesario  los dos requerimientos siguientes:

1. La BIOS de la HBA (Host Bus Adapter) debe estar habilitada.

2. Debes seleccionar la HBA con el número de slot PCI menor.

Asimismo, VMware vSphere™ ESXi 5 soporta un máximo de 8 dispositivos PCI/PCIe en modo VMDirectPath passtrough. Sin embargo, una máquina virtual no puede tener configurados más de dos dispositivos PCIx/PCIe configurados como VMDirectPath.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

¿Hola, que tal? Soy Jose Mª Gris y como cada miércoles estoy aquí con vosotros para hablar del ecosistema.

Je, viendo el título del post trae a la mente lo de “El sentido de la vida” de Monty Python, gran película, pero no, no va por ahí. O quizás sí, veremos.

Lo cierto es que a partir del post de Cloudarray he recibido varios mails sobre él. Algunos de vosotros se han ofrecido para los tests que estoy pensando hacer, compañeros que en persona me han dado su opinión o sus ganas de “poner la mano” sobre el producto.

Pero todos en algún momento me han expresado “¿Hasta donde llega en performance?”, y si no llega, que sentido va a tener un producto así.

Reconozco que bastantes ratos he pasado pensando en ello. Cuando más o menos lo tenía controlado he tenido la suerte de cenar con mi buen amigo Said Boukhizou, TAM para el sur de Europa de Datacore (otro día os lo presentaré con más tiempo) y fue una gran oportunidad de contrastar ideas.

Cloudarray es un sistema de almacenamiento en Cloud. Gestiona de forma sencilla la interface del target iSCSI por un lado para simplificarlo, y por otro lado los proveedores de storage en la cloud. ¿Y que hace en medio? Pues monta un Proxy-caché en local, que va enviando los datos a la nube.

Bien, eso ya nos da una idea de por donde van a estar los límites que nos vamos a encontrar en primer lugar. En el momento que el caché esté lleno, el rendimiento va a ser más lento y nuestro gozo en un pozo.

Claro (como dice Said) que en el fondo en tu instalación también tienes bloques que no son tan “calientes”, que son bastante o muy “cold”. Esa temperatura viene dada por el nivel de utilización que hacemos de estos bloques. Entramos en el concepto de “Tiering” de nuestros recursos de SAN.

En estos momento, lo óptimo es tener:

• Tier 1.  Recursos SDS y a poder ser en un canal ultra rápido de acceso.
• Tier 2.  Resusrsos SAS con acceso FC
• Tier 3.  Recursos “Near SAS” o “SATA”
• Tier 4.  Recursos “Cloud” como CloudArray.

Si a esto le sumas la nueva funcionalidad de Datacore de hacer “Autotiering”, tienes el cuadro completo.

No hay nada bueno ni malo, sencillamente hay que tener lo adecuado para cada caso. Tier 4 nos puede servir para  aquellos accesos que nos interese tener de forma “cold”, mientras que en nuestro Tier 1 o Tier 2 tendremos lo que se hace un uso intensivo.

Bueno, pues ya tenemos una información de partida para nuestros test J, que no es poco.

Continuaremos informando. “Stay tuned”. Take care.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.

Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.

Las opciones que tenemos para un SR son:

Veamos las propiedades de cada una de estas tecnologías.

Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6  y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.

Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.

NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.

Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.

iSCSI: La utilización de iSCSI en XenServer permite  una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.

Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.

Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local,  los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.

Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.

StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.

Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs

Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.

¿Qué tecnología de almacenamiento utilizas en tus entornos?

Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

¿Hola, que tal? ¿Como estamos? Soy Jose Maria Gris y hoy tengo una cosa bastante especial para vosotros.

Hay dias en que te cae en las manos un nuevo producto y miras las especificaciones, las features y piensas, “no, lo he entendido mal”. Lo revisas y te lo lees con un poco más de detenimiento y vuelves a pensar “pues a lo mejor sí… “.

Este es el caso que nos ocupa, Cloudarray de Twinstrata. De la mano de Datacore, esta compañia nos ofrece la posibilidad de tener una parte de nuestra SAN en la Cloud. Su instalación, simple como bajarse una “appliance”, configurarla, conectarla a un proveedor de storage (Amazon S3, etc.). Configuras una ip para dar servicio como target iSCSI de las luns que tendrás en la Cloud, defines parte del storage como caché y se lo presentas a Datacore mapeando las luns desde el appliance.

Y a jugar! Funciona, y a las mil maravillas. Otra cosa es lo que nos cueste el almacenaje en la Cloud (los precios son elevados), pero ya tenemos esta tecnología para integrarlo facilmente con nuestra infraestructura.

Como features presenta:

• Compresión de datos y deduplicación
• Rápida integración con Datacore SANsymphony V
• Encriptación
• Snapshots
• DR (on-site, off-site or in the cloud)
• Optimización del ancho de banda y programación
• Opciones de Alta Disponibilidad
• Elección de proveedores de cloud storage.

Realmente me ha gustado el producto, el rendimiento es muy bueno. Estoy pensando como plantear una serie de pruebas de carga, ya os iré comentado en próximos post.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola a todos de nuevo.Soy Miguel Ángel Alonso y aquí estoy como cada martes para hablaros sobre el mundo de la virtualización de sistemas.

En el post de hoy te voy a hablar de la solución NEXENTASTORE (basada en Solaris) para crear almacenamiento en casi cualquier hardware que reúna un mínimo de requerimientos de hardware para la virtualización de sistemas.

Te preguntarás: ¿Qué tiene de especial esta solución si ya se ha hablado en anteriores posts  de otras como DataCore, Starwind o incluso de soluciones como Openfiler, Freenas para nuestros laboratorios?

Pues lo que hace especial, a mi modo ver, a esta solución son estas características que te voy a numerar y que para mí son primordiales. Estas características, asociadas a la facilidad de instalación de XeXentaStore, han hecho que incluso en el entorno de laboratorio de JMG VirtualConsulting nos hayamos decidido por migrar todo nuestro entorno virtual de VMware, Citrix y Microsoft a esta maravillosa solución de almacenamiento para entornos virtuales.

Es que es gratuita, aunque por supuesto tienes la versión de pago

• NexentaStore 3.1.1 Community Edition (free) y hasta 18 TB
• NexentaStore Enterprise 3.1.1 con soporte, acceso a Plugins de virtualización y pago en función de los TB que necesites en tu entorno de trabajo.

Permite Compresión, Snapshots, Deduplicación, Reparación

La versión gratuita te permite todas estas funcionalidades en segundo plano de cualquier bloque o archivo dañado, optimización del rendimiento en el apartado de I/O en cabina, ISCSI,FC,NFS v2,v3 y v4, CIFS,FTP,WEBDAV, lecturas de I/O a nivel de disco y de red muy completa y un largo etcétera de opciones que nos serán de gran utilidad.

En la versión de pago (Enterprise) dispondras, además ,de alta disponibilidad y mirroring entre cabinas dealmacenamiento.

Integración con VAAI (segunda generación),  para VMware vSphere 4.1 y  5.0 que incluye las siguientes primitivas

Este es el este punto mas interesante a tener en cuenta, ya que tanto la versión gratuita como la de pago nos ofrecen 2 características que en el mundo de la virtualización nos van a dar muchas ventaja:

Primitiva 1:

SCSI Write Same

Acelerando la escritura de Zeros en los bloques cuando creamos una máquina virtual. (Compatible con vSphere 4.1 y posteriores)

Primitiva 2:

SCSI ATS

Crea una “región” en la LUN para ser bloqueada en lugar de utilizarla entera a la hora de crear Snapshots. (Compatible con vSphere 4.1 y posteriores)

Primitiva 3:

SCSI Block Copy

Evita la lectura y la escritura de los bloques de datos “a través” del host ESX   durante una operación de copia de bloque al permitir que “VMware” pueda instruir a la SAN para hacerlo. (Compatible con vSphere 4.1 y posteriores)

Primitiva 4:

SCSI Unmap

Permite a los bloques liberados, el ser devueltos a la zpool (pools de Volúmenes Zvol) para la asignación de nuevos, cuando ya no se utilizan o dejan de utilizarse para el almacenamiento de las VMs. (Compatible con vSphere 5 y versiones posteriores).

Como resultado podremos ver desde nuestro vCenter o nuestro ESX  y desde la pestaña de Storage, que tenemos Aceleración por Hardware como si de cualquier cabina de DELL, EMC, NETAPP o cualquier gran marca se tratara.

Integración con Citrix StorageLink

Por ultimo, NeXentaStore soporta Citrix StorageLink, la cual es una herramienta que nos permite crear VMs de manera masiva a partir de templates en cuestión de minutos o de crear planes de recuperación ante desastres entre algunas de sus características.

Lo único que tendremos que hace es instalar el adaptador de Storage link,  de apenas 700 Kb desde Nexenta, e instalarlo donde tengamos la consola de Citrix StorageLink.

En la imagen anterior, se muestra que ya podemos tener acceso a las cabinas NAS o SAN con Nexenta después de instalar el Adapatador.

Y aquí, podemos ver la creación y manejo de repositorios de nuestra cabina Nexenta con Citrix StorageLink.

La instalación de Nexenta es muy sencilla y creo que no cabe lugar en el post para ello. Si fuese necesario y tuvieseis dudas sobre su instalación hacernos lo saber y no dudaré en crear un post de la instalación si así lo requereis.

También, y antes de terminar, me gustaría deciros que también la podéis bajar en formato Appliance para VMware y Citrix como Máquina Virtual.

Bueno hasta aquí por hoy. Espero que te haya gustado y te emplazo hasta la semana que viene con un nuevo capítulo sobre la virtualización.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

En un post publicado la semana pasada, te explique que es la política de balanceo de VMware vSphere llamada Round Robin y como configurar esta para una cabina de Dell EqualLogic.

En el post de hoy te enseñare a configurar y elegir automáticamente la política de balanceo de E/S de disco en VMware vSphere llamada Round Robin.

Para poder configurar el PSP – de las siglas en inglés Path Selection Plugin – para cualquier dispositivo de almacenamiento, es necesario ejecutar el siguiente comando:

esxcli -–server nmp device setpolicy –device –psp

Nota: Puedes una explicación más detallada de los que es PSP en el post llamado: He configurado el Round Robin, pero los caminos no son utilizados de manera uniforme”

Lo importante que me gustaría destacar en este punto es que la configuración del PSP es por DataStore, es decir, que si tienes 100 datasotres y quieres cambiar la configuración del PSP de Fixed a Round Robin has de hacer el mismo cambio en los 100 datastores.

Sin embargo, podemos configurar VMware vSphere ESX/ESXi para que automáticamente este pueda elegir Round Robin para cualquier dispositivo controlado por el SATP – de las siglas en ingles Storage Array type Plugin.

Y aquí es donde bien lo interesante de la cuestión: ¿Cuál es el comando o comandos para configurar tu VMware vSphere ESX/ESXi de manera que el PSP por defecto sea Round Robin?

Estos son los cuatro commandos que has de ejecutar directamente en tu servidor VMware vSphere ESX/ESX 4.x:

1. esxcli –server corestorage claiming unclaim –type location
2. esxcli –server nmp satp setdefaultpsp –satp –psp VMW_PSP_RR
3. esxcli –server corestorage claimrule load
4. esxcli –server corestorage claimrule run

Una vez ejecutados estos commandos tu politica de PSP por defecto sera Round Robin.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Ya esta disponible online el episodio #24 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en español.

En el episodio de esta semana, hablaremos de los discos de estado sólido en entornos de virtualización, responderé a la pregunta de un usuario en relación a los beneficios del hardware virtual versión 7 en las máquinas virtuales, te enseñare otra utilizad impresionante relacionada con el mundo de la virtualización y del Cloud Computing y terminaremos con el caso de éxito del mundo de la virtualización del Correo Gallego.

Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, entra en virtualizacion.tv hazlo ahora. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.

¿Crees que este videopost puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por tu apoyo.

Buenos días, soy Jose Maria Gris y como cada miércoles estoy aquí para hablar sobre el Ecosistema de VMware.

Os he ido enseñando poco a poco la nueva versión de Datacore. En post anteriores sobre laboratorios de bajo coste, en algunas transparencias os he ido enseñando la nueva cara de nuestro viejo amigo.

Lo cierto es que no tiene nada que ver. La consola de SANmelody ahora se nos antoja antigua y poco amigable, ahora todo es muy intuitivo y además nos trae nuevas funcionalidades.

Hablando de nuevas funcionalidades, especial mención al CDP que incorpora. Nos ayudará mucho en momentos de apuro y nos dará tranquilidad en el resto del tiempo (que falta hace)

Quien me conoce sabe que muchas veces digo “A mi no me crea, pruébelo”. Nuestros amigos de Datacore han hecho lo mismo y han montado unas maquetas para que quien quiera pueda probar el nuevo producto.

Pulsando aquí, podréis acceder a la pagina de su web donde podréis ver dos interesantes videos sobre la presentación del producto y sobre una demostración de alta disponibilidad. Interesante de ver.

¡Pero queremos probar! Pues a ello vamos, en este link podéis acceder a un “Test Drive” y probar con vuestro mouse como funciona. Ojo, tan sólo funciona con Internet Explorer.

En breve haré un tutorial de cómo se instala y como se gestiona nuestro nuevo SANsymphony-V.

A lo mejor hago algún pinito y grabo un video. ¿Que opina nuestro Chief Editor?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

Esta semana me gustaría retomar el scripting con PowerCLI para trabajar en esta ocasión con los contadores de rendimiento de nuestra plataforma vSphere.

Para obtener la información de nuestra plataforma contaremos con dos cmdlets principales, complementarios entre sí, encargados de darnos la información que requeríamos de nuestro entorno. Básicamente se tratan de:

• Get-Stat, que es el que realmente nos devuelve la información acerca de los contadores de rendimiento que requiramos.
• Get-StatType, que nos informa de los contadores disponibles para el objeto que queramos interrogar, ya sea una máquina virtual, un host ESX(i) o un vCenter.

Si os parece bien, en lugar de ponerme a enumerar los parámetros de cada uno de los cmdlets Get-Stat y Get-StatType, vemos cómo usarlos mediante un par de ejemplos.

En su ejecución más simple, sin parámetro ninguno, este cmdlet nos devolverá el promedio de los contadores de rendimiento normales en el intervalo de muestreo, que por defecto se establece en 20 segundos, para host o vCenter al que estemos conectados. Por ejemplo:

PowerCLI> Get-Stat
MetricId Timestamp Value Unit Instance
——– ——— —– —- ——–
mem.usage.average 11/05/2011 15:27:00 90,42 %
mem.usage.average 11/05/2011 15:26:40 90,43 %
mem.usage.average 11/05/2011 15:26:20 90,43 %
…
net.usage.average 11/05/2011 15:27:00 0 KBps
net.usage.average 11/05/2011 15:26:40 0 KBps
net.usage.average 11/05/2011 15:26:20 0 KBps
…
disk.usage.average 11/05/2011 15:27:00 129 KBps
disk.usage.average 11/05/2011 15:26:40 98 KBps
disk.usage.average 11/05/2011 15:26:20 125 KBps
…

Si sólo estamos interesados en alguno de los grupos genéricos usaremos los modificadores Memory, CPU, Disk o Network según el que nos interese.

Sin embargo, como todos sabemos, los contadores de rendimiento en vmware no se limitan solo al Host o al vCenter, sino que se extienden a máquinas virtuales, resource pools, etc… Para acceder a esta información sólo tendremos que usar el parámetro Entity al que le pasaremos un array con los objetos sobre los que queramos información.

Por ejemplo, como ya vimos en otro post anterior, el cmdlet Get-VM nos devuelve todas las máquinas virtuales registradas en un host, cluster o vCenter. Si queremos obtener los contadores de rendimiento comunes de todas nuestras máquinas virtuales encendidas, sólo tendremos que ejecutar el siguiente comando:

PowerCLI>Get-Stat (Get-VM | Where-Object { $_.PowerState –eq ‘PoweredOn’ } | Export-CSV –delimiter “;” perfVM.csv

Donde Where-Object { $_.PowerState –eq ‘PoweredOn’ } es el filtro que nos permite discriminar por el estado de la máquina virtual y Export-CSV –delimiter “;” perfVM.csv exporta el resultado a un fichero CSV para que sea más sencillo realizar el tratamiento de los datos. Si estáis interesados en los datos de una VM en particular sólo tenéis que cambiar el filtro y la pipe anterior (el símbolo |) por el nombre de la máquina virtual.

No me gustaría terminar sin comentaros el modificador para mí más importante Stat. Este modificador admite como parámetro una array de tipo cadena con un listado de los contadores de rendimiento en los que estamos interesados. Es precisamente en este punto donde entra en juego el otro cmdlet que os mencionaba al principio, Get-StatType, que es el encargado de mostrarnos los contadores que tenemos disponibles para un tipo de objeto en particular. Tened presente que la lista de contadores disponibles dependerá de los elementos de los que dispongáis en vuestra plataforma.

Una vez consultado los contadores que nos interesen mediante Get-StatType, podemos interrogar a nuestra plataforma por los valores que nos interesen.

En el siguiente ejemplo comprobaremos la latencia y el throughput en el adaptador de almacenamiento vmhba2.

PowerCLI> Get-Stat -Stat @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) | Where-Object { $_.Instance -eq ‘vmhba2′ } |Out-GridView

Donde @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) es el array con los contadores que nos interesan y Where-Object { $_.Instance -eq ‘vmhba2′ } de nuevo es un filtro que en esta ocasión nos permite fijarnos sólo en el adaptador vmhba2.

Esta vez en lugar de exportar los datos a un fichero CSV he preferido sacar los resultados a una ventana externa donde además podremos filtrar mucho más los resultados.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

StarWind Software es el líder global de administración de bases de almacenamiento y desarrollo de software de SAN para pequeñas y medianas empresas.

El ejemplo más representativo de productos de StarWind es el software de SAN que convierte cualquier servidor estándar de Windows en una SAN iSCSI segura y tolerante a fallos. El programa está diseñado para su uso como almacenamiento en una red con VMware, Hyper-V, Microsoft SQL Server, Microsoft Exchange, Microsoft SharePoint y otras aplicaciones de servidor que se configuran en los clústeres de servidor.

La compañía StarWind Software está orientada a las pequeñas y medianas empresas ofreciéndoles la tecnología barata de alta disponibilidad que hace poco solamente estaba disponible en los productos prestigiosos y caros de almacenamiento.

Las características avanzadas de sus productos incluyen creación de espejos síncronos con tolerancia a fallos y recuperación automática, replicación remota en una WAN, protección continua de datos y puntos de recuperación, thin provisioning y administración de cintas virtuales.

En el año 2003 StarWind lanza su primer programa de SAN iSCSI convirtiéndose en el producto favorito para más de 30.000 usuarios de todo el mundo en más de 100 países, desde pequeñas y medianas empresas, hasta gobiernos y compañías de Fortune 1000.

Aprenda más sobre las soluciones de productos StarWind registrándose en nuestros seminarios web gratuitos:

Hola de nuevo, soy Jose Maria Gris y seguimos comentando el caso APD.

La foto no es un cuadro de Miró, es un masking de pintores…. (Nota del Blogger…)

Hoy vamos a ver como tenemos que hacer para que aunque tengamos o no el parche adecuado para solventar el APD, pues si nos aseguramos de quitar de forma correcta la LUN, estaremos mas tranquilos no?

El KB 1015084 nos indica paso a paso lo que hay que hacer por consola.

- Dejar de usar el datastore en cuestión

• Desregristrar las VM que estén allí registradas
• Asegurarse de que no hay scripts que están trabajando con la LUN en cuestión

- En ESX tenemos el NMP (Native Multi Path) y el MASK-PATH Plugin que es el que usamos para hacer masking con las LUNs. Para saber si están disponibles:

• # esxcfg-mpath –G

El output debe ser parecido a

• # esxcfg-mpath -G?MASK_PATH?NMP

Listamos las claimrules existentes

• # esxcli corestorage claimrule list

El output será parecido a

• # esxcli corestorage claimrule list?Rule Class Type Plugin Matches?0 runtime transport NMP transport=usb?1 runtime transport NMP transport=sata?2 runtime transport NMP transport=ide?3 runtime transport NMP transport=block?4 runtime transport NMP transport=unknown?101 runtime vendor MASK_PATH vendor=DELL model=Universal Xport?101 file vendor MASK_PATH vendor=DELL model=Universal Xport?65535 runtime vendor NMP vendor=* model=*

Añadimos una rule mediante el la siguiente instrucción:

• # esxcli corestorage claimrule add –rule  -t location -A -C -T -L -P MASK_PATH

donde -A <hba_adapter> -C <channel> -T <Target> -L <lun> define un único path. El numero de la “rule” debe ser entre 101 y 200.

Verificamos que la rule esta incluida….

# esxcli corestorage claimrule list

Y la cargamos. Así con todos los paths.

# esxcli corestorage claimrule load

Si todo ello esta correcto podemos hacer el claiming

# esxcli corestorage claiming reclaim -d

Donde <naa.id> es el identificador del device.

Con todo ello efectuado y borrados todos los paths, iremos a vCenter y nos iremos a Host > Configuration > Storage, click Refresh y el datastore desaparecerá.

Podemos deshacer el maping de la LUN desde nuestro Array.

Como ultimo paso, nos quedaría limpiar la tabla de rules

# esxcli corestorage claimrule delete –rule

Cargar

# esxcli corestorage claimrule load

Y listar para ver que todo queda limpio. Si queda alguna rule, pues a empezar el proceso de cleaning de nuevo.

Espero haya sido interesante.

Referencias :

Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x (1009449)

Masking a LUN from ESX and ESXi 4.x using the MASK_PATH plug-in (1009449)

Queridos lectores,

En el post de hoy os enseñaré un pequeño truco para poder disponer de nuestras ISOs en el almacenamiento local de nuestro XenServer.

Como sabéis desde la consola de XenCenter la única manera de poder crear un repositorio para ISOs es a través de la red:

Os recuerdo los pasos:

1.- Añadimos nuevo storage, seleccionamos NFS ISO

2.- Introducimos la ruta del servidor y del directorio publicado por NFS y pulsamos en finalizar

Lógicamente para este método necesitaremos un sistema que permita almacenamiento en red. Pero para instalaciones más modestas existe este otro método que explico a continuación en el cual podremos meter nuestras ISOs en el repositorio local del servidor XenServer

Nos conectamos por SSH al servidor XenServer y desde CLI ejecutaremos los siguientes comandos:

1.- Creamos el directorio por ejemplo:

mkdir /var/opt/xen/isos

2.- Creamos el repositorio en el directorio anteriormente creado:

xe sr-create name-label=ISOs type=iso device-config:location=/var/opt/xen/isos device-config:legacy_mode=true content-type=iso

Y como podéis apreciar si hacemos un listado de los repositorios sale en nuevo creado:

A partir de ahora tendremos que subir los ISOs mediante SCP desde Linux o Mac o cualquier cliente Windows como WinSCP.

Esto es todo amigos, como siempre espero que sea de utilidad.

Hola soy Jose Maria Gris y de nuevo estoy aquí con vosotros. Últimamente esta sección parece un poco como cuarto milenio . Lo que os comentaré hoy no es que sea cosa de brujas pero si es cierto que me ha traído de cabeza en 2 instalaciones estos días y la verdad es que no acababa de verlo claro. Tras investigación y pruebas de laboratorio, ha quedado bastante claro.

Bien, todo empieza cuando llego a una instalación que “se ha vuelto loca”. Sencillamente es ingobernable, no contesta ni responde correctamente ni al VI client ni a vCenter…. No se comporta correctamente con SSH. Vamos, un potro desbocado. Eso sí, las VM continúan dando servicio sin problema.

Nos ponemos en contacto con soporte y nos comentan que lo que tenemos es un “All paths Down” o APD. Solución: Hay que entrar en las vms por RDP, pararlas y posteriormente hacer caer el ESX/i con un Cold Reset. Cuando se levante, todo estará en su sitio. Soporte “dixit”

Bien, vamos a ver como ocurre esto. El KB 1016626 nos empieza a dar luz sobre el tema. El resumen es “si se efectúa un rescan cuando una lun esta con todos los enlaces caídos puede generar o bien que otra vm deje de responder o como me ocurrió a mi, que los hosts se vuelvan locos.” Las razones pueden ser múltiples, error de hardware, sacar una lun de golpe, etc. Lo cierto es que con diversos levels de ESX he visto comportamientos muy parecidos, pero distintos.

Por lo que he estado investigando, es un bug de vSphere. Con 3.5 no pasaba. Básicamente si en un rescan el sistema detecta que no encuentra una Lun, se vuelca con el proceso hotsd a buscarla, tanto, que llega a bloquear nics, etc….

Si estás leyendo esto y estas en 4.0. U1, tienes que pensar en instalar el parche que se indica mas abajo en referencias, el cual minimiza el tiempo de “no respuesta”. Con 4.0 U2 y 4.1 ya viene instalado.

La buena noticia es que ya leí en un KB que en versión 4.1 U1 el tema se solventaba. La tengo instalada en mi laboratorio y efectivamente entre las features comenta que “ya no deberá pasar mas”, aunque hay un comentario sobre “si ocurre, contacta con soporte técnico.”

No contento con ello he cogido una instalación grande en preproducción, con SANs y con Datacore importante y simplemente he sacado una lun para posteriormente hacer un rescan manual desde el cluster. Lo cierto es que no le ha gustado nada, ha “tosido” se ha molestado, se ha recorcobecado, pero al cabo de un par de minutos estaba todo bien y continuaba en su sitio. Nada que no se pueda mitigar.

Lo reconozco, no me he quedado contento. Lo he probado en mi pobre labo. Los resultados han sido los mismos.

No os voy a decir que el APD ha quedado eliminado, esto lo debe decir el fabricante, pero en mis pruebas, al menos, no ha aparecido….

No obstante, la próxima semana os presentaré como hacer correctamente un “masking” desde ESXi para despresentar una LUN en vSphere 4.x (esté o no solventado el APD, por si las moscas).

Hasta la semana que viene.

Referencias
KB Article: 1016626 Virtual machines stop responding when any LUN on the host is in an all-paths-down condition (APD)
VMware ESX 4.0, Patch ESX400-200912401-BG: Updates vmkernel, vmklinux, tools, CIM, and perftools (1016291)
VMware ESXi 4.0, Patch ESXi400-200912401-BG: Updates Firmware (1016295)