Aplicación empresarial con Oracle Database en Compute Engine

Last reviewed 2025-05-27 UTC

En este documento, se proporciona una arquitectura de referencia para ayudarte a compilar la infraestructura que aloja una aplicación empresarial con alta disponibilidad que usa una base de datos de Oracle, con toda la pila implementada en VMs de Compute Engine. Puedes usar esta arquitectura de referencia para volver a alojar (lift-and-shift) aplicaciones locales que usan bases de datos de Oracle en Google Cloudde forma eficiente. Este documento también incluye orientación para ayudarte a compilar una topología de Oracle Database enGoogle Cloud que cumpla con los requisitos de la arquitectura de máxima disponibilidad (MAA) de Oracle. El público objetivo de este documento son los arquitectos de la nube y los administradores de bases de datos de Oracle. En este documento, se supone que conoces Compute Engine y Oracle Database.

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 en Oracle Database@Google Cloud. Para obtener más información, consulta Aplicación empresarial en VMs de Compute Engine con Oracle Exadata en Google Cloud.

Arquitectura

En el siguiente diagrama, se muestra la infraestructura de una aplicación empresarial de varios niveles que usa Oracle Database. El nivel web, el nivel de aplicación y las instancias de Oracle Database se alojan en VMs de Compute Engine. El nivel web y el nivel de aplicación se ejecutan en modo activo-activo en VMs que se distribuyen en dos zonas dentro de una región de Google Cloud. Las instancias de base de datos principal y en espera se implementan en zonas separadas. Esta arquitectura se alinea con el arquetipo de implementación regional, lo que ayuda a garantizar que tu topología de Google Cloud sea sólida contra las interrupciones de una sola zona1.

Una aplicación empresarial de varios niveles usa Oracle Database en VMs de Compute Engine.

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

Componente Objetivo
Balanceador de cargas de aplicaciones externo regional El balanceador de cargas de aplicaciones externo regional recibe y distribuye las solicitudes de los usuarios a las VMs de nivel web.
Política de seguridad de Google Cloud Armor La política de seguridad de Google 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.
Instancias de Oracle Database implementadas en VMs de Compute Engine La aplicación de esta arquitectura usa un par principal y en espera de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas separadas. Tú aportas tus propias licencias (BYOL) para estas instancias de Oracle Database y administras las VMs y las instancias de base de datos.
Grupos de almacenamiento de Hyperdisk Las VMs de cada zona (en todos los niveles de la pila de aplicaciones) usan volúmenes de Hyperdisk Balanced de un grupo de almacenamiento de Hyperdisk. Crear y administrar todos los discos en un solo grupo de almacenamiento te permite mejorar el uso de la capacidad y reducir la complejidad operativa, a la vez que mantienes la capacidad y el rendimiento de almacenamiento que necesitan las VMs.
Observador de Oracle Data Guard FSFO 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 diferente de las zonas en las que se implementan las instancias de la base de datos principal y en espera.
Bucket de Cloud Storage Para almacenar copias de seguridad de las instancias de Oracle Database, esta arquitectura usa un bucket de Cloud Storage. Para facilitar la recuperación de la base de datos durante una interrupción regional, puedes almacenar las copias de seguridad con redundancia geográfica en un bucket birregional o multirregional.
Red de nube privada virtual (VPC) y subred Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC y subred. Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes de VPC o varias subredes. Para obtener más información, consulta Decide si crear o no varias redes de VPC.
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 y Cloud Logging Cloud Monitoring te ayuda a observar el comportamiento, el estado y el rendimiento de tu aplicación y tus recursos de Google Cloud . El Agente de operaciones recopila 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

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.
  • Google Cloud Hyperdisk: Es un servicio de almacenamiento de red que puedes usar para aprovisionar y escalar de forma dinámica volúmenes de almacenamiento en bloque con un rendimiento configurable y predecible.
  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Cloud Storage: Un depósito de objetos de bajo costo y sin límites para varios tipos de datos. Se puede acceder a los datos desde y hacia Google Cloud, y estos se replican en las ubicaciones para aumentar la redundancia.
  • 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 Logging: Un sistema de administración de registros en tiempo real con almacenamiento, búsqueda, análisis y alertas.
  • Cloud Interconnect: Es un servicio que extiende tu red externa a la red de Google a través de una conexión de latencia baja y alta disponibilidad.
  • Cloud VPN: Es un servicio que extiende de forma segura tu red de intercambio de tráfico a la red de Google a través de un túnel VPN con IPsec.

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

  • Base de datos de Oracle: Es un sistema de administración de bases de datos relacionales (RDBMS) que extiende el modelo relacional a un modelo relacional de objetos.
  • Oracle Data Guard: Es un conjunto de servicios para crear, mantener, administrar y supervisar una o más bases de datos en espera.

Eres responsable de obtener licencias para los productos de Oracle que implementes en Google Cloudy de cumplir con los Términos y Condiciones de las licencias de Oracle.

Consideraciones del diseño

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

La arquitectura que se muestra en este documento usa un grupo de almacenamiento de Hyperdisk en cada zona, con volúmenes de Hyperdisk Balanced para las VMs en todos los niveles. Los volúmenes de Hyperdisk proporcionan mejor rendimiento, flexibilidad y eficiencia que los de Persistent Disk. Para obtener información sobre los tipos y las funciones de Hyperdisk, consulta Acerca de Hyperdisk Balanced.

Para almacenar datos que se comparten en varias VMs en una región, como archivos de configuración para todas las VMs en el nivel web, puedes usar una instancia regional de Filestore. Los datos que almacenas en una instancia regional de Filestore se replican de forma síncrona en tres zonas dentro de la región. Esta replicación garantiza la alta disponibilidad y la solidez contra las interrupciones de zona. Puedes almacenar archivos de configuración compartidos, herramientas y utilidades comunes y registros centralizados en la instancia de Filestore, y activar la instancia en varias VMs.

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

Cuando compilas infraestructura para una pila de aplicaciones de varios niveles, debes elegir un diseño de red que cumpla con tus requisitos comerciales y técnicos. La arquitectura que se muestra en este documento usa una topología de red simple con una sola red de VPC y subred. Según tus requisitos, puedes optar por usar varias redes de VPC o varias subredes. Para obtener más información, consulta la siguiente documentación:

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 y cumplimiento de tus cargas de trabajo.

Protección contra amenazas externas

Para proteger tu aplicación contra amenazas como los ataques de denegación de servicio distribuido (DSD) y las secuencia de comandos entre sitios (XSS), puedes usar las políticas de seguridad de Google Cloud Armor. Cada política es un conjunto de reglas que especifican ciertas condiciones que se deben evaluar y las acciones que se deben realizar cuando se cumplen las condiciones. Por ejemplo, una regla podría especificar que si la dirección IP de origen del tráfico entrante coincide con una dirección IP o un rango de CIDR en particular, se debe denegar el tráfico. También puedes aplicar reglas de firewall de aplicación web (WAF) preconfiguradas. Para obtener más información, consulta Descripción general de las políticas de seguridad.

Acceso externo para las VMs

En la arquitectura de referencia que se describe en este documento, las VMs de Compute Engine no necesitan acceso entrante desde Internet. No asignes direcciones IP externas a las VMs. Google Cloud Los recursos que solo tienen una dirección IP interna privada pueden acceder a ciertas APIs y servicios de Google a través de Private Service Connect o el Acceso privado a Google. Si quieres obtener más información, consulta Opciones de acceso privado a los servicios.

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

Privilegios de la cuenta de servicio

Para las VMs de Compute Engine en la arquitectura, en lugar de usar las cuentas de servicio predeterminadas, te recomendamos que crees cuentas de servicio dedicadas y especifiques los recursos a los que puede acceder la cuenta de servicio. La cuenta de servicio predeterminada incluye una amplia variedad de permisos que no son necesarios en este caso, mientras que puedes personalizar las cuentas de servicio dedicadas para que solo tengan los permisos necesarios. 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 esta arquitectura, implementa el reenvío de Identity-Aware Proxy (IAP) con 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 de Linux en función de la identidad del usuario y las políticas de IAM. Para obtener más información sobre cómo administrar el acceso a la red, consulta Prácticas recomendadas para controlar el acceso de SSH.

Encriptación de los discos

De forma predeterminada, los datos que se almacenan en volúmenes de Hyperdisk se encriptan con Google-owned and Google-managed encryption keys. Como una capa adicional de protección, puedes optar por encriptar las claves de encriptación de datos propiedad de Google con claves que poseas y administres en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta Información sobre la encriptación de discos.

Seguridad de red

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

Más consideraciones de seguridad

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de la 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 cualquiera de los niveles, la aplicación puede seguir procesando solicitudes.

  • Si falla una VM en el nivel web o en el nivel de la 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 del servidor web y del servidor de aplicaciones que están disponibles en ese momento.
  • Si falla la VM que aloja la instancia principal de la base de datos de Oracle, el observador de FSFO de Oracle Data Guard inicia una conmutación por error automática a la instancia de base de datos de Oracle en espera.

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 zonales

Si se produce una interrupción zonal, la aplicación permanece disponible.

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

Solidez ante interrupciones regionales

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

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

  • Usa un bucket de Cloud Storage birregional o multirregional para almacenar las copias de seguridad de la base de datos de Oracle. 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 asigna al nivel Silver de la arquitectura de máxima disponibilidad (MAA) de Oracle.

    Para lograr una replicación más rápida de las copias de seguridad almacenadas en buckets de regiones dobles, puedes usar la replicación turbo. Para obtener más información, consulta 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 restablecerla 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 al balanceador de cargas 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. Para el nivel de la base de datos, puedes usar Oracle Active Data Guard FSFO para conmutar por error automáticamente a una instancia de base de datos de Oracle en espera en la región de conmutación por error. Este enfoque se asigna al nivel Gold de MAA de Oracle.

Ajuste de escala automático de MIG

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, ten en cuenta los límites predeterminados y máximos de 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

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.

Disponibilidad del almacenamiento en bloque

La arquitectura de este documento usa un grupo de almacenamiento de Hyperdisk en cada zona para proporcionar almacenamiento en bloque para las VMs de Compute Engine. Creas un grupo de capacidad de almacenamiento en bloque para una zona. Luego, crea volúmenes de Hyperdisk en el grupo de almacenamiento y conéctalos a las VMs de la zona. El grupo de almacenamiento intenta agregar capacidad automáticamente para garantizar que la tasa de uso no supere el 80% de la capacidad aprovisionada del grupo. Este enfoque garantiza 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 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.

Crear copia de seguridad y de recuperación

La arquitectura de este documento usa Cloud Storage para almacenar copias de seguridad de la base de datos. Si eliges el tipo de ubicación birregional o multirregional para el bucket de Cloud Storage, las copias de seguridad se replican de forma asíncrona en al menos dos ubicaciones geográficas. Si se produce una interrupción regional, puedes usar las copias de seguridad para restablecer la base de datos en otra región. Con un bucket de región doble, puedes lograr una replicación más rápida si habilitas la opción de replicación turbo. Para obtener más información, consulta Disponibilidad y 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. El servicio Backup and DR almacena 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 la siguiente documentación:

Más consideraciones de confiabilidad

Cuando compiles la arquitectura de nube para tu carga de trabajo, revisa las prácticas recomendadas y las recomendaciones relacionadas con la confiabilidad que se proporcionan en la siguiente documentación:

Optimización de costos

En esta sección, se proporciona orientación para optimizar el costo de configurar y operar una topología de Google Cloud que compilas a través de 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.

Licenciamiento de Oracle Database

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. Cuando calcules el costo de la licencia de Oracle Database, considera la cantidad de licencias de procesador de Oracle que se requieren según el tipo de máquina que elijas para las VMs de Compute Engine que alojan las instancias de Oracle Database. 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 bloque

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

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 VM

Para tus VMs, en lugar de usar imágenes públicas que proporciona Google, te recomendamos que crees y uses imágenes de SO personalizadas que contengan 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 del almacenamiento en bloque

La arquitectura de este documento usa un grupo de almacenamiento de Hyperdisk en cada zona para proporcionar almacenamiento en bloque para las VMs de Compute Engine. Los grupos de almacenamiento de Hyperdisk ayudan a simplificar la administración del almacenamiento. En lugar de asignar y administrar la capacidad de forma individual para numerosos discos, defines un grupo de capacidad que se puede compartir entre varias cargas de trabajo en una zona. Luego, crea volúmenes de Hyperdisk en el grupo de almacenamiento y conéctalos a las VMs de la zona. El grupo de almacenamiento intenta agregar capacidad automáticamente para garantizar que la tasa de uso no supere el 80% de la capacidad aprovisionada del grupo.

Conectividad del servidor de aplicaciones a la base de datos

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

Administración y asistencia de Oracle Database

Cuando ejecutas una instancia de base de datos de Oracle autoadministrada en una VM de Compute Engine, existen problemas operativos similares a los que se presentan cuando ejecutas la base de datos de Oracle de forma local. Sin embargo, con una VM de Compute Engine, ya no necesitas administrar la infraestructura subyacente de procesamiento, redes y almacenamiento.

  • Para obtener orientación sobre cómo operar y administrar tus instancias de Oracle Database, consulta la documentación proporcionada por Oracle para la versión correspondiente.
  • 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 (Doc ID 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 que puedes elegir según los requisitos de rendimiento de tus cargas de trabajo.

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

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

Para las cargas de trabajo que necesitan una baja latencia de red entre VM dentro de los niveles de aplicación y web, puedes crear una política de posición compacta y aplicarla a la plantilla de MIG que se usa para esos niveles. Cuando el MIG crea las VMs, las coloca en servidores físicos que están cerca. Si bien una política de posición compacta ayuda a mejorar el rendimiento de la red entre VMs, una política de posición distribuida puede ayudar a mejorar la disponibilidad de la VM, como se describió anteriormente. Para lograr un equilibrio óptimo entre el rendimiento y la disponibilidad de la red, cuando creas una política de posición compacta, puedes especificar la distancia a la que se deben colocar las VMs. Para obtener más información, consulta la Descripción general de las políticas de colocación.

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

Rendimiento del almacenamiento de Hyperdisk

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

Más consideraciones sobre el rendimiento

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

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores:

  1. Para obtener más información sobre las consideraciones específicas de la región, consulta Geografía y regiones.  ↩