Rendimiento de Service Manager

Publicado: julio de 2016

Se aplica a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

El rendimiento de las características y funciones de servidor de System Center 2012 – Service Manager se ven afectadas por diferentes factores. Por lo general, hay tres áreas en las que el rendimiento positivo o negativo resulta más evidente en Service Manager:

• Capacidad de respuesta de Consola de Service Manager. Se trata del tiempo que transcurre desde el momento en que usted realiza alguna acción en la consola hasta el momento en que dicha acción se completa.

• Tiempo de inserción de datos para los conectores. Se trata de cuánto tiempo toma Service Manager para importar datos cuando se sincroniza un conector.

• Tiempo de finalización del flujo de trabajo. Se trata del tiempo que tardan los flujos de trabajo para aplicar automáticamente algún tipo de acción.

La sincronización inicial del conector puede tomar un tiempo considerable; por ejemplo, de 8 a 12 horas en el caso de una sincronización inicial grande con System Center Configuration Manager. Mientras un conector se sincroniza inicialmente, es de esperar que el rendimiento de todos los procesos y funciones del servidor de Service Manager se vean afectados hasta tanto finalice la sincronización. Esto se debe a la manera en que los datos se insertan de modo secuencial en la base de datos de Service Manager, la cual es una base de datos de Microsoft SQL Server. Si bien no es posible acelerar el proceso de sincronización inicial del conector, puede planificar antes de realizar la sincronización inicial para asegurar que el proceso de sincronización se complete correctamente antes de que Service Manager entre en producción.

Una vez que el proceso de sincronización inicial ha finalizado, Service Manager continúa sincronizando las diferencias, lo cual no tiene un impacto cuantificable sobre el rendimiento.

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 una solicitud de cambio que activa y aplica automáticamente una plantilla.

Las consideraciones de rendimiento de flujo de trabajo incluyen lo siguiente:

• Normalmente, los flujos de trabajo comienzan y terminan en menos de un minuto. Cuando las funciones de servidor de Service Manager se encuentran bajo carga de trabajo pesada, los flujos de trabajo tardan más en completarse.

• Además, cuando se crean nuevos flujos de trabajo, como una nueva suscripción de notificación, se agrega más carga al sistema. A medida que aumenta la cantidad de flujos de trabajo que se crean, el tiempo que tarda cada flujo de trabajo en ejecutarse también se incrementa.

Cuando el sistema trabaja bajo carga pesada, por ejemplo, si se crea una gran cantidad de incidentes nuevos y cada incidente genera muchos flujos de trabajo, entonces, es posible que el rendimiento se vea afectado de forma negativa.

El rendimiento de flujo de trabajo en System Center 2012 – Service Manager ha mejorado desde System Center Service Manager 2010 porque el nuevo módulo de administración ManagmentHostKeepAlive ha aumentando la respuesta de procesamiento de flujos de trabajo para que casi todos los flujos de trabajo se procesen en un minuto.

Debe planificar los grupos y funciones de usuario con antelación. 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), System Center Configuration Manager y System Center Operations Manager antes de crear sus grupos.

A menudo, los administradores crean grupos para asegurarse de que los usuarios tengan acceso únicamente a grupos específicos. Por ejemplo, en un escenario es posible que desee crear un subconjunto de incidentes, tales como incidentes que afectan los equipos utilizados por el personal de recursos humanos. En este escenario, quizás desee que sólo cierto personal pueda ver o modificar el grupo de servidores que contienen información confidencial. En tal caso, para habilitar este tipo de acceso, deberá crear un grupo para todos los usuarios y un grupo para los equipos con información confidencial y, luego, asegurar que una función de seguridad tenga acceso tanto al grupo "Todos los usuarios" como al grupo "Servidores con información confidencial". Resulta inevitable que el hecho de crear un grupo que contenga a todos los usuarios afecte el rendimiento porque Service Manager comprueba con frecuencia para determinar si se han producido cambios en ese grupo. Esta comprobación tiene lugar cada 30 segundos de manera predeterminada. En el caso de un grupo muy grande, el hecho de comprobar los cambios genera una carga pesada en el sistema y puede ralentizar el tiempo de respuesta considerablemente.

Solución 1: Puede especificar manualmente con qué frecuencia Service Manager debe comprobar si se han producido cambios en el grupo. Para eso, sólo debe modificar una clave del Registro. Por ejemplo, si cambia la frecuencia con que se comprueba el grupo de 30 segundos a 10 minutos, aumentará el rendimiento de manera notable. Sin embargo, los objetivos de nivel de servicio y de colas son tipos especiales de grupos que utilizan el mismo intervalo de sondeo de cálculo de grupo. Por lo tanto, aumentar el valor del intervalo de sondeo dará como resultado tiempos más largos para los cálculos de objetivos de niveles de cola y de servicio.

Precaución
La edición incorrecta del Registro puede producir graves daños en el sistema. Antes de realizar cualquier cambio en el Registro, debe realizar una copia de seguridad de los datos de valor del equipo.

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

1. Ejecute Regedit y navegue hasta HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

2. Cree un nuevo valor DWORD llamado GroupCalcPollingIntervalMilliseconds.

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

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

   Nota

   
   Para System Center 2012 R2 Service Manager, el nombre Servicio de administración de System Center se ha cambiado por Microsoft Monitoring Agent.

Solución 2: puede usar un script de Windows PowerShell para agregar objetos de un tipo (como por ejemplo, "Usuarios"), a un rol de usuario. En esencia, un analista que haya iniciado sesión con esta función tendrá acceso a todos los objetos cuyo tipo sea igual a "Usuario". Si emplea este método, eliminará la necesidad de tener un grupo muy grande ("Todos los usuarios") y la pesada comprobación que Service Manager realiza para determinar la pertenencia a este grupo. En el servidor de administración de Service Manager, puede ejecutar el siguiente script de Windows PowerShell para agregar el tipo "Usuario" a una función llamada "NombreDeFunción". Deberá modificar este script de ejemplo para que se adapte a su entorno.

Para ejecutar un script de Windows PowerShell a fin de agregar objetos a una función de usuario

• Modifique el siguiente script según sea necesario y vuelva a ejecutarlo:

# 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."  
}  
  

Al crear vistas, intente usar 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 subconjunto pequeño de datos relacionados 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 objeto más avanzados se emplean para rellenar diferentes campos de formularios que no querría que normalmente se muestren en una vista determinada. Si se crea una vista basada en un tipo de objeto avanzado, cada vez que se abre esa vista, Service Manager consulta la base de datos y lee una gran cantidad de datos. Sin embargo, muy pocos de esos datos en realidad se muestran en pantalla o se utilizan.

Si tiene problemas de rendimiento con las vistas que ha definido cuando se utilizan tipos de objeto avanzadas en las vistas, pasar a utilizar tipos típicos. Otra alternativa consiste en que cree sus propios tipos de proyección que contengan sólo los datos que necesita para una vista determinada. Para obtener más información, consulte la entrada de blog Creación de vistas que usen criterios relacionados con propiedades (proyecciones de tipo): ejemplo de vistas de software, en el blog del equipo de ingeniería SCSM.

El rendimiento de la base de datos de Service Manager se ve directamente afectado por diversos factores, incluida la cantidad de Consola de Service Manager concurrentes que estén leyendo o escribiendo datos, el intervalo de comprobación de cambios en los grupos y los datos insertados por los conectores. Este documento incluye más información. Aquí se presentan algunos puntos clave:

• Debe contar con un mínimo de 8 gigabytes de RAM para el servidor de administración que hospeda la base de datos de Service Manager a fin de obtener 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 si mantiene los archivos de registro separados de los archivos de datos en discos físicos diferentes, de ser posible. Puede conseguir aún más beneficios si mueve su tempdb a una unidad RAID física distinta de aquélla donde se encuentra la base de datos de Service Manager. De ser posible, utilice un sistema de discos RAID 1+0 para hospedar la base de datos de Service Manager.

• El rendimiento puede verse negativamente afectado si la base de datos de Service Manager se crea con un tamaño menor al necesario y se selecciona la opción de que incremente su tamaño automáticamente, en especial, si es en incrementos pequeños.

Consulte la herramienta Service Manager Sizing Helper que se incluye en el conjunto de documentación Service Manager job aids (Ayudas para trabajos de Service Manager) (SM_job_aids.zip) para obtener ayuda con la evaluación del tamaño de la base de datos y crear la base de datos con un tamaño que esté cercando al tamaño final. Esto favorecerá el rendimiento al reducir el tiempo que la base de datos debe dedicar al crecimiento propio.

De forma similar, todos los otros procedimientos recomendados para base de datos de alto rendimiento también son aplicables. Por ejemplo, si pudiese aprovechar un mejor subsistema de discos, tendría la posibilidad de dividir los grupos de tablas en respectivos grupos de archivos y colocarlos en unidades físicas diferentes.

El rendimiento del servidor de administración de Service Manager depende principalmente de la cantidad de Consola de Service Manager activas concurrentes Dado que todas los roles de Service Manager interactúan con el servidor de administración, debe tener en cuenta la posibilidad de agregar más servidores de administración si tiene pensado incluir una gran cantidad de consolas concurrentes Debe tener 8 GB de RAM para el servidor de administración. Debe tener al menos 4 núcleos de CPU por cada servidor de administración, suponiendo que tenga de 10 a 12 consolas activas por núcleo de CPU.

El rendimiento de la Consola de Service Manager depende, básicamente, de la cantidad de formularios que los analistas suelen tener abiertos y de la cantidad de datos recuperados por las diferentes vistas. Debe disponer de 4 GB de RAM en el equipo en el que se instalará la Consola de Service Manager. Si cuenta con vistas que recuperan un gran número de datos, deberá tener mayor cantidad de RAM. Debe contar, al menos, una CPU de 4 núcleos para el equipo en el que se instalará la Consola de Service Manager. Como Consola de Service Manager es una aplicación de usuario final, le recomendamos que la reinicie si ve un consumo excesivo de recursos.Consola de Service Manager almacena activamente información en la memoria, lo que contribuye a un uso global de la memoria.

El rendimiento del almacenamiento de datos se ve directamente afectado por diversos factores, incluida la cantidad de servidores de administración de Service Manager que envían datos, el volumen de los datos almacenados o el período de retención de datos, la velocidad con que cambian los datos, la extracción, la transformación y la frecuencia de carga de ETL. La cantidad de datos guardados en el almacenamiento de datos aumenta con el tiempo. Es importante asegurar que no se archiven datos innecesarios. Otro factor que afecta al rendimiento del almacenamiento de datos es el valor de BatchSize de los procesos ETL.

También, puede lograr un mejor rendimiento si mantiene los archivos de registro separados de los archivos de datos en discos físicos diferentes. Sin embargo, debe evitar colocar más de un archivo de registro por cada disco. Puede conseguir aún un mejor rendimiento si mueve su tempdb a un disco físico distinto de aquél donde se encuentran las otras bases de datos. Por último, también puede resultarle beneficioso colocar las diferentes bases de datos diferentes en discos físicos separados. De ser posible, utilice un sistema de discos RAID 1+0 para hospedar el almacenamiento de datos. Por lo general debe tener un mínimo de 8 GB de RAM para el equipo en el que están instaladas las bases de datos de almacenamiento de datos. Si dispone de orígenes de datos de almacenamiento de datos adicionales desde 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 y hospeda el almacenamiento de datos e incluso más si las bases de datos de Datamart y Repositorio están en el mismo servidor. No obstante, si tiene 4.000 equipos o menos, en la topología de implementación, 4 GB serán suficientes. Debe tener, al menos, 8 núcleos de CPU en el equipo donde se instalará la base de datos de almacenamiento de datos. Agregar otros núcleos permitirá mejorar el rendimiento de ETL y de la generación de informes.

El rendimiento puede resultar negativamente afectado si todas las bases de datos del sistema se crean con un tamaño menor al necesario y se selecciona la opción de que incrementen su tamaño automáticamente, en especial, si es en incrementos pequeños. Consulte la herramienta Service Manager Sizing Helper incluida en el conjunto de documentación Service Manager job aids (ayudas de trabajo de Service Manager) (SM_job_aids.zip) que le permitirá evaluar qué tamaño debería tener la base de datos y, así, podrá crear una base de datos con el tamaño más cercano a su tamaño final. De esta manera, el rendimiento del sistema se verá favorecido gracias a que se reducirá la cantidad de veces que la base de datos deberá incrementar su tamaño de manera automática.

Service Manager incluye compatibilidad 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, consulte la documentación de SQL Server.

El rendimiento del servidor de almacenamiento de datos depende de la cantidad de servidores de administración de Service Manager que estén registrados en el almacenamiento de datos, del tamaño del sistema y el número de orígenes de datos. Normalmente debería disponer, como mínimo, de 8 GB de RAM para el servidor del almacenamiento de datos. Sin embargo, el rendimiento se beneficiará de 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 tiene que sacrificar rendimiento, la prioridad más alta debería ser hacerlo por mayor memoria para el equipo que ejecuta SQL Server. Asimismo, debe tener, al menos, 8 núcleos de CPU para evitar problemas de rendimiento.

Portal de autoservicio se ha diseñado para un acceso sencillo a la presentación de solicitud servicios e incidentes. No se ha diseñado para manejar miles de usuarios simultáneamente.

La prueba de rendimiento de Portal de autoservicio se centró en los típicos escenarios de “lunes por la mañana”, específicamente, en garantizar que el lunes por la mañana miles de usuarios puedan iniciar sesión en un intervalo de 5 a 10 minutos y abrir incidentes con tiempos de respuesta aceptables (menos de 4 o 5 segundos). Este objetivo se logró con el hardware mínimo recomendado en este documento.

No hay un número específico de objetivos de nivel de servicio que Service Manager soporte. Por ejemplo, si una organización suele tener pocos incidentes, puede admitir más los objetivos de nivel de servicio de los que podría admitir de otra manera. Sin embargo, un mayor volumen de incidentes puede necesitar menos objetivos de nivel de servicio o un escalado de hardware y software adicional, según proceda. Le recomendamos 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 se pueden crear más objetivos de nivel de servicio. No obstante, como las condiciones varían en gran medida de una organización a otra, Microsoft no puede proporcionar una recomendación concreta para el número de objetivos de nivel de servicio que no debe exceder. Si su configuración de implementación tiene un bajo rendimiento como resultado del número de objetivos de nivel de servicio, le recomendamos que escale usando el siguiente escenario mayor de implementación, tal y como se describe en la sección Configuraciones para escenarios de implementación de esta guía.