Hace unos días tuve que implementar una serie de contadores para poder comprender y también documentar un poco sobre rendimiento de mis controladores, entonces pues por la gran cantidad de estos busqué un poco como automatizar el proceso y así ahorrarme tiempo que puedo invertir explorando las maravillas de la web u otros.
Básicamente haremos lo siguiente, crear el conjunto de contadores, una tarea que los inicie al arrancar el equipo y luego otra que a media noche cree una bitácora nueva y envíe la anterior a un punto centralizado de almacenaje.
Realmente podríamos escribir la bitácoras directo a un SQL pero eso me crearía ciertas dependencias adicionales que en mi caso no deseo. Igual esto es tan solo una de las mil formas de hacer las cosas.
Pues bien, manos a la obra!
El primer punto entonces es crear el conjunto de contadores, los cuales guardaremos en un archivo XML que funcionara como plantilla, para esto ejecute el Performance Monitor, navegue a la sección de Data Collector Sets y luego User Defined. Si usted no tiene pues mucha experiencia con el PerfMon pues le recomiendo iniciar acá http://technet.microsoft.com/en-us/library/cc749249.aspx
Es ahí donde deberá agregar los contadores que usted necesite, recuerde que también hay plantillas que usted podría utilizar o bien personalizar según sus necesidades.
Para efectos de estandarización en la plataforma creare una carpeta llamada "scripts" en la raíz de C: y en esta almacenaré la plantilla o machote del Performance Monitor, esta se almacenara en formato XML.
En este caso esto lo necesito hacer únicamente en mi controladores de domino por lo cual con este comando los enlistare todos "dsquery server -o rdn >dc-list.txt"
Listo, ahora vamos a crear la carpeta y copiar su contenido en todos los servidores de la lista anterior, necesitaremos también los archivos para las tareas.
“logman start testCollectorSet”
Este lo llamaremos start-PerfData.bat
El comando anterior iniciara el set de colección de datos llamado "testCollectorSet", acá no hay como que mucha magia.
Siguiente!
“logman stop testCollectorSet
start-sleep 10
robocopy D:\perfmon \\repositorio.fqdn\carpeta\ /mov
start-sleep 180
logman start testCollectorSet”
Este lo llamaremos recycle-PerfData.ps1
Acá detenemos la captura de datos, esperamos un poco, movemos los datos hacia un repositorio central (el cual no es más que un simple folder compartido con sus respectivos permisos), purgamos los archivos e iniciamos la recolección de datos.
Procedamos a copiar la carpeta y su contenido a los servidores.
"for /f %a in (C:\serverList.txt) do xcopy C:\Scripts \\%a\c$\scripts\ /I /E"
Ahora bien, para crear el grupo de contadores en cada servidor simplemente necesito el siguiente comando:
"for /f %a in (C:\serverList.txt) do logman -s %a import testCollectorSet -xml C:\scripts\testCollectorSet.xml"
Necesito crear dos tareas, estas invocaran los archivos que acabo de transferir, la primera iniciara los contadores al arranque y la segunda que hará el movimiento de la información se ejecutara a media noche.
Para crear dichas tareas ejecute este comando:
"for /f %a in (C:\serverList.txt) do schtasks /create /s %a /RU cuentaDeServicio@daemonroot.com /RP P@$$w0rd /SC onstart /TN inicia-perfData /TR C:\Scripts\start-PerfData.bat & schtasks /create /s %a /RU cuentaDeServicio@daemonroot.com /RP P@$$w0rd /SC daily /ST 00:00 /TN reinicia-perfData /TR C:\Scripts\recycle-PerfData.ps1"
Notemos que acá estoy utilizando una cuenta de servicio, como son controladores debe usted de tomar en cuenta los permisos necesarios para esta.
Y si todo lo anterior es exitoso pues podríamos iniciar las tareas sin problema alguno
"for /f %a in (C:\serverList.txt) do schtasks /run /s %a /tn inicia-perfData"
En nuestro caso uno de mis compañeros desarrollo un humilde script que lee los archivos CSV del repositorio central, los lee y crea reportes de estos... un poco avanzado para mis capacidades!
En las propiedades del PerfMon especificamos que se recopilen datos cada minuto y que el nombre del archivo sea %computername%_Performance Counterfecha.csv, acá estan sus propiedades.
C:\>logman query testCollectorSet
Name: testCollectorSet
Status: Stopped
Root Path: C:\perfmon
Duration: 60 second(s)
Segment: Off
Schedules: On
Run as: DAEMONROOT\cuentaDeServicio
Name: testCollectorSet\Performance Counter
Type: Counter
Output Location: C:\perfmon\NEMESIS_Performance Counter031210.csv
Append: Off
Circular: Off
Overwrite: Off
Sample Interval: 60 second(s)
Counters:
\Processor(_Total)\% Privileged Time
\LogicalDisk(_Total)\% Disk Read Time
\LogicalDisk(_Total)\% Disk Write Time
\Processor(_Total)\% C1 Time
\Processor(_Total)\% C2 Time
\Processor(_Total)\% C3 Time
Bueno, espero esto les sea útil, como siempre acá estaré si necesitan una mano, hasta pronto!
Las andanzas de un fiebre de la consola, el que trata de escuchar en el 389 y responde el saludo con un "ehlo"... sumergido entre libros, foros, webcasts y otros. Un computin mas que desea continuamente aprender y compartir... ese es daemonRoot, ese soy yo!
Showing posts with label perfmon. Show all posts
Showing posts with label perfmon. Show all posts
December 03, 2010
October 05, 2010
Servidores nuevos, siiii!
Estamos en la fase de diseño de nuestros nuevos controladores, necesitamos comprender como se comporta el equipo actual para asi hacer nuestros pronósticos para el siguiente.
Con perfmon puedo crear un set de contadores como memoria, tiempos de lectura de la partición donde se aloja el NTDS.DIT y procesador, estos los salvo como un archivo HMT (Server 2003) o XML para crear un machote (a partir de Server 2008) y así los puedo reutilizar en otros equipos. Además puedo especificar que el output sea en formato CSV lo cual hará más fácil el proceso de datos en Excel.
Entonces con lo anterior puedo tener ciertos números aproximados de cuanta memoria necesito, si mi arreglo de discos y velocidad de estos es adecuado, también si necesito más procesadores, o tal vez alguno más poderoso.
También algo que nos puede ser útil es llevar un archivo histórico que refleje el comportamiento de la base de datos de AD, en el EventID 1646 podemos encontrar el tamaño de este, entonces podríamos analizar el crecimiento de este y junto con información sobre el crecimiento o proyecciones de la empresa podríamos calcular el espacio adecuado de los discos para almacenarlo. También en la sana teoría es óptimo poder cargar nuestro AD en memoria, por lo cual saber su tamaño es muy importante.
Otros factores como futuras implementaciones o ampliaciones de servicios que dependen en AD nos pueden afectar, tal como Exchange que estará haciendo consultas continuas a AD, o el almacenaje de llaves de encriptación de BitLocker lo cual hará crecer el .DIT.
Recordemos que cambiar el hardware no es algo que se hace a menudo por lo cual además de lo que con nuestro método podamos prever debemos dar un espacio de error y desde luego calcular cuántos años pretendemos utilizar el equipo nuevo.
Como siempre, esto no es una guía definitiva, son tan solo un manojo de ideas que espero les puedan ayudar, gracias por su lectura.
Con perfmon puedo crear un set de contadores como memoria, tiempos de lectura de la partición donde se aloja el NTDS.DIT y procesador, estos los salvo como un archivo HMT (Server 2003) o XML para crear un machote (a partir de Server 2008) y así los puedo reutilizar en otros equipos. Además puedo especificar que el output sea en formato CSV lo cual hará más fácil el proceso de datos en Excel.
Entonces con lo anterior puedo tener ciertos números aproximados de cuanta memoria necesito, si mi arreglo de discos y velocidad de estos es adecuado, también si necesito más procesadores, o tal vez alguno más poderoso.
También algo que nos puede ser útil es llevar un archivo histórico que refleje el comportamiento de la base de datos de AD, en el EventID 1646 podemos encontrar el tamaño de este, entonces podríamos analizar el crecimiento de este y junto con información sobre el crecimiento o proyecciones de la empresa podríamos calcular el espacio adecuado de los discos para almacenarlo. También en la sana teoría es óptimo poder cargar nuestro AD en memoria, por lo cual saber su tamaño es muy importante.
Otros factores como futuras implementaciones o ampliaciones de servicios que dependen en AD nos pueden afectar, tal como Exchange que estará haciendo consultas continuas a AD, o el almacenaje de llaves de encriptación de BitLocker lo cual hará crecer el .DIT.
Recordemos que cambiar el hardware no es algo que se hace a menudo por lo cual además de lo que con nuestro método podamos prever debemos dar un espacio de error y desde luego calcular cuántos años pretendemos utilizar el equipo nuevo.
Como siempre, esto no es una guía definitiva, son tan solo un manojo de ideas que espero les puedan ayudar, gracias por su lectura.
Subscribe to:
Posts (Atom)