En este post vamos a explicar cómo realizar una policy de Opalis 6.3 que permita que cada VM en SCVMM tenga asociada la información relativa a ella en el portal.
El Workflow sera el siguiente:
-Cada hora
-Se buscaran las VMs que no tienen centro de coste asociado
-Buscaremos si estas VMs existen en el portal de SSP
-De ser así actualizaremos las propiedades de la VM en SCVMM para que contengan la información de SSP, especialmente el centro de coste
Finalmente el workflow en Opalis queda como se ve a continuación:
Vamos a ir viendo cada uno de los elementos para que veáis lo simple que es configurarlos.
La primera actividad es del tipo “Monitor Date/Time” que encontrareis dentro de los objetos de tipo Scheduling que nos permiten programar la ejecución de los workflows a intervalos o fechas concretas.
En las propiedades de este objeto solo tendremos que configurar cada cuanto queremos que corra.
El siguiente objeto es el que vamos a usar para buscar en SCVMM todas las VMs que no tengan un centro de coste, dado que en nuestra nube privada no queremos VMs sin control.
La actividad es de tipo “GET-VM” que encontraremos entre los objetos de “System Center Virtual Machine Manager” y en sus propiedades tenemos que configurar los siguiente:
La configuración la habremos tenido que configurar previamente en Opalis para que este se pueda conectar con SCVMM.
El filtro que usaremos para buscar las VMs en este caso será que en el campo centro de coste no contengan los caracteres “BU:” que es como vamos a tipificar los centros de coste correspondientes a unidades de negocio en nuestra nube privada.
Bien, esta actividad por tanto retornara todas las VMs en SCVMM que no tienen un centro de coste tipificado correctamente.
En la siguiente actividad vamos a conectarnos con la BD del portal de autoservicio para buscar si cada VM encontrada anteriormente existe o no y recoger los datos en caso afirmativo.
Para ello usaremos la actividad “Query Database” que encontraremos en los objetos “Utilities”, tendremos que configurar tanto la conexión con la base de datos como la consulta que queremos realizar.
En la conexión indicamos el servidor que tiene la base de datos del SSP y el nombre de la misma (por defecto DITSC)
En detalles indicaremos la query como veis a continuación:
Una de las ventajas impresionantes de Opalis respecto a otros productos parecidos es lo fácil que es pasar datos de una actividad a la siguiente, en este caso como veis la query usara como parámetro el nombre de la VM que se habrá recuperado en la actividad anterior en la que nos conectábamos con SCVMM, Opalis el solo se encargara de ejecutar esta actividad por cada VM encontrada.
Para poder incluir un parámetro de este tipo solo tenéis que pulsar con el botón derecho y seleccionar Suscribe/Published Data.
Dentro de esta opción encontrareis toda la información relatiba a cada actividad del workflow, seleccionar la quereis usar y Opalis se encargara de poner el valor en el momento adecuado durante la ejecución.
La consulta a la base de datos devolverá un valor cada vez dado que solo puede haber una VM con un nombre determinado, Opalis correrá la query una vez por cada VM y en caso de encontrar en la base de datos de SSP una VM equivalente retornara todos los campos en una línea separando cada campo con un punto y coma así que para usar estos valores nos será mucho más cómodo volver a partirlos por el punto y coma.
Para realizar esta operación usaremos la actividad “Split Fields” que encontraremos en el grupo de objetos “Data Manipulation” su configuración será más que sencilla:
En “Input String” solo teneis que usar la opción de published data que os enseñe antes para seleccionar el campo con el resultado de la query.
Bien cada vez que hacéis una actividad tenis que unirla con la siguiente como veis en la primera imagen de este post, sin embargo cuando unamos la actividad de “Query Database” con la de “Split Fields” vamos a seleccionar esa unión y modificaremos sus propiedades para que el “split” solo se realice si la consulta devolvió registros de esta forma el workflow será más rápido.
La siguiente actividad que usaremos será “GET-VM” del grupo de objetos de “System Center Virtual Machine Manager” la vamos a usar para recuperar ya la VM concreta que queremos modificar, tenemos que recuperarla por el nombre que es lo que sabemos de la VM en este momento del workflow, no podemos ir directamente a actualizar la VM por que la actividad “Update-VM” nos exige saber el ID de la VM y en este momento no lo sabemos.
La configuración de la actividad es muy sencilla, la actividad “Split Fields” que hemos usado antes está publicando cada campo de la query realizada solo tendremos que configurar el filtro del “GET-VM” para que busque por nombre e indicar como valor para el nombre el campo 1 de los pasados por la actividad “Split Fields” para saber el número del campo solo tenéis que ver la query que pusisteis, cada campo indicado en el select se pasara en el mismo orden.
Ahora que ya tenemos la VM vamos a actualizarla en SCVMM para ello solo es necesario crear una actividad de tipo “UPDATE-VM” que una vez mas encontramos en el grupo de objetos “System Center Virtual Machine Manager” y configurarla de la siguiente forma:
Una vez la política de Opalis corra, podréis empezar a ver ya los resultados en SCVMM en las propiedades de las VMs:
Que se corresponden con las que estan en el portal:
Gracias a esto, ahora por ejemplo podemos de forma fácil parar todas las VMs de un cliente concreto:
Espero que os haya resultado interesante.
Un saludo a todos.
Crossposting from blogs.technet.com/dmatey