Category Archives for "DevOps"

vRealize Operations Manager: Primeros pasos

Capura de vrealize vRealize Operations Manager

Serie de posts sobre vRealize Operations Manager

vRealize Operations Manager es la solución de VMware que nació para darle a nuestro entorno vSphere una visibilidad profunda y eficiente, de una manera fácil y sobretodo flexible. Cada vez se está consolidando más como la herramienta de monitorización para estos entornos: el hecho que sea del mismo VMware ayuda, pero sobre todo es la facilidad de recolectar métricas y presentar los datos, adaptándose muchísimo a los procesos u operativas de cada departamento de IT.

“Out-of-the-box” ya nos da muchísima información tanto a nivel de análisis como a nivel de generación de alertas o notificaciones, pero es sin duda cuando se genera una necesidad de datos sobre el entorno en nuestro departamento cuando podemos sacarle el máximo partido, generando el reporte, dashboard o alerta que precisamos de manera personalizada.

Es por ello que voy a dedicar los siguientes post a ver con profundidad vRealize Operations Manager, desde su instalación a cómo configurarlo de manera que nos ayude precisamente a dar respuesta a nuestras demandas.

¿En qué consiste vRealize Operations Manager?

vRealize Operations Manager es una solución de monitorización y Capacity Planning que, como tal, se enfoca en tres grandes funciones: recolectar datos, analizarlos y presentarlos.

En todos estos puntos, vROps destaca de entre los demás de la siguiente manera:

  • En cuanto a recolección, es rápido y muy fácil de configurar para que acceda a las métricas/datos de los sistemas origen. Es importante resaltar que, aunque sea de VMware, no es un producto orientado únicamente a monitorizar nuestro vCenter, ni siquiera orientado a monitorizar sólo productos de VMware. Por defecto lo que nos viene es vROps con el conector para vCenter, ése siempre estará ahí, pero existen un montón de “Management Packs” del propio VMware para integrar vRealize Operations Manager y monitorizar otras de sus soluciones más allá de vCenter o incluso de terceros para monitorizar dispostivos (switches, cabinas, …) o aplicaciones (SAP HANA, Oracle, Antivirus, …). Aquí podréis ver qué plug-ins, ampliaciones y Management Packs existen. Hay fabricantes como Blue Medora que se dedican a desarrollar este tipo de conectores.
  • En cuanto a análisis, estaremos de acuerdo en que previamente a la caída o malfuncionamiento de un sistema, este experimentará en la mayoría de los casos un comportamiento distinto al “normal”, anómalo. Las soluciones de monitorización tradicionales basan sus sistemas de alertas en tratar la evolución de una métrica según evolucione en el tiempo y dar su comportamiento como “correcto” mientras esté contenida en un umbral preestablecido. vROps va mucho más allá. Aprende el comportamiento normal según patrones que ya ha analizado para ese objeto y su motor analítico es tan potente que permite no solo levantar alertas por que tal métrica ha alcanzado el umbral que le hemos establecido, sino que además nos dirá si ese objeto está teniendo el comportamiento esperado para ese momento. De esta manera podemos preveer un potencial problema en cada elemento monitorizado. Además, es sencillo poder crear escenarios “What-If” que nos permiten simular qué niveles de servicio tendría nuestro actual entorno si le añadiéramos más capacidad, más VMs/demanda, le quitaramos un host…,
    Finalmente, tenemos la capacidad de aplicar políticas según queramos ser más agresivos o más conservadores en cuanto a todo lo que el análisis y tratamiento de las métricas se refiere, ya sea en umbrales de alertas, Capacity Planning, …
  • En presentación de datos, además de traer reportes, widgets y Dashboards por defecto, nos aporta una gran flexibilidad para poder crear nuestros propios paneles y reportes a medida, según más nos convenga.

Una vez tiene analizadas las métricas de los objetos a monitorizar, genera unas métricas propias llamadas “Badges” que consisten en un resumen del estado de cada objeto en los siguientes términos: Salud, donde nos indicará si el objeto está actualmente experimentando algún problema o error. Riesgo, que aporta la información de capacidad y tiempo restante de nuestra infraestructura según la proyección del uso y crecimiento actual de la misma, así como problemas de salud sostenidos en el tiempo. Por último eficiencia, detallando qué oportunidades de ahorro o reclamación de recursos tenemos según el uso que estemos haciendo de la infraestructura.

De este modo que podemos tener una gran variedad de entornos monitorizados bajo una sola herramienta.  Esto nos da la gran ventaja de poder relacionar los diferentes objetos de nuestra infraestructura en todas las capas. Aún mas, ofréce toda la potencia de un motor analítico muy desarrollado y customizable. Finalmente, la libertad de customizar la presentación de datos para adaptar la herramienta a las operativas de nuestro departamento.

Arquitectura de vRealize Operations Manager

A nivel de arquitectura/implementación, vROps tiene dos tipos de despliegue según los niveles de disponibilidad que se quiera de la aplicación o la cantidad de datos que se gestionen: un modo “all-in-one” en el que un solo nodo se encarga de recolectar los datos, analizarlos y mostrarlos o un modelo distribuido en el que se pueden desplegar los siguientes nodos:

  • Master Node: siempre habrá uno nodo con este rol en nuestro “cluster” de vROps, ya sea “all-in-one” o distribuido. Este nodo se encarga de gestionar todos los demás y lleva todos los roles.
  • Data Node: Lleva los conectores para poder recolectar datos de las diferentes fuentes
  • Replica Node: Réplica del master para dar HA al cluster de vROps
  • Remote Collector Node: Estos solo recolectan información de los objetos de inventario, no almacenan los datos ni los tratan, sirven para reducir el consumo de ancho de banda para monitorizar entornos externos.

Conclusión

vROps es la solución para dar la visibilidad que todo entorno necesita. VROps permite así ser mucho más eficientes en la resolución de incidencias, poder prevenir las mismas y tener el control de cuánta infraestructura nos queda.

VMware está ofreciendo un programa de optimización de infraestructuras mediante vROps con el que se entrega un informe detallado de los problemas reales y potenciales de cada entorno basado en vSphere, así como las oportunidades de ahorro en recursos que tenemos. No dude en contactar con nosotros rellenando este formulario con la opción “Monitorización de sistemas” para llevar a cabo uno de estos estudios y tener una imagen real del estado de salud y la proyección de su entorno.

La entrada vRealize Operations Manager: Primeros pasos aparece primero en Un cio como tu ….


Source: jmgriscom

ELK cómo generar alertas

Alertas en ELK

alertas en ELK : CÓMO GENERARLAS

El uso más común de ELK (Elasticsearch, Logstash and Kibana) es la generación dashboards para la visualización de métricas y tendencias, así como para el análisis forense o en procesos de debug. Pero este también puede usarse para generar alertas basadas en los cambios que se producen en la infraestructura. ELK por si mismo no dispone de un sistema de generación de alertas, pero hay herramientas para ello. Vamos ha analizar las diferentes opciones de alertas en elk.

Watcher

Watcher es el producto de Elastic para la generación y envío de alertas.

Este genera alertas en base a los cambios de la información guardada en Elasticsearch.

Este funciona en base a la definición de consultas en elastisearch, la definición de condiciones, definir cada cuando se realiza la consulta (scheduler) y que acción realizar si se cumple la condición definida.

Watcher se integra en ELK como una aplicación más i forma parte del paquete de aplicaciones de pago que  Elastic vende como añadidos a ELK.

 

Elastalert

Elastalert ha sido desarrollado por Yelp para uso interno y liberado bajo licencia Apache License, version 2.0. A diferencia de Watcher, Elastalert no se integra como un aplicación de ELK, sino que se ejecuta al margen de ELK.

Este realiza queries sobre Elasticsearch de forma periódica i permite definir un conjunto de reglas en base a la cuales se envían alertas hacia diferentes sistemas como Email, Slack o Hipchat entre otras.

 

Kaae

Kaae es un nuevo proyecto que pretende ser una alternativa opensource a Watcher. Este utiliza el mismo modelo que Watcher y se integra como una aplicación de ELK.

 

Logstash

A diferencia de Watcher Elastalert y Kaae, que se basan en la ejecución de queries para obtener y analizar la información, Logstash permite configurar eventos en tiempo real. Es decir, Logstash puede generar alertas cuando recibe los datos.

Todo y que es memos completo, ya que no podemos generar alertas en base a la correlación de datos, permite generar alertas justo cuando se recibe el datos de la fuente.

La entrada ELK cómo generar alertas aparece primero en Un cio como tu ….


Source: jmgriscom

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

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

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

Provisionar entorno de desarrollo con Vagrant y Chef Zero

En el post Gestión de a configuración o Configuration Management (CM), características y beneficiosvimos que uno de los beneficios de los sistemas de gestión de la configuración como Chef o Puppet es que permiten replicar entornos de forma fácil y rápida, lo que nos permite establecer flujos de trabajo a través de los diferentes de entornos idénticos (desarrollo, test, … y producción).  Por otro lado, en el post anterior Tu primer entorno de desarrollo con Vagrant vimos como crear un entorno de desarrollo utilizando Vagrant. Hoy vamos a profundizar un poquito más en la creación de entornos viendo un ejemplo de como provisionar un servidor virtual Vagrant con Chef utilizando una herramienta llamada Chef-Zero. 

Chef-zero es un servidor Chef ligero que se carga en memoria RAM y que permite ejecutar el código Chef que hemos desarrollado, de la misma forma que haríamos sobre un servidor Chef.  No vamos a entrar en detalle en como funciona Chef-zero, sino que solo veremos como configurar Vagrant para que ejecute código chef durante el proceso de provisión.

Para empezar vamos a crear un pequeña estructura de carpetas y un fichero con código Chef que instalará el servidor web Apache.

Estructura de carpetas y ficheros a crear:

nodes/
cookbooks/micookbook/recipes/
cookbooks/micookbook/recipes/default.rb

El contenido del fichero cookbooks/micookbook/recipes/default.rb es el siguiente:

package ‘apache2’ do
action :install
end
service “apache2” do
action :start
end

en el fichero default.rb, el código chef describe dos acciones a realizar: primero utiliza el recurso llamado ‘package’ para indicar que se debe instalar el paquete apache2, y segundo, utiliza el recurso ‘service’ para indicar que el servicio apache2 debe estar arrancado.

Para provisionar un servidor Vagrant con Chef-zero tenemos que instalar en Vagrant un par de plugins, omnibus y vbguest. En caso de utilizar otros sistemas de provision, se deberían instalar los plugins correspondientes. Para instalar los plugins en Vagrant hay que ejecutar los comandos siguientes desde la consola:

vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-vbguest

Finalmente, tenemos que configura Vagrant para que utilice chef-zero para provisionar el servidor. Como vimos en el post anterior “Tu primer entorno de desarrollo con Vagrant” (Link al post), esto se hace en el fichero Vagrantfile.

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = “ubuntu/xenial64”
config.vm.provision “chef_zero” do |chef|
chef.cookbooks_path = “cookbooks”
chef.nodes_path = “nodes”
chef.add_recipe “micookbook”
end
end

En el fichero Vagrantfile del ejemplo configuramos que se utilice el sistema de provisión chef_zero. También configuramos en que carpeta se encuentran los cookbook – los cookbook contienen los ficheros con el código Chef -, y en que carpeta se guardara el fichero de definición del nodo o servidor virtual.  Finalmente, se indica que recipes – fichero con código Chef – se ejecutará durante el proceso de provisión.

Una vez creado el código Chef y configurado Vagrant, ya podemos arrancar el servidor virtual mediante el comando “vagrant up”. Durante el proceso de arranque, una vez creado el servidor virtual, Vagrant ejecuta el código Chef en instala el servidor web Apache. Si accedemos al servidor (vagrant ssh) podemos ver que se ha instalado apache y que el servicio de apache esta en ejecución.


Source: jmgriscom

Glosario

Bueno, Agosto va terminando, y con ello las vacaciones.

Por razones personales no he podido hacerlas (espero escaparme algo en un momento), y me he liado con un proyecto que os implica…..   Ya os iré contando. Y pensando un poco, ya que he pensado matar dos pájaros de un tiro sobre una idea que me dio alguien del Blog. ¿Porque no haces un post que sea un glosario técnico y lo vas actualizando?.

Pues bien, aquí os presento la primera version del Glosario técnico informático. Cualquier error o modificación que os parezca pertinente, por favor, mail o comentario y lo corregimos.

Un Saludo

Glosario

Acuerdo de Nivel de Servicio, “Service Level Agreement”, SLA: acuerdo escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio.

All in one: Literalmente “Todo en uno”. Se refiere a aquellos sistemas en que todos los elementos vienen integrados en un solo sistema.

Almacenamiento conectado en red, “Network Attached Storage”, NAS: Tecnología de almacenamiento dedicada a compartir la capacidad de almacenamiento de un computador (servidor) con computadoras personales o servidores clientes a través de una red (normalmente TCP/IP), haciendo uso de un sistema operativo optimizado para dar acceso con los protocolos CIFS, NFS, FTP o TFTP.

Almacenamiento definido por software, “Software Defined Storage”, SDS:   Concepto evolutivo del almacenamiento de datos para gestionar, mediante políticas, aprovisionamiento y gestión de gestores de datos independientes.

Alta disponibilidad, “High Availability”, HA: Protocolo de diseño del sistema y la implementación asociada que asegura un cierto grado absoluto  de continuidad

“Back-end”: Sistema o capa de acceso a datos, procesándolos desde el “Front-end” o frontal.

Baremetal: Software que se ejecuta directamente sobre el Hardware.

Bloque: Parte particionada de un disco que una SAN ofrece dentro de una LUN.

Burning: Proceso por el cual una pieza nueva que ha estado en su envoltorio es, después de su instalación, puesta en producción “quemando” los barnices que la protegían. También se aplica al proceso de Test.

Caché R/W:  Memoria intermedia que hace de almacenamiento o “buffer” para acelerar los procesos de acceso a datos. Pueden ser de lectura (R) o lectura/escritura (W).

Canal de Fibra, “Fibre Channel”, FC: Tecnología de red utilizada principalmente para redes de almacenamiento, disponible primero a la velocidad de 1 Gbit/s y posteriormente a 2; 4 y 8 Gbit/s.

Canal de Fibra sobre Ethernet, “Fibre Channel Over Ethernet”, FCOE: Tecnología de red de comunicaciones que encapsula las tramas de Fibre Channel sobre redes Ethernet.

Centro de Proceso de Datos, CPD: Sala con sistemas de protección antibandálica y sistemas de climatización y extinción preparadas para alojar los sistemas informáticos de la compañía o compañías.

CIFS: Protocolo de red que permite compartir archivos, impresoras entre nodos de una rede de ordenadores que usan el sistema operativo Windows.

Cloud: Computación la nube. Es un paradigma que permite ofrecer servicios de computación a través de una red que usualmente es Internet.

Cluster: Conjunto de computadores construidos mediante la utilización de hardware común y que se comportan como si fuera un único ordenador.

Código Abierto, “Open – Source”: software distribuido y desarrollado libremente. Se focaliza más en los beneficios prácticos (acceso al código fuente) que en cuestiones éticas o de libertad que tanto se destacan en el software libre.

Computadora Central, “Mainframe”: computadora grande, potente y costosa, usada principalmente por una gran compañía para el procesamiento de una gran cantidad de datos; por ejemplo, para el procesamiento de transacciones bancarias.

Controladora de disco, “Disk controller”:  Subsistema encargado de gestionar los discos de un sistema así como la de control de los datos de Entrada y Salida.

Convergencia de Hardware: Sistemas conformados ya en origen por la asociación de dos o más fabricantes.

Copia de seguridad, “Backup”: Copia de la información de un sistema que se realiza principalmente para ser restaurada en caso de pérdida de datos o en caso de ser requerida con posterioridad.

CPD en Cluster Dividido, “Split Cluster CPD”:  CPD en la que los recursos de computación están repartidos en los dos sites, conformando entre ellos un cluster de Alta Disponibilidad.

Datastore: Unidad de almacenamiento que usa VMware para ubicar las VMs. Detrás de éste puede haber un disco, un recurso NFS o una LUN.

Default: Valores establecidos en un sistema “Por defecto”.

Dirección IP, IP Address, IP: número que identifica, de manera lógica y jerárquica, a una Interfaz en red (elemento de comunicación/conexión) de un dispositivo (computadora, tableta, portátil, smartphone) que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del modelo TCP/IP.

Director Ejecutivo o General, “Chief Executive Officer“, CEO: La persona encargada de máxima autoridad dentro de la gestión y dirección administrativa en una organización.

Director de Tecnología e Información, “Chief Information Officer”, CIO: Responsable de toda la TI de la empresa, su estrategia, su mantenimiento y su operación, así como su seguridad, pasiva y activa.

Disco Flash SSD: Discos duro conformados por circuitería y memoria que trabaja a una elevadísima velocidad (al no tener movimiento no tiene rpm) con menos riesgos al no tener partes móviles).

Discos NLSAS: Discos duros de tipo magnético de 7,2k rpm.

Disco SAS: Discos duros de tipo magnético de 10k o 15k rpm.

Discos SATA: Discos duros de tipo magnético de 7,2k rpm.

DPACK o “Dell Performance Analisys Collection Kit”: Herramienta de análisis propiedad de Dell que permite monitorizar el numero de IOPS que consume un sistema, entre otras mediciones.

Driver: “controlador de dispositivo” o “manejador de dispositivo”, es el elemento software utilizado en diversos sistemas operativos.

Dummy: Máquinas o sistemas que han sido creados con el único propósito de “sufrir” las pruebas, sin valor informativo intrínseco.

Enchufar y listo, Plug & Play, P&P: Tecnología o cualquier avance que permite a un dispositivo informático ser conectado a una computadora sin tener que configurar, mediante jumpers o software específico (no controladores) proporcionado por el fabricante, ni proporcionar parámetros a sus controladores. Para que sea posible, el sistema operativo con el que funciona el ordenador debe tener soporte para dicho dispositivo.

“End of life”: Cuando un modelo de ordenador, automóvil, electrodoméstico, deja de ser “soportado” por el fabricante, dejando de fabricar tanto el modelo como sus recambios, el modelo ha llega a su “End of life”.

“Entry level”: Llamados así a los modelos más básicos y económico de cualquier artículo, desarrollado para que sea el “punto de entrada” para luego crecer.

FA: Fuente de Alimentación de un Ordenador, Servidor, etc.

FAS: Modelo de SAN del fabricante NetApp que se caracteriza por el uso primordial del protocolo NFS.

“FAST TRACK”: Carril rápido. En una serie de formaciones, Fast Track se refiere a una que es refundición de todas y aunque más dura, es más corta que las demás.

Fault-tolerance: Propiedad que le permite a un sistema seguir funcionando correctamente en caso de fallo de una o varias de sus componentes.

HyperConvergencia, “Hyperconverged Integrated System”, HCIS: En un entorno hyperconvergente todos los elementos de almacenamiento y computación están optimizados para trabajar junto en un solo elemento de un solo vendedor.

Hyper-V: Hipervisor y Virtualización del fabricante Microsoft.

Hypervisor: Software de ordenador que es capaz de crear y ejecutar máquinas virtuales.

Infraestructura de escritorios virtuales, “Virtual desktop Infraestructure”, VDI: Sistema o plataforma capaz de alojar y proporcionar recursos para el buen funcionamiento de máquinas virtuales con la particularidad de que las VMs son escritorios y van supeditados a un gestor o “Broker”.

Infraestructura Virtual, “Virtual infraestructure”: También denominada “On premise Cloud”. Sistema o plataforma capaz de alojar y proporcionar recursos para el buen funcionamiento de máquinas virtuales.

iSCSI: estándar que permite el uso del protocolo SCSI sobre redes TCP/IP.

Kick-off”: Primera reunión de un proyecto importante donde se explícitan objetivos, responsables, fechas de cumplimiento así como todos los actuantes.

KVM: Hipervisor del fabricante Red Hat.

Lista de Compatibilidad de Hardware, “Hardware Compatibility List, HCL: Lista de Hardware , incluyendo periféricos, etc, que cierto fabricante declara compatibles con cierto Sistema Operativo.

Lista de verificación, “Check-List”: Lista de verificación que se efectúa para que antes de poner en marcha un sistema o dispositivo, el operador esté seguro de que se han efectuado todas las operaciones previas precisas.

Mantenimiento adaptativo: Modifica el sistema en producción para poderlo adecuar o adaptar a nuevas normas de empresa, legales o cambios en la tecnología.

Mantenimiento correctivo: Aquel que corrige los defectos observados en los equipamientos o instalaciones, es la forma más básica de mantenimiento y consiste en localizar averías o defectos y corregirlos o repararlos

Mantenimiento evolutivo: Aquel que instala los nuevos releases o versiones o soluciona algún error menor.

Memory Balooning: Técnica para reclamar memoria en un ordenador usada por un hipervisor para permitir al sistema del host físico para recuperar memoria no usada de cierto Sistema Operativo de una VM y compartir con otras.

Migración “cut in cut off”: Migración planteada con la estrategia “paramos A”, “arrancamos B”.

Migración Smooth: Migración planteada con la estrategia de una forma escalonada i creciente.

Morning storm: Se refiere al colapso que puede sufrir la SAN cualquier mañana cuando todos los escritorios o VDI se ponen en marcha a la vez por los usuarios, requiriendo cantidades ingentes de IOPS de la SAN.

Murphy: Edward Aloysius Murphy, (11 de enero de 1918 – 17 de julio de 1990) fue un ingeniero aeroespacial estadounidense. Murphy trabajó en sistemas de seguridad críticos y es conocido por la homónima Ley de Murphy, que declara que “Si hay varias maneras de hacer una tarea, y uno de estos caminos conduce al desastre, entonces alguien utilizará ese camino”.

Multiprocesamiento simétrico, “Simetric Processing”, SMP: Los sistemas SMP permiten que cualquier procesador trabaje en cualquier tarea sin importar su localización en memoria; con un propicio soporte del sistema operativo, estos sistemas pueden mover fácilmente tareas entre los procesadores para garantizar eficientemente el trabajo.

Nodos: Puntos en redes que confluyen en un mismo lugar. Pueden ser cada ordenador de una red o cada servidor en Internet.

Núcleo, “Core”: Cada uno de los procesadores “lógicos” que alberga el procesador o “Socket” físico.

Objetivo de Punto de recuperación, “Recovery Point Objective”, RPO: Punto definido por el Plan de continuidad de negocio. Es el máximo período de tiempo que es asumible una pérdida de datos.

Objetivo de Tiempo de Recuperación, “Recovery Time Objective”, RTO:  tiempo definido dentro del nivel de servicio en el que un proceso de negocio debe ser recuperado después de un desastre o pérdida para así evitar consecuencias debido a la ruptura de continuidad de servicio.

Obligatorio, “Mandatory”: De obligado cumplimiento.

Obsolescencia programada, “Planned obsolescence”: Programación del fin de la vida útil de un producto.

Operaciones de Entrada Salida por segundo, IOPS: unidad de benchmark usada para medir el rendimiento de dispositivos de almacenamiento informáticos como unidades de disco duro (HDD), unidades de estado sólido (SSD) y acceso a almacenamiento en red (NAS).

Pasillos fríos y calientes: Técnica en los CPD para que con unos cierres semi estancos los ordenadores reciban por delante, de un pasillo frio, aire acondicionado, siendo este expulsado por detrás una vez utilizado y calentado a un pasillo caliente que disipara el calor.

Placa madre, “Mother Board”: La placa base, también conocida como placa madre o placa principal (motherboard o mainboard en inglés), es una tarjeta de circuito impreso a la que se conectan los componentes que constituyen la computadora.

Planificador de Capacidad, “Capacity Planner”: Herramienta en Cloud de VMware capaz de dimensionar una granja física ofreciendo un report de volumetrías.

Procesador: Ver CPU.

Proxmox: Virtualizacion Open Source.

Punto único de fallo, “Single Point of Failure”, S.P.O.F. Para garantizar la inexistencia de un SPOF en un sistema, todos sus componentes suelen ser redundados, conformando así un sistema de alta disponibilidad, que garantiza el correcto funcionamiento aún en caso de que alguno de sus componentes falle.

Recuperación de desastres, “Disaster recovery Plan”, DR: Proceso de recuperación que cubre los datos, el hardware y el software crítico, para que un negocio pueda comenzar de nuevo sus operaciones en caso de un desastre natural o causado por humanos.

Rollback: operación que devuelve a la base de datos o sistema a algún estado previo.

Sistemas de archivo en red,“Network File System”, NFS: protocolo para compartición de archivos, creado por Sun Microsystems para SunOS en 1984. Se caracteriza por compartir carpetas.

Red de Area de Almacenamiento, “Storage Area Network”, SAN: Una SAN es una red dedicada al almacenamiento que está conectada a las redes de comunicación de una compañía. Además de contar con interfaces de red tradicionales, los equipos con acceso a la SAN tienen una interfaz de red específica que se conecta a la SAN.

StoragevMotion: Componente de VMware vSphere que permite la migración en vivo de una VM en ejecución de sus ficheros, de un datastore a otro.

Support & Subscription: Es la quota que se abona al fabricante por concepto de “mantenimiento”, el primer concepto se refiere a que el fabricante dará soporte para que funcione el sistema, el segundo, que el cliente mantiene la capacidad de instalar siempre la última versión del sistema sin coste.

Sistema Operativo, “Operating System”, O.S., S.O.: Programa o conjunto de programas de un sistema informático que gestiona los recursos de hardware y provee servicios a los programas de aplicación de software.

Tarjeta de Red, “Network Card”, Nic:  es la periferia que actúa de interfaz de conexión entre aparatos o dispositivos, y también posibilita compartir recursos (discos duros, impresoras, etcétera) entre dos o más computadoras, es decir, en una red de computadoras.

Tecnología de la Información, “Information Technology”, TI, IT: Concepto que abarca lo otrora llamada “Informática”, con hincapié en su parte crítica en el negocio y su valor en la cadena de la empresa u organización.

Test de Carga: Valida y verifica atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos.

Test de tolerancia fallos: Validan todos los elementos redundados que se han incluido en el diseño para evitar los S.P.O.F.

Throughput: es definido como la velocidad real de transporte de datos a través de una red telemática, el cual normalmente se mide en Mbit/s y siempre será inferior al ancho de banda o bandwidth.

UCS: Model de servidor de Cisco.

Unidad de Procesamiento Central, “Central Process Unit”, CPU: Subsistema de un ordenador que interpreta las instrucciones de un programa informático mediante la realización de las operaciones básicas aritméticas, lógicas y de entrada/salida del sistema.

Update: Supone un a nueva versión en la reléase, significando una “major” o “standalone” significando hallarse en una nueva versión.

Upgrade: Supone una subida en la versión de la reléase, pero continúa estando en la misma versión.

vApp: Permite a diferentes VMs trabajar como una sola máquina trabajando juntas en un stack.

Versión, Release: número o nombre que se asigna a un programa informático para mencionar su nivel de desarrollo y su actualización. Lo habitual es que el versionado esté dado por dos números, separados por un punto.

vCPU: También conocido como procesador virtual, es una unidad de procesamiento central física que ha sido asignada a una VM.

Virtualización: Creación a través de software de una versión virtual de algún recurso tecnológico, como puede ser una plataforma de hardware, un sistema operativo, un dispositivo de almacenamiento u otros recursos de red.

VM: software que simula a una computadora y puede ejecutar programas como si fuese una computadora real. Este software en un principio fue definido como “un duplicado eficiente y aislado de una máquina física”. La acepción del término actualmente incluye a máquinas virtuales que no tienen ninguna equivalencia directa con ningún hardware real.

vMotion: Permite la migración “en vivo” de una maquina virtual en ejecución desde un host físico a otro, sin caída de servicio.

 

Take care


Source: jmgriscom

Tu primer entorno de desarrollo con Vagrant

Vagrant es una herramienta que nos permite crear y configurar entornos virtuales de desarrollo de forma fácil. La ventaja de crear un entorno de desarrollo con Vagrant es que lo podemos ejecutar sobre nuestro portátil o estación de trabajo, sin necesidad de utilizar infraestructuras externas. Podemos arrancar y parar el entorno tantas veces como queramos y finalmente lo podemos compartir con el resto del equipo de sistemas y desarrollo para que estos lo puedan ejecutar en su portátil.

Con Vagrant podemos ejecutar servidores virtuales con Windows, Linux o Mac OS X, y lo podemos hacer utilizando los hypervisores VMware Workstations, VMware Fusion o VirtualBox. Además Vagrant también dispone de conectores para ejecutar estos servidores virtuales sobre proveedores de infraestructura como AWS Amazon o Digitalocean entre otros.

Cuando utilizamos Vagrant con un sistema de gestión de configuración como Chef o Puppet, podemos desplegar una copia exacta de un entorno de producción sobre nuestro portátil. Donde podemos hacer cambios de configuración y probarlos antes de aplicarlos a producción.

A continuación veremos un ejemplo de como crear un entorno de desarrollo utilizando Vagrant con el hypervisidor Virtualbox para crear un servidor Linux con Ubuntu 16.04 LTS.

Antes de nada, hay que instalar tanto VirtualBox como Vagrant en nuestro portátil. Una vez instalado VirtualBox y Vagrant, debemos buscar la Vagrant Box (imagen de disco) del sistema operativo que queremos instalar,  en nuestro caso Ubuntu 16.04 LTS. En https://atlas.hashicorp.com/boxes/search buscamos la Vagrant Box de Ubuntu 16.04 LTS que se llama “ubuntu/xenial64”.

El siguiente paso es crear el fichero Vagrantfile. Este tiene la finalidad de establecer el directorio del proyecto y describir el entorno que vamos a instalar y su configuración. Para crear el fichero Vagrantfile con la Vagrant Box “ubuntu/xenial64” abrimos un terminal en el directorio donde queremos crear el servidor virtual y ejecutamos el comando siguiente:

vagrant init ubuntu/xenial64

Al ejecutar vagrant init se crear el fichero Vagratfile en el directorio desde donde hemos ejecutado vagrant init. Este se ha configurado con la Vagrant Box “ubuntu/xenial64”. Si editamos el fichero Vagrantfile veremos que ha configurado el parámetro “config.vm.box” con la Vagrant Box “ubuntu/xenial64”.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = “ubuntu/xenial64”
end

Esta es la configuración basica del fichero Vagratfile, pero en el podemos configurar uno o más servidores virtuales que formaran nuestro entorno de desarrollo, y para cada uno de estos servidores podemos configurar sus recursos como la ram, ips, etc. En el fichero Vagrantfile también podemos configurar el método que vamos a utilizar para provisionar cada servidor.  Por ejemplo, podemos provisionar el servidor mediante un script bash o mediante un sistema de gestión de la configuración como Chef o Puppet. En otro post veremos como provisionar el servidor virtual mediante Chef.

Antes de arrancar el servidor descargamos la Vagrant Box y la guardamos en local para evitar que esta se descargue cada vez que arrancamos el servidor virtual.

vagrant box add ubuntu/xenial64

Cuando ya tenemos la Vagrant Box descargada ya podemos arrancar el servidor virtual, acceder por SSH y finalmente destruirlo cuando ya hemos finalizado el desarrollo.

Arrancar el servidor virtual:
vagrant up

Acceder por SSH al servidor virtual:
vagrant ssh

Destruir el servidor virtual:
vagrant destroy


Source: jmgriscom

DevOps con proveedores externos

 

Hay una pregunta que cualquier empresa puede hacerse cuando se plantea implantar prácticas de DevOps. ¿Puedo implantar prácticas DevOps cuando trabajo con proveedores externos ?

Son muchas las empresas que utilizan proveedores externos, ya sean estos desarrolladores, consultoras o proveedores de servicios. Y además, estos equipos externos realizan su trabajo remotamente desde diferentes lugares y zonas horarias. Para implantar Devops con proveedores externos hay un conjunto de pautas que ayudan a que la colaboración sea fluida.

 

Lo primero y esencial es establecer una comunicación abierta. La comunicación entre todos los equipos de trabajo, internos y externos, debe establecerse en todas las etapas, desde la fase de planificación a las fases  de pruebas, despliegue o operación. Es importante que todos los actores conozcan y participen en la definición de los proyectos y en la planificación. Para ello, es altamente recomendable establecer reuniones periódicas presenciales si es posible. El contacto genera empatía, permite compartir conocimiento e ideas y permite entender al otro, uno de los aspectos en que pone énfasis DevOps. En caso de no ser posible hacer reuniones presenciales, pueden hacerse reuniones utilizando programas de video conferencia como Skype o Hangouts.

DevOpsConProveedoresExternos

También es importante integrar a los equipos externos en los sistemas de mensajería internos como listas de correo, sistemas de Chat y permitir el acceso a los espacios de trabajo compartido como los recursos de red.

Por otro lado, también se puede integrar a los equipos externos en los procesos operativos y en los sistemas de gestión utilizados como los repositorios de código fuente, aplicaciones de gestión de proyectos, sistemas de monitorización, sistemas de automatización, etc.

Otro aspecto que ayuda mucho a la colaboración entre equipos remotos, es utilizar sistemas de virtualización o en cloud para el despliegue de los entornos de desarrollo y testing. Los sistemas de virtualización permiten a los equipos externos reproducir las infraestructuras de forma fácil y económica, y sin necesidad de compartir los sistemas internos.

En definitiva, el hecho de utilizar proveedores externos no debe ser un problema para utilizar prácticas DevOps. Lo que si que hay que ver en cada caso es como establecer una comunicación fluida entro todos los equipos de trabajo y como integrar a estos proveedores externos en los procesos internos de la empresa.
Source: jmgriscom