Documentação do Oracle Cloud Infrastructure

Alta Disponibilidade

Os sistemas de HA (alta disponibilidade) são projetados para garantir que tenham o potencial máximo de tempo de atividade e acessibilidade.

Os aplicativos empresariais são fundamentais para as operações comerciais diárias e precisam estar disponíveis. Espera-se que esses sistemas estejam sempre funcionando e que nunca haja inatividade. Embora seja impossível excluir totalmente o tempo de inatividade, você pode minimizar os impactos negativos da inatividade garantindo que seus aplicativos tenham alta disponibilidade. Para garantir a Alta Disponibilidade, elimine pontos únicos de falha, de modo que, mesmo que os componentes falhem, o aplicativo permaneça em execução e disponível. O OCI (Oracle Cloud Infrastructure) fornece recursos de HA e melhores práticas de topologia de nuvem confiável e resiliente que permitem criar aplicativos empresariais com alta disponibilidade.

Como arquiteturas multicamadas ou de três camadas são comuns em aplicativos empresariais on-premises tradicionais, vamos usar um exemplo de aplicativo empresarial de três camadas para mostrar como você pode usar os recursos de HA do OCI e as melhores práticas de topologia de nuvem confiável e resiliente para fazer com que esse aplicativo tenha alta disponibilidade. O diagrama a seguir mostra um exemplo de aplicativo empresarial em uma configuração de HA de região única.

Exemplo de aplicativo empresarial em uma configuração de alta disponibilidade de região única.

Essas informações não abrangem a conectividade de on-premises com o OCI nem os aspectos de recuperação de desastre da infraestrutura.

Conceitos de HA

Quando sua infraestrutura está configurada para fornecer disponibilidade quase em tempo integral, esse é um sistema de HA.

Para projetar uma arquitetura de alta disponibilidade, considere os seguintes elementos principais:

  • Redundância: Cada recurso tem pelo menos um recurso semelhante pronto para entrar e assumir o controle? Observe que, em cada camada mostrada no diagrama, os recursos sempre têm um principal e um stand-by, e os recursos estão em diferentes domínios de disponibilidade e domínios de falha para evitar SPOF (pontos únicos de falha).
  • Monitoramento: Os recursos principais estão funcionando conforme esperado? Se não, em que ponto o recurso de backup assume como principal?
  • Failover: Quando os critérios são atendidos para acionar um switch de principal para stand-by, o stand-by está pronto?

A obtenção da alta disponibilidade exige que um sistema leve em conta todos esses elementos. Embora a alta disponibilidade possa ser obtida em muitos níveis diferentes (incluindo o nível de aplicativo e o nível de infraestrutura de nuvem), esta seção se concentra no nível de infraestrutura da nuvem. Para obter mais informações, consulte Saiba mais sobre como arquitetar uma topologia de nuvem altamente disponível.

Escolhendo uma Abordagem de HA

Alguns aplicativos são mais críticos do que outros. Use a árvore de decisão a seguir para decidir quais recursos de HA do OCI devem ser usados ao implantar aplicativos empresariais de várias camadas no OCI.

Árvore de decisão para decidir quais recursos de alta disponibilidade do OCI devem ser usados ao implantar aplicativos empresariais de várias camadas.

Para nosso exemplo de aplicativo empresarial, precisamos de alta disponibilidade e ser capazes de sobreviver a uma interrupção do domínio de disponibilidade. Além disso, precisamos ser capazes de sobreviver a uma interrupção regional, mas podermos lidar com algum tempo de inatividade se uma região for afetada. Por esses motivos, escolhemos uma implantação ativa/passiva em várias regiões. Os aspectos de implantação passiva são abordados em Recuperação de Desastre.

Medindo a Alta Disponibilidade

Alta disponibilidade é a capacidade de um sistema de atender a um nível contínuo de desempenho operacional ou período de disponibilidade por um determinado período.

A disponibilidade geralmente é expressa como porcentagem do período de disponibilidade em um ano, geralmente descrita em termos de "noves". A tabela a seguir mostra os níveis de disponibilidade e o período de indisponibilidade associado de cada nível.

% de Disponibilidade Disponibilidade (Noves) Período de Indisponibilidade por Ano Período de Indisponibilidade por Mês Período de Indisponibilidade por Semana Período de Indisponibilidade por Dia
90% Um nove 36,53 dias 73.,5 horas 16,80 horas 2,40 horas
99% Dois noves 3,65 dias 7,31 horas 1,68 hora 14,40 minutos
99,9% Três noves 8,77 horas 43,83 minutos 10,08 minutos 1,44 minuto
99,99% Quatro noves 52,60 minutos 4,38 minutos 1,01 minuto 8,64 segundos
99,999% Cinco noves 5,26 minutos 26,30 segundos 6,05 segundos 864,00 milissegundos
99,9999% Seis noves 31,56 segundos 2,63 segundos 604,80 milissegundos 86,40 milissegundos
99,99999% Sete noves 3,16 segundos 262,98 milissegundos 60,48 milissegundos 8,64 milissegundos
99,999999% Oito noves 315,58 milissegundos 26,30 milissegundos 6,05 milissegundos 864,00 microssegundos
99,9999999% Nove noves 31,56 milissegundos 2,63 milissegundos 604,80 microssegundos 86,40 microssegundos

Cada serviço do Oracle Cloud Infrastructure geralmente tem um SLA (contrato de serviço) que define a disponibilidade esperada desse serviço. A maioria das soluções de nuvem exige que você use uma combinação de serviços para obter a arquitetura desejada para a sua implantação da nuvem. Quando os serviços são usados em combinação, a disponibilidade geral do sistema depende da disponibilidade de cada um dos subsistemas. O SLA geral para um sistema com vários componentes é chamado de SLA composto.

Para calcular o SLA composto de um sistema ou aplicativo, considere todos os subsistemas e como esses sistemas são configurados. Por exemplo, considere um cenário em que um aplicativo depende de dois sistemas: A e B. Cada sistema tem 99,9% de disponibilidade. Os sistemas são serialmente dependentes, conforme mostrado na imagem a seguir.

Diagrama de um exemplo de sistema com subsistemas serialmente dependentes.

Se o Sistema A ou o Sistema B estiver indisponível, o sistema inteiro ficará indisponível. Para esse tipo de configuração do sistema, você pode calcular o SLA composto multiplicando a disponibilidade dos dois sistemas: 99,9% × 99,9% = 99,8%. Por causa da dependência serial entre os dois sistemas, o SLA composto resultante de 99,8% é menor que os SLAs individuais de cada sistema.

Consideraçõe de Design de Alta Disponibilidade

O Oracle Cloud Infrastructure fornece os blocos de construção que permitem ativar a Alta Disponibilidade para sua infraestrutura.

O exemplo de aplicativo empresarial usa serviços dentro dos conceitos do OCI de regiões, domínios de disponibilidade e domínios de falha. O uso de vários domínios de disponibilidade e vários domínios de falha, dentro de cada um desses domínios de disponibilidade, aumenta a redundância e elimina o SPOF. Para obter informações de apoio sobre regiões e uma lista de recursos disponíveis entre regiões, dentro de uma única região, ou dentro de um único domínio de disponibilidade, consulte Regiões e Domínios de Disponibilidade.

Recomendamos que você revise as informações relevantes de resiliência do produto OCI e, em seguida, com base nos produtos de plataforma OCI escolhidos, ajuste as arquiteturas para acomodar quaisquer lacunas entre os recursos do produto e seus requisitos de alta disponibilidade.

Na sua região inicial, a Oracle cria sua tenancy e é aí que os recursos de IAM (Identity and Access Management) da sua organização são definidos. Dependendo dos seus requisitos de negócios, você pode se inscrever em outras regiões e o IAM propagará automaticamente as atualizações para todas as regiões da sua tenancy. Para obter mais informações, consulte Gerenciando Regiões.

Redes

Depois de criar a base das VCNs (redes virtuais na nuvem) e sub-redes, para fornecer alta disponibilidade, use o serviço de Balanceamento de Carga para distribuir o tráfego. Quando um balanceador de carga é implantado, ele usa uma configuração de HA (alta disponibilidade), conforme mostrado no exemplo de diagrama de arquitetura. Para obter mais informações, consulte Planejar Alta Disponibilidade para Recursos de Rede.

Computação

Para eliminar o SPOF, crie várias instâncias de computação que são distribuídas entre domínios de falha em cada um dos domínios de disponibilidade. Coloque as instâncias de computação por trás de um balanceador de carga para distribuir o tráfego e obter alta disponibilidade, conforme mostrado na arquitetura de exemplo. Para obter mais informações, consulte Visão Geral do Serviço Compute, Melhores Práticas para suas Instâncias de Computação e Planejar Alta Disponibilidade para as Instâncias de Computação.

Armazenamento

O OCI fornece um conjunto de serviços de armazenamento (Block Volume, File Storage e Object Storage), que você pode configurar para atender aos requisitos de uma arquitetura de alta disponibilidade.

O Object Storage é uma plataforma de armazenamento de alto desempenho em escala na internet que oferece durabilidade de dados confiável e econômica. O Object Storage é um serviço regional e está disponível em todos os domínios de disponibilidade dentro de uma região. Os dados são armazenados redundantemente em vários servidores de armazenamento e em vários domínios de disponibilidade para garantir alta disponibilidade. O Object Storage também inclui autocorreção automática e monitoramento de integridade de dados para aprimorar ainda mais sua durabilidade e disponibilidade.

O File Storage fornece um sistema de arquivos de rede durável, escalável e seguro de nível empresarial. Ele usa uma arquitetura resiliente que replica dados cinco vezes em diferentes domínios de falha, garantindo alta disponibilidade e durabilidade. O File Storage pode ser dimensionado automaticamente para acomodar o crescimento de até 8 exabytes de dados. Os instantâneos e os clones do sistema de arquivos podem ser usados para proteger dados contra exclusões acidentais e para fazer cópias de dados instantaneamente. Os ciclos de vida dos instantâneos podem ser gerenciados automaticamente usando o recurso instantâneo baseado em política.

Os volumes em blocos são duráveis e altamente disponíveis, armazenando várias cópias de dados de forma redundante em servidores de armazenamento com mecanismos de reparo integrados. Os volumes em blocos podem ser anexados a uma ou várias máquinas virtuais (VM) e persistem além da vida útil das máquinas virtuais. Os volumes em blocos melhoram ainda mais a alta disponibilidade com backups automatizados para os recursos de Armazenamento de Objetos e clonagem de volumes.

Para ver as etapas de criação de recursos de armazenamento, consulte Criando um Volume, Criando Sistemas de Arquivos e Gerenciando Buckets. Para obter as melhores práticas, consulte Planejar Alta Disponibilidade para Armazenamento.

Banco de Dados

Os bancos de dados Oracle da OCI vêm em vários modelos ou sabores de implementação. Cada modelo oferece um conjunto crescente de recursos de HA.

Independentemente do sistema de banco de dados usado, recomendamos que você se refira a MAA (Maximum Availability Architecture), que é um conjunto de melhores práticas desenvolvidas por engenheiros da Oracle durante muitos anos para o uso integrado de tecnologias de alta disponibilidade, protecção de dados e Recuperação de desastres da Oracle.

Serviço OCI Base Database

O OCI Base Database Service permite que você tenha controle total sobre seus dados, aproveitando os recursos do Oracle Database e da OCI. Para obter a lista de edições do Banco de Dados suportadas e as formas de computação subjacentes nas quais elas podem ser implantadas, consulte a documentação do OCI Base Database Service. Os recursos de HA mencionados se aplicam a todas as versões do banco de dados ou às formas de computação subjacentes.

A Enterprise Edition Extreme Performance Edition permite um sistema de banco de dados RAC (Real Application Cluster) de dois nós com nós que abrangem diferentes domínios de falha dentro do mesmo domínio de disponibilidade. Isso fornece alta disponibilidade nos seguintes cenários:

  • Proteção contra falha de nó
  • Manutenção de software com tempo de inatividade zero
  • Alterações elásticas (CPU, memória e armazenamento) sem tempo de inatividade
  • (Quase) Manutenção não planejada transparente

Se a HA for necessária entre os domínios de disponibilidade, você poderá considerar um banco de dados stand-by passivo ativado para RAC espelhando o sistema de banco de dados RAC principal, com dados replicados por meio do Oracle Data Guard. O failover para o stand-by passivo pode ser manual com um pequeno tempo de inatividade.

Observação: O OCI Base Database suporta no máximo dois nós RAC. Para versões do Oracle Database ou para nós RAC maiores que 2, considere o Exadata Database on Dedicated Infrastructure (ExaDB-D) da OCI.

Exadata Database on Dedicated Infrastructure (ExaDB-D)

O Exadata fornece recursos de alta disponibilidade integrados.

Todas as melhores práticas existentes com o Exadata on-premises são aplicáveis. Os conceitos descritos para o OCI Base Database, como RAC e Data Guard (para banco de dados stand-by), são aplicáveis ao Exadata Database on Dedicated Infrastructure (ExaDB-D), com os seguintes atributos adicionais:

  • O Exadata Database on Dedicated Infrastructure (ExaDB-D) permite mais de dois nós RAC, o que é uma limitação com o sistema Base Database.
  • Escalabilidade, desempenho e disponibilidade do Exadata
  • Agilidade do Exadata com número variável de VMs, armazenamento e recursos de computação
  • Proteção de dados e Exadata QoS para operações de banco de dados

O Exadata tem detecção de falhas instantânea que pode detectar falhas no nó do banco de dados, no servidor de armazenamento e na rede em menos de 2 segundos e retomar o tempo de atividade e o desempenho do serviço de aplicativo e banco de dados.

Recomendamos as seguintes configurações para garantir a disponibilidade contínua de seus aplicativos.

  • Use os serviços de banco de dados gerenciados pelo Oracle Clusterware para conectar seu aplicativo. Para ambientes Oracle Data Guard, use serviços baseados em atribuição.
  • Use a string de conexão recomendada com timeouts, novas tentativas e atrasos incorporados, para que as conexões recebidas não vejam erros durante interrupções.
  • Configure suas conexões com o Fast Application Notification.
  • Aproveite o Continuidade do Aplicativo ou o Continuidade Transparente do Aplicativo para repetir transações não confirmadas em execução de forma transparente após falhas.

Autonomous Database

Por padrão, o Oracle Autonomous Database (ADB) é altamente disponível, incorporando uma configuração de vários nós para proteção contra falhas de hardware localizadas.

Cada serviço de aplicativo do ADB reside em pelo menos uma instância do Oracle Real Application Clusters (Oracle RAC), com a opção de failover para outra instância do Oracle RAC disponível para paralisações não planejadas ou atividades de manutenção planejadas, permitindo tempo de inatividade zero ou quase zero.

Os principais upgrades de banco de dados são automatizados. Além disso, o tempo de inatividade do Oracle Autonomous Database Serverless (ADB-S) é mínimo.

Os contratos de nível de serviço (SLAs) de tempo de atividade por mês são de 99,95% (um máximo de 22 minutos de tempo de inatividade por mês).

O ADB-S permite um local (em ADs ou em ADs para regiões com um único AD) e um stand-by remoto adicional.

O Autonomous Data Guard adiciona um banco de dados stand-by simétrico com o Oracle Data Guard a um rack do Exadata localmente (em ADs ou em ADs para regiões com um único AD) com um adicional em outra região. Os sistemas de banco de dados principal e stand-by são configurados simetricamente para garantir que os níveis dos serviços de desempenho sejam mantidos após a transição da atribuição de Data Guard.

As melhores práticas para manter os tempos de disponibilidade dos aplicativos são descritas aqui.

Monitoring

O serviço Monitoring permite monitorar ativamente e passivamente seus recursos de nuvem para obter maior disponibilidade e níveis de serviço consistentes. Por exemplo, consulte Monitoramento Ponto a Ponto de aplicativos em execução no Oracle Cloud Infrastructure.

Explorar Mais

Playbooks de Soluções:

Arquiteturas de Referência:

Blogs e outros recursos: