Replicação entre data centers - Um guia passo a passo para o Amazon AWS

Um dos novos recursos mais interessantes do Couchbase Server 2.0 é a adição da XDCR (Cross Data Center Replication). Com esse recurso, você pode aumentar a confiabilidade do seu aplicativo operando em vários data centers e melhorar o desempenho dos seus usuários armazenando os dados mais perto do local físico deles.

Começar a usar o Cross Data Center Replication é fácil, e Amazon EC2 é um ótimo lugar para fazer um test drive.

Infraestrutura

Primeiro, precisaremos de dois clusters do Couchbase em regiões separadas. Optei por usar as regiões Leste dos EUA (N. Virgínia) e Oeste dos EUA (N. Califórnia). Em cada região, provisionei 2 servidores (m1.large) que executam a AMI padrão do Amazon Linux. Depois que os servidores forem provisionados, você precisará instalar o Couchbase Server 2.0 beta em cada servidor.

IMPORTANTE: Há uma alteração substancial que deve ser feita em cada servidor. Por padrão, o Couchbase Server identificará o endereço IP local do servidor e o usará para toda a comunicação do cluster. Isso funciona bem dentro da região, mas não funcionará na Internet. Para contornar esse problema, configuraremos o Couchbase para usar explicitamente o nome DNS público fornecido pela Amazon para cada servidor. Isso resolverá corretamente o endereço IP interno para a comunicação intracluster e o endereço IP público para a comunicação intercluster.

1. Parar o servidor
   sudo /etc/init.d/couchbase-server stop
2. Edite o arquivo /opt/couchbase/bin/couchbase-server
3. Localize a última linha na seção _start
4. Adicione um " ao final da linha
   …
5. Adicione uma nova linha imediatamente depois, onde se lê:
   -nome ns_1@
6. Exclua os arquivos em:
   • /opt/couchbase/var/lib/couchbase/data/*
   • /opt/couchbase/var/lib/couchbase/mnesia/*
   • /opt/couchbase/var/lib/couchbase/config/config.dat
7. Iniciar o servidor
   sudo /etc/init.d/couchbase-server start

Uma boa maneira de verificar se os servidores foram configurados corretamente com o nome DNS público é examinar a guia Servidor na interface do usuário do Couchbase Server. Você deve ver os servidores listados com seus nomes de DNS; se vir os endereços IP privados, verifique novamente as etapas anteriores.

Carregar conjunto de dados de amostra

Para que tenhamos alguns documentos para replicar, carregarei o conjunto de dados da amostra de cerveja no cluster da costa leste.

Vá para o Oeste, Jovens Documentos

Vamos começar com uma replicação unidirecional do cluster da costa leste para o cluster da costa oeste. Navegarei até a guia XDCR do meu cluster da costa leste. Pressione o botão "Create Cluster Reference" (Criar referência de cluster). No campo IP/nome do host, certifique-se de usar o nome DNS público de um dos servidores no cluster remoto.

Agora, pressione o botão "Create Replication" (Criar replicação). Selecione o bucket "default", o cluster "WestSide" e digite "default" para o cluster remoto.

Não se assuste, a coluna de status continuará dizendo "Starting Up", o que é normal. Nesse momento, todos os documentos do cluster da costa leste serão replicados para o cluster da costa oeste.

Agora vamos navegar até a guia "Data Buckets" (Compartimentos de dados). Clique no bucket "default". Role para baixo até a parte inferior e expanda a seção denominada "Outgoing Replication" (Replicação de saída).

Inicialmente, a fila de alterações será alta, e os documentos verificados e replicados serão 0. À medida que a replicação prossegue, a fila de alterações será drenada para 0 e os documentos verificados e replicados se estabelecerão na contagem total de documentos. Esta é a aparência quando a replicação dos documentos é concluída (OBSERVAÇÃO: as replicações do XDCR são contínuas; embora tenha terminado de replicar todas as alterações até o momento, ele continuará executando e transferindo alterações futuras)

Vamos dar uma olhada no cluster da costa oeste na interface do usuário do Couchbase Server.

A contagem de documentos no bucket padrão corresponde ao valor do cluster da costa leste. A replicação entre os data centers está funcionando!

Viagem de ida e volta

Muitos casos de uso exigem replicação bidirecional, portanto, vamos configurar a replicação da costa oeste de volta para a costa leste. As etapas são as mesmas de antes, apenas os nomes do cluster e do DNS mudam. Novamente, certifique-se de usar os nomes DNS públicos dos servidores da Amazon.

Para testar se a replicação bidirecional está funcionando, precisamos fazer uma alteração nos dados deste lado.

Após minha apresentação na CouchConf SF, recebemos um tweet de @PabstBlueRibbon informando que nosso conjunto de dados de amostras de cerveja precisa de uma atualização.

Então, vamos cuidar disso agora. Em nosso conjunto de dados, o valor atual é 0. Vou editar o documento com ID 110fa43a2e e alterá-lo para 12.

Depois de salvar a alteração, se observarmos as estatísticas do bucket no cluster da costa oeste, veremos que a alteração está sendo replicada.
Observe como a fila de alterações subiu brevemente para 1, e vemos que o documento 1 foi replicado. Também vale a pena observar que, embora tenha verificado todos os documentos, ele replicou apenas o que foi alterado, o que mostra que o XDCR está verificando as revisões e replicando apenas os dados necessários.

Agora vamos carregar o documento no cluster da costa leste para verificar se funcionou.

Funcionou, o ibu está mostrando o valor 12 em ambos os clusters!

Práticas recomendadas

Tentei manter os exemplos aqui simples, mas há duas questões que você deve considerar antes de colocar isso em produção.

Nomes de servidores

No exemplo aqui, usei diretamente os nomes DNS públicos da instância do EC2. Isso não é recomendado na produção porque os endereços IP das instâncias da Amazon (e seus nomes DNS públicos associados) podem mudar. Recomendamos uma das duas opções:

• Use um serviço de DNS dinâmico de terceiros. Sempre que o endereço IP do servidor mudar, atualize um registro CNAME que aponte para o nome DNS público do seu servidor. É importante que esse seja um registro CNAME e que aponte para o nome DNS público, pois você precisa que o endereço seja resolvido para o endereço correto dentro e fora da Amazon.
• Use um Endereço IP da Amazon Elastic. Eles não custam nenhum dinheiro extra (quando em uso), mas talvez seja necessário solicitar mais da Amazon.

Segurança de dados

Os dados transferidos pelo XDCR são enviados sem criptografia e, ao replicar entre as regiões da Amazon, isso significa que eles estão transitando pela Internet pública.

• Você pode usar o XDCR para conectar clusters em diferentes zonas de disponibilidade sem transitar pela Internet pública. Isso não oferece tanta confiabilidade, mas evita o possível problema de segurança.
• Você pode usar um Serviço de VPN de terceiros para fazer o tunelamento de dados entre suas regiões da Amazon.

Mais informações

Esperamos que este tutorial tenha mostrado como você pode ter o XDCR instalado e funcionando em questão de minutos no AWS. Para obter mais informações sobre o Couchbase XDCR, consulte:

• Inscreva-se para participar do Webinar sobre XDCR em 17 de outubro