Alta disponibilidade é a capacidade do seu aplicação de garantir a operação contínua e minimizar o tempo de inatividade durante interrupções de infraestrutura, manutenção de sistemas e outras interrupções. A arquitetura de implantação padrão do MongoDB é projetada para alta disponibilidade, com recursos integrados para redundância de dados e failover automático. Esta página descreve opções de configuração adicionais e aprimoramentos da arquitetura de implantação que você pode escolher para evitar interrupções e oferecer suporte a mecanismos robustos de failover para interrupções de zona, região e provedor de nuvem .
Recursos do Atlas para alta disponibilidade
Replicação de banco de dados
A arquitetura de implantação padrão do MongoDB é projetada para redundância. O Atlas distribui cada cluster como um conjunto de réplicas com um mínimo de três instâncias de banco de dados (também chamadas de nós ou membros do conjunto de réplicas), distribuídas em zonas de disponibilidade separadas dentro das regiões de provedor de nuvem selecionadas. Os aplicativos gravam dados no nó primário do conjunto de réplicas e, em seguida, o Atlas replica e armazena esses dados em todos os nós dentro do cluster. Para controlar a durabilidade do armazenamento de dados, você pode ajustar a preocupação de gravação do código do aplicação para concluir a gravação somente depois que um determinado número de secundários tiver confirmado a gravação. O comportamento padrão é que os dados sejam persistentes na maioria dos nós elegíveis antes de confirmar a ação.
O diagrama a seguir representa como a replicação funciona para um conjunto de réplicas de três nós padrão:
Failover automático
No evento de um nó primário em um conjunto de réplicas ficar indisponível devido a uma interrupção da infraestrutura , manutenção programada ou qualquer outra interrupção, os Atlas clusters se auto-corrigem ao promover um nó secundário existente para a função de nó primário em uma eleição de conjunto de réplicas . Esse processo de failover é totalmente automático e é concluído em segundos sem nenhuma perda de dados, incluindo operações que estavam em andamento no momento da falha, que são repetidas após a falha se as retryable writes estiverem habilitadas. Após uma eleição de conjunto de réplicas, o Atlas restaura ou substitui o membro com falha para garantir que o cluster retorne à configuração de destino o mais rápido possível. O driver do cliente MongoDB também alterna automaticamente todas as conexões do cliente durante e após a falha.
O diagrama a seguir representa o processo de eleição do conjunto de réplicas:
Para melhorar a disponibilidade dos aplicativos mais críticos, você pode dimensionar o sistema adicionando nós, regiões ou fornecedores de nuvem para resistir a interrupções de zona, região ou fornecedor, respectivamente. Para saber mais, consulte a recomendações Dimensionar seu Paradigma de Implantação para Tolerância a Falhas abaixo.
Recomendações para Alta Disponibilidade do Atlas
As recomendações a seguir descrevem opções de configuração adicionais e aprimoramentos da arquitetura de implementação que você pode fazer para aumentar a disponibilidade da implementação.
Escolha uma camada de cluster que se adapte às suas metas de implantação
Ao criar um novo cluster, você pode escolher entre uma variedade de camadas de cluster disponíveis nos tipos de sistema Dedicado, Flex ou Gratuito. A camada do cluster no MongoDB Atlas especifica os recursos (memória, armazenamento, vCPUs e IOPS) disponíveis para cada nó em seu cluster. O dimensionamento para um nível superior melhora a capacidade do cluster de lidar com picos de tráfego e aumenta a confiabilidade do sistema por meio de uma resposta mais rápida a cargas de trabalho altas. Para determinar a camada do cluster recomendada para o tamanho do seu aplicação , consulte o Guia de tamanho do Atlas cluster.
O Atlas também oferece suporte ao escalonamento automático para permitir que o cluster se ajuste automaticamente aos picos de demanda. A automação dessa ação reduz o risco de uma interrupção devido a restrições de recursos. Para saber mais, consulte Orientação para o provisionamento automatizado de infraestrutura do Atlas .
Escale seu paradigma de implantação para tolerância a falhas
A tolerância a falhas para um sistema do Atlas pode ser medida como o número de membros do conjunto de réplicas que podem ficar indisponíveis enquanto seu sistema ainda permanece operacional. No evento de uma interrupção da zona de disponibilidade, região ou provedor de nuvem , os clusters Atlas se auto-reparam ao promover um nó secundário existente para a função de nó primary em uma eleição de conjunto de réplicas. A maioria dos nós de votação em um conjunto de réplicas deve estar operacional para que seja possível realizar uma eleição de conjunto de réplicas quando um nó primary sofrer uma interrupção.
Para garantir que um conjunto de réplicas possa eleger um primário no caso de uma interrupção parcial da região, você deve distribuir clusters em regiões com pelo menos três zonas de disponibilidade. As zonas de disponibilidade são grupos separados de data centers em uma única região de provedor de nuvem , cada uma com sua própria infraestrutura de energia, resfriamento e rede. O Atlas distribui automaticamente seu cluster entre as zonas de disponibilidade quando elas são compatíveis com a região de provedor de nuvem selecionada, de modo que, se uma zona sofrer uma interrupção, os nós restantes em seu cluster ainda oferecerão suporte a serviços regionais. A maioria das regiões de provedor de nuvem suportadas pelo Atlas tem pelo menos três zonas de disponibilidade. Essas regiões estão marcadas com um ícone de estrela na UI do Atlas . Para obter mais informações sobre regiões recomendadas, consulte Provedores de nuvem e regiões.
Para melhorar ainda mais a tolerância a falhas para seus aplicativos mais críticos, você pode dimensionar sua implantação adicionando nós, regiões ou provedores de nuvem para resistir a interrupções de zona de disponibilidade, região ou provedor, respectivamente. Você pode aumentar a contagem de nós para qualquer número ímpar de nós, com um máximo de 7 nós elegíveis e 50 nós no total. Você também pode implantar um cluster em várias regiões para aumentar a disponibilidade em uma região geográfica maior e ativar o failover automático no caso de uma interrupção de região completa que desabilite todas as zonas de disponibilidade em sua região primária. O mesmo padrão se aplica à distribuição de seu cluster em vários fornecedores de nuvem para resistir a uma interrupção total do provedor de nuvem .
Para obter orientação sobre como escolher um sistema que equilibre suas necessidades de alta disponibilidade, baixa latência, conformidade e custo, consulte nossa documentação sobre os Paradigmas de Sistema do Atlas .
Evitar exclusão acidental de clusters
Você pode ativar a proteção contra encerramento para garantir que um cluster não seja encerrado acidentalmente e exija tempo de inatividade para ser restaurado a partir de um backup. Para excluir um cluster que tenha a proteção contra encerramento ativada, primeiro você deve desabilitar a proteção contra encerramento. Por padrão, o Atlas desativa a proteção contra encerramento para todos os clusters.
Habilitar a proteção de encerramento é especialmente importante ao aproveitar as ferramentas de IaC, como o Terraform, para garantir que uma reimplantação não provisione uma nova infraestrutura.
Testar failovers automáticos
Antes de implementar um aplicação para produção, é altamente recomendável simular vários cenários que exigem failovers automáticos de nós para medir sua preparação para esses eventos. Com o Atlas, você pode testar o failover do nó primary para um conjunto de réplicas e simular interrupções regionais para um sistema multirregional .
Use o majority Write Concern
O MongoDB permite que você especifique o nível de confirmação solicitado para operações de gravação usando preocupação de gravação . O Atlas tem uma preocupação de gravação padrão de,majority o que significa que os dados devem ser replicados em mais da metade dos nós em seu cluster antes que o Atlas relate o sucesso. Usar majority em vez de um valor de número definido como 2 permite que o Atlas se ajuste automaticamente para exigir replicação em menos nós se você sofrer uma interrupção temporária de nó , permitindo que as gravações continuem após o failover automático. Isso também fornece uma configuração consistente em todos os ambientes, para que sua string de conexão permaneça a mesma, tenha você três nós em um ambiente de teste ou um número maior de nós em produção.
Configurar leituras e gravações de banco de dados repetível
O Atlas oferece suporte a operações de leitura e gravações repetíveis . Quando ativado, o Atlas tenta novamente as operações de leitura e gravação uma vez como proteção contra interrupções intermitentes de rede e eleições de conjunto de réplicas nas quais o aplicação não consegue encontrar temporariamente um nó primário íntegro. As gravações que podem ser repetidas exigem uma preocupação de gravação reconhecida, o que significa que sua preocupação de gravação não pode {w:
0} ser.
Monitore e planeje a utilização de recursos
Para evitar problemas de capacidade de recursos, recomendamos que você monitore a utilização de recursos e realize sessões regulares de planejamento de capacidade. Os serviços profissionais do MongoDB oferecem essas sessões. Consulte nosso Plano de Recuperação de Desastres da Capacidade de Recursos para obter nossas recomendações sobre como se recuperar de problemas de capacidade de recursos.
Para conhecer as melhores práticas de alertas e monitoramento da utilização de recursos, consulte Orientações para monitoramento e alertas do Atlas.
Planejar as alterações da versão do MongoDB
Recomendamos que você execute a versão mais recente do MongoDB para aproveitar os novos recursos e as garantias de segurança aprimoradas. Você deve sempre garantir a atualização para a versão principal mais recente do MongoDB antes que a versão atual chegue ao fim da vida útil.
Você não pode fazer downgrade da sua versão do MongoDB usando a UI do Atlas . Por esse motivo, recomendamos que você trabalhe diretamente com os Serviços profissionais ou Serviços técnicos do MongoDB ao planejar e executar uma atualização de versão principal para ajudá-lo a evitar problemas que possam ocorrer durante o processo de atualização.
Configurar janelas de manutenção
O Atlas mantém o tempo de atividade durante a manutenção programada aplicando atualizações de forma contínua a um nó de cada vez. Sempre que o primário atual é colocado offline para manutenção durante esse processo, o Atlas elege um novo primário por meio de uma eleição automática de conjunto de réplicas. Esse é o mesmo processo que ocorre durante o failover automático em resposta a uma interrupção não planejada de um nó primário.
Recomendamos que você configure uma período de manutenção personalizada para o seu projeto para evitar eleições de conjunto de réplicas relacionadas à manutenção durante os horários críticos para os negócios. Você também pode definir horas protegidas nas configurações da período de manutenção para definir uma janela diária de tempo na qual as atualizações padrão não podem começar. As atualizações padrão não envolvem reinicializações ou ressincronizações de cluster.
Exemplos de Automação: Alta Disponibilidade do Atlas
Os exemplos a seguir configuram a topologia de implantação de região única, 3 conjunto de réplicas de nó / shard usando as ferramentas do Atlas para automação.
Esses exemplos também incluem outras configurações recomendadas, tais como:
Camada do cluster configurada para
M10em um ambiente de desenvolvimento/teste. Use o guia de tamanho do cluster para saber qual a camada do cluster recomendada para o tamanho do seu aplicativo.Região única, 3-Conjunto de réplicas de nós/Topologia de implantação de fragmento.
Nossos exemplos utilizam AWS, Azure e Google Cloud indistintamente. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder à do provedor de nuvem. Para saber mais sobre os provedores de nuvem e as respectivas regiões, consulte Provedores de nuvem.
Camada do cluster definida como
M30para um aplicativo de porte médio. Use o guia de tamanho do cluster para saber qual a camada do cluster recomendada para o tamanho do seu aplicativo.Região única, 3-Conjunto de réplicas de nós/Topologia de implantação de fragmento.
Nossos exemplos utilizam AWS, Azure e Google Cloud indistintamente. Você pode usar qualquer um desses três provedores de nuvem, mas deve alterar o nome da região para corresponder à do provedor de nuvem. Para saber mais sobre os provedores de nuvem e as respectivas regiões, consulte Provedores de nuvem.
Observação
Antes de criar recursos com o Atlas CLI, você deve:
Crie sua organização pagadora e crie uma chave de API para a organização pagadora.
Conecte-se pelo Atlas CLI seguindo as instruções para Programmatic Use.
Criar uma implantação por projeto
Para seus ambientes de desenvolvimento e teste, execute o seguinte comando para cada projeto. Altere os IDs e nomes para usar seus valores:
atlas clusters create CustomerPortalDev \ --projectId 56fd11f25f23b33ef4c2a331 \ --region EASTERN_US \ --members 3 \ --tier M10 \ --provider GCP \ --mdbVersion 8.0 \ --diskSizeGB 30 \ --tag bu=ConsumerProducts \ --tag teamName=TeamA \ --tag appName=ProductManagementApp \ --tag env=Production \ --tag version=8.0 \ --tag email=marissa@acme.com \ --watch
Para os seus ambientes de preparação e produção, crie o seguinte arquivo cluster.json para cada projeto. Altere os IDs e nomes para usar os seus valores:
{ "clusterType": "REPLICASET", "links": [], "name": "CustomerPortalProd", "mongoDBMajorVersion": "8.0", "replicationSpecs": [ { "numShards": 1, "regionConfigs": [ { "electableSpecs": { "instanceSize": "M30", "nodeCount": 3 }, "priority": 7, "providerName": "GCP", "regionName": "EASTERN_US", "analyticsSpecs": { "nodeCount": 0, "instanceSize": "M30" }, "autoScaling": { "compute": { "enabled": false, "scaleDownEnabled": false }, "diskGB": { "enabled": false } }, "readOnlySpecs": { "nodeCount": 0, "instanceSize": "M30" } } ], "zoneName": "Zone 1" } ], "tag" : [{ "bu": "ConsumerProducts", "teamName": "TeamA", "appName": "ProductManagementApp", "env": "Production", "version": "8.0", "email": "marissa@acme.com" }] }
Após criar o arquivo cluster.json, execute o seguinte comando para cada projeto. O comando utiliza o arquivo cluster.json para criar um cluster.
atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json
Para obter mais opções de configuração e informações sobre esse exemplo, consulte o comando atlas clusters create.
Observação
Antes de criar recursos com o Terraform, você deve:
Crie sua organização pagadora e uma chave de API para a organização pagadora. Armazene sua chave de API como variáveis de ambiente ao executar o seguinte comando no terminal:
export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>" export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
Criar os projetos e as implantações
Para seus ambientes de desenvolvimento e teste, crie os seguintes arquivos para cada par de aplicação e ambientes. Coloque os arquivos para cada par de aplicação e ambiente em seu próprio diretório. Altere os IDs e nomes para usar seus valores:
main.tf
# Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalDev" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version replication_specs { region_configs { electable_specs { instance_size = var.cluster_instance_size_name node_count = 3 } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } } tags { key = "BU" value = "ConsumerProducts" } tags { key = "TeamName" value = "TeamA" } tags { key = "AppName" value = "ProductManagementApp" } tags { key = "Env" value = "Test" } tags { key = "Version" value = "8.0" } tags { key = "Email" value = "marissa@acme.com" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
Observação
Para criar um cluster multirregional, especifique cada região em seu próprio objeto region_configs e aninhe-as no objeto replication_specs. Os campos priority devem ser definidos em ordem decrescente e devem consistir em valores entre 7 e 1, conforme mostrado no exemplo a seguir:
replication_specs { region_configs { electable_specs { instance_size = "M10" node_count = 2 } provider_name = "GCP" priority = 7 region_name = "NORTH_AMERICA_NORTHEAST_1" } region_configs { electable_specs { instance_size = "M10" node_count = 3 } provider_name = "GCP" priority = 6 region_name = "WESTERN_US" } }
variables.tf
# Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Dev" environment = "dev" cluster_instance_size_name = "M10" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" } } required_version = ">= 0.13" }
Após criar os arquivos, acesse o diretório correspondente a cada par de aplicativo e ambiente e execute o seguinte comando para inicializar o Terraform:
terraform init
Execute o seguinte comando para visualizar o Terraform plan:
terraform plan
Execute o seguinte comando para criar um projeto e uma implantação para o par de aplicativo e ambiente. O comando utiliza os arquivos e o MongoDB & HashiCorp Terraform para criar os projetos e clusters:
terraform apply
Quando solicitado, digite yes e pressione Enter para aplicar a configuração.
Para seus ambientes de preparação e produção, crie os seguintes arquivos para cada par de aplicativo e ambiente. Coloque os arquivos de cada par de aplicativo e ambiente em seus respectivos diretórios. Altere os IDs e nomes para usar os seus valores:
main.tf
# Create a Group to Assign to Project resource "mongodbatlas_team" "project_group" { org_id = var.atlas_org_id name = var.atlas_group_name usernames = [ "user1@example.com", "user2@example.com" ] } # Create a Project resource "mongodbatlas_project" "atlas-project" { org_id = var.atlas_org_id name = var.atlas_project_name # Assign the Project the Group with Specific Roles teams { team_id = mongodbatlas_team.project_group.team_id role_names = ["GROUP_READ_ONLY", "GROUP_CLUSTER_MANAGER"] } } # Create an Atlas Advanced Cluster resource "mongodbatlas_advanced_cluster" "atlas-cluster" { project_id = mongodbatlas_project.atlas-project.id name = "ClusterPortalProd" cluster_type = "REPLICASET" mongo_db_major_version = var.mongodb_version replication_specs { region_configs { electable_specs { instance_size = var.cluster_instance_size_name node_count = 3 } priority = 7 provider_name = var.cloud_provider region_name = var.atlas_region } } tags { key = "BU" value = "ConsumerProducts" } tags { key = "TeamName" value = "TeamA" } tags { key = "AppName" value = "ProductManagementApp" } tags { key = "Env" value = "Production" } tags { key = "Version" value = "8.0" } tags { key = "Email" value = "marissa@acme.com" } } # Outputs to Display output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv } output "project_name" { value = mongodbatlas_project.atlas-project.name }
Observação
Para criar um cluster multirregional, especifique cada região em seu próprio objeto region_configs e aninhe-as no objeto replication_specs, conforme mostrado no exemplo a seguir:
replication_specs { region_configs { electable_specs { instance_size = "M10" node_count = 2 } provider_name = "GCP" priority = 7 region_name = "NORTH_AMERICA_NORTHEAST_1" } region_configs { electable_specs { instance_size = "M10" node_count = 3 } provider_name = "GCP" priority = 6 region_name = "WESTERN_US" } }
variables.tf
# Atlas Organization ID variable "atlas_org_id" { type = string description = "Atlas Organization ID" } # Atlas Project Name variable "atlas_project_name" { type = string description = "Atlas Project Name" } # Atlas Project Environment variable "environment" { type = string description = "The environment to be built" } # Cluster Instance Size Name variable "cluster_instance_size_name" { type = string description = "Cluster instance size name" } # Cloud Provider to Host Atlas Cluster variable "cloud_provider" { type = string description = "AWS or GCP or Azure" } # Atlas Region variable "atlas_region" { type = string description = "Atlas region where resources will be created" } # MongoDB Version variable "mongodb_version" { type = string description = "MongoDB Version" } # Atlas Group Name variable "atlas_group_name" { type = string description = "Atlas Group Name" }
terraform.tfvars
atlas_org_id = "32b6e34b3d91647abb20e7b8" atlas_project_name = "Customer Portal - Prod" environment = "prod" cluster_instance_size_name = "M30" cloud_provider = "AWS" atlas_region = "US_WEST_2" mongodb_version = "8.0" atlas_group_name = "Atlas Group"
provider.tf
# Define the MongoDB Atlas Provider terraform { required_providers { mongodbatlas = { source = "mongodb/mongodbatlas" } } required_version = ">= 0.13" }
Após criar os arquivos, acesse o diretório correspondente a cada par de aplicativo e ambiente e execute o seguinte comando para inicializar o Terraform:
terraform init
Execute o seguinte comando para visualizar o Terraform plan:
terraform plan
Execute o seguinte comando para criar um projeto e uma implantação para o par de aplicativo e ambiente. O comando utiliza os arquivos e o MongoDB & HashiCorp Terraform para criar os projetos e clusters:
terraform apply
Quando solicitado, digite yes e pressione Enter para aplicar a configuração.
Para mais opções de configuração e informações sobre este exemplo, consulte MongoDB & HashiCorp Terraform e a publicação no blog do MongoDB Terraform.