Este documento fornece uma arquitetura de referência para ajudar você a criar a infraestrutura para executar aplicativos Oracle PeopleSoft em VMs do Compute Engine com conectividade de baixa latência ao Oracle Database@Google Cloud (bancos de dados Exadata do Oracle Cloud Infrastructure executados em Google Cloud). O Oracle PeopleSoft é um conjunto de aplicativos corporativos para gestão de capital humano, soluções para campus e planejamento de recursos empresariais.
O público-alvo deste documento são arquitetos e administradores de nuvem de bancos de dados Oracle e aplicativos Oracle PeopleSoft. Ele pressupõe que você esteja familiarizado com os aplicativos Oracle PeopleSoft e os bancos de dados Oracle.
Arquitetura
O diagrama a seguir mostra uma arquitetura em que os aplicativos do Oracle PeopleSoft são executados em VMs do Compute Engine em uma Google Cloud região e usam bancos de dados Oracle Exadata na mesma Google Cloud região.
A arquitetura no diagrama anterior inclui os seguintes componentes:
| Componente | Finalidade |
|---|---|
| Balanceador de carga de aplicativo externo regional | O balanceador de carga recebe solicitações de usuários e as distribui para os servidores da Web do Oracle PeopleSoft. Para garantir a afinidade de sessão, o balanceador de carga é configurado para usar cookies gerados. |
| 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). |
| Nível da Web do Oracle PeopleSoft (BYOL) | O nível da Web do Oracle PeopleSoft consiste em servidores da Web que são executados de forma independente em duas VMs do Compute Engine. Você traz suas próprias licenças (BYOL) para o Oracle PeopleSoft e gerencia as VMs e o software do servidor da Web. |
| Binários do servidor da Web | Uma instância do Filestore contém os binários do servidor da Web. A instância do Filestore é montada em todas as VMs do Compute Engine que hospedam os servidores da Web. |
| Nível intermediário do Oracle PeopleSoft (BYOL) |
O nível intermediário do Oracle PeopleSoft consiste nos seguintes componentes:
Cada um desses componentes é executado de forma independente em duas VMs do Compute Engine. Você traz suas próprias licenças (BYOL) para os componentes do Oracle PeopleSoft e gerencia as VMs e o software de nível intermediário. |
| Binários de nível intermediário | Uma instância do Filestore contém os binários de nível intermediário. A instância do Filestore é montada em todas as VMs do Compute Engine que hospedam os componentes de nível intermediário. |
| Backups de aplicativos | Os backups do aplicativo são criados, armazenados e gerenciados usando o Serviço de backup e DR. |
| Rede de nuvem privada virtual (VPC) | Todos os recursos do Google Cloud na arquitetura usam uma única rede VPC. Os servidores da Web, os componentes de nível intermediário e os bancos de dados estão em sub-redes separadas. |
| Oracle Database@Google Cloud |
Os aplicativos Oracle PeopleSoft 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 da 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 APIs, para criar instâncias de infraestrutura do Exadata. A Oracle configura e gerencia a infraestrutura necessária de computação, armazenamento e rede em um data center dentro de uma região Google Cloud em hardware dedicado ao seu projeto. Para otimizar a latência entre o aplicativo e o banco de dados, implante o aplicativo na mesma zona em que você cria as instâncias da infraestrutura do Exadata. |
| Instância de infraestrutura do Exadata | A instância de 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 a 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 | Na 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 instâncias do Oracle Database no console do Oracle Cloud Infrastructure (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 e escolhe o tipo de licença. Você pode trazer suas próprias licenças (BYOL) ou optar pelo modelo com licença incluída. |
| VCN e sub-redes da OCI | Quando você cria um cluster de VM do Exadata, uma rede de nuvem virtual (VCN) do 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 em Google Cloud e a VCN do OCI é roteado por um Cloud Router por um gateway de roteamento dinâmico (DRG) anexado à VCN do OCI. 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 seus aplicativos enviam solicitações de leitura e gravação para os 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 do OCI por um gateway de serviço. |
| Gateway Cloud NAT público (opcional) | A arquitetura inclui um gateway público opcional do Cloud NAT. O gateway permite conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. |
| Cloud Interconnect ou 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 | Use 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.
- 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.
- 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.
- 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.
- Cloud NAT: um serviço que oferece conversão de endereços de rede de alta performance gerenciada pelo Google Cloud.
- Serviço de backup e DR: um serviço seguro e gerenciado centralmente de backup e recuperação para cargas de trabalho do Google Cloud que ajuda a proteger os dados de backup contra exclusão acidental ou maliciosa.
- Cloud DNS: um serviço que oferece DNS resiliente e de baixa latência na rede mundial do Google.
Esta arquitetura de referência usa os seguintes produtos da Oracle:
- Oracle PeopleSoft: um pacote de aplicativos empresariais para gerenciamento de capital humano, soluções para campus e planejamento de recursos empresariais.
- Exadata Database Service na infraestrutura dedicada: um serviço que permite executar instâncias do Oracle Database em hardware Exadata dedicado a você.
- 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.
- Armazenamento de objetos: um serviço para armazenar grandes quantidades de dados estruturados e não estruturados como objetos.
- Gateway de serviço: um gateway que permite que os recursos em uma VCN acessem serviços específicos da Oracle de forma privada.
Você é responsável por adquirir licenças para os produtos da Oracle que implanta no Google Cloude por obedecer aos termos e condições das licenças da Oracle.
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. Ao criar a arquitetura para sua carga de trabalho, considere também as práticas recomendadas e recomendações no Google Cloud Well-Architected Framework.
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.
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.
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 Persistent Disk. 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 em 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.
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 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 privado 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 que você atribua 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 tablespaces.
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.
Para as VMs do servidor da Web, verifique se o campo de origem da política de entrada inclui o seguinte:
- O CIDR da sub-rede somente proxy do balanceador de carga.
- Os blocos CIDR das sondagens de verificação de integridade.
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 Framework doGoogle Cloud 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 da camada de aplicativo contra falhas de VM
Se uma das duas VMs que hospedam cada componente do Oracle PeopleSoft falhar, o aplicativo vai continuar disponível. As solicitações são encaminhadas para a outra VM.
Às vezes, uma VM pode estar em execução e disponível, mas pode haver problemas com o próprio componente do Oracle Peoplesoft. O componente pode congelar, falhar ou não ter memória suficiente. Nesses cenários, a VM não responde às verificações de integridade do balanceador de carga, e o balanceador não roteia o tráfego para a VM sem resposta.
Robustez contra interrupções de zona ou região
Se ocorrer uma interrupção de zona ou região, o aplicativo ficará indisponível. Para reduzir o tempo de inatividade causado por essas interrupções, implemente a seguinte abordagem:
- Mantenha uma réplica passiva (failover) da pilha de aplicativos em outra região ou zona doGoogle Cloud .
- Crie uma instância de infraestrutura do Exadata em espera com os clusters de VM do Exadata necessários na mesma zona que tem a réplica passiva da pilha de aplicativos. Use o Oracle Active Data Guard para replicação de dados e failover automático nos 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 ou zona 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 ou zona de failover.
- Se a réplica passiva estiver em uma região diferente, use políticas de roteamento do Cloud DNS para rotear o tráfego para o balanceador de carga externo nessa região.
Para mais informações, consulte Arquitetura de máxima disponibilidade (MAA, na sigla em inglês) da Oracle para o Oracle Database@Google Cloud.
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.
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 específico 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.
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.
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.
Licenciamento 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.
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.
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.
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.
Para otimizar a latência entre o aplicativo e o banco de dados, implante o aplicativo na mesma zona em que você cria a instância da infraestrutura do Exadata.
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
- Transformação na nuvem com Google Cloud e Oracle
- Documentação do Oracle
- Visão geral do Oracle Database@Google Cloud
- Arquitetura de máxima disponibilidade (MAA, na sigla em inglês) do Oracle para o Oracle Database@Google Cloud
- Planejar o espaço de endereços IP no Oracle Database@Google Cloud
- Saiba como selecionar topologias de rede para o Oracle Database@Google Cloud
- Implantar o Oracle Database@Google Cloud
- Arquiteturas de referência do Oracle MAA
- Documentação do Google
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos
Outros colaboradores:
- Andy Colvin | Engenheiro faixa preta de banco de dados, Oracle no Google Cloud
- Balazs Pinter | Arquiteto de soluções parceiras
- Biju Narayanan | Diretor sênior, Desenvolvimento de aplicativos (Oracle)
- Bikash Kar | Líder de projeto, desenvolvimento de aplicativos (Oracle)
- Celia Antonio | Engenheira de clientes de banco de dados
- Charles Elliott | Head of Industry Architects
- Gustavo Jimenez | Arquiteto de soluções sênior para parceiros
- Hari G I | Engenheiro de software principal sênior (Oracle)
- Jignesh Patel | Engenheiro de clientes
- Jon Pawlowski | Engenheiro de parceiros
- Karteek Kotamsetty | Engenheiro de clientes líder
- Kenny He | Engenheiro de clientes, especialista em dados
- Majed Al-Halaseh | Engenheiro de clientes, modernização de infraestrutura
- Marc Fielding | Arquiteto de infraestrutura de dados
- Maria Zuliani | Engenheiro de clientes, especialista em banco de dados
- Michelle Burtoft | Gerente sênior de produtos
- Nelson Gonzalez | Gerente de produtos
- Sean Derrington | Gerente de produtos do grupo, Armazenamento