Nesta postagem, vou dar uma olhada em um aplicativo de amostra que usa o Servidor Couchbase Cliente Java MCA (Multi-Cluster Aware). Esse cliente anda de mãos dadas com a Replicação entre centros de dados do Couchbase (XDCR).
O XDCR oferece suporte à replicação flexível de dados entre diferentes clusters. O XDCR é um recurso importante para implementações em larga escala e em vários data centers. As referências abaixo incluem várias referências sobre o XDCR. O cliente MCA pode redirecionar automaticamente o tráfego para esses clusters separados com base na configuração da biblioteca, aliviando o desenvolvedor do aplicativo do gerenciamento de grande parte da complexidade envolvida.
Esses e outros recursos permitem que as implantações do Couchbase ofereçam suporte a uma variedade de alta disponibilidade e estratégias de recuperação de desastres. Para saber mais antes de se aprofundar nas especificidades do cliente, dê uma olhada nestes recursos:
Introdução ao Couchbase HA/DR Documentação de alta disponibilidade/recuperação de desastres
Couchbase XDCR - Documentação do XDCR
Webinar sobre XDCR/MCA (incluindo demonstração técnica) - Webinar sobre HA/DR
Tutorial do webinar - Configuração de clusters passo a passo, com o XDCR
Um olhar mais profundo sobre o XDCR - Mergulho profundo na replicação entre data centers (XDCR) por Denis Rosa
Configurando o XDCR usando o Docker - Replique dados NoSQL entre datacenters com o Couchbase XDCR por Nick Raboy
Vídeo curto sobre a configuração do XDCR usando o Docker - Use o XDCR para replicar dados NoSQL entre contêineres do Docker do Couchbase - Tutorial em vídeo por Nick Raboy
Detalhes do cliente MCA em resumo
O MCA Java SDK se baseia no padrão SDK Java do Couchbase. A API principal imita principalmente a do cliente padrão.
- A capacidade de priorizar uma lista de clusters.
- Formas de fornecer regras sobre o que constitui uma falha.
- APIs para coordenar as instâncias do cliente.
- Uma interface de gerenciamento.
Discutiremos os dois primeiros usando o exemplo de código. O gerenciamento ocorre de forma programática ou por meio de uma interface JMX. Isso permite que os administradores alternem os clusters na lista de prioridades. Está fora do escopo desta postagem.
O aplicativo de amostra
Para ilustrar o uso do cliente MCA, temos um aplicativo de amostra simples. O aplicativo executa um número configurável de threads em grupos. Um grupo simplesmente lê do banco de dados, um grava novos registros aleatórios, um lê documentos, modifica-os e grava-os de volta, e um executa um simples N1QL consulta. A ideia é fornecer uma variedade de cargas para aplicar em um cluster. Em este webinarNa seção "Failover", usamos esse aplicativo para ilustrar um comportamento simples de failover entre clusters.
Você pode encontrar o código completo, juntamente com instruções de construção e outros materiais no GitHub. Aqui está um exemplo de invocação em execução em dois clusters de 3 nós com 10 threads atualizando documentos.
|
1 |
java -frasco mca-1.0.jar -c 172.23.123.4,172.23.123.5,172.23.123.6:172.23.122.55,172.23.122.56,172.23.122.57 -b meu_bucket -i usuário -p senha -u 10 -l estatísticas |
Agora, vamos examinar as partes principais do código.
Passo a passo do código
O código do aplicativo, nesse caso, consiste em uma classe principal e algumas classes auxiliares simples. Quando temos a instância do cliente MCA, ela é usada quase exatamente como o cliente normal. Então, vou me concentrar apenas na configuração do cliente. O código vem da classe ClusterBasics classe.
Nós e agrupamentos de clusters
Os clusters são especificados na linha de comando como grupos de nós separados por dois pontos (:). Em cada grupo, os nomes dos nós ou os endereços IP são separados por vírgulas. Implicitamente, os clusters são especificados em ordem de prioridade. Esse bloco de código divide esse formato simples em conjuntos e cria uma especificação de cluster para cada cluster. (Uma especificação de cluster pode incluir um ID para facilitar a referência. Isso não é necessário aqui, mas vale a pena ressaltar).
|
1 2 3 4 5 6 7 8 |
Cordas[] agrupamentos = opções.stringValueOf("clusters").dividir(":"); Lista<ClusterSpec> especificações = novo ArrayList<>(agrupamentos.comprimento); para (Cordas agrupamento: agrupamentos) { Conjunto<String> nós = Matrizes.fluxo(agrupamento.dividir(",")).coletar(Colecionadores.toSet()); especificações.adicionar(ClusterSpec.criar(nós)); } |
Tipos de serviço do Couchbase
Falaremos sobre coordenação e monitoramento de falhas em breve. Você pode ajustar ambos por tipo de serviço. Neste exemplo, estamos usando a recuperação direta de chave/valor (ServiceType.BINARY) e consultas N1QL (ServiceType.QUERY). Essas duas linhas seguintes preparam um conjunto de tipos de serviço para uso posterior.
|
1 2 |
serviceTypes.adicionar(Tipo de serviço.BINÁRIO); serviceTypes.adicionar(Tipo de serviço.QUERY); |
Coordenação entre clientes
Em seguida, começamos a ver a diferença real nos recursos desse cliente. Coordenadores gerenciam a orquestração do comportamento entre as instâncias do cliente. Atualmente, apenas coordenadores isolados foram implementados, mas isso é apropriado para este caso. Outros mais sofisticados estão planejados para o futuro. Ainda assim, observando todas as opções, você pode ver que até mesmo um coordenador isolado permite um pouco de controle. Veja a seguir como criar um coordenador com algumas opções não padrão.
|
1 2 3 4 5 6 7 8 |
Coordenador coordenador = Coordenadores.isolado(novo Coordenador isolado.Opções() .clusterSpecs(especificações) .activeEntries(especificações.tamanho()) .failoverNumNodes(2) .período de carência(TEMPO LIMITE) .topologyBehavior(TopologyBehavior.WRAP_AT_END) .serviceTypes(serviceTypes) ); |
Notas de código (por número de linha):
- Criar um
Coordenador isoladocom as opções configuradas - Especifique os nós para cada membro dessa topologia
- Definir o número de clusters a serem considerados ativos
- Defina o número de nós individuais com falha antes que o cluster inteiro sofra uma falha completa
- Período de carência após a falha antes da troca de cluster
- Selecione o comportamento quando o final de uma topologia for alcançado. As alternativas incluem permanecer no cluster final ou inverter a lista. A melhor opção dependerá de seu cenário específico.
- Atribuir os serviços governados
Detecção de falhas
O cliente pode monitorar uma grande quantidade de informações durante a operação. Os detectores de falhas usam essa riqueza de informações que ocorrem nos bastidores. Eles a utilizam para sinalizar ao coordenador. O coordenador pode então decidir como responder.
A Detector de falha de monitoramento de tráfego observa as solicitações enviadas ao servidor. Você pode configurar os tipos de erros (exceções) a serem contados, o número limite de exceções, o intervalo de tempo em que elas devem ocorrer e muito mais. Na maioria das vezes, uso os padrões e apenas ajusto a contagem e o intervalo das operações com falha.
O cliente também tem visibilidade do que está acontecendo com os nós e com o cluster diretamente. Isso é capturado usando um NodeHealthFailureDetector. É melhor deixar algumas nuances para a documentação. Eu apenas uso os padrões aqui.
Por fim, você pode criar combinações de condições complexas usando ConjunctionFailureDetector e Detector de falha de disjunção. Pense nos detectores de conjunção como a realização de um "e" lógico dos detectores constituintes. A disjunção faz um "ou". Quero ser acionado em qualquer falha, portanto, conecto meu monitoramento de tráfego e de saúde em um Detector de falha de disjunção para obter o objeto detector final a ser entregue ao cliente.
|
1 2 3 4 5 6 7 8 9 10 11 |
Detector de falha de monitoramento de tráfego.Opções trafficOptions = Detector de falha de monitoramento de tráfego.opções() .maxFailedOperations(5) .intervalo de falha(60); Fábrica de detectores de falhas<TrafficMonitoringFailureDetector> tráfego = Fábricas de detectores de falhas.monitoramento de tráfego(coordenador, trafficOptions); NodeHealthFailureDetector.Opções healthOptions = NodeHealthFailureDetector.opções(); Fábrica de detectores de falhas<NodeHealthFailureDetector> saúde = Fábricas de detectores de falhas.nóSaúde(coordenador, healthOptions); DisjunctionFailureDetectorFactory detector = Fábricas de detectores de falhas.disjunção(tráfego, saúde); |
Notas de código (por número de linha):
- Instanciar e configurar o
Detector de falha de monitoramento de tráfegoopções - Corrigir o número de operações com falha necessárias para indicar um problema
- Defina o intervalo de tempo no qual as falhas serão armazenadas
- Criar um
Detector de falha de monitoramento de tráfegocom acesso à instância de fábricaCoordenadorpara acionar, e nossas opções - Criar um
NodeHealthFailureDetectorcom opções padrão - Defina a lógica final usando um
Detector de falha de disjunçãonovamente por meio de uma fábrica
Instanciação de cliente
Por fim, instanciamos um cliente e o usamos para obter uma instância de bucket. Para quem não está familiarizado com o Couchbase, os buckets são uma abstração organizacional de alto nível. Você pode pensar neles como algo entre uma tabela e um banco de dados completo.
O identificador do bucket é tudo de que precisamos para executar as cargas em nossos clusters. Um bucket de cliente com vários clusters permite que você especifique tempos limite para operações individuais. Para simplificar, envolvi a interface em uma fachada, aplicando apenas um tempo limite fixo a cada operação. Isso torna a interface idêntica à interface padrão.
|
1 2 3 4 |
Cliente MultiCluster cliente = novo Cliente MultiCluster(coordenador, detector); cliente.autenticar(opções.stringValueOf("id"), opções.stringValueOf("senha")); balde = novo BucketFacade(cliente.openBucket(bucketName, nulo), TEMPO LIMITE, TimeUnit.MILISSEGUNDOS); |
Concluindo
Isso é tudo sobre os novos conceitos necessários para começar a usar o cliente MCA. O restante do código analisa as opções, configura os threads solicitados e simplesmente os executa em loops. Há algumas estatísticas incluídas. Eu faço chamadas para obter os dados aleatórios para escrever e atualizar documentos, portanto, esse código não é otimizado para carga de condução. No entanto, ele pode fornecer algumas informações sobre o desempenho oferecido pelo Couchbase.
Novamente, para ver tudo isso em ação, além de como os clusters se comportam, confira a demonstração durante a segunda metade do este webinar.
A versão 1.0 do cliente MCA foi lançada recentemente. No momento, é um recurso exclusivo da Enterprise Edition, no momento em que este texto foi escrito. Para saber mais e obter acesso ao cliente, fale com um representante de vendas do Couchbase (sales@couchbase.com). Você também pode entrar em contato comigo para obter mais informações, conforme descrito abaixo.
