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 com o Oracle Database@Google Cloud (bancos de dados Oracle Cloud Infrastructure Exadata que são executados no Google Cloud). O Oracle PeopleSoft é um pacote de aplicativos empresariais para gestão de capital humano, soluções de campus e planejamento de recursos empresariais.
O público-alvo deste documento são arquitetos de nuvem e administradores de bancos de dados Oracle e aplicativos Oracle PeopleSoft. O documento 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 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 da 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 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. |
| Oracle PeopleSoft mid tier (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 médio | Uma instância do Filestore contém os binários de nível médio. 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 Oracle em hardware gerenciado pela Oracle em um data center do Google Cloud . Use interfaces do Google Cloud , como o console do Google Cloud , a Google Cloud CLI e APIs para criar instâncias da 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 do 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 de infraestrutura do Exadata. |
| Instância da infraestrutura do Exadata | A 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 a instância da infraestrutura do Exadata, você especifica 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, você cria um ou mais clusters de VM do Exadata. Por exemplo, é possível 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 pelo console do Oracle Cloud Infrastructure (OCI) e outras interfaces do OCI. O software Oracle Database é executado nas VMs dentro do cluster de VMs do Exadata. Ao criar o cluster de VM do Exadata, especifique a versão da infraestrutura de grade do Oracle e escolha o tipo de licença. É possível usar suas próprias licenças (BYOL) ou optar 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 que você especifica. A sub-rede do cliente é usada para conectividade da rede VPC com os bancos de dados Oracle. A sub-rede de backup é usada para enviar backups de banco de dados para o repositório de objetos da OCI. |
| Cloud Router, Interconexão por parceiro e DRG da OCI | O tráfego entre a rede VPC no Google Cloud e a VCN da OCI é roteado por um Cloud Router por um gateway de roteamento dinâmico (DRG) anexado à VCN da 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 os 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. |
| Repositório de objetos OCI e Gateway de serviço OCI | Por padrão, os backups dos bancos de dados do Oracle Exadata são armazenados no OCI Object Storage. Os backups de banco de dados são roteados para o OCI Object Storage por meio de um gateway de serviço. |
| Gateway público do Cloud NAT (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 no 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 de monitoramento da OCI. |
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 (VPC): um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui peering de rede VPC, Private Service Connect, acesso a serviços particulares e 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 suas 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 a rede de peering para a rede do Google por meio de um túnel de VPN IPsec.
- Cloud NAT: um serviço que fornece conversão de endereços de rede de alto desempenho 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 mal-intencionada.
- Cloud DNS: um serviço que fornece DNS resiliente e de baixa latência da rede mundial do Google.
Esta arquitetura de referência usa os seguintes produtos da Oracle:
- Oracle PeopleSoft: um pacote de aplicativos empresariais para gestão 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ê.
- VCN 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 o tráfego entre uma VCN e redes externas.
- Repositório de objetos: um serviço para armazenar grandes quantidades de dados estruturados e não estruturados como objetos.
- Gateway de serviço: um gateway para permitir que os recursos em uma VCN acessem serviços específicos da Oracle de forma privada.
Você é responsável por comprar as licenças dos 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 a carga de trabalho, considere também as práticas recomendadas e as recomendações no Google Cloud Well-Architected Framework.
Design do sistema
Nesta seção, fornecemos orientações para ajudar você a escolher regiões do Google Cloud para sua implantação e selecionar os serviços apropriados do Google Cloud .
Seleção da região
Ao escolher as regiões do Google Cloud 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 do Google Cloud .
- Custos da transferência de dados entre regiões.
- Requisitos regulatórios.
- Requisitos de sustentabilidade.
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. Saiba mais em 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 Consultor de métodos de migração do Oracle.
Antes de usar os bancos de dados migrados em um ambiente de produção, verifique a conectividade dos aplicativos com os bancos de dados.
Opções de armazenamento
Para as VMs do Compute Engine na arquitetura, use volumes de inicialização do Hyperdisk do Google Cloud ou do Persistent Disk. Os volumes do Hyperdisk oferecem melhor desempenho, flexibilidade e eficiência do que o Persistent Disk. Com o Google Cloud Hyperdisk Balanced, é possível provisionar IOPS e capacidade de processamento de maneira separada e dinâmica, o que permite ajustar o volume para uma ampla variedade de cargas de trabalho.
Para armazenar binários de aplicativos, use o Filestore. Os arquivos que você armazena 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 de zona. Para garantir a robustez contra interrupções de região, é possível replicar uma instância do Filestore em uma região diferente. 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 técnicos e de negócios. Por exemplo, é possível usar uma 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 para os clusters de VM do Exadata, considere os requisitos mínimos de tamanho de sub-rede. Para mais informações, consulte Planejar o espaço de endereço 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, na sigla em inglês). 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. Google Cloud Os recursos 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 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 que você crie contas de serviço dedicadas e especifique os recursos que a conta de serviço pode 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 de 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 Login do SO do Cloud. O IAP permite 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, no Persistent Disk e no Filestore são criptografados usando Google-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 do Hyperdisk e do 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 de dados transparente (TDE, na sigla em inglês), 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) apropriadas.
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 a gerenciar os requisitos de segurança e conformidade para bancos de dados Oracle. É possível usar o Oracle Data Safe para avaliar controles de segurança, monitorar a atividade do usuário e mascarar dados confidenciais. 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 Well-Architected Framework: 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 do aplicativo contra falhas de VM
Se uma das duas VMs que hospedam cada componente do Oracle PeopleSoft falhar, o aplicativo continuará disponível. As solicitações são roteadas 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 responderá às verificações de integridade do balanceador de carga, e o balanceador de carga não roteará o tráfego para a VM que não responde.
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:
- Manter 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 para os bancos de dados em espera do Exadata. 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 as 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 disponibilidade máxima (MAA) 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 on Dedicated Infrastructure, 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 das VMs do Compute Engine esteja disponível quando as VMs 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 poder usar os recursos adicionais de CPU ou armazenamento, você precisa adicionar a capacidade ao cluster de VM do Exadata associado. Para mais informações, consulte Como escalonar a computação e o armazenamento 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 as 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, é possível criar backups e snapshots da instância ou usar o Backup e DR para o 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 alcançar um RPO menor, é possível fazer backup e recuperar os 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:
- Guia de confiabilidade da infraestrutura doGoogle Cloud
- 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 do 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 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 Oracle no ambiente de computação em nuvem.
Licenciamento do banco de dados Oracle Exadata
Ao criar um cluster de VM do Exadata, é possível usar sua própria licença (BYOL) ou uma licença adquirida 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 os bancos de dados Oracle Exadata que estão 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 Well-Architected Framework: 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 do Google Cloud que possa ser operada de maneira eficiente.
Imagens do Oracle Linux
Para as VMs, é possível usar imagens do Oracle Linux disponíveis no Compute Engine ou importar imagens do Oracle Linux criadas e mantidas por você.
Também é possível criar e usar imagens do SO personalizadas que incluem as configurações e o software que seus aplicativos exigem. Agrupe 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. Atualize regularmente suas imagens personalizadas para incluir as atualizações de segurança e os patches fornecidos pelo fornecedor do SO.
Administração de banco de dados do 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 on Dedicated Infrastructure. É 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 do Google Cloud para o Oracle Database@Google Cloud incluem links que você pode usar para acessar diretamente as páginas relevantes no console da OCI. Para evitar a necessidade de fazer login novamente na OCI, é possível configurar a federação de identidade entre a OCI e o Google Cloud.
Observabilidade para aplicativos Oracle
Para implementar a observabilidade em cargas de trabalho da 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, use os serviços do Google Cloud Observability para criar um painel de monitoramento unificado para todas as cargas de trabalho.
Documentação e suporte 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 é necessário gerenciar a infraestrutura de computação, rede e armazenamento subjacente. Para orientações sobre como operar e gerenciar produtos 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 no 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 para eficiência operacional descritas em Google Cloud Well-Architected Framework: 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 que a VM de origem. Para VMs com determinados tipos de máquina, é possível conseguir 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 por VM de Tier_1.
O tráfego de rede entre as VMs do aplicativo e a rede do Oracle Exadata é roteado por uma conexão de Interconexão por parceiro de baixa latência configurada pelo Google.
A infraestrutura do Exadata usa RDMA em Ethernet convergente (RoCE) para redes 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 Well-Architected Framework: otimização de desempenho.
A seguir
- Transformação na nuvem com o Google Cloud e a Oracle
- Documentação da Oracle
- Visão geral do Oracle Database@Google Cloud
- Arquitetura de máxima disponibilidade (MAA) da Oracle para o Oracle Database@Google Cloud
- Planejar o espaço de endereços IP no Oracle Database@Google Cloud
- Aprenda Mais sobre como selecionar topologias de rede para o Oracle Database@Google Cloud
- Implantar o Oracle Database@Google Cloud
- Arquiteturas de referência de MAA da Oracle (em inglês)
- 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 de banco de dados Black Belt, Oracle no Google Cloud
- Balazs Pinter | Arquiteto de soluções de parceiros da equipe
- Biju Narayanan | Diretor sênior de 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 | Chefe de arquitetos do setor
- Gustavo Jimenez | Arquiteto sênior de soluções 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 de produtos sênior
- Nelson Gonzalez | Gerente de produtos
- Sean Derrington | Gerente de grupo de produtos, Armazenamento