MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Como otimizar o desempenho do ClusterControl e seus componentes

Monitoramento e gerenciamento são essenciais para qualquer ambiente de produção porque o desempenho é importante. Interfaces de usuário lentas que demoram ou não respondem, alertas atrasados ​​e tempos limite de trabalho de cluster quando o servidor está sem recursos são coisas que podem causar problemas. Existem maneiras de melhorar o desempenho do ClusterControl, especialmente se você estiver gerenciando vários clusters e cada cluster contiver vários nós. Este blog fornece algumas dicas de ajuste. Os pontos elaborados aqui são selecionados com base em nossa experiência em lidar com problemas de desempenho relatados por nossos usuários e clientes.

Como introdução, o ClusterControl consiste em vários componentes principais - uma aplicação web (frontend) baseada em PHP e vários processos daemonizados (backend). Eles aproveitam um banco de dados MySQL/MariaDB para armazenamento persistente. Você está controlando efetivamente seu cluster a partir do aplicativo da web, que será traduzido em uma série de chamadas de processo executadas pelos processos de backend para gerenciar e monitorar seus clusters de banco de dados.

Banco de dados MySQL

Os componentes do ClusterControl contam com um banco de dados MySQL ou MariaDB como o armazenamento persistente para monitorar os dados coletados dos nós gerenciados e todos os metadados do ClusterControl (por exemplo, quais tarefas existem na fila, agendamentos de backup, status de backup, etc.). Por padrão, o script do instalador instalará qualquer versão do repositório padrão do sistema operacional. A seguir está a versão do MySQL/MariaDB sendo instalada pelo instalador:


  • CentOS/Redhat 6 - MySQL 5.1

  • CentOS/Redhat 7 - MariaDB 5.5

  • Ubuntu 18.04 (Bionic) - MySQL 5.7

  • Ubuntu 16.04 (Xenial) - MySQL 5.7

  • Ubuntu 14.04 (Trusty) - MySQL 5.5

  • Debian 9 (Stretch) - MySQL 5.5

  • Debian 8 (Jessie) - MySQL 5.5

  • Debian 7 (Wheezy) - MySQL 5.5

O script do instalador faria alguns ajustes básicos, como configurar o local do datadir, a porta do MySQL, o usuário e o tamanho do buffer pool do InnoDB no início do estágio de instalação. No entanto, o ajuste pode não ser adequado depois que você tiver importado ou criado mais clusters/nós. Com um número maior de nós a serem monitorados e gerenciados, o ClusterControl usaria mais recursos, e a camada de banco de dados é geralmente o primeiro gargalo que os usuários encontram. Alguns ajustes adicionais podem ser necessários para conter a carga de entrada.

ClusterControl é inteligente o suficiente para detectar qualquer anomalia de desempenho escrevendo as seguintes linhas dentro de cmon_X.log (onde X é o ID do cluster):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

O acima significa simplesmente que foram necessários 220 ms (valor de soma) para carregar 70 valores para o componente "diskstat", onde a maior parte do tempo de processamento estava acontecendo no estágio de processamento SQL e 0 ms para analisar o conjunto de resultados SQL Isso conclui que a camada SQL levou a maior parte do tempo de processamento quando o ClusterControl tentou consultar o conjunto de dados.

Acreditamos que a maioria das consultas SQL executadas pelo ClusterControl são otimizadas adequadamente para uma única instância do MySQL e usam indexação adequada. Simplificando, se você vir algo como o acima aparecendo regularmente no arquivo de log, algumas melhorias na camada de banco de dados estão em ordem, conforme mostrado nas seções a seguir.

Ajustando o tamanho do pool de buffers do InnoDB

O tamanho do buffer pool é um componente importante e deve ser configurado antecipadamente para melhorar o desempenho do MySQL. Ele permite que o processamento do MySQL esteja acontecendo dentro da memória em vez de atingir o disco. Uma regra simples é verificar a taxa de acerto do InnoDB e procurar a seguinte linha na seção BUFFER POOL AND MEMORY:

Buffer pool hit rate 986 / 1000

A taxa de acerto de 986/1000 indica que de 1000 leituras de linha, foi possível ler a linha na RAM 986 vezes. Nas 14 vezes restantes, ele teve que ler a linha de dados do disco. Simplificando, 1000 / 1000 é o melhor valor que estamos tentando alcançar aqui, o que significa que os dados acessados ​​com frequência se encaixam totalmente na RAM.

Aumentar o valor innodb_buffer_pool_size ajudará muito a acomodar mais espaço para o MySQL trabalhar. No entanto, certifique-se de ter recursos de RAM suficientes com antecedência. Por padrão, o ClusterControl aloca 50% da RAM ao buffer pool. Se o host for dedicado ao ClusterControl, você pode até empurrá-lo para um valor mais alto, como 70%, desde que poupe pelo menos 2 GB de RAM para os processos e caches do sistema operacional. Se você não pode alocar tanto, aumentar a RAM é a única solução.

Alterar esse valor requer uma reinicialização do MySQL (anterior ao MySQL 5.7.5), portanto, a ordem correta de reinicialização do serviço será:
  1. Modifique o valor innodb_buffer_pool_size dentro de my.cnf.
  2. Interrompa o serviço CMON.
  3. Reinicie o serviço MySQL/MariaDB.
  4. Inicie o serviço CMON.

Ou simplesmente reinicie o host se você puder arcar com um tempo de inatividade mais longo.

Ajustando max_connections


Por padrão, o script do instalador configurará o valor max_connections até 512. Isso é bastante alto, embora sensato, já que o ClusterControl mal atinge 200 conexões no total, a menos que o servidor MySQL seja compartilhado com outros aplicativos ou você tenha dezenas de nós MySQL monitorados pelo ClusterControl (estamos falando de 30 nós e mais).

Um valor alto de max_connections desperdiça recursos e o ajuste do valor afetará a memória máxima configurada para o MySQL. Se for maior que a RAM do sistema, há uma chance de que o processo do MySQL Server termine com uma exceção OOM, se todas as conexões forem usadas.

Para verificar isso, basta procurar o status max_used_connections do MySQL. A seguir estão as conexões máximas já alcançadas pelo MySQL em um nó ClusterControl que monitora 2 clusters com 6 nós MySQL no total:
mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Um bom valor para começar é Max_used_connections x 2 e aumentá-lo gradualmente se o valor estiver crescendo consistentemente. A modificação da variável max_connections pode ser feita dinamicamente através da instrução SET GLOBAL.

Usando o arquivo de soquete MySQL


Por padrão, o script do instalador configurará automaticamente o seguinte valor de host dentro de cada arquivo de configuração do banco de dados ClusterControl:
Arquivo de configuração Valor
/etc/cmon.cnf mysql_hostname=127.0.0.1
/etc/cmon.d/cmon_X.cnf (X é o ID do cluster) mysql_hostname=127.0.0.1
/var/www/html/clustercontrol/bootstrap.php define('DB_HOST', '127.0.0.1');
/var/www/html/cmonapi/config/database.php define('DB_HOST', '127.0.0.1');

O acima forçará o cliente MySQL a se conectar via rede TCP, assim como conectar a um host MySQL remoto, embora o ClusterControl esteja sendo executado no mesmo servidor que o servidor MySQL. Nós o configuramos propositadamente dessa maneira para simplificar o processo de instalação, já que quase todas as plataformas de SO pré-configuram o arquivo de soquete MySQL de maneira diferente, o que reduz bastante a taxa de falha de instalação.

Alterar o valor para "localhost" forçará o cliente a usar o arquivo de soquete MySQL Unix:
Arquivo de configuração Valor
/etc/cmon.cnf mysql_hostname=localhost
/etc/cmon.d/cmon_X.cnf (X é o ID do cluster) mysql_hostname=localhost
/var/www/html/clustercontrol/bootstrap.php define('DB_HOST', 'localhost');
/var/www/html/cmonapi/config/database.php define('DB_HOST', 'localhost');

Em sistemas baseados em Unix, os programas MySQL tratam o nome do host localhost especialmente, de uma maneira que provavelmente é diferente do que você espera em comparação com outros programas baseados em rede. Para conexões com localhost, os programas MySQL tentam se conectar ao servidor local usando um arquivo de soquete Unix. Isso ocorre mesmo se uma opção --port ou -P for fornecida para especificar um número de porta.

Usar o arquivo de soquete MySQL UNIX é muito mais seguro e cortará a sobrecarga da rede. É sempre recomendado sobre TCP. No entanto, você precisa ter certeza de que o arquivo de soquete está configurado corretamente. Ele deve existir nas seguintes diretivas dentro de my.cnf e em todos os arquivos de opções do MySQL no nó ClusterControl, por exemplo:
[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

Alterar o arquivo de soquete também exigirá uma reinicialização do MySQL e do CMON. Se você estiver usando o "localhost", poderá adicionar algumas opções de configuração adicionais, como skip-networking=1, para evitar aceitar conexões remotas. Nossa imagem ClusterControl Docker está usando essa abordagem para superar uma limitação no docker-proxy ao vincular portas.

OpenSSH com SSSD


O ClusterControl utiliza o protocolo SSH como seu principal canal de comunicação para gerenciar e monitorar nós remotos. As configurações padrão do OpenSSH são bastante decentes e devem funcionar na maioria dos casos. No entanto, em alguns ambientes em que o SSH é integrado a outras ferramentas de aprimoramento de segurança, como SElinux ou System Security Services Daemon (SSSD), isso pode causar um impacto significativo no desempenho do SSH.

Vimos muitos casos em que uma quantidade cada vez maior de conexões SSH estabelecidas para cada um dos nós gerenciados e, eventualmente, tanto o servidor ClusterControl quanto todos os nós gerenciados maximizam a memória do sistema com conexões SSH. Em alguns casos, apenas uma reinicialização normal completa do sistema todas as noites no servidor ClusterControl poderia resolver o problema.

Se você estiver executando sua infraestrutura com o System Security Services Daemon (SSSD), é aconselhável comentar a seguinte linha dentro da configuração do cliente OpenSSH em /etc/ssh/ssh_config no nó ClusterControl:
#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

O acima irá pular o uso do SSSD para gerenciar a chave do host, que será tratada pelo cliente OpenSSH.

A partir do ClusterControl 1.7.0, você tem a opção de usar a ferramenta de monitoramento baseada em agente com o Prometheus. Com o monitoramento baseado em agente, o ClusterControl não usa SSH para amostrar métricas de host que podem ser excessivas em alguns ambientes.

Sistema de arquivos e particionamento


O controlador ClusterControl grava uma nova entrada em seu arquivo de log quase a cada segundo para cada cluster. Para aqueles que desejam aproveitar essas gravações sequenciais em disco e desejam economizar custos, você pode usar um disco de eixo para essa finalidade. Modifique a seguinte linha dentro de todos os cmon_X.cnf:
logfile=/new/partition/log/cmon_X.log

Substitua X pelo ID do cluster e reinicie o serviço CMON para aplicar as alterações.

Se você estiver usando o ClusterControl como repositório de backup, é recomendável alocar espaço em disco suficiente em uma partição separada que não seja a partição raiz. Fica melhor se a partição residir em um sistema de arquivos em rede ou em cluster para facilitar a montagem com os nós de destino ao executar a operação de restauração. Vimos casos em que os backups criados consumiram todo o espaço em disco da partição principal, acabando por impactar o ClusterControl e seus componentes.

Mantenha-se atualizado

O ClusterControl tem um ciclo de lançamento curto - pelo menos um novo lançamento importante a cada trimestre do ano, além de patches de manutenção semanais (principalmente correções de bugs - se houver). O motivo é que o ClusterControl oferece suporte a vários fornecedores e versões de banco de dados, sistemas operacionais e plataformas de hardware. Muitas vezes há coisas novas sendo introduzidas e coisas antigas sendo preteridas do que é fornecido. O ClusterControl precisa acompanhar todas as mudanças introduzidas pelos fornecedores de aplicativos e seguir sempre as melhores práticas.

Recomendamos que os usuários sempre usem a versão mais recente do ClusterControl (a atualização é fácil) junto com o navegador da Web mais recente (criado e testado no Google Chrome e no Mozilla Firefox), pois provavelmente estamos aproveitando os novos recursos disponíveis na versão mais recente.

Considerações finais

Se você tiver alguma dúvida ou encontrar algum problema ou lentidão ao usar o ClusterControl, entre em contato conosco através do nosso canal de suporte. Sugestões e comentários são muito bem-vindos.

Boa sintonia!