Saltar al contenido

vmware

Tarjeta de red USB Ethernet 3.0 en VMware ESXi 6.5

En mi homelab tengo varios equipos Intel NUC con VMware ESXi6.5.

Intel NUC

En su momento escogí este pequeño equipo de Intel para mi homelab, por los siguientes motivos:

  • Bajo consumo (son equipos que tengo encendidos las 24h, por lo que esto era un factor clave)
  • Buen rendimiento. Soportan procesadores i3,i5 e i7 y una cantidad de memoria bastante respetable (los míos tiene 32GB de RAM cada uno)
  • Poca disipación de calor
  • Factor de forma: son muy pequeños y esto se agradece

sin embargo no es oro todo lo que reluce y lógicamente un equipo tan pequeño tiene algunas limitaciones, que quizás no son evidentes al usuario promedio, pero si al usuario avanzado:

  • Su factor de forma reducido, elimina casi toda posibilidad de expansión que no venga a través de USB
  • Tiene una única tarjeta de red Gigabit Ethernet

Teniendo en cuenta el uso que hago del homelab, donde es habitual que despliegue maquetas de OpenStack, Nutanix CE, etc., etc. necesitaba contar con tarjetas de red adicionales, para mejorar el ancho de banda y poder segregar tráfico.

Después de investigar un poco me decante por la “StarTech USB 3.0 to Gigabit Ethernet NIC Network Adapter” que puede adquirirse sin ningún problema en varios comercios electrónicos, en Amazon por ejemplo la tenéis por unos 20$ (puedes verla aquí).

StarTech USB 3.0 to Gigabit Ethernet

Tienen un rendimiento bastante bueno y podemos hacerla funcionar en nuestra instalación de VMware ESXi6.5 sin demasiadas complicaciones.

Instalación:

Como podemos ver, nuestra NUC inicialmente no detecta la nueva tarjeta:

Listado tarjetas

El primer paso será encontrar y descargar los drivers, lo cual en este caso será muy fácil ya que William Lam (virtuallyGhetto) los tiene disponibles para descarga, junto con información (que ha servido como base para esta entrada) de su instalación.

Descargamos los drivers en formato .vib de aquí.

El siguiente paso será subir el fichero .vib por ssh a cada uno de los hosts ESXi donde queramos instalar nuestra nueva tarjeta.

Copiamos el driver por ssh

a continuación nos logamos por ssh en los hosts y nos posicionamos en el directorio donde hayamos subido los drivers (en mi caso /tmp) y ejecutamos el siguiente comando.

esxcli software vib install -v /vghetto-ax88179-esxi65.vib -f

Comando instalación

next step, desactivar el driver nativo de usb, para que nuestro ESXi usen el nuevo driver:

esxcli system module set -m=vmkusb -e=FALSE

Desactivar Driver nativo

y reiniciamos los hosts ESXi, para que inicien con el nuevo driver y ahora si podremos ver nuestra nueva tarjeta disponible

Tarjeta disponible

 

espero os resulte de utilidad.

Referencias:

http://www.virtuallyghetto.com/2016/11/usb-3-0-ethernet-adapter-nic-driver-for-esxi-6-5.html

 

Virtualizar Oracle, mini guía de licenciamiento (1/2)

En lo muchos proyectos de diseño de arquitecturas y virtualización de CPDs que he podido realizar a lo largo de mi carrera profesional (y seguramente en muchos de los que vendrán), hay siempre un tema recurrente, virtualizar o no virtualizar las BBDD Oracle. Bien, este post no pretende ser una guía de licenciamiento o Best Practices de Oracle (para ello podéis dirigiros a www.oracle.com o a vuestro AM/Partner de confianza, que os podrá ayudar), pero sí aclarar desde mi experiencia, alguna de las preguntas que siempre se plantean.

 

Logo Oracle

¿Cual es el modelo de licenciamiento?

Oracle BBDD se licencia por procesador, lo que quiere decir que en una máquina física que vaya a correr una BBDD Oracle se debe licenciar todos los procesadores que esa máquina tenga.

 

¿Qué pasa con los entornos virtuales?

Esta es la madre del cordero. La respuesta es que deberemos licenciar todos los procesadores físicos susceptibles de ejecutar la BBDD, ¿qué significa esto?, que si tenemos por ejemplo 3 hosts con 2 sockets de 10 cores cada host, integrantes de un cluster por ejemplo de vSphere, deberemos adquirir 6 licencias, independientemente del nº de cores virtuales que tenga la máquina virtual creada para alojar la BBDD Oracle.

La explicación a la situación anterior es que Oracle interpreta que la máquina virtual que corre la BBDD puede ejecutarse sobre todos los procesadores disponibles en el cluster (por ejemplo al hacer vMotion, estaríamos moviendo la máquina a otro host, que por tanto debe ser licenciado).

¿Que ocurre si establezco reglas de afinidad a procesador o alguna técnica similar?

Oracle no considera que reglas de afinidad a procesador o tecnologías similares, sean garantía de que se va a limitar de manera real lo cores involucrados, por lo tanto deberemos licenciar todos nuestros cores.

El fabricante X (diferente de Oracle) tiene una formula mágica para consumir menos licencias, ¿lo creo?

Cantos de sirena al margen, el único fabricante que establece el modelo de licenciamiento de Oracle es Oracle, por lo que todo lo que sea apartarnos de ese modelo podrá acarrearnos problemas a futuro con el soporte o con el licenciamiento.

 

¿De verdad Oracle me obliga a licenciar todos los cores de mi infraestructura?

No, Oracle contempla dos tipos de particionamiento de una máquina:

  • Físico o Hard Partitioning: lo que hacen las máquinas particionables tipo M6, M7, P-series, etc.
  • Lógica o Soft: VMWare y el resto de Hypervisores caen en esta categoría

pues bien si establecemos particiones fisicas solo tendremos que licenciar los cores en las particiones que corran Oracle, es decir si establecemos una partición de 10 procesadores, solo adquiriremos 10 licencias, aunque nuestra máquina tenga 200 procesadores.

 

¿Hay diferencia entre Hypervisores?,

La respuesta es que todos los Hypervisores se tratan de igual manera, salvo el propio de Oracle que en este caso tiene un trato que resulta claramente ventajoso frente a otras opciones como VMWare, AHV, KVM, etc.

 

El motivo de que OVM salga beneficiado es que pueden ser configurados como Oracle Trusted Partition, lo que les permite licenciarse como si de una partición física se tratase.

 

Disclaimer: este artículo se basa en mi experiencia y conocimiento del modelo de licenciamiento de Oracle a Agosto de 2017. Es importante remarcar que el modelo de licenciamiento puede cambiar o lo aquí indicado puede contener alguna errata involuntaria, es por ello que el lector se hace responsable del uso que haga de la misma.

 

Información adicional:

http://www.oracle.com/us/corporate/pricing/sig-070616.pdf

http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf

http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf

http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html

Configurar DSM Synology para dar NFS a VMWare 6.5

Para aquell@s que queráis usar un dispositivo Synology como almacenamiento compartido de una instalación VMWare y os plantéis usar NFS en lugar de iSCSI (altamente recomendable en el caso de Synology), a continuación podréis encontrar los pasos para exportar un Datastore por NFS desde nuestros dispositivo DSM 6.x a nuestros hosts ESXi.

<imagen ilustrativa Synology DS 414>

Comenzaremos lógicamente accediendo a nuestro dispositivo Synology y visualizando el escritorio:

Synology Desktop

 

 

chacemos click en Panel de control  y posteriormente en “Servicios de archivos”

Panel de control Synology

a continuación marcamos “Habilitar NFS” (si queréis usar NFSv4 podéis marcar también el check box y configurar el Dominio NFS correspondiente

Habilitar NFS

 

Aceptamos pulanso ok y regresamos al Panel de control, donde en esta ocasión “pincharemos” en “Carpeta Compartida”, para configurar los permisos (dejaremos unicamente el usuario administrador con permisos de lectura/escritura).

Permisos NFS

 

continuamos cambiando a la pestaña “Permisos avanzados”

 

Permisos avanazdos NFS

y finalmente en la pestaña “Permisos NFS”, deberemos crear una regla que permita la conexión de los Hosts ESXi (podemos crear una por Host, o una que cubra la red en la que se encuentran los Host ESXi).

Permisos de conexion a los hosts ESXi

en mi caso he creado una regla por cada Host ESXi

Permiso de Host ESXi para conectar a NFS

con esto finalizamos la configuración en el lado de Synology y deberemos pasarnos a nuestro Host ESXi o vSphere.  La imagen siguiente muestra mi entorno de homelab con los Datastores disponibles en ese momento:

Datastores previos

con el botón derecho sobre el Datacenter (o uno de los Hosts), seleccionamos Almacenamiento/Nuevo almacén de datos

 

Añadir_Datastore

seleccionamos NFS

Seleccionamos NFS

 

y la versión de NFS

Seleccionamos versión de NFS

introducimos configuración

Configuración NFS

si estamos realizando la operación sobre un Datacenter, seleccionaremos los Hosts que montaran el Datastore

Selección de Hosts

y finalizamos:

Finalizamos configuración

 

ahora si podemos visualizar y usar nuestro nuevo Datastore compartido por NFS

NUevos Datastores

 

¿Por qué usar NFS en lugar de iSCSI?

Normalmente yo suelo preferir iSCSI, pero en el caso de Synology, los recursos compartidos por NFS tienen un rendimiento bastante mejor en NFS que en iSCSI (y no es el único dispositivo en el que he observado este comportamiento), además Synology provee un plugin VAAI para NFS (en otra entrada, explicaré como configurarlo).

VAAI y VASA de VMWare

Hace ya algún tiempo que VMWare se decidió a desarrollar y mejorar las APIs de conexión con terceros y algunas de estas APIS son VAAI y VASA. Aunque no estamos hablando de un nuevo lanzamiento de la 6.5 (por ejemplo VAAI lleva entre nosotros desde la 4.1), no deja de sorprenderme que aún son desconocidas por gran número de personas.

¿Qué es VAAI?

VAAI (VMware vSphere API for Array Integration) es una API ofrecida por vSphere para integración con fabricantes de almacenamiento. Por decirlo de una manera sencilla (por favor, los puristas, no sigan leyendo 😉 ), esta API permite que vSphere sea consciente del almacenamiento que tiene por detrás y hable con el, no solo a través de los protocolos estándar como iSCSI, FC o FCoE.

En realidad VAAI es una parte de la API vStorage que engloba entre otras cosas:

  • vStorage API for Site Recovery Manager
  • vStorage API for Data Protection
  • vStorage API for Multipathing
  • vStorage API for Array Integration

 

<original de la imagen aquí>

¿Para que sirve VAAI?

Pues básicamente nos permite que operaciones que son muy costosas para el host, como por ejemplo hacer un snapshot de una VM, pedírselo directamente a nuestra cabina y que lo haga ella.

En operaciones de snapshot por ejemplo, se pueden obtener reducciones de un 20% en consumo de CPU (según VMWare).

Si acudimos a la página oficial de VMWare podemos leer:

The goal of VAAI is to help storage vendors provide hardware assistance to speed up VMware I/O operations that are more efficiently accomplished in the storage hardware.

Generalmente el fabricante del Storage suele suministrar un plugin para nuestro vCenter que nos permite implementar esta funcionalidad.

Podéis comprobar si vuestro almacenamiento soporta VAAI aquí.

¿Qué es VASA?

 

VASA es otra API, (en este caso VMware vSphere API for Storage Awareness) cuya finalidad es la de permitir integrar nuestro storage con el vCenter para funcionalidades de management. Es algo más nueva que VAAI, ya que se libero con la versión 5.

<imagen cortesía de VMWare>

¿Para que sirve VASA?

Se trata de ofrecer funcionalidades de management en el vCenter y las funcionalidades dependerán del fabricante. Por ejemplo una muestra podría ser:

  • Disk Type (SSD, SATA, SAS, FC)
  • Snap space reserved
  • Dedupe –
  • VV Type

Por tanto el vCenter accederá las funcionalidades VASA ofrecidas por nuestro storage, a través del “VASA Provider”.

Espero haber podido aclarar un poco mejor estos conceptos.

Synology DSM 6 y soporte de vLANs para homelab VMWare

Synology es un fabricante bastante interesante, con productos de bajo precio y funcionalidades que pueden considerarse en muchos casos avanzadas. Sus equipos ideados en principio para el entorno domestico y de pequeña empresa son ideales por ejemplo para implementar un Homelab, por su bajo consumo/ruido y “razonable” rendimiento.

En mi caso utilizo un DS414 para dar almacenamiento compartido por iSCSI y NFS a mi Homelab y aunque esto Synology lo puede hacer de manera nativa en este modelo, me veía limitado por no poder configurar vLANs (al menos desde la GUI).

 

 

 

 

 

 

 

 

 

 

<imágenes cortesía de Synology>

 

El sistema operativo de Synology (DSM) se basa en Linux, por lo que como podréis imaginar, a poco que no venga muy “capado”, podemos hacer grandes cosas… entre ellas solucionar el problema de las vLANS.

 

Descripción del entorno:

 

En mi homelab como imaginaréis tengo un pequeño caos, con numerosas redes que se crean y destruyen, por lo que (además de ser una buena practica), es imprescindible separar tráfico como el de gestión o el iSCSI a una vLAN dedicada. En mi caso opte por la vLAN 200 para el tráfico SAN/NAS.

Configuración:

Habilitar SSH:

El primer paso será contar con acceso ssh a nuestro dispositivo, que en el caso de que no lo tengáis activo, podéis hacerlo siguiendo las siguientes instrucciones.

 

Os logueáis en vuestro Synology

y en el Dashboard seleccionáis panel de control

que os mostrará algo parecido a esto

 

el icono que nos interesa es el último (Terminal y SNMP), entráis en el y veréis algo como esto:

marcáis ssh y listo, ya podéis entrar por consola a vuestro dispositivo.

 

Configuración vLAN:

Una vez dentro de nuestra Synology nos tenemos que dirigir al directorio /etc/sysconfig/network-scripts

 

cada archivo ifcfg-x es la configuración de un adaptador. En mi caso como tengo configurado un agregado para sumar el ancho de banda de los dos puertos ethernet, mi interfaz principal es el ifcfg-bond0 con el siguiente contenido:

lo que haremos a continuación es cambiar al usuario root (lo podéis hacer con un “sudo su -” y vuestra contraseña de administración) y en el mismo directorio haremos una copia del fichero ifcfg-bond0 (o el que sea en vuestro caso), añadiéndole al final “.Nº_vlan”, es decir para la vLAN 200 copiaremos el contenido al fichero ifcfg-bond0.200, para la vLAN 6 ifcfg-bond0.6 y así sucesivamente.

El contenido de ifcfg-bond0.200 es:

guardáis la configuración y reiniciáis vuestra Synology, (podéis hacerlo desde la Gui web, o desde consola como root con el comando reboot).

 

Una vez reiniciada veréis un nuevo interfaz bond con la configuración:

en el siguiente articulo, veremos como crear un recurso compartid iSCSI o NFS en nuestro Synology para presentárselo a nuestros hosts VMWare

 

 

Creación de una iso personalizad de VMware vSphere 6.5 con ESXi-Customizer-PS

Para aquellos que tenemos Homelabs con HW que no esta certificado al 100% por VMware, es habitual tener que generar una iso personalizada en la que le “inyectamos” los drivers que necesitamos y que no vienen por defecto en nuestro ESXi.

Aprovechando que recientemente he actualizado mi Homelab a 6.5 he documentado el proceso.

 

Requisitos previos:

Tener la política de ejecución de scripts a un valor que nos permita ejecutar el que vamos a usar para generar la ISO. Puedes ver el estado de la política de ejecución y cambiarla siguiendo este artículo.

 

Una vez comprobado esto, el siguiente paso es descargar e instalar (si no lo tenemos ya), el PowerCli de VMware.

Descargar PowerCli de VMware

 

a continuación descargaremos el script que usaremos para generar la iso y que se llama “ESXi-Customizer-PS“, lo podéis encontrar aquí.

 

Generar la ISO:

Nos dirigimos al directorio donde tenemos descargado el script y lo ejecutamos

 

y voila, ya tendríamos nuestra ISO personalizada. En mi caso he incluido los drivers Realtek 8165 y sata xachi.

Jugando con el script:

 

El script tiene múltiples opciones que nos permitirán personalizar nuestra ISO. Con el comando Help podemos verlas, junto a una pequeña explicación de lo que hacen.

 

ECPS-25-Help

 

para mi las opciones más interesantes son:

  • -vxx: para especificar que versión de vSphere queremos generar
  • -pkgDir: nos permite incluir drivers .vib (útil cuando el driver que necesitamos no esta en el repositorio “oficial” de los creadores del script)
  • -vft: para conectar al depot de los creadores del scritp

 

Nota importante: aunque os sintáis tentados de usar los drivers de Linux, no lo hagáis VMware empaqueta los drivers de una manera distinta y no os va a funcionar.

Habilitar ejecución de scripts PowerShell y VMware-PowerCLI

Por fin he sacado algo de tiempo para actualizar mi homelab a VMware vSphere 6.5 y me he encontrado los problemas típicos de drivers , que me han requerido generar una ISO “customizada” para mis equipos.

 

La primera traba que os vais a encontrar (sobre todo si venís de una instalación limpia, tanto del homelab como de vuestro puesto de trabajo), es que Windows10 por defecto no restringe la posibilidad de ejecutar scripts PowerShell.

 

Podemos consultar el estado de la política de ejecución mediante el comando Get-ExecutionPolicy

 

Ver política de ejecuión

 

que como podéis ver es Restricted.

Las opciones que podemos elegir al cambiar la política serán:

  • Restricted: Por defecto y la más restrictiva
  • AllSigned: requiere que los scripts estén firmados por una fuente de confianza y pide confirmación antes
  • RemoteSigned: al nivel anterior le suma la posibilidad de ejecutar scripts no firmados, siempre y cuando estén desbloqueados mediante el comando Unblock-File
  • Unrestricted: puede ejecutar scripts sin firmar y muestra advertencias
  • Bypass: puede ejecutar cualquier cosas y no muestra advertencias
  • Undefined: no hay política definida y se aplica la default

Las buenas practicas nos dices que deberíamos coger el valor más restrictivo posible. En mi caso y como en el Homelab estoy constantemente jugando y probando cosas distintas lo fije a Unrestricted.

Fijar política de ejecución a Unrestricted

finalmente comprobamos el estado de la política:

Ver política de ejecuión

 

con esto y la PowerCli de VMware (se descarga de la sección tools de vSphere), podremos ejecutar nuestros scripts para VMware.

 

Espero que os resulte de utilidad