Perguntas frequentes sobre resiliência e disponibilidade contínua da Oracle Cloud Infrastructure Services and Platform

A Oracle distancia diferentes classes de serviço, como serviços críticos, serviços disponíveis continuamente ou serviços em um só local?

Nós não fazemos tais distinções. Em vez disso, nós classificamos os nossos serviços de acordo com o nível de dependência, escopo de disponibilidade e plano de dados vs. plano de controle. O objetivo dessas categorias é fornecer pontos positivos e negativos entre a disponibilidade, a durabilidade, o desempenho e a conveniência.

Níveis de dependência

Esses níveis podem ser classificados como camadas, ou faixas, em um diagrama de blocos. Cada camada pode depender de uma única camada abaixo dela.

De baixo para cima:

• Serviços principais: Esses serviços formam a base da Oracle Cloud Infrastructure. Incluem Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry, entre diversos outros serviços internos compartilhados. Eles foram projetados para terem menos dependências, mesmo entre si. (Vide mais a frente neste documento para mais detalhes sobre dependências).
• IaaS: Essa camada entrega mais funcionalidades a nível de infraestrutura desenvolvida no topo do núcleo. Os serviços nessa camada incluem File Storage, Database e Container Engine for Kubernetes.
• SaaS: Essa camada é um software como serviço poderoso, desenvolvido sobre as camadas inferiores.

Escopo de disponibilidade

Para atender aos requisitos de disponibilidade e durabilidade de um serviço, um dos escopos de disponibilidade a seguir é escolhido para cada serviço:

• Disponibilidade em domínio local: Cada domínio de disponibilidade contêm uma instância independente do serviço. Tais serviços oferecem armazenamento de longa durabilidade para dados, com replicação síncrona entre as cópias dentro de um mesmo domínio de disponibilidade (para obter mais detalhes, vide a seção sobre domínios de falhas mais a frente neste documento). Esses serviços podem tolerar uma queda tripla, ou ainda maior, da infraestrutura dentro do domínio de disponibilidade, a depender da natureza do serviço. A disponibilidade de serviços em domínio local alcançam esse nível de tolerância a falhas com a ajuda de dois tipos diferentes de data center lógico, isto é, grupos lógicos de isolamento de falhas e de desempenho, dentro do domínio de disponibilidade. Para mais detalhes, vide as seções sobre domínios de falha e células de serviços mais a frente neste documento. Finalmente, esses serviços podem continuar em funcionando mesmo que o domínio de disponibilidade esteja incomunicável com qualquer outro domínio. Como resultado, eles toleram a perda de outros domínios de disponibilidade, ou a falha completa de uma wide area network dentro de uma dada região.
• Múltiplos domínios de disponibilidade regionais: Cada região com múltiplos domínios de disponibilidade contém uma instância independente do serviço, contendo componentes localizados em cada domínio de disponibilidade naquela região. Esses serviços oferecem armazenamento de dados de altíssima durabilidade, utilizando a replicação síncrona para múltiplos domínios de disponibilidade dentro da mesma região. Esses serviços podem ser tolerados durante uma falha, ou durante a incapacidade de comunicação, de qualquer domínio de disponibilidade dentro da região.
• Domínio de disponibilidade único regional: Se uma região contiver só um domínio de disponibilidade, as características observáveis de um serviço regional corresponderão àquelas de um serviço local do domínio de disponibilidade, conforme descrito anteriormente. A distinção entre um serviço local do domínio de disponibilidade e um serviço regional do domínio de disponibilidade único só se tornará relevante quando uma região de domínio de disponibilidade for expandida por meio da inclusão de um ou mais domínios de disponibilidade. Quando isso acontece, cada serviço regional se expande de forma automática para utilizar adequadamente os novos domínios de disponibilidade, ao passo que ainda permanecem como uma única instância do serviço. Por exemplo, o plano de dados do Object Storage se expandiria para utilizar domínios de disponibilidade adicionais, com o intuito de melhorar a durabilidade dos dados existentes. Considerando que, para a disponibilizar os serviços de domínio local, cada novo domínio de disponibilidade recebe a sua própria nova instância de cada serviço sobre o domínio de disponibilidade local.
• Distribuído entre regiões: Um princípio fundamental da Oracle Cloud Infrastructure é de que cada região é independente operacionalmente de outras regiões, sempre que possível. O teor na medida do possível ocorre pelo fato de que as regiões devem, obrigatoriamente, compartilhar ao menos uma infraestrutura. Por exemplo, a rede backbone interrregional. Caso contrário, não criamos mecanismos de rede estreita entre regiões, como alta disponibilidade ou recuperação de falhas transparente, que poderiam causar problemas que afetam várias regiões simultaneamente. Em vez disso, oferecemos dois mecanismos para distribuir serviços entre as regiões com poucas opções:
  • Recuperação de desastre (RD): Permitir que os nossos clientes desenvolvam sistemas com recursos de RD é um grande divisor de águas em nossa abordagem e investimento na nuvem. Vários serviços básicos já oferecem mecanismos de RD - por exemplo, backup entre regiões do Block Volumes e cópia entre regiões do Object Storage. Todos os nossos serviços têm a funcionalidade de RD como itens de alta prioridade em suas metas de desenvolvimento.
  • Assinaturas interregião: Atualmente, nós fornecemos assinaturas interregionais somente para dados do IAM. De forma conceitual, os dados do IAM possuem escopo global. Os clientes podem se inscrever (aceitar) em um conjunto de regiões, e nós replicamos automaticamente todos os dados do IAM e as futuras atualizações às regiões específicas. Para evitar acoplamento forte, a replicação é assíncrona e eventualmente consistente. Os clientes fazem as modificações em seus dados do IAM em uma região inicial que eles escolherem. Caso a região inicial atual fique indisponível ou inviável por alguma razão, uma nova região, diferente da primeira, pode ser escolhida.

Plano de controle vs. Plano de dados

O plano de dados de um serviço é uma coletânea de interfaces e componentes de processamento de dados que implementam a funcionalidade do serviço destinada a ser usada pelas aplicações. Por exemplo, o plano de dados VCN (rede virtual na nuvem) inclui o sistema de processamento de pacote de rede, roteadores virtualizados e gateways, enquanto o plano de dados Block Volumes inclui a implementação do protocolo iSCSI e o sistema de armazenamento replicado tolerante a falhas para dados em volume.

O plano de controle de um serviço é um conjunto de APIs e componentes responsáveis pelo seguinte:

• Apresentação de solicitações ao cliente para provisionar, reconfigurar, escalar ou encerrar recursos.
• Realizar correção automatizada de frotas grandes, de forma rápida e segura
• Detectar recursos com falha, degradados ou configurados incorretamente
• Executar reparos automatizados ou chamar operadores humanos para obter assistência
• Colaborar com outros planos de controle, por exemplo, Compute, VCN, Block Storage são interligados durante o LaunchInstance
• Gerenciar a capacidade não alocada
• Coordenar com pessoas, por exemplo, ao chegar um novo equipamento, e reparo/manutenção física
• Fornecer controle e visibilidade operacional

Como a Oracle garante que os serviços sejam resilientes e disponíveis ininterruptamente?

Para todos os tipos de serviço, usamos o mesmo conjunto de princípios de engenharia para obter resiliência e disponibilidade, porque os desafios fundamentais da engenharia de criar sistemas distribuídos tolerantes a falhas e escaláveis são os mesmos para todos os tipos de serviço.

Para alcançar resiliência e disponibilidade ininterrupta é necessário entender e depois lidar com todas as causas da indisponibilidade, desempenho reduzido e falhas sem correções em sistemas de larga escala na nuvem. Por existirem diversos motivos para essas causas,nós as agrupamos em categorias, de acordo com a natureza fundamental de cada um

Normalmente, a análise da disponibilidade de sistemas empresariais de TI focam na falha de hardware. No entanto, para sistemas na nuvem, falha de hardware é um problema de menor potencial ofensivo. É relativamente fácil reduzir, e até mesmo evitar, diversos aspectos das falhas de hardware. Por exemplo, os racks podem ter dupla alimentação de energia e unidades de distribuição de energia, além de ser possível fazer hot swapping em diversos componentes. É possível haver falha e perda de hardware em larga escala, por exemplo, devido a desastres naturais. No entanto, nossa experiência, além dos relatórios de outros fornecedores de nuvem, mostra que a falha ou perda de todo um data center ocorre muito raramente, em relação a outras causas de indisponibilidade. Falhas de hardware em larga escala ainda devem ser tratadas, por exemplo, com recuperação de desastre, entre outros mecanismos. Porém, essas falhas estão longe de serem um problema relacionado principalmente à disponibilidade.

As principais causas de indisponibilidade em sistemas de larga escala na nuvem são as seguintes:

• Bugs em software
• Erros de configuração
• Erros cometidos por operadores humanos
  Observação: A principal lição do setor é que essas três formas de erro humano são, de longe, as maiores causas de indisponibilidade. Embora a frequência possa ser reduzida com ferramentas, automatização e treinamento, ela jamais será extinta. Sendo assim, devem ser tratadas com prioridade na arquitetura, design e implementação do sistema.
• Variação inaceitável do desempenho (latência ou throughput) por qualquer motivo, inclusive:
  • Efeito "noisy neighbors" em multitenant (falha de mecanismos QoS)
  • Incapacidade de rejeitar com eficiência a sobrecarga (acidental ou maliciosa) enquanto continua a realizar um trabalho útil
  • Perda distribuída, tempestades de mensagens, alto número de solicitações e outras interações "emergentes" caras
  • Choque frio (caches vazios) após um ciclo de energia, particularmente um ciclo de energia simultâneo de vários sistemas
  • Despesas gerais quando o sistema é dimensionado (por exemplo, sharding)
• Falha em limitar o " raio de explosão" (número de clientes e sistemas afetados) de qualquer um dos problemas precedentes.

Esses desafios são universais - eles fazem parte das "leis da física" de sistemas distribuídos em escala de nuvem.

Para cada uma das categorias precedentes, usamos estratégias de engenharia comprovadas para enfrentar o problema. Os mais importantes são:

• Princípios de design da arquitetura e do sistema
• Novos conceitos arquitetônicos (que normalmente surgem da aplicação dos princípios)
• Procedimentos de engenharia de serviços

Princípios de design da arquitetura e do sistema

Existem muitos desses princípios, mas vamos nos concentrar nos mais relevantes para a resiliência e a disponibilidade.

Processamento orientado à recuperação

Para tratar os bugs no software e os erros causados pelos operadores que possuam efeitos mais localizados, seguimos os princípios de processamento orientado à recuperação¹. Em um nível mais alto, isso significa que, em vez de tentar garantir que nunca tenhamos um problema (o que é impossível de testar), focamos em tratar os problemas de modo discreto, de forma que possam ser testados. Em particular, focamos na redução do tempo médio de recuperação (MTTR), que é uma combinação de tempo médio de detecção, tempo médio de diagnóstico e tempo médio de mitigação.

O nosso objetivo é recuperar tão rápido que os usuários humanos não sejam impactados pelo problema. Os seguintes pontos que nos ajudam a alcançar esse objetivo:

• Detectar de forma rápida e automática os sintomas causados pelos bugs e erros de operadores, pelo uso extensivo de afirmações em código, além de monitoramento ativo e alarme em todos os níveis.
• Distribuir a funcionalidade em várias unidades de isolamento separadas e detalhadas (threads, processos, fibras, máquinas de estado e assim por diante) que são pareadas de modo fraco - isso é, elas não compartilham diretamente memória que possa ser corrompida.
• Ao detectar os sintomas causados por um bug, ou um erro causado pelo operador, a unidade de isolamento deve ser reiniciada automaticamente, assim que possível. A reinicialização é uma maneira prática de tentar recuperar-se de uma falha arbitrária, porque tenta restabelecer um estado que foi bem testado, e, portanto, restaura elementos invariáveis.
• Se a recuperação no nível detalhado de isolamento não funcionar - por exemplo, as asserções continuam sendo disparadas nesse nível muito frequentemente, causando spin-crashing - escale para a próxima unidade maior, isto é, processo, tempo de execução, host, data center lógico, solicitação de um operador humano.
• Criar mecanismos para ativar uma operação de "desfazer em nível de sistema", incluindo o controle de versões de todo o estado e configuração persistentes, para identificar e desfazer rapidamente as alterações incorretas.

Reduzir os efeitos dos problemas

Para lidar com bugs e erros de maior amplitude, nós desenvolvemos mecanismos para reduzir a propagação de quaisquer problemas. Ou seja, nosso foco é minimizar o número de clientes, sistemas ou recursos afetados pelos problemas, incluindo as questões particularmente desafiadoras de "noisy neighbors", sobrecarga oferecida, capacidade degradada e thrash distribuído. Para isso, usamos vários limites de isolamento e práticas de gestão de mudança (veja as seções a seguir).

Conceitos arquitetônicos provenientes dos princípios de design

Muitos desses conceitos existem, mas vamos focar em conceitos para limitar o raio de explosão.

Conceitos de posicionamento cobertos por nossa API pública: Regiões, domínios de disponibilidade e domínios de falha

Como os domínios de falha são relativamente novos, vamos apresentá-los em mais detalhes.

Os domínios de falha são usados para limitar o raio de explosão dos problemas que acontecem quando o sistema está sendo alterado ativamente- por exemplo, implementação de correções, reinícios do hipervisor e manutenção física.

A garantia é de que, em um dado domínio de disponibilidade, os recursos de um domínio com falha estão sendo carregados em qualquer ponto no tempo. Se algo der errado com o processo de mudança, alguns ou todos os recursos desse domínio de falha talvez estejam indisponíveis por algum tempo, mas os outros domínios de falha do domínio de disponibilidade não são afetados. Cada domínio de disponibilidade contém, ao menos, três domínios de falha, para permitir que sistemas de replicação por quórum, por exemplo, o Oracle Data Guard, sejam hospedados dentro de um único domínio de disponibilidade de alta disponibilidade.

Como resultado, para uma categoria dominante de problemas de disponibilidade - bugs de software, erros de configuração, operadores e problemas de desempenho que ocorrem durante um procedimento de alteração - cada domínio de falha atua como um data center lógico separado dentro de um domínio de disponibilidade.

Os domínios de falha também protegem contra falha de hardware localizado As propriedades dos domínios de falha garantem que os recursos alocados em diferentes domínios de falha não compartilhem quaisquer pontos de falha do hardware dentro do domínio de disponibilidade, na maior extensão possível. Por exemplo, recursos em diferentes domínios de falhas não compartilham o mesmo setor do switch de rede, já que o design padrão desses switches não comporta a redundância.

No entanto, a capacidade de os domínios de falha protegerem contra problemas no hardware ou no ambiente físico termina nesse nível local. Em relação aos domínios e regiões de disponibilidade, os domínios de falha, em larga escala, não entregam nenhuma isolação física da infraestrutura. Na rara eventualidade de um desastre natural ou falha de infraestrutura no nível do domínio de disponibilidade, os recursos de vários domínios de falha seriam afetados ao mesmo tempo.

Os nossos serviços internos utilizam domínios de falha da mesma forma que os clientes deveriam usá-los. Por exemplo, os serviços Block Volumes, Object Storage e File Storage armazenam réplicas dos dados em três domínios de falha diferentes. Todos os componentes de todos os planos de controle e planos de dados são hospedados em todos os três domínios de falha, ou em uma região com vários domínios de disponibilidade, em vários domínios de disponibilidade.

Células de serviço

As células de serviço são usadas para limitar o raio de alcance dos problemas quando um sistema não está sendo modificado de forma ativa. Tais problemas podem surgir porque a carga de trabalho de um sistema em nuvem multitenant pode mudar de maneiras extremas a qualquer momento, e porque falhas parciais complexas podem ocorrer em qualquer lugar e distribuído a qualquer momento. Esses cenários podem dar início a bugs escondidos ou problemas emergentes no desempenho.

Além disso, as células de serviço limitam o raio de alcance em alguns cenários raros, porém desafiadores, quando o sistema está sendo modificado de forma ativa. Um exemplo clássico é quando a implementação em um domínio de falha parece bem-sucedida - sem erros ou mudança no desempenho - mas assim que o segundo ou último domínio de falha é atualizado, novas interações dentro do sistema (na escala total da nuvem com carga de trabalho de produção) causam um problema de desempenho.

Observe que o uso das células de serviço é um padrão arquitetônico e não um conceito notadamente mencionado na Oracle Cloud API ou SDK. Qualquer sistema multitenant pode usar esse padrão arquitetônico; não é necessário suporte especial pela plataforma na nuvem.

As células de serviço trabalham da seguinte forma:

• Cada instância do serviço, por exemplo, uma região específica, ou um domínio de disponibilidade específico para os serviços locais de disponibilidade, são compostos de diversas implementações independentes da pilha de software do serviço. Cada implementação, separadamente, é chamada de célula. Cada célula é hospedada em sua própria infraestrutura, de forma a manter a praticidade. No mínimo, as células não compartilham hosts, nem VMs.
• Um serviço pode começar com um conjunto de células em cada região ou domínio de disponibilidade. Conforme o serviço é escalado para atender ao aumento da demanda, mais células são adicionadas para manter o limite no tamanho do raio de explosão de quaisquer problemas. Um serviço grande e popular pode conter diversas células. Em outras palavras, as células fornecem multiplexação "n-m" de cargas de trabalho de clientes para separar ambientes de hospedagem - ilhas de isolamento de recursos separadas. As células não possuem cardinalidade explícita, ao contrário do que ocorre com os domínios de falha. (Como mencionado anteriormente, uma escolha óbvia para os domínios de falha é três por domínio de disponibilidade, para permitir a hospedagem de sistemas de replicação baseados em quorum com alta disponibilidade em um só domínio de disponibilidade.)
• Cada "unidade natural" da carga de trabalho de um cliente é atribuída a uma célula específica. A definição de "unidade natural" depende da origem do serviço em questão. Por exemplo, para o nosso serviço interno compartilhado de Workflow, vide detalhes mais adiante, a unidade natural deveria ser "todos os fluxos de trabalho neste domínio ou região de disponibilidade para um plano de controle em particular".
• À frente de cada grupo de células existe uma dessas: uma camada minimalista de redirecionamento, ou uma API para descobrir novos endpoints de células. Por exemplo, o sistema de Streaming/Mensagens tem uma API para descobrir o endpoint do plano de dados atual de um tópico em particular, e o armazenamento de Metadados interno tem um ponto final separado por célula. No entanto, outros serviços baseados em células possuem um endpoint único de plano de dados, além de uma única camada compartilhada de redirecionamento. A camada de roteamento é uma causa potencial de falha correlacionada de várias células, mas ela é reduzida, mantendo a camada de roteamento extremamente simples, previsível e eficaz (sem operações caras) e provisionando-a com um grande volume de capacidade de margem e mecanismos sofisticados de cota e limitação QoS.
• Os donos dos serviços podem migrar uma carga de trabalho de uma célula para outra, conforme necessário. Veja a seguir alguns cenários como exemplo:
  • Para ajudar a evitar o problema de "noisy neighbors", transferindo uma carga de trabalho pesada de forma que outros usuários de uma célula não sejam impactados.
  • Para ajudar a recuperar de uma sobrecarga ou queda repentina de tensão, causadas talvez por um ataque distribuído de negação de serviço. Temos mecanismos de cota e limitação para defesa contra tais ataques, mas às vezes ocorrem casos em que um uso específico (API, padrão de acesso) é mais impactante para o serviço do que o sistema de cota ou limitação entende atualmente. A célula oferece um mecanismo para redução em curto prazo.
  • Para separar as cargas de trabalho em células diferentes, a fim de reduzir substancialmente a probabilidade de falhas correlacionadas. Por exemplo, em nosso Workflow interno compartilhado para planos de controle, cada um dos planos de controle de "núcleo crítico"(por exemplo, Platform, Computing, Networking e Block Volumes) é designado a células diferentes, e, portanto, tem muito menos correlação de falha do que seria se as células não fossem usadas, ou se fossem designadas à mesma célula.
    Observação: Note que usar as células dessa forma reduz a necessidade de trabalhar com dependências internas de serviços, com a finalidade de criar aplicações resilientes. Considerando que o gráfico de dependência ainda é uma boa prática (mais sobre isso adiante neste documento), mas há menos necessidade dele quando um mecanismo de correlação já está ativo.

O resultado é que cada célula de serviço é somente outro tipo de "data center lógico", isto é, um agrupamento lógico de isolamento de desempenho e de falhas, dentro de um domínio único ou região de disponibilidade.

Em suma, as células de serviço e os domínios de falha se complementam da seguinte forma:

• Os domínios de falha protegem contra os problemas quando um sistema está sendo alterado de forma ativa.
• As células de serviço limitam o raio de alcance quando o sistema enfrenta problemas potencialmente graves, independentemente se estiver sendo modificado de forma ativa.

Nós combinamos as propriedades dos domínios de falha e das células de serviço em uma estratégia unificada sempre que alguma implementação ou correção é realizada.

Procedimentos de engenharia de serviços

Como a excelência nos testes e na operação é fundamental para a confiabilidade dos sistemas em nuvem, temos um grande número de procedimentos de engenharia. Veja a seguir alguns dos mais importantes que aproveitam os conceitos mencionados na seção anterior:

• Implemente serviços de modo incremental, com validação cuidadosa entre etapas, e rollback reflexivo se algo surpreendente acontecer. O processo ocorre da seguinte forma:
  • Em cada domínio de disponibilidade, nós implementamos uma célula de serviço por vez. Para cada célula, nós implementamos um domínio de falha por vez, até que todos os domínios de falha tenham sido implementados para aquela célula. Em seguida, passamos para a próxima célula dentro do domínio de disponibilidade.
  • Após cada etapa da implementação, após cada célula e domínio de falha, nós certificamos de que as alterações estejam funcionando corretamente, ou seja, de que o desempenho não caiu, não haja erros, sejam internos ou externos. Caso aconteça algum erro, ou algo inesperado, nós desfazemos as alterações. Nós enfatizamos muito a preparação e os testes, incluindo testes automáticos, dos procedimentos de restauração, incluindo alterações que afetam o estado ou esquemas persistentes.
  • Dessa forma, implementamos as mudanças em um domínio de disponibilidade por vez para cada região. Implementamos em todas as regiões de um domínio de tal forma que no momento não modificaremos nenhum par de regiões que o cliente possa estar usando para sites primários e de recuperação de desastres.
• Nós verificamos regularmente se os mecanismos de tratamento de erros e outros tipos de mitigação funcionam conforme o esperado e não pioram o problema em escala. Sem esses testes, é comum que mecanismos de tratamento de erros (como repetições, algoritmos de recuperação de acidente e algoritmos de reconfiguração de máquina de estado) tenham bugs, sejam muito caros ou interajam de formas incomuns, e assim causem hiperpaginação ou outros problemas graves de desempenho.
• Avaliamos a nossa capacidade de reverter de forma rápida e segura para o software e configuração corretos utilizados da última vez, incluindo estado e esquema persistentes, conforme descrito antes.

Sobre as regiões da Oracle que possuem múltiplos domínios de disponibilidade: todos os serviços críticos são distribuídos entre os domínios de disponibilidade?

Sim. Em cada região, todos os domínios de disponibilidade oferecem o mesmo conjunto de serviços.

Como a Oracle e seus clientes evitam serviços críticos que dependam de um único data center lógico?

Em regiões com domínio de disponibilidade único, os clientes podem usar domínios de falha (grupos lógicos com modos de falha não correlacionados entre grupos) para obter o máximo das propriedades de "data centers lógicos" separados. Os clientes também podem lançar mão de múltiplas regiões para recuperação de desastre (RD).

Dentro de regiões com múltiplos domínios de disponibilidade, os clientes podem utilizar os domínios de falha da mesma forma. Os clientes também podem usar uma combinação de serviços locais no domínio de disponibilidade, recursos de failover entre domínios de disponibilidade (como DBaaS com Data Guard) e serviços regionais (Object Storage, Streaming) para obter HA completa em "data centers lógicos" (domínios de disponibilidade) de nível mais alto. Finalmente, os clientes também podem usar as múltiplas regiões para RD.

Em todos os casos, os clientes podem usar o conceito de células de serviços para isolar até os casos mais graves, como despejo distribuído.

Como a Oracle conduz atividades de manutenção sem deixar qualquer serviço crítico indisponível a qualquer cliente?

Esse resultado só é possível por meio dos domínios de falhas, células de serviço e dos nossos procedimentos operacionais para aumentar a implementação e a validação. Vide a discussão do assunto anteriormente neste documento.

Os serviços de plataforma serverless são implementados em diversos data centers lógicos, com a finalidade de aumentar a disponibilidade?

Sim. Todas as categorias de serviços são implementadas em vários data centers lógicos - agrupamentos lógicos separados de isolamento de falha e de desempenho - para resiliência e disponibilidade contínuas.

Caso a resiliência não seja uma configuração padrão, os clientes recebem a opção de escolher uma implementação em múltiplos data centers lógicos, por exemplo, uma configuração de domínio de disponibilidade múltipla ou de região cruzada?

Em regiões de domínio de disponibilidade único, oferecemos domínios de falha como o mecanismo para " vários data centers lógicos", conforme discutido em outra parte deste documento.

Em regiões de vários domínios de disponibilidade, oferecemos serviços e recursos que proporcionam um nível ainda mais alto de durabilidade física de dados replicados síncronos (a um desempenho modesto, custo por causa da distância entre os domínios de disponibilidade da região e da velocidade da luz).

Não oferecemos alta disponibilidade automática ou mecanismos de fail-over entre regiões, pois isso criaria um relacionamento de acoplamento forte entre regiões, e incorreria no risco de que várias regiões possam enfrentar problemas ao mesmo tempo. Em vez disso, capacitamos várias formas de replicação assíncrona entre regiões, e oferecemos um aumento dos recursos da lista, como cópia e backup assíncronos, para permitir a Recuperação de Desastres nas regiões.

Como a Oracle ajuda os clientes a evitar falhas correlacionadas de aplicações causadas por dependências internas entre os vários serviços de infraestrutura e plataforma?

Essa é uma pergunta complexa. Para deixar claro, vamos responder de formas diferentes.

• Se um cliente quiser usar dois serviços da Oracle (serviço A e serviço B) e quiser criar uma aplicação resiliente se um desses serviços falhar, o cliente precisa saber se o serviço A depende internamente do serviço B? As dependências internas geram falhas correspondentes em grande escala? Sendo assim, o cliente talvez precise conhecer tais dependências internas, para decidir quais outros usos vai fazer do serviço A e do serviço B - ou se, em vez disso, vai introduzir um serviço C não relacionado para esses casos adicionais - ao criar seus próprios mecanismos de resiliência no nível da aplicação.
• Como os clientes podem se defender contra qualquer falha relacionada aos serviços Oracle?

Vamos responder em duas partes.

Princípios arquitetônicos

Utilizamos princípios arquitetônicos que reduzem drasticamente falhas correlacionadas entre os serviços dependentes. Em alguns casos, essa técnica reduz a probabilidade de falha correlacionada até um ponto em que ela possa ser ignorada da perspectiva do cumprimento de um contrato de nível de serviço (SLA).

Em especial, utilizamos células de serviços na forma descrita anteriormente neste documento. As células ajudam com esse problema porque, se o serviço interno A for afetado por um problema em uma de suas dependências, o serviço B, o problema com o serviço B muito provavelmente se limitará a uma única célula. É provável que outros serviços de níveis maiores, incluindo outras aplicações próprias dos clientes, que usem o serviço B acabem utilizando outras células que não foram afetadas. Este é um argumento probabilístico que varia de acordo com o número de células, o que é um parâmetro interno oculto que não se altera (aumenta). Portanto, não é fornecida nenhuma quantificação ou garantia, além dos SLAs de serviço independente dos serviços A e B. Porém, na prática, isso pode tirar a relação das falhas entre os serviços.

Muitos dos nossos serviços internos compartilhados - por exemplo, os serviços de Workflow e Metadados para planos de controle, e o serviço de Streaming/Mensagens - usam células de serviço para descorrelacionar interrupções nos serviços ascendentes que os utilizam.

Dependências

As diretrizes abaixo são de alto nível porque a implementação de baixo nível e os detalhes dos serviços podem, e consequentemente, mudarão. Mas para as principais dimensões de computação, armazenamento, rede e autenticação/autorização, indicamos as seguintes dependências.

Para planos de controle, as dependências mais comuns são as seguintes:

• O plano de dados Identity/Platform para autenticação e autorização
• O serviço de acompanhamento de auditoria
• Serviços internos que oferecem, por exemplo, fluxo de trabalho, armazenamento de metadado e logs
• Balanceadores de carga de diversos tipos

Alguns planos de controle possuem dependências específicas para cada serviço. Por exemplo, o plano de controle Compute, quando está executando uma instância bare metal ou MV, depende de:

• Object Storage (retornar a imagem do sistema operacional especificado)
• Plano de controle Block Volumes, para gerar e anexar o volume de inicialização
• Plano de controle de rede, para gerar e anexar VNICs

Para planos de dados de serviços básicos, o princípio geral é que cada plano de dados é projetado intencionalmente para ter dependências mínimas, a fim de obter alta disponibilidade e diagnóstico/recuperação mais rápidos. Os resultados desse princípio são os seguintes:

• O plano de dados Networking é autocontido.
• O plano de dados do Block Volume é autocontido.
• As instâncias VM e bare metal de Compute dependem do plano de dados do Block Volume (para volumes de inicialização) e do plano de dados Networking.
• O plano de dados Object Storage depende do plano de dados Identity/Platform para a autenticação e autorização, por conta das expectativas do setor. O plano de dados do Object Storage não depende do Block Volume ou do File Storage.
• Todos os serviços que suportem backup e restauração dependem do plano de dados Object Storage para executar esse recurso.

Para planos de dados IaaS, o princípio geral é depender apenas dos planos de dados básico ou inferior (para evitar dependências cíclicas).

• O banco de dados RAC multinó depende do plano de dados Networking e do Block Volumes.
• O Container Engine for Kubernetes obviamente depende do Kubernetes e de suas dependências transitivas (por exemplo, etcd) e do plano de dados Networking.
• Todo o suporte para backup e restauração depende do plano de dados Object Store.

Os serviços da Oracle Cloud Infrastructure em uma região, incluindo endpoints de API regionais, continuarão a funcionar se estiverem isolados das funções do plano de controle global?

Sim, os serviços da Oracle Cloud Infrastructure são arquitetados para serem independentes da região, de modo que os serviços em uma região da Oracle Cloud Infrastructure possam continuar operando mesmo quando a região é isolada de outras regiões da Oracle Cloud Infrastructure e/ou plano de controle global. A funcionalidade do plano de dados e do plano de controle, incluindo endpoints de API de serviço, continua disponível mesmo que a região esteja isolada.

Muitos serviços da Oracle Cloud Infrastructure oferecem funcionalidade entre regiões, como a função de cópia de objetos entre regiões oferecida pelo Oracle Cloud Infrastructure Object Storage. A funcionalidade entre regiões na Oracle Cloud Infrastructure é sempre projetada como uma camada no topo do serviço principal para que o isolamento entre regiões não afete o serviço principal mesmo que isso afete a funcionalidade entre regiões. Como exemplo, a funcionalidade de cópia entre regiões do armazenamento de objetos da Oracle Cloud Infrastructure é projetada como camada no topo do serviço de armazenamento de objetos e, consequentemente, o isolamento de uma região pode afetar a função de cópia entre regiões relevante, mas não afetará o serviço de armazenamento de objetos principal na região.

O Oracle Cloud Infrastructure Services dentro de um data center lógico continua as operações mesmo quando isolado das funções do plano de controle regional?

Sim, os serviços da Oracle Cloud Infrastructure são projetados de modo que a funcionalidade do plano de dados em cada data center lógico continue a funcionar mesmo quando isolado do plano de controle regional correspondente. Como exemplo, as instâncias de processamento da Oracle Cloud Infrastructure em um data center lógico continuarão a funcionar com volumes em blocos anexados e a funcionalidade de rede virtual associada, mesmo quando o data center for isolado das funções do plano de controle de computação, armazenamento em blocos, VCN e/ou gerenciamento de identidade e acesso.

As regiões da Oracle Cloud Infrastructure possuem conexão de internet redundante para aumentar a disponibilidade?

Sim. A Oracle Cloud Infrastructure está conectada à internet através de múltiplos provedores redundantes em todas regiões comerciais. Essas conexões usam BGP (Border Gateway Protocol).