System Center – Desempenho do Service Manager

Artigo
07/10/2024

O desempenho das funções e recursos do servidor System Center – Service Manager é afetado por diferentes fatores. Geralmente, há três áreas em que o desempenho positivo e negativo é mais perceptível no Service Manager:

Capacidade de resposta do console do Service Manager. 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. Esse é o tempo que leva 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, 8 a 12 horas para uma grande sincronização inicial com Configuration Manager. À medida que um conector é sincronizado inicialmente, você pode esperar que o desempenho seja prejudicado para todas as funções e processos de servidor do Service Manager durante esse período. Isso ocorre devido à maneira como os dados são inseridos sequencialmente no banco de dados do Service Manager, que é um banco de dados do Microsoft SQL Server. Embora você não possa acelerar o processo de sincronização inicial do conector, você pode planejar a sincronização inicial e garantir que o processo de sincronização seja concluído bem antes de Service Manager ser colocado em produção.

Quando a sincronização inicial é concluída, Service Manager continua sincronizando as diferenças, que não têm um impacto mensurável no 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 estão sob uma carga de trabalho pesada, os fluxos de trabalho não são concluídos tão rapidamente quanto o 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.

Impacto da função de grupo, fila e usuário no 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 preencher inicialmente seu banco de dados com dados do AD DS (Active Directory Domain Services), Configuration Manager e System Center Operations Manager antes de criar 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 impacto no desempenho porque Service Manager frequentemente verifica se há alterações no grupo. Por padrão, essa verificação ocorre uma vez a cada 30 segundos. Para um grupo grande, a verificação das alterações cria uma carga pesada no sistema e pode diminuir consideravelmente o tempo de resposta.

Solução 1: você pode especificar manualmente a frequência com que Service Manager verifica se há 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 resulta em tempos mais longos para cálculos de objetivos de fila e nível de serviço.

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

Execute o Regedit e navegue até HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.
Crie um novo valor DWORD denominado GroupCalcPollingIntervalMilliseconds.
Para esse valor, especifique o intervalo em milissegundos. O resultado é multiplicado por 6. Por exemplo, para definir o intervalo como 10 minutos, insira 600000.
Reinicie o serviço de Gerenciamento do System Center.

Solução 2: Você pode usar um script do Windows PowerShell para adicionar objetos de um tipo, como "Usuários", a uma função de usuário. Essencialmente, um analista conectado a essa função pode acessar todos os objetos que têm um tipo igual a "Usuário". Se você usar esse método, eliminará a necessidade de um grupo grande ("Todos os Usuários") e a verificação cara que o Service Manager executa para determinar essa associação ao grupo. No servidor de gerenciamento do Service Manager, você pode executar o seguinte script do Windows PowerShell para adicionar o tipo "usuário" a uma função "RoleName". Você precisa modificar este script de exemplo para 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."  
}

Exibir desempenho

Ao criar exibições, planeje usar classes "típicas" no sistema sempre que possível. A maioria das classes de objetos, por exemplo, Gerenciamento 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 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 objeto avançados é usada para preencher campos diferentes em formulários que você normalmente não gostaria de ver exibidos em um modo de exibição. Sempre que você cria uma exibição com base em um tipo de objeto avançado e quando abre a exibição, Service Manager consulta o banco de dados e uma grande quantidade de dados é lida. No entanto, muito poucos dados recuperados são exibidos ou usados.

Se você encontrar problemas de desempenho com as exibições definidas ao usar tipos de objeto avançados em exibições, alterne para o uso de tipos típicos. Como alternativa, você pode criar seus próprios tipos de projeção que contenham apenas os dados necessários para basear uma exibição.

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 consoles simultâneos do Service Manager que estão lendo ou gravando dados, o intervalo de verificação de alteração 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 gigabytes (GB) de RAM para o servidor de gerenciamento que hospeda o banco de dados do Service Manager para que você possa ter um tempo de resposta aceitável em cenários típicos.
Você deve ter pelo menos 8 núcleos de CPU no computador que hospeda o banco de dados 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. Você pode obter mais benefícios movendo seu tempdb para uma unidade RAID física diferente daquela do banco de dados Service Manager. Use um sistema de disco RAID 1+0 para hospedar seu banco de dados do Service Manager, se possível.
O desempenho pode ser afetado negativamente se o banco de dados do Service Manager for criado com um tamanho menor e estiver definido para crescer automaticamente, especialmente por pequenos incrementos.

Consulte a ferramenta Service Manager Sizing Helper incluída no conjunto de documentação de auxiliares de trabalho do Service Manager (SM_job_aids.zip) para obter ajuda com a avaliação do tamanho do banco de dados e crie o banco de dados com um tamanho mais próximo do tamanho final. Isso ajudará no desempenho, reduzindo o número de vezes que o banco de dados precisa crescer automaticamente.

Da mesma forma, todas as outras práticas recomendadas para um banco de dados de alto desempenho também são aplicáveis. Por exemplo, se você puder aproveitar um subsistema de disco superior, poderá se beneficiar da divisão dos grupos de tabelas nos respectivos grupos de arquivos e movê-los para uma unidade física diferente.

Desempenho do servidor de gerenciamento do Service Manager

O desempenho do servidor de gerenciamento do Service Manager é afetado principalmente pelo número de consoles Service Manager simultâneos ativos. Como todas as funções do Service Manager interagem com o servidor de gerenciamento, considere adicionar servidores de gerenciamento adicionais se você planeja ter um grande número de 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 que você tenha de 10 a 12 consoles ativos por núcleo de CPU.

Desempenho do console do Service Manager

O desempenho do console do Service Manager é afetado principalmente pelo número de formulários que seus analistas normalmente têm abertos e pela quantidade de dados recuperados por exibições. Você deve ter 4 GB de RAM no computador em que o console do Service Manager está instalado. Se você tiver visualizações que recuperam uma grande quantidade de dados, precisará de RAM adicional. Você deve ter pelo menos uma CPU de 4 núcleos para o computador em que o console do Service Manager está instalado. Como o console do Service Manager é um aplicativo de usuário final, recomendamos que você o reinicie se vir um consumo excessivo de recursos. O console do Service Manager armazena agressivamente em cache as informações na memória, o que pode contribuir para o uso geral da memória.

Desempenho do banco 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 simultâneos do Service Manager 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 de ETL (extração, transformação e carregamento). 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 você tiver fontes de dados de data warehouse adicionais do Operations Manager ou Configuration Manager, 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. No entanto, se você tiver 4.000 ou menos computadores em sua topologia de implantação, 4 GB serã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 Auxiliar de Dimensionamento do Service Manager incluída no conjunto de documentação de auxílios de trabalho do Service Manager (SM_job_aids.zip) para avaliar o tamanho do banco de dados e criar o banco de dados com um tamanho mais próximo do tamanho final, o que ajudará no desempenho reduzindo o número de vezes que o banco de dados precisa crescer automaticamente.

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 as práticas recomendadas de grupo de arquivos, consulte a documentação do SQL Server.

Desempenho do servidor de data warehouse do Service Manager

O desempenho do servidor de data warehouse é afetado pelo número de servidores de gerenciamento do Service Manager registrados no data warehouse, pelo tamanho da implantação e pelo número de 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 se beneficiará por ter memória adicional para cenários de implantação avançada em que mais de um servidor de gerenciamento do Service Manager 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 facilitar o acesso ao arquivamento de incidentes e solicitações 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 foi focado em cenários típicos de "segunda-feira de manhã", especificamente, para garantir que, na segunda-feira de manhã, centenas de usuários possam entrar em um período de 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 do objetivo de nível de serviço

Não há um número específico de objetivos de nível de serviço compatíveis com o Service Manager. 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 de cinco objetivos de nível de serviço para uma configuração típica do Service Manager de 50.000 computadores. Possivelmente, você poderia criar mais objetivos de nível de serviço. No entanto, como as condições variam muito de organização para organização, a Microsoft não pode fornecer uma recomendação concreta para o número de objetivos de nível de serviço que você não deve exceder. Se sua configuração de implantação sofrer de baixo desempenho como resultado do número de objetivos de nível de serviço, recomendamos que você escale horizontalmente usando o próximo cenário de implantação maior, conforme descrito no artigo Configurações para cenários de implantação deste guia.

Próximas etapas

Para saber mais sobre configurações de hardware e software para cenários de implantação do Service Manager, examine Cenários de topologia de implantação recomendados.

Compartilhar via