Be Geek My Friend

Daniel Matey, Ingeniero Preventa Datacenter, Microsoft

December 2010 - Artículos

System Center Service Manager: El Dashboard

 

De nada vale que tengamos la mejor gestión del servicio del mundo si no podemos explotar la información fácilmente de forma que podamos mejorar el servicio.

El objetivo final no es ser capaz de gestionar miles de incidencias y resolverlas en unos tiempos determinados, o gestionar los cambios simplemente por burocracia, el objetivo real de IT es que no haya incidencias y para eso necesitamos poder analizar los datos y determinar que es necesario mejorar.

SCSM cuenta con muchos informes, pero para hacer análisis rápidos y ver la situación general del servicio desde el punto de vista de la gestión no hay nada como el dashboard del que os voy a hablar.

Podéis descargar el dashboard de SCSM gratuitamente desde http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4efb9d76-99e7-4bfe-b6f6-a58469bdcf27&displaylang=en 

El dashboard requiere Sharepoint Services v3 o Sharepoint Server 2007.

En la descarga viene un fichero readme con las instrucciones detalladas por si tenéis algún problema con algún parámetro, permisos, etc.

El dashboard recoge la información de la base de datos de datawarehouse, así que tendréis que tener instalada esa parte de SM tal y como ya explicamos en un post anterior.

Ff758669.image1(en-us,TechNet.10).jpg

Durante esta instalación he usado un usuario que es administrador de sharepoint y administrador local y para el pool de aplicación y acceso a la base de datos he usado la cuenta de servicio que cree para  SCSM.

La instalación sobre un servidor que ya tengo el sharepoint montado es sencilla:

En un CMD ejecutado con Run as Administrator ejecutáis la siguiente línea:

Msiexec /I ServiceManagerDashboard_x64.msi /L*V setup.log

image

image

image

image

image

image

En la descarga viene una guía de usuario con mucha información sobre como podéis cambiar la información que muestra la dashboard para adaptarla a vuestras necesidades:

image

Si no veis datos en el dashboard aseguraros que vuestros jobs de datawarehouse en SM han corrido adecuadamente y que hay datos de verdad.

image

image

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Posted: 16/12/2010 7:17 por Daniel Matey | con no comments
Archivado en:
System Center Service Manager: Instalando y usando el portal Web

 

El portal web de System Center Service Manager, nos permite tener un punto mas de interlocución con los usuarios.

Desde el portal podemos:

  • Permitir que los usuarios:
    • Crear y ver el estado de sus incidencias y otras solicitudes
    • Solicitar software
    • Acceder a artículos de conocimiento, FAQs, etc.
  • Anunciar a nuestros usuarios problemas o cambios
  • Si tenemos FIM, también podemos permitir que los usuarios cambien sus contraseñas.

Siempre he dicho que estratégicamente de cara al ITSM en lo relativo a incidencias conseguir que sean los propios usuarios los que introduzcan las incidencias a través de un portal de este tipo es un objetivo muy importante.

Cuando los usuarios se educan a introducir la incidencia obtenemos indudables ventajas:

  • La trazabilidad de la incidencia comienza de la mejor manera, esta claro y no es discutible el momento en el que el usuario comunico el problema.
  • Este método consume menos tiempo y recursos en el call center.
  • Funciona 24/7
  • Ofrece un canal estructurado

La instalación es muy sencilla, en un servidor Windows Server 2008 o 2008 R2 con el rol de IIS desplegado y habiendo generado un certificado SSL si vamos a querer usar HTTPs, solo tenemos que seguir los siguientes pasos:

image

image

image

image

image

image

image

image

image

En realidad habremos instalado dos portales, uno para usuario final y otro para operadores/analistas.

image

El portal es multi-idioma, aqui os enseño como se muestra el portal para usuarios cuando detecta una configuración regional española.

image

Los datos que veis que muestra, son recogidos de la CMDB, en este caso además están alimentados por un conector con el directorio activo.

Ahora por ejemplo podemos publicar un anuncio desde la consola de SCSM para que se muestre también en el portal:

image

image

Como decía también podemos publicar artículos de conocimiento

image

Por supuesto podemos incluir, comentarios, elementos relacionados, contenido interno con formato, contenido externo, enlaces, etc.

image

Para que salga en el portal, el articulo tiene que estar publicado:

image

image

image

Si el usuario lo desea puede realizar una solicitud que se materializara como un cambio o incidencia segun lo que indique

image

image

image

image

Por supuesto se puede configurar que le llegue un correo automáticamente al usuario, que se tipifiquen cosas automáticamente, la prioridad en caso de que el usuario sea VIP, etc, etc. todo eso lo iremos explicando en mas posts o si tenéis dudas con algo especifico dejar un comentario.

La incidencia ya nos aparecerá en la consola

image

El usuario puede ver el estado e incluso cerrarla si se ha resuelto de alguna forma.

image

Los usuarios tambien pueden pedir software, esta parte os la mostrare en un post especifico.

image

También esta el portal de operador/analista que se puede ver o no según los permisos que tengas en Service Manager

image

Una parte muy interesante del portal de analista es que te permite ver de una forma muy rápida si hay alguna actividad dentro de ITSM que este esperando por ti.

Para aquellos que queráis os comento que todas las partes del portal son en realidad web parts y que podéis añadirlas a vuestras intranets de sharepoint si lo preferís.

Espero que os haya resultado interesante este post.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Posted: 15/12/2010 17:24 por Daniel Matey | con no comments
Archivado en:
System Center Service Manager: SCOM CI Connector

 

Este es el ultimo de los conectores que os voy a explicar en esta serie de posts.

Mientras que otros conectores como los del AD o SCCM nos aportan CIs imprescindibles podríamos decir que el conector de SCOM para CIs nos va a permitir dar mucho valor añadido a nuestra gestión del servicio especialmente permitiéndonos establecer todas las implicaciones de cambios, incidencias y problemas gracias a que vamos a poder contar en SM con todos los CIs monitorizados por SCOM.

Como sabéis SCOM sabe que tiene que monitorizar y como gracias a los management packs, pues bien, SCSM nos permite importar los mismos management packs, acción esta imprescindible si queremos sincronizar CIs con la CMDB de SM.

Por tanto lo primero que tenemos que hacer es determinar que clases de CIs monitorizados por SCOM queremos tener en la CMDB, luego determinar que management packs son los que describen esos CI, averiguar si esos management packs tienen dependencias en otros management packs y finalmente importar todos esos management packs en SCSM.

Para este ejemplo, me voy a centrar en incorporar a la CMDB todo lo que tenga que ver con servidores windows y virtualización.

Una forma rápida de obtener los ficheros de los management packs, es desde la consola de SCOM.

image

Buscamos los management packs que queremos

image

Una vez descargados, nos vamos a la consola de SCSM para importarlos.

image

image

image

Como os decía antes, los management packs suelen depender unos de otros, en este caso nos faltan mas management packs.

image

Nos apuntamos todas las dependencias y nos los bajamos.

Nota: Algunos de los MPs relativos a SCVMM no los encuentras en el catalogo, los tenéis en el CD de SCVMM.

Nota: Los manament packs de systemcenter.datawarehouse estan en el directorio de SCSM en program files, en el servidor de SM.

image

image

Ya podemos crear el conector:

image

image

image

image

image

Si llegado a este paso no te han salido los management packs que has importado, entonces revísalos bien, posiblemente no coinciden con los que tienes en el SCOM, por ejemplo yo importe el de SCVMM 2008 y en realidad en el SCOM tenia el de SCVMM 2008 R2.

Recordar que siempre que añadáis un management pack nuevo, tendréis que venir al conector y añadirlo.

Supongo que en siguientes versiones mejoraran esto añadiendo acceso al catalogo, la verdad es que ahora no es lo mas cómodo añadir management packs a SCSM, encontrar las dependencias, etc., pero con un poco de paciencia lograreis lo que queréis, luego el esfuerzo merece la pena.

image

image

Forzamos la sincronización para probarla

image

Fijaros como ahora podemos al relacionar elementos a una incidencia seleccionar una base de datos concreta de SQL Server por ejemplo:

image

Por supuesto ya tenemos tambien las maquinas virtuales:

image

Por supuesto nos podemos crear una vista de todos los ICs de un tipo determinado, agrupar por lo que queramos, buscar, etc.

image

Como veis ya se ha traído toda la información de las VMs, numero de micros, etc.

La vista es muy fácil de configurar y se pueden activar los filtros que sean necesarios, cost center, owner, etc:

image

No suele ser necesario tocarlo, pero por si acaso os explico que con la siguiente secuencia de comandos powershell, podéis ver que clases se importan, hay que tener en cuenta que Microsoft.Windows.ApplicatonComponent se sincroniza por defecto y esta es una clase bastante genérica.

image

Si queréis añadir alguna clase mas basta con correr el cmdlet de add.

clip_image053

En otro posts os explicare como crear la definición de los servicios en SCSM y asociar los elementos de diagramas de aplicación distribuida de SCOM.

Espero que os haya gustado.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey
System Center Service Manager: El conector de alertas de SCOM

 

Venimos hablando en varios posts sobre como incorporar información a la CMDB de Service Manager, este post sin embargo trata sobre como podemos conectar las alertas de SCOM con las incidencias de SCSM.

Como sabéis cuando SCOM detecta un problema recibimos una alerta en la consola que además podemos también recibir por correo o en nuestro móvil si así lo hemos configurado.

Hace poco os comentaba en un post como podíamos organizarnos el trabajo con las alertas en SCOM sin embargo en muchas compañías cuando el nivel de madurez operativo es mas avanzado suele requerirse que las alertas de SCOM sean incorporadas al sistema en el que IT gestione las incidencias.

Desde mi punto de vista, esto tiene muchas ventajas, hay una mayor trazabilidad y control de las implicaciones de una incidencia y mas aun cuando la incidencia ha sido motivadora de un problema o mas aun incluso si se esta justificando un cambio para evitar futuras incidencias con la misma causa raíz.

Hay que reconocer que realizar este proceso de forma manual es tedioso y desmotivador, tener que introducir la incidencia en el sistema y meter a mano los datos de la alerta de SCOM es poco productivo y aunque podemos tratar de usar enlaces a la consola web de SCOM como forma de acceder a los datos de la alerta, no habrá trazabilidad una vez cerrada la alerta o pasado el periodo de grooming y lo que es peor no hay un vinculo real entre incidencia y alerta lo cual hace que al cerrar cualquiera de las dos la otra sigue estando abierta.

Aquellos de vosotros que uses Service Manager tenéis la suerte de que este problema esta mas que resuelto y de una forma muy sencilla, SCSM incluye un conector de alertas que es capaz de vincular automáticamente alertas e incidencias.

Este post os muestra como configurar este conector:

El primer paso será dar permisos en SCOM a la cuenta de servicio que uséis en SCSM.

Después desde la consola de SCSM creamos el conector como veis a continuación:

image

image

image

image

En el siguiente paso podemos indicar que plantilla de incidencia queremos usar para las incidencias que se creen con las alertas que vengan de SCOM, podemos especificar diferentes criterios cada uno de ellos puede usar una plantilla diferente, en este ejemplo no voy a especificar ninguna regla especifica y dejare que todas las incidencias se creen con la plantilla por defecto para este tipo de incidencias que es la “operations manager incident template”

image

Ahora indicaremos cada cuanto tiempo tiene que sincronizarse el conector y si queremos que se cierren solas las alertas y las incidencias si hay cambios en el otro extremo del conector.

image

image

image

El siguiente paso lo tendremos que realizar desde la consola de SCOM y consistirá en indicar que alertas queremos que pasen a SCSM a través del conector.

En mi opinión es necesario establecer un criterio en vez de hacer que todas las alertas pasen a SCSM y se conviertan en incidencias.

En general un punto de partida es que se conviertan en incidencias todas las alertas en las que se haya cambiado el estado a los estados que especifiquemos.

Para este ejemplo voy a configurar el conector para que todas las alertas que se pongan en estado “resolviéndose” que es un estado que nos hemos creado nosotros en SCOM pasen automáticamente a SCSM.

Al configurar el conector en SCSM se nos habrá creado automáticamente un conector en SCOM como el que veis en la siguiente imagen, debemos editar sus propiedades.

image

image

Pulsamos sobre “Add” para añadir una subscripción en la que especificaremos el criterio usado para pasar las alertas a SCCM

image

En este ejemplo no vamos a limitar a grupos específicos de objetos en SCOM, cualquier alerta de cualquier grupo podrá pasar a SM si cumple el criterio.

Con la siguiente configuración las alertas pasaran incluso cuando provengan de management packs importados con posterioridad a la creación de esta subscripción:

image

A continuación especificamos el criterio que queramos:

image

A partir de este momento cuando queramos sincronizar una alerta creando una incidencia en SCSM solo tendremos que cambiar su estado al que hayamos seleccionado en el criterio.

image

Pasado el tiempo que hemos indicado al conector, tendremos la incidencia creada en SCSM

image

Como hemos usado la plantilla por defecto y no hemos parametrizado nada la planilla ni el workflow asociado la incidencia esta sin asignar a nadie, no tiene clasificación, etc, todo eso se soluciona como digo parametrizando SM.

Veis como las incidencias ya tienen todos los datos que vienen de SCOM.

image

Incluido por ejemplo los elementos afectados:

image

En otro posts os explicare como importar CIs desde SCOM con lo que también se asociarían servicios afectados, etc.

Si damos por resuelta la incidencia en SCSM y la cerramos, la alerta en SCOM también pasa a estar cerrada.

image

Como veis, es mas que fácil y es una herramienta muy potente para mejorar el servicio y tener las alertas mas controladas e integradas en la gestión del servicio.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager: Configuration Manager Connector

 

Si antes veíamos como crear un conector con el directorio activo para empezar a dotar de contenido a nuestra CMDB en Service Manager ahora veremos como complementar aun mas esta información con todos los datos que tiene SCCM sobre los servidores y ordenadores, además también nos será muy útil para tener la información de las actualizaciones y software.

El proceso es también muy sencillo:

image

image

image

image

image

El usuario tiene que tener permisos en el SQL usado por SCCM (smsroledb_extract y databasereaders)

image

image

image

image

El conector tardara un poco en sincronizar los datos con la CMDB, podéis ver el progreso desde la consola:

image

image

image

image

image

Como veis este conector es muy importante para la CMDB dándonos mucha información muy útil.

En otro post os mostrare como trabajar con los paquetes de software, permitir que los usuarios pidan software a través del portal de autoservicio de service manager, etc.

Aun podemos añadir mas información a los CIs que nos hemos traído del AD y el SCCM y añadir nuevos CI a través del conector de SCOM que será el siguiente que os enseñare.

Un saludo.

Crossposting from blogs.technet.com/dmatey

System Center Service Manager 2010: El Active Directory Connector

 

Hace poco hablábamos de la CMDB de System Center Service Manager (SCSM), vamos a ir viendo uno a uno los conectores mas comunes y como emplearlos, empezando por el conector del directorio activo.

Tal vez los CI (Configuration Items) mas comunes y numerosos en una CMDB son los usuarios y ordenadores, precisamente estos CI mas otros como grupos e impresoras son los que sincronizaremos entre el Directorio Activo y Service Manager.

Crear el conector es realmente sencillo como veis en las siguientes capturas:

image

image

image

Podemos seleccionar el dominio y OU a partir de los cuales se realizaran las sincronizaciones, si lo necesitamos podemos tener varios conectores.

También es posible especificar con que cuenta queremos realizar el acceso al AD

image

Por defecto se importaran todos los objetos de los tipos soportados, si queremos podemos seleccionar objetos manualmente.

image

image

image

Los objetos del AD sincronizados se importaran en la CMDB como CIs, en caso de eliminar el conector todos los CIs que no tengan otras relaciones o que no hayan tenido incidencias, cambios, problemas, etc. relacionados serán eliminados de la CMDB.

Una opción que tenemos es la de forzar la sincronización cuando queramos, por defecto el conector se sincronizara automáticamente cada hora.

image

En el panel de “Configuration Items” podéis ver todos los CIs

image

Ahora, ya podemos por ejemplo relacionar una incidencia con su usuario

image

image

image

Al vincular un usuario o un ordenador podemos ver todas sus propiedades rescatadas del AD:

image

Si tenéis cualquier problema con el conector, los eventos están en el registro de “operations manager” en el event viewer del servidor de Service Manager.

image

En un próximo post hablaremos sobre como crear un conector para configuration manager de forma que tengamos para cada equipo toda la información de inventario hardware y software, actualizaciones, etc.

Un saludo.

Crossposting from blogs.technet.com/dmatey

¿Que es el datacenter toolkit for hosters?

 

Cada empresa es un mundo, para todas ellas es interesante algún tipo de sabor mas o menos descafeinado de nube privada, Microsoft es consciente de esto y por eso ha desarrollado un conjunto de soluciones que permiten a cada empresa construir su nube privada de la forma mas conveniente, siendo el punto de entrada mas comun a estas nubes privadas el Self Service Portal 2.0 de System Center Virtual Machine Manager.

Existe un tipo de empresa denominada Hosters, que tiene muchas peculiaridades, por ejemplo mientras que para la mayoría de las empresas un portal de autoservicio es la entrada a la nube privada para sus clientes, los hosters suelen requerir algo mucho mas personalizado y si cabe mas potente a lo que se denomina usualmente panel de control.

El datacenter toolkit for hosters es un proyecto de Microsoft cuyo código fuente esta disponible y que esta orientado a que los hosters puedan a partir de el construir su panel de control de forma rápida en base a este código de Microsoft, lo que reduce drásticamente los costes de desarrollo y el time to market.

El kit permite ofrecer servicios basados en virtualización sobre Hyper-V y gestión basada en system center, además el kit también permite interactuar con otros servicios como el DNS, el directorio activo, etc.

El kit no es una solución para instalar con next-next-next, es un punto de partida, los hosters están acostumbrados a construir y desarrollar portales y por eso esto no supone un problema si no una ventaja que les permite adaptarlo a sus necesidades.

Esto quiere decir que si no tenéis conocimientos de programación el kit no os valdrá de mucho y que seguramente este no es vuestro sitio para empezar con la nube privada, os recomiendo ver el Self Service Portal 2.0 de System Center Virtual Machine Manager que os puede ser de muchísima ayuda sin requerir hacer una sola línea de código.

El kit no es solo interesante para los hosters pues también permite a aquellos que no tengan miedo a la programación o a aquellos que en algún momento requieran una fuerte interacción programática con System Center tener un punto de partida.

¿Como funciona?

Microsoft ha desarrollado una serie de servicios web a los que podemos llamar en base a unos contratos preestablecidos.

Estos servicios web atienden en función del modulo al que pertenecen (SCVMM, SCOM, SCCM, SCDPM) y exponen un montón de métodos que podemos agrupar en 3 grupos:

-Aprovisionamiento

-Administración

-Consultas

Por supuesto los servicios cuentan cada uno con contratos de fallos preestablecidos y con contratos de datos para el intercambio de información.

image

Por ejemplo aquí tenéis un diagrama UML de algunas de las clases del servicio de monitorización

image

¿Como es el interfaz del panel de control?

Como os decía el kit esta mas pensado para que lo personaliceis que para que lo uséis tal cual viene, aun así trae dos ejemplos de panel de control, uno sobre silverlight y otro sobre ASP.net.

Este es un ejemplo del portal silverlight

image

image

image

image

image

image

¿De donde puedo descargar el toolkit?

Puedes descargar el toolkit y toda la documentación desde: http://code.msdn.microsoft.com/ddc/Release/ProjectReleases.aspx?ReleaseId=5127

En cuanto tenga un segundo y lo termine os publico un ejemplo de panel de control en el que estoy trabajando.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Trabajando con Alertas en SCOM desde el punto de vista del operador

 

Es muy común que después de desplegar SCOM, especialmente si nunca antes se ha trabajado con un sistema de monitorización experto, los operadores tengan algún problema en su día a día gestionando las alertas, usualmente estos problemas vienen dados principalmente por no establecer previamente un criterio consensuado por todo el equipo encargado de la monitorización con respecto a como gestionar las alertas.

¿De donde vienen las alertas?

Lo primero y mas importante que tenemos que entender es que SCOM no es sistema orientado a las alertas si no a la monitorización de estados de salud, las alertas son un medio, no el fin.

Si dentro de la consola pulsáis sobre cualquier elemento en rojo, veréis un menú que se llama explorador de salud.

image

Dentro del explorador veis como esta la salud de todos los elementos monitorizados organizados jerárquicamente a partir del objeto que seleccionasteis.

image

Cada uno de los elementos que veis en el explorador recoge su estado de lo que denominamos un “monitor” o bien representa el estado de varios monitores agregados.

Si pulsáis sobre uno de ellos podréis acceder a las propiedades del monitor.

image

Dentro de las propiedades del monitor tenéis la configuración de la alerta, no todos los monitores tienen por que emitir alertas:

image

Así que tenemos que entender que toda alerta viene de un monitor que ha cambiado de estado.

Nota: En realidad las alertas pueden también venir de conectores con otros sistemas de monitorización o de procesos de orquestación, pero eso es otra historia.

Si damos por resuelta/cerrada una alerta que no hemos resuelto, tener de seguro que si el problema sigue pasando el monitor seguirá en rojo y no tendremos de nuevo una alerta hasta que el monitor se reevalué.

Algunos monitores como es el caso del que os estoy enseñando son capaces de resolver ellos solos las alertas, pero no deis esto por supuesto.

Por tanto, la regla mas importante del trabajo con alertas en SCOM es que  NUNCA deis por resuelta una alerta por quitárosla de encima sin haber resuelto el problema y sin revisar los monitores, haciéndolo escondes el problema durante un lapso de tiempo para tener que volver a el mas tarde lo que es frustrante, además haces que la consola de alertas no represente fielmente el estado de los monitores lo que es desconcertante.

¿Como puedo organizar las alertas?

En SCOM existen por defecto dos estados para las alertas, lo cual es claramente insuficiente:

image

Os recomiendo que como mínimo creéis dos mas, aunque podéis establecer los que queráis según vuestro criterio.

image

Como decía, yo suelo crear los estados “En resolución” y “conocido”, notar que el numero o ID es cualquiera libre de los 255 que podéis escoger y que no tiene importancia cual seleccionéis.

En las propiedades de cada alerta hay dos campos que son muy importantes para organizarnos:

image

El campo dueño nos permite indicar quien tiene que trabajar sobre la alerta o quien esta trabajando sobre ella, el campo estado nos facilita un medio de comunicar al equipo si el tema ya esta controlado.

De esta forma nos podemos crear un pequeño esquema de como podemos trabajar en equipo con las alertas de SCOM:

SCOM_Alertas

 

Os recomiendo que personalicéis las columnas de la vista general de alertas a través del menú de la misma de forma que se muestre el dueño de las alertas:

image

image

Ahora de un solo vistazo cualquier compañero que mire las alertas sabe que yo me estoy encargando de esta y que ya estoy en ello.

¿Como puedo crearme una vista con mis alertas?

El mejor sitio es “My Workspace” espacio que ves tanto en la consola de siempre como en la consola web.

image

Crea una vista de alertas

Configura las propiedades de la vista como ves en la siguiente imagen pero con tus parámetros.

image

image

¿Que hago entonces con las alertas con las que no estoy de acuerdo o que no se ajustan a nuestros criterios?

Una cosa buena de SCOM es que cada vez que cargamos un management pack introducimos en el sistema un montón de conocimiento, varemos y reglas ya parametrizadas.

Esto nos quita mucho trabajo y hace el sistema muy potente, sin embargo a veces un management pack puede decir por ejemplo que se nos avise cada vez que una unidad de disco tiene menos del 10% de espacio libre y puede que siguiendo con el ejemplo tengamos algunos servidores donde sabemos que esta condición se da y que no queremos que se nos avise pues conocemos el problema y no lo vamos a solucionar porque para este servidor no es un problema.

En estas situaciones emprender una guerra con SCOM por dar por resuelta la incidencia del espacio en disco es una perdida de tiempo y dejar la alerta no nos ayudara tampoco, cada X tiempo SCOM limpiara solo las alertas antiguas y la alerta volverá otra vez a salir.

La solución es realmente muy simple, solo tenemos que indicarle a SCOM lo que consideramos un problema y lo que no.

La siguiente vez que salga la alerta nos iremos a su monitor de la forma que os he enseñado antes, siguiendo con el ejemplo aquí tenéis el monitor de espacio libre en disco.

image

Nos vamos a la tab de “Overrides”

image

Ahora viene algo muy importante, cada vez que hagáis un override tenéis que pensar muy bien en hacerlo para el menor ámbito posible.

En nuestro caso solo queremos modificar cuando se nos avisa del espacio en disco libre de un disco en concreto de un servidor en concreto, así que seleccionamos la opción que nos permite crear el override limitándolo a ese ámbito que será “For a specific object of class: Windows Server 2008 Logical Disk”

Ahora nos saldrán todos los discos duros monitorizados por SCOM, seleccionar el que nos preocupe.

image

Ahora nos aparecen todos los parámetros del monitor que podemos modificar para este objeto concreto.

Como nosotros no queremos que se nos avise al 10% si no al 5% lo modificamos:

image

Fijaos que abajo del todo en la pantalla nos dice que el override se guardara en el default management pack, mi consejo es que nunca los guardéis ahí y que os creéis un management pack propio por cada uno que importéis para guardar este tipo de cambios.

Insisto en que hay que ser muy cuidadoso con los overrides, hacerlos sin criterio puede implicar que el día que pase algo de verdad no seremos avisados.

¿Como puedo saber todos los overrides que se han hecho?

En los informes tienes uno que te permite ver los overrides que hay activos para cada management pack.

image

Conclusiones:

  • No cierres las alertas sin resolverlas de verdad, si no puedes trabajar ahora con ellas, cámbialas el estado y asígnalas un dueño.
  • Si la alerta no es correcta no la cierres ni ignores, haz un override para que no de mas trabajo ni a ti ni a tus compañeros
  • Ten criterio y piensa dos veces los overrides antes de hacerlos
  • Se consciente de mirar siempre los monitores de salud antes de dar por resuelta una alerta, si algún monitor sigue en rojo, recalcula la salud del mismo desde su menú, si sigue rojo, es que el problema sigue ahí.

Espero que este post os haya sido de alguna ayuda.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Trabajar con unidades de disco sin letra:

 

Me hace una pregunta un amigo que trabaja en un partner desplegando soluciones de virtualización y gestión y como ya me lo han preguntado otra veces voy a contestar desde aquí.

Hoy en día cuando montamos un cluster de virtualización es común usar CSV para poder tener mas de una VM por LUN(Disco).

Sin embargo hay situaciones en las que podemos preferir dedicar una o varias LUN de disco a una VM por motivos de aislamiento, control, rendimiento, por requisitos de algún software, etc.

En estas ocasiones si a cada disco le damos una letra de unidad nos encontraremos con que si el cluster llega a tener muchos casos así, nos quedaremos sin letras de unidad.

Desde hace ya bastante tiempo Windows y por supuesto los clusters nos dejan trabajar con unidades de disco que no tienen letra.

Cuando una unidad no tiene letra, accedemos a ella mediante un identificador único al que llamamos GUID.

Existe el malentendido de que para trabajar sin letras de unidad es necesario inicializar el volumen con el estilo de formato de partición GPT en vez de MBR, deciros que esto es falso y que salvo en maquinas con arquitectura Itanium debéis de dejar el estilo de formato de partición GPT para aquellos volúmenes que vayan a tener mas de 2TB.

image

Para que un volumen no tenga letra solo tendremos que quitársela o no asignársela durante la creación.

image

Para mi la etiqueta del volumen es muy importante, en un cluster es una herramienta clave para tener trazabilidad en los discos desde todas las herramientas, suelo aconsejar que si es un disco SAN uséis la misma etiqueta que hayáis usado en la SAN, si ya además es una etiqueta que nos de información añadida pues mejor que mejor, como por ejemplo la SAN de la que viene, el tipo de discos, etc.

Bien, ya tenéis creado el disco, ¿ahora como accedéis?, desde el disk manager veréis que no podéis abrir la unidad, si vais al explorer la unidad no sale.

Para abrir la unidad lo primero que necesitáis es saber el GUID, para ello abrir el Powershell y ejecutar el siguiente comando:

“gwmi win32_volume|where-object {$_.filesystem -match "ntfs"} |fl Label, name”

image

Selecciona el GUID, cópialo, abre un “ejecutar” y pega el GUID, pulsa OK y tu volumen se abrirá en el explorador.

image

image

Espero que os sea útil.

Un saludo.

Crossposting from blogs.technet.com/dmatey

La CMDB en System Center

 

Puede que alguno no este familiarizado con lo que es la Configuration Management Database (CMDB), permitiros daros una definición: la CMDB es un repositorio de información donde podemos encontrar todos los componentes de los sistemas de información gestionados por un departamento de IT dentro del contexto de ITIL.

Si bien decimos que la CMDB es un repositorio, en realidad podemos también considerarlo un elemento abstracto que puede formarse a partir de información que resida en múltiples bases de datos.

Cualquiera que haya intentado aplicar ITIL en mayor o menor medida, sabe que el éxito de este reto esta estrechamente vinculado a la CMDB, sin esta información será imposible relacionar adecuadamente las actuaciones, solicitudes,  incidencias, problemas y cambios a los elementos de configuración (CI) que se vean afectados por ellos y de esta forma será muy difícil que consigamos la excelencia en el servicio pues no conseguiremos que la información nos sea útil.

Una CMDB que esta viva y descubra automáticamente los CIs, sin tener que empeñar la empresa, meterse en largos proyectos o vivir para ello es el sueño de muchos.

System Center como sabéis esta compuesto de varios productos, cada uno de ellos contiene información tremendamente importante para la CMDB.

En System Center el producto que expone la CMDB, que agrupa el conocimiento de System Center y el directorio activo y sobre la que podemos federar la información de CIs que pueda residir en otros sistemas es System Center Service Manager que además también es el que os permite trabajar con incidencias, cambios, solicitudes, problemas, etc.

El siguiente diagrama os muestra como System Center es sin duda una alternativa que tenéis que valorar si queréis conseguir una buena CMDB de forma fácil.

SM_CMDB 

 

Como veis la CMDB de SCSM esta construida sobre SQL Server e incorpora información de las siguientes fuentes:

  • Directorio Activo:
    • Importa automáticamente la información de usuarios, grupos, computadoras, servidores, impresoras, shares, etc.
  • System Center Configuration Manager
    • Importa automáticamente toda la información de inventario, hardware y software así como gestión de la configuración deseada y cumplimiento de normativas como la ley de protección de datos, etc.
  • System Center Operations Manager
    • Todos los CI monitorizados pueden ser incorporados automáticamente a la CMDB, esto incluye:
      • Cualquier tipo de producto monitorizado sea de Microsoft o no, como por ejemplo routers, servidores linux, bases de datos Oracle, lo que sea.
      • A traves de la conexión entre SCOM y SCVMM todo lo relativo a los CIs relacionados con la virtualización tanto de VMWare como de Hyper-V.
      • Información relativa a backups proviniente de SCDPM
  • A través de System Center Opalis podemos integrar en la CMDB de Service Manager
    • Otras CMDB (HP, IBM, BMC) federando de forma sencilla y trabajando las relaciones
    • Datos de cualquier otra base de datos, sacados de scripts, etc.
  • Finalmente a través del CSV connector del resource kit de SCSM es posible incorporar información a CIs o crear nuevos CIs con información en ficheros separados por comas.

Service Manager se encarga de agrupar los datos de los CIs desde las diferentes fuentes.

Una vez que tengamos los CIs con toda su información en la CMDB de Service Manager ya podremos comenzar a trabajar con ellos.

Espero publicar nuevos posts explicando como instalar Service Manager y como trabajar con los CIs, gestionar incidencias, problemas, cambios, etc.

Espero que os haya gustado el post y que construyáis vuestra CMDB sobre Service Manager.

Un saludo.

Crossposting from blogs.technet.com/dmatey
Instalación de Opalis 6.3 Parte 1 de 2

 

La instalación de Opalis no es de las mas sencillas que tenemos en Microsoft, por eso voy a explicaros de la forma mas rápida y sencilla posible como desplegar Opalis para que podáis probarlo.

Como sabéis y ya he explicado en este blog, Opalis sirve para automatizar y orquestar proceso a través de flujos de actividades que diseñamos nosotros, estos flujos (workflows) estan agrupados dentro de politicas (policies)

En Opalis tenemos varios componentes principales:

  • Una base de datos SQL Server
  • Un management server desde el que contramos Opalis
  • Uno o mas Action Servers que corren las políticas

En otros posts hablaremos de todas las consolas incluida la web de operación y elementos adicionales como el web service de acceso, el remote trigger y la herramienta que nos permite crear nuestros propios IPs.

Vamos a realizar la instalación completa para ello os podéis bajar la versión de evaluación de este enlace: http://www.microsoft.com/systemcenter/en/us/opalis.aspx 

Opalis requiere una base de datos SQL Server 2005 o 2008 que no sean Express, la podéis instalar en el propio servidor de Opalis o en otro servidor.

El servidor puede ser de 32 bits o x64 y Windows Server 2008 R2 también esta soportado.

Aunque Opalis se pueda instalar en x64 es un programa de 32 bits, esto implica que cuando Opalis llama a powershell por ejemplo lo hace a la versión de 32 bits, esto no es un problema insalvable y ya os contare como arreglarlo si en algún momento necesitáis hacerlo.

Si me preguntáis, creo que lo mas acertado para empezar suele ser montarlo en Windows Server 2008 x86.

Yo como soy como soy, lo voy a hacer en este post en R2(x64) pero el proceso será igual.

Tenéis que crear una cuenta de servicio para Opalis, hacerla administrador local del servidor.

Aseguraros de que la cuenta con la que instaláis el Opalis tenga permisos en la base de datos.

0

Ejecutamos el setup de la carpeta de Opalis 6.2.2, acordaros de hacerlo con “Run As Administrator”

1

2

Seleccionamos “Install Opalis Integration Server”

3

Lo primero será montar el management server

4

Pulsamos “Next”

5

Aceptamos el acuerdo y pulsamos “Next”

6

Introducimos nuestros datos y pulsamos “Next”

7

Dejamos la ruta por defecto y pulsamos “Next”

8

Introducimos los datos de la cuenta de servicio que hemos creado anteriormente y pulsamos “Next”

9

Pulsamos “Next”

10

Pulsamos “Finish”

11

El siguiente paso es configurar el acceso a la base de datos que habremos configurado previamente.

Seleccionamos “Configure Datastore”

12

Seleccionamos “Microsoft SQL Server” y pulsamos “Next”

13

Indicamos el nombre del servidor en el que esta el SQL Server, recordar que en este punto tenéis que estar usando para correr el setup un usuario que sea system administrator de SQL Server.

14

Creamos una nueva base de datos, nombre por defecto “Opalis”, pulsamos “Next”

15

Pulsamos “Ok”

16

Antes de continuar importando las licencias necesitamos hacer varias cosas mas.

Lo primero ve al administrador de SQL Server y añade el login de la cuenta de servicio de Opalis, asígnale permisos de Owner en la base de datos de Opalis (si no haces esto, no funcionara)

Ahora copia el archivo que ves en la siguiente imagen de la carpeta de instalación del Opalis 6.3 a la carpeta Opalis\Management Service\Components\Objects que tienes dentro de Program Files(x86) en el servidor de Opalis y ejecuta el MSI.

17

18

Pulsa “Next”

19

Introduce tus datos y pulsa “Next”

20

Pulsa “Next”

21

Ahora ten cuidado viene algo completamente nuevo; pulsa “Next” Winking smile

22

Pulsa “Finish” y reinicia el servidor.

Cuando el servidor arranque asegúrate de que los servicios de Opalis han arrancado

24

Si no lo han hecho es momento de repasarlo todo, mirar el visor de eventos y los ficheros dentro de la carpeta logs dentro de la carpeta de Opalis.

Paso siguiente, ejecutar el MSI del parche para el management service de Opalis que encontráis en la carpeta de instalación del Opalis 6.3.

25

26

Pulsamos “Next”

27

Pulsamos “Finish”

28

Ejecutamos el “Deployment Manager” de Opalis con un “Run as administrator” solo para ver que funciona.

29

Nota: si os da un error “No such inteface supported” mirar los permisos de SQL Server para la cuenta de servicio que no están bien.

Volvemos al setup.

30

Seleccionamos “import license”, en la carpeta de instalación encontraras una carpeta llamada licences, dentro de ella hay un montón de archivos “.LIC” que son las licencias de los diferentes integration packs, también encontraras un archivo “.DOC” llamado Opalis Product Licences que tiene las key de cada fichero.

Ahora tienes que echarle paciencia, dale al botón “import” selecciona un fichero de un integration pack que quieras usar mas tarde y copia y pega la key desde el fichero .doc, pulsa “OK” y esto con cada IP.

Te aconsejo que no metas todos los IP, solo los que vayas a usar.

Desde el setup instalamos el cliente de Opalis.

33

Pulsamos “Next”

34

Aceptamos las condiciones y pulsamos “Next”

35

Introducimos nuestros datos y pulsamos “Next”

36

Pulsamos “Next”

37

Pulsamos “Next”

38

Pulsamos “Finish”

De la carpeta de instalación del Opalis 6.3 ejecutamos el parche para el cliente

39

40

Lo siguiente es registrar los integration packs que vayamos a necesitar.

Abrimos la consola del deployment manager

41

Seleccionamos “Register IP with the management server”

En las carpetas de instalación que has descomprimido hay integration packs dentro de las carpetas de la 6.2.2 el service pack 1 de la 6.2 y los ultimos de System Center que están en la carpeta de instalación de la 6.3, te recomiendo que los descomprimas todos en una única carpeta para ir mas rápido y no dejarte ninguno.

También tienes algunos IPs (sharepoint, manipulación de datos, logs y uno mas de AD) en la web de codeplex.

48

Tendrás que añadirlos uno a uno, pulsando “add” cuando los tengas todos pulsa “Next”

49

Pulsa “finish” el proceso tardara un poco.

50

Ahora tenemos que crear nuestro primer action server que es el que se encargara de ejecutar las políticas de automatización y orquestación a las que llamamos políticas o policies.

Puedes tener varios action servers por tolerancia fallos, seguridad u organización.

Puedes usar el mismo servidor de Opalis como management server y como action server

51

52

Pulsa “Next”

53

Introduce el nombre del servidor y la cuenta de servicio que obviamente puede ser la misma.

Pulsa “Next”

54

Selecciona todos los integration packs que quieres desplegar en este action server y pulsa “Next”

55

Pulsa “Finish”

Ya has instalado la mayor parte de Opalis, ya puedes arrancar el la consola cliente que tendrás en el menú de inicio dentro de Opalis y empezar a crear tus automatizaciones.

En el siguiente post os mostrare como montar la consola web de operación.

Un saludo.

Crossposting from blogs.technet.com/dmatey

Introducción a System Center Opalis; tu mejor aliado en el día a día.

 

image

 

System Center Opalis ha sido el ultimo miembro en llegar a la familia de productos Sytem Center.

Opalis sin embargo no es precisamente un recién nacido, Opalis era ya uno de los productos lideres en su segmento y Microsoft lo adquirió hace un par de años con el fin de complementar System Center en uno de los aspectos que se prevé sea cada vez mas importante en los departamentos de IT, la automatización y orquestación de procesos disciplina que además es uno de los aspectos clave de la nube privada.

Todo departamento de IT dedica una importante parte de sus recursos humanos a la realización de procesos, un porcentaje importante de los cuales es repetitivo y por lo tanto susceptible de automatizarse.

Cada vez que una persona realiza un proceso esta acción tiene un coste, que entre otras cosas estará compuesto por una partida muy importante horas/hombre.

Además debemos tener en cuenta que el tiempo que IT dedica a la realización de procesos es tiempo que no dedica a labores que tengan impacto en el negocio, reduciendo así las posibilidades que tiene el departamento de IT para representar una ventaja competitiva para la empresa, lo que ancla IT a esa visión de ser un simple e incomodo centro de coste que aun tienen muchas empresas.

Otros aspectos a recalcar cuando hablamos de orquestación y automatización son sin duda los de la trazabilidad, seguridad y reducción del riesgo de errores, un proceso automático es seguro que siempre cumplirá con las políticas establecidas y que será auditable, todos somos humanos y hasta el mejor de los administradores se ha saltado un paso en un procedimiento o ha cometido un error.

La automatización de los procesos también evita esos quebraderos de cabeza que hay todos los departamentos de IT, cuando alguien esta de vacaciones y no se tienen sus procedimientos bien documentados o cuesta seguirlos.

Para terminar de contaros ventajas que estamos encontrando en los clientes a los que les estamos enseñando Opalis, es común encontrar en los departamentos de IT, procesos que todo el mundo sabe que habría que realizar pero que no se hacen por falta de tiempo, como por ejemplo el que voy a automatizar en este post para mostraros como funciona Opalis y que será probar los backups.

Hasta aquí todos estaremos de acuerdo, pero seguro que estáis pensando que todo esto es muy bonito pero que automatizar un proceso  seguro que tiene sus pegas, normalmente nos centraríamos en dos:

  • Necesitamos complejos conocimientos de programación o scripting y luego es difícil realizar cambios y mantener el código
  • Desarrollar la automatización puede llevarnos mas tiempo que hacerlo a mano

Lo bueno que tiene Opalis es que nos abstrae en casi todos los casos de la realización de scripts o de programar ya que esta pensado para que diseñemos las automatizaciones de forma sencilla arrastrando y soltando las acciones y enlazándolas entre ellas, permitiéndonos muy fácilmente pasar la información de unas actividades a otras.

De esta forma desarrollar la automatización de un proceso no requiere desarrolladores o complejos conocimientos solo algo de practica y saber lo que se quiere hacer.

Como decía antes cada vez que realizamos un proceso esto tiene un coste, supongamos el siguiente ejemplo que además voy a hacer usando tecnologías que no son de Microsoft para que veáis la potencia de Opalis en entornos heterogéneos.

Juan que es un administrador de copias de seguridad tiene entre sus obligaciones probar las copias de seguridad de una aplicación critica para su empresa, para ello dedica 2 horas dos veces por semana siguiendo un procedimiento que consiste en:

1 Recuperar la copia de seguridad en un servidor de pruebas de la base de datos de la aplicación usando Veritas NetBackup

2 Recuperar también la copia de los ficheros de la web de la aplicación

3 Configurar el IIS de la aplicación web

4 Probar la aplicación

5 Deshacer las instantáneas de las maquinas virtuales de VMware que usa para el proceso preparándolas para la siguiente vez

6 Para el control del departamento, Juan tiene que introducir en el Remedy una solicitud ya cerrada asociada a a la aplicación indicando que los backups han sido probados.

7 Si las pruebas han salido mal, tiene que meter una incidencia en Remedy indicando el problema y asignándosela al responsable de los backups de esa aplicación y mandar un correo al responsable del servicio para que tenga conocimiento

En siguientes posts haremos automatizaciones paso a paso para que veáis lo sencillo que es, ahora simplemente os pondré una captura de pantalla de como se vería la automatización de este ejemplo en la consola cliente de Opalis.

image

Realizar esta automatización y probarla bien no debe llevarte mucho tiempo, a mi no me ha tomado mas de 20 minutos tener el esqueleto, pero digamos que te llevara 6 horas, a mitad de la segunda semana ya habrías amortizado el esfuerzo!

En esta otra captura tenéis un ejemplo de como configurar la actividad de quitar una instantánea de una VM, al final cada actividad simplemente tiene que ser configurada de esta forma.

image

Otro ejemplo, la actividad de mandar un correo:

image

Los enlaces (líneas) entre cada actividad nos permiten configurar cuando queremos que funcionen si al fallar la anterior actividad o al tener éxito.

image

Los parámetros de cada actividad pueden rellenarse manualmente o bien ser recogidos de los datos publicados por actividades anteriores:

image

Opalis se integra automáticamente con un montón de productos gracias a los paquetes de integración (IPs) que trae el producto.

Si no existe un IP y el producto con el que te quieres integrar tiene algún tipo de interfaz de automatización (servicios web, scripts, objetos COM, .Net, Java, ficheros, SNMP, etc) es posible hacerte tu propio IP con una herramienta gratuita de Microsoft llamada QIK.

En este enlace podéis encontrar todos los productos con los que se integra Opalis: Opalis Integration Pack Workflow Object List, como veis hay productos de BMC, IBM, HP, VMware, Microsoft y muchos otros fabricantes.

Además en la versión 6.3 ya disponible tenéis también los IPs para System Center lo que os permite automatizar procesos con SCVMM, SCCM, SCOM, SCDPM y SCSM. (http://blogs.technet.com/b/systemcenter/archive/2010/08/31/introducing-the-new-opalis-6-3-integration-pack-activities.aspx )

Por supuesto también puedes automatizar el directorio activo (crear usuarios, cambiar contraseñas, etc), operaciones de ficheros, logs, ficheros de texto, traps SNMP, trabajar con eventos, etc., el abanico es mas que extenso.

Empieza a haber una creciente comunidad de usuarios de Opalis desarrollando sus propios IPs, ya pueden encontrar IPs también para Sharepoint, mas actividades aun para SCOM y el AD, manipulación de datos, etc.

Opalis se adquiere como parte de las suites de System Center , si aun no tienes licenciada ninguna suite de System Center y queréis probarlo podéis descargar una versión de evaluación desde http://www.microsoft.com/opalis.

Espero que Opalis se convierta en vuestro mejor aliado y os ayude a mejorar vuestro día a día.

Un saludo.

Crossposting from blogs.technet.com/dmatey

Virtualizando Exchange 2010

 

En este post voy a intentar responder a las cuestiones mas comunes que nos preguntáis acerca de la virtualización de Exchange 2010 que además son casi todas extrapolables a Exchange 2007.

¿Recomiendas virtualizar Exchange?

Lo que de verdad, de verdad recomendamos todos es que tu Exchange este diseñado, dimensionado y desplegado conforme a las buenas practicas y recomendaciones, esto es independiente de si lo virtualizas o no.

Un arquitectura de Exchange bien diseñada y dimensionada que sea desplegada sobre una plataforma de virtualización bien diseñada, dimensionada y gestionada funcionara tan bien como una desplegada sobre servidores físicos, sin embargo un Exchange virtualizado sobre una plataforma de virtualización improvisada seguro que nos da algún quebradero de cabeza y esto será igual virtualicemos con lo que virtualicemos ya sea Hyper-V u otro producto.

¿En que afecta el virtualizar o no virtualizar al diseño de Exchange?

En los documentos de diseño de Exchange 2010 veras que se suele decir que en nada, que debes realizar el diseño de igual forma que si fuera en físico.

Sin embargo en mi opinión si que afecta en dos cosas principalmente:

  • Probablemente vas a querer que ningún servidor virtual tenga mas de 4 procesadores virtuales, si trabajas para una empresa con miles y miles de buzones esto tendrá implicaciones para el numero máximo de buzones por servidor y en general para el numero de servidores que tendrás que desplegar.
  • Tu diseño tendrá que contemplar un capitulo mas que hable de como vas a alinear el despliegue de Exchange con el diseño actual de plataforma de virtualización y si es necesario algún cambio.

Espera, espera ¿Estas hablando de virtualizar también los servidores de Mailbox?

Todos los roles de Exchange con la excepción del rol de mensajería unificada están soportados virtualizados, esto incluye los servidores de Mailbox.

Sin embargo un rendimiento deficiente de los servidores de buzones seria horrible para tu servicio de correo y si vas a virtualizar este rol tienes que tener especial cuidado.

Si tienes varios miles de buzones a tu cargo probablemente elegir virtualizar tus servidores de buzones implicara que tengas algún servidor mas en virtual de lo que habrías tenido de desplegarlo en físico, sin embargo para muchos clientes las ventajas de gestión, alineamiento con la estrategia de arquitectura de la compañía, recuperación ante desastres, etc. hacen que puedas querer virtualizar estos servidores.

¿Que debo tener en cuenta especialmente al virtualizar un servidor de Mailbox?

El proceso es muy simple:

Toma tus decisiones en cuanto a las bases de datos de tu Exchange como si fueran físicos, ten en cuenta las copias que habrá en tu DAG, las copias de seguridad,  tipos de discos, etc.

Usa el Exchange Profile Analyzer (EPA) para entender el perfil de uso del correo en tu sistema actual (http://www.microsoft.com/downloads/en/details.aspx?familyid=C009C049-9F4C-4519-A389-69C281B2ABDA&displaylang=en ).

Con los datos del EPA usa el Exchange Storage Calculator (http://msexchangeteam.com/archive/2010/01/22/453859.aspx ) para calcular los requisitos de storage.

image

A mi me gusta ir mas que sobre seguro así que suelo aumentar el parámetro de sobrecarga de IO en el storage calculator en 10% mas.

image

Es muy importante que rellenemos todos los campos con la información mas ajustada posible y que realicéis varios cálculos con diferentes opciones, por ejemplo un aspecto muy importante son los tipos de discos:

image

El tamaño de las bases de datos tiene un impacto brutal en la carga esperada del sistema, RAM requerida, etc. seguir las recomendaciones que podéis encontrar en la technet y realizar varias simulaciones con diferentes tamaños hasta dar con el que se adecua a vuestros requisitos y por favor tener en cuenta los tiempos de recuperación al definir el tamaño estándar de vuestras bases de datos.

Por supuesto tenéis que especificar también el asunto de los 4 procesadores y los megaciclos que tienen vuestros procesadores (ojo con los ratios de consolidación, luego hablare de ello, lo de los megaciclos se explica en el blog del equipo de producto de Exchange, es fácil de calcular):

image

Algo que va a hacer la calculadora por nosotros es recomendarnos el nivel de Raid que tenemos que usar (si es que la cabina nos deja especificarlo) y finalmente en función de todos los parámetros introducidos nos dará las IOps:

image

Bien, pues aquí viene el aspecto clave de todo esto, tenemos que asegurarnos de que nuestros servidores de buzones tendrán las IOps que requieren.

Para ello la mejor forma es desplegar y configurar nuestras maquinas virtuales y su correspondiente almacenamiento y empezar a probar.

Yo lo hago así:

-Para terminar de diseñar el almacenamiento realizo unas primeras comparativas entre las diferentes opciones usando IOMeter con un perfil de IOPs parecido al de Exchange.

-Cuando ya tengo una decisión preliminar uso el JetStress para realizar la prueba definitiva con las mismas configuraciones de DAG, etc. que voy a desplegar en producción (http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=13267027-8120-48ed-931b-29eb0aa52aa6) esta herramienta es la definitiva si el nivel de IOps esta por encima del que necesitamos podemos continuar adelante, si no tendremos que seguir haciendo cambios (una vez mas me gusta añadir un pequeño margen de seguridad)

Hay algunas consideraciones a tener en cuenta al diseñar el almacenamiento:

  • El numero de copias definirá si usas JBOD o no, si es que no, deberías usar RAID, esto es muy importante por que cada tipo de RAID como sabes tiene su impacto en las IOps.
  • Si usas FATA de 7200Rpm no uses RAID 5
  • Formatea los discos (tanto los físicos como los virtuales) con un allocation unit de 64Kb.
  • Alinea los discos si es necesario para tu storage, podemos estar hablando de una sobrecarga importante si los discos no están alineados.
  • Usa discos pass-through si puedes, si no puedes usa VHD fijo.
  • NUNCA, NUNCA uses discos virtuales que no sean de tamaño fijo y nunca uses instantáneas en los discos duros virtuales de las bases de datos o logs.
  • Dependiendo del diseño que hagas puede no ser necesario separar logs y bases de datos, tenlo en cuenta para reducir LUNs.

Exchange virtualizado tendrá que convivir en un mismo host con otras cargas, por favor ten en cuenta:

  • No esta soportado que el ratio de consolidación de procesadores virtuales sobre cores físicos en los hosts donde estén virtualizados lo Exchange sean mayor que 2:1 o sea en un host de 2 procesadores de 4 cores no deberías tener mas de 16 procesadores virtuales en total.
    • Yo no te recomendaría mas de 15 en realidad
    • Esto es igual uses Hyper-V, VMWare, lo que sea…
    • La calculadora de storage te dará una aproximación sobre la carga de micro que puedes esperar:

image

  •  
    •  
      • Asegúrate de sumar lo que necesites para el antivirus, agentes de monitorización, etc., suma un margen “prudencial” y si te da mas del 50% entonces tu ratio de consolidación procesadores virtuales/cores físicos deberá ser evaluado acorde.
  • En los servidores de buzones no uses técnicas de memoria dinámica, sobrecarga de memoria, swap o lo que sea, no tiene ningún sentido por como funciona Exchange 2010 en relación con la memoria.
  • No es normal que tengas problemas de contención con las HBA o la red, pero revisa el estado de capacity de tu plataforma de virtualización antes de sumar una carga tan importante.

Si vas a usar DAG, ten en cuenta que no esta soportado virtualizar los Mailbox con DAG sobre plataformas de virtualización que aporten su propia alta disponibilidad, esto una vez mas es igual para Hyper-V que para otras plataformas de virtualización con independencia de lo que te puedan decir, al final quien soporta o no Exchange es Microsoft asi que es a Microsoft a quien debemos hacer caso sobre lo que esta o no soportado.

Si vas a usar CSV, por favor no uses un CSV para todo, separa los sistemas operativos, las bases de datos, etc. en diferentes CSV, como buena practica proponte un tamaño de CSV estándar de entre 380Gb y 500GB y no los sobresatures.

Bien ya tengo mi Exchange 2010 virtualizado en producción, ¿cual es el consejo mas importante que me darías?

No hay ninguna duda: Monitoriza, monitoriza, monitoriza.

Usa una herramienta experta capaz de entender perfectamente Exchange y tu plataforma de virtualización, a ser posible que entienda también tu hardware, HBAs, cabinas, etc y que analice en tiempo real el rendimiento de tus servidores incluido el flujo de correo.

Si me preguntas, solo se de una que haga todo esto tanto para Hyper-V como para VMWare y es System Center Operations Manager 2007 R2, si no tienes la suerte de poder usarlo ni evaluarlo asegúrate de contar con la mejor monitorización que puedas.

Exchange virtualizado sin monitorizar no es una buena idea., de hecho virtualizar sin monitorizar no es una buena idea.

¿Junto o por separado?

Si tienes unos cuantos miles de buzones si sumas todos los roles en alta disponibilidad seguramente te darán suficientes VMs como para llenar 2 hosts normales así que te surgirá la pregunta de si juntar todos los roles o no.

Seria algo como esto por ejemplo:

image

En principio esta alternativa de diseño tiene de bueno que Exchange no se ve afectado por otras cargas y que el dimensionamiento por tanto es seguro.

En contra desde luego tiene que si pierdes un host pierdes mucha de la infraestructura y que el otro servidor asumirá toda la carga, pero se supone que para eso esta dimensionado.

Otra cosa a tener en cuenta sobre esta alternativa de diseño es que es muy poco “cómoda” para administrar, cuando tienes que reiniciar un host por algo tiene sus implicaciones y requerirá trabajo.

¿Y los EDGE?

Ningún problema virtualizalos también, son grandes candidatos para ello, pero por favor ten en cuenta que los EDGE tienen que estar en la DMZ y que DMZ y redes internas no redes tan diferentes a nivel de seguridad que te recomendaría encarecidamente que despliegues en la DMZ servidores específicos de virtualización sin conexión con tus redes internas.

Con el tiempo espero escribir un post sobre virtualización en DMZ.

¿Por que creemos que debes valorar Hyper-V R2 para virtualizar Exchange?

Si ya usas Hyper-V no me harás esta pregunta Winking smile si aun no lo usas aquí tienes los puntos que creo debes considerar:

  • Hyper-V al igual que Exchange son productos de Microsoft, esto implica grandísimas ventajas a tener en cuenta a la hora de virtualizar un servicio tan critico:
    • Como es lógico desde el comienzo del desarrollo los equipos de Microsoft realizan sus pruebas, despliegues y desarrollos sobre Hyper-V, esto implica que al final del desarrollo esta mas que garantizado que Exchange funcionara perfectamente sobre Hyper-V y que tendrá un fantástico rendimiento.
    • Por la misma razón es de esperar que nuevos Service Packs, parches, etc., siempre estarán probados sobre Hyper-V.
    • Si alguna vez tienes un problema y tienes que acudir a soporte de Microsoft por un problema con un Exchange sobre Hyper-V, el proceso de resolución como es lógico es mas eficiente comparación con otras soluciones, los técnicos de soporte especializados de Exchange estarán en contacto con los técnicos especializados de Hyper-V y Windows Server, el trabajo en equipo y el conocimiento en profundidad de todas las tecnologías implicadas es obvio que ayuda cuando estamos hablando de incidencias complicadas.
    • Por supuesto aplican las mismas razones generales de Hyper-V, mejores herramientas de gestión, ahorro de coste, etc, etc.

Y si de momento no voy a usar Hyper-V, ¿puedo virtualizar Exchange?

Claro, todo lo que he contado en este post aplica también a otras plataformas de virtualización.

Puedes consultar si la tuya esta soportada o no en este enlace: http://windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm 

Conclusiones

Virtualiza si es tu decisión de arquitectura pero hazlo con garantías y criterio.

Espero que el post os haya sido de ayuda.

Un saludo para todos.

Crossposting from blogs.technet.com/dmatey

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

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.

Crossposting from blogs.technet.com/dmatey
Extendiendo SSP 2.0 en la nube privada II: Integrando SSP y SCVMM con Opalis

 

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:

1

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.

2

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:

image

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.

image

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:

image

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.

image

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.

image

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:

image

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.

image

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:

image

Una vez la política de Opalis corra, podréis empezar a ver ya los resultados en SCVMM en las propiedades de las VMs:

image

image

Que se corresponden con las que estan en el portal:

image

Gracias a esto, ahora por ejemplo podemos de forma fácil parar todas las VMs de un cliente concreto:

image

Espero que os haya resultado interesante.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey
Extendiendo SSP 2.0 en la nube privada I: Objetivos

 

El portal de autoservicio 2.0 nos permite disponer de un frontal de autoservicio para nuestra nube privada de forma rápida y gratuita.

Esto es suficiente para muchos de vosotros, sin embargo otros tendréis planes más completos para vuestra nube privada y probablemente tendréis una serie de inquietudes al respecto que voy a tratar de aclararos en los siguientes posts.

A simple vista, si trato de ponerme en el lugar del arquitecto y del equipo de administradores de la nube privada echaría de menos en primer lugar las siguientes cosas:

  • Disponer en SCVMM de la información del portal SSP (Centro de coste, roles, infraestructuras, etc.) de forma que desde la consola pueda rápidamente agrupar y buscar VMs en base a estos criterios y por supuesto desde script automatizar tareas que afecten por ejemplo a todas las VMs de un rol concreto en una infraestructura concreta.
  • Que la jerarquía que suponen las unidades de negocio, infraestructuras, etc. estén representadas en SCOM de forma automática
  • Que los parámetros indicados desde el SSP en cuanto a backup y parcheo permitan automatizar dichas configuraciones en SCDPM y SCCM respectivamente.
  • Que las VMs terminen de aprovisionarse con los servicios adecuados en función del rol seleccionado para ellas en el portal y sin requerir decenas de plantillas
  • Enviar una notificación por correo a los dueños de las VMs días antes de la caducidad indicada para la VM

Creo que resolviendo estas inquietudes os podre enseñar suficientes ejemplos para que podáis desarrollar vuestras propias soluciones para vuestras necesidades.

Aunque haya pasado mucho tiempo de mi vida profesional desarrollando ahora se supone que soy un IT Pro así que no voy a desarrollar una sola línea de código para resolver estas necesidades, voy a usar uno de los productos más importantes de System Center para la nube privada nuestro orquestador y automatizador de procesos llamado System Center Opalis.

Podéis descargar System Center Opalis de http://www.microsoft.com/opalis y en siguientes posts explicare como instalarlo y configurarlo.

Un saludo.

Crossposting from blogs.technet.com/dmatey
Gestionando la memoria dinamica VI (b): Controlando la presión (Informe personalizando SCOM)

 

En el anterior post veíamos como tener monitorizada la presión de memoria desde SCOM y como lanzar alertas si fuera necesario.

Ahora vamos a crear de forma rápida un informe personalizado con SCOM 2007 R2 CU3.

Accedemos al apartado de reporting de la consola de SCOM y seleccionamos “Microsoft Generic Report Library” y después el informe “Performance

rp5

Ahora introducimos los datos que queremos para el informe tal y como veis en el siguiente ejemplo:

Nota: Podéis usar grupos de objetos en vez de como he hecho yo seleccionar directamente el host, así os saldrá las VMs de todos los hosts y de nuevos hosts que añadáis en un futuro.

rp

Ya podeis correr el informe

rp2

Paso siguiente, en el menu “File”  seleccionamos la opción “Save Report to a Management Pack”, damos un nombre al informe y lo seleccionamos el management pack que nos creamos en el post anterior.

rp3

Y ya esta, ya podeis correr el informe siempre que querais.

rp4

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Gestionando la memoria dinamica VI: Controlando la presión

 

SP1 de SCVM R2, de momento la RC no incorpora a sus management packs de SCOM la información que necesitamos para tener contralada la presión de memoria en nuestras VMs una vez activemos la memoria dinámica en ellas.

Cuando una VM está usando la memoria máxima configurada en la memoria dinámica, decimos que su presión de memoria es un 100% a partir de ese valor estaremos de seguro paginando en disco.

Para que el balanceador de memoria de Hyper-V pueda jugar con la memoria es necesario que o bien tenga memoria libre o bien se la pueda quitar a VMs que no estén usando toda su memoria y que tengan activada la memoria dinámica.

Por tanto si yo tuviera que administrar una plataforma de virtualización con memoria dinámica querría ser informado si alguna VM está por encima del 100%, además me gustaría tener una visión a largo plazo de cómo está evolucionando la presión en las VMs y la cantidad de memoria con la que puede jugar el host.

Para conseguir estos objetivos vamos a usar como es lógico System Center Operations Manager, recalcar que previamente deberíamos haber instalado el management pack de Hyper-V.

Quiero comentaros que lo que vamos a hacer es algo muy rápido y que se puede hacer mucho mejor con un poquito de tiempo, sin embargo lo hago de esta forma pensando que en breve tendremos los management packs definitivos que incluirán todo lo necesario.

Lo primero que haremos es crear un nuevo management pack

1

2

3

Bien ahora desde la consola en el apartado de “authoring” generaremos 3 reglas con las configuraciones que se muestran a continuación.

La primera de ellas recolectara los datos de rendimiento relativos a la presión actual en cada VM

4

5

La segunda guardara la presión media, si lo configuramos con algo más de tiempo que la anterior será más fácil detectar variaciones bruscas.

6

La tercera nos permitirá saber con cuanta memoria cuenta el host para balancear y atender las peticiones de las VMs

7

Ahora que ya guardamos los datos es momento de configurar las alertas, para ello creamos un monitor de doble estado con la configuración que veis a continuación.

8

9

10

11

12

Y aquí ya os puedo explicar por qué digo que se puede hacer mejor, sin usar las herramientas de authoring no podemos evitar que este monitor evalué todas las instancias de VM como un todo, esto significa que si una VM tiene la presión por encima de 100 el monitor se pondrá rojo, pero en la siguiente evaluación si otra VM está por debajo de 100 el monitor se pondrá verde y la alerta se resolvería sola y nunca la veríamos, por esa razón como veis he quitado la opción de resolver automáticamente la alerta si el monitor vuelve a verde. Como digo esto lo podemos resolver haciendo el management pack con algo más de tiempo y las herramientas adecuadas.

Perf

Ahora ya será cuestión de hacernos unas sencillas vistas para ver la presión de las VMs y estresarlas para ver si sale la alerta

alert

Si vemos el explorador de salud del host veremos lo siguiente:

mon

En el siguiente post os explico como sacar un informe de la presión de memoria de las VMs.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Gestionando la memoria dinamica V: El portal de autoservicio SSP 2.0

 

Como es lógico siendo SCVMM SP1 una versión RC, su uso desde SSP 2.0 no está soportado, sin embargo para aquellos que tengáis curiosidad en saber si podéis aprovisionar máquinas virtuales usando memoria dinámica desde el portal de autoservicio os diré que funcionar, aparentemente funciona.

A continuación vamos a ver como configurar los diferentes elementos para poder ver cómo funciona.

El primer paso es modificar en SCVMM aquellas plantillas de máquina virtual que queramos que empleen memoria dinámica.

1

2

En el portal de autoservicio habremos configurado previamente las infraestructuras, roles y plantillas a usar, de forma que en realidad no tendremos que tocar el portal si ya teníamos configurado que usara las plantillas que hemos reconfigurado para usar memoria dinámica. (si no conoces bien el portal de autoservicio puedes consultar los post de mi compañero David Cervigon sobre el tema, sin duda te servirán de ayuda conceptos e instalación )

3

Vamos a probarlo!,  pulsamos en “Create virtual machine” y seleccionamos los parámetros de unidad de negocio, infraestructura, servicio y rol que queremos desplegar, estos parámetros determinaran las plantillas disponibles.

4

Indicamos si queremos generar una o varias VMs y la plantilla que usaremos (la que previamente habremos modificado para usar memoria dinámica)

5

Seleccionamos la red y el dominio en el que estará la VM

6

Una vez pulsemos “Create” se nos mostrara el trabajo de despliegue ejecutándose (si no lo ves pulsa F5)

7

Si miramos la consola de SCVMM veis como el trabajo se está ejecutando

8

El proceso termina correctamente y la VM tiene configurada memoria dinamica tal y como esperábamos.

9

Ahora, ¿qué pasa si importamos una plantilla nueva en vez de modificar una que ya teníamos configurada en el portal?

Lo único a tener en cuenta es que el portal no está hecho para entender el SP1 del SCVMM ni la memoria dinámica, así que hasta que haya una actualización que lo soporte el portal detecta como memoria configurada la memoria mínima que hayamos configurado en la template cómo podemos ver en la siguiente imagen.

10

Pero la plantilla se importa bien…

11

Por tanto el truco está claro, si no queremos que los usuarios del portal de autoservicio sean conscientes de que estamos haciendo un “overselling” de la memoria lo único que tenemos que hacer es importar la plantilla con memoria estática y luego modificar la plantilla desde la consola de SCVMM para que tenga memoria dinámica.

Recordatorio: Por favor tener en cuenta que tanto el SP1 de R2 que es el que permite la memoria dinámica como el SP1 del SCVMM R2 no están soportados en producción y que el portal SSP 2.0 aunque parezca que funciona no está pensado para trabajar con estas nuevas funcionalidades.

Si me vais a preguntar que cuanto queda para que salgan las versiones finales, os dire que queda poco Winking smile

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

Gestionando la memoria dinamica IV: La consola de SCVMM R2 SP1

 

Para configurar la memoria dinámica en una VM simplemente nos iremos a las propiedades de la misma y dentro del tab “Hardware Configuration” seleccionaremos la opción de memoria dinámica dentro del apartado de memoria.

7

Recordar que la VM tiene que estar apagada para que os deje cambiar de estática a dinámica y al contrario.

La prioridad que tenga una máquina virtual para solicitar memoria en contra de otras en caso de presión excesiva se realiza desde el aparto de prioridades que encontráis dentro de “Advanced”

8

Sabéis que siempre aconsejamos que seáis cuidadosos al configurar prioridades pues sin duda con configuraciones que requieren ser controladas y tener un seguimiento a lo largo del tiempo.

En la consola podéis cambiar fácilmente las columnas que se muestran en la vista de máquinas virtuales para incluir aquellas relativas a la memoria.

6

Esto os permitirá contar con toda la información a simple vista.

14

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey
Más artículos Página siguiente >