25 de julio de 2011

Twago. El Portal Europeo para Proyectos Freelance


Muchos de los que leéis este blog sois profesionales freelance o tenéis en mente serlo.

Os recomiendo este portal europeo llamado Twago donde podéis daros de alta y conseguir oportunidades de negocio. Es muy recomendable!

21 de julio de 2011

VMware Hipervisor (antes ESXi Free) limitado a 8GB de vRAM

vSphere 5, como sabéis, sólo soporta ya ESXi, dejando a ESX definitivamente superado.

Seguirá existiendo la versión gratuita llamada en versiones 3.x ESXi free y en las 4.x y 5.x vmware Hypervisor. Esta versión no tenía límite de RAM en la versión 3.x y 4.x más allá de la propia del Hypervisor que era de bastantes GB, normalmente una RAM que no tenían la mayoría de clientes.

En la versión 5, vmware Hypervisor está limitado a 8GB de memoria vRAM por CPU. Si el host tiene 2 CPU (lo más típico) pues 16GB de vRAM. De 256GB a 8/16GB ha sido un cambio radical, evidentemente para mal...

Je suis désolé! :-(

Los entornos de hipervisores gratuitos son ideales para entornos de prueba, laboratorios, etc. A pesar de sus limitaciones tienen un uso interesante y que los clientes saben apreciar. Limitar esto, es totalmente lícito por parte de vmware, pues es su producto y pueden poner el tipo de licenciamiento que quieran y de limitaciones que consideren más oportuno, aunque cómo lo perciben los clientes debería ser una variable a tener muy en consideración.

¿Qué os parece esta decisión de vmware?

Espero que rectifiquen. Sería lo más inteligente.

PD: tras la presión vmware rectificó y pasó a 32GB de RAM el límite de vmware hipervisor.

vRAM, el bueno, el malo y el feo

Los amigos de vKernel han publicado un post llamado el bueno, el malo y el feo en el que hacen diversas reflexiones sobre el licenciamiento vRAM de vSphere 5.

Os recomiendo su lectura:

http://www.vkernel.com/reader/items/vram-pricing-vsphere-5

15 de julio de 2011

Herramienta de control de licenciamiento de vRAM

Bryan Semple me ha mandado un mail indicándome que ha publicado en su web vkernel una aplicación muy interesante: vRAM Capacity View.

Esta aplicación gratuita analiza el entorno vSphere que tengamos en producción y nos indica cómo estamos respecto a la nueva política de licenciamiento de la versión 5.0.

Importante tomaros una tila antes de ver el resultado!

La podéis descargar aquí:

http://www.vkernel.com/pages/vram-capacity-view

14 de julio de 2011

vSphere 5 y vRAM, luces y sombras


Hoy 30 de diciembre de 2011 corrijo los valores de vRAM para no crear lio.

Prólogo

La Constitución española de 1978, en su artículo 9.3 aprueba la "irretroactividad de las disposiciones sancionadoras no favorables". Y es que si se aprueba una nueva ley con un impuesto, una subida de una tasa, etc. siempre es un problema que se aplique con carácter retroactivo :-)

Esto viene a colación de una de las muchas novedades de vSphere 5, las vRAM Pools.
VMware sigue evolucionando, como líder destacado y claro del mercado innovando y sacando múltiples características que realmente son ventajosas para las empresas. No obstante en la versión 5 hay una espina o un manojo de espinas entre las rosas y es el cambio en el licenciamiento.

Os recomiendo la lectura (para mí obligada) de este documento de VMware llamado vSphere 5, Licensing, Pricing and Packaging:

El licenciamiento de vSphere 5

Como sabéis el licenciamiento de las versiones de ESX/ESXi en sus versiones 1.x, 2.x, 3.x y 4.x ha sido el socket, CPU o procesador físico. En función de las versiones había una restricción de uso en el número de cores. Así por ejemplo en vSphere 4.1 las versiones essentials y essentials plus no podían utilizar más de 6 cores por procesador.

En vSphere 5 hay un cambio de modelo de licenciamiento, que se quiere alinear con el modelo de pago por utilización de la nube. El licenciamiento sigue siendo por procesador físico, pero con un límite de vRAM, es decir de RAM que pueden utilizar las VMs.

Los Pools de vRAM

Concretamente los valores son para cada CPU física o socket:

Versiones Essentials, Essentials Plus y Standard:
32GB vRAM x CPU.


Versión Enterprise:
64GB vRAM x CPU


Versión Enterprise Plus:
96GB vRAM x CPU


La versión Advanced ha desaparecido y los propietarios de esa versión pasan a tener la Enterprise en vSphere 5, para lo bueno (DRS, Storage vMotion, DPM...) y para lo malo, van a pagar más de mantenimiento.

Realmente no hablamos de CPUs aisladas sino del concepto vRAM Pool. Así si, por ejemplo adquirimos la versión Essentials Plus de vSphere (también llamada cariñosamente pelón plus) tenemos un total de 6x32=192GB de memoria RAM. Si un socket está utilizando más memoria RAM y otro menos, el vRAM Pool lo equilibra, el caso es que no nos podemos pasar de esos 192GB en su uso global.

Directiva de bloqueo de arranque de VMs

Hay otra cuestión y es que en las versiones Essentials y Essentials Plus no se puede superar este límite, es decir, si estoy utilizando 190GB de memoria RAM e intento levantar una VM de 4GB me va a decir que no se puede y no la voy a poder levantar. No levantarla siempre es un problema, ¿verdad? :-)

En las versiones Standard, Enterprise y Enterprise Plus nos saldrá una advertencia de la directiva de vRAM Pool indicándonos que no cumplimos con el EULA pero sí dejará levantar las VMs.

Sumatorio de licencias sobre la misma CPU

Más cosas. Podemos sumar licencias. Esto es si tengo 4 sockets en mi entorno puedo comprar 8 licencias y sumar 4x2 de modo que para cada CPU entregue 2 licencias y pueda, en el caso de Standard, tener 64GB de RAM por cada socket.

Directiva de licenciamiento obligatoria

Si queremos migrar de vSphere 3.x o 4.x a la versión 5 la aplicación de esta nueva filosofía de licenciamiento es obligatoria, no optativa. Son lentejas, si quieres las comes y sino las dejas :-(
Ejemplos amables de vmware

(estos ejemplos son con los valores de 24GB para standard que inicialmente se aprobaron)

Vmware, muy amablemente, nos dan algunos ejemplos en el documento anteriormente referenciado. Digo muy amablemente porque es un ejemplo 'amable' para con la nueva directiva de licenciamiento.

Así se nos habla de un escenario con 2 hosts, cada uno con 2 CPU físicas. El cliente adquiere 4 licencias de vSphere Enterprise, lo que significa 4x32= 128GB de RAM en su vRAM Pool. El cliente levanta 20 VMs con 4GB de memoria RAM y está usando 80GB. Hasta aquí todo perfecto.

En su evolución tiene necesidad de implementar 5VMs nuevas con 8GB de RAM, lo que hace que necesite 120GB de RAM, para no ir justos decide comprar otro host (ya tenemos 3) con un procesador. Entonces nos encontramos con 3 hosts y 5 licencias por CPU. Ahora la capacidad es de 160GB, pues estamos con licencias enterprise.

En la evolución se explica que el cliente va añadiendo más VMs y va evolucionando añadiendo más licencias y finalmente upgradando a Essentials Plus para finalizar con una vRAM Pool de 192GB y 180GB usadas, con 4 hosts y 6 licencias para las 6 CPU totales.

Es un ejemplo muy bien redactado, pues se ve cómo puedes sumar licencias a una misma CPU y cómo puedes evolucionar de una versión a otra superior.

El licenciamiento, como tal, viene a ser muy similar al del SAAS que se utiliza en el cloud, sólo que aquí hablamos de licencias perpétuas y en el escenario de la nube tenemos pagos mensuales.

La estrutura física de la RAM en los hosts de los diferentes fabricantes

Hoy día los diferentes fabricantes de hosts, Dell, IBM, HP, Fujitsu... tienen la mayoría de hosts de 1 y 2 U con 9 módulos de RAM por procesador físico o socket. Además estos módulos están divididos en bloques de 3 que se tienen que ir rellenando de 3 en 3 para tener compatibilidad con las especificaciones del fabricante. Por ejemplo si llenamos 3 ranuras de RAM con módulos de 8GB tenemos 8x3=24GB, curiosamente la RAM de una licencia de vSphere Standard.

Clientes nuevos y clientes que actualizan

Este licenciamiento, como comento, pues es el que es y si eres un nuevo usuario de vSphere lo aceptas y listos, no hay problema. Al hacer el dimensionamiento hardware lo tienes en cuenta lo aplicas y aquí paz y allá gloria.

Pero, ¿qué sucede con los clientes (unos cuantos millones) que ya disponen de vSphere?
Vamos a ver un par de ejemplos reales de clientes que ya me han llamado atemorizados ante el nuevo licenciamiento de vSphere.

Ejemplo 1. Cliente con Essentials Plus.

Este cliente tiene 3 hosts con 6 sockets en total y tiene 72GB de RAM en cada servidor, esto es 3x72=216GB de memoria RAM en su entorno. Adquirió en su momento una licencia de vSphere Essentials Plus Bundle y 6 licencias de Microsoft Windows Server 2008 R2 Datacenter OPEN, pudiendo levantar infinitas VMs en cada host. Le está dando un uso intensivo a su entorno y está muy contento y satisfecho con el modelo actual.

¿Qué sucede si quiere migrar a la versión 5 de vSphere? pues que tiene un problema bonito. Al actualizar, con su licencia de Essentials Plus, la vRAM que va a poder utilizar son tan sólo 6CPUx24GBvRAM=144GB de VRAM disponibles. Si se pasa un MB la VM no se le va a levantar.

Opciones que tiene el cliente:

1. Ir al médico y decir 'no se me levanta' y que le receten viagra. Esto está en beta aún pero parece que no va a ayudarle en exceso.

2. Quedarse con la versión 4.1. La buena noticia es que vmware ha prometido 7 años de soporte y actualizaciones para esta versión. Quien no se consuela es porque no quiere.

3. Actualizar a la versión 5.0 y perder capacidad de proceso a nivel de RAM. Va a tener RAM física que no va a poder utilizar. Una opción es que me regalen a mí que tengo una ONG de recogida de RAM y Macs: yo corro con los portes.

4. Actualizar a la versión 5.0 y pasar por caja adquiriendo, por ejemplo, licencias Standard. En caso de que tuviese que pagarlas de nuevo, tendría que adquirir 9 licencias. Esto es los 216GB de memoria RAM entre 24GB de vRAM que le proporciona cada licencia. Un bundle de 8CPU vale $10.000. Evidentemente el cliente tendría un descuento por ya tener el vSphere Essentials plus, pero se encontraría con un coste de aproximadamente 10K así por la obra y gracia del espíritu santo. Y este gasto ¿para ganar qué? bueno pues en su caso se quedaría con las mismas prestaciones que tiene: HA y vMotion y se beneficiaría de todas las virguerías técnicas de vSphere 5... Claramente el cliente se va a llevar un buen susto y un cabreo considerable, que lógicamente querrá compartir con el Partner que le ha vendido la solución, probablemente responsabilizándolo del diseño hardware del entorno.

Ejemplo 2: Cliente con Enterprise.

Un cliente potente con miles de usuarios que tiene 20 hosts con 2CPU cada uno y 144GB de memoria RAM por host, con su vCenter Standard y sus licencias Enterprise chachis. Probablemente también haya adquirido el Windows Datacenter para poder levantar centenares de VMs. Este cliente ha comprado 40 licencias de vSphere Enterprise, con un coste bien guapo. Veamos qué puede hacer.

1. No actualizar a vSphere 5.0. Ya lo hemos comentado en el caso anterior. Al ser un cliente bastante grande se supone que va a querer estar a la última tecnológicamente y va a tener que plantearse un día u otro el upgrade. Tiene 7 años para pensárselo.

2. Actualizar a vSphere 5.0 tal cual. Le saldrá una alarma permanente cuando levante las VMs y aparecerán alarmas continuas diciéndole que es un piraaaaaaaaaaata.

3. Actualizar a vSphere 5.0 y quitar RAM de sus Hosts. Lo mismo que comenté antes, que me la den a mí. Las VMs que ahora no va a poder levantar, pues no sé... que las apague o las vaya encendiendo por horas, rollo racionamiento de agua en épocas de sequía. Imagino que el cliente no se va a poner muy contento que digamos. Los usuarios igual si que están felices porque no podrán trabajar tantas horas como antes :-)

4. Actualizar a vSphere 5.0 y legalizar su situación a nivel de licenciamiento de vRAM. Tendría que comprar, vamos a ver cuántas licencias. Ahora tiene 144GB de RAM x 20 hosts, esto hace la friolera de 2.880GB de RAM, bien. Tiene adquiridas y en mantenimiento hemos dicho que 20x2=40 licencias de vSphere Enterprise. Cada licencia Enterprise soporta 32GB de RAM, pues bien, 32GB de vRAM x 40CPU = 1.280GB de vRAM licenciado. Hasta 2.880, pues son 2.880-1.280=1.600GB de RAM física que le quedan por licenciar. Échale guindas al pavo que yo le echaré a la pava... Esto son 1.600GBvRAM / 32GBvRAM por cada CPU = 50 licencias de nada que tiene que comprar. Cada licencia vale $2.875 + el mantenimiento que vale sobre el 10%, pongamos que valga $287 y lo añadimos, ya que es obligatorio. Así pues 2.875+287=3.162$ cada licencia. Vamos a redondear en 3.000$. Tiene que comprar 50 licencias, así pues 3.000*50= $150.000 no está nada mal... Ciento cincuenta mil dólares del Ala. Bueno, igual es un cliente grande de esos para los que 'el tema económico no es nada importante' :-) O igual al responsable TIC le da un ataque al corazón, que también podría ser.

Mis reflexiones al respecto

Así podríamos seguir enumerando un ejemplo y otro y otro... ¿Qué beneficio tienen estos clientes? seguro que si ponemos en una balanza las novedades de vSphere y la hostia de licenciamiento que tienen que pagar, la mayoría lo van a ver como un gran paso atrás.
Hay momentos en los que un fabricante se despega de la realidad, sumido en su éxito tremendo en el mercado y parecen olvidar a sus clientes, que son quienes les sustentan en su posición comercial. Le pasó a Microsoft y, a pesar de la cagada impresionante de Windows Vista, seguían en su mundo de fantasía diciendo que era un gran producto y que los fallos eran de los demás... ¿Parece como si vmware estuviese sufriendo ese síndrome en la actualidad? Espero que no. Pero claramente no han preguntado a ningún Partner o Cliente qué les parece este tipo de licenciamiento de Cloud aplicado a las licencias definitivas.
A mí me parecería genial que implementasen este tipo de licenciamiento opcionalmente para entornos de nube privada, vaya para licenciamientos definitivos y que también pudieses acogerte al modelo vigente de límite de cores que a nadie le hace daño y que cada cliente adopte el que mejor le convenga.

Me parece muy bien que en la nube, al tratarse de un mercado nuevo, se imponga el licenciamiento que se considere más adecuado, en este caso la modalidad de licenciamiento por vRAM yo la veo bien y permite a un proveedor de servicios en la nube, como pueda ser mi empresa, tener en un host 3 pastillas de RAM de 8GB para cada cliente y que paguen una licencia de vSphere de la edición que mejor se considere cada uno de ellos. Yo aprovecho el valor de los hosts, les saco todo el partido a nivel de capacidad de RAM y todos contentos.
Sin embargo esta imposición 'sí o sí' de este licenciamiento, sin previo aviso creo que va ocasionar más de un problema en clientes satisfechos, sin ninguna necesidad.

Espero que alguien de vmware reflexione y se flexibilice este tipo de licenciamiento que me parece un grave error por parte del líder del mercado de la virtualización.

¿Cuál es vuestra opinión?

Espero vuestros comentarios. ¿Qué pensáis? Alguna persona de vmware me ha dicho que el 95% de los casos que él ha contemplado van a quedar igual, sin que el cliente tenga que pagar ni un €. Opináis igual?

Agradeceré vuestras opiniones, como siempre.

vExpert 2011


Quiero agradecer a todos los que me habéis nominado, un año más, para vExpert 2011. Hace unos días recibí el mail de John Troyer comunicándomelo.

Os estoy muy agradecido, de verdad, por confiar, un año más en este blog.