Serviços de aplicativos Capella é um backend de nuvem totalmente gerenciado para seus aplicativos front-end móveis, de desktop e de IoT. No outro extremo do espectro, o paradigma de "Computação de borda" tem ganhado muita força nos últimos anos. A computação de borda é uma topologia de computação distribuída que visa a aproximar a computação e o armazenamento da borda, que é essencialmente o local onde os dados são gerados e consumidos. Os aplicativos executados na borda se beneficiam das respostas em tempo real de baixa latência, da redução dos custos de largura de banda da rede para a nuvem e da adesão à privacidade dos dados e às restrições regulamentares que determinam que os dados confidenciais sejam processados na borda.
A computação de borda complementa a computação em nuvem. A nuvem continua a servir como a fonte da verdade. Os dados que são processados na borda são transmitidos para a nuvem para obter consistência e integridade dos dados. Então, como habilitamos essa topologia de implementação que combina o poder do ambiente de nuvem gerenciado da Capella com a implementação de borda autogerenciada no local? Isso é possível com o Replicação de gateway entre sincronizações que oferece sincronização segura e dimensionável de nível empresarial entre a nuvem couchbase e os clusters de borda.
Nesta postagem, apresentaremos um exemplo de como você pode configurar uma implantação híbrida entre uma implantação do App Services gerenciado pelo Capella e uma implantação do Couchbase Mobile autogerenciada.
Topologia de implantação híbrida e casos de uso
No contexto desta postagem, usamos a topologia de implementação híbrida para nos referirmos a uma topologia que consiste em um Capella App Services totalmente gerenciado que sincroniza dados com um ou mais clusters móveis autogerenciados do Couchbase. Um cluster móvel autogerenciado do Couchbase pode ser aquele implantado e gerenciado por um usuário em uma nuvem pública, nuvem privada, data center ou no local. Uma topologia híbrida simples é mostrada abaixo. Nesse modelo, os dados são armazenados e processados no Capella App Services, bem como no cluster móvel couchbase autogerenciado. Os dados são sincronizados entre a nuvem e o cluster de borda usando a Replicação do Gateway de Inter-Sync. Os aplicativos clientes móveis e de desktop podem sincronizar os dados com o Capella App Services ou com o cluster móvel autogerenciado do Couchbase.
Há vários casos de uso de implementações de nuvem distribuída, conforme descrito neste whitepaper. Eles incluem resiliência a interrupções na Internet e latência reduzida no processamento de dados.
Especificamente, a topologia de implantação híbrida oferece os seguintes benefícios
-
- Privacidade/Governança de dados: Cumprimento das políticas regulatórias que determinam que os dados confidenciais só devem ser armazenados e processados em data centers privados ou locais autogerenciados
- Migração em fases para o Capella: Não é tão óbvio, mas a topologia híbrida com o Capella simplificará a migração das implementações móveis existentes do couchbase no local para o Capella. Enquanto Migração baseada em XDCR permite uma migração única de clusters móveis no local para o Capella App Services, em que todos os clientes precisam mudar do cluster autogerenciado para o Capella. Por outro lado, uma topologia híbrida com uma Replicação de Gateway de Inter-Sync bidirecional permitirá uma migração em fases, permitindo que os clientes façam a migração ao longo do tempo.
- Serviços de borda de provedores de nuvem emergentes: Como os provedores de serviços em nuvem continuam a expandir sua infraestrutura para a borda com ofertas como Zonas locais da AWSOs usuários podem aproveitar essas ofertas conectando seus clusters móveis couchbase autogerenciados implantados na borda da rede do provedor de nuvem com o Capella App Services.
Configuração
Cluster ativo
O cluster do Sync Gateway no qual a replicação é inicializada ou agendada é o Cluster ativo. Pense nisso como sendo equivalente a um cliente em uma conexão cliente-servidor clássica que está inicializando uma conexão. Na implantação híbrida, isso corresponderia ao cluster autogerenciado do Couchbase Mobile. Em outras palavras, todas as replicações (bidirecionais e unidirecionais) são inicializadas no lado autogerenciado.
Cluster passivo
O cluster do Sync Gateway que é o alvo da replicação é o Cluster passivo. Pense nisso como sendo equivalente a um servidor em uma conexão cliente-servidor clássica que está ouvindo conexões de entrada.
Passo a passo
Vamos analisar um exemplo simples que demonstra como você pode configurar uma topologia híbrida com o Capella App Services. Por questões de brevidade, não abordaremos os detalhes de como você implementa e provisiona o Sync Gateway no local ou no Capella App Services. Se você for novo no Capella App Services, consulte a seção Primeiros passos com o App Services guia. Se você for novo no Couchbase Mobile, consulte Primeiros passos com o Sync Gateway guia.
Estado inicial
Para dar suporte à implantação híbrida com o Capella App Services, o Cluster ativo que é o cluster móvel autogerenciado DEVE estar executando as versões v3.0.5 ou v2.8.4 do Sync Gateway.
Cluster autogerenciado
Esta é a configuração do banco de dados do Sync Gateway no lado autogerenciado da implantação, conforme recuperado usando GET db ligar.
Solicitação
|
1 2 3 4 |
enrolar --localização --solicitação OBTER 'https://on-prem-syncgateway:4985/travel-sample/_config' \ --cabeçalho 'Accept: application/json' \ --cabeçalho 'Content-Type: application/json' \ --cabeçalho 'Authorization: Basic c2d3X2FkbWluOnBhc3N3b3Jk' |
Resposta
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
{ "servidor": "couchbases://on-prem-couchbase-server", "bucket" (balde): "amostra de viagem", "nome de usuário": "sgw_admin", "senha": "xxxxx", "name" (nome): "amostra de viagem", "sync": "\nfunction sync(doc, oldDoc) {\n if (doc.type) {\n channel(\"channel.\"+doc.type);\n }\n else {\n channel(\"!\");\n }\n}", "import_docs": verdadeiro, "cache": { "rev_cache": {}, "channel_cache": {} }, "sem suporte": { "warning_thresholds": { "xattr_size_bytes": 943718, "channels_per_doc": 50, "access_and_role_grants_per_doc": 50, "channels_per_user" (canais por usuário): 50000, "tamanho_do_nome_do_canal": 250 } }, "enable_shared_bucket_access": verdadeiro, "num_index_replicas": 0, "delta_sync": { "habilitado": verdadeiro } } |
Como você pode ver, a configuração é simples.
-
- Tenho um banco de dados do Sync Gateway chamado "amostra de viagem" com o apoio de um "amostra de viagem" no servidor Couchbase. O bucket "travel-sample" é um bucket de amostra que é carregado no servidor.
- "sgw_admin" é o usuário do gateway de sincronização que é usado para autenticar o Sync Gateway no servidor Couchbase.
- A função de sincronização faz o seguinte:
- Todos os documentos que têm um "tipo" são atribuídos a um canal correspondente a esse tipo de documento. Por exemplo, os documentos que têm uma propriedade "type": "airline" são atribuídos a um canal chamado "channel.airline", um documento que tem um "type": "airport" são atribuídos a um canal chamado "channel.airport" e assim por diante.
- Os documentos que não têm um "tipo" são atribuídas a um canal público.
O restante da configuração é padrão.
Serviços de aplicativos Capella
Esta é a configuração no lado do Capella App Services.
Eu tenho um Ponto de extremidade do aplicativo nomeado "amostra de viagem" que é apoiado por um banco de dados de "amostra de viagem". No meu exemplo, o banco de dados "amostra de viagemO banco de dados " é vazio.
O Função de controle de acesso é idêntica à Sync Function no lado autogerenciado.
Eu tenho um Usuário do aplicativo nomeado "demo@example.com" a quem é concedido acesso ao "channel.airline" (além do canal público "!" do sistema).
Configuração da replicação do Inter-Sync Gateway
O cluster móvel autogerenciado do Couchbase é o "cluster ativo" e é o cluster em que as replicações DEVE ser inicializado.
Vou inicializar uma replicação contínua e bidirecional chamada "pushandpull-with-target-continuous" no Sync Gateway autogerenciado usando o PUT _replicação API.
Solicitação
Validação da sincronização de dados
Por fim, como temos uma configuração de sincronização bidirecional entre o Capella App Services e um cluster autogerenciado, posso validar que as alterações de documentos feitas em um dos pontos de extremidade são sincronizadas com o outro lado.
Sincronização do cluster autogerenciado do Couchbase Mobile com o Capella App Services
As alterações em qualquer documento no autogerenciado são sincronizadas automaticamente com a nuvem, conforme demonstrado abaixo. Isso ocorre porque não temos nenhum filtro definido na replicação.
As alterações no documento no Couchbase Server autogerenciado (à direita) são sincronizadas com o Capella (à esquerda)
Sincronização do capella App Services com o cluster autogerenciado do Couchbase Mobile
Por outro lado, somente as alterações feitas em documentos que têm uma propriedade "tipo" de "companhia aérea" no Capella App Services são sincronizados com o cluster autogerenciado. A razão para isso é que o usuário do aplicativo no Capella App Services, "demo@example.com" tem acesso apenas ao "channel.airline". Portanto, o usuário do aplicativo só pode ler documentos de "tipo"igual a"companhia aérea“.
As alterações no documento no Capella (à esquerda) são sincronizadas com o Couchbase Server autogerenciado (à direita)
Monitoramento de réplicas
Quando suas configurações estiverem em funcionamento, você poderá monitorá-las por meio do status da replicação ponto final.
Recursos
Você pode Experimente os Serviços de Aplicativos Capella gratuitamente hoje mesmo e implemente topologias híbridas com clusters de borda autogerenciados.
Certifique-se de implantar as versões v3.0.5 ou v2.8.4 do Sync Gateway, que você pode baixar em nosso site página de downloads.
Se você quiser se aprofundar nos detalhes, veja aqui onde encontrar mais informações:
O Fóruns do Couchbase é um ótimo lugar para entrar em contato com perguntas. Deixe um comentário abaixo ou sinta-se à vontade para entrar em contato comigo via Twitter ou enviar-me um e-mail
Agradecimentos
Gostaria de agradecer a Mark Gamble por sua análise e feedback sobre a postagem do blog.
