Compartilhar via

Considerações sobre design do SQL Server

  • Artigo

O System Center Operations Manager conta com o Microsoft SQL Server para dar suporte a seus bancos de dados operacionais, de data warehouse e de auditoria do ACS. Esses bancos de dados são essenciais e são criados durante a implantação do primeiro servidor de gerenciamento ou coletor ACS em seu grupo de gerenciamento.

Em um ambiente de laboratório ou implantação em pequena escala do Operations Manager, o SQL Server pode ser colocado no primeiro servidor de gerenciamento no grupo de gerenciamento.

Em uma implantação distribuída de escala média a empresarial, a instância do SQL Server deve estar localizada em um servidor autônomo dedicado ou em uma configuração de alta disponibilidade do SQL Server. Em ambos os casos, o SQL Server já deve existir e estar acessível antes de iniciar a instalação do primeiro servidor de gerenciamento ou coletor ACS.

Não recomendamos a utilização de bancos de dados do Operations Manager de uma instância do SQL que tenha outros bancos de dados de aplicativo para evitar possíveis problemas com E/S e outras restrições de recursos de hardware.

Importante

O Operations Manager não dá suporte a instâncias de PaaS (Plataforma como Serviço) do SQL, incluindo produtos como a Instância Gerenciada de SQL do Azure ou o AWS RDS (Amazon Relational Database Service). Use uma instância do SQL Server instalada em um computador Windows. A única exceção a isso é na Instância Gerenciada do SCOM do Azure Monitor, que utiliza a MI do SQL do Azure e não é reconfigurável.

Requisitos do SQL Server

As seguintes versões do SQL Server Enterprise e Standard Edition têm suporte para uma instalação existente da versão do System Center Operations Manager para hospedar o Servidor de Relatórios, Operacional, Data Warehouse e banco de dados ACS:

  • SQL Server 2019 com uma atualização cumulativa mínima de CU8 (Atualização Cumulativa) ou posterior, conforme disponível aqui
  • SQL Server 2016 e as atualizações mais recentes disponíveis aqui
  • SQL Server 2022 com uma atualização cumulativa mínima de CU11 (Atualização Cumulativa 11) ou posterior, conforme disponível aqui
  • SQL Server 2019 com uma atualização cumulativa mínima de CU8 (Atualização Cumulativa) ou posterior, conforme disponível aqui
  • SQL Server 2017 com a atualização mais recente disponível, conforme disponível aqui
  • SQL Server 2017 e atualizações cumulativas, conforme detalhado aqui
  • SQL Server 2016 e Service Packs conforme detalhado aqui

As seguintes versões do SQL Server Enterprise e Standard Edition têm suporte para uma instalação nova ou existente do System Center 2016 – Operations Manager para hospedar o Servidor de Relatórios, Operacional, Data Warehouse e banco de dados ACS:

  • SQL Server 2016 e as atualizações mais recentes disponíveis aqui
  • SQL Server 2014 e as atualizações mais recentes disponíveis aqui
  • SQL Server 2012 e as atualizações mais recentes disponíveis aqui

Drivers do SQL Server

Os drivers OLE DB e ODBC SQL Server precisam ser instalados em todos os servidores de gerenciamento e no servidor de console Web, pois esses componentes interagem diretamente com os bancos de dados e permitem acesso no nível da API ao SQL.

Recomenda-se utilizar uma conexão criptografada do SQL Server; ao fazer isso, você precisa instalar as versões mais recentes dos drivers SQL:

Mais informações sobre como configurar a criptografia de conexão SQL podem ser encontradas aqui: Configurar o Mecanismo de Banco de Dados do SQL Server para criptografar conexões

Se não estiver utilizando conexões SQL criptografadas, use versões anteriores dos drivers SQL que não impõem criptografia:

Atualizações do SQL Server

Cada um dos seguintes componentes do SQL Server que dão suporte a uma infraestrutura do Operations Manager deve estar na mesma versão principal do SQL Server:

  • Instâncias do mecanismo de banco de dados do SQL Server que hospedam qualquer um dos bancos de dados do Operations Manager, incluindo:
    • Gerenciador de Operações
    • OperationManagerDW
    • Bancos de dados SSRS ReportServer e ReportServerTempDB
  • Instância do SSRS (SQL Server Reporting Services).

Modo de autenticação do SQL Server

Por padrão, o SQL opera em uma configuração de autenticação de modo misto. No entanto, o Operations Manager utiliza apenas a autenticação do Windows para se comunicar com o SQL Server. Se deixada no padrão, a configuração de Autenticação de Modo Misto do SQL ainda funcionará se nenhuma conta local tiver a db_owner função. Sabe-se que as contas locais com a função causam problemas com o db_owner Operations Manager.

É altamente recomendável remover a db_owner função de todas as contas locais antes de instalar o produto e não adicionar a db_owner função a nenhuma conta local após a instalação.

Outras considerações

Outras considerações de hardware e software se aplicam ao seu planejamento de projeto:

  • Recomenda-se que a TI tenha discos SQL no formato de arquivo NTFS.
  • Você deve ter pelo menos 1 GB de espaço livre em disco para o banco de dados operacional e de data warehouse, isso é imposto no momento da criação do banco de dados. Lembre-se de que a utilização do disco dos bancos de dados aumentará significativamente após a instalação, certifique-se de ter bastante espaço livre em disco acima desse requisito básico.
  • O .NET Framework 4 é necessário.
  • O Operations Manager 2022 dá suporte ao .NET Framework 4.8.
  • Não há suporte para o Reporting Server no Windows Server Core.
  • A configuração de ordenação do SQL Server deve ser um dos tipos com suporte, conforme descrito na seção: Configuração de ordenação do SQL Server.
  • A Pesquisa de Texto Completo do SQL Server é necessária para todas as instâncias do mecanismo de banco de dados do SQL Server que hospedam qualquer um dos bancos de dados do Operations Manager.
  • As opções de instalação do Windows Server (Server Core, Server with Desktop Experience e Nano Server) compatíveis com os componentes de banco de dados do Operations Manager são baseadas nas opções de instalação compatíveis com o SQL Server.

Para obter mais informações, consulte a seção Requisitos de hardware e software na documentação de instalação e planejamento do SQL Server aqui: Planejar uma instalação do SQL Server

Configuração de agrupamento do SQL Server

Os seguintes agrupamentos do SQL Server e do Windows têm suporte no System Center Operations Manager.

Observação

Para evitar problemas de compatibilidade na comparação ou cópia de operações, recomendamos que você use a mesma ordenação para o banco de dados SQL e Operations Manager.

Ordenação do SQL Server

  • SQL_Latin1_General_CP1_CI_AS

Ordenação do Windows

  • Latin1_General_100_CI_AS
  • French_CI_AS
  • French_100_CI_AS
  • Cyrillic_General_CI_AS
  • Chinese_PRC_CI_AS
  • Chinese_Simplified_Pinyin_100_CI_AS
  • Chinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_AS
  • Japanese_XJIS_100_CI_AS
  • Traditional_Spanish_CI_AS
  • Modern_Spanish_100_CI_AS
  • Latin1_General_CI_AS
  • Cyrillic_General_100_CI_AS
  • Korean_100_CI_AS
  • Czech_100_CI_AS
  • Hungarian_100_CI_AS
  • Polish_100_CI_AS
  • Finnish_Swedish_100_CI_AS

Se sua instância do SQL Server não estiver configurada com um dos agrupamentos com suporte listados anteriormente, a execução de uma nova configuração da instalação do Operations Manager falhará. No entanto, uma atualização in-loco é concluída com êxito.

Configuração do firewall

O Operations Manager depende do SQL Server para hospedar seus bancos de dados e de uma plataforma de relatórios para analisar e apresentar dados operacionais históricos. As funções de servidor de gerenciamento, Operações e console Web precisam ser capazes de se comunicar com êxito com o SQL Server, e é importante entender o caminho de comunicação e as portas para configurar seu ambiente corretamente.

Se estiver criando uma implantação distribuída que usa Grupos de Disponibilidade Always On do SQL, há definições de configuração de firewall extras que precisam ser incluídas em sua estratégia de segurança de firewall.

A tabela a seguir identifica as portas de firewall exigidas pelo SQL Server para que os servidores de gerenciamento se comuniquem com os bancos de dados:

Cenário Porta Direção Função do Gerente de Operações
SQL Server hospedando bancos de dados do Operations Manager TCP 1433 * Entrada servidor de gerenciamento e console Web (para Application Advisor e Application Diagnostics)
Serviço Navegador do SQL Server UDP 1434 Entrada Management Server
Conexão de administrador dedicado do SQL Server TCP 1434 Entrada Management Server
Outras portas usadas pelo SQL Server
- Chamadas de procedimento remoto da Microsoft (MS RPC)
- Instrumentação de Gerenciamento do Windows (WMI)
- Coordenador de Transações Distribuídas da Microsoft (MS DTC)		 TCP 135 Entrada Management Server
Ouvinte do Grupo de Disponibilidade Always On do SQL Server Porta configurada pelo administrador Entrada Management Server
SQL Server Reporting Services hospedando o Servidor de Relatórios do Operations Manager TCP 80 (padrão)/443 (SSL) Entrada servidor de gerenciamento e console de operações

Observação

Embora o TCP 1433 seja a porta padrão para a instância padrão do Mecanismo de Banco de Dados, quando você cria uma instância nomeada em um SQL Server autônomo ou implanta um Grupo de Disponibilidade Always On do SQL, uma porta personalizada é definida e deve ser documentada para referência para que você configure corretamente seus firewalls e insira essas informações durante a instalação.

Para obter uma visão geral mais detalhada dos requisitos de firewall para o SQL Server, consulte Configurar o Firewall do Windows para permitir o acesso ao SQL Server.

Considerações sobre capacidade e armazenamento

Banco de dados do Operations Manager

O banco de dados do Operations Manager é um banco de dados do SQL Server que contém todos os dados necessários para o Operations Manager para o monitoramento diário. O dimensionamento e a configuração do servidor de banco de dados são essenciais para o desempenho geral do grupo de gerenciamento. O recurso mais crítico usado pelo banco de dados do Operations Manager é o subsistema de armazenamento, mas a CPU e a RAM também são significativas.

Os fatores que influenciam a carga no banco de dados do Operations Manager incluem:

  • Taxa de coleta de dados operacionais.
    • A taxa de coleta de dados operacionais é influenciada por fatores como o número de pacotes de gerenciamento importados, o número de agentes adicionados e o tipo de computador que está sendo monitorado. Por exemplo, um agente que monitora um computador desktop comercialmente crítico coleta menos dados em comparação com um agente que monitora um servidor que executa o SQL Server com vários bancos de dados.
  • A taxa de alterações no espaço de instância.
    • A atualização de dados existentes no banco de dados do Operations Manager consome muitos recursos em comparação com a gravação de novos dados operacionais. Além disso, quando há alterações nos dados de espaço de instância, os servidores de gerenciamento precisam fazer mais consultas ao banco de dados para calcular a configuração e as alterações de grupo. A taxa de alterações no espaço de instância aumenta ao importar novos pacotes de gerenciamento ou adicionar novos agentes ao grupo de gerenciamento.
  • O número de Consoles de Operações e outras conexões do SDK em execução simultaneamente também afeta a carga no banco de dados.
    • Cada console de Operações lê dados do banco de dados do Operations Manager. Consultar esses dados consome quantidades potencialmente grandes de recursos de E/S de armazenamento, tempo de CPU e RAM. Os consoles de operações que exibem grandes quantidades de dados operacionais na Exibição de Eventos, Exibição de Estado, Exibição de Alertas e Exibição de Dados de Desempenho tendem a causar a maior carga no banco de dados.

O banco de dados do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, ele pode ser altamente disponibilizado usando configurações de failover com suporte, como Grupos de Disponibilidade Always On do SQL Server ou Instâncias de Cluster de Failover.

Você pode configurar e atualizar bancos de dados do Operations Manager com uma configuração Always-On do SQL existente sem a necessidade de alterações pós-configuração.

Habilitar o SQL Broker no banco de dados do Operations Manager

O System Center Operations Manager depende do SQL Server Service Broker para implementar todas as operações de tarefa. Se o SQL Server Service Broker estiver desabilitado, todas as operações de tarefa serão afetadas. O comportamento resultante pode variar de acordo com a tarefa iniciada. Portanto, é importante verificar o estado do SQL Server Service Broker sempre que um comportamento inesperado for observado em torno de uma tarefa no System Center Operations Manager.

Para habilitar o SQL Server Service Broker, siga estas etapas:

  1. Execute a seguinte consulta SQL para verificar se a corretora já está habilitada, indicada por um resultado de 1 (um) no is_broker_enabled campo:

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

  2. Se o valor exibido no is_broker_enabled campo for 0 (zero), execute a seguinte instrução SQL para habilitar o agente:

    ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER

Banco de dados do Data Warehouse do Operations Manager

Observação

O Data Warehouse do Operations Manager também é conhecido como banco de dados "Data Warehouse de Relatórios" ou apenas "Data Warehouse" em algumas documentações.

O System Center – Operations Manager insere dados no data warehouse quase em tempo real, é importante ter capacidade suficiente nesse servidor que dê suporte à gravação de todos os dados que estão sendo coletados no data warehouse. Assim como acontece com o banco de dados do Operations Manager, o recurso mais crítico no data warehouse é o subsistema de E/S de armazenamento. Na maioria dos sistemas, as cargas no data warehouse são semelhantes ao banco de dados do Operations Manager, mas podem variar. Além disso, a carga de trabalho colocada no data warehouse por meio de relatórios é diferente da carga colocada no banco de dados do Operations Manager pelo uso do console de Operações.

Os fatores que influenciam a carga no data warehouse incluem:

  • Taxa de coleta de dados operacionais.
    • O data warehouse executa cálculos e armazena dados agregados, juntamente com uma quantidade limitada de dados brutos, para permitir relatórios mais eficientes. Como resultado, o custo de coleta de dados operacionais para o data warehouse é um pouco maior em comparação com o banco de dados do Operations Manager. No entanto, esse custo é compensado pelo custo de processamento reduzido de dados de descoberta no data warehouse em comparação com o banco de dados do Operations Manager.
  • Número de usuários de relatórios simultâneos ou geração de relatórios agendada.
    • Cada usuário de relatório pode adicionar uma carga significativa ao sistema porque os relatórios frequentemente resumem grandes volumes de dados. As necessidades gerais de capacidade são influenciadas pelo número de relatórios executados simultaneamente e pelo tipo de relatórios que estão sendo executados. Relatórios que consultam grandes intervalos de datas ou um grande número de objetos exigem recursos extras do sistema.

Com base nesses fatores, há várias práticas recomendadas a serem consideradas ao dimensionar o data warehouse:

  • Escolha um subsistema de armazenamento apropriado.
    • Como o data warehouse é parte integrante do fluxo geral de dados por meio do grupo de gerenciamento, é importante escolher um subsistema de armazenamento apropriado para o data warehouse. Assim como no banco de dados do Operations Manager, o RAID 0 + 1 geralmente é a melhor opção. Em geral, o subsistema de armazenamento do data warehouse deve ser semelhante ao subsistema de armazenamento do banco de dados do Operations Manager, e as diretrizes que se aplicam ao banco de dados do Operations Manager também se aplicam ao data warehouse.
  • Considere o posicionamento apropriado de logs de dados versus logs de transações.
    • Quanto ao banco de dados do Operations Manager, separar dados SQL e logs de transações geralmente é uma opção apropriada à medida que você aumenta o número de agentes. Se o banco de dados e o data warehouse do Operations Manager estiverem localizados no mesmo servidor e você quiser separar os logs de dados e transações, deverá colocar os logs de transações do banco de dados do Operations Manager em um volume físico separado e em eixos de disco do data warehouse para receber qualquer benefício. Os arquivos de dados do banco de dados e do data warehouse do Operations Manager podem compartilhar o mesmo volume físico, desde que o volume forneça capacidade adequada e o desempenho de E/S do disco não afete negativamente a funcionalidade de monitoramento e relatório.
  • Considere colocar o data warehouse em um servidor separado do banco de dados do Operations Manager.
    • Embora as implantações de menor escala geralmente possam consolidar o banco de dados e o data warehouse do Operations Manager no mesmo servidor, é vantajoso separá-los à medida que você aumenta o número de agentes e o volume de dados operacionais de entrada. Quando o data warehouse e o Servidor de Relatórios estão em um servidor separado do banco de dados do Operations Manager, você obtém um melhor desempenho de relatórios.

O banco de dados do Data Warehouse do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, ele pode ser altamente disponibilizado usando configurações de failover com suporte, como Grupos de Disponibilidade Always On do SQL Server ou Instâncias de Cluster de Failover.

SQL Server Always On

Os grupos de disponibilidade Always On do SQL Server dão suporte a ambientes de failover para um conjunto discreto de bancos de dados de usuário (bancos de dados de disponibilidade). Cada conjunto de bancos de dados de disponibilidade é hospedado em uma réplica de disponibilidade.

Com o System Center 2016 e posterior – Operations Manager, o SQL Always On é preferível ao clustering de failover para fornecer alta disponibilidade para bancos de dados. Todos os bancos de dados, exceto a instalação do Reporting Services no modo nativo, que usa dois bancos de dados para separar o armazenamento de dados persistente dos requisitos de armazenamento temporário, podem ser hospedados em um Grupo de Disponibilidade AlwaysOn.

Para configurar um grupo de disponibilidade, implante um cluster WSFC (Clustering de Failover do Windows Server) para hospedar a réplica de disponibilidade e habilite o Always On nos nós de cluster. Em seguida, você pode adicionar o banco de dados SQL Server do Operations Manager como um banco de dados de disponibilidade.

Dica

A partir do Operations Manager 2022, você pode configurar e atualizar bancos de dados do Operations Manager com uma configuração SQL Always-On existente sem a necessidade de alterações pós-configuração.

Para configurar um grupo de disponibilidade, implante um cluster WSFC (Clustering de Failover do Windows Server) para hospedar a réplica de disponibilidade e habilite o Always On nos nós de cluster. Em seguida, você pode adicionar o banco de dados SQL Server do Operations Manager como um banco de dados de disponibilidade.

Observação

Depois de implantar o Operations Manager nos nós do SQL Server que participam do SQL Always On, para habilitar a segurança estrita do CLR, execute o script SQL em cada banco de dados do Operations Manager.

Cadeia de caracteres de várias sub-redes

O Operations Manager não dá suporte às palavras-chave da cadeia de conexão (MultiSubnetFailover=True). Como um grupo de disponibilidade tem um nome de ouvinte (conhecido como nome de rede ou Ponto de Acesso para Cliente no Gerenciador de Cluster do WSFC) dependendo de vários endereços IP de sub-redes diferentes, como quando você implanta em uma configuração de failover entre sites, as solicitações de conexão de cliente dos servidores de gerenciamento para o ouvinte do grupo de disponibilidade atingirão um tempo limite de conexão.

A abordagem recomendada para contornar essa limitação com nós de servidor de grupo de disponibilidade implantados em um ambiente de várias sub-redes é:

  1. Defina o nome da rede do ouvinte do grupo de disponibilidade para registrar apenas um único endereço IP ativo no DNS.
  2. Configure o cluster para usar um valor de TTL baixo para o registro DNS registrado.

Essas configurações permitem uma recuperação e resolução mais rápidas do nome do cluster com o novo endereço IP ao fazer failover para um nó em uma sub-rede diferente.

Execute os seguintes comandos do PowerShell em qualquer um dos nós SQL para modificar essas configurações:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Se você estiver usando Always On com um nome de ouvinte, também deverá fazer essas alterações de configuração no ouvinte. Para obter mais informações sobre como configurar um ouvinte do grupo de disponibilidade, consulte a documentação aqui: Configurar o ouvinte do grupo de disponibilidade – SQL Server Always On.

Os seguintes comandos do PowerShell podem ser executados no nó SQL que hospeda o ouvinte no momento para modificar suas configurações:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Quando uma instância SQL clusterizada ou Always On é usada para alta disponibilidade, você deve habilitar o recurso de recuperação automática em seus servidores de gerenciamento para evitar a reinicialização do serviço de Acesso a Dados do Operations Manager sempre que ocorrer um failover entre nós. Para obter informações de configuração, consulte o seguinte artigo da base de dados de conhecimento O serviço de Gerenciamento do System Center para de responder depois que uma instância do SQL Server fica offline.

Otimizar o SQL Server

As experiências de suporte mostraram que os problemas de desempenho normalmente não são causados pela alta utilização de recursos (ou seja, processador ou memória) com o próprio SQL Server; em vez disso, o problema está diretamente relacionado à configuração do subsistema de armazenamento. Os gargalos de desempenho geralmente são atribuídos ao não cumprimento das diretrizes de configuração recomendadas com o armazenamento provisionado para a instância de banco de dados do SQL Server. Esses exemplos são:

  • Alocação insuficiente de eixos para os LUNs para dar suporte aos requisitos de E/S do Operations Manager.
  • Hospedar logs de transações e arquivos de banco de dados no mesmo volume. Essas duas cargas de trabalho têm características diferentes de E/S e latência.
  • A configuração do TempDB está incorreta em relação ao posicionamento, dimensionamento e assim por diante.
  • Desalinhamento da partição de disco de volumes que hospedam os logs de transações do banco de dados, arquivos de banco de dados e TempDB.
  • Ignorar a configuração básica do SQL Server, como usar AUTOGROW para arquivos de banco de dados e log de transações, configuração MAXDOP para paralelismo de consulta, criar vários arquivos de dados TempDB por núcleo de CPU e assim por diante.

A configuração de armazenamento é um dos componentes críticos para uma implantação do SQL Server para o Operations Manager. Os servidores de banco de dados tendem a ser fortemente vinculados à E/S devido à rigorosa atividade de leitura e gravação do banco de dados e ao processamento do log de transações. O padrão de comportamento de E/S do Operations Manager normalmente é de 80% de gravações e 20% de leituras. Como resultado, a configuração inadequada de subsistemas de E/S pode levar a um desempenho e operação insatisfatórios de sistemas SQL Server e se torna perceptível no Operations Manager.

É importante testar o design do SQL Server executando o teste de taxa de transferência do subsistema de E/S antes de implantar o SQL Server. Certifique-se de que esses testes sejam capazes de atender aos requisitos de E/S com uma latência aceitável. Use o Utilitário Diskspd para avaliar a capacidade de E/S do subsistema de armazenamento que dá suporte ao SQL Server. O artigo de blog a seguir, de autoria de um membro da equipe do Servidor de Arquivos no grupo de produtos, fornece diretrizes e recomendações detalhadas sobre como executar testes de estresse usando essa ferramenta – DiskSpd, PowerShell e desempenho de armazenamento: medindo IOPs, taxa de transferência e latência para discos locais e compartilhamentos de arquivos SMB.

Tamanho da unidade de alocação NTFS

O alinhamento de volume, comumente chamado de alinhamento de setor, deve ser executado no sistema de arquivos (NTFS) sempre que um volume for criado em um dispositivo RAID. Não fazer isso pode levar a uma degradação significativa do desempenho e é mais comumente o resultado do desalinhamento da partição com os limites da unidade de faixa. Isso também pode levar ao desalinhamento do cache de hardware, resultando na utilização ineficiente do cache do array.

Ao formatar a partição usada para arquivos de dados do SQL Server, a recomendação é usar um tamanho de unidade de alocação de 64 KB (ou seja, 65.536 bytes) para dados, logs e TempDB. No entanto, lembre-se de que o uso de tamanhos de unidade de alocação maiores que 4 KB resulta na incapacidade de usar a compactação NTFS no volume. Embora o SQL Server dê suporte a dados somente leitura em volumes compactados, ele não é recomendado.

Memória de reserva

Observação

Muitas das informações nesta seção vêm de Jonathan Kehayias em sua postagem no blog Quanta memória meu SQL Server realmente precisa? (sqlskills.com).

Nem sempre é fácil identificar a quantidade certa de memória física e processadores a serem alocados para o SQL Server em suporte ao System Center Operations Manager (ou para outras cargas de trabalho fora deste produto). A calculadora de dimensionamento fornecida pelo grupo de produtos fornece diretrizes com base na escala de carga de trabalho, mas suas recomendações são baseadas em testes realizados em um ambiente de laboratório que pode ou não estar alinhado com sua carga de trabalho e configuração reais.

O SQL Server permite configurar a quantidade mínima e máxima de memória que será reservada e utilizada por seu processo. Por padrão, o SQL Server pode alterar seus requisitos de memória dinamicamente com base nos recursos disponíveis do sistema. A configuração padrão para memória mínima do servidor é 0 e a configuração padrão para memória máxima do servidor é 2.147.483.647 MB.

Problemas relacionados ao desempenho e à memória podem surgir se você não definir um valor apropriado para a memória máxima do servidor. Muitos fatores influenciam a quantidade de memória necessária para alocar ao SQL Server para garantir que o sistema operacional possa oferecer suporte a outros processos em execução nesse sistema, como a placa HBA, os agentes de gerenciamento e a verificação em tempo real do antivírus. Se memória suficiente não for definida, o sistema operacional e o SQL serão paginados para o disco. Isso pode fazer com que a E/S de disco aumente, diminuindo ainda mais o desempenho e criando um efeito cascata onde ele se torna perceptível no Operations Manager.

Recomendamos especificar pelo menos 4 GB de RAM para memória mínima do servidor. Isso deve ser feito para cada nó SQL que hospeda um dos bancos de dados do Operations Manager (operacional, data warehouse, ACS).

Para memória máxima do servidor, recomendamos que você reserve inicialmente um total de:

  • 1 GB de RAM para o sistema operacional
  • 1 GB de RAM por cada 4 GB de RAM instalada (até 16 GB de RAM)
  • 1 GB de RAM por cada 8 GB de RAM instalada (acima de 16 GB de RAM)

Depois de definir esses valores, monitore o contador Memória\MBytes disponíveis no Windows para determinar se você pode aumentar a memória disponível para o SQL Server. O Windows sinaliza que a memória física disponível está acabando em 96 MB, portanto, o ideal é que o contador não seja inferior a cerca de 200 a 300 MB, para garantir que você tenha um buffer. Para servidores com 256 GB de RAM ou superior, verifique se ele não é executado abaixo de 1 GB.

Lembre-se de que esses cálculos pressupõem que você deseja que o SQL Server seja capaz de usar toda a memória disponível, a menos que você os modifique para levar em conta outros aplicativos. Considere os requisitos de memória específicos para seu sistema operacional, outros aplicativos, a pilha de threads do SQL Server e outros alocadores de várias páginas. Uma fórmula típica seria ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), onde a memória para pilha de threads = ((max worker threads) (stack size)). O tamanho da pilha é de 512 KB para sistemas x86, 2 MB para sistemas x64 e 4 MB para sistemas IA64, e você pode encontrar o valor para max worker threads na coluna max_worker_count de sys.dm_os_sys_info.

Essas considerações também se aplicam aos requisitos de memória para que o SQL Server seja executado em uma máquina virtual. Como o SQL Server foi projetado para armazenar dados em cache no pool de buffers e usa o máximo de memória possível, pode ser difícil determinar a quantidade ideal de RAM necessária. Ao reduzir a memória alocada para uma instância do SQL Server, você pode chegar a um ponto em que a alocação de memória mais baixa é trocada por um acesso de E/S de disco mais alto.

Para configurar a memória do SQL Server em um ambiente que foi provisionado em excesso, comece monitorando o ambiente e as métricas de desempenho atuais, incluindo a expectativa de vida da página do SQL Server Buffer Manager e as leituras de página/s e os valores de leituras de disco do disco físico/s. Se o ambiente tiver excesso de memória, a expectativa de vida da página aumentará em um valor de um a cada segundo, sem qualquer diminuição na carga de trabalho, devido ao cache; o valor de leituras de página/s do Gerenciador de Buffer do SQL Server será baixo depois que o cache for aumentado; e as leituras de disco/s do disco físico também permanecerão baixas.

Depois de entender a linha de base do ambiente, você pode reduzir a memória máxima do servidor em 1 GB e, em seguida, ver como isso afeta seus contadores de desempenho (depois que qualquer liberação inicial do cache diminuir). Se as métricas permanecerem aceitáveis, reduza em mais 1 GB e monitore novamente, repetindo conforme desejado até determinar uma configuração ideal.

Para obter mais informações, consulte Opções de configuração de memória do servidor.

Para obter mais informações, consulte Opções de configuração de memória do servidor.

Otimize o TempDB

O tamanho e o posicionamento físico do banco de dados TempDB podem afetar o desempenho do Operations Manager. Por exemplo, se o tamanho definido para o TempDB for muito pequeno, parte da carga de processamento do sistema poderá ser ocupada com o TempDB de crescimento automático para o tamanho necessário para dar suporte à carga de trabalho sempre que você reiniciar a instância do SQL Server. Para obter o desempenho ideal do TempDB, recomendamos a seguinte configuração para o TempDB em um ambiente de produção:

  • Defina o modelo de recuperação do TempDB como SIMPLE.
    • Esse modelo recupera automaticamente o espaço de log para manter os requisitos de espaço pequenos.
  • Aloque espaço antecipadamente para todos os arquivos do TempDB definindo o tamanho de arquivo com um valor grande o bastante para acomodar a carga de trabalho comum no ambiente. Isso impede que o TempDB se expanda com muita frequência, o que pode afetar o desempenho. O banco de dados TempDB pode ser definido para crescer automaticamente, mas isso deve ser usado para aumentar o espaço em disco para exceções não planejadas.
  • Crie quantos arquivos forem necessários para maximizar a largura de banda do disco.
    • O uso de vários arquivos reduz a contenção de armazenamento do TempDB e produz escalabilidade aprimorada. No entanto, não crie muitos arquivos, pois isso pode reduzir o desempenho e aumentar a sobrecarga de gerenciamento.
    • Como diretriz geral, crie um arquivo de dados para cada processador lógico no servidor (levando em conta as configurações de máscara de afinidade) e ajuste o número de arquivos para cima ou para baixo conforme necessário.
    • Como regra geral, se o número de processadores lógicos for menor ou igual a 8, use o mesmo número de arquivos de dados que o de processadores lógicos.
      • Se o número de processadores lógicos for maior que 8, use oito arquivos de dados e, se a contenção continuar, aumente o número de arquivos de dados em múltiplos de 4 (até o número de processadores lógicos) até que a contenção seja reduzida a níveis aceitáveis ou faça alterações na carga de trabalho/código.
      • Se a contenção não for reduzida, talvez seja necessário aumentar mais o número de arquivos de dados.
  • Faça com que cada arquivo de dados tenha o mesmo tamanho, permitindo um desempenho ideal de preenchimento proporcional.
    • O dimensionamento igual dos arquivos de dados é crítico porque o algoritmo de preenchimento proporcional é baseado no tamanho dos arquivos. Se os arquivos de dados forem criados com tamanhos desiguais, o algoritmo de preenchimento proporcional tentará usar o maior arquivo mais para alocações do GAM em vez de espalhar as alocações entre todos os arquivos, anulando assim a finalidade de criar vários arquivos de dados.
  • Coloque o banco de dados TempDB em um subsistema de E/S rápido usando unidades de estado sólido para obter o desempenho ideal.
    • Use a distribuição de disco se houver muitos discos anexados diretamente.
  • Coloque o banco de dados TempDB em discos diferentes dos usados por bancos de dados de usuários.

Para configurar o TempDB, você pode executar a consulta a seguir ou modificar suas propriedades no Management Studio.

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Execute a consulta SELECT * from sys.sysprocesses T-SQL para detectar a contenção de alocação de página para o banco de dados TempDB. Na saída da tabela do sistema, o recurso de espera pode aparecer como "2:1:1" (Página PFS) ou "2:1:3" (Página do Mapa de Alocação Global Compartilhada). Dependendo do grau de contenção, essa configuração pode fazer com que o SQL Server pareça não responder por curtos períodos. Outra abordagem é examinar as Exibições de Gerenciamento Dinâmico [sys.dm_exec_request ou sys.dm_os_waiting_tasks]. Os resultados mostram que essas solicitações ou tarefas estão aguardando recursos do TempDB e têm valores semelhantes aos destacados anteriormente quando você executa a sys.sysprocesses consulta.

Se as recomendações anteriores não reduzirem significativamente a contenção de alocação e a contenção estiver em páginas SGAM, implemente o sinalizador -T1118 de rastreamento nos parâmetros de inicialização do SQL Server para que o sinalizador de rastreamento permaneça em vigor mesmo depois que o SQL Server for reciclado. Sob esse sinalizador de rastreamento, o SQL Server aloca extensões completas para cada objeto de banco de dados, eliminando assim a contenção em páginas SGAM.

Observação

Esse sinalizador de rastreamento afeta todos os bancos de dados na instância do SQL Server.

Grau máximo de paralelismo

Dica

Para obter as práticas recomendadas e recomendações mais recentes da equipe do SQL Server, consulte a documentação aqui: Definir a opção de grau máximo de paralelismo para obter o desempenho ideal

A configuração padrão do SQL Server para implantações de pequeno a médio porte do Operations Manager é adequada para a maioria das necessidades. No entanto, quando a carga de trabalho do grupo de gerenciamento é dimensionada para cima em direção a um cenário de classe empresarial (normalmente 2.000+ sistemas gerenciados por agente e uma configuração de monitoramento avançada, que inclui monitoramento de nível de serviço com transações sintéticas avançadas, monitoramento de dispositivo de rede, plataforma cruzada e assim por diante), é necessário otimizar a configuração do SQL Server descrita nesta seção do documento. Uma opção de configuração não discutida nas diretrizes anteriores é MAXDOP.

A opção de configuração MAXDOP (grau máximo de paralelismo) do Microsoft SQL Server controla o número de processadores usados para a execução de uma consulta em um plano paralelo. Essa opção determina os recursos de computação e thread usados para os operadores de plano de consulta que executam o trabalho em paralelo. Dependendo se o SQL Server está configurado em um computador SMP (multiprocessamento simétrico), em um computador NUMA (acesso não uniforme à memória) ou em processadores habilitados para hyperthreading, você deve configurar a opção de grau máximo de paralelismo adequadamente.

Quando o SQL Server é executado em um computador com mais de um microprocessador ou CPU, ele detecta o melhor grau de paralelismo, ou seja, o número de processadores empregados para executar uma única instrução, para cada execução de plano paralelo. Por padrão, seu valor para essa opção é 0, o que permite que o SQL Server determine o grau máximo de paralelismo.

Os procedimentos armazenados e as consultas predefinidos no Operations Manager no que se refere ao banco de dados operacional, de data warehouse e até mesmo de auditoria não incluem a opção MAXDOP, pois não há como consultar dinamicamente quantos processadores são apresentados ao sistema operacional durante a instalação, nem tentar codificar o valor dessa configuração, o que pode ter consequências negativas quando a consulta é executada.

Observação

A opção de configuração de grau máximo de paralelismo não limita o número de processadores que o SQL Server usa. Para configurar o número de processadores que o SQL Server usa, use a opção de configuração de máscara de afinidade.

  • Para servidores que usam mais de oito processadores, use a seguinte configuração: MAXDOP=8

  • Para servidores que usam oito ou menos processadores, use a seguinte configuração: MAXDOP=0 a N

    Dica

    Nesta configuração, N representa o número de processadores.

  • Para servidores que têm NUMA configurado, MAXDOP não deve exceder o número de CPUs atribuídas a cada nó NUMA.

  • Para servidores que têm hyperthreading habilitado, o valor MAXDOP não deve exceder o número de processadores físicos.

  • Para servidores que têm NUMA configurado e hyperthreading habilitado, o valor MAXDOP não deve exceder o número de processadores físicos por nó NUMA.

Você pode monitorar o número de trabalhos paralelos consultando select * from sys.dm_os_tasks.

Neste exemplo, a configuração de hardware do servidor era um HP Blade G6 com processadores de 24 núcleos e 196 GB de RAM. A instância que hospeda o banco de dados do Operations Manager tinha uma configuração MAXMEM de 64 GB. Depois de executar as otimizações sugeridas nesta seção, o desempenho melhorou. No entanto, um gargalo de paralelismo de consulta ainda persistia. Depois de testar diferentes valores, o desempenho mais ideal foi encontrado definindo MAXDOP=4.

Dimensionamento inicial do banco de dados

Tentar estimar o crescimento futuro dos bancos de dados do Operations Manager, especificamente os bancos de dados operacionais e de data warehouse, nos primeiros meses após a implantação não é um exercício simples. Embora o Auxiliar de Dimensionamento do Operations Manager seja razoável ao estimar o crescimento potencial com base na fórmula derivada pelo grupo de produtos de seus testes no laboratório, ele não leva em consideração vários fatores que podem influenciar o crescimento no curto prazo versus no longo prazo.

O tamanho inicial do banco de dados, conforme sugerido pelo Auxiliar de Dimensionamento, deve ser alocado para um tamanho previsto para reduzir a fragmentação e a sobrecarga correspondente, que pode ser especificada no momento da configuração para os bancos de dados Operacional e Data Warehouse. Se, durante a instalação, não houver espaço de armazenamento suficiente disponível, os bancos de dados poderão ser expandidos posteriormente usando o SQL Management Studio e, em seguida, reindexados para desfragmentar e otimizar adequadamente. Esta recomendação também se aplica ao banco de dados ACS.

O monitoramento proativo do crescimento do banco de dados operacional e do data warehouse deve ser realizado em um ciclo diário ou semanal. Isso é necessário para identificar surtos de crescimento inesperados e significativos e iniciar a solução de problemas para determinar a causalidade, seja por um bug em um fluxo de trabalho do pacote de gerenciamento (ou seja, regra de descoberta, regra de desempenho ou coleta de eventos ou regra de monitoramento ou alerta) ou outro sintoma com um pacote de gerenciamento que não foi identificado durante a fase de teste e garantia de qualidade do processo de gerenciamento de versão.

Crescimento automático do banco de dados

Quando o tamanho do arquivo de bancos de dados reservados fica cheio, o SQL Server pode aumentar automaticamente o tamanho em uma porcentagem ou em um valor fixo. Além disso, um tamanho máximo de banco de dados pode ser configurado para evitar o preenchimento de todo o espaço disponível no disco. Por padrão, o banco de dados do Operations Manager não está configurado com o crescimento automático habilitado; somente os bancos de dados Data Warehouse e ACS são.

Confie apenas no crescimento automático como uma contingência para um crescimento inesperado. O crescimento automático introduz uma penalidade de desempenho que deve ser considerada ao lidar com um banco de dados altamente transacional. As penalidades de desempenho incluem:

  • Se você não fornecer um incremento de crescimento apropriado, poderá ocorrer a fragmentação do arquivo de log ou do banco de dados.
  • Se você executar uma transação que exija mais espaço de log do que o disponível e o crescimento automático estiver habilitado para o log de transações desse banco de dados, o tempo que a transação levará para ser concluída incluirá o tempo que o log de transações levará para aumentar pelo valor configurado.
  • Se você executar uma transação grande que exija que o log aumente, outras transações que exigem uma gravação no log de transações também terão que aguardar até que a operação de crescimento seja concluída.

Se as opções de crescimento automático e redução automática forem combinadas, isso pode criar uma sobrecarga desnecessária. Verifique se os limites que disparam as operações de aumento e redução não causarão alterações frequentes de tamanho para cima e para baixo. Por exemplo, você pode executar uma transação que faz com que o log de transações cresça em 100 MB no momento em que ele é confirmado; algum tempo depois disso, a redução automática inicia e reduz o log de transações em 100 MB. Em seguida, você executa a mesma transação e isso faz com que o log de transações cresça 100 MB novamente. Nesse exemplo, você está criando sobrecarga desnecessária e potencialmente criando fragmentação do arquivo de log, o que pode afetar negativamente o desempenho.

Defina essas duas configurações com cuidado. A configuração específica realmente depende do seu ambiente. A recomendação geral é aumentar o tamanho do banco de dados em um valor fixo para reduzir a fragmentação do disco. Consulte, por exemplo, a figura a seguir, em que o banco de dados está configurado para aumentar em 1.024 MB sempre que o crescimento automático é necessário.

Política de failover de cluster

O Clustering de Failover do Windows Server é uma plataforma de alta disponibilidade que monitora constantemente as conexões de rede e a integridade dos nós em um cluster. Se um nó não estiver acessível pela rede, a ação de recuperação será executada para recuperar e colocar aplicativos e serviços online em outro nó no cluster. As configurações padrão prontas para uso são otimizadas para falhas em que há uma perda completa de um servidor, o que é considerado uma falha "grave". Esses seriam cenários de falha irrecuperáveis, como a falha de hardware ou energia não redundante. Nessas situações, o servidor é perdido e o objetivo é que o Clustering de Failover detecte rapidamente a perda do servidor e se recupere rapidamente em outro servidor no cluster. Para realizar essa recuperação rápida de falhas graves, as configurações padrão para monitoramento de integridade do cluster são bastante agressivas. No entanto, eles são totalmente configuráveis para permitir flexibilidade para vários cenários.

Essas configurações padrão oferecem o melhor comportamento para a maioria dos clientes; No entanto, à medida que os clusters são estendidos de polegadas para possivelmente quilômetros de distância, o cluster pode ficar exposto a mais componentes de rede potencialmente não confiáveis entre os nós. Outro fator é que a qualidade dos servidores comuns está aumentando constantemente, juntamente com a resiliência aumentada por meio de componentes redundantes (como fontes de alimentação duplas, agrupamento de NIC e E/S de vários caminhos), o número de falhas de hardware não redundantes pode ser bastante raro. Como as falhas graves podem ser menos frequentes, alguns clientes podem querer ajustar o cluster para falhas transitórias, em que o cluster é mais resiliente a breves falhas de rede entre os nós. Ao aumentar os limites de falha padrão, você pode diminuir a sensibilidade a breves problemas de rede que duram um curto período de tempo.

É importante entender que não há uma resposta certa aqui, e a configuração otimizada pode variar de acordo com seus requisitos de negócios específicos e contratos de nível de serviço.

Virtualizando o SQL Server

Em ambientes virtuais, por motivos de desempenho, é recomendável armazenar o banco de dados operacional e o banco de dados do data warehouse em um armazenamento anexado diretamente e não em um disco virtual. Você pode usar o utilitário Auxiliar de Dimensionamento do Operations Manager lançado para o Operations Manager 2012 para estimar o IOPS necessário e testar o estresse de seus discos de dados para verificar. O desempenho do armazenamento pode ser testado com o utilitário DiskSpd. Consulte também Suporte à virtualização do Operations Manager para obter diretrizes adicionais sobre o ambiente virtualizado do Operations Manager.

Always On e modelo de recuperação

Embora não seja estritamente uma otimização, uma consideração importante em relação ao Grupo de Disponibilidade Always On é o fato de que, por design, esse recurso requer que os bancos de dados sejam definidos no modelo de recuperação "Completo". Ou seja, os logs de transações nunca são descartados até que um backup completo seja feito ou apenas o log de transações. Por esse motivo, uma estratégia de backup não é opcional, mas uma parte necessária do design AlwaysOn para bancos de dados do Operations Manager. Caso contrário, com o tempo, os discos contendo logs de transações serão preenchidos.

Uma estratégia de backup deve levar em conta os detalhes do seu ambiente. Um agendamento de backup típico é fornecido na tabela a seguir.

Tipo de backup Agenda
Somente log de transações A cada uma hora
Completo Semanalmente, domingo às 03:00

Otimizando os serviços de relatórios do SQL Server

A instância do Reporting Services atua como um proxy para acesso aos dados no banco de dados do Data Warehouse. Ele gera e exibe relatórios com base em modelos armazenados nos pacotes de gerenciamento.

A função de Relatório do Operations Manager não pode ser instalada lado a lado com uma versão anterior da função de Relatório e deve ser instalada somente no modo nativo (não há suporte para o modo integrado do SharePoint).

Nos bastidores do Reporting Services, há uma instância de Banco de Dados do SQL Server que hospeda os bancos de dados ReportServer e ReportServerTempDB. Aplicam-se recomendações gerais sobre o ajuste de desempenho desta instância.

Observação

No SQL Server Reporting Services (SSRS) 2017 versão 14.0.600.1274 e posterior, as configurações de segurança padrão não permitem uploads de extensão de recurso. Isso leva a exceções ResourceFileFormatNotAllowedException no Operations Manager durante a implantação de componentes de relatório.

Para corrigir isso:

  1. Abra o SQL Management Studio.
  2. Conecte-se à sua instância do Reporting Services.
  3. Clique com o botão direito do mouse na instância do servidor na janela Pesquisador de Objetos.
  4. Selecione Propriedades.
  5. Selecione Avançado na barra lateral esquerda.
  6. Adicione *.* à lista de AllowedResourceExtensionsForUpload.

Como alternativa, você pode adicionar a lista completa de extensões de relatório do Operations Manager à lista de permissões no SSRS. A lista é descrita na "Resolução 2" aqui: Falha na implantação dos relatórios do Operations Manager

Próximas etapas

Para entender como configurar a hospedagem do Data Warehouse (de Relatórios) atrás de um firewall, consulte Conectar o Data Warehouse (de Relatórios) em um firewall.