Isenção de Responsabilidades

O texto apresentado a seguir tem como objetivo esboçar nossas intenções gerais em relação aos produtos. Destina-se apenas a fins informativos e não pode ser incorporado a contratos. Não constitui um compromisso de entrega de qualquer tipo de material, código ou funcionalidade e não deve ser considerado em decisões de compra. O desenvolvimento, a liberação, a data de disponibilidade e os preços dos recursos ou funcionalidades descritos para produtos da Oracle podem ser alterados e são de critério exclusivo da Oracle.

Esta seção de Perguntas mais Frequentes responde a perguntas comuns sobre como a Oracle obtém a resiliência e a disponibilidade contínua dos nossos principais serviços de infraestrutura e plataforma hospedeira. Os clientes do Oracle Cloud talvez estejam interessados nessas respostas por diversos motivos:

  • Elas ajudam os clientes a praticar diligência prévia ao avaliar a plataforma hospedeira e os serviços da Oracle.
  • Muitas das respostas discutem os desafios e soluções fundamentais a todos os sistemas em escala de nuvem, e assim podem informar a arquitetura e projeto de sistemas que os clientes desejam criar na nuvem.

Perguntas mais Frequentes sobre Resiliência e Disponibilidade Contínua dos Serviços e da Plataforma do Oracle Cloud Infrastructure

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

Não fazemos tais distinções. Em vez disso, categorizamos nossos serviços por nível de dependência, escopo de disponibilidade e plano de dados X plano de controle. Essas categorias se destinam a oferecer vários prós e contras entre disponibilidade, durabilidade, desempenho e conveniência.

Níveis de Dependência

Eles podem ser considerados camadas ou níveis em um diagrama de blocos arquitetônicos. Cada camada só pode depender das camadas abaixo dela.

De baixo para cima:

  • Serviços básicos: Esses serviços formam a base do Oracle Cloud Infrastructure. Eles incluem Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry e vários serviços internos compartilhados. Eles foram projetados para ter dependências mínimas, até mesmo de um para o outro. (Veja adiante neste documento os detalhes sobre dependências).
  • IaaS: Essa camada oferece mais funcionalidade no nível da infraestrutura que é construída em cima da base. Os serviços dessa camada incluem File Storage, Database e Container Engine para Kubernetes.
  • SaaS: Esta camada é um software como serviço cheia de recursos, criada sobre camadas inferiores.
Escopo de Disponibilidade

Para atingir as metas de disponibilidade e durabilidade de um serviço, um dos seguintes escopos de disponibilidade é escolhido para cada serviço:

  • Local do domínio de disponibilidade: Cada domínio de disponibilidade contém uma instância independente do serviço. Tais serviços oferecem alta durabilidade dos dados armazenados, usando replicação síncrona entre réplicas dentro do mesmo domínio de disponibilidade (para ver detalhes, consulte a seção sobre domínios de falha mais adiante neste documento). Esses serviços podem tolerar uma interrupção de um terço ou mais da infraestrutura no domínio de disponibilidade, dependendo da natureza do serviço. Os serviços locais do domínio de disponibilidade obtêm esse nível de tolerância a falhas usando dois tipos diferentes de data center lógico — grupos lógicos de isolamento de falhas e de desempenho — dentro do domínio de disponibilidade. Para saber detalhes, consulte as seções sobre domínios de falha e células de serviço mais adiante neste documento. Finalmente, esses serviços poderão continuar a funcionar normalmente mesmo que o domínio de disponibilidade não possa se comunicar com quaisquer outros domínios de disponibilidade. Como resultado, eles toleram a perda de outros domínios de disponibilidade ou a falha completa da rede de longa distância dentro da região.
  • Vários domínios de disponibilidade regionais: Cada região com vários domínios de disponibilidade contém uma instância independente do serviço, com componentes localizados em cada domínio de disponibilidade dessa região. Esses serviços oferecem alta durabilidade de dados armazenados usando replicação síncrona para vários domínios da mesma região. Esses serviços podem tolerar uma interrupção da comunicação ou a incapacidade de comunicar-se com qualquer domínio de disponibilidade único na 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 torna relevante quando uma região de domínio de disponibilidade único é expandida por meio da inclusão de um ou mais domínios de disponibilidade. Quando isso acontece, cada serviço regional se expande automaticamente para fazer uso apropriado dos novos domínios de disponibilidade, permanecendo ao mesmo tempo uma instância única do serviço. Por exemplo, o plano de dados Object Storage se expandiria para usar os domínios de disponibilidade adicionais para aumentar a durabilidade dos dados existentes. Por outro lado, para serviços locais do domínio de disponibilidade, cada um dos novos domínios de disponibilidade recebe sua própria e distinta instância de cada serviço local do domínio de disponibilidade.
  • Distribuição entre regiões: Um princípio básico do Oracle Cloud Infrastructure é que cada região é tão operacionalmente independente de outras regiões quanto possível. A qualificação quanto possível reflete o fato de que as regiões devem necessariamente compartilhar pelo menos alguma infraestrutura, por exemplo, a rede backbone inter-regional. Por outro lado, não criamos mecanismos de 'close-coupling' (acoplamento forte) entre regiões, como alta disponibilidade ou failover transparente, que poderiam causar problemas que afetam várias regiões simultaneamente. Em vez disso, fornecemos dois mecanismos para distribuir serviços nas regiões com 'loose coupling' (acoplamento fraco):
    • Recuperação de desastres (RD): Permitir que nossos clientes criem sistemas com características de RD é uma base que sustenta nossa metodologia 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.
    • Inscrições entre regiões: No momento, só fornecemos inscrições entre regiões para dados do IAM. Conceitualmente, os dados do IAM têm escopo global. Os consumidores podem se inscrever (por aceitação) em um conjunto de regiões, e replicamos automaticamente os dados relevantes do IAM e atualizações subsequentes para as regiões especificadas. Para evitar acoplamento forte, a replicação é assíncrona e eventualmente consistente. Os consumidores fazem modificações em seus dados do IAM em uma região "inicial" que designam. Se a região inicial atual ficar indisponível ou não for adequada por algum motivo, outra região poderá ser designada.
Plano de Controle X Plano de Dados

O plano de dados de um serviço é a coletânea de interfaces e componentes de processamento de dados que implementam a funcionalidade do serviço destinada a ser usada por aplicativos. 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 pelas seguintes tarefas:

  • Tratar de solicitações de consumidores para provisionar, reconfigurar, expandir/reduzir ou encerrar recursos.
  • Executar aplicação de patches automatizada de grandes frotas, de modo rápido e seguro
  • Detectar recursos com falha, prejudicados ou mal configurados
  • Executar reparo automatizado ou chamar operadores humanos para obter ajuda
  • Colaborar com outros planos de controle (por exemplo, Compute, VCN e Block Storage são acoplados durante LaunchInstance)
  • Gerenciar capacidade não utilizada
  • Coordenar-se com seres humanos, por exemplo, na chegada de um novo equipamento, e no reparo e manutenção físicos
  • Fornecer visibilidade e controle operacional
 
 

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

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 obter resiliência e disponibilidade contínua, é necessário entender e depois lidar com todas as causas da indisponibilidade — desempenho prejudicado e falhas não tratadas — em sistemas de escala de nuvem. Há um grande número de causas como essa, portanto nós as agrupamos em categorias de acordo com sua natureza fundamental.

Tradicionalmente, a análise da disponibilidade de sistemas empresariais de TI vem se concentrando na categoria de falha de hardware. Entretanto, para sistemas em nuvem, a falha de hardware é um problema relativamente menor e bem compreendido. Agora é relativamente fácil evitar ou mitigar a maioria dos pontos de falha únicos de hardware. Por exemplo, os racks podem ter alimentações de energia duplas e unidades de distribuição de energia associadas, e muitos componentes são plugáveis a quente. Naturalmente, falha e perda de hardware em grande escala são possíveis — por exemplo, em decorrência de desastres naturais. No entanto, nossa experiência, além dos relatórios em post-mortems públicos de outros fornecedores de nuvem, mostra que a falha ou perda de todo um data center acontece de modo extremamente raro, em relação às outras causas de indisponibilidade. A falha de hardware em grande escala ainda tem que ser tratada (por exemplo, com recuperação de desastres e outros mecanismos), mas está longe de ser o problema de disponibilidade dominante.

São as seguintes as causas dominantes da indisponibilidade nos sistemas em escala de nuvem:

  1. Bugs de software
  2. Erros de configuração
  3. 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 sua frequência possa ser reduzida por ferramentas, automação e treinamento, não é possível eliminá-los. Portanto, eles devem ser enfrentados como as principais preocupações na arquitetura, projeto e implementação do sistema.
  4. Variação inaceitável do desempenho (latência ou throughput) por qualquer motivo, inclusive estes:
    • "Vizinhos barulhentos" multitenant (falha dos mecanismos de QoS)
    • Incapacidade de rejeitar a sobrecarga (acidental ou maliciosa) de modo eficiente, ao mesmo tempo continuando a fazer um trabalho útil
    • Hiperpaginação (thrashing), tempestades de mensagens, tempestades 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 ao escalar o sistema (por exemplo, novo sharding)
  5. 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. As mais importantes são:

  • Princípios de arquitetura e projeto de sistemas
  • Novos conceitos arquitetônicos (que em geral derivam da aplicação dos princípios)
  • Procedimentos de engenharia de serviços
Princípios de Arquitetura e Projeto de Sistemas

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

Computação Orientada à Recuperação

Para lidar com bugs de software e erros de operadores que têm efeitos relativamente localizados, seguimos os princípios da computação orientada à recuperação1. Em um nível alto, isso significa que em vez de tentar garantir que nunca tenhamos um problema (o que é impossível de testar), nós nos concentramos em tratar dos problemas de modo discreto, de forma que possam ser testados. Em particular, focamos na minimização do MTTR (tempo médio de recuperação), que é uma combinação de tempo médio de detecção, tempo médio de diagnóstico e tempo médio de mitigação.

Nossa meta é recuperar tão rápido que os usuários humanos não sejam impactados pelo problema. Os pontos a seguir nos ajudam a atingir essa meta:

  • Detectar de forma rápida e automática os sintomas de bugs e erros de operadores, pelo uso extensivo de asserçõ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 etc.) que são acopladas de modo fraco — ou seja, elas não compartilham diretamente memória que possa se corromper.
  • Ao detectar os sintomas de um bug ou erro de um operador, reinicie automaticamente a unidade de isolamento delimitadora o mais rápido possível. A reinicialização é uma maneira prática de tentar recuperar-se de uma falha arbitrária, porque ela 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 continuarem a ser disparadas nesse nível muito frequentemente, causando spin-crashing), escale para a próxima unidade maior (processo, runtime, host, data center lógico, paginação de um operador humano).
  • Criar mecanismos para ativar uma operação de "desfazer em nível de sistema", incluindo controle de versões de todo o estado e configuração persistentes, para identificar e desfazer rapidamente commits incorretos.

Minimizando os Efeitos dos Problemas

Para lidar com bugs e erros que possam ter efeitos mais amplos, criamos mecanismos para minimizar o "raio de explosã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 "vizinhos barulhentos" multitenant, sobrecarga oferecida, capacidade degradada e hiperpaginação (thrashing). Conseguimos isso usando vários limites de isolamento e práticas de gestão da mudança (veja as seções a seguir).

Conceitos Arquitetônicos Provenientes dos Princípios de Design

Existem muitos desses conceitos, mas vamos nos concentrar naqueles que limitam 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 descrevê-los em mais detalhes.

Os domínios de falha são usados para limitar o raio de explosão dos problemas que acontecem quando um sistema está sendo alterado ativamente— por exemplo, implantações, aplicações de patches, reinicializações do hypervisor e manutenção física.

A garantia é que, em um determinado domínio de disponibilidade, os recursos de no máximo um domínio de falha estejam sendo alterados a qualquer momento. Se algo der errado com o processo de mudança, alguns ou todos os recursos desse domínio de falha talvez fiquem 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 pelo menos três domínios de falha, para permitir a hospedagem de sistemas de replicação baseados em quórum (por exemplo, Oracle Data Guard) com alta disponibilidade dentro de um só domínio de disponibilidade.

Como resultado, para uma categoria dominante de problemas de disponibilidade — bugs de software, erros de configuração, erros de 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 alguns tipos de falha de hardware localizada. As propriedades dos domínios de falha garantem que os recursos colocados em diferentes domínios de falha não compartilhem nenhum ponto único de falha de hardware em potencial dentro do domínio de disponibilidade, na medida máxima da praticidade. Por exemplo, os recursos de diferentes domínios de falha não compartilham o mesmo comutador de rede TOR ("top-of-rack"), porque o design padrão de tais comutadores não tem 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. Ao contrário dos domínios de disponibilidade e regiões, os domínios de falha não oferecem isolamento físico da infraestrutura em larga escala. 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 provavelmente seriam afetados ao mesmo tempo.

Nossos serviços internos usam domínios de falha da mesma forma que os clientes deveriam estar usando. Por exemplo, os serviços Block Volumes, Object Storage e File Storage armazenam réplicas de dados em três domínios de falha separados. 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 explosão de problemas que acontecem até mesmo quando um sistema não está sendo alterado ativamente. Tais problemas podem surgir porque a carga de trabalho de um sistema em nuvem multitenant pode mudar de formas extremas a qualquer momento, e porque falhas parciais complexas podem ocorrer inesperadamente em qualquer sistema distribuído de grande porte. Esses cenários podem disparar bugs ocultos sutis ou problemas de desempenho emergentes.

Além disso, as células de serviço também limitam o raio de explosão em alguns cenários raros, porém desafiadores, nos quais o sistema está sendo alterado ativamente. Um exemplo clássico é quando a implantação em um domínio de falha parece bem-sucedida — sem erros ou mudança no desempenho —, mas logo que o segundo (ou final) domínio de falha tiver sido atualizado, novas interações dentro do sistema (na escala completa da nuvem com carga de trabalho de produção) causarão um problema de desempenho.

Observe que o uso das células de serviço é um padrão arquitetônico, não um conceito explicitamente denominado na API ou SDK do Oracle Cloud. Qualquer sistema multitenant pode usar esse padrão arquitetônico; ele não requer suporte especial da plataforma de nuvem.

As chamadas de serviço funcionam como se segue:

  • Cada instância do serviço (por exemplo, em uma determinada região ou em um domínio de disponibilidade em particular para serviços locais do domínio de disponibilidade) consiste em várias implantações separadas da pilha de software do serviço. Cada implantação separada é chamada de célula. Cada célula é hospedada em sua própria infraestrutura, na medida em que seja praticável. No nível mínimo, as células não compartilham hosts ou VMs.
  • Um serviço pode começar com uma certa quantidade de células em cada domínio de disponibilidade ou região. À medida que 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 popular de grande porte pode ter muitas células. Em outras palavras, as células oferecem multiplexação "n-to-m" de cargas de trabalho de clientes para separar ambientes de hospedagem — ilhas separadas de isolamento de recursos. As células não têm uma cardinalidade óbvia, como acontece com os domínios de falha. (Conforme mencionado anteriormente, uma escolha óbvia para a cardinalidade dos domínios de falha é três por domínio de disponibilidade, para permitir a hospedagem de sistemas de replicação baseados em quórum com alta disponibilidade em um só domínio de disponibilidade.)
  • Cada "limite natural" da carga de trabalho de um cliente é designada a uma célula em particular. A definição de "unidade natural" depende da natureza do serviço em particular. Por exemplo, para nosso serviço interno de Workflow compartilhado (descrito posteriormente), a unidade natural pode ser "todos os fluxos de trabalho neste domínio de disponibilidade ou região para um plano de controle em particular".
  • Na frente de cada grupo de células está uma camada de roteamento minimalista ou uma API para descobrir pontos finais de célula. Por exemplo, o sistema de Streaming/Mensagens tem uma API para descobrir o ponto final 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élula têm um ponto final de plano de dados único e uma camada de roteamento compartilhada. A camada de roteamento é uma causa potencial de falha correlacionada de várias células, mas essa situação é mitigada mantendo-se a camada de roteamento extremamente simples, previsível e operacional (sem operações caras) e provisionando-a com um grande volume de capacidade de margem e mecanismos sofisticados de cota de QoS e limitação.
  • Os proprietários do serviço podem transferir uma carga de trabalho de uma célula para outra, conforme a necessidade. A seguir apresentamos alguns cenários exemplificativos:
    • Para ajudar a evitar o problema de "vizinho barulhento" multitenant, transferindo uma carga de trabalho pesada de forma que outros usuários de uma célula não sejam impactados.
    • Para ajudar a recuperar-se de uma sobrecarga ou queda de energia, causados 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 limítrofes nos quais um caso de uso em particular (API, padrão de acesso) é mais impactante para o serviço do que o sistema de cota ou limitação entende no momento. As células oferecem um mecanismo para mitigação de curto prazo.
    • Para separar cargas de trabalho críticas em células diferentes, a fim de reduzir significativamente a probabilidade de falha correlacionada. Por exemplo, em nosso Workflow compartilhado interno para planos de controle, cada um dos planos de controle "básicos críticos" (por exemplo, Plataforma, Computação, Rede e Volumes em Blocos) é designado a células diferentes, e portanto tem muito menos correlação de falha do que seria o caso se as células não fossem usadas, ou se fossem designados à mesma célula.
      Observe que este uso das células reduz a necessidade de os clientes considerarem as dependências internas de serviços para criar aplicativos resilientes. Considera-se 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 ainda é outro tipo de "data center lógico" — um grupamento lógico de isolamento de desempenho e de falhas — dentro de um domínio de disponibilidade único ou região.

Em resumo, as células de serviço e os domínios de falha complementam-se mutuamente das seguintes formas:

  • Os domínios de falha protegem contra problemas quando um sistema está sendo alterado ativamente.
  • As células de serviço limitam o raio de explosão quando um sistema enfrenta problemas potencialmente graves — quer esteja sendo ativamente alterado ou não.

Combinamos as propriedades de domínios de falha e células de serviço em uma estratégia unificada quando executamos implantações e aplicação de patches.

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. A seguir estão alguns dos mais importantes que utilizam os conceitos mencionados na seção precedente:

  • Implantamos serviços de modo incremental, com validação cuidadosa ente etapas, e reversão reflexiva se algo surpreendente acontecer. Em termos concretos, o processo é como se segue:
    • Em cada domínio de disponibilidade, implantamos em uma célula de serviço de cada vez. Para cada célula, implantamos em um domínio de falha de cada vez, até completarmos todos os domínios de falha dessa célula. Em seguida, avançamos até a próxima célula desse domínio de disponibilidade.
    • Após cada etapa da implantação (depois de cada domínio de falha e célula), validamos se a alteração está funcionando conforme pretendido — ou seja, o desempenho não foi prejudicado e nenhum erro foi introduzido, seja interna ou externamente. Se algo parecer errado ou inesperado, fazemos uma reversão reflexiva na alteração. Enfatizamos de modo veemente a preparação e os testes, incluindo testes automáticos, dos procedimentos de reversão, inclusive alterações que afetem o estado ou esquemas persistentes.
    • Desse modo, implantamos a alteração em um domínio de disponibilidade de cada vez nas regiões individuais. Implantamos em todas as regiões de um realm de tal forma que no momento não modificamos nenhum par de regiões que o cliente possa estar usando para sites principais 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 panes e algoritmos de reconfiguração de máquina de estado) tenham bugs, sejam muito caros ou interajam de formas surpreendentes, e assim causem hiperpaginação (thrashing) ou outros problemas sérios de desempenho.
  • Verificamos 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.
 
 

Nas regiões da Oracle que contêm vários domínios de disponibilidade, os serviços críticos são todos distribuídos pelos 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 ter um serviço fundamental que dependa de um só 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 usar várias regiões para recuperação de desastres (RD).

Em regiões com vários domínios de disponibilidade, os clientes podem usar 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 (Armazenamento de Objetos, Streaming) para obter alta disponibilidade total entre "data centers lógicos" (domínios de disponibilidade) de nível mais alto. Finalmente, os clientes também podem usar várias regiões para RD.

Em todos os casos, os clientes podem usar o conceito de células de serviço para isolar ainda mais os problemas mais graves, como hiperpaginação (thrashing).

 
 

Como a Oracle conduz atividades de manutenção sem indisponibilizar temporariamente algum serviço fundamental para os clientes?

Conseguimos isso por meio de domínios de falha, células de serviço e nossos procedimentos operacionais para implantação e validação incremental. Veja a discussão anterior neste documento.

 
 

Os serviços de plataforma sem servidor são implantados em vários data centers lógicos para obter alta disponibilidade?

Sim. Todas as categorias de serviços são implantadas em vários data centers lógicos — grupamentos lógicos separados de isolamento de falha e de desempenho — para obter resiliência e disponibilidade contínua.

 
 

Se a resiliência não for a configuração padrão, os clientes têm a opção de uma implantação de vários data centers lógicos (por exemplo, uma configuração de vários domínios de disponibilidade ou entre regiões)?

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 com 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 uma relação custo-desempenho modesta 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 uma crescente lista de recursos, 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 a falha correlacionada de aplicativos causada por dependências internas entre os vários serviços de infraestrutura e plataforma?

Esta é uma questão complicada. Portanto, para esclarecer, vamos discuti-la de algumas formas diferentes:

  • Se um cliente quiser usar dois serviços da Oracle (serviço A e serviço B) e quiser criar um aplicativo resiliente caso um desses serviços falhe, o cliente precisa saber se o serviço A depende internamente do serviço B? As dependências internas causam, até um grau significativo, uma falha correlacionada? Se for o caso, 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 do aplicativo.
  • Como o cliente pode se defender da melhor forma contra qualquer falha correlacionada dos serviços da Oracle?

A resposta se divide em duas partes.

Princípios Arquitetônicos

Usamos princípios arquitetônicos que reduzem significativamente a falha correlacionada entre serviços dependentes. Em alguns casos, esta técnica reduz a probabilidade de falha correlacionada até um ponto em que ela possa ser ignorada do ponto de vista do cumprimento de um acordo de nível de serviço (SLA).

Em particular, usamos chamadas de serviço, conforme descrito 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 ficará confinado a uma só célula. Outros serviços de nível mais alto — e os próprios aplicativos do cliente — que usarem o serviço B provavelmente estarão usando outras células que não forem afetadas. Este é um argumento de probabilidade que varia com o número de células, o que é um parâmetro interno oculto que não se altera (aumenta). Portanto, não é dada 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 descorrelacionar falhas entre serviços de modo significativo.

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

A orientação a seguir é de alto nível porque a implementação de nível baixo e os detalhes dos serviços podem mudar e de fato mudam. Contudo, para as dimensões principais de computação, armazenamento, rede e autenticação/autorização, indicamos as dependências a seguir.

Para planos de controle, as dependências comuns são como se segue:

  1. O plano de dados Identity/Platform para autenticação e autorização
  2. O serviço de acompanhamento de auditoria
  3. Serviços internos que oferecem, por exemplo, workflow, armazenamento de metadados e registro em log
  4. Balanceadores de carga de vários tipos

Alguns planos de controle obviamente têm dependências específicas do serviço. Por exemplo, o plano de controle Computação, ao iniciar uma instância bare metal ou VM, depende de:

  • Armazenamento de Objetos (para recuperar a imagem do sistema operacional especificada)
  • Plano de controle Volumes em Blocos (para provisionar e vincular o volume de inicialização)
  • Plano de controle Rede (para provisionar e vincular 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 como se segue:

  • O plano de dados Networking é autocontido.
  • O plano de dados Block Volumes é autocontido.
  • As instâncias de Computação bare metal e VM dependem do plano de dados Block Volumes (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 autenticação e autorização (por causa das expectativas do mercado). O plano de dados Object Storage não depende do Block Volumes ou do File Storage.
  • Todos os serviços que suportam backup e restauração dependem do plano de dados Object Storage para esse recurso.

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

  • O banco de dados RAC com vários nós depende do plano de dados Networking e do plano de dados Block Volumes.
  • O Container Engine para Kubernetes obviamente depende do Kubernetes e das respectivas dependências transitivas (por exemplo, etc) e do plano de dados Networking.
  • Todo o suporte para backup e restauração depende do plano de dados Object Store.

1Um programa público de pesquisa da Stanford e da Berkeley, liderado por Armando Fox e Dave Patterson

 
×
Ligue para nós
1-800-633-0738 (Estados Unidos)

Contato
×
Ligue para nós
1-800-633-0738 (Estados Unidos)


Fóruns de Discussão do Oracle Cloud