Este documento fornece uma arquitetura de referência para uma aplicação empresarial de elevada disponibilidade alojada em máquinas virtuais (VMs) do Compute Engine com conetividade de baixa latência a bases de dados Oracle Cloud Infrastructure (OCI) Exadata que são executadas no Google Cloud. O público-alvo deste documento são arquitetos da nuvem e administradores de bases de dados Oracle. Este documento pressupõe que tem conhecimentos do Compute Engine e do Oracle Exadata Database Service.
Se usar o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bases de dados Oracle no local, pode migrar as suas aplicações de forma eficiente para Google Cloud e executar as suas bases de dados no Oracle Database@Google Cloud. O Oracle Database@Google Cloud é uma oferta do Google Cloud Marketplace que lhe permite executar o Oracle Exadata Database Service e o Oracle Autonomous Database diretamente no Google Cloud.
Se não precisar da capacidade do Oracle RAC ou se precisar de uma versão do Oracle Database que não seja a 19c nem a 23ai, pode executar bases de dados Oracle autogeridas em VMs do Compute Engine. Para mais informações, consulte o artigo Aplicação empresarial com a base de dados Oracle no Compute Engine.
Arquitetura
O diagrama seguinte mostra uma vista de alto nível da arquitetura:
No diagrama anterior, um equilibrador de carga externo recebe pedidos de utilizadores de uma aplicação virada para o público e distribui os pedidos para servidores Web de front-end. Os servidores Web encaminham os pedidos dos utilizadores através de um equilibrador de carga interno para os servidores de aplicações. Os servidores de aplicações leem dados e escrevem em bases de dados no Oracle Database@Google Cloud. Os administradores e os serviços do OCI podem estabelecer ligação e interagir com as bases de dados Oracle.
O diagrama seguinte mostra uma vista detalhada da arquitetura:
Nesta arquitetura, a camada Web e a camada de aplicação são executadas no modo ativo-ativo em VMs do Compute Engine distribuídas por duas zonas numa Google Cloud região. A aplicação usa bases de dados Oracle Exadata na mesma Google Cloud região.
Todos os componentes na arquitetura estão numa única Google Cloud região. Esta arquitetura está alinhada com o arquétipo de implementação regional. Pode adaptar esta arquitetura para criar uma topologia robusta contra interrupções regionais através do arquétipo de implementação multirregional. Para mais informações, consulte o artigo Implementação multirregional no Compute Engine e também as orientações na secção Fiabilidade mais adiante neste documento.
A arquitetura apresentada no diagrama anterior inclui os seguintes componentes:
| Componente | Purpose |
|---|---|
| Balanceador de carga de aplicações externo regional | O Application Load Balancer externo regional recebe pedidos de utilizadores e distribui-os pelas VMs da camada Web. |
| Política de segurança do Google Cloud Armor | A política de segurança do Cloud Armor ajuda a proteger a sua pilha de aplicações contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS). |
| Grupo de instâncias geridas (GIG) regional para a camada Web | A camada Web da aplicação é implementada em VMs do Compute Engine que fazem parte de um GIG regional. Este MIG é o back-end do Application Load Balancer externo. O MIG contém VMs do Compute Engine em duas zonas. Cada uma destas VMs aloja uma instância independente da camada Web da aplicação. |
| Balanceador de carga de aplicações interno regional | O balanceador de carga de aplicações interno regional distribui o tráfego das VMs da camada Web para as VMs da camada de aplicações. |
| MIG regional para o nível da aplicação | A camada de aplicação, como um cluster do Oracle WebLogic Server, é implementada em VMs do Compute Engine que fazem parte de um GIG regional. Este MIG é o back-end do balanceador de carga da aplicação interno. O MIG contém VMs do Compute Engine em duas zonas. Cada MV aloja uma instância independente do servidor de aplicações. |
| Rede de nuvem virtual privada (VPC) e sub-rede | Todos os Google Cloud recursos na arquitetura usam uma única rede VPC. Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes. Para mais informações, consulte o artigo Decidir se deve criar várias redes VPC. |
| Oracle Database no Google Cloud |
Os servidores de aplicações leem dados e escrevem nas bases de dados Oracle no Oracle Exadata Database Service. Aprovisiona o Oracle Exadata Database Service através do Oracle Database@Google Cloud, uma oferta do Cloud Marketplace que lhe permite executar bases de dados Oracle em hardware gerido pela Oracle num Google Cloud centro de dados. Usa interfaces como a consola, a CLI do Google Cloud e as APIs para criar instâncias de infraestrutura do Exadata. Google Cloud Google Cloud A Oracle configura e gere a infraestrutura de computação, armazenamento e rede necessária num centro de dados numa região no hardware dedicado ao seu projeto. Google Cloud |
| Instâncias da infraestrutura do Exadata | Cada instância da infraestrutura do Exadata contém dois ou mais servidores de base de dados físicos e três ou mais servidores de armazenamento. Estes servidores, que não são apresentados no diagrama, estão interligados através de uma estrutura de rede de baixa latência. Quando cria uma instância da infraestrutura do Exadata, especifica o número de servidores de base de dados e servidores de armazenamento que têm de ser aprovisionados. |
| Clusters de VMs do Exadata |
Numa instância da infraestrutura do Exadata, cria um ou mais clusters de VMs do Exadata. Por exemplo, pode optar por criar e usar um cluster de VMs do Exadata separado para alojar as bases de dados necessárias para cada uma das suas unidades empresariais. Cada cluster de VMs do Exadata contém uma ou mais VMs do Oracle Linux que alojam instâncias da base de dados Oracle. Quando cria um cluster de VMs do Exadata, especifica o seguinte:
As VMs nos clusters de VMs do Exadata não são VMs do Compute Engine. |
| Instâncias do Oracle Database | Cria e gere bases de dados Oracle através da consola da OCI e de outras interfaces da OCI. O software da base de dados Oracle é executado nas VMs no cluster de VMs do Exadata. Quando cria o cluster de VMs do Exadata, especifica a versão da infraestrutura de grelha da Oracle. Também pode escolher o tipo de licença: trazer as suas próprias licenças (BYOL) ou optar pelo modelo com licença incluída. |
| VCN do OCI e sub-redes | Quando cria um cluster de VMs do Exadata, é criada automaticamente uma rede na nuvem virtual (VCN) do OCI. A VCN tem uma sub-rede de cliente e uma sub-rede de backup com intervalos de endereços IP que especifica. A sub-rede do cliente é usada para a conetividade da sua rede VPC às bases de dados Oracle. A sub-rede de cópia de segurança é usada para enviar cópias de segurança da base de dados para o armazenamento de objetos do OCI. |
| Cloud Router, Partner Interconnect, e OCI DRG | O tráfego entre a sua rede VPC e a VCN é encaminhado por um Cloud Router associado à VPC e através de um gateway de encaminhamento dinâmico (DRG) associado à VCN. O tráfego flui através de uma ligação de baixa latência que a Google configura através da interligação de parceiros. |
| Zona Cloud DNS privada | Quando cria um cluster de VMs do Exadata, é criada automaticamente uma zona privada do Cloud DNS. Quando os servidores de aplicações enviam pedidos de leitura e escrita para as bases de dados Oracle, o Cloud DNS resolve os nomes de anfitrião da base de dados para os endereços IP correspondentes. |
| OCI Object Storage e OCI Service Gateway | Por predefinição, as cópias de segurança das bases de dados do Oracle Exadata são armazenadas no OCI Object Storage. As cópias de segurança da base de dados são encaminhadas para o armazenamento de objetos da OCI através de um gateway de serviços. |
| Gateway do Cloud NAT público | A arquitetura inclui um gateway Cloud NAT público para ativar ligações de saída seguras a partir das VMs do Compute Engine, que têm apenas endereços IP internos. |
| Cloud Interconnect e Cloud VPN | Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede. |
| Cloud Monitoring | Pode usar o Cloud Monitoring para observar o comportamento, o estado e o desempenho da sua aplicação e Google Cloud recursos, incluindo os recursos do Oracle Exadata. Também pode monitorizar os recursos no Oracle Exadata através do serviço OCI Monitoring. |
Produtos usados
Esta arquitetura de referência usa os seguintes produtos Google Cloud :
- Compute Engine: um serviço de computação seguro e personalizável que lhe permite criar e executar VMs na infraestrutura da Google.
- Cloud Load Balancing: um portefólio de balanceadores de carga globais, escaláveis e de elevado desempenho, bem como balanceadores de carga regionais.
- Nuvem virtual privada (VPC): um sistema virtual que oferece funcionalidade de rede global e escalável para as suas Google Cloud cargas de trabalho. A VPC inclui o intercâmbio da rede da VPC, o Private Service Connect, o acesso a serviços privados e a VPC partilhada.
- Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicação Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicações.
- Cloud NAT: um serviço que oferece tradução de endereços de rede de alto desempenho gerida pela Google Cloud.
- Cloud Monitoring: um serviço que oferece visibilidade do desempenho, da disponibilidade e do estado das suas aplicações e infraestrutura.
- Cloud Interconnect: um serviço que expande a sua rede externa para a rede Google através de uma ligação de alta disponibilidade e baixa latência.
- Partner Interconnect: um serviço que oferece conetividade entre a sua rede no local e as suas redes da nuvem privada virtual e outras redes através de um fornecedor de serviços suportado.
- VPN na nuvem: um serviço que estende de forma segura a sua rede ponto a ponto à rede da Google através de um canal VPN IPsec.
Esta arquitetura de referência usa os seguintes produtos da OCI:
- Exadata Database Service on Dedicated Infrastructure: um serviço que lhe permite executar instâncias da base de dados Oracle em hardware Exadata dedicado.
- Armazenamento de objetos: um serviço para armazenar grandes quantidades de dados estruturados e não estruturados como objetos.
- VCNs e sub-redes: uma VCN é uma rede virtual e privada para recursos numa região do OCI. Uma sub-rede é um intervalo contíguo de endereços IP com uma VCN.
- Gateway de encaminhamento dinâmico: um router virtual para tráfego entre uma VCN e redes externas.
- Gateway de serviço: um gateway para permitir que os recursos numa VCN acedam a serviços Oracle específicos de forma privada.
Considerações de design
Esta secção descreve os fatores de design, as práticas recomendadas e as recomendações de design que deve considerar quando usa esta arquitetura de referência para desenvolver uma topologia que cumpra os seus requisitos específicos de segurança, fiabilidade, eficiência operacional, custo e desempenho.
As orientações nesta secção não são exaustivas. Consoante os requisitos específicos da sua aplicação e os produtos e funcionalidades de terceiros que usa, podem existir fatores de design e compromissos adicionais que deve considerar. Google Cloud
Design do sistema
Esta secção fornece orientações para ajudar a escolher as Google Cloud regiões para a sua implementação e a selecionar os Google Cloud serviços adequados.
Seleção de região
Quando escolher as Google Cloud regiões onde as suas aplicações têm de ser implementadas, considere os seguintes fatores e requisitos:
- Disponibilidade de Google Cloud serviços em cada região. Para mais informações, consulte Produtos disponíveis por localização.
- Disponibilidade dos tipos de máquinas do Compute Engine em cada região. Para mais informações, consulte o artigo Regiões e zonas.
- Requisitos de latência do utilizador final.
- Custo dos Google Cloud recursos.
- Custos de transferência de dados entre regiões.
- Requisitos regulamentares.
Alguns destes fatores e requisitos podem envolver compromissos. Por exemplo, a região mais rentável pode não ter a menor pegada de carbono. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.
Infraestrutura de computação
A arquitetura de referência neste documento usa VMs do Compute Engine para determinados níveis da aplicação. Consoante os requisitos da sua aplicação, pode escolher entre outros Google Cloud serviços de computação:
- Contentores: pode executar aplicações em contentores em clusters do Google Kubernetes Engine (GKE). O GKE é um motor de orquestração de contentores que automatiza a implementação, o dimensionamento e a gestão de aplicações contentorizadas.
- Sem servidor: se preferir concentrar os seus esforços de TI nos dados e nas aplicações em vez de configurar e operar recursos de infraestrutura, pode usar serviços sem servidor, como o Cloud Run.
A decisão de usar VMs, contentores ou serviços sem servidor envolve uma troca entre a flexibilidade da configuração e o esforço de gestão. As VMs e os contentores oferecem mais flexibilidade de configuração, mas é responsável pela gestão dos recursos. Numa arquitetura sem servidor, implementa cargas de trabalho numa plataforma pré-configurada que requer um esforço de gestão mínimo. Para mais informações sobre a escolha de serviços de computação adequados para as suas cargas de trabalho no Google Cloud, consulte Alojamento de aplicações no Google Cloud.
Opções de armazenamento
Para as VMs do Compute Engine na arquitetura, pode usar volumes de arranque do Hyperdisk ou do Persistent Disk. Os volumes Hyperdisk oferecem melhor desempenho, flexibilidade e eficiência do que o disco persistente. Com o Hyperdisk Balanced, pode aprovisionar IOPS e débito de forma separada e dinâmica, o que lhe permite ajustar o volume a uma grande variedade de cargas de trabalho.
Para armazenar binários de aplicações, use o Filestore. Os ficheiros que armazena numa instância do Filestore regional são replicados de forma síncrona em três zonas na região. Esta replicação ajuda a garantir a alta disponibilidade e a robustez contra falhas de zonas. Para garantir a robustez contra interrupções de regiões, pode replicar uma instância do Filestore para uma região diferente. Para mais informações, consulte o artigo Replicação de instâncias.
Quando cria armazenamento para as suas cargas de trabalho, considere as características funcionais das cargas de trabalho, os requisitos de resiliência, as expetativas de desempenho e os objetivos de custo. Para mais informações, consulte o artigo Crie uma estratégia de armazenamento ideal para a sua carga de trabalho na nuvem.
Conceção de rede do Oracle Database@Google Cloud
Escolha um design de rede que cumpra os seus requisitos empresariais e técnicos. Por exemplo, pode usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte o artigo Saiba como selecionar topologias de rede para o Oracle Database no Google Cloud.
Quando atribui intervalos de endereços IP para as sub-redes de cliente e de cópia de segurança a usar para os clusters de VMs do Exadata, considere os requisitos mínimos de tamanho da sub-rede. Para mais informações, consulte Planeie o espaço de endereços IP no Oracle Database@Google Cloud.
Migração de base de dados
Quando planeia migrar bases de dados no local para o Oracle Database@Google Cloud, avalie o seu ambiente de base de dados atual e receba recomendações de configuração e dimensionamento através da ferramenta Database Migration Assessment (DMA).
Para ver informações sobre o procedimento e as ferramentas que pode usar para migrar bases de dados Oracle para o Google Cloud, consulte oOracle Migration Methods Advisor.
Antes de usar as bases de dados migradas num ambiente de produção, verifique a conetividade das suas aplicações às bases de dados.
Segurança, privacidade e conformidade
Esta secção descreve os fatores a ter em conta quando usa esta arquitetura de referência para criar uma topologia no Google Cloud que cumpre os requisitos de segurança, privacidade e conformidade das suas cargas de trabalho.
Proteção contra ameaças externas
Para proteger a sua aplicação contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS), pode usar as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que devem ser avaliadas e ações a tomar quando as condições são cumpridas. Por exemplo, uma regra pode especificar que, se o endereço IP de origem do tráfego de entrada corresponder a um endereço IP específico ou a um intervalo CIDR, o tráfego tem de ser recusado. Também pode aplicar regras de firewall de app Web (WAF) pré-configuradas. Para mais informações, consulte a Vista geral da política de segurança.
Acesso externo para VMs
Na arquitetura de referência descrita neste documento, as VMs do Compute Engine não precisam de acesso de entrada a partir da Internet. Não atribua endereços IP externos às VMs. Google Cloud Os recursos que têm apenas um endereço IP interno e privado podem continuar a aceder a determinadas APIs e serviços Google através do Private Service Connect ou do acesso privado à Google. Para mais informações, consulte Opções de acesso privado para serviços.
Para ativar ligações de saída seguras a partir de Google Cloud recursos que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, pode usar o proxy Web seguro ou o Cloud NAT.
Para as sub-redes usadas pelas VMs do Exadata, a Oracle recomenda que atribua intervalos de endereços IP privados.
Privilégios da conta de serviço
Para as VMs do Compute Engine na arquitetura, em vez de usar as contas de serviço predefinidas, recomendamos que crie contas de serviço dedicadas e especifique os recursos aos quais a conta de serviço pode aceder. A conta de serviço predefinida tem uma vasta gama de autorizações, incluindo algumas que podem não ser necessárias. Pode personalizar contas de serviço dedicadas para terem apenas as autorizações essenciais. Para mais informações, consulte o artigo Limite os privilégios da conta de serviço.
Segurança SSH
Para melhorar a segurança das ligações SSH às VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. O IAP permite-lhe controlar o acesso à rede com base na identidade do utilizador e nas políticas de gestão de identidade e de acesso (IAM). A API Cloud OS Login permite-lhe controlar o acesso SSH do Linux com base na identidade do utilizador e nas políticas de IAM. Para mais informações sobre a gestão do acesso à rede, consulte as Práticas recomendadas para controlar o acesso ao início de sessão SSH.
Encriptação de dados
Por predefinição, os dados armazenados no Hyperdisk, no Persistent Disk e no Filestore são encriptados através da Google-owned and Google-managed encryption keys. Como camada adicional de proteção, pode optar por encriptar os dados de conversão usando chaves que detém e gere no Cloud Key Management Service (Cloud KMS). Google-owned and managed key Para mais informações, consulte Acerca da encriptação de disco para volumes do Hyperdisk e do disco persistente e Encriptar dados com chaves de encriptação geridas pelo cliente para o Filestore.
Por predefinição, as bases de dados Exadata usam a encriptação de dados transparente (TDE), que lhe permite encriptar dados confidenciais armazenados em tabelas e espaços de tabelas.
Segurança de redes
Para controlar o tráfego de rede entre os recursos na arquitetura, tem de configurar as políticas da firewall de nova geração (NGFW) do Google Cloud adequadas.
Segurança e conformidade do Oracle Exadata
O Oracle Exadata Database Service inclui o Oracle Data Safe, que ajuda a gerir os requisitos de segurança e conformidade para bases de dados Oracle. Pode usar o Oracle Data Safe para avaliar os controlos de segurança, monitorizar a atividade do utilizador e ocultar dados confidenciais. Para mais informações, consulte o artigo Gerir a segurança da base de dados com o Oracle Data Safe.
Mais considerações de segurança
Quando criar a arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações de segurança ao nível da plataforma fornecidas no projeto de base empresarial e na Google Cloud estrutura bem arquitetada: segurança, privacidade e conformidade.
Fiabilidade
Esta secção descreve os fatores de design a ter em conta quando usa esta arquitetura de referência para criar e operar uma infraestrutura fiável para a sua implementação noGoogle CloudGoogle Cloud.
Robustez contra falhas de VMs
Na arquitetura apresentada neste documento, se uma VM do Compute Engine na camada Web ou na camada de aplicação falhar, o GIG relevante recria a VM automaticamente. Os equilibradores de carga encaminham os pedidos apenas para as instâncias do servidor Web disponíveis e as instâncias do servidor de aplicações.
Autorreparação de VMs
Por vezes, as VMs que alojam a sua aplicação podem estar em execução e disponíveis, mas podem existir problemas com a própria aplicação. A aplicação pode ficar bloqueada, falhar ou não ter memória suficiente. Para verificar se uma aplicação está a responder conforme esperado, pode configurar verificações de funcionamento baseadas em aplicações como parte da política de autocorreção dos seus MIGs. Se a aplicação numa determinada VM não estiver a responder, o GIG faz a autorrecuperação (repara) da VM. Para mais informações sobre a configuração da autocorreção, consulte Acerca da reparação de VMs para alta disponibilidade.
Robustez contra interrupções de regiões
Se ocorrer uma interrupção ao nível da região, a aplicação fica indisponível. Para reduzir o tempo de inatividade causado por falhas de funcionamento da região, pode implementar a seguinte abordagem:
- Mantenha uma réplica passiva (de alternativa) da camada Web e da camada de aplicação noutra Google Cloud região.
- Crie uma instância de infraestrutura do Exadata em modo de espera com os clusters de VMs do Exadata necessários na mesma região que tem a réplica passiva da pilha de aplicações. Use o Oracle Data Guard para a replicação de dados e a comutação por falha automática para as bases de dados Exadata em espera. Se a sua aplicação precisar de um objetivo de ponto de recuperação (RPO) inferior, pode fazer uma cópia de segurança e recuperar as bases de dados através do Oracle Autonomous Recovery Service.
- Se ocorrer uma indisponibilidade na região principal, use a réplica da base de dados ou a cópia de segurança para restaurar a base de dados para produção e ativar a aplicação na região de alternativa.
- Use políticas de encaminhamento de DNS para encaminhar o tráfego para um balanceador de carga externo na região de comutação por falha.
Para aplicações essenciais para o negócio que têm de continuar a estar disponíveis mesmo quando ocorre uma interrupção regional, considere usar o arquétipo de implementação multirregional. Pode usar o Oracle Active Data Guard para fornecer uma base de dados de espera só de leitura na região de failover.
A Oracle gere a infraestrutura no Oracle Database@Google Cloud. Para obter informações acerca dos objetivos ao nível do serviço (SLOs) do Oracle Exadata Database Service na infraestrutura dedicada, consulte os objetivos ao nível do serviço para os serviços de nuvem pública de IaaS e PaaS da Oracle.
Escala automática do MIG
A arquitetura neste documento usa MIGs regionais para a camada Web e a camada de aplicação. A capacidade de escala automática dos GIGs sem estado garante que as VMs do Compute Engine que alojam a camada Web e a camada de aplicação não são afetadas por interrupções de uma única zona.
Para controlar o comportamento de escalamento automático dos MIGs sem estado, pode especificar métricas de utilização alvo, como a utilização média da CPU. Também pode configurar o ajuste de escala automático baseado em programação para MIGs sem estado. Não é possível ajustar automaticamente a escala dos MIGs com estado. Para mais informações, consulte o artigo Grupos de escalamento automático de instâncias.
Limite de tamanho do MIG
Quando decidir o tamanho dos seus MIGs, considere os limites predefinidos e máximos no número de VMs que podem ser criadas num MIG. Para mais informações, consulte o artigo Adicione e remova VMs de um MIG.
Posicionamento de VMs
Na arquitetura descrita neste documento, a camada de aplicação e a camada Web são executadas em VMs do Compute Engine distribuídas por várias zonas. Esta distribuição ajuda a garantir que a camada Web e a camada de aplicação são robustas contra falhas de zona única.
Para melhorar a robustez da arquitetura, pode criar uma política de posicionamento disperso e aplicá-la ao modelo MIG. Quando o MIG cria VMs, coloca-as em diferentes servidores físicos (denominados anfitriões) em cada zona, para que as VMs sejam robustas contra falhas de anfitriões individuais. Para mais informações, consulte o artigo Crie e aplique políticas de posicionamento disperso a VMs.
Planeamento de capacidade de VMs
Para garantir que a capacidade das VMs do Compute Engine está disponível quando as VMs precisam de ser aprovisionadas, pode criar reservas. Uma reserva oferece capacidade garantida numa zona específica para um número especificado de VMs de um tipo de máquina à sua escolha. Uma reserva pode ser específica de um projeto ou partilhada em vários projetos. Para mais informações sobre reservas, consulte o artigo Escolha um tipo de reserva.
Armazenamento com estado
Uma prática recomendada no design de aplicações é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, pode configurar os discos persistentes para serem com estado, de modo a garantir que os dados são preservados quando as VMs são reparadas ou recriadas. No entanto, recomendamos que mantenha os discos de arranque sem estado para que os possa atualizar para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte o artigo Configurar discos persistentes com estado em MIGs.
Capacidade do Oracle Exadata
Pode dimensionar a infraestrutura do Exadata adicionando servidores de bases de dados e servidores de armazenamento conforme necessário. Depois de adicionar os servidores de base de dados ou os servidores de armazenamento necessários à infraestrutura do Exadata, para poder usar os recursos de CPU ou de armazenamento adicionais, tem de adicionar a capacidade ao cluster de VMs do Exadata associado. Para mais informações, consulte o artigo Escalar o cálculo e o armazenamento do Exadata.
Durabilidade dos dados
Pode usar o serviço de cópia de segurança e recuperação de desastres para criar, armazenar e gerir cópias de segurança de VMs do Compute Engine. A cópia de segurança e a RD armazenam dados de cópia de segurança no formato original legível pela aplicação. Quando necessário, pode restaurar cargas de trabalho para produção usando diretamente dados do armazenamento de cópias de segurança a longo prazo sem atividades de preparação ou movimentação de dados demoradas. Para mais informações, consulte Cópia de segurança e recuperação de desastres para cópias de segurança de instâncias do Compute Engine.
Para garantir a durabilidade dos dados nas suas instâncias do Filestore, pode criar cópias de segurança e capturas de ecrã da instância ou usar a cópia de segurança e a recuperação de desastres para o Filestore e os sistemas de ficheiros.
Por predefinição, as cópias de segurança de bases de dados no Oracle Exadata Database Service on Dedicated Infrastructure são armazenadas no OCI Object Storage. Para alcançar um RPO inferior, pode fazer uma cópia de segurança e recuperar as bases de dados através do Oracle Autonomous Recovery Service.
Mais considerações de fiabilidade
Quando criar a arquitetura de nuvem para a sua carga de trabalho, reveja as práticas recomendadas e as recomendações relacionadas com a fiabilidade que são fornecidas na seguinte documentação:
- Google Cloud guia de fiabilidade da infraestrutura
- Padrões para apps escaláveis e resilientes
- Conceber sistemas resilientes
- Google Cloud Framework de arquitetura bem estruturada: fiabilidade
Otimização de custos
Esta secção fornece orientações para otimizar o custo de configuração e funcionamento de uma topologia que cria através desta arquitetura de referência. Google Cloud
Tipos de máquinas de VMs
Para ajudar a otimizar a utilização de recursos das suas instâncias de VM, o Compute Engine oferece recomendações de tipo de máquina. Use as recomendações para escolher tipos de máquinas que correspondam aos requisitos de computação da sua carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, pode personalizar o tipo de máquina de acordo com as suas necessidades e poupar dinheiro usando tipos de máquinas personalizados.
Modelo de aprovisionamento de VMs
Se a sua aplicação for tolerante a falhas, as VMs do Spot podem ajudar a reduzir os custos do Compute Engine para as VMs nas camadas de aplicação e Web. O custo das VMs do Spot é significativamente inferior ao das VMs normais. No entanto, o Compute Engine pode parar ou eliminar preventivamente VMs do Spot para reaver capacidade.
As VMs do Spot são adequadas para tarefas de lotes que podem tolerar a preempção e não têm requisitos de alta disponibilidade. As VMs do Spot oferecem os mesmos tipos de máquinas, opções e desempenho que as VMs normais. No entanto, quando a capacidade de recursos numa zona é limitada, os GIGs podem não conseguir ser expandidos (ou seja, criar VMs) automaticamente para o tamanho alvo especificado até que a capacidade necessária fique novamente disponível.
Utilização de recursos da VM
A capacidade de escala automática dos GIGs sem estado permite que a sua aplicação lide facilmente com aumentos no tráfego e ajuda a reduzir os custos quando a necessidade de recursos é baixa. Não é possível ajustar automaticamente a escala dos MIGs com estado.
Licenças de produtos Oracle
É responsável pela obtenção de licenças para os produtos Oracle que implementa no Compute Engine, e é responsável por agir em conformidade com os termos de utilização das licenças Oracle. Para mais informações, consulte o artigo Licenciamento de software Oracle no ambiente de computação em nuvem.
Licenças de base de dados Oracle Exadata
Quando cria um cluster de VMs do Exadata, pode trazer a sua própria licença (BYOL) ou usar uma licença que comprou como parte da sua encomenda do Google Cloud Marketplace para o Oracle Database@Google Cloud.
Os custos de rede para a transferência de dados entre as suas aplicações e as bases de dados Oracle Exadata que se encontram na mesma região estão incluídos no preço da oferta Oracle Database@Google Cloud.
Mais considerações sobre o custo
Quando criar a arquitetura para a sua carga de trabalho, considere também as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização de custos.
Eficiência operacional
Esta secção descreve os fatores a ter em conta quando usa esta arquitetura de referência para criar uma Google Cloud topologia que pode operar de forma eficiente.
Atualizações da configuração de VMs
Para atualizar a configuração das VMs num GIG (como o tipo de máquina ou a imagem do disco de arranque), crie um novo modelo de instância com a configuração necessária e, em seguida, aplique o novo modelo ao GIG. O MIG atualiza as VMs através do método de atualização que escolher: automático ou seletivo. Escolha um método adequado com base nos seus requisitos de disponibilidade e eficiência operacional. Para mais informações sobre estes métodos de atualização do MIG, consulte o artigo Aplique novas configurações de VMs num MIG.
Imagens do Oracle Linux
Para as suas VMs, pode usar imagens do Oracle Linux disponíveis no Compute Engine ou pode importar imagens do Oracle Linux que cria e mantém. Também pode criar e usar imagens de SO personalizadas que incluem as configurações e o software de que as suas aplicações precisam. Pode agrupar as suas imagens personalizadas numa família de imagens personalizadas. Uma família de imagens aponta sempre para a imagem mais recente nessa família, pelo que os seus modelos de instâncias e scripts podem usar essa imagem sem ter de atualizar referências a uma versão de imagem específica. Tem de atualizar regularmente as suas imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.
Modelos de instância determinísticos
Se os modelos de instância que usa para os seus MIGs incluírem scripts de arranque para instalar software de terceiros, certifique-se de que os scripts especificam explicitamente parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG cria as VMs, o software instalado nas VMs pode não ser consistente. Por exemplo, se o modelo de instância incluir um script de arranque para instalar o Apache HTTP Server 2.0 (o pacote apache2), certifique-se de que o script especifica a versão exata do apache2 que deve ser instalada, como a versão 2.4.53. Para mais informações, consulte o artigo
Modelos de instâncias determinísticos.
Administração da base de dados Oracle Exadata
A Oracle gere os servidores de bases de dados físicos, os servidores de armazenamento e o hardware de rede no Oracle Exadata Database Service on Dedicated Infrastructure. Pode gerir as instâncias da infraestrutura do Exadata e os clusters de VMs do Exadata através das interfaces da OCI ou do Google Cloud . Cria e gere bases de dados através das interfaces da OCI. As páginas da consola para Oracle Database no Google Cloud incluem links que pode usar para aceder diretamente às páginas relevantes na consola do OCI. Google Cloud Para evitar ter de iniciar sessão novamente no OCI, pode configurar a federação de identidades entre o OCI e o Google Cloud.
Observabilidade para aplicações Oracle
Para implementar a observabilidade para cargas de trabalho Oracle implementadas no Google Cloud, pode usar os serviços de observabilidade do Google Cloud ou o Oracle Enterprise Manager. Escolha uma estratégia de monitorização adequada consoante os seus requisitos e restrições. Por exemplo, se executar outras cargas de trabalho, Google Cloud além das cargas de trabalho Oracle, pode usar os serviços de observabilidade do Google Cloud para criar um painel de controlo de operações unificado para todas as cargas de trabalho.
Documentação e apoio técnico da Oracle
Os produtos Oracle executados em VMs do Compute Engine têm preocupações operacionais semelhantes às dos produtos Oracle executados no local. No entanto, não tem de gerir a infraestrutura subjacente de computação, rede e armazenamento. Para obter orientações sobre o funcionamento e a gestão de produtos Oracle, consulte a documentação relevante da Oracle.
Para informações sobre a política de apoio técnico da Oracle para instâncias da Oracle Database que implementa no Google Cloud, consulte o artigo Apoio técnico da Oracle Database para ambientes de nuvem pública não pertencentes à Oracle (ID do documento 2688277.1).
Mais considerações operacionais
Quando cria a arquitetura para a sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações para a eficiência operacional descritas no Google Cloud Well-Architected Framework: excelência operacional.
Otimização do desempenho
Esta secção descreve os fatores a ter em conta quando usa esta arquitetura de referência para criar uma topologia no Google Cloud que cumpre os requisitos de desempenho das suas cargas de trabalho.
Desempenho de computação
O Compute Engine oferece uma ampla gama de tipos de máquinas predefinidos e personalizáveis para as cargas de trabalho que executa em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o recurso de famílias de máquinas e o guia de comparação.
Vários threads da VM
Cada CPU virtual (vCPU) que atribui a uma VM do Compute Engine é implementada como um único multithread de hardware. Por predefinição, duas vCPUs partilham um núcleo da CPU físico. Para aplicações que envolvem operações altamente paralelas ou que realizam cálculos de vírgula flutuante (como a análise de sequências genéticas e a modelagem de risco financeiro), pode melhorar o desempenho reduzindo o número de threads que são executados em cada núcleo da CPU física. Para mais informações, consulte o artigo Defina o número de threads por núcleo.
A multithreading de VMs pode ter implicações de licenciamento para algum software de terceiros, como bases de dados. Para mais informações, leia a documentação de licenciamento do software de terceiros.
Desempenho da rede
O Compute Engine tem um limite por VM para a largura de banda da rede de saída. Este limite depende do tipo de máquina da VM e se o tráfego é encaminhado através da mesma rede VPC que a VM de origem. Para VMs com determinados tipos de máquinas, pode obter uma largura de banda de saída máxima mais elevada ativando a rede de nível 1. Para mais informações, consulte o artigo Configure o desempenho da rede de nível 1 por VM.
O tráfego de rede entre as VMs de aplicações e a rede do Oracle Exadata é encaminhado através de uma ligação Partner Interconnect de baixa latência configurada pela Google.
A infraestrutura Exadata usa RDMA over Converged Ethernet (RoCE) para rede de elevada largura de banda e baixa latência entre os respetivos servidores de base de dados e servidores de armazenamento. Os servidores trocam dados diretamente na memória principal sem envolver o processador, a cache ou o sistema operativo.
Mais considerações sobre o desempenho
Quando criar a arquitetura da sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização do desempenho.
O que se segue?
- Acelerar a transformação na nuvem com a Google Cloud e a Oracle
- Documentação da Oracle
- Documentação da Google
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.
Colaboradores
Autores:
- Kumar Dhanagopal | Cross-Product Solution Developer
- Samantha He | Redatora técnica
Outros colaboradores:
- Andy Colvin | Database Black Belt Engineer, Oracle on Google Cloud
- Jeff Welsch | Director, Product Management
- Lee Gates | Group Product Manager
- Marc Fielding | Data Infrastructure Architect
- Mark Schlagenhauf | Redator técnico, redes
- Michelle Burtoft | Senior Product Manager
- Rajesh Kasanagottu | Engineering Manager
- Roberto Mendez | Staff Network Implementation Engineer
- Samantha He | Redatora técnica
- Sekou Page | Outbound Product Manager
- Souji Madhurapantula | Gestor de produtos de grupo
- Victor Moreno | Gestor de produtos, redes na nuvem