Oracle E-Business Suite con la base de datos de Oracle en Compute Engine

Last reviewed 2025-08-13 UTC

En este documento, se proporcionan arquitecturas de referencia para ayudarte a compilar la infraestructura que te permitirá ejecutar aplicaciones de Oracle E‑Business Suite con Oracle Database en VMs de Compute Engine en Google Cloud. Oracle E-Business Suite es un conjunto de aplicaciones empresariales para funciones comerciales, como finanzas, recursos humanos, cadena de suministro y relaciones 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 conoce la base de datos de Oracle y la arquitectura y la pila de tecnología de Oracle E-Business Suite.

Si necesitas usar Oracle Exadata o 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 Oracle E-Business Suite en Compute Engine con Oracle Exadata.

Arquitectura

Según tu caso de uso y los requisitos de disponibilidad y recuperación ante desastres (DR), 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 dentro de una sola zona de Google Cloud. Este arquetipo de implementación es adecuado para entornos de desarrollo y prueba, y para aplicaciones no críticas que no necesitan alta disponibilidad.
  • Regional: Tus aplicaciones se ejecutan de forma independiente en dos o más zonas dentro de una sola Google Cloud región. Recomendamos este arquetipo de implementación para aplicaciones que no son fundamentales, pero que necesitan solidez contra las interrupciones zonales.
  • Multirregional: Tus aplicaciones se ejecutan de forma independiente en varias zonas de dos o más Google Cloud regiones, ya sea en modo activo-activo o activo-pasivo. Este arquetipo de implementación es ideal para admitir situaciones de DR. Recomendamos este arquetipo para aplicaciones esenciales que necesitan resiliencia ante interrupciones y desastres regionales.

Elegir un arquetipo de implementación ayuda 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 las aplicaciones de Oracle E-Business Suite con Oracle Database que se ejecutan en una sola zona dentro de una región deGoogle Cloud . Esta arquitectura está alineada con el arquetipo de implementación zonal.

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

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
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 tus aplicaciones contra amenazas como los ataques de 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 VMs de Compute Engine. 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.

Tú proporcionas 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 zonal de Filestore contiene los datos y los archivos binarios de la aplicación. La instancia de Filestore se activa en las VMs de Compute Engine que alojan los componentes de la capa de aplicación.
Base de datos de Oracle (BYOL)

Las aplicaciones de Oracle E-Business Suite usan una instancia de Oracle Database implementada en una VM de Compute Engine. Los discos de arranque y de datos de la VM son volúmenes de Hyperdisk.

Tú proporcionas tu propia licencia (BYOL) para la instancia de Oracle Database y administras la VM y la base de datos.
Copias de seguridad de aplicaciones y bases de datos Las copias de seguridad de los datos de la aplicación y la base de datos se crean, almacenan y administran con el servicio de copia de seguridad y DR.
Red de nube privada virtual (VPC) y subredes

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

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Puerta de enlace NAT pública La arquitectura incluye una puerta de enlace pública de Cloud NAT 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 local a la red de VPC enGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige 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 independientes de Oracle E-Business Suite que se ejecutan en VMs de Compute Engine. Una de las capas de la aplicación es una zona desmilitarizada (DMZ), que atiende a los usuarios externos de las aplicaciones de Oracle E-Business Suite. La otra capa presta servicios a los usuarios internos. Ambas capas de la aplicación se ejecutan dentro de una sola zona en una región de Google Cloud y usan una sola instancia de Oracle Database. Al igual que la arquitectura de la sección anterior, esta arquitectura está alineada con el arquetipo de implementación zonal.

Una arquitectura para las 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 cargas de aplicaciones externo regional El balanceador de cargas externo recibe y distribuye solicitudes de usuarios externos a la capa de aplicación orientada al exterior.
Balanceador de cargas de aplicaciones interno regional El balanceador de cargas 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 contra amenazas externas, como ataques DSD 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. Cada VM aloja una instancia independiente de la capa de aplicación. Las aplicaciones internas y externas se publican desde conjuntos distintos de VMs. El disco de arranque de cada VM es un volumen de Hyperdisk.

Tú proporcionas 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 zonal de Filestore contiene los datos y los archivos binarios de la aplicación. La instancia de Filestore se activa en las VMs de Compute Engine que alojan los componentes de la capa de aplicación.
Base de datos de Oracle (BYOL)

Las aplicaciones de Oracle E-Business Suite usan una instancia de Oracle Database implementada en una VM de Compute Engine. Los discos de arranque y de datos de la VM son volúmenes de Hyperdisk.

Tú proporcionas tu propia licencia (BYOL) para la instancia de Oracle Database y administras la VM y la base de datos.
Copias de seguridad de aplicaciones y bases de datos Backup and DR crea, almacena y administra copias de seguridad de los datos de la aplicación y la base de datos.
Red de nube privada virtual (VPC) y subredes

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

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Puerta de enlace NAT pública La arquitectura incluye una puerta de enlace de 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 local a la red de VPC enGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Los administradores y los usuarios internos de la aplicación usan estas conexiones para acceder a los recursos y las aplicaciones, respectivamente. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige 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 VMs de Compute Engine que se distribuyen en dos zonas dentro de una región de Google Cloud . Ambas implementaciones de aplicaciones usan una instancia principal de Oracle Database que se ejecuta en una VM en una de las zonas. Oracle Data Guard administra la replicación y la conmutación por error de la base de datos a una instancia en espera de Oracle Database 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 dentro de una región de Google Cloud .

La arquitectura del diagrama anterior incluye los siguientes componentes:

Componente Descripción
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 Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tus aplicaciones contra amenazas como los ataques DSD distribuidos y XSS.
Oracle E-Business Suite (BYOL)

Los componentes de la capa de aplicación de Oracle E-Business Suite (servidor HTTP de Oracle, servidor Oracle WebLogic 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 VM es un volumen de Hyperdisk.

Tú proporcionas 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 datos y los archivos binarios de la aplicación. La instancia de Filestore está activada en todas las VMs de Compute Engine que alojan los componentes de la capa de aplicación en ambas zonas.
Base de datos de Oracle (BYOL)

Las aplicaciones de Oracle E-Business Suite usan un par principal-en espera de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas separadas. Los discos de arranque y de datos de la VM son volúmenes de Hyperdisk.

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

Tú aportas tus propias licencias (BYOL) para las instancias de Oracle Database y administras las VMs y las bases de datos.
Copias de seguridad de aplicaciones y bases de datos Backup and DR crea, almacena y administra copias de seguridad de los datos de la aplicación y la base de datos.
Red de nube privada virtual (VPC) y subredes

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

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Puerta de enlace NAT pública La arquitectura incluye una puerta de enlace de 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 local a la red de VPC enGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige un producto de Conectividad de red.

Arquitectura activa-pasiva multirregional (DR)

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 región de Google Cloud . Ambas implementaciones de aplicaciones usan una instancia principal de Oracle Database que se ejecuta en una VM en una de las zonas. Oracle Data Guard administra la replicación y la conmutación por error de la base de datos a una instancia en espera de Oracle Database 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 DR. Al igual que la arquitectura de la sección anterior, esta se basa en el arquetipo de implementación regional.

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

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 enruta las solicitudes de los usuarios al balanceador de cargas en la región que atiende las solicitudes.
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 Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tus aplicaciones contra amenazas como los ataques DSD 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 VM es un volumen de Hyperdisk.

Tú proporcionas 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 en la región principal contiene los datos y los archivos binarios 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 de la región principal. La instancia de Filestore se replica en la región de conmutación por error.
Base de datos de Oracle (BYOL)

Las aplicaciones de Oracle E-Business Suite usan un par principal y en espera de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas separadas de la región principal. Los discos de arranque y de datos de la VM son volúmenes de Hyperdisk.

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

Tú aportas tus propias licencias (BYOL) para las instancias de Oracle Database y administras las VMs y las bases de datos.
Copias de seguridad de aplicaciones y bases de datos Backup and DR crea, almacena y administra copias de seguridad de los datos de la aplicación y la base de datos.
Red de nube privada virtual (VPC) y subredes

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

Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Puerta de enlace NAT pública La arquitectura incluye una puerta de enlace de Cloud NAT pública en cada región para las 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 local a la red de VPC enGoogle Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige un producto de Conectividad de red.

Productos usados

Estas arquitecturas de referencia usan los siguientes productos de Google Cloud :

  • 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 de 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 completamente administrado y de alto rendimiento en Google Cloud al que puedes conectarte con diversos tipos de clientes.
  • Servicio de copia de seguridad y DR: 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 un servicio de DNS resistente y con baja latencia de la red mundial de Google.
  • 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 de 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 Interconnect: Es un servicio que extiende tu red externa a la red de Google a través de una conexión de latencia baja y alta disponibilidad.
  • 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.

En estas arquitecturas de referencia, se usan los siguientes productos de Oracle:

  • Oracle E-Business Suite: Es un conjunto de aplicaciones para operaciones comerciales, como finanzas, recursos humanos y cadena de suministro.
  • Base de datos de Oracle: Es un sistema de administración de bases de datos relacionales (RDBMS) que extiende el modelo relacional a un modelo relacional de objetos.
  • Oracle Data Guard: Es un conjunto de servicios para crear, mantener, administrar y supervisar una o más bases de datos en espera.

Eres responsable de obtener licencias para los productos de Oracle que implementes 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 estas arquitecturas de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento.

Diseño de sistemas

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

Selección de región

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 Regiones y zonas
  • Requisitos de latencia del usuario final
  • Costo de los Google Cloud recursos.
  • Costos de transferencia de datos interregionales
  • Requisitos reglamentarios

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 planees migrar implementaciones locales de Oracle Database 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

Para las VMs de Compute Engine en la arquitectura, puedes usar volúmenes de arranque de Hyperdisk o Persistent Disk. Los volúmenes de Hyperdisk proporcionan 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 para una amplia variedad de cargas de trabajo.

Para almacenar archivos binarios de la aplicación, 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 garantizar la solidez ante las interrupciones regionales, 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 para tus cargas de trabajo, considera las características funcionales de las cargas de trabajo, los requisitos de 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

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

Análisis de datos

Para obtener estadísticas avanzadas, 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 con Oracle E-Business Suite.

Security, privacy, and compliance

En esta sección, se describen los factores que debes tener en cuenta cuando usas estas arquitecturas de referencia para diseñar una topología en Google Cloud que cumpla con los requisitos de seguridad y cumplimiento de tus 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.

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 una amplia variedad de permisos, incluidos algunos que podrían no ser necesarios. Puedes personalizar las cuentas de servicio dedicadas para que solo tengan 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 la API de 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 Identity and Access Management (IAM). La API de Cloud OS Login te permite controlar el acceso SSH a Linux en función de la identidad del usuario y las políticas de IAM. Para obtener más información sobre cómo administrar el acceso a la red, consulta Prácticas recomendadas para controlar el acceso de SSH.

Encriptación de los discos

De forma predeterminada, los datos que se almacenan en volúmenes de Hyperdisk y en Filestore se encriptan conGoogle-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 volúmenes de Hyperdisk y Encripta datos con claves de encriptación administradas por el cliente para Filestore.

Seguridad de red

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

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 el Google Cloud Framework de Well-Architected: Seguridad, privacidad y cumplimiento.

Confiabilidad

En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas estas arquitecturas 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 la VM

Con todas las opciones de arquitectura que se describen en este documento, si fallan algunas (pero no todas) de las VMs de la aplicación, las aplicaciones seguirán 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 este caso, 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 de la base de datos ante fallas de la VM

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

Si la coherencia de los datos es una prioridad, configura una instancia de base de datos principal y una en espera, de preferencia en VMs que se encuentren en diferentes zonas, como se muestra en la arquitectura regional. Para la replicación y la conmutación por error en la instancia de la base de datos en espera, usa Data Guard. Data Guard ayuda a garantizar la coherencia replicando las transacciones en la instancia en espera antes de confirmarlas en la instancia principal. La arquitectura de base de datos principal y en espera implica costos 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 la base de datos de Oracle en espera. Durante el proceso de conmutación por error, las aplicaciones no pueden acceder a la base de datos.

Solidez ante interrupciones zonales

En una arquitectura zonal, si la zona que aloja tu implementación tiene una interrupción, las aplicaciones y la base de datos no estarán disponibles. Puedes restablecer las aplicaciones y la base de datos en producción en una zona o región diferente con las copias de seguridad almacenadas en Backup and DR.

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

Solidez ante interrupciones regionales

Si se produce una interrupción regional, las aplicaciones y la base de datos no estarán disponibles. Puedes restablecer las aplicaciones y la base de datos en producción en una región diferente con las copias de seguridad almacenadas en Backup and DR. Para reducir el tiempo de inactividad, usa la arquitectura multirregional activa-pasiva (DR). 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 cargas en la región de conmutación por error.

Para las aplicaciones fundamentales para la empresa que no pueden tolerar el tiempo de inactividad, incluso cuando se produce una interrupción regional, usa el arquetipo de implementación multirregional activo-activo.

Planificación de la capacidad de las VMs

Para asegurarte de que la capacidad de las VMs de Compute Engine esté disponible cuando se deban aprovisionar VMs, 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.

Durabilidad de los datos

Las arquitecturas de este documento usan Backup and DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. La copia de seguridad y la DR almacenan 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 y evitar la necesidad de preparar o mover datos.

Backup and DR admite dos métodos para crear copias de seguridad:

  • Almacenamiento de la bóveda de copias de seguridad: Los datos de la copia de seguridad se almacenan en la misma región que los datos de origen, y no se pueden cambiar ni borrar.
  • Almacenamiento autoadministrado: Los usuarios autorizados pueden modificar o borrar los datos de la copia de seguridad, y puedes almacenar datos en varias regiones.

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

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 a través de estas arquitecturas 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 software de Oracle en el entorno de computación en la nube).

Más consideraciones de los costos

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

Eficiencia operativa

En esta sección, se describen los factores que debes tener en cuenta cuando usas estas arquitecturas 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 compiles y mantengas. También puedes crear y usar imágenes personalizadas del SO que incluyan la configuración y el software que requieren 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 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. Debes actualizar tus imágenes personalizadas con regularidad para incluir las actualizaciones de seguridad y los parches que proporciona 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 de 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 de DNS en la dirección IP interna principal de la VM. Una ventaja adicional de este enfoque es que no necesitas reservar ni asignar direcciones IP internas estáticas para las VMs de la base de datos.

Documentación y asistencia de Oracle

Los productos de Oracle que se ejecutan en VMs de Compute Engine tienen preocupaciones operativas similares a los productos de Oracle que se ejecutan de forma local. Sin embargo, no es necesario que administres la infraestructura subyacente de procesamiento, redes y almacenamiento.

Observabilidad para aplicaciones de Oracle

Para implementar la observabilidad en 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 limitaciones. Por ejemplo, si ejecutas otras cargas de trabajo en Google Cloud además de las cargas de trabajo de Oracle, puedes usar los servicios de Google Cloud Observability para compilar un panel de operaciones unificado para todas las cargas de trabajo.

Más consideraciones operativas

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

Optimización del rendimiento

En esta sección, se describen los factores que debes tener en cuenta cuando usas estas arquitecturas 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 que puedes elegir según los requisitos de rendimiento de tus cargas de trabajo.

  • Para las VMs que alojan las aplicaciones y la base de datos, elige un tipo de máquina adecuado según tus requisitos de rendimiento. Para obtener una lista de los tipos de máquinas disponibles que admiten volúmenes de Hyperdisk y que cumplen con tus requisitos de rendimiento y otros, usa la tabla de comparación de series de máquinas.
  • Para la VM que aloja las instancias de Oracle Database, te recomendamos que uses un tipo de máquina de la serie de máquinas C4 de la familia de máquinas de uso general. Los tipos de máquinas C4 proporcionan un rendimiento alto y coherente para las cargas de trabajo de bases de datos.

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. En el caso de las VMs con ciertos tipos de máquinas, para mejorar el rendimiento de la red, puedes obtener un mayor ancho de banda de salida máximo si habilitas las redes de nivel 1. Para obtener más información, consulta Configura el rendimiento de red Tier_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 VMs y para los discos de datos de la VM de la base de datos. 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 Framework de Well-Architected: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: