Alta disponibilidade e recuperação de desastre

A alta disponibilidade (HA) e a recuperação de desastres (DR) no site IBM® watsonx.data em IBM Cloud foram projetadas para ajudar a garantir a resiliência, o mínimo de tempo de inatividade e a proteção dos dados.

Alta disponibilidade (HA)

IBM® watsonx.data usa MZRs (Multi-Zone Regions, regiões de várias zonas) em IBM Cloud e AWS para oferecer alta disponibilidade. Os vários componentes do watsonx.data são implementados em uma configuração Active-Active e Active-Only para ajudar a garantir alta disponibilidade e resiliência.

Ativa/ativa

Em uma configuração ativa-ativa, várias instâncias de um componente são executadas simultaneamente em diferentes zonas de disponibilidade (AZs). Essas instâncias têm balanceamento de carga e podem lidar com solicitações em paralelo.

Principais características:

  • Redundância - se uma instância ou AZ falhar, as outras continuarão a atender ao tráfego sem interrupção.
  • Distribuição de carga - o tráfego é distribuído entre todas as instâncias ativas, melhorando o desempenho e reduzindo a latência.
  • Failover automático - Não é necessária nenhuma intervenção manual; o sistema redireciona o tráfego automaticamente.

Benefícios:

  • Alta tolerância a falhas.
  • Experiência de usuário perfeita durante falhas de zona.
  • Melhor utilização de recursos.

Em watsonx.data, a maioria dos componentes é implantada na configuração Active-Active com réplicas em várias zonas para ajudar a garantir a disponibilidade contínua. Por exemplo, Metadata Services (MDS) no plano Enterprise.

Ativo-Apenas

Em uma configuração Active-Only, um componente é executado em apenas uma zona de disponibilidade por vez. Se essa zona falhar, o componente deverá ser reiniciado ou reimplantado em outra zona.

Principais características:

  • Uma única instância ativa por componente.
  • Reinício automático em uma nova zona em caso de falha.
  • Ligeiro atraso durante o failover devido ao tempo de reinicialização.

Benefícios:

  • Arquitetura mais simples.
  • Redução do consumo de recursos.
  • Resiliência com um breve tempo de inatividade durante o failover.

Em watsonx.data, os componentes de locatário único são implantados na configuração Active-Only. Esses componentes de locatário único, que incluem o mecanismo Presto e os componentes do metastore, são estrategicamente distribuídos em três AZs para capacidade e failover. Esses componentes são reiniciados em uma nova zona durante a falha Por exemplo, Metadata Services (MDS) no plano Lite.

Nas regiões de várias zonas (MZRs), Presto e o MDS são distribuídos em diferentes zonas.

Quando uma única zona de disponibilidade falha em uma MZR, ou uma falha de hardware ocorre em qualquer região, as cargas de trabalho falham automaticamente e são reiniciadas em outras zonas dentro dessa região Cada instância do watsonx.data é fornecida com um depósito de metadados entre regiões padrão e um depósito de avaliação opcional (10 GB). Ambos os compartimentos estão ativados com IBM Cloud® Object Storage Versionamento. O backup dos dados é feito ativando a replicação em uma conta separada do IBM Cloud Object Storage. No entanto, para qualquer bucket externo que o cliente traga para a instância watsonx.data, o cliente é responsável por esses backups.

Em um desastre regional, você recebe um e-mail que inclui todas as etapas que você precisa seguir. Consulte as responsabilidades do watsonx.data. Os componentes de locatário único operam em um modelo 'Somente Ativo', assegurando a reinicialização imediata em novos nós que fornecem o mesmo serviço se houver uma falha

Componentes de locatário único são estrategicamente distribuídos em 3 AZs para melhorar a confiabilidade. Quando uma AZ falha, a capacidade suficiente para iniciar os serviços necessários nas AZs disponíveis é assegurada Isso minimiza qualquer impacto causado por uma indisponibilidade de AZ.

Responsabilidades

Backup

Responsabilidades da IBM

  • Backups diários automáticos: o site watsonx.data executa automaticamente backups diários de todos os recursos que são fornecidos e gerenciados pelo site IBM. Isso inclui:
    • Metadados do sistema
    • Definições de configuração
    • Dados internos gerenciados por watsonx.data
  • Armazenamento e segurança de backup: Esses backups são armazenados com segurança na infraestrutura do IBM, garantindo a durabilidade dos dados e a conformidade com os padrões de nível empresarial.

Responsabilidades do cliente

  1. Provisione uma nova instância para restauração:
    • Se for necessária uma restauração, o cliente deverá criar uma nova instância do watsonx.data para receber os dados restaurados.
    • Isso garante que o ambiente original permaneça intocado e que os dados restaurados possam ser validados com segurança.
  2. Valide os backups do site IBM: Após a restauração, o cliente deve verificar a integridade e a completude dos dados restaurados. Isso inclui a verificação de metadados, configurações e comportamento do sistema.
  3. Restaurar componentes externos:
    • Quaisquer fontes de dados ou componentes externos integrados ao watsonx.data (por exemplo, conectores personalizados, ferramentas de terceiros, conjuntos de dados gerenciados pelo usuário) não são armazenados em backup pelo IBM.
    • O cliente é responsável por fazer o backup e a restauração desses componentes separadamente.

Restaurar

Responsabilidades da IBM

Restauração dos recursos fornecidos: IBM cuida do processo de restauração real dos recursos dos quais faz backup. Isso inclui carregar o backup na nova instância e garantir a consistência em nível de sistema.

Responsabilidades do cliente

  1. Crie uma nova instância para restauração: O cliente deve iniciar uma nova instância de watsonx.data para receber os dados restaurados.
  2. Validar os dados restaurados: O cliente deve executar a validação pós-restauração para garantir que os dados restaurados sejam precisos e utilizáveis.
  3. Restaurar componentes externos: O cliente deve restaurar manualmente todas as integrações externas ou fontes de dados que faziam parte da configuração original.

Alta disponibilidade de nível do aplicativo

Os aplicativos que se comunicam sobre redes e serviços de nuvem estão sujeitos a falhas de conexão temporárias. Projete seus aplicativos para tentar conexões novamente quando uma perda temporária na conectividade com sua implementação ou com o IBM Cloudcausar erros. Como o watsonx.data é um serviço gerenciado, as atualizações e a manutenção regulares ocorrem como parte das operações normais. Tal manutenção ocasionalmente causa uma interrupção temporária do serviço.

Os seus aplicativos devem ser projetados para lidar com interrupções provisórias do serviço, implementar a manipulação de erros para os comandos com falha e implementar a lógica de nova tentativa para se recuperar delas.

A seguir estão alguns dos códigos de erros que podem ser esperados durante as interrupções temporárias de serviço:

Se um nó coordenador do Presto for reiniciado, seja para propósitos de manutenção ou devido a uma falha do sistema, os aplicativos serão necessários para restabelecer sua conexão com o mecanismo Presto

Não são esperados vários minutos de indisponibilidade ou interrupções de conexão. Abra um tíquete de suporte com detalhes se você tiver períodos de tempo superiores a um minuto sem conectividade, para que as interrupções sejam investigadas.

Estratégia de recuperação de desastres

O objetivo de tempo de recuperação (RTO) refere-se à duração máxima aceitável do tempo em que um sistema ou serviço pode ficar indisponível após uma falha. Ele define a rapidez com que o sistema deve ser restaurado para evitar interrupções significativas nas operações. O RTO em watsonx.data depende dos seguintes aspectos:

  • O ponto de backup mais recente.
  • Status do arquivamento de registros.
  • Etapas manuais necessárias para a restauração de metadados.

O objetivo do ponto de recuperação (RPO) refere-se à quantidade máxima aceitável de perda de dados no caso de uma falha. Indica o intervalo de tempo em que o sistema pode recuperar dados, com base no backup ou snapshot bem-sucedido mais recente. A recuperação é baseada no último backup bem-sucedido de metadados e no arquivo de registro. Pode haver um atraso entre a falha e o estado restaurado.

Para fortalecer a resiliência dos dados e minimizar possíveis perdas, a frequência de backup do serviço Milvus no ambiente SaaS foi aumentada. Essa alteração reduz o objetivo do ponto de recuperação (RPO) para apenas 2 horas, garantindo que os dados possam ser restaurados a partir de um ponto muito mais recente no caso de uma falha.

Localizações

Regiões AWS

  1. Oregon ( us-west-2 )
  2. N. Virgínia (us-east-1)
  3. Frankfurt ( eu-central-1 )
  4. Tokyo (jp-tok)

Regiões IBM

  1. Dallas (us-south)
  2. Washington (us-east)
  3. Frankfurt (eu-de)
  4. London (eu-gb)
  5. Tokyo (jp-tok)
  6. Sydney (au-syd)