{"id":82495,"date":"2020-05-22T01:42:27","date_gmt":"2020-05-21T23:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii"},"modified":"2020-05-22T01:42:27","modified_gmt":"2020-05-21T23:42:27","slug":"ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","title":{"rendered":"oVirt en 2 horas. Parte 1. Plataforma de virtualizaci\u00f3n de c\u00f3digo abierto y tolerante a fallos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introducci\u00f3n<\/h2>\n

\nProyecto de c\u00f3digo abierto oVirt<\/a><\/noindex> \u2014 una plataforma de virtualizaci\u00f3n de nivel empresarial. Al revisar habr, descubr\u00ed que oVirt<\/a><\/noindex> no se ha discutido aqu\u00ed tan ampliamente como merece.
\noVirt es b\u00e1sicamente el upstream para el sistema comercial Red Hat Virtualization (RHV, anteriormente RHEV), creciendo bajo el ala de Red Hat. Para evitar confusiones, esto no<\/b> es lo mismo que CentOS vs RHEL, el modelo es m\u00e1s parecido a Fedora vs RHEL.
\nBajo el cap\u00f3 \u2014 KVM<\/a><\/noindex>, se utiliza una interfaz web para la gesti\u00f3n. Est\u00e1 basado en RHEL\/CentOS 7.
\noVirt puede ser utilizado tanto para virtualizaci\u00f3n de servidores \"tradicional\" como de escritorio (VDI), a diferencia de la soluci\u00f3n de VMware, ambos sistemas pueden coexistir en un mismo entorno.
\nEl proyecto est\u00e1 bien documentado<\/a><\/noindex>, ha alcanzado la madurez para aplicaciones productivas y est\u00e1 listo para altas cargas.
\nEste art\u00edculo es el primero de un ciclo sobre c\u00f3mo construir un cl\u00faster redundante en funcionamiento. Siguiendo estos pasos, en un corto per\u00edodo (alrededor de 2 horas) obtendremos un sistema completamente funcional, aunque no se podr\u00e1n abordar varios temas, tratar\u00e9 de iluminarlos en los siguientes art\u00edculos.<\/a><\/noindex>
\nLo hemos estado utilizando durante varios a\u00f1os, comenzamos con la versi\u00f3n 4.1. Nuestro sistema industrial ahora funciona en los servidores HPE Synergy 480 y ProLiant BL460c de 10\u00aa generaci\u00f3n con CPU Xeon Gold.
\nEn el momento de escribir esto, la versi\u00f3n activa es la 4.3. <\/p>\n

Art\u00edculos<\/h2>\n

<\/p>\n

    \n
  1. Introducci\u00f3n (Estamos aqu\u00ed)<\/li>\n
  2. Instalaci\u00f3n del administrador (ovirt-engine) y hipervisores (hosts)<\/a><\/noindex><\/li>\n
  3. Configuraciones adicionales<\/a><\/noindex><\/li>\n<\/ol>\n

    Caracter\u00edsticas funcionales<\/h2>\n

    \nEn oVirt hay 2 entidades principales: ovirt-engine y ovirt-host(s). Para aquellos que est\u00e1n familiarizados con los productos de VMware, oVirt en general como plataforma es vSphere, ovirt-engine \u2014 la capa de gesti\u00f3n \u2014 cumple las mismas funciones que vCenter, y ovirt-host es el hipervisor, como ESX(i). Dado que vSphere es una soluci\u00f3n muy popular, a veces har\u00e9 comparaciones con ella.
    \n\"oVirt
    \nFig. 1 \u2014 panel de control de oVirt.<\/p>\n

    Se admite la mayor\u00eda de las distribuciones de Linux y versiones de Windows como m\u00e1quinas invitadas. Para las m\u00e1quinas invitadas hay agentes y dispositivos virtuales optimizados y controladores virtio, principalmente el controlador de disco y la interfaz de red.
    \nPara implementar una soluci\u00f3n de alta disponibilidad y todas las funciones interesantes se requerir\u00e1 almacenamiento compartido. Se admiten tanto el almacenamiento en bloque FC, FCoE, iSCSI, como los almacenamiento de archivos NFS, entre otros. Para implementar una soluci\u00f3n de alta disponibilidad, el sistema de almacenamiento tambi\u00e9n debe ser redundante (m\u00ednimo 2 controladores, multipathing).
    \nEl uso de almacenamiento local es posible, pero por defecto, solo se pueden utilizar almacenamientos compartidos para un cl\u00faster real. Los almacenamientos locales convierten el sistema en un conjunto desarticulado de hipervisores, y aunque haya un almacenamiento compartido, no ser\u00e1 posible formar un cl\u00faster. La opci\u00f3n m\u00e1s adecuada es utilizar m\u00e1quinas sin disco con arranque desde SAN o discos de volumen m\u00ednimo. Probablemente, mediante un vdsm hook, es posible ensamblar almacenamiento definido por software (por ejemplo, Ceph) a partir de discos locales y presentarlo a las m\u00e1quinas virtuales, aunque no se ha considerado seriamente.<\/p>\n

    Arquitectura<\/h4>\n

    \n\"oVirt
    \nFig. 2 \u2014 arquitectura de oVirt.
    \nPara m\u00e1s detalles sobre la arquitectura, puedes consultar la     la documentaci\u00f3n<\/a><\/noindex> documentaci\u00f3n del desarrollador.<\/p>\n

    \"oVirt
    \nFig. 3 \u2014 objetos de oVirt.<\/p>\n

    El elemento superior en la jerarqu\u00eda es el Centro de Datos<\/b>. Este define si se utilizan almacenamientos compartidos o locales, as\u00ed como el conjunto de funciones disponibles (compatibilidad, de 4.1 a 4.3). Puede haber uno o varios. Para muchas opciones, es adecuado utilizar el Centro de Datos por defecto \u2014 Default.
    \nEl Centro de Datos consta de uno o varios Cl\u00fasteres<\/b>. Un cl\u00faster define el tipo de procesador, las pol\u00edticas de migraci\u00f3n, entre otros. Para instalaciones peque\u00f1as, tambi\u00e9n se puede limitar a usar el cl\u00faster por defecto.
    \nUn cl\u00faster, a su vez, se compone de Host<\/b>de servidores que realizan el trabajo principal: albergan m\u00e1quinas virtuales y est\u00e1n conectados a los almacenamiento. En un cl\u00faster se espera que haya 2 o m\u00e1s hosts. Aunque t\u00e9cnicamente es posible crear un cl\u00faster con solo 1 host, no tiene ninguna utilidad pr\u00e1ctica.<\/p>\n

    oVirt admite muchas funciones, incluida la migraci\u00f3n en vivo de m\u00e1quinas virtuales entre hipervisores (live migration) y entre almacenamientos (storage migration), virtualizaci\u00f3n de escritorio (virtual desktop infrastructure) con grupos de m\u00e1quinas virtuales, m\u00e1quinas virtuales stateful y stateless, soporte para NVidia Grid vGPU, importaci\u00f3n desde vSphere, KVM, y muchas m\u00e1s. Todas estas funciones est\u00e1n disponibles sin pagos de licencia, y si se necesita soporte, se puede adquirir a trav\u00e9s de Red Hat a trav\u00e9s de socios regionales. API<\/a><\/noindex> Sobre los precios de RHV<\/p>\n

    El costo no es alto comparado con VMware, solo se compra el soporte, sin la obligaci\u00f3n de adquirir la licencia en s\u00ed. El soporte se compra solo para los hipervisores, ovirt-engine, a diferencia de vCenter Server que requiere gastos adicionales.<\/h4>\n

    \nEjemplo de c\u00e1lculo para el primer a\u00f1o de propiedad<\/p>\n

    Consideremos un cl\u00faster de 4 m\u00e1quinas de 2 sockets y precios al por menor (sin descuentos por proyecto).<\/h4>\n

    \nLa suscripci\u00f3n est\u00e1ndar de RHV
    \ncuesta $999     por socket\/a\u00f1o (premium 365\/24\/7 \u2014 $1499), en total 4*2*$999=<\/a><\/noindex> Precio de vSphere$7992<\/b>.
    \n    Precio de vSphere<\/a><\/noindex>:<\/p>\n