Couchbase Operador autônomo A versão 1.1.0 foi liberado em 15 de novembro de 2018. Para a equipe do Kubernetes, é uma versão pequena, mas importante para melhorar a experiência do usuário final. Nesta postagem, vamos nos aprofundar nos detalhes do que foi alterado e por quê.
Serviços com estado e volumes persistentes
A versão 1.0.0 do Autonomous Operator permitia que servidores de um grupo específico de escalonamento de servidores fossem apoiados por armazenamento persistente. O suporte ao armazenamento persistente é essencial por vários motivos.
Os dados são a força vital de um banco de dados, e nós os levamos a sério. Eles registram quem são seus clientes, suas preferências para promoções direcionadas, suas transações e inúmeras outras informações críticas para os negócios. Se você perder esses dados, a empresa poderá ser afetada de forma negativa, desde penalidades financeiras até a perda de confiança do consumidor.
A plataforma Kubernetes que o Operador gerencia é, por design, baseada em recursos efêmeros que só estão disponíveis enquanto o processo que os requer estiver em execução. No entanto, o Kubernetes fornece volumes de armazenamento persistentes que permitem que aplicativos com estado, como a plataforma de dados Couchbase, restaurem os dados em caso de falha de um processo de servidor ou exclusão acidental.
Práticas recomendadas
É altamente recomendável que todos os grupos de dimensionamento que contenham dados de documentos ou serviços de índice usem armazenamento persistente. Ao fazer isso, os dados não são perdidos devido a uma falha e ficam disponíveis para uma instância de servidor substituta. O cluster inteiro pode ser restaurado após uma perda total de energia, o que não é possível sem o armazenamento persistente para registrar o estado do cluster. A recuperação de uma falha se torna muito mais rápida, pois o servidor substituto pode reutilizar dados e índices de documentos existentes, recuperando de réplicas o pequeno subconjunto de dados que foi modificado nesse ínterim. Como efeito colateral, os registros são mantidos no mesmo volume persistente que permite a recuperação, possibilitando o diagnóstico e uma solução para a causa raiz da falha.
Alguns grupos de escalonamento de servidores, como os que executam apenas o serviço de consulta, não dependem do armazenamento persistente para uma operação confiável. Esses serviços usam o estado fornecido pelos serviços de dados e índices atendidos por outros nós. Como resultado, não é necessário que os servidores sem estado usem armazenamento persistente. Sem persistência, os registros do servidor não poderão ser recuperados se um servidor sem estado falhar.
A versão 1.1.0 do Autonomous Operator resolve esse problema, permitindo que um volume de log leve seja anexado aos servidores.
Melhorias na coleta de registros
Em caso de falha do servidor, o volume de registro é detectado como órfão pelo Operador e retido para a coleta de registros. O cbopinfo A ferramenta de suporte do Couchbase foi aprimorada para detectar esses volumes de log e apresentá-los no momento da coleta de logs. A ferramenta de suporte coleta seletivamente os logs do servidor Couchbase de volumes de log persistentes e faz o download deles para a máquina local que executa o comando automaticamente.
A ferramenta de suporte agora redige os registros do servidor com informações potencialmente confidenciais. Tanto os registros redigidos quanto os simples estão disponíveis para o usuário. O usuário final pode escolher a versão a ser enviada à nossa equipe de suporte.
Melhorias na retenção de registros
O Operator apresenta uma nova política de retenção de registros que pode ser suficientemente controlada pelo administrador do cluster para limitar o uso de recursos. O Operator suporta a retenção de logs com base na número máximo de volumes de registro permitidos (os volumes mais antigos são excluídos primeiro se o número existente exceder esse valor) ou com base no duração do volume órfão. As políticas de retenção de registros evitam o uso excessivo de recursos e também ajudam o administrador a aderir à legislação de retenção de dados.
Aprimoramentos no gerenciamento de clusters
A ferramenta de gerenciamento de cluster, cbopctl também foi atualizado para ajudar os usuários finais a implementar clusters compatíveis. A presença do padrão ou registros montagens de volume em qualquer grupo de dimensionamento de servidor sinaliza a intenção de que o usuário final deseja que o cluster seja compatível. Essas montagens de volume não podem ser especificadas ao mesmo tempo. Além disso, cbopctl garante que todos os grupos de escalonamento de servidores sejam compatíveis, se pretendido, e os registros sempre estarão disponíveis para coleta por cbopinfo. Finalmente, o registros a montagem de volume não pode ser usada em grupos de dimensionamento que contenham o dados, índice ou análises serviços. Isso ajuda a evitar cenários de perda de dados, forçando o uso de padrão montagens de volume que o operador pode recuperar.
A ferramenta de gerenciamento de cluster ainda permite que o usuário crie clusters sem nenhum backup de volume persistente para avaliação. Conforme descrito, nessa configuração, o cluster não pode sobreviver a uma queda de energia, pode resultar em perda de dados e os problemas podem não ter suporte devido à ausência de logs do servidor Couchbase.
Links úteis
- Documentação de práticas recomendadas atualizada
- Documentação da ferramenta de suporte do Operador Autônomo do Couchbase
- Documentação da ferramenta de gerenciamento do Operador Autônomo do Couchbase
