Desempenho e dimensionamento do banco de dados

Artigo
07/18/2023

Importante

Esta versão do Orchestrator chegou ao fim do suporte. Recomendamos que você atualize para o Orchestrator 2022.

O dimensionamento do banco de dados é a chave para entender o desempenho do System Center – Orchestrator. Os servidores Runbook, o servidor de management e os componentes Web dependem do banco de dados Orchestrator para suas operações. Problemas com implantações do Orchestrator podem surgir de uma compreensão incompleta dos tipos de dados no banco de dados e de como gerenciá-los.

Como o Runbook Designer se comunica com o banco de dados Orchestrator (pelo servidor de management), um desempenho ruim do banco de dados impedirá essa comunicação.

A experiência do operador Orchestrator baseia-se em dois componentes: o Console de Orquestração e o Serviço Web. O Orchestration Console é um aplicativo baseado em Silverlight que depende do Serviço da Web para conectar-se ao banco de dados Orchestrator. O Serviço da Web é um aplicativo IIS que se conecta ao banco de dados. Portanto, o Serviço Web e o Console de Orquestração dependem do desempenho do banco de dados do Orchestrator.

Além disso, embora o Orchestration Console seja dependente do Serviço da Web, ele também tem lógica exclusiva para sua função como interface de usuário e características próprias de desempenho.

Dados de configuração e dados de log

Em um alto nível, o banco de dados orchestrator contém dois tipos de dados:

Dados de configuração

A infraestrutura do Orchestrator contém dados de configuração. Esses dados não são uma preocupação no contexto de crescimento do banco de dados porque os requisitos de armazenamento para esse tipo de dados são pequenos.

Dados de log

O Orchestrator cria diferentes tipos de dados de log, que podem ser exibidos e gerenciados no runbook Designer. Os requisitos de armazenamento para esses dados podem variar de tamanho e podem ser grandes.

A tabela a seguir lista os tipos de dados de log que podem ser armazenados no banco de dados Orchestrator. O Orchestrator também armazena dados em arquivos de log separados (fora do banco de dados) para trilhas de auditoria e rastreamento. Para obter mais informações sobre todos os tipos de dados de log, consulte Orchestrator Logs.

Tipo de dados de log	Local no Runbook Designer	Gerenciado pela Limpeza de Log?
Logs de runbook	GuiasLog e Histórico de Log	Yes
Eventos de atividade (plataforma)	GuiaEventos	No
Histórico de auditoria	GuiaHistórico de Auditoria	No

Código de plataforma e código de domínio

As atividades de runbook do Orchestrator contêm dois tipos distintos de código:

Código de plataforma

Esse é o código comum compartilhado pela maioria das atividades e é usado para executar tarefas comuns executadas pelas atividades do Orchestrator. Código de plataforma gera Dados Publicados Comuns.
Código de domínio

Executa várias tarefas específicas para as ações de cada atividade, que normalmente não estão associadas à plataforma do Orchestrator em si. Potencialmente, pode haver uma grande variação entre código de plataforma e código de domínio.

Os dados de log gerados por uma determinada atividade podem conter elementos de dados com valor único ou múltiplos valores. Cada atividade produz um único registro de dados de valor único. O código de domínio pode produzir registros múltiplos de dados com múltiplos valores, e portanto é responsável por determinar o que a atividade faz com os dados publicados comuns recebidos de atividades anteriores.

Essencialmente, runbooks do Orchestrator são projetados para passar dados entre elementos distintos do código de domínio. Além disso, o código de domínio pode opcionalmente gerar Dados Publicados Específicos da Atividade.

Todos os runbooks têm semelhanças básicas, já que executam atividades que consistem em código de domínio e código de plataforma, executam fluxos de trabalho em loop e se ramificam. A ramificação ocorre quando um runbook chama outros runbooks para realizar uma tarefa específica. Quando um runbook é invocado pela primeira vez, ele consiste em um único thread. Quando esse thread encontra uma atividade de runbook cujos links exigem uma ramificação, threads adicionais são criados, um para cada ramificação. Cada thread aceita como entrada os dados publicados comuns da atividade que criou a ramificação. Esses dados estão correlacionados às atividades anteriores no runbook para atualizar os dados publicados comuns assinados pelas atividades.

O código de domínio tem mais potencial para afetar o desempenho do banco de dados do que o multithreading gerado pela ramificação. Isso ocorre porque o código de domínio potencialmente pode gerar grandes quantidades de dados publicados específicos da atividade.

Opções de log

A guia Log nas Propriedades de um runbook permite opcionalmente armazenar entradas de log. O termo log padrão se refere a não ter nenhuma das duas opções de dados publicados selecionada, o que gera 524 bytes para cada atividade. As opções de log oferecem duas categorias de dados publicados comuns:

Dados publicados comuns

O conjunto de itens de dados comuns a todas as atividades. Para obter uma lista, consulte As Opções de Log do Runbook.

Essa opção de log gera 6082 bytes para cada atividade.
Dados Publicados Específicos da Atividade

O conjunto de dados que são específicos para a atividade, opcionalmente criados pelo código de domínio.

Essa opção de log gera 6082 bytes, além dos bytes registrados por atividades específicas.

Dica

Esta opção é selecionada primariamente para fins de depuração. Deixe-a desmarcada para limitar o crescimento do log.

Definir opções de log pode afetar significativamente o desempenho e aumentar o crescimento do banco de dados. Imagine um cenário em que a mesma atividade de runbook seja executada duas vezes, primeiro com o log de dados em nível padrão (nenhuma das opções de dados publicados selecionada) e depois com a configuração de dados publicados comuns selecionada. O código de domínio deve levar a mesma quantidade de tempo para ser concluído. Porém, o código de plataforma demorará mais para ser executado, já que terá que dar suporte a 12 vezes a quantidade de log de dados publicados comuns do que faria somente com o log padrão.

Limpando Logs

As opções padrão especificadas para o recurso limpeza de log no runbook Designer são configuradas para fornecer a melhor experiência do usuário para uma implantação pronta para uso do Orchestrator. A alteração desses valores pode alterar as características de desempenho do ambiente e deve ser implementada gradualmente e com marca d'água alta para que o efeito da alteração possa ser avaliado.

Para obter mais informações sobre a limpeza automática e manual de logs, consulte Purging Runbook Logs.

Criando parâmetros de comparação de desempenho

Para criar um runbook simples para testar o crescimento do log, você pode usar os Valores de Comparação de Atividade Padrão para criar parâmetros de comparação de um ambiente do Orchestrator.

O procedimento a seguir cria um runbook que executa uma atividade Comparar Valores 10.000 vezes. Comparar Valores é uma atividade simples cujo código de domínio é mínimo. Esse runbook pode ser invocado em várias circunstâncias para caracterizar o desempenho geral de um determinado ambiente de runtime do Orchestrator.

Para criar um runbook que possa ser usado para avaliar o desempenho de seu ambiente Orchestrator

Crie um novo runbook.
Adicione uma atividade Compare Values da paleta Atividade Padrão. Clique duas vezes na atividade para configurá-la.
Selecione a guia Geral e configure essa atividade para comparar cadeias de caracteres (o valor padrão).
Selecione a guia Detalhes , insira o valor STRING na caixa Teste e selecione está vazio.
Selecione Concluir para salvar as atualizações na atividade.
Clique com o botão direito na atividade e selecione Looping.
Marque a caixa de seleção Ativar e insira o número 0 (zero) em Atraso entre tentativas.
Selecione a guia Sair .
Altere a condição de saída padrão. Selecione Comparar Valores, marcar caixa de seleção Mostrar Dados Publicados Comuns e selecione Loop: Número de tentativas. Selecione OK para salvar essa alteração.
Selecione o valor na condição de saída atualizada e insira o número 10000 (dez mil). Selecione OK para salvar essa alteração.
Selecione Concluir para salvar essas atualizações.
Selecione Check In para salvar as alterações no banco de dados do Orchestrator.

Este runbook pode ser usado para fazer experiências com configurações diferentes do Orchestrator. Por exemplo, você pode criar os runbooks de parâmetro de comparação para determinar o desempenho de quatro Runbook Servers implantados em data centers diferentes.

Data Center	Configuração de log	Tempo de execução de código de plataforma (milissegundos)	Milissegundos por atividade	Fator de escala
Local 1	log padrão	819	82	1.0 (referência)
Local 1	Log de dados publicados comuns	2012	201	2.5
Local 2	log padrão	1229	123	1.5
Local 2	Log de dados publicados comuns	3686	369	4.5
Local 3	log padrão	2457	426	3.0
Local 3	Log de dados publicados comuns	4422	442	5.4
Local 4	log padrão	1474	147	1.8
Local 4	Log de dados publicados comuns	2654	265	3.2

Observe a redução significativa no desempenho da plataforma ocasionado pelo log de dados publicados comuns. A pior das hipóteses parece ser o log de dados publicados comuns no Local 2. Superficialmente, essa parece ser uma conclusão clara e relevante.

Porém, é preciso notar que esses números refletem a sobrecarga do código de plataforma, não do código de domínio. Os runtimes de código de domínio podem ser mais longos. Por exemplo, a atividade Criar VM a partir do modelo no Pacote de Integração do Virtual Machine Manager pode ser executada por vários minutos enquanto a VM é criada. Expandindo o exemplo anterior, considere os custos de código da plataforma em uma atividade de runbook que leva 1 minuto para ser executada (1 minuto = 60.000 milissegundos), independentemente do local.

Data Center	Configuração de log	Tempo de execução de código de plataforma (milissegundos)	% de código de domínio	% de código de plataforma
Local 1	log padrão	819	98,6%	1,4%
Local 1	Log de dados publicados comuns	2012	96,7%	3,3%
Local 2	log padrão	1229	98,0%	2,0%
Local 2	Log de dados publicados comuns	3686	93,9%	6,1%
Local 3	log padrão	2457	95,9%	4,1%
Local 3	Log de dados publicados comuns	4422	92,6%	7,4%
Local 4	log padrão	1474	97,5%	2,5%
Local 4	Log de dados publicados comuns	2654	95,6%	4,4%

Uma imagem mais nítida começa a surgir dos dados. O cenário em que o log de dados publicados comuns está ativado no Local 2 continua a ter o pior desempenho. Porém, o código de plataforma e o log são responsáveis por apenas 6% do runtime total. Embora esse seja um número significativo, o cenário mais favorável é de 1,4%. Essencialmente, o tempo gasto no código do domínio do exemplo tem muito mais peso do que o tempo gasto executando código de plataforma. Para colocar isso em perspectiva, se você fosse capaz de eliminar completamente os custos de código da plataforma, só veria melhorias no desempenho do runbook no intervalo de 1,4% a 7,4%.

A maioria dos cenários do mundo real será diferente. O comportamento da atividade pode mudar dependendo do que o código de domínio é instruído a fazer. Por exemplo, uma atividade Clonar VM do Modelo pode levar um minuto para clonar uma VM do Modelo de Servidor A, mas levar 5 minutos para clonar uma VM do Modelo de Servidor B. Além disso, os Runbook Servers podem residir em redes diferentes com características de desempenho diferentes, o que pode afetar potencialmente o desempenho do código de domínio e o desempenho de log de dados do Orchestrator.

Determinando o crescimento do banco de dados

O administrador de banco de dados do seu banco de dados Orchestrator pode usar as orientações a seguir para determinar uma estratégia de crescimento do arquivo de banco de dados:

Em geral, os arquivos de banco de dados não aumentarão de tamanho com cada invocação de um runbook. Os arquivos crescerão quando os dados contidos neles chegarem a uma marca d'água alta específica configurada pelo seu administrador de banco de dados, e nesse momento o arquivo normalmente será expandido.
Cada vez que uma atividade de runbook é executada, ela deve ser contada individualmente, o que deve ser considerado quando os recursos de loop podem fazer com que uma única atividade seja executada várias vezes.
Para determinar o armazenamento necessário para cada invocação do runbook, multiplique o número de atividades no runbook pelo número de bytes adicionados ao banco de dados de acordo com o nível de log selecionado. Esses valores são:
- 524 bytes
  
  Configuração de log padrão.
- 6082 bytes
  
  Nível de log de dados publicados comuns.
- 6082 bytes + dados registrados pela atividade
  
  Nível de log de dados publicados específicos da atividade.
Por padrão, o Orchestrator limpa tudo, menos os 500 logs mais recentes para cada runbook à noite, às 2h00 am. Para determinar o armazenamento necessário para cada invocação do runbook, multiplique o armazenamento necessário para cada invocação do runbook por 500. Se você alterar a configuração de Limpeza de log, multiplique cada invocação pelo número estimado de invocações por dia, semana ou mês, conforme necessário.

A tabela a seguir mostra as estimativas de crescimento e desempenho para as configurações de nível de log.

Nível de log	Fator de crescimento do banco de dados	Fator de desempenho	Recomendado para produção
Default	1	1	Sim
Dados publicados comuns	11,6 x	2,5 x	Uso limitado com planejamento
Dados Publicados Específicos da Atividade	Maior do que 11,6 x	Maior do que 2,5 x	Não

Exemplos

Exemplo 1

A tabela a seguir descreve as considerações de dimensionamento de banco de dados para uma implantação do Orchestrator.

Nome do runbook	Número de atividades	Nível de log	Invocações por dia
Runbook 1	50	Default	100
Runbook 2	25	Default	50
Runbook 3	12	Dados publicados comuns	24
Runbook 3	8	Dados publicados comuns	500

Usando o dimensionamento de banco de dados descrito acima, você pode estimar os requisitos de armazenamento para os runbooks.

Nome do runbook	Bytes por invocação	Armazenamento em MB Limpeza de Log padrão (500 invocações)	Invocações por mês	Armazenamento em MB Um mês (não é o padrão da Limpeza de Log)	% do armazenamento do banco de dados após 30 dias
Runbook 1	26,200	12.5	3.000	74,5	9%
Runbook 2	13.100	6.2	1\.500	18,7	2%
Runbook 3	72.984	34,8	720	50,1	6%
Runbook 3	48.656	23,2	15,000	696,0	83%
		Total: 76,7 MB		Total: 839,3 MB

Este exemplo ilustra claramente a importância de tomar decisões sensatas para o log de dados. O Runbook 4 contém apenas oito atividades, mas quando configurado no nível log de dados publicados comuns, ele consome a maior parte do armazenamento no banco de dados devido à alta frequência de invocação. Com base nesses resultados, talvez você prefira reduzir o nível de log do Runbook 4 para a configuração de log padrão.

Exemplo 2

A tabela a seguir descreve as considerações de dimensionamento do banco de dados para outra implantação do Orchestrator.

Nome do runbook	Número de atividades	Nível de log	Invocações por dia
Runbook 1	50	Default	100
Runbook 2	25	Default	50
Runbook 3	12	Dados publicados comuns	24
Runbook 3	8	Padrão	500

Recalcular os valores de armazenamento para a configuração atualizada gera resultados significativamente diferentes.

Nome do runbook	Bytes por invocação	Armazenamento em MB Limpeza de Log padrão (500 invocações)	Invocações por mês	Armazenamento em MB Um mês (não é o padrão da Limpeza de Log)	% do armazenamento do banco de dados após 30 dias
Runbook 1	26,200	12.5	3.000	74,5	37%
Runbook 2	13.100	6.2	1\.500	18,7	9%
Runbook 3	72.984	34,8	720	50,1	25%
Runbook 3	4,192	2,0	15,000	60.0	29%
		Total: 55,5 MB		Total: 203,3 MB

Embora haja pouca alteração na configuração de log padrão (500 entradas de log por runbook), os requisitos de armazenamento de 30 dias foram muito alterados. Claramente, o custo de armazenamento do uso do log de dados publicados comuns para o Runbook 4 deve ser cuidadosamente considerado, pois essa alteração resulta em uma redução de 76% nos requisitos de armazenamento de banco de dados para 30 dias de dados.

Resumo

Use as orientações a seguir para gerenciar o desempenho e o dimensionamento do banco de dados:

Somente habilite o log de Dados Publicados Comuns se for necessário.
Lembre-se de que o número de vezes que as atividades são executadas determina o volume de dados no log. Um runbook pequeno com algumas atividades executadas várias vezes pode resultar em mais log de dados do que um runbook maior executado um número menor de vezes.
Não habilite o registro em log de dados publicados específicos da atividade em ambientes de produção e só deve ser usado para fins de depuração.
Desenvolva um entendimento de quanto tempo seus runbooks gastam executando código de domínio em comparação com a execução de código de plataforma.
Estime custos de código de plataforma usando as técnicas descritas neste documento. Use-o como referência para considerar onde é possível aprimorar o desempenho do runbook.
Identifique oportunidades de aprimoramento fazendo comparações normalizadas de suas medições.