CIM/WMI
Introducción
El título de este capítulo probablemente no le diga gran cosa excepto que las tres letras WMI significan Windows Management Instrumentation. WMI lo conocen bien los administradores de sistemas Microsoft ya que esta tecnología permite obtener información acerca de la infraestructura pero también permite actuar sobre una parte o la totalidad de un sistema operativo, así como en ciertas aplicaciones del mundo Microsoft. Esta tecnología se concibió de manera que se pueda utilizar de manera local o remota con la misma facilidad.
WMI ha sido la tecnología elegida durante muchos años para la gestión de hardware y software en red, aunque cederá progresivamente su sitio a la tecnología CIM. Igual es una torpeza decir esto ya que WMI ya se apoya en gran medida sobre CIM. CIM es más bien una norma (o estándar) abierto que una tecnología. CIM es el acrónimo de Common Information Model.
Este capítulo le dará un pequeño vistazo de lo que se puede hacer en términos de gestión distribuida. Estas tecnologías son tan amplias que han dado paso a algunos libros muy densos... A lo largo de este capítulo nos esforzaremos en ir a lo esencial para que pueda debutar con rapidez en estas tecnologías. Sin embargo hemos elegido hablar de CIM y WMI separándolos ya que existen dos conjuntos de comandos PowerShell...
Estándares y más estándares, pero ¿para hacer qué?
La obtención de datos para administrar un entorno determinado es importante, pero no constituye más que una pequeña parte del problema de gestión más global en una empresa. Otro esfuerzo importante va dirigido sobre la normalización y la organización de los datos. Por ejemplo, una persona sabe que «bueno», «funcional», «operacional» y «en marcha» son todos sinónimos de un estado «OK». Pero ¿cómo un programa informático lo llega a saber? Peor aún, ¿cómo sabe el programa dónde se encuentra la información que busca?
Sin embargo el problema no se termina aquí con la determinación del lugar y la semántica. En efecto existe una necesidad creciente de gobierno del sistema de información en términos básicos. Así, por muy anodina que parezca, la avería de un ventilador en un equipo (en un procesador por ejemplo) puede tener consecuencias importantes. Por lo tanto es capital estar en disposición de determinar cuáles son los riesgos en la operativa expresados en términos de nivel de servicio.
La totalidad de la gestión de múltiples componentes en un entorno distribuido es una realidad que se convierte en requisito previo. Ya no basta con gestionar individualmente los puestos de trabajo, los servidores, los elementos activos de la red, los armarios de almacenamiento, los hypervisores, etc. Todos estos componentes interactúan entre sí para suministrar servicios globales....
Arquitectura general y terminología
La arquitectura CIM/WMI se descompone en tres capas como en el siguiente esquema:
Arquitectura CIM/WMI
Consumidor CIM/WMI es el término genérico para designar una aplicación cliente que realiza llamadas CIM/WMI. Puede ser simplemente un script o una herramienta de administración, o también una aplicación empresarial como Microsoft System Center Configuration Manager.
Un recurso gestionado puede ser cualquier componente físico o lógico administrable mediante CIM/WMI. Puede ser cualquier componente del sistema como el sistema de discos, el visor de eventos, el registro, los servicios, los procesos, etc. La lista es realmente muy larga. ¡Es increíble todo lo que puede ser administrado!
Un recurso gestionado dialoga con la infraestructura CIM/WMI exclusivamente a través de un proveedor. Cada recurso o más bien cada clase de recurso está descrita en un archivo de texto con el formato MOF (Managed Object Format). Este tipo de archivos contiene todas las propiedades, métodos y demás información útil que describen todo lo que es posible hacer con un recurso gestionado a través de CIM/WMI.
Para que la infraestructura CIM/WMI pueda usarlo, un archivo MOF debe estar compilado. Después se carga en la base CIM. Si conoce SNMP (Simple Network Management Protocol), sepa que un archivo MOF es a CIM/WMI...
Comandos de la familia CIM
1. Conjunto de comandos
Introducidos en PowerShell 3.0, el conjunto de comandos de la familia CIM se indica en la siguiente tabla. En PowerShell 6.0 es el único juego de comandos soportado para interactuar con CIM/WMI:
Comando |
Descripción |
Get-CimInstance |
Recupera las instancias de una clase. |
Set-CimInstance |
Modifica una o varias instancias de una clase. |
New-CimInstance |
Crea una nueva instancia de clase. |
Remove-CimInstance |
Suprime una o varias instancias de una clase. |
Get-CimAssociatedInstance |
Recupera las instancias asociadas de una instancia determinada. |
Get-CimClass |
Recupera el esquema de clase de una clase CIM. |
Invoke-CimMethod |
Invoca una instancia o un método estático de una clase. |
New-CimSession |
Crea una sesión CIM en el equipo local o en un equipo remoto. |
New-CimSessionOption |
Crea un conjunto de opciones a utilizar cuando se establece la sesión. |
Get-CimSession |
Recupera la lista de sesiones establecidas. |
Remove-CimSession |
Suprime las sesiones CIM establecidas en un equipo. |
Register-CimIndicationEvent |
Se suscribe a un evento WMI/CMI. |
El comando que más usaremos es Get-CimInstance. Sin embargo, para utilizarlo, debemos determinar la clase a partir de la cual queremos obtener instancias. Y ahora las cosas se ponen un poco más feas...
2. Descubrimiento de clases
Get-CimClass es EL comando elegido para descubrir todo lo que se esconde en una infraestructura CIM/WMI ya que el descubrimiento era hasta ahora el gran punto débil de esta tecnología. En efecto, en las versiones anteriores de PowerShell, teníamos que escribir nuestros propios scripts de búsqueda para tener la esperanza de encontrar LA propiedad correcta o EL método necesario a la problemática del momento. ¡Esto forma parte del pasado! Microsoft, bajo el impulso de numerosos comentarios por parte de la comunidad MVP pero también de sus clientes, ha puesto los medios para colmar esta laguna. Es precisamente lo que vamos a ver en esta sección.
Antes de empezar, debe saber que si no se precisa un espacio de nombres, root/cimv2 será el que se considerará por defecto. Nada más normal cuando se sabe que el 90% de las clases CIM estándares se encuentran en su interior. Sin embargo, también debe saber que por ejemplo las clases relativas a la administración de un servidor Hyper-V se encuentran en un espacio de nombres...
Comandos de la familia WMI
Se habrá dado cuenta, a lo largo de este capítulo, de que desde la aparición de PowerShell 3 el conjunto de comandos WMI ha quedado en beneficio de los comandos de la familia CIM. Microsoft no lo evolucionará más, y a lo mejor la mantendrá durante cierto tiempo. Los comandos de esta familia no han evolucionado desde la anterior versión de PowerShell.
Como le decíamos, estos comandos no forman parte de PowerShell Core, de modo que, si los utiliza en un script, sepa que este puede no ejecutarse correctamente en PowerShell Core.
La familia de comando WMI se resume en los cinco comandos siguientes:
Comando |
Descripción |
Equivalente CIM |
Get-WmiObject |
Recupera las instancias de una clase. |
Get-CimInstance |
Invoke-WmiMethod |
Invoca una instancia o un método estático de una clase. |
Invoke-CimMethod |
Register-WmiEvent |
Se suscribe a un evento WMI/CIM. |
Register-CimIndicationEvent |
Remove-WmiObject |
Suprime una o varias instancias de una clase. |
Remove-CimInstance |
Set-WmiInstance |
Modifica una o varias instancias de una clase. |
Set-CimInstance |
Cada uno de estos comandos de la familia WMI posee un equivalente en la familia CIM. Hemos añadido, como recordatorio, en la tabla anterior la columna Equivalente CIM para ayudarle en la transición si desea convertir antiguos scripts.
El comando más utilizado de entre todos los que se han presentado es, sin duda, Get-WmiObject. Este, a diferencia de su equivalencia CIM Get-CimInstance, devuelve objetos «vivos», es decir que poseen propiedades y métodos, métodos sobre las instancias en las que podemos actuar.
Esto no es posible con el conjunto de comandos CIM, por la sencilla razón de que los objetos se serializan y deserializan entre el cliente y el servidor (flujo XML) para atenerse a la norma CIM. Es la razón por la cual se utiliza el comando Invoke-CimMethod con mayor frecuencia en el mundo CIM que el comando Invoke-WmiMethod en el mundo WMI.
Aquí tiene los parámetros más habituales usados por Get-WmiObject:
Parámetro |
Descripción |
Class <String> |
Permite definir el nombre de la clase de la cual deseamos recuperar las instancias. |
Property <String> |
Permite definir el nombre de la propiedad o conjunto de propiedades a recuperar. |
NameSpace <String> |
Permite definir el espacio de nombres en el cual se encuentra la clase.... |
Establecer sesiones con equipos remotos
Mientras que con los comando WMI es posible comunicarse con máquinas remotas (mediante los protocolos DCOM y RPC), la comunicación no está optimizada ya que en cada consulta se establece una sesión, y a continuación se elimina después de haber devuelto los resultados al cliente. Además el diálogo con los equipos remotos se realiza de manera secuencial.
Los comandos de la familia CIM mejoran enormemente esta comunicación aportando:
-
Una comunicación que permite eligir entre los protocolos HTTPS/WS-Man o DCOM/RPC.
-
La posibilidad de mantener una sesión entre el cliente y los servidores.
-
La posibilidad de enviar consultas de manera paralela y no secuencial.
-
Un mecanismo de « remoting » similar a las sesiones PowerShell remotas.
El «remoting» CIM es muy similar al funcionamiento del mecanismo de «comunicación remota» de PowerShell (consulte el capítulo Ejecución remota).
Disponemos por lo tanto de la posibilidad de establecer una sesión temporal para una consulta con el parámetro -ComputerName, o utilizar una sesión CIM con el parámetro -Session, para enviar simultáneamente una consulta hacia varios equipos. Lo habrá comprendido, el uso de sesiones CIM es un mecanismo eficaz ya que permite reutilizar conexiones y evita así tener que crear y eliminar sesiones....
Monitoring de los recursos con la gestión de eventos
Otra faceta de CIM/WMI desconocida pero sin embargo muy útil es la gestión de eventos (o events en inglés). CIM permite vigilar o «monitorizar» eventos enviando una notificación. Después somos libres de decidir las acciones a llevar a cabo según la recepción de uno u otro evento.
La gestión de eventos CIM/WMI puede revelarse como un formidable aliado para ayudarnos, a nosotros los administradores de sistemas, a evitar transformarnos en auténticos bomberos. En efecto, gracias a este mecanismo, estaremos prevenidos, por ejemplo, si un disco lógico de un equipo llega al 80% de ocupación.
«Estar prevenido» puede significar recibir un e-mail, un SMS o un pop-up; todo depende de su script y el modo de notificación que haya elegido. Lo habrá entendido, es posible notificar de la aparición de un evento sobre cualquier recurso gestionado por CIM/WMI. Podemos por lo tanto vigilar el buen funcionamiento de los servicios en ciertos equipo remotos, la ejecución de un proceso determinado, o también monitorizar ciertas claves de registro. Viendo todas las clases WMI disponibles, es muy posible que podamos monitorizar EL recurso que le hacía tanta falta y que le permitirá en el futuro dormir a placer...
Para los que conocen SCOM (System Center Operations Manager), deben saber que el principio de notificaciones de eventos es el mismo; y para aquellos que no lo conozcan, podrán hacer lo mismo que con SCOM pero a una escala infinitamente más pequeña y con menor coste…
Si las notificaciones no existieran, y para intentar hacer lo mismo, estaríamos obligados a desarrollar scripts que se ejecutasen a intervalos de tiempo constantes para vigilar ciertos recursos gestionados. Aunque esto es posible, esta técnica puede llegar a consumir muchos recursos ya que el script debe ejecutarse con mucha frecuencia, o incluso ejecutarse como tarea de fondo constantemente. Las notificaciones WMI se han diseñado precisamente para ser la manera más eficiente de realizar estas tareas.
1. Vigilar la creación de un proceso local
Tomemos un ejemplo sencillo: la vigilancia del proceso MSPaint.exe que corresponde a la aplicación de dibujo estándar de Windows. El objetivo es lanzar un evento cuando el sistema detecta...
Gestión basada en las URI (Uniform Resource Identifier)
El uso de URI (Uniform Resource Identifier) se hace necesario cuando debemos administrar sistemas que disponen de un CIMOM, es decir administrables respetando el estándar CIM del DMTF, que no sean sistemas operativos Microsoft. En efecto, para estos últimos, es mucho más práctico y natural usar las clases CIM/WMI de las cuales ya hemos hablado. Sin embargo, lo uno no impide lo otro. Es decir que si conoce perfectamente el esquema CIM, entonces puede, bajo su responsabilidad, usar las URI para administrar también Windows. Debe saber que en realidad cuando hacemos una consulta CIM/WMI en un equipo remoto, por ejemplo con el comando Get-CimInstance sobre una clase dada, PowerShell transforma el nombre de la clase y la propiedad solicitada en una URI.
Por ejemplo, la siguiente línea de comandos:
PS > Get-CimInstance -ComputerName WS2012fr-1 -ClassName Win32_OperatingSystem
equivale a esta otra:
PS > $Uri = 'http://schemas.microsoft.com/wbem/wsman/1/wmi/root/
cimv2/Win32_OperatingSystem'
PS > Get-CimInstance -ComputerName WS2012fr-1 -ResourceUri $Uri
Los ejemplos que damos se han realizado con un equipo bajo Windows 8 x64 que sirve de cliente y otro con Windows Server 2012 que sirve de equipo gestionado, pero hubiésemos podido perfectamente hacerlos a la inversa. Estos dos equipos se encuentran dentro de un mismo dominio y el cortafuegos está activado en cada uno de ellos. No hemos configurado reglas particulares en el cortafuegos.
WS-Man responde a los estándares Web, y por lo tanto cualquier recurso gestionado debe conformarse con un cierto formalismo. Cada recurso CIM está normalizado por el DMTF y por eso se puede representar por una URI.
1. Anatomía de una URI
En la plataforma Microsoft, las URI permiten enlazar el protocolo WS-Management y las clases WMI. Las URI WMI se han definido directamente en el esquema WS-Management.
Una URI es la concatenación de un prefijo y del espacio de nombres WMI, como vemos abajo:
El prefijo estándar contiene una URL que no es una verdadera URL válida en el sentido que suele darse en Internet al término, pero representa la norma que define el esquema del recurso gestionado. Por ejemplo, para gestionar una tarjeta iDRAC en un servidor DELL, es necesario usar la URI siguiente: http://schemas.dell.com/wbem/wscim/1/cim-schema/2...
Caja de herramientas gráfica para la exploración de la base CIM/WMI
Si no se siente muy cómodo usando la línea de comandos para la exploración de la base CIM/WMI, sepa que existen algunas herramientas gráficas de más o menos fácil acceso.
1. Tester WMI (Wbemtest.exe)
El tester WMI está presente por defecto en todas las versiones de Windows desde Windows NT4. Gracias a él, puede explorar el esquema de la base CIM, examinar las definiciones de clases, visualizar y actuar sobre instancias en ejecución. Es una herramienta interesante, pero por desgracia reservada a personas experimentadas. Su mayor interés reside en el hecho de que está instalado en todos los equipos Windows (cliente o servidor).
Aquí tiene una muestra de su interfaz gráfica:
Tester WMI (Wbemtest.exe)
2. CIM Studio
Preste atención: esta herramienta ya no funciona en Windows 8/Server 2012. Le hablamos de ella puesto que sigue siendo una excelente herramienta para explorar gráficamente la infraestructura WMI.
CIM Studio pertenece al kit de desarrollo WMI (WMI SDK); es una aplicación Web. Microsoft ofrece este SDK gratuitamente. CIM Studio retoma lo esencial de las funcionalidades de Wbemtest pero aporta una interfaz gráfica netamente más ergonómica con algunas funcionalidades adicionales como la búsqueda de clases, de propiedades y métodos.
La exploración...