SoftGrid (Parte 1) Introducción e Instalación del servidor

Introducción a softgrid.

Cuando alguien me pregunta que es lo que más me fascina de la tecnología de Microsoft que esta por venir, tengo que decir que de entre toda la vorágine de tecnologías apasionantes, las dos que me parecen más revolucionarias son Hypervisor de longhorn y Softgrid.

Hypervisor como ya sabéis es la tecnología de particionamiento que funcionara con Longhorn y que permitirá particionar el hardware obteniendo maquinas virtuales de 32 o 64 bits y hasta 8 procesadores, acceso directo al hardware y un rendimiento prácticamente semejante al de una maquina real.

Softgrid sin embargo es una tecnología de virtualización de aplicaciones y diréis ¿qué significa esto?, y yo os diré, esto es la caña, esto es como House en una guardería, como si Alonso tuviera cuello, como si Chema el Maligno se cortara el pelo y llevara traje, como si yo fuera sociable, como si mi amigo Alf dejara de usar la camiseta de Atari, esto es lo más grande a la informática de escritorio desde que el mismísimo Bill Gates decidiera comprar su primera patente.

Entonces porque Softgrid es tan, tan la leche; Imaginaros un mundo en el que en los PCs solo está cargado el sistema operativo y cualquier usuario que arranca un pc sea el que sea dentro del dominio dispone automáticamente de sus aplicaciones listas para correr usando los recursos locales de la maquina que está usando, imaginar que no hay conflictos entre aplicaciones, que todas las licencias se controlan centralizadamente, que uses el ordenador que uses, las personalizaciones que hagas en los programas que uses estarán disponibles para ti, imaginar que podéis actualizar todas las versiones de un software de forma centralizada e instantánea, imaginar que los programas solo ocuparan en disco el espacio requerido por la parte del programa que uséis.

Si todo esto fuera real, ¿no sería la leche?, ¿no sería mejor que los percebes con pan :-D?, bien pues todo esto es softgrid.

La base de softgrid es un programa llamado secuenciador, el secuenciador es usado para virtualizar una aplicación, como resultado de esa virtualización obtendremos una serie de ficheros que representan la aplicación ya virtualizada.

Una vez que se tiene la aplicación virtualizada se introduce dentro del Servidor de Softgrid, donde asignaremos las aplicaciones a usuarios o grupos de usuarios del Directorio Activo.

Los usuarios que tengan esas aplicaciones asignadas y que usen una maquina que tenga instalado el cliente de softgrid verán los iconos de los programas y los tendrán en el menú de programas, adema los archivos con las extensiones adecuadas estarán correctamente asociados a dichas aplicaciones.

Cuando un usuario ejecute uno de estos programas, el cliente de softgrid bajara la parte del programa necesaria para que corra la aplicación, esto suele ser aproximadamente un 8-10% de la aplicación, la aplicación correrá en local, podremos ver el proceso en el task manager con el nombre que tendría si lo corriéramos normalmente, la única diferencia es que en realidad no tenemos la aplicación instalada, las carpetas de la aplicación no están , las ramas del registro no están, no hay rastro de la aplicación, cuando la cerremos será como si no hubiéramos tenido nunca nada.

Esto es así por que el secuenciador virtualiza las partes del registro necesarias para la aplicación, también virtualiza las carpetas y todas las dependencias desde el framework hasta objetos com, etc.

El administrador puede decidir si las aplicaciones se bajan completas o a medida que las uses, también puede definir que se queden en el cache local del cliente softgrid y en ese caso por cuánto tiempo quieren que se queden.

Es posible unir softgrid a SMS y repartir los paquetes (aplicaciones virtualizadas) por los medios habituales en SMS.

Softgrid es una tecnología que pertenecía a una empresa que compro Microsoft y la versión actual es la 4.x.

No me extraña que lo compraran, la tecnología no hace mella (salvo en algun tema de seguridad), es como programada por Microsoft, las consolas están bien, todo bien integrado usa SQL Server para guardar las configuraciones, toda la administración se basa en Web Services.

A nivel de red, todo corre muy comprimido, es impresionante ver que funciona aceptablemente hasta por satélite y qué decir de UMTS.

Si por ejemplo un usuario tiene problemas con una aplicación, el administrador puede reiniciar esa aplicación al estado inicial de la virtualización, con lo cual problema solucionado.

Microsoft inicialmente distribuirá softgrid a los clientes a través de un paquete llamado DOPSA del que ya he hablado muchas veces en este blog, este paquete ya está disponible para los clientes con Software Assurance.

Por ultimo decir que por desgracia la versión que ha incluido Microsoft en el Dopsa Pack no es la ultima versión de softgrid.

Bueno, con esto termino la cháchara 😀 y llego a la parte en la que me mancho las manos y os muestro las pantallas del softgrid.

Instalando el servidor de softgrid.

Windows 2003 SP1, SQL Server 2005 SP1, mmc 3.0 (http://www.microsoft.com/downloads/details.aspx?familyid=4C84F80B-908D-4B5D-8AA8-27B962566D9F&displaylang=en), IIS Instalado

Ejecutamos el setup:

Instalamos el servidor y las utilidades

 

Instalamos el servidor y las utilidades

 

 

 

 

La consola cliente solo hay que instalarla si queremos gestionar los clientes remotamente desde este servidor.


El servidor en el que lo estoy instalando se llama sps2007 que esta heredado de una demo de Sharepoint 😀

 


No se para que sale un combo si solo se puede seleccionar SQL Server 😉

 

 

 

 

Yo he creado una cuenta de SQL especial para el softgrid, llamada SvcSoftGrid, pero no me gusta que no se pueda usar seguridad integrada.

 

El Servicio necesita otra cuenta para acceder a la base de datos, he creado otra cuenta llamada SvcSoftGridDataAccess, si usais SQL 2005 aseguraros de que la password que ponéis cumple con la política de seguridad.

 

Softgrid necesita una cuenta para poder acceder al directorio activo, creo una cuenta en la unidad organizativa “Services” llamada SvcSoftGridDirectoryAccess, al estar en esa OU se le aplicaran las políticas y scripts adecudos para mantener segura una cuenta de este tipo, pero eso sale del alcance de este articulo.


Creo un grupo en el directorio activo llamado GrpSoftGridAdmin donde estarán los usuarios que tengan que administrar el softgrid, tengo montado el AD de tal forma que el sistema está configurado para que todos los grupos que terminan en admin son monitorizados, si los miembros cambian, se lanza una alerta tanto al sistema forense como al MOM y por correo al oficial de seguridad, pero esto se sale de esta articulo :-D.


Hay que crear otro grupo que será el de usuarios que formaran parte del softgrid y de esta forma se les podrán asignar aplicaciones, luego podremos añadir más grupos, etc. En mi caso lo llamo GrpSoftGridUsers.



 

Esto es una demo, pero en producción os recomendaría que usarais un disco aparte alejado de la paginación.

Este directorio hay que convertirlo en un share ya que es desde aqui desde donde los clientes se bajaran las aplicaciones y otros contenidos.



Ok, ya esta, ya tenemos instalado el servidor.

Curioseemos.

Lo primero que vemos es una BD llamada softgrid con unas vistas muy curiosas


Jeje, esto es extensible :-D.

 

Luego tenemos un directorio virtual en el default website, que es donde el sofgrid ha montado sus cositas y ups un udl :-D, chungo en el UDL ha metido a capon la password :-¿???


2 puntos menos.

Bueno mañana seguimos con otro capítulo.

SCOM 2007 RC2 (Parte 1) Introducción e Instalación del servidor.


System Center Operations Manager también conocido como MOM 2007 o MOMv3 es la nueva versión del servidor de monitorización y operación de Microsoft.


SCOM, nos permitirá monitorizar nuestros servidores y:


-Saber en todo momento el estado y la calidad de los servicios.


-Medir el acuerdo de calidad de servicio (SLA)


-Monitorizar aplicaciones más allá del estado de los servidores y servicios sobre los que corre, siendo capaz de obtener una visión general de la aplicación.


-Obtener informes puntuales o a largo plazo del rendimiento o sucesos en los servidores.


-Centralizar y almacenar todos los eventos de los servidores.


-Contar con un sistema centralizado de almacenamiento y análisis de eventos de seguridad de todos nuestros servidores.


-Contar con una base de datos de conocimiento desarrollada por los fabricantes de los productos que nos ayudara cuando surjan problemas con los servidores.


-Obtener graficas con baselines del rendimiento de servidores y servicios.


-SCOM usa Managements Packs desarrollados por los fabricantes de los productos para poder entender cada producto, como por ejemplo Exchange, Oracle o Linux, estos Managment Packs puede contener información que le indique a MOM que configuraciones son las mejores o que parámetros de rendimiento son correctos, o como por ejemplo en el caso de Exchange indica a MOM que tiene que validarse en cada servidor simulando ser un Outlook y medir cuanto tiempo tarda en responder el servidor.


-SCOM permite también monitorizar los puestos y dispositivos SNMP.


-Usando SCOM se puede hacer que cada administrador solo vea los servidores o servicios que le competan.


-SCOM permite correr tareas en los servidores monitorizados, permitiendo incluso que los administradores puedan correr tareas usando otros credenciales si así se ha configurado.


-SCOM cuenta con una base de dasos de reporting que nos permite crear nuestros propios informes usando herramientas estándares como el report builder de Microsoft.


Estas son algunas de las cosas que se pueden hacer con SCOM, como veis el producto es increíble, además SCOM se puede conectar con sistemas de help-desk u otros productos de monitorización como Tivoli o OpenView.


A lo largo de esta serie de artículos, tratare los temas más importantes de SCOM 2007, desde la instalación hasta la arquitectura, pasando por la monitorización de productos como Exchange, Routers, Linux, AD y la integración con otros productos.


Veamos ahora el proceso de instalación.


Ejecutamos el setup:



 

Bien, lo primero es ver que cumplís con los requisitos.

En este artículo instalaremos todo en un solo servidor, así que los requisitos a cumplir son.



  • Windows 2003 SP1.

  • SQL Server 2005 SP1

  • Parche KB918222 de SQL Instalado.

  • SQL Server Reporting Services SP1

  • Framework 2.0

  • Framework 3.0 components

  • Powershell

Cuidado con algunos de los componentes que tienen que ser versiones específicas, en el check os dice cuales.

Cuando el producto este terminado y lo montéis en producción necesitareis como poco 2gb de ram, este producto come muchos recursos.

Para esta articulo usaremos un servidor que es un DC, cosa que no está recomendada.

 

Cuando todo esté correcto, volvemos a la pantalla de inicio y pulsamos en “Install Operations Manager 2007”

 

Este es uno de los cambios de RC1 a RC2, en la RC2 se puede instalar directamente la web console, en la RC1 no se podía, había que bajarla a parte desde connect.

 

Nos dara warnings por la memoria y por ser un DC.

 

 

El servidor en el que lo estoy instalando se llama SPS2007.

 

En producción recordar poner la base de datos y los logs en discos independientes, diseñar los raids pensando en la alta carga transaccional que tiene este tipo de BDs.

La base de datos quedara en modo simple de recuperación, nunca la pongáis en full recovery, dado que el rendimiento se degrada demasiado por el tipo de uso que hace MOM de la BD.

 

Al igual que en MOM 2005 será necesaria una cuenta para recuperar datos de los proveedores, correr respuestas e instalar y desinstalar los agentes.

Es posible hacer esto con Local System pero está absolutamente desaconsejado por motivos de seguridad y mantenimiento.

 

SDK Account, tenemos que usar una cuenta diferente de la anterior por motivos de seguridad, esta cuenta se usara para acceder a la base de datos y en el proceso de distribuir la configuración a los agentes.

 

En el paso siguiente elegiremos el tipo de autenticación que queremos para la consola.

 

Hay que ser buenos vecinos y colaborar con Microsoft en la mejora del software asi que dejaremos que MOM envie errores automáticamente a MS.

 

Mas de los mismo.

 

 

La instalación terminara y nos dirá si queremos ejecutar la consola.

En la siguiente parte, daremos una vuelta por la consola viendo las partes más importantes.

Monitorizando un dispositivo de red con SNMP y SCOM 2007

Hasta ahora con MOM 2000 y MOM 2005 tratar de monitorizar dispositivos SNMP sin comprar productos de terceras partes, era cuanto menos complicado.


SCOM 2007 viene con un soporte nativo para dispositivos SNMP que hace que sea una tarea muy sencilla.


Veamos paso a paso como monitorizar un dispositivo SNMP con SCOM 2007-01-07


Para poder monitorizar este tipo de dispositivos, es necesario haber instalado el componente de Windows de SNMP y Proveedor WMI para SNMP y que el dispositivo que queremos monitorizar este correctamente configurado para mandar traps SNMP al servidor de SCOM y con una comunidad SNMP Configurada.


Crear un dispositivo.


Desde la consola de SCOM, dentro de “Administration” creamos un nuevo dispositivo de red, para ellos usamos el “Discovery Wizard”




Seleccionamos “Network Devices” en tipos de dispositivos.


Introducimos el rango de IPs y la comunidad SNMP que se usara para acceder al dispositivo.


Proxy Agent será la maquina encargada de monitorizar al dispositivo.




Ya hemos añadido el dispositivo, si accedéis a las propiedades, podréis ver como se ha detectado el modelo del router y el OID del dispositivo.

Desde “Monitoring” dentro de la carpeta “Network Device”, tenemos la vista de estado de todos los dispositivos de red, en esta vista podemos ver el estado del router.


Como ejemplo, vamos a ver qué pasa si perdemos contacto con el router.


Accediendo al “Health Explorer” que está en el panel de acciones podemos ver el histórico del estado del dispositivo.


En el paso, siguiente vamos a configurar el SCOM para que si algún interfaz del router pierde conexión, se dispare una alerta.

Pare realizar esta configuración entraremos en la parte de “authoring” y luego en la carpeta “Management Pack Objects”, después seleccionaremos Rules y pulsando con el botón derecho entraremos en “new rule”


Tendremos que introducir el OID del Trap SNMP que queramos detectar, el caso del router que estoy usando, lo he configurado para que sea el 0.0.1


Tendremos que introducir la descripción de la alerta y el grado de gravedad y prioridad que queremos que tenga.


Cuando un interfaz del router se caiga, se producirán las alertas consecuentes en MOM.


Veamos las propiedades de la alerta, al igual que en MOM 2000 o 2005 es posible asignar la alerta a un operador concreto o introducir una referencia al sistema de help desk rellenando el atributo “Ticket-ID”


En el tab de “alert Context” podemos ver toda la información recibida en la alerta.


Por supuesto podemos indicar a SCOM que nos avise por Mail u otros medios


Ya hemos visto, las funcionalidades de estado, salud y alertas de los dispositivos de red, vamos a ver ahora la parte mas interesantes, graficas.

Vamos a tomar como ejemplo el grafico del Nº de paquetes enviados, cuyo OID de SNMP es 1.3.6.1.2.1.11.2.0

De nuevo entraremos en el apartado de “Authoring” y en la carpeta de “Management Pack Objects”, donde seleccionaremos “Rules” pulsaremos el botón derecho y luego “new rule”




Si desde la sección de “Monitoring” dentro de la carpeta “Network Device” seleccionamos “Network Device State” y luego marcando el router, pulsamos el botón derecho del ratón y luego seleccionamos la opción “Open/Performance View” accederemos al visor de gráficos.


Desde esta ventana se pueden seleccionar los diferentes contadores y verlos juntos, también es posible ver la “Baseline” que nos marcara el comportamiento normal de este contador.

Los contadores se pueden ver en tres dimensiones y rotarlos dinámicamente.

Por supuesto también podemos acceder a los datos a través de la consola web de SCOM 2007-01-07


 

Mi nombre es Daniel Matey y soy un Geek.

    Supongo que con el tiempo terminare en una clínica de desintoxicación pero de momento es solo una forma de presentarme para los que no me conozcan.


 


    Como ya he dicho, mi nombre es Daniel Matey, soy MVP y trabajo como arquitecto de infraestructuras lo cual hace que me dedique sobre todo a diseñar y trabajar en optimizar el mantenimiento y operación de las infraestructuras en grandes empresas.


 


     Después de un par de años,  luchando tediosamente con las penurias infligidas por los spaces de live.com, emerjo a los blogs serios de la mano de geeks.ms.


 


      Para los que no leyerais mi blog en http://dmatey.spaces.live.com (que seréis la mayoría) os comentare que es un blog con dos tipos de temáticas:


 


    Por un lado, encontrareis un post casi diario, en el que comento todas las cosas que me llamaron la atención en el día anterior, documentos que he leído, posts de otros blogs que me parecierón interesantes, opiniones, etc, el contenido esta tanto orientado a infraestructuras como a desarrollo y se suele colar algún gadget que otro.


 


   Regularmente aparecerán artículos sobre infraestructura, seguridad, extensibilidad o “buenas prácticas” en el managing.


 


   Pretendo traer a este blog, los artículos del antiguo que más éxito han tenido y que son consultados más frecuentemente.


 


  Espero que os guste y veros por aquí.


 


    Un saludo para todos


 


Daniel Matey.


MVP Operations Manager.


MCSE, MCSA, MCSD, MCDBA.