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 OpalisManagement ServiceComponentsObjects 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