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

27nov/140

El verdadero Software-Defined Data Center (SDDC)

automation

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.

10oct/140

Tech Field Day en VMworld Europe 2014

TFD_Logo

Tech Field Day conocido por sus eventos IT sobre productos innovadores, llega por primera vez a Europa de la mano de su organizador Stephen Foskett y su equipo. Su llegada a Europa se debe al VMworld Europe 2014 que tendrá lugar en Barcelona como bien sabéis, y donde el Blog PiPo e2H estará presente para haceros llegar día a día toda la información relevante sobre nuevos anuncios de los distintos fabricantes, incluido por supuesto, VMware.

El Tech Field Day está dividido en distintas áreas tecnológicas como son: Networking, Storage, Wireless, Virtualization, y el propio Tech Field Day que son eventos extras que suelen tener lugar en eventos como VMworld, Interop, Cisco Live, entre otros. Además también tienen una versión Live, donde realizan las sesiones de cara al público en algún auditorio del evento en el que se encuentren.

Para mí es todo un orgullo haber sido invitado como delegado para participar por primera vez en estas sesiones, donde tendré la oportunidad junto con el resto de miembros de destripar los productos que X-IO, VMTurbo, Diablo y Veeam presentarán en las distintas sesiones que tendrán lugar miércoles y jueves.

Os iré informando de cómo avanza todo. Y recuerda, si consideras este artículo interesante no dejes de compartirlo con tus contactos.

19sep/140

VMware NSX. La solución Software-Defined Networking de VMware

vmware-nsx21

Como habrás oído hablar desde hace un año, y más aún las últimas semanas tras el VMworld 2014 US, la compañía del hypervisor más desplegado en el mundo anunció la nueva versión 6.1 de su producto VMware NSX. El producto forma parte de las soluciones disponibles en el mercado enfocadas al Software-Defined Networking (a.k.a. SDN). Aunque en realidad este producto fue adquirido tras la compra de la compañía Nicira en Julio de 2012, VMware ha potenciado su desarrollo mejorando el producto e incluso añadiendo funcionalidades disponibles en vCloud Network & Security (a.k.a. vCNS). El plan de VMware es continuar desarrollando únicamente NSX y su integración con sus distintos productos así como con terceros, y descontinuar el desarrollo pero no soporte de vCNS.

¿Qué es VMware NSX?

Como ya se ha indicado, VMware NSX es la solución Software-Defined Networking de VMware. Con este producto VMware busca dotar a proveedores cloud y grandes entornos la capacidad de tener mayor agilidad, reducir costes, escalar ofreciendo un alto rendimiento, y mejorar la seguridad de las aplicaciones que consumen redes virtuales independientemente del hypervisor que las hospede.

VMware NSX dotará de mayor flexibilidad a la hora de escalar el centro de datos bien en la misma ubicación, o extendiendo este a lo largo de múltiples localizaciones. Todo ello gracias al soporte de distintos protocolos como VXLAN (buen artículo del VCDX Agustín Malanco), Stateless Transport Tunneling (a.k.a. STT) y Generic Routing Encapsulation (a.k.a. GRE).

¿Cómo funciona VMware NSX?

VMware NSX como solución SDN que es, busca llevar la virtualización a los dispositivos de red. Igual que ocurriera con la virtualización de servidores donde el hypervisor es agnóstico al hardware que utilices (siempre hardware soportado por la HCL), la virtualización de los dispositivos de red consiste en tener dispositivos que ofrezcan conexión (switches) donde lo importante son los recursos como ocurre con el de computo para los hypervisores. Este símil intenta exponer que lo importante de los dispositivos de conexión será su número de puertos, velocidad y tipo de conexión, así como el backplane y capacidad de conmutación del switch (a.k.a. Data Plane); la lógica estará completamente delegada a el/los controladores NSX (a.k.a. Control Plane). Sería como tener metido un ESXi en cada dispositivo de conexión y todos gestionados desde vCenter.

Diagrama SDN

A día de hoy VMware NSX no tiene la capacidad de poder gestionar la lógica de switches físicos, aunque se prevé que puedan soportar esta funcionalidad en breve. En estos momentos, VMware NSX está capacitado para soportar la virtualización de redes pero únicamente funcionando sobre hypervisores como ESXi, Xen Server o KVM; o plataformas de gestión Cloud como vCloud Automation Center, OpenStack o CloudStack.

Teniendo en cuenta que VMware NSX en estos momentos no gestiona dispositivos físicos, el diagrama conceptual de funcionamiento del producto es el siguiente:

Diagrama NSX

Data Plane

Compuesto por los servidores ESXi, el data plane ofrece un alto rendimiento al tráfico de las máquinas virtuales. VMware NSX es habilitado desde NSX Manager y siempre se configura sobre un cluster, instalando en cada uno de los miembros el módulo kernel de NSX.

VMware NSX requiere de vSphere Distributed Switch (a.k.a. VDS) para su funcionamiento, por lo que será necesario tener licenciados tus hosts ESXi con la edición Enterprise Plus. Cumpliendo con este requisito, tendrás la capacidad de crear switches lógicos, routers lógicos distribuidos (a.k.a. DLR) y firewalls sin necesidad de desplegar máquina virtual alguna, ya que estas funcionalidades son proporcionadas por el módulo kernel instalado. Adicionalmente si requieres funcionalidades del tipo NAT, DHCP, VPN, balanceador o alta disponibilidad, es necesario desplegar NSX Edge que es un servidor virtual que ofrece estas capacidades.

Control Plane

Compuesto por uno o varios NSX Controller(s), gestiona la lógica de todas las redes virtuales y se encarga de la comunicación con el Data Plane. Los NSX Controllers se pueden desplegar según necesidades de rendimiento o disponibilidad, es decir, mínimo deberían existir dos NSX Controllers para dotar de disponibilidad, y después escalar en horizontal (a.k.a. scale-out) cuando se necesite más capacidad lógica.

Management Plane

Está compuesto por NSX Manager, el cual proporciona un punto único de configuración y el punto de acceso de peticiones REST API en un entorno vSphere con NSX.

Consumo Cloud

VMware NSX se puede consumir directamente desde la interfaz gráfica de NSX Manager. En un entorno vSphere está disponible en vSphere Web Client, pero si quieres integrarlo con gestores cloud como vCloud Automation Center, vCloud Director o OpenStack con el plugin de NSX para Neutron también es posible.

Conclusión

VMware NSX es un gran producto enfocado a clientes que requieren agilizar la gestión de sus redes virtuales para así reducir su OPEX. También, este producto ayudará a reducir el CAPEX ya que con sus capacidades de enrutamiento y switching interno sin necesidad de subir al core ayudará a optimizar el consumo de los enlaces de red entre los hosts que contienen el hypervisor y la capa de distribución o core.

Aún no está disponible su descarga pero estoy impaciente de poder meterle la mano y ver qué tal se comporta e integra con herramientas de gestión Cloud como las anteriormente mencionadas.

Estad atentos a próximos artículos donde se irá profundizando en cada una de las funcionalidades y beneficios que ofrece VMware NSX.

Recuerda, si el artículo ha sido de tu interés, ayuda compartiéndolo.

29ago/142

VMware EVO:RACK. Escalabilidad del centro de datos en dos horas

evorack

Como se publicó en un artículo anterior, el pasado lunes 25 de Agosto en el VMworld 2014 de San Franciso, se anunció VMware EVO:RAIL, la solución hyper-converged de VMware. En ese anuncio también apareció otro nombre dentro de la familia de productos EVO, hablamos de EVO:RACK (pronunciado IVO RACK).

VMware EVO:RACK se encuentra en fase de desarrollo y su objetivo es permitir una gran escalabilidad en centros de datos que requieren una alta densidad de máquinas virtuales con un tiempo de instalación bajo para el nuevo hardware.

 

¿Qué es VMware EVO:RACK?

VMware EVO:RACK es una solución que aún se encuentra en fase de desarrollo y que busca ofrecer una alta escalabilidad con un tiempo reducido en la instalación del nuevo hardware. Esta plataforma está pensada para grandes centro de datos de proveedores Cloud o compañías con una importante plataforma Cloud privada.

Como su nombre indica, la solución vendrá instalada en un rack propio y su arquitectura será muy semejante a Oracle Exadata. Aunque el objetivo es proporcionar servidores y escritorios virtuales, aunque esperan entrar también en soluciones de análisis como Big Data con su división Pivotal.

VMware EVO:RACK escalará hasta 10 racks por el momento, permitiendo ser gestionado como una única entidad gracias a la federación de múltiples vCenter. Cada rack busca ser un PoD (Point of Delivery) cuadrando los distintos componentes a su máximo permitido.

Imagen cortesía de vmware.com

¿Qué compone VMware EVO:RACK?

VMware EVO:RACK será igual que EVO:RAIL pero también incluirá el hardware de red y posiblemente una herramienta de gestión enfocada a añadir EVO:RACKs similar a la de añadir nodos en EVO:RAIL.

Como hemos comentado, EVO:RACK será casi un clon de Oracle Exadata a nivel de rendimiento y escalabilidad, y parecido a IBM PureFlex, VCE Vblock, o NetApp FlexPod. VMware pretende seguir dos líneas hardware, una por el Open Compute Project, y otra siguiendo su alianza con Cisco y EMC con la solución VCE Vblock. El componente que siempre sufre modificaciones en Vblock es el almacenamiento, por lo que en EVO:RACK no será la excepción y se buscará una solución JBOD con conectividad DAS hacia X nodos que harán de almacenamiento y posiblemente otros sólo de cómputo.

Un rack vendría a estar compuesto de:

  • Hardware
    • Switches ToR (Top of the Rack) que podrán ser Nexus 2K conectados a Nexus 9k que soporta SDN.
    • Switches SAN si deciden no usar los puertos unificados que podrán ser MDS y si lleva almacenamiento SAN.
    • Switches InfiniBand si optan por almacenamiento distribuido y requieren alta tasa de transferencia con una baja latencia.
    • Servidores Blade que podrán ser Cisco UCS para alojar los servidores y escritorios virtuales.
    • Servidores Rack que harían la función de almacenamiento distribuido ya sea con discos internos o conectividad DAS (cuando esté soportada) y que conectarían por InfiniBand para su sincronización y por 10GbE con los Cisco UCS.
  • Software
    • Todo lo que incluye EVO:RAIL menos su Manager.
    • VMware NSX. Para toda la lógica y automatización de red.
    • EVO:RACK Manager. La herramienta de gestión del estilo de la de EVO:RAIL.

Imagen cortesía de vmware.com

Conclusión

Esta solución será esencial para proveedores de servicio donde verán reducido su CAPEX y sobre todo su OPEX gracias a la agilidad en su escalado. Además, tendrán un control exhaustivo de los costes por instancia de máquina virtual lo que les ayudará a tener controlada su inversión.

Con toda probabilidad en España será difícil ver estas soluciones, ya que estará accesible para bancos y teleoperadoras que apuesten por los servicios Cloud tanto públicos como privados.

Recuerda, si el artículo te ha parecido de interés, no dudes en compartirlo.

Archivado en: Noticias, VMware 2 Comentarios
27ago/140

VMware EVO:RAIL. El appliance hyper-converged de VMware

VMW-LOGO-EVO-Rail-108

El pasado lunes 25 de Agosto en el VMworld 2014 de San Franciso, se anunció VMware EVO:RAIL (pronunciado IVO REIL), la solución hyper-converged creada mediante la alianza de distintos fabricantes hardware con VMware.

VMware EVO:RAIL entra a formar parte del mercado de soluciones all-in-one junto a otras como Nutanix y SimpliVity. Como ya se ha hablado varias veces en el blog, estas soluciones all-in-one ofrecen cómputo, almacenamiento e hypervisor en un appliance compacto y con un scale-out rápido (+15 minutos) y sencillo.

 

¿Qué es VMware EVO:RAIL?

VMware EVO:RAIL es la última solución hyper-converged que se conoce en el mercado. Con esta solución VMware busca acelerar el despliegue de centro de datos automatizados de una forma rápida y sencilla (+15 minutos).

Esta solución NO se puede asemejar a adquirir VSAN y el hardware de forma independiente, ya que le falta toda esa lógica que consigue automatizar la instalación de ESXi, vCenter, VSAN y Log Insight.

Esta solución all-in-one proporcionará un punto único de soporte que será el fabricante hardware, lo que facilitará el soporte y posiblemente agilice la resolución de incidencias.

Las capacidades de VMware EVO:RAIL para servidores y escritorios virtuales son:

  • Servidores virtuales. Cada nodo podrá soportar aproximadamente 25 máquinas virtuales servidor, lo que son 100 servidores virtuales por appliance de 2U.
  • Escritorios virtuales. Cada nodo podrá soportar aproximadamente 65 máquinas virtuales escritorio, lo que son 250 escritorios virtuales por appliance de 2U.

¿Qué compone VMware EVO:RAIL?

VMware EVO:RAIL está compuesto de dos pilares fundamentales, la parte hardware y la inteligencia software. De la parte hardware se encargan fabricantes ya conocidos (VMware NO fabrica hardware!) que son:

  • Dell. El modelo elegido por el fabricante no se ha publicado aún (se rumorea el PowerEdge C6220 - Gracias @m_a_amigo), si sus especificaciones. Es probable que sea el mismo que se utiliza para Nutanix.
  • EMC. El modelo elegido por el fabricante para su integración con VMware EVO:RAIL es su plataforma "Phoenix", solución que ya utilizan para ViPR y ScaleIO.
  • Fujitsu. El modelo elegido por el fabricante para su integración con VMware EVO:RAIL es el PRIMERGY CX400.
  • Inspur. Aún no hay información disponible en su sitio oficial.
  • NetOne. Aún no hay información disponible en su sitio oficial.
  • SuperMicro. El modelo elegido por el fabricante para su integración con VMware EVO:RAIL es el SYS-2027TR-VRL001/002, distinta identificación pero mismo modelo que los utilizado por Nutanix.

Los componentes software incluidos en la solución son:

  • EVO:RAIL Rapid Deployment, Configuration, and Management. Es la interfaz utilizada para el despliegue inicial de la solución, ampliación de nodos, monitorización y por ahora despliegue básico de máquinas virtuales.
  • vSphere Enterprise Plus. Edición necesaria para contar con todas las funcionalidades avanzadas que agilizan la gestión (vSphere Distributed Switch, vSphere Host Profiles y vSphere Auto Deploy, Storage DRS y Profile-Driven Storage, Storage y Network I/O Control, y Flash Read Cache)
  • vCenter Server. Pieza esencial de la solución desde la cual se nutrirá EVO:RAIL para conocer la información de la plataforma.
  • VMware Virtual SAN. Pilar fundamental que proporciona un escalado horizontal sin la necesidad de adquirir un almacenamiento SAN.
  • vCenter Log Insight. Herramienta para gestionar y resolver incidencias de una solución que puede escalar rápidamente y se puede volver incontrolable.

Conclusión

VMware EVO:RAIL es una solución pensada para empresas de rango medio en USA, es decir, para grandes corporaciones españolas. No es una solución pensada para PYMEs, por lo que no existe debate alguno de que en España esta solución no cuadra. Como digo, en España cuadra, pero para grandes corporaciones que cada semestre/año ven crecer su infraestructura en más hosts ESXi y almacenamiento SAN. En mi opinión, las grandes corporaciones deberían comenzar a realizar PoCs para comprobar que estas soluciones son adecuadas para su negocio por la agilidad de despliegue, alto rendimiento, ahorro en CAPEX y OPEX, y consolidación de espacio en CPD y ahorro energético.

Estas soluciones por ahora no encajan en la PYME española por los siguientes motivos:

  • El número mínimo de nodos son tres, lo que equivale a 75 servidores virtuales o 200 VDIs. Tal vez si alojas tus servidores virtuales y escritorios en la misma plataforma, puede ser que encaje (hay que valorar el gasto en networking)
  • Se necesita adquirir tecnología de red 10GbE de baja latencia. El appliance no incluye los switches, y resulta que estos dispositivos tienen un coste elevado. Si sólo vas a adquirir tres nodos y vas a hacer una inversión en switches de 10GbE donde no vas a consumir más de 4 puertos por switch, ¿para qué hacer esta inversión?
  • La PYME española realiza una inversión a 4 años mínimo, compra todo el hardware de una vez y difícilmente vuelva a adquirir algo en 4 años. Si no realiza un Capacity Plan anual, es como venderles tecnología blade y nunca lleguen a llenar un chasis.

Recuerda, si el artículo te ha resultado de interés, no dudes en compartirlo.