PiPo e2H – Soluciones TIC Avanzadas Jose Luis Gomez – vEXPERT 2011-16, VCIX-NV, VCAP5-DCA/DCD/CIA, CCA, CCNA & VCP 4&5

20Jul/1512

‘Hiperconvergencia’: ¿moda o necesidad?

Share

Nutanix-NoSAN2Hablar de hiperconvergencia es hablar de actualidad, desde hace poco más de un mes vengo notando que ha aumentado la actividad en redes sociales y blogs. Quizás provocado por la última de muchas batallas pero no definitiva entre VMware y Nutanix. Chuck Hollis, empleado de VMware, ha publicado una serie de artículos donde intenta mostrar la superioridad de VMware VSAN, núcleo de su producto hiperconvergente VMware EVO:RAIL versus Nutanix, líder actual del mercado hiperconvergente. Pero, ¿es la hiperconvergencia una moda o una necesidad?

Como toda nueva tecnología, esta comienza como una moda donde pocas corporaciones disponen de acceso a ellas, ya porque sólo estén disponibles en ciertos países, o por que su precio en el mercado y casos de uso estén limitados a ser usada por muy pocos. Hace ya más de dos años que escribí uno de los primeros artículos sobre hiperconvergencia en España, y después de este tiempo, puedo decir que la penetración que ha tenido la hiperconvergencia en España es insignificante.

¿Es España un mercado para la hiperconvergencia?

Si alguien me hiciera esta pregunta mi respuesta sería un "No", pero con ciertos matices. La adopción de una tecnología siempre viene dada por sus casos de uso y que estos cubran los requisitos de una organización con unos costes controlados y un ROI evidente.

Las soluciones hiperconvergentes están pensadas para llevar a cabo una alta consolidación de las cargas de trabajo existentes, mejorando la eficiencia de las operaciones de la infraestructura, y aportando la escalabilidad linear necesaria para esas organizaciones que necesitan un rápido crecimiento mensual, todo ello con una gran eficiencia energética y una reducción cercana al 50% de espacio en el centro de datos. Con este mensaje resulta atractivo para cualquier corporación el querer adoptar soluciones hiperconvergentes en sus centros de datos, pero la realidad es absolutamente otra.

Los fabricantes empujan con sus mensajes comerciales a crear una necesidad que antes no existía en los clientes. Lo habitual es que se quiera vender un producto del que se es nuevo distribuidor o que está de moda, en vez de escuchar las necesidades y retos que tienen y ofrecerles una solución que cumpla con sus requisitos. Por eso, cuando veo presentaciones por parte de fabricantes sobre estos productos y dicen que el mercado español esta preparado para adoptarlos, me hace pensar que me toman por bobo.

Prueba de ello, es uno de los vídeos que Ncora TV realizó durante el VMworld 2014. En el vídeo resumen de este evento podemos ver como entrevistan a dos empleados de VMware, y no dos empleados cualesquiera, hablo de Juergen Kuehlewein (Senior Director, EMEA Channel & General Business - en pocas palabras responsable de canal en EMEA); y de Duncan Epping (Chief Technologist at VMware Office of CTO - perfil técnico y persona relevante en VMware). Aquí se observa dos puntos de vistas completamente distintos, el comercial que siempre intenta vender la solución y mostrar que es adaptable a cualquier mercado, y el punto de vista racional que siempre aporta la parte técnica, donde evalúa los requisitos del cliente y lo que realmente encaja con ellos.

Como bien indica Duncan, el hardware es el que es y por ahora VMware EVO:RAIL esta disponible con una configuración hardware muy estricta en lo que a CPU, RAM y almacenamiento se refiere. Por el contrario, Nutanix ha comprobado que si no bajan las capacidades hardware de sus dispositivos, lo tienen bastante difícil para poder competir con las soluciones tradicionales en el mercado español y europeo.

Casos de uso

Cuando tratas vender una tecnología es importante conocer los casos de uso de esta, pero más importante es detectar cuáles de estos casos de uso aplican al mercado en el que te mueves. A continuación encontrarás los casos de uso que aportan los fabricantes con su experiencia adquirida, pero intentaré aplicar la lógica en cada uno de ellos de cara al mercado español y ver cuáles realmente encajarían.

Propósito general (virtualización de servidores y aplicaciones de negocio). Si echamos un ojo a los datasheets de los distintos fabricantes observaremos que la media de cargas de trabajo virtuales que pueden ejecutarse en un bloque (4 nodos) es de aproximadamente 100 máquinas virtuales.

Cuando compras un nuevo hardware o renuevas el existente para tu plataforma de propósito general, siempre intentas ajustar lo máximo posible los recursos de tus hipervisores para que soporten tus máquinas virtuales actuales y tu previsión de cara a 3-5 años (+ 20% según expectativas). Si hablamos que en España el 99,88% son PYME (entre 0 y 249 empleados) y que de ahí sólo el 1,1% son medianas (entre 50 y 249 empleados), podríamos deducir que el número de máquinas virtuales que están ejecutando en sus centro de datos no supera y siendo optimista una media de 50 cargas de trabajo virtuales. Si a esas 50 máquinas virtuales le añadimos el 20% de crecimiento que esperamos en 3-5 años, hablamos de 60 cargas de trabajo totales, muy lejos de las 100 máquinas virtuales de media que soporta un bloque de una solución hiperconvergente.

Podría llegar alguien y decir que existen otros muchos beneficios en la hiperconvergencia que el de consolidar cargas de trabajo, como pueden ser el ahorro de consumo energético y de espacio en el centro de datos, su simplicidad a la hora de desplegar, su escalabilidad, su alta disponibilidad, etc. los cuales para mi son todos propensos a discusión en el mercado español.

Consumo energético. ¿El ahorro es realmente significante en una infraestructura de una PYME donde con suerte tienen una media de tres hipervisores y almacenamiento, respecto al coste que tiene una solución hiperconvergente? Mi respuesta es NO.

Menos espacio. ¿Cuántas PYME veis que tengan problema de espacio? La gran mayoría al menos tienen una habitación o trastero del tamaño de un rack y con eso van sobradas. ¿Es motivo el espacio a la hora de adquirir una solución hiperconvergente en la PYME? Mi repuesta es NO.

Simplicidad. ¿Realmente se requiere este tipo de simplicidad en los centros de dato de una PYME española? Depende del enfoque que la PYME ande buscando. Si van a realizar un proyecto de virtualización con su partner de confianza y van a delegar en ellos la administración del entorno, mi respuesta es NO aplica la hiperconvergencia. Por el contrario, si la PYME busca poder gestionar ellos mismos la solución sin personal cualificado, mi respuesta es SI aplica la hiperconvergencia. Pero volvemos a lo mismo, ¿se justifica el coste de este tipo de solución respecto a contratar los servicios del partner por 3-5 años? Mi respuesta es NO.

Escalabilidad. ¿De verdad que una PYME busca escalabilidad? Me hace gracia cada vez que ponen este argumento sobre la mesa cuando van a vender hiperconvergencia. ¿Por qué?, pues es simple y seguro que tanto cliente como consultor os vais a sentir identificados con la siguiente imagen, donde seguro que os vendieron o vendisteis algunos y que nunca llegasteis a llenar. Y que cuando quisisteis pasar de 32-bits a 64-bits os dijeron que no era posible y que teníais que cambiar casi todo por completo.

chassis

Así es, los famosos chasis y servidores "blade". Si te visita el comercial que te vendió en su momento esta tecnología, ten cuidado que podrá venderte también hiperconvergencia (xD!) Si el cliente está buscando escalabilidad, o tiene temor que la infraestructura se le pueda quedar corta, opta por recomendar servidores en formato "rack" donde el cliente pueda hacer "scale-up", lo que viene siendo añadir más RAM e incluso cambiar procesadores por otros con mayor capacidad de procesamiento y núcleos. ¿Hiperconvergencia para escalado horizontal en vez de vertical en la PYME? Mi respuesta es NO.

 Alta disponibilidad. ¿A caso una solución tradicional no es ya altamente disponible? La disponibilidad de una plataforma siempre viene de la mano de la inversión. La relación disponibilidad inversión es directamente proporcional, cuanta más disponibilidad quieres más has de invertir. Cuando se diseñan soluciones hay que tener siempre en mente evitar puntos únicos de fallo (SPOF), y las soluciones hiperconvergentes no son la excepción. ¿Tiene una solución hiperconvergente mayor disponibilidad que una tradicional? Mi respuesta es NO.

En definitiva, la hiperconvergencia que conocemos hoy en día NO está preparada para entornos de propósito general de la PYME española.

VDI. Si una vez más echamos un ojo a los datasheet de los fabricantes, podremos observar que para el caso de uso de escritorios virtuales hablan de 250 instancias por bloque (4 nodos). Este es el caso de uso por excelencia y por el cual comenzó la hiperconvergencia, pero aún así en España estos números siguen siendo elevados para poder amortizar una inversión en una plataforma hiperconvergente.

Existe una opción donde se podría alcanzar la media de cargas de trabajo por bloque. Esta consistiría en que convivieran los casos de uso de propósito general y VDI en la misma infraestructura subyacente, es decir, que el bloque adquirido sirva tanto para ejecutar servidores virtuales, como escritorios de usuarios.

ROBO (Oficina o sucursal remota). A este caso de uso no le voy a dedicar mucho tiempo, porque si estamos hablando de una oficina remota de 250 usuarios no estaríamos hablando de PYME en España. Este NO es un caso de uso aplicable a PYME española.

Cloud. Aquí diferenciaré entre privada y pública, aunque para mí como ocurriera con el caso de uso anterior, este no aplica a la PYME española. Una cosa son los deseos del cliente de poder contar con una nube privada, y otra es la realidad cuando se ponen los números encima de la mesa para ver los costes de esta. Así que me centraré en la gran empresa (a partir de 250 empleados).

Nube privada. Si se trata de una corporación donde sus gastos de "colo" (alquiler de espacio) resultan altos, requieren de terceros para desplegar, configurar y poner en producción nuevo hardware, buscan reducir el OpEx contando con una plantilla más reducida, necesitan escalar de forma horizontal cada mes, y sus cargas de trabajo críticas se encuentran en sistemas dedicados a este propósito, la hiperconvergencia SI es una solución prioritaria a tener en cuenta. En este caso es recomendable comenzar con una "PoC" (prueba de concepto) donde mover cargas de trabajo no críticas y que sus necesidades de rendimiento a nivel de almacenamiento puedan ser asumidas por las IOPS que ofrece un único nodo. Este último dato es importante tenerlo en cuenta, los fabricantes muestran que las IOPS en la hiperconvergencia escalan proporcionalmente con cada nuevo nodo, pero no especifican que una maquina virtual no puede consumir todas las IOPS del clúster, sino sólo la del nodo donde se encuentra ejecutándose.

Nube pública. La hiperconvergencia es una de las mejores soluciones para este caso de uso, pero con un gran matiz. La hiperconvergencia utilizada en la nube pública no es la ofrecida por los fabricantes, es decir, un proveedor de nube pública difícilmente se decante por utilizar VMware, Nutanix, o alguno de estos como su proveedor de hiperconvergencia. El motivo no es otro que el proveedor de nube pública "vive" de vender instancias de máquina virtual, por lo que su objetivo es reducir el TCO al máximo. Para ello se basa en la adquisición de hardware "white label" tanto a nivel servidor como en comunicaciones y todo funcionando con software libre lo que les permite una reducción importante de CapEx; y por otro lado una automatización cercana al 100% de todas sus operaciones, lo que les permite reducir el número de ingenieros al cargo de la plataforma y a su vez poder crecer con un OpEx reducido y controlado. La hiperconvergencia SI es una solución para un proveedor de nube pública.

Conclusión

En el último año he tenido oportunidad de viajar a lo largo del mundo y trabajar con corporaciones de distintos tamaños, desde plataformas virtuales con 25.000 máquinas virtuales y 24 PB de almacenamiento, hasta plataformas de 1.000 máquinas virtuales y 1 PB de almacenamiento. Como imaginaréis ninguna PYME española y europea entra en esa horquilla, pero os puedo asegurar que incluso en este tipo de corporación, he podido observar que la hiperconvergencia sólo es usada para los entornos VDI. Para sus nubes privadas siguen apostando por soluciones convergentes, ya que sigue existiendo limitaciones en cuanto al almacenamiento distribuido para cargas de trabajo de misión crítica.

En mi opinión, la hiperconvergencia en España no deja de ser un tema de moda como ocurre en otros muchos países, pero estoy seguro que en un par de años podremos ver que este tipo de soluciones empiezan a ser asequibles para la PYME porque los precios de hardware se reducirán, aparecerán nuevas configuraciones por parte de los fabricantes, y ajustarán sus software para que cuadre con este tamaño de corporación.

¿A que no comprarías un autobús escolar previendo que en un futuro tengas los suficientes hijos como para que sea rentable? No hagas lo mismo con tu inversión, existen otras muchas tecnologías que aportarán mucho más valor a tu negocio que simple hardware. Para mí, y que es una completa dejada en nuestro país, es la automatización. Si no has empezado a qué esperas, aporta agilidad a tu negocio y descarga de tareas innecesarias y repetitivas a tu reducido departamento de TI. Ahí si verás el beneficio cuando ese equipo de máximo tres personas empiezan a ir más desahogados y tengan oportunidad de sacar el trabajo que genera valor a negocio.

Recuerda, si el artículo ha sido de tu agrado no dudes en compartirlo en tus redes sociales.

Share
27Nov/140

El verdadero Software-Defined Data Center (SDDC)

Share

Cada día escuchamos el término Software-Defined Data Center (SDDC), pero siempre desde una perspectiva meramente orientada a la infraestructura.

El SDDC engloba mucho más que las áreas Software-Defined Storage (en adelante SDS) y Software-Defined Network (en adelante SDN), donde compañías como VMware entre otras buscan únicamente potenciar su terreno dejando de lado otros muy importantes como las operaciones del día 2 (Day 2 Operations) y la automatización del ciclo de vida del desarrollo de software (SDLC). Cuando se habla de SDDC se debería hacer siempre desde un enfoque holístico, donde la infraestructura es una parte más del ciclo completo del SDDC.

Retos

Para mejorar los procesos de negocio no basta con agilizar sólo el despliegue de infraestructura, sino también acelerar el despliegue de software, operaciones y gobernancia. Es decir, ofrecer una solución end-to-end completa, donde desde un cuadro de mandos se tenga una visión detallada del estado de nuestro SDDC respecto a negocio.

Este viaje hacia el verdadero SDDC no es cosa de meses, sino de un largo proceso que dura años y donde intervienen muchas áreas de la compañía alineadas con el departamento de TI. A lo largo de este camino, dos aspectos gozarán de un gran protagonismo: los procesos de negocio y la automatización.

Para el primero es necesario que la compañía se involucre y defina, si no cuenta con ello, todos sus procesos de negocio para poder trasladarlos al departamento de TI y así buscar su automatización. Existen distintas herramientas en el mercado que ayudan a crear estos modelados de proceso y posteriormente realizar simulaciones para conocer de forma aproximada cuál sería el resultado. Por mencionar alguna herramienta, Bizagi podría ser una opción.

Una vez modelados los procesos de negocio, se puede pasar a la automatización de estos. Resulta de gran ayuda dividir el proyecto en etapas y marcar objetivos asumibles y no pecar de optimistas. Los objetivos forman parte de áreas globales como:

  • Infraestructura
  • Desarrollo
  • Operaciones
  • Gobernancia

Para lograr automatizar cada un de las áreas anteriormente mencionadas y que interactúen entre ellas de forma lo más integradas posible, es necesario que los componentes de estas cuenten con API accesibles y utilizar un orquestador que soporte múltiples protocolos de comunicación. Una posible opción es vRealize Orchestrator, que está disponible en toda organización que cuente con una plataforma vSphere gestionada a través de vCenter.

Infraestructura

Cuando hablamos de automatizar la capa de infraestructura se nos viene a la mente la palabra virtualización, donde existen distintas tecnologías que permiten virtualizar el cómputo, el almacenamiento (SDS) y la red (SDN). Todo estos componentes de forma separada pueden ser automatizados, habría que realizar una instalación de vSphere (cómputo), VSAN (SDS) y NSX (SDN), pero realizar instalaciones manualmente no es el objetivo, sino conseguir automatizar ese proceso y reducir el tiempo de despliegue lo máximo posible, por ejemplo de días a minutos. Para ello se requiere de un desarrollo software, conocimientos, tiempo e inversión. Es el motivo por el cual apareció el concepto “hiperconvergencia”.

Fuente: Cortesía vmware.com

La hiperconvergencia aporta esa flexibilidad, escalabilidad, y acelera el tiempo de entrega que se requiere como base para cualquier plataforma SDDC. Este paradigma busca simplificar el despliegue de cómputo, almacenamiento, red e hipervisor, creando un todo en uno por cada nodo (Fabric). Además del despliegue de servidores virtuales que cuentan con una instalación limpia del sistema operativo, también se pueden facilitar máquinas virtuales que incluyan de base servicios como Apache, WebLogic, MSSQL, etc. De este modo se rompe el esquema de lo tradicional, el cual dentro de unos años se considerará una infraestructura legacy. Para ampliar información sobre hiperconvergencia puedes visitar el siguiente artículo.

Fuente: Cortesía http://nutanix.com/

Desarrollo

Una vez dispuesta la capa de infraestructura donde se tiene la capacidad de entregar IaaS o PaaS de forma ágil, hay que ofrecer a los equipos de desarrollo, calidad y negocio, la capacidad de poder desplegar y probar las nuevas versiones de las aplicaciones que se desarrollan. Para ello es importante que esta tarea se pueda automatizar igual que ocurriera a nivel de infraestructura. Aquí entran en juego conceptos como la integración continua, el desarrollo continuo, y el despliegue continuo.

Siguiendo SDLC, el objetivo sería como mínimo desplegar de forma continua y automatizada las nuevas versiones de producto en los distintos entornos de DEV, TEST, UAT, STAGE y PRE; dejando el entorno de PRO con un despliegue manual si negocio no puede asumir que existan pequeños bugs que no han sido identificados durante las pruebas de calidad.

Para automatizar este proceso es importante contar con una herramienta de integración continua. De las más conocidas e implantadas en el mercado es Jenkins CI, herramienta de código abierto que permite recuperar el código de repositorios como Git o Subversion, realizar la integración, solicitar las pruebas de calidad a una tercera herramienta, y desplegar la versión del producto resultante en cada uno de los entornos disponibles. Además, si se requiere probar un nuevo producto en un nuevo entorno diferente a los ya existentes, Jenkins CI puede integrarse con la capa de infraestructura y solicitar de forma automatizada a esta que despliegue un nuevo entorno para posteriormente inyectarle (push) la nueva versión del producto. Si deseas probar este proceso de integración continua y despliegue continuo, te recomiendo bajar el appliance virtual llamado Clinker, desarrollado por la startup sevillana, Klicap.

Fuente: Cortesía cloudbees.com

Operaciones

Con infraestructura y desarrollo automatizados, llega el momento de agilizar las operaciones y automatizar el mayor número posible. Habitualmente las compañías obvian que los sistemas tienen que seguir siendo gestionados, independientemente del nivel de automatización que se haya conseguido. Cuando se automatizan cosas como el despliegue de infraestructura, y los tiempos de entrega de una máquina virtual o entorno pasan de días a horas, incluso minutos, es muy fácil que proliferen de forma descontrolada y como si de una barra libre se tratase, el número de máquinas virtuales y sus correspondientes servicios. Este nuevo crecimiento se gestiona con el mismo personal existente, es decir, la compañía no contrata más administradores para gestionar los nuevos servidores. Entonces, si ya se tiene un equipo de operaciones que está al 100% y no da abasto (ocurre en cualquier compañía), ¿cómo van a asumir todo lo nuevo que se despliegue bajo demanda y sin control? Es lo que se conoce como operaciones del día dos (Day 2 Operations)

Los fabricantes se centran en agilizar las operaciones del día dos de sus productos, ocultando en muchos folletos y documentación que las operaciones del día dos no son sólo esas. Como ocurre con VMware, ellos difunden el mensaje de la importancia de las operaciones del día dos, pero siempre desde la perspectiva de escalar verticalmente añadiendo más recursos a una máquina virtual (Scale-up), la de escalar horizontalmente añadiendo más máquinas virtuales a una granja (Scale-out), o la de apagar, encender, o realizar tareas de red en estas.

Las operaciones del día dos incurren en tareas de mayor calado como es la gestión de lo que está dentro de la máquina virtual, es decir, administrar el sistema operativo invitado y todos sus servicios. Esta es una de las carencias que presenta VMware en su suite vRealize, y motivo por el cual difunden que disponen de integración con herramientas como Puppet o Chef.

Las herramientas de gestión de la configuración como Puppet o Chef, resultan vitales en la automatización de las operaciones. Basta con añadir el agente a la plantilla de máquina virtual y ya se dispondrá de control de cualquier máquina virtual desplegada desde esta. Estas herramientas permiten de forma centralizada y con poco esfuerzo, realizar modificaciones masivas de configuraciones en servidores físicos o virtuales, asegurando la homogeneidad de los parámetros a lo largo de una granja de servidores. Ahora, cambiar la contraseña de root en 25.000 servidores supondrá el mismo esfuerzo para el equipo de operaciones que cambiarla en un único servidor.

Otras áreas a cubrir con las operaciones del día dos son las de copia de seguridad y monitorización. La primera sería interesante que el software de backup utilizado soporte el auto descubrimiento de máquinas virtuales y su categorización por etiquetas, además de contar con API para su integración con el orquestador.

Fuente: Cortesía rackspace.com

Por otro lado está la monitorización de la infraestructura y los servicios que corren en esta. Con llegada de la nube híbrida y la automatización, el servicio de monitorización se ha convertido en pieza clave para el auto escalado (auto-scaling) y el desbordamiento en la nube (cloud-bursting). Con información tan valiosa en nuestras manos como es conocer el comportamiento de la infraestructura cuando se consume, nos permite analizar su tendencia y comportamiento y tomar medidas en base a KPIs. Os pongo el siguiente ejemplo:

Imaginad una compañía de juguetes que tras analizar tendencias detecta que la época del año en la que vende más juguetes es en Navidad. Este año han decidido no comprar más hardware en su Capacity Plan anual y han optado por auto escalar en un proveedor Cloud siguiendo un modelo de nube híbrida. Como ya disponen de la capa de infraestructura y desarrollo automatizadas, tienen la agilidad, flexibilidad y escalabilidad de poder desplegar nuevos nodos de un servicio tanto en su cloud privada como en su proveedor público, quedando la infraestructura como una simple commodity. Productos como RightScale ayudan a la gestión de plataformas híbridas.

Ocurre que no saben con exactitud cuándo van a empezar a llegar las compras, ya que las rebajas comienzan más tarde y tal vez esperen a que los precios de los productos bajen. Es por ello que marcan un umbral de tiempos de respuesta en relación a las peticiones por segundo, y si este es superado durante un periodo de tiempo determinado, se invocará un workflow en el orquestador y creará nuevas máquinas virtuales hasta que los tiempos de respuesta se normalicen respecto a las peticiones. De igual modo, cuando hayan bajado el número de peticiones por segundo debido a que la Navidad finalizó, el orquestador de forma automática y apoyado por la herramienta de monitorización ejecutará un workflow para destruir todo aquel servidor virtual que ya no sea necesario.

Esta flexibilidad y nivel de automatización harán que negocio y por supuesto el equipo de operaciones, se preocupen menos en si estarán listos o no para asumir el aumento de peticiones. Además, para la compañía supondrá una reducción de CAPEX, ya que no han adquirido nuevos nodos de virtualización y sólo pagarán lo que hayan consumido en el proveedor público, incluso tendrán más fiabilidad y flexibilidad, ya que si hubiesen adquirido los nodos y la carga que llega es más que la que pueden soportar, esto supondría un problema y no estarían en disposición de ofrecer el servicio en un corto periodo de tiempo, mientras que con un proveedor Cloud no tendrán ese inconveniente y podrán escalar cuando y cuanto quieran. También existe una reducción en el OPEX, ya que no tendrán que contratar externos para que ayuden al equipo de operaciones a desplegar los servidores que suponen necesarios para asumir la carga.

Fuente: Cortesía domenech.org

Gobernancia

La automatización de todas las áreas anteriormente mencionadas permiten agilizar la respuesta de TI respecto a negocio, pero una mala gobernancia de los entornos en cuanto ciclo de aprobaciones o control de los servicios desplegados pueden suponer un gran lastre que impactarán en la agilidad lograda en las otras áreas.

Cuando se habla del ciclo de aprobaciones es importante conseguir la armonía entre el número de niveles de aprobación, y los miembros de cada uno de esos niveles. Es decir, poner cinco niveles de aprobación ofrecerá mayor control y trazabilidad de los servicios desplegados, pero reducirá la agilidad del despliegue, ya que posiblemente las aprobaciones se demorarán días. Por el contrario, poner un único nivel de aprobación proporcionará agilidad pero tal vez una falta de control. En definitiva, se trata de enumerar los distintos blueprints disponibles en el catálogo de servicios e identificar quienes son los responsables de estos, para así poder modelar el proceso de aprobaciones de la forma más optimizada posible. También y no menos importante, cada uno de los niveles de aprobación deberían contar con al menos con tres aprobadores, ya que suele ser bastante común las coincidencias en vacaciones, enfermedades u otros aspectos externos que pueden bloquear el despliegue de una plataforma.

Respecto al control de los servicios desplegados, cuando se ha dicho que esta solución ayuda a la proliferación descontrolada de servicios, es importante llevar un control de estos y nada mejor que integrarlo con una CMDB. Durante la creación del workflow en el orquestador, una de las tareas a realizar será la de añadir cada uno de los componentes desplegados dentro de la CMDB, ya que resultará de gran ayuda para conocer cómo se encuentra la plataforma configurada, y qué servicios están desplegados. Además de la CMDB, será importante contar con un sistema de control de costes, donde se tenga una visión detallada de los costes por servicio, instancia de máquina virtual, y cuánto son los gastos con los distintos proveedores Cloud utilizados. Una de las soluciones más conocidas del mercado es ServiceNow, la cual dispone de una amplia gama de herramientas para la gobernancia TI de la plataforma.

Fuente: Cortesía vmware.com

Conclusión

Cada compañía debe analizar de forma detenida el estado en el que se encuentran para detectar cuales son sus carencias a la hora de poner en producción un nuevo servicio y su posterior administración. Conociendo estos puntos que se pueden mejorar es cuando hay que tomar las acciones, es decir, tal vez la compañía ya cuenta con un método de despliegue de software ágil pero carece de ese aspecto en el área de infraestructura, entonces tendrán que adoptar soluciones hiperconvergentes o similares para reducir los tiempos y mejorar en el despliegue. También puede ocurrir lo contrario, que ya cuenten con la agilidad en la capa de infraestructura pero no en la de software u operaciones.

Algo que hay que tener claro es que la transición hacia el concepto SDDC no es cosa de meses, sino que requiere de varios años y de un trabajo sin interrupciones, ya que las soluciones y nuevos productos creados por el cliente están en continua evolución y esto habrá que plasmarlo en los procesos ya automatizados.

Es ahora cuando los perfiles de arquitecto Cloud cogen fuerza para toda la parte de infraestructura e integración con proveedores Cloud públicos, igual que ocurre con los DevOps para todo lo que es la capa de integración continua y despliegue continuo del software, así como las operaciones del día dos.

Recuerda, si el artículo te ha parecido interesante, no olvides compartirlo con tus contactos.

Share
8Jul/145

VMware VSAN hace agua en poco tiempo

Share

Antes de nada, puntualizar que este artículo es una opinión personal y que puede ser un punto de vista erroneo. Siguiendo de cerca este producto en su corto periodo de vida y habiendo tenido la oportunidad de probarlo, pienso que VMware VSAN hace agua en poco tiempo.

A lo largo del artículo se va dando información desde distintas fuentes donde se refuerza la idea de que VMware VSAN no está aún lo suficientemente maduro como para que juegue un papel importante en el centro de datos productivo actual.

¿Por qué hace agua?

Desde el 12 de marzo de 2014 que se anunciara la disponibilidad general del producto, han sido varios los errores/fallos que han ido apareciendo en este. Prueba de ello es consultar la base de conocimiento de VMware y los distintos bugs que se han ido solucionando en cada release.

Pero el aspecto más relevante que  me ha hecho tomar la decisión de escribir este artículo, ha sido la reciente actualización del KB2081431 donde indican que controladoras de almacenamiento no son soportadas por VMware VSAN.

Controladoras no soportadas

Otro de los motivos fue la discusión que mantuvieron varios empleados de VMware como Duncan Epping y el ex exmpleado y empleado de Nutanix, Andre Leibovici. En ella hablan de que VMware habla de VSAN sólo para entornos VDI, desarrollo y test, pero en ningún momento para entornos productivos con aplicaciones de misión crítica.

Para terminar, VMware ha ido lanzando varias versiones de su documento "ready nodes". Este documento cubre los modelos servidor que VMware ha probado para VSAN y certifican su correcto funcionamiento. ¿Dónde está la sorpresa? La sorpresa es que VMware en nuevas versiones de este documento ha ido eliminando hardware que estaba soportado desde un primer momento, como es el caso de Cisco UCS.

Esto habrá provocado que varios clientes que hayan comprado ese hardware certificado por VMware, ahora se ven en la situación que no está soportado (Vaya gracia!!!) Es por ello que Duncan Epping en un artículo de su blog indica que estos clientes que tienen controladoras no soportadas contacten lo antes posible con atención al cliente (Tremendo!!!)

Desde aquí y como iniciativa tras hablar con Tony Doval (@tonydoval), estaría genial que igual que VMware lanza un documento llamado "ready nodes" donde recomienda el hardware a utilizar sin necesidad de realizar configuraciones personalizadas, también lanzara en ese mismo documento un apartado de switches 1Gb y 10GbE recomendados para su producto. Con este nuevo paradigma del almacenamiento distribuido, la red de comunicación donde los nodos intercambian su información juega un papel importante.

¿Apostar por VMware VSAN?

Personalmente me declaro un activista de este tipo de soluciones, pienso que son el futuro y que dotará de agilidad y facilidad de gestión en los centro de datos de medio y gran tamaño.

VMware VSAN es un producto que aún no está maduro y es necesario dejarlo crecer y ver qué otras opciones van apareciendo por el mercado. Pero estoy seguro que VMware VSAN terminará formando parte de muchas plataformas en nuestro país.

Recuerda, si el artículo ha resultado de tu interés, se sociable y compártelo en las redes sociales con tus contactos.

Share
24Jun/144

Configurar VSAN

Share

Para configurar VSAN se necesita cumplir con los siguientes requisitos como mínimo (KB2058424):

  • Tres nodos ESXi 5.5 con al menos 1 disco SSD y 1 disco SAS/SATA
  • 6GB RAM por nodo ESXi
  • Cluster gestionado por vCenter 5.5
  • Adaptador de red 1Gbps dedicado para VSAN por nodo ESXi
  • Para más información, consultar el KB arriba indicado.

 

Este ejemplo se realiza sobre la siguiente plataforma:

  • VMware Workstation 10
  • Tres nodos ESXi 5.5 con las siguientes características comunes:
    • 2 x vCPUs
    • 6GB RAM
    • 1 SSD 6GB para hypervisor
    • 1 SSD 10GB para VSAN
    • 1 SSD 50GB para VSAN convertido a SATA quitando el flag de SSD (ver procedimiento más abajo)
    • 1 NIC para gestión y VM (NAT)
    • 1 NIC para VSAN (host only)
    • 1 NIC para vDS (host only)

Desmarcar un dispositivo SSD autodetectado

Debido a que no se dispone de disco SAS o SATA, ha sido necesario simular el disco SSD de 50GB como un no-SSD. Para ello hay que quitar el flag de SSD ejecutando los siguientes comandos. Si no es tu caso, puedes saltar estos pasos e ir a la configuración de red.

  • Listar la lista de dispositivos e identificar el disco de 50GB con el tag SSD habilitado. Copiar el identificador en formato naa. o mpx.

esxcli storage core device list|more

  • Identificar la regla SATP en uso para el disco deseado, en nuestro caso VMW_SATP_LOCAL

esxcli storage nmp device list

  • Cambiar el flag de SSD a deshabilitado (los atributos en cursiva a rellenar según los datos anteriormente recogidos)

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device mpx.vmhba1:C0:T2:L0 --option disable_ssd

  • Reclamar el dispositivo

esxcli storage core claiming reclaim --device mpx.vmhba1:C0:T2:L0

  • Comprobar que el disco aparece como Is SSD: false

esxcli storage core device list -d mpx.vmhba1:C0:T2:L0

Configuración de red

Para configurar VSAN es necesario tener una red VMkernel dedicada para tal propósito. Esta configuración se ha de realizar desde vSphere Web Client, ya que es necesario marcar una casilla de VSAN que no está disponible en el cliente tradicional.

  1. Accede al vSphere Web Client y selecciona el host ESXi que deseas configurar
  2. Haz clic en la pestaña Manage y posteriormente en Networking
  3. Selecciona VMkernel Adapters de la lista desplegable
  4. Haz clic en Add host networking y posteriormente en Next
  5. En la página de propiedades del puerto selecciona la opción Virtual SAN traffic y configura los valores según tu configuración de red.
  6. Finaliza la configuración y repite estos pasos con cada uno de los hosts ESXi
Configurar VSAN

Crear red VMkernel

Configurar VSAN

Si dispones de un cluster ya creado sólo tendrás que marcar la opción de VSAN en la configuración del cluster. De no ser así, crea un cluster nuevo marcando la opción de VMware VSAN y añade los tres hosts ESXi.

  1. En vSphere Web Client haz clic con el botón derecho sobre un datacenter y elige New Cluster
  2. Escribe un nombre y marca la casilla de Virtual SAN Turn On
  3. Selecciona el modo de reclamar los discos como Manual. En mi caso como Automatic no funcionó, tal vez por estar trabajando con Workstation 10
  4. Añade los hosts al cluster creado
Configurar VSAN

Crear cluster y habilitar VSAN

En este momento se habrá creado un datastore de tamaño 0 bytes llamado vsanDatastore. Cuando se le asignen los discos correspondientes este pasará a disponer de espacio. Es importante saber que sólo los discos magnéticos aportan capacidad a un datastore de VSAN, es decir, los discos SSD sólo realizan las funciones de caching.

Para reclamar los discos que están sin uso hay que realizar los siguientes pasos:

  1. En vSphere Web Client elige el cluster creado y haz clic en la pestaña Manage
  2. Elige en el menú desplegable la opción Virtual SAN --> Disk Management
  3. Aparecerán los tres hosts ESXi y el número de discos utilizados dentro de los detectados
  4. Haz clic en Claim disks y selecciona todos los discos haciendo clic en Select all eligible disks
Configurar VSAN

Reclamar los discos para VSAN

Ahora sólo falta comprobar que tu datastore de VSAN dispone de espacio y comenzar a desplegar servidores virtuales

Configurar VSAN

Recuerda, si el artículo ha resultado de tu interés, se sociable y compártelo en las redes sociales con tus contactos.

Share
12Mar/140

Precio VMware VSAN

Share

Ayer VMware anunció que ya está disponible VMware VSAN al haber liberado VMware vSphere 5.5 Update 1. Desde esta versión VMware VSAN pasa de ser versión Beta a GA. Con este movimiento también se conoce ya el precio de VMware VSAN, donde puede obtenerse con distintos tipos de licenciamiento. Ahora que ya existen varios productos en el mercado que ofrecen casi las mismas funcionalidades, es hora de que comience la batalla de precios para conseguir que este tipo de tecnología sea más asequible para cualquier tipo de empresa. Abajo podrás consultar en dolares las distintas modalidades de licenciamiento y los bundles disponibles que existen por un tiempo limitado.

  • VMware Virtual SAN
    • Licencia independiente sin límite de escalado. Se licencia por socket CPU.
    • Todas las funcionalidades
    • Capacidad ilimitada
    • vSphere Distributed Switch
    • Todos los hosts en un cluster con VSAN han de estar licenciados
    • $2.495 por CPU
  • VMware Virtual SAN para Escritorios
    • Licencia independiente para ser usada sólo con escritorios virtuales.
    • Todas las funcionalidades
    • Capacidad ilimitada
    • vSphere Distributed Switch
    • $50 por conexión concurrente
  • Bundle para actualizar desde VSA
    • Actualización desde vSphere Storage Appliance a Virtual SAN
    • No hay una actualización directa desde VSA
    • Se requiere instalación manual y actualización
    • El bundle incluye 6 CPUs licenciadas
    • Disponible hasta el 15 de septiembre de 2014
    • $9.180
  • VMware Virtual SAN con Data Protection
    • Bundle de VSAN con vSphere Data Protection Advanced
    • Todas las funcionalidades
    • Capacidad ilimitada
    • vSphere Distributed Switch
    • Disponible hasta el 15 de septiembre de 2014
    • $2.875 por CPU
  • Promoción Beta
    • VMware ofrece un descuento del 20% para usuarios que han participado en la Beta
    • Todas las funcionalidades
    • Capacidad ilimitada
    • vSphere Distributed Switch
    • Se requiere una compra mínima de 10 licencias (sólo primera compra)
    • Disponible hasta el 15 de junio de 2014
    • $1.996 por CPU

Como podéis observar, licenciar tres hosts utilizando sólo 1 socket por host tendría un coste de la nada desdeñable cantidad de $7485. Luego habrá que añadir el coste de las licencias de vSphere, más el coste de los tres servidores y los discos. Como diría el gran Josep Ros: "Esta TOO PAGAOOOO!

Recuerda, se sociable y comparte el artículo si lo consideras interesante.

Share