Compartir a través de

Rendimiento de System Center - 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 los datos para los conectores. Este es el tiempo que tarda Service Manager en importar los 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 de envergadura con Configuration Manager. Dado que un conector se sincroniza inicialmente, es de esperar que el rendimiento se vea afectado por todos los roles y procesos del 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 (una base de datos de Microsoft SQL Server). Aunque no se puede acelerar el proceso de sincronización inicial del conector, puedes planear la sincronización inicial y asegurarte de que el proceso de sincronización se complete correctamente antes de poner en marcha Service Manager.

Una vez completada la sincronización inicial, Service Manager continúa sincronizando las diferencias que no tienen un efecto 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 consideración de rendimiento del flujo de trabajo, se incluyen:

  • Los flujos de trabajo suelen comenzar y finalizar en un minuto. Cuando los roles del servidor de Service Manager están sometidos a una carga de trabajo intensiva, los flujos de trabajo no se completan tan rápido como de costumbre.

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

Cuando el sistema está sometido a una carga intensiva (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.

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

Debes planear anticipadamente los grupos y los roles de usuario. Debes crear los grupos con moderación y para el ámbito más pequeño posible. A continuación, debes rellenar inicialmente tu base de datos con los datos de Active Directory Domain Services (AD DS), Configuration Manager y System Center Operations Manager antes de crear tus grupos.

A menudo, los administradores crean grupos para asegurarse de que los usuarios solo tengan acceso a los grupos especificados. Por ejemplo, en un escenario, es posible que desees crear un subconjunto de incidentes, como los incidentes que afectan a los equipos usados por el personal de recursos humanos. En este escenario, es posible que solo quieras que un personal específico pueda ver o modificar el grupo de servidores confidenciales. A continuación, para habilitar este tipo de acceso, tendrías que crear un grupo para todos los usuarios y un grupo para los equipos confidenciales y, a continuación, asegurarte de que un rol de seguridad tenga acceso a los grupos Todos los usuarios y Servidores confidenciales. Inevitablemente, la creación de un grupo contentivo de todos los usuarios afecta el rendimiento porque Service Manager comprueba si hay cambios en el grupo con frecuencia. De forma predeterminada, esta comprobación se produce una vez cada 30 segundos. En caso de grupos grandes, la comprobación de los cambios supone una carga significativa en el sistema, por lo que puede ralentizar considerablemente el tiempo de respuesta.

Solución 1: puedes especificar manualmente la frecuencia con la que Service Manager comprueba los cambios del grupo mediante la modificación de una clave del registro. Por ejemplo, si cambias la frecuencia de comprobación del grupo de 30 segundos a 10 minutos, aumentarás 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 del grupo. Por lo tanto, aumentar el valor del intervalo de sondeo da como resultado tiempos más largos para los cálculos de los 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.

Especificar manualmente el intervalo de comprobación de cambios de grupo

  1. Ejecuta Regedit y accede a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Crea un nuevo valor DWORD denominado GroupCalcPollingIntervalMilliseconds.

  3. En lo que respecta a su valor, especifica el intervalo en milisegundos. El resultado se multiplica por 6. Por ejemplo, para establecer el intervalo en 10 minutos, introduce 600000.

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

Solución 2: puedes 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 usas este método, eliminas la necesidad de un grupo grande ("Todos los usuarios") y la comprobación costosa que Service Manager debe realizar para determinar esta pertenencia a grupos. En el servidor de administración de Service Manager, puedes ejecutar el siguiente script de Windows PowerShell para agregar el tipo "usuario" a un rol "RoleName". Tienes que modificar este script de ejemplo para tu entorno.

Ejecución de un script de Windows PowerShell para agregar objetos a un rol de usuario

  • Modifica el siguiente script según sea necesario y luego ejecútalo:
#  
# 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, planea el uso de clases "típicas" en el sistema siempre que sea posible. La mayoría de las clases de objeto como, por ejemplo, la 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 se quieren ver incluidos en una vista. Cada vez que se crea una vista basada en un tipo de objeto avanzado y se abre dicha vista, Service Manager consulta la base de datos y se lee una gran cantidad de datos. Pero se muestra o se usa una parte pequeña de los datos recuperados.

Si detectas problemas de rendimiento con las vistas que has definido al usar tipos de objetos avanzados en vistas, cambia al uso de tipos típicos. Como alternativa, puedes crear tus propios tipos de proyección que contengan solo los datos sobre los que necesitas basarte para 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, incluidos 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. Encontrarás más información a tu disposición en este documento. Aquí se presentan algunos puntos clave:

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

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

  • Puedes 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. Puedes obtener más ventajas si mueves tempdb a una unidad RAID física diferente a la de la base de datos de Service Manager. Si es posible, usa un sistema de disco RAID 1+0 para hospedar la base de datos de Service Manager.

  • 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 si se hace en incrementos pequeños.

Consulta la herramienta de la aplicación auxiliar de ajuste de tamaño de Service Manager que se incluye en el conjunto de documentación de las ayudas para trabajos de Service Manager (SM_job_aids.zip) para obtener ayuda al 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 te ayudará con el rendimiento, al reducir el número de veces que la base de datos tiene que crecer automáticamente.

Del mismo modo, también son aplicables todos los demás procedimientos recomendados para una base de datos de alto rendimiento. Por ejemplo, si puedes aprovechar un subsistema de disco superior, puedes beneficiarte 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, considera la posibilidad de agregar servidores de administración adicionales si planeas tener un gran número de consolas simultáneas. Debes tener 8 GB de RAM para el servidor de administración. Debes tener al menos 4 núcleos de CPU por servidor de administración, suponiendo que tengas 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. Debes tener 4 GB de RAM en el equipo donde esté instalada la consola de Service Manager. Si tienes vistas que recuperan una gran cantidad de datos, necesitarás RAM adicional. Debes 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 ves un consumo excesivo de recursos. La consola de Service Manager almacena de forma intensiva la información en caché en la memoria, lo que puede contribuir al consumo general de la memoria.

Problemas de rendimiento de la base de datos o del almacenamiento de datos de Operations Manager

El rendimiento del almacenamiento de datos se ve afectado directamente por varios factores, incluidos 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 que son innecesarios. Otro factor que afecta al rendimiento del almacenamiento de datos es la configuración BatchSize de los procesos ETL.

Puedes lograr un mejor rendimiento separando los archivos de registro y los archivos de datos para separar los discos físicos. Pero debes evitar colocar más de un archivo de registro por disco. De forma similar, puedes lograr una mejor capacidad de proceso colocando la base de datos tempdb en un disco físico diferente al de las demás bases de datos. Por último, también puede beneficiarte colocando las distintas bases de datos en sus respectivos discos físicos. Si es posible, usa un sistema de disco RAID 1+0 para hospedar el almacenamiento de datos. Por lo general, debes tener un mínimo de 8 GB de RAM para el equipo donde instales las bases de datos del almacenamiento de datos. Si tienes orígenes de datos de almacenamiento de datos adicionales de Operations Manager o Configuration Manager, debes aumentar la cantidad de RAM para las bases de datos. Te beneficiarás 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 tienes 4000 equipos o menos en la topología de implementación, 4 GB es suficiente. Debes tener al menos 8 núcleos de CPU en el equipo donde está instalada la base de datos del almacenamiento de datos. Los núcleos adicionales ayudarán tanto al rendimiento de ETL como a los informes.

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. Consulta la herramienta de la aplicación auxiliar de ajuste de tamaño de Service Manager que se incluye en el conjunto de documentación de las ayudas para trabajos de Service Manager (SM_job_aids.zip) para evaluar el tamaño de la base de datos y crear una base de datos con un tamaño más cercano al tamaño final, lo que te ayudará al rendimiento al reducir el número de veces que la base de datos tiene que crecer automáticamente.

Service Manager incluye una compatibilidad integrada con grupos de archivos. Puedes beneficiarte de esta función 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, consulta la documentación de SQL Server.

Rendimiento del servidor de almacenamiento de datos de Service Manager

El rendimiento del servidor del 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, debes tener un mínimo de 8 GB de RAM para el servidor del almacenamiento de datos. Pero el rendimiento se beneficiará al contar con memoria adicional para escenarios de implementación avanzados en los que más de un servidor de administración de Service Manager inserte datos en el almacenamiento de datos. Si debes comprometer el rendimiento, la prioridad más alta debe ser para la memoria del equipo que ejecuta SQL Server. Debes 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, puedes admitir más objetivos de nivel de servicio de los que podrías ser capaz. Pero 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 sea necesario. Se recomienda crear no más de cinco objetivos de nivel de servicio para una configuración típica de Service Manager de 50000 equipos. Es posible que puedas crear más objetivos de nivel de servicio. Pero, dado que las condiciones varían considerablemente de organización a organización, Microsoft no puede ofrecer una recomendación concreta sobre el número de objetivos de nivel de servicio que no debes 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