Category Archives for "Assoc. Cat. Virtualització"

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

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

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

Reclamando espacio en cabinas Thin Provision a nivel de vSphere

Una de las grandes novedades que trajo vSphere 5.0 fueron las APIs de integración con las cabinas para optimizar ciertas tareas, sobretodo aligerando la carga del hipervisor. La idea es pasar esta carga a la cabina, quien tiene más facilidad para operar con los datos que ya residen en ella.

Si tenemos una cabina con configuración compatible con estas APIs, las tenemos habilitadas por defecto por lo que el uso de muchas de sus funcionalidades las usamos de manera transparente. Sin embargo, hay algunas de estas “primitivas” que nos pueden ayudar muchísimo pero hay que conocerlas, puesto que requiere que las invoquemos de alguna manera. Una de ellas es “Unmap”:

“Unmap” resuelve un dolor de cabeza con el que te habrás enfrentado si usas una cabina con Thin Provisioning, que es la reclamación. Thin Provisioning, como toda innovación, aporta muchas ventajas pero también tiene sus consideraciones. Una de ellas es la necesidad de reclamar el espacio inutilizado.

Este espacio se genera cuando el SO de nuestras máquinas virtuales deja de usar una cantidad de almacenamiento que anteriormente usaba. Lo que sucede es que en realidad, el sistema operativo marca este espacio como libre pero no hace lo propio la cabina, quien aún lo mostrará como espacio ocupado en nuestros Disk Groups.
A nivel de vSphere es más sencillo de entender: Supongamos que tenemos una LUN/Datastore de 500GB de capacidad con una VM en ella de 100GB en uso. En ese momento, nuestro Disk Pool en la cabina marcará que tenemos 100GB utilizados. Pero pongamos que, por algún motivo, tenemos que restaurar esa misma VM, en esa misma LUN. Sin problema, podremos mantener las dos VMs y nuestro Datastore marcará un uso de 200GB, hasta que a posteriori, cuando eliminemos la VM original, el uso de nuestro Datastore será 100GB de nuevo. Sin embargo, en nuestro Disk Pool, aparecerán usados 200GB. Tradicionalmente, el procedimiento por el cual recuperábamos esos 100GB que corresponden a la VM original consistía en crear un VMDK “Thick Provisioned – Lazy Zeroed” de un espacio un poco menor que el que marca el Datastore como libre. En nuestro ejemplo, el Datastore marcará 400GB libres por lo que creando un VMDK de ese modo, lo que haremos es marcar todos los bloques que use ese nuevo disco a cero. Una vez realizado, tendremos que decirle a la cabina que reclame espacio en ese Disk Pool. Lo que hará este comando, es buscar bloques a cero que no estén en uso, por lo que podremos recuperar casi la totalidad de los 100GB que ocupaba la VM que hemos ocupado.

Este método conlleva bastantes problemas potenciales más allá de su relativa complejidad:
El paso de crear el VMDK en Eager Zeroed marcará en cero bastantes bloques. Esta operación es bastante pesada para la cabina por lo que podríamos impactar en el rendimiento de otros servicios. Volviendo a las VAAI, otra primitiva que ayuda un montón es “Write Same”. Tradicionalmente, cuando un host ESXi quería marcar a cero bloques (como al crear un disco en Eager Zeroed), lo hacía mandando comandos SCSI a la cabina que lo cargaban en ciclos de procesador y sobretodo, en la cola de la HBA de turno. Con VAAI esta operación la realiza la cabina de manera transparente descargando al host, pero si no es compatible nuestra LUN, querremos tener control con esta operación.
No podemos crear un VMDK del mismo tamaño que el que marca el datastore como libre, pues lo llenaríamos y bloquearíamos las VMs que se ejecutan en él. Igualmente, querremos quedarnos cuanto más cerca posible de ese valor para recuperar cuanto más espacio. La avaricia rompe el saco, cuanto más cerca queramos quedarnos, en más riesgo entraremos.

Todo este procedimiento podemos resumirlo en un simple comando, el comando de esxcli “unmap” (valga la redundancia). Además, nos va a recuperar todo el espacio realmente disponible, pues va iterando en búsqueda de bloques ya no usados y los marca a cero automáticamente. Es importante remarcar que, aunque VMware anuncia que a partir de 5.5 el impacto es mínimo, igualmente vamos a sobrecargar cabina al reclamar, así que mejor hacerlo en horario de mantenimiento.

Visto lo que nos puede aportar “unmap”, veamos cómo podemos invocarlo.

Primero de todo, debemos tener el UUID del datastore anotado. Nos conectaremos por SSH a cualquier ESXi que tenga ese Datastore presentado y, una vez dentro, anotaremos qué UUID tienen las LUNs sobre las que queremos reclamar. Para ello, ejecutaremos el comando
# esxcli storage vmfs extent list.
El output nos dará un listado de los Datastores que ve el host con el nombre que les hayamos dado, y al lado qué UUID tienen las LUNs que lo componen, en la columna “Devices”. Tomamos nota de la que nos interesa y listo.
Antes de nada, tendremos que asegurarnos que nuestro datastore soporta VAAI. Para verlo, # esxcli storage core device vaai status get -d naa.xxxxxxxxxxxxxxxxxxxxxxxxxx. El campo “Delete” debe estar en “Supported”.
En este momento ya lo tenemos todo listo para ejecutar el comando “unmap”. Solo queda por discutir un punto: cuantos bloques vamos a “unmapear” por iteración. Aquí, lo mejor es hablar con el fabricante de vuestra cabina para acordar qué valor le damos. Así que estamos preparados, vamos a ejecutar:
# esxcli storage vmfs unmap –u XXXXXXXX-XXXXXXXX-XXXX-XXXXXXX –n YYY, donde la cadena de Xs será el UUID que anotamos en el paso 1 y las Ys el número de bloques que queremos que reclame por iteración.
Por último, podremos monitorizar el proceso mediante esxtop. Ejecutamos el comando # esxtop en nuestro ESXi, clickamos “u” para ir a la ventana de discos/devices, clickamos “f” y escogemos qué campos queremos mostrar.

fields

Depende de la resolución de vuestra pantalla, seleccionad solo el campo de “Device name”, que nos mostrará los naa de las LUNs y “o” y “p” para ver las métricas de comandos de VAAI. Además, si os cabe, podéis incluir el campo “i” para ir monitorizando también los tiempos de latencia en general (R/W) y poder ir viendo que no tengamos ningún susto.

Entonces, una vez hemos seleccionado los campos que queremos ver en nuestra ventana de esxtop y hemos ejecutado nuestro comando de unmap en una LUN, veremos algo como esto:

extop

Las columnas que nos interesan son:
DELETE: número de comandos de unmap que se han ejecutado sobre la LUN
DELETE_F: número de comandos de unmap que han fallado sobre la LUN
MBDEL/s: MB que está “unmapeando” en este momento el comando que hemos ejecutado. Aquí solo deberías ver distinto de cero la LUN que has seleccionado.

Por último, tendremos que reclamar. Recordad que con unmap estamos liberando bloques, o informando a la cabina de qué bloques ya no están en uso en vSphere. Lo que faltará és que la cabina los reclame y por lo tanto los marque como Free en nuestro Disk Pool. Aquí ya cada una lo hará a su manera. La mayoría tendrán un botón de “Reclaim” que barrerá todo el Disk Pool en búsqueda de los bloques que habremos liberado, y que por lo tanto, pueda marcar como libres. En el caso de Datacore por ejemplo, al ejecutar el comando de unmap, se dispara automáticamente la funcionalidad de “Auto-Reclaim” que lo que hará será ir reclamando los bloques que vamos liberando de manera transparente, unmap lo desencadena todo. Lo veréis así (Storage Source – Online, auto-reclamation in progress):

cabina


Source: jmgriscom

vCheck para vSphere: Informes de nuestra infraestructura mediante PowerShell

 

Vengo esta semana con un post de alcance para presentaros otra herramienta que, siguiendo la línea de de los últimas semanas, nos aportará de manera sencilla y pseudo-nativa reportes de nuestro entorno de vSphere. En este caso, hablaremos de vCheck que nos dará un overview de nuestro entorno virtual y un detalle de los problemas que pueda presentar.

Además de ser una herramienta bastante utilizada y reconocida, he querido aprovechar para presentarla estos días porque en el VMworld que tendrá lugar a finales de este mes de agosto en Las Vegas se ha organizado un Hackhaton donde uno de los puntos que se va a desarrollar va a ser precisamente vCheck, esperemos que salgan mejoras y desarrollos interesantes. Por cierto, si tenéis la suerte de andar por Las Vegas el dia 29, os recomiendo mucho asistir al Hackhaton de VMware Code, podéis registraros a este evento aquí

Está basada en PowerCLI, la interface y cmdlets de PowerShell para gestionar las soluciones de VMware. Basta con disponer de PowerShell en versión 3.0 o superior, tener PowerCLI instalado y disponer del script de PowerShell que nos lanzará el reporte.

Podéis descargar el script aquí y disponéis de un pequeño vídeo de introducción donde el mismo Alan Renouf, desarrollador del script cuenta como empezar con ello.

sVMWare_preston_vcheck_report
Source: jmgriscom

 

EL CÓDIGO

 

El texto no es mío. Llego a mí no se como, sinó, citaría su procedencia.

El texto es largo y friki, pero para los que nos dedicamos a esto de la IT, cuando lo vas leyendo, vas sonriendo, porque reconoces muchas, muchas situaciones.

Os lo recomiendo leer, porque la moraleja es importante y hay más de una. No me alargo más, porque hay tela que cortar…….  PS. Muchos casos ahí expuestos los he vivido en propia carne 🙂


El código

Tengo la boca grande como un buzón. Media vida metido en el departamento de informática y aún me tengo que castigar el lomo yo mismo por lo inocente que soy. Pero no digo que tenga la boca grande por ser indiscreto, o faltón, que también; sino porque cada vez que me preguntan contesto con lo que yo sé que es verdad y no con lo que quieren escuchar.

Ser honesto en la vida es una puta mierda. Suprakillminds depende enormemente de la buena marcha de una aplicación muy particular. La dichosa aplicación la usan muchos usuarios y ha de ser rápida, veloz y ligera cual gacela huyendo de un guepardo con hambre de seis días y zapatillas nuevas. Cuando compraron la aplicación, y maldigo al lenguaje HTML por no tener suficientes herramientas de formato para remarcar el “compraron”; resultó que todo iba como la seda. Asignamos un servidor normalito, con treinta y dos gigas de RAM y dos procesadores de ocho núcleos con tres discos SAS de trescientos gigas en RAID 5. Una cosa normalita para mover una base de datos e intercambio de ficheros de operaciones. La aplicación en cuestión se comunica con dispositivos remotos mediante un fichero que se deja en un directorio y los dispositivos remotos preguntan si hay algo mediante FTP, o si tienen que dejar algo para que la aplicación procese, pues lo dejan mediante el mismo sofisticado mecanismo. Hasta ahí todo muy siglo XX, pero bien.

Entonces, la parte servidora hace lo que coño sea que tenga que hacer y devuelve el resultado a impresoras, dispositivos, gente, máquinas de café, etc. Todo esto que cuento no puede parecerle a nadie ni medio complicado. No lo es. De hecho, las operaciones se parecen mucho a un carrito de la compra. Sin embargo, de un tiempo a esta parte, la aplicación se ha ralentizado hasta límites inaceptables. La base de datos no es. Aquí mi colega el MKII ha sacado los diplomas Emecé, los ha puesto encima de la mesa y ha tuneado la base de datos puesto que el servidor de bases de datos fue forjado en Mordor. De hecho, la base de datos responde ahora como un puto tiro. Me voy a tener que hacer un Emecé para aprender cosas tan chula. No quisiera quitarle méritos a MKII por nada del mundo. Es un tío formado y serio. Pero que digo yo que se tiene que notar el aumento de rendimiento si pones índices coherentes a las tablas de la base de datos. Aunque sea uno. Porque no tenía ni un mal índice. Nada.

Descartada la base de datos miramos el procesador. Los procesadores. Nada. La aplicación provocaba algunos picos pero nada que perturbase la paz de los dieciséis núcleos instalados. Tan panchos estaban limándose las uñas. La memoria no era tampoco. Había memoria libre para aburrir. El disco tampoco estaba muy ocupado, la verdad. La red local estaba tocando las palmas y los enlaces al exterior relajados y con capacidad testada. No era tampoco. Aquello tenía pinta de que iba a ser el pin siete del RJ45 o que habíamos encendido el servidor con el dedo en ángulo de doce grados en lugar de dieciséis. Vamos, que sólo nos quedaba un sospechoso: el programa. Y ahí estuvo mi error. $Hyperboss fue informado pertinentemente por Gargamel de un problema informático sin resolver y nos reunió a MKII y a mi en su despacho. Muy serio. -Pero vamos a ver, Wardog: si el servidor es muy lento, cámbialo. -Que no. que no es lento, oiga. El servidor no es. -¡Ponle más memoria! -No le hace falta, no la está gastando. -¿Entonces? -Como no sea el programa… -¿Y por qué iba a ser el programa? -Por exclusión. Me quedan el programa y los usuarios. Y por una vez les voy a dar un voto de confianza a los usuarios porque no pueden tocar nada de la aplicación, sólo la echan de comer. –

Pues llama a los del programa. -Ya lo he hecho. -¿Y qué te dicen? -Que es por la red de la empresa, que a ellos les va bien. -¡Pues cambia la red! -No. Va bien. La red no es. -¿Lo sabrán mejor los del programa, no? -No. Ellos ni puta idea de cómo va nuestra red. Ellos saben de su programa. -Vale, pues si no es la red, ¿qué es? -Insisto: el programa o el usuario. Descarto el usuario. -Pues busca otra causa. -Un pitufo epiléptico ha estado practicando sexo tántrico con doce sapos encantados sobre los portales RFID me parece una causa razonable. -¡Una causa seria! -Con todos los respetos- interrumpe EL Máquina II,- pero Wardog tiene razón. No puede ser otra cosa que el programa. Hemos descartado las demás opciones y no tenemos ningún interés en llevar razón, sino que simplemente, el resto de posibles causas están funcionando perfectamente. -Vamos a ver si nos entendemos, muchachos-, se frota el puente de la nariz concienzudamente.- He pagado una cifra considerable a una empresa de desarrollo de software muy conocida para que esa aplicación vuele. No me puedo creer que, después de seis meses, ya no funcione. Algo habéis tocado. -No. Conforme la dejaron los artistas de $Bullshitsoft está. De hecho, ni siquiera hemos habilitado ningún puesto nuevo ni hemos quitado los existentes. Cero cambios. -¡Pues algo tiene que ser!- dice con un puñetazo en la mesa. -¡Pues es el programa!- replico con una palmada y un firulillo flamenco por encima de la cabeza. Nos miramos fijamente a los ojos. Él con el puño aún en la mesa. Yo, con la mano a diez centímetros de la cabeza y la palma hacia arriba. –

El programa no puede ser, Wardog. Que me ha costado una millonada. -Primera fase del duelo: negación. El Titanic también costó una millonada. Y ahí está, en calo. -Pues mira a ver qué falla en el programa y arréglalo. -No puedo. -¿Cómo que no puedes? -No puedo. Sabemos que en los dispositivos el cambio de una pantalla a otra tarda mucho, pero no sabemos qué coño hace en el intervalo. A veces la conexión explota y otras veces suelta un error inespecífico. Pero sin el código fuente no podemos saber qué es lo que le pica. -¡Pues que lo arreglen los de $Bullshitsoft! -No. Como son tan guays y tan caros, si no les damos un diagnóstico claro, no mueven un dedo. -¿Cómo que no? -Como que no. Que o les decimos qué va mal o no pueden hacer nada. Y nuestra mejor aproximación a un diagnóstico detallado es: “Todo va lento”. -¡Ponme con ellos! Marco el número en el teléfono de sobremesa de $Hyperboss. Pide hablar con soporte. Grita mucho. Dice que va lento. Se calma. Dice que eso espera. Cuelga. –

Ya está, solucionado. -¿Ya va rápido el programa? -No, joder. Mañana tenemos aquí a un ingeniero de la empresa para arreglarlo. Sólo hacía falta ponerse duro. -Entonces no está solucionado. -¡Pero mañana estará solucionado! -Vale, vale, si yo lo decía por hablar con propiedad. Al día siguiente, a las nueve de la mañana se presentó un ingeniero de $Bullshitsoft en $Suprakillminds, con su chaqueta, su corbata y las manos en los bolsillos. $Deity me libre de prejuzgar a la gente, pero mi olfato canino para detectar imbéciles me estaba alertando acerca de este individuo. Le cogí de la manita y me lo llevé, a petición suya, a ver cómo iban de lento los terminales equipados con su software. Se colocó detrás de un operario para ver cómo trabajaba el hombre. -Ahá-. Dijo muy concentrado el ingeniero.- Parece que tenemos un problema de velocidad. -¡No me digas! ¿Cómo lo has notado? ¿Quizá por el hecho de que nuestro operario puede pulsar un botón cada minuto y medio? -Sí. Parece que hay algo que ralentiza la aplicación. -Y así, concretando más… -No sé. Pero efectivamente, va todo muy lento. -Eso ya lo sabíamos y os lo hicimos saber. -Pero ahora ya lo sabemos con certeza. -Anda. Oye, me tienes que decir dónde estudia uno la carrera de saber las cosas con certeza. Porque ya hemos comunicado en varias ocasiones que todo el aplicativo se arrastra como una babosa coja. -Bien, yo hablaré con los programadores para que lo revisen. -¿Para que revisen qué? -El problema de lentitud. -¿Y cuál es la causa concreta por la que va lento? -No lo sé, es algo general. -Tócate los cojones.

Yo, de verdad, con vosotros es que aprendo. ¡Ay si yo me hubiese hecho ingeniero en vez de puta! El ingeniero ingenioso se fue con las manos en los bolsillos as fast as he came. Dejando en mi correo electrónico un precioso informe de dos líneas redactado al vuelo con su Ladrilloberry. Eso es un usuario móvil avanzado, amigos. Le enseñé el informe a $Hyperboss. Lo leyó doce veces, incrédulo. El informe rezaba: Detectada ralentización en todos los procesos de la aplicación. Se pasa tarea a soporte para corrección y puesta en producción. Y debajo la firma del Ingeniero en Diagnósticos por la prestigiosa Universidad Handinpockets. Casi podía apreciar cómo la ira se abría camino desde la vésicula biliar de $Hyperboss hacia su garganta y cómo el hombre, en un esfuerzo de autocontrol la retenía ahí. -Wardog… ¿cómo se llama eso que decís los informáticos para tocar los programas? -¿Dedo? – juego con él. -No, coño. Lo de programar. -Ah. Código fuente. -Si os consigo el código fuente, ¿podéis mirar qué coño le pasa a la aplicación? -Podemos intentarlo. Pero no le van a dar el código fuente. -Ya te digo yo que sí me lo dan. Dicho y hecho. Al día siguiente $Hyperboss se presentó en el departamento mientras desayunábamos y me puso en la mesa un pendrive con el código fuente de la aplicación de los cojones.

MKII y yo lo miramos atemorizados. Parece vibrar quedamente, emitir una especie de fulgor fantasmagórico. Era algo difícil de explicar. Como una luz oscura. Como si estuviese iluminado por la oscuridad que emitía. Al final lo cogí con más curiosidad que ganas y lo puse en mi equipo. Abrí el pendrive y vi que contenía un directorio de nombre “SRC”. Vamos bien, hasta ahí lo entiendo. Abro el directorio y veo el nombre Suprakillminds. Abro y tenemos “srv” y “clt”. Joder, qué bueno soy. Hasta aquí entiendo todo. Abro primero “srv” y veo un proyecto de Mordor Cé Cross Plus. Abro el proyecto y ante mí se muestra en toda su grandeza. Siempre me maravillo cuando veo un programa hecho con un lenguaje orientado a objetos que no implementa ni una clase. De hecho, el programa principal parece ser un monolítico fichero. Todo corre en un gigantesco loop cuya única condición de salida es, al parecer, un valor uno en una variable de nombre “salir”.

Empiezo a leer mientras MKII gestiona cosas, pero tanto me oye bufar que se trae la silla a mi puesto y se pone a leer en la pantalla. -Mira, tenemos seis scrolls completos sólo para las variables globales. No está mal, ¿eh? -¿Y por qué hay tantas variables globales? -Y yo qué sé. Espera, espera, terrible sospecha. Mira, ahí está. -¿El qué? -¿No lo ves? ¡Todas las funciones devuelven void! -¡No jodas! -¡Claro! ¡Son unos cracks! ¡Si todas las variables son globales no hace falta pasar parámetros ni devolver valores! -Pero eso no es eficiente. -¡Porque tú lo digas! ¡Es súper efectivo! ¡Efectivo que te defecas haciendo estrellitas! -¿Hablas en serio? -No. Ah, mira, ¿ves? Aquí hay funciones que no devuelven void. Desde luego, qué malpensado somos. -Oye, pero esa función… -Sí, ¿qué pasa? Suma dos variables globales y devuelve el resultado. Y te callas que te veo un poco talibán del Mordor Cé Cross Plus. -¿Hablas en serio? -Que no, coño, pero es que si no relajo tensiones con las coñas me van a empezar a sangrar los ojos. -Espera, espera, ¿qué es eso?- me dice MKII abriendo mucho los ojos y señalando la pantalla. Me da palmaditas con su mano helada en el antebrazo. -Oh. $deity desdoblado. Me envaro en la silla y empiezo a hiperventilar.

Antes nuestros estupefactos ojos se muestran brillantes, sólidos, rotundos y pulidos, incontables GOTOs destacando sobre el blanco del editor como una macha de sangre fresca en la nieve. Pero no es sólo el GOTO infame. Es que, uno tras otro, y sin orden lógico aparente, los GOTOs envían la ejecución del programa a etiquetas de nombre tan específico como “Label1″, “Label2″, “Label7″ y así hasta “Labeln” siendo n un número entero desaforado. Con los ojos a punto de salírsenos de las órbitas nos levantamos sin decir nada en busca de bálsamo caliente. Por el pasillo nos encontramos a $Hyperboss. Le miramos con nuestra cara de espanto. -¡Qué tal chicos! ¿Entendéis el código fuente ese? Salimos corriendo gritando mucho con los brazos levantados. Bueno, esa fue mi primera intención; y sé que MKII me hubiese imitado, pero no. Permanecimos con nuestra cara de espanto estoicamente. -¿Chicos? ¿Lo podéis arreglar? -Mire, $Hyperboss… eso no se puede arreglar. Por mucho que queramos. Es una perversión. Es… es… -¿Ya estamos con las quejas? Primero que si no tenéis el código fuente, luego que si lo tenéis. –

$Hyperboss- dice MKII.- Ese programa es obsceno. -Está tan mal hecho que parece fabricado con trozos aleatorios de manual. MKII y yo nos miramos inmediatamente. Claro, por eso las etiquetas de los gotos se llaman Labelx. Trozos de manual. -Becarios- decimos al unísono. -¿De qué habláis? -Este programa lo han debido hacer becarios en precario. -¿Con lo que cuesta lo van a haber hecho becarios? ¡Que es una empresa seria! -Con lo que cuesta. El programa compila y funciona cumpliendo los requisitos. Facturado. Los becarios son gratis o baratos. Más margen de beneficio.- replico. -Bueno, da igual. Me ha costado mucho conseguir el código fuente. Arregladlo como sea. -Haremos lo que esté en nuestra mano.- contesta demasiado dispuesto MKII. Con un café en el cuerpo la cosa parece más soportable. El ejecutable principal de la parte cliente no parece tener más problemas que la sobredosis de tumores de código. El hijo de puta es feo y deforme, pero como sólo tiene que recoger unos ficheros, leerlos y meterlos en la base de datos y vive en una máquina absolutamente sobredimensionada, corre que se las pela. -Pero hay una cosa que no veo.- Dice MKII. -¿El qué? -¿Cómo pasa parámetros desde el bucle principal al programa de impresión? –

No sé, veamos el programa de impresión. Abro “print.cpp” y busco la entrada de parámetros. No la veo. Edición, buscar argc. Nop. ¿Cómo es posible? MKII y yo nos miramos extrañados. ¿Cómo es posible que un programa necesite un parámetro para imprimir un resultado y no lo reciba al iniciar la ejecución? ¿Cómo puede ser tan sofisticado? Una lectura rápida de main lo explica de inmediato. -Esto es lo más grande, MKII. -¿Es eso lo que parece que es? -Los parámetros los coge de una variable de entorno del sistema. ¿Qué te parece? -Pero… ¿no se supone que si eso es así, se podría sobreescribir la variable de entorno y que las impresiones salgan por donde les de la gana? -Veámoslo en el programa principal. Buscamos la llamada a print. Resulta que no, que no se puede sobreescribir dicha variable de entorno porque resulta que la llamada a print está detrás de un bucle del que sólo se sale si otra variable de entorno está a cero: la variable “PUEDIMP”. Así, tal cual la escribo. Cuando PUEDIMP tiene el valor apropiado (no parece ser booleana, sino otra cosa, tal vez trileana con valores sí, no y psá) se imprime y se cambia de nuevo el valor para indicar que está dispuesta a imprimir otra vez. Un semáforo un poco rústico y sobre todo, muy seguro. -La madre que los parió. ¿Y tú sabes lo que ha costado esto, Maqui? -Lo sé. Y por eso sufro más que tú. -Al comercial de esta casa hay que juzgarlo en Estrasburgo. -En fin. Sigamos.

Esto está feo, pero no afecta a la velocidad. Vamos a ver el cliente qué hace. Abro el directorio del cliente. Ahogo un grito. Intento tragar saliva y me cuesta horrores. MKII me mira. Mira la pantalla. Suspira hondamente. Me levanto. Voy hacia un armario y con un suspiro lo abro. Aparto las tarjetas serialix, los conmutadores manuales de puerto paralelo, un disco duro de cuarenta megas y una bolsa de conectores BNC. Maldigo no haberme puesto guantes de amianto. Cojo la caja que hay al fondo, blanca y en cuyo frontal reza “Visual Basic 6.0″. Saco el disco y lo meto en la unidad. Lo instalo en una máquina virtual con XP y abro por fin el proyecto. Reconozco de inmediato los formularios de la aplicación y paso a ver lo que hay detrás. MKII no tiene experiencia con esta atrocidad y no lo lee con la misma fluidez que yo. -Los controles no tienen nombre. Bueno, tienen el nombre por defecto-le explico.- Bien. Cojonudo. El código no está indentado. Mejor todavía. -Para que luego digan que las llaves de C son un coñazo. -Son una bendición divina. No me jodas.

No pasa mucho rato hasta que veo el problema de lentitud de todos los clientes. El problema residen en la comunicación con la base de datos. -Mira, MKII, ya he encontrado el porqué de la lentitud. -¿Sí? ¿Dónde? -Mira, ¿ves esta matriz bidimensional? -La veo. -Pues ahí se monta la consulta SQL. -¿Y por qué en una matriz? -Por joder, porque no es para plantillar. -Vale, ¿entonces a un lado el campo y al otro el valor y luego se concatena la sentencia? –

Que no, que no. A un lado se pone “select *” y al otro “from tabla” y ya. -¿Cómo que “y ya”? -Y ya. No hay where. No se selecciona de más de una tabla. -¿Entonces cómo se filtran los resultados de la consulta? Sonrío como un maníaco. -Muy fácil: iteramos todos los valores de la consulta y nos quedamos con el que nos coincida. ¡Es genial! -¿Cómo? ¿Cómo? -¡Es genial! Y si necesito una subconsulta… ¡repito el proceso! Una risa nerviosa se apoderó de nosotros y nos tuvo fuera de combate durante una hora. ¡Bimbambidubi! ¡Dubi! -¡Jiajiajiajiajia! ¡Sistemas, Joker al habla! ¡Jajajajaja! -Cada día estáis peor ahí. Oye, que no tenemos internet y necesito entrar en los bancos. -¡Jajajajaja! ¡Jiaaaajajajaja! ¡Bancos! ¡Bancos! ¡No sé ni quién eres tú! ¡Jiajajajia! ¡Pero da igual! ¡Iré puesto por puesto comprobando si tienes internet! -¿De qué hablas? -¡Es súper rápido! ¡Jiajiajiaaaaaa! -¿Me lo arreglas o no? -¡No! ¡Jiaaaaajajajajaaaaa! Cuando por fin conseguimos rehacernos, desconectamos los teléfonos y pasamos varios días modificando chapuzas similares en ambas partes del programa.

Después de mucho tocar, de mucho corregir error de compilación tras error de compilación, conseguimos meter unos cuantos tumores que suplieran otros cuantos tumores más dañinos y la aplicación volvió a correr decentemente. Como Gargamel no informaba de nuestros progresos a $Hyperboss, decidí mandarle un correo electrónico. Asunto: La aplicación ya va bien. Cuerpo del texto: Pues eso. A los pocos minutos me llama al despacho. -He llamado a unos cuantos usuarios para comprobar que va bien y me han dicho que ya va como al principio. ¿Qué coño le pasaba al programa? -Técnicamente a este problema se le conoce como “Rendimiento diferencial demo-producción” o “Mal del becario”. -¿Y eso qué es? –

Pues que si un programa hace lo que tiene que hacer no necesariamente está bien hecho. -Explícate. -El programa fue bien cuando tenía pocos datos que manejar. Conforme la base de datos creció, resultó no estar bien preparado para manejar tantos datos. -¿Y cómo lo habéis solucionado? -Limitando los registros devueltos por la base de datos. ¿Pero por qué le interesan los detalles técnicos? Normalmente ésto le importa una mierda. -Para decírselo al ingeniero de Bullshitsoft. -Ah, yo les mando un informe. -¿No te importa? -En absoluto. -Vale, gracias, Wardog. -De nada. Oiga, una curiosidad. ¿Cómo consiguió el código fuente tan rápido? -¿Conoces a Astaroth? -¿El abogado? -Él se lo trajo en un pendrive en dos horas. -Joder. Yo seré BOFH, pero éste no veas lo cabrón que llega a ser en el mundo real. Astaroth es a los abogados lo que un volcán a un mechero de gas. Es capaz de acojonar a Satanás.

Volví a mi despacho y redacté un email Para: jefazos@bullshitsoft.es, CC: higiniero@bullshitsoft.esAsunto: Aplicación arreglada. Informe de reparación. Cuerpo: Ya funciona rápido. El problema era que tenéis a los becarios bajos de azúcar. Mantas. Enviar.

Update post el 18 de agosto
——————————————————-

Gracias a mis amigos Jose Félix y Jose, me han indicado que el texto tiene su origen Wardog y su mundo:http://mundowdg.com/blog/page/3/

Así al César lo que es del César. Wardog, no era mi interés aprovecharme, y de paso indicarte que verdaderamente es un texto que hay que leer y de “digestion lenta” como dice mi amigo Manuel Férez.

Un abrazo a todos
Source: jmgriscom