En este documento, se proporciona una arquitectura de referencia para una aplicación empresarial de alta disponibilidad que se aloja en máquinas virtuales (VMs) de Compute Engine con conectividad de baja latencia a las bases de datos de Exadata de Oracle Cloud Infrastructure (OCI) que se ejecutan en Google Cloud. El público objetivo para este documento son los arquitectos de la nube y los administradores de bases de datos de Oracle. En el documento, se supone que estás familiarizado con Compute Engine y el servicio de base de datos Oracle Exadata.
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. Oracle Database@Google Cloud es una oferta de Google Cloud Marketplace que te permite ejecutar Oracle Exadata Database Service y Oracle Autonomous Database directamente en Google Cloud.
Si no necesitas la función de Oracle RAC o si necesitas una versión de la base de datos de Oracle distinta de 19c y 23ai, puedes ejecutar bases de datos de Oracle autoadministradas en VMs de Compute Engine. Para obtener más información, consulta Aplicación empresarial con Oracle Database en Compute Engine.
Arquitectura
En el siguiente diagrama, se muestra una vista de alto nivel de la arquitectura:
En el diagrama anterior, un balanceador de cargas externo recibe solicitudes de los usuarios de una aplicación orientada al público y las distribuye a los servidores web del frontend. Los servidores web reenvían las solicitudes del usuario a través de un balanceador de cargas interno a los servidores de aplicaciones. Los servidores de aplicaciones leen datos de bases de datos y escriben en ellas en Oracle Database@Google Cloud. Los administradores y los servicios de OCI pueden conectarse e interactuar con las bases de datos de Oracle.
En el siguiente diagrama, se muestra una vista detallada de la arquitectura:
En esta arquitectura, el nivel web y el nivel de aplicación se ejecutan en modo activo-activo en las VMs de Compute Engine que se distribuyen en dos zonas dentro de una región de Google Cloud. La aplicación usa bases de datos de Oracle Exadata en la misma región Google Cloud.
Todos los componentes de la arquitectura se encuentran en una sola región Google Cloud. Esta arquitectura está alineada con el arquetipo de implementación regional. Puedes adaptar esta arquitectura para compilar una topología que sea sólida contra las interrupciones regionales con el arquetipo de implementación multirregional. Para obtener más información, consulta Implementación multirregional en Compute Engine y también la guía en la sección Confiabilidad más adelante en este documento.
La arquitectura que se muestra en el diagrama anterior incluye los siguientes componentes:
Componente | Purpose |
---|---|
Balanceador de cargas de aplicaciones externo regional | El balanceador de cargas de aplicaciones externo regional recibe las solicitudes del usuario y las distribuye 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. |
Red de nube privada virtual (VPC) y subred | Todos los recursos de Google Cloud en la arquitectura usan una sola red de VPC. Según tus requisitos, puedes optar por compilar una arquitectura que use varias redes. Para obtener más información, consulta Decide si crear o no varias redes de VPC. |
Oracle Database@Google Cloud |
Los servidores de aplicaciones leen y escriben datos en las bases de datos de Oracle en Oracle Exadata Database Service. Para aprovisionar el servicio de bases de datos de Oracle Exadata, usa Oracle Database@Google Cloud, una oferta de Cloud Marketplace que te permite ejecutar bases de datos de Oracle en hardware administrado por Oracle dentro de un Google Cloud centro de datos. Usas Google Cloud interfaces como la consola de Google Cloud, Google Cloud CLI y las APIs para crear instancias de Exadata Infrastructure. Oracle configura y administra la infraestructura de procesamiento, almacenamiento y redes requerida en un centro de datos dentro de una región de Google Cloud en hardware dedicado a tu proyecto. |
Instancias de la infraestructura de Exadata | Cada instancia de Exadata Infrastructure contiene dos o más servidores de bases de datos físicos y tres o más servidores de almacenamiento. Estos servidores, que no se muestran en el diagrama, están interconectados a través de un tejido de red de baja latencia. Cuando creas una instancia de infraestructura de Exadata, especificas la cantidad de servidores de bases de datos y de almacenamiento que se deben aprovisionar. |
Clústeres de VM de Exadata |
Dentro de una instancia de Exadata Infrastructure, creas uno o más clústeres de VM de Exadata. Por ejemplo, puedes crear y usar un clúster de VM de Exadata independiente para alojar las bases de datos necesarias para cada una de tus unidades de negocio. Cada clúster de VM de Exadata contiene una o más VMs de Oracle Linux que alojan instancias de la base de datos de Oracle. Cuando creas un clúster de VM de Exadata, debes especificar lo siguiente:
Las VMs de los clústeres de VM de Exadata no son VMs de Compute Engine. |
Instancias de Oracle Database | Puedes crear y administrar bases de datos de Oracle a través de la consola de OCI y otras interfaces de OCI. El software de Oracle Database se ejecuta en las VMs del clúster de VMs de Exadata. Cuando creas el clúster de VM de Exadata, especificas la versión de Oracle Grid Infrastructure. También debes elegir el tipo de licencia: usar tus propias licencias (BYOL) o optar por el modelo con licencia incluida. |
VCN de OCI y subredes | Cuando creas un clúster de VM de Exadata, se crea automáticamente una red de nube virtual (VCN) de OCI. La VCN tiene una subred cliente y una subred de copia de seguridad con los rangos de direcciones IP que especifiques. La subred del cliente se usa para la conectividad de tu red de VPC a las bases de datos de Oracle. La subred de copia de seguridad se usa para enviar copias de seguridad de la base de datos a OCI Object Storage. |
Cloud Router, interconexión de socios y DRG de OCI | Un Cloud Router conectado a la VPC enruta el tráfico entre tu red de VPC y la VCN a través de una puerta de enlace de enrutamiento dinámico (DRG) conectada a la VCN. El tráfico fluye a través de una conexión de baja latencia que Google configura con la interconexión de socios. |
Zona privada de Cloud DNS | Cuando creas un clúster de VM de Exadata, se crea automáticamente una zona privada del DNS de Cloud. Cuando tus servidores de aplicaciones envían solicitudes de lectura y escritura a las bases de datos de Oracle, Cloud DNS resuelve los nombres de host de la base de datos en las direcciones IP correspondientes. |
Almacenamiento de objetos de OCI y Puerta de enlace de servicios de OCI | De forma predeterminada, las copias de seguridad de las bases de datos de Oracle Exadata se almacenan en el almacenamiento de objetos de OCI. Las copias de seguridad de la base de datos se enrutan a OCI Object Storage a través de una puerta de enlace de servicio. |
Puerta de enlace 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 | Puedes usar Cloud Monitoring para observar el comportamiento, el estado y el rendimiento de tu aplicación y los recursos de Google Cloud , incluidos los recursos de Oracle Exadata. También puedes supervisar los recursos de Oracle Exadata con el servicio de supervisión de OCI. |
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.
- Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
- 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 Interconnect: Es un servicio que extiende tu red externa a la red de Google a través de una conexión de latencia baja y alta disponibilidad.
- Interconexión de socio: Es un servicio que proporciona conectividad entre tu red local y tus redes de nube privada virtual y otras redes a través de un proveedor de servicios compatible.
- Cloud VPN: Es un servicio que extiende de forma segura tu red de intercambio de tráfico a la red de Google a través de un túnel VPN IPsec.
En esta arquitectura de referencia, se usan los siguientes productos de OCI:
- Exadata Database Service en infraestructura dedicada: Es un servicio que te permite ejecutar instancias de Oracle Database en hardware de Exadata dedicado para ti.
- Almacenamiento de objetos: Es un servicio para almacenar grandes cantidades de datos estructurados y no estructurados como objetos.
- VCN y subredes: Una VCN es una red virtual y privada para los recursos de una región de OCI. Una subred es un rango contiguo de direcciones IP con una VCN.
- Puerta de enlace de enrutamiento dinámico: Es un router virtual para el tráfico entre una VCN y redes externas.
- Puerta de enlace de servicio: Es una puerta de enlace que permite que los recursos de una VCN accedan a servicios específicos de Oracle de forma privada.
Consideraciones del diseño
En esta sección, se describen los factores de diseño, las prácticas recomendadas y las recomendaciones de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para desarrollar una topología que cumpla con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento.
La guía de esta sección no está completa. Según los requisitos específicos de tu aplicación y los productos y funciones de 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
- Disponibilidad de Oracle Database@Google Cloud en cada región. Para obtener más información, consulta Configuraciones disponibles.
- 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
En la arquitectura de referencia de este documento, se usan VMs de Compute Engine para alquilar el nivel web y el nivel de 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 y funciones de 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 Alojamiento de aplicaciones en Google Cloud.
Opciones de almacenamiento
Para proporcionar almacenamiento persistente para las VMs de Compute Engine en el nivel web y el nivel de aplicación, elige un tipo de disco persistente o Hyperdisk de Google Cloud adecuado según los requisitos de capacidad, escalamiento, disponibilidad y rendimiento de tu aplicación. Para obtener más información, consulta Opciones de almacenamiento.
Si necesitas almacenamiento de bajo costo que sea redundante en todas las zonas de una región, usa buckets regionales de Cloud Storage.
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 de Filestore Regional se replican de forma síncrona en tres zonas dentro de la región1. Esta replicación ayuda a garantizar la alta disponibilidad y la solidez contra las interrupciones de zona de los datos que almacenas en Filestore. 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 de VPC. Según tus requisitos, puedes optar por usar varias redes. Para obtener más información, consulta la siguiente documentación:
Cuando asignes rangos de direcciones IP para las subredes de cliente y de copia de seguridad que se usarán para los clústeres de VM de Exadata, ten en cuenta los requisitos de tamaño mínimo de subred. Para obtener más información, consulta Planifica el espacio de direcciones IP en Oracle Database@Google Cloud.
Migración de bases de datos
Cuando planifiques migrar bases de datos locales a Oracle Database@Google Cloud, evalúa tu entorno de base de datos actual y obtén recomendaciones de configuración y tamaño con la herramienta Database Migration Assessment (DMA).
Para migrar datos locales a implementaciones de bases de datos de Oracle enGoogle Cloud, puedes usar herramientas estándar de Oracle, como Oracle GoldenGate.
Antes de usar las bases de datos migradas en un entorno de producción, verifica la conectividad de tus aplicaciones con las bases de datos.
Seguridad
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 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 y el nivel de aplicación no necesitan acceso entrante directo desde Internet. No asignes direcciones IP externas a esas VMs.Los recursos de Google Cloudque 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 deseas 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 Cloud NAT, como se muestra en el diagrama de arquitectura anterior, o usar Secure Web Proxy.
Para las subredes que usan las VMs de Exadata, Oracle recomienda que asignes rangos de direcciones IP privadas.
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 en el nivel web y el nivel de aplicación usen solo 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 de Compute Engine que creas con gcloud CLI o la consola de Google Cloud. El rol 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.
Seguridad de red
Para controlar el tráfico de red entre los recursos del nivel web y el nivel de aplicación de la arquitectura, debes configurar las políticas de Cloud Next Generation Firewall (NGFW) adecuadas.
Seguridad y cumplimiento de la base de datos
El servicio de Oracle Database incluye Oracle Data Safe, que te ayuda a administrar los requisitos de seguridad y cumplimiento de las bases de datos de Oracle. Puedes usar Oracle Data Safe para evaluar los controles de seguridad, supervisar la actividad de los usuarios y enmascarar los datos sensibles. Para obtener más información, consulta Administra la seguridad de la base de datos con Oracle Data Safe.
Más consideraciones de seguridad
Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones de seguridad a nivel de la plataforma que se proporcionan en el plano sobre las bases de empresa.
Confiabilidad
En esta sección, se describen los factores de diseño que debes tener en cuenta cuando usas esta arquitectura de referencia para compilar y operar una infraestructura confiable para tu implementación enGoogle Cloud.
Robustez ante fallas de VM
En la arquitectura que se muestra en este documento, si falla una VM de Compute Engine en el nivel web o de aplicación, el MIG correspondiente vuelve a crear la VM automáticamente. Los balanceadores de cargas reenvían las solicitudes solo a las instancias del servidor web y del servidor de aplicaciones disponibles en ese momento.
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 ante las interrupciones regionales
Si se produce una interrupción regional, la aplicación no estará disponible. Para reducir el tiempo de inactividad causado por las interrupciones de la región, puedes implementar el siguiente enfoque:
- Mantén una réplica pasiva (de conmutación por error) del nivel web y del nivel de aplicación en otra región de Google Cloud .
- Crea una instancia de Exadata Infrastructure de reserva con los clústeres de VM de Exadata necesarios en la misma región que tiene la réplica pasiva de la pila de aplicaciones. Usa Oracle Data Guard para la replicación de datos y la conmutación por error automática a las bases de datos de Exadata en espera. Si tu aplicación necesita un objetivo de punto de recuperación (RPO) más bajo, puedes crear una copia de seguridad de las bases de datos y recuperarlas con el servicio de recuperación autónoma de Oracle.
- Si se produce una interrupción en la región principal, usa la réplica o la copia de seguridad de la base de datos para restablecerla en producción y activar la aplicación en la región de conmutación por error.
- Usa políticas de enrutamiento de DNS para enrutar el tráfico a un balanceador de cargas externo en la región de conmutación por error.
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. Puedes usar Oracle Active Data Guard para proporcionar una base de datos en espera de solo lectura en la región de conmutación por error.
Oracle administra la infraestructura de Oracle Database@Google Cloud. Para obtener información sobre los objetivos de nivel de servicio (SLO) del servicio de base de datos Oracle Exadata en infraestructura dedicada, consulta Objetivos de nivel de servicio para los servicios de nube pública de PaaS y IaaS de Oracle.
Ajuste de escala automático de MIG
La arquitectura de este documento usa MIG regionales para el nivel web y el nivel de aplicación. La capacidad de ajuste de escala automático de los MIG sin estado garantiza que las VMs de Compute Engine que alojan el nivel web y el nivel de aplicación no se vean afectadas por interrupciones de zona única. 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 ayuda a garantizar que el nivel web y el nivel de la aplicación sean sólidos 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 posición dispersa, 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 las VMs. Para obtener más información, consulta la descripción general de las políticas de publicación.
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.
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.
Capacidad de la base de datos
Puedes escalar la infraestructura de Exadata agregando servidores de base de datos y servidores de almacenamiento según sea necesario. Después de agregar los servidores de base de datos o de almacenamiento necesarios a la infraestructura de Exadata, para poder usar los recursos adicionales de CPU o almacenamiento, debes agregar la capacidad al clúster de VMs de Exadata asociado. Para obtener más información, consulta Escalamiento de Exadata Compute y Storage.
Crear copia de seguridad y de recuperación
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 Servicio de copia de seguridad y DR para copias de seguridad de instancias de Compute Engine.
De forma predeterminada, las copias de seguridad de las bases de datos en Oracle Exadata Database Service en infraestructura dedicada se almacenan en el almacenamiento de objetos de OCI. Para lograr un RPO más bajo, puedes crear copias de seguridad de las bases de datos y recuperarlas con el servicio de recuperación autónoma de Oracle.
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:
- Google Cloud guía de confiabilidad de la infraestructura
- Patrones de apps escalables y resilientes
- Diseña sistemas resilientes
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 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 las VMs de tu nivel web y de nivel de aplicación. Para cargas de trabajo que tengan 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 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.
Costos de la base de datos
Cuando creas un clúster de VM de Exadata, puedes elegir la opción de llevar tu propio licenciamiento o aprovisionar bases de datos de Oracle con licencia incluida.
Los cargos de red por la transferencia de datos entre tus aplicaciones y las bases de datos de Oracle Exadata que se encuentran en la misma región se incluyen en el precio de la oferta de Oracle Database@Google Cloud.
Más consideraciones de los costos
Cuando compiles la arquitectura 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.
Database administration (Administra la base de datos)
Oracle administra los servidores de base de datos físicos, los servidores de almacenamiento y el hardware de redes en el servicio de base de datos de Oracle Exadata en infraestructura dedicada. Puedes gestionar las instancias de Exadata Infrastructure y los clústeres de VM de Exadata a través de las interfaces de OCI o Google Cloud . Creas y administras bases de datos a través de las interfaces de OCI. Las páginas de la consola de Google Cloud para Oracle Database@Google Cloud incluyen vínculos que puedes usar para ir directamente a las páginas relevantes en la consola de OCI. Para evitar tener que volver a acceder a OCI, puedes configurar la federación de identidades entre OCI y Google Cloud.
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 adecuado según tus requisitos de rendimiento para esos niveles. Para obtener más información, consulta la comparación de series de máquinas.
Rendimiento de la red
Para las cargas de trabajo que necesitan una baja latencia de red entre VMs dentro de los niveles web y de la aplicación, 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 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.
El tráfico de red entre las VMs del nivel de aplicación y la red de Oracle Exadata se enruta a través de una conexión de interconexión de socios de baja latencia que configura Google.
La infraestructura de Exadata usa RDMA sobre Ethernet convergente (RoCE) para redes de ancho de banda alto y baja latencia entre los servidores de bases de datos y los servidores de almacenamiento. Los servidores intercambian datos directamente en la memoria principal sin involucrar el procesador, la caché ni el sistema operativo.
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?
- Acelera la transformación en la nube con Google Cloud y Oracle
- Documentación de Oracle
- Documentación de Google
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
Colaboradores
Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos
Otros colaboradores:
- Andy Colvin | Ingeniero de bases de datos con cinturón negro (Oracle en Google Cloud)
- Jeff Welsch | Director, Administración de productos
- Lee Gates | Gerente de Grupo de Productos
- Marc Fielding | Arquitecto de infraestructura de datos
- Mark Schlagenhauf | Escritor técnico, Herramientas de redes
- Michelle Burtoft | Gerente sénior de productos
- Rajesh Kasanagottu | Gerente de Ingeniería
- Roberto Mendez | Ingeniero de implementación de redes de personal
- Sekou Page | Gerente de Productos Salientes
- Souji Madhurapantula | Gerente de grupo de productos
- Victor Moreno | Gerente de producto, Herramientas de redes de Cloud
-
Para obtener más información sobre las consideraciones específicas de cada región, consulta Geografía y regiones. ↩