Este documento fornece uma arquitetura de referência para um aplicativo empresarial altamente disponível hospedado em máquinas virtuais (VMs) do Compute Engine com conectividade de baixa latência aos bancos de dados Exadata da Oracle Cloud Infrastructure (OCI) executados em Google Cloud. Os arquitetos de nuvem e administradores de banco de dados Oracle são o público-alvo deste documento. O documento pressupõe que você já conheça o Compute Engine e o Oracle Exadata Database Service.
Se você usa o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bancos de dados Oracle no local, pode migrar seus aplicativos com eficiência para Google Cloud e executar os bancos de dados no Oracle Database@Google Cloud. O Oracle Database@Google Cloud é uma oferta do Google Cloud Marketplace que permite executar o Oracle Exadata Database Service e o Oracle Autonomous Database diretamente no Google Cloud.
Se você não precisar do recurso do Oracle RAC ou se precisar de uma versão do Oracle Database diferente de 19c e 23ai, execute bancos de dados Oracle autogerenciados em VMs do Compute Engine. Para mais informações, consulte Aplicativo empresarial com o Oracle Database no Compute Engine.
Arquitetura
O diagrama a seguir mostra uma visão geral da arquitetura:
No diagrama anterior, um balanceador de carga externo recebe solicitações de usuários de um aplicativo voltado ao público e distribui as solicitações para servidores da Web de front-end. Os servidores da Web encaminham as solicitações do usuário por um balanceador de carga interno para os servidores de aplicativos. Os servidores de aplicativos leem e gravam dados em bancos de dados no Oracle Database@Google Cloud. Os administradores e serviços da OCI podem se conectar e interagir com os bancos de dados Oracle.
O diagrama a seguir mostra uma visão detalhada da arquitetura:
Nessa arquitetura, os níveis da Web e do aplicativo são executados no modo ativo-ativo em VMs do Compute Engine distribuídas em duas zonas dentro de uma região do Google Cloud. O aplicativo usa bancos de dados Oracle Exadata na mesma região Google Cloud.
Todos os componentes da arquitetura estão em uma única região Google Cloud. Essa arquitetura está alinhada com o arquétipo de implantação regional. É possível adaptar essa arquitetura para criar uma topologia robusta contra interrupções regionais usando o arquétipo de implantação multirregional. Para mais informações, consulte Implantação multirregional no Compute Engine e as orientações na seção Confiabilidade mais adiante neste documento.
A arquitetura mostrada no diagrama anterior inclui os seguintes componentes:
| Componente | Purpose |
|---|---|
| Balanceador de carga de aplicativo externo regional | O balanceador de carga de aplicativo externo regional recebe solicitações de usuários e as distribui para as VMs no nível da Web. |
| Política de segurança do Google Cloud Armor | A política de segurança do Cloud Armor ajuda a proteger sua pilha de aplicativos contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários locais (XSS). |
| Grupo gerenciado de instâncias (MIG) regional para o nível da Web | O nível da Web do aplicativo é implantado nas VMs do Compute Engine que fazem parte de um MIG regional. Esse MIG é o back-end do balanceador de carga de aplicativo externo. O MIG contém VMs do Compute Engine em duas zonas. Cada uma dessas VMs hospeda uma instância independente do nível da Web do aplicativo. |
| Balanceador de carga de aplicativo interno regional | O balanceador de carga de aplicativo interno regional distribui o tráfego das VMs de nível da Web para as VMs de nível de aplicativo. |
| MIG regional para o nível do aplicativo | O nível do aplicativo, como um cluster do Oracle WebLogic Server, é implantado em VMs do Compute Engine que fazem parte de um MIG regional. Esse MIG é o back-end do balanceador de carga de aplicativo interno. O MIG contém VMs do Compute Engine em duas zonas. Cada VM hospeda uma instância independente do servidor de aplicativos. |
| Rede de nuvem privada virtual (VPC) e sub-rede | Todos os recursos do Google Cloud na arquitetura usam uma única rede VPC. Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes. Para mais informações, consulte Como decidir se você quer criar várias redes VPC. |
| Oracle Database@Google Cloud |
Os servidores de aplicativos leem e gravam dados em bancos de dados Oracle no Oracle Exadata Database Service. Você provisiona o Oracle Exadata Database Service usando o Oracle Database@Google Cloud, uma oferta do Cloud Marketplace que permite executar bancos de dados Oracle em hardware gerenciado pela Oracle em um data center Google Cloud . Você usa interfaces Google Cloud como o console Google Cloud , a Google Cloud CLI e as APIs para criar instâncias de infraestrutura do Exadata. A Oracle configura e gerencia a infraestrutura de computação, armazenamento e rede necessária em um data center em uma região Google Cloud em hardware dedicado ao seu projeto. |
| Instâncias de infraestrutura do Exadata | Cada instância da infraestrutura do Exadata contém dois ou mais servidores de banco de dados físicos e três ou mais servidores de armazenamento. Esses servidores, que não são mostrados no diagrama, são interconectados usando uma estrutura de rede de baixa latência. Ao criar uma instância da infraestrutura do Exadata, especifique o número de servidores de banco de dados e de armazenamento que precisam ser provisionados. |
| Clusters de VM do Exadata |
Dentro de uma instância da infraestrutura do Exadata, crie um ou mais clusters de VM do Exadata. Por exemplo, você pode criar e usar um cluster de VM do Exadata separado para hospedar os bancos de dados necessários para cada uma das suas unidades de negócios. Cada cluster de VM do Exadata contém uma ou mais VMs do Oracle Linux que hospedam instâncias do Oracle Database. Ao criar um cluster de VM do Exadata, especifique o seguinte:
As VMs nos clusters de VM do Exadata não são VMs do Compute Engine. |
| Instâncias do Oracle Database | Você cria e gerencia bancos de dados Oracle no console do OCI e em outras interfaces do OCI. O software do Oracle Database é executado nas VMs no cluster de VM do Exadata. Ao criar o cluster de VM do Exadata, você especifica a versão da infraestrutura de grade do Oracle. Você também pode escolher o tipo de licença: traga suas próprias licenças (BYOL) ou opte pelo modelo com licença incluída. |
| VCN da OCI e sub-redes | Quando você cria um cluster de VM do Exadata, uma rede de nuvem virtual (VCN) da OCI é criada automaticamente. A VCN tem uma sub-rede de cliente e uma sub-rede de backup com intervalos de endereços IP especificados por você. A sub-rede do cliente é usada para conectividade da sua rede VPC aos bancos de dados Oracle. A sub-rede de backup é usada para enviar backups de banco de dados para o Object Storage da OCI. |
| Cloud Router, Interconexão por parceiro e DRG da OCI | O tráfego entre a rede VPC e a VCN é roteado por um Cloud Router conectado à VPC e por um gateway de roteamento dinâmico (DRG) conectado à VCN. O tráfego flui por uma conexão de baixa latência que o Google configura usando a Interconexão por parceiro. |
| Zona particular do Cloud DNS | Quando você cria um cluster de VM do Exadata, uma zona privada do Cloud DNS é criada automaticamente. Quando os servidores de aplicativos enviam solicitações de leitura e gravação aos bancos de dados Oracle, o Cloud DNS resolve os nomes de host do banco de dados para os endereços IP correspondentes. |
| OCI Object Storage e OCI Service Gateway | Por padrão, os backups dos bancos de dados do Oracle Exadata são armazenados no Object Storage da OCI. Os backups de banco de dados são encaminhados para o Object Storage da OCI por um gateway de serviço. |
| Gateway Cloud NAT público | A arquitetura inclui um gateway público do Cloud NAT para ativar conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. |
| Cloud Interconnect e Cloud VPN | Para conectar sua rede local à rede VPC em Google Cloud, use o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte Como escolher um produto de conectividade de rede. |
| Cloud Monitoring | É possível usar o Cloud Monitoring para observar o comportamento, a integridade e o desempenho do aplicativo e dos recursos do Google Cloud , incluindo os recursos do Oracle Exadata. Também é possível monitorar os recursos do Oracle Exadata usando o serviço OCI Monitoring. |
Produtos usados
Esta arquitetura de referência usa os seguintes produtos do Google Cloud :
- Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
- Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
- Nuvem privada virtual: um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui o peering de rede VPC, o Private Service Connect, o acesso a serviços particulares e a VPC compartilhada.
- Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativos da Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicativos.
- Cloud NAT: um serviço que oferece conversão de endereços de rede de alta performance gerenciada pelo Google Cloud.
- Cloud Monitoring: um serviço que fornece visibilidade do desempenho, da disponibilidade e da integridade dos aplicativos e da infraestrutura.
- Cloud Interconnect: um serviço que estende sua rede externa para a rede do Google por meio de uma conexão de alta disponibilidade e baixa latência.
- Interconexão por parceiro: um serviço que fornece conectividade entre sua rede local e as redes de nuvem privada virtual e outras redes por meio de um provedor de serviços compatível.
- Cloud VPN: um serviço que estende com segurança sua rede de peering para a rede do Google por um túnel de VPN IPsec.
Esta arquitetura de referência usa os seguintes produtos da OCI:
- Exadata Database Service na infraestrutura dedicada: um serviço que permite executar instâncias do Oracle Database em hardware Exadata dedicado a você.
- 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 em uma região da OCI. Uma sub-rede é um intervalo contíguo de endereços IP com uma VCN.
- Gateway de roteamento dinâmico: um roteador virtual para tráfego entre uma VCN e redes externas.
- Gateway de serviço: um gateway que permite que os recursos em uma VCN acessem serviços específicos da Oracle de forma privada.
Considerações sobre o design
Nesta seção, descrevemos fatores de design, práticas recomendadas e recomendações de design que você precisa considerar ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho.
As orientações desta seção não são completas. Dependendo dos requisitos específicos do seu aplicativo e dos produtos e recursos do Google Cloud e de terceiros que você usa, pode haver outros fatores de design e compensações que você precisa considerar.
design do sistema
Nesta seção, fornecemos orientações para ajudar você a escolher Google Cloud regiões para sua implantação e selecionar os Google Cloud serviços adequados.
Seleção da região
Ao escolher as Google Cloud regiões em que seus aplicativos precisam ser implantados, considere os seguintes fatores e requisitos:
- Disponibilidade dos serviços do Google Cloud em cada região. Para mais informações, consulte Produtos disponíveis por local.
- Disponibilidade de tipos de máquina do Compute Engine em cada região. Para mais informações, consulte Regiões e zonas.
- Requisitos de latência do usuário final.
- Custo dos recursos Google Cloud .
- Custos da transferência de dados entre regiões.
- Requisitos regulatórios.
Alguns desses fatores e requisitos podem envolver compensações. Por exemplo, a região mais econômica pode não ter a menor pegada de carbono. Para mais informações, consulte 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 do aplicativo. Dependendo dos requisitos do aplicativo, é possível escolher outros serviços de computação do Google Cloud :
- Contêineres: é possível executar aplicativos conteinerizados nos clusters do Google Kubernetes Engine (GKE). O GKE é um mecanismo de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres.
- Sem servidor: se você preferir concentrar as iniciativas de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run.
A decisão de usar VMs, contêineres ou serviços sem servidor envolve uma troca entre flexibilidade de configuração e esforço de gerenciamento. As VMs e os contêineres oferecem mais flexibilidade de configuração, mas você é responsável por gerenciar os recursos. Em uma arquitetura sem servidor, as cargas de trabalho são implantadas em uma plataforma pré-configurada que requer esforço mínimo de gerenciamento. Para mais informações sobre como escolher serviços de computação adequados para suas cargas de trabalho no Google Cloud, consulte Hospedagem de aplicativos no Google Cloud.
Opções de armazenamento
Para as VMs do Compute Engine na arquitetura, é possível usar volumes de inicialização do Hyperdisk ou do disco permanente. Os volumes do Hyperdisk oferecem melhor desempenho, flexibilidade e eficiência do que o disco permanente. Com o Hyperdisk equilibrado, é possível provisionar IOPS e capacidade de processamento de maneira separada e dinâmica, o que permite ajustar o volume a uma grande variedade de cargas de trabalho.
Para armazenar binários de aplicativos, use o Filestore. Os arquivos armazenados em uma instância do Filestore Regional são replicados de maneira síncrona em três zonas na região. Essa replicação ajuda a garantir alta disponibilidade e robustez contra interrupções dos serviços da zona. Para ter robustez contra interrupções regionais, é possível replicar uma instância do Filestore para outra região. Para mais informações, consulte Replicação de instâncias.
Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais, os requisitos de resiliência, as expectativas de desempenho e as metas de custo. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.
Design de rede do Oracle Database@Google Cloud
Escolha um design de rede que atenda aos seus requisitos comerciais e técnicos. Por exemplo, é possível usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte Saiba como selecionar topologias de rede para o Oracle Database@Google Cloud.
Ao atribuir intervalos de endereços IP para as sub-redes de cliente e de backup a serem usadas nos clusters de VM do Exadata, considere os requisitos mínimos de tamanho da sub-rede. Para mais informações, consulte Planejar o espaço de endereços IP no Oracle Database@Google Cloud.
Migração de bancos de dados
Ao planejar a migração de bancos de dados locais para o Oracle Database@Google Cloud, avalie seu ambiente de banco de dados atual e receba recomendações de configuração e dimensionamento usando a ferramenta Database Migration Assessment (DMA).
Para informações sobre o procedimento e as ferramentas que podem ser usadas para migrar bancos de dados Oracle para o Google Cloud, consulte o Oracle Migration Methods Advisor.
Antes de usar os bancos de dados migrados em um ambiente de produção, verifique a conectividade dos seus aplicativos com os bancos de dados.
segurança, privacidade e conformidade
Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar uma topologia no Google Cloud que atenda aos requisitos de segurança, privacidade e conformidade das suas cargas de trabalho.
Proteção contra ameaças externas
Para proteger o aplicativo contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários locais (XSS), use as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que precisam ser avaliadas e ações a serem tomadas quando as condições são atendidas. 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 ou intervalo CIDR específico, o tráfego precisará ser negado. Também é possível aplicar regras pré-configuradas de firewall de aplicativos da Web (WAF). Para mais informações, consulte Visão 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 da Internet. Não atribua endereços IP externos às VMs.Os recursos do Google Cloud que têm apenas um endereço IP interno particular ainda podem acessar determinadas APIs e serviços do Google usando o Private Service Connect ou o Acesso privado do Google. Para mais informações, consulte Opções de acesso privado para serviços.
Para ativar conexões de saída seguras de recursos do Google Cloud que têm apenas endereços IP privados, como as VMs do Compute Engine nessa arquitetura de referência, use o Secure Web Proxy ou o Cloud NAT.
Para as sub-redes usadas pelas VMs do Exadata, a Oracle recomenda atribuir intervalos de endereços IP particulares.
Privilégios da conta de serviço
Para as VMs do Compute Engine na arquitetura, em vez de usar as contas de serviço padrão, recomendamos criar contas de serviço dedicadas e especificar os recursos a que elas podem acessar. A conta de serviço padrão tem uma ampla variedade de permissões, incluindo algumas que podem não ser necessárias. É possível personalizar contas de serviço dedicadas para ter apenas as permissões essenciais. Para mais informações, consulte Limitar os privilégios da conta de serviço.
Segurança SSH
Para aumentar a segurança das conexões SSH com as VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. Com o IAP, é possível controlar o acesso à rede com base na identidade do usuário e nas políticas do Identity and Access Management (IAM). A API Cloud OS Login permite controlar o acesso SSH do Linux com base na identidade do usuário e nas políticas do IAM. Para mais informações sobre como gerenciar o acesso à rede, consulte Práticas recomendadas para controlar o acesso de login SSH.
Criptografia de dados
Por padrão, os dados armazenados no Hyperdisk, Persistent Disk e no Filestore são criptografados usando oGoogle-owned and Google-managed encryption keys. Como uma camada extra de proteção, é possível criptografar o Google-owned and managed key usando chaves que você tem e gerencia no Cloud Key Management Service (Cloud KMS). Para mais informações, consulte Sobre a criptografia de disco para volumes de Hyperdisk e Persistent Disk e Criptografar dados com chaves de criptografia gerenciadas pelo cliente para o Filestore.
Por padrão, os bancos de dados do Exadata usam a criptografia transparente de dados (TDE), que permite criptografar dados sensíveis armazenados em tabelas e espaços de tabela.
Segurança de rede
Para controlar o tráfego de rede entre os recursos na arquitetura, é preciso configurar as políticas do Cloud Next Generation Firewall (NGFW) adequadas.
Segurança e compliance do Oracle Exadata
O Oracle Exadata Database Service inclui o Oracle Data Safe, que ajuda você a gerenciar os requisitos de segurança e conformidade dos bancos de dados Oracle. Você pode usar o Oracle Data Safe para avaliar controles de segurança, monitorar a atividade do usuário e mascarar dados sensíveis. Para mais informações, consulte Gerenciar a segurança do banco de dados com o Oracle Data Safe.
Mais considerações sobre a segurança
Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas de segurança no nível da plataforma e as recomendações fornecidas no Blueprint de bases empresariais e no Google Cloud Framework do Well-Architected: segurança, privacidade e conformidade.
Confiabilidade
Nesta seção, descrevemos os fatores de design que você precisa considerar ao usar essa arquitetura de referência para criar e operar uma infraestrutura confiável para sua implantação noGoogle Cloud.
Robustez contra falhas de VM
Na arquitetura mostrada neste documento, se uma VM do Compute Engine no nível da Web ou do aplicativo falhar, o MIG relevante vai recriar a VM automaticamente. Os balanceadores de carga encaminham solicitações apenas para as instâncias de servidor da Web e de servidor de aplicativos disponíveis.
Recuperação automática de VM
Às vezes, as VMs que hospedam o aplicativo podem estar em execução e disponíveis, mas pode haver problemas com o próprio aplicativo. O aplicativo pode congelar, falhar ou não ter memória suficiente. Para verificar se um aplicativo está respondendo conforme o esperado, configure verificações de integridade baseadas em aplicativo como parte da política de recuperação automática dos seus MIGs. Se o aplicativo em uma VM específica não estiver respondendo, o MIG vai recuperar (reparar) automaticamente a VM. Para mais informações sobre como configurar a recuperação automática, consulte Como reparar VMs para alta disponibilidade.
Robustez contra interrupções regionais
Se ocorrer uma interrupção do serviço na região, o aplicativo ficará indisponível. Para reduzir o tempo de inatividade causado por falhas de região, implemente a seguinte abordagem:
- Mantenha uma réplica passiva (failover) das camadas da Web e de aplicativo em outra região do Google Cloud .
- Crie uma instância de infraestrutura do Exadata em espera com os clusters de VM do Exadata necessários na mesma região que tem a réplica passiva da pilha de aplicativos. Use o Oracle Data Guard para replicação de dados e failover automático para os bancos de dados Exadata em espera. Se o aplicativo precisar de um objetivo de ponto de recuperação (RPO) menor, faça backup e recupere os bancos de dados usando o Oracle Autonomous Recovery Service.
- Se ocorrer uma interrupção na região principal, use a réplica ou o backup do banco de dados para restaurar o banco de dados para produção e ativar o aplicativo na região de failover.
- Use políticas de roteamento de DNS para rotear o tráfego para um balanceador de carga externo na região de failover.
Para aplicativos essenciais para os negócios que precisam continuar disponíveis mesmo quando ocorre uma interrupção em uma região, considere usar o arquétipo de implantação multirregional. É possível usar o Oracle Active Data Guard para fornecer um banco de dados em espera somente leitura na região de failover.
A Oracle gerencia a infraestrutura no Oracle Database@Google Cloud. Para informações sobre os objetivos de nível de serviço (SLOs) do Oracle Exadata Database Service na infraestrutura dedicada, consulte Objetivos de nível de serviço para serviços de nuvem pública de PaaS e IaaS da Oracle.
Escalonamento automático de MIG
A arquitetura neste documento usa MIGs regionais para os níveis da Web e de aplicativo. A capacidade de escalonamento automático dos MIGs sem estado garante que as VMs do Compute Engine que hospedam os níveis da Web e de aplicativos não sejam afetadas por interrupções de zona única.
Para controlar o comportamento de escalonamento automático de seus MIGs sem estado, é possível especificar métricas de utilização de destino, como a utilização média da CPU. Também é possível configurar o escalonamento automático baseado em programação para MIGs sem estado. MIGs com estado não podem ser escalonados automaticamente. Para mais informações, consulte Escalonamento automático de grupos de instâncias.
Limite de tamanho do MIG
Ao decidir o tamanho dos MIGs, considere os limites padrão e máximo do número de VMs que podem ser criadas em um MIG. Para mais informações, consulte Adicionar e remover VMs de um MIG.
Posicionamento da VM
Na arquitetura descrita neste documento, a camada do aplicativo e da Web são executadas nas VMs do Compute Engine distribuídas por várias zonas. Essa distribuição ajuda a garantir que a camada da Web e a camada de aplicativo sejam robustas contra interrupções de zona única.
Para melhorar a robustez da arquitetura, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca dentro de cada zona em diferentes servidores físicos (chamados de hosts), de modo que suas VMs sejam resistentes contra falhas de hosts individuais. Para mais informações, consulte Criar e aplicar políticas de posicionamento distribuído às VMs.
Planejamento de capacidade de VM
Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando elas precisarem ser provisionadas, crie reservas. Uma reserva oferece capacidade garantida em uma zona específica para um número especificado de VMs de um tipo de máquina escolhido por você. Uma reserva pode ser específica para um projeto ou compartilhada entre vários projetos. Para mais informações sobre reservas, consulte Escolher um tipo de reserva.
Armazenamento com estado
Uma prática recomendada ao projetar aplicativos é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, é possível configurar os discos permanentes com estado para garantir que os dados sejam preservados quando as VMs forem reparadas ou recriadas. No entanto, recomendamos que você mantenha os discos de inicialização sem estado para atualizá-los para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte Como configurar discos permanentes com estado em MIGs.
Capacidade do Oracle Exadata
É possível escalonar a infraestrutura do Exadata adicionando servidores de banco de dados e de armazenamento conforme necessário. Depois de adicionar os servidores de banco de dados ou de armazenamento necessários à infraestrutura do Exadata, para usar os recursos extras de CPU ou armazenamento, adicione a capacidade ao cluster de VM do Exadata associado. Para mais informações, consulte Como escalonar o armazenamento e a computação do Exadata.
Durabilidade dos dados
É possível usar o serviço de Backup e DR para criar, armazenar e gerenciar backups de VMs do Compute Engine. O Backup e DR armazena os dados de backup no formato original legível pelo aplicativo. Quando necessário, é possível restaurar cargas de trabalho para produção usando diretamente os dados do armazenamento de backup de longo prazo sem atividades demoradas de movimentação ou preparação de dados. Para mais informações, consulte Backup e DR para backups de instâncias do Compute Engine.
Para garantir a durabilidade dos dados nas instâncias do Filestore, crie backups e snapshots da instância ou use o Backup e DR para Filestore e sistemas de arquivos.
Por padrão, os backups de bancos de dados no Oracle Exadata Database Service on Dedicated Infrastructure são armazenados no OCI Object Storage. Para reduzir o RPO, faça backup e recuperação dos bancos de dados usando o Oracle Autonomous Recovery Service.
Mais considerações sobre confiabilidade
Ao criar a arquitetura de nuvem para sua carga de trabalho, analise as práticas recomendadas e as recomendações relacionadas à confiabilidade fornecidas na documentação a seguir:
- Google Cloud guia de confiabilidade da infraestrutura
- Padrões para apps escalonáveis e resilientes
- Como projetar sistemas resilientes
- Google Cloud Well-Architected Framework: confiabilidade
Otimização de custos
Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia Google Cloud criada usando essa arquitetura de referência.
Tipos de máquina de VM
Para ajudar você a otimizar a utilização de recursos das instâncias de VM, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que atendem aos requisitos de computação da carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, é possível personalizar o tipo de máquina de acordo com suas necessidades e economizar dinheiro usando tipos de máquinas personalizados.
Modelo de provisionamento de VM
Se o aplicativo for tolerante a falhas, as VMs spot podem ajudar a reduzir os custos do Compute Engine para as VMs nos níveis do aplicativo e da Web. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir antecipadamente as VMs spot para recuperar a capacidade.
As VMs spot são adequadas para jobs em lote que toleram preempção e não têm requisitos de alta disponibilidade. As VMs spot oferecem os mesmos tipos de máquina, opções e desempenho que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir fazer o escalonamento horizontal (ou seja, criar VMs) automaticamente para o tamanho de destino especificado até que a capacidade necessária fique disponível novamente.
Utilização de recursos da VM
O recurso de escalonamento automático dos MIGs sem estado permite que seu aplicativo processe aumentos no tráfego de maneira eficiente, além de ajudar a reduzir o custo quando a necessidade de recursos for baixa. MIGs com estado não podem ser escalonados automaticamente.
Licenças de produtos da Oracle
Você é responsável por adquirir licenças para os produtos da Oracle que implanta no Compute Engine e por obedecer aos termos e condições das licenças da Oracle. Para mais informações, consulte Licenciamento de software da Oracle no ambiente de computação em nuvem.
Licenças do banco de dados Oracle Exadata
Ao criar um cluster de VM do Exadata, você pode trazer sua própria licença (BYOL) ou usar uma licença comprada como parte do seu pedido do Google Cloud Marketplace para o Oracle Database@Google Cloud.
As cobranças de rede para transferência de dados entre seus aplicativos e bancos de dados Oracle Exadata na mesma região estão incluídas no preço da oferta do Oracle Database@Google Cloud.
Mais considerações sobre custo
Ao criar a arquitetura para a carga de trabalho, considere também as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Framework Well-Architected: otimização de custos.
Eficiência operacional
Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar uma topologia de Google Cloud que possa ser operada de maneira eficiente.
Atualizações de configuração da VM
Para atualizar a configuração das VMs em um MIG (como o tipo de máquina ou a imagem do disco de inicialização), crie um novo modelo de instância com a configuração necessária e, em seguida, aplique o novo modelo ao MIG. O MIG atualiza as VMs usando o método de atualização que você escolher: automático ou seletivo. Escolha um método apropriado com base nos seus requisitos de disponibilidade e eficiência operacional. Para mais informações sobre esses métodos de atualização de MIG, consulte Aplicar novas configurações de VM em um MIG.
Imagens do Oracle Linux
Para suas VMs, use imagens do Oracle Linux disponíveis no Compute Engine ou importe imagens do Oracle Linux que você cria e mantém. Também é possível criar e usar imagens do SO personalizadas que incluem as configurações e o software necessários para seus aplicativos. É possível agrupar suas imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre indica a imagem mais recente que ela contém, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica de imagem. É necessário atualizar regularmente as imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.
Modelos deterministas de instância
Se os modelos de instância que você usa para seus MIGs incluírem scripts de inicialização para instalar software de terceiros, verifique se os scripts especificam explicitamente os parâmetros de instalação de software, como a versão do software. Caso contrário, quando
o MIG criar as VMs, o software instalado nelas poderá não ser
consistente. Por exemplo, se o modelo de instância incluir um script de inicialização para instalar o Servidor HTTP Apache 2.0 (o pacote apache2), verifique se o script especifica a versão exata do apache2 que precisa ser instalada como a versão 2.4.53. Para mais informações, consulte Modelos deterministas de instâncias.
Administração do banco de dados Oracle Exadata
A Oracle gerencia os servidores de banco de dados físicos, os servidores de armazenamento e o hardware de rede no Oracle Exadata Database Service na infraestrutura dedicada. É possível gerenciar as instâncias da infraestrutura do Exadata e os clusters de VM do Exadata pelas interfaces do OCI ou do Google Cloud . Você cria e gerencia bancos de dados pelas interfaces da OCI. As páginas do console Google Cloud para o Oracle Database@Google Cloud incluem links que podem ser usados para acessar diretamente as páginas relevantes no console da OCI. Para evitar a necessidade de fazer login novamente no OCI, configure a federação de identidade entre o OCI e o Google Cloud.
Observabilidade para aplicativos Oracle
Para implementar a capacidade de observação das cargas de trabalho do Oracle implantadas no Google Cloud, use os serviços do Google Cloud Observability ou o Oracle Enterprise Manager. Escolha uma estratégia de monitoramento adequada de acordo com seus requisitos e restrições. Por exemplo, se você executar outras cargas de trabalho no Google Cloud além das cargas de trabalho da Oracle, poderá usar os serviços do Google Cloud Observability para criar um painel de operações unificado para todas as cargas de trabalho.
Documentação e suporte da Oracle
Os produtos da Oracle executados em VMs do Compute Engine têm preocupações operacionais semelhantes aos produtos da Oracle executados no local. No entanto, não é necessário gerenciar a infraestrutura de computação, rede e armazenamento subjacente. Para orientações sobre como operar e gerenciar produtos da Oracle, consulte a documentação relevante da Oracle.
Para informações sobre a política de suporte da Oracle para instâncias do Oracle Database implantadas em Google Cloud, consulte Suporte do Oracle Database para ambientes de nuvem pública que não são da Oracle (ID do documento 2688277.1).
Mais considerações operacionais
Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais e as recomendações para eficiência operacional descritas no Google Cloud Framework Well-Architected: excelência operacional.
Otimização de desempenho
Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar uma topologia no Google Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.
Desempenho de computação
O Compute Engine oferece uma ampla variedade de tipos de máquinas predefinidos e personalizáveis para as cargas de trabalho executadas em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.
Várias linhas de execução de VM
Cada CPU virtual (vCPU) alocada para uma VM do Compute Engine é implementada como um multithread de hardware único. Por padrão, duas vCPUs compartilham um núcleo físico da CPU. Para aplicativos que envolvem operações altamente paralelas ou que realizam cálculos de ponto flutuante, como análise de sequência genética e modelagem de risco financeiro, é possível melhorar o desempenho reduzindo o número de linhas de execução executadas em cada núcleo de CPU física. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.
O multithreading de VMs pode ter implicações de licenciamento para alguns softwares de terceiros, como bancos de dados. Para saber mais, 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 de rede de saída. Esse limite depende do tipo de máquina da VM e se o tráfego é roteado pela mesma rede VPC da VM de origem. Para VMs com determinados tipos de máquinas, é possível ter uma largura de banda de saída máxima maior ativando a rede Tier_1. Para mais informações, consulte Configurar o desempenho de rede Tier_1 por VM.
O tráfego de rede entre as VMs do aplicativo e a rede do Oracle Exadata é encaminhado por uma conexão de baixa latência da Interconexão por parceiro configurada pelo Google.
A infraestrutura do Exadata usa RDMA sobre Ethernet convergente (RoCE) para rede de alta largura de banda e baixa latência entre os servidores de banco de dados e de armazenamento. Os servidores trocam dados diretamente na memória principal sem envolver o processador, o cache ou o sistema operacional.
Mais considerações de desempenho
Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas em Google Cloud Framework Well-Architected: otimização de desempenho.
A seguir
- Acelerando a transformação na nuvem com a Google Cloud e a Oracle
- Documentação do Oracle
- Documentação do Google
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Kumar Dhanagopal | Desenvolvedor de soluções para vários produtos
- Samantha He | Redatora técnica
Outros colaboradores:
- Andy Colvin | Engenheiro faixa preta de banco de dados, Oracle no Google Cloud
- Jeff Welsch | Diretor, gerenciamento de produtos
- Lee Gates | Gerente de produtos do grupo
- Marc Fielding | Arquiteto de infraestrutura de dados
- Mark Schlagenhauf | Redator técnico, Rede
- Michelle Burtoft | Gerente sênior de produtos
- Rajesh Kasanagottu | Gerente de engenharia
- Roberto Mendez | Engenheiro de implementação de rede
- Samantha He | Redatora técnica
- Sekou Page | Gerente de produtos de prospecção ativa
- Souji Madhurapantula | Gerente de produtos do grupo
- Victor Moreno | Gerente de produtos, Cloud Networking