Entendendo a alta disponibilidade e a recuperação de desastre para o IBM Cloud VPC
Alta disponibilidadeA capacidade de um serviço ou carga de trabalho de resistir a falhas e continuar fornecendo capacidade de processamento de acordo com algum nível de serviço predefinido. (HA) é a capacidade de um serviço permanecer operacional e acessível na presença de falhas inesperadas. A recuperação de desastresA capacidade de um serviço ou carga de trabalho de se recuperar de incidentes raros e importantes e de falhas em larga escala, como a interrupção do serviço. Isso inclui um desastre físico que afeta toda uma região, a corrupção de um banco de dados ou a perda de um serviço que contribui para uma carga de trabalho. O impacto excede a capacidade do projeto de alta disponibilidade de lidar com ele. é o processo de recuperação da instância de serviço para um estado de funcionamento.
IBM Cloud® Virtual Private Cloud é um serviço altamente disponível, projetado para atender aos objetivos de nível de serviço(SLO). Ele é composto por serviços zonais e regionais.
Para obter mais informações sobre a região disponível e os locais do data center, consulte Disponibilidade de serviço e infraestrutura por local.
Arquitetura de alta disponibilidade
Os recursos da VPC são divididos em serviços de plano de controle e plano de dados para permitir que os clientes criem aplicativos altamente disponíveis sobre a VPC. O plano de controle existe para provisionar e gerenciar os recursos da VPC (criar, atualizar, excluir) e para fornecer funções de controle. O plano de dados é a coleção de recursos de VPC provisionados, como instâncias de servidor virtual, endereços IP flutuantes, grupos de segurança, armazenamento em bloco e muito mais.
O plano de controle é hospedado em hardware redundante entre zonas, o que oferece resiliência para falhas de hardware e de zona. O plano de controle e o plano de dados estão em domínios de falha diferentes. Por exemplo, uma interrupção do plano de controle não afeta a disponibilidade do plano de dados. Todos os recursos existentes do cliente continuam sendo executados sem nenhum impacto. Para aumentar a resiliência, os usuários podem criar aplicativos a partir de recursos redundantes do plano de dados.
Os recursos VPC são categorizados em recursos zonais e recursos regionais com base em seu escopo. Alguns recursos, como o VPC, abrangem várias zonas e são considerados recursos regionais. A maioria dos recursos tem escopo zonal e está disponível em uma zona específica. Por exemplo, sub-redes, listas de controle de acesso, grupos de segurança, tabelas de roteamento, gateways públicos e gateways de Virtual Private Endpoint existem na zona em que foram criados.
Para obter mais informações sobre a proteção do plano de dados contra falhas no plano de controle, independência de serviço zonal e redundância de serviço regional, consulte IBM Cloud arquitetura de serviço para alta disponibilidade e resiliência.
falha da zona
Se ocorrer uma falha completa na zona, tanto o plano de controle quanto o plano de dados serão afetados na zona. As funções de controle nas zonas afetadas não estão disponíveis e todos os recursos zonais estão inativos. Por exemplo, as instâncias de servidor virtual na zona afetada ficam indisponíveis e não são movidas para outra zona íntegra. Todas as alterações feitas nos recursos regionais não entram em vigor na zona com falha até que a zona se recupere.
O plano de dados em outras zonas não é afetado, e todos os recursos zonais nas zonas não afetadas continuam a funcionar sem nenhuma interrupção. Os recursos regionais, como o VPC, continuam sendo executados nas zonas íntegras. O plano de controle é altamente disponível e permite que os serviços gerenciem os recursos nas outras zonas não afetadas.
Os clientes devem desenvolver mecanismos para gerenciar a alta disponibilidade de seus aplicativos, distribuindo os recursos entre zonas (domínios de falha), e planejar a recuperação de desastres.
Falha regional
No caso incomum de um desastre regional, todos os problemas subjacentes são resolvidos e o plano de controle da VPC é restaurado com foco na redução da perda de dados para os recursos. O plano de dados também é restaurado recuperando o estado dos dados do cliente do armazenamento com o objetivo de atender ao objetivo de ponto de recuperação (RPO) e ao objetivo de tempo de recuperação (RTO).
Em uma região com várias zonas de um único campus (SC-MZR), um desastre no data center pode afetar toda a região, pois as zonas estão mais intimamente relacionadas. Os serviços devem empregar estratégias de backup e recuperação em outro MZR para evitar a perda de dados.
Falhas de hardware
Os recursos são fornecidos por hardware confiável e, muitas vezes, redundante, mas uma falha imprevista de hardware pode derrubar esses recursos. Por exemplo, uma instância de servidor virtual pode falhar quando o hardware subjacente falha.
Nessa situação, a política de recuperação de falhas do host determina como o servidor virtual é recuperado. Se a falha ocorrer e a política de recuperação de falha de host
estiver definida como a configuração padrão, restart, o plano de controle detectará a falha de hardware e migrará o servidor virtual para o hardware disponível na mesma zona e reiniciará o servidor virtual. O armazenamento efêmero
em disco não é restaurado no volume de inicialização. Os volumes de dados estão disponíveis, mas podem estar faltando gravações de cache do aplicativo ou do sistema operacional que não foram salvas no momento da falha.
Os volumes de blocos são respaldados por hardware redundante com técnicas avançadas de replicação para melhorar a resiliência. No entanto, um desastre zonal ou uma falha em vários hardwares pode resultar em uma falha no volume de blocos. O backup e a restauração são uma abordagem adequada para reduzir a perda ou a corrupção de dados. Essa abordagem também pode ser usada para mitigar um desastre regional, replicando dados para outras regiões IBM Cloud. O recurso de instantâneo pode ser usado para dar suporte a backup e restauração. Os clientes também podem distribuir seus aplicativos em outras zonas para evitar interrupções e melhorar o RPO/RTO.
Pode haver uma forte correlação de falhas entre o armazenamento de volumes e a falha do aplicativo de servidor associado. Certifique-se de examinar e testar as cargas de trabalho para determinar o comportamento do aplicativo na presença de um dispositivo de armazenamento com falha.
Para obter informações sobre servidores bare metal e seu armazenamento associado, consulte Visão geral do armazenamento para Bare Metal Servers for VPC. Os instantâneos não estão disponíveis para os discos locais em servidores bare metal. Os clientes devem gerenciar a alta disponibilidade e a recuperação de desastres para esses dispositivos.
Criação de aplicativos de HA
Você pode usar um balanceador de carga VPC para distribuir solicitações de entrada para vários servidores virtuais e servidores bare metal. Os servidores virtuais e os servidores bare metal que se tornam indisponíveis param de responder às verificações de integridade; o balanceador de carga equilibra a carga nos recursos disponíveis. Você pode usar um ALB (Application Load Balancer, balanceador de carga de aplicativos) para distribuir o tráfego de uma carga de trabalho para servidores virtuais em várias zonas e para criar cargas de trabalho que estejam disponíveis mesmo quando uma zona inteira ficar indisponível.
Quando o próprio ALB é configurado em sub-redes entre zonas, ele é resiliente a uma falha em uma única zona. O Network Load Balancer é um serviço zonal que é distribuído em vários servidores virtuais subjacentes e resiliente a uma única falha de servidor virtual.
A estratégia básica para melhorar a disponibilidade de cargas de trabalho criadas a partir de recursos de VPC é distribuir a carga de trabalho em vários recursos. É possível distribuir recursos em uma zona, em várias zonas em uma região com várias zonas (MZR) ou em várias regiões. Para obter mais informações, consulte Implantar cargas de trabalho isoladas em vários locais e zonas; essa estratégia usa o site IBM Cloud Internet Services (CIS) e um Global Load Balancer.
Recursos de alta disponibilidade
IBM Cloud VPC oferece suporte aos seguintes recursos de alta disponibilidade:
| Recursos | Descrição | Consideração |
|---|---|---|
| Application Load Balancer | Um ALB distribui a carga entre zonas para endereços IP. | A carga de trabalho deve ser escalonável. |
| Balanceador de carga de rede | Um NLB distribui a carga para endereços IP em uma zona. | A carga de trabalho deve ser escalonável. |
| Escala automática para VPC | Melhore o desempenho e os custos criando dinamicamente instâncias de servidores virtuais para atender às demandas de seu ambiente. | A carga de trabalho deve ser escalonável. |
| Balanceador de carga e grupo de instâncias | Cargas de trabalho escalonáveis que são lideradas por um balanceador de carga distribuem a carga para várias instâncias entre zonas. | A carga de trabalho deve ser escalonável. |
Como cliente, você pode criar e dar suporte ao HA:
| Recursos | Descrição | Consideração |
|---|---|---|
| Carga de trabalho escalável | Crie uma carga de trabalho baseada em servidor virtual ou servidor bare metal que possa ser dimensionada horizontalmente com mais servidores. | Nem todas as cargas de trabalho podem ser dimensionadas horizontalmente. |
Carga de trabalho escalável
As cargas de trabalho escalonáveis podem lidar com o aumento da demanda adicionando mais servidores que estejam executando a mesma imagem. A carga de trabalho dimensionável pode ser implementada usando balanceadores de carga e o Auto Scale for VPC.
Arquitetura de recuperação de desastres
A estratégia para recuperação de desastres é fornecer automação de scripts para restaurar uma carga de trabalho de VPC em um local de recuperação. Por exemplo, quando uma região fica indisponível, é responsabilidade do cliente migrar a carga de trabalho e os dados associados para uma região disponível. IBM tem suporte para a infraestrutura Terraform como sistema de código que pode ser usado para definir cargas de trabalho com locais e desempenho parametrizados. A API, o SDK e a CLI do VPC podem ser usados pelos clientes para criar scripts para recuperar recursos em um local disponível durante um desastre. Para obter mais informações, consulte Planejamento para recuperação de desastres.
Você pode saber mais sobre como usar IBM Cloud Object Storage, IBM Cloud Schematics que fornecem Terraform-as-a-Service e arquiteturas implantáveis em Usando serviços IBM Cloud em sua recuperação de desastres.
Recursos de recuperação de desastres
IBM Cloud VPC oferece suporte aos seguintes recursos de recuperação de desastres:
| Recursos | Descrição | Consideração |
|---|---|---|
| Instantâneos de volume único | Um snapshot é uma cópia pontual do seu volume de dados ou de inicialização. Block Storage os instantâneos são armazenados na instância regional do Cloud Object Storage. | Um instantâneo é independente de seu volume de origem. Se a zona do volume de origem não estiver disponível, o instantâneo poderá ser usado para criar um novo volume em uma zona diferente na região. Os instantâneos podem ser criados sob demanda no console, a partir da CLI, com a API ou o Terraform. Eles também podem ser agendados usando o serviço Backup for VPC. |
| Cópias de instantâneos inter-regionais | Você pode usar cópias de snapshot inter-regionais que sejam independentes de seus snapshots de origem para criar novos volumes. | Os instantâneos podem ser copiados para outra região manualmente no console, a partir da CLI, ou programaticamente com a API ou o Terraform. Você também pode incluir a criação de uma cópia em outra região em sua política de backup. |
| Instantâneos de grupos de consistência | Um grupo de consistência de snapshot contém snapshots de vários volumes Block Storage que estão anexados à mesma instância de servidor virtual. | Quando você solicita um instantâneo de um grupo de consistência, o sistema gera instantâneos de todos os volumes marcados Block Storage que estão anexados à instância do servidor virtual ao mesmo tempo. Você pode incluir ou excluir volumes de inicialização. O armazenamento da instância não está incluído. |
| Instantâneos de restauração rápida | Os snapshots de restauração rápida são snapshots armazenados em cache na zona com o volume de bloco pai. Quando você cria um servidor virtual com um instantâneo de restauração rápida inicializável, o servidor se torna totalmente operacional mais rapidamente do que quando você provisiona seu volume de inicialização a partir de um instantâneo normal. | |
| Replicação de compartilhamento de arquivos | Se o compartilhamento de origem ficar indisponível, você poderá iniciar um failover de replicação para o compartilhamento de réplica. | Você pode criar uma réplica de compartilhamento em outra zona da mesma região. Também é possível criar uma réplica em outra região na mesma área geográfica. Você pode replicar seus dados a cada 15 minutos. |
A restauração de um volume ou de um compartilhamento a partir de um instantâneo é uma operação manual que leva tempo. Se você precisar de um nível mais alto de serviço para recuperação de desastres, consulte IBM Cloud 's Backup and recovery services.
Como cliente, você pode criar e oferecer suporte a opções adicionais de recuperação de desastres:
| Recursos | Descrição | Consideração |
|---|---|---|
| Fonte externa de verdade para a configuração da VPC | Construção de VPC, rede e servidores capturados em arquivos de configuração gerenciados pelo cliente, como scripts do Terraform, scripts de shell ou programas. | O cliente deve criar o script e manter a configuração onde possa ser usada durante um possível desastre. |
| Scripts criados pelo cliente para backup e cópia de armazenamento de arquivos | Copie o conteúdo de um compartilhamento de arquivos para disponibilizá-lo em outro local. | O cliente deve criar o script ou usar o backup e a restauração contínuos gerenciados pelo cliente. |
| Backup e restauração contínuos gerenciados pelo cliente para volumes de blocos e armazenamento de arquivos | Os clientes podem instalar agentes de terceiros e drivers de sistema operacional em servidores que se integram a sistemas de backup e recuperação, como a Veeam. | O cliente deve instalar e gerenciar a solução de backup e recuperação de terceiros. |
Planejando a Recuperação de Desastre
As etapas de recuperação de desastres devem ser praticadas regularmente. Ao criar seu plano, considere os cenários de falha e as resoluções a seguir.
| Falha | Resolução |
|---|---|
| Falha no volume de inicialização | Você pode criar um novo volume a partir de uma imagem personalizada criada a partir do seu volume. Ou você pode restaurar um volume a partir de um instantâneo no console, na CLI, com a API, Terraform ou usando uma solução de backup e restauração contínua gerenciada pelo cliente. Quando você restaurar um volume de inicialização a partir de um instantâneo, espere alguma degradação do desempenho enquanto os dados são copiados para o volume de inicialização a partir do instantâneo. Usando snapshots de restauração rápida, você pode atingir os objetivos de tempo de recuperaçãoNo planejamento de recuperação de desastres, o período de tempo para que um processo comercial seja restaurado após um desastre. (RTO) mais rapidamente do que restaurando a partir de um snapshot regular, pois todos os dados estão disponíveis e o desempenho não é afetado. |
| Falha no volume de dados ou corrupção de dados | Restaure um volume a partir de um instantâneo no console, da CLI, com a API, Terraform ou usando uma solução de backup e restauração contínua gerenciada pelo cliente. Os instantâneos de restauração rápida também estão disponíveis para volumes de dados. |
| Corrupção de dados de compartilhamento de arquivos | É possível criar instantâneos de compartilhamento de arquivos para preservar os dados no compartilhamento de arquivos em um ponto específico no tempo. Assim, você pode restaurar dados de um instantâneo de compartilhamento de arquivos se o conteúdo do compartilhamento de arquivos for acidentalmente excluído ou substituído. |
| Falha no compartilhamento de arquivos | Mitigado ao iniciar um failover para uma réplica existente em outra zona. Teste o processo de failover para ver quanto tempo ele leva. |
| Falha no servidor virtual | Mitigado pelo uso dos recursos de alta disponibilidade de um balanceador de carga e do Auto Scale for VPC, criando uma carga de trabalho dimensionável. Pode ser necessário reiniciar o servidor virtual. Pode ser necessária a resolução de falhas no volume do bloco. |
| Falha no servidor bare metal | Solução de backup e restauração gerenciada pelo cliente. |
| falha da zona | Mitigado pelo uso dos recursos de alta disponibilidade de um balanceador de carga e do Auto Scale for VPC, criando uma carga de trabalho dimensionável. Use uma fonte externa de verdade para a configuração da zona VPC para criar recursos em uma zona disponível usando a resolução de falhas de servidor e a resolução de falhas de volume de bloco. |
| Falha regional | Use uma fonte externa de verdade para a configuração da região VPC para criar recursos em uma região disponível. Restaurar volumes e armazenamento de arquivos para valores anteriores usando a resolução de falhas do servidor. |
Suas responsabilidades pela alta disponibilidade e recuperação de desastres
Para obter mais informações, consulte Entendendo suas responsabilidades ao usar a nuvem privada virtual. É sua responsabilidade testar continuamente seu plano de HA e DR. Para obter mais informações, consulte Teste de recuperação de desastres.
Podem ocorrer interrupções na conectividade da rede e curtos períodos de indisponibilidade de um serviço. É sua responsabilidade garantir que o código-fonte do aplicativo inclua a lógica de nova tentativa de disponibilidade do cliente para manter a alta disponibilidade do aplicativo.
Você pode usar as seguintes listas de verificação para ajudá-lo a criar e praticar seu plano.
-
Instantâneo de volume de bloco
-
Replicação de armazenamento de arquivos
-
Fonte externa de verdade para a configuração da VPC
Gerenciamento de mudanças
O gerenciamento de alterações inclui tarefas como upgrades, alterações de configuração e exclusão.
Conceda aos usuários e processos as funções e ações do IAM com o mínimo de privilégio necessário para o trabalho deles. Para obter mais informações, consulte Como posso evitar a exclusão acidental de serviços?
Considere a possibilidade de criar um backup manual antes de fazer alterações nas configurações da infraestrutura.
Como o site IBM® ajuda a apoiar o planejamento de recuperação de desastres
IBM® toma medidas específicas de recuperação para IBM Cloud VPC se ocorrer um desastre.
Se um único host falhar inesperadamente, os servidores virtuais no host com falha poderão ser reiniciados automaticamente em um host íntegro. Para obter mais informações sobre como o IBM monitora a infraestrutura e responde a falhas de host, consulte Políticas de recuperação de falhas de host.
Como o IBM se recupera de falhas de zona
As falhas de zona podem resultar de desastres naturais, problemas de infraestrutura, como falta de energia, ações acidentais ou mal-intencionadas que excluem informações ou atualizações de software que contêm um bug ou erro. No caso de uma falha de zona, o IBM trabalha para recuperar instalações e data centers, redes físicas e dispositivos, armazenamento físico, servidores físicos e memória, e hipervisores. Para obter mais informações, consulte Responsabilidades compartilhadas pelo uso de produtos IBM Cloud.
Como o site IBM se recupera de falhas regionais
Caso uma região inteira sofra uma falha, o site IBM trabalha novamente para recuperar instalações e data centers, redes e dispositivos físicos, armazenamento físico, servidores físicos e memória, e hipervisores. Para obter mais informações, consulte Responsabilidades compartilhadas pelo uso dos produtos IBM Cloud e Perguntas frequentes sobre recuperação de desastres.
Se o site IBM não puder restaurar a instância do serviço, você deverá restaurar o serviço conforme descrito na arquitetura de recuperação de desastres.
Como o site IBM mantém os serviços
Quando a manutenção de rotina é realizada em servidores virtuais, hosts e data centers, os protocolos de rotina são seguidos. Para obter mais informações, consulte Entendendo as operações de manutenção de nuvem.
Todos os upgrades seguem as práticas recomendadas de serviço do site IBM, incluindo planos de recuperação e processos de reversão. A manutenção regular pode causar interrupções curtas, atenuadas pela lógica de nova tentativa de disponibilidade do cliente. As alterações são implementadas sequencialmente, região por região e zona por zona dentro de uma região. O site IBM reverte as atualizações ao primeiro sinal de defeito.
As alterações complexas são ativadas e desativadas com sinalizadores de recursos para controlar a exposição.
As alterações que afetam as cargas de trabalho dos clientes são detalhadas nas notificações do site IBM Cloud. Para obter mais informações sobre manutenção planejada, anúncios e notas de versão que afetam esse serviço, consulte Monitoramento de notificações e status.