Saltar al contenido

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.

 

Fortigate 30D configuración de VLANs

Continuando con el artículo anterior de configuración de un Forti 30D para uso en homelab, os dejo a continuación como configurar VLANs.

fortigate-30d-frontal

Si recordáis en el artículo anterior explicaba como romper el switch que agrupaba los 4 interfaces LAN, para disponer de 4 interfaces individuales con capacidad de filtrado y Routing. Esto ya es una mejora sustancial con respectoa las funcionalidades que Fortinet penso darnos con este equipo, pero seguía faltando algo fundamental… la configuración de VLANs.

Si recorremos los menus de la web y las opciones de los interfaces veremos que no es posible configurar estas opciones, por lo que deberemos recurrir a la cli.

FWF30D # config system interface

FWF30D (interface) # edit vlan_dmz

FWF30D (vlan_dmz) # set interface lan2

 

FWF30D(vlan_dmz) # set type vlan

 

FWF30D (vlan_dmz) # set vlanid 2

 

FWF30D (vlan_dmz) # set mode static

 

FWF30D (vlan_dmz) # set ip 192.168.xxx.yyy 255.255.255.0

 

FWF30D(vlan_dmz) # set allowaccess https ping ssh

 

FWF30D (vlan_dmz) # next

de esta manera tan sencilla veremos como en los interaces ya nos aparecen en la web

forti_vlan_1

 

y con esto si que tenemo sun equipo mucho más operativo para nuestro Homelab.

 

Espero que os resulte de utilidad.

Cambiar Switch Mode a un interface en Fortigate FortiOS 5

Hace poco he tenido la oportunidad de ampliar mi homelab, con un FortiWifi 30D. Es un equipo diseñado para ROBO que equipa un puerto WAN y un switch de 4 puertos gigabit (además de la parte de controladora Wifi, que en mi caso me interesa menos).

fortigate-30d-frontalfortigate-30d-trasera

El problema de este equipo es que con unicamente dos interfaces (WAN e internal) y sin VLANs tenemos poco juego, así que vamos a ver como “romper” el switch interno y pasar a tener disponibles de manera individual los 4 interfaces del Switch.

 

Lo primera es tener acceso (sobre todo si lo hacemos en remoto) de administración sobre un interfaz que no se vea afectado por el cambio, en mi caso habilite momentaneamente el acceso a través del interfaz WAN y ver los interfaces que tenemos:

 

forti_sw_to_int_1

como podéis ver el interfaz “internal” es un Swich, lo editamos y desactivamos el servicio DHCP

forti_sw_to_int_2

lo siguiente es eliminar todas las políticas que hagan referencia al Switch “internal”, acordaos de tener acceso desde otro interfaz antes de eliminar políticas que puedan dejaros sin conexión al equipo.

forti_sw_to_int_3

 

el siguiente paso desde la cli sera cambiar el modo del interfaz

forti_sw_to_int_4

 

y lo siguiente que tendremos e sun error que hará referencia al interfaz “lan”, que es uno de los interfaces (junto con el Wifi en mi caso), que forman parte del Switch “internal”

forti_sw_to_int_5

 

¿solución?, en la pestaña interaces eliminar el interfaz “internal”, recordad nuevamente tener conexión al equipo a través de otro interfaz que no estéis tocando en este momento.En la pestaña interfaces, nos aparecerá un nuevo interfaz llamado “lan”, nuevamente volemos al cli y ahora si podremos ejecutar el cambio de modo sin problema:

 

forti_sw_to_int_4

 

 

Una vez realizado este paso ya deberíamos ver todos los interfaces:

 

forti_sw_to_int_7

 

y nada más, con esto tendremos un equipo con 5 interfaces capaces de enrutar y filtrar trafico.

 

Espero os resulte de utilidad.

Heweltt Packard Enterprise (HPE) y Simplivity juntos?

El gigante HPE podría estar interesado en la adquisición de Simplivity, que es junto con Nutanix uno de los principales actores en el mundo de la Hyperconvegencia. La operación podría estar valorada en 3.9 Billones de dolares y tondría todo el sentido del mundo ya que la Hyperconvergencia (al menos del nivel de Simplivity) es un producto que HPE no tiene en cartera.

SimpliVity_Logo

Simplivity viene de tener un crecmiento del 110% frente al 77.4% de su inmediato perseguidor (Nutanix) en los últimos 12 meses según Gartner, lo que la posicionaría como un opción más que apetecible para gigantes con carencias en está tecnología.

De momento ambas compañías guardan silencio al respecto de lo que sería un movimiento importante en este mundo. Mientras tanto,  Simplivity continua revalorizandose en bolsa.