Chubascos Blog

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

Archivos en la Categoría: Oracle

vCloud Director – Primeros pasos

El post de hoy va dedicado a los requisitos y la instalación de vCloud Director y todos los servicios necesarios para ponerlo en marcha.

vCloud

vCloud Director es la solución que nos proporciona VMware para poder ofrecer IaaS (Infraestructura entregada como un servicio) a los distintos clientes internos o externos que nos demanden este tipo de recursos. Como veremos a continuación, este tipo de solución necesita de productos adicionales que nos brinden la abstracción de los distintos recursos de computación, almacenamiento y servicios de red, y según el tipo de despliegue podremos automatizar en mayor o menor medida la provisión de los recursos de infraestructura virtuales necesarios. VMware ya se ha encargado que todos estos productos adicionales necesarios estén incluidos en el licenciamiento de su vCloud Suite.

Requisitos para el despliegue de vCloud Director

Para poder desplegar vCloud Director necesitaremos tener desplegados:

    • Hosts ESXi
  • vCenter Server
  • vShield Manager
  • vCloud Director Cells
  • vCenter Chargeback (opcional. Desplegaremos este servidor si queremos facturar los servicios consumidos por los distintos clientes)

Las buenas prácticas de VMware nos indican que siempre que podamos despleguemos un clúster de vSphere para ubicar los servidores de gestión del entorno (vCenter Server, vShield Manager, vCloud Director Cells, etc.) y uno o más clústers utilizados como granjas de computación y destinados a ubicar las cargas desplegadas dentro del entorno de Cloud. Podemos ver un ejemplo a continuación:

vCloud Clusters

Esta configuración garantizará que en caso que haya algún problema en las granjas de computación, esto no afecte a los distintos servicios de gestión del entorno de Cloud.

vCloud Cells

Las vCloud Cells son las encargadas de, por un lado, proveer de un portal web de autoservicio y por otro lado de hacer de director de orquesta comunicándose con vShield Manager para la automatización del despliegue y destrucción de las redes creadas en este entorno, y con vSphere (vCloud y los hosts ESXi) para el despliegue de VMs, operaciones de encendido, apagado, snapshots, etc.

Las vCloud Cells necesitan de ciertos servicios adicionales que per-sé no proveen:

  • Load Balancer
  • Share NFS
  • Base de Datos

Load Balancer

Como bien hemos comentado, las vCloud Cells son servidores web, y por tanto si queremos ofrecer redundancia y además evitar que ninguna de nuestras Cells se sobrecargue necesitaremos balancear la carga. Para ello podemos utilizar cualquier producto existente en el mercado, como por ejemplo los balanceadores de F5, Riverbed, etc. aunque podemos también buscar una opción comercial y además gratuita para nuestro entorno: vShield Edge.

vShield Edge, para el entorno de vCloud viene licenciado dentro del recientemente renombrado paquete “vCloud Networking and Security” y entro otros servicios típicos de un Firewall (VPN IPSec, SNAT, DNAT, DHCP, etc) también nos puede ofrecer balanceo de carga y podemos aprovecharlo para balancear también nuestras vCloud Cells. Cabe destacar que también, a partir de vCloud 5.1, se puede configurar este balanceo de carga desde el Web GUI de vCloud Director.

Share NFS

En caso que queramos desplegar más de una vCloud Cell (Entiendo que en 99,9% de los casos que queramos entrar en producción) necesitaremos de un recurso compartido NFS que será donde guardaremos los datos comunes a los que necesitan acceder las distintas vCloud Cells. En este share NFS se ubicarán:

  • Archivos de los catálogos de vCloud Director
    • Plantillas de vApps
    • ISOs y otros medios

Ojo, la gestión y guardado de los archivos mencionados es realizado por vCloud, así que no deberemos copiar manualmente las ISOs ni plantillas en este recurso compartido, sino deberemos hacerlo a través de vCloud Director.

Aunque no necesario, también es recomendable ubicar en este recurso compartido:

  • Certificados usado para nuestras vCloud Cells
  • Archivos de sysprep

La recomendación de ubicar también estos archivos es debido a que cada vez que debamos añadir una nueva vCloud Cell, necesitaremos de estos archivos, y de esta manera evitaremos tener que ir copiando archivos a las Cells a través de ssh y los tendremos ubicados en un almacenamiento visible por todas las Cells.

Base de Datos

Por último, el ingrediente que nos falta para tener las vCloud Cells totalmente funcionales es un servidor de Base de Datos. vCloud soporta 2 tipos de bases de datos desde la versión 5.1: Oracle DB y Microsoft SQL Server. No entraremos más en detalle respecto a estos tipos de servicios, que son ya de sobras conocidos. Tan solo a nivel de puntualización, comentar que al contrario que otros productos de VMware donde tenemos un asistente “siguiente, siguiente”, para la creación de nuestra base de datos deberemos lanzar unos cuantos scripts contra nuestra BBDD proporcionados por VMware y que harán un poco más tediosa nuestra instalación.

Seguiremos en los próximos posts con los distintos tipos de redes que nos encontramos en vCloud, tipos de Network Pools, Virtual DataCenters, etc. Manteneros atentos!

Saludos,

Sergi de la Torre

Anuncios

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!!!

Bases de datos Oracle sobre VMware vSphere – Soporte

Hola amigos,

Soy Sebastián Greco, un apasionado más sobre las tecnologías de virtualización y Cloud Computing. En esta ocasión quiero compartir con vosotros los conocimientos adquiridos mediante varios medios en lo referente a la virtualización de las bases de datos Oracle sobre la plataforma de VMware. Puesto que es un tema que da de sí, este será el primer post de una serie de posts sobre este tema.

A todos los que nos hemos enfrentado a proyectos de virtualización de bases de datos Oracle, se nos han planteado preguntas referentes al rendimiento, el licenciamiento, soporte y disponibilidad. A aquellos que han tenido que plantear migraciones entre plataformas con tipos de Endian distintos (migraciones de plataformas RISC a x86), las preguntas habrán incluido también cuestiones en cuanto a métodos de migración más complejos. Intentaré abordar todos los temas y en este primer post, el que según mi opinión genera más “temor” entre muchos de los usuarios habituados a trabajar con bases de datos Oracle y a la virtualización con VMware, pero por separado 🙂

El temor a no recibir soporte o a tener problemas de compatibilidad entre vSphere y las bases de datos Oracle, como tantos otros temores se deben al desconocimiento y/o desinformación. Dicho esto, la solución es fácil:

Informarse e informar.

Son varios los argumentos, sobre todo provenientes de VMware los que intentan mitigar estos temores.

Como punto más destacable, VMware cuenta con una política de soporte específicamente orientada a las bases de datos Oracle. Este artículo muestra el compromiso del fabricante en este aspecto y puede jugar un papel importante en la toma de decisiones. No tiene desperdicio:

http://www.vmware.com/support/policies/oracle-support.html

Algunos de los puntos más destacados de este artículo en mi opinión son:

–       Provide any relevant evidence that virtualization does not play a part in the Oracle product technical problem

Sacado de contexto puede sonar mal, pero recordad que en esta ocasión estoy citando las características del soporte de VMware!!! Por lo que este punto significa que es el propio VMware el que se compromete a ayudarnos a presentar la evidencia que Oracle nos puede llegar a solicitar.

–       “…as part of the existing Support and Subscription contract at no additional charge”

Esto es gratis! Esta política de soporte se incluye en el SnS “normal”. No se trata de ninguna especie de “add-on” o “extensión” al soporte y subscripción contratados para la plataforma de vSphere.

–       Faster resolution of technical issues in VMware environments via a TSANet collaborative support arrangement between VMware Support and Oracle Support

SoporteTanto Oracle Support como VMware Support están vinculados por su participación mutua en TSANet.

Como comento anteriormente, el artículo no tiene desperdicio y todos los puntos son destacables y seguro que algunos de ellos sorprenderán a más de uno.

Todo esto está muy bien, ¿pero qué dice Oracle al respecto? Bueno, Oracle simplemente no certifica vSphere. ¿Qué quiere decir esto?

vSphere trabaja a un nivel Bare Metal. En este sentido, lo podríamos situar como un elemento más al mismo nivel que nuestros servidores físicos. Oracle no certifica servidores físicos Dell, HP, IBM,  la familia x86 de Sun, etc. Hasta tiene lógica que no certifique vSphere si se mira de este modo. Es de lo más normal que las cargas no virtualizadas de Oracle se ejecuten sobre alguna de estas plataformas físicas…muy posiblemente las mismas cargas que se tiene temor a virtualizar por ejectuarlas en una plataforma no certificada. ¿Se entiende lo irónico de la situación? 🙂

La diferencia entre “soportar” y “certificar”

Aplicado al soporte de los productos de Oracle en vSphere, se puede traducir en decir que Oracle aceptará y tratará sin distinción una incidencia en un sistema virtualizado sobre vSphere siempre y cuando se trate de un “known issue”. Caso contrario, se reserva el derecho de solicitar que se pruebe que el problema no es debido a las tecnologías de virtualización que soportan la infraestructura (aquí puede ser muy útil la ayuda del soporte de VMware). En un mundo idílico, se podría decir “asunto resuelto”, pero en la mayoría de los casos este tener que reproducir una incidencia en un sistema no virtualizado, puede significar tener un servicio crítico caído a la espera de replataformar un servidor físico…en caso que se cuente con uno “extra”. Existen dos formas de mitigar este temor:

1)      Un diseño de arquitectura en el cual se contemple un servidor físico capaz de ejecutar las cargas de Oracle para reproducir los errores. Benditos entornos de Pre-producción J

2)      Utilizar un entorno de pre-producción el tiempo necesario para comprobar que el soporte de Oracle no pone pegas

Lamentablemente, no existe a día de hoy ningún statement oficial que diga “sí! Lo soportamos todo sobre vSphere”. Sin embargo, se puede ver que argumentos no faltan. A aquellos que contéis con acceso a MyOracleSupport, los statements oficiales son:

942852.1

249212.1

Una buena opción es estudiar y presentar los casos de éxito publicados por VMware. En caso de ser un integrador/partner de VMware y contar con casos de éxito propios, aún mejor! Aquí os dejo un par de estos casos…sólo para tranquilizar que tampoco se está inventando la rueda con un proyecto de virtualización de Oracle…muy posiblemente gente con bbdd más grandes ya están virtualizados.

http://www.vmware.com/files/pdf/customers/11Q1_University_of_British_Columbia_Case_Study.pdf

http://www.vmware.com/files/pdf/customers/VMW_10Q1_CS_INDIANA_UNI_USLET_EN.pdf

Otra buena noticia es que desde hace algún tiempo Oracle soporta RAC sobre vSphere como se puede leer en unos de sus artículos de soporte (249212.1), desde la versión 11.2.0.2 y posteriores. Recordar que “soportar” no es “certificar” y que al igual que con la capa de hardware que no certifica (nuestros servidores, switches, etc), Oracle Support se reserva el derecho de solicitar la reproducción del error en otro host.

Por último pero no menos importante, en mi experiencia personal, jamás me vi en la situación en la que un DBA me dijera que tuvo problemas con Oracle Support por tener las bases de datos virtualizadas con VMware.
Y vosotros, ¿tenéis alguna experiencia para compartir al respecto?