“Vocês tornam tudo tão intuitivo e fácil demais que isso me dá confiança. Por que tudo não pode ser assim tão fácil?”
— Cliente anônimo
Na minha primeira postagem, nossa discussão sobre atualizações terminou com algumas ressalvas a serem levadas em conta em relação à replicação. Desta vez, vamos nos aprofundar em alguns pontos que chegam à equipe de sucesso do cliente e na melhor forma de lidar com eles.
Vamos retomar de onde paramos – o controle de versões. A partir da versão 5.0.1, o Qumulo aplica uma regra de dois lançamentos trimestrais no que diz respeito à replicação (como vocês devem se lembrar do mês passado, os lançamentos trimestrais são identificados pelo terceiro dígito sendo um 0). Se considerarmos a versão 5.3.0, isso se refere às duas versões trimestrais anteriores (5.1.0 e 5.2.0) e às duas versões trimestrais posteriores (6.0.0 e 6.1.0). É importante observar que uma versão com ponto decimal acima do .0 não está dentro desse intervalo. Usando nosso exemplo anterior de 5.3.0, 6.1.0 é o limite máximo, pois essa é a versão trimestral. 6.1.1 é um caso totalmente diferente no que diz respeito à replicação, e a versão 5.3.0 simplesmente se recusará a se comunicar com ela.
Você pode se perguntar: quais são minhas opções se, inadvertidamente, fizermos a atualização fora do período de dois trimestres? Nesse caso, você precisaria atualizar o lado de origem da relação. Nesse sentido, a equipe de Sucesso do Cliente da Qumulo costuma receber a pergunta: “Devo pausar a replicação durante a atualização?” Não, senhor, você não deve. O mecanismo de replicação é muito inteligente e retomará a replicação assim que a atualização for concluída. Quando se trata de atualizações e replicações, não há nada a fazer a não ser simplesmente executá-las.
Outra dúvida que surge na equipe de Sucesso do Cliente diz respeito a alterações na fonte — como renomear um diretório de origem. Digamos, por exemplo, que estejamos replicando `/financials/current_fiscal` e queiramos renomeá-lo para `/financials/FY2023`. Será que vamos acabar replicando todos os dados novamente? De jeito nenhum. Como alteramos o nome, isso acionará uma verificação, mas não fará com que nada seja replicado novamente. Em vez disso, nos logs de replicação, você verá o valor “Skipped” aumentar à medida que o “pequeno mecanismo de replicação que dá conta do recado” percorre os dados e garante que nada esteja aguardando para ser transferido.
O que acontece se você tiver uma estrutura de diretórios como `/zoo/animals/mammals/capybara`, mas quiser definir uma política especial apenas para “mammals”? O sistema copiará essa estrutura de diretórios automaticamente ou você precisará criá-la? Nossa equipe de desenvolvimento estava de olho em você naquele dia — o mecanismo de replicação do Qumulo criará os diretórios anteriores para você, recriando a árvore como ‘/zoo/animals/mammals/’ no destino assim que a política entrar em vigor.
Vamos parar um momento para discutir as políticas. Preciso de políticas de snapshot? De jeito nenhum. Você pode configurar uma relação de replicação contínua básica sem a necessidade de políticas. Se faz sentido ou não fazer isso sem uma política é uma decisão comercial. No entanto, normalmente recomendamos o uso de políticas — principalmente para fins de configuração avançada.
Com as políticas, você pode configurar a replicação como “política + contínua”. Isso permitirá que você crie e transfira instantâneos na origem em horários específicos, além de definir um prazo de validade para os instantâneos no lado de destino. Sem uma política, você ficará limitado a um único instantâneo de replicação no lado de destino (a menos que habilite a criação de instantâneos nesse local). À medida que aumentar o número de replicações para o seu site de recuperação de desastres, provavelmente será interessante avaliar a implementação de políticas, caso ainda não tenha feito isso.
Por fim, vamos considerar os usuários locais e a replicação. Se você tiver usuários locais definidos no cluster de origem, é necessário definir os mesmos usuários locais no cluster de destino? Como prática recomendada, você deve fazê-lo. O cluster fará referência ao UID do NFS caso tenham sido definidas permissões locais nos arquivos. Ao replicar esses usuários, se o UID não estiver definido no lado de destino, o cluster não saberá quem deve receber as permissões, interromperá a replicação e exibirá um erro mais ou menos assim:
“Última tentativa: /data/ não pode ser replicado porque pertence a um usuário local. Remova todos os usuários e grupos locais do arquivo ou certifique-se de que todos os usuários e grupos locais tenham IDs NFS associados e edite a relação para habilitar o mapeamento de IDs locais para IDs NFS.”
Você também precisará verificar os usuários locais no servidor de origem (Cluster -> Usuários e Grupos Locais) e recriá-los no servidor de destino. Na relação, será necessário editá-la para marcar a caixa de seleção “Mapear IDs de usuários/grupos locais para IDs NFS associados”. O mecanismo de replicação tentará novamente automaticamente após 60 segundos; portanto, desde que você tenha feito tudo corretamente, a replicação será retomada e continuará normalmente.
Esperamos que isso tenha esclarecido algumas dúvidas sobre a replicação e como ela se relaciona com o seu cluster do Qumulo. Como sempre, se tiver alguma dúvida, não hesite em entrar em contato pelo seu canal do Slack, e o seu simpático engenheiro de sucesso do cliente da Qumulo terá prazer em ajudar. Volte em breve, e vamos mergulhar no maravilhoso mundo dos snapshots.
Até a próxima!