Aplicación empresarial en Compute Engine con Oracle Exadata

Last reviewed 2025-08-18 UTC

En este documento, se proporciona una arquitectura de referencia para una aplicación empresarial de alta disponibilidad alojada en máquinas virtuales (VMs) de Compute Engine con conectividad de baja latencia a las bases de datos de Oracle Cloud Infrastructure (OCI) Exadata que se ejecutan en Google Cloud. El público objetivo para este documento son los arquitectos de la nube y los administradores de bases de datos de Oracle. En el documento, se supone que estás familiarizado con Compute Engine y Oracle Exadata Database Service.

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

Si no necesitas la capacidad de Oracle RAC o si necesitas una versión de Oracle Database que no sea 19c ni 23ai, puedes ejecutar bases de datos de Oracle autoadministradas en VMs de Compute Engine. Para obtener más información, consulta Aplicación empresarial con Oracle Database en Compute Engine.

Arquitectura

En el siguiente diagrama, se muestra una vista de alto nivel de la arquitectura:

Una vista de alto nivel de una arquitectura que usa Oracle Database@Google Cloud.

En el diagrama anterior, un balanceador de cargas externo recibe solicitudes de los usuarios de una aplicación pública y las distribuye a los servidores web de frontend. Los servidores web reenvían las solicitudes de los usuarios a través de un balanceador de cargas interno a los servidores de aplicaciones. Los servidores de aplicaciones leen datos de las bases de datos en Oracle Database@Google Cloud y escriben en ellas. Los administradores y los servicios de OCI pueden conectarse a las bases de datos de Oracle y, luego, interactuar con ellas.

En el siguiente diagrama, se muestra una vista detallada de la arquitectura:

Una vista detallada de una arquitectura que usa Oracle Database@Google Cloud.

En esta arquitectura, el nivel web y el nivel de aplicación se ejecutan en modo activo-activo en VMs de Compute Engine que se distribuyen en dos zonas dentro de una Google Cloud región. La aplicación usa bases de datos de Oracle Exadata en la misma región Google Cloud.

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

La arquitectura que se muestra en el diagrama anterior incluye los siguientes componentes:

Componente Purpose
Balanceador de cargas de aplicaciones externo regional El balanceador de cargas de aplicaciones externo regional recibe solicitudes de los usuarios y las distribuye a las VMs de nivel web.
Política de seguridad de Google Cloud Armor La política de seguridad de Cloud Armor ayuda a proteger tu pila de aplicaciones contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencia de comandos entre sitios (XSS).
Grupo de instancias administrado (MIG) regional para el nivel web El nivel web de la aplicación se implementa en las VMs de Compute Engine que forman parte de un MIG regional. Este MIG es el backend del balanceador de cargas de aplicaciones externo. El MIG contiene VMs de Compute Engine en dos zonas. Cada una de estas VMs aloja una instancia independiente del nivel web de la aplicación.
Balanceador de cargas de aplicaciones interno regional El balanceador de cargas de aplicaciones interno regional distribuye el tráfico desde las VMs de nivel web hasta las VMs de nivel de aplicación.
MIG regional para el nivel de la aplicación El nivel de la aplicación, como un clúster de Oracle WebLogic Server, se implementa en las VMs de Compute Engine que forman parte de un MIG regional. Este MIG es el backend del balanceador de cargas de aplicaciones interno. El MIG contiene VMs de Compute Engine en dos zonas. Cada VM aloja una instancia independiente del servidor de aplicaciones.
Red de nube privada virtual (VPC) y subred Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC. Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
Oracle Database@Google Cloud

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

Usas Google Cloud interfaces como la Google Cloud consola, Google Cloud CLI y las APIs para crear instancias de infraestructura de Exadata. Oracle configura y administra la infraestructura de procesamiento, almacenamiento y redes necesaria en un centro de datos dentro de una región Google Cloud en hardware dedicado a tu proyecto.

Instancias de infraestructura de Exadata Cada instancia de Exadata Infrastructure 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 a través de una estructura de red de baja latencia. Cuando creas una instancia de infraestructura de Exadata, especificas la cantidad de servidores de bases de datos y servidores de almacenamiento que se deben aprovisionar.
Clústeres de VMs de Exadata

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

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

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

Las VMs dentro de los clústeres de VM de Exadata no son VMs de Compute Engine.

Instancias de Oracle Database Puedes crear y administrar bases de datos de Oracle a través de la consola de OCI y otras interfaces de OCI. El software de Oracle Database se ejecuta en las VMs dentro del clúster de VMs de Exadata. Cuando creas el clúster de VM de Exadata, especificas la versión de Oracle Grid Infrastructure. También puedes elegir el tipo de licencia: usar tus propias licencias (BYOL) o elegir el modelo con licencia incluida.
VCN de OCI y subredes Cuando creas un clúster de VM de Exadata, se crea automáticamente una red virtual en la nube (VCN) virtual de OCI. La VCN tiene una subred del cliente y una subred de copia de seguridad con rangos de direcciones IP que usted especifica. La subred del cliente se usa para la conectividad desde 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 DRG de OCI Un Cloud Router adjunto a la VPC y una puerta de enlace de enrutamiento dinámico (DRG) adjunta a la VCN enrutan el tráfico entre tu red de VPC y la VCN. El tráfico fluye a través de una conexión de baja latencia que Google configura con la interconexión de socio.
Zona privada de Cloud DNS Cuando creas un clúster de VM de Exadata, se crea automáticamente una zona privada de Cloud DNS. Cuando los servidores de aplicaciones envían solicitudes de lectura y escritura a las bases de datos de Oracle, Cloud DNS resuelve los nombres de host de la base de datos en las direcciones IP correspondientes.
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 enrutan a OCI Object Storage a través de una puerta de enlace de servicio.
Puerta de enlace de Cloud NAT pública La arquitectura incluye una puerta de enlace de Cloud NAT pública para habilitar conexiones salientes seguras desde las VMs de Compute Engine, que solo tienen direcciones IP internas.
Cloud Interconnect y Cloud VPN Para conectar tu red local a la red de VPC en Google Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elige 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 los recursos de Google Cloud , incluidos los recursos de Oracle Exadata. También puedes supervisar los recursos en los recursos de Oracle Exadata con el servicio de OCI Monitoring.

Productos usados

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

  • Compute Engine: Un servicio de procesamiento seguro y personalizable que te permite crear y ejecutar VMs en la infraestructura de Google.
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • 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.
  • 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.
  • Cloud NAT: Es un servicio que proporciona traducción de direcciones de red de alto rendimiento administrada por Google Cloud.
  • Cloud Monitoring: Un servicio que proporciona visibilidad del rendimiento, la disponibilidad y el estado de la infraestructura y las aplicaciones.
  • Cloud Interconnect: Es un servicio que extiende tu red externa a la red de Google a través de una conexión de latencia baja y alta disponibilidad.
  • Interconexión de socio: Es un servicio que proporciona conectividad entre tu red local y tus redes de nube privada virtual, y otras redes a través de un proveedor de servicios compatible.
  • Cloud VPN: Es un servicio que extiende de forma segura tu red de intercambio de tráfico a la red de Google a través de un túnel VPN con IPsec.

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

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

Consideraciones del diseño

En esta sección, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento.

La guía de esta sección no está completa. Según los requisitos específicos de tu aplicación y los productos y funciones de Google Cloud y de terceros que uses, es posible que debas considerar factores de diseño y compensaciones adicionales.

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.

Infraestructura de procesamiento

La arquitectura de referencia de este documento usa VMs de Compute Engine para ciertos niveles de la aplicación. Según los requisitos de tu aplicación, puedes elegir entre otros Google Cloud servicios de procesamiento:

  • Contenedores: Puedes ejecutar aplicaciones alojadas en contenedores en clústeres de Google Kubernetes Engine (GKE). GKE es un motor de organización de contenedores que automatiza la implementación, el escalamiento y la administración de aplicaciones en contenedores.
  • Sin servidores: Si prefieres enfocar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidores como Cloud Run.

La decisión de usar VMs, contenedores o servicios sin servidores implica un equilibrio entre la flexibilidad de la configuración y el esfuerzo de administración. Las VMs y los contenedores proporcionan más flexibilidad de configuración, pero eres responsable de administrar los recursos. En una arquitectura sin servidores, implementas las cargas de trabajo en una plataforma preconfigurada que requiere un esfuerzo de administración mínimo. Si quieres obtener más información para elegir los servicios de procesamiento adecuados para tus cargas de trabajo enGoogle Cloud, consulta Hosting Applications on Google Cloud.

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 de Oracle Database@Google Cloud

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

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

Migración de bases de datos

Cuando planees migrar bases de datos locales a Oracle Database@Google Cloud, evalúa tu entorno de bases 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 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.

Security, privacy, and compliance

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

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

Privilegios de la cuenta de servicio

Para las VMs de Compute Engine en la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio dedicadas y especifiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada tiene 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 datos

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

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

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.

Seguridad y cumplimiento de Oracle Exadata

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

Más consideraciones de seguridad

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de empresa y 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 esta arquitectura de referencia para compilar y operar una infraestructura confiable para tu implementación enGoogle Cloud.

Robustez ante fallas de VM

En la arquitectura que se muestra en este documento, si falla una VM de Compute Engine en el nivel web o de aplicación, el MIG correspondiente vuelve a crear la VM de forma automática. Los balanceadores de cargas reenvían las solicitudes solo a las instancias disponibles del servidor web y del servidor de aplicaciones.

Reparación automática de VMs

A veces, las VMs que alojan tu aplicación pueden estar en ejecución y disponibles, pero puede haber problemas con la aplicación. La aplicación puede congelarse, fallar o no tener suficiente memoria. Para verificar si una aplicación responde como se espera, puedes configurar las verificaciones de estado basadas en aplicaciones como parte de la política de reparación automática de los MIG. Si la aplicación en una VM en particular no responde, el MIG repara automáticamente (remedia) la VM. Para obtener más información sobre la configuración de la reparación automática, consulta Información sobre la reparación de VMs para alta disponibilidad.

Solidez ante interrupciones regionales

Si se produce una interrupción regional, la aplicación no estará disponible. Para reducir el tiempo de inactividad causado por las interrupciones regionales, puedes implementar el siguiente enfoque:

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

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

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

Ajuste de escala automático de MIG

La arquitectura de este documento usa MIG regionales para el nivel web y el nivel de aplicación. La capacidad de ajuste de escala automático de los MIG sin estado garantiza que las VMs de Compute Engine que alojan el nivel web y el nivel de aplicación no se vean afectadas por las interrupciones de una sola zona.

Para controlar el comportamiento del ajuste de escala automático de tus MIG sin estado, puedes especificar las métricas de uso objetivo, como el uso de CPU promedio. También puedes configurar el ajuste de escala automático basado en programas para MIG sin estado. Los MIG con estado no pueden realizar un ajuste de escala automático. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

Límite de tamaño del MIG

Cuando decidas el tamaño de tus MIG, considera los límites predeterminados y máximos en la cantidad de VMs que se pueden crear en un MIG. Para obtener más información, consulta Agrega y quita VMs en un MIG.

Ubicación de las VMs

En la arquitectura que se describe en este documento, el nivel de aplicación y el nivel web se ejecutan en las VMs de Compute Engine que se distribuyen en varias zonas. Esta distribución ayuda a garantizar que tu nivel web y tu nivel de aplicación sean sólidos contra las interrupciones de una sola zona.

Para mejorar la solidez de la arquitectura, puedes crear una política de posición de distribución y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las ubica dentro de cada zona en diferentes servidores físicos (llamados hosts), por lo que tus VMs son sólidas frente a fallas de hosts individuales. Para obtener más información, consulta Crea y aplica políticas de posición distribuida a las VMs.

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.

Almacenamiento con estado

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de discos locales con estado. Pero si el requisito existe, puedes configurar tus discos persistentes para que tengan estado para garantizar que los datos se conserven cuando las VMs se reparen o se vuelvan a crear. Sin embargo, te recomendamos que mantengas los discos de arranque sin estado para que puedas actualizarlos a las imágenes más recientes con versiones y parches de seguridad nuevos. Para obtener más información, consulta Configura discos persistentes con estado en MIG.

Capacidad de Oracle Exadata

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

Durabilidad de los datos

Puedes usar el servicio Backup and DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. 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 sin mucho tiempo de movimiento de datos o actividades de preparación. Para obtener más información, consulta Backup and DR para copias de seguridad de instancias de Compute Engine.

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

De forma predeterminada, las copias de seguridad de las bases de datos en Oracle Exadata Database Service on Dedicated Infrastructure se almacenan en OCI Object Storage. Para lograr 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 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 esta arquitectura de referencia.

Tipos de máquinas de VMs

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

Modelo de aprovisionamiento de VM

Si tu aplicación es tolerante a errores, las VMs Spot pueden ayudarte a reducir los costos de Compute Engine para las VMs en los niveles de aplicación y la Web. El costo de las VMs Spot es significativamente menor que las VMs normales. Sin embargo, Compute Engine podría detener o borrar las VMs Spot de forma preventiva para recuperar capacidad.

Las VMs Spot son adecuadas para trabajos por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs Spot ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos en una zona es limitada, es posible que los MIG no puedan escalar horizontalmente (es decir, crear VMs) de forma automática al tamaño objetivo especificado hasta que la capacidad requerida vuelva a estar disponible.

Uso de recursos de VMs

La capacidad de ajuste de escala automático de los MIG sin estado permite que tu aplicación maneje los aumentos de tráfico con facilidad y te ayuda a reducir los costos cuando la necesidad de recursos es baja. Los MIG con estado no pueden realizar un ajuste de escala automático.

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

Licencias de bases de datos de Oracle Exadata

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

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

Más consideraciones de los costos

Cuando compiles la arquitectura 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 esta arquitectura de referencia para diseñar una topología de Google Cloud que puedas operar de manera eficiente.

Actualizaciones de la configuración de VMs

Para actualizar la configuración de las VMs en un MIG (como el tipo de máquina o la imagen de disco de arranque), debes crear una plantilla de instancias nueva con la configuración necesaria y, luego, aplicar la plantilla nueva al MIG. El MIG actualiza las VMs a través del método de actualización que elijas: automático o selectivo. Elige un método adecuado en función de tus requisitos de disponibilidad y eficiencia operativa. Para obtener más información sobre estos métodos de actualización de MIG, consulta Aplica una configuración de VM nueva en un MIG.

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.

Plantillas de instancias deterministas

Si las plantillas de instancias que usas para tus MIG incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen de forma explícita parámetros de instalación de software, como la versión del software. De lo contrario, cuando el MIG crea las VMs, es posible que el software instalado en las VMs no sea coherente. Por ejemplo, si tu plantilla de instancias incluye una secuencia de comandos de inicio para instalar Apache HTTP Server 2.0 (el paquete apache2), asegúrate de que la secuencia de comandos especifique la versión apache2 exacta que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancias determinísticas.

Administración de bases de datos de Oracle Exadata

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

Observabilidad para aplicaciones de Oracle

Para implementar la observabilidad 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.

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. Para obtener orientación sobre el funcionamiento y la administración de los productos de Oracle, consulta la documentación pertinente de Oracle.

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

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 esta arquitectura de referencia para diseñar una topología en Google Cloud que cumpla con los requisitos de rendimiento de tus cargas de trabajo.

Rendimiento de procesamiento

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

Subprocesos múltiples de VMs

Cada CPU virtual que asignas a una VM de Compute Engine se implementa como un solo subproceso de hardware único. De forma predeterminada, dos CPU virtuales comparten un núcleo de CPU física. Para las aplicaciones que implican operaciones altamente paralelas o que realizan cálculos de punto flotante (como el análisis de secuencias genéticas y el modelado de riesgo financiero), puedes mejorar el rendimiento si reduces la cantidad de subprocesos que se ejecutan en cada CPU física. Para obtener más información, consulta Configura una cantidad de subprocesos por núcleo.

Los subprocesos múltiples de VM pueden tener implicaciones de licencias para algún software de terceros, como las bases de datos. Para obtener más información, lee la documentación sobre licencias del software de terceros.

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, puedes obtener un mayor ancho de banda de salida máximo si habilitas las redes de Tier_1. Para obtener más información, consulta Configura el rendimiento de red Tier_1 por VM.

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

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

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: