Microsoft, su tecnología y yo

El Blog de David Cervigón (Microsoft)

December, 2008

  • Dos libros de MSPress para descarga gratuita

    Solo hace falta pasar por el habitual proceso de registro/perfilado con vuestro Live ID

    Saludos

    David Cervigón

  • Virtualizacion y Reyes Magos

    Ingeniero preventa de Microsoft pidiéndole a su Evangelista-Mago favorito que, como ha sido muy bueno, le traiga la cuota de virtualización. Por su cara de póker y la desteñida palidez de su tez, me temo que tocará seguir currándoselo por si acaso.

    IMG_6777 IMG_6778

    El que perpetró tan bonita postal navideña es el nuevo monaguillo recién fichado, del que ya daremos más señas.

    Mis mejores deseos, y que el próximo año sea bueno para todos.

    Feliz Navidad

    David Cervigón

  • VDS, VSS y Snapshots

    En una reunión el pasado viernes con Jorge, de NetApp, además de aprender muchas cosas en poco tiempo, recordé un tema que tenia pendiente hace algún tiempo; intentar aclarar en pocas palabras que es esto de Virtual Disk Service (VDS), Volume Shadow Copy Services (VSS) y su relación con las tan traídas y llevadas instantáneas, omnipresentes hoy en el mundo de las copias de seguridad y estrategias de recuperación ante desastres.

    El Virtual Disk Service entró por primera vez en escena en Windows Server 2003 para resolver un problema clásico en la gestión del almacenamiento en Windows. Se trataba de ofrecer a las aplicaciones de una interfaz única para manejar discos y volúmenes, independiente del hardware que fuese finalmente responsable de las mismas, por lo general, sistemas SAN (Storage Area Network). La idea es que el fabricante del almacenamiento ofrece in "VDS hardware provider" para su hardware, y por otro lado, pueden escribirse aplicaciones de gestión del almacenamiento multi-fabricante, llamando a un único conjunto de APIs. Esta es la arquitectura de la solución:

    VDS

    Como puede observarse, en el propio sistema operativo ya se incluyen tanto herramientas de gestión del almacenamiento (DiskPart, DiskRAID y el propio Administrador de Discos) como dos "Software Providers" que son los que nos permiten crear discos básicos o dinámicos. Otro buen ejemplo de aplicación que se basa en VDS y en los "Hardware Providers" correspondientes a nuestra solución de almacenamiento es la MMC de Storage Manager for SANs (Administrador de Almacenamiento para redes SAN, presente en Windows Server 2003 R2 y Windows Server 2008) que nos permite llevar a cabo tareas básicas de administración y aprovisionamiento de estos entornos sin tener que usar herramientas específicas del fabricante. Todo esto y mucho más está muy bien descrito detalladamente en What Is Virtual Disk Service? y How Virtual Disk Service Works.

    Por otro lado, los Volume Shadow Copy Services se introdujeron para resolver parte del problema clásico de la copia de seguridad de ficheros que estaban en uso por las ampliaciones encargadas de almacenar datos en ellos. Siempre ha habido software con la capacidad de sacar una copia de un fichero abierto, pero otra cosa es muy distinta es hacerlo asegurando que la información que hemos almacenado en la copia está en un estado consistente y que podrá ser utilizada con posterioridad. VSS nos permite por tanto extraer instantáneas o copias en el tiempo de determinada información, y para ello requiere de diferentes componentes:

    VSS

    Por un lado, el "Requestor", o aplicación que solicitará la extracción de la instantánea, que será típicamente una solución de copia de seguridad. Por otro lado, un "VSS Writer" específico contiene toda la lógica y conocimiento de cómo se debe extraer esa instantánea para una aplicación en particular. Un gran número de aplicaciones y servicios para Windows incluyen un VSS Writer, como son el caso del propio Sistema Operativo, los servicios de Directorio Activo, Exchange, SQL, Sharepoint, ISA, Virtual Server y un largo etcétera, en el que se encuentra, como no, Hyper-V. Por último tendremos diferentes "providers" hardware y software que se encargaran de gestionar el almacenamiento físico que está detrás de los volúmenes de donde se sacan las instantáneas y en el que se almacenan. De nuevo, todo esto, y lo que sucede detalladamente cuando se saca una instantánea, está descrito en What Is Volume Shadow Copy Service? y How Volume Shadow Copy Service Works.

    Gran parte de las funcionalidades avanzadas que ofrece el software especializado de copia de seguridad para sistemas y productos Windows, y también las equivalentes que ofrecen los fabricantes de sistemas de almacenamiento están basados en el uso combinado de las funcionalidades de VDS y VSS. Es importante por tanto preocuparse de tener correctamente instalados y configurados los correspondientes "hardware providers" de nuestras cabinas para poder hacer uso de las facilidades que estos servicios nos ofrecen a la hora de gestionar y automatizar las operaciones del almacenamiento y de las copias de seguridad mediante instantáneas de los productos Windows que corren en nuestros servidores. Es decir, tener disponibles todas las piezas de este cuadrito:

    clip_image002

    De todo esto hay un documento muy recomendable para acabar de tener claro el funcionamiento y la potencia de todo esto:

    Saludos

    David Cervigón

  • Disponible el SP1 de System Center Data Protection Manager 2007

    DPM2007 Hola

    Se acaba de liberar el Service Pack 1 de System Center Data Protection Manager 2007. Se puede descargar de aquí:

    Entre sus novedades, que se suman a las del ya obsoleto esquema del dibujo, destacan:

    • Soporte para la protección de Hyper-V (esto va a merecer un post dedicado muy muy pronto)
    • Mejoras en el soporte de SQL 2008
    • Protección mejorada de MOSS 2007 y Windows Sharepoint Services 3.0
    • Soporte de Exchange 2007 Standby Cluster Replication (SCR)

    Tenéis toda la lista de novedades en este enlace: http://www.microsoft.com/SystemCenter/DataProtectionManager/en/us/WHATs-NEW.aspx

    Saludos

    David Cervigón

  • Sobre Clusters de Hyper-V y clusteres virtuales

    Hola

    Hoy toca hablar de cluster. Lo cierto es que el término es a veces un poco confuso, porque se refiere a un grupo de diferentes máquinas trabajando juntas por alguna razón determinada. En éste artículo de la Wikipedia creo que se explica muy bien, y distingue entre clústeres de Alta Disponibilidad (HA clusters), clústeres de balanceo de carga (Load Balancing clusters) y clústeres de computación (Grids)

    En particular, en el mundo Microsoft existen tres tecnologías diferentes para cada uno de estos tipos de clustering. Dos de ellas están incluidas en Windows Server, y la otra en una edición especial. Ésta es una presentación al respecto, un poco arcaica ya, pero es mía :-)

    • Failover Cluster: Conocido también como MSCS o de almacenamiento compartido. Se utiliza para dotar de alta disponibilidad por tolerancia a fallos de servicios que por lo general tienen una dependencia del almacenamiento. Ejemplos de esto serían bases de datos, buzones de correo, máquinas virtuales, etc.
    • Clústeres de NLB (Network Load Balancing): Pensados para dotar de alta disponibilidad por tolerancia a fallos y escalabilidad a servicios de red. El ejemplo más frecuente son granjas Web o de Terminal Services. Se asume que todos los frontales tienen la información que sirven a los clientes correctamente replicada o en un repositorio central o back-end (generalmente este en Failover Cluster).
    • Clústeres HPC o de High Performance Computing: A "grosso modo" un nodo cabecera recibe un trabajo que paraleliza entre los diferentes nodos de computación, y estos le devuelven los resultados de vuelta para componer el resultado total. Esto se usa generalmente para hacer sumas y restas de esas que con una calculadora resultaría extremadamente tedioso realizar.

    Todos y cada uno de estos tipos de cluster tienen algo que ver con el mundo de la virtualización. Todos pueden montarse en un entorno puramente virtual allí donde tenga sentido hacerlo (Clústeres virtuales, NLB entre VMs, o nodos de HPC virtuales), y los hosts físicos de Hyper-V pueden funcionar tanto con Failover Clustering como con NLB, si bien esto último es raro y me costaría imaginar algún entorno en el que fuera aplicable.

    En adelante nos vamos a centrar únicamente en Failover Clustering y su relación tanto con los hosts de hyper-V como con las VMs que montemos encima. Distinguimos entonces:

    • Host Clustering: de 2 a 16 nodos con Hyper-V funcionando conjuntamente de modo que las Máquinas Virtuales puedan pivotar entre ellos, según sea necesario:
      • Bien por una caída no planificada del Host que la alberga. En este caso la VM reiniciará en alguno de los hosts del cluster automáticamente
      • Bien de manera manual o automática, por un mantenimiento planificado del host, o porque queramos redistribuir de forma diferente las cargas de trabajo entre los nodos del cluster. Esto es lo que hoy en día conocemos por Quick Migration, y en Windows Server 2008 R2 podremos hacer también con Live Migration.
    • Guest Clustering: Esto se refiere a un Failover Cluster en el que los diferentes nodos del mismo son máquinas virtuales corriendo en Hyper-V. Rizando el rizo puedes tener guest clustering en HA, es decir que las VMs que componen el cluster virtual, estén albergadas a su vez en un host cluster de Hyper-V

    Vamos a tratar de aclarar las dudas más frecuentes que suelen surgir sobre todo esto:

    Host Clustering

    Creo que esto se entiende fácilmente simplemente diciendo que es la combinación de la característica (role) de Hyper-V y la funcionalidad (feature) de Failover  Cluster incluidos en Windows Server 2008 x64 Enterprise y Datacenter. La configuración hardware más típica para montar esto consiste en:

    • Almacenamiento compartido (típicamente SAN, con Fiber Channel, iSCSI o SAS, aunque este tipo de tecnologías proliferan). Muy importante en este punto y en lo que sigue: Windows Server 2008 NO SOPORTA Failover Clustering usando el tradicional bus SCSI
    • De 2 a 16 servidores que tienen la capacidad de acceder a un cierto numero de LUNs expuestas a todos ellos por el almacenamiento compartido
    • Dos o tres subredes diferentes para gestión, acceso publico y heartbeat.

    Por suerte, puedo ahorrarme el hacer un paso a paso de la creación de un cluster de Hyper-V porque abundan. Si que creo que es importante referenciar la documentación que considero "autoritativa" para ello:

    Para los interesados en probar esto y que no cuenten con este tipo de sistemas de almacenamiento compartido, queda la friki-opción de usar uno o varios File Shares (y si ya nos queremos complicar aún más la vida, que sean por NFS). Todo esto, y mucho más, está detallado en este post de mi compañero José Barreto. De hecho él tiene publicado un post mucho mas curado que éste que estas leyendo, y que se titula Windows Server 2008 Hyper-V Failover Clustering Options.

    Un tipo particular de Failover Clusters son los clústeres geográficamente dispersos, multi-site clusters o GeoClusters. Y están de moda. Espero poder dedicar algún tiempo a dar más detalles sobre ellos (aprovechando que Dani Matey, con nocturnidad y en compañía de otros, hace poco que ha estado montando un par de ellos en sendos clientes de esos cuyo nombre conocemos sin excepción todos los españolitos). Mientras tanto, vayan por delante algunas consideraciones:

    • Estrictamente hablando, el almacenamiento debe estar replicado en las diferentes localizaciones. La idea es que el sitio físico donde reside el almacenamiento no sea un punto único de fallo.
    • El Failover Cluster de Windows Server 2008 ha sido rediseñado a nivel de almacenamiento y red para soportar este tipo de entornos. En particular sus modelos de quorum permiten una arquitectura del almacenamiento "shared nothing", en la que la replicación de la información se realiza por algún medio más o menos ajeno al cluster. En un extremo tendríamos las soluciones tipo Database Mirroring, Log-shipping etc. (como la de los clústeres CCR de Exchange 2007) y en el otro la pura replicación hardware. En este último caso hay que tener en cuenta una máxima de cajón. La velocidad de la replicación debe ser mayor o igual que la velocidad a la que el nodo escribe datos en el almacenamiento.
    • Debe existir un componente software que medie entre el cluster y el almacenamiento para decidir en que sentido debe realizarse la réplica, y tomar la acciones necesarias en caso de fallo o movimiento manual de los recursos.
    • La arquitectura de Hyper-V le hace agnóstico de toda esta película. Mientras que en el otro nodo el almacenamiento sea a todos los niveles idéntico, todo lo que espera Hyper-V es que alguien le presente los ficheros necesarios para continuar moviendo la máquina virtual.
    • Esta solución es cara. Y hay quien pregunta por algo similar, pero sin el coste asociado. Existen diferentes soluciones de replicación de datos a nivel software (podríamos imaginar, solo imaginar, una replicación de datos a base de robocopys :-) ), pero dudo muchas de ellas lleguen a cumplir todas y cada una de las condiciones anteriores. Por tanto, se parecerán mucho más a una solución de backup que a un geocluster. Y en estos casos conviene preguntarse quién y como garantiza la consistencia de los datos copiados. Prometo investigar.

    Para hacernos una idea de soluciones de este tipo, he aquí una lista, que francamente no he repasado y no sé cuantas de ellas pueden aplicar a Hyper-V y Windows Server 2008.

    Guest Clustering

    Llegados a este punto, cabe preguntarse acerca de la necesidad o no de montar un cluster virtual. Por un lado, si el failover cluster se inventó principalmente para proteger a las cargas de trabajo ante un eventual fallo del hardware físico, y no solamente ya no tenemos hardware físico que se rompa sino que además ese "hardware virtual" se puede beneficiar de las tolerancia a fallos del host de virtualización que lo sustenta, ¿que ganamos?. Si la VM ya tiene alta disponibilidad, ¿para que rizar el rizo?. Pero por otro, ¿quien nos defiende ante un fallo que suceda a nivel de sistema operativo o aplicación dentro de la máquina virtual?. Y además, si tengo clusteres físicos en producción, ¿por qué no beneficiarme de las ventajas de la virtualización en los entornos de pre-producción y pruebas y desarrollo equivalentes?. Resumiendo, el "host clustering" de VMs reduce pero no elimina la necesidad de usar "guest clustering".

    Antes de meternos a ver cómo se montan en Hyper-V, es conveniente repasar la manera en que hace en Virtual Server y en otras soluciones de virtualización. En esos entornos se emular una controladora SCSI que soporte bus sharing (la Adaptec 7870 para mas señas en el caso de Virtual Server, y en otros casos LSI, BusLogic, etc.), y que, en resumidas cuentas, pueda realizar las operaciones descritas en este artículo de la Knowledge Base. Pues bien, el diseño del Failover Cluster de Windows Server 2008 se lleva a cabo teniendo en cuenta las necesidades de los modernos entornos de almacenamiento compartido, y no soporta más el tradicional bus SCSI. Me sorprendería mucho que alguien montara un cluster virtual de Windows Server 2008 (que efectivamente funcione, no que termine el el proceso de configuración) usando las controladoras emuladas arriba citadas.

    La controladora SCSI que se usa en Hyper-V no es una emulada sino sintética, es decir, no es una implementación software de una ninguna controladora SCSI que exista o existió en el mercado. Y no soporta bus sharing, lo que la hace incapaz de soportar un cluster de Windows 2000 Server o Windows Server 2003. Mis sospechas (personales) es que si el clustering a través de SCSI no se soporta en Windows Server 2008, simplemente no se ha invertido en este sentido en la controladora SCSI sintética de Hyper-V.

    ¿Cómo se hace pues un cluster virtual en Hyper-V?. Pues a través de una tecnología bien soportada en Windows 2000, 2003 y 2008. Usando iSCSI. Para ello necesitamos dos piezas:

    • El iSCSI Initiator en el sistema operativo de la máquina virtual. Windows Server 2008 lo lleva de serie, y para Windows 2000 SP4 y Windows 2003 se puede descargar de aquí.
    • Almacenamiento que sea capaz de exponer sus LUNs mediante iSCSI o un "iSCSI Target" por software. Muchas de las cabinas modernas soportan tanto Fiber Channel con iSCSI, y hay también servidores de especializados de almacenamiento que exponen su almacenamiento a través de iSCSI. Tal es el caso de Windows Unified Data Storage Server 2003 (Windows Server Storage Server 2003 R2), que incluye una evolución de Wintarget que comercializaba String Bean Software.

    Esto tiene bajo mi punto de vista una ventaja y un inconveniente. La ventaja es que el almacenamiento se le presenta directamente a la VM, y solo nos tendremos que preocupar de optimizar las tarjetas de red virtuales y las del host físico, ya que obviamente estamos encapsulando comandos SCSI sobre Ethernet lo que debe ser tenido en cuenta a la hora de dimensionar la solución. El inconveniente es que a fecha de hoy el almacenamiento iSCSI no es tan frecuente como el Fiber Channel, y los buenos iSCSI targets gratuitos escasean. En este sentido creo que vamos a asistir en los próximos años a la competencia entre la fibra y el cobre también en el campo del almacenamiento.

    Bueno, menudo ladrillo. Y lo peor es que tengo la sensación de dejarme un montón de cosas en el tintero. Espero que al menos a alguien le resulte aclaratorio.

    Saludos

    David Cervigón

  • El Yeti, Microcortes de red, y el Blog de mis antiguos compañeros

    Hola

    Tenia pendiente enlazar el blog de equipo que mantienen los compañeros del grupo al que tuve la suerte de pertenecer hace unos años, pero este fin de semana Alberto Camina me ha dado la razón definitiva:

    Microcortes, el Yeti, Hombres lobo y otros seres imaginarios (me ha dicho que la saga continuará)

    Este es el blog, y éste su RSS (Rafa llega un poco tarde con eso de como crear tu primera VM en Virtual Server :-) )

    Hay mucha gente que usa el gracioso botón que pone "Email" de aquí arriba para colocarme un inocente "seguro que tu te la sabes" como quien pasaba por aquí. Bueno, pues con estos no os cortéis, que seguro que si se la saben.

    Saludos

    David Cervigón

  • Licenciamiento en entornos virtualizados: ¿Y que Clave de Producto le pongo al Windows de la Máquina Virtual?

    Hola

    A raíz de la información del licenciamiento de Windows Server en entornos virtualizados que publiqué aquí, me han preguntado en algunas ocasiones algo bastante obvio, pero que no se me había ocurrido hasta el momento. ¿Y que Product Key se le pone a la Máquina Virtual?. Yo siempre tiro para todos mis entornos de demo con las claves de mi suscripción a TechNet, pero en el mundo real lo que hay es Retail, OEM, Open, Select, etc. Y sin embargo el licenciamiento de Windows Server es independientemente de acuerdo adquirido.

    En el caso de FPP (Full Packaged Product o Retail) y OEM la respuesta se encuentra en http://support.microsoft.com/kb/949748. En ambos casos, en el COA (Certificado de Autenticidad, la etiquetita que viene pegada al equipo) hay dos claves de producto:

    • El Product Key "clásico" para ejercer nuestro derecho de instalación física (si procede).
    • Una Virtual Key o  Virtual Product Key para instalar y activar las instancias virtuales a las que nos de derecho la edición de Windows adquirida (ver a modo de ejemplo éste documento que tiene DELL a propósito de éste tema, o éste otro específico de Hyper-V).

    Es importante mencionar que en el caso de equipos OEM las licencias de Windows (cliente o servidor) no son transportables a otro equipo. Esto es importante tenerlo en cuenta a la hora realizar conversiones P2V de estos equipos (equivalentes a instalar/restaurar un Sistema Operativo OEM de una máquina física a otra)

    En el caso del licenciamiento por volumen (Open, Select, etc.) el funcionamiento está descrito, como en el caso de Windows Vista, en el sistema de activación de Volume Licensing 2.0. Hay dos tipos de claves, y en ambos casos, las instalaciones de Windows Server en las máquinas virtuales se imputan a la cuenta total de equipos activados teniendo en cuenta el modelo de licenciamiento en entornos virtuales:

    • Claves MAK (Multiple Activation Keys), que se reportan a los sistemas de Microsoft por Internet o por teléfono, o también usando esta desconocida pero muy útil herramienta a modo de proxy: Volume Activation Management Tool (VAMT) 1.1 (x86). Cada clave de este tipo da derecho a activar con ella solamente un cierto número de servidores preestablecido.
    • Claves KMS (key Management Server), en las que la activación se realiza contra un servidor interno de nuestra organización, y habida cuenta de que tengamos al menos 5 servidores físicos, "systems operating in virtual machine (VM) environments can also be activated using KMS, but they do not contribute to the system count". El sistema de reporting del servidor KMS interno "breaks the cumulative number of virtual machines and physical machines that are activated using KMS activations for each Windows edition". Ambas parrafadas en inglés están sacadas de la Volume Activation 2.0 Step-By-Step Guide

    Mas información:

    Saludos

    David Cervigón

  • Extrema las precauciones

    Harto de aeropuertos, estaciones y horarios, y en estricto cumplimiento del deber, me levanto a las 5:30 AM, Nescafé con galletas y salgo al volante de mi vehículo de empresa en dirección Norte, ignorando los consejos de evitar los viajes de carretera de la tele.

    Todo bien hasta El Molar, donde empiezan las inclemencias del tiempo, que empeoran en cuanto atravieso Somosierra y atravieso Segovia y después Burgos. Aproximadamente en el Km 200 de la N-I vislumbro un todoterreno de la Guardia Civil de Tráfico, y casi me alegro. No están las cosas para infracciones y así no me siento solo. En un momento dado me adelantan, y pasados unos minutos llegamos a un desvío, encienden todas las lucecitas de su flamante coche nuevo y parece que me indican que les siga a la gasolinera. No lo tengo muy claro, pero no me parece muy buena idea darles esquinazo, y además me pica la curiosidad.

    Ya en el recinto de la gasolinera hace unos extraños quiebros y se detienen. Me pongo a su lado y les pregunto si querían algo. 7:30 de la mañana. Una boca de lobo. Se bajan. Abro la ventanilla. Bob Marley a todo volumen.

    - Agente: Buenos días.

    - Yo: Buenos días.

    - Agente: ¿Sabe usté que circula con el alumbrado de niebla?

    - Yo: Si, lo he puesto yo.

    - Agente: Además con el delantero y el trasero

    - Yo: Ciertamente. Se quita y se pone todo junto. No me pregunte si se puede hacer por separado. Yo solo tiro de la palanquita

    - Pues es que está prohibido

    Miro a mi alrededor. Hago memoria. Donde no llovía nevaba, y donde no había bancos de niebla. Me paro a pensar que esta es una de las múltiples ocasiones en las que el Señor me manda pruebas para enseñare a ser prudente, con irregulares resultados hasta el momento. Además uno ya tiene una edad suficiente como para saber que con la gente de uniforme resulta particularmente poco fructífero discutir, y que la Autoridad y la Razón son conceptos que demasiado frecuentemente no van de la mano. Decido intentar no encabronarles.

    - Yo: ¿Ustedes han visto que nochecita?. No se ve un carajo (Pero, ¿ustedes son idiotas?)

    - Agente: Es que va deslumbrando a todo el mundo. Los papeles del coche por favor...

    - Yo: Si, un momento. (¿Deslumbrando?. ¿Como lo que haces cada vez que enciendes todas las lucecitas de tu feria choquetin?. No, debe ser como ese cartel de ahí atrás con los LEDs recién instalados que ponía a todo color "Precaución, bancos de niebla". ¿A todo el mundo?. Ah, ya, debes referirte al esfrozado conductor la quitanieves que acabamos de adelantar los dos hace un par de kilómetros. Si esa que iba esparciendo sal...)

    - Agente: Es suyo el coche

    - Yo: No, es de Renting

    - Agente: ¿Y por qué no lleva los originales?

    - Yo: Porque no es mío y no me los dan

    - Agente: ¡Ah! las fotocopias están compulsadas.

    - Yo: Si, mis compañeros, que están en todo.

    - Agente: Pues le voy a tener que extender una denuncia. Un momento

    Se van y se meten en el todoterreno. Tardan un rato largo, les veo barajar los papeles afanosamente. Al rato vuelven a bajarse, me devuelven la documentación y me envidan a 70 €, con buena prosa:

    multa

    Agente: Le he puesto lo mínimo. Si la paga pronto son solo 42 €. ¡Ah!, y no quita puntos.

    Yo: Vaya, que bien, cuanto me alegro. Francamente, parece que veníamos por diferente carretera. Me ha caído de todo, y no se ve un carajo desde que he pasado Somosierra.

    Agente: No, en este momento las condiciones son excelentes. No puede llevar las anti-niebla hasta Irún.

    Yo: Ciertamente. Pero insito que yo no veo un carajo, por lo que asumo que a mi tampoco se me ve (me estoy jugando un test de alcoholemia. Y además es cierto que ahí atrás había un tramo con buena visibilidad. Justo en esa recta ancha donde está colocado el radar. Que extraña coincidencia...).

    Agente2 (Hasta ahora había permanecido en silencio): Además le he hecho señales, y usté ni caso.

    Yo: Lo lamento agente. Tampoco vi las sus señales. Cosas de la nevada, supongo. (¿Que señas exactamente?. ¿Me has pasado dúples o 31?. ¿Tu bonito todoterreno no tiene ráfagas o claxon, o no sabes ponerte en paralelo, sacar la manita y hacer el perrito como hacemos todos?.

    Agente: ¿Desea firmar?.

    Yo: No, traiga, buenos días.

    Agentes: Buenos días y buen viaje.

    Vamos a ver como acaba mi particular partidita tras este animado debate sobre la conveniencia o no de llevar las luces de niebla en un frío amanecer burgales, en pleno temporal. Lo que si que es cierto es que este par de números de la benemérita, a los que Dios les conserve la salud, el humor y sobre todo la vista muchos años, tienen un sentido del deber encomiable. Con lo calentitos que debían de estar en el coche-patrulla van y se bajan, llevando solamente su jersey verde de reglamento, y sin gorra ni tricornio ni nada. ¡A bajo cero y por 40 € de nada!. Eso va a ser que deben ir bajos de objetivos y que peligra su bonus ahora que se acerca el fin de año. Si no, francamente, la cosa no me cuadra.

    Lo mejor fue la vuelta. A la hora de cenar pasaba el mismo punto, en dirección contraria. Un poco más adelante, Aranda de Duero. Decidí celebrar las 8 horas de viaje, y las 7 que pasé siendo toreado por un par de máquinas virtuales en casa de un cliente, con un buen corederaco asado. Mejorable (asado por la mañana), pero me supo a gloria.

    Amigo conductor. Extrema las precauciones y no dejes de parar en Aranda (o en el Landa :-) )

    David Cervigón

  • Instalación de un servidor de gestión y monitorización de entornos físicos y virtuales (y III)

    Hola

    En los dos últimos posts se ha cubierto la instalación de un servidor de SCOM2007 y SCVM2008 (Instalación de un servidor de gestión y monitorización de entornos físicos y virtuales (I)) y la forma de agregar diferentes tipos de hosts al entorno de gestión de SCVMM2008 (Instalación de un servidor de gestión y monitorización de entornos físicos y virtuales (II)). En este último artículo de la serie vamos a ver diferentes formas de desplegar el agente de Operations Manager 2007 tanto a los hosts con Hyper-V y Virtual Server como a las máquinas virtuales que estén funcionando por encima de ellos o de VMware ESX. Cubriremos tres situaciones:

    • Despliegue del agente a equipos Windows del dominio.
    • Despliegue del agente a equipos de otros dominios sin relaciones de confianza o en grupos de trabajo.
    • Monitorización de equipos con ciertos sabores de UNIX/Linux.

    En este punto, es importante recordar que la arquitectura de nuestro entorno de monitorización es la más sencilla posible, y en particular no incluye un servidor de Operations Manager con el role de Gateway. Por tanto es muy posible que lo que sigue se quede muy pronto pequeño, por lo que la información "autoritativa" en este sentido es la que se encuentra en estos enlaces:

    1.- Despliegue del agente a equipos Windows del dominio.

    Esta es sin duda la parte más sencilla. Basta con irse a la sección de Administración de la Consola de Operations Manager y lanzar el Discovery Wizard. En este caso hemos hecho un descubrimiento automático, pero podríamos haber usado la opción avanzada si conociésemos de antemano los nombres de los equipos que queremos descubrir, o incluso la query LDAP que realizar al directorio para localizarlos. Tal y como se instaló el servidor, la Management Server Action Account es Local System, que debería ser suficiente para leer la información del AD, pero no para llevar a cabo la instalación del agente local en los clientes. Usamos por tanto las credenciales del administrador del dominio, que debería tener permisos de administrador local en ellos. En este caso se han descubierto tanto el servidor con Hyper-V Server como dos máquinas virtuales que corren sobre el, todos pertenecientes al dominio.

    image image image image image image image image

    Como puede observarse, estos equipos se unen al Controlador de Dominio y a un servidor con System Center Data Protection Manager que ya habían sido descubiertos con anterioridad y ya estaban siendo monitorizados por SCOM2007. A partir de este momento los servidores/clientes irán apareciendo y reportando su estado de salud en los diferentes apartados de la sección Monitoring, en función del modelo que definen los Management Packs que se hayan importado.

    2.- Despliegue del agente a equipos de otros dominios sin relaciones de confianza o en grupos de trabajo.

    • Primeramente, necesitaremos configurar la seguridad del Management Server para que permita la configuración manual de los agentes (Sección Administración de la consola, Settings, y clic con el boton de la derecha en Security)

    image

    • Instalamos el agente en el equipo a monitorizar. Debemos usar la versión correspondiente a la arquitectura que podremos encontrar en Program Files\System Center Operations Manager 2007\AgentManagement:

    image image image image image image

    • Obtenemos los certificados tanto del equipo con el agente como el del Management Server y los importamos utilizando en ambos la herramienta MOMImportCert.exe que se encuentra en la carpeta SupportTools del punto de instalación de Operations Manager 2007 (x86 o x64 según corresponda). Para ello hay que aplicar http://support.microsoft.com/kb/947691/en-us, aunque es muy recomendable leerse la manera en que el grupo de producto recomienda obtener certificados para su uso en Operations Manager (http://blogs.technet.com/momteam/archive/2008/06/02/obtaining-certificates-for-ops-mgr.aspx). El objetivo es que cada extremo use su certificado, emitido por una CA común para establecer el canal seguro por el que comunicarse.

    image image

    • Tras esto, el servidor aparecerá en la consola en estado "Pending Management". Lo aprobamos y pasados unos minutos podremos empezar a monitorizarlo y a comprobar su estado de salud en la sección de Monitorización:

    image image image

    3.- Monitorización de equipos con ciertos sabores de UNIX/Linux.

    Para lograr esto, he utilizado la primera Beta pública de las Cross-Platform Extensions, que vendrán incluidas en la futura R2 de Operations Manager 2007 al y como se detalla en Operations Manager 2007 Cross Platform and Interop Solutions.

    Esta beta nos permite gestionar:

    • HP-UX 11i v3 PA-RISC
    • HP-UX 11i v3 IA64
    • IBM AIX 5L 5.3, Technology Level 6, SP5
    • Solaris 10 SPARC
    • Solaris 10 x86
    • Red Hat Enterprise Linux 5 Server
    • SUSE Linux Enterprise Server 10 SP1

    Lo cierto es que este punto merecería un artículo dedicado, pero resulta que ya hay uno muy bueno escrito por Ian Blyth, que se puede descargar de aquí, y que complementa la System Center Operations Manager 2007 Cross Platform Extensions Quick Start Guide, que contiene los pasos que es necesarios seguir en orden escrupuloso para instalar y configurar las Cross Platform Extensions. Desafortunadamente la descarga individual que estaba en Microsoft Connect se ha eliminado en favor de la Beta completa de la R2, que la incluye, por lo que supongo que la instalación del producto realizará automáticamente parte de los pasos de estas guías. Si estás interesado en probar la beta individual sobre SCOM 2007 SP1, envíame un correo e intento hacerte llegar el paquete individual.

    En cualquier caso, lo importante de este punto es el resultado. Yo lo he probado con máquinas virtuales con SUSE 10 SP2 y HedHat Enterprise 5:

    image image image

    RESUMEN:

    Con toda la infraestructura configurada de la forma que hemos explicado en estos tres artículos (ver Parte 1 y Parte 2), System Center Virtual Machine Manager 2008 podrá no solamente gestionar Virtual Server, Hyper-V y VMware y todas las máquinas virtuales que se estén ejecutando por encima de estos sistemas, sino que podrá mostrarnos también a través de la consola de Operations Manager tanto los diagramas de dependencias y salud del entorno físico y virtual, así como de los servicios que estén corriendo dentro de las máquinas virtuales. También será capaz de capturar los Performance and Resource Optimization (PRO) Tips que se reciben de Operations Manager a través de los Management Packs en el caso de detectarse alguna alerta que ponga en riesgo nuestros servicios, si es que ésta es relevante al entorno virtualizado. Nos sugerirá además las acciones correctivas pertinentes, o incluso las llevará a cabo automáticamente si así lo lo hemos especificado para ese grupo de hosts en particular:

    imageimage image

    Saludos

    David Cervigón