Archivos de la categoría ‘OVM Server’

Oracle VM 3.0 Released

Publicado: noviembre 17, 2011 de NataS en OpenSource, Oracle, OVM, OVM Server, Virtualización, XEN
Etiquetas:, , , ,

Hace no mucho tiempo que Oracle liberó una nueva versión de su hypervisor para mantenerse en la linea y competir contra VMWare en su hegemonía de la virtualización empresarial (Si tienen dudas pueden consultar el último reporte que saco Gartner en Junio del 2011 ).

Pues bien, con este nuevo release, se vienen diferentes mejoras, asociadas al uso de las últimas versiones en casi todos sus componentes (la versión 2.2, aun usaba Xen 2.X #LOL):

  • High performance, high scalability, creo que es una de las características mas interesante. Oracle esta apostando mucho al “Cloud Computing”, sus nuevas versiones se denominan 12c en honor al cloud, así que con esta nueva versión de OVM, se sorporta hasta 160 CPU físicos y 2TB de RAM, además que podrán asignar a sus máquinas virtuales hasta 128 vCPU’s y 1TB de memoria.
  • Manejo Avanzado por ningún costo adicional, gracias a su nueva interfaz con ADF, se tiene una UI mas intuitiva y limpia. Además tiene integración directa con Enterprise Manager. Entre otras cosas esta nueva versión cuenta con soporte para administrar, maquinas virtuales basadas en políticas, Dynamic Resource Scheduling, Dynamic Capacity y finalmente Power Management.
  • Configuración y administración central del almacenamiento, lo que permite manejar el almacenamiento de forma autómatica, de hecho una de las nuevas características del OVM 3.0, es que ya detecta el almacenamiento en automático para cada OVM Server.
  • Configuración y Administración Central de la Red, ahora toda la configuración lógica de la red es realizada desde la consola de administración (OVM Manager), permitiendo generar desde una amigable interfaz gráfica port bounding, bridges y VLAN’s
  • Soporte OVF, la estandarización se da en OVM dando soporte a software basado en OVF (Open Virtualization Format), para acelerar el despliegue de máquinas generados por terceros.
  • Rápido provisionamiento y clonado de VM’s, el soporte de archivos SPARSE en OCFS, permite una ganancia en performance al crear y clonar máquinas virtuales. Ademas gracias a las nuevas características de OCFS, ahora se puede clonar cualquier maquina virtual e iniciarla en cualquier servidor del Pool al momento gracias a su copy-on-write.
  • Soporte para Solaris, OpenSolaris, Linux y Windows
  • XEN 4.0
  • OCFS 1.6, gracias a la nueva versión de OCFS y su característica denominada REFLINK es posible hacer snapshots de la maquina virtual en caliente. Para más información de las nuevas mejoras con este sistema de archivos pueden revisar La Guia de Usuario de OCFS

El producto sigue siendo gratuito, con opción de soporte. Este último tiene algunas ventajas muy significativas, como el hecho que cualquier OEL instalado como guest va sin licencia con soporte.

Sinceramente y a nivel personal tiene muy buena pinta, de hecho la interfaz ya es tan intuitiva como Proxmox y las capacidades para niveles empresariales son bastante aceptables.

Como nota curiosa, el CERN, ha implementado Oracle VM en sus equipos. Y si quieren conocer todos los clientes de Oracle que cuentan con Oracle VM y como han realizado su implementación pueden visitar Este Sitio.

Finalmente recuerden que a pesar de que los productos de Oracle están soportados en otros hypervisor, estos no están certificados… así que es un arriesgue.

Cualquier duda, queja o sugerencia, es bienvenida.

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio

Anuncios

Debido a una modificación en la arquitectura inicial, se nos solicito mover unas maquinas virtuales (creadas con OVM) de su repositorio local hacia un “Storage” de SAN.
Esto porque mediante otro software se iban a replicar todos los cambios de un servidor a otro para tener un ambiente DRP. Debido a que “se queria” simplificar la administración no se hizo uso de las capacidades de H-A de OVM.
La siguiente guía puede ser aplicada en los siguientes escenarios (ya sea directa o indirectamente):

  1. Cuando se requiere migrar del storage local hacia un storage de Fibra Optica
  2. Cuando se copia bit a bit las VM’s y estas llegan a un servidor OVM que no fue configurado para ello
  3. Cuando se configuro un servidor con un repositorio inicial y los discos fueron cambiados lo que modifico a su vez los UUID’s

Los siguientes son los pasos necesarios para lograr la migración de la VM’s:

  1. Instalar y configurar los drivers de la tarjeta de fibra. Dependiendo de la marca, serán los pasos necesarios, la mayoría cuenta con sus drivers y únicamente es necesario compilarlos e instalarlos. En conjunto con este paso les recomendamos instalar las sg3-utils, las cuales les ayudarán a detectar issues con la configuración de las LUNS.
  2. Configurar el multipath, para ello deberemos editar el archivo /etc/multipath.conf y dejarlo acorde a la configuración de nuestro ambiente. El siguiente ejemplo es la configuración común de EMC y un Storage Clarion, por supuesto si leemos el manual de multipath.conf encontraremos más información al respecto.
    ## This is the /etc/multipath.conf file recommended for
    ## EMC storage devices.
    ## OS : RHEL5
    ## Arrays : CLARiiON
    ## Use user friendly names, instead of using WWIDs as names.
    defaults {
    user_friendly_names yes
    }

    ## The blacklist is the enumeration of all devices that are to be
    ## excluded from multipath control
    devnode_blacklist {
    ## Replace the wwid with the output of the command
    ## 'scsi_id -g -u -s /block/internal scsi disk name'
    ## Enumerate the wwid for all internal scsi disks.
    ## Optionally, the wwid of VCM database may also be listed here.
    # wwid 20010b9fd080b7321
    #devnode "sd[a]$"
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)0-9*"
    devnode "^hda-z"
    devnode "^cciss!c0-9d0-9*"
    }
    devices {
    ## Device attributes for EMC CLARiiON
    device {
    vendor "DGC"
    product "*"
    path_grouping_policy group_by_prio
    getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
    prio_callout "/sbin/mpath_prio_emc /dev/%n"
    hardware_handler "1 emc"
    features "1 queue_if_no_path"
    no_path_retry 300
    path_checker emc_clariion
    failback immediate
    }
    }

  3. En caso de que necesitemos re-scanear los dispositivos y/o las luns, es preciso ejecutar:
    echo “1” > /sys/class/fc_host/hostX/issue_lip
    echo “- – -” > /sys/class/scsi_host/hostX/scan
    Donde X es el ID asociado (normalmente) con cada tarjeta de fibra.
  4. Arrancar el demonio del multipath. Estó generará (en base al archivo antes descrito), los dispositivos con los cuales podremos trabajar. Para validar las configuraciones nos valdremos del comando multipath -ll el cual nos pintará los dispositivos:
    mpath1 (360060160539022006d7b78ce81b4df11) dm-1 DGC,RAID 5
    [size=52G][features=1 queue_if_no_path][hwhandler=1 emc][rw]
    \_ round-robin 0 [prio=2][active]
    \_ 0:0:1:1 sdf 8:80 [active][ready]
    \_ 1:0:1:1 sdn 8:208 [active][ready]
    \_ round-robin 0 [prio=0][enabled]
    \_ 0:0:0:1 sdb 8:16 [active][ready]
    \_ 1:0:0:1 sdj 8:144 [active][ready]
    mpath0 (360060160539022006c7b78ce81b4df11) dm-0 DGC,RAID 5
    [size=52G][features=1 queue_if_no_path][hwhandler=1 emc][rw]
    \_ round-robin 0 [prio=2][active]
    \_ 0:0:0:0 sda 8:0
    [active][ready]
    \_ 1:0:0:0 sdi 8:128 [active][ready]
    \_ round-robin 0 [prio=0][enabled]
    \_ 0:0:1:0 sde 8:64 [active][ready]
    \_ 1:0:1:0 sdm 8:192 [active][ready]
  5. Una vez con los dispositivos /dev/mapper/mpathX generados, procederemos a particionarlos, usando para ello el comando fdisk /dev/mapper/mpathX
  6. Ya particionadas las unidades debemos solicitar al servidor a leer la nueva tabla de particiones, para ello podemos o reiniciar o forzar la lectura de la misma. En este caso nos ocuparemos de “forzar” al servidor, usando para ello la siguiente secuencia de comandos (para más información consulta la página del manual del comando):
    kpartx -a /dev/mapper/mpathX
    kpartx -l /dev/mapper/mpathX
  7. Después se deben formatear las particiones generadas con el sistema de archivos OCFS2, una configuración aceptable es la siguiente:
    mkfs.ocfs2 -T datafiles -N 8 -L “VOL_NAME” /dev/mapper/mpathXp1
    Sin embargo, les recomendamos leer la página del manual del comando y ajustarse de acuerdo a sus necesidades específicas.
  8. Ahora es cuando debemos apagar las máquinas virtuales que estén corriendo en el OVM-server
  9. Agregamos el storage de la SAN como repositorio, para ello hacemos uso del siguiente comando que esta ubicado en /opt/ovs-agent-2.3/utils/ :
    ./repos.py -n /dev/mapper/mpathXp1
    En caso de tener diferentes storages, agregamos cada uno de ellos, y una vez que se hayan agregado todos, los inicializamos ejecutando el siguiente comando:
    ./repos.py -n /dev/mapper/mpathXp1
  10. Agregados todos los repositorios solo basta inicializarlos con el comando: ./repos.py -i

  11. Finalmente solo resta mover las maquinas virtuales a su destino, en general la ruta de destino debe ser:
    /var/ovs/mount/$PAT_UUID/running_pool/
  12. Lo único que resta es encender lás maquinas virtuales, las cuales se pueden encender desde el OVM-manager, o para los desesperados directamente desde linea de comandos con:
    xm create $PATH_TO_VM/vm.cfg

Obviamente, con sus respectivas modificaciones, se puede lograr que estos pasos funcionen para un esquema iScsi, o inclusive solo para activar la SAN para cualquier sistema GNU/Linux sin necesidad de virtualización.

Dudas y/o comentarios son bienvenidos (y requeridos)!

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>