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 para bancos de dados Exadata do Oracle Cloud Infrastructure (OCI) executados no Google Cloud. O público-alvo deste documento são arquitetos de nuvem e administradores de banco de dados do Oracle. O documento pressupõe que você já conhece 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 da Oracle localmente, é possível migrar seus aplicativos de maneira eficiente para o Google Cloud e executar seus 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 Oracle RAC ou precisar de uma versão do Oracle Database diferente do 19c e do 23ai, será possível executar bancos de dados autogerenciados do Oracle 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 as distribui 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 os serviços do OCI podem se conectar e interagir com os bancos de dados do Oracle.
O diagrama a seguir mostra uma visão detalhada da arquitetura:
Nesta arquitetura, o nível da Web e o nível do aplicativo são executados no modo ativo-ativo em VMs do Compute Engine distribuídas em duas zonas em uma região do Google Cloud. O aplicativo usa bancos de dados Oracle Exadata na mesma região do Google Cloud.
Todos os componentes da arquitetura estão em uma única região do Google Cloud. Essa arquitetura está alinhada ao arquétipo de implantação regional. É possível adaptar essa arquitetura para criar uma topologia robusta contra falhas regionais usando o arquétipo de implantação multirregional. Para mais informações, consulte Implantação multirregional no Compute Engine e também as orientações na seção Confiabilidade deste 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 Google Cloud Armor ajuda a proteger seu stack 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 a camada 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 do nível da Web para as VMs do nível do 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 apps. |
| Rede de nuvem privada virtual (VPC) e subrede | 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 Decidir se vai criar várias redes VPC. |
| Oracle Database@Google Cloud |
Os servidores de aplicativos leem e gravam dados nos bancos de dados do Oracle no serviço de banco de dados Oracle Exadata. Você provisiona o serviço de banco de dados Exadata da Oracle 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 centro de dados Google Cloud . Você usa interfaces do 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 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. |
| Instâncias da Exadata Infrastructure | Cada instância da Exadata Infrastructure 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 aparecem no diagrama, são interconectados usando um tecido de rede de baixa latência. Ao criar uma instância da Exadata Infrastructure, você especifica o número de servidores de banco de dados e de armazenamento que precisam ser provisionados. |
| Exadata VM Clusters |
Em uma instância da Exadata Infrastructure, você cria um ou mais clusters de VM do Exadata. Por exemplo, é possível criar e usar um cluster de VM 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, você especifica 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 pelo console do OCI e outras interfaces do OCI. O software Oracle Database é executado nas VMs dentro do cluster de VM do Exadata. Ao criar o cluster de VM Exadata, você especifica a versão da Oracle Grid Infrastructure. Você também escolhe o tipo de licença: traga sua própria licença (BYOL) ou opte pelo modelo com licença incluída. |
| OCI VCN e sub-redes | Quando você cria um cluster de VM do Exadata, uma rede de nuvem virtual (VCN, na sigla em inglês) 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. A sub-rede do cliente é usada para conectividade da sua rede VPC aos bancos de dados do Oracle. A sub-rede de backup é usada para enviar backups do banco de dados ao OCI Object Storage. |
| Cloud Router, Partner Interconnect e OCI DRG | O tráfego entre a rede VPC e a VCN é roteado por um Cloud Router anexado à VPC e por um gateway de roteamento dinâmico (DRG) anexado à 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 Exadata, uma zona particular do Cloud DNS é criada automaticamente. Quando os servidores de aplicativos enviam solicitações de leitura e gravação para os bancos de dados do Oracle, o Cloud DNS resolve os nomes de host do banco de dados para os endereços IP correspondentes. |
| OCI Object Storage 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 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 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 | É 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 no Oracle Exadata usando o serviço de monitoramento do 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.
- Nuvem privada virtual (VPC, na sigla em inglês): um sistema virtual que oferece funcionalidades de rede globais e escalonáveis 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.
- Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativo da Web (WAF, na sigla em inglês) 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 alto desempenho 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 oferece 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 pareamento para a rede do Google por um túnel de VPN IPsec.
Esta arquitetura de referência usa os seguintes produtos do OCI:
- Serviço de banco de dados Exadata em infraestrutura dedicada: um serviço que permite executar instâncias do Oracle Database em hardware Exadata dedicado.
- Armazenamento de objetos: um serviço para armazenar grandes quantidades de dados estruturados e não estruturados como objetos.
- VCN e sub-redes: uma VCN é uma rede virtual e privada para recursos em uma região do OCI. Uma sub-rede é um intervalo contínuo 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.
- Gateway de serviço: um gateway para permitir que recursos em uma VCN acessem serviços específicos do Oracle de forma privada.
Considerações sobre o design
Esta seção descreve os fatores de design, as práticas recomendadas e as 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 app e do Google Cloud e dos produtos e recursos de terceiros que você usa, talvez haja outros fatores de design e trade-offs que você precisa considerar.
design do sistema
Esta seção oferece orientações para escolher as 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 a região do Google Cloud para sua implantação, 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.
- Disponibilidade do Oracle Database@Google Cloud em cada região. Para mais informações, consulte Configurações disponíveis.
- Requisitos de latência do usuário final.
- Custo dos recursos do Google Cloud .
- 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. Saiba mais em 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 hospedar o nível da Web e do aplicativo. Dependendo dos requisitos do seu aplicativo, você pode escolher os seguintes 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ê prefere concentrar os esforços de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run e as funções do 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. VMs e contêineres oferecem mais flexibilidade e controle de configuração, mas você é responsável por gerenciar os recursos. Em uma arquitetura sem servidor, você implanta cargas de trabalho em uma plataforma pré-configurada que exige um esforço mínimo de gerenciamento. As orientações de design para esses serviços estão fora do escopo deste documento. Para mais informações sobre as opções de serviço, consulte Hospedagem de aplicativos no Google Cloud.
Opções de armazenamento
Para fornecer armazenamento permanente para as VMs do Compute Engine no nível da Web e do aplicativo, escolha um tipo de Persistent Disk ou Google Cloud Hyperdisk apropriado com base nos requisitos de capacidade, escalonamento, disponibilidade e desempenho do aplicativo. Para mais informações, consulte Opções de armazenamento.
Se você precisar de armazenamento de baixo custo e redundante em todas as zonas de uma região, use os buckets regionais do Cloud Storage.
Para armazenar dados compartilhados em várias VMs em uma região, como arquivos de configuração de todas as VMs no nível da Web, use uma instância regional do Filestore. Os dados armazenados em uma instância regional do Filestore são replicados de maneira síncrona em três zonas na região1. Essa replicação ajuda a garantir alta disponibilidade e robustez contra falhas de zona para os dados armazenados no Filestore. É possível armazenar arquivos de configuração compartilhados, ferramentas e utilitários comuns e registros centralizados na instância do Filestore e montar a instância em várias VMs.
Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais das cargas de trabalho, requisitos de resiliência, expectativas de desempenho e 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
Ao criar a infraestrutura para uma pilha de aplicativos de vários níveis, é necessário escolher um design de rede que atenda aos requisitos comerciais e técnicos. A arquitetura mostrada neste documento usa uma topologia de rede simples com uma única rede VPC. Dependendo dos seus requisitos, é possível usar várias redes. Para mais informações, consulte a seguinte documentação:
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 de 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 migrar 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 migrar dados locais para implantações de banco de dados Oracle no Google Cloud, use ferramentas padrão do Oracle, como Oracle GoldenGate.
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
Esta seção descreve os fatores a serem considerados 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 seu aplicativo contra ameaças externas, como ataques DDoS e XSS, defina as políticas de segurança adequadas do Google Cloud Armor com base nos seus requisitos. Cada política é um conjunto de regras que especifica as condições a serem avaliadas e as ações a serem tomadas quando as condições forem 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 será negado. Também é possível aplicar regras pré-configuradas do 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 que hospedam o nível da Web e do aplicativo não precisam de acesso de entrada direto da Internet. Não atribua endereços IP externo a essas VMs. Google Cloud recursos que têm apenas endereços IP internos e privados 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 Google Cloud recursos que têm apenas endereços IP particulares, como as VMs do Compute Engine nesta arquitetura de referência, use o NAT do Cloud conforme mostrado no diagrama de arquitetura anterior ou use o Proxy da Web seguro.
Para as sub-redes usadas pelas VMs do Exadata, a Oracle recomenda que você atribua intervalos de endereços IP particulares.
Segurança de imagens de VM
Imagens aprovadas são imagens com software que atende às suas políticas ou requisitos de segurança. Para garantir que as VMs no nível da Web e do aplicativo usem apenas imagens aprovadas, defina uma política da organização que restrinja o uso de imagens em projetos de imagens públicas específicos. Para mais informações, consulte Como configurar políticas de imagens confiáveis.
Privilégios da conta de serviço
Nos projetos do Google Cloud em que a API Compute Engine está ativada, uma
conta de serviço padrão
é criada automaticamente. Para Google Cloud organizações criadas
antes de 3 de maio de 2024, essa conta de serviço padrão recebe o papel de editor
do IAM (roles/editor), a menos que esse comportamento seja desativado.
Por padrão, a conta de serviço padrão é anexada a todas as VMs do Compute Engine criadas usando a CLI gcloud ou o console Google Cloud . A função de editor inclui uma ampla gama de permissões. Portanto, a vinculação da conta de serviço padrão a VMs cria um risco de segurança. Para evitar esse risco, crie e use contas de serviço dedicadas para cada nível da pilha de aplicativos. Para especificar os recursos que a conta de serviço pode acessar, use políticas refinadas. Para mais informações, consulte Limitar os privilégios da conta de serviço.
Segurança de rede
Para controlar o tráfego de rede entre os recursos do nível da Web e do aplicativo da arquitetura, configure as políticas do Cloud Next Generation Firewall (NGFW, na sigla em inglês) adequadas.
Segurança e compliance do banco de dados
O serviço Exadata Database inclui o Oracle Data Safe, que ajuda a gerenciar requisitos de segurança e conformidade para 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 sua carga de trabalho, considere as práticas recomendadas de segurança no nível da plataforma e as recomendações fornecidas no modelo de fundamentos empresariais.
Confiabilidade
Esta seção descreve os fatores de design a serem considerados 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 recria 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 no momento.
Recuperação automática de VM
Às vezes, as VMs que hospedam o nível da Web e do aplicativo podem estar em execução e disponíveis, mas podem haver problemas com o próprio aplicativo. O aplicativo pode congelar, falhar ou não ter memória suficiente. Nesse cenário, as VMs não respondem às verificações de integridade do balanceador de carga, e o balanceador não encaminha o tráfego para as VMs que não respondem. Para garantir que os aplicativos respondam conforme o esperado, configure verificações de integridade baseadas em aplicativos 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 fazer a autocorreção (reparo) da VM. Para mais informações sobre como configurar a autocorreção, consulte Sobre o reparo de VMs para alta disponibilidade.
Robustez contra interrupções da região
Se ocorrer uma interrupção regional, o aplicativo ficará indisponível. Para reduzir o tempo de inatividade causado por falhas na região, implemente a seguinte abordagem:
- Mantenha uma réplica passiva (failover) do nível da Web e do nível do aplicativo em outra região do Google Cloud .
- Crie uma instância de infraestrutura Exadata reserva 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 a 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 na 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 falha na região, use o arquétipo de implantação multirregional. É possível usar o Oracle Active Data Guard para fornecer um banco de dados de 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 serviço de banco de dados Oracle Exadata em infraestrutura dedicada, consulte Objetivos de nível de serviço para serviços de nuvem pública do Oracle PaaS e IaaS.
Escalonamento automático de MIG
A arquitetura neste documento usa MIGs regionais para o nível da Web e do aplicativo. O recurso de escalonamento automático de MIGs sem estado garante que as VMs do Compute Engine que hospedam o nível da Web e do aplicativo não sejam afetadas por falhas de uma zona. MIGs com estado não podem ser escalonados automaticamente.
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 mais informações, consulte Escalonamento automático de grupos de instâncias.
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 o nível da Web e o nível do aplicativo sejam robustos contra falhas de zona única. Para melhorar ainda mais essa robustez, crie uma política de posicionamento expandida e aplique ao modelo de MIG. Com uma política de posicionamento de propagação, quando o MIG cria VMs, elas são colocadas em cada zona em servidores físicos diferentes (chamados de hosts), para que as VMs sejam resistentes a falhas de hosts individuais. No entanto, uma desvantagem dessa abordagem é que a latência do tráfego de rede entre VMs pode aumentar. Para mais informações, consulte Visão geral das políticas de posicionamento.
Planejamento de capacidade de VM
Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando necessário para o escalonamento automático de MIGs, 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 ser compartilhada em vários projetos. Você vai receber cobranças por recursos reservados, mesmo que eles não sejam provisionados ou usados. Para mais informações sobre reservas, incluindo considerações de faturamento, consulte Reservas de recursos zonais do Compute Engine.
Armazenamento com estado
Uma prática recomendada ao projetar aplicativos é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, você poderá configurar os discos para terem estado e 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 facilmente 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 banco de dados
É possível dimensionar a Exadata Infrastructure 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 à Exadata Infrastructure, adicione a capacidade ao cluster de VM Exadata associado para usar os recursos de CPU ou armazenamento adicionais. Para mais informações, consulte Como dimensionar o Exadata Compute e o Exadata Storage.
Backup e recuperação
Você pode usar o serviço de backup e DR para criar, armazenar e gerenciar backups de VMs do Compute Engine. O serviço de backup e DR armazena dados de backup no formato original legível pelo aplicativo. Quando necessário, é possível restaurar cargas de trabalho para a produção usando diretamente os dados do armazenamento de backup de longo prazo sem atividades de preparação ou movimentação de dados demoradas. Para mais informações, consulte Backup e serviço de DR para backups de instâncias do Compute Engine.
Por padrão, os backups de bancos de dados no Oracle Exadata Database Service em infraestrutura dedicada são armazenados no OCI Object Storage. Para alcançar um RPO menor, faça backup e recupere 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:
Otimização de custos
Esta seção fornece orientações para otimizar o custo de configuração e operação de uma Google Cloud topologia que você cria usando esta arquitetura de referência.
Tipos de máquina de VM
Para ajudar a otimizar a utilização das VMs, o Compute Engine oferece recomendações de tipo de máquina. Use as recomendações para escolher tipos de máquina que correspondam aos requisitos de computação das VMs do nível da Web e do nível do aplicativo. 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áquina 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 suas VMs no nível da Web e do aplicativo. O custo das VMs Spot é significativamente menor do que o das VMs comuns. No entanto, o Compute Engine pode interromper ou excluir VMs do Spot para recuperar a capacidade.
As VMs spot são adequadas para jobs em lote que toleram a 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 comuns. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir escalonar horizontalmente automaticamente (ou seja, criar VMs) para atingir o tamanho de destino especificado até que a capacidade necessária esteja disponível novamente.
Utilização de recursos da VM
O recurso de escalonamento automático de MIGs sem estado permite que seu aplicativo lide com aumentos no tráfego para a camada da Web e do aplicativo. O escalonamento automático também ajuda a reduzir custos quando a necessidade de recursos é baixa. MIGs com estado não podem ser escalonados automaticamente.
Custos do banco de dados
Ao criar um cluster de VM Exadata, você pode escolher o BYOL ou provisionar bancos de dados Oracle incluídos na licença.
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 Framework de arquitetura: otimização de custos.
Eficiência operacional
Esta seção descreve os fatores a serem considerados ao usar essa arquitetura de referência para projetar uma topologia 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 aplique o novo modelo ao MIG. O MIG atualiza as VMs usando um método de atualização especificado por você: 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 de VM
Para os modelos de instâncias de MIG, em vez de usar imagens públicas fornecidas pelo Google, recomendamos que você crie e use imagens de SO personalizadas que incluam as configurações e o software necessários para seus aplicativos. É possível agrupar as imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre aponta para a imagem mais recente da família, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica. É necessário atualizar regularmente as imagens personalizadas para incluir atualizações de segurança e patches fornecidos pelo fornecedor do SO.
Modelos deterministas de instância
Se os modelos de instância usados para os MIGs incluem scripts de inicialização,
por exemplo, para instalar softwares de terceiros, verifique se os scripts
especificam explicitamente os parâmetros de instalação do software, como a versão
do software. Caso contrário, quando o MIG criar as VMs, o software instalado
nas VMs poderá não ser consistente. Por exemplo, se o modelo de instância
incluir um script de inicialização para instalar o Apache HTTP Server 2.0 (o pacote
apache2), verifique se o script especifica a versão exata de apache2
que precisa ser instalada, como a versão 2.4.53. Para mais informações, consulte Modelos deterministas de instâncias.
Administração de banco de dados
O Oracle gerencia os servidores de banco de dados físicos, os servidores de armazenamento e o hardware de rede no Oracle Exadata Database Service em infraestrutura dedicada. É possível gerenciar as instâncias de infraestrutura do Exadata e os clusters de VM do Exadata usando as interfaces do OCI ou do Google Cloud . Você cria e gerencia bancos de dados pelas interfaces do OCI. As páginas do console do Google Cloud para o Oracle Database@Google Cloud incluem links que podem ser usados para acessar diretamente as páginas relevantes no console do OCI. Para evitar a necessidade de fazer login novamente no OCI, configure a federação de identidade entre o OCI e o Google Cloud.
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 Framework de arquitetura: excelência operacional.
Otimização de desempenho
Esta seção descreve os fatores a serem considerados 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áquina predefinidos e personalizáveis que você pode escolher de acordo com os requisitos de desempenho das cargas de trabalho. Para as VMs que hospedam o nível da Web e do aplicativo, escolha um tipo de máquina adequado com base nos requisitos de desempenho para esses níveis. Para mais informações, consulte Comparação de séries de máquinas.
Desempenho da rede
Para cargas de trabalho que precisam de baixa latência de rede entre VMs nos níveis de aplicativo e da Web, crie uma política de posicionamento compacto e aplique-a ao modelo MIG usado para esses níveis. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Enquanto uma política de posicionamento compacto ajuda a melhorar o desempenho da rede entre VMs, uma política de posicionamento distribuído pode ajudar a melhorar a disponibilidade da VM, conforme descrito anteriormente. Para alcançar o equilíbrio ideal entre a performance e a disponibilidade da rede, ao criar uma política de posicionamento compacta, você pode especificar a distância entre as VMs. Para mais informações, consulte Visão geral das políticas de posicionamento.
O Compute Engine tem um limite por VM para 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áquina, para melhorar o desempenho da rede, é 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 nível do aplicativo e a rede Oracle Exadata é roteado por uma conexão de Interconexão por parceiro de baixa latência configurada pelo Google.
A Exadata Infrastructure usa RDMA sobre Ethernet Converged (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 envolvimento do processador, cache ou 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 de arquitetura: otimização de desempenho.
A seguir
- Como acelerar a transformação em nuvem com o Google Cloud e 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
Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos
Outros colaboradores:
- Andy Colvin | Database Black Belt Engineer (Oracle on 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
- Sekou Page | Gerente de produtos de prospecção ativa
- Souji Madhurapantula | Gerente de produtos do grupo
- Victor Moreno | Gerente de produtos, Cloud Networking
-
As regiões do México, de Montreal e de Osaka têm três zonas em um ou dois data centers físicos. Essas regiões estão em processo de expansão para pelo menos três data centers físicos. Para mais informações, consulte Locais do Cloud e Google Cloud SLAs da plataforma. Para melhorar a confiabilidade das cargas de trabalho, considere uma implantação multirregional. ↩