Saltar al contenido

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

VMWorld Europe 2017, razones para asistir

Del 11 al 14 de septiembre de 2017, se celebrará en Barcelona un año más el VMWorld edición Europa.

Para los que no lo conozcan decirles que es uno de los principales eventos IT a nivel mundial y por supuesto una fecha clave en lo referente a VMWare.

vmworld2017_Europe

 

Particularmente es uno de los eventos que más me gusta y al que intento asistir siempre que mi trabajo me lo permite y es que hay muchas razones para hacerlo, aunque VMWare lo limite solo a 7.

 

para mí y esto es una opinión personal, mis razones para asistir son:

  • Reencuentro con amigos: en un mundo donde todos tenemos muchos viajes y agendas complejas, a veces este tipo de eventos son las excusa ideal para reencontrarse con compañeros/amigos que llevemos tiempo sin vernos.
  • Networking personal: Es una oportunidad única para conocer gente del sector, de partners, de integradores y por supuesto de fabricantes
  • Actualización tecnológica: si buscas un sitio donde poder tener acceso y conocer de primera mano el estado del arte en tecnologías de virtualización y cloud, este es tu evento
  • + Networking personal:  en serio, si asistes a este evento, tienes que aprovechar y conocer a tanta gente como puedas, intercambiar opiniones, debatir….
  • Divertirse: por supuesto también hay diversión y no solo de las numerosas fiestas, que también las tienen. Los mejores momentos los compartidos con amigos y compañeros.

 

Si tenéis oportunidad de asistir, no lo dudéis.

 

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

Xeon Scalable, el nuevo procesador de Intel ya está aquí

Hace unos días hemos podido asistir al lanzamiento de la nueva familia de procesadores Xeon de Intel, denominada Xeon Scalable. Según Intel esta nueva familia de procesadores supondrá un importante avance en materia de rendimiento y eficiencia energética, contando además con variantes especificas para determinados tipos de cargas de trabajo, tales como HPC, IoT, etc.

 

Imagen_procesadores_Xeon

 

¿Qué podemos esperar de ellos?

 

Para empezar el número de cores crece hasta los 28 y (siempre según Intel), se pueden experimentar mejoras de rendimiento de hasta:

  • 70% menos de latencia en acceso a datos
  • 4.2 veces más máquinas virtuales que la familia anterior
  • Entre 40% y 100% de rendimiento más, usando plataformas como Google Compute Platform
  • Etc.

 

Silver, Bronce, Platinum….

Si este no fuese un blog tecnológico, parecería que estamos en una joyería :-), en realidad esta nueva clasificación de los procesadores se basa en:

 

Platinum

Son los más potentes de la familia y lógicamente podemos usarlos para todo, pero es en HPC y análisis de datos donde puede tener más sentido pagar el coste. Por hacer una analogía, serán los sustitutos de los E7

 

 

Gold y Silver

Son los procesadores que más vamos a ver en Servidores en el Datacenter, ideales para Virtualización, Cloud, etc, etc.

Xeon Scalable Gold

Xeon Scalable Silver

Bronze

 

Serán los Xeon de bajo coste, enfocados sobre todo al SMB y a equipos de almacenamiento Entry Level

Xeon Scalable Bronze

 

Reconocimiento de créditos:

Todas las imágenes son propiedad y cortesía de Intel. Puede consultarse las originales, así como información adicional sobre los procesadores aquí.

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

 

 

SDN & NFV, ¿quién es quién?

SDN y NFV son dos de las palabras que surgen en toda discusión (actual) sobre arquitecturas de red. Están de moda y por tanto parece que abordar una nueva arquitectura de red (independientemente del tamaño o necesidades) sin tan si quiera plantearlo es poco menos que un pecado mortal, pero realmente ¿tenemos claro que es SDN y que NFV?, ¿que ventajas e inconvenientes podemos obtener de la adopción de estos modelos?.

Mi intención con esta entrada es dar una pequeña introducción de que es SDN y NFV, si eres un arquitecto de sistemas/redes acostumbrado a grandes despliegues, posiblemente este post no es para ti ;-).

 

SDN:

En las redes tradicionales, la inteligencia o capacidad de configuración y control se aplicaba a nivel de cada dispositivo, es decir, la configuración de un switch se hacía en el propio switch y esta era más o menos aislada de la del resto de dispositivos que le rodeaban.

Con SDN se pretende desacoplar/separar el plano de control de los dispositivos del propio dispositivo, de tal manera que este puede ser transferido a un elemento “controlador”.

 

sdn

<original de la imagen, aquí>

Algunas preguntas interesantes sobre SDN

 

¿Se pueden definir redes SDN multi-vendor? => Sí, siempre que nos basemos en estándares abiertos. El más popular es OpenFlow.

¿Se pueden controlar múltiples dispositivos desde una misma controladora? => Sí, es una de las cosas más interesantes que aporta SDN, la simplificación de redes complejas y la posibilidad de gestionar todos los dispositivos desde un único punto.

¿Permite configuraciones multi-tenant?=> Of course

¿Es apta para despliegues cloud?=> Nació entre otras cosas para solucionar los problemas derivados de los grandes despliegues cloud.

 

NFV:

NFV es una iniciativa para virtualizar las funciones de red, de tal manera que se reduzca la cantidad de HW necesaria, pero…¿qué es exactamente una función de red?.

Entendemos por funciones de red aquellas tales como Routing, switching, balanceo de carga, Firewall, etc., etc.

Algunas preguntas interesantes sobre NFV

¿Es SDN lo mismo que NFV? => No,SDN se puede apoyar sobre dispositivos físicos o virtuales y su principal objetivo es optimizar el funcionamiento de la red y de su gestión. NFV, tiene entre sus objetivos, reducir la cantidad de HW necesario.

¿Pueden trabajar juntas SDN y NFV? Sí, en arquitecturas modernas y de un cierto tamaño es habitual cierto grado de integración entre ambas.

¿Qué es mejor SDN o NFV?=> Son complementarias, pueden usarse de manera individual o conjunta dependiendo de nuestras necesidades

 

Espero os resulte de interés y utilidad esta entrada, que intentare completar con una individual que trate con más detalles tanto SDN, como NFV.

Conferencia de Masayoshi Son en MWC 2017

Hoy charlando con uno de mis compañeros de Dusseldorf acerca de la evolución de los procesadores ARM y de sus aplicaciones a IoT, ha salido a colación la presentación de Masayoshi Son en el MWC 2017 de Barcelona. Para los que no sepan quien es este señor, os diré que es el fundador y CEO de SoftBank y también el dueño de ARM desde el pasado mes de Septiembre de 2016.

Podéis verla a continuación:

Personalmente yo ya la conocía y me parece muy interesante. También he de decir que algunas de las afirmaciones que hace son cuando menos “sensacionalistas”, aunque reflejan un futuro más que probable y no sabemos como de cercano.

 

 

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.