Mostrando entradas con la etiqueta Virtualizacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta Virtualizacion. Mostrar todas las entradas

martes, abril 30, 2013

¿Qué ancho de banda es suficiente para un centro de datos virtual?

 
Los profesionales de TI suelen citar la virtualización y las copias de seguridad como las razones por las que necesitan más ancho de banda. Pero no es necesario disponer de una red de 10 GbE para mantener un alto nivel de rendimiento.

En principio tiene mucho sentido pensar que una infraestructura virtual necesita una gran cantidad de ancho de banda. Digamos que la organización dispone de 20 servidores físicos consolidados, cada uno de ellos con dos puertos Gigabit Ethernet (GbE) conectados a un host virtual. Seguro que esto significa que el host no necesita más que unos cuantos puertos GbE, ¿no?
La realidad es que la mayor parte de esos host físicos no usan por completo todo el ancho de banda disponible, salvo en momentos muy concretos. Así que compartir un puerto GbE entre una docena de máquinas virtuales (VMs) no será un problema. La virtualización tiende a incrementar el uso medio de esos puertos desde menos de 1% hasta un 5% ó un 10%. Los VMs no necesitan mucho ancho de banda.

Dicho esto, los hosts de virtualización requieren puertos rápidos, principalmente para las transferencias de VMs entre los hosts. Mover 16 GB de datos contenidos en una de las VMs a través de una migración en vivo puede saturar el puerto GbE durante unos minutos. Este problema se agrava si consideramos que las migraciones también usan la memoria RAM de forma intensiva.

Si mi host virtual con 128 GB de RAM está saturado, migrar todos los datos de las VMs usando un solo puerto GbE puede llevar en torno a media hora o más. Si estoy migrando las VMs debido a un error físico en el sistema, podría tardar aún más. (Imagine la sensación cuando un host repleto de terabytes de memoria está a punto de fallar). Sin embargo la misma operación con un host de 128 GB y 10 conexiones GbE tardaría menos de cinco minutos, reduciendo el riesgo de fallo de las VM debido a un fallo del host virtual.

La importancia del ancho de banda en el almacenamiento

Las redes de almacenamiento con un gran ancho de banda también son un importante activo en las infraestructuras virtuales. La cantidad de ancho de banda necesaria para el almacenamiento depende no solo del número de transacciones, sino también de su tamaño. Windows File Server, por ejemplo, necesita transacciones relativamente pequeñas para acceder al almacenamiento, mientras que los servidores de base de datos usan transacciones de tamaño medio.

En ambos casos la carga de trabajo está limitada por la tasa de transacción de almacenamiento, incluso mucho antes de que el ancho de banda se convierta en un factor a tener en cuenta. Para las VMs de bajo uso y fácil virtualización, el almacenamiento en red no es una limitación, incluso a velocidades de GbE. Pero para las VMs con un uso más intensivo de recursos es mejor asegurarnos de disponer de docenas de “ejes” disponibles o de una razonable cantidad de discos de almacenamiento sólido antes de empezar a exigir redes de almacenamiento más veloces.

Copias de seguridad: las asesinas del ancho de banda

Conforme pasamos de la jornada laboral de 9 a 5 a la era del “siempre en línea” del Internet, la jornada laboral se superpone con la ventana de las copias de seguridad – ese momento en el que las empresas solían hacer copias del contenido de sus servidores, normalmente en las horas más tranquilas. Ahora las empresas necesitan mantener todo su rendimiento durante todo el día, así que las redes no pueden estar saturadas.

Las copias de seguridad son transacciones enormes que pueden colapsar una red rápidamente. Por eso resulta de sentido común tener una “vía rápida y ancha” por donde mover los datos. En estos casos, el elemento limitador son los discos de almacenamiento y no la propia conexión.

Siendo más concretos, si la herramienta de copia de seguridad usa agentes instalados en las VM, entonces necesitamos rutas rápidas a los hosts virtuales que eviten los posibles bloqueos durante el proceso de copia. (También deberíamos asegurarnos de que los hosts cuenten con la RAM y la CPU suficientes para poder gestionar este aumento de carga). Pero con un poco de suerte, nuestras copias de seguridad se descargan de las VM y de los host virtuales. Por lo tanto, conectar el servidor de seguridad con la unidad de almacenamiento, usando la conexión más rápida disponible, es definitivamente una buena idea. 

Y si disponemos de una red rápida para conectar el servidor de almacenamiento con el de copia de seguridad, ¿tiene sentido tener una red mucho más lenta para los hosts? Si vamos a comprar nuevo equipamiento, seguramente no. El coste incremental de disponer de puertos de red más rápidos es bajo y, con el tiempo, la demanda de ancho de banda seguramente aumentará.

Por otro lado, si lo que queremos es simplemente resolver el problema de la velocidad de las copias, probablemente compraremos puertos más rápidos para los servidores de almacenamiento y seguridad.

En última instancia, a medida que se compre nuevo equipamiento, iremos incluyendo puertos más rápidos. Con el paso del tiempo nos preguntaremos cómo nos las habíamos ingeniado en el pasado con esas redes tan lentas.

viernes, octubre 02, 2009

Redimensionar VMWare y VirtualBox

Redimensionar un disco de VMWare.

Este documento describe como puede redimensionar los discos en VMWare.

Aqui se describe varios metodos de como hacer esta tarea,

SIEMPRE ANTES DE HACER CUALQUIER MODIFICACION POR FAVOR RESPALDO SU INFORMACION.

Metodo 1: Usando VMWare Converter (Probado con la v3):

1. Apague todas las virtual machine;
2. Inicie VMWare Converter;
3. Abra las ventanas de Convert Machine;
4. Seleccione 'standalone virtual machine' tanto al Source como al Destination;
5. Seleccione 'Select volumes and resize to save or add space';
6. Ingrese el nuevo tamaño, con eso queda listo.

En muchos de los casos el proceso de expansion es un proceso muy lento, generalmente se requiere reinstalar VMWare Tools, la principal desventaja es que el Convertidor de VMWare utiliza mucho espacio en disco, tanto para el Origen como para el Destino.

Metodo 2: Utilizando VDiskManager:

1. Apague todas las virtual machine;
2. Haga Commit/Elimine todos los Snapshots primero o haga Full Clone si utiliza Link Clones.
3. Abra el Command Prompt y ubiquese en:
C:\Program Files\VMWare\VMWare Server O
C:\Program Files\VMware\VMware Workstation

Para 64-bit
C:\Program Files (x86)\VMWare\VMWare Server O
C:\Program Files (x86)\VMware\VMware Workstation
4.Ejecute este para expandir el virtual disk:
vmware-vdiskmanager -x 12GB "Mi-Particion.vmdk"
(En este caso esta ampliando el nuevo tamaño a 12GB), el nombre puede contener espacios dentro de las comillas.

Metodo 3:
Ayer cree una partición virtual en un VMWare Workstation que voy a tener que utilizar durante unos días para normalizar un proceso de migración de Windows a Linux.

El caso es que como se trataba de instalar un Windows XP y hacer cuatro apaños con él, pues el tamaño de la partición lo hice de sólo 2GB. Cuál fue mi sorpresa después de inyectarle las 63 actualizaciones pertinentes que me había quedado con sólo 200MB libres de esos 2048 iniciales. Es algo que no entiendo porque no he instalado NADA sobre ese SO.

Por la tarde, hablando con un tipo le comento la jugada y le digo ‘mañana haré la partición más tocha con vmware-vdiskmanager y luego redimensionaré el volumen lógico del WinXP con diskpart.exe en Modo a prueba de fallos’.
Un par de comandos y una captura que ilustran el proceso y problema resulto sin QParted, Partition Magic ni cositas gŕaficas similares.

Nota: en el caso de que el disco a dimensionar no sea ‘preallocated’ basta con la segunda instrucción.

Lo primero es convertir el disco virtual de preallocated a growable (de monolito a agrandable o redimensionable), el comando es este:

# vmware-vdiskmanager -r DiscoFuente.vmdk -t 0 DiscoDestino.vmdk

Para convertirlo en varios archivos (split) no redimensionable (preallocated):

# vmware-vdiskmanager.exe -r DiscoFuente.vmdk -t 1 DiscoDestino.vmdk

Para convertirlo en varios archivos (split) redimensionable (growable):

# vmware-vdiskmanager.exe -r DiscoFuente.vmdk -t 3 DiscoDestino.vmdk

Esto convierte el disco de su tipo reservado original a un disco virtual growable que consiste en un solo archivo de disco virtual. La espacio de disco virtual se reserva no más.

Ampliar el tamaño de un disco virtual existente:

Para ampliar el tamaño de un disco virtual, utiliza el siguiente comando:

# vmware-vdiskmanager -x 40GB Disco_Growable.vmdk

Esto aumenta la capacidad máxima del disco virtual a 40GB.

Ahora para arrancar la máquina deberemos darle la ruta de la imagen que hemos redimensionado.




Redimensionar Unidad de VirtualBox - DriveImage XML

No sería la primera vez en que las perspectivas de tamaño con el que creamos una maquina virtual se quedan pequeñas, y el problema es que VirtualBox no nos permite redimensionar el tamaño de los discos. La solución la vamos a encontrar en otro programa, DriveImage XML.

Este programa, que podemos usar de forma gratuita siempre y cuando sea para uso personal, nos permite crear imagenes / backups de nuestros discos duros. Realmente lo que vamos a hacer es copiar la unidad que se ha quedado pequeña en otra de mayor tamaño.

Los pasos que debemos de llevar a cabo son los siguientes:

1. Crear un nuevo disco con el tamaño deseado, desde el administrador de discos Virtuales de VirtualBox.

2. Añadir la nueva unidad a la maquina virtual en la que tenemos el disco que se nos quedo pequeño.

3. Instalar el programa DriveImage XML en la maquina virtual.

4. Realizar un Drive to Drive.



* Elegimos el Disco Origen. NEXT
* Elegimos el Disco Destino. NEXT
* Y Confirmar, Simple no?



5. Ahora tenemos que ir Administrador de discos de Windows y activar la unidad.



6. Por último solo nos queda apagar la maquina y volver al gestor de Discos Virtuales de VirtualBox, y seleccionar la nueva unidad de mayor tamaño como unidad Maestra.

Si todo ha ido bien tendremos una maquina virtual con una unidad de mayor tamaño. En este caso podremos borrar la unidad original si ya no la necesitamos.