Chubascos Blog

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

Archivos por Etiqueta: vSphere

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

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/

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 – 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?