Cisco anunció hoy la disponibilidad del  nuevo routers CRS3 (Carrier Routing System) diseñados para soportar las demandas actuales de internet como las transmisiones de video en tiempo real, como así también los requerimientos futuros de los nuevos servicios online de esta década y las futuras.

Este nuevo router presenta una capacidad 12 veces superior de trabajo con respecto al equipo más cercano en capacidad de la competencia y 3 veces más que su predecesor de la misma marca está pensado para las comunicaciones de banda ancha y los nuevos requerimientos de entretenimiento como de video on demand cada vez más populares.

Detalles del equipo:

• Escalable con una arquitectura multi-chasis el Cisco CSR3 permite procesar hasta 322 tbps lo cual nos permitiría descargar la biblioteca del Congreso de los Estados Unidos en menos de un segundo y permitir que todo China haga video conferencia en simultáneo.

• Diseñado para trabajar de forma óptima, este equipo no solamente puede encaminar los paquetes a las rutas necesarias sino que además de esto puede hacer uso de las nuevas tecnologías multi-direccionales pudiendo determinar el camino más corto a un contenido determinado mejorando el impacto sobre la red y la experiencia del usuario.

• Todo estas funcionalidad consumen solo el 40% de la energía consumida por el modelo anterior, el CSR1, que puede ser modificado para transformarse en un CSR3 protegiendo las inversiones realizadas.

De acuerdo al anuncio de prensa del lanzamiento del Cisco CSR3 el costo del equipo es de U$D90.000 (ya veremos cuanto sale en LATAM).

Nicolás Solop

El pasado primero de Febrero de 2010, nuestros amigos de xtravirt (empresa dedicada a virtualización) publicó de forma gratuita su plugin de microsoft remote desktop (RDP) para vmware vsphere client.

Por más trivial que parezca, el plugin es sumamente útil para aquellos administradores que día a día utilizan más de 50 o 100 máquinas virtuales y tienen que tomar control remoto de ellas para administrarlas.

El principal motivo para utilizar este plugin es justamente que acceder por el modo consola en VMware no es una de las mejores practicas sugeridas por VMware dado que  consume una importante cantidad de recursos en las másquinas virtuales y en el service console del ESX, ni hablar si hay varios administradores conectados y olvidan las sesiones de consola abiertas.

Por otro lado nos agiliza las tareas del día a día evitando tener que abrir dos o tres aplicaciones para gestionar nuestros servidores.

Sin lugar creo que será una tendencia creciente la de incorporar pequeños plugins que nos facilitaran un poco la existencia.

En esta Nota, enumeramos los puertos que se necesitan disponibles para la infraestructura de VMWare View y la virtualización de Estaciones de Trabajo.

Para permitir la conexión de clientes Externos a un Security Server que se encuentra dentro de una DMZ, el Firewall Front-End debe permitir el tráfico entrante de los siguientes puertos TCP:

También, como es de imaginarse, se necesitan habilitar los puertos para la comunicación entre los Servidores View Connection que están en la red interna.

Los puertos necesarios para habilitar el tráfico de entrada son:

En caso de utilizar las políticas de USB Redirection y MMR, habilitar tambien los siguientes puertos para RDP:

USB Redirection: TCP:32111

MMR: TCP:9427

Cortito y conciso! Justo lo que buscás, los puertos para habilitar y que tu infraestructura de Desktops virtualizadas funcione.

Saludos!

Los servidores blades han experimentado una importante evolución desde sus comienzos. Allá por el 2003 los servidores blades empezaban a hacer auge y las compañías mas cercanas a la innovación eran las primeras en adoptarlos, bajo una gran desconfianza en términos de compatibilidad futura, pero con gran entusiasmo por ser pioneros en la implementación de dicha tecnología.

HP Blade C7000 Chasis

Bien, en esa época IBM también comenzaba a hablar de su Datacenter on demand, una idea muy buena pero con poca visibilidad en Argentina, más aun cuando su principal competidor HP vendía mas Blades que quien promulgaba el on demand como su principal estrategia para el datacenter corporativo. En conreto y en esas epocas, adquirir tecnología blade era sumamente caro y si el CIO intentaba realizar un calculo de retorno de inversión, este prácticamente era viable si el cajón de blades estaba lleno, caso contrario seguía siendo una buena opción comprar equipos slim rackeables.

En principios del 2004 un pequeño vmware pero con aires de grandeza, se empieza a ver instalado en los servidores de IBM, HP y DELL. Ese pequeño tardará poco tiempo en volverse el eje central de todo datacenter de mediano y gran tamaño.

Y volvemos a los blades, que eran caros, pero el paso del tiempo, la maduración de la tecnología y  el cambio de las reglas de juego lo volvieron mucho más atractivo, un chasis de blades básico puede estar USD 1500 e incluso depende el volumen hasta pueden regalarlo, lo cual cambia enormemente las reglas de juego.

El retorno de inversion en los blades ya se ve a partir de 5 hojas o cuchillas, entonces, equipar el datacenter con blades es una buena opción?, sin lugar a dudas si, pero no para todos los casos.

La principal excusa de porque no virtualizar el Datacenter con Blades

Hace 2 años atrás dos especialistas de un carrier  internacional cuestionaban el uso de blades por la falta de escalabilidad en networking, a lo que contesté, – sin lugar a dudas todo depende de como se diseñen y como se calcule la demanda de del servicio que se da – , la realidad también es que ese carrier tenía un acuerdo corporativo con un vendor que no se jactaba de tener blades dignos para el mercado, también es por ese motivo que ellos no podían elegir blades dado que el único vendor al que podían comprarle realmente no los satisfacía y con justa razón.

Entrando en detalle, la realidad es que lo que ellos decían estaba bien, la vieja generación de blades daba poca escalabilidad en términos de networking, y los vendors lo detectaron rápidamente, solo por citar un ejemplo HP por medio de su virtual connect y Flex 10 están permitiendo escalar hasta 32 placas de red en una sola hoja de blade, entonces la respuesta hacia a aquellos especialistas se ha modificado notablemente, hoy no tenemos excusas, los blades son la solución.

Empezando de Cero, como pensar la solución con blades.

Listemos los 9 aspectos fundamentales en una solución de virtualización:

IBM Blade Center

1. Proposito
2. CPU
3. Memoria
4. Red
5. Disco
6. Energización
7. Dinero 

1 – PROPOSITO – Para que utilizaremos la tecnología de virtualización? es para Servicios de Datacenter de un ISP, es para servicios propios ?, es para VDI (virtualización de Desktops) ?. Definir cual es el propósito marcará un punto importante en la definición del SLA, costos de la solución y en el diseño de la arquitectura de Networking. Pensemos que el manejo de vlans en vmware es muy completo y puede ser un punto importante a considerar, más aun para los ISP

2- CPU – La tecnología de cpu es vital, pensando que queremos dar una densidad elevada de maquinas virtuales por CPU, tenemos que considerar. Hoy podríamos citar que por experiencia en distintos ambientes de gran magnitud, los INTEL NEHALEM entregan una razon de 8 maquinas virtuales de carga baja por CORE. EL numero es elevado, o sea una buena noticia para nuestro ROI. Entonces si consideramos poner 2 Procesadores HEXA CORE, hablamos de 12 CORES, lo que hace a un total de 96 maquinas virtuales. Ojo, no todo es Alicia en el país de las maravillas, estos son valores teóricos pero muy cercanos a la realidad.  De llegar a lograr esa densidad van a tener que tener muy ajustados otros parámetros más allá de la CPU. También tengan en cuenta variables como el FSB, la caché de los procesadores elegidos, etc.

3. MEMORIA – Hoy las tecnologías de Blade están permitiendo valores superiores de 128 GB de RAM, claro, estos pueden costar más que un departamento   pero eso no viene al caso,  lo importante es que si buscamos darle la máxima densidad de Virtual Machines por Hoja,  hoy están soportando un valor considerable. ESX hoy admite hasta 1 TB de Memoria dado que ya vSphere 4 corre sobre una arquitectura de 64 bits nativa.

Las maquinas virtuales, consumen en promedio entre 1 a 2 GB de memoria Ram, haciendo uso de memory overcommit en VMware podemos reducir ese valor hasta casi un 50 %, con lo cual seguimos sumando puntos a favor para llegar a convertir el ROI en algo más que aceptable. En general las soluciones de blade de alta densidad están haciendo uso de hasta 96 GB de ram dado el alto costo que implica seguir sumando memoria, dado que en ese caso resulta más barato y performante agregar otra hoja con menos memoria que seguir subiendo en memoria el blade anterior.

3. RED – Diseñar el ambiente de red puede ser muy sencillo o extremadamente complejo. Todo depende que se quiere hacer. Básicamente si diseñaramos una solucion basada en VMware, se podría decir que a nivel networking tendríamos que tener al menos 2 placas para el Port Group de service console, 2 placas para VMkernel donde estará VMotion y Fault tolerance, al menos 2 placas para Payload o carga de VMs, y si usáramos ISCSI, recomendaría otras dos placas más. Si uno toma este ambiente, puede llegar a requerir desde mínimo 6 placas pasando por 8 o más en el caso ideal.  hoy en día una solución promedio de blades contempla el uso de al menos dos switches en la parte trasera del chasis, generalmente la cantidad de switches que están conectados en la parte posterior le agrega mayor cantidad de placas de red a cada hoja (ej: con dos switches se pueden tener 4 placas de red en cada hoja de blade), dependiendo la tecnología usada por el fabricante se puede escalar a numeros mayores.

Generalmente los switches traseros se interconectan entre sí brindando a nivel horizontal y por un uplink a nivel vertical, lo que ofrece alta disponibilidad a nivel de red. También se suelen linkear entre chasis de blades, evitando que el trafico salga al core ( exceptuando el trafico que requiere ser ruteado).

4. DISCO – En términos de disco, no hay grandes secretos, si o si la recomendación es salir a una SAN o una red ISCSI. Particularmente soy un optimista respecto del ISCSI, me parece muy performante, poco costoso y muy confiable (ver soluciones como lefthand, falconstor,openfiler) aunque la mayoría de redes que llevo instaladas son sobre FC.

Es un requerimiento para tener HA, FT y VMotion tener un storage compartido y la verdad es que para Blades, tenerlo afuera es mejor. El unico storage recomendado son apenas dos discos sata para raid 1 donde instalar – por ejemplo – el ESX.

5.ENERGIZACION – El aspecto de consumo es vital. Las soluciones de blades de baja gamma no requieren mas de 10 A, pero en otros casos requieren hasta trifasica. Muchos datacenters están al limite de consumo energético, y conectar un chasis de blades los lleva casi a pasar ese limite. Más aun cuando el proceso de migración de todos los servidores físicos puede durar unos meses. Las soluciones de blades tiene la característica de tener rendundancia en todas sus fuentes y fans, de manera de que ninguna falla de power impida del normal funcionamiento del chasis. Existen soluciones que compensan las fallas de hardware, por ejemplo si una turbina de refrigeración falla, el resto aumenta automáticamente la velocidad para compensar la falta de una de ellas.

6.DINERO – Frente a presupuestos ajustados, optar por blades no siempre será la mejor opción, dado que requiere de acompañar toda la solución de una SAN y probablemente si se necesitan menos de 5 servidores, la solución puede que nos quede algo grande.

Sin embargo, utilizar blades cuando se requiere reducir espacio, bajar el consumo energético, consolidar y virtualizar, esta es hoy en día la mejor opción. Tengamos en cuenta que en un rack de blades con 12 hojas, mas storage, podemos estar colocando casi 600 maquinas virtuales. Imaginen el espacio y consumo que estas tendrían si fueran fisicas? o que costo de mantenimiento de hw tendrían?. En ese caso, la cuenta cierra, y les aseguro que con un ROI de 2 años.

Conclución

No quedan dudas que la tecnología de blades está madura, incluso que supera enormemente en escalabilidad a muchas soluciones tipo rackeables. También quedó demostrado que bajo un diseño adecuado, no hay limitantes en términos de networking, storage , memoria y procesador. Incluso también aprendimos que superando cierta cantidad de equipos, la reducción de costos es verdaderamente tangible.

Todo esto nos pemite pensar que hoy en día el Blade ya es la plataforma elegida para la mayoría de empresas que optan por virtualizar y consolidar, sabiendo que es posible escalará aun más, siempre asegurando la disponibilidad y performance.

Yo por mi parte no lo dudo, hoy elijo virtualizar sobre blades.

Saludos,

Ing. Diego Quintana

Bueno, esta idea de explicar qué es un Virtual Appliance (VA a partir de ahora), surgió luego de la nota emitida por Nicolás Solop: Qué es una Máquina Virtual?.

Un VA es muy similar y sencillo de entender:

Se trata de una Máquina Virtual (VM a partir de ahora) que se encuentra alojada en algún sitio de internet, con un formato comprimido llamado OVF (Open Virtualization Format).

En general se trata de VMs creadas con un Sistema Operativo (SO), una ó varias Aplicaciones, y configuradas para cumplir determinado fin, por ejemplo:

- NAS Servers virtuales.

- Routers y Firewalls.

- Monitoreo de Infraestructura tecnológica.

Dónde están?

Estos VA son muy fáciles de encontrar y de elegir, ya que están muy bien organizados en el Virtual Appliance Marketplace de VMWare.

En el VA Marketplace se puede ver las VA ordenadas por categorías, vendor, etc.

Cómo se ponen en Producción?

Bueno, según cada Fabricante…

Los pasos comunes para obtenerla son:

	Encontrar la VA deseada y revisar release note para comprobar la compatibilidad con nuestra infraestructura y Hardware si es necesario.
	Descargar el archivo ZIP ó RAR (según vendor), el cual contiene los archivos OVF y VMDK.
	Una vez descargado, descomprimirlo, conectarse con vSphere Client al Virtual Center. Click en File, y luego en “Deploy OVF Template”.  Buscar el ZIP descargado, ó colocar URL donde se encuentre el VA.
	En el caso de Browse, buscar el archivo OVF, y clikc en Deploy. Los archivos que se verán son VMDK y OVF. OVF sólo 1, y VMDK según la cantidad de discos que tenga el VA. Luego seguir los pasos de Importación tal como pide.

Luego de finalizado el Deploy del VA, ya tendremos una VM en funcionamiento.

Al encenderla, en general, deberíamos seguir los pasos de Configuración final tales como Networking, Sincronización de fecha y hora, etc.

Recuerden que cada VA puede variar en cuanto a la forma de descarga, y la forma de Configuración final.  Leer atentamente Release note e Installation Guide.

Saludos!

Hoy les muestro una configuración muy importante, que a la vez puede pasar desapercibida, trayendo confusiones, mal entendidos, y hasta algún dolor de cabeza.  La doy a conocer para que ese potencial dolor de cabeza, pase a ser un alivio y una posibilidad más de controlar las conexiones a través de VMWare View.

VMWare View, más puntualmente la Consola de Administración, tiene una configuración de Time Out, que por defecto, viene configurada en 600 minutos (10 horas).  Esta característica sirve para dar un límite de tiempo de conexión a un equipo.

Puede utilizarse para liberar conexiones disponibles, para limitar el tiempo de uso de los recursos de la compañia, y cualquier otro tipo de fin.

Esa configuración puede ser modificada sin necesidad de reiniciar ningún tipo de servicio.

Dónde está esa configuración?

1- Ingresar a la consola del View Manager, y click en el Botón CONFIGURATION:

2- Luego Click en Global Settings, prestar atención a la línea de “Session TimeOut”

3- Click en el link “Edit” y modificar el valor en minutos.

Una vez que estos cambios fueron aplicados, las terminales deberán reconectarse para que tomen la política. 

Espero les sirva!

Saludos…

Patricio

Luego de 18 meses de investigación y desarrollo conjunto entre ingenieros de VMware y de Mitel lograron derribar la barrera de la latencia producida por la virtualización entregando de esta forma la primer solución de virtualización de voz del mercado.

La combinación de la virtualización junto con los productos de Mitel como el Mitel Communications Director permite a las empresas que cuenten con sus centros de datos virtualizados hacer uso de las nuevas versiones de producto de Mitel en forma virtual reduciendo consumo eléctrico espacio y tareas de administración.

El desarrollo de ambas empresas tiene como objetivo permitir a sus clientes la consolidación de aplicaciones de voz junto con aplicaciones estándar en una misma plataforma esperando como resultado mejoras en la productividad, una utilización de los recursos eficiente y la disponibilidad de las tecnologías de voz incluso en casos de contingencia.

El problema de la virtualización de la voz

El desarrollo para aplicaciones estándar (no de tiempo real) siguió su propio curso con el correr de los tiempos pero al intentar virtualizar aplicaciones en tiempo real como la voz es extremadamente complejo debido a la latencia inyectada por la capa de virtualización.

La plataforma de virtualización soportada para correr las soluciones de voz de Mitel al día de hoy es VMware vSphere ESX 4.

Sobre Mitel: Mitel es líder en la provisión de soluciones de comunicación unificada para organizaciones de todos los tamaños.

Más información en el comunicado de prensa: Mitel and VMware Announce First Customers to Leverage Voice Virtualization

 
Nicolás Solop