Exclusão de Responsabilidade

Este documento destina-se a realçar a nossa direção geral dos produtos. Destina-se apenas a efeitos informativos e não pode ser incorporado em nenhum contrato. O presente documento não constitui qualquer compromisso de fornecimento de qualquer material, código ou funcionalidade e não deve servir de base à tomada de decisões de compra. O desenvolvimento, lançamento, duração e preços de quaisquer funcionalidades descritas para produtos da Oracle poderão ser alterados e são da exclusiva responsabilidade da Oracle.

Estas Perguntas Mais Frequentes respondem a questões acerca da forma como a Oracle garante a resiliência e a disponibilidade contínua dos nossos serviços de base e da nossa plataforma de hosting. Os clientes do Oracle Cloud poderão estar interessados nestas respostas por vários motivos:

  • Ajudam os clientes a exercer o respetivo dever de diligência durante a avaliação dos serviços e da plataforma de hosting da Oracle.
  • Muitas das respostas abordam os desafios e soluções fundamentais para todos os sistemas à escala da cloud e podem, portanto, informar a arquitetura e o design dos sistemas que os clientes pretendem criar na cloud.

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

A Oracle distingue entre diferentes classes de serviços, como os serviços essenciais, os serviços continuamente disponíveis ou os serviços de localização única?

Não fazemos essas distinções. Em vez disso, categorizamos os nossos serviços por nível de dependência, âmbito de disponibilidade e plano de dados versus plano de controlo. Estas categorias estão concebidas para fornecer várias contrapartidas úteis entre a disponibilidade, a durabilidade, o desempenho e a conveniência.

Níveis de Dependência

Estes níveis podem ser considerados camadas ou escalões num diagrama de blocos arquiteturais. Cada camada poderá depender apenas das camadas subjacentes.

Cabeçalhos de baixo para cima:

  • Serviços essenciais: estes serviços formam a base do Oracle Cloud Infrastructure. Incluem os serviços Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry e vários serviços internos partilhados. Estão concebidos para terem o mínimo de dependências, mesmo entre si. (Consulte as informações mais à frente neste documento para obter os detalhes das dependências).
  • IaaS: esta camada fornece a funcionalidade ao nível da infraestrutura que é criada sobre a base. Esta camada inclui os serviços File Storage, Database e Container Engine for Kubernetes.
  • SaaS: esta camada é constituída pelo software-as-service avançado que é um serviço criado sobre as camadas inferiores.
Âmbito da Disponibilidade

Para se atingir os objetivos da disponibilidade e durabilidade de um serviço, é escolhido um dos seguintes âmbitos de disponibilidade para cada serviço:

  • Domínio de disponibilidade - local: cada domínio de disponibilidade contém uma instância independente do serviço. Esses serviços garantem a elevada durabilidade dos dados armazenados utilizando replicação síncrona entre réplicas no interior do mesmo domínio de disponibilidade (para obter os detalhes, consulte a secção sobre os domínios de falhas mais à frente neste documento). Estes serviços podem tolerar uma falha 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 atingem este nível de tolerância às falhas utilizando dois tipos diferentes de centro lógico de dados — grupos lógicos de isolamento das falhas e isolamento do desempenho — no interior do domínio de disponibilidade. Para obter mais detalhes, consulte a secções sobre domínios de falhas e células de serviços mais à frente neste documento. Por último, estes serviços podem continuar a funcionar normalmente mesmo se o domínio de disponibilidade não puder comunicar com quaisquer outros domínios de disponibilidade. Portanto, toleram a perda doutros domínios de disponibilidade ou a falha total da rede de área alargada no interior da região.
  • Domínio de disponibilidade múltiplo - regional: cada região com múltiplos domínios de disponibilidade contém uma instância independente do serviço, com componentes localizados em cada domínio de disponibilidade nessa região. Estes serviços garantem a durabilidade muito elevada dos dados armazenados utilizando replicação síncrona para múltiplos domínios de disponibilidade na mesma região. Estes serviços podem tolerar uma falha ou a incapacidade de comunicar com qualquer domínio único de disponibilidade na região.
  • Domínio único de disponibilidade - regional: se uma região contiver apenas um único domínio de disponibilidade, as características observáveis de um serviço regional corresponderão às de um serviço local de domínio de disponibilidade, tal como já descrito. A distinção entre um serviço local de domínio de disponibilidade e um serviço regional de domínio único de disponibilidade só se torna relevante quando a região de domínio único de disponibilidade for expandida acrescentando-se um ou mais domínios de disponibilidade. Quando isso acontecer, cada serviço regional expandir-se-á automaticamente para utilizar, de forma adequada, os novos domínios de disponibilidade sem deixar de ser uma instância única do serviço. O plano de dados do Object Storage, por exemplo, iria expandir-se para utilizar os domínios de disponibilidade adicionais e assim melhorar a durabilidade dos dados existentes. No caso dos serviços locais de domínio de disponibilidade, pelo contrário, cada um dos novos domínios de disponibilidade irá receber a sua própria instância nova de cada serviço local do domínio de disponibilidade.
  • Distribuídas por várias regiões: um dos princípios de base do Oracle Cloud Infrastructure é que cada região deverá ser tão operacionalmente independente das outras regiões quanto possível. A qualificação de quanto possível reflete o facto de as regiões terem necessariamente de partilhar, pelo menos, alguma infraestrutura; por exemplo, a rede de suporte inter-regiões. Doutra forma, não criamos mecanismos de acoplagem forte entre regiões, tais como a disponibilidade elevada transparente ou o failover, que poderiam causar problemas que afetassem várias regiões em simultâneo. Em vez disso, fornecemos dois mecanismos para distribuir os serviços por várias regiões com acoplagem fraca:
    • Recuperação de Situações Graves (DR): garantir que os nossos clientes são capazes de criar sistemas com características de DR é um pilar da nossa abordagem e investimento na cloud. Vários serviços essenciais já oferecem mecanismos de DR; por exemplo, a cópia de segurança inter-regiões do Block Volumes e a cópia inter-regiões do Object Storage. Todos os nossos serviços têm a funcionalidade DR como um dos itens de alta prioridade nos seus planos.
    • Subscrições inter-regiões: atualmente, só oferecemos subscrições inter-regiões para os dados do IAM. Conceptualmente, os dados do IAM têm um âmbito global. Os clientes podem subscrever (optar ativamente pela participação) um conjunto de regiões e nós iremos replicar os dados do IAM relevantes e as atualizações subsequentes para as regiões especificadas. A fim de se evitar a acoplagem forte, a replicação é assíncrona e, por fim, consistente. Os clientes fazem modificações aos seus dados do IAM numa região "principal" à sua escolha. Se a região principal atual se tornar indisponível ou inadequada por algum motivo, pode ser escolhida uma outra região.
Plano de Controlo versus Plano de Dados

O plano de dados de um serviço é uma recolha das interfaces e dos componentes de processamento dos dados que implementa a funcionalidade do serviço que deverá ser utilizada pelas aplicações. O plano de dados da virtual cloud network (VCN), por exemplo, inclui o sistema de processamento dos pacotes de rede, os routers virtualizados e os gateways, ao passo que o plano de dados do Block Volumes inclui a implementação do protocolo iSCSI e o sistema de armazenamento replicado e tolerante a falhas para os dados do volume.

O plano de controlo de um serviço é o conjunto de APIs e componentes responsáveis pelas seguintes tarefas:

  • Tratar dos pedidos de provisionamento dos clientes, reconfigurar, redimensionar com aumento ou redução ou terminar recursos
  • Efetuar a aplicação automática de correções para grandes frotas, de forma rápida e segura
  • Detetar recursos com falhas, degradados ou incorretamente configurados
  • Efetuar a reparação automática ou contactar os operadores humanos para obter assistência
  • Colaborar com outros planos de controlo (por exemplo: os serviços Compute, VCN, Block Storage são acoplados durante o LaunchInstance)
  • Gerir a capacidade não utilizada
  • Coordenar com intervenientes humanos; por exemplo, na chegada de novos equipamentos e na reparação e manutenção físicas
  • Fornecer visibilidade e controlo operacionais
 
 

Como assegura a Oracle que os serviços são resilientes e estão continuamente disponíveis?

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

Para se atingir a resiliência e a disponibilidade contínua, é necessário compreender e, em seguida, lidar com todas as causas da indisponibilidade — degradação do desempenho e falhas não tratadas — nos sistemas à escala da cloud. Essas causas são em grande número, portanto agrupámo-las em categorias de acordo com a respetiva natureza fundamental.

Tradicionalmente, a análise da disponibilidade em sistemas empresariais de TI tem-se concentrado na categoria das falhas no hardware. No entanto, e no caso dos sistemas da cloud, as falhas de hardware constituem um problema relativamente menor e bem conhecido. É já relativamente fácil evitar-se ou mitigar-se a maioria dos pontos únicos de falhas no hardware. Os racks, por exemplo, podem ter fontes de alimentação duplas e unidades de distribuição de energia associadas, e muitos componentes podem ser trocados sem necessidade de os desligar. As perdas e falhas de hardware em larga escala são, obviamente, possíveis; por exemplo, devido a desastres naturais. No entanto, a nossa experiência, e os relatórios de post mortems públicos de outros fornecedores de soluções cloud, mostram que a perda ou falha de um centro de dados completo ocorre com extrema raridade, em comparação com outras causas de indisponibilidade. As falhas de hardware em larga escala devem ainda ser tratadas (por exemplo, com a recuperação de situações graves e outros mecanismos), mas estão longe de constituir o problema dominante na disponibilidade.

As causas dominantes da indisponibilidade em sistemas à escala da cloud são as seguintes:

  1. Bugs no software
  2. Erros de configuração
  3. Erros cometidos pelos operadores humanos
    Nota: a principal lição da indústria é que estas três formas de erro humano são, de longe, as maiores causas de indisponibilidade. Embora a respetiva frequência possa ser reduzida através de ferramentas, automação e formação, não é possível eliminá-las por completo. Portanto, terá de se lidar com elas enquanto preocupações principais na arquitetura, no design e na implementação do sistema.
  4. Variações inaceitáveis no desempenho (latência ou processamento) devidas a um qualquer motivo, incluindo os seguintes:
    • "Vizinhos ruidosos" multitenant (falha dos mecanismos de QoS)
    • Incapacidade de rejeitar sobrecargas de forma eficaz (acidental ou maliciosa) sem deixar de executar trabalho útil
    • Impactos (thrash) distribuídos, excesso de mensagens, excesso de novas tentativas e outras interações "emergentes" dispendiosas
    • Caches vazias (cold-shock) após um ciclo de arranque ou reinicialização, particularmente no caso de arranque ou reinicialização em simultâneo de vários sistemas
    • Despesas gerais decorrentes do redimensionamento do sistema (por exemplo, refragmentação)
  5. Falha na limitação do "raio de explosão" (número de clientes e sistemas afetados) de qualquer um dos problemas anteriores

Estes desafios são universais — fazem parte das "leis da física" dos sistemas distribuídos à escala da cloud.

Para cada uma das categorias precedentes, utilizamos estratégias de engenharia comprovadas para lidar com o problema. Dentre elas, as mais importantes são:

  • Princípios de arquitetura e conceção de sistemas
  • Novos conceitos arquiteturais (que resultam normalmente da aplicação dos princípios)
  • Procedimentos de engenharia de serviços
Princípios de Arquitetura e Conceção de Sistemas

Existem muitos princípios deste tipo, mas iremos concentrar-nos nos mais relevantes para a resiliência e a disponibilidade.

Computação Orientada para a Recuperação

Para tratar dos bugs no software e dos erros cometidos pelos operadores que tenham um impacto relativamente localizado, seguimos os princípios da computação orientada para recuperação1. A um nível mais elevado, isto significa que, em vez de tentarmos garantir que nunca teremos um problema (o que é impossível de se testar), concentramo-nos no tratamento discreto dos problemas, de uma forma que possa ser testada. Em particular, concentramo-nos em minimizar o tempo médio para recuperação (MTTR), o qual é uma combinação do tempo médio para detetar, tempo médio para diagnostica e tempo médio para mitigar.

O nosso objetivo é recuperar tão depressa que os utilizadores humanos não chegam a ser perturbados pelo problema. Os pontos seguintes ajudam-nos a atingir este objetivo:

  • Detetar, rápida e automaticamente, os sintomas dos bugs e erros cometidos pelos operadores, pela utilização generalizada de asserções no código, pela monitorização ativa e pela definição de alarmes em todos os níveis.
  • Agregar funcionalidades em várias unidades de isolamento distintas e detalhadas (threads, processos, fibras, máquinas de estado, etc.) que estão independentes — ou seja, não partilham diretamente memória que se poderá corromper.
  • Ao detetar-se os sintomas de um bug ou erro cometido por um operador, reiniciar-se automaticamente a unidade de isolamento circundante tão rapidamente quanto for possível. A reinicialização é uma forma prática de se tentar recuperar de uma falha arbitrária, porque vai tentar restabelecer um estado bem testado e, assim, repor os invariantes.
  • Se a recuperação no nível de isolamento detalhado não funcionar (por exemplo, as asserções podem continuar a ser ativadas com demasiada frequência, causando uma "queda em parafuso"), escalonar para a unidade maior seguinte (processo, runtime, host, centro lógico de dados, contactar um operador humano).
  • Criar mecanismos que permitam uma "anulação em todo o sistema", incluindo a gestão de versões de todos os estados do sistema e das versões, para se identificar rapidamente e anular as confirmações erróneas.

Minimização dos Efeitos dos Problemas

Para lidar com os bugs e os erros que possam ter efeitos mais alargados, criámos mecanismos para minimizar o "raio de explosão" de quaisquer problemas. Ou seja, concentramo-nos na minimização dos número de clientes, sistemas ou recursos afetados por quaisquer problemas, incluindo os problemas particularmente desafiantes como os "vizinhos ruidosos" multitenant, a sobrecarga oferecida, a capacidade degradada e os impactos (thrash) distribuídos. Atingimos este objetivo utilizando vários perímetros de isolamento e práticos de gestão de alterações (consulte as secções seguintes).

Conceitos Arquiteturais Resultantes de Princípios de Design

Existem um grande número destes conceitos, mas iremos concentrar-nos nos conceitos de limitação do "raio de explosão".

Conceitos de Colocação Consagrados na Nossa API Pública: Regiões, Domínios de Disponibilidade e Domínios de Falhas

Visto os domínios de falhas serem relativamente novos, iremos descrevê-los de forma mais detalhada.

Os domínios de falhas são utilizados para se limitar o "raio de explosão" dos problemas que ocorrem quando um sistema estiver a ser ativamente alterado — por exemplo, implementações, aplicação de correções, reinicializações pelo hipervisor e manutenção física.

A garantia é que, num determinado domínio de disponibilidade, os recursos existentes em, no máximo, um domínio de falhas estão a ser alterados em qualquer altura. Se algo correr mal com o processo de alteração, alguns ou todos os recursos nesse domínio de falhas poderão estar indisponíveis durante algum tempo, mas os outros domínios de falhas no domínio de disponibilidade não serão afetados. Cada domínio de disponibilidade contém pelo menos três domínios de falhas, para se permitir que os sistemas de replicação baseados no quórum (por exemplo, o Oracle Data Guard) possam ser alojados com disponibilidade elevada no interior de um único domínio de disponibilidade.

Como resultado, para uma categoria dominante de problemas de disponibilidade — bugs do software, erros de configuração, erros cometidos pelos operadores e problemas de desempenho que ocorram durante um procedimento de alteração — cada domínio de falhas agirá como um centro lógico de dados separado no interior do domínio de disponibilidade.

Os domínios de falhas também protegem contra alguns tipos de falha de hardware localizada. As propriedades dos domínios de falhas garantem que os recursos colocados em diferentes domínios de falhas não partilhem nenhuns pontos únicos potenciais de falha de hardware no interior do domínio de disponibilidade, tanto quanto for praticamente possível. Os recursos em diferentes domínios de falhas, por exemplo, não partilham o mesmo switch de rede de "topo do rack", porque o design standard desse tipo de switches não tem redundância.

No entanto, a capacidade de os domínios de falhas protegerem contra problemas no hardware ou no ambiente físico para a esse nível local. Em contraste com os domínios e regiões de disponibilidade, os domínios de falhas não fornecem qualquer isolamento físico de grande escala da infraestrutura. Nos raros casos de um desastre natural ou de falha da infraestrutura em todo o domínio de disponibilidade, os recursos nos vários domínios de falhas iriam, provavelmente, ser afetados ao mesmo tempo.

Os nossos serviços internos utilizam os domínios de falha da mesma forma que os clientes os deveriam estar a utilizar. Por exemplo, os serviços Block Volumes, Object Storage e File Storage armazenam réplicas dos dados em três domínios de falhas separados. Todos os componentes de todos os planos de controlo e de dados estão alojados em três domínios de falhas (ou, no caso de uma região de vários domínios de disponibilidade, em vários domínios de disponibilidade).

Células de Serviços

As células de serviços são utilizadas para limitar o "raio de explosão" dos problemas que possam ocorrer quando um sistema não estiver a ser ativamente alterado. Estes problemas podem surgir porque o volume de transações de um sistema da cloud multitenant se pode alterar dramaticamente em qualquer altura e porque as falhas parciais complexas podem ocorrer em qualquer grande sistema distribuído a qualquer momento. Estes cenários poderão ativar bugs ocultos subtis ou precipitar problemas de desempenho emergentes.

Além disso, as células de serviço também limitam o "raio de explosão" nalguns cenários raros mas problemáticos em que o sistema esteja a ser ativamente alterado. Um exemplo clássico é quando a implementação para um domínio individual de falhas parece ter sido bem-sucedido — sem erros nem alterações no desempenho — mas, assim que o segundo ou último domínio de falhas tiver sido atualizado, as novas interações no interior do sistema (à escala total da cloud com um volume de transações de produção) causarão um problema de desempenho.

Note que a utilização das células de serviço constitui um padrão arquitetural e não um conceito que seja explicitamente nomeado na API ou no SDK do Oracle Cloud. Qualquer sistema multitenant pode utilizar este padrão arquitetural, o qual não requer suporte especial da parte da plataforma cloud.

As células de serviços funcionam da seguinte forma:

  • Cada instância do serviço (por exemplo, numa região específica, ou num domínio específico de disponibilidade no caso dos serviços locais de domínios de disponibilidade) consiste em várias implementações separadas da pilha de software do serviço. Cada implementação separada é conhecida como uma célula. Cada célula está alojada na sua própria infraestrutura, tanto quanto for praticamente possível. No mínimo, as células não partilham hosts nem VMs.
  • Um serviço poderá começar com um número reduzido de células em cada domínio de disponibilidade ou região. À medida que o serviço se redimensiona para responder ao aumento da procura, são acrescentadas mais células para se manter o limite do "raio de explosão" de quaisquer problemas. Um serviço popular e de grandes dimensões poderá ter muitas células. Por outras palavras, as células fornecem multiplexagem N para M dos volumes de transações dos clientes para separar os ambientes de hosting — ilhas separadas de isolamento dos recursos. As células não têm um número óbvio de elementos, como o que existe para os domínios de falhas. (Tal como já mencionado, uma escolha óbvia para o número de elementos dos domínios de falhas é de três por domínio de disponibilidade, para que os sistemas de replicação baseados no quórum possam ser alojados com disponibilidade elevada num único domínio de disponibilidade.)
  • Cada "unidade natural" de um volume de transações de um cliente é atribuída a uma célula específica. A definição de "unidade natural" depende da natureza do serviço específico. Por exemplo, para o nosso serviço Workflow partilhado interno (descrito mais adiante), a unidade natural poderá ser "todos os fluxos de trabalho neste domínio de disponibilidade ou nesta região para um plano de controlo específico".
  • À frente de cada grupo de células está uma camada de encaminhamento minimalista ou uma API para se descobrir os endpoints das células. Por exemplo, o sistema de Streaming/Messaging tem uma API para se descobrir o endpoint do plano de dados atual para um tópico específico, e o armazém interno de Metadados tem um endpoint separado por célula. No entanto, existem outros serviços baseados em células que têm um endpoint único de plano de dados e uma camada de encaminhamento partilhada. A camada de encaminhamento é uma causa potencial da falha correlacionada de várias células, mas este facto é mitigado mantendo-se a camada de encaminhamento extremamente simples, previsível e eficaz (sem operações dispendiosas), e provisionando-a com uma grande quantidade de capacidade de expansão e mecanismos de QoS sofisticados de quota e limitação.
  • Os proprietários dos serviços podem deslocar o volume de transações de uma célula para outra, conforme for necessário. Seguem-se alguns cenários de exemplo:
    • Para ajudar a evitar o problema dos "vizinhos ruidosos" multitenant deslocando-se um volume elevado de transações, para que os restantes utilizadores de uma célula não sejam afetados.
    • Para ajudar a recuperar de uma sobrecarga ou quebra de energia, talvez causadas por um ataque DDoS distribuído. Dispomos de mecanismos de quota e limitação para defender contra esse tipo de ataque, mas, por vezes, ocorrem casos-limite nos quais um caso de utilização específico (API, padrão de acesso) exige mais do serviço do que o sistema de quotas ou limitação é atualmente capaz de compreender. As células fornecem um mecanismo para a mitigação a curto prazo.
    • Para separar os volumes críticos de transações em diferentes células, para reduzir significativamente a probabilidade de uma falha correlacionada. Para o nosso Workflow partilhado interno para planos de controlo, por exemplo, os planos de controlo "essenciais e críticos" (por exemplo, Platform, Compute, Networking e Block Volumes) são individualmente atribuídos a células diferentes e têm, portanto, significativamente menos correlação de falha do que teriam se não fossem utilizadas células ou se fossem todos atribuídos à mesma célula.
      Nota: esta utilização das células reduz a necessidade de os clientes terem de pensar nas dependências internas dos serviços para criarem aplicações resilientes. Ainda é uma boa prática ter-se em conta o grafo de dependências (este assunto é abordado mais adiante neste documento), mas este gráfico torna-se menos necessário quando já estiver ativo um mecanismo de correlação.

O resultado é que cada célula de serviço é mais outro tipo de "centro lógico de dados" — um agrupamento lógico constituído pelo isolamento do desempenho e pelo isolamento de falhas — no interior de um único domínio de disponibilidade ou região.

Resumindo, as células dos serviços e os domínios de falhas complementam-se mutuamente das seguintes formas:

  • Os domínios de falhas protegem contra problemas quando um sistema estiver a ser ativado alterado.
  • As células dos serviços limitam o "raio de explosão" quando um sistema experimentar problemas potencialmente graves — quer esteja ou não a ser ativamente alterado.

Combinamos as propriedades dos domínios de falhas e das células de serviços numa estratégia unificada quando efetuamos implementações e aplicamos correções.

Procedimentos de Engenharia de Serviços

Uma vez que os testes e a excelência operacional são essenciais para a fiabilidade dos sistemas cloud, dispomos de um grande número de procedimentos de engenharia. Em seguida, elencamos alguns dos mais importantes que tiram partido dos conceitos mencionados na secção anterior:

  • Implementamos os serviços de forma incremental, com validação cuidadosa entre os passos e anulação reflexiva caso aconteça algo inesperado. Em termos concretos, o processo é o seguinte:
    • Em cada domínio de disponibilidade, implementamos uma célula de serviço de cada vez. Para cada célula, implementamos um domínio de falhas de cada vez, até termos terminado todos os domínios de falhas para essa célula. Em seguida, avançamos para a célula seguinte nesse domínio de disponibilidade.
    • Depois de cada passo da implementação (após cada célula e domínio de falhas), confirmamos que a alteração está a funcionar de acordo com o esperado — ou seja, que não degradámos o desempenho nem introduzimos quaisquer erros, internos ou externos. Se algo parecer errado ou inesperado, anulamos reflexivamente a alteração. Damos grande destaque à preparação e aos testes, incluindo a execução automática de testes e de procedimentos de anulação, incluindo alterações que afetem schemas e estados persistentes.
    • Desta forma, implementamos a alteração num domínio de disponibilidade de cada vez para cada região. Implementamos para todas as regiões num domínio de forma a não se alterar concorrentemente nenhum par de regiões que o cliente possa estar a utilizar para sites primários e de recuperação de situações graves.
  • Verificamos regularmente se os mecanismos de tratamento de erros e outras formas de mitigação funcionam de acordo com o esperado e se não agravam o problema à escala. Sem esses testes, é habitual que os mecanismos de tratamento de erros (como as novas tentativas, os algoritmos de recuperação de falhas e os algoritmos de reconfiguração das máquinas de estados) tenham bugs, sejam demasiado dispendiosos ou interajam de formas inesperadas, causando, portanto, impactos (thrash) distribuídos ou outros problemas graves de desempenho.
  • Verificamos a nossa capacidade de anular, de forma rápida e segura, as alterações feitas e repor o último software e a última configuração adequados, incluindo o schema e o estado persistente, tal como já descrito.
 
 

Em regiões Oracle que contenham vários domínios de disponibilidade, poderá afirmar-se que todos os serviços essenciais se encontram distribuídos pelos domínios de disponibilidade existentes?

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

 
 

Qual é a forma de a Oracle, e os seus clientes, evitarem ter um serviço essencial que dependa de um único centro lógico de dados?

Nas regiões com um único domínio de disponibilidade, os clientes podem utilizar domínios de falhas (grupos lógicos com modos de falha correlacionados entre os grupos) para atingirem a maior parte das propriedades que caracterizam os "centros lógicos de dados" separados. Os clientes também podem utilizar várias regiões para a recuperação de situações graves (DR).

Nas regiões com vários domínios de disponibilidade, os clientes podem utilizar os domínios de falhas da mesma maneira. Os clientes também podem utilizar uma combinação de serviços locais de domínio de disponibilidade (como o DBaaS com Data Guard) e serviços regionais (Object Storage, Streaming) para atingir uma disponibilidade elevada em todos os "centros lógicos de dados" de nível superior (domínios de disponibilidade). Por último, os clientes podem também utilizar várias regiões para DR.

Em todos os casos, os clientes podem utilizar o conceito de células de serviço para reforçar o isolamento mesmo nos problemas mais graves, como os impactos (thrash) distribuídos.

 
 

Qual é a forma utilizada pela Oracle para conduzir as atividades de manutenção sem tornar temporariamente indisponíveis quaisquer serviços essenciais para qualquer cliente?

Atingimos esse objetivo através dos domínios de falhas, das células de serviços e dos nossos procedimentos operacionais para implementação incremental e validação. Consulte o debate já apresentado neste documento.

 
 

Os serviços de plataforma sem servidor são implementados em vários centros lógicos de dados de forma a assegurar-se a disponibilidade elevada?

Sim. Todas as categorias de serviços são implementadas em vários centros lógicos de dados — agrupamentos lógicos separados de isolamento das falhas e isolamento do desempenho — para assegurar a resiliência e a disponibilidade contínua.

 
 

Se a resiliência não for a configuração por omissão, os clientes poderão optar por uma implementação em vários centros lógicos de dados (por exemplo, vários domínios de disponibilidade ou configuração em várias regiões)?

Nas regiões de domínio único de disponibilidade, oferecemos os domínios de falhas como o mecanismo para os "vários centros lógicos de dados", tal como já mencionado neste documento.

Em regiões de vários domínios de disponibilidade, oferecemos serviços e funcionalidades que asseguram um nível ainda maior de durabilidade física dos dados sincronicamente replicados (com um custo de desempenho modesto, por causa da distância entre os domínios de disponibilidade na região e da velocidade da luz).

Não oferecemos disponibilidade elevada automática ou mecanismos de failover que abranjam várias regiões em simultâneo, porque isto iria criar uma relação de associação próxima entre regiões e incorrer-se-ia o risco de várias regiões poderem experimentar problemas em simultâneo. Em vez disso, ativamos várias formas de replicação assíncrona entre regiões e oferecemos uma lista crescente de funcionalidades, como a cópia normal e de segurança, para ativar a Recuperação de Situações Graves em várias regiões e em simultâneo.

 
 

Qual é o procedimento utilizado pela Oracle para ajudar os clientes a evitarem a falha correlacionada de aplicações causada pelas dependências internas entre os vários serviços de plataforma e de infraestrutura?

Trata-se de uma questão complexa, portanto, e para a clarificar, vamos refraseá-la de algumas formas diferentes:

  • Se um cliente quiser utilizar os serviços Oracle (serviço A e serviço B) e pretender criar uma aplicação que seja resiliente em caso de falha de um desses serviços, terá o cliente de saber se o serviço B depende internamente ou não do serviço B? As dependências internas levam a falha correlacionada a um grau significativo? Em caso afirmativo, o cliente poderá ter de conhecer essas dependências internas, para que possa decidir quais serão as outras possíveis utilizações do serviço A e do serviço B — ou se deverá, em vez disso, assegurar a intervenção de um serviço C não relacionado para estes casos adicionais — quando criar os seus próprios mecanismos de resiliência a nível da aplicação.
  • Qual é a melhor forma de o cliente se defender de qualquer falha correlacionada dos serviços Oracle?

A resposta divide-se em duas partes.

Princípios Arquiteturais

Utilizamos princípios arquiteturais que reduzem significativamente a falha correlacionada em vários serviços dependentes. Nalguns casos, esta técnica reduz de tal forma a probabilidade da falha correlacionada que esta pode ser ignorada do ponto de vista do cumprimento de um contrato de nível de serviço (SLA) relativo à disponibilidade.

Mais concretamente, utilizamos células de serviço, tal como já descrito neste documento. As células ajudam com este problema porque se o serviço interno A for afetado por um problema numa das suas dependências, o serviço B, então o problema com o serviço B será muito provavelmente confinado a uma única célula. Os outros serviços de nível superior — e as aplicações do próprio cliente — que utilizem o serviço B estarão provavelmente a utilizar outras células que não sejam afetadas. Trata-se de um argumento probabilístico que varia de acordo com o número de células, o qual é um parâmetro interno oculto que não se altera (não aumenta), pelo que não se dá qualquer garantia ou quantificação para além dos SLAs autónomos de serviço dos serviços A e B. Na prática, porém, este procedimento pode anular significativamente a correlação de falhas entre os serviços.

Muitos dos nossos serviços internos partilhados — por exemplo, os serviços Workflow e Metadata para planos de controlos e o serviço Streaming/Messaging — utilizam células de serviços que anulam a correlação de falhas para os serviços upstream que os utilizam.

Dependências

A orientação seguinte é de nível superior porque a implementação de baixo nível e os detalhes dos serviços mudam e podem mudar. Mas, e em relação às dimensões-chave da computação, do armazenamento, das redes e da autenticação/autorização, indicamos as seguintes dependências.

Para os planos de controlo, as dependências habituais são as seguintes:

  1. O plano de dados do serviço Identity ou Platform para a autenticação e autorização
  2. O serviço de controlo de auditorias
  3. Os serviços internos que fornecem, por exemplo, fluxos de trabalho, armazenamento de metadados e registo no diário
  4. Balanceadores de carga de vários tipos

Alguns planos de controlo têm, obviamente, dependências específicas dos serviços. O plano de controlo do Compute, por exemplo, ao lançar uma instância bare metal ou de VM, depende de:

  • Object Storage (para obter a imagem do sistema operativo especificada)
  • Plano de controlo do Block Volumes (para provisionar e anexar o volume de arranque)
  • Plano de controlo do Networking (para provisionar e anexar VNICs)

Para os planos de dados dos serviços essenciais, o princípio geral é que cada plano de dados seja intencionalmente concebido para ter o mínimo de dependências, para que se possa atingir a disponibilidade elevada, o diagnóstico rápido e a recuperação rápida. Os resultados desse princípio são os seguintes:

  • O plano de dados do Networking é independente.
  • O plano do Block Volumes é independente.
  • As instâncias de bare metal e VM do Compute dependem do plano de dados do Block Volumes (para os volumes de arranque) e do plano de dados do Networking.
  • O plano de dados do Object Storage depende do plano de dados do Identity/Platform para a autenticação e autorização (por causa das expetativas da indústria). O plano de dados do Object Storage não depende do Block Volumes nem do File Storage.
  • Todos os serviços que suportam a cópia de segurança e reposição dependem do plano de dados do Object Storage para essa funcionalidade.

Para os planos de dados do IaaS, o princípio geral é depender apenas dos planos de dados de nível inferior ou principal (para se evitar dependências cíclicas).

  • O RAC de vários nós de base de dados depende do plano de dados do Networking e do plano de dados do Block Volumes.
  • O Container Engine para Kubernetes depende, obviamente, do Kubernetes e das respetivas dependências transitivas (por exemplo, etcd) e do plano de dados do Networking.
  • Toda a funcionalidade de cópia de segurança e reposição depende do plano de dados do Object Store.

1Um programa público de investigação da Stanford and Berkeley, liderado por Armando Fox e Dave Patterson

 
×
Telefone
1-800-633-0738 (Estados Unidos)

Contactar
×
Telefone
1-800-633-0738 (Estados Unidos)


Fóruns de Debate do Oracle Cloud