{"id":1768,"date":"2014-12-16T18:41:44","date_gmt":"2014-12-16T18:41:44","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1768"},"modified":"2023-06-28T01:13:50","modified_gmt":"2023-06-28T08:13:50","slug":"rebalancing-couchbase-part-i","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/rebalancing-couchbase-part-i\/","title":{"rendered":"Rebalanceamento com o Couchbase - Parte I"},"content":{"rendered":"

Esta \u00e9 a primeira de duas postagens do blog que abordam alguns dos detalhes essenciais da tecnologia de rebalanceamento do Couchbase. Este primeiro post detalha a funcionalidade de rebalanceamento em si, e o segundo<\/a>\u00a0discute como monitorar e trabalhar com ele.<\/p>\n

Guia pr\u00e1tico de rebalanceamento com o Couchbase<\/h2>\n

Em meados de 2010, uma pequena empresa chamada NorthScale lan\u00e7ou um produto chamado Membase<\/a>. Entre os muitos recursos revolucion\u00e1rios estava a capacidade de aumentar (ou diminuir) dinamicamente um cluster de \"n\u00f3s\" (inst\u00e2ncias do software). Por defini\u00e7\u00e3o, essa \u00e9 uma opera\u00e7\u00e3o on-line, o que significa que n\u00e3o afeta a disponibilidade dos dados armazenados nesse cluster e n\u00e3o afeta materialmente o desempenho de um aplicativo que acessa esses dados.<\/p>\n

Avan\u00e7amos rapidamente at\u00e9 agora (final de 2011... ok, foi um avan\u00e7o r\u00e1pido). Desde ent\u00e3o, a empresa mudou de nome (duas vezes) para Couchbase e aprendeu muito sobre como o produto funciona \"no mundo real\". Ele est\u00e1 sendo implantado em ambientes drasticamente diferentes (pense em seu pr\u00f3prio data center versus a nuvem da Amazon) sob aplicativos drasticamente diferentes (pense em registro versus jogos sociais versus segmenta\u00e7\u00e3o de an\u00fancios). A mesma tecnologia de \"rebalanceamento\" est\u00e1 sendo empregada n\u00e3o apenas no Membase, mas tamb\u00e9m no futuro Couchbase Server 2.0. Achei que agora seria um bom momento para escrever este artigo bastante extenso para responder a muitas das perguntas que cercam esse processo, al\u00e9m de abordar alguns dos problemas conhecidos. A vers\u00e3o atual \u00e9 a 1.7.1.1, e ela percorreu um longo caminho desde a primeira vers\u00e3o beta da 1.6.0, naquele memor\u00e1vel ver\u00e3o de 2010.<\/p>\n

Chega de introdu\u00e7\u00e3o, vamos ver at\u00e9 onde podemos ir na toca do coelho...<\/p>\n

O que \u00e9 um rebalanceamento?<\/h2>\n

Vamos come\u00e7ar em um n\u00edvel mais alto. O rebalanceamento \u00e9 o processo de redistribui\u00e7\u00e3o de dados para n\u00f3s adicionados ou removidos em um cluster do Membase\/Couchbase Server.<\/p>\n

Parece bem simples, certo? Para o observador casual, \u00e9. E nossa inten\u00e7\u00e3o \u00e9 que seja. Assim como a maioria das outras tecnologias, \u00e9 preciso um pouco de complexidade para alcan\u00e7ar essa simplicidade (distra\u00e7\u00e3o total: https:\/\/plus.google.com\/112218872649456413744\/posts\/dfydM2Cnepe).<\/p>\n

Um n\u00edvel abaixo agora.<\/h3>\n

Para come\u00e7ar a entender como o Membase\/Couchbase Server funciona, o principal conceito subjacente \u00e9 o de vbuckets (https:\/\/dustin.github.com\/2010\/06\/29\/memcached-vbuckets.html). Um vbucket \u00e9 uma \"fatia\" l\u00f3gica de um conjunto de dados geral (no nosso caso, um bucket... desculpe a nomenclatura, mas ainda n\u00e3o t\u00ednhamos uma equipe de marketing de produto quando isso surgiu). H\u00e1 um n\u00famero est\u00e1tico desses vbuckets, e as chaves s\u00e3o criptografadas (usando CRC32) nessa lista est\u00e1tica. Dessa forma, voc\u00ea tem a garantia de que uma determinada chave sempre far\u00e1 hash para o mesmo vbucket. Cada vbucket \u00e9 ent\u00e3o atribu\u00eddo a um determinado servidor dentro do cluster. Com 256 vbuckets e um servidor, todos eles estariam no mesmo servidor. Com dois servidores, eles seriam compartilhados igualmente entre os dois com 128 buckets cada, quatro servidores receberiam 64 cada e assim por diante.<\/p>\n

Um \"mapa de vbucket\" \u00e9 simplesmente a enumera\u00e7\u00e3o dessa lista de vbuckets e dos servidores que os possuem.<\/p>\n

Estou ignorando propositalmente a replica\u00e7\u00e3o no momento... Voltarei a ela, mas n\u00e3o \u00e9 importante neste momento.<\/p>\n

Um rebalanceamento \u00e9 simplesmente (essa palavra novamente...) o processo de mover um determinado n\u00famero de vbuckets de alguns servidores para outros servidores. O objetivo final \u00e9 que cada servidor dentro do cluster termine com o mesmo n\u00famero de vbuckets. Isso garante que os dados sejam distribu\u00eddos uniformemente em todo o cluster e, portanto, o acesso do aplicativo a esses dados tamb\u00e9m seja balanceado de forma uniforme em todos os n\u00f3s do cluster.<\/p>\n

Est\u00e1 me acompanhando at\u00e9 agora? (se n\u00e3o estiver, envie um e-mail para perry@couchbase.com).<\/p>\n

E outro n\u00edvel.<\/h3>\n

Quando um rebalanceamento \u00e9 iniciado, um processo chamado \"orquestrador\" examina o mapa atual de vbuckets e o combina com qualquer adi\u00e7\u00e3o\/remo\u00e7\u00e3o de n\u00f3s para calcular como deve ser o novo mapa de vbuckets. Em seguida, o orquestrador come\u00e7a a iniciar a movimenta\u00e7\u00e3o de vbuckets de um n\u00f3 para outro. \u00c9 importante observar que o orquestrador simplesmente \"inicia o processo\" entre dois n\u00f3s, mas n\u00e3o transfere de fato os dados em si... isso \u00e9 propositalmente deixado para os n\u00f3s de origem e destino coordenarem para evitar gargalos ou pontos de falha. Do ponto de vista do orquestrador, n\u00e3o importa realmente se um n\u00f3 est\u00e1 sendo adicionado ou removido do cluster. De fato, v\u00e1rios n\u00f3s podem ser adicionados e\/ou removidos do cluster no mesmo rebalanceamento. Tudo o que est\u00e1 acontecendo \u00e9 que um novo mapa de vbucket est\u00e1 sendo calculado e os movimentos de vbucket iniciados para tornar esse mapa uma realidade.<\/p>\n

Cada vbucket \u00e9 movido individualmente e independentemente dos outros (v\u00e1rios podem ser e s\u00e3o movidos em paralelo, mas o ponto \u00e9 que n\u00e3o h\u00e1 rela\u00e7\u00e3o entre vbuckets exclusivos). O n\u00f3 de destino inicia um processo chamado 'ebucketmigrator' que abre uma conex\u00e3o TAP (https:\/\/www.couchbase.org\/wiki\/display\/membase\/TAP+Protocol) com um vbucket no n\u00f3 de origem. Essa conex\u00e3o tem sinalizadores espec\u00edficos que indicam que ela a) deseja todos os dados contidos nela e b) planeja \"assumir\" esse vbucket quando tudo estiver conclu\u00eddo.<\/p>\n

Essa \u00faltima parte informa ao n\u00f3 de origem para iniciar o processo de transi\u00e7\u00e3o assim que todos os dados forem enviados. (li\u00e7\u00e3o de hist\u00f3ria: o ebucketmigrator costumava se chamar vbucketmigrator, mas n\u00f3s o transferimos para a VM Erlang... da\u00ed o 'e')<\/p>\n

Enquanto cada vbucket est\u00e1 sendo movido, o acesso do cliente (leituras e grava\u00e7\u00f5es) ainda est\u00e1 indo para o local original. Depois que todos os dados s\u00e3o copiados, ocorre uma troca at\u00f4mica em que o local original diz \"n\u00e3o sou mais o mestre deste vbucket\" e envia um \"token\" para o vbucket rec\u00e9m-criado dizendo \"voc\u00ea \u00e9\". O vbucket original passa de ativo para morto, e o novo passa de pendente para ativo. Os clientes inteligentes e o Moxi s\u00e3o atualizados com um novo mapa de vbucket para saber que isso ocorreu e as solicita\u00e7\u00f5es de dados subsequentes s\u00e3o direcionadas para o novo local. (veja algumas se\u00e7\u00f5es abaixo para uma discuss\u00e3o ainda mais aprofundada sobre o comportamento do Moxi e do cliente inteligente)<\/p>\n

E agora o n\u00edvel inferior<\/h3>\n

Pelo menos at\u00e9 onde eu vou. Isen\u00e7\u00e3o de responsabilidade: este texto vai se tornar bastante t\u00e9cnico. Pule uma se\u00e7\u00e3o se estiver com pouco tempo.<\/p>\n

Conforme mencionado acima, o orquestrador direcionar\u00e1 o processo ebucketmigrator no n\u00f3 de destino para \"puxar\" um vbucket do n\u00f3 de origem por meio do TAP.<\/p>\n

Conex\u00f5es TAP no n\u00f3 de origem<\/h3>\n

Quando essa conex\u00e3o TAP \u00e9 iniciada com o n\u00f3 de origem, um \"cursor\" come\u00e7a a percorrer a tabela de hash dentro do vbucket espec\u00edfico. Paralelamente, um processo de \"backfiller\" \u00e9 iniciado e decide se os dados devem ser carregados em massa a partir do disco. Como voc\u00ea provavelmente sabe, o Membase\/Couchbase suporta perfeitamente a exist\u00eancia de mais dados no sistema do que a RAM dispon\u00edvel. Nesse caso, pode haver uma quantidade significativa de dados que precisam ser lidos do disco para serem transferidos para outro n\u00f3. O processo de backfiller analisa a \"propor\u00e7\u00e3o de itens residentes\" (quantidade de dados armazenados em cache na RAM e n\u00e3o armazenados). Se essa propor\u00e7\u00e3o for menor que 90%, ele carrega em massa todo o vbucket do disco em um buffer tempor\u00e1rio de RAM (h\u00e1 limites e retrocessos incorporados para garantir que a capacidade de RAM do n\u00f3 n\u00e3o seja excedida). Se a propor\u00e7\u00e3o de itens residentes for maior que 90%, esse processo n\u00e3o ocorrer\u00e1.<\/p>\n

\u00c0 medida que o cursor percorre a tabela de hash, ele come\u00e7a a transmitir as chaves e os documentos pela conex\u00e3o TAP. Qualquer coisa que j\u00e1 esteja armazenada em cache na RAM \u00e9 enviada muito rapidamente; qualquer outra coisa \u00e9 retirada do espa\u00e7o tempor\u00e1rio do buffer (se dispon\u00edvel) ou lida de uma \u00fanica vez no disco.<\/p>\n

Durante esse processo, as muta\u00e7\u00f5es nos dados que j\u00e1 foram enviados s\u00e3o transmitidas pelo fluxo TAP \u00e0 medida que ocorrem (tecnicamente, elas s\u00e3o enfileiradas, mas, de qualquer forma, isso acontece muito r\u00e1pido). As muta\u00e7\u00f5es nos dados que ainda n\u00e3o foram enviados s\u00e3o aplicadas somente ao vbucket de origem e ser\u00e3o coletadas quando esse documento espec\u00edfico for transmitido.<\/p>\n

Depois que todos os dados tiverem sido copiados e sincronizados, a transi\u00e7\u00e3o acontece. Tecnicamente, seria poss\u00edvel transmitir as altera\u00e7\u00f5es t\u00e3o rapidamente para um vbucket que ele nunca conseguiria recuperar o atraso e fazer a troca. Na pr\u00e1tica, isso nunca acontece. Qualquer pequeno atraso no lado do cliente entre as solicita\u00e7\u00f5es \u00e9 suficiente para que os \u00faltimos bits sejam transmitidos, e seria extremamente raro que a comunica\u00e7\u00e3o entre n\u00f3s fosse drasticamente mais lenta do que a comunica\u00e7\u00e3o entre cliente e servidor.<\/p>\n

Conex\u00f5es TAP no n\u00f3 de destino<\/h3>\n

Em geral, a extremidade receptora de uma conex\u00e3o TAP n\u00e3o \u00e9 tratada de forma muito diferente de um cliente comum que coloca dados no vbucket espec\u00edfico desse n\u00f3. H\u00e1 algumas exce\u00e7\u00f5es:<\/p>\n