Entendendo a alta disponibilidade e a recuperação de desastre para o IBM Cloud Monitoring

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. Para serviços, a disponibilidade é definida no Contrato de Nível de Serviço. A disponibilidade inclui eventos planejados e não planejados, como manutenção, falhas e desastres. (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.

O IBM Cloud® Monitoring é um serviço regional altamente disponível e de diversos locatários para monitorar os aplicativos, os recursos de plataforma e a infraestrutura.

Você pode encontrar a região disponível e os locais dos data centers na documentação Regions for IBM Cloud Monitoring. Como um serviço regional, o IBM Cloud Monitoring atende aos Objetivos de Nível de Serviço(SLO) definidos com o plano de Nível Graduado. O SLO não é uma garantia e a IBM não emitirá créditos por não atingir um objetivo.

Arquitetura de alta disponibilidade

Zonas de disponibilidade

Uma zona de disponibilidade é um local lógica e fisicamente isolado dentro de uma região do IBM Cloud, na qual os dados são processados e hospedados.

Uma zona de disponibilidade tem infraestruturas independentes de energia, de resfriamento e de rede que são isoladas de outras zonas para fortalecer a tolerância a falhas, evitando pontos únicos de falha entre as zonas.
Uma zona de disponibilidade oferece alta largura de banda e baixa latência entre as zonas dentro de uma região.

Uma região (local) é um grupo geográfica e fisicamente separado de uma ou mais zonas de disponibilidade com infraestruturas elétrica e de rede independentes isoladas de outras regiões.

As regiões são projetadas para remover pontos únicos de falha compartilhados com outras regiões e garantir baixa latência entre as zonas dentro da região.
Cada região tem três data centers (DC) diferentes para redundância.

A tabela a seguir lista o status de alta disponibilidade (HA) das regiões (locais) nas quais o serviço IBM Cloud Monitoring está disponível:

Lista de locais onde o serviço está disponível
Geografia	Região	Status de HA
`Asia Pacific`	Sydney (`au-syd`)	`MZR`
`Asia Pacific`	Tóquio (`jp-tok`)	`MZR`
`Asia Pacific`	Osaka (`jp-osa`)	`MZR`
`Europe`	Frankfurt (`eu-de`)	`MZR`
`Europe`	Londres (`eu-gb`)	`MZR`
`Europe`	Madri (`eu-es`)	`MZR`
`North America`	Dallas (`us-south`)	`MZR`
`North America`	Washington (`us-east`)	`MZR`
`North America`	Montreal (`ca-mon`)	`MZR`
`North America`	Toronto (`ca-tor`)	`MZR`
`South America`	São-Paulo (`br-sao`)	`MZR`

em que

Uma geografia é uma área geográfica ou corpo político maior que contém uma ou mais regiões.
Uma região é um território geográfico definido.

Uma região poderia ser uma área de código de endereçamento postal específico, uma cidade, um estado, um grupo de estados ou até mesmo um grupo de países.

Uma região contém várias zonas de disponibilidade para atender aos requisitos de acesso local, baixa latência e segurança da região.
N/A significa recurso que não é aplicável a essa geografia.
MZR significa região multizona. Saiba mais.

Disponibilidade de uma instância do Monitoring

Ao provisionar uma instância do Monitoring, você seleciona o MZR (local) onde a instância é criada. A região determina o local de processamento dos dados de monitoramento e de hospedagem dos dados.

Uma região multizona (MZR) consiste em três ou mais zonas de disponibilidade que são independentes umas das outras para assegurar que os eventos de falha única afetem apenas uma única zona.

Por padrão, cada instância de monitoramento consiste em três zonas, uma zona primária e duas zonas secundárias:

Cada zona está localizada em um data center diferente na região.
Os dados em sua zona primária são replicados automaticamente para as zonas secundárias com baixa latência. Não é necessário fazer nada para ativar a replicação.
Quando a zona primária falha, uma zona secundária é eleita como a primária para evitar que a sua instância de serviço seja afetada.
Se duas zonas falharem ao mesmo tempo, o serviço ficará indisponível.

A arquitetura MZR oferece failover automático entre duas zonas e alta disponibilidade para uma instância do Monitoring dentro de uma região.

Recursos de alta disponibilidade

IBM Cloud Monitoring oferece suporte aos seguintes recursos de alta disponibilidade:

Recursos de HA para IBM Cloud Monitoring
Recursos	Descrição
Implementação de regiões com várias zonas	IBM Cloud Monitoring é implantado em regiões multizonas (MZRs) e, dentro de uma MZR, o plano de dados abrange todas as três zonas, garantindo que a perda de uma zona não afete a disponibilidade do serviço.
Replicação de métricas da plataforma entre zonas	As métricas ingeridas no site IBM Cloud Monitoring são replicadas em três zonas dentro dos MZRs.
Monitoramento de vivacidade / prontidão	Todos os microsserviços são monitorados por meio de sondas de prontidão e vivacidade do site Kubernetes.

Arquitetura de recuperação de desastres

Falha em uma única zona: IBM Cloud Monitoring é HA e pode continuar a funcionar em qualquer falha de uma única zona ou máquina.

Falha regional: IBM Cloud Monitoring é um serviço de plataforma. Não há failover automático entre regiões ou recuperação de desastres entre regiões. Se todas as zonas de disponibilidade em uma região falharem, o site IBM Cloud Monitoring ficará indisponível nessa região.

Backup e restauração de banco de dados: os bancos de dados do IBM Cloud Monitoring são submetidos a backups periódicos e, em um cenário de recuperação de desastres, é possível criar uma recuperação pontual para restaurar os dados.

Recursos de recuperação de desastres

IBM Cloud Monitoring oferece suporte aos seguintes recursos de recuperação de desastres:

Recursos de DR para IBM Cloud Monitoring
Recursos	Descrição	Consideração
Vários destinos configuráveis	Detalhes podem ser encontrados para que os clientes se conectem às regiões disponíveis	A configuração deve ser implementada pelo cliente.

Planejamento para DR

As etapas do DR devem ser praticadas regularmente. Ao criar seu plano, considere os seguintes cenários de falha e resoluções.

Cenários de DR para IBM Cloud Monitoring
Falha	Resolução
Falha de hardware (ponto único)	IBM fornece um banco de dados que é resiliente a um único ponto de falha de hardware em uma zona, sem necessidade de configuração.
falha da zona	Não é necessária nenhuma configuração
Distorção de dados	IBM executa backups frequentes dos bancos de dados e, em caso de corrupção de dados, o serviço IBM Cloud Monitoring tentará restaurar usando um backup pontual do banco de dados regional.
Falha regional	Siga as etapas em Suas responsabilidades para HA e DR.

Suas responsabilidades com HA e DR

A recuperação de desastre trata-se de sobreviver a uma falha catastrófica ou perda de disponibilidade em uma única localização.

O IBM Cloud Monitoring segue os requisitos do IBM Cloud para planejar e recuperar-se de eventos de desastre.

Se ocorrer um desastre regional, considere as informações a seguir:

O tempo de recuperação estimado para a reconstrução do site regional e a restauração do serviço em outro local é de 24 horas.
Será necessário atualizar os terminais de aplicativos e agentes de monitoramento para apontarem para o terminal de ingestão no novo local.
Você terá que restaurar os metadados da instância de serviço, ou seja, os painéis e as definições de alerta, por meio de seus backups.

Os dados históricos podem ser perdidos durante um desastre. Se forem necessárias métricas históricas para propósitos de auditoria, faça backup delas regularmente, consultando as métricas do serviço e armazenando-as em um site de backup remoto. Para obter mais informações, consulte Extraindo métricas de uma instância do Monitoring usando a API.

Recuperação manual do serviço

Se ocorrer um desastre regional, o tempo de recuperação do serviço dependerá do tempo de recuperação da região. Para minimizar o tempo de inatividade do serviço e o impacto em seu negócio, seria possível implementar um failover manual para alternar para outra região enquanto a região está sendo restaurada. Para reduzir o tempo de funcionamento em um novo local, considere o uso de grupos de acesso para gerenciar permissões que trabalham com o serviço e faça backup dos metadados de monitoramento de cada instância. É necessário fazer backup dos alertas, das notificações, dos painéis e de definições de equipe regularmente.

Como continuar trabalhando enquanto um site de DR é reconstruído?

Quando os aplicativos e os serviços que estão sendo monitorados por meio de uma instância de monitoramento estão todos colocalizados na mesma região, deve-se aguardar que a região esteja disponível novamente para negócios.

Se você implementou agentes de monitoramento em seus sistemas e esses sistemas não foram afetados pela falha regional, é possível optar por redirecionar as métricas para outras instâncias de monitoramento em uma região diferente. Para redirecionar os dados de métrica, conclua as etapas a seguir:

Provisione uma instância de monitoramento
Reconfigure o agente de monitoramento de cada sistema: mude a chave de acesso e os terminais de ingestão na configuração do agente.
Defina permissões do IAM para trabalhar com a nova instância de monitoramento.

Usar grupos de acesso para gerenciar permissões para trabalhar com uma instância de monitoramento reduz a quantidade de trabalho que precisa ser feito para configurar as políticas e usuários corretos para trabalhar com uma nova instância. As informações sobre grupos de acesso são globais e não baseadas em região.
Ative a instância de monitoramento e importe os alertas, as notificações, as equipes e o painéis para monitorar seus aplicativos e sistemas.

Para saber mais sobre a responsabilidade entre você e o IBM Cloud pelo uso do IBM Cloud Monitoring, consulte Entendendo suas responsabilidades ao usar o IBM Cloud Monitoring.

Objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO)

A tabela a seguir indica os tempos de recuperação estimados em caso de DR:

Objetivos de recuperação para DR
Objetivo de recuperação para DR	Tempo estimado
Tempo máximo de indisponibilidade tolerável (MTD)/Objetivo de tempo de recuperação (RTO)	Até 24 horas
Objetivo de ponto de recuperação (RPO)	Até 24 horas

Gerenciamento de mudanças

O gerenciamento de alterações inclui tarefas como upgrades, alterações de configuração e exclusão.

Recomenda-se conceder 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. Consulte Como posso evitar a exclusão acidental de serviços?

É necessário fazer backup dos alertas, das notificações, dos painéis e de definições de equipe regularmente. Considere a possibilidade de criar um backup manual antes de fazer upgrade para uma nova versão do IBM Cloud Monitoring.

Como o site IBM® oferece suporte ao planejamento de recuperação de desastres

IBM® adota ações de recuperação específicas no caso de um desastre.

IBM realiza testes anuais de vários cenários de desastres e aprimora continuamente nossa documentação de recuperação com base nos resultados encontrados durante esses testes.
o suporte global 24 horas por dia, 7 dias por semana, está disponível para os clientes com os especialistas no assunto do site IBM®, que estão de plantão para ajudar em caso de desastre.
Todos os especialistas no assunto do site IBM são treinados anualmente em políticas e procedimentos de continuidade de negócios e recuperação de desastres para garantir a preparação no caso de um desastre.
Uma região de várias zonas (MZR) consiste em 3 ou mais zonas de disponibilidade independentes entre si para garantir que as métricas de falha única afetem apenas uma única zona.

Por padrão, o IBM Cloud Monitoring é implantado em 3 zonas. Cada zona é configurada como ativa/ativa/ativa:

Cada zona está localizada em um data center diferente na região.
As métricas da plataforma em cada zona são replicadas automaticamente para as outras zonas com baixa latência. Não é necessário fazer nada para ativar a replicação.
O serviço foi projetado para resistir a uma falha de zona única sem interrupção.
A arquitetura MZR oferece failover automático entre zonas dentro da região e alta disponibilidade para uma instância dentro de uma região.
IBM Cloud Monitoring os dados são armazenados em backup periodicamente e podem ser restaurados usando uma recuperação point-in-time em caso de desastre.

Como o IBM se recupera de falhas de zona

Em caso de falha de zona, o site IBM Cloud resolverá a interrupção da zona. Como o serviço se estende por todas as três zonas em uma região, não haverá impacto na disponibilidade do serviço em uma MZR. Após a recuperação da zona, os eventos e as solicitações de API voltarão a ser enviados para a zona restaurada. Não haverá necessidade de ação do cliente nesse momento.

Como o site IBM se recupera de falhas regionais

Quando uma região é restaurada após uma falha, o site IBM tentará restaurar a instância de serviço a partir do estado regional, sem perda de dados e com as mesmas cadeias de conexão.

Se o estado regional for corrompido, o serviço será restaurado para o estado do último backup interno. O serviço faz backup de todos os dados associados ao serviço uma vez por dia. Há um potencial de perda de dados de 24 horas. Quando um serviço é recuperado de backups com as mesmas cadeias de conexão. Para os dados do cliente, incluindo painéis, alertas e notificações, o cliente é responsável pela restauração dos dados.

Se o site IBM não puder restaurar a instância do serviço, o cliente deverá restaurar ou redirecionar conforme descrito em Recuperação manual do serviço.

Como o site IBM mantém os serviços

Todos os upgrades seguem as práticas recomendadas de serviço do site IBM e têm um plano de recuperação e um processo de reversão em vigor. Atualizações regulares para novos recursos e manutenção ocorrem como parte das operações normais. Essa manutenção pode ocasionalmente causar curtos intervalos de interrupção que são tratados 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. As atualizações são canceladas 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. Para obter mais informações, consulte notificações de monitoramento e status para manutenção planejada, anúncios e notas de versão que afetam esse serviço.