Esta é a segunda parte de um artigo de duas partes que aborda os detalhes essenciais da tecnologia de rebalanceamento do Couchbase. O primeira parte trata da mecânica básica e do histórico do processo de rebalanceamento. Nesta segunda parte, veremos mais detalhadamente como monitorar o processo de rebalanceamento e como interromper e lidar com problemas de rebalanceamento.
Monitoramento de um rebalanceamento
Além do monitoramento geral de um Membase/Couchbase, há algumas áreas específicas nas quais se concentrar durante um rebalanceamento. A maioria delas pode ser monitorada por meio da interface do usuário da Web e, mais especificamente, capturada pela observação das estatísticas subjacentes disponíveis em cada nó.
- Você pode monitorar por quantos (e quais) vbuckets um determinado nó é responsável e usar isso para ter uma ideia do progresso de um rebalanceamento
- Devido a um "backfill" em massa ou a leituras únicas para materializar os dados na RAM antes de enviá-los ao nó de destino.
- Combinado com a carga de tráfego normal, um reequilíbrio pode resultar em uma fila de gravação em disco muito maior, pois os dados são transferidos para a RAM mais rapidamente do que podem ser drenados para o disco. (*veja abaixo um bug/falha de projeto que está sendo resolvido no momento)
- Você deve ver um pouco de atividade aqui, e ela pode ser "explosiva" quando um vbucket é movido de um lugar para outro.
- É essencial para entender por si mesmo por que um rebalanceamento pode estar demorando mais do que o esperado. Você verá esses backoffs associados ao nó de destino (porque ele está registrando quantos enviou... ao contrário do nó de origem, que está sendo instruído a fazer backoff).
Por que meu rebalanceamento está demorando tanto?
Os clientes perguntam rotineiramente quanto tempo deve levar um rebalanceamento, e eu tenho que dizer constantemente que realmente não sei. Depende muito da quantidade de dados (número e tamanho de objetos individuais), da velocidade do disco (tanto de leitura quanto de gravação) e da carga da rede... sem mencionar a possibilidade de falhas nos nós e outras lentidões inesperadas ao longo do processo.
Em vez de tentar quantificar de forma confiável o tempo que um rebalanceamento levaria em condições cada vez mais variáveis, considero muito mais importante poder caracterizar e monitorar seu status. Conforme mencionado acima, o ideal é que um rebalanceamento não tenha um impacto material em seu aplicativo e, portanto, não importa realmente quanto tempo ele leva. Se houver um impacto percebido, será mais importante entender o motivo (e possivelmente resolver) do que tentar acelerar o processo de rebalanceamento em si.
A causa mais comum de lentidão geral é um disco lento no nó de destino, o que leva a backoffs do TAP.
*Bug atual/falha de projeto: nas versões 1.7.1.1 e posteriores, um nó pode começar a excluir dados antigos do disco enquanto ainda estiver recebendo novos dados. Em nossos testes iniciais, foi demonstrado que essa exclusão não leva muito tempo. Na realidade, descobrimos que, em determinadas condições (especialmente no EC2 da Amazon), isso pode levar muito mais tempo do que o esperado. Infelizmente, um nó não consegue realizar essas exclusões (em massa) e gravar ao mesmo tempo, o que pode acabar "deixando" o processo de gravação. Isso leva a uma fila de gravação em disco muito grande e, por fim, a um período prolongado de backoffs do TAP. Embora não seja catastrófico, pode ser desconcertante para o usuário em termos de um tempo de reequilíbrio muito prolongado e possível receio quanto à segurança dos dados. O comportamento está sendo (ou foi) corrigido na versão 1.7.2 para evitar que essa situação ocorra.
Desempenho durante um rebalanceamento
Por definição, um rebalanceamento não deve ter um impacto material sobre o desempenho do aplicativo. Na realidade, porém, uma operação de rebalanceamento aumenta a carga geral e a utilização de recursos de um sistema, de modo que determinados ambientes podem notar uma degradação. Nossa prática recomendada é realizar um rebalanceamento durante os níveis de tráfego mais baixos de um aplicativo, se possível.
As duas principais causas de um impacto no desempenho durante o rebalanceamento são a saturação da rede e a contenção de disco. Embora a utilização da CPU seja outra causa possível, é muito incomum que seja a única causa, exceto nas taxas de tráfego mais altas (várias centenas de milhares de operações por segundo) e geralmente está relacionada a alguma causa subjacente (como a espera de E/S do disco).
A saturação da rede deve ser bastante óbvia. Se o seu aplicativo já estiver levando o cluster para perto da largura de banda da rede, um rebalanceamento provavelmente causará mais saturação, o que pode levar a tempos limite e erros. No momento, não permitimos (mas podemos permitir no futuro) a limitação da atividade de rede de um rebalanceamento.
A contenção de disco é um pouco mais difícil de ver e caracterizar. Isso remete a um dos principais benefícios do Membase/Couchbase Server, a separação da RAM da E/S do disco. Ao servir o máximo possível a partir da RAM, o software mascara qualquer lentidão no nível de E/S do disco. Normalmente, o disco é muito mais lento do que a RAM, mas quando uma carga maior é exigida de um disco, ele fica ainda mais lento. O rebalanceamento é um desses aumentos de carga. Se o seu aplicativo estiver lendo todos os dados da RAM, você não deverá ver nenhum impacto aqui. No entanto, se muitas solicitações (e "muitas" é subjetivo) estiverem sendo atendidas a partir do disco porque não estão armazenadas em cache na RAM, o desempenho pode e será prejudicado. Você pode atenuar isso com mais RAM, mas isso nem sempre é prático e, portanto, às vezes é apenas uma questão de estar ciente do que está acontecendo.
Interromper um rebalanceamento
Como cada vbucket é movido individualmente, um rebalanceamento pode ser interrompido (manualmente ou por causa de alguma falha) sem a necessidade de refazer todo o processo. Você pode simplesmente reiniciar o rebalanceamento e ele será retomado de onde parou.
Há duas ressalvas quanto a isso, considerando o estado atual do software:
- Se você estiver removendo nós com um rebalanceamento e esse rebalanceamento for interrompido, será necessário remover novamente os nós antes de iniciar o rebalanceamento novamente. O cluster não "lembra" o que você estava fazendo da última vez, portanto, é importante lembrá-lo.
- É uma prática recomendada esperar pelo menos 5 minutos antes de reiniciar um rebalanceamento (independentemente do motivo pelo qual ele foi interrompido). Isso permite que as várias conexões entre os nós sejam limpas adequadamente. Versões posteriores do software realmente imporão esse limite (por meio da interface do usuário da Web, que pode ser substituída pelo uso da API CLI/REST, se desejado... mas não faça isso a menos que lhe digamos para fazê-lo ;-)
Se um rebalanceamento parar no meio da movimentação de um determinado vbucket (como provavelmente aconteceria), não há com o que se preocupar. Essa movimentação específica é "cancelada" simplesmente deixando o vbucket original como ativo. Nada mais é necessário.
Falhas de reequilíbrio
O que você deve fazer quando um rebalanceamento falhar? O ideal é retomar o rebalanceamento em pouco tempo, se isso fizer sentido (novamente, espere pelo menos 5 minutos). Isso depende muito da natureza da falha. Quando ocorre uma falha de rebalanceamento, você deve tentar descobrir a causa e também o estado atual do cluster.
Embora, obviamente, nos esforcemos para corrigir todos os bugs do software, inevitavelmente haverá situações em que o rebalanceamento falhará. Os dois motivos mais comuns são timeouts ou travamentos.
Um timeout será gerado quando um determinado nó demorar a responder (ou não responder após um período de tempo) e, geralmente, é causado por lentidão na rede ou no disco. Você também verá um timeout se um nó falhar, mas somente se isso acontecer de uma forma que o outro lado não consiga descobrir o que aconteceu. Nesse último caso, um timeout pode, na verdade, mascarar algum outro problema mais grave.
Uma falha (seja de um processo interno, como o memcached, ou de algum componente externo do sistema, como o kernel) também resultará em uma falha no rebalanceamento.
Os registros terão algumas (esperamos que uma quantidade substancial) informações sobre a falha em si. Eles dirão algo como "timeout" (o mesmo que "wait for memcached failed") ou "some process exited unexpectedly". Embora essas informações sejam úteis, especialmente para a investigação do suporte, a causa é muito menos importante do que o estado atual do cluster.
Você deseja avaliar imediatamente se é ou não necessária alguma ação adicional antes de retomar o rebalanceamento. O diagnóstico principal é determinar se todos os nós do cluster ainda estão íntegros e capazes de fornecer dados. Se estiverem, ótimo. Caso contrário, você precisa resolver essa situação primeiro. Não vou abordar essa atividade mais geral de solução de problemas aqui, mas você já entendeu a ideia. Você pode ter certeza de que os dados estão seguros (e que um failover é possível, se necessário).
Resumindo
Se você acompanhou este artigo e o Primeira postagem sobre rebalanceamento então você sabe praticamente tudo o que há para saber sobre o processo de rebalanceamento. Mais importante ainda, agora você deve estar em condições de fazer uma suposição fundamentada sobre os efeitos e as necessidades de fazer um rebalanceamento e como isso afetará suas implementações e operações dos clusters do Couchbase e do Membase.
