Monthly Archives: septiembre 2016

El valor de Devops para un negocio

Print

Cuando hablamos de Devops, tenemos tendencia a centrarnos en las tecnología, herramientas y procesos utilizados. Básicamente es porque quién hablamos de ello somos gente que formamos parte de los equipos de desarrollo o de operaciones. Pero que valor aporta Devops para un negocio?

En el post anterior “Devops ROI” vimos los conceptos generales que permiten justificar la inversión en tecnología, el ahorro en costes de horas de trabajo y el ahorro en caídas del sistema. Pero Devops aporta otras ventajas o valor difícil de cuantificar en términos monetarios. Hoy en día, donde todos o la mayoría de los negocios son negocios basados en tecnología, este valor puede ser el hecho diferencial entre una empresa u otra.

La implantación de Devops nos permite impactar directamente en mejorar como distribuimos un producto al cliente, cambiar el producto rápidamente para satisfacer las necesidades del cliente o como recuperamos después de un fallo que afecta al cliente.

Un producto en si mismo no es nada hasta que un cliente lo utiliza. Es por ello que es importante reducir el tiempo de lanzamiento de un producto, y aquí es donde la automatización actúa como un multiplicador, permitiendo la colaboración de todos los equipos involucrados en la creación de un producto.

De la misma forma que un producto no sirve de nada si no lo utiliza un cliente, las mejores funcionalidades son aquella que utiliza el cliente. De nada sirve tener un producto con un montón de funcionalidades que no se utilizan. Es por ello que todos los esfuerzos deben focalizarse sobre las funcionalidades que utilizan los clientes, pero como sabemos que funcionalidades va a utilizar el cliente si aún no la hemos lanzado? Devops permite cambiar el enfoque en que priorizamos las funcionalidades de un producto. Pasamos de un enfoque basado en lo que el propietario o la gente de marketing quiere que tenga el producto a un enfoque basado en lo que el cliente quiere que tenga el producto. Para ello, la frecuencia de desarrollo y el uso de test A/B sobre grupos de clientes nos permiten conocer que funcionalidades y mejoras que quieren los clientes.

Por otro lado, todo y que a todos nos gustaría que un producto nunca fallara, tenemos que asumir que en el mundo real el fallo forma parte del ciclo de vida de un producto, falla la tecnología y fallamos nosotros. Todo y que con la automatización de los procesos de testing y deploy se reduce el número de fallos, debemos entrenarnos en la gestión del fallo para reducir el tiempo de recuperación ante fallo o MTTR (Mean Time To Repair). La reducción del tiempo de recuperación ante un fallo mejora la satisfacción del cliente.

En resumen, aplicar Devops permite reducir el tiempo de lanzamiento de un producto, distribuir al cliente aquello que desea el cliente, y mejorar la satisfacción del cliente.


Source: jmgriscom

Lo que nadie te va a contar sobre las consecuencias negativas de la virtualización.

463741502c1ef58458437425e3c67529

”En las batallas te das cuenta de que los planes son inservibles, pero hacer planes indispensable”, Dwight E. Eisenhower.

463741502c1ef58458437425e3c67529

Como bien decía Eisenhower, aunque no te vaya a hacer falta (o así lo crees), planifica y organiza, organiza y muchas veces, lidiar con nuestros entornos virtuales me han parecido algo parecido a batallas. Me explico:

¿La virtualización tiene sus partes negativas?

Como todo en esta vida, no todo son albricias, todo tiene su “bueno, pero ademas…”.

En este caso estamos ante una tecnología que como hemos visto en otros posts, “todo son facilidades”, bueno, hasta que nos topamos con el “sprawl”. Este término inglés lo podríamos trducir por “expandirse”, “extenderse” o “desparramarse” y estoy seguro que muchos de vosotros, en cuanto entremos en harina lo reconoceréis fácilmente.

¿QUÉ ES EL VM SPRAWL?

VM sprawl es un fenómeno que ocurre cuando el numero de VMs en un sistema llega a tal punto que el administrador no puede gestionarlo de forma eficiente, bien por el numero de VMs que gestiona y no tiene identificadas, bien porque a veces (demasiadas) no sabe ni lo que hace ahí esa VM.

el porque del “sprawl”

El Correo electrónico es un buen símil del sprawl en el mundo virtualizado. Empezó cuando el señor A quería decirle algo al señor B, sobre un tema interesante. La facilidad con la que se ha podido obtener cuentas de email para todo el mundo y la necesidad de comunicarse entre los humanos ha hecho que nuestras bandejas de Inbox, hoy por hoy, sean casi ingobernables.

Creo que una vez se ha virtualizado un entorno, se entra en un nuevo paradigma parecido al de “barra libre” (en unos casos más en unos casos menos, de todo he visto)

  • Se crea un nuevo paradigma. “Mira, no necesitamos casi nada, en 15 minutos podemos tener un server para ti”.
  • Necesito una maquina. La quiero ya, no es necesario esperar al servidor. Mira clóname ésta y ya la limpiaré yo.
  • Gradualmente esta “resistencia” va cayendo y de forma gradual van apareciendo  máquinas que al final perdemos el control
  • De la misma forma que ocurre su creación “por las prisas”, la organización, “por las prisas” olvida que hay ahí recursos usado o pero aún, funcionando, consumiendo tensión eléctrica del Host, de la aclimatación de aire, etc. que se podrían evitar.

CONSECUENCIAS DEL SPRAWL

Las consecuencias del sprawl son todas ellas económicas en su raíz, pero vamos a enumerarlas para una mayor claridad:

  • Máquinas Zombies. Máquinas en marcha que nadie accede a ellas, ya no se utilizan pero estan ahí. Malgastan disco, CPU y memoria
  • Snapshots no controlados. Nos consumen espacio en disco no necesario y cuanto mas tardemos en quitarlos, más nos va a costar en quitarlo, en tiempo de proceso y complicaciones
  • Máquinas paradas o suspendidas. Igual que el primer concepto, sólo que si no se usan, ¿por qué están ahí?. Malgastan disco
  • Vmdks o ficheros huérfanos. En distintos movimientos de las VMs fallidos, o en algun “crash”, es relativamente fácil que nos hayan quedado ficheros y discos “huérfanos” que no dependen de nadie. Malgastan espacio
  • Tener cuidado con el “Thin Provisioning”. Thin Provisioning es lo más alejado de “shot & forget” pues aunque tiene definido X espacio, realmente está ocupando X/Y pero nada va a impedir que el usuario, aplicación o “dueño” de la VM nos reduzca drásticamente la Y al hacer un volcado de una BBDD o de una aplicación
  • Licencias de aplicación. Si tenemos máquinas que no estamos usando, las licencias que puede haber en estas VMs se prodrían reutilizar en otra VM o lugar
  • VMs con memoria o CPU sobredimensionada. En Virtualización, la expresión menos es más toma su más alto sentido. Si sobredimensionamos en CPU una VM veremos como su rendimiento puede decaer debido al fenómeno llamado “co-stop”. Mal uso de CPU y/o memoria.

FORMAS SENCILLAS DE MITIGARLO

Aunque ya existen herramientas encargadas de ello como los “Virtual Machine Lifecicle Managemente” (VMLM), es cierto que en general son productos con un precio elevado que hace que desistamos en plantearnos la compra de uno de ellos.

No obstante hay formas y metodologías que nos permiten mitigar el sprawl y todas ellas se basan en una, organización:

  • Crear plantillas de las máquinas que vamos a usar normalmente y que estén “homologadas” por la dirección de TI de la empresa (si la empresa usa Ubuntu, pues una plantilla de Ubuntu, así no tendremos Debian, Fedora y  Ubuntu mezclados por ahí salvo en los casos que sea preciso.
  • Dar los permisos de crear nuevas VMs al SysAdmin.
  • Establecer un formulacio y su circuito de petición de VM nueva, donde debe especificarse que Departamento y que persona va a ser el “propietario” de la VM, el propósito de la máquina y si interacciona con otra y sobre todo la fecha de expiración de la VM
  • Con este documento y la autorización del CIO, el SysAdmin procederá al alta de la VM.
  • Tras inventariar la VM, introducirá los TAGS en la misma de Dpto, propietario y sobre todo la fecha de expiración.
  • Tendrá que haber alguien o hacer un script para que vaya “delatando” las VM que se hallan en período “post-produccion”. Puestos en contacto con el propietario se acordará su ampliación del tiempo de producción o su borrado.

No nos debe extrañar que haya “fecha de caducidad” en las VM. Como decíamos, una de las potencias de la virtualización es la facilidad de creación de VMs, se utilizan y acto seguido , cuando no son necesarias, “ahí quedan”, utilizando unos preciados cursos no baratos precisamente.

Evidentement esto se debe conjugar con unas auditorías internas utilizando herramientas o scripts capaces de localizar disco huerfanos, etc.

¿SOLO EN VIRTUALIZACION?

No, no es un mal “endémico” de la virtualización. Tal como puedes ver en las referencias, ya existía el server sprawl en el entorno físico que se definía como una pobre utilización, no controlados ni organizados, de los recursos de IT de los que disponía una entidad.

De ahí venimos, y “esas lluvias, estos barros”, pero vemos que ahora el sprawl se expande a La Cloud.

Gracias a la facilidad que comporta, estamos llegando a hacer deploy en breve tiempo en Amazón AWS, mientras tenemos una máquina en Amazon y algunas en algún service provider. Las probamos, vemos como funcionan y ahí se nos quedan. Esto en cuanto a Infraestructura as a Service (IaaS), pero seamos conscientes de lo que estamos haciendo en la parte Software as a Service (SaaS). Es típico que alguien esté fuera de tiempo y una solución en la cloud le ayude de forma importante y tirando de Paypal o de tarjeta la contratemos en minutos. Y lo más fácil es que ahí se quede.

Osea, te recomiendo que revises tu cuenta de Paypal o tu extracto de la Visa para ir detectando estos “Zombies” que te van debilitando la cartera.

CONCLUSIONES

Queda claro el alcance del VM Sprawl. No es la primera vez que somos requeridos para evaluar la expansion de un entorno y terminar haciendo una consultoría sobre la adecuación del uso de los recursos.

Desde Orbal nos preocupa mucho este fenómeno y es algo que hacemos difusión especial para que todas vuestras infraestructuras funcionen lo mejor posible y os den a vuestras empresas el ROI que ofrecimos al mover vuestro entorno físico a entorno virtual.

Por otro lado estamos trabajando en un proyecto para controlar el VM sprawl. Si alguien está interesado en el tema, estamos a vuestra disposición en este link

Recomendación: el sprawl es muy peligroso y traicionero. Llega el día en que se precisan una serie de recursos para un proyecto y salta la pregunta ¿Donde fueron nuestros recursos? y el SysAdmin no tendrá la respuesta adecuada para esta pregunta, cosa que será peligrosa. Aplicad todos los medios para mantener bajo control vuestra infraestructura.

Take care

JM

Foto: Morguefile

Referencias:

  • Server Sprawl de Anil Desai
  • Virtual machine sprawl prevention: Best practices.
  • VMware. Controlling Virtual machine Sprawl


Source: jmgriscom

Nueva Web en Orbal

web-orbal

Una web llena de recursos para vosotros

web-orbal

Siempre he dicho que una imagen vale más que cien palabras, y por eso creo que lo mejor es que se vea lo que estamos haciendo.

Estamos haciendo un punto de encuentro donde un Responsable Informático pueda encontrar la mayor cantidad de recursos sobre ello, videos, white papers, e-books

Y mientras vamos populando este apartado, podéis ver nuestro nuevo site, desde donde podréis ver lo que hacemos, nuestras novedades, etc.

captura-de-pantalla-2016-09-25-a-las-18-39-52

Os esperamos pronto por www.orbal.es

Take care,

JM

 


Source: jmgriscom

Configurando OVAs i OVFs con OVFTOOL

packageovaovf

La portabilidad es sin duda una de los principales beneficios de definir nuestras máquinas como virtuales. Al ser éstas un compendio de ficheros de configuración, son fácilmente exportables e importables en otros entornos manteniendo su consistencia. Sin embargo, la proliferación de hipervisores y versiones de los mismos hace que no siempre sea “tan” fácil.

Para tal efecto nació el formato OVF (Open Virtualization Format). Su objetivo era sencillo: una manera standard de poder definir una VM para que pudiera ser importada en un hipervisor distinto del que fue “originada”. Consiste en una carpeta que incluye un fichero XML con extensión .ovf (podemos verlo como el equivalente a el .vmx que describe la configuración de nuestra VM en origen) juntamente con los .vmdk, los discos de nuestra VM y normalmente un fichero .mf que contiene un hash SHA1 de los ficheros del ovf. Poco después, salió el .ova, que no es más que la compresión de la carpeta que conforma el OVF.

Hasta aquí todo suena bien, pero la realidad nos lo suele complicar bastante más: ¿qué sucede por ejemplo si tenemos una VM en un entorno VMware Fusion 8 de desarrollo y queremos importarla en un ESXi 6.0? Lo más normal es que hubiéramos creado la VM en versión de Hardware 12 en origen cuando, en destino, esta versión no está soportada.

Para todas las tareas relacionadas con la gestión y configuración de un fichero .ova o un paquete .ovf, nació ovftool, una herramienta de VMware.

¿Cómo solventamos el problema expuesto antes?

Normalmente, al intentar importar el .ovf de nuestra VM exportada de Fusion en vSphere 6.0, recibiremos el siguiente error:

The OVF package requires unsupported hardware
Details: Line 25: Unsupported hardware family ‘vmx-10’.

Primero de todo, vamos a descargar ovftool desde aquí. A continuación, vamos a obtener el fichero .vmx a partir del .ovf. Ejecutamos el siguiente comando:

ovftool <ruta donde se encuentra el fichero .ovf> <ruta donde queremos guardar el fichero .vmx>

Una vez tenemos el .vmx, lo abrimos con un editor de texto y cambiamos la línea virtualHW.version a la versión de hardware que soporte nuestro hipervisor en destino.

Imaginemos ahora que no partimos de un fichero .ovf y partimos de un .ova. Para pasar del formato comprimido a .ovf nos valemos también de ovftool mediante el siguiente comando:

ovftool.exe --lax <ruta donde se encuentra el fichero .ova> <ruta donde queremos guardar el fichero .ovf>

Para más información, recomiendo ver su manual acerca de lo que nos puede aportar ovftool.


Source: jmgriscom

¿Cúal es la inversión de nuestra empresa en IT?

Hay una serie de métricas que un CIO tiene que tener muy claras si quiere que su departamento esté a la altura de las circunstancias y que el desempeño de su cargo no sea cuestionado (entre otras).

Uno de los primeros conceptos que tiene que tener en cuenta un responsable de un Departamento de IT es que esta gestionando un presupuesto más o menos elevado, pero que no ha solicitado ni precisa el Departamento de IT.

Si, parece mentira pero es así. El 80 o 90% del presupuesto del Departamento de IT está dedicado a dar servicio a nuestros clientes internos, los otros Departamentos, para que ellos a su vez, den servicio a los clientes de la empresa.

Lo primero que debiera tener claro el CIO es este concepto y defenderlo, lo segundo, conocer que porcentaje usa cada Departamento del 80% en cuestión y lo tercero (ya vamos para nota) que cada mes hubiera una nota interna o “factura” donde le indicáramos a cada Departamento en lo que ha incurrido. Al lado, para compensar la situación, una evaluación del servicio.

Esto, para las empresas que trabajan con una contabilidad de centros de costes será relativamente fácil, porque la cultura ya estará implantada, en las que no, pues pasito a pasito y empezar a clarificar quién es el responsable del presupuesto y quién es el que lo está explotando en verdad.

Estoy preparando un post donde además hablaremos sobre como confeccionar un presupuesto anual “por concepto y destino”, pero ahora volvamos al post original. Volvemos…

Si Vd. CIO de la empresa X le preguntara que porcentaje de los ingresos de su empresa se invierten en IT, ¿me sabría contestar? ¿Y si le pregunto cual es la media de su sector, o la media general?.

Antes de que dejes de leer este post déjame decirte que es muy fácil conocerlo (facturación anual y OPEX incluyendo amortización del Depto de IT y hacer una operación) y muy importante saberlo.

¿Por qué? Porque cuando venga el momento de poner presupuestos sobre la mesa, si sabemos ese dato y comparamos nuestra inversión en frente de la sectorial, tendremos argumentos en lenguaje de negocio para defender el proyecto, porque así se defienden los proyectos, en lenguaje de negocios, y demostrando que la inversión o ROI de nuestro proyecto es menor que los beneficios que va a aportar.

Sí, ya sé, y lo sé por experiencia (10 años como CIO) que hay muchos puntos “difíciles” en los proyecto, “intocables” que tendremos que volver “tocables”, poniendo un valo, y puntos “incuantificables” que volveremos “cuantificables”, porque nuestro CIO va a discutir un punto crítico “que gano si pongo en marcha este proyecto”.

Si esto lo podemos “indexar” al cuadro de lo que se gasta la industria en IT, tendremos otro punto de apoyo.


Acabo de ver el cuadro de Gartner y lo cierto es que continúo pensando que es bajo el “Share” de IT en los ingresos de la empresa.

El sector financiero está invirtiendo un 6.3% y el de Software e internet un 6,7, mientras que el general de la industria es un 3.3%. Ojo con confundirnos. Veamos que el sector de la energía tiene tan sólo un 1.1%, Igual con el 1.3% de las químicas. ¿sobre que cantidad de ingresos?

Tengamos un momento para hacer estos cuatro números y comparémonos con el cuadro o con nuestros colegas (si es posible). El paisaje nos dará mucha información.

Me encantaría que me dejárais algun comentario al respecto.

Hasta la semana que viene

Take care,

JM


Source: jmgriscom

Virtualización de servidores con éxito. Nuevo Ebook de este Blog.

virtualizacion-de-servidores-con-exito

¿Cómo estáis? Espero que ya reintegrados afrontando el ultimo trimestre del año.

Bien. Pues vengo a presentaros algo que llevaba dentro hace tiempo  y tenía ganas de que viera la luz. Un Ebook que contemplara las fases necesarias en un proyecto de virtualización de servidores (la virtualización de escritorios, aplicaciones y storage tienen un ciclo de vida similar pero distinto). Tenía que escribirlo….

¿A quien va dirigido el Ebook?  Pues a todos aquellos IT-Man, CIOs, informáticos y personas relacionadas que piensan o desean preparar un proyecto de virtualización de Servidores.  Y la intención final no es más que explicar y detallar las distintas fases del proyecto y argumentar porqué tiene sentido cada fase y que ganamos con ella.

A lo largo de mi experiencia en este mundo de la virtualización he tenido que revisar instalaciones las cuales tenían problemas e investigando he ido viendo que el 90% de las instalaciones que he tenido que recomponer era sencillamente porque en el proyecto nadie había puesto sobre la mesa la conveniencia o necesidad de cierta fase.

No se trata tan sólo de un libro técnico, sino que hay capítulos de gestión de TI en la que expongo o apunto a oportunidades donde se puede generar un proyecto de este tipo. Si eres capaz de “detectar” los puntos identificativos que indico, podrás con alto grado de seguridad empezar a sembrar lo que en un futuro va a ser las bases del proyecto para tu pequeño o gran CPD.

¿Y que más puedo decir? Que el libro va a ser gratuito y se va a distribuir en breve desde este blog o desde nuestra web www.orbal.es. Tan sólo te voy a pedir que te suscribas a nuestra Newsletter a cambio.

Y nada más, tan sólo indicaros que la intención es que otros libros eminentemente técnicos o de gestión, pretendo que sucedan a éste. Ya os iré dando noticias sobre ellos.

Dos puntos finales. El primero, espero que disfrutéis y sobre todo os sirva lo que he estado escribiendo para vosotros. Gracias por vuestro tiempo en leerlo.

El segundo. Me gustaría mucho que si estáis interesados en algún tema que os gustase/interesase, me lo escribierais abajo en los comentarios o me enviaseis un mail. Os estaría muy reconocido. Os avanzaré que estamos pensando en que Albert escriba un E-book sobre como usar elementos opensource para monitorizar sistemas virtualizados (Monitorización de guerrillas) y yo me estoy planteando uno sobre como evaluar los costes de un departamento de IT o como elaborar el presupuesto anual del mismo. Vosotros tenéis la palabra.

Take care, JM


Source: jmgriscom

Organiza tus jobs de Veeam mediante políticas

organiza-tus-jobs-mediante-veeam

El hecho de que la virtualización es una tecnología ya bastante madura en cada vez más entornos supone muchos retos. Vamos añadiendo cargas (seguramente cada vez más críticas y sensibles) a los hipervisores, nuevas máquinas, ratios de consolidación más agresivos y demás realidades que parece que induzcan la idea de que mantener el control de nuestra infraestructura tenga que ser más una cuestión de “hacer malabares”. Estos fenómenos son los que o ya afrontamos o afrontaremos en algún momento y es por ello que por ahí van las tendencias de los fabricantes cada vez apostando más por la automatización y la monitorización.

Estas realidades aplican por supuesto también a las soluciones que dependen directamente de nuestra infraestructura vSphere, como por ejemplo Veeam Backup&Replication. Antes de nada, en el caso de Veeam, lo primordial es mantener una definición de los requerimientos de cada VM en cuanto a su nivel de disponibilidad, luego veremos cómo aplicarlos y sobretodo mantenerlos de manera ágil.

Al final, lo que queremos es una manera ordenada y dinámica de proteger nuestras VMs según las condiciones específicas de cada una de ellas.

Para definir estas políticas deberemos analizar qué requerimientos tienen nuestras VMs o nuestros perfiles de VMs: tenemos que declarar los parámetros en los que basaremos nuestras políticas de Backup/Replicación.

Paso 1 – definir parámetros y valores

Un ejemplo sencillo de estos parámetros podría ser el siguiente:

  • RPO
    • ¿Cada cuanto tiempo debemos ejecutar una copia de la VM? Lo podemos medir en minutos, horas, días …
  • Ventana
    • ¿Qué intervalo tenemos para ejecutar la copia? Pierde relevancia si usamos Storage Snapshots. Expresado en franja horaria.
  • Retención
    • ¿Qué histórico de copias debemos almacenar para esa VM? Lo especificaremos en valores “absolutos”. Es decir, si quiero mantener una semana de copias y mi RPO es de 24h, tendrá un valor de 7.
  • RTO
    • Tiempo en poner la máquina en producción a partir de la declaración del desastre. En sí no es un parámetro que apliquemos al job como el RPO, pero podemos agilizarlo usando Reverse Incremental o más aún con replicas.
  • Encriptación
    • ¿Debemos encriptar los datos de esa VM?
  • OS
    • Mantener VMs de OS/Datos/Apps parecidos nos ayudará a tener mejores ratios de deduplicación.
  • ¿Backup secundario?
    • Hay que almacenar una copia de la VM en algún otro lugar.

Paso 2 – agrupar

Con  este análisis como primer paso, tendremos una descripción en términos de protección de datos de nuestras VMs, “metadatos” para cada una. Ahora nos hará falta agruparlas según valores parecidos. Fácilmente, acabaremos (siga esto entendiéndose como ejemplo) con un grupo que será “Producción – Linux” con unos valores iguales para cada parámetro en todas las VMs. Con estos grupos, tendremos una posible propuesta de organización/distribución de nuestros Jobs de Backup/Replicación.

Paso 3 – “dinamizarlo”

Sin embargo, no olvidemos que el principal ánimo de este post es hacer el trabajo (sobretodo el de mantenimiento) más sencillo. De momento, tenemos una manera ordenada de proteger a nuestras VMs según los requisitos específicos de cada una, pero no hemos hablado de cómo hacer todo este proceso dinámico o semi-automatizado.

Cuando hablamos de Jobs dinámicos en Veeam Backup & Replication, nos referimos a Jobs que como origen tienen un objeto que no es/son una VM en sí. En la definición del job, como “Source”, podemos añadir una a una cada VM que cumpla los requisitos definidos por el Job. Si tu entorno es pequeño, y sobretodo, con pocas modificaciones, es algo planteable, pero si el entorno va evolucionando (que es lo más normal), habrá que empezar a plantear otras maneras, puesto que no vamos a ir añadiendo VMs a los Jobs, sería bastante ineficiente.

En el fondo, para tener un job dinámico bastaría con crear uno solo para toda tu infraestructura que, como “Source”, incluyera todo el vCenter. De esta manera, toda máquina nueva sería incluida directamente en la copia sin necesidad de dar “un paso más” añadiéndola. Sin embargo, catalogar todas las VMs bajo la misma definición no es lo que buscamos tampoco.

Es aquí donde toman relevancia objetos de vCenter que quizás no habías tenido en cuenta antes, como son las etiquetas (o “tags”) y las carpetas. En este whitepaper, Luca Dell’Oca nos sugiere que, una vez definidos los grupos de VMs que hemos visto en el paso 2, cada grupo se mapee a un tag de vCenter y luego, creando un Job para cada grupo, añadir cada etiqueta como “source” del job. Así pues, para nuestro grupo de ejemplo “Producción – Linux”, tendremos que crear su etiqueta en vCenter, etiquetar cada VM que pertenezca a este grupo con ella, y luego crear un Job de Veeam que como Source tenga dicho tag. Además de ser un genial White Paper (recomiendo descargarlo y leerlo detenidamente sobre todo por cómo se detallan los pasos), me parece un método perfecto para entornos heterogéneos, diversificados, (muy) grandes y con muchos usuarios y permisos en vCenter. Sin embargo, quizás vea más acorde a un entorno “standard” de los que tenemos hoy en día por nuestras tierras usar las carpetas de vCenter . La razón es sencilla: al crear una VM, ya sea mediante el wizard tradicional del cliente de vSphere o incluso mediante herramientas de terceros como Chef, nos dejará (de hecho nos “obligará”) especificar en qué carpeta la ubicamos.

Esto hace que no tengamos que dar ese “paso más” de luego ir y etiquetar la VM. Luca habla de maneras muy válidas mediante scripting por ejemplo de automatizar el proceso de etiquetar, pero quizás es demasiado complejo si ya nos sirven las carpetas.

La idea es que no queden máquinas virtuales fuera de copia. Si usamos carpetas, nos aseguramos que siempre nos pregunte en qué carpeta ponemos la VM, pero cabe la posibilidad de que la VM caiga en la carpeta “Discovered Virtual Machines” o en la matriz del Datacenter. Para mitigar este problema, podemos por ejemplo ejectuar un pequeño script que cada dia revise que no queden VMs en carpetas que no estén incluidas en ningún job.


Source: jmgriscom

Retorno de la inversión (ROI) en Devops

design-process-thumb

El calculo de cualquier retorno de inversión se basa en el ahorro esperado. Cuando analizamos el retorno de inversión de implantar prácticas como DevOps, es difícil cuantificar este ahorro en términos monetarios. Hay dos aspectos que nos pueden ayudar a entender los ahorros que obtenemos al implantar DevOps: ahorro de costos en horas de trabajo y ahorro de costos de caídas del sistema.

Por lo que hace al ahorro de coste en las horas de trabajo, podemos clasificar el trabajo de cualquier departamento de TI o desarrollo en dos tipos, trabajos planificados y trabajos no planificados, donde los trabajos planificados son aquellos que están destinados a aportar valor a nuestros clientes, en cambio, los trabajos no planificados son aquellos que se realizan a causa de errores o incidencias que hay de resolver de inmediato. Implantar prácticas de Devops permite reducir el tiempo de trabajo no planificado. Pero cual es el coste del trabajo no planificado?

En el informe anual que publica Puppet “State of Devops Report” del 2016, se plantea la siguiente formula para calcular el exceso de coste que supone el trabajo no planificado.

Cost del exceso de trabajo = Personas * Salario medio * Beneficios * Porcentaje de tiempo dedicado a trabajo extra.

• Número de personas: total de personas del equipo técnico.
• Salario medio: según un artículo de computerworld, que hace referencia a un informe de Addeco, el sueldo medio del sector TIC en España oscila entre los 30.000 y 60.000 euros anuales.
• Beneficios: es el coste de los variables o incentivos que perciben los trabajadores a más a más del sueldo, como tickets restaurant, mutuas, etc.. Podemos estimar un factor de 1.2 sobre el sueldo medio.
• Porcentaje de tiempo de trabajo extra: según el informe de Pupper “State of Devops Report” del 2016, para una empresa media este está entre un 10% y un 32%.

Para poner un ejemplo del coste de trabajo extra o trabajo no planificado realizado, ponemos que tenemos un equipo de 10 personas. El cálculo seria el siguiente:

Coste de exceso de trabajo = 10 * 45.000,00€/año * 1.2 * 22% = 540.000,00€/año * 22% = 118.800,00€/año

A este coste, debemos añadir el coste de las caídas de servicio, coste que varia mucho en función de la naturaleza de la organización y que no es fácil de calcular. Todo y la dificultad de calcular el coste de las caídas, es interesante ver la aproximación que se hace en el informe de Puppet,donde se plantea una formula para estimar el coste de las caídas de servicios.

Coste del “downtime” = Frecuencia de Deploys * Porcentaje de caídas * Tiempo medio de recuperación * Coste por hora de caída

• Frecuencia de deploys o despliegues que se realizan en el entorno de producción y que pueden ser causa de caídas del sistema.
• Porcentaje de caídas producidas por cambios en el sistema.
• Tiempo medio de recuperación o MTTR (Mean Time To Recover) que corresponde al tiempo medio que el equipo de operaciones tarda en recuperar los sistemas ante una caída.
• Coste de por hora de caída. Este dependerá mucho de lo crítico que sea el sistema caído.

Aquí las prácticas de Devops nos ayudan a reducir el tiempo de recuperación de los sistemas ante caídas y a reducir el porcentaje de errores producidos por cambios en el sistema.

Podéis encontrar más información en el informe de Puppet “2016 State of Devops Report”


Source: jmgriscom

Planificando vuestra visita al VMWORLD 2016

vmworld-2016

Se acerca Octubre y con él llega el VMworld europeo de este año. Después del éxito del evento americano que reunió a casi 25000 personas en Las Vegas durante este final de Agosto. Por lo que ha llegado de los asistentes, poquitas novedades significativas se anunciaron y estuvieron muy centradas en OpenStack, containers y Cloud con especial foco en este último con presentaciones como Cloud Foundation i vCloud Availability. Es por eso que se esperan mayores noticias para el evento europeo (no olvidemos la noticia de la compra de EMC por parte de Dell durante el evento del año pasado).

VMworld siempre aporta grandes experiencias en muchos planos. Ver el “state of the Art” de todo lo relacionado con virtualización y Software Defined DataCenter, reencontrar amigos de todos los rincones, los eventos paralelos, los regalos… A todos nos encanta, sin embargo, en mis últimas experiencias siempre acabo con una sensación de que podría haber aprovechado más a nivel técnico ya que la cantidad y sobretodo calidad de las sesiones es altísima. No nos engañaremos, en los días que dura el evento no da tiempo a verlo todo. Es imposible. Pero a más planificación, más probabilidades de ver todo lo que nos propongamos.

Así que si lo que queréis es “actualizaros”, ver en profundidad funcionalidades o productos de o sus Partners, os recomiendo encarecidamente que le deis un vistazo a este enlace. Se trata del catálogo de contenidos de todas las charlas que se realizarán en el VMworld europeo este año. Las plazas para las sesiones son limitadas, así que si teneis claro que queréis asistir a alguna, registraros cuanto antes. Podréis montaros un pequeño calendario de sesiones a las que asistir Además, en breve debería aparecer la app para el VMworld 2016 EU donde podréis realizar lo mismo de manera más cómoda e ir consultándolo in-situ (incluso recibir notificaciones de los eventos a los que estáis suscritos).


Source: jmgriscom