Como sabéis en SSP 2.0 las VMs que componen los servicios se organizan en la siguiente jerarquía completamente definible por el usuario.
Lo que vamos a intentar conseguir en este post es el principio de una monitorización de maquinas virtuales y servicios en linea con este esquema.
Obviamente será solo el primer paso, pues como decimos siempre monitorizar solo las VM no nos lleva a nada, más adelante en otro post hablaremos de la monitorización de servicios avanzada.
La forma en la que vamos a instrumentalizar esta monitorización es en base a grupos de objetos de SCOM y a la informarción que hemos sincronizado entre SCVMM y el SSP mediante Opalis en el post anterior.
Los grupos de objetos de SCOM se pueden crear de forma programática, sin embargo para este post vamos a obviar esa parte dado que considero que es excesivamente complicada para los que tenéis un número reducido de clientes e infraestructuras, para los que tengan curiosidad sobre la creación automática de grupos, les recomiendo ver el siguiente post: http://blogs.msdn.com/b/jakuboleksy/archive/2006/11/15/creating-and-updating-groups.aspx?PageIndex=2#comments , la idea sería usar esta mecánica desde Opalis en relación a la estructura de SSP que obtendríamos de la BD de SSP desde Opalis como veíamos en el ejemplo del anterior post.
En nuestro caso crearemos los grupos de los clientes (business units), infraestructuras, servicios y roles de servicios nosotros mismos y usaremos una membresía dinámica en SCOM para que los grupos contengan las máquinas virtuales de forma automática a medida que las vayamos creando.
Empezaremos creándonos un management pack.
Introducimos el nombre que deseemos y pulsamos “Next” en la siguiente pantalla pulsamos “Create”
Para el ejemplo voy a utilizar los datos que ya tengo cargados en el SSP que uso para las demos y que veis a continuación:
El siguiente paso es crear los grupos desde abajo del todo es decir empezando por los roles de servicios
Recordar seleccionar vuestro nuevo management pack e indicar el nombre del “Service Role”, de momento pulsar “Next” y “Create” volveremos a este grupo mas tarde.
Ahora crearemos el grupo que representara el servicio en la jerarquia de SSP, este grupo tendra como subgrupo miembro a todos los service role que lo compongan.
Ahora llega el turno de la infraestructura que contendrá todos los servicios que dependan de ella, usaremos el mismo método de subgroups para indicarlos.
El grupo siguiente sera como es logico el cliente
El grupo que representa cliente debe referenciar a todas las infraestructuras que haya solicitado en el portal
Ahora crearemos el grupo raíz al que pertenecerán todos los clientes y que representa por ende la propia nube privada que estamos construyendo
Ahora nos queda configurar los grupos que representan los roles de servicio para que contengan automáticamente las máquinas virtuales que corresponda.
Para poder hacer esto vamos a necesitar que alguna información de la que tiene SCVMM sobre la VM contenga el nombre del service role, en el anterior post de esta serie visteis como usábamos Opalis para rellenar esta información, por desgracia SCOM no contiene todos los campos del SCVMM, así que vamos a modificar la actividad que usamos antes en Opalis para rellenar estos atributos para que rellene también la descripción de la VM indicando ahí el service rol.
De esta forma la siguiente vez que corra la política de Opalis la VM tendra en la descripción el service role.
Ahora ya podemos crear la regla de pertenencia dinamica , asi que editamos las propiedades del grupo
En el tab de miembros dinamicos introducimos la siguiente información:
Notar que especificamos también la business unit por si hubiera un service rol con el mismo nombre en otro sitio del SSP.
Con el fin de que el resultado sea mejor, he creado otro servicio dentro de la misma infraestructura, repitiendo el mismo proceso que hemos seguido hasta ahora.
Ahora crearemos una carpeta dentro del nuevo management pack para representar a cada cliente
Dentro de la carpeta de cada cliente creamos una “State View”
Configuramos la vista de estado como veis a continuación:
Podeis personalizar la vista para mostrar los campos que querais:
En esta vista que hemos configurado se veran todas las VMs del cliente
Ahora vamos a generar una vista de diagrama con la configuración que veis a continuación:
Esto nos facilitara una visión gráfica del estado de un cliente.
Me he permitido ir haciendo drill down del diagrama para que podáis observar cómo sin ningún trabajo nuestro, SCOM ya está siendo consciente de que por ejemplo dentro de una VM hay un Sharepoint, un SQL y otros elementos cuyo estado se nos muestra en el diagrama.
Ahora que ya tenemos este trabajo realizado es fácil permitir a un usuario autorizado del cliente acceder a su monitorización.
Para ello creamos un rol en SCOM, en este caso lo voy a hacer de solo lectura para que no pueda modificar nada.
Nunca me gusta usar usuarios directamente pero para esta demo lo dejare pasar, en producción mejor usar grupos.
Seleccionamos el ambito que podra ver este usuario:
Y también las vistas:
Finalmente pulsamos “Create” para crear el rol
Con esta configuración cuando el usuario entre en el portal web de SCOM o en la consola solo vera lo que nosotros hemos indicado.
Por supuesto este trabajo que hemos realizado nos permitirá también ofrecer a los clientes de nuestra nube privada informes de disponibilidad, rendimiento, etc. restringidos solo a sus máquinas virtuales y servicios.
En el siguiente post veremos como ofrecer control del nivel de servicio.
Espero que os haya resultado interesante.
Un saludo.
Crossposting from blogs.technet.com/dmatey