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. “Lead 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.