D铆a: 30 julio, 2018

Calor y lluvias, un desaf铆o para la transformaci贸n digital del Centro de Datos

Las empresas est谩n invirtiendo en su innovaci贸n para alcanzar la transformaci贸n digital. En el centro de datos, esto se traduce en la necesidad de contar con una estrategia que les permita mantener la capacidad de desarrollar y dar soporte a los nuevos servicios digitales que las unidades de negocio requieren, con agilidad y eficiencia.

La llegada de nuevas tecnolog铆as marca la pauta de esta evoluci贸n, centrada en la nube h铆brida. Por un lado, este modelo se asocia a una mayor complejidad, ya que es preciso realizar la integraci贸n y gesti贸n del ecosistema diverso, y por otro las organizaciones tambi茅n necesitan proveer a sus centros de datos con una mayor automatizaci贸n, flexibilidad e hiper disponibilidad.

Seg煤n IDC, este a帽o se prev茅 un incremento de 18% en la inversi贸n en sistemas convergentes e hiper convergentes en el centro de datos, los cuales les permiten conformar el ambiente id贸neo.

Sin embargo, todo lo anterior es inservible si el data center sigue presentando interrupciones no planificadas, mismas que obstaculizan la hiper disponibilidad, base de la transformaci贸n digital.

Las altas temperaturas y las fuertes lluvias que tienen lugar durante primavera y verano dificultan el escenario. El calor favorece el sobrecalentamiento de los equipos; los servidores pueden llegar a apagarse por razones de seguridad y los procesadores aceleran su velocidad para brindar el rendimiento esperado. Igualmente, la humedad que aumenta en temporada de lluvias puede ocasionar afectaci贸n en el funcionamiento del centro de datos e, incluso, da帽o permanente en la infraestructura.

De acuerdo con el Reporte de Disponibilidad 2017 de Veeam, en M茅xico las brechas de disponibilidad ocasionan costos por $427.4 millones de pesos a las empresas, y 7 de cada 10 consideran que el costo por hora de tiempo inactivo se incrementar谩 en los pr贸ximos a帽os.

A ello se suman, por supuesto, afectaciones como p茅rdida de confianza de los clientes (con 77% de respuestas de los encuestados por Veeam), da帽os a la integridad de la marca (47%) y p茅rdida de confianza de los empleados (40%).

Pero no son los 煤nicos retos que enfrentan las 谩reas de TI con relaci贸n a sus centros de datos. Seg煤n indica IDC, los cambios tecnol贸gicos y de negocios que han tenido lugar en los 煤ltimos a帽os ejercen una gran presi贸n en los modelos tradicionales, por lo que es urgente su modernizaci贸n. Para la firma analista, la edad es uno de los desaf铆os principales, puntualizando que el promedio de ca铆das en instalaciones con 5 a帽os de antig眉edad es el doble del que se produce en los que tienen de 1 a 3 a帽os. Expone tambi茅n que en la era actual los centros de datos deben garantizar mayor agilidad, menores tiempos de planificaci贸n y reducci贸n de riesgos, ante el hecho de que las cargas de energ铆a van en aumento y la demanda de espacio, capacidad e infraestructura son imprescindibles y var铆an r谩pidamente.

As铆 que son tiempos de cambio. Por un lado, ante la posibilidad de condiciones clim谩ticas adversas o eventualidades diversas, las organizaciones deben asegurar que sus instalaciones se encuentran protegidas y cuentan con una continuidad de las operaciones garantizada. Y, por otro lado, en el ambiente digital actual, dominado por altas exigencias en torno a velocidad y capacidad de respuesta, las soluciones tradicionales de respaldo y recuperaci贸n ya no son suficientes.

Para alcanzar la hiper disponibilidad, es imprescindible contar con un manejo inteligente de datos, aplicaciones e infraestructura, el cual maximiza la agilidad y eficiencia del centro de datos y brinda mayor tolerancia a fallas.

 

Por: Carlos Ram铆rez,

Ingeniero de Sistemas,

Veeam M茅xico.

驴Cu谩l es el futuro de la virtualizaci贸n de servidores?

La virtualizaci贸n de servidores es una de esas tecnolog铆as que tiene un concepto simple y un impacto profundo en los centros de datos empresariales.

驴Qu茅 pasar铆a si, en lugar de ejecutar una instancia de sistema operativo y una aplicaci贸n por servidor, puede agregar una capa de software, conocida como hipervisor, que le permite ejecutar varias instancias del sistema operativo y las cargas de trabajo asociadas en un 煤nico servidor f铆sico?

Esa es la idea detr谩s de la virtualizaci贸n de servidores, y la idea se remonta a los mainframes de聽IBM聽en la d茅cada de 1960 y fue popularizada por聽VMware,聽que introdujo el software de聽virtualizaci贸n para servidores聽x86 a principios de la d茅cada de 2000. Desde entonces, otros proveedores han desarrollado sus propias plataformas de virtualizaci贸n de servidores y la industria en su conjunto ha creado herramientas avanzadas de administraci贸n, automatizaci贸n y orquestaci贸n que hacen que la implementaci贸n, el movimiento y la administraci贸n de las cargas de trabajo de las m谩quinas virtuales (VM) sean muy sencillas.

Antes de la聽virtualizaci贸n de servidores,聽las empresas tratan la proliferaci贸n de servidores, la potencia de c谩lculo subutilizado, con alza de facturas de energ铆a, con los procesos manuales y con la ineficiencia general y falta de flexibilidad en sus entornos de centros de datos.

La virtualizaci贸n de servidores cambi贸 todo eso y ha sido ampliamente adoptado. De hecho, es dif铆cil encontrar una聽empresa que no est茅 trabajando聽la mayor parte de sus cargas de trabajo en un entorno de m谩quina virtual.

La virtualizaci贸n de servidores tom贸 un dispositivo f铆sico y lo dividi贸 en dos, lo que permite que m煤ltiples sistemas operativos y m煤ltiples aplicaciones completas aprovechen la potencia inform谩tica subyacente.

En la siguiente ola de computaci贸n, desarrolladores de aplicaciones est谩 cortando en partes m谩s peque帽as qu茅聽servicios se ejecutan en un lugar de聽cara a experimentar con la inform谩tica sin servidor (tambi茅n conocida como funci贸n-as-a-service (FAAS).

 

Beneficios de la virtualizaci贸n de servidores

El servidor virtual comenz贸 y se reuni贸 con la consolidaci贸n del servidor base. Se pueden combinar m煤ltiples aplicaciones en una sola pieza de hardware, reduciendo as铆 el n煤mero total de servidores necesarios en el centro de datos. Menos servidores, menos bastidores, menos equipo de red.聽Todo se traduce en ahorros de dinero, desde el espacio f铆sico hasta los costes de mantenimiento y el aire acondicionado.

La virtualizaci贸n de servidores reduce la necesidad de gastos de capital en hardware nuevo, lo que le permite desconectarse de la actualizaci贸n de hardware.

Con la virtualizaci贸n de servidores los聽avances en la automatizaci贸n le permiten girar una m谩quina virtual en cuesti贸n de segundos y mover varias cargas de trabajo en el toque de un bot贸n en respuesta a las cambiantes necesidades del negocio.

La virtualizaci贸n de servidores tambi茅n ofrece la alta disponibilidad, velocidad, escalabilidad, agilidad, rendimiento y flexibilidad que requieren las empresas altamente conectadas basadas en la web de hoy en d铆a.

Y la virtualizaci贸n de servidores es la tecnolog铆a subyacente que permite a los proveedores de computaci贸n en la nube ofrecer sus servicios. Cuando un cliente solicita una infraestructura-as-a-Service (IaaS) de un proveedor de servicio en la nube, Comienzan con m谩quinas virtuales y despu茅s a帽adir sobre las caracter铆sticas de almacenamiento, gesti贸n y seguridad asociados necesarios para llevar a cabo la tarea en cuesti贸n.

 

Los diferentes tipos de virtualizaci贸n de servidores

Con la virtualizaci贸n est谩ndar basada en hipervisor, el hipervisor o monitor de m谩quina virtual (VMM) se ubica entre el sistema operativo host y la capa de hardware subyacente, proporcionando los recursos necesarios para los sistemas operativos invitados.

La virtualizaci贸n de para y la virtualizaci贸n completa modifican el sistema operativo invitado antes de la instalaci贸n en la m谩quina virtual. Esto mejora el rendimiento ya que el sistema operativo hu茅sped modificado se comunica directamente con el hipervisor, lo que elimina la sobrecarga de la emulaci贸n.
Tambi茅n se intenta la virtualizaci贸n asistida por hardware para reducir la sobrecarga del hipervisor, pero lo hace a trav茅s de extensiones de hardware, en lugar de modificaciones de software.

Con la virtualizaci贸n a nivel kernel, en lugar de usar un hipervisor, ejecuta una versi贸n separada del kernel de Linux. Esto hace que sea f谩cil de ejecutar m煤ltiples m谩quinas virtuales en un 煤nico host, con un controlador de dispositivo utilizado para la comunicaci贸n entre el principal n煤cleo de Linuxy las m谩quinas virtuales. Finalmente, con la virtualizaci贸n del sistema operativo, puede ejecutar entornos m煤ltiples pero l贸gicamente distintos en una 煤nica instancia del kernel del sistema.聽Con la virtualizaci贸n a nivel de sistema, todas las m谩quinas virtuales deben compartir la misma copia del sistema operativo, mientras que la virtualizaci贸n de servidores permite que diferentes m谩quinas virtuales tengan diferentes sistemas operativos.

 

Neal Weinberg

M茅tricas del modelo DevOps, para tomar mejores decisiones

El objetivo principal de la pr谩ctica DevOps es agilizar el ciclo de vida del software, asegurando la calidad en cada uno de los pasos y partiendo de la automatizaci贸n y la monitorizaci贸n como herramientas fundamentales para conseguirlo.

Por ello, MTP nos propone ciertas m茅tricas que se centran en ese objetivo, manteniendo tambi茅n el foco en la calidad, ya que tampoco hay que olvidar que lo que se desea no es producir mal software a gran velocidad:

  1. N煤mero de commits asociados correctamente a un ticket. Por medio de esta m茅trica podremos conocer en todo momento si los equipos de desarrollo est谩n contribuyendo a la trazabilidad del c贸digo, un aspecto fundamental.
  2. Porcentaje de c贸digo cubierto por test unitario. Aunque no hay que llevar al extremo la cobertura de c贸digo por test unitario, contar con un nivel adecuado ayuda a prevenir problemas en etapas posteriores.
  3. Ratio de construcciones fallidas. Si una build, con independencia del motivo, no se completa correctamente, se pierde un tiempo valioso que repercutir谩 en el resto del proceso de construcci贸n del software.
  4. Ratio de despliegues fallidos. Ya sea por indisponibilidad de entornos, por fallos en la configuraci贸n o por defectos en los tests postdespliegue, conviene llevar traza de la cantidad de despliegues que no se han completado con 茅xito.
  5. Tiempo medio de despliegue. Esta m茅trica nos ayudar谩 a identificar procedimientos que no est茅n del todo maduros, por ejemplo, pasos que a煤n no est茅n automatizados o que requieran de revisi贸n manual.
  6. Frecuencia de despliegue. Uno de los objetivos debe ser hacer despliegues peque帽os y frecuentes. Esta m茅trica nos ayudar谩 a saber si estamos acerc谩ndonos o alej谩ndonos de este objetivo.
  7. Porcentaje de 茅xito en tests autom谩ticos. Los tests autom谩ticos son fundamentales en un entorno DevOps. Un despliegue puede interrumpirse por errores en los tests autom谩ticos. Relacionar esta m茅trica con otras, como el n煤mero de defectos encontrados por entorno, puede ayudar a saber si los tests autom谩ticos construidos son o no suficientes.
  8. Defectos encontrados en entornos de integraci贸n y UAT. Ya sea por fallos detectados gracias a tests autom谩ticos o a tests de usuario, es una m茅trica que deber铆a tender a cero con el tiempo. Es un indicador de la madurez de todo el proceso.
  9. Ratio de indisponibilidad. Tanto en entornos intermedios como en entornos productivos, una indisponibilidad es un problema grave. Evidentemente, el problema es mayor si un entorno de producci贸n deja de estar disponible. Por ello, podr铆a tener sentido dividir esta m茅trica por tipo de entorno.
  10. Tiempo medio para salir de indisponibilidad. La rapidez con la que se reaccione para volver a dar servicio es clave para no interrumpir el ciclo de vida y para no da帽ar la imagen de cara al cliente, adem谩s de limitar una potencial p茅rdida de ingresos.
  11. Defectos encontrados en entorno productivo. Un defecto ser谩 m谩s costoso de corregir cuanto m谩s tarde se detecte en el ciclo de vida. El objetivo es que esta m茅trica tienda a cero. Como mencion谩bamos anteriormente, si no vemos disminuido este valor con el tiempo, convendr铆a ajustar las bater铆as de test de todo tipo aplicadas al software.
  12. Tiempo medio de resoluci贸n de defectos en entorno productivo. Cada defecto que se da en un entorno productivo supone un coste en t茅rminos de deterioro de imagen, potencial p茅rdida de ingresos o corrupci贸n de datos, por poner s贸lo algunos ejemplos. El tiempo de resoluci贸n debe ser m铆nimo para mantener estas consecuencias dentro de lo admisible.
  13. 鈥淟ead time鈥 de un cambio. Tiempo medio transcurrido entre el registro de un ticket y la puesta en producci贸n de la funcionalidad asociada. Nos ayuda a medir el tiempo de respuesta de todo el engranaje DevOps.

 

Todas estas m茅tricas son una ayuda a la hora de tomar decisiones, pero tambi茅n para conocer si los cambios aplicados van o no en el buen camino.