IT Virtual Shocks

11 marzo 2011

VMware vSphere PowerCLI 4.1.1 ...corregido!!!

Pues si, el famoso porster del PowerCLI por fin corregido y actualizado: VMware vSphere PowerCLI 4.1.1

Pero si os quedais con ganas....en breve estar disponible el Powerclibook: "The book will be releasing from our warehouses on March 28^th which means that books should reach stores/resellers a week later."

http://www.powerclibook.com/

Veeam: deduplicacion y compresion de backups

Para mejorar los ratios de deduplicacion de las tareas de backup, debemos agregar maquinas con sistemas operativos similares en los mismos jobs (linux en una tarea, windows en otra, solaris en otra, etc). La progresion de deduplicacion aumentaran en funcion del numero de rollbacks que se generen de cada tarea y si estos son tipo incremental, reversed o full. Ademas, sobre ellos actua la compresion de los ficheros con lo que el ahorro en disco sera mayor de lo esperado segun aumenten los puntos de retroceso.

Una buena practica es hacer un seguimiento de las tareas comparando los tiempos que tarda en crear el backup y los ratios de compresion.

Recordemos que Veeam dispone de backups sinteticos, es decir, la ultima copia es la completa y las antiguas pasan a server decrementales de esta ultima, lo cual ademas permite una rapida recuperacion de la maquina virtual al estado anterior.

Tambien la recuperacion de ficheros interno del SO de la mv, desde Windows es muy rapido pero desde Linux puede dar algun que otro quebradero de cabeza.

Enjoy Veeam!

10 marzo 2011

Acceder al ESX aunque no responda la Service Console

Alguna vez nos puede ocurrir que no podamos acceder a un ESX por el vClient o por ssh contra la ip o nombre fqdn, si ademas coincide que no tenemos acceso fisicamente al servidor por consola y nuestro servidor no tiene un puerto de gestion remoto (ILO, iDrac, Alom, BMC, etc)....pero las maquinas virtuales funcionan correctamente y tenemos acceso a ellas, entonces, tenemos dos opciones:

-Si tenemos alguna mv con un Windows, accedemos a esta por RDP/VNC/etc y desde ahi accedemos por ssh o por el vClient directamente por la ip del ESX y ya podemos revisar que es lo que ocurre con la Service Console :-)

-Si tenemos una mv sin entorno grafico y/o linux, podemos acceder a ella por ssh y a su vez nuevamente por ssh a la ip de la Service Console del ESX y revisarlo desde ahi :-)

Esto se explica sencillamente porque el trafico entre las mv no sale del vSwitch del propio ESX.

De esto sacamos dos conclusiones: la primera es que tener un puerto de gestion remota del propio servidor fisico con redireccion grafica de consola, es muy importante patra no tener que hacer este salto; y la segunda es que quizas sea conveniente tener dos service console configuradas en vSwitch diferentes para tener un doble camino de acceso.