Arquitecturas para bases de datos Oracle en máquinas virtuales Azure

Artículo
06/13/2023

Se aplica a: ✔️ Máquinas virtuales Linux

En esta guía se detalla la información sobre la implementación de una base de datos de alta disponibilidad de Oracle en Azure. Además, en esta guía se profundiza en las consideraciones sobre la recuperación ante desastres. Estas arquitecturas se han creado en función de las implementaciones de los clientes. Esta guía solo se aplica a Oracle Database Enterprise Edition.

Si está interesado en obtener más información sobre cómo maximizar el rendimiento de su base de datos Oracle, consulte Diseñar e implementar una base de datos Oracle en Azure.

Requisitos previos

Reconocimiento de los diferentes conceptos de Azure, como zonas de disponibilidad
Oracle Database Enterprise Edition 12c o posterior
Conocimiento de las implicaciones de las licencias al utilizar las soluciones de este artículo

Alta disponibilidad para bases de datos de Oracle

Lograr una alta disponibilidad en la nube es una parte importante de la planificación y el diseño de cada organización. Azure ofrece zonas de disponibilidad y conjuntos de disponibilidad para su uso en regiones donde las zonas de disponibilidad no están disponibles. Para más información sobre cómo diseñar para la nube, consulte Opciones de disponibilidad para máquinas virtuales Azure.

Además de las herramientas y ofertas nativas de la nube, Oracle proporciona soluciones para alta disponibilidad que pueden configurarse en Azure:

En esta guía se describen las arquitecturas de referencia para cada una de estas soluciones.

Cuando migre o cree aplicaciones para la nube, le recomendamos que utilice patrones nativos de la nube como patrón de reintento y patrón de disyuntor. Para ver otros patrones que pueden ayudar a que su aplicación sea más resistente, consulte la Guía de patrones de diseño para la nube.

Oracle RAC en la nube

Oracle Real Application Cluster (RAC) es una solución de Oracle que ayuda a los clientes a lograr un alto rendimiento al tener muchas instancias que obtienen acceso a un almacenamiento de base de datos. Este patrón es una arquitectura compartida. Mientras que Oracle RAC se puede usar para alta disponibilidad en las instalaciones, Oracle RAC por sí solo no se puede usar para alta disponibilidad en la nube. Oracle RAC solo protege contra errores a nivel de instancia y no contra errores a nivel de bastidor o centro de datos. Por este motivo, Oracle recomienda usar Oracle Data Guard con la base de datos, ya sea de una sola instancia o RAC para lograr la alta disponibilidad.

Los clientes suelen necesitar un SLA elevado para ejecutar aplicaciones de misión crítica. Oracle no certifica ni admite actualmente Oracle RAC en Azure. Sin embargo, Azure ofrece características como zonas de disponibilidad y ventanas de mantenimiento planeado para ayudar en la protección frente a errores de nivel de instancia. Además de estas ofertas, puede usar Oracle Data Guard, Oracle GoldenGate y Oracle Sharding para lograr un alto rendimiento y resistencia. Estas tecnologías pueden ayudar a proteger sus bases de datos contra errores a nivel de rack, de centro de datos y geopolíticos.

Cuando ejecuta bases de datos Oracle en varias zonas de disponibilidad con Oracle Data Guard o GoldenGate, puede obtener un SLA de tiempo de actividad del 99,99 %. En las regiones Azure en las que aún no existen zonas de disponibilidad, puede utilizar conjuntos de disponibilidad y conseguir un SLA de tiempo de actividad del 99,95 %.

Nota:

Se puede tener un objetivo de tiempo de actividad mucho mayor que el SLA de tiempo de actividad proporcionado por Microsoft.

Recuperación ante desastres para bases de datos de Oracle

Al hospedar las aplicaciones críticas en la nube, es importante diseñar la alta disponibilidad y la recuperación ante desastres.

En Oracle Database Enterprise Edition, Oracle Data Guard es una característica útil para la recuperación ante desastres. Puede configurar una instancia de base de datos en espera en una región de Azure emparejada y configurar la conmutación por error de Data Guard para la recuperación ante desastres. Para evitar la pérdida de datos, le recomendamos que implemente una instancia de Oracle Data Guard Far Sync además de Active Data Guard.

Si su aplicación permite la latencia, considere la posibilidad de configurar la instancia de Data Guard Far Sync en una zona de disponibilidad distinta a la de su base de datos principal Oracle. Pruebe exhaustivamente la configuración. Use un modo de disponibilidad máxima para configurar el transporte sincrónico de los archivos de fase de puesta al día en la instancia de Far Sync. Estos archivos se transfieren de forma asincrónica a la base de datos en espera.

Es posible que su aplicación no permita la pérdida de rendimiento al configurar la instancia Far Sync en otra zona de disponibilidad en modo Disponibilidad máxima (sincrónica). Si no es así, puede configurar una instancia de Far Sync en la misma zona de disponibilidad que su base de datos principal. Para obtener una mayor disponibilidad, considere la posibilidad de configurar varias instancias de Far Sync cerca de su base de datos principal y al menos una instancia cercana a la base de datos en espera, si el rol realiza la transición.

Cuando se utilizan bases de datos Oracle Standard Edition, existen soluciones ISV que permiten configurar la alta disponibilidad y la recuperación ante desastres, como DBVisit Standby.

Arquitecturas de referencia

Protección de datos de Oracle

Oracle Data Guard garantiza la alta disponibilidad, la protección de datos y la recuperación ante desastres para los datos empresariales. Data Guard mantiene las bases de datos en espera como copias coherentes con las transacciones de la base de datos principal. En función de la distancia entre las bases de datos principal y secundaria y la tolerancia de la aplicación para la latencia, puede configurar la replicación sincrónica o asincrónica. Si la base de datos principal no está disponible debido a una interrupción planeada o no planeada, Data Guard puede cambiar cualquier base de datos en espera al rol principal, lo que minimiza el tiempo de inactividad.

Al usar Oracle Data Guard, también puede abrir su base de datos secundaria para solo lectura. Esta configuración se conoce como Active Data Guard. Oracle Database 12c presentó una característica denominada instancia de Data Guard Far Sync. Esta instancia le permite configurar una configuración de pérdida de datos cero de la base de datos de Oracle, sin tener que poner en peligro el rendimiento.

Nota

Active Data Guard requiere una licencia adicional. Esta licencia también es necesaria para usar la característica Far Sync. Póngase en contacto con su representante de Oracle para analizar las implicaciones de las licencias.

Oracle Data Guard con Fast-Start Failover

Oracle Data Guard con Fast-Start Failover (FSFO) puede proporcionar una mayor capacidad de recuperación configurando el agente en una máquina independiente. Data Guard Broker y la base de datos secundaria ejecutan el observador y observan si se produce un tiempo de inactividad en la base de datos principal. Este enfoque también permite la redundancia en la configuración del observador de Data Guard.

Con Oracle Database versión 12.2 y versiones posteriores, también es posible configurar varios observadores con una única configuración de agente de Oracle Data Guard. Esta configuración proporciona disponibilidad adicional, en caso de que un observador y la base de datos secundaria experimenten tiempos de inactividad. Data Guard Broker es ligero y se puede hospedar en una máquina virtual relativamente pequeña. Para más información sobre Data Guard Broker y sus ventajas, consulte Conceptos de Oracle Data Guard Broker.

En el siguiente diagrama se presenta una arquitectura recomendada para usar Oracle Data Guard en Azure con zonas de disponibilidad. Esta arquitectura le permite obtener un SLA de tiempo de actividad de VM del 99,99 %.

En el diagrama anterior, el sistema cliente accede a una aplicación personalizada con Oracle backend mediante la web. El front-end de la web está configurado en un equilibrador de carga. El front-end de la web realiza una llamada al servidor de aplicaciones adecuado para administrar el trabajo. El servidor de aplicaciones consulta la base de datos principal de Oracle. La base de datos de Oracle se ha configurado con una máquina virtual con optimización para memoria de hiperproceso con vCPU principales restringidas para ahorrar en los costos de licencia y maximizar el rendimiento. Se usan varios discos Premium o Ultra (Managed Disks) para el rendimiento y la alta disponibilidad.

Las bases de datos de Oracle se colocan en varias zonas de disponibilidad para lograr la alta disponibilidad. Cada zona consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. Para garantizar la resistencia, se configuran un mínimo de tres zonas independientes en todas las regiones habilitadas. La separación física de las zonas de disponibilidad dentro de una región protege los datos frente a los errores del centro de datos. Además, se configuran dos observadores FSFO en dos zonas de disponibilidad para iniciar y conmutar por error la base de datos a la secundaria cuando se produce una interrupción.

Puede configurar otros observadores o bases de datos en espera en una zona de disponibilidad diferente, AZ 1, en este caso, que la zona mostrada en la arquitectura anterior. Por último, Oracle Enterprise Manager (OEM) supervisa el tiempo de actividad y el rendimiento de las bases de datos Oracle. El OEM también le permite generar varios informes de rendimiento y uso.

En regiones en las que no se admiten zonas de disponibilidad, puede utilizar conjuntos de disponibilidad para implementar su Oracle Database en alta disponibilidad. Los conjuntos de disponibilidad permiten lograr un tiempo de actividad de VM del 99,95 %. El siguiente diagrama es una arquitectura de referencia de este uso:

Nota:

Dado que solo se implementa una instancia de OEM, no es necesario colocar la VM de Oracle Enterprise Manager en un conjunto de disponibilidad.
Los discos Ultra no se admiten actualmente en una configuración de conjunto de disponibilidad.

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync proporciona la funcionalidad de protección de pérdida de datos cero para Oracle Database. Esta funcionalidad le permite protegerse frente a la pérdida de datos en el caso de que se produzca un error en la máquina de base de datos. Oracle Data Guard Far Sync tiene que estar instalado en una máquina virtual independiente. Far Sync es una instancia ligera de Oracle que solo tiene un archivo de control, un archivo de contraseña, spfile y registros en espera. No hay archivos de datos ni archivos de registro redo.

Para una protección de pérdida de datos cero, debe haber comunicación sincrónica entre la base de datos principal y la instancia de Far Sync. La instancia de Far Sync recibe la fase de puesta al día de la principal de forma sincrónica y la reenvía inmediatamente a todas las bases de datos en espera de forma asincrónica. Esta configuración también reduce la sobrecarga en la base de datos principal, ya que solo tiene que enviar la fase de puesta al día a la instancia de Far Sync, en lugar de a todas las bases de datos en espera. Si se produce un error en una instancia de Far Sync, Data Guard usa automáticamente el transporte asincrónico a la base de datos secundaria desde la base de datos principal para mantener una protección de pérdida de datos casi cero. Para una mayor capacidad de recuperación, los clientes pueden implementar varias instancias de Far Sync por cada instancia de base de datos, incluidas la primaria y las secundarias.

En el siguiente diagrama se presenta una arquitectura de alta disponibilidad que usa Oracle Data Guard Far Sync:

En la arquitectura anterior, hay una instancia de Far Sync implementada en la misma zona de disponibilidad que la instancia de base de datos para reducir la latencia entre las dos. En los casos en los que la aplicación sea sensible a la latencia, considere la posibilidad de implementar la base de datos y la instancia o instancias de Far Sync en un grupo de selección de ubicación de proximidad.

El siguiente diagrama es una arquitectura que utiliza Oracle Data Guard FSFO y Far Sync para lograr alta disponibilidad y recuperación de desastres:

Oracle GoldenGate

GoldenGate permite el intercambio y la manipulación de datos en el nivel de transacción entre varias plataformas heterogéneas en toda la empresa. Mueve las transacciones confirmadas con integridad de transacción y mínima sobrecarga de la infraestructura existente. Su arquitectura modular le ofrece la flexibilidad necesaria para extraer y replicar registros de datos seleccionados, cambios transaccionales y cambios en el lenguaje de definición de datos (DDL) en varias topologías.

Oracle GoldenGate le permite configurar la base de datos para la alta disponibilidad al proporcionar replicación bidireccional. Este enfoque le permite establecer una configuración arquitectura multimaestro o activo-activo. En el siguiente diagrama se presenta una arquitectura recomendada para una configuración activo-activo de Oracle GoldenGate en Azure. En la siguiente arquitectura, la base de datos de Oracle se ha configurado con una máquina virtual con optimización para memoria de hiperproceso con vCPU principales restringidas para ahorrar en los costos de licencia y maximizar el rendimiento. La arquitectura usa varios discos premium o ultra (discos gestionados) para mejorar el rendimiento y la disponibilidad.

Nota

Se puede configurar una arquitectura similar con conjuntos de disponibilidad en regiones en las que las zonas de disponibilidad no están disponibles actualmente.

Oracle GoldenGate tiene procesos como la extracción, el bombeo y la replicación que le ayudan a replicar de forma asincrónica los datos de un servidor de base de datos de Oracle en otro. Estos procesos le permiten configurar una replicación bidireccional para garantizar una alta disponibilidad de su base de datos si se produce un tiempo de inactividad a nivel de zona de disponibilidad.

En el diagrama anterior, el proceso Extract se ejecuta en el mismo servidor que su base de datos Oracle. Los procesos Data Pump y Replicat se ejecutan en un servidor independiente en la misma zona de disponibilidad. El proceso de replicación se usa para recibir datos de la base de datos en la otra zona de disponibilidad y confirmar los datos en la base de datos de Oracle de su zona de disponibilidad. Del mismo modo, el proceso Data Pump envía los datos que extrae el proceso Extract al proceso Replicat en la otra zona de disponibilidad

Aunque el diagrama de arquitectura anterior muestra los procesos Data Pump y Replicat configurados en un servidor independiente, puede configurar todos los procesos de Oracle GoldenGate en el mismo servidor, en función de la capacidad y el uso de su servidor. Consulte siempre el informe AWR y las métricas de Azure para comprender el patrón de uso del servidor.

Al configurar la replicación bidireccional de Oracle GoldenGate en distintas zonas de disponibilidad o en distintas regiones, es importante asegurarse de que la latencia entre los distintos componentes es aceptable para su aplicación. La latencia entre zonas de disponibilidad y regiones puede variar. La latencia depende de varios factores. Se recomienda configurar pruebas de rendimiento entre el nivel de aplicación y el nivel de base de datos en diferentes zonas o regiones de disponibilidad. Las pruebas pueden confirmar que la configuración cumple los requisitos de rendimiento de la aplicación.

La capa de aplicación se puede configurar en su propia subred y la capa de base de datos se puede separar en su propia subred. Cuando sea posible, considere la posibilidad de usar Azure Application Gateway para equilibrar la carga del tráfico entre los servidores de aplicaciones. Application Gateway es un equilibrador de carga sólido del tráfico web. Proporciona la afinidad de sesiones basada en cookies que mantiene una sesión de usuario en el mismo servidor, lo que minimiza los conflictos en la base de datos. Las alternativas a Application Gateway son Azure Load Balancer y Azure Traffic Manager.

Oracle Sharding

Sharding es un patrón de capa de datos que se presentó en Oracle 12.2. Permite particionar y escalar horizontalmente los datos entre bases de datos independientes. Es una arquitectura que no comparte nada en la que cada base de datos se hospeda en una máquina virtual dedicada. Este patrón permite un alto rendimiento de lectura y escritura, además de resistencia y mayor disponibilidad.

Este patrón elimina los únicos puntos de error, proporciona aislamiento de errores y permite las actualizaciones graduales sin tiempo de inactividad. El tiempo de inactividad de una partición o de un error de nivel de centro de datos no afecta al rendimiento o a la disponibilidad de las demás particiones en otros centros de datos.

Sharding es adecuado para aplicaciones OLTP de alto rendimiento que no se pueden permitir ningún tiempo de inactividad. Se garantiza que todas las filas con la misma clave de fragmentación se encuentran siempre en el mismo fragmento. Este hecho aumenta el rendimiento, lo que proporciona una alta coherencia. Las aplicaciones que usan particionamiento deben tener un modelo de datos bien definido y una estrategia de distribución de datos, como hash coherente, intervalo, lista o compuesto. La estrategia accede principalmente a los datos mediante una clave de particionamiento, por ejemplo, customerId o accountNum. El particionamiento también le permite almacenar conjuntos concretos de datos más cerca de los clientes finales, lo que ayuda a cumplir los requisitos de rendimiento y cumplimiento.

Se recomienda replicar las particiones para garantizar una alta disponibilidad y la recuperación ante de desastre. Esta configuración se puede realizar mediante tecnologías de Oracle como Oracle Data Guard u Oracle GoldenGate. Una unidad de replicación puede ser una partición, una parte de una partición o un grupo de particiones. Una interrupción o ralentización de uno o más particiones no afecta a la disponibilidad de una base de datos particionada.

Para lograr la alta disponibilidad, las particiones en espera se pueden colocar en la misma zona de disponibilidad donde se encuentran las particiones principales. En el caso de la recuperación ante desastres, las particiones en espera pueden encontrarse en otra región. También puede implementar particiones en varias regiones para dar servicio al tráfico de esas regiones. Para más información sobre cómo configurar la alta disponibilidad y la replicación de la base de datos particionada, consulte Alta disponibilidad de nivel de partición.

Oracle Sharding consta principalmente de los siguientes componentes. Para obtener más información, vea Información general de la publicación de Oracle.

Catálogo de particiones. Base de datos de Oracle de propósito especial que es un almacén persistente de todos los datos de configuración de las bases de datos de particiones. Todos los cambios de configuración, como la adición o la eliminación de particiones, la asignación de los datos y DDL en una base de datos de particiones se inician en el catálogo de particiones. El catálogo de particiones también contiene la copia maestra de todas las tablas duplicadas en una SDB.

El catálogo de particiones usa vistas materializadas para replicar automáticamente los cambios en las tablas duplicadas en todas las particiones. La base de datos del catálogo de particiones también actúa como un coordinador de consultas que se usa para procesar consultas de varias particiones y consultas que no especifican una clave de particionamiento.

Se recomienda utilizar Oracle Data Guard con zonas de disponibilidad o conjuntos de disponibilidad para la alta disponibilidad del catálogo de particiones es un procedimiento recomendado. La disponibilidad del catálogo de particiones no afecta a la disponibilidad de la base de datos particionada. Un tiempo de inactividad en el catálogo de particiones solo afecta a las operaciones de mantenimiento y a las consultas de varias particiones durante el breve período en que se completa la conmutación por error de Data Guard. SDB continúa enrutando y ejecutando transacciones en línea. Una interrupción del catálogo no las afecta.
Directores de particiones. Servicios ligeros que deben implementarse en cada zona de disponibilidad o región en la que residen las particiones. Los directores de particiones son los administradores de servicios globales implementados en el contexto de Oracle Sharding. Para una alta disponibilidad, se recomienda implementar al menos un director de particiones en cada zona de disponibilidad en la que existan sus particiones.

Al conectarse inicialmente a la base de datos, el director de particiones configura la información de enrutamiento y almacena en caché la información de las solicitudes posteriores, que omiten el director de particiones. Una vez que la sesión se establece con una partición, se admiten todas las consultas SQL y DML y se ejecutan en el ámbito de la partición especificada. Este enrutamiento es rápido y se usa para todas las cargas de trabajo OLTP que realizan transacciones dentro de las particiones. Se recomienda usar el enrutamiento directo para todas las cargas de trabajo OLTP que requieran el máximo rendimiento y disponibilidad. La caché de enrutamiento se actualiza automáticamente cuando una partición deja de estar disponible o se producen cambios en la topología de particionamiento.

Para el enrutamiento dependiente de los datos de alto rendimiento, Oracle recomienda el uso de un grupo de conexiones al acceder a los datos de la base de datos particionada. Los grupos de conexiones de Oracle, las bibliotecas específicas del lenguaje y los controladores admiten Oracle Sharding. Para más información, consulte Descripción general de partición de Oracle.
Servicio global. El servicio global es similar al servicio de base de datos normal. Además de todas las propiedades de un servicio de base de datos, un servicio global tiene propiedades para bases de datos fragmentadas. Estas propiedades incluyen afinidad de región entre clientes y tolerancia de retardo de replicación y particiones. Solo es necesario crear un servicio global para leer y escribir datos hacia y desde una base de datos particionada. Al usar Active Data Guard y configurar réplicas de solo lectura de las particiones, puede crear otro servicio global para cargas de trabajo de solo lectura. El cliente puede usar estos servicios globales para conectarse a la base de datos.
Bases de datos de particiones. Las bases de datos de particiones son las bases de datos de Oracle. Cada base de datos se replica mediante Oracle Data Guard en una configuración de Broker con la opción FSFO habilitada. No es necesario configurar la conmutación por error y la replicación de Data Guard en cada partición. Este aspecto se configura e implementa automáticamente cuando se crea la base de datos compartida. Si se produce un error en una partición determinada, Oracle Sharding conmuta por error las conexiones de base de datos del servidor principal al modo en espera.

Puede implementar y administrar las bases de datos particionadas de Oracle con dos interfaces: La GUI Oracle Enterprise Manager Cloud Control o la utilidad de línea de comandos GDSCTL. Incluso puede supervisar la disponibilidad y el rendimiento de las distintas particiones mediante el control de la nube. El comando GDSCTL DEPLOY crea automáticamente las particiones y sus respectivos clientes de escucha. Además, este comando implementa automáticamente la configuración de replicación usada para la alta disponibilidad en el nivel de partición especificada por el administrador.

Existen distintas formas de particionar una base de datos:

Particionamiento administrado por el sistema: distribuye automáticamente entre particiones mediante el particionamiento.
Particionamiento definido por el usuario: le permite especificar la asignación de los datos a las particiones, lo que funciona bien cuando existen requisitos normativos o de localización de datos.
Particionamiento compuesto: una combinación de particionamiento administrado por el sistema y definido por el usuario para diferentes espacios de particiones
Subparticiones de tabla: similar a una tabla con particiones normal.

Para más información, consulte Métodos de particionamiento.

Una base de datos particionada es similar a una base de datos única para aplicaciones y desarrolladores. Al migrar a una base de datos particionada, planee cuidadosamente para comprender qué tablas están duplicadas frente a particionadas.

Las tablas duplicadas se almacenan en todas las particiones, mientras que las tablas particionadas se distribuyen entre diferentes particiones. Se recomienda duplicar las tablas pequeñas y dimensionales y distribuir o particionar las tablas de hechos. Los datos se pueden cargar en la base de datos particionada usando el catálogo de particiones como coordinador central o ejecutando el bombeo de datos en cada partición. Para más información, consulte Migración de datos a una base de datos particionada.

Oracle Sharding con Data Guard

Oracle Data Guard se puede usar para el particionamiento con métodos de particionamiento compuestos, administrados por el sistema y definidos por el usuario.

En el siguiente diagrama se presenta una arquitectura de referencia para Oracle Sharding con Oracle Data Guard que se usa para la alta disponibilidad de cada partición. El diagrama de arquitectura muestra un método de particionamiento compuesto. Es probable que el diagrama de arquitectura difiera para aplicaciones con distintos requisitos de localización de datos, equilibrio de carga, alta disponibilidad y recuperación ante desastres. Las aplicaciones pueden usar un método diferente para particionamiento. Oracle Sharding le permite cumplir estos requisitos y escalar horizontal y eficazmente mediante estas opciones. Incluso puede implementarse una arquitectura similar mediante Oracle GoldenGate.

El particionamiento administrado por el sistema es el más fácil de configurar y administrar. El particionamiento definido por el usuario o el particionamiento compuesto son idóneos para escenarios en los que los datos y la aplicación están distribuidos geográficamente o en escenarios en los que es necesario tener control sobre la replicación de cada partición.

En la arquitectura anterior, el particionamiento compuesto se usa para distribuir geográficamente los datos y escalar horizontalmente las capas de aplicación. El particionamiento compuesto es una combinación de particionamiento administrado por el sistema y definido por el usuario y, por tanto, proporciona las ventajas de ambos métodos. En el escenario anterior, en primer lugar, se particionan los datos entre varios espacios de particiones separados por región. Después, los datos se particionan aún más mediante el uso de hash consistentes a través de múltiples particiones en el espacio de particiones.

Cada espacio de particiones contiene varios grupos de particiones. Cada grupo de particiones tiene varias particiones y es una "unidad" de replicación. Cada grupo de particiones contiene todos los datos del espacio de particiones. Los grupos de particiones A1 y B1 son grupos de particiones principales, mientras que los grupos de particiones A2 y B2 están en espera. Puede elegir que las particiones individuales sean la unidad de replicación, en lugar de un grupo de particiones.

En la arquitectura anterior, se implementa un director de particiones o Administrador de servicios globales (GSM) en cada zona de disponibilidad para alta disponibilidad. Se recomienda implementar al menos un director de particiones o GSM por centro de datos/región. Además, se implementa una instancia del servidor de aplicaciones en cada zona de disponibilidad que contenga un grupo de particiones. Esta configuración permite que la aplicación conserve la latencia baja entre el servidor de aplicaciones y la base de datos/grupo de particiones. Si se produce un error en una base de datos, el servidor de aplicaciones de la misma zona que la base de datos en espera puede controlar las solicitudes una vez que se produce la transición del rol de base de datos. Azure Application Gateway y el director de particiones realizan un seguimiento de la latencia de solicitud y respuesta y redirigen las solicitudes en consecuencia.

Desde el punto de vista de una aplicación, el sistema cliente realiza una solicitud a Azure Application Gateway u otras tecnologías de equilibrio de carga en Azure que redirige la solicitud a la región más cercana al cliente. Azure Application Gateway también admite sesiones temporales, por lo que las solicitudes procedentes del mismo cliente se redirigen al mismo servidor de aplicaciones. El servidor de aplicaciones usa una agrupación de conexiones en los controladores de acceso a datos. Esta característica está disponible en controladores como JDBC, ODP.NET y OCI Los controladores pueden reconocer las claves de particionamiento especificadas como parte de la solicitud. Oracle Universal Connection Pool (UCP) para los clientes JDBC puede permitir que los clientes de aplicaciones que no son de Oracle, como Apache Tomcat e IIS, funcionen con Oracle Sharding. Para más información, consulte Información general sobre el grupo compartido de UCP para partición de bases de datos.

Durante la solicitud inicial, el servidor de aplicaciones se conecta al director de particiones de su región para obtener información de enrutamiento de la partición a la que se debe redirigir la solicitud. En función de la clave de particionamiento pasada, el director redirige el servidor de aplicaciones a la partición correspondiente. El servidor de aplicaciones almacena en caché esta información mediante la creación de una asignación y, en las solicitudes posteriores, se omite el director de particiones y redirige las solicitudes directamente a la partición.

Oracle Sharding con GoldenGate

En el siguiente diagrama se muestra una arquitectura de referencia para Oracle Sharding con Oracle GoldenGate que se usa para la alta disponibilidad en la región de cada partición. A diferencia de la arquitectura anterior, esta arquitectura solo representa la alta disponibilidad dentro de una única región Azure, con múltiples zonas de disponibilidad. Puede implementar una base de datos fragmentada de alta disponibilidad multirregional, similar al ejemplo anterior, mediante Oracle GoldenGate.

La arquitectura de referencia anterior usa el método de particionamiento administrado por el sistema para particionar los datos. Dado que la replicación de Oracle GoldenGate se realiza en un nivel de fragmento, la mitad de los datos replicados en una partición se pueden replicar en otra partición. La otra mitad se puede replicar en una partición diferente.

La forma en que se replican los datos depende del factor de replicación. Con un factor de replicación dos, tiene dos copias de cada fragmento de datos en las tres particiones del grupo de particiones. De forma similar, con un factor de replicación tres y tres particiones en el grupo de particiones, todos los datos de cada partición se replica en todas las demás particiones del grupo de particiones. Cada partición del grupo de particiones puede tener un factor de replicación diferente. Esta configuración le ayuda a definir el diseño de alta disponibilidad y recuperación ante desastres de forma eficaz dentro de un grupo de particiones y entre varios grupos de particiones.

En la arquitectura anterior, el grupo de particiones A y el grupo de particiones B contienen los mismos datos, pero residen en zonas de disponibilidad diferentes. Si tanto el grupo de particiones A como el grupo de particiones B tienen el mismo factor de replicación tres, cada fila o fragmento de la tabla con particiones se replica seis veces en los dos grupos de particiones. Si el grupo de particiones A tiene un factor de replicación tres y el grupo de particiones B tiene un factor de replicación dos, cada fila o fragmento se replica cinco veces en los dos grupos de particiones.

Esta configuración evita la pérdida de datos si se produce un error de nivel de instancia o de zona de disponibilidad. La capa de aplicación es capaz de leer y escribir en cada partición. Para minimizar los conflictos, Oracle Sharding designa un fragmento maestro para cada intervalo de valores hash. Esta característica garantiza que las solicitudes de escritura para un fragmento determinado se dirigen al fragmento correspondiente. Además, Oracle GoldenGate proporciona la detección y resolución automática de conflictos para controlar cualquier conflicto que pueda surgir. Para obtener más información y conocer las limitaciones de la implementación de GoldenGate con Oracle Sharding, vea el Uso de Oracle GoldenGate con una base de datos particionada.

En la arquitectura anterior, se implementa un director de particiones o GSM en cada zona de disponibilidad para alta disponibilidad. Se recomienda implementar al menos un director de particiones o GSM por centro de datos o región. Se implementa una instancia del servidor de aplicaciones en cada zona de disponibilidad que contenga un grupo de particiones. Esta configuración permite que la aplicación conserve la latencia baja entre el servidor de aplicaciones y la base de datos/grupo de particiones. Si se produce un error en una base de datos, el servidor de aplicaciones de la misma zona que la base de datos en espera puede controlar las solicitudes una vez que se produce la transición del rol de base de datos. Azure Application Gateway y el director de particiones realizan un seguimiento de la latencia de solicitud y respuesta y redirigen las solicitudes en consecuencia.

Aplicación de revisión y mantenimiento

Cuando implementa sus cargas de trabajo de Oracle en Azure, Microsoft se encarga de todos los parches a nivel del sistema operativo del host. Microsoft comunica con antelación cualquier mantenimiento planeado de nivel de sistema operativo a los clientes. Nunca se aplican revisiones a dos servidores de dos zonas de disponibilidad diferentes simultáneamente. Para más información sobre el mantenimiento y la aplicación de revisiones de máquinas virtuales, consulte Opciones de disponibilidad para Azure Virtual Machines.

La aplicación de revisiones al sistema operativo de una máquina virtual se puede automatizar mediante Azure Automation Update Management. La aplicación de revisiones y el mantenimiento de una base de datos de Oracle se pueden automatizar y programar mediante Azure Pipelines o Azure Automation Update Management para minimizar el tiempo de inactividad. Para obtener más información sobre la entrega continua y las implementaciones azules y verdes, consulte Técnicas de exposición progresiva.

Consideraciones sobre la arquitectura y el diseño

Considere la posibilidad de usar una máquina virtual con optimización para memoria de hiperproceso con vCPU principales restringidas para VM de Oracle Database para ahorrar en los costos de licencia y maximizar el rendimiento. Use varios discos Premium o Ultra (Managed Disks) para el rendimiento y la disponibilidad.
Cuando se usan discos administrados, el nombre del disco o dispositivo puede cambiar al reiniciarse. Se recomienda usar el UUID del dispositivo en lugar del nombre para asegurarse de que los montajes se conservan en sprite del reinicio. Para obtener más información, vea Agregar el nuevo sistema de archivos a /etc/fstab.
Use las zonas de disponibilidad para lograr una alta disponibilidad en la región.
Considere la posibilidad de usar discos Ultra si están disponibles o discos Premium para la base de datos de Oracle.
Considere la posibilidad de configurar una base de datos de Oracle en espera en otra región de Azure mediante Oracle Data Guard.
Considere la posibilidad de usar grupos de selección de ubicación de proximidad para reducir la latencia entre la aplicación y la capa de base de datos.
El ancho de banda de red máximo de las máquinas virtuales de Azure es (normalmente) mayor que el rendimiento máximo del disco en la misma SKU. Puede lograr un mayor rendimiento en la misma SKU de máquina virtual, o usar una SKU de máquina virtual más pequeña, mediante el almacenamiento en red de alto rendimiento y baja latencia, como Azure NetApp Files. para la base de datos.
Configure Oracle Enterprise Manager para la administración, la supervisión y el registro.
Considere la posibilidad de usar la administración automática del almacenamiento de Oracle para simplificar la administración del almacenamiento de la base de datos.
Use Azure Pipelines para administrar la aplicación de revisión y las actualizaciones de la base de datos sin tiempo de inactividad.
Ajuste el código de su aplicación para agregar patrones nativos de la nube que puedan ayudar a que su aplicación sea más resistente. Considere los patrones como el patrón de reintento, el patrón de disyuntor y otros definidos en la guía de patrones de diseño en la nube.

Pasos siguientes

Revise los siguientes artículos de referencia de Oracle que se aplican a su escenario.