Entradas con la etiqueta ‘vsphere’

Mejora la seguridad de tu ESXi sustituyendo los certificados autofirmados

Por defecto, VMware viene instalado con una serie de certificados autofirmados (no emitidos por una autoridad certificadora) para establecer conexiones seguras entre los clientes y los servidores.

Estos certificados pueden ser seguros si son utilizados en una red privada. Pero si son utilizados para conectarse a través de Internet (por ejemplo si nos conectamos a nuestra infraestructura de virtualización con un cliente vSphere), es más seguro utilizar un certificado emitido por una autoridad de certificación (CA). En este caso, durante el proceso de conexión, la CA certifica que el certificado utilizado es auténtico.

Tanto los certificados autofirmados como los firmados por una CA aseguran que los datos viajan encriptados, pero los usuarios no están seguros de que realmente se están conectando a tu servidor vSphere.

Cómo reemplazar los certificados autofirmados

En primer lugar emitiremos una solicitud que enviaremos a la autoridad de certificación que elijamos (por ejemplo Thawte, Verisign, GeoTrust, etc.). Durante la solicitud generaremos un fichero de clave privada (.key). La CA nos enviará la clave pública (.crt) que será enviada al cliente cuando se inicie la conexión con nuestra infraestructura de virtualización.

Ambos ficheros (.key y .crt) deben ser copiados en nuestro host ESXi. Para realizar la copia de dichos ficheros en el host deberemos utilizar el interfaz vSphere CLI (vCLI) que puede ser descargado de forma gratuita desde la web de VMware.

Una vez descargado e instalado vCLI en nuestro ordenador, abriremos una consola MS-DOS (cmd) de Windows y nos colocaremos en la carpeta de instalación mediante el comando cd (normalmente C:\Archivos de Programa\VMware\VMware vSphere CLI\bin).

El siguiente paso es ejecutar una serie de comandos para copiar los ficheros .key y .crt a nuestro host ESXi (los ficheros deben estar alojados en el directorio de instalación de vCLI):

vifs --server youresxiserver.example.com --put yourkey.key /host/ssl_key

vifs --server youresxiserver.example.com --put yourkey.crt /host/ssl_cert

Para finalizar reiniciaremos el interfaz de gestión. Nos logueamos por SSH en nuestro host ESXi y ejecutamos los siguientes comandos (nos tenemos que asegurar antes de que no está configurada la opción de arranque/parada automática de máquinas virtuales ya que se pueden reiniciar automáticamente nuestras máquinas virtuales):

service mgmt-vmware restart

service vmware-vpxa restart

Share

Características a tener en cuenta si estamos considerando actualizar a VMware vSphere 5 (I)

En un artículo anterior hablábamos de las razones por las cuales las empresas están retrasando la adopción de VMware vSphere 5. En una serie de artículos comentaremos que nuevas características introduce la nueva versión de vSphere y qué aspectos deberemos evaluar si estamos considerando actualizar nuestra infraestructura de virtualización.

vSphere 5 introduce un conjunto de características que no están disponibles en la versión 4:

  • Gestión mejorada del almacenamiento con la introducción de la tecnología Storage Distributed Resource Scheduler y Profile-Driven Storage.
  • Mejoras en la gestión de red que puede ayudar a los administradores a priorizar el tráfico de las máquinas virtuales.
  • Sistema de alta disponibilidad rediseñado.
  • Mejoras en la seguridad.

Aparte de estas nuevas características ya conocidas, deberemos también conocer otras que en ocasiones se pasan por alto y podrían favorecer la adopción de la nueva versión de vSphere:

VMFS 5

El nuevo sistema de ficheros de VMware permite crear discos virtuales de hasta 2 TB utilizando bloques de disco de 1 MB. Es posible actualizar de un sistema de ficheros antiguo VMFS 3 a VMFS 5 de manera fácil y sin tener que reconstruir los datos existentes.

VMFS 5 es compatible con LUNs de hasta 64 TB sin necesidad de extensiones que conectan varias LUNs.

SplitRx Mode

Nuevo método para el procesamiento de paquetes de red recibidos. En versiones anteriores las máquinas virtuales procesaban los paquetes de red en un contexto único y compartido. Ahora es posible dividir los paquetes recibidos en múltiples contextos. Imaginemos que antes los paquetes tenían que esperar a que la línea de comunicación se liberara y ahora pueden tener una línea “VIP” con acceso directo a la máquina virtual.

Es posible especificar que NICs virtuales procesarán paquetes en un contexto separado, en vez de utilizar el método tradicional de cola de red compartida. Para ello es necesario que la NIC virtual utilize el adaptador de red VMXNET 3.

Control de E/S de red

vSphere 5 introduce mejoras en el control de E/S de red, de tal modo que es posible priorizar el tráfico de las máquinas virtuales. En vSphere 4, el control de E/S de red permite crear pools de recursos y establecer prioridades para un determinado Host, tipos de tráfico de red, etc. Pero el tráfico de las máquinas virtuales va en un único pool que no permite priorizar tráfico por máquina.

En vSphere 5 se introducen nuevos pools de recursos basados en 802.1p, permitiendo crear pools que asignan diferentes anchos de banda a múltiples máquinas virtuales ejecutándos en un mismo host. De este modo nos aseguramos que máquinas virtuales críticas obtienen el ancho de banda necesario.

Mejoras en Storage vMotion

Se introduce un nuevo sistema de Storage vMotion más eficiente. Ya no se utiliza el mecanismo de Change Block Tracking para almacenar cambios de disco durante el proceso de migración de datos. Ahora Storage vMotion realiza una escritura en espejo, lo que significa que cualquier escritura que se realiza durante la migración se realiza en el disco origen y destino a la vez. De este modo se asegura que los discos están siempre sincronizados.

Ahora también es posible realizar un Storage vMotion de una máquina con snapshots activos, lo cual no es posible en vSphere 4.

Mejoras en vMotion

La principal actualización en lo que respecta a vMotion en vSphere 5, es que ahora es posible utilizar múltiples NICs físicas para realizar una migración de máquina virtual, en vez de utilizar una sóla NIC. VMkernel utiliza todas las NICs físicas asignadas al grupo de VMkernel para automáticamente balancear el tráfico vMotion.

Es posible utilizar hasta 16 NICs físicas de 1 GBps o 4 NICs de 10 GBps. De este modo podemos incrementar la velocidad de las migraciones.

vMotion incluye la tecnología Metro vMotion. De este modo se incrementa la latencia permitida desde 5 a 10 milisegundos entre los interfaces VMkernel de los hosts que participan en la migración de máquinas virtuales. Esto nos permite migrar mejor máquinas virtuales entre centros de datos situados en diferentes localizaciones.

Share

¿Por qué se retrasa la adopción de vSphere 5?

Hemos encontrado un artículo en el cual se resume alguna de las razones por las cuales las empresas están retrasando la adopción de la versión 5 de VMware vSphere.

En muchas de las ocasiones, la principal razón es que los usuarios de VMware están esperando a ver como evoluciona el producto, en otros casos las empresas no ven razones suficientes para realizar la actualización a la nueva versión: si una empresa tiene una infraestructura VMware vSphere 4 que es estable y que periódicamente es actualizada mediante la emisión de parches, ¿por qué actualizar?

De hecho, más que las nuevas características incluidas, lo que ha llamado la atención de la nueva versión de vSphere es el nuevo modelo de licenciamiento basado en vRAM y no en sockets. Las principales mejoras introducidas en vSphere 5, por separado pueden no ser una razón suficiente para actualizar la infraestructura de virtualización. Si las empresas las comienzan a considerar en conjunto, podremos ver como en los próximos meses muchas empresas comienzan a actualizar sus infraestructuras. Estas mejoras son:

  • Con vSphere 5 es posible tener ficheros de sistemas de mayor tamaño que permiten alojar más datos conjuntamente y de forma consistente.
  • El sistema de alta disponibilidad se ha mejorado, siendo más robusto.
  • El sistema de almacenamiento se ha optimizado siendo más eficiente. La funcionalidad de Storage Distributed Resource Scheduler permite automatizar la gestión del almacenamiento. Los administradores son capaces de establecer políticas de almacenamiento y automáticamente gestionar la ubicación y el balanceo de máquinas virtuales entres sus recursos de almacenamiento.
Share

Cómo funciona y usos del filtro vSCSI de VMware

VMware introdujo en la versión 4 de vSphere el filtro vSCSI, una herramienta de filtrado adjunta al interfaz virtual SCSI. Esta herramienta actúa como una capa de transporte que envía los datos SCSI a las máquinas virtuales.

Entre los distintos tipos de usos de vSCSI está prevenir la pérdida de datos, establecer una capa antimalware y antivirus, así como técnicas de replicación para máquinas virtuales en ejecución. Actualmente existen grupos de trabajo desarrollando otros usos de vSCSI, como por ejemplo la encriptación de datos.

Uno de los aspectos más reseñables del filtro es su gran rendimiento en la lectura y escritura de bloques SCSI, una de las claves en la tecnología de discos virtuales dentro del entorno vSphere.

El primer uso que hizo VMware de la tecnología vSCSI fue en su producto de seguridad vShield Endpoint. Éste detecta y aisla el tráfico de antivirus y antimalware. A continuación, VMware desarrolló vShield App with Data Security, que utiliza el filtro vSCSI para ver qué datos sensibles no pertenecen a una determinada máquina virtual.

Como vemos los primeros usos de vSCSI fueron relacionados con la seguridad, pero nuevos usos han aparecido. Por ejemplo, vSCSI es utilizado en replicaciones en tiempo real de máquinas virtuales, de tal modo que bloques de datos que cambien en una máquina virtual pueden ser escritos en un centro de replicación externo. Un producto que utiliza vSCSI para replicar es Zerto Virtual Replication.

Cómo funciona vSCSI

El filtro vSCSI intercepta los bloques SCSI conforme son leídos y escritos por una máquina virtual, permitiendo enviar comandos personalizados al subsistema SCSI. Por lo tanto, es posible leer un disco virtual sin intervención de una máquina virtual.

http://www.virtualscsi.com/vscsi_files/image001.gif

Vamos a poner un ejemplo de cómo trabaja vSCSI en un proceso de replicación:

  1. Comienza un trabajo de replicación.
  2. El software de replicación envía comandos para leer un disco virtual de forma completa.
  3. La replicación, mediante técnicas de deduplicación, conforme va leyendo datos del disco virtual los envía al centro de replicación.
  4. El sistema de replicación cambia a un mecanismo de interceptación para guardar sólo aquellos bloques escritos por la máquina virtual.

Este tipo de esquema de replicación reduce los tiempos y los costes de ancho de banda asociados, ya que sólo aquellos bloques que han sido modificados serán replicados. Además, el filtro vSCSI es independiente de la máquina virtual por lo que no afecta al rendimiento de la misma.

 

Share

Siguen las reticencias con el nuevo licenciamiento de vSphere 5

Hace cerca de dos meses que VMware anunció su nueva versión de vSphere y su nuevo modelo de licencia todavía sigue dando que hablar.

¿En qué consiste el nuevo modelo de licenciamiento de vSphere 5?

Hasta la versión vSphere 4 el modelo de licenciamiento se basaba en un máximo de sockets CPU y memoria RAM por servidor físico. En la nueva versión, el enfoque cambia a un modelo de asignación de memoria desde un pool de memoria virtual (vRAM) limitando el máximo de vRAM por licencia. Cuando una máquina virtual es creada, se configura con una determinada cantidad de memoria virutal. A esto se le denomina VRAM.

No existe un límite en el número de cores por CPU y cada Host puede tener una cantidad ilimitada de memoria RAM. Cada licencia CPU de vSphere 5 tendrá asignada una cantidad máxima de vRAM  que es posible establecer en las máquinas virtuales y que esté siendo usada. Por lo tanto, sólo cuando una máquina virtual es encendida, la vRAM que tenga configurada es descontada del total de vRAM asignada en la licencia.

Según VMware, el nuevo modelo de licenciamiento ha evolucionado para darle un enfoque más “cloud” en el cual se paga por lo que se consume. El objetivo de este nuevo modelo es:

  • Liberar a los clientes de la asignación de licencias basada en hardware
  • El modelo se alinea con el concepto “IT as a Service”

A continuación os indicamos los distintos límites de memoria en función de la edición de vSphere 5. La capacidad de memoria sólo puede ser compartida entre servidores con la misma licencia de vSphere:

  • Standard Edition: 24 GB (995 USD)
  • Enterprise Edition: 32 GB (2.875 USD)
  • Enterprise Plus: 48 GB (3.495 USD)

El propio fabricante afirma que este modelo no afectará en los costes del 95% de sus clientes, pero si puede afectar a los ratios de consolidación y utilización de características avanzadas como la sobreutilización (overcommit) de memoria.

 

Reacciones sobre el nuevo modelo de licenciamiento

Según expertos, las empresas más afectadas serán las grandes compañías. Éstas han dimensionado sus entornos de virtualización con Hosts que disponen de muchos recursos hardware. Será necesario que vuelvan a rediseñar su arquitectura: una asignación excesiva de memoria en sus máquinas virtuales puede derivar en que sus costes de licenciamiento se disparen.

Por ejemplo existe el caso de una empresa estadounidense que quería reducir el número de host ESX de 16 a 7 antes del lanzamiento de la nueva versión de vSphere. Bajo vSphere 4, esta reducción suponía reducir de 30 a 12 licencias Enterprise Plus. Con el nuevo licenciamiento de vSphere 5, la utilización de toda la RAM disponible en los host supondrá al menos la utilización de 20 licencias Enterprise Plus.

Supongamos el caso de una empresa con una infraestructura vSphere 4.1 de reciente implantación con cuatro host ESX de 256 GB de RAM, 4 sockets y licencia Enterprise Plus cada uno. Con el nuevo modo de licenciamiento pasará de 16 licencias en la versión 4.1 frente a 18 licencias.

Algunos analistas dicen que la nueva filosofía va en contra de la proposición de valor que siempre ha ofrecido VMware, basada en utilizar al máximo los recursos físicos. Durante los últimos años VMware ha estado diciendo que uno de los principales beneficios de su hypervisor ESX frente a otros ha sido la capacaidad de sobreutilización (overcommit) de memoria. Todo ello gracias a su tecnología TPS que ahorra memoria física.

 

Share

Bienvenido a Virtualizamos

Virtualizamos es un proyecto de la empresa nerion que nace con el objetivo de convertirse en un portal de referencia en el mundo de la virtualización y el cloud computing.
Suscripción a Virtualizamos
Entradas antiguas por mes
Twitter
nerion - Registro Dominios, Hosting y Housing Profesional