Oracle PeopleSoft en Compute Engine con Oracle Exadata

Last reviewed 2025-08-21 UTC

En este documento se proporciona una arquitectura de referencia para ayudarte a crear la infraestructura necesaria para ejecutar aplicaciones de Oracle PeopleSoft en máquinas virtuales de Compute Engine con una conectividad de baja latencia a Oracle Database@Google Cloud (bases de datos de Oracle Cloud Infrastructure Exadata que se ejecutan en Google Cloud). Oracle PeopleSoft es una suite de aplicaciones empresariales para la gestión del capital humano, las soluciones para centros educativos y la planificación de recursos empresariales.

Este documento está dirigido a arquitectos y administradores de nubes de bases de datos de Oracle y aplicaciones Oracle PeopleSoft. En este documento se da por supuesto que conoces las aplicaciones de Oracle PeopleSoft y las bases de datos de Oracle.

Arquitectura

En el siguiente diagrama se muestra una arquitectura en la que las aplicaciones Oracle PeopleSoft se ejecutan en VMs de Compute Engine en una Google Cloud región y usan bases de datos Oracle Exadata en la misma Google Cloud región.

Arquitectura de Oracle PeopleSoft con Oracle Exadata.

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Finalidad
Balanceador de carga de aplicación externo regional El balanceador de carga recibe las solicitudes de los usuarios y las distribuye a los servidores web de Oracle PeopleSoft. Para asegurar la afinidad de sesión, el balanceador de carga se configura para usar cookies generadas.
Política de seguridad de Google Cloud Armor La política de seguridad de Cloud Armor te ayuda a proteger tu pila de aplicaciones frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las vulnerabilidades de tipo cross-site scripting (XSS).
Nivel web de Oracle PeopleSoft (BYOL) El nivel web de Oracle PeopleSoft consta de servidores web que se ejecutan de forma independiente en dos VMs de Compute Engine. Tú proporcionas las licencias de Oracle PeopleSoft (BYOL) y gestionas las máquinas virtuales y el software del servidor web.
Binarios del servidor web Una instancia de Filestore contiene los archivos binarios del servidor web. La instancia de Filestore se monta en todas las VMs de Compute Engine que alojan los servidores web.
Nivel intermedio de Oracle PeopleSoft (BYOL)

El nivel intermedio de Oracle PeopleSoft consta de los siguientes componentes:

  • OpenSearch
  • Servidor de aplicaciones
  • Planificador de procesos

Cada uno de estos componentes se ejecuta de forma independiente en dos VMs de Compute Engine. Tú proporcionas las licencias (BYOL) de los componentes de Oracle PeopleSoft y gestionas las VMs y el software de nivel intermedio.
Binarios de nivel medio Una instancia de Filestore contiene los archivos binarios de nivel intermedio. La instancia de Filestore se monta en todas las VMs de Compute Engine que alojan los componentes de nivel intermedio.
Copias de seguridad de aplicaciones El servicio Backup y DR crea, almacena y gestiona copias de seguridad de la aplicación.
Red de nube privada virtual (VPC) Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. Los servidores web, los componentes de nivel intermedio y las bases de datos se encuentran en subredes independientes.
Base de datos de Oracle@Google Cloud

Las aplicaciones de Oracle PeopleSoft leen y escriben datos en bases de datos de Oracle en Oracle Exadata Database Service. Puedes aprovisionar Oracle Exadata Database Service mediante Oracle Database@Google Cloud, una oferta de Cloud Marketplace que te permite ejecutar bases de datos de Oracle en hardware gestionado por Oracle en un centro de datos de Google Cloud .

Para crear instancias de infraestructura de Exadata, se usan Google Cloud interfaces como la Google Cloud consola, la CLI de Google Cloud y las APIs. Oracle configura y gestiona la infraestructura de computación, almacenamiento y redes necesaria en un centro de datos de una Google Cloud región en hardware dedicado a tu proyecto.

Para optimizar la latencia entre la aplicación y la base de datos, despliega la aplicación en la misma zona en la que crees las instancias de infraestructura de Exadata.
Instancia de infraestructura de Exadata La 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, están interconectados mediante una estructura de red de baja latencia. Cuando creas la instancia de infraestructura de Exadata, especificas el número de servidores de bases de datos y servidores de almacenamiento que se deben aprovisionar.
Clústeres de máquinas virtuales de Exadata

En la instancia de infraestructura de Exadata, se crea uno o varios clústeres de VM de Exadata. Por ejemplo, puede crear y usar un clúster de VM de Exadata independiente para alojar las bases de datos que necesite cada una de sus unidades de negocio. Cada clúster de VM de Exadata contiene una o varias VMs de Oracle Linux que alojan instancias de Oracle Database.

Cuando crea un clúster de VM de Exadata, debe especificar lo siguiente:

  • Número de servidores de bases de datos.
  • La capacidad de computación, memoria y almacenamiento que se asignará a cada VM del clúster.
  • La red de VPC a la que debe conectarse el clúster.
  • Los intervalos de direcciones IP de las subredes de copia de seguridad y de cliente del clúster.

Las VMs de los clústeres de VMs de Exadata no son VMs de Compute Engine.
Instancias de Oracle Database Puedes crear y gestionar instancias de Oracle Database a través de la consola de Oracle Cloud Infrastructure (OCI) y otras interfaces de OCI. El software de base de datos de Oracle se ejecuta en las máquinas virtuales del clúster de máquinas virtuales de Exadata. Cuando creas el clúster de VM de Exadata, especificas la versión de Oracle Grid Infrastructure y eliges el tipo de licencia. Puedes usar tus propias licencias (BYOL) o elegir el modelo con licencia incluida.
VCN de OCI y subredes Cuando crea un clúster de VM de Exadata, se crea automáticamente una red virtual en la nube (VCN) de OCI. La VCN tiene una subred de cliente y una subred de copia de seguridad con intervalos de direcciones IP que usted especifica. 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 a OCI Object Storage.
Cloud Router, Partner Interconnect, y OCI DRG Un Cloud Router enruta el tráfico entre tu red de VPC en Google Cloud y la VCN de OCI a través de una pasarela de enrutamiento dinámico (DRG) que está conectada a la VCN de OCI. El tráfico fluye a través de una conexión de baja latencia que Google configura con Partner Interconnect.
Zona de Cloud DNS privada 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 las bases de datos en las direcciones IP correspondientes.
OCI Object Storage y OCI Service Gateway 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 dirigen a OCI Object Storage a través de una Service Gateway.
Pasarela de Cloud NAT pública (opcional) La arquitectura incluye una pasarela de Cloud NAT pública opcional. La pasarela permite conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas.
Cloud Interconnect o Cloud VPN Para conectar tu red on-premise a la red de VPC de Google Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elegir un producto de conectividad de red.
Cloud Monitoring Puedes usar Cloud Monitoring para observar el comportamiento, el estado y el rendimiento de tu aplicación y tus Google Cloud recursos, incluido Oracle Exadata. También puede monitorizar los recursos de Oracle Exadata mediante el servicio de monitorización de OCI.

Productos usados

Esta arquitectura de referencia usa los siguientes Google Cloud productos:

  • Compute Engine: un servicio de computación seguro y personalizable con el que puedes crear y ejecutar máquinas virtuales en la infraestructura de Google.
  • Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
  • Google Cloud Armor: un servicio de seguridad de red que ofrece reglas de cortafuegos de aplicaciones web (WAF) y ayuda a protegerse frente a ataques DDoS y a aplicaciones.
  • Nube privada virtual (VPC): un sistema virtual que proporciona funciones de red globales y escalables para tus Google Cloud cargas de trabajo. VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso a servicios privados y la VPC compartida.
  • Cloud Interconnect: un servicio que amplía tu red externa a la red de Google a través de una conexión de alta disponibilidad y baja latencia.
  • Partner Interconnect: un servicio que proporciona conectividad entre tu red on-premise y tus redes de nube privada virtual, así como otras redes, a través de un proveedor de servicios compatible.
  • Cloud VPN: un servicio que amplía de forma segura tu red de emparejamiento a la red de Google a través de un túnel VPN IPsec.
  • Cloud NAT: un servicio que proporciona traducción de direcciones de red de alto rendimiento gestionada por Google Cloud.
  • Servicio de copia de seguridad y recuperación tras fallos: un servicio seguro de copia de seguridad y recuperación gestionado de forma centralizada para cargas de trabajo de Google Cloud que ayuda a proteger los datos de copia de seguridad frente a eliminaciones malintencionadas o accidentales.
  • Cloud DNS: un servicio que ofrece un servicio DNS resiliente y de baja latencia desde la red mundial de Google.

Esta arquitectura de referencia usa los siguientes productos de Oracle:

  • Oracle PeopleSoft: una suite de aplicaciones empresariales para la gestión del capital humano, soluciones para campus y planificación de recursos empresariales.
  • Exadata Database Service en infraestructura dedicada: un servicio que te permite ejecutar instancias de Oracle Database en hardware de Exadata dedicado.
  • VCN y subredes: una VCN es una red virtual y privada para los recursos de una región de OCI. Una subred es un intervalo contiguo de direcciones IP con una VCN.
  • Pasarela de enrutamiento dinámico: un router virtual para el tráfico entre una VCN y redes externas.
  • Almacenamiento de objetos: servicio para almacenar grandes cantidades de datos estructurados y sin estructurar como objetos.
  • Pasarela de servicio: una pasarela que permite que los recursos de una VCN accedan de forma privada a servicios específicos de Oracle.

Eres responsable de obtener las licencias de los productos de Oracle que implementes en Google Cloud, así como de cumplir los términos y condiciones de dichas licencias.

Factores 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 al usar esta arquitectura de referencia para desarrollar una topología que cumpla tus requisitos específicos de seguridad, fiabilidad, eficiencia operativa, coste y rendimiento. Cuando crees la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias del Google Cloud framework Well-Architected.

Google Cloud

Diseño de sistemas

En esta sección se ofrecen directrices para ayudarte a elegir las Google Cloud regiones de tu implementación y a seleccionar los Google Cloud servicios adecuados.

Selección de regiones

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

  • Disponibilidad de los servicios de Google Cloud en cada región. Para obtener más información, consulta Productos disponibles por ubicación.
  • Disponibilidad de los tipos de máquinas de Compute Engine en cada región. Para obtener más información, consulta el artículo Regiones y zonas.
  • Requisitos de latencia para los usuarios finales.
  • Coste de los Google Cloud recursos.
  • Costes de transferencia de datos entre regiones.
  • Requisitos normativos.

Algunos de estos factores y requisitos pueden implicar concesiones. Por ejemplo, la región más rentable puede no tener la huella de carbono más baja. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.

Migración de bases de datos

Cuando tengas previsto migrar bases de datos on-premise 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 artículo Oracle Migration Methods Advisor.

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

En el caso de las VMs de Compute Engine de la arquitectura, puedes usar volúmenes de arranque de Hyperdisk o de Persistent Disk. Los volúmenes de Hyperdisk ofrecen un mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Hyperdisk Balanced, puedes aprovisionar IOPS y capacidad de procesamiento por separado y de forma dinámica, lo que te permite ajustar el volumen a una gran variedad de cargas de trabajo.

Para almacenar archivos binarios de aplicaciones, usa Filestore. Los archivos que almacenes en una instancia regional de Filestore se replicarán de forma síncrona en tres zonas de la región. Esta replicación ayuda a asegurar una alta disponibilidad y una gran solidez frente a las interrupciones de zonas. Para aumentar la solidez frente a las interrupciones de la región, puedes replicar una instancia de Filestore en otra región. Para obtener más información, consulta Replicación de instancias.

Cuando diseñes el almacenamiento de tus cargas de trabajo, ten en cuenta las características funcionales de las cargas de trabajo, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costes. Para obtener más información, consulta el artículo Diseñar 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 los requisitos técnicos y empresariales. Por ejemplo, puedes usar una o varias redes de VPC. Para obtener más información, consulta Información sobre la selección de topologías de red para Oracle Database@Google Cloud.

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

Seguridad, privacidad y cumplimiento

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

Protección frente a amenazas externas

Para proteger tu aplicación frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las secuencias 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 especifica determinadas condiciones que se deben evaluar y las acciones que se deben llevar a cabo cuando se cumplan esas 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 intervalo CIDR específicos, se debe denegar el tráfico. También puede aplicar reglas de cortafuegos de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta el artículo Información general sobre la política de seguridad.

Acceso externo a 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 determinadas APIs y servicios de Google mediante Private Service Connect o Acceso privado de Google. Para obtener más información, consulta el artículo sobre las opciones de acceso privado a servicios.

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

En el caso de las subredes que usan las máquinas virtuales de Exadata, Oracle recomienda que asignes intervalos de direcciones IP privadas.

Privilegios de cuenta de servicio

En el caso de las máquinas virtuales de Compute Engine de la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio específicas y que indiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene una amplia gama de permisos, incluidos algunos que puede que no sean necesarios. Puedes adaptar las cuentas de servicio dedicadas para que solo tengan los permisos esenciales. Para obtener más información, consulta Limitar los privilegios de las cuentas de servicio.

Seguridad de SSH

Para mejorar la seguridad de las conexiones SSH a las VMs de Compute Engine de tu arquitectura, implementa Identity-Aware Proxy (IAP) y la API Cloud OS Login. IAP te permite controlar el acceso a la red en función de la identidad del usuario y las políticas de Gestión de Identidades y Accesos (IAM). La API Cloud OS Login te permite controlar el acceso SSH de Linux en función de la identidad del usuario y las políticas de gestión de identidades y accesos. Para obtener más información sobre cómo gestionar el acceso a la red, consulta las prácticas recomendadas para controlar el acceso de inicio de sesión SSH.

Encriptado de datos

De forma predeterminada, los datos almacenados en Hyperdisk, Persistent Disk y Filestore se encriptan medianteGoogle-owned and Google-managed encryption keys. Como medida de protección adicional, puedes cifrar los Google-owned and managed key con claves que poseas y gestiones en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta Acerca del cifrado de discos sobre los volúmenes de Hyperdisk y de disco persistente, y Cifrar datos con claves de cifrado gestionadas por el cliente sobre Filestore.

De forma predeterminada, las bases de datos de Exadata usan Transparent Data Encryption (TDE), que te permite cifrar los datos sensibles almacenados en tablas y espacios de tabla.

Seguridad de la red

Para controlar el tráfico de red entre los recursos de la arquitectura, debes configurar las políticas de cortafuegos de última generación (NGFW) de Cloud adecuadas.

En las VMs del servidor web, asegúrate de que el campo de origen de la política de entrada incluya lo siguiente:

Seguridad y cumplimiento de Oracle Exadata

Oracle Exadata Database Service incluye Oracle Data Safe, que te ayuda a gestionar los requisitos de seguridad y cumplimiento de las bases de datos de Oracle. Puede usar Oracle Data Safe para evaluar los controles de seguridad, monitorizar la actividad de los usuarios y enmascarar datos sensibles. Para obtener más información, consulta Gestionar la seguridad de la base de datos con Oracle Data Safe.

Más consideraciones sobre seguridad

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de plataforma que se proporcionan en el blueprint de bases empresariales y en el Google Cloud framework Well-Architected: seguridad, privacidad y cumplimiento.

Fiabilidad

En esta sección se describen los factores de diseño que debes tener en cuenta al usar esta arquitectura de referencia para crear y operar una infraestructura fiable para tu implementación enGoogle Cloud.

Robustez de la capa de aplicación frente a errores de máquinas virtuales

Si falla una de las dos VMs que alojan cada componente de Oracle PeopleSoft, la aplicación sigue estando disponible. Las solicitudes se dirigen a la otra máquina virtual.

A veces, una VM puede estar en ejecución y disponible, pero puede haber problemas con el propio componente Oracle PeopleSoft. Es posible que el componente se bloquee, falle o no tenga suficiente memoria. En estos casos, la VM no responderá a las comprobaciones de estado del balanceador de carga y este no dirigirá el tráfico a la VM que no responda.

Robustez frente a interrupciones de zonas o regiones

Si se produce una interrupción en una zona o región, la aplicación no estará disponible. Para reducir el tiempo de inactividad provocado por estas interrupciones, puedes implementar la siguiente estrategia:

  • Mantén una réplica pasiva (de conmutación por error) de la pila de aplicaciones en otraGoogle Cloud región o zona.
  • Crea una instancia de infraestructura de Exadata de reserva con los clústeres de VM de Exadata necesarios en la misma zona que tenga la réplica pasiva de la pila de aplicaciones. Usa Oracle Active Data Guard para replicar datos y conmutar por error automáticamente a las bases de datos Exadata de reserva. Si tu aplicación necesita un objetivo de punto de recuperación (RPO) más bajo, puedes crear copias de seguridad y recuperar las bases de datos mediante Oracle Autonomous Recovery Service.
  • Si se produce una interrupción en la región o zona principal, utiliza la réplica o la copia de seguridad de la base de datos para restaurarla en producción y activar la aplicación en la región o zona de conmutación por error.
  • Si la réplica pasiva está en otra región, usa las políticas de enrutamiento de Cloud DNS para enrutar el tráfico al balanceador de carga externo de esa región.

Para obtener más información, consulta Oracle Maximum Availability Architecture (MAA) para Oracle Database@Google Cloud.

Oracle gestiona la infraestructura de Oracle Database@Google Cloud. Para obtener información sobre los objetivos de nivel de servicio (SLOs) de Oracle Exadata Database Service en infraestructura dedicada, consulta Objetivos de nivel de servicio de los servicios de nube pública de PaaS e IaaS de Oracle.

Planificación de la capacidad de las VMs

Para asegurarte de que haya capacidad disponible para las VMs de Compute Engine cuando sea necesario aprovisionarlas, puedes crear reservas. Las reservas proporcionan capacidad asegurada en una zona específica para un número determinado de máquinas virtuales de un tipo de máquina que elijas. Una reserva puede ser específica de un proyecto o compartirse entre varios proyectos. Para obtener más información sobre las reservas, consulta Elegir un tipo de reserva.

Capacidad de Oracle Exadata

Puede escalar la infraestructura de Exadata añadiendo servidores de bases de datos y servidores de almacenamiento según sea necesario. Después de añadir los servidores de bases de datos o de almacenamiento necesarios a la infraestructura de Exadata, para poder usar los recursos adicionales de CPU o de almacenamiento, debe añadir la capacidad al clúster de VM de Exadata asociado. Para obtener más información, consulta Escalar el almacenamiento y los recursos de computación de Exadata.

Durabilidad de los datos

Puedes usar el servicio Backup y DR para crear, almacenar y gestionar copias de seguridad de máquinas virtuales de Compute Engine. Backup and DR almacena los datos de las copias de seguridad en su formato original legible por la aplicación. Cuando sea necesario, puedes restaurar cargas de trabajo en producción usando directamente los datos del almacenamiento de copias de seguridad a largo plazo sin tener que realizar actividades de preparación o transferencia de datos que requieren mucho tiempo. Para obtener más información, consulta el artículo sobre copias de seguridad y recuperación tras fallos de instancias de Compute Engine.

Para asegurar la durabilidad de los datos de tus instancias de Filestore, puedes crear copias de seguridad y capturas 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 de Oracle Exadata Database Service en infraestructura dedicada se almacenan en OCI Object Storage. Para conseguir un RPO más bajo, puedes crear copias de seguridad de las bases de datos y recuperarlas con Oracle Autonomous Recovery Service.

Más consideraciones sobre la fiabilidad

Cuando crees la arquitectura en la nube de tu carga de trabajo, consulta las prácticas recomendadas y las recomendaciones relacionadas con la fiabilidad que se proporcionan en la siguiente documentación:

Optimización de costes

En esta sección se ofrecen directrices para optimizar el coste de configurar y operar una Google Cloud topología que se cree con esta arquitectura de referencia.

Tipos de máquinas virtuales

Para ayudarte a optimizar el uso de los recursos de tus instancias de VM, Compute Engine ofrece recomendaciones sobre el tipo de máquina. Usa las recomendaciones para elegir los tipos de máquinas que se ajusten a los requisitos de computación de tu carga de trabajo. En el caso de las cargas de trabajo con requisitos de recursos predecibles, puedes personalizar el tipo de máquina según tus necesidades y ahorrar dinero usando tipos de máquinas personalizadas.

Licencias de productos de Oracle

Eres responsable de obtener las licencias de los productos de Oracle que implementes en Compute Engine, así como de cumplir 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 software de Oracle en el entorno de computación en la nube).

Licencias de bases de datos de Oracle Exadata

Cuando creas un clúster de VM de Exadata, puedes usar tu propia licencia (BYOL) o una que hayas comprado como parte de tu pedido de Google Cloud Marketplace de 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 encuentren en la misma región están incluidos en el precio de la oferta Oracle Database@Google Cloud.

Más consideraciones sobre los costes

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el Google Cloud framework Well-Architected: optimización de costes.

Eficiencia operativa

En esta sección se describen los factores que debes tener en cuenta al usar esta arquitectura de referencia para diseñar una topología que puedas gestionar de forma eficiente. Google Cloud

Imágenes de Oracle Linux

En el caso de tus máquinas virtuales, puedes usar imágenes de Oracle Linux disponibles en Compute Engine o importar imágenes de Oracle Linux que hayas creado y que mantengas. También puedes crear y usar imágenes de SO personalizadas que incluyan las configuraciones y el software que necesiten tus aplicaciones. Puedes 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, por lo que tus plantillas de instancia y tus secuencias de comandos pueden usar esa imagen sin que tengas que actualizar las referencias a una versión de imagen específica. Debe actualizar periódicamente sus imágenes personalizadas para incluir las actualizaciones y los parches de seguridad que proporcione el proveedor del SO.

Administración de bases de datos de Oracle Exadata

Oracle gestiona los servidores de bases de datos físicos, los servidores de almacenamiento y el hardware de redes en Oracle Exadata Database Service en infraestructura dedicada. Puede gestionar las instancias de infraestructura de Exadata y los clústeres de VM de Exadata a través de las interfaces de OCI o de Google Cloud . Puedes crear y gestionar bases de datos a través de las interfaces de OCI. Las páginas de la consola de Google Cloud Oracle Database en Google Cloud incluyen enlaces que puedes usar para ir directamente a las páginas correspondientes de la consola de OCI. Para no tener que volver a iniciar sesión en OCI, puedes configurar la federación de identidades entre OCI y Google Cloud.

Observabilidad de aplicaciones Oracle

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

Documentación y asistencia de Oracle

Los productos de Oracle que se ejecutan en máquinas virtuales de Compute Engine tienen problemas operativos similares a los productos de Oracle que se ejecutan en las instalaciones. Sin embargo, no tienes que gestionar la infraestructura subyacente de computación, redes y almacenamiento. Para obtener información sobre el funcionamiento y la gestión de los productos de Oracle, consulta la documentación correspondiente de Oracle.

Para obtener información sobre la política de asistencia de Oracle para las instancias de Oracle Database que despliegues en Google Cloud, consulta Oracle Database Support for Non-Oracle Public Cloud Environments (Doc ID 2688277.1).

Más consideraciones operativas

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas generales y las recomendaciones para mejorar la eficiencia operativa que se describen en el Google Cloud framework Well-Architected: excelencia operativa.

Optimización del rendimiento

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

Rendimiento de computación

Compute Engine ofrece una amplia gama 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 en función de tus requisitos de rendimiento. Para obtener más información, consulta la guía de comparación y recursos de las familias de máquinas.

Rendimiento de la red

Compute Engine tiene un límite por máquina virtual 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 VPC que la VM de origen. En las máquinas virtuales con determinados tipos de máquinas, puedes obtener un ancho de banda de salida máximo más alto si habilitas la red de nivel 1. Para obtener más información, consulta Configurar el rendimiento de la red de nivel 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 Interconnect de partner de baja latencia que configura Google.

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

Para optimizar la latencia entre la aplicación y la base de datos, despliegue la aplicación en la misma zona en la que cree la instancia de infraestructura de Exadata.

Más consideraciones sobre el rendimiento

Cuando diseñes la arquitectura de tu carga de trabajo, ten en cuenta las prácticas recomendadas y las sugerencias generales que se proporcionan en el artículo Google Cloud Well-Architected Framework: optimización del rendimiento.

Siguientes pasos

Colaboradores

Autor: Kumar Dhanagopal | Desarrollador de soluciones multiproducto

Otros colaboradores: