Os balanceadores de carga são um componente essencial de qualquer configuração de banco de dados altamente disponível. Eles são usados para aumentar a capacidade e a confiabilidade de seus sistemas e aplicativos críticos, evitando que qualquer servidor fique sobrecarregado. Falamos muito sobre eles no blog do Variousnines, como por que você precisa deles e como eles funcionam. Um dos balanceadores de carga mais populares disponíveis para MySQL e MariaDB é o HAProxy.
Em termos de recursos, o HAProxy não é comparável ao ProxySQL ou MaxScale. No entanto, o HAProxy é um balanceador de carga rápido e robusto que funcionará perfeitamente bem em qualquer ambiente, desde que o aplicativo possa executar a divisão de leitura/gravação e enviar consultas SELECT para um back-end e todas as gravações e SELECT...FOR UPDATE para um Processo interno.
Acompanhar todas as métricas disponibilizadas pelo HAProxy é muito importante; você deve saber o estado do seu proxy, especialmente para saber se encontrou algum problema.
ClusterControl sempre disponibilizou uma página de status HAProxy mostrando o estado do proxy em tempo real. Agora, com os novos painéis SCUMM (Severalnines ClusterControl Unified Monitoring &Management) baseados em Prometheus, é possível rastrear facilmente como essas métricas mudam ao longo do tempo.
Esta postagem de blog explorará as diferentes métricas apresentadas no painel HAProxy SCUMM.
Explorando o painel HAProxy no ClusterControl
Todos os painéis do Prometheus e SCUMM são desabilitados por padrão no ClusterControl. No entanto, para implantá-los em qualquer cluster é apenas uma questão de um clique. Se você monitorar vários clusters com ClusterControl, poderá reutilizar a mesma instância do Prometheus para cada cluster.
Uma vez implantado, você pode acessar o painel HAProxy. Vamos dar uma olhada nos dados disponíveis no painel:
A primeira coisa que você verá ao navegar para o painel HAProxy é informações sobre o estado de seus back-ends. Aqui, observe que o que você vê pode depender do tipo de cluster e de como você implantou o HAProxy. Nesse caso, implantamos um cluster Galera e o HAProxy foi implantado de forma round-robin. Portanto, você vê três back-ends para leituras e três para gravações — seis no total. É também por isso que você vê todos os back-ends marcados como "Ativados".
Em um cenário com um cluster de replicação, as coisas parecerão diferentes, pois o HAProxy será implantado em uma divisão de leitura/gravação e os scripts manterão apenas um host (mestre) em execução no gravador Processo interno.
Aviso, é por isso que abaixo você vê dois servidores de back-end marcados como "Inativos":
No gráfico a seguir, você verá os dados enviados e recebidos por ambos backend (do HAProxy para os servidores de banco de dados) e frontend (entre o HAProxy e os hosts do cliente):
Você também pode verificar a distribuição de tráfego entre back-ends em sua configuração HAProxy. Nesse caso, temos dois backends e as consultas são enviadas pela porta 3308, que atua como ponto de acesso round-robin para nosso cluster Galera:
A seguir, você pode ver como o tráfego foi distribuído em todos os servidores de back-end. Nesse cenário — devido ao padrão de acesso round-robin — os dados foram distribuídos de forma mais ou menos uniforme em todos os três servidores Galera de back-end:
Informações sobre sessões, incluindo quantas sessões foram abertas do HAProxy para o back-end servidores, também podem ser monitorados, como pode ser visto no gráfico a seguir. Você também pode rastrear quantas vezes por segundo uma nova sessão foi aberta para o back-end e como essas métricas são exibidas por servidor de back-end.
Os dois gráficos a seguir mostram o número máximo de sessões por servidor de back-end e quando problemas de conectividade apareceram. Isso pode ser bastante útil para fins de depuração em que você encontra um erro de configuração em sua instância do HAProxy e as conexões começam a cair.
Este próximo gráfico é potencialmente mais valioso, pois mostra várias métricas relacionadas ao erro manipulação, como erros, erros de solicitação, tentativas no backend, etc. Há também um gráfico de “Sessões” mostrando uma visão geral das métricas da sessão.
Aqui você pode ver que o ClusterControl rastreia os erros de conexão em tempo real, o que pode ajudar a identificar o momento preciso em que os problemas começaram a evoluir.
Por último, veremos os dois gráficos a seguir relacionados a solicitações enfileiradas . O HAProxy enfileira solicitações para o back-end se os servidores de back-end estiverem supersaturados. Isso pode apontar para, por exemplo, os servidores de banco de dados sobrecarregados, que não podem lidar com mais tráfego.
Encerrando
Implantar e monitorar seu balanceador de carga HAProxy no ClusterControl pode ajudar a facilitar o trabalho de gerenciamento e monitoramento de suas conexões. Ter visibilidade clara do desempenho de seus back-ends, distribuição de tráfego, métricas de sessão, erros de conexão e o número de solicitações enfileiradas pode ajudar a garantir a disponibilidade e a escalabilidade de qualquer configuração de banco de dados.
O ClusterControl facilita muito a configuração e o monitoramento de balanceadores de carga para qualquer configuração de banco de dados. Ainda não está usando o ClusterControl? Se você quiser ver por si mesmo como é fácil implantar e monitorar seu balanceador de carga HAProxy com ClusterControl, estamos convidando você para uma avaliação gratuita de 30 dias da plataforma, sem compromisso. Para uma explicação mais detalhada de por que e como usar o HAProxy para balanceamento de carga, confira nosso tutorial sobre MySQL Load Balancing com HAProxy.
