Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

Hace unos meses escribí un post hablando de la conexión de un ESX a un switch físico con Cisco IOS.

Opsss… ¡¡hace más de un año que lo escribí!! Menos mal que sigue siendo válido…

Ahora ha llegado el momento de agarrar un servidor ESXi y conectarlo a un switch físico con Cisco NX-OS. Cisco NX-OS es la evolución de Cisco IOS adaptado a las necesidades del Datacenter. Concretamente, para el ejemplo, vamos a utilizar un Cisco Nexus de la familia 5000.

Pero antes, definiré el concepto BPDU para evitar que nadie se quede por el camino:

Bridge Protocol Data Units (BPDUs) son paquetes de red que contienen información del protocolo spanning tree (STP). Los switches mandan BPDUs usando la dirección MAC del switch como origen y la dirección MAC multicast 01:80:C2:00:00:00 como MAC destino.

Existen tres tipos de BPDUs: De configuración de la topología, de notificación de cambio topológico y de confirmación de notificación del cambio topológico. Por defecto se envían cada 2 segundos.

Volviendo al Cisco Nexus 5000, la configuración de cada puerto del switch físico donde se conecta una vmnic podría ser algo así:

router(config)# interface Ethernet 1/12

router(config-if)# switchport

Configura el puerto como un interfaz L2

router(config-if)# switchport mode trunk

Configura el puerto como trunk IEEE 802.1q

router(config-if)# switch trunk allowed vlan 11-14

Define las VLANs que permitimos pasar por este puerto de trunk

router(config-if)# spanning-tree port type edge trunk

Es un puerto que no emite BPDUs de spanning-tree y no participa en el cálculo de la topología de STP, ha de ser así, el servidor ESXi no sabe lo que es una BPDU de spanning tree

router(config-if)# spanning-tree bpduguard enable

Si recibimos BPDUs bloquea el puerto, de un ESXi no vendrán BPDUs, evitamos de esta manera que se conecte otro switch a este puerto

router(config-if)#

Aunque esta configuración es correcta, no es la habitual. Para evitar repetir esta configuración en cada puerto que tenga la misma configuración creamos un port-profile e incluimos en él los comandos comunes. Luego, asignamos puertos al port-profile, aplicándoles los comandos al interfaz. Facilita mucho el cambio de configuraciones.

router(config)# port-profile GRUPO1

router(config-ppm)# switchport

router(config-ppm)# switchport mode trunk

router(config-ppm)# switch trunk allowed vlan 11-14

router(config-ppm)# spanning-tree port type edge trunk

router(config-ppm)# spanning-tree bpduguard enable

router(config-ppm)# state enabled

router(config-ppm)# exit

router(config)# interface Ethernet 1/12

router(config-if)# inherit port-profile GRUPO1

Aplicamos los comandos del port-profile a este interface

router(config-if)# exit

router(config)# exit

¿Se pueden construir grandes infraestructuras de cloud sin switches diseñados para datacenter? ¿Qué opináis?

¿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 Florián Murillo y aquí estoy, como cada viernes.

Si queréis formaros en vSphere 5 o actualizaros a esta versión, os pueden surgir dudas o cuestiones tales como: ¿qué cursos tengo a mi disposición? ¿cuáles están dirigidos a mi?  Vamos a clarificar este tema.

vSphere 5 Installation, Configuration & Management (ICM) – Con una duración de 5 días, es el curso estrella de vSphere 5. En parte porque es necesario su asistencia para obtener el VCP5 (si no somos VCP4) y en parte porque pasa por todos los aspectos de vSphere dándonos una visión completa del alcance de la tecnología.

El mayor inconveniente de esta tecnología es que cada versión crece en funcionalidades y sofisticación. A veces tenemos la sensación de quedarnos cortos con este curso. Pero, pensemos que dura lo mismo que el antiguo vSphere 4 ICM. Cada minuto que estamos hablando de novedades dejamos de hablar de funcionalidades que ya existían. No descarto que salga un vSphere 5 ICM avanzado que complete la formación del actual.

vSphere 5 Fast Track – Este intenso curso de 5 días es para personas que quieren presentarse a la certificación VCP5 y que ya tengan experiencia en vSphere. Para obtener la certificación se puede hacer el vSphere 5 ICM o este curso. En este curso se realizan más laboratorios y se explica más teoría que en el vSPhere 5 ICM. Los días son mas largos y las horas mas intensas. Sin experiencia previa, puede resultar agotador. De hecho, los alumnos con mucha experiencia lo disfrutan más que el vSphere 5 ICM.

vSphere 5 What’s New – Este curso de 2 días está pensado para actualizar a personas que ya tienen sobrada experiencia en vSphere 4 o que ya son VCP4. Sólo se habla de novedades. Los VCP4 que quieran pasar a VCP5 tras el 29 de febrero deberán realizar este curso. Antes de esta fecha no necesitan curso previo.

vSphere 5 Design Workshop – Es un curso de 3 días orientado a Consultores, Preventas Técnicos y a todo aquel que tenga que preparar un Documento de Diseño. Es básico para implantar un proyecto de virtualización.

La primera parte de este curso describe una metodología de trabajo y nos familiarizamos con las plantillas que nos proporciona VMware. La segunda parte del curso son debates permanentes sobre cuestiones de diseño, revisión de las Best Practices del fabricante y su aplicación sobre escenarios de entrenamiento.

Mi opinión personal es que este curso gusta mucho. El alumno se lleva una metodología de diseño y plantillas de los diferentes documentos requeridos en un proyecto, evitando empezar un proyecto con una hoja en blanco.  Da orden a nuestro proyecto y nos ayuda a no dejarnos nada.

Es recomendable haber tomado previamente un vSphere 5 ICM para tener asimilados los conceptos. Se enseña, por ejemplo, a implantar vSphere HA en un caso concreto, pero no se explica como funciona vSphere HA.

¿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 Florián Murillo y aquí estoy, como cada viernes. Hoy toca hacer incómodas reflexiones acerca de la dependencia que tienen los negocios con las tecnologías de la información. También reflexionaré acerca del nivel de servicio que el negocio necesita y el que “compra”.

Están lejos los días en los que analizábamos la exótica tecnología de virtualización para decidir si mejoraba nuestro negocio o era una moda pasajera. Ahora nadie duda de que estamos más de paso que la virtualización y su impacto en los negocios y en el mundo.

La virtualización está en los cimientos de los grandes cambios producidos en los últimos años en los modelos de relación con las TIC e incluso en los cambios sociales. ¿Serían Google, Facebook, Twitter o Amazon quiénes son hoy sin la virtualización? Seguro que no, son los hijos predilectos del “binary translation”.

Estos cambios impactan en todos los aspectos de la sociedad, los negocios y la fuerte interacción que existe entre ellos. Un ejemplo: ¿somos capaces de estar 24 horas sin correo electrónico?

Recuerdo un pequeño proyecto de virtualización que se realizaba un viernes por la tarde y su fin de semana correspondiente. Se anunció durante días a los trabajadores/usuarios para facilitarles su planificación – Por cierto, ¿por qué si utilizan un ordenador son usuarios y si utilizan una fresadora son trabajadores? –
Y, tras esperar el fin de la jornada laboral del viernes, cuando al fin pensábamos que todos los usuarios se habían ido a descansar de su duro trabajo, se pararon los sistemas. Por fin, el servidor de correo pasaba a mejor vida (máquina virtual). Cual fue nuestra sorpresa cuando se abrió la puerta del datacenter y apareció angustiado un presunto ejecutivo que necesita enviar un email, para salvar al mundo… al menos eso parecía por la expresión de su cara y el tono de voz…

Fue imposible decir que no, no sabíamos quien era y estaba fuera de si para preguntarle nada, por tanto, la prudencia prevaleció. El proyecto de migración se paró durante mas de una hora: arrancar, redactar, enviar el correo salvador, volver a parar… todo ello para que este usuario salvara al mundo.

Nos sentimos orgullosos de participar en este acto heroico… ¿qué hubiera sido del mundo si, en nuestros avisos repetitivos, nos hubiera hecho caso y se hubiera ido a casa dejando al mundo a su suerte? ¿sobreviviríamos a la hecatombe? ¿o lo pasaríamos peor que los protagonistas de “Walking Dead”? No me lo hubiera perdonado nunca…

Recuerdo otra anécdota del 2011 en el que Office 365 cayó. Estaba con un cliente que lo estaba probando y le dije: “¿Seguro que has contratado Office 365 u Office 364?” La broma hizo reír a algunos detractores de la solución… Pero, a los que estaban a favor no les hizo ninguna gracia (ojo con las bromas). El caso es que en ese momento nadie contesto a mi siguiente pregunta: “¿Qué nivel de servicio tiene la solución que estáis probando?” Y eso si fue preocupante y para nada es culpa de Office 365.

Está claro que no podemos pasar 24 horas sin un servicio tan básico como el respirar o el correo electrónico. Pero siempre me ha fascinado la contradicción del ser humano. Es decir, la diferencia entre la disponibilidad que EXIGIMOS para sobrevivir como empresa y sociedad civilizada por un lado y, por otro, la disponibilidad que ESPERAMOS con el presupuesto que hay… ¡¡para el mismo servicio!!! O nos engañamos a nosotros mismos como niños o pensamos que Gandalf trabaja para nosotros.

Y todo esto, ¿dónde nos lleva?

Si externalizamos servicios en la nube, que me parece una solución excelente cuando se hace bien, hemos de asegurarnos qué es lo que estamos comprando. Es decir: ¿cuál es el nivel de disponibilidad que vamos a contratar?” La nube no se parará una hora para que salvemos al mundo, ni nos va a dar una disponibilidad del 100% a mitad de precio, ni se pondrá Gandalf al teléfono para transformar en medallas nuestras promesas a nuestro jefe.

A Winston Churchill se le atribuye la célebre frase “Cada pueblo tiene los gobernantes que se merece”. Si extrapolamos esta famosa cita con los servicios en la nube podríamos decir que: “cada empresa tiene los servicios que se merece”. Por tanto cuida mucho lo que contratas, porque dice mucho de ti.

¿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 Florián Murillo y aquí estoy, como cada viernes. Antes de nada quiero desearos un feliz inicio de año 2012 y que lo acabéis mejor que lo empezáis.

Alguna vez te has preguntado: ¿Cuanto dura un vMotion en una VM de 255GB de memoria asignada? es decir el límite de memoria de una VM en un host ESX/ESXi v.4 con hardware v.7 en la placa base de la máquina virtual. Pues con vSphere 5 aparecen VMs de hasta 1GB de RAM, anunciando migraciones de larga duración para máquinas virtuales de gran formato.

vSphere 5 trae una funcionalidad que no aparece entre las mas importantes pero que es muy bien recibida en entornos con grandes máquinas virtuales. Me refiero a la posibilidad de hacer vMotion utilizando varios interfaces de red SIMULTANEAMENTE.

En EMC han realizado un análisis de carga interesante, han comparado un vMotion con diferentes escenarios, con 1 NIC, con 2NICs y con 4 NICs.

La máquina virtual de test no está nada mal, un SQL Server con 60 GB de memoria, mas de 2TB de datos y 10.000 IOPS. Es decir una máquina virtual con alta actividad y tamaño medio/alto.

Los resultados (redondeados a minutos) han sido los siguientes:

• vMotion con 1 puerto de vmKernel: 23 minutos.
• vMotion con 2 puertos de vmKernel: 8 minutos.
• vMotion con 4 puerto de vmKernel: 3 minutos

Para evitar dudas os diré que las pruebas se han hecho con todos los interfaces a 1Gbps y con una MTU de 9000 bytes, o como la conocemos coloquialmente con Jumbo Frame activado en todos los puertos de vmKernel.

¿Cuál es la conclusión?

En todo diseño con máquinas virtuales de tamaño medio o grande, hemos de tener en cuenta el tamaño de las maquinas mas grandes para atender sus necesidades de conectividad y sus necesidades de movilidad, o sea vMotion. La eficiencia obtenida es tan alta con vMotion multi-NIC que merece la pena invertir un poco en interfaces de red.

Con máquinas de gran tamaño ¿Os podéis permitir tardar mas de una hora en poner un host en mantenimiento? o bien que DRS tarde este tiempo en mejorar el balanceo de un cluster ¿impensable verdad?

¿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 Florián Murillo y aquí estoy, como cada viernes. Llega fin de año y es momento de hacer un resumen, esta semana le toca a las tecnologías de virtualización de servidores, hablaremos de lideres, zombis, despistados y otra hierbas.

Para tener un criterio único he cogido el Cuadrante Mágico de Gartner del 2010 y del 2011 y los he comparado, las conclusiones con interesantes:

Si observamos a VMware, no ha cambiado mucho pero hay datos interesantes:

1. Oracle ha madurado su porfolio de soluciones y en el 2012 pasará examen, veremos si su apuesta basada en la pila de soluciones Oracle juega a su favor o en contra. El mercado tendrá la última palabra.

2. Microsoft ha hecho los deberes este año, Live Migration, Gestión dinámica de memoria y Azure le han llevado al cuadrante de lideres.

3. Citrix tiene un crecimiento fuerte basado en la calidad de XenDesktop y su apuesta clara hacia el cloud computing.

4. La adquisición de Novell por Attachmate Group ha diluido su presencia en el mundo de la virtualización ¿Es el principio del fin para Novell?

¿Que pasará en el 2012? Veremos una doble batalla, tanto en el terreno de la virtualización como en cloud computing.

El primer enfrentamiento será entre vSphere 5 y Windows 8 Server Hyper-V. Donde VMware ha de hacer tanto esfuerzo en mantener la distancia como Microsoft en convencer a los clientes de la madurez de su tecnología.

En el terreno de cloud computing no se olviden de Citrix, que con la reciente adquisición de cloud.com puede haber encontrado un atajo frente a sus competidores. Será interesante ver el desarrollo de su modelo cloud.

Será un año apasionante, pero mantengo una duda desde hace años … ¿Por qué es Mágico este Cuadrante? ¿Lo hace Gandalf?

Aprovecho para desearos Felices Fiestas, agradeceros el seguirnos en el blog continuamente y confiar en que tengáis un feliz entorno virtual y familiar

¿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 y aquí estoy, como cada viernes.

Hace mas de dos años que me compré un MacBook, volví a mis orígenes ¿fruto de la edad? ¿fruto de una pasión oculta? ¿por qué es bonito? ¿fruto de la lógica? no lo se, me lo pedía el cuerpo, mi primer computador personal fue un Apple IIe, hace muuuuchos años.

El caso es que dos años después,  lo sigo utilizando felizmente. Me acompaña en mis cursos como Instructor Oficial de VMware (VCI) y en las consultorías y proyectos en los que participo. Aquí acaba mi pequeño tributo a Steve Jobs, he compartido en la distancia sus triunfos y sus fracasos, pero sobretodo compartimos la idea de que “la velocidad de rotación del mundo la decidimos nosotros con nuestros actos”.

Apple no ha aportado mucho al mundo de la virtualización, pero gracias a VMware dispongo de VMware Fusion, el equivalente a VMware Workstation para la plataforma Mac, me permite disfrutar de virtualización con mi ordenador favorito.

Llegó el día que necesité hacer unos scripts en Perl utilizando el vSphere SDK for Perl, rápidamente decidí que el camino era la vMA, una auténtica joya de VMware que debería ser mas utilizada.

La vMA es una virtual appliance que debemos descargar de la zona de descargas de VMware. Para transformar la virtual appliance en una VM para VMware Fusion utilicé ovftool, una utilidad en modo comando que convierte la virtual appliance en una VM ejecutable.

La utilidad ovftool también se descarga del download de VMware, está disponible para Windows, Linux y Mac.

Tras descompactar el archivo descargado, nos aparece un paquete instalable en Mac. Una vez instalada, desde una sesión de terminal, ejecutamos:

# ovftool /path/vMA-5.0.0.0-472630_OVF10.ovf /path/vma5.vmx

Como vemos ovftool tiene dos parámetros, el primero es la virtual appliance a convertir (formato .ovf) y el segundo es el destino y nombre de la VM (acompañado de .vmx).

A partir de este momento tenemos una VM ejecutable en VMware Fusion. ¿Qué os parece ovftool?

¿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 y aquí estoy, como cada viernes. La semana pasada empezamos a construir la lista Top 10 de las cuestiones clave respecto mi proveedor cloud, esta semana toca completar la lista:

6. ¿Qué posibilidades de recuperación tengo con el almacenamiento en la nube?

He de revisar el diseño de mis estrategias de respaldo y recuperación, averiguar si son aplicables en los servidores virtuales ubicados en el cloud. Si extraigo de la nube los respaldos, he de analizar el impacto económico que puede tener la transferencia de datos, ya que probablemente nos cobren el ancho de banda por transferencia.

7. ¿Qué posibilidades tengo de exportación de mi información alojada en una solución SaaS?

Antes de añadir el primer dato en una base de datos en la nube, he de saber las posibilidades que tengo de exportación (y recuperación) de esta información. Esto puede hacernos huir de algunas aplicaciones SaaS.

8. ¿Puedo auditar el entorno donde se ejecutan mis datos, aplicaciones o VMs en la nube?

Auditar infraestructuras en la nube suele ser mas caro que en nuestro Data Center, hemos de adaptar nuestros procesos de operaciones al nuevo entorno, la logística es mas compleja por tener que coordinar a ms personas y seguramente hay gastos extra en desplazamientos y estancias.

9. ¿En que idiomas da soporte el proveedor cloud?

Aunque el ingles es un idioma “casi” global, cuando tenemos un problema, el idioma local del cliente hace acortar por tiempos de resolución de la incidencia, o sea, menor impacto económico sobre el negocio, es un elemento a considerar.

10. ¿Quién hay detrás del proveedor?

Es difícil saber si un proveedor vivirá mucho tiempo, ahora estamos en época emergente pero cuando el negocio se estabilice, por un céntimo/hora un proveedor puede perder clientes y entrar en crisis.

Conocer las empresas que hay detrás del proveedor es un elemento de posible confianza. No tendremos nunca la certeza absoluta de tener un riesgo cero al escoger, pero la confianza es clave en esta elección, recordar que no buscamos un proveedor, buscamos un socio para nuestro negocio. Las capacidades del proveedor pueden hacer que nuestro negocio tenga nuevas capacidades o limitaciones.

Me haréis muy feliz si entre todos mejoramos esta lista con otras importantes preguntas que queráis incluir. Gracias adelantadas.

¿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 y aquí estoy, como cada viernes, para aportar mi granito de arena a la montaña de las TIC actuales.

Estamos en un momento de efervescencia creativa en lo que a servicios cloud se refiere, existen grandes multinacionales con servicios consolidados (o no tanto), empresas locales buscando su hueco, empresas creativas “inventando” soluciones y grandes operadoras reclamando su lugar en la historia.

Esto genera grandes dudas a los clientes ¿Son todos los proveedores iguales? ¿Qué he de buscar en los proveedores? ¿Cómo distinguir los que mejoran mi negocio?

No son preguntas triviales ni existe la formula mágica y general, pero hay preguntas que no podemos dejar de hacer y analizar, por eso propongo un Top10 de las preguntas fundamentales:

1. ¿Cual es el SLA y las indemnizaciones por la perdida de servicio?

Esta es importante y de sorprendente respuesta, nos podemos encontrar un 99,9% mensual de SLA para Amazon S3, o sea 45 minutos de caída “legal”.

Mas curioso es el servicio Amazon EC2, con un SLA de 99,95% anual, es decir más de 4h de caída “legal”.

Lo más divertido es Salesforce.com, no tiene SLA en su precio base, se ha de negociar!!!!, es muy curioso porque cuando tiene perdidas de servicio aparece en todos los periódicos.

Las indemnizaciones son de risa, no nos engañemos, no resuelven económicamente los problemas que generan ¿es una pista de la inversión realizada y los procedimientos existentes del proveedor cloud?.

2. ¿Bajo qué cumplimiento normativo está cubierta mi instancia de VM?

Es muy importante porque cada proveedor de servicio tiene, como vimos en anteriores post, diferentes cumplimientos normativos, hemos de tener proveedores alineados con nuestro negocio, por estrategia de negocio y por necesidades normativas.

3. ¿En que localización estarán mis servidores virtuales y que legislación cumple?

Es necesario conocer la dirección de nuestros datos, sobretodo si tenemos datos de carácter personal, en este caso es obligatorio.

También es importante para poder analizar las reglamentaciones que han de cumplir nuestros datos, recuerda que son las del país donde se alojan, NO las del nuestro.

4. ¿Qué tecnología de hipervisor utiliza?

¿Necesito mover una VM en caliente de mi datacenter a la nube pública? Si esto es así he de asegurar la compatibilidad de la tecnología de hipervisor que proporciona el proveedor a mis máquinas virtuales.

5. ¿Qué posibilidades tengo para integrar mi DC con la nube?

Para que mi nube privada tenga la elasticidad que proporciona la nube pública, necesito integrar la nube pública en mi red, para ello es importante conocer las capacidades de extensión de VLANs y aislamiento con VPN que la nube pública proporciona para ayudar a mejorar mi negocio.

La semana próxima continuaremos con la segunda parte de la lista…

¿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. En los últimos años hemos visto un fenómeno llamado la inversión de la pirámide, hace unos años el 70% de los usuarios estaba en la central de la organización y el 30% estaban en las oficinas remotas, ahora esto a cambiado, el 70% de los usuarios están en sedes remotas y usuarios móviles y el 30% en la sede central.

Además las migraciones de Datacenter Corporativo hacia Proveedores de Servicios hacen que cada vez mas empresas tengan un 100% de usuarios remotos.

Una de las tecnologías aplicadas para resolver el problema de la concentración de aplicaciones es la aceleración WAN.

Los aceleradores de WAN mitigan el problema de las latencias de las comunicaciones remotas, así como la aceleración con cachés, balanceo de servicios, tolerancia a fallos y técnicas de de-duplicación WAN, incluso me atrevería a decir que se utilizó esta técnica antes en aceleración WAN que en almacenamiento.

Veamos una tabla de mejoras:

¿Como podemos atender el cada vez mayor número de usuarios que pretenden conectarse a nuestra red?

La incorporación de la virtualización complican el escenario y supone nuevos retos a este cambio de habito en la entrega de servicios en las empresas.

Nuestro aceleradores de WAN basadas en appliances no están diseñados para entornos multi-tenant que encontramos en grandes compañías y proveedores de servicios. La solución es fácil, pasa por virtualizar también estos equipos.

Esto ha hecho Cisco con el Cisco Virtual WAAS, a partir de ahora vWAAS. Es un Virtual Appliance que acelera el tráfico WAN hacia servicios virtualizados o lo que es lo mismo, un vWAAS por cada entorno aislado o cliente.

Cisco vWAAS necesita la tecnología vPath de Cisco Nexus 1000V y utiliza el protocolo WCCP para hacer su trabajo.

Ya quedan pocas funciones por virtualizar ¿Cuál será la siguiente?

¿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.

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.

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.

Hola amigos, soy Florián Murillo. En el VMworld 2011 de agosto en Las Vegas, Cisco ha anunciado grandes novedades para la infraestructura virtual de VMware.

Me centraré en una de ellas, en el Cisco ASA 1000V cloud firewall,  es un virtual firewall en formato virtual appliance que se integra con Cisco Nexus 1000V, estará disponible en la primera mitad del 2012.

Como es habitual en Cisco (y otros fabricantes) primero llega el marketing y detrás el producto, las características principales del nuevo producto son:

Proporciona cortafuegos perimetral “multi-tenant”, o lo que es lo mismo, se puede utilizar para securizar varios clientes en entornos aislados.

Proporciona VPN site-to-site, las conexiones VPN de clientes remotos, como Cisco AnyConnect no están soportadas en esta primera versión.

Requiere para su funcionamiento, como pre-requisito, de Cisco Nexus 1000V, el switch distribuido de Cisco.

Se gestiona desde el Cisco Virtual Network Managemeng Center (VNMC) compartiendo consola con el Cisco Virtual Security Gateway (otro día hablamos de este producto).

La versión inicial no soportará vCloud Director, pero como Cisco Nexus 1000V está soportado por vCloud Director, no dudo que se soportará en siguientes versiones.

Está soportado desde vSphere 4.1 y se basa en la versión de software Cisco ASA v.8.4

El licenciamiento será por sockets, siguiendo la línea de Cisco Nexus 1000V y Cisco Virtual Security Gateway.

Resumiendo: Es una versión inicial que alegrará a muchos consumidores de tecnología Cisco, aunque con ausencias esperadas, las VPNs de usuarios remotos y la no integración de vCloud Director hacen que denominemos esta versión como “la primera”.

Seguimos esperando el precio final pero, me surge una duda: ¿Puede el mantenimiento y soporte de la versión virtual de un producto ser mas cara que su homónimo del mundo físico?

Lo sabremos en unas semanas

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

Hola amigos, soy Florián Murillo. Con vSphere 5 nos llega la entrada de vCenter Server al mundo Linux.

La llegada de vCenter Server es en formato OVF, lo que simplifica enormemente la instalación.

Descripción del producto:

La máquina virtual desplegada tiene SUSE Enterprise Linux 11 x64 con 2 vCPUs, 8 GB de RAM y dos discos, uno de 15GB y otro de 60GB.

Incluye:
• Base de datos DB2 Express embebida
• ESXi Dump Collector
• Syslog server (utiliza syslog-ng)
• Auto Deploy Server

Es la primera versión, tiene cualidades y carencias, vamos a repasarlas:

No soporta:
• Microsoft SQL Server
• vCenter Server Linked Mode
• vCenter Server Heartbeat
• Linked Clone de VMware View Composer
• vSphere Storage Appliance
• IPv6

Algunas limitaciones son inherentes a plataforma Windows.

Si soporta:
• Oracle como base de datos externa
• Integración con Directorio Activo
• SRM5
• vCloud Director
• Update Manager
• vCenter Operations

Con la base de datos embebida podemos gestionar hasta 5 host y 50 máquinas virtuales, es el mismo dimensionamiento del Microsoft SQL Server Express.

Los consumos de memoria del appliance dependen de los host y las máquinas virtuales a gestionar, como pasa en la versión Windows, los requerimientos de RAM son similares en Windows y en Linux.

Aún siendo un producto de “desplegar, configurar y usar” las tareas de explotación del día a día requerirán conocimientos de Linux, no recomendaría su uso si no hay capacidades Linux en la empresa.

Sus puntos fuertes:
• No hay sobrecostes de licencias de Microsoft.
• Se despliega mucho más rápido, sobretodo si necesitamos syslog, dump collector o autodeploy.
• No hay debate acerca de vCenter Server en máquina física o virtual.

A mi modo de ver, es una gran noticia la llegada de este producto, el limitador mas importante es no soportar Microsoft SQL Server para gestionar mas de 5 hosts. Pero intuyo que veremos evolucionar el producto en sucesivas actualizaciones.

¿Creéis que vCenter Server Appliance se implantará masivamente?

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

Hola amigos, soy Florián Murillo. La semana pasada revisamos los proveedores de servicio cloud con infraestructura vCloud en Europa.

Una de las preocupaciones que nos invaden al hablar de servicios cloud es la seguridad de nuestros servicios y confidencialidad de la información.

Tengo una buena noticia y una mala noticia. La buena es que las limitaciones de presupuesto hacen que, en muchos casos, no podamos tener el nivel de seguridad que necesita nuestro negocio, por tanto, es mas viable auditar que ser auditado, los proveedores cloud pueden ser una alternativa valida.

La mala noticia, por llamarla de alguna manera, es que no todos los proveedores son iguales, hemos de analizar en profundidad los procesos y certificaciones de nuestro proveedor de servicios cloud.

Volviendo a la lista de proveedores EMEA, me pregunto: ¿disponen todos de las mismas certificaciones? Os avanzo la respuesta: NO

Veamos una tabla resumen:

Vamos a definir brevemente cada certificación:

SAS 70 Type I : El Statement on Auditing Standards nº 70 son normas de auditoría de procesos externalizados de la AICPA (American Institute of Certified Public Accountants).

SAS 70 Type II : El Type II es mas riguroso (genera mas confianza) que el Type I, la diferencia está en que en el Type II el auditor realiza (durante 6 meses) variados tests de la eficiencia de las operaciones, se controla y se mide la eficiencia.

HIPPA : La Health Insurance Portability and Accountability Act es una ley estadounidense para garantizar la privacidad, confidencialidad y seguridad de la información manipulada en el sector sanitario.

PCI DSS : La Payment Card Industry Data Security Standard fue creada por un consorcio formado por los fabricantes de tarjetas de crédito ayuda a las empresas que procesan, almacenan o transmiten datos de tarjetas de crédito a asegurar dichos datos.

ISO27001 : Es el estándar internacional para procesos que garanticen la seguridad de la información. Incluye aspectos de prevención, protección activa y trazabilidad del movimiento de la información. Recoge el cumplimiento de la LOPD, me atrevería a decir que es imprescindible si llevamos a la nube datos de carácter personal.

SSAE 16 : El Statement on Standards for Attestation Engagements 16 es la adaptación realizada por el IACPC del estándar ISAE 3402, la misión del SSAE 16 es sustituir a la norma SAS 70 adecuándola al estándar internacional.

ISAE 3000 : La International Standard on Assurance Engagement 3000 permite auditar los informes de Responsabilidad Social Corporativa (RSC) de las empresas, aportando credibilidad a la estrategia de RSC en la empresa, algo cada vez mas importante para accionistas y clientes.

Tras esta tormenta de normas y siglas, la conclusión es que las normas que garantizan la externalización de servicios, la privacidad y seguridad de la información, la eficiencia energética (Green IT) e incluso las que hacen creíbles las estrategias de RSC existen y evolucionan para adaptarse a este mercado cambiante.

También hemos observado que los proveedores europeos de vCloud están avanzando en el cumplimiento de estas normas.

Y por la cara que imagino estáis poniendo, estas normas son poco conocidas, y su difusión ayudaría a dar confianza en servicios cloud.

¿Creéis que las normas ayudan a proporcionar credibilidad y confianza en los servicios cloud?

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