Aplicación empresarial con Oracle Database en Compute Engine

Last reviewed 2025-08-13 UTC

En este documento se proporciona una arquitectura de referencia para ayudarte a crear la infraestructura que aloja una aplicación empresarial de alta disponibilidad que usa una base de datos de Oracle, con toda la pila desplegada en máquinas virtuales de Compute Engine. Puedes usar esta arquitectura de referencia para rehospedar (trasladar) de forma eficiente las aplicaciones locales que usan bases de datos de Oracle en Google Cloud. Este documento también incluye directrices para ayudarte a crear una topología de Oracle Database enGoogle Cloud que cumpla los requisitos de la arquitectura de máxima disponibilidad (MAA) de Oracle. Este documento está dirigido a arquitectos de nube y administradores de bases de datos de Oracle. En este documento se da por supuesto que conoces Compute Engine y Oracle Database.

Si usas Oracle Exadata u Oracle Real Application Clusters (Oracle RAC) para ejecutar bases de datos de Oracle en las instalaciones, puedes migrar tus aplicaciones de forma eficiente a Google Cloud y ejecutar tus bases de datos en Oracle Database@Google Cloud. Para obtener más información, consulta el artículo Aplicación empresarial en Compute Engine con Oracle Exadata.

Arquitectura

En el siguiente diagrama se muestra la infraestructura de una aplicación empresarial multinivel que usa Oracle Database. Las instancias de la capa web, la capa de aplicación y la base de datos de Oracle se alojan en máquinas virtuales de Compute Engine. El nivel web y el nivel de aplicación se ejecutan en modo activo-activo en máquinas virtuales distribuidas en dos zonas de una Google Cloud región. Las instancias de base de datos principal y de espera se implementan en zonas independientes. Esta arquitectura se ajusta al arquetipo de implementación regional, que ayuda a asegurar que tu topología de Google Cloud sea sólida frente a las interrupciones de una sola zona1.

Una aplicación empresarial multinivel usa Oracle Database en máquinas virtuales de Compute Engine.

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

Componente Finalidad
Balanceador de carga de aplicación externo regional El balanceador de carga de aplicación externo regional recibe y distribuye las solicitudes de los usuarios 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.
Instancias de Oracle Database desplegadas en máquinas virtuales de Compute Engine La aplicación de esta arquitectura usa un par principal-de reserva de instancias de Oracle Database que se despliegan en VMs de Compute Engine en zonas independientes. Tú proporcionas las licencias (BYOL) de estas instancias de Oracle Database y gestionas las VMs y las instancias de base de datos.
Grupos de almacenamiento de Google Cloud Hyperdisk Las VMs de cada zona (en todos los niveles de la pila de la aplicación) usan volúmenes Hyperdisk Balanced de un grupo de almacenamiento Hyperdisk. Si creas y gestionas todos los discos en un único grupo de almacenamiento, puedes mejorar la utilización de la capacidad y reducir la complejidad operativa, al tiempo que mantienes la capacidad de almacenamiento y el rendimiento que necesitan las VMs.
Observador FSFO de Oracle Data Guard El observador de conmutación por error de inicio rápido (FSFO) de Oracle Data Guard es un programa ligero que inicia la conmutación por error automática a la instancia de Oracle Database en espera cuando la instancia principal no está disponible. El observador se ejecuta en una VM de Compute Engine en una zona distinta de las zonas en las que se implementan las instancias de base de datos principal y de espera.
Segmento de Cloud Storage Para almacenar copias de seguridad de las instancias de Oracle Database, esta arquitectura usa un segmento de Cloud Storage. Para facilitar la recuperación de la base de datos durante una interrupción de la región, puedes almacenar las copias de seguridad con redundancia geográfica en un segmento multirregional o de dos regiones.
Red de nube privada virtual (VPC) y subred Todos los Google Cloud recursos de la arquitectura usan una única red VPC y una única subred. En función de tus requisitos, puedes crear una arquitectura que use varias redes de VPC o varias subredes. Para obtener más información, consulta Decidir si crear varias redes de VPC.
Pasarela de Cloud NAT pública La arquitectura incluye una pasarela 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 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 y Cloud Logging Cloud Monitoring te ayuda a observar el comportamiento, el estado y el rendimiento de tu aplicación y tus recursos. Google Cloud El Agente de operaciones recoge métricas y registros de las VMs de Compute Engine, incluidas las VMs que alojan las instancias de Oracle Database. El agente envía registros a Cloud Logging y métricas a Cloud 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.
  • Google Cloud Hyperdisk: un servicio de almacenamiento en red que puedes usar para aprovisionar y escalar dinámicamente volúmenes de almacenamiento en bloques con un rendimiento configurable y predecible.
  • Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
  • Cloud Storage: un almacén de objetos ilimitado y a un coste bajo para diversos tipos de datos. Se puede acceder a los datos desde dentro y fuera de Google Cloud, y se replican en varias ubicaciones para ofrecer redundancia.
  • 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 Logging: un sistema de gestión de registros en tiempo real con funciones de almacenamiento, búsqueda, análisis y alertas.
  • Cloud Interconnect: un servicio que amplía tu red externa a la red de Google a través de una conexión de alta disponibilidad y baja latencia.
  • Cloud VPN: un servicio que amplía de forma segura tu red de emparejamiento a la red de Google a través de un túnel VPN IPsec.

Esta arquitectura de referencia usa los siguientes productos de Oracle:

  • Oracle Database: un sistema de gestión de bases de datos relacionales (RDBMS) que amplía el modelo relacional a un modelo relacional de objetos.
  • Oracle Data Guard: un conjunto de servicios para crear, mantener, gestionar y monitorizar una o varias bases de datos de espera.

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

Factores del diseño

En esta sección se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que 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 redes

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

Seguridad, privacidad y cumplimiento

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

Protección frente a amenazas externas

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

Acceso externo a las VMs

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

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

Privilegios de cuenta de servicio

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

Seguridad de SSH

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

Cifrado del disco

De forma predeterminada, los datos almacenados en volúmenes de Hyperdisk se encriptan con Google-owned and Google-managed encryption keys. Como capa de protección adicional, puedes cifrar las claves de cifrado de datos propiedad de Google con claves que sean de tu propiedad y que gestiones en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta el artículo Acerca del cifrado de discos.

Seguridad de la red

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

Más consideraciones sobre seguridad

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

Fiabilidad

En esta sección se describen los factores de diseño que debes tener en cuenta al usar 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 cualquiera de los niveles, la aplicación puede seguir procesando solicitudes.

  • Si una VM de la capa web o de la capa de aplicación falla, el MIG correspondiente la recrea automáticamente. Los balanceadores de carga reenvían las solicitudes solo a las instancias de servidor web y de servidor de aplicaciones disponibles.
  • Si falla la VM que aloja la instancia principal de Oracle Database, el observador de FSFO de Oracle Data Guard inicia una conmutación por error automática a la instancia de Oracle Database de reserva.

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 zonas

Si se produce una interrupción en una zona, la aplicación seguirá estando disponible.

  • Los niveles web y de aplicación están disponibles (y responden) porque las VMs están en MIGs regionales. Los MIGs regionales se aseguran de que se creen automáticamente nuevas VMs en la otra zona para mantener el número mínimo de VMs configurado. Los balanceadores de carga reenvían las solicitudes a las VMs de servidor web y de servidor de aplicaciones disponibles.
  • Si una interrupción afecta a la zona que tiene la instancia principal de Oracle Database, el observador de FSFO de Oracle Data Guard inicia una conmutación por error automática a la instancia de Oracle Database en espera. El observador de FSFO se ejecuta en una VM de una zona diferente de las zonas que tienen las instancias de base de datos principal y de espera.
  • Para asegurar la alta disponibilidad de los datos en los volúmenes de Hyperdisk durante una interrupción de una sola zona, puedes usar Hyperdisk Balanced High Availability. Cuando se escriben datos en un volumen, estos se replican de forma síncrona entre dos zonas de la misma región.

Robustez frente a interrupciones de la región

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

  • Mantener una réplica pasiva (de conmutación por error) de la pila de infraestructura en otra Google Cloud región.

  • Usa un segmento de Cloud Storage multirregional o de dos regiones para almacenar las copias de seguridad de Oracle Database. Las copias de seguridad se replican de forma asíncrona en al menos dos ubicaciones geográficas. Con las copias de seguridad de bases de datos replicadas, tu arquitectura se corresponde con el nivel Silver de la arquitectura de máxima disponibilidad (MAA) de Oracle.

    Para conseguir una replicación más rápida de las copias de seguridad almacenadas en segmentos de dos regiones, puedes usar la replicación turbo. Para obtener más información, consulta el artículo Disponibilidad y durabilidad de los datos.

  • Si se produce una interrupción en la región principal, usa la copia de seguridad de la base de datos para restaurarla y activa la aplicación en la región de conmutación por error. Usa políticas de enrutamiento de DNS para enrutar el tráfico al balanceador de carga de la región de failover.

En el caso de las aplicaciones 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. En el nivel de base de datos, puedes usar Oracle Active Data Guard FSFO para conmutar automáticamente por error a una instancia de Oracle Database de reserva en la región de conmutación por error. Este enfoque se corresponde con el nivel Gold de MAA de Oracle.

Autoescalado de MIG

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

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.

Disponibilidad del almacenamiento en bloques

La arquitectura de este documento usa un grupo de almacenamiento de Hyperdisk en cada zona para proporcionar almacenamiento en bloques a las VMs de Compute Engine. Crea un grupo de capacidad de almacenamiento en bloque para una zona. A continuación, crea volúmenes de Hyperdisk en el grupo de almacenamiento y adjunta los volúmenes a las VMs de la zona. El grupo de almacenamiento intenta añadir capacidad automáticamente para asegurarse de que la tasa de utilización no supere el 80% de la capacidad aprovisionada del grupo. De esta forma, se asegura de que el espacio de almacenamiento en bloque esté disponible cuando sea necesario. Para obtener más información, consulta Cómo funcionan los grupos de almacenamiento de Hyperdisk.

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.

Copia de seguridad y sistema de recuperación

La arquitectura de este documento usa Cloud Storage para almacenar copias de seguridad de bases de datos. Si eliges el tipo de ubicación birregional o multirregional para el segmento de Cloud Storage, las copias de seguridad se replicarán de forma asíncrona en al menos dos ubicaciones geográficas. Si se produce una interrupción en una región, puede usar las copias de seguridad para restaurar la base de datos en otra región. Con un segmento de dos regiones, puedes conseguir una replicación más rápida habilitando la opción de replicación turbo. Para obtener más información, consulta el artículo Disponibilidad y 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. El servicio de Backup y DR almacena los datos de las copias de seguridad en su formato original, legible por las aplicaciones. 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 la siguiente documentación:

Más consideraciones sobre la fiabilidad

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

Optimización de costes

En esta sección se ofrecen directrices para optimizar el coste de configurar y operar una 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).

Uso de recursos de almacenamiento en bloques

La arquitectura de este documento usa un grupo de almacenamiento de Hyperdisk en cada zona para proporcionar almacenamiento en bloques a las VMs de Compute Engine. Puedes mejorar la utilización general de la capacidad de almacenamiento en bloques y reducir los costes usando grupos de almacenamiento de capacidad avanzada, que usan aprovisionamiento ligero y tecnologías de reducción de datos para mejorar la eficiencia del almacenamiento.

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.

Gestión del almacenamiento en bloques

La arquitectura de este documento usa un grupo de almacenamiento de Hyperdisk en cada zona para proporcionar almacenamiento en bloques a las VMs de Compute Engine. Los grupos de almacenamiento de Hyperdisk ayudan a simplificar la gestión del almacenamiento. En lugar de asignar y gestionar la capacidad de numerosos discos de forma individual, puedes definir un grupo de capacidad que se pueda compartir entre varias cargas de trabajo de una zona. A continuación, crea volúmenes de Hyperdisk en el grupo de almacenamiento y adjúntalos a las VMs de la zona. El grupo de almacenamiento intenta añadir capacidad automáticamente para asegurarse de que la tasa de utilización no supere el 80% de la capacidad aprovisionada del grupo.

Conectividad del servidor de aplicaciones a la base de datos

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

Administración y asistencia de bases de datos de Oracle

Cuando ejecutas una instancia de Oracle Database autogestionada en una máquina virtual de Compute Engine, se plantean problemas operativos similares a los que surgen cuando ejecutas Oracle Database on-premise. Sin embargo, con una máquina virtual de Compute Engine, ya no tienes que gestionar la infraestructura subyacente de computación, redes y almacenamiento.

Observabilidad de aplicaciones Oracle

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

Más consideraciones operativas

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

Optimización del rendimiento

En esta sección se describen los factores que debes tener en cuenta al usar 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 que puedes elegir en función de los requisitos de rendimiento de tus cargas de trabajo.

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

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

En el caso de las cargas de trabajo que necesiten una latencia de red baja entre las máquinas virtuales en los niveles de aplicación y web, puedes crear una política de emplazamiento compacta y aplicarla a la plantilla de MIG que se utilice en esos niveles. Cuando el MIG crea máquinas virtuales, las coloca en servidores físicos que están cerca unos de otros. Aunque una política de emplazamiento compacta ayuda a mejorar el rendimiento de la red entre máquinas virtuales, una política de emplazamiento dispersa puede ayudar a mejorar la disponibilidad de las máquinas virtuales, como se ha descrito anteriormente. Para conseguir un equilibrio óptimo entre el rendimiento y la disponibilidad de la red, cuando crees una política de colocación compacta, puedes especificar la distancia que debe haber entre las VMs. Para obtener más información, consulta el resumen de las políticas de colocación.

Compute Engine tiene un límite por máquina virtual para el ancho de banda de red de salida. Este límite depende del tipo de máquina de la VM y de si el tráfico se enruta a través de la misma red VPC que la VM de origen. En las VMs con determinados tipos de máquinas, puedes habilitar redes Tier_1 para mejorar el rendimiento de la red y obtener un ancho de banda de salida máximo más alto.

Rendimiento del almacenamiento de Hyperdisk

La arquitectura que se describe en este documento usa volúmenes de Hyperdisk para las VMs de todos los niveles. Hyperdisk te permite escalar el rendimiento y la capacidad de forma dinámica. Puedes ajustar las IOPS aprovisionadas, el rendimiento y el tamaño de cada volumen para que se adapten a las necesidades de rendimiento y capacidad de almacenamiento de tu carga de trabajo. El rendimiento de los volúmenes de Hyperdisk depende del tipo de Hyperdisk y del tipo de máquina de las VMs a las que están conectados los volúmenes. Para obtener más información sobre los límites de rendimiento y la optimización de Hyperdisk, consulta la siguiente documentación:

Más consideraciones sobre el rendimiento

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

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores:

  1. Para obtener más información sobre las consideraciones específicas de cada región, consulta el artículo sobre geografía y regiones.  ↩