pu

Buscar este blog

lunes, 20 de octubre de 2014

oVirt en Fedora

oVirt en Fedora
En esta nota vamos a introducirnos acerca de que es Ovirt y mencionar los elementos que la componen. Para eso primero vamas a ver un pantallazo general acerca de lo que es Ovirt.
Comenzemos con un breve resumen:
oVirt es una plataforma de virtualizacion open source por la cual podemos administrar por medio de una aplicación web nuestra infraestructura, actualmente en su comunidad oVirt[1] podemos encontrar muchisima informacion acerca del estado del proyecto, ademas tambien Red Hat esta detras de este proyecto dado que su producto de virtualizacion RHEV proviene de oVirt. Podriamos decir que es la version open source que compite con VMware VSphere a nivel de soluciones de virtualizacion en datacenters. OVirt utiliza libvirt lo cual permite manejar diferentes maquinas virtuales corriendo en diferentes backed, incluyendo KVM,Xen y VirtualBox[2], sin embargo el foco principal de oVirt es KVM.
OVirt tiene una aplicación de administracion muy sofisticada muy util para los administradores de sistemas, pero tambien posee una interfaz de consola de texto muy similar a la de virsh por la cual podemos realizar las mismas tareas que hacemos por la web. Esta interface de administracion nos da un panel central de configuracion en la cual podemos manejar todo el storage,red , recursos de las vm, sistema de reportes, manejo de roles de administracion para determinados usuarios en donde se le aplica que perfil usa para que pueda hacer determinadas tareas de administracion u solo un uso basico, y por supuesto todo lo referente a la virtualizacion de nuestra infraestructura.
oVirt puede manejar multiples hosts, estos host servers diferentes del nodo que se instala el producto ovirt-manager se comunican por medio de https con xml-rpc por medio de un agente instalado en el servidor – VDSMd (Virtual Desktops and Servers Manager daemon), este ultimo se comunica con libvirt para tener el control de las maquinas virtuales. Por medio de VDSMd tambien configura la parte de networking ( Vlans, MTU , multiples gateways, y soporte para OpenStack Neutron,entre otras).
OVirt esta escrito en Java, con JBoss como servidor de aplicaciones y GWT como framework grafico. VSDMd esta escrito en python.
Arquitectura:
La arquitectura de oVirt[7] en un aspecto general la podriamos definir de la siguiente manera:
Partiendo del modelo anterior una vista rapida y estandar de oVirt consta de tres partes primeramente:
ovirt-engine el cual es usado para deployar, monitorear, mover,parar y crear imagenes de VM, configurar storate, redes, etc.
Uno o moas hosts (nodes), en donde correran las maquinas virtuales (VM)
Uno o mas nodos Storage, en donde estaran las imagenes ISo que corresponden a cada VM
Tambien se necesita un servicio de autenticacion para manejar todo el sistema de administracion de usuarios para ovirt-engine, para eso se puede usar Active Directory, LDAP, IPA.
Los nodos son sistemas GNU/Linux con VDSM y libvirt instalados, tambien con otros paquetes extras para poder habilitar la virtualizacion de networking y otros servicios del sistema. Fedora 17 fue la primera version que soporto oVirt para instalar ovirt-engine o la iso personalizada llamada oVirt-node que contiene basicamente lo justo y necesario para la virtualizacion del sistema como nodo.
Los nodos de Storage pueden ser block o file storages, tambien pueden ser locales o remotos, accedios por NFS tambien. Otro feature imporante es el uso de Gluster para storage compartidos, tambien tenemos iscis, FCoE. Los nodos de storage son agrupados en pools de storage para poder brindar alta disponibilidad y redundancia, para mas informacion podemos ver VDSM Storage Terminology[8], que basicamente resume el concetpo de lo que son los Storage Pool, Storage Domain, Image, Volume/Snapshot.
Podriamos desglozar un poco mas el modelo de arquitectura en la siguiente imagen:
Sus componentes principales son:
1. Engine (ovirt-engine) – Maneja los host oVirt, y permite que los administradores creen y deployen nuevas VMs.
2. Admin Portal – Aplicacion web que permite realizar diversas tareas avanzadas de administracion.
3. User Portal – Una aplicación web mas simple para determinados casos de administracion mas basicos.
4. REST API – Una API que permite realizar diversas tareas de virtualizacion, se puede usar desde la linea de compandos o por medio del SDK de python
5. CLI/SDK – La interface CLI y SDK permiten un metodo de comunicación hacia el engine por medio de scritps.
6. Database – La base de datos Postgres es usada por el engine para poder proveer de persistencia para cada configuracion que ovirt realiza con cada componente..
7. Host agent (VDSM) - El engine oVirt se comunica con VSDSM para pedirle realizar determinadas acciones sobre las VMs
8. Guest Agent – El agente que corre dentro de cada vm provee informacion acerca de los recursos a oVirt engine. La comunicación se realiza atraves de una conecion serial virtualizada.
9. AD/IPA – Servicios de Directorio. Engine los utiliza para recibir informacion correspondientes de los usuarios y grupos asi puede determinar los mecanimos de permisos.
10. DWH (Data Warehouse) – El compontente data warehouse realiza diversas tareas ETL en la data extraida de la base usando Talend , y asi inserta esta en el historial de la base.
11. Reports Engine - Gneracion de reportes basado en la informacion historica de la DB, de diversos tipo como el uso de recursos,etc, los reportes que usa son Jasper
12. SPICE client – El memto de accceso de os usuarios a las VMs.
Otro grafico que podriamos poner para redondear un poco mas , asi igual recomiendo mirar la documentacion oficial para ahondar mas a fondo.
Versiones de oVirt y features:
oVirt actualmente en Fedora se encuentra en la version 3.2 para Fedora 20[3] pero en el proyecto ya tenemos la version 3.3 como estable[4]. Son muchisimas las caracteristicas que posee ovirt[5,6], pero podriamos mencionar algunas mas importantes.
Alta Disponibilidad : Reiniciar los Guests VMs de un host con errores automaticamente a otro host
Migracion en caliente de VMs: Mover las VM que esta corriendo en otro host sin donwtime.
Migracion en caliente de Storage: Poder mover una VMs tambien con su disco de un storage domain a otro.
Scheduler de Sistema: Balanceo continuo de los recursos de las VM según politicas o uso del host.
Power Saver: Concentrar las maquinas virtuales en la menor cantidad de servidores durante las horas no pico
Administrador de Mantenimiento: No hay tiempo de inactividad en las máquinas virtuales durante las ventanas de mantenimiento programadas cuando por ejemplo se hace parcheo del Hypervisor.
Administrador de Imagenes: Creacio de VM basadas en plantillas, thin provisioning y snapshosts. Posibilidad de hacer en caliente
Monitoreo y reportes: Para cada item del sistema – VM guest, hosts, networking, storage,etc
OVF Importar/Exportar: Importar y exportar VM y plantillas usando OVF files.
V2V: Convertir Vms desde Vmware y RHEL/Xen a oVirt
Storage: Soporte para iSCSI, FCoE, NFS, y Gluster para storage compartidos.
Instalacion:
Ahora que ya vimos un patanllazo general del producto vamos a ver un poco los requirimientos de instalacion y los pasos a seguir para una instalacion basica y tambien algunas capturas de las pantallas mas comunes.
Vamos a ver una serie de 7 pasos para insalar tanto el oVirt-engine y el ovirt-node[9] en el mismo equipo, lo cual no es lo mas recomendado pero para probarlo sirve , dado que lo ideal es instalarlo todo por separado, en un nodo el ovirt-engine y en otro utilizar la iso de ovirt-node o instalar vdsm y otros paquetes para transformar esa distro en un nodo ovirt. Esta el camino mas dificil que es buildear desde las fuentes el oVirt-engine[10] y el oVirt-node[11]
Requerimientos de Hardware
4 GB Memoria
20 GB disk space
Opcional
Network storage
Software
Fedora 19 or Red Hat Enterprise Linux 6.4 (o similar)
Navegadores recomendados
Mozilla Firefox 17 or later
Internet Explorer 9 or later
Los siguientes pasos estan para Fedora 19, pero se utiliza el repo de ovirt porque la version 3.3 no esta disponible para Fedora, recien en Fedora 20 esta la 3.2.
Fedora 19 
0. Agregar el repositorio oficial de oVirt para Fedora.
sudo yum localinstall http://ovirt.org/releases/ovirt-release-fedora.noarch.rpm
Esto agregara el repositorio de oVirt a tu equipo permitiendo tener los ultimos paquets de oVirt
Tambien esto habilitara el repositorio virt-preview en tu equipo dandote acceso a las versiones ultimas de libvirt y KVM
1. Instalar oVirt Engine.
sudo yum install -y ovirt-engine
2. Opcionalmente se puede instalar el paquete All-In-One plugin si se desea tener el host de VMs dentro del Engine Host
sudo yum install -y ovirt-engine-setup-plugin-allinone
3. Set up oVirt Engine.
sudo engine-setup
4. Seguir los pasos que van saliendo en patanlla para configurar e instalar el engine.
5. Una vez terminada satifactoriamente la instalacion de oVirt Engine, tendra en pantalla las instrucciones para poder acceder al panel de administracion web de oVirt
6. ¿Eso fue todo?, querian algo mas complicado ??, ya se encuentra todo instalado.
7. En el caso que instalamos solo el oVirt-node, hay que seguir otros pasos para instalar los oVirt Host[12]
Una pantalla de como quedaria nuestro portal recien instalado, en este caso hay un par de cosas mas.
Para la proxima entrega vamos a ver como instalarlo de forma separa paso a paso mostrando cada pantalla.
Les dejo estos slides[13] que explican mas en profundidad como funciona todo.
Referencias:
[0] Sacado de http://www.itrestauracion.com.ar/?p=1505

[1] http://www.ovirt.org/Community
[2] http://libvirt.org/drvvbox.html
[3] https://fedoraproject.org/wiki/Features/oVirtEngine_3.2
[4] http://resources.ovirt.org/releases/
[5] http://www.ovirt.org/OVirt_3.2_release-management#Features
[6] http://www.ovirt.org/OVirt_3.3_release-management#Features
[7] http://www.ovirt.org/Architecture
[8] http://www.ovirt.org/Vdsm_Storage_Terminology
[9] http://resources.ovirt.org/releases/3.3/iso/ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19.iso
[10] http://www.ovirt.org/Building_oVirt_engine
[11] http://www.ovirt.org/Node_Building
[12] http://www.ovirt.org/Quick_Start_Guide#Install_Hosts
[13] http://www.ovirt.org/OVirt_Slide_Decks

lunes, 13 de octubre de 2014

Instalar Adobe Reader vía GPO

Uno de los principales problemas de los administradores de sistemas es la distribución de programas de terceros en entornos empresariales.
En ocasiones, podemos usar un simple script que instale la aplicación deseada. No obstante, a no ser que dicho script este algo elaborado, es posible que instalemos una aplicación varias veces en el mismo equipo con las consecuentes perdidas de rendimiento y ancho de banda.
Dado que Active Directory implementa políticas de grupo para la instalación de aplicaciones es más sensato usar estas.
Vamos a ver como instalar Adobe Reader X por medio de una política de grupo.

Instalando Adobe Reader
Aunque Adobe es una aplicación gratuita si queremos distribuirlo en nuestro entorno empresarial debemos solicitar una licencia. Dicha licencia también es gratuita.
Una vez que tengamos nuestra licencia, descargamos el paquete msi del Adobe Reader X del siguiente sitio FTP.
ftp://ftp.adobe.com/pub/adobe/reader/win/
Personalizando el Paquete de Instalación
Aunque que podemos distribuir el paquete msi tal cual lo hemos descargado, merece la pena ver brevemente como modificar su comportamiento por defecto.
Podemos alterar la forma en que los paquetes msi se instalan usando distintos modificadores cuando los instalamos vía línea de comandos o por medio de un script.
Sin embargo cuando usamos una política de grupo o GPO la instalación se realiza de forma silenciosa sin interacción del usuario y no es posible especificar estas opciones. En caso de querer alterar las opciones de la instalación debemos editar el paquete msi con una herramienta de terceros o usar ORCA de Microsoft.
Por suerte, Adobe nos simplifica el trabajo y proporciona un asistente de configuración de su paquete msi que puede encontrase en este link.
Una vez instalado podemos abrir el paquete msi y modificar su comportamiento en la instalación.

Algunas de las opciones interesantes de las que disponemos son: Habilitar la optimización, Activar la cache, elegir el tipo de instalación, posponer el reinicio,

suprimir el mensaje EULA cuando el usuario abre el programa por primera vez,

o eliminar los accesos directos del escritorio o del menú inicio.

También disponemos de un editor donde podemos cambiar cualquier valor posible del paquete msi. Aquí recomiendo deshabilitar el del servicio de actualizaciones de Adobe ya que seremos nosotros quienes vamos a actualizar adobe a través de las GPO. Para esto buscamos el campo InstallService y cambiamos el valor de la columna StarType a 4.

Una vez realizados los cambios deseados guardamos el paquete.
Si recibimos un error indicando que no se encuentra el archivo Setup.ini. Lo único que tenemos que hacer es meter un archivo vacío con ese nombre en la carpeta donde está el paquete msi.

Si examinamos el directorio donde hemos guardado el paquete vemos que se ha creado un archivo con extensión mst. Este archivo contendrá las modificaciones efectuadas sobre el paquete.

Creación de la GPO
La ruta de nuestro paquete debe ser accesible por todos los equipos del dominio, así que lo lógico es tenerlo en una unidad de red compartida con permisos de lectura para todos los usuarios.
Para crear la política abrimos el  gestor de políticas de grupo en el controlador de dominio y creamos una nueva política. Editamos y buscamos la siguiente ruta Configuración del equipo => Directivas => Configuración de software => Instalación de software.
Pinchamos con el botón derecho => Nuevo => Paquete…

Buscamos el paquete en la carpeta compartida y pinchamos en Abrir.

Se nos da a elegir dos métodos para implementar el software. Publicada se usa cuando asignamos esta GPO por usuario. La aplicacion no se instalara pero estara disponible para el usuario en Agregar o Quitar Programas en el Panel . En Asignada sin embargo el paquete se instalará sin interacción ninguna del usuario.

Si hemos hecho modificaciones sobre el paquete msi debemos pinchar en Avanzada para seleccionar las el fichero mst. Para esto nos vamos a Modificaciones => Agregar… Buscamos el archivo mst y pinchamos en Abrir.

En unos instantes veremos como el paquete se ha agregado a la lista de paquetes a instalar.
Si queremos probar la esta nueva política podemos forzar las politicas de grupo con el comando “gpupdate /force” tanto en el servidor de dominio como en el equipo donde queremos aplicarla. Si después reiniciamos podemos observar como Adobe Reader se ha instalado correctamente con las modificaciones deseadas.
MUY IMPORTANTE, hay que escoger la versión que corresponda con el idioma en el que esté instalado Windows en los clientes donde vamos a distribuir el paquete. Si por alguna razón queremos Adobe Reader en un lenguaje diferente debemos pinchar con el botón derecho sobre el paquete => Propiedades => Implementación, Opciones avanzadas…  y luego marcar la casilla Omitir el idioma al implementar este paquete.

Referencias

Deploying Adobe Reader X - http://blog.stealthpuppy.com/deployment/deploying-adobe-reader-x/

Deploy Adobe Reader using Group Policy - http://mysysadmintips.com/index.php/active-directory/24-deploy-adobe-reader-using-group-policy

Windows Installer - http://en.wikipedia.org/wiki/Windows_Installer

Introducción a Instalación de software de Directiva de grupo - http://technet.microsoft.com/es-es/library/cc738858%28WS.10%29.aspx

CÓMO: Utilizar Directiva de grupo para instalar software de forma remota en Windows 2000 - http://support.microsoft.com/kb/314934/es

How to use the Orca database editor to edit Windows Installer files - http://support.microsoft.com/kb/255905