Share via


Extendiendo SSP 2.0 en la nube privada: SCOM y SSP

 

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.

 

1

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: https://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.

image

image

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:

image

El siguiente paso es crear los grupos desde abajo del todo es decir empezando por los roles de servicios

image

image

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.

image

image

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.

image

image

El grupo siguiente sera como es logico el cliente

image

El grupo que representa cliente debe referenciar a todas las infraestructuras que haya solicitado en el portal

image

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

image

image

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.

image

De esta forma la siguiente vez que corra la política de Opalis la VM tendra en la descripción el service role.

image

Ahora ya podemos crear la regla de pertenencia dinamica , asi que editamos las propiedades del grupo

image

En el tab de miembros dinamicos introducimos la siguiente información:

image

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.

image

Ahora crearemos una carpeta dentro del nuevo management pack para representar a cada cliente

image

Dentro de la carpeta de cada cliente creamos una “State View”

image

Configuramos la vista de estado como veis a continuación:

image

Podeis personalizar la vista para mostrar los campos que querais:

image

En esta vista que hemos configurado se veran todas las VMs del cliente

image

Ahora vamos a generar una vista de diagrama con la configuración que veis a continuación:

image

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.

image

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.

image

Nunca me gusta usar usuarios directamente pero para esta demo lo dejare pasar, en producción mejor usar grupos.

image

Seleccionamos el ambito que podra ver este usuario:

image

Y también las vistas:

image

Finalmente pulsamos “Create” para crear el rol

image

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.

image

 

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.

image

image

En el siguiente post veremos como ofrecer control del nivel de servicio.

Espero que os haya resultado interesante.

Un saludo.