Compartir a través de

System Center: rendimiento de Service Manager

  • Artículo

El rendimiento de los roles y características del servidor de System Center - Service Manager se ve afectado por distintos factores. Por lo general, hay tres áreas en las que el rendimiento positivo y negativo es más notable en Service Manager:

  • Capacidad de respuesta de la consola de Service Manager. Este es el período de tiempo que tarda desde el momento en que se realiza algún tipo de acción en la consola hasta que se completa.

  • Tiempo de inserción de datos para conectores. Este es el tiempo que tarda Service Manager en importar datos cuando se sincroniza un conector.

  • Tiempo de finalización del flujo de trabajo. Este es el período de tiempo que tardan los flujos de trabajo en aplicar automáticamente algún tipo de acción.

Rendimiento del conector

La sincronización inicial del conector puede tardar mucho tiempo; por ejemplo, de 8 a 12 horas para una sincronización inicial grande con Configuration Manager. Como conector se sincroniza inicialmente, puede esperar que el rendimiento se vea afectado por todos los roles y procesos de servidor de Service Manager durante este tiempo. Esto ocurre debido a la forma en que los datos se insertan secuencialmente en la base de datos de Service Manager, que es una base de datos de Microsoft SQL Server. Aunque no se puede realizar el proceso de sincronización inicial del conector, puede planear la sincronización inicial y asegurarse de que el proceso de sincronización se completa correctamente antes de que Service Manager se ponga en producción.

Una vez completada la sincronización inicial, Service Manager continúa sincronizando las diferencias, que no tienen un impacto medible en el rendimiento.

Rendimiento del flujo de trabajo

Los flujos de trabajo son procesos automáticos que se producen. Incluyen el envío de notificaciones por correo electrónico, el siguiente paso de la activación de una solicitud de cambio y la aplicación automática de una plantilla.

Entre las consideraciones de rendimiento del flujo de trabajo se incluyen las siguientes:

  • Normalmente, los flujos de trabajo comienzan y finalizan en un minuto. Cuando los roles de servidor de Service Manager están en una carga de trabajo intensiva, los flujos de trabajo no se completan tan rápido como lo normal.

  • Además, al crear nuevos flujos de trabajo, como una nueva suscripción de notificación, se coloca una carga adicional en el sistema. A medida que aumenta el número de flujos de trabajo nuevos que se crean, también aumenta el tiempo que tarda cada flujo de trabajo en ejecutarse.

Cuando el sistema está bajo una carga pesada (por ejemplo, si se crea un gran número de incidentes nuevos y cada incidente genera muchos flujos de trabajo), el rendimiento podría verse afectado negativamente.

Impacto en el rendimiento del grupo, la cola y el rol de usuario

Debe planear los grupos y los roles de usuario al principio. Debe crear grupos con moderación y crearlos para el ámbito más pequeño posible. A continuación, debe rellenar inicialmente la base de datos con datos de Servicios de dominio de Active Directory (AD DS), Configuration Manager y System Center Operations Manager antes de crear los grupos.

A menudo, los administradores crean grupos para asegurarse de que los usuarios solo tienen acceso a grupos especificados. Por ejemplo, en un escenario es posible que desee crear un subconjunto de incidentes, como incidentes que afectan a los equipos usados por el personal de recursos humanos. En este escenario, es posible que solo quiera que un personal específico pueda ver o modificar el grupo de servidores confidenciales. A continuación, para habilitar este tipo de acceso, tendría que crear un grupo para todos los usuarios y un grupo para equipos confidenciales y, a continuación, asegurarse de que un rol de seguridad tiene acceso a los grupos Todos los usuarios y servidores confidenciales. Inevitablemente, la creación de un grupo que contenga todos los usuarios produce un impacto en el rendimiento porque Service Manager comprueba con frecuencia si hay cambios en el grupo. Esta comprobación se produce una vez cada 30 segundos de forma predeterminada. Para un grupo grande, la comprobación de los cambios crea una carga pesada en el sistema y puede ralentizar considerablemente el tiempo de respuesta.

Solución 1: Puede especificar manualmente la frecuencia con la que Service Manager comprueba los cambios de grupo modificando una clave del Registro. Por ejemplo, si cambia la frecuencia de comprobación de grupo de 30 segundos a 10 minutos, aumentará significativamente el rendimiento. Sin embargo, las colas y los objetivos de nivel de servicio son tipos especiales de grupos que usan el mismo intervalo de sondeo de cálculo de grupo. Por lo tanto, aumentar el valor del intervalo de sondeo da como resultado tiempos más largos para los cálculos de objetivos de nivel de servicio y cola.

Precaución

La edición incorrecta del Registro puede dañar gravemente el sistema. Antes de realizar cambios en el Registro, debe hacer una copia de seguridad de los datos de valor guardados en el equipo.

Para especificar manualmente el intervalo de comprobación de cambios de grupo

  1. Ejecute Regedit y vaya a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Cree un nuevo valor DWORD denominado GroupCalcPollingIntervalMilliseconds.

  3. Para su valor, especifique el intervalo en milisegundos. El resultado se multiplica por 6. Por ejemplo, para establecer el intervalo en 10 minutos, escriba 600000.

  4. Reinicie el servicio de administración de System Center.

Solución 2: puede usar un script de Windows PowerShell para agregar objetos de un tipo, como "Usuarios", a un rol de usuario. Básicamente, un analista que ha iniciado sesión en este rol puede acceder a todos los objetos que tienen un tipo igual a "Usuario". Si usa este método, elimina la necesidad de un grupo grande ("Todos los usuarios") y la comprobación costosa de que Service Manager realiza para determinar esta pertenencia a grupos. En el servidor de administración de Service Manager, puede ejecutar el siguiente script de Windows PowerShell para agregar el tipo "usuario" a un rol "RoleName". Tiene que modificar este script de ejemplo para su entorno.

Para ejecutar un script de Windows PowerShell para agregar objetos a un rol de usuario

  • Modifique el siguiente script según sea necesario y, a continuación, ejecútelo:
#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}

Visualización del rendimiento

Al crear vistas, planee el uso de clases "típicas" en el sistema siempre que sea posible. La mayoría de las clases de objeto,por ejemplo, Administración de incidentes tienen dos tipos: "típico" y "avanzado". El tipo de objeto típico contiene referencias simples a un pequeño subconjunto de datos que está relacionado con un elemento. El tipo avanzado contiene muchas referencias complejas a los datos relacionados con un elemento. Los tipos típicos son proyecciones simples; los tipos avanzados son proyecciones complejas. Los tipos de objetos más avanzados se usan para rellenar campos diferentes en formularios que normalmente no desea ver mostrados en una vista. Cada vez que se crea una vista basada en un tipo de objeto avanzado y al abrir la vista, Service Manager consulta la base de datos y se lee una gran cantidad de datos. Sin embargo, se muestra o usa muy poco de los datos recuperados.

Si encuentra problemas de rendimiento con las vistas que ha definido al usar tipos de objetos avanzados en vistas, cambie al uso de tipos típicos. Como alternativa, puede crear sus propios tipos de proyección que contengan solo los datos que necesita para basar una vista.

Rendimiento de la base de datos de Service Manager

El rendimiento de la base de datos de Service Manager se ve directamente afectado por varios factores, incluido el número de consolas simultáneas de Service Manager que leen o escriben datos, el intervalo de comprobación de cambios de grupo y los datos que insertan los conectores. Puede encontrar más información en este documento. Estos son algunos puntos clave:

  • Debe tener un mínimo de 8 gigabytes (GB) de RAM para el servidor de administración en el que hospeda la base de datos de Service Manager para que pueda tener un tiempo de respuesta aceptable en escenarios típicos.

  • Debe tener al menos 8 núcleos de CPU en el equipo que hospeda la base de datos de Service Manager.

  • Puede lograr un mejor rendimiento de la base de datos separando los archivos de registro y los archivos de datos para separar los discos físicos, si es posible. Para obtener más ventajas, mueva tempdb a una unidad RAID física diferente a la de la base de datos de Service Manager. Use un sistema de disco RAID 1+0 para hospedar la base de datos de Service Manager, si es posible.

  • El rendimiento puede verse afectado negativamente si la base de datos de Service Manager se crea con un tamaño menor y se establece en crecimiento automático, especialmente en incrementos pequeños.

Consulte la herramienta Asistente de ajuste de tamaño de Service Manager que se incluye en el conjunto de documentación de ayudas al trabajo de Service Manager (SM_job_aids.zip) para obtener ayuda para evaluar el tamaño de la base de datos y crear la base de datos con un tamaño más cercano al tamaño final. Esto ayudará al rendimiento al reducir el número de veces que la base de datos tiene que crecer automáticamente.

Del mismo modo, también se aplican todos los demás procedimientos recomendados para una base de datos de alto rendimiento. Por ejemplo, si puede aprovechar un subsistema de disco superior, puede beneficiarse de dividir los grupos de tablas en grupos de archivos respectivos y moverlos a una unidad física diferente.

Rendimiento del servidor de administración de Service Manager

El rendimiento del servidor de administración de Service Manager se ve afectado principalmente por el número de consolas de Service Manager simultáneas activas. Dado que todos los roles de Service Manager interactúan con el servidor de administración, considere la posibilidad de agregar servidores de administración adicionales si planea tener un gran número de consolas simultáneas. Debe tener 8 GB de RAM para el servidor de administración. Debe tener al menos 4 núcleos de CPU por servidor de administración, suponiendo que tenga de 10 a 12 consolas activas por núcleo de CPU.

Rendimiento de la consola de Service Manager

El rendimiento de la consola de Service Manager se ve afectado principalmente por el número de formularios que los analistas suelen tener abiertos y la cantidad de datos que recuperan las vistas. Debe tener 4 GB de RAM en el equipo donde está instalada la consola de Service Manager. Si tiene vistas que recuperan una gran cantidad de datos, necesitará ram adicional. Debe tener al menos una CPU de 4 núcleos para el equipo donde está instalada la consola de Service Manager. Dado que la consola de Service Manager es una aplicación de usuario final, se recomienda reiniciarla si ve un consumo excesivo de recursos. La consola de Service Manager almacena de forma agresiva la información en caché en la memoria, lo que puede contribuir al uso general de la memoria.

Rendimiento de la base de datos de almacenamiento de datos de Service Manager

El rendimiento del almacenamiento de datos se ve afectado directamente por varios factores, incluido el número de servidores de administración simultáneos de Service Manager que envían datos, el volumen de datos almacenados o el período de retención de datos, la tasa de cambio de datos y la frecuencia de extracción, transformación y carga (ETL). La cantidad de datos almacenados en el almacenamiento de datos aumenta con el tiempo. Es importante asegurarse de archivar datos innecesarios. Otro factor que afecta al rendimiento del almacenamiento de datos es la configuración BatchSize de los procesos ETL.

Puede lograr un mejor rendimiento separando los archivos de registro y los archivos de datos para separar los discos físicos. Sin embargo, debe evitar colocar más de un archivo de registro por disco. De forma similar, puede lograr un mejor rendimiento colocando tempdb en un disco físico diferente al de las demás bases de datos. Por último, también puede beneficiarse colocando las distintas bases de datos en sus respectivos discos físicos. Use un sistema de disco RAID 1+0 para hospedar el almacenamiento de datos, si es posible. Por lo general, debe tener un mínimo de 8 GB de RAM para el equipo donde se instalan las bases de datos del almacenamiento de datos. Si tiene orígenes de datos de almacenamiento de datos adicionales de Operations Manager o Configuration Manager, debe aumentar la cantidad de RAM para las bases de datos. Se beneficiará de más memoria en el equipo que ejecuta SQL Server que hospeda el almacenamiento de datos y, aún más, si las bases de datos Datamart y Repository están en el mismo servidor. Sin embargo, si tiene 4000 equipos o menos en la topología de implementación, 4 GB es suficiente. Debe tener al menos 8 núcleos de CPU en el equipo donde está instalada la base de datos de almacenamiento de datos. Los núcleos adicionales ayudarán tanto al rendimiento de ETL como al informe.

El rendimiento puede verse afectado negativamente si todas las bases de datos del sistema se crean con un tamaño menor y se establecen en crecimiento automático, especialmente en incrementos pequeños. Consulte la herramienta Asistente de ajuste de tamaño de Service Manager que se incluye en el conjunto de documentación de ayudas al trabajo de Service Manager (SM_job_aids.zip) para evaluar el tamaño de la base de datos y crear la base de datos con un tamaño más cercano al tamaño final, lo que ayudará al rendimiento al reducir el número de veces que la base de datos tiene que crecer automáticamente.

Service Manager incluye compatibilidad integrada con grupos de archivos. Puede beneficiarse de esto colocando los grupos de archivos en unidades de disco duro independientes. Para obtener más información sobre los procedimientos recomendados del grupo de archivos, consulte la documentación de SQL Server.

Rendimiento del servidor de almacenamiento de datos de Service Manager

El rendimiento del servidor de almacenamiento de datos se ve afectado por el número de servidores de administración de Service Manager registrados en el almacenamiento de datos, el tamaño de la implementación y el número de orígenes de datos. Por lo general, debe tener un mínimo de 8 GB de RAM para el servidor de almacenamiento de datos. Sin embargo, el rendimiento se beneficiará al tener memoria adicional para escenarios de implementación avanzados en los que más de un servidor de administración de Service Manager inserta datos en el almacenamiento de datos. Si debe desactivar el rendimiento, la prioridad más alta debe ser para la memoria del equipo que ejecuta SQL Server. Debe tener al menos 8 núcleos de CPU para evitar problemas de rendimiento.

Rendimiento del portal de autoservicio

El Portal de autoservicio está diseñado para facilitar el acceso a la presentación de solicitudes de incidentes y servicios. No está diseñado para controlar miles de usuarios simultáneamente.

Las pruebas de rendimiento del Portal de autoservicio se centraron en escenarios típicos de "lunes a la mañana", específicamente, para asegurarse de que el lunes por la mañana cientos de usuarios pueden iniciar sesión en un intervalo de 5 a 10 minutos y abrir incidentes con tiempos de respuesta aceptables (menos de 4 a 5 segundos). Este objetivo se ha logrado con el hardware mínimo recomendado en este documento.

Rendimiento objetivo de nivel de servicio

No hay ningún número específico de objetivos de nivel de servicio compatibles con Service Manager. Por ejemplo, si una organización suele tener pocos incidentes, puede admitir más objetivos de nivel de servicio de los que podría ser capaz de hacerlo. Sin embargo, un volumen de incidentes mayor podría requerir menos objetivos de nivel de servicio o un escalado horizontal de hardware y software adicionales, según corresponda. Se recomienda crear no más de cinco objetivos de nivel de servicio para una configuración típica de Service Manager de 50 000 equipos. Posiblemente podría crear más objetivos de nivel de servicio. Sin embargo, dado que las condiciones varían considerablemente de la organización a la organización, Microsoft no puede proporcionar una recomendación concreta para el número de objetivos de nivel de servicio que no debe superar. Si la configuración de implementación sufre un rendimiento deficiente como resultado del número de objetivos de nivel de servicio, se recomienda escalar horizontalmente mediante el siguiente escenario de implementación más grande, como se describe en el artículo Configuraciones para escenarios de implementación de esta guía.

Pasos siguientes