O operador do Kubernetes pode migrar uma implantação que o Ops Manager ou o Cloud Manager gerencia em máquinas virtuais ou bare metal para o Kubernetes. A migração é ao vivo e incremental. Sua implantação continua atendendo a leituras e a gravar durante todo o processo. Você move os nós das máquinas virtuais para o Kubernetes um de cada vez, usando a replicação normal do MongoDB.
Como funciona a migração
A migração depende da replicação padrão do MongoDB em vez de uma ferramenta de cópia de dados. Ela ocorre em três fases:
Ampliar. Você adiciona membros do Kubernetes ao conjunto de réplicas existente. O Operador Kubernetes cria os novos nós como nós não votantes, e eles realizam uma sincronização inicial a partir dos nós existentes.
Promova. Você transfere os votos e a prioridade dos nós da máquina virtual para os nós do Kubernetes. Os nós externos mantêm os votos e a prioridade que já possuem na configuração de automação de origem até que você os remova.
Prune. Você remove os nós da máquina virtual um por um, esperando que o conjunto de réplicas atinja o estado de meta entre cada remoção.
A migração está concluída quando o operador do Kubernetes gerencia 100% dos nós, spec.externalMembers está vazio e todos os dados residem em declarações de volume persistente do Kubernetes. Nesse ponto, nenhum nó permanece em máquinas virtuais.
Por que a migração não usa restaurar snapshot ou o Cluster-to-Cluster Sync
O fluxo de trabalho de migração não restaura um snapshot e não usa mongosync ou outra ferramenta de Cluster-to-Cluster Sync. As FERRAMENTAS Cluster-to-Cluster Sync impõem tempo de inatividade na transição, não têm suporte para coleções de séries temporais e geralmente exigem ajuda de campo para executar com segurança. A migração baseada em replicação evita essas limitações. Sua implantação permanece disponível, a migração oferece suporte aos mesmos tipos de coleção que o restante da sua implantação e você mesmo conduz o processo com o plugin kubectl mongodb.
Disponibilidade durante a migração
As leituras continuam disponíveis ao longo da migração. As gravações podem falhar brevemente durante as eleições; portanto, seus drivers devem usar gravações repetíveis. A latência de leitura pode aumentar se um destino de leitura se mover, portanto, execute o cluster Kubernetes na mesma região que as máquinas virtuais. Cursores de longa duração em um secundário migrado quebram porque não há modo de hibernação.
A operação híbrida é transitória
Enquanto a migração está em andamento, sua implantação é executada em um estado híbrido com nós em divisão entre máquinas virtuais e Kubernetes. O Kubernetes operador oferece suporte a esse estado híbrido apenas como uma condição transitória durante uma migração ativa. A migração requer conectividade de rede bidirecional permanente entre os dois ambientes durante o período. O operador do Kubernetes não oferece suporte à execução de uma implantação de ambiente dividido indefinidamente.
O que a migração não faz
O Kubernetes operador não:
Desative as máquinas virtuais. Você os desativa você mesmo após a conclusão da migração.
Reverter uma migração. Não existe uma maneira automatizada de reverter uma migração depois que ela é iniciada.
Faça o seed ou a pré-cópia dos dados. Toda a movimentação de dados ocorre por meio da replicação do MongoDB.
Migre o Ops Manager ou o Cloud Manager. Apenas a implantação do MongoDB é movida para o Kubernetes.