Oracle E-Business Suite con Oracle Database en Compute Engine

Last reviewed 2025-08-13 UTC

En este documento se proporcionan arquitecturas de referencia para ayudarte a crear la infraestructura necesaria para ejecutar aplicaciones de Oracle E-Business Suite con Oracle Database en máquinas virtuales de Compute Engine en Google Cloud. Oracle E-Business Suite es un conjunto de aplicaciones empresariales para funciones empresariales como finanzas, recursos humanos, cadena de suministro y relaciones con los clientes.

Este documento está dirigido a arquitectos y administradores de bases de datos de Oracle y aplicaciones de Oracle E-Business Suite en la nube. En este documento se da por hecho que tu equipo está familiarizado con Oracle Database y con la pila tecnológica y la arquitectura de Oracle E-Business Suite.

Si necesitas usar Oracle Exadata u Oracle Real Application Clusters (Oracle RAC), puedes migrar tus aplicaciones a Google Cloud y ejecutar tus bases de datos en Oracle Database@Google Cloud. Para obtener más información, consulta el artículo Oracle E-Business Suite en Compute Engine con Oracle Exadata.

Arquitectura

En función de tu caso práctico y de los requisitos de disponibilidad y recuperación ante desastres, puedes elegir uno de los siguientes Google Cloud arquetipos de implementación para ejecutar aplicaciones de Oracle E-Business Suite en Google Cloud:

  • Zonal tus aplicaciones se ejecutan en una sola zona. Google Cloud Este arquetipo de implementación es adecuado para entornos de desarrollo y prueba, así como para aplicaciones no críticas que no necesitan una alta disponibilidad.
  • Regional: tus aplicaciones se ejecutan de forma independiente en dos o más zonas de una sola Google Cloud región. Recomendamos este arquetipo de implementación para aplicaciones que no sean críticas, pero que necesiten solidez frente a las interrupciones de zonas.
  • Multirregional: tus aplicaciones se ejecutan de forma independiente en varias zonas de dos o más regiones Google Cloud , ya sea en modo activo-activo o activo-pasivo. Este arquetipo de implementación es ideal para admitir escenarios de recuperación ante desastres. Recomendamos este arquetipo para aplicaciones esenciales que necesiten resiliencia ante interrupciones y desastres regionales.

Elegir un arquetipo de implementación te ayudará a simplificar las decisiones posteriores sobre los Google Cloud productos y las funciones que necesitas para tu arquitectura.

En las siguientes secciones se presentan cuatro opciones de arquitectura. Cada opción se basa en uno de los arquetipos de implementación:

Arquitectura zonal

En el siguiente diagrama se muestra una arquitectura para aplicaciones de Oracle E-Business Suite con Oracle Database ejecutándose en una sola zona de unaGoogle Cloud región. Esta arquitectura se ajusta al arquetipo de implementación zonal.

Una arquitectura para aplicaciones de Oracle E-Business Suite se ejecuta en una sola zona de una región Google Cloud .

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
Balanceador de carga de aplicación externo regional El balanceador de carga 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 tus aplicaciones frente a amenazas como los ataques DDoS y 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 máquinas virtuales de Compute Engine. Cada máquina virtual aloja una instancia independiente de la capa de aplicación. El disco de arranque de cada máquina virtual es un volumen de Hyperdisk de Google Cloud.

Tú proporcionas las licencias (BYOL) de Oracle E-Business Suite y gestionas las máquinas virtuales y las aplicaciones.
Binarios y datos de aplicaciones Una instancia zonal de Filestore contiene los archivos binarios y los datos de la aplicación. La instancia de Filestore se monta en las VMs de Compute Engine que alojan los componentes de la capa de aplicación.
Oracle Database (BYOL)

Las aplicaciones de Oracle E-Business Suite usan una instancia de Oracle Database que se implementa en una máquina virtual de Compute Engine. Los discos de arranque y de datos de la VM son volúmenes de hiperdisco.

Tú aportas tu propia licencia (BYOL) para la instancia de Oracle Database y gestionas la máquina virtual y la base de datos.
Copias de seguridad de aplicaciones y bases de datos El servicio de copia de seguridad y recuperación tras fallos crea, almacena y gestiona copias de seguridad de los datos de la aplicación y de la base de datos.
Red de nube privada virtual (VPC) y subredes

Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. Las VMs que alojan la capa de aplicación y la base de datos usan subredes independientes.

En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decidir si crear varias redes VPC.
Pasarela de NAT pública La arquitectura incluye una pasarela Cloud NAT pública para conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas. Por ejemplo, las VMs pueden acceder al servidor Oracle Linux Yum para descargar paquetes del SO.
Cloud Interconnect y Cloud VPN Para conectar tu red on-premise a la red de VPC deGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta el artículo Elegir un producto de conectividad de red.

Arquitectura zonal con una DMZ

En el siguiente diagrama se muestra una arquitectura con dos capas de aplicación de Oracle E-Business Suite independientes que se ejecutan en VMs de Compute Engine. Una de las capas de aplicación es una zona desmilitarizada (DMZ), que sirve a los usuarios externos de las aplicaciones de Oracle E-Business Suite. La otra capa está dirigida a los usuarios internos. Ambas capas de aplicación se ejecutan en una sola zona de una Google Cloud región y usan una sola instancia de Oracle Database. Al igual que la arquitectura de la sección anterior, esta arquitectura se ajusta al arquetipo de implementación zonal.

Una arquitectura para aplicaciones de Oracle E-Business Suite se ejecuta en una sola zona con una DMZ dentro de una región Google Cloud .

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
Balanceador de carga de aplicación externo regional El balanceador de carga externo recibe y distribuye las solicitudes de usuarios externos a la capa de aplicación orientada al exterior.
Balanceador de carga de aplicación interno regional El balanceador de carga interno recibe y distribuye solicitudes de usuarios internos a una capa de aplicación interna.
Política de seguridad de Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tus aplicaciones frente a amenazas externas, como ataques DDoS y 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 máquinas virtuales de Compute Engine. Cada máquina virtual aloja una instancia independiente de la capa de aplicación. Las aplicaciones internas y externas se sirven desde conjuntos distintos de máquinas virtuales. El disco de arranque de cada máquina virtual es un volumen Hyperdisk.

Tú proporcionas las licencias (BYOL) de Oracle E-Business Suite y gestionas las máquinas virtuales y las aplicaciones.
Binarios y datos de aplicaciones Una instancia zonal de Filestore contiene los archivos binarios y los datos de la aplicación. La instancia de Filestore se monta en las VMs de Compute Engine que alojan los componentes de la capa de aplicación.
Oracle Database (BYOL)

Las aplicaciones de Oracle E-Business Suite usan una instancia de Oracle Database que se implementa en una máquina virtual de Compute Engine. Los discos de arranque y de datos de la VM son volúmenes de hiperdisco.

Tú aportas tu propia licencia (BYOL) para la instancia de Oracle Database y gestionas la máquina virtual y la base de datos.
Copias de seguridad de aplicaciones y bases de datos Copia de seguridad y recuperación tras fallos crea, almacena y gestiona copias de seguridad de los datos de la aplicación y de la base de datos.
Red de nube privada virtual (VPC) y subredes

Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. Las VMs que alojan la capa de aplicación y la base de datos usan subredes independientes.

En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decidir si crear varias redes VPC.
Pasarela de NAT pública La arquitectura incluye una pasarela Cloud NAT pública para establecer conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas. Por ejemplo, las VMs pueden acceder al servidor Oracle Linux Yum para descargar paquetes del SO.
Cloud Interconnect y Cloud VPN Para conectar tu red on-premise a la red de VPC deGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Los administradores y los usuarios de aplicaciones internas usan estas conexiones para acceder a los recursos y las aplicaciones, respectivamente. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elegir un producto de conectividad de red.

Arquitectura regional

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 máquinas virtuales de Compute Engine que se distribuyen en dos zonas de una Google Cloud región. Ambas implementaciones de aplicaciones usan una instancia principal de Oracle Database que se ejecuta en una VM de una de las zonas. Oracle Data Guard gestiona la replicación y la conmutación por error de la base de datos a una instancia de Oracle Database en espera en la segunda zona. Esta arquitectura se basa en el arquetipo de implementación regional.

Una arquitectura para las aplicaciones de Oracle E-Business Suite se ejecuta en dos zonas de una región Google Cloud .

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
Balanceador de carga de aplicación externo regional El balanceador de carga recibe y distribuye las solicitudes de los usuarios a las aplicaciones de Oracle E-Business Suite.
Política de seguridad de Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tus aplicaciones frente a amenazas como los ataques DDoS distribuidos y 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. Cada VM aloja una instancia independiente de la capa de aplicación. El disco de arranque de cada máquina virtual es un volumen Hyperdisk.

Tú proporcionas las licencias (BYOL) de Oracle E-Business Suite y gestionas las máquinas virtuales y las aplicaciones.
Binarios y datos de aplicaciones Una instancia regional de Filestore contiene los archivos binarios y los datos de la aplicación. La instancia de Filestore se monta en todas las VMs de Compute Engine que alojan los componentes de la capa de aplicación en ambas zonas.
Oracle Database (BYOL)

Las aplicaciones de Oracle E-Business Suite usan un par principal-de reserva de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas independientes. Los discos de arranque y de datos de la máquina virtual son volúmenes de hiperdisco.

Oracle Data Guard gestiona la replicación y la conmutación por error de la base de datos de la instancia principal a la de espera.

Tú aportas tus propias licencias (BYOL) para las instancias de Oracle Database y gestionas las máquinas virtuales y las bases de datos.
Copias de seguridad de aplicaciones y bases de datos Copia de seguridad y recuperación tras fallos crea, almacena y gestiona copias de seguridad de los datos de la aplicación y de la base de datos.
Red de nube privada virtual (VPC) y subredes

Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. Las VMs que alojan la capa de aplicación y la base de datos usan subredes independientes.

En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decidir si crear varias redes VPC.
Pasarela de NAT pública La arquitectura incluye una pasarela Cloud NAT pública para establecer conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas. Por ejemplo, las VMs pueden acceder al servidor Oracle Linux Yum para descargar paquetes del SO.
Cloud Interconnect y Cloud VPN Para conectar tu red on-premise a la red de VPC deGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta el artículo Elegir un producto de conectividad de red.

Arquitectura multirregional activa-pasiva (recuperación tras fallos)

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 máquinas virtuales de Compute Engine que se distribuyen en dos zonas de una Google Cloud región. Ambas implementaciones de aplicaciones usan una instancia principal de Oracle Database que se ejecuta en una VM de una de las zonas. Oracle Data Guard gestiona la replicación y la conmutación por error de la base de datos a una instancia de Oracle Database en espera en la segunda zona. La arquitectura incluye una réplica a menor escala de la pila de aplicaciones en una región remota (de conmutación por error) para la recuperación tras desastres. Al igual que la arquitectura de la sección anterior, esta arquitectura se basa en el arquetipo de implementación regional.

Una arquitectura para aplicaciones de Oracle E-Business Suite se ejecuta en dos zonas de una región Google Cloud , con una réplica en una región remota para recuperación ante desastres.

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
Política de enrutamiento de conmutación por error de DNS Una zona pública de Cloud DNS configurada con una política de enrutamiento de conmutación por error dirige las solicitudes de los usuarios al balanceador de carga de la región que está atendiendo las solicitudes.
Balanceador de carga de aplicación externo regional El balanceador de carga recibe y distribuye las solicitudes de los usuarios a las aplicaciones de Oracle E-Business Suite.
Política de seguridad de Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tus aplicaciones frente a amenazas como los ataques DDoS distribuidos y 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 máquina virtual es un volumen de Hyperdisk.

Tú proporcionas las licencias (BYOL) de Oracle E-Business Suite y gestionas las máquinas virtuales y las aplicaciones.
Binarios y datos de aplicaciones

Una instancia regional de Filestore en la región principal contiene los archivos binarios y los datos de la aplicación. La instancia de Filestore se monta en todas las VMs de Compute Engine que alojan los componentes de la capa de aplicación en ambas zonas de la región principal. La instancia de Filestore se replica en la región de conmutación por error.
Oracle Database (BYOL)

Las aplicaciones de Oracle E-Business Suite usan un par principal-standby de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas independientes de la región principal. Los discos de arranque y de datos de la máquina virtual son volúmenes de hiperdisco.

Oracle Data Guard gestiona la replicación y la conmutación por error de la base de datos de la instancia principal a la de espera.

Tú aportas tus propias licencias (BYOL) para las instancias de Oracle Database y gestionas las máquinas virtuales y las bases de datos.
Copias de seguridad de aplicaciones y bases de datos Copia de seguridad y recuperación tras fallos crea, almacena y gestiona copias de seguridad de los datos de la aplicación y de la base de datos.
Red de nube privada virtual (VPC) y subredes

Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. Las máquinas virtuales que alojan la capa de aplicación y la base de datos usan subredes regionales independientes.

En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decidir si crear varias redes VPC.
Pasarela de NAT pública La arquitectura incluye una pasarela Cloud NAT pública en cada región para establecer conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas. Por ejemplo, las VMs pueden acceder al servidor Oracle Linux Yum para descargar paquetes del SO.
Cloud Interconnect y Cloud VPN Para conectar tu red on-premise a la red de VPC deGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta el artículo Elegir un producto de conectividad de red.

Productos usados

Estas arquitecturas de referencia usan los siguientes productos: Google Cloud

  • 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.
  • Google Cloud Hyperdisk: un servicio de almacenamiento en red que puedes usar para aprovisionar y escalar dinámicamente volúmenes de almacenamiento en bloques con un rendimiento configurable y predecible.
  • Filestore: un servicio que proporciona almacenamiento de archivos de alto rendimiento y totalmente gestionado en Google Cloud al que puedes conectar varios tipos de clientes.
  • 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.
  • 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 NAT: un servicio que proporciona traducción de direcciones de red de alto rendimiento gestionada por Google Cloud.
  • 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.
  • 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.

Estas arquitecturas de referencia usan los siguientes productos de Oracle:

  • Oracle E-Business Suite: un conjunto de aplicaciones para operaciones empresariales como finanzas, recursos humanos y cadena de suministro.
  • Oracle Database: un sistema de gestión de bases de datos relacionales (RDBMS) que amplía el modelo relacional a un modelo relacional de objetos.
  • Oracle Data Guard: un conjunto de servicios para crear, mantener, gestionar y monitorizar una o varias bases de datos de espera.

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 debe tener en cuenta al usar estas arquitecturas de referencia para desarrollar una topología que cumpla sus requisitos específicos de seguridad, fiabilidad, eficiencia operativa, coste y rendimiento.

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 implementaciones de Oracle Database on-premise aGoogle 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 migrar datos locales a implementaciones de bases de datos de Oracle enGoogle Cloud, puedes usar herramientas estándar de Oracle, como Oracle GoldenGate.

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 redes

Elige un diseño de red que cumpla los requisitos técnicos y empresariales. Puedes usar una o varias redes de VPC. Para obtener más información, consulta la siguiente documentación:

Analíticas de datos

Para hacer analíticas avanzadas, puedes usar Google Cloud Cortex Framework para ingerir datos de tus aplicaciones de Oracle E-Business Suite en BigQuery. Para obtener más información, consulta Cortex Framework: integración con Oracle E-Business Suite.

Seguridad, privacidad y cumplimiento

En esta sección se describen los factores que debes tener en cuenta al usar estas arquitecturas 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 puede 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.

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.

Cifrado del disco

De forma predeterminada, los datos almacenados en volúmenes de Hyperdisk y en 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 en el caso de los volúmenes de Hyperdisk y Cifrar datos con claves de cifrado gestionadas por el cliente en el caso de Filestore.

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.

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 estas arquitecturas de referencia para crear y operar una infraestructura fiable para tu implementación en Google Cloud.

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

Con todas las opciones de arquitectura de este documento, si fallan algunas (pero no todas) de las VMs de la aplicación, las aplicaciones seguirán estando disponibles porque el balanceador de carga 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 en sí. Es posible que la aplicación se bloquee, falle o no tenga suficiente memoria. En este caso, la VM no responderá a las comprobaciones del estado del balanceador de carga y este no dirigirá el tráfico a la VM que no responda.

Robustez de la base de datos frente a fallos de la VM

En una arquitectura zonal, si falla la VM de la base de datos, puedes restaurar la base de datos en producción en una nueva VM mediante las copias de seguridad almacenadas en Backup and DR. Después de restaurar la base de datos, debes conectar las aplicaciones a la nueva instancia de base de datos.

Si la coherencia de los datos es una prioridad, configura una instancia de base de datos principal y otra de reserva, preferiblemente en máquinas virtuales que estén en zonas diferentes, tal como se muestra en la arquitectura regional. Para la replicación y la conmutación por error a la instancia de base de datos de espera, usa Data Guard. Data Guard ayuda a garantizar la coherencia replicando las transacciones en la instancia de espera antes de confirmarlas en la instancia principal. La arquitectura de base de datos principal-de reserva implica costes adicionales de infraestructura y licencias.

En una arquitectura regional o multirregional, si falla la VM que aloja la base de datos principal, Oracle Data Guard inicia una conmutación por error a la instancia de base de datos de Oracle de espera. Durante el proceso de conmutación por error, las aplicaciones no pueden acceder a la base de datos.

Robustez frente a interrupciones de zonas

En una arquitectura por zonas, si la zona que aloja tu implementación sufre una interrupción, las aplicaciones y la base de datos dejarán de funcionar. Puedes restaurar las aplicaciones y la base de datos en producción en otra zona u otra región mediante las copias de seguridad almacenadas en Backup and DR.

En una arquitectura regional, si una de las zonas sufre una interrupción, el balanceador de carga 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 asegurar la alta disponibilidad de los datos en los volúmenes de Hyperdisk durante una interrupción de una sola zona, puedes usar Hyperdisk Balanced High Availability. Cuando se escriben datos en un volumen de Hyperdisk Balanced High Availability, los datos se replican de forma síncrona entre dos zonas de la misma región.

Robustez frente a interrupciones de la región

Si se produce una interrupción en una región, las aplicaciones y la base de datos no estarán disponibles. Puedes restaurar las aplicaciones y la base de datos en producción en otra región mediante las copias de seguridad almacenadas en Backup and DR. Para reducir el tiempo de inactividad, usa la arquitectura activa-pasiva multirregional (recuperación tras desastres). Después de iniciar las aplicaciones y la base de datos, debes actualizar la política de enrutamiento de DNS para enrutar el tráfico al balanceador de carga de la región de failover.

En el caso de las aplicaciones esenciales para la empresa que no pueden tolerar periodos de inactividad, ni siquiera cuando se produce una interrupción del servicio en una región, usa el arquetipo de implementación activa-activa multirregional.

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.

Durabilidad de los datos

Las arquitecturas de este documento usan Backup and DR para crear, almacenar y gestionar copias de seguridad de máquinas virtuales de Compute Engine. Copia de seguridad y recuperación tras fallos 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 preparar ni mover datos.

El servicio de copias de seguridad y recuperación ante desastres admite dos métodos para crear copias de seguridad:

  • Almacenamiento en el archivo de copias de seguridad: los datos de las copias de seguridad se almacenan en la misma región que los datos de origen y no se pueden cambiar ni eliminar.
  • Almacenamiento autogestionado: los usuarios autorizados pueden modificar o eliminar los datos de copia de seguridad, y puedes almacenar datos en varias regiones.

Para obtener más información, consulta la siguiente documentación:

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 topología de Google Cloud que se crea con estas arquitecturas 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).

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 estas arquitecturas 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.

Conectividad del servidor de aplicaciones a la base de datos

Para las conexiones de tus aplicaciones a Oracle Database, te recomendamos que uses el nombre DNS interno zonal de la VM de la base de datos en lugar de su dirección IP. Google Cloud resuelve automáticamente el nombre DNS en la dirección IP interna principal de la VM. Otra ventaja de este enfoque es que no es necesario reservar ni asignar direcciones IP internas estáticas a las VMs de la base de datos.

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.

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.

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 estas arquitecturas 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 que puedes elegir en función de los requisitos de rendimiento de tus cargas de trabajo.

  • En el caso de las máquinas virtuales que alojan las aplicaciones y la base de datos, elige un tipo de máquina adecuado en función de tus requisitos de rendimiento. Para obtener una lista de los tipos de máquinas disponibles que admiten volúmenes de Hyperdisk y que cumplen tus requisitos de rendimiento y otros, consulta la tabla Comparación de series de máquinas.
  • En el caso de la máquina virtual que aloja las instancias de Oracle Database, te recomendamos que uses un tipo de máquina de la serie C4 de la familia de máquinas de uso general. Los tipos de máquina C4 proporcionan un rendimiento alto y constante para las cargas de trabajo de bases de datos.

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 VMs con determinados tipos de máquinas, puedes habilitar redes Tier_1 para mejorar el rendimiento de la red y obtener un ancho de banda de salida máximo más alto. Para obtener más información, consulta Configurar el rendimiento de la red de nivel 1 por VM.

Rendimiento del almacenamiento de Hyperdisk

Las arquitecturas que se describen en este documento usan volúmenes de Hyperdisk para todos los discos de arranque de las máquinas virtuales y para los discos de datos de la máquina virtual de la base de datos. Hyperdisk te permite escalar el rendimiento y la capacidad de forma dinámica. Puedes ajustar las IOPS aprovisionadas, el rendimiento y el tamaño de cada volumen para que se adapten a 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 la optimización de Hyperdisk, consulta la siguiente documentación:

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

Autores:

Otros colaboradores: