En este documento, se proporciona una arquitectura de referencia para ayudarte a compilar la infraestructura que ejecuta las aplicaciones de Oracle E-Business Suite con conectividad de baja latencia a las bases de datos de Oracle Cloud Infrastructure (OCI) Exadata que se ejecutan enGoogle Cloud. Oracle E-Business Suite es un conjunto de aplicaciones empresariales para funciones comerciales, como finanzas, recursos humanos, cadena de suministro y relaciones con los clientes.
El público objetivo de este documento son los arquitectos y administradores de la nube de bases de datos de Oracle y aplicaciones de Oracle E-Business Suite. En este documento, se supone que tu equipo conoce la arquitectura y la pila de tecnología de Oracle E-Business Suite y el servicio de base de datos de 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 enOracle 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.
Arquitectura
En el siguiente diagrama, se muestra una arquitectura en la que las aplicaciones de Oracle E-Business Suite se ejecutan en modo activo-activo en VMs de Compute Engine que se distribuyen en dos zonas dentro de una Google Cloud región. La aplicación usa bases de datos de Oracle Exadata en la misma región Google Cloud.
Todos los componentes de la arquitectura 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 la orientación en la sección Confiabilidad más adelante en este documento.
La arquitectura del diagrama anterior incluye los siguientes componentes:
Componente | Objetivo |
---|---|
Balanceador de cargas de aplicaciones externo regional | El balanceador de cargas recibe y distribuye las solicitudes de los usuarios a las aplicaciones de Oracle E-Business Suite. |
Política de seguridad de Google Cloud Armor | La política de seguridad de 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). |
Oracle E-Business Suite (BYOL) | Los componentes de la capa de aplicación de Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server y un servidor de procesamiento simultáneo) se ejecutan en VMs de Compute Engine que se distribuyen en dos zonas de la región principal. Cada VM aloja una instancia independiente de la capa de aplicación. El disco de arranque de cada VM es un volumen de Hyperdisk Balanced. Tú aportas tus propias licencias (BYOL) para Oracle E-Business Suite y administras las VMs y las aplicaciones. |
Objetos binarios y datos de la aplicación | Una instancia regional de Filestore contiene los datos y los archivos binarios de la aplicación. La instancia de Filestore está activada en todas las VMs de Compute Engine que alojan los componentes de la capa de aplicación en ambas zonas. |
Copias de seguridad de aplicaciones | El servicio Backup and DR crea, almacena y administra las copias de seguridad de la aplicación. |
Red de nube privada virtual (VPC) | Todos los recursos de la arquitectura usan una sola red de VPC. Google Cloud 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 | Las aplicaciones leen y escriben datos en bases de datos de Oracle en Oracle Exadata Database Service. Aprovisionas Oracle Exadata Database Service con 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 centro de datos Google Cloud . Usas Google Cloud interfaces como la Google Cloud consola, Google Cloud CLI y las APIs para crear instancias de infraestructura de Exadata. Oracle configura y administra la infraestructura de procesamiento, almacenamiento y redes necesaria en un centro de datos dentro de una región Google Cloud en hardware dedicado a tu proyecto. |
Instancias de 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 una estructura de red de baja latencia. Cuando creas una instancia de infraestructura de Exadata, especificas la cantidad de servidores de bases de datos y servidores de almacenamiento que se deben aprovisionar. |
Clústeres de VMs de Exadata |
Dentro de una instancia de infraestructura de Exadata, puedes crear uno o más clústeres de VM de Exadata. Por ejemplo, puedes optar por crear y usar un clúster de VM de Exadata independiente para alojar las bases de datos que se requieren para cada una de tus unidades de negocios. Cada clúster de VM de Exadata contiene una o más VMs de Oracle Linux que alojan instancias de Oracle Database. Cuando creas un clúster de VM de Exadata, debes especificar lo siguiente:
Las VMs dentro 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 dentro del clúster de VMs de Exadata. Cuando creas el clúster de VM de Exadata, especificas la versión de Oracle Grid Infrastructure. También puedes elegir el tipo de licencia: usar tus propias licencias (BYOL) o elegir el modelo con licencia incluida. |
VCN de OCI y subredes | Cuando creas un clúster de VM de Exadata, se crea automáticamente una red virtual en la nube (VCN) virtual de OCI. La VCN tiene una subred de cliente y una subred de copia de seguridad con rangos de direcciones IP que tú especificas. La subred del cliente se usa para la conectividad desde tu red de VPC a las bases de datos de Oracle. La subred de copia de seguridad se usa para enviar copias de seguridad de la base de datos a OCI Object Storage. |
Cloud Router, Partner Interconnect y OCI DRG | Un Cloud Router adjunto a la VPC y una puerta de enlace de enrutamiento dinámico (DRG) adjunta a la VCN enrutan el tráfico entre tu red de VPC y la VCN. El tráfico fluye a través de una conexión de baja latencia que Google configura con la interconexión de socio. |
Zona privada de Cloud DNS | Cuando creas un clúster de VM de Exadata, se crea automáticamente una zona privada de Cloud DNS. Cuando tus 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. |
OCI Object Storage y OCI Service Gateway | De forma predeterminada, las copias de seguridad de las bases de datos de Oracle Exadata se almacenan en OCI Object Storage. Las copias de seguridad de la base de datos se enrutan al almacenamiento de objetos de OCI a través de una puerta de enlace de servicio. |
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 o Cloud VPN | Para conectar tu red local a la red de VPC enGoogle 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 en los recursos de Oracle Exadata con el servicio de OCI Monitoring. |
Productos usados
En esta arquitectura de referencia, se usan los siguientes productos Google Cloud :
- Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
- 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.
- 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.
- 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 con IPsec.
- 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.
- Filestore: Es un servicio que proporciona almacenamiento de archivos completamente administrado y de alto rendimiento en Google Cloud al que puedes conectarte con diversos tipos de clientes.
- Servicio de copia de seguridad y DR: Un servicio de copia de seguridad y recuperación seguro y administrado de forma centralizada para cargas de trabajo de Google Cloud que ayuda a proteger los datos de copia de seguridad de la eliminación accidental o maliciosa.
- Cloud DNS: Es un servicio que proporciona un servicio de DNS resistente y con baja latencia de la red mundial de Google.
En esta arquitectura de referencia, se usan los siguientes productos de Oracle:
- Oracle E-Business Suite: Es un conjunto de aplicaciones para operaciones comerciales, como finanzas, recursos humanos y cadena de suministro.
- Servicio de base de datos de Exadata en infraestructura dedicada: Es un servicio que te permite ejecutar instancias de Oracle Database en hardware de Exadata dedicado para ti.
- Object Storage: 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 en 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.
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. Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones del Google Cloud Framework de Well-Architected.
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.
Migración de bases de datos
Cuando planees migrar bases de datos locales a Oracle Database@Google Cloud, evalúa tu entorno de bases de datos actual y obtén recomendaciones de configuración y tamaño con la herramienta Database Migration Assessment (DMA).
Para obtener información sobre el procedimiento y las herramientas que puedes usar para migrar bases de datos de Oracle a Google Cloud, consulta el Oracle Migration Methods Advisor.
Antes de usar las bases de datos migradas en un entorno de producción, verifica la conectividad de tus aplicaciones a las bases de datos.
Opciones de almacenamiento
Para las VMs de Compute Engine en la arquitectura, puedes usar volúmenes de arranque de Hyperdisk o Persistent Disk. Los volúmenes de Hyperdisk proporcionan mejor rendimiento, flexibilidad y eficiencia que Persistent Disk. Con Hyperdisk Balanced, puedes aprovisionar IOPS y capacidad de procesamiento por separado y de forma dinámica, lo que te permite ajustar el volumen para una amplia variedad de cargas de trabajo.
Para almacenar archivos binarios de la aplicación, usa Filestore. Los archivos que almacenas en una instancia de Filestore Regional se replican de forma síncrona en tres zonas dentro de la región. Esta replicación ayuda a garantizar la alta disponibilidad y la solidez contra las interrupciones de zona. Para garantizar la solidez ante las interrupciones regionales, puedes replicar una instancia de Filestore en otra región. Para obtener más información, consulta Replicación de instancias.
Cuando diseñes el almacenamiento 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 de Oracle Database@Google Cloud
Elige un diseño de red que cumpla con tus requisitos comerciales y técnicos. Por ejemplo, puedes usar una sola red de VPC o varias redes de VPC. Para obtener más información, consulta Más información para seleccionar topologías de red para Oracle Database@Google Cloud.
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 mínimos de tamaño de la subred. Para obtener más información, consulta Planifica el espacio de direcciones IP en Oracle Database@Google Cloud.
Análisis de datos
Para el análisis avanzado, puedes usar Google Cloud Cortex Framework para transferir datos de tus aplicaciones de Oracle E-Business Suite a BigQuery. Para obtener más información, consulta Cortex Framework: integración con Oracle E-Business Suite.
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.
Para las subredes que usan las VMs de Exadata, Oracle recomienda que asignes rangos de direcciones IP privadas.
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 tiene una amplia variedad de permisos, incluidos algunos que podrían no ser necesarios. Puedes personalizar las cuentas de servicio dedicadas para que solo tengan los permisos esenciales. 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 tu arquitectura, implementa Identity-Aware Proxy (IAP) y 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 a 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 datos
De forma predeterminada, los datos que se almacenan en Hyperdisk, Persistent Disk y Filestore se encriptan conGoogle-owned and Google-managed encryption keys. Como una capa adicional de protección, puedes encriptar el Google-owned and managed key con claves que poseas y administres en Cloud Key Management Service (Cloud KMS). Para obtener más información, consulta Acerca de la encriptación de discos para volúmenes de Hyperdisk y Persistent Disk, y Encripta datos con claves de encriptación administradas por el cliente para Filestore.
De forma predeterminada, las bases de datos de Exadata usan la Encriptación de datos transparente (TDE), que te permite encriptar los datos sensibles que se almacenan en tablas y espacios de tablas.
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.
Seguridad y cumplimiento de Oracle Exadata
Oracle Exadata Database Service 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 del usuario 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 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 de la capa de aplicación ante fallas de la VM
Si fallan algunas (pero no todas) de las VMs que alojan las aplicaciones de Oracle E-Business Suite, las aplicaciones seguirán disponibles porque el balanceador de cargas reenvía las solicitudes a otras VMs de aplicaciones.
A veces, una VM de aplicación puede estar en ejecución y disponible, pero puede haber problemas con la aplicación. La aplicación puede congelarse, fallar o no tener suficiente memoria. En este caso, la VM no responderá a las verificaciones de estado del balanceador de cargas, y este no enrutará el tráfico a la VM que no responde.
Solidez ante interrupciones zonales
En una arquitectura regional, si una de las zonas tiene una interrupción, el balanceador de cargas reenvía las solicitudes a las instancias de las aplicaciones que se ejecutan en la otra zona. Filestore sigue estando disponible porque la arquitectura usa el nivel de servicio regional de Filestore.
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 de Hyperdisk Balanced High Availability, los datos se replican de forma síncrona entre dos zonas de la misma región.
Solidez ante interrupciones regionales
Si se produce una interrupción regional, las aplicaciones no estarán disponibles. Para reducir el tiempo de inactividad causado por las interrupciones regionales, puedes implementar el siguiente enfoque:
- Mantén una réplica pasiva (de conmutación por error) del nivel de aplicación en otra Google Cloud región.
- Crea una instancia de infraestructura de Exadata en espera 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 copias de seguridad de las bases de datos y recuperarlas con Oracle Autonomous Recovery Service.
- 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 restablecer la base de datos en producción y activar la aplicación en la región de conmutación por error.
- Usa políticas de enrutamiento de DNS para enrutar el tráfico a un balanceador de cargas externo 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. 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 en Oracle Database@Google Cloud. Para obtener información sobre los objetivos de nivel de servicio (SLO) de Oracle Exadata Database Service en infraestructura dedicada, consulta Objetivos de nivel de servicio para los servicios de nube pública de IaaS y PaaS de Oracle.
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.
Capacidad de Oracle Exadata
Puedes escalar la infraestructura de Exadata agregando servidores de bases de datos y servidores de almacenamiento según sea necesario. Después de agregar los servidores de almacenamiento o de bases de datos necesarios a la infraestructura de Exadata, para poder usar los recursos adicionales de CPU o almacenamiento, debes agregar la capacidad al clúster de VM de Exadata asociado. Para obtener más información, consulta Cómo escalar el almacenamiento y el procesamiento de Exadata.
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. La copia de seguridad y la DR almacenan 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 Backup and DR para copias de seguridad de instancias de Compute Engine.
Para garantizar la durabilidad de los datos en tus instancias de Filestore, puedes crear copias de seguridad y copias instantáneas de la instancia o usar Backup and DR para Filestore y sistemas de archivos.
De forma predeterminada, las copias de seguridad de las bases de datos en Oracle Exadata Database Service on Dedicated Infrastructure se almacenan en OCI Object Storage. Para lograr un RPO más bajo, puedes crear copias de seguridad de las bases de datos y recuperarlas con Oracle Autonomous Recovery Service.
Más consideraciones 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
- Google Cloud Well-Architected Framework: Confiabilidad
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.
Licencias de productos de Oracle
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. Para obtener más información, consulta Licensing Oracle Software in the Cloud Computing Environment (Licencias de software de Oracle en el entorno de computación en la nube).
Licencias de bases de datos de Oracle Exadata
Cuando creas un clúster de VM de Exadata, puedes traer tu propia licencia (BYOL) o usar una licencia que compraste como parte de tu pedido de Google Cloud Marketplace para Oracle Database@Google Cloud.
Los cargos de redes 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 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.
Imágenes de Oracle Linux
Para tus VMs, puedes usar imágenes de Oracle Linux que están disponibles en Compute Engine o puedes importar imágenes de Oracle Linux que compiles y mantengas. También puedes crear y usar imágenes personalizadas del SO 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.
Administración de bases de datos de Oracle Exadata
Oracle administra los servidores de bases de datos físicos, los servidores de almacenamiento y el hardware de redes en Oracle Exadata Database Service on Dedicated Infrastructure. Puedes administrar las instancias de la infraestructura de Exadata 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 Oracle Database@Google Cloud incluyen vínculos que puedes usar para ir directamente a las páginas pertinentes de 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.
Observabilidad para aplicaciones de Oracle
Para implementar la observabilidad en las cargas de trabajo de Oracle implementadas en Google Cloud, puedes usar los servicios de Google Cloud Observability o Oracle Enterprise Manager. Elige una estrategia de supervisión adecuada según tus requisitos y limitaciones. Por ejemplo, si ejecutas otras cargas de trabajo en Google Cloud además de las cargas de trabajo de Oracle, puedes usar los servicios de Google Cloud Observability para compilar un panel de operaciones unificado para todas las cargas de trabajo.
Documentación y asistencia de Oracle
Los productos de Oracle que se ejecutan en VMs de Compute Engine tienen preocupaciones operativas similares a los productos de Oracle que se ejecutan de forma local. Sin embargo, no es necesario que administres la infraestructura subyacente de procesamiento, redes y almacenamiento. Para obtener orientación sobre el funcionamiento y la administración de los productos de Oracle, consulta la documentación pertinente de Oracle.
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 (ID de documento 2688277.1).
Para obtener un resumen de las políticas de asistencia de Oracle para Oracle E-Business Suite, consulta Certificaciones de EBS.
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 para las cargas de trabajo que ejecutas en VMs. Elige un tipo de máquina adecuado según tus requisitos de rendimiento. Para obtener más información, consulta la guía de comparación y recurso de familias de máquinas.
Rendimiento de la red
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, puedes obtener un mayor ancho de banda de salida máximo si habilitas las redes de Tier_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 de la aplicación y la red de Oracle Exadata se enruta a través de una conexión de interconexión de socio de baja latencia que configura Google.
La infraestructura de Exadata usa RDMA a través de Ethernet convergente (RoCE) para redes de alto ancho de banda y baja latencia entre sus servidores de bases de datos y servidores de almacenamiento. Los servidores intercambian datos directamente en la memoria principal sin involucrar al procesador, la caché ni el sistema operativo.
Rendimiento del almacenamiento de Hyperdisk
La arquitectura que se describe en este documento usa volúmenes de Hyperdisk para todos los discos de arranque de las VMs que alojan las aplicaciones de Oracle E-Business Suite. 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:
- Tipos de máquinas que admiten Hyperdisk
- Límites de rendimiento de los Hyperdisk
- Optimiza el rendimiento de los Hyperdisks
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?
- 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
Autores:
- Autor: Kumar Dhanagopal | Desarrollador de soluciones entre productos
- Samantha He | Escritora técnica
Otros colaboradores:
- Andy Colvin | Ingeniero cinturón negro de bases de datos, Oracle en Google Cloud
- Balazs Pinter | Arquitecto de soluciones para socios de personal
- Celia Antonio | Ingeniera de Atención al cliente de bases de datos
- Johannes Passing | Arquitecto de soluciones de Cloud
- Majed Al-Halaseh | Ingeniero de Atención al Cliente, Modernización de la infraestructura
- Marc Fielding | Arquitecto de infraestructura de datos
- Mark Schlagenhauf | Escritor técnico, Herramientas de redes
- Michelle Burtoft | Gerente de producto sénior
- Nelson Gonzalez | Gerente de producto
- Rajesh Kasanagottu | Gerente de Ingeniería
- Sean Derrington | Gerente de grupo de productos, Almacenamiento
- Sekou Page | Gerente de Productos Salientes
- Souji Madhurapantula | Gerente de grupo de productos
- Victor Moreno | Gerente de producto, Herramientas de redes de Cloud