EventoObtenha 50% de desconto no seu ingresso para MongoDB.local Londres em outubro 2. Use o código WEB50Saiba mais >>
Desenvolvedor MongoDB
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
MongoDBchevron-right

Garantir alta disponibilidade para MongoDB no Kubernetes

Mercy Bassey11 min read • Published Jul 12, 2024 • Updated Jul 12, 2024
MongoDB
SNIPPET
Ícone do FacebookÍcone do Twitterícone do linkedin
Gráfico de Kubernetes e MongoDB
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Um banco de dados é uma coleção estruturada de dados que permite armazenamento, recuperação e manipulação eficientes de informações. Os bancos de dados são fundamentais para aplicativos modernos e oferecem suporte a funções críticas, como armazenamento de contas de usuário, transações e muito mais. Garantir a alta disponibilidade de um banco de dados é vital, pois o tempo de inatividade pode levar a interrupções significativas, perda de dados e impactos financeiros. A alta disponibilidade garante que um banco de dados permaneça acessível e funcional, mesmo diante de falhas de hardware, problemas de rede ou outras interrupções. Neste tutorial, vamos nos concentrar em obter alta disponibilidade com o MongoDB.
MongoDB, quando implantado no Kubernetes, pode aproveitar os recursos de orquestração e automação da plataforma para aumentar sua disponibilidade e resiliência. Com seus recursos robustos para gerenciamento, dimensionamento e recuperação de contêineres, o Kubernetes fornece um ambiente ideal para a implantação de instâncias MongoDB altamente disponíveis. Este tutorial guiará você pelas etapas necessárias para implantar o MongoDB no Kubernetes, configurá-lo para alta disponibilidade, configurar mecanismos de backup usando o mongodumpe implementar o dimensionamento automático para lidar com cargas de trabalho variáveis.

Pré-requisitos

Para acompanhar este tutorial, verifique se você tem:

Implementando o MongoDB

Para começar, você precisará definir os recursos e as configurações necessárias para implantar o MongoDB em seu cluster Kubernetes. Você criará um volume persistente para garantir que seus dados do MongoDB sejam mantidos mesmo que os pods sejam reagendados. Você também configurará um serviço headless para permitir uma comunicação de rede estável entre os pods do MongoDB. Por fim, você distribuirá o MongoDB usando um StatefulSet, que gerenciará a implantação e o dimensionamento dos pods do MongoDB enquanto mantém suas identidades exclusivas.
Observação: se quiser ler mais sobre os conceitos mencionados, você pode acessar a documentação do Kubernetes.
Adicione as seguintes definições de configuração em um arquivo chamado pv-pvc.yaml. Isso criará um volume persistente chamado mongodb-pv e uma reivindicação de volume persistente chamada mongodb-pvc:
O PersistentVolume (PV) fornecerá o armazenamento real, enquanto o PersistentVolumeClaim (PVC) solicitará o armazenamento a partir do VP disponível.
Execute os seguintes comandos para criar o PersistentVolume e oPersistentVolumeClaim:
Confirme que eles foram criados com os seguintes comandos:
Você deverá ver uma saída semelhante à seguinte, confirmando que PersistentVolume e PersistentVolumeClaim foram criados com sucesso:
Captura de tela representando que PersistentVolume e PersistentVolumeClaims foram criados
Captura de tela representando que PersistentVolume e PersistentVolumeClaims foram criados
Em seguida, crie um serviço headless para gerenciar identidades de rede estáveis para os pods MongoDB. Em um arquivo chamado headless-service.yaml, adicione a seguinte configuração; isto criará um serviço headless para seu MongoDB database chamado mongodb-service:
Aplique o serviço headless ao seu cluster Kubernetes usando o comando:
Confirme que o serviço headless foi criado usando o seguinte comando:
A seguinte saída é esperada:
Criando e visualizando serviço headless
Criando e visualizando serviço headless
Configure a autenticação para seu conjunto de réplicas MongoDB utilizando os seguintes comandos:
Configurar a autenticação para seu conjunto de réplicas MongoDB usando o mongodb-keyfile é crucial para proteger a comunicação entre os membros, evitar o acesso não autorizado e garantir que somente nós confiáveis possam ingressar no conjunto de réplicas, mantendo assim a integridade e a segurança dos dados.
Crie um segredo do Kubernetes para armazenar o arquivo de chave:
Por fim, crie um StatefulSet para implantar o MongoDB com armazenamento persistente e identidades de rede estáveis. Em um arquivo chamado statefulset.yaml, adicione a seguinte configuração:
Aplique o StatefulSet ao seu cluster Kubernetes:
Confirme que o StatefulSet foi criado com sucesso com todos os pods íntegros e em execução:
Você deverá ter a seguinte saída com o StatefulSet criando três pods do MongoDB denominados mongodb-0, mongodb-1 e mongodb-2:
Criar e visualizar Statefulsets e pods
Criar e visualizar Statefulsets e pods

Configuração de alta disponibilidade

Para garantir alta disponibilidade para seu banco de MongoDB database, você configurará um conjunto de réplicas. Um conjunto de réplicas no MongoDB é um grupo de instânciasmongod que mantém o mesmo conjunto de dados, fornecendo redundância e alta disponibilidade.
Antes de configurar o conjunto de réplicas, é útil ter alguns dados presentes. Esta etapa é opcional, mas ter dados em seu banco de dados ajudará você a entender o processo de backup com mais clareza nas subseções a seguir.
Primeiro, exec em um dos pods do MongoDB e inicialize o conjunto de réplicas. Normalmente, você usaria o primeiro pod (por exemplo, mongodb-0).
Você deve ver a seguinte saída:
Quando se trata de conjuntos de réplicas, a inserção ocorre apenas no primário. Como definimos o primeiro pod mongodb-0 para servir como principal, podemos fazer inserções. No entanto, se você não tiver certeza de qual pod é o principal, pode fazer isso usando o comando:
Mude para um banco de dados chamado “users” e insira alguns dados usando os seguintes comandos:
Observação: você pode usar o comandofind()para listar os usuários que acabamos de inserir. Esse comando pode ser executado em qualquer um dos membros do conjunto de réplicas, incluindo os pods secundários.
Depois de executar os comandos, você deverá ver as seguintes saídas indicando a inserção bem-sucedida dos documentos na collection femaleusersno banco de dadosusers:
Visualização da inserção bem-sucedida de documentos de usuário na collection FeminineUsers
Visualização da inserção bem-sucedida de documentos de usuário na collection FeminineUsers

Executando um backup com mongodump

Com alguns dados já inseridos em seu MongoDB database, agora você está pronto para iniciar a primeira etapa de alta disponibilidade do MongoDB database usando mongodump.
Primeiro, crie um PV e um PVC separados para armazenar backups adicionando as seguintes definições de configuração em um arquivobackup-pv-pvc.yaml:
Aplique isso com o seguinte comando:
Confirme se eles foram criados com os seguintes comandos:
Confirmando que o backup-pv e o backup-pvc foram criados
Confirmando que o backup-pv e o backup-pvc foram criados
Para fazer backup dos dados do MongoDB, você criará um Kubernetes CronJob que usará o utilitáriomongodump. Usar um CronJob aqui significa que você pode agendar quando deseja que os backups ocorram automaticamente.
Crie um arquivo denominado mongodb-backup-cronjob.yaml com o seguinte conteúdo:
Aplique a configuração para criar o CronJob e verifique se o CronJob foi criado:
Você deverá ver um resultado semelhante ao seguinte, confirmando que o CronJob foi criado com sucesso:
Confirmando que o CronJob foi criado
Confirmando que o CronJob foi criado
Após cinco minutos, você pode confirmar o status dos pods usando o seguinte comando:
Você deve ver um pod com um nome semelhante a este que foi criado pelo CronJob:
Visualizando o pod criado pelo CronJob
Visualizando o pod criado pelo CronJob
Para verificar se o backup foi criado com sucesso, verifique os registros do pod de backup:
A saída do log deve ser semelhante a esta:
Visualizando os registros do pod criado pelo CronJob
Visualizando os registros do pod criado pelo CronJob
Para acessar os arquivos de backup, é necessário visualizar o conteúdo do volume persistente onde os backups estão armazenados. Crie um pod temporário para acessar esses arquivos criando um arquivo chamado backup-access.yaml com o seguinte conteúdo:
Isso criará um busybox pod temporário que monta a reivindicação de backup-pvc volume persistente (PVC) no /backup diretório dentro do container, permitindo acessar e explorar os arquivos de backup armazenados no PV.
Aplique a configuração e acesse o pod temporário:
Uma vez dentro do pod, navegue até o diretório/backup para visualizar os arquivos de backup:
Você deve ver a seguinte saída:
Acessando usuários do backup
Acessando usuários do backup
Agora, saia do contêiner do busybox digitando exit.

Realização de testes de failover e recuperação

Para garantir a alta disponibilidade do seu conjunto de réplicas MongoDB, você precisa testar os processos de failover e recuperação. Esta seção orientará você a simular uma falha e a verificar se a configuração do MongoDB pode lidar com isso normalmente.
Em um conjunto de réplicas do MongoDB, um membro é o nó primário responsável por lidar com as operações de gravação, enquanto os outros membros são nós secundários que replicam dados do primário. Se o nó primário falhar, o conjunto de réplicas elegerá automaticamente um novo primário dos nós secundários restantes.
Observação: para saber mais sobre conjuntos de réplicas no MongoDB, acesse a documentação sobre conjuntos de réplicas no MongoDB.
Comece identificando o nó primário atual:
Procure o membro com o atributo"stateStr" : "PRIMARY" :
Simule uma falha excluindo o pod de nó primário atual:
Monitore o status do conjunto de réplicas e observe a eleição de uma nova primária:
Você deve ver que um dos nós secundários foi promovido a primary:
Verifique se o pod excluído foi recriado e se juntou novamente ao conjunto de réplicas como um nó secundário:
Confirme se o pod está de volta e em execução:
Verifique novamente o status do conjunto de réplicas para garantir que o novo nó seja reeleito como primário, pois ele tinha a prioridade mais alta:
Você deve ver:

Configurando o dimensionamento automático

Em um ambiente dinâmico, as demandas de carga de trabalho podem flutuar, exigindo que sua implantação do MongoDB seja dimensionada automaticamente para garantir um desempenho consistente. O Kubernetes fornece um recurso chamado Horizontal Pod Autoscaler (HPA) para gerenciar esse escalonamento.
O Kubernetes horizontal Pod Autoscaler dimensiona automaticamente o número de pods em um sistema, controlador de replicação ou conjunto de réplicas com base na utilização observada da CPU (ou em outras métricas selecionadas). Isso ajuda a garantir que seu aplicativo tenha a quantidade certa de recursos para lidar com níveis variados de tráfego.
Para configurar o dimensionamento automático para sua implementação do MongoDB , primeiro instale oServidor de Métricas MongoDB usando os comandos a seguir.
O HPA depende do servidor de métricas para coletar métricas do cluster Kubernetes.
Você verá a seguinte saída se aplicado com sucesso:
Instalando servidor de métricas
Instalando servidor de métricas
Execute o comando kubectl get pods -n kube-system para visualizar o status dos pods do servidor de métricas. Você deve ver o seguinte:
Neste momento, os contêineres no Metrics Server não estão em execução devido a problemas com o certificado TLS. Para resolver isso, execute o seguinte comando para editar a implantação do servidor de métricas:
O comandokubectl edit deployment metrics-server -n kube-system abre a configuração de implantação em um editor vim por padrão. Para editar o arquivo, mova o cursor para a seção apropriada usando as teclas de seta. Digite i para entrar no modo de inserção e fazer suas alterações. Depois de terminar a edição, pressione a teclaEsc para sair do modo de inserção e digite :wq para salvar as alterações e fechar o editor.
Adicione os seguintes comandos à especificação do container para ignorar a verificação TLS:
Adição de comandos para ignorar a verificação TLS para o Servidor MongoDB de métricas
Adição de comandos para ignorar a verificação TLS para o Servidor MongoDB de métricas
Depois de fazer essas alterações, confirme se os container estão em funcionamento executando:
Você deve ver a seguinte saída:
Verifique o uso de recursos dos Pods em seu cluster:
Você vê a seguinte saída:
Verifique o uso de recursos dos pods em seu cluster
Verifique o uso de recursos dos pods em seu cluster
Defina um recurso HPHA que especifique como e quando dimensionar o MongoDB StatefulSet usando o seguinte comando:
Essa configuração definirá o número mínimo de réplicas como 3 e permitirá o dimensionamento até um máximo de 10 réplicas com base na utilização da CPU.
Você deve ver a seguinte saída:
Monitore o status do HPA usando o seguinte comando:
Isso mostrará o status atual do HPA, incluindo o número atual de réplicas e as métricas usadas para o dimensionamento.
Visualizando o HPA para o StatefulSet do MongoDB
Visualizando o HPA para o StatefulSet do MongoDB

Conclusão

Alta disponibilidade é crucial para o bom funcionamento de qualquer sistema de banco de dados. Este tutorial demonstra como implantar o MongoDB no Kubernetes, configurá-lo para alta disponibilidade com um conjunto de réplicas, configurar mecanismos de backup usando o MongoDump e configurar o dimensionamento automático usando o HPA do Kubernetes. Seguindo as etapas destacadas neste tutorial, você pode manter o acesso contínuo aos seus dados para evitar tempos de inatividade significativos, o que pode levar à perda de dados e impactos financeiros. Como resultado, você terá durabilidade de dados e alta disponibilidade ao seu alcance.
Se você tiver alguma dúvida ou comentário, sinta-se à vontade para se juntar a nós na Comunidade de Desenvolvedores do MongoDB.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.
Iniciar a conversa

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Relacionado
Tutorial

Zap, tweet e repita! Como usar o Zapier com o MongoDB


Sep 09, 2024 | 7 min read
Artigo

Paginações 1.0: Coleções de séries temporais em cinco minutos


May 19, 2022 | 4 min read
Notícias e Anúncios

MongoDB 3.6: Aqui para o SRV com conexões de conjunto de réplicas mais fáceis


Sep 23, 2022 | 4 min read
Artigo

Acelerador de soluções para fraudes de cartão em tempo real com MongoDB e Databricks


Jul 11, 2023 | 7 min read
Sumário