Confiabilidade Máxima
Use os princípios de alta disponibilidade e recuperação de desastre para projetar uma arquitetura de nuvem de confiabilidade máxima.
Os sistemas de HA (alta disponibilidade) foram projetados para garantir que tenham o máximo potencial de período de disponibilidade e acessibilidade. 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.
Um plano de DR (recuperação de desastre) bem arquitetado permite que você se recupere rapidamente de desastres e continue a fornecer serviços aos seus usuários. DR é o processo de preparação e recuperação de um desastre. Um desastre pode ser qualquer evento que coloque seus aplicativos em risco, desde interrupções na rede, falhas de equipamentos e aplicativos até desastres naturais. Para projetar uma Recuperação de Desastre, implante seus aplicativos de missão crítica em várias regiões e use a replicação assíncrona entre regiões. Planeje a recuperação de desastre em todas as camadas da pilha, incluindo Rede, Computação, Armazenamento de Objetos, Banco de Dados e Monitoramento.
Recomendações de Arquitetura para Confiabilidade Máxima
Recomendamos uma abordagem em fases para confiabilidade máxima. Na primeira fase, implante uma arquitetura que forneça recursos de Alta Disponibilidade aproveitando os domínios de falha dentro de um domínio de disponibilidade. Se for necessária mais resiliência, na segunda fase, implante uma arquitetura que abranja várias regiões.
Para obter mais informações sobre regiões, domínios de disponibilidade e domínios de falha, consulte Regiões e Domínios de Disponibilidade.
Fase 1: Distribuir Instâncias entre Domínios de Falha
Os sistemas de alta disponibilidade foram projetados para evitar pontos únicos de falha. Um dos princípios chave para projetar um sistema de alta disponibilidade é distribuir as instâncias entre diversos domínios de falha. Utilizando corretamente domínios de falha, você pode aumentar a disponibilidade dos aplicativos em execução no Oracle Cloud Infrastructure.
A arquitetura do seu aplicativo determina se você separa ou agrupa instâncias usando domínios de falha.
Cenário A: Arquitetura de Aplicativo Altamente Disponível
Nesse cenário, você tem um aplicativo altamente disponível, por exemplo, você tem dois servidores Web e um banco de dados clusterizado. Nesse cenário, você deve agrupar um servidor Web e um nó de banco de dados em um domínio de falha e a outra metade de cada par em outro domínio de falha. Esse posicionamento garante que uma falha de qualquer um dos domínios de falha não resulte em uma interrupção do seu aplicativo.
Cenário B: Servidor Web Único e Arquitetura da Instância do Banco de Dados
Nesse cenário, sua arquitetura de aplicativo não está altamente disponível, por exemplo, você tem um servidor Web e uma instância de banco de dados. Nesse cenário, o servidor Web e a instância do banco de dados devem ser colocados no mesmo domínio de falha para minimizar indisponibilidades de clientes. Esse posicionamento garante que o aplicativo só seja impactado pela falha desse único domínio de falha, fornecendo uma maior disponibilidade geral do aplicativo.
SLAs Compostos
Quando os serviços são usados em combinação, a disponibilidade geral do sistema depende da disponibilidade de cada subsistema. Para maximizar a disponibilidade de um sistema com vários subcomponentes, minimize as dependências que os subcomponentes têm entre si. Isso significa que, dependendo da arquitetura do seu aplicativo, você poderá obter maior confiabilidade para um determinado grau de esforço de engenharia, aproveitando os domínios de falha dentro de um domínio de disponibilidade, em vez de expandir seus recursos entre domínios de disponibilidade.
Fase 2: Implantar Recursos em Várias Regiões
Para maximizar a resiliência de suas cargas de trabalho, implante suas cargas de trabalho da nuvem em várias regiões, em vez de em vários domínios de disponibilidade.
A implantação em várias regiões permite minimizar os riscos associados a uma interrupção regional, porque uma interrupção regional pode afetar todos os domínios de disponibilidade na região. A implantação em várias regiões também maximiza o valor do esforço de engenharia investido na transferência de suas cargas de trabalho em vários data centers.
Cenário C: Arquitetura de Várias Regiões
Nesse cenário, sua arquitetura replica a mesma pilha entre duas regiões.
Para fornecer uma origem de dados consistente nas duas regiões, use recursos de replicação, como GoldenGate para a camada de dados, Autonomous Data Guard para a camada de banco de dados e políticas de replicação do Object Storage no bucket de origem que identificam a região e o bucket no qual fazer a replicação.
Para a camada de front-end e aplicativo, crie um balanceador de carga e configure recursos de verificação de integridade nos recursos de backend implantados em domínios de falha nas duas regiões. Toda vez que você implantar um novo aplicativo em produção, implante-o em instâncias de ambas as regiões.
Explorar Mais
Documentação: