Category Archives for "Uncategorized"

AS400. Cómo darle una nueva vida en dos pasos.

as-400-vmware

Jamás un hombre es demasiado viejo para recomenzar su vida y no hemos de buscar que lo que fue le impida ser lo que es o lo que sera. Miguel de unamuno

Aunque las palabras de Unamuno nos sirven “como anillo al dedo” al tema que nos ocupa, vamos a dejar la literatura un poco al lado para hablar del tema que nos ocupa, nuestro viejo amigo AS400.

Hoy vamos a escribir sobre una situación que puede mantener preocupados a muchos CEOs, Directores Grales y CIOS en España que disponen de AS400 en estos momentos.

Se trata de algo parecido al “Efecto 2000”, no sé si lo recordaréis, que acaeció hace algunos años. Aunque este caso no tenga las proporciones que tuvo el mencionado caso, el que nos ocupa sobre el AS400 puede llegar a ser de importancia importante para algunos en particular.

Hoy vamos a escribir como podemos no sentirnos “atados” a las viejas arquitecturas y hardware, beneficiándonos de sus aplicaciones. ¿Parece curioso? ¿Incluso imposible?, pues vamos a verlo

 

AS400

De donde venimos…

Este post ha tenido varios títulos como “El ocaso de los dioses” o “Parque Jurásico”. Que duda cabe que todos los ordenadores de los que hablaremos en este escrito han sido como “dioses” para la industria en general.

En los años 80-90 no existian los servidores actuales ni por asomo. Toda empresa mediana grande precisaba o bien de un Mainframe (trabajaba con un 4381 mod 20 en los 80), maquina grandiosa que precisaba un sistema de climatizacion casi digno de una sala de cine, o bien los llamados “minis” que eran o bien, con sistema propietario como los 36, 38, AS400 o bien eran una “unix box” como un Alpha, un HP 3000, también podría ser un VAX con su vms o un PDP-11. Nombres que algunos de vosotros ni habréis oído nunca.

Lo importante es que funcionaban y funcionaban muy bien. Recursos limitados que generó el efecto 2000, memorias insuficientes que te obligaban a hacer overlays y discos inmentos (como armarios roperos) que contenían megas.

Y dentro de ese “dinosaurio”(con cariño), grande, generalmente ruidoso y hoy fuera de su época, se empezó a crear la joya preciosa que  es la aplicación que hoy, 30 años después, tras haber sufrido modificaciones tienes toda la confianza depositada en ella, la conoces al dedillo y lo que es mejor, la conocen como el pasillo de su casa.

AS400:LA PARADOJA, O EL MOMENTO DE LA VERDAD….

Y es el momento donde nos encontramos ahora. La aplicación funciona razonablemente bien (que yo sepa no he oido ninguna que sea la purga de Benito), fruto de todas las inversiones que se han hecho en ella, pero se halla “embutida” dentro de un contenedor que cada vez tiene más años, los mantenimientos te arruinan, los usuarios te piden mas funcionalidaes y buscas subsistemas “satélites” para evitar “el dinosaurio” y encima te empiezas a plantear o te plantean como vas a afrontar el plan de continuidad de negocio o de contingencia. “Con estos juncos vamos a hacer nuestros cestos…”

Hasta aquí la paradoja. Algo que va bien, dentro, atado, de algo que no tiene futuro. Y de ahí es donde nace el momento de la verdad ¿Que hacer?

Hasta ahora habían pocas opciones, por no decir una. Comprar un aplicativo nuevo que funcionara dentro de un entorno wintel y si podia ser virtualizado. Punto.

En mis años en IT (van para 35) he vivido y he visto muchos cambios de ERP. Corre por ahí una estadística de que este cambio puede generar más de un 33% de caida de facturación en tu empresa debido a ineficiencias (Procesos que aún no funcionan bien, gente que no conoce bien el funcionamiento, funcionalidades que no cubren bien o no entienden los procesos de la empresa, auténticos latidos de la misma.

Nuevas propuestas actuales a la paradoja

¡Muerte al Hardware, viva el Software!

Bueno, tampoco es que vayamos a montar un 14 de Julio en la Bastilla….  pero va por ahí el tema. El problema, entendámoslo bien, es que claro que lo necesitamos, claro que necesitamos que evolucione. Pero tiene dos puntos muy “malos”. Tiene por definición limitaciones y si lo configuras de una forma es muy difícil, sino imposible, reconfigurar en otra.

y ¿cómo lo hacemos?

Pues poco a a poco y bien.

El primer paso al que nos referimos se basa en “liberar” a la aplicación de sus “ataduras físicas” que tiene con el Hardware. ¿Que hay más puro y limpio de una aplicación que su código fuente, perfectamente leíble y editable? Pues eso es lo que quiere nuestro partner ASNA, ése código fuente que ha ido siendo modelado en función de los procesos que ha ido teniendo la organización. Los procesos, aquellos que hacen nuestra empresa singular y que nos ha costado “un riñón y un ojo de la cara” automatizar a pesar de todo…

Pues bien, los amigos de ASNA disponen de un conversor que “traduce” este código fuente a RPG .NET, capaz de “correr” sin ningún tipo de problema sobre una convencional plataforma wintel.

En la otra mano tenemos la Base de Datos, auténtica biografía de la empresa, donde está aquel dato único que no podemos encontrar en ningona otra parte. De nuevo nuestro partner ASNA dispone de un módulo capaz de convertir la Base de datos DB2/DB400 en una Base de Datos MS-SQL, de nuevo siendo capaz de ejecutarse en una plataforma wintel.

¿y el segundo paso?

Hombre, ya que hemos llevado nuestra aplicación al futuro, sobreviviendo al sistema para el que fue concevido, no nos que quedemos en “antesdeayer”.

Lo suyo es integrar estas plataformas wintel dentro de una convergencia como puede ser Flexpod (Cisco y NetApp) para que con los elementos de redundancia, su HA (Alta disponibilidad), vMotion (movimiento de la maquina virtual en marcha entre servidores), FT Capacidad de tolerancia a fallos… con todo ello podemos “arropar” nuestra querida aplicación en un entorno que si de por sí era robusto, ahora además disfruta de herramientas de tolerancia a fallos.

La entrada AS400. Cómo dárle una nueva vida en dos 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

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

463741502c1ef58458437425e3c67529

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

463741502c1ef58458437425e3c67529

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

¿La virtualización tiene sus partes negativas?

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

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

¿QUÉ ES EL VM SPRAWL?

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

el porque del “sprawl”

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

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

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

CONSECUENCIAS DEL SPRAWL

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

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

FORMAS SENCILLAS DE MITIGARLO

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

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

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

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

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

¿SOLO EN VIRTUALIZACION?

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

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

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

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

CONCLUSIONES

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

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

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

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

Take care

JM

Foto: Morguefile

Referencias:

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


Source: jmgriscom

¿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