Chubascos Blog

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

Archivos por Etiqueta: ESXi

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

Hola,

Vamos con la cuarta 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 los requerimientos y configurar NPIV.

En un fabric se encuentran varios tipos de puertos. Entre ellos los N_port, E_port, U_port y F_port. Los puertos que nos ocupan, los N_port, utilizados en los nodos que se conectan a un switch de fibra o a otro N_port en una conexión punto a punto, se identifican con una especie de MAC address que se llama “world wide name” de las siglas WWN. Al igual que una MAC address, este ID es único para cada port dentro del fabric. Una de las capacidades del protocolo Fibre Channel (alguna vez escuché que se escribe “Fibre” para distingirlo de una conexión que va por fibra “fiber” aunque si lo busco en el traductor aparecen las dos como válidas) es que permite virtualizar este ID, de forma que podamos asignar más de un ID a un mismo N_port físico. Por esto veremos que a veces uno habla del WWN del nodo o del port. Los puertos virtuales se crean y eliminan cada vez que uno enciende y apaga la VM. Para las operaciones de vMotion, este puerto (VPORT) se borra del host origen y “viaja con la máquina” para volver a ser creado en el host destino. A todos los efectos se comporta dentro de nuestro fabric como un puerto más de tipo N. Para los casos en que a una VM no le asignemos un VPORT, la misma utilizará el WWN del nodo para identificarse dentro de nuestro fabric.

vSphere permite aprovechar esta funcionalidad para que podamos presentarle a nuestras VMs, HBAs virtuales con distintos IDs y puertos. Cormac Hogan en su blog (la referencia a este blog está en la bibliografía) no termina de ver claro para qué se puede querer algo así. Leí una vez en el libro de vSphere Design Best Practices al cual ya no tengo acceso, que uno de los usos para este tipo de tecnología podía ser realizar zonings y/o maskings ya que este tipo de consideraciones era pertinente en la fase de diseño del storage y de los hosts (tipos y número de HBAs).

Vemos los requerimientos de esta tecnología:
– Sólo trabaja con discos RDM.
– HBAs compatibles con NPIV.
– Las HBAs de un host que accedan a la misma LUN deben ser de un único fabricante.
– Si un host utiliza paths de varias HBAs físicas para acceder al storage, la VM que utilice NPIV deberá estar en todas esas zonas. Esto es un requerimiento para soportar multipathing.
– Las HBA físicas del host deben tener acceso a las LUNs que queramos que nuestras VMs con los NPIV configurados tengan acceso.
– Los switches en el fabric tienen que soportar NPIV.
– Asegurarse que el NPIV ID configurado en LUN sea el de el NPIV ID del target que le queremos configurar.

Capacidades o funcionalidades soportadas por NPIV:
– vMotion. La VM retiene el WWN virtual asignado. También se puede hacer vMotion de esa VM a un host con HBAs que no soporten NPIV. En este caso la VM utilizaría el WWN del nodo (el WWN de la HBA física). Perderíamos zonnings y maskings hechos a la NPIV_ID. Para poder hacer vMotion, el RDM tiene que estar en el mismo datastore que el fichero de configuración (.vmx) de la VM.
– Para storages activo/activo que soporten I/O concurrentes, los I/Os concurrentes de 2 puertos NPIV también están soportados.

Limitaciones:
– Es necesario que la HBA física esté conectada a un switch de fibra. Dicho de otra forma no soporta DAS.
– Cuando se clona una VM o se despliega una desde una plantilla, el WWN asignado no persiste.
– Storage vMotion no está soportado.
– Deshabilitar y volver a habilitar la funcionalidad de NPIV en un switch puede provocar un fallo en el link y que por tanto se detengan las I/Os…supongo que esto según como puede llegar a estropear datos.

Si queréis ver cómo se configura, os recomiendo este link. http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html

Yo no lo puedo probar en mi lab que lo tengo todo por red…el tema fibra evidentemente se me iba de presupuesto 🙂

No obstante, estos son los pasos según la documentación de VMware.

Asignar WWNs a las VMs en el cliente Web de vSphere:
– Seleccionar y editar la VM.
– Dentro de VM Options, expandir las opciones de “Fibre Channel NPIV” para ver las opciones.
– Deseleccionar el checkbox “Temporarily Disable NPIV for this virtual machine” .
– Seleccionar “Generate new WWNs”.
– Especificar el número de WWNNs (World Wide Node Name o el que se asigna a la VM) y WWPNs (World Wide Port Name o los que se asignan a cada WWNN). Se necesitan un mínimo de 2 WWPN para soportar failover con NPIV.
– Dar de alta los WWNs en el switch y configurar los zoning/masking deseados.
– Asignar las LUNs deseadas a los WWNs creados.

En estos pasos no consta la creación previa de un disco de tipo RDM…recordad que es condición necesaria para poder utilizar NPIV. En este link veréis una guía que sí contempla los pasos incluidos la creación de la VM con el RDM http://goo.gl/rNUccr

El post de hoy ha sido particularmente corto pero no he tenido tiempo para más. Espero que os sea de utilidad. Si os gustan estos posts y creéis que a alguien más le pueden ser de utilidad, por favor compartid el enlace :).

Saludos,
Sebastián Greco

Bibliografía utilizada para escribir este post:

http://goo.gl/uDboJR
http://en.wikipedia.org/wiki/Fibre_Channel#Ports
http://en.wikipedia.org/wiki/NPIV
http://www.valcolabs.com/2012/05/12/objective-1-1-implement-and-manage-complex-storage-solutions/
http://blogs.vmware.com/vsphere/2011/11/npiv-n-port-id-virtualization.html
http://blog.scottlowe.org/2009/11/27/understanding-npiv-and-npv/

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

Hola,

En esta entrada nos meteremos de lleno en “Capacidad y habilidades del objetivo 1.1. A ver hasta donde llegamos hoy.

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 los casos de uso y configurar VMware DirectPath I/O.
Empezaremos por ver qué es VMware DirectPath I/O. Me sería imposible sintetizar más la propia descripción que VMWare hace de esta característica por lo que traduciré su definición y agregaré algunas líneas.

DirectPath I/O permite a las VMs acceder a las funciones de los dispositivos PCI de forma directa, en plataformas que dispongan de una unidad de gestión de I/O de memoria o de sus siglas en inglés “IOMMU”, habilitada en la BIOS.
Para AMD es AMD-Vi y para Intel es VT-d. Realmente quien permite este acceso directo es el hardware…DirectPath I/O en VMware es la característica que permite aprovechar esta funcionalidad del hardware.

Las siguientes funcionalidades no están disponibles para las VMs que tengan DirectPath I/O:
– Añadir o quitar dispositivos virtuales en caliente (Hot add).
– Operaciones de suspend/resume.
– Operaciones de record/play.
– Fault tolerance.
– High availability.
– vMotion (cambio lo que pone el doc. de VMware ya que no mencionan en esta sección lo de vMotion, sino que aquí ponen DRS).
– Snapshots.

Las siguientes funcionalidades están sólo disponibles para las VMs que tengan DirectPath I/O configurado en UCS de Cisco con switches distribuidos VM-FEX.
– vMotion
– Añadir o quitar dispositivos virtuales en caliente (Hot add).
– Operaciones de suspend/resume.
– High availability.
– DRS (venga va…lo ponemos 🙂 ).
– Snapshots.

Una limitación que no vi en el link que os comento (en la bibliografía están todos los links de donde saco la info) es que un dispositivo con DirectPath I/O no puede ser presentado a más de una VM por con DirectPath I/O (sí se podría presentar a otra VM mediante emulación/paravirtualización aunque parece que da problemas). Tampoco mencionan NIOC. Aunque sea obvia, está bien mencionarla creo.
Adicionalmente, en los configurations maximums vemos los máximos soportados de esta tecnología (ojo que mezcla DirectPath I/O con SR-IOV que veremos más adelante).


VMDirectPath PCI/PCIe devices per host 8
SR-IOV Number of virtual functions 64 (43 en NICs Intel soportadas y 64 en NICs Emulex)
SR-IOV Number of 10G pNICs 8
VMDirectPath PCI/PCIe devices per virtual machine 4 (hasta 6 si 2 de ellos son Teradici)

Creo que este tipo de lista es importante prestarle atención…me late a mi que se pueden esperar preguntas del tipo “configura DRS en el cluster” y que luego resulta que hay máquinas que tienen DirectPath I/O habilitado y uno se vuelva loco buscando el motivo por el cual esas VMs no migran. Esas preguntillas que a uno tanto le gustan en un test jejeje!

Ok…hasta aquí la definición pero no es lo que pedía el bluprint. Por tanto, cuáles son los casos de uso de una tecnología del estilo y más aun sabiendo que tiene tantas limitaciones excepto en los UCS?

La respuesta parece fácil: RENDIMIENTO.
Como sabréis, vSphere ofrece a las VMs 3 formas de gestionar los I/Os de red. Mediante emulación (e1000 por ejemplo), paravirtualización (vmxnet3 por ejemplo) y accediendo directamente al dispositivo (ahí entra DirectPath I/O). Sabido es también que el rendimiento de una vmxnet3 es muy alto y soporta perfectamente cargas de más 10Gbs sin problemas. Entonces ¿DirectPath qué es lo que aporta? Lo que aporta esta tecnología es descargar a nuestro micro de la tarea de tener que gestionar una carga tan elevada de I/Os y LATENCIAS más bajas en las comunicaciones. Además de RENDIMIENTO, también pueden existir ciertas características físicas de nuestras NICs que serán aprovechadas por nuestras VMs si pueden hablar directamente con la NIC. Este es el caso de TCP offload engine para algunas HBA/S.O.s o SSL offload.
El secreto de cuándo utilizar DirectPath I/O y cuándo no, es cuando queremos obtener el máximo rendimiento de una VM que deberá gestionar un número muy elevado de paquetes IP. Estamos hablando en el orden de los 300.000 por segundo! Para cargas de unas 8.000, el rendimiento es el mismo que con una NIC paravirtual y en casos como los de servidores de base de datos donde pueden haber muchos menos paquetes pero de tamaños mayores, el rendimiento es MEJOR en tarjetas virtuales que en una con DirectPath I/O!!! 🙂 Esto no lo sabía yo jejeje! Si estáis preparando el examen del VCAP-DCA, repito, no os quedéis con lo que yo escribo aquí ya que se trata de un resumen de las cosas que leí. Id a las fuentes. En este caso podréis ver las gráficas de rendimiento y las cargas que VMware testeó. Adicionalmente y de forma explícita, VMware recomienda este tipo de adaptadores para cargas muy sensibles a las latencias y cita el caso de las aplicaciones de “stock traiding”. Existe una diferencia de unos 10microsegundos (no confundir con ms) en las latencias de un test de round-trip.

Vamos a configurar DirectPath I/O

1. Desde el vSphere WebClient (no utilizaré el cliente instalable para nada…limitaré el estudio al Cliente Web. Adaptarse o morir 🙂 )

Home > Hosts and Clusters > Seleccionar el host > Manage > Advanced y hasta aquí llego porque recibo el mensaje de “DirectPath I/O Not supported”. Si no fuera así, se listarían los dispositivos que soportan esta tecnología.
Un icono verde significa que el dispositivo está activado y habilitado para DirectPath I/O.
Un icono naranja significa que el estado del dispositivo ha cambiado y que el host debe ser reiniciado para poder utilizar el dispositivo.

Como nota al margen, VMware requiere que antes de quitar un dispositivo que se utiliza para DirectPath I/O, se deshabilite el mismo ANTES de quitarlo. Si nos queremos ahorrar el reinicio, una forma poco ortodoxa de deshabilitar DirectPath I/O podría ser descargar el módulo. Para ello se podría ejecutar: /usr/lib/vmware/vmkmod/vmkload_mod -u vtd

Ahora que está el dispositivo habilitado en el host, es hora de configurarlo en una VM.

Home > VM and Templates > Seleccionar la VM (no sé si ha de estar apagada o puede estar encendida, en cualquier caso supongo que deberá reiniciarse puesto que DirectPath I/O no soporta Hot Add > Manage > VM Hardware > Edit > New device > PCI Device y hasta aquí llego sin dispositivos que lo soporten en mi lab. En la bibliografía veréis que hay un link con alguien que sí lo configura y muestra las capturas de pantalla.

Al añadir este tipo de dispositivo, se creará de forma automática una reserva de memoria igual al tamaño de la RAM de la VM.

Para configurar DirectPath I/O para que la VM soporte vMotion. Aquí simplemente copio y pego los pasos de la guía oficial de VMware.


You can enable DirectPath I/O with vMotion for virtual machines in a datacenter on a Cisco UCS system that has at least one supported Cisco UCS Virtual Machine Fabric Extender (VM-FEX) distributed switch.
Prerequisites

Enable high performance network I/O on at least one Cisco UCS port profile on a supported Cisco VM-FEX distributed switch. For supported switches and switch configuration, see Cisco’s documentation at http://www.cisco.com/go/unifiedcomputing/b-series-doc.

Power off the virtual machine.
Procedure
1 Log in to the vSphere Client and select the VMs and Templates inventory view.
2 Right-click the virtual machine to modify and click Edit Settings.
3 On the Resources tab, select Memory.
4 Select Unlimited.
5 On the Hardware tab, select the network adapter to configure as a passthrough device.
6 Select a port profile with high performance enabled from the network label drop-down menu, and click OK.
7 Power on the virtual machine.
After the virtual machine is powered on, DirectPath I/O appears as Active on the Hardware tab of the virtual machine properties dialog box.”

Bibliografía utilizada en este post:
http://goo.gl/veuhRb
http://en.wikipedia.org/wiki/X86_virtualization
http://goo.gl/nQQ6Z1
http://goo.gl/wWxl5
http://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf
http://goo.gl/mOvPdd
http://goo.gl/RYSwws
http://goo.gl/rkRu1K
http://theithollow.com/2012/07/vmdirectpath-io-basic-setup/
http://www.vmware.com/files/pdf/techpaper/network-io-latency-perf-vsphere5.pdf
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805
http://en.wikipedia.org/wiki/Round-trip_delay_time
http://infrastructureadventures.com/tag/directpath-io/
http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
http://www.vm-help.com/esx40i/VMDirectPath/fix_config_issues.php
http://www.valcolabs.com/2012/05/12/objective-1-1-implement-and-manage-complex-storage-solutions/

Hubiera querido tratar más temas en el post pero creo que por hoy es suficiente 🙂 Por favor, dejad vuestros comentarios, sugerencias y aportaciones que serán bienvenidos!

Hasta la próxima,
Sebastián Greco

Creación de USBs de arranque para Hyper-V Server y vSphere

Hola amigos!

Como algunos de vosotros habréis visto, nuestro laboratorio no cuenta con discos duros locales en los hosts, con lo que hay que buscar otras alternativas para la ejecución del hypervisor en los mismos.

Para quienes lo hayáis hecho anteriormente, seguramente se trate de un procedimiento que no ofrece ningún desafío. Sin embargo, para quienes no lo habéis hecho o tenéis dudas de su funcionamiento, veréis que es fácil y puede ser muy cómodo además de económico (servidores sin disco duro pueden resultar en un ahorro nada despreciable).

Antes de ir al lío, unas consideraciones generales del sistema y la BIOS:
– Se deben cumplir los requerimientos mínimos de hardware de cada uno de los fabricantes.
– Activar virtualización ahí donde sea posible 🙂 (EPT, RVI, VT-x, etc).
– Deshabilitar dispositivos que no se van a utilizar es otra buena idea…por ejemplo puertos paralelos.
– Se recomiendan configurar los modos de ahorro de energía a “OS Controlled Mode” o similar, así como asegurarse que están todos los cores habilitados.
– Ambos sistemas son “NUMA aware” por lo que casi mejor activarlo en la BIOS. Normalmente suele ser una configuración llamada “Node interleaving” que hay que dejar en estado “Disabled”. “Enabled” significa que está en modo UMA de Uniform Memory Access.
– Si es posible, habilitar Hyperthreading y/o Turbo Boost.
– Ya que la idea es “arrancar” desde un USB, el orden de arranque es importante. Comprobad que USB esté primero o en su defecto, utilizar las opciones de arranque para seleccionar el FBD (First boot device).

Empezaremos por la configuración de un USB con vSphere, como bien explica Bolo Álvarez en su blog – http://mecongratula.es/, el procedimiento es el siguiente:

vSphere (4 pasos extremadamente simples)
1) Descargar y ejecutar UNetbootin – http://unetbootin.sourceforge.net/
2) Descargar la ISO de ESXi – https://my.vmware.com/web/vmware/evalcenter?p=free-esxi5&lp=default (necesitaréis crearos una cuenta en caso que no dispongáis de una)
3) Formatear el USB en FAT32.
4) Ejecutar UNetbootin y “planchar” la ISO del ESXi en el USB. Precaución, esto borrará los datos del dispositivo que escojáis como destino. Aseguraos que el destino seleccionado es el USB que queréis.

Unebootini1

HyperV Server (12 pasos basándome en esta guía http://technet.microsoft.com/en-us/library/ee731893(WS.10).aspx)

1) Crear un VHD y montarlo.
– Lanzar un cmd y ejecutar las siguientes líneas:
– mkdir c:\hvvhd
– diskpart
– create vdisk file=c:\hvvhd\hyperV.vhd maximum=12288 type=fixed
– select vdisk file=c:\hvvhd\hyperV.vhd
– attach disk
– create partition primary
– assign letter=r
– format quick fs=ntfs label=hyperV
– exit

En este primer paso se creará un directorio de nombre “hvvhd” y desde la utilidad de “diskpart” se creará un disco virtual de nombre “hyperV.vhd” dentro del directorio “hvvhd” que se creó anteriormente. Este disco virtual tendrá un tamaño fijo de 12288 KB (para nuestro chubascos lab utilizamos 6144 puesto que nuestros USB son de 8 GB), lo que equivale a 12 GB. Dentro de este disco virtual se creará una partición de nombre “r” y se la formateará con un formato “rápido”, un file system de tipo “ntfs” y se le dará el nombre “hyperV”.

Paso1

2) Descargar e instalar Windows AIK (necesitaréis una cuenta para descargaros algunos elementos de esta guía)
http://go.microsoft.com/fwlink/?LinkId=136976
Esta guía hace referencia a la ruta de instalación por defecto de este software.

3) Descargar y montar la imagen de Windows Hyper-V Server
http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx
Nota: El archivo .wim al que se hará referencia en el siguiente punto está en la carpeta “sources” de esta ISO.

4) Aplicar el archivo install.wim en la partición del VHD que se creó en el paso 1 de esta guía.
Para ello, lanzar el cmd como usuario “Administrador” y ejecutar las siguientes lineas:
Ruta_Windows_AIK\Windows AIK\Tools\arquitectura\imagex.exe /apply path_al_wim 1 r:\

Paso4

5) Desmontar el disco virtual
Para ello, ejecutar los siguientes comandos en el cmd.
– diskpart
– select vdisk file=c:\hvvhd\hyperV.vhd
– detach vdisk
– exit

Paso5

6) Preparar el USB
Primero, identificar el disco con los siguientes commandos.
– diskpart
– list disk

Siguiente, limpiarlo, particionarlo y formatearlo.
– select disk número_del_USB_que_nos_devolvió_el “list disk”
– clean
– create partition primary
– select partition 1
– active
– format quick fs=ntfs label=hyperV
– assign letter=z

Paso6

7) Copiar el .vhd al USB

8) Compatibilizar el USB con Bootmgr
ruta_Windows_AIK\Tools\PETools\arquitectura\bootsect.exe /nt60 x: /force /mbr

Paso8

9) Montar el .vhd del USB
– diskpart
– select vdisk file=z:\HyperV.vhd
– attach vdisk
– exit

Paso9

10) Hacer el USB booteable
ruta_Windows_AIK\tools\arquitectura\bcdboot letra_partición_VHD\windows /s letra_partición_USB

11) Deshabilitar paging (la fresa en la nata)
Esto es por temas de performance, podéis probar sin hacerlo pero funciona mejor siguiendo esta recomendación de Microsoft.

Para ello hay que cargar el hive del registro del VHD del USB y configurar las entradas necesarias de las Page Files.

– reg load HKLM\HyperVTemp r:\windows\system32\config\system

– reg add “HKLM\HyperVTemp\ControlSet001\Control\Session Manager\Memory Management” /v PagingFiles /t REG_MULTI_SZ /d “” /f

– reg delete “HKLM\HyperVTemp\ControlSet001\Control\Session Manager\Memory Management” /v ExistingPageFiles /f

– reg unload HKLM\HyperVTemp

12) Desmontar el VHD y quitar el USB
– diskpart
– select vdisk file=x:\hyperV.vhd
– detach vdisk
– exit

Sí, el proceso de creación de este USB puede resultar más largo para HyperV Server y en mi experiencia personal, más complicado. Otra alternativa es intentar utilizar esta herramienta para facilitar el proceso.
http://archive.msdn.microsoft.com/BootHVSR2FromUSB. No la he probado y por lo que vi tiene algunas limitaciones que podrían hacer que no valiera para una instalación de la versión 2012 y menos en castellano. Pero bueno, a veces estas cosas aunque no lo especifiquen sí funcionan…todo es cuestión de probar.

Espero que os haya gustado esta pequeña guía que reúne en un único post, algo de lo que normalmente no se habla en las comparativas tipo “checklist” que tanto me disgustan.

En futuros posts intentaremos comentar un poco cómo se consigue levantar el hypervisor desde estos dispositivos USB y controlarlo remotamente.

Si este post ha sido de vuestro agrado o creéis que pueden resultar de interés para otros, por favor compartidlo en vuestras redes sociales 🙂 Si además tenéis algo que decir o aportar, por favor dejad un comentario!

Gracias por leernos,
Sebastián Greco

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?