Aplicación empresarial con Oracle Database en Compute Engine

Last reviewed 2024-09-02 UTC

En este documento, se proporciona una arquitectura de referencia para ayudarte a compilar la infraestructura que alojará una aplicación empresarial de 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 Cloud. En este documento, también se incluye orientación para ayudarte a compilar una topología de base de datos de Oracle en Google Cloud que cumpla con los requisitos de la arquitectura de máxima disponibilidad (MAA) de Oracle. El público objetivo para este documento son los arquitectos de la nube y los administradores de bases de datos de Oracle. En el documento, se supone que 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 Google Cloud región. Las instancias de la base de datos principal y en espera se implementan en zonas separadas. Esta arquitectura está alineada 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 del usuario 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 (DDoS) y las secuencias 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 del nivel de la 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 primario-en espera de instancias de Oracle Database que se implementan en VMs de Compute Engine en zonas separadas. Tú proporcionas las 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 Hyperdisk Balanced de un grupo de almacenamiento de Hyperdisk. Cuando creas y administras todos los discos en un solo grupo de almacenamiento, mejora el uso de la capacidad y reduce la complejidad operativa a la vez que mantienes la capacidad de almacenamiento y el rendimiento que las VMs necesitan.
Observador de 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 en espera de Oracle Database cuando la instancia principal no está disponible. El observador se ejecuta en una VM de Compute Engine en una zona que es 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 la base de datos de Oracle, esta arquitectura usa un bucket 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 de forma georedundante en un bucket birregional o multirregional.
Red de nube privada virtual (VPC) y subred Todos los Google Cloud recursos de 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 pública de Cloud NAT La arquitectura incluye una puerta de enlace pública de Cloud NAT 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 los Google Cloud recursos. 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 Google Cloud productos:

  • 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 dentro y fuera de Google Cloud, y estos se replican en las ubicaciones para aumentar la redundancia.
  • Nube privada virtual (VPC): Un sistema virtual que proporciona funcionalidad de red global y escalable para tus Google Cloud cargas de trabajo. La 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: Es un servicio de seguridad de red que ofrece reglas de firewall de aplicación web (WAF) y ayuda a proteger contra ataques DDoS 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 IPsec.

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

  • Oracle Database: 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 terceros Google Cloud que uses, puede haber factores de diseño y compensaciones adicionales que deberías considerar.

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 servicios Google Cloud adecuados.

Selección de región

Cuando elijas la región de Google Cloud para tu implementación, 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 recursos de Google Cloud .
  • 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 alquilar todos los niveles de la aplicación. Según los requisitos de tu aplicación, puedes elegir entre los siguientes otros servicios de procesamiento Google Cloud :

  • Contenedores: Puedes ejecutar aplicaciones alojadas en contenedores en los 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 y control 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. La guía de diseño de esos servicios está fuera del alcance de este documento. Para obtener más información sobre las opciones de servicio, consulta Opciones de hosting de aplicaciones.

Opciones de almacenamiento

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

Para almacenar datos que se comparten en varias VMs en una región, como los archivos de configuración para todas las VMs del 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 la infraestructura para una pila de aplicaciones de varios niveles, debes elegir un diseño de red que cumpla con tus requisitos técnicos y empresariales. La arquitectura que se muestra en este documento usa una topología de red simple con una sola red y subred de VPC. 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 externas, como ataques DDoS y XSS, define las políticas de seguridad de Google Cloud Armor adecuadas según tus requisitos. Cada política es un conjunto de reglas que especifican las 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 que alojan el nivel web, el nivel de aplicación y las instancias de Oracle Database no necesitan acceso entrante directo desde Internet. No asignes direcciones IP externas a esas VMs.Los recursos de Google Cloud que solo tienen direcciones IP internas privadas 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 Google Cloud recursos 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.

Seguridad de imágenes de VM

Las imágenes aprobadas son imágenes con software que cumple con tus políticas o requisitos de seguridad. Para garantizar que tus VMs solo usen imágenes aprobadas, puedes definir una política de la organización que restrinja el uso de imágenes en proyectos de imagen pública específicos. Para obtener más información, consulta Configura políticas de imágenes confiables.

Privilegios de la cuenta de servicio

En los proyectos de Google Cloud en los que la API de Compute Engine está habilitada, se crea una cuenta de servicio predeterminada de forma automática. Para las Google Cloud organizaciones que se crearon antes del 3 de mayo de 2024, a esta cuenta de servicio predeterminada se le otorga el rol de IAM Editor (roles/editor), a menos que este comportamiento esté inhabilitado.

De forma predeterminada, la cuenta de servicio predeterminada se conecta a todas las VMs que creas con Google Cloud CLI o la consola de Google Cloud. La función de editor incluye una amplia gama de permisos, por lo que conectar la cuenta de servicio predeterminada a las VMs crea un riesgo de seguridad. Para evitar este riesgo, puedes crear y usar cuentas de servicio dedicadas para cada nivel de la pila de aplicaciones. Para especificar los recursos a los que puede acceder la cuenta de servicio, usa políticas detalladas. Para obtener más información, consulta Limita los privilegios de la cuenta de servicio.

Encriptación de los discos

De forma predeterminada, los datos que se almacenan en volúmenes de Hyperdisk se encriptan conGoogle-owned and Google-managed encryption keys. Como una capa adicional de protección, puedes encriptar las claves de encriptación de datos que pertenecen a Google con claves que posees y administras 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 empresa.

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 una VM del nivel web o del nivel de aplicación falla, el MIG relevante 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 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 la base de datos de Oracle en espera.

Reparación automática de VMs

A veces, las VMs que alojan tu nivel web y de aplicación pueden estar en ejecución y disponibles, pero puede haber problemas con la aplicación. La aplicación podría congelarse, fallar o no tener suficiente memoria. En esta situación, las VMs no responderán a las verificaciones de estado del balanceador de cargas, y este no enrutará el tráfico a las VMs que no responden. Para garantizar que las aplicaciones respondan 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 contra interrupciones zonales

Si se produce una interrupción zonal, la aplicación seguirá 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 MIG regionales garantizan que se creen VMs nuevas de forma automática 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 a 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 base 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 las 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 las interrupciones de 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 región de Google Cloud .
  • Usa un bucket de Cloud Storage birregional o multirregional 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 asigna al nivel de plata 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 región doble, 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.

En el caso de las aplicaciones fundamentales para la empresa que deben seguir disponibles incluso cuando ocurre una interrupción regional, considera usar el arquetipo de implementación multirregional. Para el nivel de la base de datos, puedes usar el FSFO de Oracle Active Data Guard para realizar la conmutación 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 de oro de MAA de Oracle.

Ajuste de escala automático de MIG

Cuando ejecutas tu aplicación en VMs en un MIG regional, la aplicación permanece disponible durante las interrupciones de zonas aisladas. La capacidad de ajuste de escala automático de los MIG sin estado te permite mantener la disponibilidad y el rendimiento de la aplicación en niveles predecibles. Los MIG con estado no pueden realizar un ajuste de escala automático.

Para controlar el comportamiento del ajuste de escala automático de tus MIG, 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. Si quieres obtener más información, consulta Ajuste de escala automático para grupos de instancias.

Ubicación de las VMs

En la arquitectura que se describe en este documento, el nivel de aplicación y el nivel web se ejecutan en las VMs de Compute Engine que se distribuyen en varias zonas. Esta distribución garantiza que la aplicación sea sólida contra las interrupciones de una sola zona. Para mejorar aún más esta solidez, puedes crear una política de posición de distribución y aplicarla a la plantilla de MIG. Con una política de ubicación spread, cuando el MIG crea VMs, las coloca dentro de cada zona en diferentes servidores físicos (llamados hosts), por lo que tus VMs son sólidas contra fallas de hosts individuales. Sin embargo, una desventaja de este enfoque es que podría aumentar la latencia del tráfico de red entre VMs. Para obtener más información, consulta la descripción general de las políticas de posiciones.

Planificación de la capacidad de las VMs

Para asegurarte de que la capacidad de las VMs de Compute Engine esté disponible cuando sea necesaria para el ajuste de escala automático de MIG, 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. Se generarán cargos por los recursos reservados, incluso si no se aprovisionan ni se usan los recursos. Para obtener más información sobre las reservas, incluidas las consideraciones de facturación, consulta Reservas de recursos zonales de Compute Engine.

Disponibilidad del almacenamiento en bloque

En la arquitectura de este documento, se usa un grupo de almacenamiento de Hyperdisk en cada zona para provide storage 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 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 fácilmente 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 habilitando la opción de replicación turbo. Para obtener más información, consulta Disponibilidad y durabilidad de los datos.

Puedes usar el servicio de copia de seguridad y DR para crear, almacenar y administrar copias de seguridad de las VMs de Compute Engine. El servicio de copia de seguridad y 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 tus recursos de VMs, 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 que tienen 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 que 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 con VMs Spot no puedan escalar horizontalmente (es decir, crear VMs) de forma automática para alcanzar el tamaño objetivo especificado hasta que la capacidad requerida vuelva a estar disponible. No uses VMs Spot para las VMs que alojan las instancias de la base de datos de Oracle.

Uso de recursos de VMs

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

Licencias de 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 las licencias de Oracle Database, ten en cuenta la cantidad de licencias de Oracle Processor 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 Licencias de software de Oracle en el entorno de computación en la nube.

Uso de recursos de almacenamiento en bloque

En la arquitectura de este documento, se usa un grupo de almacenamiento de Hyperdisk en cada zona para provide storage en bloque para las VMs de Compute Engine. Puedes mejorar la utilización general de la capacidad de almacenamiento en bloque y reducir el costo 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 de tu carga de trabajo, también considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Google Cloud Framework de la arquitectura: 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 especifiques: 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 las plantillas de instancias de MIG, en lugar de usar imágenes públicas que proporciona Google, te recomendamos que crees y uses imágenes de SO personalizadas que incluyan la configuración y el software que requieren tus aplicaciones. Puedes agrupar tus imágenes personalizadas en una familia de imágenes personalizada. Una familia de imágenes siempre apunta a la imagen más reciente de esa familia para que tus plantillas de instancias y secuencias de comandos puedan usarla sin que tengas que actualizar las referencias a una versión de imagen específica. Debes actualizar tus imágenes personalizadas con regularidad para incluir las actualizaciones de seguridad y los parches que proporciona el proveedor del SO.

Plantillas de instancias deterministas

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

Administración de almacenamiento en bloque

En la arquitectura de este documento, se usa un grupo de almacenamiento de Hyperdisk en cada zona para provide storage en bloque para las VMs de Compute Engine. Los grupos de almacenamiento de Hyperdisk ayudan a simplificar la administración de almacenamiento. En lugar de asignar y administrar la capacidad de forma individual para varios 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 de tu aplicación a Oracle Database, te recomendamos que use 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 la base de datos de Oracle

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

Más consideraciones operativas

Cuando compiles la arquitectura de tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales para la eficiencia operativa que se describen en Google Cloud Framework de la arquitectura: 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 predefinidos y personalizables de máquinas 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 apropiado 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 tu rendimiento y otros requisitos, usa la tabla 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 propósito general. Los tipos de máquinas C4 proporcionan un rendimiento alto y coherente para las cargas de trabajo de bases de datos.

Rendimiento de la red

Para las cargas de trabajo que necesitan una baja latencia de red entre VMs, puedes crear una política de posición compacta y aplicarla a la plantilla de MIG que se usa para el nivel de aplicación. 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 publicació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. Para las VMs con ciertos tipos de máquinas, para mejorar el rendimiento de la red, puedes obtener un ancho de banda de salida máximo más alto habilitando las redes de nivel 1. Para obtener más información, consulta Configura el rendimiento de red Tier_1 por VM.

Rendimiento del almacenamiento de Hyperdisk

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 almacenamiento 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 de tu carga de trabajo, considera las prácticas recomendadas y las recomendaciones generales que se proporcionan en Google Cloud Framework de la arquitectura: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos

Otros colaboradores:


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