Compartilhar via

  • Artigo

Desempenho do Service Manager

 

Publicado: julho de 2016

Aplicável a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

O desempenho para recursos e funções de servidor do System Center 2012 - Service Manager é afetado por diferentes fatores. Em geral, há três áreas em que níveis positivos e negativos de desempenho são mais perceptíveis no Service Manager:

  • Receptividade do Service Manager Console. Tempo necessário desde o momento em que uma determinada ação é executada no console até a sua conclusão.

  • Tempo de inserção de dados para conectores. O tempo necessário para o Service Manager importar dados quando um conector é sincronizado.

  • Tempo de conclusão do fluxo de trabalho. O tempo necessário para os fluxos de trabalho aplicarem automaticamente um determinado tipo de ação.

Desempenho do conector

A sincronização inicial do conector pode levar um tempo significativo; por exemplo, de 8 a 12 horas para uma sincronização inicial de grande porte com o Gerenciador de configuração do System Center. Durante a sincronização inicial de um conector, pode-se esperar uma queda do desempenho para todos os processos e funções de servidor do Service Manager em execução. Isso ocorre devido à forma como os dados são inseridos sequencialmente no banco de dados do Service Manager, que é um banco de dados SQL Server da Microsoft. Embora não seja possível apressar o processo de sincronização inicial do conector, você pode planejar essa sincronização e garantir que o processo seja concluído bem antes de o Service Manager ser colocado em produção.

Concluída a sincronização inicial, o Service Manager continuará a sincronizar as diferenças, o que não exerce um impacto significativo sobre o desempenho.

Desempenho do fluxo de trabalho

Os fluxos de trabalho são processos automáticos que ocorrem. Incluem a remessa de notificações de e-mail, o passo seguinte de uma ativação de solicitação de alteração e a aplicação automática de um modelo.

As considerações sobre desempenho de fluxo de trabalho incluem o seguinte:

  • Normalmente, os fluxos de trabalho começam e terminam em um intervalo de um minuto. Quando as funções de servidor do Service Manager se encontram em condições de intensa carga de trabalho, esses fluxos de trabalho não são concluídos com a rapidez normal.

  • Além disso, quando novos fluxos de trabalho são criados, como uma nova assinatura de notificação, uma carga adicional é colocada no sistema. Conforme o número de novos fluxos de trabalho criados aumenta, o tempo necessário para a execução de cada um também aumenta.

Quando o sistema se encontra em condições de carga intensa; por exemplo, quando um número muito grande de novos incidentes estão sendo criados e cada um gera diversos fluxos de trabalho, é possível que o desempenho fique prejudicado.

O desempenho do fluxo de trabalho em System Center 2012 - Service Manager melhorou desde System Center Service Manager 2010 porque o novo pacote de gerenciamento ManagmentHostKeepAlive aumentou a resposta do processamento do fluxo de trabalho, de modo que quase todos os fluxos de trabalho são processados em um minuto.

Impacto de grupos, filas e funções de usuário sobre o desempenho

É necessário planejar grupos e funções de usuário com antecedência. Você deve criar grupos com moderação e criá-las para o menor escopo possível. Em seguida, você deve inicialmente preencher o seu banco de dados com dados dos Serviços de domínio do Active Directory (AD DS), Gerenciador de configuração do System Center e Operations manager do System Center antes de criar os seus grupos.

Muitas vezes, os administradores criam grupos para garantir que os usuários tenham acesso apenas a grupos especificados. Por exemplo, em um cenário, é possível criar um subconjunto de incidentes, como aqueles que afetam os computadores usados pela equipe de recursos humanos. Nesse cenário, você pode preferir que apenas funcionários específicos possam ver ou modificar o grupo de servidores com conteúdo confidencial. Para permitir esse tipo de acesso, é preciso criar um grupo para todos os usuários e outro para computadores com conteúdo confidencial e, em seguida, garantir que uma função de segurança tenha acesso a ambos os grupos: Todos os Usuários e Servidores com Conteúdo Confidencial. Inevitavelmente, a criação de um grupo contendo todos os usuários resulta em um impacto no desempenho, pois o Service Manager faz verificações frequentes para determinar se existem alterações nesse grupo. Por padrão, essa verificação ocorre uma vez a cada 30 segundos. No caso de um grupo muito grande, a verificação de alterações gera uma carga muito intensa no sistema e pode aumentar consideravelmente o tempo de resposta.

Solução 1: É possível especificar manualmente a frequência com a qual o Service Manager verifica alterações de grupo, modificando uma chave do Registro. Por exemplo, se você alterar a frequência de verificação de grupos de 30 segundos para 10 minutos, aumentará o desempenho significativamente. No entanto, as filas e os objetivos de nível de serviço são tipos especiais de grupos que usam o mesmo intervalo de sondagem de cálculo de grupo. Portanto, aumentar o valor do intervalo de sondagem resultará em tempos mais prolongados para cálculos de objetivo de nível de serviço e fila.

System_CAPS_ICON_caution.jpg Cuidado


A edição incorreta do Registro pode causar danos graves ao sistema. Antes de alterar o Registro, faça backup 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 até HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

  2. Crie um novo valor DWORD denominado GroupCalcPollingIntervalMilliseconds.

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

  4. Reinicie o serviço de Gerenciamento do System Center.

    System_CAPS_ICON_note.jpg Observação


    Para o System Center 2012 R2 Service Manager, o Serviço de Gerenciamento do System Center foi renomeado como Microsoft Monitoring Agent.

Solução 2: Você pode usar um script do Windows PowerShell para adicionar objetos de um determinado tipo, como “Usuários”, a uma função de usuário. Basicamente, um analista conectado a essa função pode acessar todos os objetos cujo tipo é igual a “Usuário”. Usando esse método, não é mais necessário ter um grupo muito grande (“Todos os Usuários”) e executar a verificação exorbitante feita pelo Service Manager para determinar a associação desse grupo. No servidor de gerenciamento do Service Manager, é possível executar o seguinte script do Windows PowerShell para adicionar um tipo “user” a uma função “RoleName”. Você precisará modificar esse exemplo de script de acordo com o seu ambiente.

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

  • Modifique o script a seguir 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 dos modos de exibição

Ao criar modos de exibição, planeje o uso de classes “típicas” no sistema sempre que possível. A maioria das classes de objetos, por exemplo, Gerenciamento de Incidentes, possui 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 a um item. O tipo de objeto avançado contém muitas referências complexas a dados relacionados a um item. Tipos típicos são projeções simples, enquanto tipos avançados são projeções complexas. A maioria dos tipos de objetos avançados é usada para popular diferentes campos em formulários que normalmente você não deseja exibir em um modo de exibição. Sempre que um modo de exibição baseado em um tipo de objeto avançado é criado e quando esse modo de exibição é aberto, o Service Manager consulta o banco de dados, e uma grande quantidade de dados é lida. No entanto, uma parte muito pequena dos dados recuperados chega a ser exibida ou utilizada.

Em caso de problemas de desempenho com modos de exibição definidos e se você tiver utilizado tipos de objetos avançados nesses modos de exibição, convém passar a usar tipos típicos. Como alternativa, você pode criar seus próprios tipos de projeções contendo somente os dados que precisam ser usados como base para um modo de exibição. Para mais informações, consulte a Criação de visualizações que utilizam critérios de propriedade relacionados (Projeções de tipo): Postagem em blogue com exemplos de visualizações de software postagem no blogue no Blogue da equipe de engenharia de SCSM.

Desempenho do banco de dados do Service Manager

O desempenho do banco de dados do Service Manager é diretamente afetado por vários fatores, incluindo o número de unidades simultâneas do Service Manager Console realizando operações de leitura ou gravação de dados, o intervalo de verificação de alterações de grupo e os dados inseridos pelos conectores. Mais informações estão disponíveis neste documento. Estes são alguns pontos básicos:

  • Você deve ter um mínimo de 8 GB de RAM para o servidor de gerenciamento que hospeda o banco de dados do Service Manager para ter um tempo de resposta aceitável em cenários típicos.

  • É necessário ter pelo menos 8 processadores de CPU no computador que hospeda o banco de dados do Service Manager.

  • Você pode alcançar níveis melhores de desempenho do banco de dados segregando arquivos de log e arquivos de dados em discos físicos separados, se possível. Benefícios ainda maiores são possíveis movendo o tempdb em uma unidade RAID física diferente daquela do banco de dados do Service Manager. Use um sistema de discos RAID 1+0 para hospedar o Service Manager banco de dados, se possível.

  • O desempenho poderá piorar significativamente se o banco de dados do Service Manager for criado com um tamanho melhor e definido para crescimento automático especialmente em pequenos incrementos.

Consulte a Service Manager ferramenta de dimensionamento auxiliar que vem incluída no conjunto de documentação dos recursos de trabalho do Service manager . (SM_job_aids.zip) para ajudar a avaliar o tamanho do banco de dados e criar o banco de dados com um tamanho que seja mais próximo do tamanho final. Isso ajudará o desempenho, reduzindo a quantidade de vezes que o banco de dados tem de crescimento automático.

Da mesma forma, todas as outras práticas recomendadas para um banco de dados de alto desempenho são aplicáveis, também. Por exemplo, se fosse possível tirar proveito de um subsistema de disco superior, você poderia se beneficiar com a divisão dos grupos de tabelas em respectivos grupos de arquivos e da sua transferência a unidades físicas diferentes.

Desempenho do servidor de gerenciamento do Service Manager

Desempenho do servidor de gerenciamento do Service Manager é afetado principalmente pelo número de Service Manager Consoles ativas simultâneas. Como todas as funções do Service Manager interagem com o servidor de gerenciamento, convém levar em consideração a inclusão de servidores de gerenciamento adicionais se você planeja ter vários consoles simultâneos. Você deve ter 8 GB de RAM para o servidor de gerenciamento. Você deve ter pelo menos 4 núcleos de CPU por servidor de gerenciamento, supondo-se que tenha de 10 a 12 consoles ativos por núcleo de CPU.

Desempenho do console do Service Manager

O desempenho do Service Manager Console é afetado principalmente pelo número de formulários que os analistas costumam manter abertos e pela quantidade de dados que é recuperada por modos de exibição. É necessário ter 4 GB de RAM no computador onde o Service Manager Console está instalado. Se você tiver modos de exibição que recuperam muitos dados, será necessário usar RAM adicional. Você deve ter pelo menos uma CPU quad-core para o computador no qual o Service Manager Console está instalado. Uma vez que o Service Manager Console é um aplicativo para o usuário final, recomendamos que você o reinicie se houver consumo excessivo de recursos. O Service Manager Consolearmazena agressivamente informações na memória, o que pode contribuir para o uso de memória geral.

Desempenho dos bancos de dados do data warehouse do Service Manager

O desempenho do data warehouse é diretamente afetado por vários fatores, incluindo o número de servidores de gerenciamento do Service Manager simultâneos que enviam dados, o volume de dados armazenados ou o período de retenção desses dados, além da taxa de alteração de dados e da frequência de ETL (extração, transformação e carga). A quantidade de dados armazenados no data warehouse aumenta com o passar do tempo. É muito importante garantir o arquivamento dos dados desnecessários. Outro fator que afeta o desempenho do data warehouse é a configuração BatchSize (tamanho do lote) dos processos ETL.

Você pode alcançar níveis melhores de desempenho segregando arquivos de log e arquivos de dados em discos físicos separados. No entanto, você deve evitar colocar mais de um arquivo de log por disco. De maneira semelhante, é possível alcançar níveis melhores de taxa de transferência colocando tempdb em um disco físico diferente dos outros bancos de dados. Por fim, você também pode se beneficiar colocando os bancos de dados diferentes em seus respectivos discos físicos. Use um sistema de discos RAID 1+0 para hospedar o data warehouse, se possível. Você deve ter, em geral, um mínimo de 8 GB de RAM para o computador onde os bancos de dados do data warehouse estão instalados. Se tiver fontes adicionais de dados de data warehouse do Operations manager ou do Gerenciador de configuração, você deverá aumentar a quantidade de RAM para os bancos de dados. Você irá se beneficiar de mais memória no computador executando o SQL Server que hospeda o data warehouse e ainda mais se os bancos de dados Datamart e Repository estiverem no mesmo servidor. Porém, para 4.000 ou menos computadores na topologia da sua implantação, 4 GB são suficientes. É necessário ter pelo menos 8 processadores de CPU no computador em que o banco de dados do data warehouse está instalado. Processadores adicionais contribuirão com o desempenho de relatórios e ETL.

O desempenho poderá piorar significativamente se todos os bancos de dados no sistema forem criados com um tamanho menor e definidos para crescimento automático, especialmente em pequenos incrementos. Consulte a ferramenta Service Manager de dimensionamento auxiliar que é incluída no conjunto de documentação dos recursos de trabalho do Service manager (SM_job_aids.zip) para avaliar o tamanho do banco de dados e criar um banco de dados com um tamanho que seja mais próximo do tamanho final, o que ajudará no desempenho, ao reduzir a quantidade de vezes que o banco de dados tem que crescer automaticamente.

O Service Manager inclui suporte interno para grupos de arquivos. Você pode aproveitar isso colocando os grupos de arquivos em discos rígidos separados.Para obter mais informações sobre práticas recomendadas do grupo de arquivos, consulte a documentação do SQL Server.

Desempenho do servidor de data warehouse do Service Manager

O desempenho do servidor do data warehouse é afetado pelo número de servidores de gerenciamento do Service Manager registrados no data warehouse, pelo tamanho da sua implantação e a quantidade das fontes de dados. Geralmente, é necessário ter um mínimo de 8 GB de RAM para o servidor do data warehouse. No entanto, o desempenho irá se beneficiar de memória adicional para os cenários de implantação avançada, onde mais de um Service Manager servidor de gerenciamento insere dados no data warehouse. Caso seja necessário sacrificar o desempenho, sua maior prioridade deve ser a memória do computador que executa o SQL Server. É necessário ter pelo menos 8 processadores de CPU para evitar problemas de desempenho.

Desempenho do portal de autoatendimento

O Portal de autoatendimento foi projetado para fácil acesso ao arquivamento de incidentes e de solicitação de serviço. Ele não foi projetado para lidar com milhares de usuários simultaneamente.

O teste de desempenho para o Portal de autoatendimento enfocou os cenários típicos de "segunda-feira de manhã", especialmente para assegurar que na segunda-feira de manhã centenas de usuários possam fazer logon em 5 a 10 minutos e abrir incidentes com tempos de resposta aceitáveis (menos de 4 a 5 segundos). Essa meta foi alcançada com o hardware mínimo recomendado neste documento.

Desempenho de objetivo de nível de serviço

Existe um número específico de objetivos de nível de serviço que Service Managersuporta. Por exemplo, se uma organização tipicamente tem poucos incidentes, ela pode suportar mais objetivos de nível de serviço do que seria capaz em caso contrário. No entanto, um volume maior de incidentes pode necessitar de menos objetivos de nível de serviço ou então um excedente de hardware e software adicionais, conforme for adequado. Recomendamos que você não crie mais do que cinco objetivos de nível de serviço para uma configuração típica de computador de 50.000Service Manager. Possivelmente, você poderia criar mais objetivos de nível de serviço. No entanto, uma vez que as condições variam muito de organização para organização, a Microsoft não pode fornecer uma recomendação concreta sobre a quantidade de objetivos de nível de serviço que você não deve exceder. Se a sua configuração de implantação tiver um desempenho insatisfatório como resultado da quantidade de objetivos de nível de serviço, recomendamos que você aumente a escala utilizando o cenário de implantação maior, conforme descrito na Configurações para a implantação de cenários seção deste guia.