Oracle E-Business Suite en Compute Engine con Oracle Exadata

Last reviewed 2025-08-18 UTC

En este documento, se proporciona una arquitectura de referencia para ayudarte a compilar la infraestructura para ejecutar aplicaciones de Oracle E-Business Suite con conectividad de baja latencia a las bases de datos de Exadata de Oracle Cloud Infrastructure (OCI) que se ejecutan en Google Cloud. Oracle E-Business Suite es un conjunto de aplicaciones empresariales para funciones empresariales, como finanzas, recursos humanos, cadena de suministro y relación con los clientes.

El público objetivo de este documento son los arquitectos y administradores de la nube de bases de datos de Oracle y aplicaciones de Oracle E-Business Suite. En el documento, se supone que tu equipo está familiarizado con la pila tecnológica y la arquitectura de Oracle E-Business Suite y Oracle Exadata Database Service.

Si usas Oracle Exadata o Oracle Real Application Clusters (Oracle RAC) para ejecutar bases de datos de Oracle de forma local, puedes migrar tus aplicaciones de manera eficiente a Google Cloud y ejecutar tus bases de datos en Oracle Database@Google Cloud. Oracle Database@Google Cloud es una oferta de Google Cloud Marketplace que te permite ejecutar Oracle Exadata Database Service y Oracle Autonomous Database directamente en Google Cloud.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura en la que las aplicaciones de Oracle E-Business Suite se ejecutan en modo activo-activo en VMs de Compute Engine que se distribuyen en dos zonas dentro de una Google Cloud región. La aplicación usa bases de datos de Oracle Exadata en la misma región de Google Cloud.

Todos los componentes de la arquitectura se encuentran en una sola región de Google Cloud. Esta arquitectura está alineada con el arquetipo de implementación regional. Puedes adaptar esta arquitectura para compilar una topología que sea sólida contra las interrupciones regionales con el arquetipo de implementación multirregional. Para obtener más información, consulta Implementación multirregional en Compute Engine y también la orientación en la sección Confiabilidad más adelante en este documento.

Las aplicaciones de Oracle E-Business Suite se ejecutan en modo activo-activo en las VMs de Compute Engine.

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Objetivo
Balanceador de cargas de aplicaciones externo regional El balanceador de cargas recibe y distribuye las solicitudes de los usuarios a las aplicaciones de Oracle E-Business Suite.
Política de seguridad de Google Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tu pila de aplicaciones contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencia de comandos entre sitios (XSS).
Oracle E-Business Suite (BYOL)

Los componentes de la capa de aplicación de Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server y un servidor de procesamiento simultáneo) se ejecutan en VMs de Compute Engine que se distribuyen en dos zonas de la región principal. Cada VM aloja una instancia independiente de la capa de aplicación. El disco de arranque de cada VM es un volumen de Google Cloud Hyperdisk Balanced.

Tú traes tus propias licencias (BYOL) para Oracle E-Business Suite y administras las VMs y las aplicaciones.
Objetos binarios y datos de la aplicación Una instancia regional de Filestore contiene los objetos binarios y los datos de la aplicación. La instancia de Filestore se activa en todas las VMs de Compute Engine que alojan los componentes de la capa de aplicación en ambas zonas.
Copias de seguridad de aplicaciones Las copias de seguridad de la aplicación se crean, almacenan y administran con el servicio Backup and DR.
Red de nube privada virtual (VPC) Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC. Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Oracle Database@Google Cloud

Las aplicaciones leen datos de las bases de datos de Oracle y escriben en ellas en Oracle Exadata Database Service. Aprovisionas Oracle Exadata Database Service con Oracle Database@Google Cloud, una oferta de Cloud Marketplace que te permite ejecutar bases de datos de Oracle en hardware administrado por Oracle dentro de un centro de datos de Google Cloud .

Usas interfaces de Google Cloud como la consola de Google Cloud , Google Cloud CLI y las APIs para crear instancias de infraestructura de Exadata. Oracle configura y administra la infraestructura de procesamiento, almacenamiento y herramientas de redes necesaria en un centro de datos dentro de una región de Google Cloud en hardware dedicado para tu proyecto.
Instancias de infraestructura de Exadata Cada instancia de infraestructura de Exadata contiene dos o más servidores de bases de datos físicos y tres o más servidores de almacenamiento. Estos servidores, que no se muestran en el diagrama, se interconectan con una estructura de red de baja latencia. Cuando creas una instancia de infraestructura de Exadata, especificas la cantidad de servidores de bases de datos y de almacenamiento que se deben aprovisionar.
Clústeres de VMs de Exadata

Dentro de una instancia de infraestructura de Exadata, creas uno o más clústeres de VMs de Exadata. Por ejemplo, puedes optar por crear y usar un clúster de VMs de Exadata independiente para alojar las bases de datos que se requieren para cada una de tus unidades de negocio. Cada clúster de VMs de Exadata contiene una o más VMs de Oracle Linux que alojan instancias de Oracle Database.

Cuando creas un clúster de VM de Exadata, especificas lo siguiente:

  • Es la cantidad de servidores de base de datos.
  • La capacidad de procesamiento, memoria y almacenamiento que se asignará a cada VM del clúster.
  • Es la red de VPC a la que se debe conectar el clúster.
  • Son los rangos de direcciones IP de las subredes de copia de seguridad y de cliente para el clúster.

Las VMs dentro de los clústeres de VMs de Exadata no son VMs de Compute Engine.
Instancias de Oracle Database Las bases de datos de Oracle se crean y administran a través de la consola de OCI y otras interfaces de OCI. El software de Oracle Database se ejecuta en las VMs dentro del clúster de VMs de Exadata. Cuando creas el clúster de VMs de Exadata, especificas la versión de Oracle Grid Infrastructure. También puedes elegir el tipo de licencia: licencia adquirida por el usuario (BYOL) o el modelo de licencia incluida.
VCN de OCI y subredes Cuando creas un clúster de VMs de Exadata, se crea automáticamente una red de nube virtual (VCN) de OCI. La VCN tiene una subred de cliente y una subred de copia de seguridad con los rangos de direcciones IP que especifiques. La subred del cliente se usa para la conectividad de tu red de VPC a las bases de datos de Oracle. La subred de copia de seguridad se usa para enviar copias de seguridad de la base de datos al almacén de objetos de OCI.
Cloud Router, interconexión de socio y DRG de OCI El tráfico entre tu red de VPC y la VCN se enruta a través de un Cloud Router conectado a la VPC y de una puerta de enlace de enrutamiento dinámico (DRG) conectada a la VCN. El tráfico fluye a través de una conexión de baja latencia que Google configura con la interconexión de socio.
Zona privada de Cloud DNS Cuando creas un clúster de VMs de Exadata, se crea automáticamente una zona privada de Cloud DNS. Cuando tus aplicaciones envían solicitudes de lectura y escritura a las bases de datos de Oracle, Cloud DNS resuelve los nombres de host de la base de datos en las direcciones IP correspondientes.
Almacenamiento de objetos de OCI y puerta de enlace de servicio de OCI De forma predeterminada, las copias de seguridad de las bases de datos de Oracle Exadata se almacenan en OCI Object Storage. Las copias de seguridad de la base de datos se enrutan a OCI Object Storage a través de una puerta de enlace de servicio.
Puerta de enlace de Cloud NAT pública La arquitectura incluye una puerta de enlace de Cloud NAT pública para habilitar las conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas.
Cloud Interconnect o Cloud VPN Para conectar tu red local a la red de VPC en Google Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige una Conectividad de red red.
Cloud Monitoring Puedes usar Monitoring para observar el comportamiento, el estado y el rendimiento de tu aplicación y de los recursos de Google Cloud , incluidos los recursos de Oracle Exadata. También puedes supervisar los recursos de Oracle Exadata con el servicio de OCI Monitoring.

Productos usados

En esta arquitectura de referencia, se usan los siguientes productos de Google Cloud :

  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Google Cloud Armor: Es un servicio de seguridad de redes que ofrece reglas de firewall de aplicación web (WAF) y ayuda a proteger contra ataques DSD y de aplicaciones.
  • Nube privada virtual (VPC): Es un sistema virtual que proporciona funcionalidad de red global y escalable para tus cargas de trabajo de Google Cloud . La VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso privado a servicios y la VPC compartida.
  • Cloud NAT: Es un servicio que proporciona traducción de direcciones de red de alto rendimiento administrada por Google Cloud.
  • Cloud Monitoring: Un servicio que proporciona visibilidad del rendimiento, la disponibilidad y el estado de la infraestructura y las aplicaciones.
  • Cloud Interconnect: Es un servicio que extiende tu red externa a la red de Google a través de una conexión de alta disponibilidad y baja latencia.
  • Interconexión de socio: Es un servicio que proporciona conectividad entre tu red local y tus redes de nube privada virtual y otras redes a través de un proveedor de servicios compatible.
  • Cloud VPN: Es un servicio que extiende de forma segura tu red de intercambio de tráfico a la red de Google a través de un túnel VPN con IPsec.
  • Compute Engine: Un servicio de procesamiento seguro y personalizable que te permite crear y ejecutar VMs en la infraestructura de Google.
  • Google Cloud Hyperdisk: Es un servicio de almacenamiento en red que puedes usar para aprovisionar y escalar de forma dinámica volúmenes de almacenamiento en bloque con un rendimiento configurable y predecible.
  • Filestore: Es un servicio que proporciona almacenamiento de archivos de alto rendimiento y completamente administrado en Google Cloud que puedes conectar a una variedad de tipos de clientes.
  • servicio Backup and DR: Es un servicio de copia de seguridad y recuperación seguro y administrado de forma centralizada para cargas de trabajo de Google Cloud que ayuda a proteger los datos de copia de seguridad de la eliminación accidental o maliciosa.
  • Cloud DNS: Es un servicio que proporciona una entrega de DNS resiliente y de baja latencia desde la red mundial de Google.

En esta arquitectura de referencia, se usan los siguientes productos de Oracle:

  • Oracle E-Business Suite: Es un paquete de aplicaciones para operaciones comerciales, como finanzas, recursos humanos y cadena de suministro.
  • Servicio de base de datos de Exadata en infraestructura dedicada: Es un servicio que te permite ejecutar instancias de Oracle Database en hardware de Exadata dedicado para ti.
  • Almacenamiento de objetos: Es un servicio para almacenar grandes cantidades de datos estructurados y no estructurados como objetos.
  • VCN y subredes: Una VCN es una red virtual y privada para los recursos de una región de OCI. Una subred es un rango contiguo de direcciones IP con una VCN.
  • Puerta de enlace de enrutamiento dinámico: Es un router virtual para el tráfico entre una VCN y las redes externas.
  • Puerta de enlace de servicio: Es una puerta de enlace que permite que los recursos de una VCN accedan a servicios específicos de Oracle de forma privada.

Eres responsable de obtener licencias para los productos de Oracle que implementas en Google Cloudy de cumplir con los Términos y Condiciones de las licencias de Oracle.

Consideraciones del diseño

En esta sección, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento. Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones del Google Cloud Well-Architected Framework.

Diseño de sistemas

En esta sección, se proporciona orientación para que puedas elegir las regiones de Google Cloud para tu implementación y seleccionar los servicios de Google Cloud adecuados.

Selección de región

Cuando elijas las regiones de Google Cloud en las que se deben implementar tus aplicaciones, ten en cuenta los siguientes factores y requisitos:

Algunos de estos factores y requisitos pueden incluir compensaciones. Por ejemplo, es posible que la región más rentable no tenga la huella de carbono más baja. Si deseas obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.

Migración de bases de datos

Cuando planifiques migrar bases de datos locales a Oracle Database@Google Cloud, evalúa tu entorno de base de datos actual y obtén recomendaciones de configuración y tamaño con la herramienta Database Migration Assessment (DMA).

Para obtener información sobre el procedimiento y las herramientas que puedes usar para migrar bases de datos de Oracle a Google Cloud, consulta el Asesor de métodos de migración de Oracle.

Antes de usar las bases de datos migradas en un entorno de producción, verifica la conectividad de tus aplicaciones a las bases de datos.

Opciones de almacenamiento

Para las VMs de Compute Engine en la arquitectura, puedes usar volúmenes de arranque de Google Cloud Hyperdisk o Persistent Disk. Los volúmenes de Hyperdisk proporcionan un mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Google Cloud Hyperdisk Balanced, puedes aprovisionar las IOPS y la capacidad de procesamiento de forma independiente y dinámica, lo que te permite ajustar el volumen a una amplia variedad de cargas de trabajo.

Para almacenar objetos binarios de aplicaciones, usa Filestore. Los archivos que almacenas en una instancia de Filestore regional se replican de forma síncrona en tres zonas dentro de la región. Esta replicación ayuda a garantizar la alta disponibilidad y la solidez contra las interrupciones de zona. Para obtener solidez contra interrupciones regionales, puedes replicar una instancia de Filestore en una región diferente. Para obtener más información, consulta Replicación de instancias.

Cuando diseñes el almacenamiento para tus cargas de trabajo, considera las características funcionales de las cargas de trabajo, los requisitos de la resiliencia, las expectativas de rendimiento y los objetivos de costos. Si quieres obtener más información, consulta Diseña una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Diseño de red de Oracle Database@Google Cloud

Elige un diseño de red que cumpla con tus requisitos empresariales y técnicos. Por ejemplo, puedes usar una sola red de VPC o varias. Para obtener más información, consulta Obtén información sobre cómo seleccionar topologías de red para Oracle Database@Google Cloud.

Cuando asignes rangos de direcciones IP para las subredes de cliente y de copia de seguridad que se usarán en los clústeres de VMs de Exadata, ten en cuenta los requisitos de tamaño mínimo de la subred. Para obtener más información, consulta Planifica el espacio de direcciones IP en Oracle Database@Google Cloud.

Análisis de datos

Para realizar análisis avanzados, puedes usar Google Cloud Cortex Framework para transferir datos de tus aplicaciones de Oracle E-Business Suite a BigQuery. Para obtener más información, consulta Cortex Framework: integración en Oracle E-Business Suite.

Security, privacy, and compliance

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar una topología en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de las cargas de trabajo.

Protección contra amenazas externas

Para proteger tu aplicación contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencia de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifican ciertas condiciones que se deben evaluar y las acciones que se deben realizar cuando se cumplen las condiciones. Por ejemplo, una regla podría especificar que si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un rango de CIDR en particular, se debe denegar el tráfico. También puedes aplicar reglas de firewall de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta Descripción general de las políticas de seguridad.

Acceso externo para las VMs

En la arquitectura de referencia que se describe en este documento, las VMs de Compute Engine no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a las VMs. Google Cloud Los recursos que solo tienen una dirección IP interna privada pueden acceder a ciertas APIs y servicios de Google a través de Private Service Connect o el Acceso privado a Google. Si quieres obtener más información, consulta Opciones de acceso privado a los servicios.

Para habilitar las conexiones salientes seguras desde recursos de Google Cloud que solo tienen direcciones IP privadas, como las VMs de Compute Engine en esta arquitectura de referencia, puedes usar Secure Web Proxy o Cloud NAT.

Para las subredes que usan las VMs de Exadata, Oracle recomienda que asignes rangos de direcciones IP privadas.

Privilegios de la cuenta de servicio

Para las VMs de Compute Engine en la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio dedicadas y especifiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene un amplio rango de permisos, incluidos algunos que podrían no ser necesarios. Puedes adaptar las cuentas de servicio dedicadas para que tengan solo los permisos esenciales. Para obtener más información, consulta Limita los privilegios de la cuenta de servicio.

Seguridad de SSH

Para mejorar la seguridad de las conexiones SSH a las VMs de Compute Engine en tu arquitectura, implementa Identity-Aware Proxy (IAP) y API de Acceso al SO de Cloud. IAP te permite controlar el acceso a la red según la identidad del usuario y las políticas de Identity and Access Management (IAM). La API de Acceso al SO de Cloud te permite controlar el acceso SSH de Linux según la identidad del usuario y las políticas de IAM. Para obtener más información sobre cómo administrar el acceso de red, consulta Prácticas recomendadas para controlar el acceso de acceso SSH.

Encriptación de datos

De forma predeterminada, los datos que se almacenan en Hyperdisk, Persistent Disk y Filestore se encriptan con Google-owned and Google-managed encryption keys. Como una capa adicional de protección, puedes encriptar el Google-owned and managed key con claves que poseas y administres en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta Acerca de la encriptación de discos para los volúmenes de Hyperdisk y Persistent Disk, y Encripta datos con claves de encriptación administradas por el cliente para Filestore.

De forma predeterminada, las bases de datos de Exadata usan la encriptación de datos transparente (TDE), que te permite encriptar datos sensibles almacenados en tablas y espacios de tablas.

Seguridad de red

Para controlar el tráfico de red entre los recursos de la arquitectura, debes configurar las políticas de Cloud Next Generation Firewall (NGFW) adecuadas.

Seguridad y cumplimiento de Oracle Exadata

Oracle Exadata Database Service incluye Oracle Data Safe, que te ayuda a administrar los requisitos de seguridad y cumplimiento de las bases de datos de Oracle. Puedes usar Oracle Data Safe para evaluar los controles de seguridad, supervisar la actividad del usuario y enmascarar los datos sensibles. Para obtener más información, consulta Administra la seguridad de la base de datos con Oracle Data Safe.

Más consideraciones de seguridad

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de empresa y en el Google Cloud Well-Architected Framework: Seguridad, privacidad y cumplimiento.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para compilar y operar una infraestructura confiable para tu implementación en Google Cloud.

Robustez de la capa de aplicación ante fallas de VM

Si algunas (pero no todas) de las VMs que alojan las aplicaciones de Oracle E-Business Suite fallan, las aplicaciones seguirán estando disponibles porque el balanceador de cargas reenvía las solicitudes a otras VMs de la aplicación.

A veces, una VM de aplicación puede estar en ejecución y disponible, pero puede haber problemas con la aplicación. La aplicación puede congelarse, fallar o no tener suficiente memoria. En esta situación, la VM no responderá a las verificaciones de estado del balanceador de cargas, y este no enrutará el tráfico a la VM que no responde.

Solidez contra interrupciones zonales

En una arquitectura regional, si una de las zonas tiene una interrupción, el balanceador de cargas reenvía las solicitudes a las instancias de las aplicaciones que se ejecutan en la otra zona. Filestore sigue estando disponible porque la arquitectura usa el nivel de servicio regional de Filestore.

Para garantizar la alta disponibilidad de los datos en los volúmenes de Google Cloud Hyperdisk durante una interrupción de una sola zona, puedes usar Google Cloud Hyperdisk Balanced High Availability. Cuando se escriben datos en un volumen de Hyperdisk Balanced High Availability, estos se replican de forma síncrona entre dos zonas de la misma región.

Solidez contra las interrupciones regionales

Si se produce una interrupción regional, las aplicaciones no estarán disponibles. Para reducir el tiempo de inactividad que causan las interrupciones regionales, puedes implementar el siguiente enfoque:

  • Mantén una réplica pasiva (de conmutación por error) de la capa de aplicación en otra región de Google Cloud .
  • Crea una instancia de infraestructura de Exadata en espera con los clústeres de VMs de Exadata necesarios en la misma región que tiene la réplica pasiva de la pila de aplicaciones. Usa Oracle Data Guard para la replicación de datos y la conmutación por error automática a las bases de datos de Exadata en espera. Si tu aplicación necesita un objetivo de punto de recuperación (RPO) más bajo, puedes crear copias de seguridad de las bases de datos y recuperarlas con Oracle Autonomous Recovery Service.
  • Si se produce una interrupción en la región principal, usa la réplica o la copia de seguridad de la base de datos para restablecer la base de datos a producción y activar la aplicación en la región de conmutación por error.
  • Usa políticas de enrutamiento de DNS para enrutar el tráfico a un balanceador de cargas externo en la región de conmutación por error.

En el caso de las aplicaciones fundamentales para la empresa que deben seguir disponibles incluso cuando se produce una interrupción regional, considera usar el arquetipo de implementación multirregional. Puedes usar Oracle Active Data Guard para proporcionar una base de datos en espera de solo lectura en la región de conmutación por error.

Oracle administra la infraestructura en Oracle Database@Google Cloud. Para obtener información sobre los objetivos de nivel de servicio (SLO) de Oracle Exadata Database Service on Dedicated Infrastructure, consulta Objetivos de nivel de servicio para los servicios de nube pública de Oracle PaaS e IaaS.

Planificación de la capacidad de las VMs

Para asegurarte de que la capacidad de las VMs de Compute Engine esté disponible cuando sea necesario aprovisionarlas, puedes crear reservas. Una reserva proporciona capacidad garantizada en una zona específica para una cantidad específica de VMs de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse en varios proyectos. Para obtener más información sobre las reservas, consulta Elige un tipo de reserva.

Capacidad de Oracle Exadata

Puedes escalar la infraestructura de Exadata agregando servidores de bases de datos y de almacenamiento según sea necesario. Después de agregar los servidores de bases de datos o de almacenamiento necesarios a la infraestructura de Exadata, para poder usar los recursos adicionales de CPU o almacenamiento, debes agregar la capacidad al clúster de VMs de Exadata asociado. Para obtener más información, consulta Escala el procesamiento y el almacenamiento de Exadata.

Durabilidad de los datos

Puedes usar el servicio Backup and DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. Backup and DR almacena datos de copia de seguridad en su formato original legible para la aplicación. Cuando sea necesario, puedes restablecer las cargas de trabajo a producción directamente a través del uso de datos de almacenamiento de copia de seguridad a largo plazo sin mucho tiempo de movimiento de datos o actividades de preparación. Para obtener más información, consulta Backup and DR para copias de seguridad de instancias de Compute Engine.

Para garantizar la durabilidad de los datos en tus instancias de Filestore, puedes crear copias de seguridad y también instantáneas de la instancia o usar Backup and DR para Filestore y sistemas de archivos.

De forma predeterminada, las copias de seguridad de las bases de datos en Oracle Exadata Database Service en la infraestructura dedicada se almacenan en OCI Object Storage. Para lograr un RPO más bajo, puedes crear copias de seguridad y recuperar las bases de datos con Oracle Autonomous Recovery Service.

Más consideraciones de confiabilidad

Cuando compiles la arquitectura de nube para tu carga de trabajo, revisa las prácticas recomendadas y las recomendaciones relacionadas con la confiabilidad que se proporcionan en la siguiente documentación:

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una topología de Google Cloud que compilas con esta arquitectura de referencia.

Tipos de máquinas de VMs

Para ayudarte a optimizar el uso de los recursos de tus instancias de VM, Compute Engine proporciona recomendaciones sobre los tipos de máquinas. Usa las recomendaciones para elegir los tipos de máquinas que coincidan con los requisitos de procesamiento de tu carga de trabajo. Para cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero a través de los tipos personalizados de máquinas.

Licencias de productos de Oracle

Eres responsable de obtener licencias para los productos de Oracle que implementes en Compute Engine y de cumplir con los Términos y Condiciones de las licencias de Oracle. Para obtener más información, consulta Licensing Oracle Software in the Cloud Computing Environment.

Licencias de bases de datos de Oracle Exadata

Cuando creas un clúster de VMs de Exadata, puedes usar tu propia licencia (BYOL) o una que hayas comprado como parte de tu pedido de Google Cloud Marketplace para Oracle Database@Google Cloud.

Los cargos de red por la transferencia de datos entre tus aplicaciones y las bases de datos de Oracle Exadata que se encuentran en la misma región se incluyen en el precio de la oferta de Oracle Database@Google Cloud.

Más consideraciones de los costos

Cuando compiles la arquitectura de tu carga de trabajo, también considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Google Cloud Well-Architected Framework: Optimización de costos.

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar una topología de Google Cloud que puedas operar de manera eficiente.

Imágenes de Oracle Linux

Para tus VMs, puedes usar imágenes de Oracle Linux que están disponibles en Compute Engine o puedes importar imágenes de Oracle Linux que crees y mantengas.

También puedes crear y usar imágenes de SO personalizadas que incluyan los parámetros de configuración y el software que requieren tus aplicaciones. Agrupar tus imágenes personalizadas en una familia de imágenes personalizada Una familia de imágenes siempre apunta a la imagen más reciente de esa familia para que tus plantillas de instancias y secuencias de comandos puedan usarla sin que tengas que actualizar las referencias a una versión de imagen específica. Actualiza tus imágenes personalizadas con regularidad para incluir las actualizaciones y los parches de seguridad que proporciona el proveedor del SO.

Administración de bases de datos de Oracle Exadata

Oracle administra los servidores de bases de datos físicos, los servidores de almacenamiento y el hardware de red en Oracle Exadata Database Service on Dedicated Infrastructure. Puedes administrar las instancias de infraestructura de Exadata y los clústeres de VMs de Exadata a través de las interfaces de OCI o Google Cloud . Creas y administras bases de datos a través de las interfaces de OCI. Las páginas de la consola de Google Cloud para Oracle Database@Google Cloud incluyen vínculos que puedes usar para ir directamente a las páginas pertinentes en la consola de OCI. Para evitar tener que volver a acceder a OCI, puedes configurar la federación de identidades entre OCI y Google Cloud.

Observabilidad para aplicaciones de Oracle

Para implementar la observabilidad de las cargas de trabajo de Oracle implementadas en Google Cloud, puedes usar los servicios de Google Cloud Observability o Oracle Enterprise Manager. Elige una estrategia de supervisión adecuada según tus requisitos y restricciones. Por ejemplo, si ejecutas otras cargas de trabajo en Google Cloud además de las de Oracle, puedes usar los servicios de Google Cloud Observability para crear un panel de supervisión unificado para todas las cargas de trabajo.

Documentación y asistencia de Oracle

Los productos de Oracle que se ejecutan en las VMs de Compute Engine tienen problemas operativos similares a los de los productos de Oracle que se ejecutan de forma local. Sin embargo, no necesitas administrar la infraestructura subyacente de procesamiento, herramientas de redes y almacenamiento. Para obtener orientación sobre cómo operar y administrar productos de Oracle, consulta la documentación pertinente de Oracle.

Para obtener información sobre la política de asistencia de Oracle para las instancias de Oracle Database que implementas en Google Cloud, consulta Asistencia de Oracle Database para entornos de nube pública que no son de Oracle (ID de documento 2688277.1).

Para obtener un resumen de las políticas de asistencia de Oracle para Oracle E-Business Suite, consulta Certificaciones de EBS.

Más consideraciones operativas

Cuando compiles la arquitectura de tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales para la eficiencia operativa que se describen en Google Cloud Well-Architected Framework: Excelencia operativa.

Optimización del rendimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas esta arquitectura de referencia para diseñar una topología en Google Cloud que cumpla con los requisitos de rendimiento de tus cargas de trabajo.

Rendimiento de procesamiento

Compute Engine ofrece una amplia variedad de tipos de máquinas predefinidos y personalizables para las cargas de trabajo que ejecutas en las VMs. Elige un tipo de máquina adecuado según tus requisitos de rendimiento. Para obtener más información, consulta la guía de comparación y recurso de familias de máquinas.

Rendimiento de la red

Compute Engine tiene un límite por VM para el ancho de banda de red de salida. Este límite depende del tipo de máquina de la VM y de si el tráfico se enruta a través de la misma red de VPC que la VM de origen. Para las VMs con ciertos tipos de máquinas, puedes obtener un ancho de banda de salida máximo más alto si habilitas las redes de Tier_1. Para obtener más información, consulta Configura el rendimiento de red Tier_1 por VM.

El tráfico de red entre las VMs de la aplicación y la red de Oracle Exadata se enruta a través de una conexión de interconexión de socio de baja latencia que configura Google.

La infraestructura de Exadata usa RDMA sobre Ethernet convergente (RoCE) para redes de alto ancho de banda y baja latencia entre sus servidores de bases de datos y servidores de almacenamiento. Los servidores intercambian datos directamente en la memoria principal sin involucrar al procesador, la caché ni el sistema operativo.

Rendimiento del almacenamiento de Hyperdisk

En la arquitectura que se describe en este documento, se usan volúmenes de Hyperdisk para todos los discos de arranque de las VMs que alojan las aplicaciones de Oracle E-Business Suite. Hyperdisk te permite escalar el rendimiento y la capacidad de forma dinámica. Puedes ajustar las IOPS aprovisionadas, la capacidad de procesamiento y el tamaño de cada volumen para que coincidan con las necesidades de rendimiento y capacidad de almacenamiento de tu carga de trabajo. El rendimiento de los volúmenes de Hyperdisk depende del tipo de Hyperdisk y del tipo de máquina de las VMs a las que están conectados los volúmenes. Para obtener más información sobre los límites de rendimiento y el ajuste de Hyperdisk, consulta la siguiente documentación:

Más consideraciones sobre el rendimiento

Cuando compiles la arquitectura para tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Google Cloud Well-Architected Framework: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: