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 una conectividad de baja latencia a las bases de datos Exadata de Oracle Cloud Infrastructure (OCI) que se ejecutan en Google Cloud. Este documento está dirigido a arquitectos de nube y administradores de bases de datos de Oracle. En este documento se da por hecho que conoces Compute Engine y Oracle Exadata Database Service.

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

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

Arquitectura

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

Vista general de una arquitectura que usa Oracle Database@Google Cloud.

En el diagrama anterior, un balanceador de carga 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 carga interno a los servidores de aplicaciones. Los servidores de aplicaciones leen datos de las bases de datos de Oracle Database@Google Cloud y escriben en ellas. Los administradores y los servicios de OCI pueden conectarse e interactuar con las bases de datos de Oracle.

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

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

En esta arquitectura, los niveles web y de aplicación se ejecutan en modo activo-activo en VMs de Compute Engine que se distribuyen en dos zonas 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 están en una sola región Google Cloud. Esta arquitectura se ajusta al arquetipo de implementación regional. Puedes adaptar esta arquitectura para crear una topología que sea resistente a las interrupciones regionales mediante el arquetipo de implementación multirregional. Para obtener más información, consulta el artículo Implementación multirregional en Compute Engine y las directrices de la sección Fiabilidad más adelante en este documento.

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

Componente Purpose
Balanceador de carga de aplicación externo regional El balanceador de carga de aplicaciones externo regional recibe las solicitudes de los usuarios y las distribuye a las VMs de la capa web.
Política de seguridad de Google Cloud Armor La política de seguridad de Cloud Armor te ayuda a proteger tu pila de aplicaciones frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las vulnerabilidades de tipo cross-site scripting (XSS).
Grupo de instancias gestionado (MIG) regional para el nivel web El nivel web de la aplicación se despliega en máquinas virtuales de Compute Engine que forman parte de un MIG regional. Este MIG es el backend del balanceador de carga de aplicación externo. El MIG contiene máquinas virtuales de Compute Engine en dos zonas. Cada una de estas máquinas virtuales aloja una instancia independiente de la capa web de la aplicación.
Balanceador de carga de aplicación interno regional El balanceador de carga de aplicaciones interno regional distribuye el tráfico de las VMs de la capa web a las VMs de la capa de aplicación.
MIG regional para el nivel de aplicación El nivel de aplicación, como un clúster de Oracle WebLogic Server, se despliega en máquinas virtuales de Compute Engine que forman parte de un MIG regional. Este MIG es el backend del balanceador de carga de aplicaciones interno. El MIG contiene máquinas virtuales de Compute Engine en dos zonas. Cada máquina virtual aloja una instancia independiente del servidor de aplicaciones.
Red de nube privada virtual (VPC) y subred Todos los Google Cloud recursos de la arquitectura usan una única red de VPC. En función de tus requisitos, puedes crear una arquitectura que utilice varias redes. Para obtener más información, consulta Decidir si se deben crear varias redes de VPC.
Oracle Database@Google Cloud

Los servidores de aplicaciones leen y escriben datos en bases de datos de Oracle en Oracle Exadata Database Service. Para aprovisionar Oracle Exadata Database Service, usa Oracle Database@Google Cloud, una oferta de Cloud Marketplace que te permite ejecutar bases de datos de Oracle en hardware gestionado por Oracle en un centro de datos. Google Cloud

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

Instancias de Exadata Infrastructure Cada instancia de infraestructura de Exadata contiene dos o más servidores de bases de datos físicos y tres o más servidores de almacenamiento. Estos servidores, que no se muestran en el diagrama, están interconectados mediante una estructura de red de baja latencia. Cuando creas una instancia de infraestructura de Exadata, especificas el número de servidores de bases de datos y servidores de almacenamiento que se deben aprovisionar.
Clústeres de VM de Exadata

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

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

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

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

Instancias de Oracle Database Puedes crear y gestionar 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 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 crea un clúster de VM de Exadata, se crea automáticamente una red virtual en la nube (VCN) de OCI. La VCN tiene una subred de cliente y una subred de backup con los intervalos de direcciones IP que especifiques. La subred de cliente se usa para la conectividad de tu red de VPC a las bases de datos de Oracle. La subred de copia de seguridad se usa para enviar copias de seguridad de la base de datos a OCI Object Storage.
Cloud Router, Partner Interconnect y DRG de OCI El tráfico entre tu red de VPC y la VCN se enruta mediante un router de Cloud Router conectado a la VPC y a través de una pasarela de enrutamiento dinámico (DRG) conectada a la VCN. El tráfico fluye a través de una conexión de baja latencia que Google configura mediante Partner Interconnect.
Zona de Cloud DNS privada Cuando creas un clúster de VMs de Exadata, se crea automáticamente una zona privada de Cloud DNS. Cuando 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.
Object Storage de OCI y Service Gateway de OCI De forma predeterminada, las copias de seguridad de las bases de datos de Oracle Exadata se almacenan en OCI Object Storage. Las copias de seguridad de la base de datos se dirigen a OCI Object Storage a través de una Service Gateway.
Pasarela de Cloud NAT pública La arquitectura incluye una pasarela 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 on-premise a la red de VPC de Google Cloud, puedes usar Cloud Interconnect o Cloud VPN. Para obtener información sobre las ventajas relativas de cada enfoque, consulta Elegir un producto de conectividad de red.
Cloud Monitoring Puede usar Cloud Monitoring para observar el comportamiento, el estado y el rendimiento de su aplicación y sus Google Cloud recursos, incluido Oracle Exadata. También puede monitorizar los recursos de Oracle Exadata mediante el servicio OCI Monitoring.

Productos usados

Esta arquitectura de referencia usa los siguientes Google Cloud productos:

  • Compute Engine: un servicio de computación seguro y personalizable con el que puedes crear y ejecutar máquinas virtuales en la infraestructura de Google.
  • Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
  • 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.
  • 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.
  • Cloud NAT: un servicio que proporciona traducción de direcciones de red de alto rendimiento gestionada por Google Cloud.
  • Cloud Monitoring: un servicio que ofrece visibilidad sobre el rendimiento, la disponibilidad y el estado de tus aplicaciones e infraestructura.
  • Cloud Interconnect: un servicio que amplía tu red externa a la red de Google a través de una conexión de alta disponibilidad y baja latencia.
  • Partner Interconnect: un servicio que proporciona conectividad entre tu red on-premise y tus redes de nube privada virtual, así como otras redes, a través de un proveedor de servicios compatible.
  • Cloud VPN: un servicio que amplía de forma segura tu red de emparejamiento a la red de Google a través de un túnel VPN IPsec.

Esta arquitectura de referencia usa los siguientes productos de OCI:

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

Factores del diseño

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

Las directrices de esta sección no son exhaustivas. En función de los requisitos específicos de tu aplicación y de los productos y funciones de terceros que utilices, puede que haya otros factores de diseño y compensaciones que debas tener en cuenta. 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.

Infraestructura informática

La arquitectura de referencia de este documento usa máquinas virtuales de Compute Engine para determinados niveles de la aplicación. En función de los requisitos de tu aplicación, puedes elegir entre otros Google Cloud servicios de computación:

  • Contenedores: puedes ejecutar aplicaciones en contenedores en clústeres de Google Kubernetes Engine (GKE). GKE es un motor de orquestación de contenedores que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores.
  • Sin servidor: si prefieres centrar tus esfuerzos de TI en los datos y las aplicaciones en lugar de configurar y operar recursos de infraestructura, puedes usar servicios sin servidor, como Cloud Run.

Para decidir si usar máquinas virtuales, contenedores o servicios sin servidor, debes encontrar el equilibrio entre la flexibilidad de la configuración y el esfuerzo de gestión. Las máquinas virtuales y los contenedores ofrecen más flexibilidad de configuración, pero tú eres el responsable de gestionar los recursos. En una arquitectura sin servidor, las cargas de trabajo se despliegan en una plataforma preconfigurada que requiere un esfuerzo de gestión mínimo. Para obtener más información sobre cómo elegir los servicios de computación adecuados para tus cargas de trabajo enGoogle Cloud, consulta Alojar aplicaciones en Google Cloud.

Opciones de almacenamiento

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

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

Cuando diseñes el almacenamiento de tus cargas de trabajo, ten en cuenta las características funcionales de las cargas de trabajo, los requisitos de resiliencia, las expectativas de rendimiento y los objetivos de costes. Para obtener más información, consulta el artículo Diseñar una estrategia de almacenamiento óptima para tu carga de trabajo en la nube.

Diseño de red de Oracle Database@Google Cloud

Elige un diseño de red que cumpla los requisitos técnicos y empresariales. Por ejemplo, puedes usar una o varias redes de VPC. Para obtener más información, consulta Información sobre la selección de topologías de red para Oracle Database@Google Cloud.

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

Migración de bases de datos

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

Para obtener información sobre el procedimiento y las herramientas que puedes usar para migrar bases de datos de Oracle a Google Cloud, consulta el artículo Oracle Migration Methods Advisor.

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

Seguridad, privacidad y cumplimiento

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

Protección frente a amenazas externas

Para proteger tu aplicación frente a amenazas como los ataques de denegación de servicio distribuido (DDoS) y las secuencias de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifica determinadas condiciones que se deben evaluar y las acciones que se deben llevar a cabo cuando se cumplan esas condiciones. Por ejemplo, una regla podría especificar que, si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un intervalo CIDR específicos, se debe denegar el tráfico. También puede aplicar reglas de cortafuegos de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta el artículo Información general sobre la política de seguridad.

Acceso externo a las VMs

En la arquitectura de referencia que se describe en este documento, las VMs de Compute Engine no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a las VMs. Google Cloud Los recursos que solo tienen una dirección IP interna privada pueden acceder a determinadas APIs y servicios de Google mediante Private Service Connect o Acceso privado de Google. Para obtener más información, consulta el artículo sobre las opciones de acceso privado a servicios.

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

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

Privilegios de cuenta de servicio

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

Seguridad de SSH

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

Encriptado de datos

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

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

Seguridad de la red

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

Seguridad y cumplimiento de Oracle Exadata

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

Más consideraciones sobre seguridad

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

Fiabilidad

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

Robustez frente a errores de máquinas virtuales

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

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 propia aplicación. Es posible que la aplicación se bloquee, falle o no tenga suficiente memoria. Para verificar si una aplicación responde según lo esperado, puedes configurar comprobaciones de estado basadas en aplicaciones como parte de la política de reparación automática de tus MIGs. Si la aplicación de una máquina virtual concreta no responde, el MIG se recupera automáticamente (repara la máquina virtual). Para obtener más información sobre cómo configurar la reparación automática, consulta Información sobre la reparación de VMs para la alta disponibilidad.

Robustez frente a interrupciones de la región

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

  • Mantén una réplica pasiva (de conmutación por error) de los niveles web y de aplicación en otra región Google Cloud .
  • Crea una instancia de infraestructura de Exadata de reserva 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 de reserva. Si tu aplicación necesita un objetivo de punto de recuperación (RPO) más bajo, puedes crear copias de seguridad y recuperar las bases de datos mediante Oracle Autonomous Recovery Service.
  • Si se produce una interrupción en la región principal, usa la réplica de la base de datos o la copia de seguridad para restaurar 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 carga externo en la región de failover.

En el caso de las aplicaciones críticas para la empresa que deben seguir estando disponibles incluso cuando se produzca una interrupción en una región, considera la posibilidad de usar el arquetipo de despliegue multirregional. Puedes usar Oracle Active Data Guard para proporcionar una base de datos de espera de solo lectura en la región de conmutación por error.

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

Autoescalado de MIG

La arquitectura de este documento usa grupos de instancias gestionados regionales para los niveles web y de aplicación. La función de autoescalado de los MIGs sin estado asegura que las máquinas virtuales de Compute Engine que alojan los niveles web y de aplicación no se vean afectadas por las interrupciones de una sola zona.

Para controlar el comportamiento del autoescalado de tus MIGs sin estado, puedes especificar métricas de utilización objetivo, como la utilización media de la CPU. También puedes configurar el escalado automático basado en la programación para los MIGs sin estado. Las MIGs con estado no se pueden escalar automáticamente. Para obtener más información, consulta Grupos de instancias con autoescalado.

Límite de tamaño de MIG

Cuando decidas el tamaño de tus MIGs, ten en cuenta los límites predeterminados y máximos del número de VMs que se pueden crear en un MIG. Para obtener más información, consulta Añadir y quitar VMs de un MIG.

Emplazamiento de VM

En la arquitectura que se describe en este documento, los niveles de aplicación y web se ejecutan en máquinas virtuales de Compute Engine distribuidas en varias zonas. Esta distribución ayuda a asegurar que tu nivel web y tu nivel de aplicación sean resistentes a las interrupciones de una sola zona.

Para mejorar la solidez de la arquitectura, puedes crear una política de colocación de réplicas y aplicarla a la plantilla de MIG. Cuando el MIG crea VMs, las coloca en servidores físicos diferentes (llamados hosts) dentro de cada zona, por lo que tus VMs son resistentes a los fallos de hosts concretos. Para obtener más información, consulta Crear y aplicar políticas de colocación dispersa a VMs.

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.

Almacenamiento con estado

Una práctica recomendada en el diseño de aplicaciones es evitar la necesidad de usar discos locales con estado. Sin embargo, si es necesario, puedes configurar tus discos persistentes para que tengan reconocimiento del estado y así asegurarte de que los datos se conserven cuando se reparen o se vuelvan a crear las VMs. Sin embargo, te recomendamos que mantengas los discos de arranque sin reconocimiento del estado para que puedas actualizarlos a las imágenes más recientes con nuevas versiones y parches de seguridad. Para obtener más información, consulta Configurar discos persistentes con reconocimiento del estado en MIGs.

Capacidad de Oracle Exadata

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

Durabilidad de los datos

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

Para asegurar la durabilidad de los datos de tus instancias de Filestore, puedes crear copias de seguridad y capturas de la instancia o usar Backup and DR para Filestore y sistemas de archivos.

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

Más consideraciones sobre la fiabilidad

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

Optimización de costes

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

Tipos de máquinas virtuales

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

Modelo de aprovisionamiento de VMs

Si tu aplicación es tolerante a fallos, las VMs de acceso puntual pueden ayudarte a reducir los costes de Compute Engine de las VMs de los niveles de aplicación y web. El coste de las máquinas virtuales de acceso puntual es significativamente inferior al de las máquinas virtuales normales. Sin embargo, Compute Engine puede detener o eliminar de forma preventiva las Spot VMs para recuperar capacidad.

Las máquinas virtuales Spot son adecuadas para tareas por lotes que pueden tolerar la interrupción y no tienen requisitos de alta disponibilidad. Las VMs de acceso puntual ofrecen los mismos tipos de máquinas, opciones y rendimiento que las VMs normales. Sin embargo, cuando la capacidad de recursos de una zona es limitada, es posible que los MIGs no puedan aumentar la escala (es decir, crear VMs) automáticamente hasta el tamaño de destino especificado hasta que la capacidad necesaria vuelva a estar disponible.

Uso de recursos de las VMs

La función de autoescalado de los MIGs sin estado permite que tu aplicación gestione los aumentos de tráfico de forma adecuada y te ayuda a reducir los costes cuando la demanda de recursos es baja. Las MIGs con estado no se pueden escalar automáticamente.

Licencias de productos de Oracle

Eres responsable de obtener las licencias de los productos de Oracle que implementes en Compute Engine, así como de cumplir los términos y condiciones de las licencias de Oracle. Para obtener más información, consulta Licensing Oracle Software in the Cloud Computing Environment (Licencias de software de Oracle en el entorno de computación en la nube).

Licencias de bases de datos de Oracle Exadata

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

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

Más consideraciones sobre los costes

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

Eficiencia operativa

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

Actualizaciones de configuración de máquinas virtuales

Para actualizar la configuración de las VMs de un MIG (como el tipo de máquina o la imagen del disco de arranque), crea una plantilla de instancia con la configuración necesaria y, a continuación, aplícala al MIG. El MIG actualiza las VMs mediante el 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 MIGs, consulta Aplicar nuevas configuraciones de VM en un MIG.

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.

Plantillas de instancia deterministas

Si las plantillas de instancia que usas en tus MIGs incluyen secuencias de comandos de inicio para instalar software de terceros, asegúrate de que las secuencias de comandos especifiquen explícitamente los parámetros de instalación del software, como la versión del software. De lo contrario, cuando el MIG cree las VMs, es posible que el software instalado en ellas no sea coherente. Por ejemplo, si tu plantilla de instancia incluye un script de inicio para instalar el servidor HTTP de Apache 2.0 (el paquete apache2), asegúrate de que el script especifique la versión exacta de apache2 que se debe instalar, como la versión 2.4.53. Para obtener más información, consulta Plantillas de instancia deterministas.

Administración de bases de datos de Oracle Exadata

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

Observabilidad de aplicaciones Oracle

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

Documentación y asistencia de Oracle

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

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

Más consideraciones operativas

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

Optimización del rendimiento

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

Rendimiento de computación

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

Multihilo de VM

Cada CPU virtual (vCPU) que asignas a una máquina virtual de Compute Engine se implementa como un único multihilo de hardware. De forma predeterminada, dos vCPUs comparten un núcleo de CPU físico. En las aplicaciones que implican operaciones altamente paralelas o que realizan cálculos de coma flotante (como el análisis de secuencias genéticas y la modelización de riesgos financieros), puedes mejorar el rendimiento reduciendo el número de subprocesos que se ejecutan en cada núcleo de CPU físico. Para obtener más información, consulta Definir el número de hilos por núcleo.

El multihilo de las máquinas virtuales puede tener implicaciones en las licencias de algunos softwares de terceros, como las bases de datos. Para obtener más información, consulta la documentación de licencias del software de terceros.

Rendimiento de la red

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

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

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

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: