Saltar al contenido

Cisco y el extraño caso de la señal de reloj

Hace unos días el mundo IT (en su parte de sistemas, porque la verdad no he percibido que los desarrolladores estén muy preocupados por este tema 😉 ) se sobresaltaba con un comunicado de Cisco (podéis leerlo aquí), donde reconocía que determinados equipos de gran popularidad (ASA, algunos Nexus…) estaban afectados por un problema en la señal de reloj, que podía derivar a la indisponibilidad de los sistemas.

 

 

El problema afectaba a equipos con fecha de fabricación anterior al  16 de Noviembre de 2016 y Cisco ofrecía a aquellos clientes con garantía la sustitución de los equipos. Quedando fuera aquellos clientes que no contasen con soporte, lo cual teniendo en cuenta que estos equipos se venden por defecto con un único año de garantía podía poner en apuros a aquellos clientes que por algún motivo no hubiesen renovado.

 

Lo realmente grave del asunto (aparte de la respuesta adecuada o no de Cisco) es que el fallo se localiza en los chips AtomC2000 de Intel (que esta evitando pronunciarse) que equipan numerosas marcas.

 

Los chips afectados serían los C2308, C2338, C2350, C2358, C2508, C2518, C2530, C2538, C2550, C2558, C2718, C2730, C2738, C2750, y C2758.

 

 

vExpert 2017

En el día de ayer se hacía publica la lista de galardonados en 2017 con el vEXPERT de Vmware y he tenido el honor de repetir en ella un año más.

 

 

He de decir que es un galardón que me hace especial ilusión por lo que supone en cuanto a reconocimiento del trabajo realizado en la comunidad, además se trata de una renovación, lo que implica que seguimos en la brecha y que el trabajo realizado compartiendo conocimiento y experiencias deja sus frutos.

Muchas gracias a todos los que habéis hecho posible esta renovación y espero seguir contando con vuestras visitas, comentarios, retwiteos, críticas, etc.

Podéis consultar la lista completa de vEXPERTS aquí

Gracias  !!

Crear un USB de VMware ESXi6.5

Utilizar un USB para arrancar nuestro VMware es una de esas cosas que tenemos que hacer habitualmente y aunque no es una labor complicada, aquí os dejo una pequeña guía de como hacerlo.

Paso 1: obviamente descargar la imagen iso que queramos “flasear” en nuestro usb

Paso 2: Descargar una utilidad para grabar la iso, yo por ejemplo uso Rufus, que puedes descargar de aquí.

Rufus

 

Paso 3: creamos nuestro CD siguiendo los pasos de las imágenes siguientes:

 

Rufus_Esxi1

como podéis ver, seleccionamos Fat32 como sistema de archivos, y tamaño de cluster por defecto. Pulsamos sobre el icono señalado con la flecha para seleccionar la iso y clickamos sobre empezar

Rufus_Selección ISO

 

y voila!!!, ya tenemos nuestro usb listo para usar

OpenStack Newton for Dummies – Introducción – Newton Networking for Dummies (II)

OpenStack Newton Networking for Dummies – Introducción – Decisiones de Networking (II)

Como pudimos ver en la primera entrega OpenStack está formado para varias componentes que interactúan entre si para ofrecer el resultado final de IaaS y lógicamente esto no sería posible sin la correcta gestión del networking.

Las consideraciones acerca del networking en una plataforma cloud tan potente (y compleja) como OpenStacj pueden ser muchas, pero en este punto nos limitaremos a decidir entre el tipo de despliegue que realizaremos, siendo las opciones:

 

  • Network Provider
  • Self Service Network

 

La opción de Netowrk provider es la más sencilla de todas y básicamente trabajara a nivel 2 (Layer 2), realizando funciones de bridging y switching para conectar la red virtual con la física. Por supuesto tendremos disponible las funciones de segmentación en vLans.

 

OpenStack Network Provider

<imagen cortesía del proyecto OpenStack>

La siguiente opción es la más completa y nos permitirá incorporar a nuestro juego de herramientas la capa 3 (Layer 3), lo que nos permitirá realizar el autoservicio de redes con “overlay” en la segmentación, lo que nos posibilitará por ejemplo el uso de vXlan.

Simplificando podemos decir que la conexión entre las redes virtuales y físicas se realizará usando NAT.

 

OpenStack_SelfService_Network

 

¿Qué opción es preferible?

Pues depende mucho de nuestro entorno. Si hacemos caso al principio Kiss lo lógico sería optar por un diseño Networkk Provider salvo que preveamos necesitar funcionalidades de Self Service.

¿Qué opciones pueden hacer recomendable un diseño Self Service?

 

Pues hay varias cosas que pueden hacer necesario este tipo de despliegue. La primera de ellas es que seamos muy grandes y preveamos necesitar más de 4096 vLans, por lo que necesitaremos hacer uso de cosas como las vXlan, la segunda sería que necesitásemos el uso de funcionalidades como Balanceador o Firewall como servicio (LBaaS/FWaaS)

 

y vosotros, ¿por qué opción optaríais para vuestro cloud?

OpenStack Newton for Dummies – Introducción(I)

OpenStack Newton for Dummies – Introducción(I)

Cloud Conputing es un nuevo paradigma de computación y aunque no es objeto de este artículo explicar que es, o que variantes podemos encontrar, si indicaremos que estas son:

  • SAAS: software as service
  • IAAS: infraestructura as service
  • PAAS: platform as service.

OpenStack

OpenStack es un proyecto apoyado por importantes actores del mundo Cloud (NASA, RackSpace, Huawei, DELL, CISCO, Intel y un largo etc. que puedes ver aquí), que encajaría en la categoría de IAAS, siendo la alternativa comercial más cercana y conocida el servicio AWS (Amazon Web Service) de Amazón. Newton es la última versión disponible de este software.

¿Es realmente una alternativa a Amazon AWS?, bueno hay que matizar que Amazon comercializa un “producto” soportado por su propia implementación de la nube, por tanto OpenStack sería el software que nos permitiría montar un servicio cloud equiparable a Amazon ( lógicamente condicionado por nuestra infraestructura, conectividad, etc.). OpenStack es realmente potente y la mayoría de grandes actores y competidores en el mundo Cloud lo usan.

Explicarlo todo en un artículo sería realmente complicado, por lo que voy a optar por estructurarlo en varios entregas más pequeñas que vayan cubriendo los aspectos principales.

Arquitectura de OpenStack:

Como imaginaréis está formado por un número significativo de componentes, que se reparten las distintas funciones y entre las que podemos encontrar:

  • Controller: es el nodo de control de nuestra plataforma y por tanto deberá estar conectado a la red de gestión de la misma
  • Compute Node: son los nodos que alojan la capacidad de computo en si misma (Hypervisor)
  • Block Storage: es una componente opcional y permite servir almacenamiento de bloque a la plataforma
  • Object Storage Node: son nodos de almacenamiento en forma de objetos. Es una componente opcional

 

Esas componentes se integrarán para dar soporte desde a arquitecturas pequeñas, como a los más complejos despliegues para ISPs.

 

Para nuestro Homelab, podemos partir de los siguientes parámetros básicos:

<imagen cortesía del proyecto OpenStack>

Sistemas Operativos Soportados

Podemos instalarlo en cualquiera distribución Linux, aunque sin duda para una prueba de concepto Ubuntu es la mejor opción, por similitud en los ciclos de desarrollo (disponibilidad de versiones). Centos es otra muy buena opción para probar OpenStack si nos encontramos más comodos con un RedHat Like flavor.

Hypervisores soportados:

OpenStack, soporta un número importante de Hypervisores (con distinto grado de funcionalidades), Xen, XenServer/XCP, KVM, UML, Hyper-V y VMware, siendo hoy por hoy KVM el preferido de la comunidad.

En la siguiente url, podéis encontrar la mátriz de compatibilidad y funciones soportadas por cada uno de los hypervisores.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix

 

Vente para Dublín Pepe!!

De los creadores de vente para UK Pepe!!,  hoy os traigo vente a para Dublín (Irlanda) Pepe!!.

 

Hace poco encontré este mapa de la ciudad de Dublín con la ubicación de las empresas tecnológicas y es realmente espectacular. No puede uno dejar de tener cierta envidia de las posibilidades que supone contar con un Hub tecnológico así en su ciudad y preguntarse, porque no ha sido posible conseguir algo similar en una ciudad española.

 

Hace unos años tuvimos en la ciudad de Málaga, una iniciativa encaminada a atraer empresas tecnológicas (Málaga Valley) que surgió a raíz de un estudio que identificaba a Málaga y Ankara como lugares con las características necesarias para poder reproducir un ecosistema como Silicón Valley, lamentablemente esta iniciativa no termina cuajar o al menos no al ritmo que nos gustaría.

Cisco HyperFlex, ¿decepcionante o prematuro?

Después de un tiempo queriendo evaluar la solución de Cisco para Hyperconvergencia a la que por desgracia aún no he tenido acceso (si algún chic@ de Cisco quiere proporcionarme acceso a un lab o documentación técnica sobre la misma, será bienvenida), por lo que me he tenido que conformar con los papers que la marca usa para publicitar su solución.

¿Que es HyperFlex?

Cisco HyperFlex, es el nombre con el que el fabricante denomina a su nueva solución de Hyperconvergencia.

 

Arquitectura Cisco HyperFlex

 

basada en procesadores Xeon y en sus servidores UCS, la solución de Cisco pone especial énfasis (como no podía ser de otra forma), en la conectividad de red para diferenciarse de sus competidores, pero vamos a analizar la propuesta de Cisco un poco más en detalle.

 

Cisco UCS como plataforma:

 

El HW elegido son los nodos HX-Series y B-Series integrando un único cluster

Cisco HX Series

 

Hypervisor:

De momento solo soporta VMware, pero según he podido comentar con personal cercano a la marca tienen en “Roadmap” la inclusión de soporte para otros hypervisores… ¿cual?….. al menos Hyper-V…..

 

Storage:

No he podido encontrar documentación realmente técnica de como construye Cisco la capa de SDS (Software Define Storage) y en todos sus papers solo hacen referencia al uso de tecnologías SSD, que hoy por hoy NO es un factor diferenciador. Eso si se soporta compresión y deduplicación IN-Line.

 

Limitaciones:

Después de recabar información y leer bastante hay algunas cosas que me parecen factores limitantes y que a continuación detallo:

 

  • No parece que sea posible desactivar la compresión y deduplicación, lo que puede suponer un problema al ejecutar algunas cargas de trabajo
  • Hay una limitación de 8 nodos HX por cluster, aunque si necesitamos más computo podríamos añadir hasta 4 nodos B200M4  en una configuración Mixta
  • No soporta tarjetas NVIDIA GRID, lo cual puede ser limitante para algunas cargas de trabajo

 

Cisco HyperFlex Family

Mi impresión:

Siempre teniendo en cuenta que es una opinión personal y que se basa en lo que he podido documentarme sobre la solución (por tanto susceptible a error), he de decir que la solución me ha defraudado un poco. A nivel de Hypervisor solo tenemos disponible VMware, la capa de gestión de almacenamiento tampoco parece a la altura de la de sus competidores y lo que debería ser su punto fuerte (la conectividad de red), tampoco es especialmente brillante en lo referente a la parte definida por sftware (si en cuanto a integración con equipos Cisco Físicos).

En mi opinión el producto aún no esta al nivel del estado del arte y presenta serias carencias con respecto a las soluciones de fabricantes como Nutanix, Simplivity, Huawei o incluso VxRail de EMC/DELL/VMware, por lo que su lanzamiento quizás ha sido algo prematuro y forzado posiblemente por el desarrollo de la competencia.

 

¿y vosotros que pensáis?, ¿alguien con más experiencia en esta plataforma quiere complementar este artículo?

Simplivity y Huawei unen fuerzas

El 6 de Diciembre de 2016, Simplivity y Huawei anunciaron un acuerdo para distribuir la plataforma Ommistack sobre los Fusion Server de Huawei, lo cual supondrá mejorar la oferta de HW disponible para uno de los principales actores en el mundo de la Hyperconvergencia.

 

 

La noticia ha sido una de las grandes sorpresas de final de año, más incluso después de los recientes rumores de adquisición de Simplivity por parte de HPE.

El acuerdo en principio solo afecta a los servidores Huawei FusionServer RH2288H V3, que son por así decirlo los pequeñitos de la familia:

 

pero no deja de ser una noticia de impacto, por lo que pudiese significar acuerdos con terceros para el uso de servidores “superiores”, no hay que olvidar que Huawei es uno de los principales players en venta de equipos por encima de 4 vías y cuenta en su arsenal con equipos muy potentes y versatiles, como el x6800 o los RH8100.

 

 

Tampoco deja de ser interesante la capacidad de Huawei para alcanzar acuerdos y colaborar con “competidores” (Huawei cuenta con su propia solución de Hyperconvergencia)

 

Puedes leer el comunicado oficial, aquí.

 

Las limitaciones de los sistemas de hiperconvergencia de primera generación (Según CISCO)

Si hace un tiempo se rumoreo que Cisco intento comprar Nutanix y que el fracaso de estas negociaciones dio lugar al proyecto Hyper-Flex, parece que por fin han entrado en fase de competencia con el resto de players (la competencia dinamiza el mercado), ¿por qué digo esto?, fundamentalmente por la aparición de publicidad y notas de prensa, no solo acerca de su solución…también comparándola (con o sin nombres) con la competencia.

logo_cisco

El 14 de Noviembre de 2016 aparecía en el Blog de Cisco un artículo titulado “Las limitaciones de los sistemas de hiperconvergencia de primera generación“, es ese artículo el que da origen a esta entrada, donde resumiré las principales argumentaciones del fabricante. Es importante aclarar que NO es un artículo que refleje mi opinión acerca de Hyper-Flex o su competencia, aunque si introduciré algunas notas al final de la entrada para ayudar a comprender el artículo que puede ser complicado para quien no este familiarizado con estas nuevas tecnologías.

 

Bien…. entramos en materia:

 

Introducción: básicamente da  un par de pinceladas de los motivos que facilitaron la aparición de la Hyperconvergencia como respuesta a problemas de complejidad, necesidad de implementar clústeres (orientados a la virtualización) de manera rápida, etc.

Argumentos: esto es lo que realmente nos interesa.

Según Cisco, “La primera generación de sistemas hiperconvergentes combinaba servidores genéricos de arquitectura x86 con el almacenamiento definido por software para crear una plataforma informática simplificada y distribuida.”, este objetivo debían cumplirlo de manera rápida si querían aprovechar el mercado (antes de que las grandes reaccionasen ante este nuevo nicho de mercado) y esa celeridad  implico “… La simplicidad ha sido el incentivo de venta clave para estos pioneros. Pero para hacerlo posible y llegar al mercado a tiempo, estos primeros proveedores necesitaron hacer concesiones de diseño y tomar muchos atajos arquitectónicos.”

Continuamos con las razones de Cisco:

  • Automoaización limitada: se basa en que los llamados sistemas Hyperconvergentes de primera generación no integran la red (fisica) como parte de la propia solución
  • Falta de flexibilidad al escalar: la mayoría de las soluciones Hyperconvergentes se basa en servidores de Rack en los cuales se escala tanto en computo como en almacenamiento, lo cual no siempre puede ser apropiado.
  • Concesiones al rendimiento:  las plataformas implementan sistemas de archivos estándar, lo cual penaliza funcionalidades como la compresión o deduplicación
  • El soporte de las aplicaciones es estrecho (creo que es una mala traducción y querían decir limitado/malo): argumentan que los sistemas Hyperconvergentes solo admiten entornos virtualizados, lo cual puede ser limitante en arquitecturas que requieran microservicios sobre contenedores (empieza a aparecer artículos muy interesantes que comparan en eficiencia virtualización con sistemas tipo Doscker)
  • Se crean nuevos silos: se añade una nueva GUI para gestionar la plataforma Hyperconvergente, no soportan adecuadamente las redes SDN, carecen de plano de control unificado….

 

¿La solución a todo esto?

Los sistemas Hyperconvergentes de nueva generación como HyperFlex de Cisco.

cisco_hyperflex

<imagen cortesía de Cisco>

 

Comentarios del autor:

  •  Los nuevos players contaban con un tiempo limitado para explotar un nuevo nicho de mercado. La razón del tiempo limitado es muy sencilla de explicar, los nuevos players debían conseguir suficiente cuota de mercado para subsistir por si solos, antes de que las grandes copasen (o anulasen) ese nuevo nicho.
  • ¿Quiénes son los nuevos players?, no se mencionan explícitamente pero en función de los argumentos se pueden encontrar alusiones principalmente a Nutanix, Simplivity y vSANs like solutions
  • ¿Donde ponen especialmente el foco?: en la red, que por otro lado y como es normal en Cisco es uno de los puntos fuertes de su solución

 

Si queréis saber más sobre este tipo de soluciones podéis leer “Hyperconvergencia, ¿quién es quién? (Mayo 2016)” de un servidor.