Partilhar via

  • Artigo

Desempenho do Service Manager

 

Publicado: julho de 2016

Aplica-se A: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

O desempenho das funções e funcionalidades do servidor do System Center 2012 – Service Manager é afetado por fatores diferentes. Geralmente, existem três áreas em que o desempenho positivo ou negativo é mais evidente no Service Manager:

  • Capacidade de resposta da Service Manager console. É o período de tempo decorrido entre a execução e a conclusão de uma ação na consola.

  • Tempo de inserção de dados para os conectores. É o tempo que o Service Manager demora a importar dados durante a sincronização de um conector.

  • Tempo de conclusão do fluxo de trabalho. É o tempo que os fluxos de trabalho demoram a aplicar automaticamente qualquer tipo de ação.

Desempenho do Conector

A sincronização inicial de um conector pode ser muito demorada (por exemplo, 8 a 12 horas para uma grande sincronização inicial com o System Center Configuration Manager). Durante a sincronização inicial de um conector é expetável que o desempenho de todas as funções e processos do servidor do Service Manager seja afetado. Esta situação acontece devido ao modo como os dados são introduzidos sequencialmente na base de dados do Service Manager, que é uma base de dados do Microsoft SQL Server. Embora não seja possível acelerar o processo de sincronização inicial do conector, é possível planear a sincronização inicial de modo a garantir que o processo de sincronização seja concluído corretamente muito antes de colocar o Service Manager em produção.

Quando a sincronização inicial estiver concluída, o Service Manager continua a sincronizar as diferenças, mas esta operação não tem um impacto significativo no desempenho.

Desempenho do Fluxo de Trabalho

Os fluxos de trabalho são processos automáticos que se produzem. Eles incluem o envio de notificações por correio eletrónico, o passo seguinte na ativação de um pedido de alteração e a aplicação automática de um modelo.

Entre as considerações sobre o desempenho do fluxo de trabalho incluem-se as seguintes:

  • Normalmente, os fluxos de trabalho começam e terminam num minuto. Quando as funções do servidor do Service Manager estão sujeitas a uma pesada carga de trabalho, os fluxos de trabalho demoram mais tempo a ser concluídos.

  • Além disso, quando se criam novos fluxos de trabalho (tais como uma nova subscrição de notificação), adiciona-se mais carga ao sistema. À medida que o número de novos fluxos de trabalho criados aumenta, o tempo de execução de cada fluxo de trabalho também aumenta.

Quando o sistema estiver em sobrecarga, se por exemplo for criado um grande número de novos incidentes e cada incidente gerar muitos fluxos de trabalho, então o desempenho pode ser afetado negativamente.

O desempenho do fluxo de trabalho no System Center 2012 – Service Manager melhorou em relação ao System Center Service Manager 2010 porque o novo pacote de gestão ManagmentHostKeepAlive aumentou a capacidade de resposta de processamento de fluxos de trabalho de modo a que quase todos os fluxos de trabalho sejam processados num minuto.

Impacto dos Grupos, Filas e Funções de Utilizador no Desempenho

Os grupos e as funções de utilizador devem ser planeados com antecedência. Os grupos devem ser criados com moderação e de modo a terem o menor âmbito possível. Em seguida, deve-se começar a preencher a base de dados com dados de Serviços de Domínio do Active Directory (AD DS), do System Center Configuration Manager e do System Center Operations Manager antes de se criar os grupos.

Os administradores criam muitas vezes grupos para se certificarem de que os utilizadores apenas têm acesso a grupos especificados. Por exemplo, num cenário poderá pretender criar um subconjunto de incidentes como aqueles que afetam os computadores que são utilizados pelo pessoal de recursos humanos. Neste cenário, poderá pretender que o grupo de Servidores Sensíveis apenas possa ser visto ou modificado por pessoal específico. Assim, para ativar este tipo de acesso, seria necessário criar um grupo para todos os utilizadores e um grupo para computadores sensíveis e, em seguida, certificar-se de que uma função de segurança tenha acesso aos grupos Todos os Utilizadores e Servidores Sensíveis. Inevitavelmente, a criação de um grupo que contenha todos os utilizadores afeta o desempenho porque o Service Manager efetua uma verificação frequente para determinar se o grupo sofreu alterações. Por predefinição, esta verificação acontece a cada 30 segundos. Se o grupo for muito grande, a verificação das alterações sobrecarrega o sistema e pode reduzir consideravelmente o tempo de resposta.

Solução 1: é possível especificar manualmente com que frequência o Service Manager deve verificar se os grupos sofreram alterações, modificando uma chave de registo. Por exemplo, se a frequência de verificação de grupos for alterada de 30 segundos para 10 minutos, o desempenho melhora significativamente. No entanto, os objetivos de nível de serviço e de filas são tipos de grupos especiais que utilizam o mesmo intervalo de consulta de cálculo de grupo. Aumentar o valor de um intervalo de consulta resultará em tempos mais longos de cálculos do objetivo de nível de serviço e de fila.

System_CAPS_ICON_caution.jpg Atenção


A edição incorreta do registo poderá danificar gravemente o sistema. Antes de efetuar alterações no registo, crie uma cópia de segurança de todos os dados importantes do computador.

Para especificar manualmente o intervalo de verificação de alterações em grupos

  1. Execute Regedit e navegue para HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

  2. Crie um novo valor DWORD chamado GroupCalcPollingIntervalMilliseconds.

  3. Para definir esse valor, especifique o intervalo em milésimos de segundo. O resultado é multiplicado por 6. Por exemplo, para definir o intervalo para 10 minutos, escreva 600000.

  4. Reinicie o serviço de Gestão do System Center.

    Nota


    Para o System Center 2012 R2 Service Manager, o nome do Serviço de Gestão do System Center foi mudado para Microsoft Monitoring Agent.

Solução 2: é possível utilizar um script do Windows PowerShell para adicionar objetos de um tipo como, por exemplo, “Utilizadores”, a uma função de utilizador. Essencialmente, um analista que tenha iniciado sessão com esta função pode aceder a todos os objetos do mesmo tipo que “Utilizador”. Se utilizar este método, elimina a necessidade de utilização de um grupo muito grande (“Todos os Utilizadores”) e da verificação custosa efetuada pelo Service Manager para determinar a associação a este grupo. No servidor de gestão do Service Manager, pode executar o seguinte script do Windows PowerShell para adicionar o tipo “utilizador” a uma função “RoleName”. Será necessário modificar este script de exemplo para adaptá-lo ao seu ambiente.

Para executar um script do Windows PowerShell de modo a adicionar objetos a uma função de utilizador

  • Modifique o seguinte script conforme necessário e, em seguida, execute-o:
# 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."  
}

Desempenho das Vistas

Ao criar vistas, deve procurar utilizar classes “típicas” no sistema sempre que for possível. A maioria das classes de objetos (por exemplo, Gestão de Incidentes) tem dois tipos: “típico” e “avançado”. O tipo de objeto típico contém referências simples a um pequeno subconjunto de dados relacionados com um item. O tipo avançado contém várias referências complexas a dados relacionados com um item. Os tipos típicos são projeções simples e os tipos avançados são projeções complexas. A maioria dos tipos de objetos avançados é utilizada para preencher diferentes campos em formulários que normalmente não gostaria que fossem apresentados numa vista. Sempre que se cria uma vista baseada num tipo de objeto avançado e se abre a vista, o Service Manager consulta a base de dados e é lida uma grande quantidade de dados. No entanto, na realidade, apenas uma parte muito pequena dos dados obtidos é visualizada ou utilizada.

Se tiver problemas de desempenho com as vistas definidas quando utilizar tipos de objetos avançados em vistas, experimente utilizar tipos típicos. Ou então pode criar os seus próprios tipos de projeção apenas com os dados que são necessários para uma determinada vista. Para obter mais informações, consulte a mensagem de blogue Creating Views That Use Related Property Criteria (Type Projections): Software Views Example (Criar Vistas que Utilizam Critérios de Propriedade Relacionados (Projeções de Tipo): Exemplo de Vistas de Software) no Blogue da Equipa Técnica do SCSM.

Desempenho da Base de Dados do Service Manager

O desempenho da base de dados do Service Manager depende diretamente de vários fatores, incluindo o número de Service Manager console simultâneas que estão a efetuar a leitura ou escrita de dados, o intervalo de verificação de alterações em grupos e os dados inseridos por conectores. Este documento inclui mais informações. Eis alguns pontos chave:

  • É necessário ter um mínimo de 8 gigabytes (GB) de RAM para o servidor de gestão que aloja a base de dados do Service Manager de modo a obter um tempo de resposta aceitável em cenários típicos.

  • É necessário ter pelo menos 8 núcleos de CPU no computador que aloja a base de dados do Service Manager.

  • É possível melhorar o desempenho da base de dados mantendo os ficheiros de registo separados dos ficheiros de dados em discos físicos diferentes, se possível. É possível tirar ainda mais benefícios movendo a tempdb para uma unidade RAID física diferente da utilizada na base de dados do Service Manager. Utilize um sistema de disco RAID 1+0 para alojar a base de dados do Service Manager, se possível.

  • O desempenho pode ser afetado negativamente se a base de dados do Service Manager for criada com uma dimensão mais pequena e definida para a opção AutoGrow, especialmente se for por pequenos incrementos.

Consulte a Ferramenta Auxiliar de Dimensionamento do Service Manager incluída no conjunto de documentação de utilitários de tarefas do Service Manager (SM_job_aids.zip) para ajudar a avaliar o tamanho da base de dados e criar a base de dados com um tamanho próximo ao tamanho final. Isto ajuda a melhorar o desempenho graças à redução do número de vezes que a base de dados deverá crescer automaticamente.

Da mesma forma, também são aplicáveis todos os outros procedimentos recomendados para uma base de dados de elevado desempenho. Por exemplo, para tirar partido de um subsistema de disco superior seria vantajoso dividir os grupos de tabelas nos respetivos grupos de ficheiros e movê-los para unidades físicas diferentes.

Desempenho do Servidor de Gestão do Service Manager

O desempenho do servidor de gestão do Service Manager depende principalmente do número de Service Manager console simultâneas ativas. Uma vez que todas as funções do Service Manager interagem com o servidor de gestão, deve-se considerar a possibilidade de adicionar mais servidores de gestão se estiver previsto um grande número de consolas simultâneas. É necessário ter 8 GB de RAM para o servidor de gestão. É necessário ter pelo menos 4 núcleos de CPU por servidor de gestão, partindo do princípio que tem 10 a 12 consolas ativas por núcleo de CPU.

Desempenho da Consola do Service Manager

O desempenho da Service Manager console depende principalmente do número de formulários que os analistas têm normalmente abertos e da quantidade de dados obtida pelas vistas. É necessário ter 4 GB de RAM no computador em que a Service Manager console está instalada. Se tiver vistas que obtêm uma grande quantidade de dados, necessitará de mais RAM. É necessário ter pelo menos 4 núcleos de CPU no computador em que a Service Manager console está instalada. Como a Service Manager console é uma aplicação para utilizador final, é recomendável reiniciá-la se se notar um consumo excessivo de recursos. A Service Manager console armazena grandes quantidades de informações na memória cache, o que pode contribuir para a utilização total de memória.

Desempenho da Base de Dados do Armazém de Dados do Service Manager

O desempenho do armazém de dados depende diretamente de vários fatores, incluindo o número de servidores do Service Manager simultâneos que enviam dados, o volume de dados armazenados ou o período de retenção de dados, a taxa de alteração de dados e a frequência ETL (extração, transformação e carregamento). A quantidade de dados armazenados no armazém de dados aumenta com o passar do tempo. É importante garantir que não se arquivam dados desnecessários. Outro fator que afeta o desempenho do armazém de dados é a definição BatchSize dos processos de ETL.

É possível melhorar o desempenho mantendo os ficheiros de registo separados dos ficheiros de dados em discos físicos diferentes. No entanto, não se deve colocar mais do que um registo de ficheiro por disco. Da mesma forma, é possível melhorar o débito colocando a tempdb num disco físico diferente daquele onde se encontram as outras bases de dados. Por último, também pode ser vantajoso colocar as diferentes bases de dados nos respetivos discos físicos. Utilize um sistema de disco RAID 1+0 para alojar o armazém de dados, se possível. Geralmente, é necessário ter um mínimo de 8 GB de RAM no computador em que as bases de dados do armazém de dados estão instaladas. Se existirem origens de dados adicionais no armazém de dados do Operations Manager ou do Configuration Manager, deve aumentar a quantidade de RAM para as bases de dados. Será vantajoso contar com mais memória no computador que executa o SQL Server que aloja o armazém de dados, ainda mais se as bases de dados do Data mart e do Repositório estiverem no mesmo servidor. No entanto, se existirem 4000 computadores ou menos na topologia de implementação, 4 GB são suficientes. É necessário ter pelo menos 8 núcleos de CPU no computador em que a base de dados do armazém de dados está instalada. A existência de núcleos adicionais melhorará o desempenho de ETL e dos relatórios.

O desempenho pode ser afetado negativamente se todas as bases de dados no sistema forem criadas com uma dimensão mais pequena e definidas para a opção AutoGrow, especialmente se for por pequenos incrementos. Consulte a Ferramenta Auxiliar de Dimensionamento do Service Manager incluída no conjunto de documentação de utilitários de tarefas do Service Manager (SM_job_aids.zip) para avaliar o tamanho da base de dados e criar a base de dados com um tamanho próximo ao tamanho final, que ajudará o desempenho ao reduzir o número de vezes que a base de dados tem de aumentar automaticamente.

O Service Manager inclui suporte integrado para grupos de ficheiros. É possível tirar partido desta situação colocando os grupos de ficheiros em discos rígidos separados. Para mais informações acerca do procedimentos recomendados para grupos de ficheiros, consulte a documentação do SQL Server.

Desempenho do Servidor do Armazém de Dados do Service Manager

O desempenho do servidor do armazém de dados depende do número de servidores de gestão do Service Manager registados no armazém de dados, do tamanho da implementação e do número de origens de dados. Geralmente, é necessário ter um mínimo de 8 GB de RAM para o servidor do armazém de dados. No entanto, é possível melhorar o desempenho se se contar com mais memória para cenários de implementação avançados em que vários servidores de gestão do Service Manager inserem dados no armazém de dados. Se o desempenho tiver de ser comprometido, a prioridade máxima deve ser a memória do computador que executa o SQL Server. É necessário ter pelo menos 8 núcleos de CPU para evitar problemas de desempenho.

Desempenho do Portal Self-Service

O Portal Self-Service for concebido para facilitar o acesso ao arquivo de incidentes e pedidos de serviços. Não foi concebido para processar milhares de utilizadores simultaneamente.

Os testes de desempenho do Portal Self-Service focaram-se em cenários típicos de “segunda-feira de manhã” — especificamente, de modo a assegurar que nas segundas-feiras de manhã centenas de utilizadores podem iniciar sessão num período de 5 a 10 e abrir incidentes com tempos de resposta aceitáveis (inferiores a 4-5 segundos). O objetivo foi atingido com o hardware mínimo recomendado neste documento.

Desempenho do Objetivo do Nível de Serviço

Não existe um número específico de objetivos do nível de serviço que o Service Manager suporta. Por exemplo, se uma organização tiver normalmente poucos incidentes, poderá suportar mais objetivos do nível de serviço do que seria capaz de outro modo. Contudo, um volume maior de incidentes pode necessitar de menos objetivos do nível de serviço ou de uma ampliação de hardware e software adicionais, conforme adequado. Recomendamos que não crie mais de cinco objetivos do nível de serviço para uma configuração típica do Service Manager com 50.000 computadores. É possível que possa criar mais objetivos do nível de serviço. No entanto, uma vez que as condições variam significativamente de uma organização para outra, a Microsoft não pode fornecer uma recomendação concreta sobre o número de objetivos do nível de serviço que não devem ser excedidos. Se a configuração da implementação apresentar desempenho insuficiente como resultado do número de objetivos do nível de serviço, recomendamos a respetiva ampliação, utilizando o cenário de implementação maior seguinte, como descrito na secção Configurações para Cenários de Implementação deste guia.