Hola amigos, hoy vengo con una serie de buenas prácticas para mantener nuestros entornos XenServer lo más seguros posibles.

No soy ningún experto en seguridad, pero creo que lo podemos diferenciar en 3 niveles.

• Acceso a la administración
• Acceso a disco remoto
• Acceso a la red externa

Acceso a la administración (XAPI, SSH)

La XenAPI escucha por HTTP, puerto 80 es decir, texto plano y por HTTPS, puerto 443, cifrado por SSL. La interconexión entre XenCenter y XenAPI siempre se realiza por HTTPS con lo cual, nuestro acceso desde XenCenter siempre va a ser cifrado. El problema lo podemos tener en “plugins” de terceros que no implementen SSL para las peticiones hacia nuestros servidores.

Una buena práctica seria bloquear, en nuestros firewalls perimetrales, el acceso a nuestros servidores por el puerto 80 desde cualquier red y solo permitir HTTPS.

Es necesario también el acceso mediante SSH a nuestros servidores, pero solo desde la red administrativa/management. Un acceso por SSH por una contraseña insegura, expone a todo el entorno a un ataque.

Acceso a disco remoto (NFS, i-SCSI)

En el caso que estés utilizando un acceso a disco remoto vía ISCSI o NFS, es muy importante el aislamiento mediante interfaces dedicadas al propio storage. De este modo nunca expondremos el tráfico de disco (texto plano) a ninguna red de acceso.

Si usas NFS, los ficheros VHD de tu repositorio, están en texto plano así que sobretodo es importante que solo tengan acceso a estos recursos los servidores XenServer y administradores.

En el caso ISCSI, si tu cabina soporta CHAP para autentificar el “target” remoto, es la mejor opción. En ese caso solo van a tener acceso a esta LUN los servidores autentificados y asignados.

Acceso a la red externa

A menos que sea necesario, una máquina virtual no tiene por qué tener acceso a la red de administración del entorno XenServer.

Es una buena práctica establecer una interface física aislada para la administración y otra para hacerle llegar las demás redes (servicio) con el tráfico “taggeado” a nivel de switch. De este modo para la red de servicio, podemos crear un bridge por cada una de las vlans, aislando así cada uno de los entornos.

Eso es todo por hoy. Espero como siempre haberte aportado un nuevo granito de arena del mundo de la virtualización ¿Cómo securizas tu entorno XenServer?

Hola soy Miguel ángel Alonso y aquí estoy como cada martes para escribir sobre un nuevo tema del mundo de la virtualización de sistemas.

En el tema de hoy, vamos a hablar sobre cómo utilizar nuestras opciones de servidor de email en VMware vCenter para poder recibir tareas, eventos, alarmas y un largo etcetera cuando debemos enviarlo a cuentas de correo que requieren de cifrado o autenticación.

Este post se lo dedico a todos nuestros lectores pero en especial a mis alumnos de Barcelona de la semana pasada, ya que fueron ellos los que me hicieron indagar la manera de poder hacer dicha tarea.

Debo resaltar que este post está basado en un post de Paul Grevink, del cual he podido recoger la mayoría de los recursos de este post. Finalmente le he dado algún matiz distinto para una mejor compresión y algunas pinceladas propias para poder entenderlo bajo mi propio prisma y por supuesto traducirlo al castellano para la mayoría de todos nuestros lectores del blog.

Espero que os guste porque me parece muy provechoso y útil en nuestros entornos de VMware, así que comencemos  explicando todo desde un principio:

vCenter permite configurar alarmas para enviar correo electrónico, si es necesario. Antes de que vCenter pueda enviar el primer correo electrónico, ir en el menú, elige Administration y vCenter Configuratión del servidor.

Selecciona la sección de correo (MAIL). En esta sección puedes introducir el nombre del servidor SMTP (que será nuestro transmisor de correo electrónico) y  la cuenta del remitente, el nombre de la cuenta utilizada para enviar correo electrónico.

En mi “homelab”, me gustaría enviar correo electrónico a mi cuenta de Gmail. También sería bueno utilizar smtp.gmail.com como retransmisor de correo.

Gmail exige autenticación, por desgracia, en este momento no es posible configurar la autenticación SMTP con vCenter. Esto está confirmado en VMware KB 1004070.

Existen algunas opciones, ejecutar tu propio servidor de Microsoft Exchange, o instalar una máquina virtual Linux y ejecutar Postfix.

En mi homelab, quiero una solución simple, y no quiero que vCenter  dependa de otro tipo de máquinas virtuales que ejecutan bases de datos o servidores SMTP.

Por esta razón, MS SQL que se instala en el servidor vCenter , sería  una buena opción para enviar correo electrónico directamente desde vCenter.

Así que es momento de añadir alguna funcionalidad adicional, en este caso: hMailServer

hMailServer es un software de correo, libre y fácil de configurar como servidor de correo electrónico para Microsoft Windowsy además  también funciona en Windows Server 2008 R2.

Aquí está  un tutorial para que puedas instalar, configurar, probar y solucionar hMailServer con vCenter.

Preparación.

El fqdn de mi servidor vCenter es: vc.virtual.local.

En primer lugar, creamos un alias para el servidor SMTP, algo así como: smtp.virtual.local.

Ahora crearemos un (MX record) de correo en nuestro servidor DNS para la zona “virtual.local”.

Para comprobar el resultado, abrir una ventana de DOS y escriba este comando:

> nslookup –type mx < nombre >

La respuesta debe ser algo como esto:

hMailServer

Ejecuta hMailServer-5.3.3-B1879.exe en el servidor vCenter.

Hacemos click en NEXT

Hacemos click en  I Accept the agreement y seleccionamos Next.

Aceptamos  Full installation y Next

Para un “homelab” la opción de utilizar un motor de base de datos integrado (Microsoft SQL Compact) está bien. Microsoft SQL Server Compact Edition no puede utilizarse con servicios de alojamiento comerciales. Lee esto para otras posibles alternativas

Y finalmente en Install para comenzar con la instalación. Introduciremos un password del administrador  para la instalación de HMailserver y marcaremos la opción de conectarse automáticamente al arranque de nuestro sistema.

Una vez instalado, unicamente marcaremos la opción de SMTP para nuestro caso en concreto y los salvaremos.

Seguidamente iremos a la opción Settings de nuestra izquierda, elegimos el protocolo SMTP y finalmente la pestaña de la derecha:  Delivery of email

En este ejemplo, smtp.gmail.com es el servidor SMTP re dirección de nuestro mail.

Introduce la siguiente información:

Host local (nombre), recuerda has creado un alias en tu DNS.

Nombre del host remoto. En este caso se desea transmitir a Gmail y Google requiere autenticación por SSL. Así que escribe el nombre del host remoto, puerto TCP/IP remoto que  debe ser 465, tus credenciales de Gmail (si es tu caso) y no te olvides de comprobar el uso de SSL.

Ves a Configuración, Avanzado, IP Ranges. En este momento sólo queremos manejar correo electrónico desde el servidor local, así que vamos a eliminar el rango de Internet.

Bajo la anterior opción de IP Ranges, editaremos nuestra computadora, tal y como muestra el Screenshot. Deja marcadas las opciones tal y como te lo muestro para su correcto funcionamiento.

En el siguiente paso vas a ir al Top Level del asistente sobre la opción Wellcome y añade tu dominio desde la opción Add Domain.

Introduce el nombre de tu dominio de correo, en mi caso será virtual.local y guarda los cambios.

Ahora, es el momento para que compruebes la configuración. Ir a utilidades, diagnósticos Y selecciona el dominio que deseas ejecutar en prueba, luego selecciona el nuevo “maildomain” y presiona el botón de START para comenzar con los diagnósticos.

Como podemos observar todas las pruebas que has realizado están perfectas y con ello listo nuestro servidor para el re direccionamiento de correo con seguridad SSL de nuestro entorno de vCenter.

Ahora volvemos nuestro vCenter y en el apartado de Configuración y Mail podemos introducir finalmente los datos necesarios para que nuestra cuenta de correo se redireccione con la cuenta de gmail configurada en nuestro HMailserver.

Y por último, es el momento para tu prueba final. Quizás, ya has configurado tus alarmas, por lo que puedes esperar,que hasta alguna de ellas te funcione en este momento. De todas maneras hay otra forma  de probar instantáneamente nuestra configuración.

Ejemplo:

• Ir a tareas programadas y crear una nueva tarea. Realmente vamos a iniciar una máquina virtual.
• Selecciona Change the power state
• Selecciona la VM que quieres iniciar
• En este caso vamos a seleccionar Power ON.
• Introduce un nombre descriptivo para esta tarea y le seleccionamos  bajo Start Time la opción NOW.

Aquí introduciremos la cuenta de gmail a la que queremos envíar los eventos de dicha tarea. En el ejemplo podemos ver la cuenta de prueba  de Paul Grevink de quien es originario dicho post.

Aquí podemos ver el task enviado a dicha cuenta de correo.

Si queremos ver los logs de nuestro servidor de Mail para poder cerciorarnos de que dicho correo ha sido enviado, deberemos activar dichos logs y observar en la opción Status, Delivery Queue dicha tarea.

Ejemplo:

Bueno hasta aquí por hoy, espero que te haya gustado y puedas sacar partido de ello en todas tus instalaciones.

Me despido de vosotros hasta la semana que viene con un nuevo post sobre el maravilloso mundo de la virtualización de sistemas. Hasta la semana que viene.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, soy Florián Murillo. Hoy hablamos de Cisco Virtual Security Gateway, o lo que es lo mismo la solución de Cisco para la creación de zonas seguras dentro de la infraestructura virtual, integrado con Cisco Nexus 1000V.

Cisco Virtual Security Gateway tiene dos dependencias, necesita:

• Cisco Nexus 1000V ya que utiliza la tecnología vPath del switch virtual para su desempeño.
• Cisco Virtual Network Management Center, o sea la consola desde donde se crean y aplican las zonas y las reglas de filtrado.

Veamos como funciona Cisco VSG integrado con Cisco Nexus 1000V, para ello utilizaremos un ejemplo de flujo que penetra en la zona.

1. El primer paquete de un flujo que llega a la zona es capturado por vPath

2. vPath retransmite el paquete al Cisco VSG para su análisis.

3. Cisco VSG responderá denegando el acceso y se acabó la conexión, o bien, permitiendo el tráfico.

4. En ese momento se aplican en caliente ACLs de acceso para permitir que este tráfico concretamente SI pueda penetrar en la zona.

5. El resto del flujo no pasa por el VSG, las ACLs se mantienen hasta que finaliza el flujo.

Me parece una estrategia hábil para un despliegue masivo de seguridad.

La disponibilidad de Cisco VSG se realiza con 2 virtual appliances en activo/standby.

En esta categoría de productos hay muchos competidores: VMware, Reflex Systems o Altor Networks (ahora parte de Juniper) entre otros. La competencia siempre enriquece la creatividad de los fabricantes y nos beneficiamos todos. ¿Crees que este tipo de productos son una necesidad real o de marketing?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Esta semana veremos las diferencias entre la virtualización basada en hipervisor y la virtualización basada en host.

La virtualización basada en hipervisor (también denominada Bare-Metal), como por ejemplo vSphere™ ESXi, Microsoft Hyper-V o Citrix XenServer, está instalada en un servidor físico sin la necesidad de que exista un sistema operativo (Windows o Linux) instalado previamente.

No obstante, la virtualización basada en host, como por ejemplo VMware Server, VMware Workstation o VMware Fusion, necesita previamente un sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux.

Hay varias razones por las que un cliente elegiría el software de virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en lugar de un software de virtualización basado en host, como por ejemplo VMware Server.

• Primero, con el software de virtualización basado en hipervisor, es posible actualizar las máquinas virtuales que se albergan en los servidores físicos sin ningún tipo de downtime.
• Segundo, es muy probable que la empresa ya esté virtualizando varios servidores físicos y quiera tener la opción de tener una gestión centralizada.
• Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y rendimiento al no precisar de un sistema operativo Host, con lo cual se elimina un posible punto de fallo.

Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento, es la virtualización basada en host la que ofrece una compatibilidad con el hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en tu servidor físico entonces podrás instalar la solución de virtualización basada en host.

Por consiguiente, una de las mayores diferencias de la solución de virtualización basada en hipervisor y la solución de virtualización basada en host – aparte de las obvias ya mencionadas – , es que esta última tiende a tener una lista de hardware certificado mucha más amplia.

Sin embargo, la virtualización basada en hipervisor tiene un mayor rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más funcionalidad. Para ver más información sobre los tres factores más importantes a la hora de elegir un hipervisor para el software de virtualización entra en este enlace:

Asimismo, y a diferencia de las versiones anteriores a VMware vSphere™ ESXi,  las variables memoria reservada y memoria configurada (Reserved Memory y Configured Memory) afectan al incremento o reducción del memory overhead, el cual es una “penalización” a nivel de la capa de memoria que todos tenemos que pagar por el simple hecho de virtualizar nuestro servidor físico. Esta penalización se mide en megas de memoria RAM y son megas de memoria que dejamos de ver y de usar en nuestro servidor físico.

Como consecuencia de este “impuesto revolucionario” que existía por el simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa una nueva funcionalidad llamada VMX swap con la que es posible reducir el memory overhead de tus máquinas virtuales. Puedes ver un video tutorial sobre el Memory Overcommit en VMware vSphere 5 en este enlace.

Básicamente, con esta nueva tecnología llamada VMX swap, el tamaño del memory overhead se crea en un fichero swap con lo que este espacio de memoria puede llegar a ser reutilizado por el hipervisor. Esta técnica posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5 con respecto a versiones anteriores para soluciones de virtualización basados en hipervisor.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Ferran Serafini y hoy os enseñaré a instalar un Ubuntu 10.04 LTS paravirtualizado partiendo de una instalación HVM para nuestro entorno XenServer.

XenServer ya viene preparado para instalar Ubuntu. El método que voy a usar en este post quizá no es el más sencillo y rápido pero podremos ver muchos puntos interesantes y sobretodo la diferencia entre HVM y PV.

Lanzamos “New VM” usando el template “Other Install Media”. La llamaremos Ubuntu-HVM

La seleccionamos de nuestro repositorio de Isos donde previamente hemos descargado la ISO.

De CPU/Memoria se  puede poner lo que uno quiera, por ejemplo 2 CPUs i 512 MB de Ram. Posteriormente creamos su disco duro virtual

Finalizamos la configuración de la máquina virtual y arrancamos la máquina virtual siguiendo el asistente de instalación de una Ubuntu normal.

A modo de consejo personal, prefiero poner la swap en la primera partición del disco, de modo que el sistema este instalado en la ultima partición, así, en el momento que haga falta extender el disco de la maquina virtual por falta de espacio, simplemente haciendo un resize2fs redimensionariamos la partición.

Otro dato muy importante es que pygrub no soporta ahun EXT4, por lo tanto la particion /boot tiene que ser EXT3.

Ya tenemos nuestra Ubuntu 10.04 HVM. Ahora vamos a paravirtualizarla. Para ello, entramos como root y nos “guardamos” algunos datos que necesitaremos para la parametrización siguiente.

Las nuevas versiones de Ubuntu vienen ya con el nuevo grub-pc, accedemos al fichero /boot/grub/grub.cfg y localizamos las siguientes líneas ya que este no es “leíble” para pygrub:

### BEGIN /etc/grub.d/10_linux ###

menuentry ‘Ubuntu, with Linux 2.6.32-33-server’ –class ubuntu –class gnu-linux –class gnu –class os {

recordfail

insmod ext2

set root=’(hd0,1)’

search –no-floppy –fs-uuid –set 115a8cea-b9ac-4ecc-bc2e-3f172630cdc8

linux    /boot/vmlinuz-2.6.32-33-server root=UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro   quiet

initrd   /boot/initrd.img-2.6.32-33-server

Ejecutamos la siguiente línea para especificar que la consola virtual de la maquina sera hvc0 y no tty1 para que podamos usar la consola de la maquina virtual de XenCenter.

sed -e “s/tty1/hvc0/ig” /etc/init/tty1.conf | sudo bash -c ‘cat > /etc/init/hvc0.conf’

Apagamos la máquina virtual.

El siguiente, totalmente opcional, consiste clonar la máquina virtual. Para no confundirnos, la renombramos el clon a Ubuntu-PV.

En el domain0 ejecutamos lo siguiente:

# xe vm-list name-label=Ubuntu-PV

uuid ( RO)           : fce7a414-4475-4875-0af0-632b4a8d6d03

Localizando así el uuid nuestra máquina virtual

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-policy=”"

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-params:”"

Con esto habremos eliminado los parámetros que interpreta XenServer para arrancar la máquina virtual como HVM.

Añadimos ahora los parámetros que vimos en el grub para arrancar  de forma paravirtualizada:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-args=”root= UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro quiet console=hvc0 xencons=hvc0″

Utilizaremos pygrub para arrancar la máquina virtual:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader=pygrub

Como pygrub no es compatible con las nuevas versiones de grub, especificamos el kernel y el ramdisk directamente.

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader-args=”–kernel=/boot/vmlinuz-2.6.32-33-server –ramdisk=/boot/initrd.img-2.6.32-33-server”

Esta configuración del PV-bootloader-args hay que modificarla cada vez que se cambie/actualice el Kernel de la máquina virtual.

Con esto, arrancamos nuestra máquina virtual y ya la tenemos totalmente paravirtualizada. Vera un incremento de rendimiento muy interesante y estarás aprovechando toda la potencia de Xen. Ahora solo falta instalar las XenTools y convertir como template.

Eso es todo por hoy, espero como siempre, haberte enseñado algo útil para hacerte tu día a día con XenServer más sencillo y eficaz.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Buenos dias, soy José Mª Gris y como cada semana estoy aquí para comentar temas de este ecosistema.

Hoy nos vamos a ir a entornos más conceptuales para hablar sobre la Virtualización y su aplicación en entornos industriales. Sí, parece como si hasta ahora siempre que pensábamos en montar un entorno virtualizado estaríamos hablando de CPD impolutos o como mucho de racks dentro de una oficina.

En alguna otra vida he trabajado en compañías químicas y he vivido el mundo de los PCs industriales, de las BlackBox y los PLCs (no hablo de los Power Line Connect). Os aseguro que es un mundillo distinto, donde el rack es un armario industrial que está colgado de un altillo de un techo sobre una nave industrial en la que para hablar con tu compañero tienes que alzar la voz.

Que los sistemas informáticos estan imbricados en los diversos sistemas industriales, hoy por hoy está fuera de discusión. Pero las preguntas son dos: ¿Ha llegado la virtualización a este entorno? ¿Y si no ha llegado que puede aportar?.

En mi experiencia y en visitas desarrolladas últimamente a estos entornos, hasta donde llega mi conocimiento puedo decir que la virtualización es incipiente, aunque los responsables de IT están muy interesados en buscar soluciones y miran muy de cerca la virtualización.

¿Que aporta?

He visto lugares donde los pc de control corren sobre sistemas operativos de mas de 10 años. Dice mucho de los PC de entonces ¿no?. En ocasiones estos pcs estan controlando toda la ventilación de una planta o bien una prensa de plancha del entorno automovilístico. El problema es “un dia este pc se va a morir y entonces que haremos”. Independientemente de la conveniencia estratégica o no (lo dejaremos para otras personas), el virtualizar el Sistema permitirá prolongar la vida de la VM más allá de la vida del PC físico donde fué instalado.

Estos sistemas informáticos, además de tener como principal función la de “ordenar” la ejecución de las operaciones de los sistemas industriales, también se encargan de recoger la información de pesos, medidas, cantidades que proporcionan los PLC. En este punto la disponibilidad del sistema sera del 9x% si aplicamos facilidades de Alta Disponibilidad que nos aporta la virtualización de servidores. De igual forma, técnicas de replicación síncrona o bien asíncrona nos permitirán disponer de un sistema de respaldo y una pérdida mínima de informacion (RPO) en caso de caída. Muchas de estas técnicas en entornos fisicos son inviables o bien de un alto coste.

En casos de industria farmaceútica o de principios activos hemos tenido que diseñar sistemas SAN activo-activo para no perder un sólo dato que haya salido de los PLC, sencillamente porque la FAA obliga a que toda la producción esté respaldada por trazabilidad de lotes e información. Pérdidas de información pueden suponer que la producción que no dispone de esta información tenga que ser desechada.

En otro orden, las cadenas de montaje cada vez más incorporan el concepto de “estación de trabajo”, la cual incorpora su propio PC. Este PC, aunque industrial muchas veces (otras no) se halla en un punto de la cadena con todos los PC de la misma. Ello significa que debemos disponer de BlackBox y otras soluciones complicadas para poder llegar a las estaciones con los periféricos precisos.

En este punto la virtualización de escritorios facilita de forma importante la administración, disponibilidad del sistema (RTO), reducción de consumo y averías, etc. Por encima de ello la virtualización de aplicaciones nos permitirá migrar la aplicación crítica (ultima razón de la existencia del escritorio) para que pueda ser migrada o portada a través de la evolución de los S.O.

En conclusión, la virtualización aplicada a los entorno industriales aporta muchas facilidades para desarrollar sistemas más robustos, fiables y flexibles a costes asumibles. Hasta la semana que viene.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo. Las novedades aparecidas en la versión 1.4 (incluyo la 1.4a) de Cisco Nexus 1000V son importantes y a continuación detallaré las más destacadas desde mi punto de vista:

Cisco vPath: Es una novedad de la versión 1.4 y, su sola presencia, justifica la nueva versión.

Se integra con los VEM, por tanto se instala en todos los host que participan del switch distribuido.

Su misión es interceptar el tráfico, interrogar a los Virtual Service Nodes y ejecutar las políticas definidas. Los Virtual Service Nodes existentes en este momento son: Cisco vWAAS, el Cisco VSG y el Cisco ASA 1000V.

Class-Based Weighted Fair Queueing (CBWFQ): Es la respuesta de Cisco al Network Resources Pool de los switches distribuidos de VMware.

Las características destacadas de CBWFQ son:

• La estrategia de colas permite que una clase de tráfico no impida otros tráficos.
• Respeta el ancho de banda garantizado para cada clase de  tráfico.
• Optimiza la utilización del ancho de banda.

Dispone de varios protocolos ya definidos: vMotion, FT-Logging, iSCSI, NFS, ESX Management, N1K Control, N1K Packet y N1K Management.

Compatibilidad con vSphere 5: En la versión 1.4a de Cisco Nexus 1000V nos encontramos con soporte para vSphere 5, es importante, en especial si pensamos en migraciones futuras de arquitecturas existentes.

El resto son mejoras de funcionalidades ya existentes, algunas de ellas muy demandadas a nivel de seguridad. Por ejemplo la posibilidad de poner ACLs en el interfaz de gestión del switch distribuido, ya que el firewall de ESXi no lo contempla.

¿Qué nos depara el futuro de Cisco Nexus 1000V?

Apertura a nuevas plataformas de virtualización, VXLAN y otras sutilezas que llegarán pronto… Pero de eso hablaremos mas adelante.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hoy hablaremos sobre máquinas virtuales y su uso con lo que esta semana toca teoría. A lo largo de las próximos post de las próximas semanas, empezaremos a ir desgranando los diferentes componentes que forman una solucione de virtualización de servidores.

Una máquina virtual, por ejemplo en VMware vSphere™ 5, es básicamente un conjunto de ficheros planos y binarios los cuales conforman la máquina virtual (MV) completa, con su sistema operativo y aplicaciones incluidas. Los ficheros más importantes que componen una máquina virtual son: el fichero de configuración (.vmx), el fichero de disco virtual (.vmdk), el fichero BIOS de la máquina virtual (.nvram) y el fichero de log (.log).

VMware vSphere™ 5 permite crear máquinas virtuales usando dos wizards: Typical y Custom. Si seleccionas el método Typical, el wizard solo te pedirá el nombre, DataStore para la máquina virtual, sistema operativo y el tamaño del disco virtual, sin embargo, no tendrás la opción de configurar otras opciones como el número de vCPUs, la versión del hardware virtual, la cantidad de memoria y un largo etcétera.

El tamaño del fichero swap de una máquina virtual (.vswp) es igual a la cantidad de memoria RAM configurada en dicha máquina virtual. Recuerda que este fichero en VMware vSphere se genera cuando la máquina virtual se arranca y se borra cuando se apaga.

Con la nueva versión vSphere™ ESXi 5, el máximo número de discos virtuales por host se ha aumentado a 2048 discos virtuales. Asimismo, el tamaño máximo de un disco virtual que puedes configurar en una máquina virtual es de 2TB menos 512Bytes (espacio necesario del overhead del disco virtual).

En cuanto a la memoria RAM asignada a las máquinas virtuales, ahora es posible asignar hasta un 1TB de memoria RAM física de tu host, el cual es el tamaño máximo que un host ESXi físico puede tener configurado.

A cada máquina virtual le puedes conectar máximo un controlador IDE, al cual puedes conectar hasta 4 dispositivos IDE, siendo cuatro el número máximo de adaptadores SCSI por máquina virtual.

En cuanto a dispositivos xHCI USB se refiere, es posible conectar hasta 20 controladores USB por máquina virtual. Sin embargo, solo es posible conectar un dispositivo USB 3.0 por máquina virtual.

Por último, puedes configurar hasta 128MB de memoria RAM destinada a la memoria de video por máquina virtual. Asimismo, el máximo número de vCPUs (virtual CPUs) por host ESXi es de 2048, siendo 25 el número máximo de vCPUs por core. El número máximo de vCPUs que podrás asignar a tus máquinas virtuales es de 32 vCPUs. Nota que para llegar a este número de vCPUs también el sistema operativo tiene que soportarlo.

Con el lanzamiento de la  nueva versión de VMware vSphere 5, VMware ha introducido una nueva versión también de hardware virtual, concretamente la llamada versión 8. Esta version de hardware virtual no es compatible con versiones anteriores a vSphere™ 5. Por consiguiente, si quieres tener un entorno mixto, ESX/ESXi 4.x y vSphere™ ESXi 5, has de dejar el hardware virtual de tus máquinas virtuales con la versión 7 correspondiente a la versión 4 de VMware vSphere™ ESX/ESXi.

Para terminar, puedes ver un video tutorial de instalación de una máquina virtual en un servidor ESXi 5 gratuitamente. Entra en nuestra página web dedicada en exclusiva a los videos tutoriales de contenido multimedia en nuestra sección de videos tutoriales de formacion en VMware vSphere 5.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.

Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.

Las opciones que tenemos para un SR son:

Veamos las propiedades de cada una de estas tecnologías.

Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6  y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.

Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.

NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.

Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.

iSCSI: La utilización de iSCSI en XenServer permite  una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.

Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.

Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local,  los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.

Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.

StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.

Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs

Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.

¿Qué tecnología de almacenamiento utilizas en tus entornos?

Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, soy Florián Murillo. Estamos en un entorno muy cambiante, tanto que lo DICHO este mes puede quedar obsoleto el mes próximo… Por ese motivo, durante las próximas semanas, desarrollaré el estado ACTUAL de las tecnologías Cisco relacionadas con el Virtual Networking.

¿Qué es Virtual Networking?

Es la virtualización de la capa de acceso de switches; aquellos switches donde están conectados los servidores que también vamos a virtualizar.

O lo que es lo mismo: Los switches virtuales donde están conectados los servidores (ahora virtuales).

Se esquematiza en la figura siguiente:

Esto es lo que hace que los responsables de configurar los switches físicos a los que se conectarán los hosts ESX/ESXi deban pensar en estos hosts como switches, ya que en realidad están conectados a switches (virtuales).

Características únicas de los switches virtuales:

1. Los switches virtuales no se pueden apilar entre ellos, solo podemos conectar a un switch virtual interfaces físicos del host, las vNICs de las VMs y los puertos de servicio del kernel (vmk y vswif).
2. Los switches virtuales no tienen spannning-tree (STP), por tanto recordar deactivar STP en los puertos de los switches físicos donde se conectan los hosts ESX.
3. Los switches son de nivel 2 (L2), es decir, requieren “ayuda” externa para encaminar tráfico entre VLANs.

Cisco entra en el Virtual Networking con la llegada de vSphere 4 y concretamente utilizando la vNetwork Appliance API.

El switch virtual distribuido (dvSwitch) es un elemento básico para la implantación de grandes infraestructuras virtuales y, por extensión, para el despliegue de soluciones IaaS bajo el modelo de cloud computing. El elemento diferencial es su arquitectura. Las configuraciones se despliegan automáticamente a todos los hosts que participan en el dvSwitch, sin necesidad de repetir el cambio host por host, como ocurre con el vSwitch clásico de VMware.

El dvSwitch aporta funcionalidades nuevas respecto a los vSwitches, que podemos resumir en Seguridad, QoS, Gestión y Arquitectura abierta.

Cisco basa su arquitectura de Virtual Networking en Cisco Nexus 1000V, que incorpora características adicionales respecto dvSwitch.

Desde su aparición en el 2009, han aparecido productos que extienden las funcionalidades de Cisco Nexus 1000V, como son:

• Cisco Virtual WAAS
  • Solución de aceleración WAN y balanceo.
• Cisco Virtual Security Gateway
  • Solución de firewall por zonas, de forma que tengamos varios servicios de clientes diferentes en el mismo segmento de red y poder definir que se puede ver y por quien…
• Cisco ASA 1000V (que describimos la semana pasada)
  • Firewall perimetral y de filtrado entre VMs dentro de una zona.

Estos elementos se complementan con funcionalidades y soluciones clave:

• Cisco Nexus vPath
• Cisco Virtual Network Management System

En los próximos post, hablaremos de las novedades que nos aporta cada producto, empezando por la base: Cisco Nexus 1000V y Cisco Nexus vPath. ¿Qué opináis de la estrategia de Cisco en el tema Virtual Networking?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de abajo. Gracias por el apoyo.