Hola amigos, soy Florián Murillo y me gustaría hacer algunas reflexiones acerca de la “carrera” entre Cisco y Brocade por liderar el “transporte” del futuro.

Cisco es el líder en el transporte por Ethernet y Brocade en el transporte por Fibre Channel, solo hay que ver sus cuotas de mercado, son claramente dominadores en sus ámbitos naturales.

Por otro lado, la virtualización rompe las barreras que existen entre los equipos de especialistas, me refiero a comunicaciones, almacenamiento, seguridad, sistemas y aplicaciones entre otros, demandando al I/O velocidad e elasticidad.

Cisco presentó hace un tiempo ya, su familia Cisco Nexus, switches que integran las redes Ethernet y Fibre Channel, utilizando Ethernet (FCoE) como transporte a 10Gb/s pero evolucionará, con el estandar IEEE P802.3ba hacia 40Gb/s y 100Gb/s en el futuro, con total seguridad.

Por otra parte Brocade acaba de lanzar sus primeras soluciones con soporte de 16Gb/s en Fibre Channel, el chasis Brocade DCX 8510 Backbone y el atractivo Brocade 6510 con 48 puertos 16Gb/s en 1U, no está nada mal. Además de disponer del Brocade VDX 6720, producto que compite en el terreno de FCoE con Cisco Nexus.

Cada uno tiene un caballo ganador, Brocade conoce como nadie Fibre Channel y Cisco domina el atractivo mundo de la unificación de las redes, o como ellos lo llaman “Unified Fabric”.

Para hacer este tema mas divertido, ya se está trabajando en un estandar de Fibre Channel a 32Gb/s.

Mi pregunta es ¿el mercado que pide velocidad o integración?

Fibre Channel a 16Gb/s es una solución que cautivará a los administradores de almacenamiento de grandes sistemas, pero si pienso en arquitecturas cloud con aprovisionamiento dinámico de recursos, opino que FCoE es el ganador, permite aprovechar la virtualización del I/O, cosa que es mas complicado con las HBAs de Fibre Channel.

Por tanto, a mi modo de ver, en el futuro próximo, la capacidad de integración y la elasticidad de FCoE tendrá mas peso que la velocidad.

¿Que opináis amigos? Hasta la semana próxima.

¿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. Los amigos de Cisco Systems, empeñados en liderar el mercado de tecnologías de Data Center, no dejan de aportar soluciones nuevas al mercado, hoy hablaremos de la Cisco UCS P81E Virtual Interface Card, que aporta virtualización a los interfaces de I/O.

Es una tarjeta para los Cisco UCS C-Series, servidores rack, aunque existe versión para los Cisco UCS B-Series, que son los servidores blades de la casa.

Con la tarjeta en la mano, nos encontramos con una PCI 8x con dos interfaces de 10Gb con conector SFP+. El hipervisor lo que ve son, hasta 2 interfaces HBA y hasta 16 interfaces ethernet, por cada placa física (en el futuro 128 interfaces virtuales).

Las tramas Fiber Channel se encapsulan en Ethernet (FCoE) y se transportan en una VLAN, por tanto necesitamos una infraestructura de red Unified Fabric, como lo llama Cisco, este concepto lo escucharemos mucho en los próximos años.

Este tipo de interfaz es ideal para ampliar un cluster con 8-12 interfaces de red, sin hipotecar nuestro futuro invirtiendo en tecnologías de 1Gb, cuando nuestro cuerpo nos pide invertir en 10Gb.

También es muy útil para entornos VDI con muchos segmentos de red, por permite asignar “bandwidth” a las VLANs en vez de interfaces.

Por ahora es compatible con vSphere 4.0 U1, amigos, los tiempos están cambiando …

Hola amigos, soy Florián Murillo y en los cursos de VMware que imparto como VCI detecto que los módulos de networking requieren mas esfuerzos que otros, por eso he pensado que podía ser de utilidad explicar con claridad y brevedad (a ver si lo consigo) como se ha de configurar un switch Cisco Catalyst para conectar sistemas ESX/ESXi.

¿Que nos recomienda VMware?

- Los puertos de los switches donde se conectan los ESX/ESXi se han de configurar con trunk VLAN 802.1q

switchport mode trunk

- Los puertos de los ESX/ESXi no participan de negociación en protocolos como DTP, PAgP o LACP, por tanto desactivar protocolos dinámicos de configuración en los puertos de los switches.

switchport nonegotiate

- Los puertos de los ESX/ESXi no participan en negociaciones de STP (spanning tree protocol) por tanto se ha de desactivar en lor puertos de los switches el envío de BPDUs de STP.

spanning-tree portfast trunk

- En Cisco, la native VLAN es la VLAN por la que circula el tráfico de protocolos de nivel 2, y los que no tiene un tagging de VLAN, por tanto, todos los port-groups han de tener VLAN ID para prevenir que algún tráfico se “cuele” en la native VLAN en vez de “circular” por la VLAN que le toca.

switchport trunk native vlan 99

- Otra cosa a cuidar es que ninguna VLAN tenga el mismo número de VLAN que la native VLAN.

- Todos los puertos de los switches donde se conecta un ESX/ESXi han de permitir, solamente, el paso de las VLANs que se han configurado en la infraestructura virtual.

switchport trunk allowed vlan 10-12, 20

Si vemos la configuración completa del puerto, queda de la siguiente manera:

description PUERTO DE ESX
switchport trunk native vlan 99
switchport trunk allowed vlan 10-12, 20
switchport mode trunk
switchport nonegotiate
spanning-tree portfast trunk

Estoy de acuerdo que esta configuración no engloba todas las posibilidades y diseños, pero en los temas cubiertos se ajusta a las Best Practices de VMware.

Espero que os sea de ayuda.

Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.

Mucho hemos oído hablar de que Cisco quería entrar en el tema de Servidores de la mano de su coalición con VMware. Y aquí están.

Os presento al UCS C200 M1 High Density Rack-mount server. Servidor de 1U con 2 sockets y con 12 slots de memoria, llegando a poder instalar 96 Gb con alta densidad o bien llegar a tasas altas con precios asequibles.

Incorpora 2 Nics de 10 Gb y un nuevo chipset que es capaz de gestionar la memoria para ofrecer más memoria de la que realmente tiene (me han dicho un número de veces que quiero antes validar.)

A ver si me cae uno en demo y os cuento cosas bonitas sobre ellos….. también hemos de ver los precios.

Podéis ver una demo interactiva en este link

Según pública hoy eweek.com magazine, VMware y Cisco podrían estar trabajando sobre la idea de usar la tecnología VMware VMotion para poder mover maquinas virtuales en caliente desde un centro de datos a otro.

Esta nueva funcionalidad seria de especial interés para aquellos centros de datos que ya están virtualizados y quieren disponer de un plan de contingencias en caso de fallo del centro de datos primario.

Según se comenta en el artículo de eweek.com, VMware y Cisco ya han demostrado esta tecnología durante el evento de Cisco Live Show. Sin embargo, fuentes oficiales de VMware han comentado por activa y por pasiva, que esta nueva funcionalidad requiere aun mucho trabajo para que llegue a ser una realidad y pueda desplegarse en los centros de datos.

Si esta funcionalidad de migración de maquinas virtuales en caliente entre centro de datos llega a buen puerto, no podre llegar a imaginar cómo Cisco y VMWare habrán solucionado el problema de las altas latencias en las líneas entre los centros de datos y como habrán solventado el problema del “disk locking” en los volumenes VMFS. Supongo que usaran una tecnología similar a la que se usa hoy con Storage VMotion!.

Haz clic en este link para ver el artículo completo:

http://www.eweek.com/c/a/IT-Infrastructure/Cisco-VMware-Look-to-Move-VMs-Between-Data-Centers-583506/?kc=EWKNLINF07082009STR1

Cisco y VMware han anunciado recientemente que el nuevo switch virtual de Cisco, Cisco Nexus ® 1000V, estará soportado en VMware vSphere 4.

La solución combinada se ha diseñado para ayudar a los clientes a simplificar la virtualización y la gestión de servicios de red para entornos Cloud. Esto significa que a partir del 21 de abril, el Nexus 1000V estará disponible en la lista de precios de VMware pero no estará disponible hasta el 12 de Junio.

El Nexus 1000V es parte del paquete vSphere Enterprise Plus y estará disponible para todos los revendedores y distribuidores de VMware, incluso si estos distribuidores no son Partners de Cisco.

Puedes ver más detalles técnicos del switch virtual de Cisco Nexus 1000v en este link:

http://www.vmware.com/products/cisco-nexus-1000V/index.html

This blog post is part of Zemanta’s “Blogging For a Cause” campaign to raise awareness and funds for worthy causes that bloggers care about.

Cisco® y VMware®  anunciaron ayer un acuerdo OEM ( Original equipment manufacturer) el cual incorporara ingeniería de producto, ventas integradas y estrategias de soporte para la virtualización del centro de datos y la informática unificada.

El anuncio se hizo público ayer por John Chambers, CEO de Cisco,  y otros altos executivos como por ejemplo Paul Otellini, CEO de Intel, Paul Maritz, Presidente y CEO de  VMware, Joe Tucci, CEO de EMC.

“La combinación resultante de la solución de Computación de Sistemas Unificados de Cisco,   con la plataforma de virtualización de VMware,  proporcionará a los clientes una potente y única solución virtualizada así como un sistema informático físico inteligente y unificado”.

Veremos a ver cuántos clientes es capaz de ganar este  nuevo Blade de Cisco sobre los líderes del mercado de sistemas Blade; Dell,HP, IBM.

El Microsoft´s Server Virtualization Validation Program (SVVP), que se anunció por primera vez en noviembre de 2007, y que se inició el pasado mes de junio con la patricipation de Citrix, Sun, Novell y Virtual Iron, ha firmado esta semana dos importantes nuevos miembros.

Cisco ha anunciado su inclusion y ya está incluido en la página web SVVP, y VMware que debiudo a que firmo muy tarde no está en la lista  todavía (aunque Chris Wolf ya habia confirmado la noticia).

Microsoft y VMware han estado trabajando muy bien durante varios meses en la finalización de este acuerdo y apoyo para la inclusión de VMware en el SVVP, hecho que evidentemente empujara mas hacia la unidad de la tecnologia de la virtualización asi como su adopción en  próximos meses y años.

Los costos asociados en la participacion del programa incluirá la pertenencia a TSAnet a nivel de misión crítica, para que los vendedores y Microsoft puedan compartir información de soporte, los costos incrementales para realizar las pruebas de validación, y un gasto nominal (en la actualidad $250) para calificar cada Configuración que se presente para su validación.

KVM es la plataforma de virtualización más joven de en entrar en escena, pero la posición estratégica que ocupaba hasta el momento ha batido a cualquier competidor.

En primer lugar, se incluyó en el núcleo de Linux después de sólo seis meses a partir de la puesta en marcha, y, por tanto, hoy cualquier distribución con el kernel 2.6.20 o superior puede ofrecer esta solución out-of-the-box.

Luego KVM fue elegido para una de las distribuciones de consumidores más populares en lugar de Xen: Ubuntu.

Y ahora, Cisco incluye en el nuevo IOS-XE, la potencia del sistema operativo Linux para su gama más alta de router: el ASR 1000.

El aggregation Services Router (ASR) 1000 es el primer router de Cisco, que sustituye a su tradicional desarrollo tradicional de IOS con Linux. Entre las características exclusivas que ofrece este nuevo equipo es el sistema operativo en modo redundancia, que se consigue sin ningún tipo de módulo de hardware: el primero en la industria de redes.

¿Y como es capaz Cisco de ofrecer una imagen IOS redundante? A través de las máquinas virtuales de KVM como apuntan los informes de Information Week.

En este momento aún se desconoce la versión del kernel de Linux que se utilizara para IOS-XE, asi como la versión de KVM, pero la empresa debe estar absolutamente segura de su fiabilidad de uso de tal producto en entornos Enterprise.

Es interesante el hecho de que Cisco haya elegido KVM para esta entorno, mientras que está muy ocupado con VMware, invirtiendo en este.

Después de Intel, Ciscol también quiere un pedazo de VMware.

Extraído del el anuncio oficial de VMware: