Category Archives for "CPD"

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

Organiza tus jobs de Veeam mediante políticas

organiza-tus-jobs-mediante-veeam

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

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

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

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

Paso 1 – definir parámetros y valores

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

  • RPO

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

Paso 2 – agrupar

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

Paso 3 – “dinamizarlo”

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

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

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

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

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

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


Source: jmgriscom

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

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

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

 

El futuro de La Cloud

Leo  “Por ello un 41% de las compañías españolas ya utiliza la nube de alguna forma, según un estudio llevado a cabo por IDC. Esta cifra es muy superior al 15% de 2011 y aumentará hasta alcanzar el 52% en 2014, según sus previsiones

Había quien se las creía muy felices con este crecimiento “imparable”, pero claro sólo Jano, el Dios de pasado y del futuro es el que tiene “los datos” en el bolsillo…

No hay duda que la crisis ha vuelto a las empresas recelosas, defensivas, y “mirando hacia adentro” y más sobre su core business que no sobre procesos como los de TI. Que sí, que lo entienden y les gusta lo del “pago por uso”, pero lo miraremos más adelante.

Personalmente no creo que todo sea eso. Creo que falta confianza y una nueva cultura.

Sin duda que AWS, Microsoft y Google son los “chicos grandes” del patio. Pero tuvieron su parte visionaria y “su desierto del Sahara” para llegar a donde están. Vamos a decir que Microsoft supo darse cuenta del cambio del viento y hizo un viraje importante apostando por Azure.

Vuelvo a ver el informe IDC de este año y aunque más comedido, sigue haciendo “push” hacia “La Cloud”. 

Mi punto de vista.

El TI que hay ahora en Cloud, según mi visión, nace de 3 orígenes:

  • La TI de La Cloud. En este grupo pondríamos toda aquella infraestructura que “como va a dar servicio a La Cloud, ¿dónde la vamos a poner si no?”
  • La TI que nació en La Cloud. Generalmente son empresa muy nuevas, que han tenido un CIO visionario y ha pensado ¿Por qué no nacemos con la TI en Cloud?
  • Las grandes empresas, que ya tienen subcontratada la TI y la tienen de Cloud.

El resto pues está en ello. Mirando al de al lado, a ver que ha hecho, leyendo si ha pasado esto o aquello en tal CPD…

Voy a hacer un par de preguntas para demostrarlo. Cuantos CIOs conocen la calificación de los CPD según TIER y cuando conocen las 5 claves para considerar que un servicio Cloud?. Los que consiguen contestar correctamente las dos preguntas son aquellos que se han planteado alguna vez mover su TI a un CPD o a La Cloud!

He sido CIO de una aseguradora durante 10 años y los entiendo perfectamente (me gustó un artículo hace mucho tiempo ¿Porqué los CIOs no confían en las montañas rusas? ) y el problema es siempre el mismo.

Como decía el primer punto es la falta de confianza. ¡Pero es que no hay que poner todos los huevos en el mismo cesto! ¿ y como lo vamos a hacer?  Pues poco a poco y sin equivocarnos…..

Particularmente creo que hay varios “approaches” al tema. En primer lugar, haga un diseño de todo su TI, incluyendo el “on-premises” y el “off-premises”, con eso Vd tendrá la visión de su Cloud Híbrida. Así sin darse cuenta Vd. verá que dispone de un “pool” de recursos inside y otro offside.

Momento muy bueno para plantearse ¿Por qué no hacemos las copias aquí en local y un “copy job” en off-site?  ¡Un primer paso para disponer de una Cloud Híbrida!

el futuro de la cloudEsto nos podría conllevar a “Si tengo los datos allí, los puedo levantar en un DR con cierta facilidad, no?”

En un momento de “pico” de trabajo, Vd puede alquilar y aprovisionar infraestructura en remoto para, por ejemplo, tener desarrollo en la Cloud, o bien convertir todo en un DRaaS, enlazando la copia con la recuperación en una plataforma remota.

La última estrategia que he visto es quedando el hardware “local” con ciertos años, contratar los servicios generales en cloud, siendo los servicios locales que son los de respaldo (pero este caso es rara avis…. )


Por ello entiendo que el modelo que se debe plantear es un movimiento “smooth”, donde además el modelo permita ir paso adelante, paso atrás (Clouds Híbridas!)

Sé que varios de Vdes. están esperando por la cultura….  Verán, allá por 1987 yo era un técnico que mi función era, dentro de una gran industria química, forma y “vender” el uso de los PCs bajo es escepticismo de mis compañeros del IBM 4381 que creían que esos “ordenadores” eran simples juguetes. Lo mismo pasaba en los departamentos. ¡Había 1 ordenador y una impresora por departamento! Hasta que llegó, y llegó la cultura del PC y yo iba arriba y abajo instalando PCs ¡1 por mesa! quien lo hubiera  imaginado nunca!!!

Y esta es mi conclusión. Sí señores, la crisis ha ahogado mucho a la Cloud, pero no ha habido programas y estrategias de atraer los servicios de TI de una forma “gradual” hacia la Cloud. Cuando llegue la cultura de Cloud, recuerden mis palabras.

Take care,

Source: jmgriscom

Continous, continous, continous

Continous integrations, Continous delivery, Continous deployment,  son conceptos que cada vez oímos más. Uno de ellos, continous delivery es de vital importancia para la gestión de cualquier cambio a aplicar en uno o un conjunto de servidores.

Los que hayan trabajado o colaborado con equipo de desarrollo de software seguramente el concepto continous integration o integración continua les sea familiar. La integración continua es una técnica utilizada por los equipos de desarrollo para detectar fallos en el código cuanto antes. Esta consiste en ejecutar de forma automática un conjunto de test cada vez que se sube un cambio al repositorio de código fuente. Estos test comprueban todas las funcionalidades de la aplicación para detectar si el nuevo cambio afecta a alguna de las funcionalidades de la aplicación. Este proceso protege de desplegar código erróneo a producción.

El concepto de continous delivery va un paso más allá. Continous delivery lleva la idea de integración continua a todos los actores y procesos  que participan en el flujo de despliegue de una aplicación o actualización de un sistema. El objetivo es desplegar todos los cambios, ya sea la instalación de nuevas funcionalidades, actualizar un bug o aplicar nuevas configuraciones a producción de forma segura y rápida.

La idea es establecer un conjunto de etapas o pipeline a través de las cuales pasa cada cambio antes de ser aplicado al entorno de producción. El objetivo de cada una de estas etapas es validar la calidad del cambio desde diferentes puntos de vista y prevenir los errores. No hay un pipeline único, sino que cada organización tienes su propio pipeline,  pero típicamente este puede estar formado por algunas es estas etapas:

  • Integración continua.
  • Ejecución de test funcionales.
  • Ejecución de test de seguridad.
  • Ejecución de test de rendimiento.
  • Despliegue a producción.
  • Operación.

El esquema siguiente muestra un pipeline para la gestión de cambios en los sistemas, donde lo deseado es que todas las etapas del pipeline sean automática, solo dejando el paso a producción con una acción manual, todo y que solo sea para activar el despliegue del cambio en el entorno de producción.

esquema continuos

Cada una de las etapas debe informar a los diferentes actores que intervienen en el proceso de continous delivery (desarrolladores, operadores, ingenieros de calidad, ingenieros de seguridad, gestores, …) del resultado de cada etapa. De esta forma, detectamos los problemas que pueda ocasionar un nuevo cambio antes que este se aplique sobre el entorno producción.

Para poder agilizar el proceso de aplicación de cambios y repetirlo tantas veces como sea necesarios, es básico automatizar los test ejecutados en cada una de estas etapas. Por otro lado, existen herramientas como Jenkins que permiten configurar y automatizar las etapas del pipeline.

Si os interesa, en https://continuousdelivery.com/ encontrareis recursos que profundizan en el tema.


Source: jmgriscom