Chubascos Blog

Chubascos tecnológicos para quitarnos la neblina de las tecnologías de la nube! Viva la lluvia!

Archivos por Etiqueta: VMware

Yet Another VCAP-DCA post – Sección 1 – Objetivo 1.1 / Parte 5

Hola,

Quinta parte del objetivo 1.1. Recordad que los temas a tratar en la entrada están enmarcados con asteriscos (*) y los temas tratados en entradas anteriores son hipervínculos a las mismas.

Conocimiento:
Identificar tipos de RAID.
Identificar tipos de HBA soportadas.
Identificar formatos de discos virtuales.

Capacidad y habilidades para:
Determinar los casos de uso y configurar VMware DirectPath I/O.
Determinar los requerimientos y configurar NPIV.
*Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.*
Aplicar las best practices de VMware para almacenamiento.
Entender los casos de uso para RAWs (Raw Device Mapping).
Configurar los filtros de almacenamiento de vCenter.
Entender y aplicar la VMFS re-signaturing (traducir esto como “re-firma” me suena raro).
Entender y aplicar masking de LUNs utilizando comandos del tipo PSA.
Analizar los I/O de las cargas de trabajo para determinar los requerimientos de I/O del almancenamiento.
Identificar y etiquetar dispositivos SSD.
Administrar la aceleración por hardware para VAAI.
Configurar y administrar almacenamiento “profil-driven”.
Preparar el almacenamiento para mantenimiento.
Upgradear la infraestructura de almacenamiento de VMware.

Herramientas:
vSphere Installation and Setup 5.5 – http://goo.gl/nUXi7i
vSphere Storage 5.5 – http://goo.gl/bO5VlT
vSphere Command-Line Interface Concepts and Examples – http://goo.gl/T3X6DV

Cliente de vSphere/Cliente Web de vSphere
vscsiStats
vSphere CLI:
esxcli
vifs
vmkfstools
esxtop/resxtop

Contenido:

Determinar el nivel de RAID apropiado para distintos tipos de cargas en las VMs.

Bien, entramos de lleno en un tema más que interesante y que por el detalle que requiere se suele pasar por alto o dimensionar “más o menos a ojo y a base de experiencia”.

Como ya se habló en otro post de la serie, cada tipo de RAID viene acompañado de algún tipo de penalización en el momento de escribir. Esta penalización puede ser de 1-1 IOPS (penalización nula o dicho de otra forma, que no hay penalización) o como es el caso más conocido, el del RAID 5, el cual es 4-1 IOPS. Donde por cada operación de I/O que le sea solicitada a nuestro RAID, se generarán 4 IOPS.

Bien, determinar el nivel apropiado de RAID para los distintos tipos de cargas en las VMs primero y sobre todo, implica que conozcamos el tipo de carga de nuestra VM. Esto se refiere a:
– Porcentaje de lecturas
– Porcentaje de escrituras
– Frecuencia de acceso a la información
– Cantidad de información actual y previsión de crecimiento
– Tipo de operaciones (secuenciales o aleatorias)
– Picos y utilización media

Esto sólo para empezar! Para seguir con lo de “nivel apropiado de RAID”, también habría que conocer cómo calcular el impacto de cada tipo de RAID en determinados tipos de carga. Esto básicamente se reduce a una fórmula muy sencilla en la cual se consideran los porcentajes de lectura y de escritura así como la penalización por el tipo de RAID y también la cantidad de IOPS para las que estamos dimensionando el RAID.

Por último podríamos también hablar de la infraestructura en sí. Desde donde viajarán los datos (HBA), el tipo de protocolo que utilizaremos, el recorrido que harán y finalmente las características físicas y configuraciones que tengamos en nuestro storage…desde tipos de procesador hasta tipos de interconexión de los discos. Nada más imaginaos dimensionar un storage para soportar una cantidad altísima de operaciones pero lo conectamos todo a través de un cable a 1Gbps.

Como veréis, no son pocas las variables y sí es poco el conocimiento que se tiene del impacto REAL Y MEDIBLE de cada una de ellas. Evidentemente escribir un libro para calcular un RAID no es la idea (como lo de las HCL que comentábamos en otra entrada) por lo que veremos más en profundidad lo que a mi entender es más relevante.

Por favor, si os parece que me dejo algún aspecto relevante fuera del estudio, avisadme para poder valorar su inclusión en el post.

Tendremos en cuenta:

– Espacio necesario
– Porcentaje de lecturas
– Porcentaje de escrituras
– IOPS de la VM

Espacio necesario

Lo primero será obtener la información de la ocupación actual de la VM y la previsión de crecimiento. Esto es demasiado fácil como para tener que explicarlo 🙂 Pero basta con mirar la información de la VM desde el propio S.O. en todas sus particiones/puntos de montaje y mirar un poco el histórico de crecimiento además de preguntar si habrá algún tipo de cambio importante. Por ejemplo, que en un servidor de correo se desee ampliar la cuota de los buzones, que en un servidor de ficheros se piense comenzar a almacenar otro tipo de información como videos, fotos, etc por las mismas necesidades de negocio…vamos, cualquier cosa que pueda “romper” el histórico de crecimiento.

IOPS y distribución entre lecturas y escrituras

Esto ya tiene un poco más de miga (un poco) y podemos decir que hay muchas formas de verlo. Por ejemplo, con vcOPS. Esta herramienta ya nos presentará la información (TPS=Transacciones por segundo) desglozadas en lecturas y escrituras desde donde podremos obtener los porcentajes.

Utilizando esxtop o resxtop (la variante de esxtop que se usa desde vMA), podremos identificar las IOPS. Bastará con ir a la vista de las VMs (presionando “v”) y ver el número que nos muestra el campo CMDs de comandos por segundo. Normalmente este campo es igual al número de IOPS, salvo que algunas veces puede estar un poco hinchado por otro tipo de datos que no está demás contar como las reservas SCSI. “READS/s y WRITES/s” son la cantidad de inodos que se ven afectados ante las vibraciones de nuestro storage y la posición relativa del sol y la luna….que no! era para ver si estabais despiertos 😀 Evidentemente se trata de las lecturas y escrituras y la suma de estos dos valores dan como resultado los “CMDs” del primer campo.

Imagen

esxtop no sería mi primera opción ya que se trata de una herramienta para diagnosticar problemas y las circunstancias que los causan (root cause analisys). Sin embargo, se puede ejecutar esxtop de forma que guarde la información en un fichero y lugo la podamos “graficar” con un excel. Marco Broeken lo explica detalladamente en su blog http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/

Existe una versión gráfica de esxtop que podréis descargar desde los labs de VMware. Es un “fling” muy útil y fácil de usar.
http://labs.vmware.com/flings/visualesxtop

En lo personal suelo utilizar la versión opensource de Hyperic ya que además de analizar IOPS, me permite relacionar esas IOPS con otros factores como las consultas SQL, el número de usuarios conectados a una aplicación, bbdd, etc.
http://www.hyperic.com/hyperic-open-source-download

Las cuentas claras, conservan la amistad

Ahora sólo falta hacer números. Es MUY sencillo y no guarda ningún misterio. La fórmula con las modificaciones que Duncan Epping hizo para contemplar la penalización en las escrituras de los tipos de RAID, es la siguiente:

( IOPS de la VM × % lecturas ) + (( IOPS de la VM × % escrituras ) × Penalización RAID)

Por tanto, en caso de que nuestro estudio previo nos haya dado como resultado que nuestra VM necesita 1000 IOPS (aquí entra en factor un aspecto de diseño importante…diseñaremos para los picos de carga o diseñaremos para el consumo medio lo que resultará en ahorre de costes y cuellos de botella esporádicos. Aunque esto mejor dejarlo cuando vayamos por el VCAP-DCD 🙂 ) de los cuales el 40% son escrituras y el otro 60% son lecturas. La fórmula quedaría:

IOPS de la VM = 1000
% lecturas = 60%
% escrituras = 40%

( 1000 IOPS x 0,6 ) + (( 1000 IOPS x 0,4) * Penalización RAID) =
600 IOPS + ( 400 IOPS * Penalización RAID) =

Ahora toca jugar un poco con los RAIDs y recordar las penalizaciones para cada uno de ellos. Sobran las tablas por internet que muestran estas penalizaciones así que simplemente supondremos que queremos ver cómo nos quedaría con un RAID 5.

600 IOPS + ( 400 IOPS * 4 IOPS ) =
600 IOPS + 1600 IOPS = 2200 IOPS

Vemos así cómo para una VM con 1000 IOPS necesitaremos un RAID 5 de 2200 IOPS ya que cada una de las IOPS de escritura y sólo de escritura, tendrá una penalización de 4 IOPS por c/u de escritura.

Aquí se puede jugar mucho pero otra vez nos iríamos a la parte de diseño más que VCAP-DCA. Cuando tengamos que diseñar un storage, básicamente en este punto se tratará de un equilibrio entre IOPS y espacio que se necesita. De forma que la tarea se reduzca a encontrar la combinación que cubra las necesidades de IOPS y espacio con el menor coste posible. En este sentido, los discos de estado sólido están rompiendo las reglas del juego ya que para lo que antes podíamos necesitar barbaridades de discos, ahora con 4 o 5 discos de estado sólido lo conseguimos y a un mejor precio!

Algunas cosas que quiero comentar antes de dar por finalizado el post:

Lecturas – Si bien las escrituras sólo pueden quedarse igual o empeorar según el tipo de RAID que utilicemos, las escrituras sólo pueden mejorar. En este caso los cálculos son muy sencillos, basta con sumar las IOPS de los discos que forman el RAID y ya sabremos las IOPS de lectura que tenemos. Hay muchos debates en internet de “qué RAID es el mejor en lecturas”…la respuesta es fácil, mientras de más discos se pueda leer la información, mejor. Supongamos que un fichero de 10 MB está distribuido en 5 discos y que la controladora es capaz de leer de todos a la vez (a cada disco le toca leer 2MB)…mejor que si sólo tenemos el fichero en 2 discos (a cada disco le toca leer 5MB).

IOPS = La cantidad de operaciones de entrada/salida por segundo. Normalmente utilizada para medir los accesos aleatorios de escritura y lectura de bloques pequeños. Cargas habituales OLTP. Se puede calcular:
IOPS = throughput / block size

Throughput = La cantidad de información que se puede transmitir por segundo. Normalmente se utiliza para medir accesos aleatorios de bloques más grandes (64K). Se puede calcular:
Throughput = IOPS * block size

Block size = La cantidad de datos que se transmite en una operación de entrada/salida. Se puede calcular:
Block size = IOPS / Throughput

Frecuencia de acceso a la información = Casi todas las cabinas traen más o menos caché. Algunas con funcionalidades de tiering ponen en esta caché la información más utilizada por lo que es muy posible que cuando estemos realizando operaciones, muchas de ellas se valgan de la caché de nuestro storage. Por esto también es importante contrastar las fuentes de nuestra información. Una cosa es medir desde dentro del entorno virtual, otra es hacerlo a nivel de hipervisor y otra es hacerlo a nivel de storage. Como recomendación, si es posible, contrastar todas las fuentes para depurar la información en la que basaréis el diseño.

Bueno, otro post que se nos fue. Espero que esta información os sea útil y por favor dejad vuestros comentarios que hará ilusión leerlos 🙂

Saludos,
Sebastián Greco

Bibliografía utilizada para escribir este post:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008205
http://www.yellow-bricks.com/esxtop/
http://labs.vmware.com/flings/visualesxtop
https://communities.vmware.com/thread/456397
http://labs.vmware.com/flings/io-analyzer
http://goo.gl/t9Hl0Y
http://www.lucd.info/2011/04/22/get-the-maximum-iops/
http://www.vclouds.nl/2012/04/25/creating-disk-io-excel-graphics-with-esxtop/
http://www.hyperic.com/hyperic-open-source-download
http://wintelguy.com/2013/20130406_disk_perf.html
http://www.yellow-bricks.com/2009/12/23/iops/
http://www.tomshardware.co.uk/forum/251893-32-raid-raid#.
http://wintelguy.com/raidperf.pl
http://www.dataram.com/blog/?p=112
http://es.wikipedia.org/wiki/OLTP
http://es.wikipedia.org/wiki/OLAP

Anuncios

VMware Horizon Mirage – Introducción

Muy buenas a todos,

Mi nombre es Sergi de la Torre y vamos a dedicar el post de hoy a un producto que parece que este año va a dar mucho que hablar, en concreto nos referimos a VMware Horizon Mirage.

Muchos de vosotros lo conoceréis, y tal vez muchos será la primera vez que escucháis al respecto de este producto. Horizon Mirage no es un nuevo software recién sacado del horno por VMware sino que se trata del software de la compañía Wanova que el año pasado VMware adquirió y que actualmente ha integrado dentro de su portfolio dirigido a las soluciones de EUC (End User Computing) y que como bien he comentado dará mucho que hablar.

layers

¿Qué es VMware Horizon Mirage?

Horizon Mirage se trata una de las soluciones que proporciona VMware para reducir de manera dramática el OpEx (Operational Expenses) consiguiendo reducir los recursos necesarios para mantener nuestra infraestructura de microinformática.

¿Cómo explicar de manera rápida, y sencilla que és Mirage? Bien, la manera más resumida para dar una idea clara de que es Mirage cuando alguien me pregunta es: “¿Conoces la virtualización de escritorios? ¿Conoces las ventajas que proporciona a nivel de gestión centralizada de los desktops? ¿Los ahorros en OpEx que te facilita? Bien, pues Horizon Mirage te ofrece la misma facilidad y ahorros en OpEx pero sin ningún tipo de virtualización, es decir, la ejecución del Sistema Operativo y las aplicaciones sigue siendo en local, en el dispositivo final del usuario”

¿Cómo funciona Horizon Mirage?

Para poder explicar el funcionamiento de la solución, explicaremos como segmenta las distintas partes de un desktop/laptop y como se gestionan en nuestro servidor.

Mirage trabaja con un conjunto de capas claramente diferenciadas y nos permite poder intercambiar estas capas desde nuestro servidor central sin ningún tipo de intervención del usuario (miento aquí, el usuario deberá reiniciar su equipo para aplicar los cambios de capa. Complicado, eh!?). Podemos ver a continuación las distintas capas que gestiona el sistema:

Podemos ver 2 categorías claras: las capas gestionadas por el usuario y las capas gestionadas por el personal de TI.

Las capas gestionadas por el usuario son sus propios datos, su configuración (fondo de pantalla, favoritos, etc) así como las aplicaciones que él mismo se instale sobre su equipo

En cambio, las capas gestionadas por TI son:

  • Driver Library: Uno de los puntos a gestionar en este entorno son los drivers. Mirage gestiona una librería de drivers que el administrador deberá ir alimentando con los drivers de todos los dispositivos que hayan en el parque de PCs. Esto permite migrar por completo un equipo con todos sus datos hacia otro equipo con Hardware completamente distinto sin ningún tipo de problema.
  • Base Layer: Esta capa incluye el sistema operativo así como las aplicaciones corporativas que queramos desplegar a todo el conjunto de usuarios. Un ejemplo de aplicaciones comunes a todos los usuarios podría ser el antivirus, Microsoft Office, etc.
  • App Layer: Estas capas serán desplegadas para instalar de manera centralizada aplicaciones a distintos usuarios. Podremos crear grupos de aplicaciones para crear paquetes de aplicaciones departamentales y además nos permitirá lanzar actualizaciones de las aplicaciones de manera centralizada sin ningún tipo de actuación sobre los equipos cliente.

Arquitectura de la solución

¿Que mejor explicación para la arquitectura que una imagen?

Mirage Architecture

Como podéis ver, el despligue de Horizon Mirage consta de distintos elementos. Pasamos a detallar estos elementos a continuación:

–        Storage Volumes. Se trata de los volumenes donde se almacenarán los distintos datos tales como las imagenes base, las capas de aplicación, la librería de drivers, los datos de usuario,e tc. Estos Storage Volumes será recomendable presentarlos como un recurso compartido a través de CIFS para poder ser usados por varios Mirage Server, ya que esto nos permitirá poder redundar y balancear la carga entre distintos servidores, aunque en cualquier caso están soportados los almacenamientos tipo SAN, NAS y almacenamiento local.

  • Muy importante. Horizon Mirage realiza deduplicación a nivel de fichero y acto seguido a nivel de bloque. Esto permite reducir el tamaño que ocupan los distintos CVDs en disco de manera drástica
  • Nota a tener en consideración. VMware recomienda usar como “rule of thumb” (regla estándard) 15GB por usuario a la hora de dimensionar el tamaño del almacenamiento.

–        Mirage Servers. Se trata de el/los servidores/es encargados de la transferencia de los ficheros y de la comunicación con los dispositivos finales. Deberemos desplegar varios de servidores con este rol cuado nos interese proporcionar toleráncia a fallos o bien si necesitamos escalar para poder dar servicio a un número mayor de dispositivos finales. Recordemos que cada Mirage Server soporta 1.500 dispositivos gestionados (si se trata de un servidor físico) o 300 dispositivos gestionados (servidor virtual). El número máximo de serivodres en el clúster es de 10 nodos.

–        Mirage Management Server. Este servidor es el encargado de la gestión y administración de nuestro clúster de Servidores de Mirage. Un único nodo gestionará los distintos Mirage Servers que tengamos. Necesita de un servidor de base de datos, en concreto una BBDD de Microsoft SQL Server

–        Mirage Management Console. No se trata de un servidor en si, pero será el punto desde el que gestionaremos el entorno. Se trata del entorno gráfico que nos proporcionan para el Mirage Management Server. Esta consola se instala como un Snap-In de MMC.

A nivel de conectividad desde los clientes hacia el/los servidor/es de Mirage podemos ver que podemos conectar desde la mayoría de tipos de conexión: LAN, WAN e Internet. Es importante mencionar que Mirage dispone además de la deduplicación que hemos comentado anteriormente en almacenamiento, deduplicación a la hora de enviar los bloques, con lo cual, antes de enviar ningún bloque a través de la red realiza las siguientes optimizaciones:

  • Deduplicación a nivel de fichero
  • Deduplicación a nivel de bloque
  • Compresión de los paquetes a enviar

Con esto el sistema consigue reducir enormemente el tráfico necesario a enviar. Así mismo, no se enviará ningún archivo que ya resida en el servidor a la hora de realizar la cópia. En caso que ese archivo ya se encuentre en el servidor, en su lugar se almacenará un apuntador hacia el archivo existente, con lo cual también tendremos una reducción del espacio en disco.

En cuanto a las oficinas remotas, también existe una funcionalidad muy interesante llamada Branch Reflector. Esta funcionalidad permite seleccionar un equipo cliente como servidor dentro de la sede. Este equipo seguirá siendo usado por un usuario, pero a la vez será el repositorio de las imagenes y dónde accederán a descargar las nuevas capas los distintos equipos que se encuentren en esa sede. Esto consigue que las imágenes solo sean descargadas una única vez desde la sede hacia el Branch Reflector y este las distribuya entre los distintos equipos de manera local.

Mirage Branch Reflector

Todo esto es muy bonito y interesante pero, ¿Para que puedo usar Mirage?

Mirage es un producto que podemos usar para el dia a dia en la administración de los dispositivos finales, pero los casos de uso más claros tratamos de exponerlos a continuación:

a) Migración de Windows XP a Windows 7

Como hemos comentado, Mirage nos segmenta cada una de las maquinas en distintas capas que podemos intercambiar sin ningún problema. Una de estas capas es la de sistema operativo, con lo cual nos permite migrar de manera muy fácil nuestro parque de Windows XP hacia Windows 7.

b) Disaster Recovery

Un usuario pierde su portátil en el aeropuerto, o bien el disco duro muere, o se le ha caído el café encima… Todos sabemos que pueden pasar mil cosas! Bien, como hemos comentado todos los datos del equipo del cliente están guardados en nuestro servidor Mirage, desde el S.O., las aplicaciones, sus datos, sus configuraciones… Mirage dispone de un asistente para que en caso que ocurra cualquiera de estas desgracias poder mover estos datos hacia otro equipo y el equipo esté exactamente igual que el anterior, con sus datos, configuración, apps, etc.

c) Cambio de equipos PC

Como os podéis imaginar este caso es exactamente igual que el anterior, así que no hay ningún problema en hacerlo.

d) Entrega/actualización de aplicaciones de manera centralizada

Al poder entregar distintas capas de manera centralizada, podemos hacer llegar nuevas aplicaciones o bien actualizaciones de aplicaciones que tiene el usuario sin que el administrador se tenga que levantar de su mesa. Bueno… dejémosle que se levante a tomar un café al menos y lance el despliegue 😉

 

¿Es Horizon Mirage competencia de Horizon View?

La respuesta es: ¡Rotundamente No!

La apuesta de VMware por este producto es para poder ofrecer una solución completa para la gestión del parque de microinformática para todas las distintas necesidades y distintos perfiles que podemos encontrar dentro de una empresa.

Uno de los mensajes que suelo lanzar cuando tengo una conversación respecto a virtualización de escritorios es: “Si alguien te dice que puedes virtualizar el 100% de tus escritorios, huye, esa persona te está mintiendo”. De la misma manera usaría el mismo mensaje en cuanto a Horizon Mirage. Debemos tener en cuenta que según las necesidades de cada usuario será necesario ir hacia una solución u otra, o incluso la combinación de ambas soluciones.

En este sentido creo que el movimiento de VMware en su aproximación hacia una solución global para los dispositivos de usuario final es muy acertada, y con ello han sacado la llamada Horizon Suite.

Horizon Suite no es más que un paquete que incluye los distintos productos tales como: View, Mirage y Horizon Workspace, consiguiende ofrecer una solución global a los problemas actuales de la informática de usuario. Obviamente es posible que no necesitemos todos los productos o realicemos una aproximación por fases, en ese caso todos los productos se pueden seguir adquiriendo por separado.

Horizon Suite

Bien, esto es todo por hoy respecto a Mirage. Espero veros pronto con los siguientes posts de Mirage enfocados a su instalación, administración y casos de uso.

Saludos!!

Sergi

Bases de datos Oracle sobre VMware vSphere – Licenciamiento

Hola amigos,

En esta nueva entrada hablaremos sobre uno de los aspectos que más confusión crea a la hora de virtualizar Oracle sobre vSphere, el licenciamiento.

Antes de ir al lío, permitidme ahorrar la lectura del artículo entero a quien simplemente quiera respuesta a la eterna pregunta:

¿Tengo que licenciar todos los procesadores físicos del host si únicamente presento 1 vCPU a la VM con Oracle?

La respuesta rápida es “”.

La respuesta un poco más larga es “Sí, para todos los servidores en los que se vaya a ejecutar Oracle y en caso de utilizar un modelo de licenciamiento por procesador y no por usuario además de utilizar una tecnología de virtualización distinta a Oracle VM configurado de la siguiente forma:

http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf

Veréis que en el documento antes mencionado se habla de la capacidad de ofrecer “hard partitioning” con Oracle VM gracias a su funcionalidad de “pinning” que a primera vista y sin conocer en profundidad su funcionamiento, se parece mucho (por no decir que es lo mismo) a las funcionalidades conseguidas con la afinidad de CPU de VMware. Dicho esto, Oracle tilda su tecnología como “hard partitioning” y la de VMware como “soft partitioning”. Soft partitioning no ofrece ninguna ventaja a efectos de licenciamiento con Oracle y hard partitioning sí.

Eso sí, recordad que si bien Oracle VM permite realizar “hard partitioning”, lo hace bajo ciertas condiciones:

Live migration of CPU pinned virtual machines to another Oracle VM Server is not permitted under the terms of the hard partitioning license. Consequently, for Oracle VM 3, DRS (Distributed Resource Scheduler) and DPM (Distributed Power Management) policies should not be enabled for server pools containing CPU pinned guests.

Sobre el licenciamiento:

–       ¿Qué dice VMware al respecto?

http://www.vmware.com/files/pdf/techpaper/vmw-understanding-oracle-certification-supportlicensing-environments.pdf

–       Existe un tipo de licenciamiento llamado “Named User Plus”. Para este tipo de licenciamiento no hay ningún impacto en utilizar vSphere.

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

Este licenciamiento lo utilicé una única vez en la que necesité licenciar Oracle para albergar únicamente la base de datos del propio vCenter y Update Manager y en la que se utilizaría un único usuario para trabajar con las bases de datos tanto de forma directa como indirecta. Opción mucho más económica que otro modelo de licenciamiento para este escenario.

–          La mayoría de las tecnologías de Oracle se licencian por socket físico o core sobre el cual se “instala” o ejecuta. Este es el tipo de licenciamiento sobre el cual se discute generalmente. Lo de “instala”  lo pongo entre comillas porque es la definición que utiliza el propio Oracle y la quería dejar reflejada, aunque desconozco y dudo que exista la posibilidad de “instalar” software en un procesador…

Sobre este tipo de licenciamiento, estas son algunas características:

  • La licencia no toma en cuenta la ubicación de la base de datos sino en qué procesador se ejecute (importante tenerlo presente para escenarios de recuperación ante desastres como veremos más adelante).
  • En un host virtualizado con vSphere, se deben licenciar todos los procesadores y cores (en este caso no hay opción de licenciamiento de tipo “hard-partitioned”).

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

  • Se pueden ejecutar un número ilimitado de workloads virtuales en un host totalmente licenciado.
  • Oracle no tiene ninguna política específica declarada en cuanto mecanismos de VMware clustering o DRS Host Affinity.
  • En líneas generales, todos los nodos que en algún momento ejecuten cargas de Oracle, han de estar totalmente licenciados. Esto incluye HA, FT, operaciones de vMotion manuales o por DRS, migraciones “frías”, etc.

Digo lo de “en líneas generales” porque existen ciertas excepciones.

Funcionalidad VMware Requerimiento de licencia en primario Requerimiento de licencia en secundario

HA

Con storage compartido en el mismo site, NO hasta 10 días por año

vMotion

NO hasta 10 días por año

Fault Tolerance

SRM

SÍ, si se replican los ejecutables de Oracle. NO si se utiliza backup.

Para obtener información más exhaustiva, seguir el siguiente link:

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

En la página 20 está lo de los 10 días.

Adicionalmente a lo ya comentado, se pueden ver los registros para comprobar los movimientos de las VMs.

  • vCenter genera y mantiene logs (hostd.log y vmware.log) de migración que pueden ser usados para llevar un control interno y/o externo (por ejemplo en caso de una auditoría).
  • vCenter cuenta con APIs para que se puedan integrar herramientas de terceros que controlen el “compliance” del licenciamiento.

Sobre las ediciones:

Poco podré decir que no diga el propio Oracle en su página Web.

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

Sin embargo me gustaría destacar algunas cosas:

–          Oracle Database Standard Edition:

  • Se licencia por socket sin tener en cuenta la cantidad de cores.
  • “Procesador” equivale a “socket”.
  • La cantidad de sockets habilitados en la BIOS, equivale al número de “procesadores” que hay que licenciar.
  • La cantidad de sockets ocupados, equivale al número de “procesadores” que hay que licenciar.
  • Cada tipo de licencia de Standard Edition está limitado a una capacidad máxima de sockets. A efectos de esta limitación, sí cuentan los sockets vacíos o deshabilitados.
  • Ejecuta el mismo motor de base de datos que Oracle Database Enterprise Edition.
  • Existen dos opciones:
    • Oracle Database Standard Edition One (SE-1).
      • 1/16 parte del precio de la Enterprise Edition (aproximadamente).
      • Máximo de 2 sockets.
      • Oracle Database Standard Edition (SE) (mayor número de funcionalidades y mejor escalabilidad).
        • Máximo de 4 sockets.
        • Incluye Oracle RAC (limitado a clústers de hasta 4 sockets).

En cuanto a Oracle XE, explico en una entrada de mi blog personal de la VMware Community porqué no es válido para ejecutar sobre él, las bases de datos de vCenter ni siquiera para entornos de prueba/laboratorio.

http://communities.vmware.com/people/elgreco81/blog/2013/02/23/oracle-express-with-vcenter-server-database

Reducción del número de licencias en entornos de recuperación ante desastres

En el siguiente diagrama se enseña un modelo de Disaster Recovery utilizando VMware Site Recovery Manager y en el que se intenta evitar “sobre-licenciar” la infraestructura. Por lo menos hasta que ocurra un desastre y haya que hacer un failover.

Imagen

La idea es simple:

1)      Replicación asíncrona de las bases de datos (no de los ejecutables).

Con esto tendremos a resguardo y disponible la información.

2)      Pruebas de recuperación de las copias en los hosts licenciados en el site primario.

Simplemente para verificar que lo que estamos copiando, es recuperable. En este escenario las pruebas se realizan utilizando la WAN que nos une al site secundario, con el impacto correspondiente en el rendimiento. Pero bueno, se trata de probar la fiabilidad del sistema y el rendimiento no es un factor relevante en este tipo de pruebas.

3)      En caso de tener que realizar un failover, habrá que licenciar los nodos en el site secundario según se vayan a utilizar.

Resumiendo:

Existen varias formas de licenciar y varias ediciones de Oracle siendo el licenciamiento por socket el más debatido.

VM 3 de Oracle es el único hipervisor que permite no tener que licenciar todos los procesadores físicos sino los procesadores virtuales que la máquina virtual que ejecuta Oracle utiliza. Existen ciertas condiciones que se deben cumplir para que esto sea así.

Existen formas de reducir el número de licencias necesarias incluso con VMware, si se diseña el entorno aprovechando al máximo las capacidades de las soluciones de VMware y conociendo los modelos de licenciamiento de ambos fabricantes.

Cualquier host de VMware ha de contar con todos sus procesadores físicos cubiertos por el licenciamiento de Oracle. Esto también permite que se puedan crear n máquinas virtuales que ejecuten Oracle sobre ese host.

Espero haber aclarado algunas cosas y haber dejado en un post, si bien no toda la información al respecto, una guía bastante completa a efectos de licenciamiento de Oracle sobre vSphere y en la cual existen los links oficiales a la información que no incluí en este post.

La multa por violar el acuerdo de licenciamiento puede llegar a ser extremadamente alta (he visto ejemplos que hablaban de millones de dólares…), tanto en entornos virtualizados como físicos. Cualquier precaución está más que justificada y cualquier pregunta debería ser más que bienvenida tanto por parte de fabricantes como por parte de sus canales de distribución. Os animo a que preguntéis siempre todas vuestras dudas y agradeceré cualquier información que podáis añadir a lo ya escrito en este post J

Si os gustó el post, por favor compartid el link en vuestras redes sociales. Tal vez también le sea de utilidad a otros y así también nos estaréis echando un cable en dar a conocer este blog!

Saludos y gracias por leernos!!!