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

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.

José Luis Gómez Ferrer de Couto

José Luis Gómez Ferrer de Couto

VMware vExpert since 2011 / VCP-DCV 4&5 / VCP5-DT / VCIX-NV / VCAP5-DCA/DCD / VCAP-CIA. Technical Architect at Computacenter. Author of blog PiPo e2H specialized in Virtualization, Storage and Networking.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

Share

¿Te gustó este artículo?

¡Suscríbete a nuestro feed RSS!