Saltar al contenido

virtualizacion

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

Continuando con el artículo anterior  “Virtualizar Oracle, mini guía de licenciamiento (1/2)“, que la verdad ha despertado bastante interés (o al menos generado feedback por vuestra parte), voy a intentar aclarar algunos aspectos alrededor del licenciamiento de este popular motor de RDBM.

Logo Oracle

Antes que nada recordar que 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.

Entornos de Desarrollo, Test, Pre-Producción…. ¿tengo que licenciarlos?

 

Toda instalación de Oracle debe estar licenciada adecuadamente, ahora bien, existen diversos modelos de licenciamiento (OTN, OMA, OSA, ULA,…). Cuando descargamos software de la OTN ( Oracle Technology Network (OTN) ), aceptamos el modelo de licenciamiento OTN que dice algo así como :

..this limited license allows the user to develop applications using the licensed products as long as such applications have not been used for any data processing, business, commercial, or production purposes….

es decir, podremos usar esta licencia “gratuita” para desarrollar, siempre y cuando no hagamos un uso comercial de la misma, o ejecutemos sobre ella ningún tipo de acción ajeno al desarrollo.

Cualquier entorno de Pre, validación, test, etc., necesitaría por tanto ser licenciado, salvo que lo tratemos como un entorno de desarrollo y ojo!!, no hagamos sobre ellos ninguna labor distinta a los tests propios asociados al desarrollo.

 

Procesadores y factor de corrección

Oracle puede desplegarse sobre distintas arquitecturas (X86, Power, UltraSparc, etc.) y el licenciamiento cambia de un procesador a otro en un factor multiplicador o de corrección. Esto significa que una vez tengamos nuestro número de procesadores, deberemos multiplicarlo por el factor de corrección asociado a esa CPU y tendremos el nº final de licencias necesarias.

 

Podéis consultar la tabla (Oracle la actualiza periódicamente), aquí.

 

VMWare certificado / Soportado para Oracle

Este es otro de los temas que genera bastante confusión.  VMWare NO esta certificado oficialmente para Oracle, pero si soportado, lo que significa que si tenemos un problema podremos acudir al soporte de Oracle y ellos nos ayudaran, pero al no ser un entorno certificado, pueden pedirnos que movamos nuestra BBDD a un entorno certificado para continuar dándonos soporte.

VMWare DRS, afinidad de Hosts  y Oracle

Desde la versión 5.1, Oracle considera necesaria licenciar todos los hosts pertenecientes a un vCenter que vaya a ejecutar una RDBM Oracle, independientemente de que establezcamos DRS con afinidad de Hosts.

Podéis encontrar más información al respecto aquí.

 

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

https://blog.dbi-services.com/all-you-need-to-know-about-oracle-database-licensing-with-vmware/

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

Nutanix + Lenovo, nuevos servidores convergentes

La Hyperconvergencia es una de las palabras de moda  y posiblemente la tecnología que liderara el cambio en nuestros Datacenters, los próximos años. Son varios los fabricantes que incluyen en portfolio alguna solución (más o menos) Hyperconvergente, si bien a día de hoy, Nutanix es el principal player y rival a batir en este nicho.

 

Hasta la fecha Nutanix comercializaba sus appliances con Hardware Supermicro o Dell, a partir de ahora podremos adquirirlos también con HW Lenovo.

Lenovo_Nutanix_1207

La familia de servidores convergentes se ha denominado Lenovo Converged HX Series y de momento esta compuesta por los siguientes modelos:

  • Lenovo Converged HX3500: optimizado para VDI y pequeñas cargas de virtualización
  • Lenovo Converged HX5500: optimizazo para virtualización de servidores y aplicaciones CPU intensivas (Hadoop, Splunk, entre otras)
  • Lenovo Converged HX7500: optimizada para BBDD y aplicaciones con altos requisitos de I/O

Nutanix_Lenovo_HX_Series

Podéis encontrar más información sobre este anuncio en la web de Lenovo aquí y aquí.

Como os comentaba es una de las soluciones Hyperconvergentes que por tecnología, rendimiento y funcionalidades más me gusta a día de hoy y contar con otra alternativa más de HW (recordemos que no todas las soluciones Hyperconvergentes nos permiten elegir HW) es siempre una buena noticia.

 

 

 

 

VMworld Barcelona 2014

Del 14 al 16 de Octubre se celebrará   en Barcelona la versión europea de la cita anual por excelencia en el mundo de la virtualización, la VMworld.

La VMworld es algo así como un salón  del automóvil para empresas y profesionales de la virtualización (centrado en VMware of course).

banner-eu-hero-registerNow

Aunque a priori es un evento abierto, los precios de los pases hacen que sea bastante profesional, con partners  y visitantes realmente interesados en la virtualización con tecnologías VMware.

Este año tengo la suerte de poder asistir y de hacerlo junto a uno de los pocos vExperts de Espana @AndresReyMacias de ItSysBlog, compañero de aventuras laborales.

La lista de charlas y HoL es interminable, las expectativas muchas y el tiempo….. por desgracia poco, muy poco, tres días no son suficientes para aprovechar las posibilidades de formación, descubrimiento y Networking.

Si tenéis la suerte de asistir, quizás podamos coincidir :-), sino intentare contaros  lo más importante que vaya ocurriendo, mientras tanto y para calentar motores os dejo un par de videos de las sesiones generales de la edición USA de este evento.

Nos vemos en la VMworld!!!

It's time to move I.T. Forward, by RedHat

Una de esas infografías con trasfondo comercial que si que sirven sin embargo para ilustrar algunas de las realidad de la I.T. actual, tales como el incremento de servidores por administrador, la adopción masiva de la virtualización y la necesidad de estandarizar para no vernos desbordados.

RedHat_IT_Forward

El original podéis consultarlo aquí.

 

 

Alineación de discos y problemas de rendimiento

Este es un problema que podemos encontrarnos a veces, sobre todo con la proliferación de entornos virtuales (aunque es aplicable a discos físicos).

 

Un poco de teoría:

En el principio de los tiempos los discos IDE/ATA utilizaban un modelo CHS (Cilindro, Head,Sector) para leer y escribir los datos, esto evoluciono hasta los actuales discos SATA que utilizan modelo diferente para direccionar los datos, el LBA.

 

LBA (Logical Bloc Addressing) divide el disco en sectores referenciados desde 0 hasta el tamaño máximo del disco, donde cada uno de estos sectores tiene un número único que lo identifica.

Todos los sistemas operativos modernos usan LBA para acceder y escribir la información en disco.

Como solución temporal de compatibilidad para la adopción de este nuevo modelo de direccionamiento aparecieron discos que emulaban un tamaño de sector de 512 bytes, mientras que por debajo usaban los comandos ATA/SCSI para acceder a los datos, resultando en que a efectos prácticos tenemos dos tipos de sector:

  • Logical sector:  se utiliza para direccionar bloques de datos y es la unidad mínima de información a leer/escribir que aceptara nuestro almacenamiento.
  • Physical sector: es la unidad mínima de información que nuestro dispositivo (disco) es capaz de leer o escribir e una única operación.

¿En que se tradujo todo esto?

En que el mercado termino inundado por dos tipos de discos con los que los sistemas operativos debían lidiar:

  • 4 KB nativos: tamaño lógico de sector de 4KB
  • 512e: emulación de 512 bytes

y cada sistema operativo soporta esto de una manera diferente, por ejemplo para el caso de Windows

block_Size_Windowspodemos ver que sistemas operativos como Windows 7, 2008, 2008 R2, usan sectores lógicos de 512B.

Con tamaños de sector lógicos de 512B tenemos que un sector físico de 4KB contendrá 8 sectores lógicos

emulacion_disco_4-512

el problema es que sistemas operativos relativamente recientes (versiones de windows anteriores a la 7, RHEL 5.x, etc.) y que podemos encontrar en múltiples instalaciones, creaban la primera partición a partir del LBA 63, produciendo una desalineación que penalizaba las operaciones de lectura / escritura

Desalineación

¿y todo esto realmente importa?

Si, la realidad es que tener no alineadas las particiones pueda ocasionar perdidas significativas de rendimiento, esto en entornos virtuales puede ser realmente sangrante, con caídas de rendimiento de alrededor de un 30-40%

Os recomiendo leer el siguiente artículo, de donde se han extraído las imágenes y la mayoría de la información. Es realmente bueno y podéis encontrarlo aquí.

 

¿Por qué debería mejorar mis skills en virtualización?

Pues para contestarte esa pregunta los chic@s de Traingsignal prepararon esta infografía:

 

top-virtualization-skills

Si quitamos la parte referida al salario, que lógicamente es ciencia ficción (al menos en España), el resto de argumentos pueden ser validos. El original podéis consultarlo aquí.

 

¿Qué opináis vosotr@s?

Cloud Computing y Green Datacenters, la extraña pareja

Más que extraña pareja, se puede decir que son dos caras de la misma moneda, reduciéndose todo a usar los dispositivos e infraestructuras en su franja óptima de utilización.

¿Como puede ayudar el Cloud Computing a ser más verde?

Pensad que el Cloud, en su estado más puro (porque esto del Cloud tiene distintos grados), se sustenta sobre varias capas una de las cuales es la virtualización (tanto del almacenamiento como de computo), lo cual se traduce en un mejor uso de los recursos HW y por ende de la reducción del número de equipos necesarios. El resto es sencillo, menos equipos menos consumo.

VMware preparo hace no mucho algunos posters bastante interesantes a este respecto:

<imagen original aquí>

Laboratorio doméstico para un Arquitecto de Sistemas

He recibido alguna consulta, acerca de cual sería el equipamiento necesario para un laboratorio de corte domestico, de alguien que quiera dedicarse a la arquitectura de sistemas.

Bien, lo primero es definir que entiendo por arquitecto de sistemas y es básicamente aquella persona con conocimientos de las principales técnicas y tecnologías necesarias para implementar de la mejor manera posible un sistema informático. Como podéis ver la definición es muy amplia y es que esta disciplina englobaría conocimientos de:

  • Sistemas operativos.
  • Almacenamiento.
  • Redes.
  • Seguridad.
  • Técnicas de tolerancia a fallos y alta disponibilidad.
  • Virtualización.
  • Green IT
  • Etc.

A pesar de lo amplio de la lista anterior, hoy en día es posible montar un laboratorio decente, con muy poca inversión, como todo a más medios mejor será nuestro laboratorio.

Para mi el mínimo imprescindible sería:

Hardware:

  • Un  equipo con al menos 8GB de RAM, 4 tarjetas de red y un buen H.D., para usar como plataforma de virtualización. Aunque hoy por hoy podemos encontrar equipo portátiles con esa capacidad, prefiero un equipo que soporte varios discos a fin de configurar raids que mejoren el desempeño de la plataforma. Imprescindible que la CPU del equipo soporte virtualización.
  • Un segundo equipo con 4GB de RAM y 4 tarjetas de red.
  • 2 Switches gestionables con soporte para LACP, VLans, etc.

Software:

  • Software de virtualización (VMWare, XEN, Hyper V, etc..). Personalmente en mi laboratorio suelo usar VMWareESXi como plataforma base.
  • Balanceadores de carga: Existen appliance  para máquinas virtuales de diferentes fabricantes (como f5), que ofrecen versiones trial limitadas, pero funcionales de equipos de balanceo de carga. Otra opción sería implementarlos con software libre.
  • Proxys: Al igual que con los balanceadores, existen máquinas virtuales que emulan el funcionamiento de estos dispositivos físicos y que nos permitirán simularlos, sin necesidad de tener acceso a uno físico.
  • Cortafuegos: Además de los sistemas que se pueden montar basados en software libre, existe la opción de descargar versiones trial de gran cantidad de software (Checkpoint, Stonegate, etc.)
  • Routers: Cualquier Linux, Unix nos permitirá implementar un Router. También existe software de simulación como GNS3 que puede ayudarnos en esta tarea.
  • Sistemas Operativos: Imágenes de diferentes sistemas operativos para montaje de maquetas.
  • Software SAN con soporte para iSCSI: Una SAN, puede montarse con software OpenSource, por ejemplo Openfiler.

 

 

 

 

En mi caso mi laboratorio tiene el siguiente equipamiento:

Hardware:

  • Un equipo con 8GB de RAM, 4 tarjetas de red y 4 TB de almacenamiento en un equipo de este tipo (me importaba el bajo consumo, aunque supusiese sacrificar rendimiento) como este.

  • Un segundo equipo con 4GB de RAM y 4 tarjetas de red con Linux.
  • 1 Mac Mini con 4GB de RAM  y VMware Fussion.
  • 1 Mac Book con 4GB de RAM.
  • 1 NetBook con 2 GB de RAM .
  • 3 Switches gestionables con soporte para LACP, VLans, etc. Del fabricante Cisco(Un 2960 y dos 2950).
  • Un HP Procurve 2624
  • Varios Access point con soporte para openwrt (son bastante baratos)
  • Un dispositivo de balanceo de carga con soporte para 4 proveedores de acceso.
  • Una NAS con capacidad para 2 TB en raid 1.
  • Varios routers cisco de la familia 26xx,25xx y 18xx
  • Un Juniper SSG5 y un CISCO ASA 5505 como firewalls.

Software:

  • Software de virtualización (VMWare, XEN, Hyper V, etc.). Mi plataforma base es el ESXi.
  • Balanceadores de carga: Trabajo con software libre y appliance virtuales cuando los hay. También con acceso remoto a equipos cuando es necesario y tengo la oportunidad.
  • Proxys: Al igual que con los balanceadores, existen máquinas virtuales que emulan el funcionamiento de estos dispositivos físicos y que nos permitirán simularlos, sin necesidad de tener acceso a uno físico.
  • Cortafuegos:  Además de con Linux es posible hacer cosas bastante interesantes con FreeBSDS y OpenBSD.
  • Sistemas Operativos: Imágenes de diferentes sistemas operativos para montaje de maquetas.

Cuando se trata de software comercial es habitual que algunos fabricantes ofrezcan software en modo trial para evaluación (Checkpoint, Stonegate).

  • Routers: Los Routers software suelo implementarlos con Linux o FreeBSD, también es de ayuda GNS3.
  • SAN: Este apartado lo resuelvo con una máquina virtual con OpenFiler.

Cosas que me faltan:

Pues como suele pasar con estas cosas, me faltan tantas como quiera, pero siendo razonables y teniendo en cuenta que se trata de un laboratorio eminentemente domestico y personal, creo que con una segunda unidad del microserver y un dispositivo NAS/SAN con soporte para iSCSI como esta, tendría un laboratorio bastante completo.