Category Archives for "Cloud"

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

¿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

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

 

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere II

La semana pasada vimos como sacar datos de caracterización y rendimiento de nuestros discos virtuales mediante la herramienta vscsiStats nativa de ESXi. Hasta donde conté en ese post, podíamos ver los datos directamente en el terminal pero además, podemos exportarlos y tratarlos para generar informes de uso que pueden resultar muy útiles.

graficos-stats

Para ello, primero de todo tenemos que modificar los comandos con opción –p para que exportar los histogramas a csv y luego poder tratarlos. El comando para exportar todos los histogramas a csv sería:

# vscsiStats -p all –w <worldID> -c > /root/vscsiStats-export.csv

Una vez generado en el directorio que le indiquemos como parámetro, lo podemos importar mediante scp por ejemplo. Una vez descargado en nuestro equipo es cuando podemos empezar a tratarlo. De por sí tendremos los datos en “crudo”, pero hay maneras de poder graficar los resultados para analizarlos de manera más visual.

Lo que necesitaremos es Excel y una macro que podemos obtener aquí desarrollada por Paul Dunn y Matt Kelliher. Así los obtendremos:

  • Abrir el fichero csv que hemos obtenido desde el ESX en excel
  • Apretar alt+f11 y añadir el código de la macro
  • Para ejecutar el código, bastará con apretar f5

Con ello, obtendremos los gráficos de los datos que hemos recabado desde vscsiStats.

Otra gran herramienta más sencilla y directa es ésta desarrollada por virten.net. Subimos el fichero .csv  e inmediatamente obtendremos los gráficos.

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

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere

Cada vez hay más soluciones de terceros o del propio VMware que nos sirven para monitorizar y analizar nuestra infraestructura. Las infraestructuras van madurando y se vuelven más confiables, hecho que hace que se virtualicen más cargas en ellas. Además, ya prácticamente todas las aplicaciones están soportadas dando niveles de rendimiento a la par o incluso mejores que en entornos físicos. Más consolidación de máquinas virtuales por host, más dispersión y máquinas virtuales más sensibles hacen que la necesidad de monitorizar de manera más exhaustiva sea una realidad

Como decía, hay herramientas de diversos tipos y funcionalidades que sacan, procesan y almacenan datos de rendimiento de nuestra infraestructura virtual para que podamos generar alertas o informes predictivos. Podríamos entrar a valorar muchas de ellas, pero antes creo que es casi obligado conocer las herramientas nativas en vSphere/vCenter. Conocerlas, además de otras ventajas que expondré seguidamente, nos ayudará a conocer “de base” las métricas más críticas que luego podremos explotar con otras soluciones.
 
Una de estas herramientas nativas es vscsiStats, nativa en ESXi. Con ella, obtendremos datos de caracterización del uso a nivel de Storage de nuestras máquinas virtuales. Qué ventajas supone? Como decimos, es nativa, por lo que ya la tienes incluida en tu hipervisor, es rápida en obtener datos en real-time, puesto que estamos consultando directamente el scheduler de ESXi, es relativamente sencilla de usar (veremos cómo a continuación) y fácilmente podemos exportar los datos que nos aporta. A diferencia de los datos de storage que nos aporta esxtop, otra herramienta nativa de monitorización para ESXi, que solo aplican para almacenamiento basado en iSCSI o Fibre Channel, vscsiStats nos da más variedad de información y sobretodo sin importarle en qué tipo de almacenamiento esté la VM, pues se sacan los datos a nivel de disco virtual.
 
Podremos sacar información de storage de cualquier VM, pero qué información? Básicamente lo que nos dará vscsiStats son datos de utilización y carácter de las operaciones de I/O de storage durante un periodo de muestreo en forma de histograma, por lo que será importante ejecutar las cargas que queremos monitorizar durante ese momento. Podemos sacar los siguientes histogramas:

  • seekDistance: localidad “espacial” de los I/Os

    • Dada una VM, podemos ver la secuencialidad de los bloques que consulta/escribe. Si un bloque está más cerca que los consultados/leídos inmediatamente antes, se accederá mucho más rápido. En cambio, si el patrón de uso de bloques es muy aleatorio, impactará en el rendimiento. Es interesante juntar patrones de uso común en las mismas LUNs para intentar optimizar el rendimiento.
  • ioLength: tamaño de IO
    • Como comentaba en anteriores posts, es importante alinear las configuraciones en todas las capas que intervienen en el uso de disco, pero a su vez puede resultar muy complejo. Sobretodo a alto nivel, pues puede resultar complicado sacar patrones de IO a nivel de sistema operativo de la VM o incluso la aplicación que use. Con vscsiStats, podremos sacar datos del tamaño de IO real que están utilizando nuestras VMs sin importar qué OS/aplicación estén ejecutando. Por ejemplo, si sabemos el tamaño medio de IO de nuestras VMs, podemos configurar el tamaño de stripe de nuestra cabina a ese valor para maximizar su rendimiento.
  • latency: análisis de latencias
    • Rápidamente podemos sacar analizar qué tiempos de respuesta están teniendo nuestras operaciones de I/O para sacar medias, ver a qué máximos estamos llegando y ver qué latencias son las más comunes.
  • interarrival
    • Nos sacará qué tiempo entre llegada de I/Os están teniendo nuestras VMs.
  • outstandingIOs
    • Al llegar una operación de I/O, se calculan cuantas otras para ese disco virtual están aún pendientes por llegar. Al verlo en histograma, se puede ver que concurrencia de I/Os se tiene para ese disco y ver si hay contención a nivel de profundidad de colas.

Vistas sus posibilidades, vayamos a ver como funciona:

  • Recoger IDs de las VMs y los discos: como hemos visto, vscsiStats se invoca para empezar a captar datos. Estos pueden ser referentes a todas las VMs y todos sus discos o de una VM o disco en concreto.

Si queremos recoger datos de todos los discos y VMs, podemos obviar este primer paso. En caso contrario, deberemos introducir el siguiente comando en la consola de nuestro ESXi (por SSH o DCUI):

# vscsiStats –l

El output serà un listado de las VMs y discos. Los datos que queremos obtener serán el “Virtual Machine worldID” que identificará nuestra VM y el “Virtual SCSI Disk handleID” que identifica el disco virtual. Con estos dos datos, seguimos adelante.

  • Empezamos la recolección de datos: debemos usar la opción “-s” para empezar a capturar datos de uso de nuestras VMs.

Si queremos capturar datos de todas las VMs y discos, tan solo hace falta que ejecutemos el siguiente comando:

# vscsiStats –s

En caso de que querramos monitorizar todos los discos de una VM en concreto, necesitaremos el parámetro “Virtual Machine worldID”:

#vscsiStats –s –w <worldID>

Si queremos concretar más y solo capturar datos de un solo disco virtual necesitaremos el “Virtual Machine worldID” y el “Virtual SCSI Disk handleID”

# vscsiStats –s –w <worldID> -i <handleID>

A partir de ejecutar el comando con la opción –s, empieza el periodo de muestreo que durará (si no indicamos lo contrario) 30 minutos. Si queremos alargárlo, tenemos que volver a ejecutar el comando –s con los parámetros que hayamos especificado anteriormente para “renovar” otros 30 minutos más.

  • Sacar histogramas: una vez hemos empezado a llenar los contadores, ya podemos obtener histogramas del uso. Como hemos visto previamente, hay varios disponibles así que previamente debemos saber cuál queremos sacar. Una vez está claro:

    1. seekDistance: # vscsiStats –p seekDistance
    2. ioLength: # vscsiStats –p ioLength
    3. latency: # vscsiStats –p latency
    4. interrarrival: # vscsiStats –p interarrival
    5. OIOs: #vscsiStats –p outstandingIOs

De esta manera podremos obtener los datos que precisamos en la pantalla de nuestra consola. En el siguiente post veremos como exportar datos con esta herramienta y ver como podemos sacar informes con los datos en excel.

.code {
font-family: “Courier New”, Courier, monospace;
}

Source: jmgriscom

¿Cual es el real “Estado del Arte” de los cryptolocker, ransomware y otros elementos dañinos?

En estos últimos días, oyendo casos de Ransomware, de su proliferación y lo que es más, su “no resolución” empieza a preocuparme.

No sé si conocéis la paradoja del cisne negro. Los ingleses en sus viajes, encontraron cisnes negros, pero claro, “Los cisnes son blancos….” Luego esto no es un cisne. Cuando llegaron a Inglaterra y los diseccionaron la respuesta era clara. Era un perfecto cisne, pero de color negro.

Esta paradoja se ha extendido en el mundo empresarial como “no des por sabido lo que sabes, puede que haya más sobre el tema que desconoces”. ¿Quien iba a pensar que unos aviones civiles se podían estrellar contra unas torres?

Recuerdo cuando empezó los auges de antivirus como el “I love you” y lo que está ocurriendo ahora me lo trae a la memoria, aquello fue un “Boom”, esto va en escalada.

Y así con aquella máxima informática que dice “Hay que saber del tema, y sino, el teléfono del que sabe” llamo a mi amigo Antonio Martínez Algora , Responsable Técnico de Stormshield para Iberia, curiosamente una empresa participada por Airbus. Aprovecho para “atracarle” con una entrevista para vosotros 🙂 J. Gracias Antonio, eres un amigo….

JMG. Antonio, que nos puedes decir de esta “escalada”?

AMA. Estamos asistiendo a un fenómeno preocupante: la confluencia de técnicas de ciberdelincuencia para conseguir un efecto más letal y evadir las medidas de protección.  Por primera vez, ransomware, como Locky o Cerber, son utilizados por una vulnerabilidad de Día Cero de Flash para infectar a sus víctimas.  Una razón adicional para actualizar su plugin de Flash con el último parche propuesto por Adobe.

Existen al menos dos kits de exploit, llamados Nucleus y Magnitude, que se encuentran disponibles “in the wild” y que aprovechan la vulnerabilidad de Día Cero descubierta recientemente en la aplicación multimedia.  Gracias a estos kits, los cibercriminales pueden explotar la vulnerabilidad de Flash para infectar a sus víctimas con Locky o Cerber, dos tipos de ransomware que cifran los documentos del ordenador de sus víctimas con potentes tecnologías de cifrado, y solicitan un pago o rescate para desencriptar y restaurar los documentos originales.

JMG. ¿Nos cuentas un poco sobre cada uno de ellos?

AMA. El primero de estos dos malware, Locky, ha hecho estragos el mes pasado en distintos países europeos y de todo el mundo, afectando a todo tipo de empresas y particulares.  Uno de los incidentes más renombrados ha sido el de un hospital en Los Ángeles, Estados Unidos, obligado a pagar 17.000USD de rescate para remover el malware en múltiples sistemas infectados y recuperar datos médicos como historiales, radiografías, análisis, etc.

En un primer momento, las técnicas utilizadas para la difusión de este ransomware han consistido en macros de Office incluidas dentro de un documento Word,  y también archivos JavaScript enviados como archivos adjuntos en campañas masivas de correos electrónicos o spam.  En ambos casos, se requiere de la participación del usuario, aprovechándose de su “ingenuidad” y menor concienciación de seguridad, para abrir estos documentos Word o JavaScript, a pesar de provenir de una fuente que podría no ser de confianza.

Si bien un usuario debidamente formado es poco propenso a abrir documentos sospechosos, el uso de la vulnerabilidad de Flash permite a los ciberdelincuentes infectar a cualquier tipo de usuario durante una simple visita a un sitio Web y por tanto sin requerir ningún tipo de intervención directa del usuario.  De esta forma, incluso los usuarios más recelosos y expertos, se convierten en víctimas impotentes de esta nueva forma de infección.

Desde la perspectiva de los piratas, esta combinación de técnicas de ataque permite optimizar la tasa de usuarios infectados de forma espectacular.  Los ciberdelincuentes buscan otros vectores para rentabilizar sus inversiones, ya que los usuarios se van mostrando cada vez más desconfiados hacia los ficheros adjuntos de fuentes desconocidas. Igualmente las herramientas de protección tradicionales están añadiendo capacidades para bloquear documentos que contengan macros o bien bloquear tipos de ficheros potencialmente peligrosos como programas ejecutables, JavaScript o scripts en general.   Gracias al uso de sitios Web legítimos infectados, o sitios web suplantados mediante redirección por los ciberdelincuentes, estos ataques son mucho más difíciles de detectar y de prevenir.

JMG. ¿Cuál es el perfil del Ciberdelincuente?

AMA. Si el kit de exploit Nuclear sirve para difundir Locky, Magnitude hace lo propio con otro ransomware, Cerber.  Este último malware, que también cifra  los datos de sus víctimas, tiene la particularidad de atacar múltiples sistemas operativos (Windows, Linux, MacOS X).  Con Cerber, asistimos a la llegada de una generación de ransomware proporcionados como un servicio.  Incluso sin conocimientos técnicos especiales, los ciberdelincuentes pueden comprar malware en línea y generar sus propias campañas de infección.

También se empieza a popularizar la infección de ransomware aprovechando una vulnerabilidad de Día Cero para acelerar su difusión. Estamos asistiendo a un cruce entre dos mercados de ciberdelincuencia: el negocio muy rentable del ransomware y el mercado para la venta de exploits de vulnerabilidades o “zero-day exploit”.

Hasta ahora el mercado de zero-day exploits  -que se venden por un precio que ronda desde unos pocos miles a decenas de miles de euros – era utilizado fundamentalmente para campañas de ataques persistentes avanzados (o APT por sus siglas en Inglés), para infiltrarse en una organización objetivo y robarle datos confidenciales y tomar control de sus sistemas a lo largo del tiempo.

antonio_stormshield

JMG. ¿Apuntar a las empresas más negligentes o con menor inversión en seguridad?

AMA. Si bien la vulnerabilidad de Flash afectaba a muchas versiones de la tecnología de Adobe, los exploits sólo atacaban a las versiones antiguas.  Esto plantea la pregunta de por qué los atacantes no están sacando el máximo provecho al exploit y auto-limitan el alcance de sus víctimas.

Matthieu Bonenfant, director de Producto de Stormshield, avanza una explicación bastante lógica para esta elección a priori sorprendente: “A menudo observamos dos tipos de empresas a la hora de abordar la instalación de parches de seguridad. Las que despliegan de forma regular las actualizaciones de sus aplicaciones; éstas empresas en realidad tendrían menor interés para los ciberdelincuentes, ya que tendrán más dificultad para atacarlas. Y por otra parte aquellas que muestran una carencia técnica desde hace varios años; estas empresas les permiten a los ciberdelincuentes perpetrar sus ataques durante mayor tiempo por debajo del radar sin saltar a la luz pública, especialmente con exploits de día cero”. En pocas palabras, los hackers podrían haber apuntado intencionadamente a las versiones más antiguas de Flash… por una mera cuestión de rentabilidad de sus acciones, para pasar desapercibidos el mayor tiempo posible.

Los últimos ataques de ransomware están tomando proporciones muy grandes. En primer lugar debido al número de usuarios afectados por la vulnerabilidad CVE-2016-1019, que afecta a todas las versiones de Flash anteriores al parche publicado el 7 de abril. Además, porque Nucleus y Magnitude, aunque no tienen la popularidad de un Anger, no son menos habituales en el “mercado negro”.  Hay que señalar que ha sido a través de un análisis del kit Magnitude como los investigadores de Proofpoint, ayudados por los de FireEye, han descubierto la vulnerabilidad CVE-2016-1019.

Esta escalada de la amenaza es parte de un aumento de la potencia de los ransomware.  Debido a este auge, las empresas están demandando herramientas específicas de protección contra APTs y zero-days como la solución de Stormshield Endpoint Security (SES). SES utiliza tecnologías avanzadas de protección, que tratan, no de reconocer cepas infecciosas, sino sus efectos, bloqueando los comportamientos nocivos, incluso de procesos legítimos, como escalado  de privilegios, ejecución de código, desbordamiento de la memoria, etc.

Las herramientas avanzadas de seguridad de Stormshield que anteriormente eran demandadas únicamente por empresas de sectores sensibles con altos requerimientos, están siendo solicitadas hoy en día por empresas de todos los sectores y de cualquier tamaño, incluyendo PYMEs… después de haber sido infectadas con ransomware y haber sufrido sus efectos, y para evitar seguir tropezando con distintas variantes del mismo problema en el futuro.

JMG. Pues nada Antonio, muchas gracias por tu valiosa información y nos gustaría volverte a ver por estos lares. Un abrazo

 

—– UPDATE 4.Agosto.2016 —-

Me informa Antonio Martinez que los que producen RaaS (Ransomware as a service) han tenido un enfrentamiento entre ellos. En este caso, los de PETYA han hackeado a otro Ransonmware rival, de nombre CHIMERA siendo sus claves plublicadas.

Tambien aquí podemos ver como detectar si tienes o no Chimera.

Saludos. JM


Source: jmgriscom