Arquitecturas para Oracle Database Enterprise Edition en Azure

Artículo
04/18/2023

Se aplica a: ✔️ Máquinas virtuales Linux

Azure es el hogar de todas las cargas de trabajo de Oracle, incluidas las que necesitan seguir ejecutándose de forma óptima en Azure con Oracle. Si tiene el paquete de diagnóstico de Oracle o el repositorio automático de cargas de trabajo (AWR), puede recopilar datos sobre las cargas de trabajo. Use estos datos para evaluar la carga de trabajo de Oracle, ajustar las necesidades de los recursos y migrar la carga de trabajo a Azure. Las diversas métricas proporcionadas por Oracle en estos informes pueden proporcionar un conocimiento del rendimiento de las aplicaciones y la utilización de la plataforma.

Este artículo le ayuda a entender cómo preparar una carga de trabajo de Oracle para ejecutarla en Azure y a explorar las mejores soluciones de arquitectura para proporcionar un rendimiento más óptimo en la nube. Los datos proporcionados por Oracle en Statspack y aún más, en su descendiente, el AWR, le ayudan a desarrollar expectativas claras. Estas expectativas incluyen los límites de la optimización física a través de la arquitectura, las ventajas de la optimización lógica del código de la base de datos y el diseño general de la base de datos.

Diferencias entre los dos entornos

Al migrar aplicaciones locales a Azure, tenga en cuenta algunas diferencias importantes entre los dos entornos.

Una diferencia importante es que en una implementación en Azure, los recursos, como las máquinas virtuales, discos y redes virtuales, se comparten con otros clientes. Además, los recursos pueden estar limitados en función de los requisitos. En lugar de centrarse en evitar errores, Azure se centra más bien en superar los errores. El primer enfoque intenta aumentar el tiempo medio entre los errores (MTBF) y el segundo intenta reducir el tiempo medio de recuperación (MTTR).

En la tabla siguiente se enumeran algunas de las diferencias entre una implementación local y una implementación en Azure de una base de datos de Oracle.

	Implementación local	Implementación en Azure
Redes	LAN/WAN	Redes definidas por software (SDN)
Grupo de seguridad	Herramientas de restricción de IP y puerto	Grupo de seguridad de red (NSG)
Resistencia	MTBF	MTTR
Mantenimiento planeado	Aplicación de revisiones/actualizaciones	Conjuntos de disponibilidad con aplicación de revisiones o actualizaciones administradas por Azure
Recurso	Dedicado	Compartido con otros clientes
Regiones	Centros de datos	Pares de región
Storage	SAN/discos físicos	Almacenamiento administrado por Azure
Escala	Escalado vertical	Escalado horizontal

Requisitos

Considere los siguientes requisitos antes de iniciar la migración:

Determine el uso real de LA CPU. Oracle concede licencias por núcleo, lo que significa que dimensionar las necesidades de vCPU puede ser esencial para ayudarle a reducir los costos.
Determine el tamaño de la base de datos, el almacenamiento de copia de seguridad y la tasa de crecimiento.
Determine los requisitos de E/S, que puede calcular en función de los informes de Oracle Statspack y de AWR. También puede calcular los requisitos de las herramientas de supervisión de almacenamiento disponibles en el sistema operativo.

Opciones de configuración

Es una buena idea generar un informe de AWR para obtener algunas métricas que le ayuden a tomar decisiones sobre la configuración. Por tanto, hay cuatro áreas posibles que se pueden ajustar para mejorar el rendimiento en el entorno de Azure:

Tamaño de la máquina virtual
Capacidad de proceso de la red
Tipos y configuraciones de disco
Configuración de la caché de disco

Generar un informe de AWR

Si tiene una base de datos de Oracle Enterprise Edition y está planeando migrar a Azure, tiene varias opciones. Si tiene el paquete de diagnósticos para sus instancias de Oracle, puede ejecutar el informe de AWR de Oracle para obtener las métricas, por ejemplo, IOPS, Mbps y GiBs. En el caso de las bases de datos sin la licencia del paquete de diagnósticos o de una base de datos Standard Edition de Oracle, puede recopilar las mismas métricas importantes con un informe de Statspack después de recopilar instantáneas manuales. Las principales diferencias entre estos dos métodos de informe son que AWR se recopila automáticamente y que proporciona más información sobre la base de datos que Statspack.

Considere la posibilidad de ejecutar el informe de AWR durante las cargas de trabajo normales y máximas, para poder comparar ambas. Para recopilar la carga de trabajo más precisa, considere un informe de ventana ampliado de una semana, en lugar de un día. AWR proporciona promedios como parte de sus cálculos en el informe. De forma predeterminada, el repositorio de AWR conserva ocho días de datos y toma instantáneas en intervalos de una hora.

Para una migración de centro de datos, debería recopilar informes para dimensionar los sistemas de producción. Calcule las copias de bases de datos restantes utilizadas para las pruebas de los usuarios, las pruebas y el desarrollo mediante porcentajes. Por ejemplo, calcule el 50 por ciento del tamaño de producción.

Para ejecutar un informe de AWR desde la línea de comandos, use el siguiente comando:

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Métricas clave

El informe le pedirá la siguiente información:

Tipo de informe: HTML o TEXT. El tipo HTML proporciona más información.
Número de días de instantáneas que se mostrarán. Por ejemplo, para intervalos de una hora, un informe de una semana genera 168 id. de instantánea.
El SnapshotID inicial de la ventana de informe.
El SnapshotID final de la ventana de informe.
Nombre del informe que crea el script de AWR.

Si va a ejecutar el informe AWR en un clúster de aplicaciones real (RAC), el informe de la línea de comandos es el archivo awrgrpt.sql en lugar de awrrpt.sql. El informe g crea un informe para todos los nodos de la base de datos RAC en un único informe. Este informe elimina la necesidad de ejecutar un informe en cada nodo RAC.

Puede obtener las siguientes métricas del informe de AWR:

Nombre de la base de datos, nombre de la instancia y nombre del host
Versión de base de datos para la compatibilidad de Oracle
Núcleos de CPU
SGA/PGA y asesores para informarle de si está subdimensionado
Memoria total en GB
Porcentaje de CPU ocupada
CPU DE BD
IOPS (lectura y escritura)
Mbps (lectura/escritura)
Capacidad de proceso de la red
Tasa de latencia de red (baja/alta)
Principales eventos de espera
Configuración de parámetros para la base de datos
Si la base de datos es RAC, Exadata o usa características o configuraciones avanzadas

Tamaño de la máquina virtual

Estos son algunos de los pasos que puede seguir para configurar el tamaño de la máquina virtual para obtener un rendimiento óptimo.

La estimación del tamaño de la máquina virtual se basa en el uso de CPU, memoria y E/S según el informe de AWR

Consulte los primeros cinco eventos de primer plano cronometrados, que indican dónde están los cuellos de botella del sistema. Por ejemplo, en el diagrama siguiente, la sincronización de archivos de registro está en la primera posición. Indica el número de esperas necesarias antes de que el redactor de registros escriba el búfer de registro en el archivo de registro de fase de puesta al día. Estos resultados indican que son necesarios almacenamiento o discos de mejor rendimiento. Además, también se muestra en el diagrama el número de núcleos de CPU y la memoria.

Captura de pantalla que muestra la sincronización del archivo de registro en la parte superior de la tabla.

El siguiente diagrama muestra el total de E/S de lectura y escritura. Hubo 59 GB de lectura y 247,3 GB de escritura durante la realización del informe.

Elegir una máquina virtual

En función de la información recopilada en el informe de AWR, el paso siguiente consiste en elegir una máquina virtual de un tamaño similar que cumpla los requisitos. Para más información sobre tamaños de máquinas virtuales disponibles, consulte Tamaños de máquina virtual optimizada para memoria.

Ajustar el tamaño de la máquina virtual con una serie de máquina virtual similar en función del valor de ACU

Una vez que eligió la máquina virtual, preste atención a la unidad de proceso de Azure (ACU) de la máquina virtual. Puede elegir una máquina virtual diferente en función del valor de ACU que mejor se adapte a sus necesidades. Para más información, consulte Unidad de proceso de Azure (ACU).

Captura de pantalla de la página de unidades de ACU.

Capacidad de proceso de la red

El diagrama siguiente muestra la relación que existe entre el rendimiento y las E/S por segundo (IOPS):

Diagrama que muestra la relación entre el rendimiento y los IOPS, donde IOPS multiplicado por el tamaño de entrada/salida es igual al rendimiento.

El rendimiento total de la red se calcula en función de la siguiente información:

Tráfico de SQL*Net
MBps multiplicado por el número de servidores (secuencia de salida, como Oracle Data Guard)
Otros factores, como la replicación de aplicaciones

Captura de pantalla del rendimiento de SQL*Net.

En función de los requisitos de ancho de banda de red, puede elegir diferentes tipos de puerta de enlace. Entre los tipos se incluyen Básica, VpnGw y Azure ExpressRoute. Para obtener más información, vea Precios de VPN Gateway.

Recomendaciones

La latencia de red es superior en comparación con una implementación local. El rendimiento puede mejorar considerablemente si se reducen los recorridos de ida y vuelta de red.
Consolide las aplicaciones que tengan transacciones elevadas o estén fragmentadas en la misma máquina virtual para reducir los recorridos de ida y vuelta.
Use una instancia de máquinas virtuales con las redes aceleradas para mejorar el rendimiento de la red.
En cuanto a ciertas distribuciones de Linux, habilite la compatibilidad con TRIM/UNMAP.
Instale Oracle Enterprise Manager en una máquina virtual individual.
Las páginas de gran tamaño no están habilitadas en Linux de forma predeterminada. Habilite las páginas de gran tamaño y establezca use_large_pages = ONLY en Oracle DB. Este enfoque puede ayudarle a mejorar el rendimiento. Para obtener más información, consulte USE_LARGE_PAGES.

Tipos y configuraciones de disco

A continuación le ofrecemos algunos consejos sobre discos.

Discos de sistema operativo predeterminados: estos tipos de disco ofrecen datos persistentes y almacenamiento en caché. Estos discos están optimizados para el acceso del sistema operativo en tiempo de inicio y no están diseñados para cargas de trabajo transaccionales o de almacenamiento de datos (analíticas).
Discos administrados: Azure administra las cuentas de almacenamiento utilizadas para los discos de la máquina virtual. Especifique el tipo de disco y el tamaño de disco que necesite. El tipo suele ser Premium (SSD) para cargas de trabajo de Oracle. Azure crea y administra el disco en su nombre. Un disco administrado SSD premium solo está disponible para la serie de máquinas virtuales optimizadas y diseñadas para memoria. Después de elegir un tamaño de máquina virtual determinado, el menú muestra solo las SKU de Premium Storage disponibles que se basan en ese tamaño de máquina virtual.

Una vez configurado el almacenamiento en una máquina virtual, tal vez le interese realizar una prueba de carga en los discos antes de crear una base de datos. Puede ser útil conocer la velocidad de E/S en términos de latencia y rendimiento para ayudarle a determinar si las máquinas virtuales admiten el rendimiento esperado con objetivos de latencia. Existen diversas herramientas para realizar pruebas de carga de aplicaciones, como Oracle Orion, Sysbench, SLOB y Fio.

Vuelva a ejecutar la prueba de carga después de implementar una base de datos de Oracle. Inicie las cargas de trabajo normales y máximas y los resultados mostrarán la línea de base de su entorno. Sea realista en la prueba de carga de trabajo. No tiene sentido ejecutar una carga de trabajo que no se parece en nada a lo que se ejecute en la máquina virtual en realidad.

Como Oracle puede ser una base de datos intensiva en E/S, es importante dimensionar el almacenamiento en función de la tasa de IOPS en lugar del tamaño del almacenamiento. Por ejemplo, si los valores IOPS necesarios son 5000, pero solo necesita 200 GB, puede elegir el clásico disco Premium P30 aunque se ofrezca con más de 200 GB de almacenamiento.

Puede obtener la tasa de IOPS del informe de AWR. El registro de fase de puesta al día, las lecturas físicas y las escrituras determinan la tasa de IOPS. Compruebe siempre que la serie de máquinas virtuales elegida tiene la capacidad de controlar la demanda de E/S de la carga de trabajo. Si la máquina virtual tiene un límite de E/S más bajo que el almacenamiento, el límite máximo lo establece la máquina virtual.

Captura de pantalla de la página del informe de AWR.

Por ejemplo: el tamaño del registro de recuperación es 12 200 000 bytes por segundo, lo que equivale a 11,63 MBPs. El valor de IOPS es 12,200,000 / 2,358 = 5,174.

Una vez que se haya hecho una idea de los requisitos de E/S, puede elegir la combinación de unidades más adecuada para cumplirlos.

Recomendaciones de tipo de disco

Para el espacio de tabla de datos, reparta la carga de trabajo de E/S entre varios discos mediante el almacenamiento administrado o Administración Automática de Almacenamiento de Oracle (ASM).
Use la compresión avanzada de Oracle para reducir la E/S para datos e índices.
Separe los registros de recuperación y los espacios de tabla temporales y de deshacer en discos de datos independientes.
No coloque ningún archivo de aplicación en discos predeterminados del sistema operativo. Estos discos están optimizados para un tiempo de arranque rápido de la máquina virtual y podría no proporcionar un buen rendimiento para la aplicación.
Al usar máquinas virtuales de la serie M en el almacenamiento Premium, habilite el acelerador de escritura en el disco de registros de recuperación.
Considere la posibilidad de mover los registros de recuperación con una latencia alta al disco Ultra.

Configuración de la caché de disco

Aunque hay tres opciones para el almacenamiento en caché de host, solo se recomienda el almacenamiento en caché de solo lectura para una carga de trabajo de base de datos en una base de datos de Oracle. La opción de lectura y escritura puede introducir vulnerabilidades significativas en un archivo de datos porque el objetivo de la escritura de una base de datos es registrarla en el archivo de datos, no almacenar en caché la información. Con solo lectura, todas las solicitudes se almacenan en caché para lecturas futuras. Todas las escrituras se seguirán escribiendo en el disco.

Recomendaciones de caché de disco

Para maximizar el rendimiento, comience con solo lectura para el almacenamiento en caché de host siempre que sea posible. En el caso de almacenamiento premium, tenga en cuenta que debe deshabilitar las barreras al montar el sistema de archivos con las opciones de solo lectura. Actualice el archivo /etc/fstab con el identificador único universal de los discos.

Para los discos del sistema operativo, use SSD premium con almacenamiento en caché de host de lectura y escritura.
Para los discos de datos que contienen lo siguiente, utilice SSD premium con almacenamiento en caché de host de solo lectura: archivos de datos de Oracle, archivos temporales, archivos de control, archivos de seguimiento de cambios en bloques, BFIL, archivos para tablas externas y registros de flashback.
Para los discos de datos que contienen archivos de registro de fase de puesta al día en línea de Oracle, use SSD premium o UltraDisk sin almacenamiento en caché de host, la opción Ninguno. Los archivos de registro de fase de puesta al día de Oracle que se archivan y los conjuntos de copias de seguridad de Oracle Recovery Manager también pueden residir con los archivos de fase de puesta al día en línea. El almacenamiento en caché de host está limitado a 4095 GiB, así que no asigne SSD premium mayor que P50 con este tipo de almacenamiento. Si necesita más de 4 TiB de almacenamiento, coloque en cadena varias unidades SSD premium con RAID-0. Use Linux LVM2 o Administración Automática de Almacenamiento de Oracle.

Si las cargas de trabajo varían considerablemente entre el día y la noche, y la carga de trabajo de E/S puede admitirlo, la SSD premium P1-P20 con ráfagas puede proporcionar el rendimiento necesario durante las cargas por lotes de la noche o las demandas de E/S limitadas.

Seguridad

Después de instalar y configurar el entorno de Azure, debe proteger la red. Estas son algunas recomendaciones:

Directiva de NSG: puede definir el NSG mediante una subred o una tarjeta de interfaz de red. Es más sencillo controlar el acceso en el nivel de subred para garantizar la seguridad y forzar el enrutamiento del firewall de aplicaciones.
Jumpbox: para un acceso más seguro, los administradores no deben conectarse directamente con el servicio de aplicación o la base de datos. Utilice un Jumpbox entre la máquina del administrador y los recursos de Azure.

La máquina del administrador solo debería tener un acceso restringido a la dirección IP del Jumpbox. El Jumpbox debe tener acceso a la aplicación y la base de datos.
Red privada (subredes): se recomienda tener el servicio de aplicación y la base de datos en subredes independientes, de forma que la política de NSG pueda establecer un mejor control.