consolide y simplifique las cargas de trabajo mixtas de ......tradicionalmente, las cargas de...

Internal Use - Confidential

Consolide y simplifique las cargas de trabajo mixtas de bases de datos

con bases de datos Oracle 18c y Microsoft SQL Server 2017 en la infraestructura modular Dell EMC PowerEdge MX, el arreglo de almacenamiento Dell EMC PowerMax 2000 y el sistema de respaldo Dell EMC Data Domain DD9300

Julio de 2019

H17744.1

Guía de arquitectura de referencia

Resumen

En esta guía de arquitectura de referencia se describe la manera en que se diseñan y prueban las cargas de trabajo mixtas de bases de datos SQL Server y Oracle en una infraestructura que incluye una infraestructura modular Dell EMC PowerEdge MX y un arreglo de almacenamiento PowerMax 2000. También se describe la protección de datos mediante el sistema Dell EMC Data Domain DD9300 para respaldar y recuperar una base de datos Oracle.

Soluciones de Dell EMC

Copyright

2 Consolide y simplifique las cargas de trabajo mixtas de bases de datos con bases de datos Oracle 18c y Microsoft SQL Server 2017 en la infraestructura modular Dell EMC PowerEdge MX, el arreglo de almacenamiento Dell EMC PowerMax 2000 y el sistema de respaldo Dell EMC Data Domain 9300 Guía de arquitectura de referencia

La información de esta publicación se proporciona tal cual. Dell Inc. no se hace responsable ni ofrece garantía de ningún tipo con respecto a la información de esta publicación y específicamente renuncia a toda garantía implícita de comerciabilidad o capacidad para un propósito determinado.

El uso, la copia y la distribución de cualquier software descrito en esta publicación requieren una licencia de software correspondiente.

Copyright © 2019 Dell Inc. o sus filiales. Todos los derechos reservados. Dell Technologies, Dell, EMC, Dell EMC y otras marcas comerciales son marcas comerciales de Dell Inc. o sus filiales. Intel, el logotipo de Intel, el logotipo de Intel Inside y Xeon son marcas comerciales de Intel Corporation en los Estados Unidos o en otros países. Las demás marcas comerciales pueden ser marcas comerciales de sus respectivos dueños. Publicado en México, 19/07, Guía de arquitectura de referencia H17744.1.

Dell Inc. considera que la información de este documento es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso.

Contenido

3 Consolide y simplifique las cargas de trabajo mixtas de bases de datos con bases de datos Oracle 18c y Microsoft SQL Server 2017 en la infraestructura modular Dell EMC PowerEdge MX,

el arreglo de almacenamiento Dell EMC PowerMax 2000 y el sistema de respaldo Dell EMC Data Domain 9300 Guía de arquitectura de referencia

Contenido

Chapter 1 Resumen ejecutivo 5

Visión general ejecutiva .......................................................................................... 6

Audiencia y propósito ............................................................................................. 7

Valor de las arquitecturas de referencia validadas ................................................. 7

Valoramos sus comentarios ................................................................................... 8

Chapter 2 Visión general de arquitectura y diseño de la solución 9

Diagrama de la arquitectura de la solución .......................................................... 10

Chasis modular de PowerEdge MX7000 .............................................................. 11

Arreglo de almacenamiento PowerMax 2000 ....................................................... 12

Dispositivo de respaldo Data Domain DD9300 .................................................... 12

Redundancia ........................................................................................................ 13

Chapter 3 Objetivos, configuración y casos de uso de las pruebas de validación 14

Objetivos y configuración de las pruebas ............................................................. 15

Caso de uso 1: Carga de trabajo de OLTP con el uso de un parámetro de referencia tipo TPC-C ........................................................................................... 19

Caso de uso 2: Carga de trabajo de DSS con el uso de un parámetro de referencia tipo TPC-H ........................................................................................... 19

Caso de uso 3: Carga de trabajo de OLTP de instantáneas con el uso de un parámetro de referencia tipo TPC-C .................................................................... 20

Niveles de servicio de PowerMaxOS ................................................................... 21

Chapter 4 Resultados de las pruebas de validación 23

Descripción general .............................................................................................. 24

Utilización promedio de CPU ................................................................................ 24

TPM ...................................................................................................................... 26

NOPM ................................................................................................................... 29

IOPS del almacenamiento .................................................................................... 31

Latencia del almacenamiento ............................................................................... 34

Rendimiento ......................................................................................................... 37

Rendimiento combinado de IOPS, latencia y rendimiento ................................... 38

Chapter 5 Solución de respaldo y recuperación Data Domain 40

Introducción .......................................................................................................... 41

Solución de respaldo y recuperación para Oracle ................................................ 41

Solución de respaldo y recuperación para SQL Server ....................................... 48

Contenido


Chapter 6 Conclusiones de los resultados de las pruebas 49

Rendimiento a escala ........................................................................................... 50

Observaciones sobre el rendimiento de PowerEdge MX840c ............................. 50

Observaciones sobre el rendimiento de PowerMax 2000 .................................... 50

Observaciones sobre el respaldo y la recuperación de Data Domain ...................... 51

Resumen de los resultados .................................................................................. 51

Para obtener más información ............................................................................. 52

Chapter 7 Referencias 53

Documentación de Dell EMC ............................................................................... 54

Documentación de VMware ................................................................................. 54

Documentación de Oracle .................................................................................... 54

Documentación de Microsoft ................................................................................ 54

Documentación de HammerDB ............................................................................ 54

Appendix A Hardware y software de la solución 55

Componentes de hardware .................................................................................. 56

Componentes de software .................................................................................... 58

Appendix B Detalles de diseño y configuración 59

Diseño de computación y red ............................................................................... 60

Configuración del almacenamiento PowerMax .................................................... 66

Configuraciones de VM y sistemas operativos huéspedes de Oracle ................. 72

Configuraciones de VM y sistemas operativos huéspedes de SQL Server ......... 76

Chapter 1: Resumen ejecutivo



Chapter 1 Resumen ejecutivo

Este capítulo presenta los siguientes temas:

Visión general ejecutiva ....................................................................................... 6

Audiencia y propósito .......................................................................................... 7

Valor de las arquitecturas de referencia validadas ........................................... 7

Valoramos sus comentarios ................................................................................ 8



Visión general ejecutiva

La consolidación de cargas de trabajo de bases de datos tiene muchos beneficios.

Quizás el más importante es que permite a la empresa aumentar la utilización de la

infraestructura sin sacrificar el rendimiento y, al mismo tiempo, mantener la flexibilidad

y la agilidad para responder a nuevas solicitudes. Sin embargo, el mayor reto para el

diseño y la entrega de una solución de consolidación es la incertidumbre respecto de

la manera en que se integrarán todos los componentes y si estos cumplirán con los

objetivos de la inversión. Las complejidades de la integración, el soporte y la optimización

de un diseño de múltiples proveedores podrían requerir una inversión por adelantado

importante que podría tardar bastante tiempo en recuperarse.

El objetivo de las infraestructuras convergentes (CI) e hiperconvergentes (HCI) es reducir las

complejidades de las bases de datos modernas con la oferta de una solución completamente

diseñada con administración del ciclo de vida. Las bases de datos son únicas en el sentido

de que las consideraciones de licenciamiento y rendimiento son de igual importancia para

la empresa. El posicionamiento del licenciamiento de las bases de datos en las soluciones

convergentes puede representar una incertidumbre o un riesgo significativos para la

empresa. Sin embargo, muchas empresas ejecutan correctamente las bases de datos

en infraestructura convergente, lo que demuestra que este enfoque sí funciona.

Una combinación de enfoques de múltiples proveedores e infraestructura convergente

ofrece una solución integrada y probada que está diseñada para las cargas de trabajo

de bases de datos. Esta arquitectura de referencia para cargas de trabajo mixtas se

diseñó y probó para bases de datos SQL Server y Oracle que se ejecutan en la misma

infraestructura validada, la que incluye los productos Dell EMC PowerEdge y PowerMax.

La infraestructura modular Dell EMC PowerEdge MX le permite destinar servidores a bases

de datos específicas. En esta solución se demuestra cómo las bases de datos Oracle y

SQL Server utilizan servidores dedicados para simplificar la administración, la escalabilidad

y la eficiencia en el licenciamiento y el uso de un arreglo de almacenamiento Dell EMC

PowerMax 2000 para admitir las cargas de trabajo mixtas.

Tradicionalmente, las cargas de trabajo mixtas de bases de datos, como las cargas de trabajo

del procesamiento de transacciones en línea (OLTP) y del sistema de apoyo para la toma

de decisiones (DSS), han sido difíciles de administrar en la misma infraestructura. Cada una

de estas cargas de trabajo plantea distintas exigencias al sistema de almacenamiento.

El sistema de almacenamiento no se puede ajustar para una u otra carga de trabajo, sino que

debe admitir ambas cargas de bases de datos en niveles de rendimiento que cumplan con

los acuerdos de nivel de servicio (SLA). Las unidades flash de PowerMax 2000 con NVM

Express (NVMe) incorporan mejoras en el rendimiento y el paralelismo que brindan una

adaptación ideal a las cargas de trabajo mixtas de bases de datos. Las unidades flash

NVMe ofrecen mayor velocidad y la capacidad de procesar más solicitudes en paralelo.

Reto para

el negocio

Infraestructuras

convergentes

e hiperconver-

gentes

Cargas de

trabajo mixtas de

bases de datos




En esta guía se describen tres pruebas de validación que se diseñaron para llevar el sistema a límites de nivel de servicio realistas. Un objetivo clave de estas pruebas fue generar la cantidad máxima de carga en la arquitectura de referencia sin que la mayor parte de la actividad de lectura y escritura superara 1 milisegundo (ms) de latencia. Las pruebas de validación superaron las expectativas, en especial en el caso de una configuración de arreglo de almacenamiento de nivel de entrada que se diseñó para mantener baja la inversión inicial de un cliente. En el capítulo 6 se resumen los resultados de las pruebas.

Las fallas de las bases de datos pueden representar un riesgo significativo para la empresa debido a la detención de las operaciones, lo que afecta los ingresos. El respaldo y la protección de las bases de datos preparan a la empresa para recuperarse de una falla espontánea. El equipo de validación de Dell EMC probó una solución de respaldo y recuperación mediante el software DD Boost y el sistema de respaldo Data Domain DD9300 que puede admitir las cargas de trabajo de bases de datos que se analizan en esta guía. En el capítulo 5 se analizan los casos y los resultados de las pruebas.

Audiencia y propósito

Esta guía está dirigida a cualquier persona interesada en conocer los beneficios de esta arquitectura de referencia, incluidos los arquitectos de soluciones, los DBA de SQL Server y Oracle, los administradores de almacenamiento y los administradores de Linux. Ofrece:

Detalles de la configuración física

Resultados de las pruebas de rendimiento de cargas de trabajo mixtas de bases de datos SQL Server y Oracle

Configuración de almacenamiento y mejores prácticas de PowerMax

Configuración de Red Hat Enterprise Linux para optimizar el rendimiento

Además, esta guía tiene valor para cualquier persona que desee evaluar, adquirir, administrar, mantener y operar entornos de bases de datos mixtas.

Valor de las arquitecturas de referencia validadas

El equipo de diseño validado de Dell EMC consta de un grupo de expertos con amplia experiencia en bases de datos. El objetivo es crear soluciones focalizadas para las cargas de trabajo más desafiantes que una empresa puede requerir. Esto es excepcionalmente diferente a la mayoría de las soluciones actuales, las cuales están diseñadas para funcionar con todo. Para aumentar el valor para los clientes, las soluciones se validaron mediante la ejecución de múltiples pruebas:

Se ejecutaron bases de datos de OLTP de SQL Server y Oracle en paralelo en la arquitectura de referencia.

Se ejecutaron cargas de trabajo de OLTP y DSS desde ambas bases de datos en paralelo en la arquitectura de referencia.

Se probó la funcionalidad de instantáneas de PowerMax mediante la creación de instantáneas de ambas bases de datos y la ejecución de una carga de trabajo de OLTP en ellas.

Se probó DD Boost y el rendimiento y la capacidad del sistema DD9300 para el respaldo y la restauración de una base de datos Oracle de 1,8 TB.

Objetivo de

pruebas de

validación clave

Respaldo y recuperación de las bases de datos



Como parte de las pruebas de validación, se ajustaron y optimizaron todos los componentes

de software y hardware de esta arquitectura de referencia a fin de maximizar el rendimiento.

En esta guía se documentaron como mejores prácticas todos los cambios que se realizaron

y que mejoraron el rendimiento.

Esta arquitectura de referencia beneficia a los clientes, ya que les proporciona

lo siguiente:

Una solución de base de datos especializada: ninguna solución se ajusta

a todas las necesidades. Esta arquitectura de referencia se diseñó, probó y validó

especialmente para las cargas de trabajo mixtas de bases de datos.

Pruebas de validación de las bases de datos: las pruebas se llevaron a cabo

con los archivos ejecutables que los clientes usarían para ejecutar sus bases

de datos. En esta prueba no se simuló ninguna I/O de base de datos.

Dimensionamiento acorde con los requisitos: puede personalizar la configuración

probada para satisfacer sus necesidades de cargas de trabajo mixtas de bases

de datos.

Solución de respaldo y recuperación probada y comprobada: prepárese para

fallas no planificadas de las bases de datos y minimice el tiempo de inactividad.

Menos riesgo: este sistema validado se integró, se probó y se documentó.

Se utilizó la herramienta de análisis comparativo HammerDB para crear cargas de trabajo de

OLTP y DSS en la nueva solución de base de datos. HammerDB es gratuita y está disponible

para cualquier persona que desee utilizarla en la realización de sus propias pruebas.

Valoramos sus comentarios

Dell EMC y los autores del presente documento recibirán con mucho agrado sus

comentarios sobre la solución y la documentación. Póngase en contacto con el equipo

de soluciones de Dell EMC por correo electrónico o proporcione sus comentarios

completando la encuesta sobre la documentación.

Autores: equipos de ingeniería de Oracle y SQL, Indranil Chakrabarti, Anil Papisetty,

Sam Lucido y Reed Tucker

En las siguientes páginas de los espacios de Oracle y SQL Server en el sitio web de

comunidades de Dell EMC se proporcionan enlaces a documentación adicional para

esta solución:

Centro de información de Oracle

Centro de información de Microsoft SQL

Beneficios clave

mailto:[email protected]?subject=Feedback:%20Simplify,%20Standardize,%20Consolidate,%20and%20Accelerate%20Mixed%20Database%20Workloads%20(H17744)

https://www.surveymonkey.com/r/SolutionsSurveyExt

https://community.emc.com/docs/DOC-69044

https://community.emc.com/docs/DOC-67007

Chapter 2: Visión general de arquitectura y diseño de la solución



Chapter 2 Visión general de arquitectura y diseño de la solución


Diagrama de la arquitectura de la solución ..................................................... 10

Chasis modular de PowerEdge MX7000 .......................................................... 11

Arreglo de almacenamiento PowerMax 2000 ................................................... 12

Redundancia ....................................................................................................... 13



Diagrama de la arquitectura de la solución En la siguiente figura se proporciona una visión general del diseño de esta arquitectura

de referencia:

Figure 1. Visión general del diseño de la arquitectura de la solución

Como se muestra, la infraestructura de chasis modular de PowerEdge MX7000 proporciona los recursos de computación y red, PowerMax 2000 se utiliza como el arreglo de almacenamiento SAN y Data Domain DD9300 se usa como el dispositivo de respaldo en esta arquitectura de referencia.




Chasis modular de PowerEdge MX7000

Se utiliza el chasis modular Dell EMC PowerEdge MX7000, el cual proporciona una

infraestructura de centro de datos de alto rendimiento para los recursos de computación

y red de esta solución.

Los recursos de computación o servidor de esta arquitectura de referencia son los siguientes:

Un blade PowerEdge MX840c para bases de datos Oracle: este servidor blade de

cuatro conectores se implementó con el hipervisor VMware ESXi 6.7 y se configuró

para ejecutar tres máquinas virtuales (VM) de bases de datos Oracle de nodo único.

Cada VM se implementó con Oracle 18c (18.3.0) Grid Infrastructure (GI) y Oracle

Database 18c (18.3.0) independiente que se ejecuta en Red Hat Enterprise Linux 7.4

como el sistema operativo huésped. Las VM se configuraron de la siguiente manera:

La primera VM se configuró para ejecutar la carga de trabajo de base de datos de producción de OLTP de Oracle.

La segunda VM se configuró para ejecutar la carga de trabajo de base de datos de DSS de Oracle.

La tercera VM se configuró para ejecutar una carga de trabajo de base de datos de OLTP que se creó como una instantánea de la base de datos de producción de OLTP en el arreglo de almacenamiento PowerMax.

Para obtener más información sobre el host ESXi, las VM de las bases de datos

Oracle y la configuración de la red virtual, consulte el apéndice B: Detalles de

diseño y configuración.

Un blade PowerEdge MX840c para bases de datos SQL Server: este servidor

blade de cuatro conectores se implementó con el hipervisor VMware ESXi 6.7 y

se usó para ejecutar cinco máquinas virtuales (VM) de bases de datos SQL Server

de nodo único. Se implementó una instancia independiente de SQL Server 2017

en cada VM con Red Hat Enterprise Linux 7.6 como el sistema operativo huésped.

Las VM se configuraron de la siguiente manera:

Las primeras dos VM se configuraron para ejecutar la carga de trabajo de base de datos de producción de OLTP de SQL.

La tercera y la cuarta VM se configuraron para ejecutar la carga de trabajo de base de datos de DSS de SQL.

La quinta VM se configuró para ejecutar una carga de trabajo de base de datos de OLTP que se creó como una instantánea de la base de datos de producción de OLTP en el arreglo de almacenamiento PowerMax con el fin de simular un entorno de desarrollo, un ambiente de pruebas o ambos.

Para obtener más información sobre el host ESXi, las VM de las bases de datos

SQL Server y la configuración de la red virtual, consulte el apéndice B: Detalles

de diseño y configuración.

Subcomponentes de los blades MX840c: cada blade MX840c que se usa para las bases de datos Oracle y SQL Server consta de cuatro CPU físicas escalables Intel Xeon de 20 núcleos, 1536 GB de RAM y cuatro tarjetas mezzanine o adaptadores de red convergente (CNA) QLogic QL41262 de dos puertos y 25 GbE para tráfico de LAN y SAN. Dos tarjetas mezzanine se configuraron para el tráfico de Fibre Channel mediante Ethernet (FCoE) o SAN. Las dos tarjetas restantes se configuraron para el tráfico de LAN. Se creó particionamiento NIC (NPAR) en todas las tarjetas mezzanine. Para obtener más información sobre la configuración de los CNA, consulte Configuración de adaptadores de red convergente en el apéndice B.

Capa de

computación

o servidor



La infraestructura modular PowerEdge MX7000 se utilizó para proporcionar la capa de conmutación de red en esta solución. La capa de red consta de lo siguiente:

Dos módulos de I/O (IOM) o switches del motor de conmutación de fabric (FSE) MX9116n: se configuraron dos IOM MX9116n instalados en las ranuras de fabric MX A1 y B1 para ejecutar el tráfico de LAN y SAN convergentes en esta solución. Los dos IOM se configuraron en modo de troncalización de enlace virtual (VLT). Los dos puertos unificados QSFP28 (100 Gb) externos se configuraron en modo de cuatro conexiones Fibre Channel (FC) de 16 Gb/s, las que se conectaron directamente al arreglo de almacenamiento PowerMax 2000. El puerto QSFP28 externo se configuró en el modo de cuatro conexiones de 10 GbE y se enlazó de manera ascendente a switches centrales con fines de conectividad de LAN externa. Los puertos internos de 25 GbE que se conectaron a los puertos del CNA se configuraron en los blades MX840c para transportar el tráfico de FCoE y LAN. Para obtener más información sobre la configuración de red LAN y SAN, incluida la zonificación de FC, consulte Diseño de la computación y la red en el apéndice B.

Módulo de administración MX redundante: se conectaron módulos de administración MX de 1 GbE redundantes a switches de 1 GbE. Este módulo de administración se usó para administrar el chasis MX7000 y los IOM MX9116n, y para conectarse a iDRAC en los blades MX840c. Para obtener más información sobre la administración del chasis MX7000, consulte Dell EMC OpenManage Enterprise - Modular Edition versión 1.00.01 para el chasis PowerEdge MX7000, Guía del usuario.

Arreglo de almacenamiento PowerMax 2000 Un único arreglo de almacenamiento PowerMax 2000 se usó como el almacenamiento FC SAN para alojar las bases de datos Oracle y SQL Server. El arreglo PowerMax 2000 de esta arquitectura de referencia consta de lo siguiente:

Un brick o motor PowerMax 2000 que consta de dos directores

Dieciséis puertos FC de front-end de 16 Gb/s conectados directamente a IOM MX9116n independientes para proporcionar dos fabrics para SAN con fines de alta disponibilidad y balanceo de carga

Dos grupos de puertos de front-end, uno para el tráfico de la base de datos Oracle y otro para el tráfico de la base de datos SQL Server, con ocho puertos FC independientes en cada uno

Veinticuatro unidades flash NVMe de 3,8 TB en una configuración RAID 5 (7+1) para proporcionar una capacidad de almacenamiento útil de 73,35 TB

Grupos de almacenamiento independientes para las bases de datos Oracle y SQL Server con fines de balanceo de carga a través de diferentes grupos de puertos, facilidad de administración y monitoreo

Para obtener más información sobre los grupos de almacenamiento y la configuración de volúmenes, consulte Configuración del almacenamiento PowerMax en el apéndice B.

Dispositivo de respaldo Data Domain DD9300

DD9300 se utilizó como el dispositivo de respaldo para probar el respaldo y la recuperación de una base de datos Oracle en esta arquitectura de referencia. Cuatro interfaces de 10 GbE de front-end distribuidas entre dos NIC instaladas en el DD9300 se conectaron a los mismos switches centrales a los que estaban conectados los switches de red MX. Esto proporcionó una conectividad de alta disponibilidad y un ancho de banda suficiente entre los servidores de base de datos MX840c y el dispositivo de respaldo DD9300. Las interfaces configuradas para el tráfico de la red pública dentro de los servidores de base de datos también se utilizaron para el tráfico de respaldo y recuperación. Para que esta comunicación suceda, las interfaces de 10 GbE en el DD9300 también se configuraron en este mismo rango de direcciones de la red IP pública.

Capa de red

https://www.dell.com/support/manuals/us/en/19/poweredge-mx7000/omem1.00.01_ug/overview?guid=guid-452f9894-f2e2-41a6-801e-41c5acfaefa3&lang=en-us






Para obtener más información sobre el DD9300 y la configuración del servidor de base

de datos, la metodología de prueba para el respaldo y la recuperación, y los resultados,

consulte el capítulo 5: Solución de respaldo y recuperación de Data Domain.

Redundancia

El diseño de la LAN y la SAN cuenta con componentes y conectividad redundantes en

todos los niveles a fin de garantizar que no exista ningún punto único de falla. El diseño

permite que el servidor de aplicaciones y el sistema de respaldo accedan al servidor de

base de datos y que este acceda al arreglo de almacenamiento, incluso si falla alguno

de los siguientes componentes:

Uno o más puertos de CNA o tarjeta mezzanine dentro de los blades

de procesamiento MX840c

Un IOM o switch MX9116n

Uno o más puertos de front-end de PowerMax

Una controladora de almacenamiento PowerMax

Una o más interfaces de front-end de 10 GbE dentro del sistema de respaldo DD9300

Chapter 3: Objetivos, configuración y casos de uso de las pruebas de validación


Chapter 3 Objetivos, configuración y casos de uso de las pruebas de validación


Objetivos y configuración de las pruebas ....................................................... 15

Caso de uso 1: Carga de trabajo de OLTP con el uso de un parámetro de referencia tipo TPC-C .................................................................................... 19

Caso de uso 2: Carga de trabajo de DSS con el uso de un parámetro de referencia tipo TPC-H .................................................................................... 19

Caso de uso 3: Carga de trabajo de OLTP de instantáneas con el uso de un parámetro de referencia tipo TPC-C ...................................................... 20

Niveles de servicio de PowerMaxOS ................................................................ 21




Objetivos y configuración de las pruebas

El objetivo de probar esta solución de cargas de trabajo mixtas fue simular una plataforma de base de datos consolidada para uso por parte de los equipos de Oracle y SQL Server. Por lo general, la consolidación de ecosistemas de bases de datos es de menor prioridad que el rendimiento y la protección, ya que los riesgos y la complejidad percibidos en relación con la consolidación de las bases de datos son de consideración. Sin embargo, la introducción de CPU más rápidas y potentes, y de la nueva tecnología de almacenamiento en una arquitectura de referencia probada y comprobada permite a las empresas consolidar las bases de datos sin inquietudes respecto del riesgo.

El arreglo de almacenamiento PowerMax 2000 utiliza unidades flash NVMe que son significativamente más rápidas que las unidades de estado sólido (SSD) SATA tradicionales. Las unidades flash NVMe proporcionan varias mejoras que aceleran las operaciones de almacenamiento, entre las que se incluyen un mayor paralelismo y un bus actualizado que permite el transporte de datos más rápido. Al probar esta plataforma de base de datos, se creó un entorno de bases de datos mixtas con Oracle y SQL Server, y un entorno de cargas de trabajo mixtas, incluidas cargas de trabajo de OLTP y DSS. Esta combinación de distintas bases de datos y cargas de trabajo simula lo que un cliente podría encontrar durante una iniciativa de consolidación de bases de datos.

El chasis modular MX7000 aloja bloques de servidor y almacenamiento desagregados, lo que lo convierte en una solución ideal para la consolidación de bases de datos. En la configuración de la prueba, se utilizaron dos servidores PowerEdge MX840c en el chasis modular MX7000. Un servidor MX840c se destinó a la base de datos SQL Server 2017 Enterprise Evaluation Edition RTM-CU13 y el otro a la base de datos Oracle 18c Enterprise Edition. La asignación de un servidor MX840c a cada base de datos optimiza el licenciamiento, ya que limita los costos y permite probar la consolidación de las bases de datos. En las pruebas, cada MX840c se configuró idénticamente con 4 CPU y 1,5 TB de memoria. Cada CPU contaba con 20 núcleos, por lo que estaban disponibles 80 núcleos para cada base de datos.

Las VM de las bases de datos SQL Server y Oracle se implementaron con Red Hat Enterprise Linux 7 como el sistema operativo huésped. Microsoft permite que los clientes de SQL Server transfieran sus licencias de bases de datos de Windows a Linux de manera gratuita. El sistema operativo se estandarizó con Linux en ambas bases de datos para simplificar la administración. En términos de las pruebas de las bases de datos mixtas, el uso del mismo sistema operativo optimizó la ejecución y permitió el análisis más rápido de las observaciones relacionadas con el rendimiento.

El arreglo de almacenamiento PowerMax 2000 se configuró con 24 unidades flash NVMe, lo que representa una configuración de almacenamiento de nivel de entrada. El uso de una configuración de nivel de entrada para las pruebas demuestra que los clientes pueden comenzar con una inversión mínima y escalar de manera vertical para adaptarse a las crecientes exigencias. En la siguiente tabla se muestra el tamaño de la configuración de almacenamiento que se usó y los tamaños máximos para el arreglo PowerMax 2000, como se detalla en la hoja de especificaciones de la familia PowerMax:

Table 1. Configuración compatible máxima de PowerMax 2000 frente a la configuración probada

Componentes de PowerMax 2000 Configuración compatible máxima

Configuración probada

Cantidad de bricks o motores 2 1

Caché del sistema (crudo) 4 TB (con motor de 2 TB) 1 TB

Cantidad de módulos de I/O de front-end por arreglo

16 4

Puertos de host FC de 16 Gb/s por arreglo 64 16

Cantidad de unidades flash NVMe 96 24

Configuración de

la infraestructura

validada

https://mexico.emc.com/collateral/data-sheet/h16739-powermax-2000-8000-ss.pdf



Durante las pruebas de rendimiento del almacenamiento del arreglo PowerMax 2000, los objetivos fueron los siguientes:

Generar una carga de trabajo mixta de bases de datos significativa para exigir a PowerMax 2000.

Impulsar una combinación de IOPS y latencia inferior a un milisegundo representativa de la demanda en un ecosistema de cargas de trabajo mixtas.

Capturar observaciones de las pruebas y transformar el análisis en mejores prácticas para los clientes.

El arreglo PowerMax 2000 es compatible con unidades flash NVMe. Las unidades flash NVMe permiten que el almacenamiento de bloques a gran escala admita los adaptadores de red y las tarjetas adaptadoras de bus de host (HBA) existentes. Una de las principales ventajas de las unidades flash NVMe es el mejor rendimiento. Entre otros beneficios del almacenamiento basado en NVMe se incluyen los siguientes:

Una menor latencia y más IOPS

Compatibilidad con líneas de espera profundas: 64 comandos por línea de espera y hasta 64 000 líneas de espera

Interfaz de registro optimizada que minimiza la utilización de CPU necesaria para administrar las operaciones de I/O

Transparencia para las bases de datos, de modo que es posible aprovechar los beneficios del rendimiento de NVMe sin necesidad de realizar pasos adicionales

Nota: Dell EMC también ofrece el sistema PowerMax 8000, el cual cuenta con funcionalidades de escalamiento y rendimiento incluso mayores que el PowerMax 2000 que se usó en las pruebas de esta solución.

VMware vSphere se usó en esta arquitectura de referencia para impulsar una mayor consolidación, acelerar el aprovisionamiento de las bases de datos y simplificar la administración. La virtualización le permite agrupar en pools los recursos de computación y almacenamiento para impulsar una mayor eficiencia del hardware. En esta solución de cargas de trabajo mixtas, vSphere se usó para virtualizar las bases de datos SQL Server y Oracle, y para asignar recursos de CPU y memoria.

En las pruebas, los recursos de CPU y memoria no fueron los mismos entre SQL Server y Oracle, así como tampoco la cantidad de bases de datos. El objetivo no fue comparar SQL Server con Oracle, sino colocar bases de datos y cargas de trabajo de bases de datos mixtas en los servidores MX840c y el arreglo PowerMax 2000 para mostrar la manera en que esta única solución de infraestructura acelera las bases de datos consolidadas. En la siguiente tabla se muestran las configuraciones de VM de Oracle y SQL Server:

Table 2. Configuración de la virtualización para las bases de datos

Tipo de carga de trabajo

Tipo de base de datos

Cantidad de máquinas virtuales

Asignación de vCPU

Asignación de vMem (GB)

Reserva de memoria de bases de datos (GB)

OLTP Oracle VM 1 10 150 56 (48 SGA + 8 PGA)

OLTP SQL Server VM 1 6 64 8

OLTP SQL Server VM 2 6 64 8

DSS Oracle VM 1 8 256 96 (32 SGA + 64 PGA)

DSS SQL Server VM 1 8 256 32

DSS SQL Server VM 2 8 256 32

OLTP de instantáneas Oracle VM 1 6 150 36 (28 SGA + 8 PGA)

OLTP de instantáneas SQL Server VM 1 4 64 8

NVMe

VMware vSphere




Cada base de datos virtualizada utilizó un subconjunto de los núcleos de computación disponibles en los servidores MX840c. Se asignaron 24 núcleos de computación a VM de Oracle y se dejaron 136 núcleos para la consolidación de bases de datos adicionales en el servidor MX840c que se destinó a Oracle. De manera similar, se asignaron 32 núcleos de computación a VM de SQL Server y se dejaron 128 núcleos disponibles para otras bases de datos.

Se usaron reservas de memoria para asignar memoria a cada base de datos virtualizada. Se configuraron reservas de memoria bajas para cada base de datos con el fin de generar actividad en el arreglo de almacenamiento PowerMax 2000. Si estas bases de datos fueran aplicaciones de producción reales del cliente, se recomendaría reservar más memoria, ya que las operaciones en la memoria son más rápidas que las operaciones en el almacenamiento. Al igual que las configuraciones de CPU, las configuraciones de la memoria utilizaron un subconjunto de la memoria disponible en el servidor. En todas las bases de datos virtualizadas Oracle, la cantidad de memoria utilizada fue de 188 GB y el total de memoria disponible en el servidor MX840c fue de 1,5 TB. En todas las bases de datos virtualizadas SQL Server, la cantidad de memoria utilizada fue de 88 GB y el total de memoria disponible en el servidor MX840c fue de 1,5 TB.

Los núcleos de computación se pueden limitar en la capa de la base de datos mediante el uso de CPU caging de Oracle o del regulador de recursos de SQL Server, o en la capa del sistema operativo Linux con cgroups. Sin embargo, la virtualización de vSphere simplifica la administración de recursos, lo que la convierte en la mejor opción para asignar núcleos de computación y memoria.

El arreglo de almacenamiento PowerMax 2000 es compatible con la tecnología vSphere Native Multipathing Plug-In (NMP). Las múltiples rutas aumentan la eficiencia del envío de datos a través de rutas de hardware redundantes que conectan los servidores PowerEdge con el almacenamiento PowerMax. Entre los beneficios se incluyen la alternancia de I/O mediante round robin para optimizar el uso de las rutas de hardware y distribuir los datos de manera más uniforme. Otro beneficio es que, si falla alguno de los componentes en la ruta de almacenamiento, NMP restablece la conexión y pasa las I/O por una ruta alternativa.

Se probaron tres casos de uso incrementales:

Caso de uso 1: Carga de trabajo de OLTP con el uso de un parámetro de referencia tipo TPC-C

Caso de uso 2: Carga de trabajo de DSS con el uso de un parámetro de referencia tipo TPC-H

Caso de uso 3: Carga de trabajo de OLTP de instantáneas con el uso de un parámetro de referencia tipo TPC-C

En las métricas de rendimiento de estas pruebas se incluyó lo siguiente:

Núcleos de CPU: se generaron cargas de trabajo similares a las de producción con la menor cantidad posible de núcleos de CPU. Las bases de datos Oracle y SQL Server usan licenciamiento basado en núcleos. A medida que aumenta la cantidad de núcleos, también aumenta el costo del licenciamiento. El uso de la combinación de los servidores MX840c y el arreglo de almacenamiento PowerMax 2000 permitió generar una carga de trabajo de base de datos significativa con menos núcleos de procesamiento.

Utilización de CPU: la utilización de CPU se capturó en la capa de Linux mediante dstat. Los valores de utilización de CPU que se capturaron representan la suma de todo el trabajo que admitieron los núcleos asignados a las VM. La generación de informes sobre la utilización de CPU proporciona una comprensión de la carga de procesamiento que llevaron a cabo los núcleos de CPU en estas pruebas. No se definieron objetivos en cuanto a la utilización de CPU porque el uso de menos núcleos en cada VM tuvo mayor prioridad; sin embargo, esta métrica se capturó para proporcionar información valiosa sobre la carga de trabajo de procesamiento.

Métricas de

rendimiento

de las pruebas



TPM: se capturó la cantidad de transacciones por minuto (TPM) para mostrar la

velocidad con la que una base de datos OLTP procesaba las transacciones. Un

valor de TPM más alto indica que la base de datos procesaba más transacciones

comerciales. En las pruebas de la solución de cargas de trabajo mixtas, el objetivo

fue generar un valor de TPM suficiente como para admitir una carga de trabajo de

producción típica. Esta métrica se aplica únicamente a las cargas de trabajo de

OLTP y se captura en el informe de HammerDB.

NOPM: nuevos pedidos por minuto (NOPM) es una medición de rendimiento

del parámetro de referencia TPC-C. Cada transacción consta de los siguientes

tipos de transacción: nuevo pedido, pago, estado del pedido, entrega y nivel de

existencias. Por lo tanto, NOPM indica la cantidad de transacciones de pedidos

que se completaron en un minuto como parte de un proceso de negocios en serie.

Esta métrica se aplica únicamente a las cargas de trabajo de OLTP y se captura

en el informe de HammerDB.

IOPS: la cantidad de IOPS indica la carga en un sistema de almacenamiento.

Puede utilizar IOPS para comprender la cantidad de carga que cada base de

datos y aplicación generan en el arreglo y si se aproximan a la carga máxima

en el arreglo de almacenamiento. Las IOPS junto con la latencia proporcionan

un panorama integral del rendimiento del almacenamiento. En estas pruebas,

el objetivo fue mostrar las IOPS que son adecuadas para la compatibilidad con

bases de datos de producción.

Latencia en valores inferiores a 1 milisegundo: la latencia indica la velocidad

de lectura y escritura de los datos en el arreglo de almacenamiento. La latencia

del almacenamiento es una métrica importante para las aplicaciones de OLTP,

ya que mientras más rápido pueda responder el sistema de almacenamiento

a las solicitudes de lectura y escritura, mayor capacidad de respuesta tendrá

la experiencia con las aplicaciones para los usuarios. El objetivo de latencia del

almacenamiento para esta solución fue de 1 ms o menos para las lecturas y las

escrituras de todos los datos y los archivos de registro en cargas de trabajo de

OLTP que simulaban cargas de trabajo de producción.

Rendimiento en megabytes por segundo (MB/s): el rendimiento es una métrica

que se utiliza para las cargas de trabajo de DSS con el fin de indicar la velocidad

con la que el sistema puede procesar grandes cantidades de datos con consultas

complejas. Cuanto mayor sea el rendimiento de un sistema, más datos podrá

procesar y más rápido podrá realizar análisis de datos complejos. El objetivo fue

generar un nivel moderado de rendimiento en la solución para mostrar que los

clientes pueden tener cargas de trabajo de DSS y OLTP en ejecución en paralelo.

Compresión y desduplicación: la compresión y la desduplicación de PowerMax

se deshabilitaron en el nivel del grupo de almacenamiento para todos los casos

de uso. Por lo tanto, en estas pruebas de validación no se observó ninguna

reducción de datos. En la fase de pruebas de estrés, se ejecutaron escenarios

de prueba del peor caso posible con un 100 % de datos activos en PowerMax

2000. Este perfil de carga de trabajo no aprovecha las funciones de rendimiento

de reducción de datos de PowerMax. Un entorno de producción de base de

datos típico con cargas de trabajo mixtas se beneficia del motor de desduplicación

y compresión de PowerMax, lo que ofrece ventajas de rendimiento y consolidación.

Al implementar la solución, es posible que prefiera usar estas funciones.

http://www.tpc.org/tpcc/detail.asp




Caso de uso 1: Carga de trabajo de OLTP con el uso de un parámetro de referencia tipo TPC-C

En la primera prueba se estableció una base mediante la ejecución de una carga de trabajo de base de datos de OLTP que se generó con el uso de un parámetro de referencia tipo TPC-C en las bases de datos Oracle y SQL Server. Tenga en cuenta que un parámetro de referencia “tipo TPC-C” significa que los resultados de las pruebas no están certificados. El parámetro de referencia TPC-C es una carga de trabajo de OLTP compleja. Las cargas de trabajo de OLTP simulan las aplicaciones empresariales que utilizan las empresas para administrar todos los procesos operacionales. La popular herramienta HammerDB se usó para generar la carga de trabajo tipo TPC-C.

Para la prueba del caso de uso de OLTP, se ejecutó una base de datos Oracle y dos bases de datos SQL Server en paralelo para generar una carga de trabajo de OLTP en el sistema. Las métricas de rendimiento que se capturaron sirven de base para determinar la manera en que otras cargas de trabajo afectan la carga de trabajo de OLTP. En la siguiente tabla se muestra la configuración de la carga de trabajo de OLTP de TPC-C:

Table 3. Configuración del parámetro de referencia tipo TPC-C para el caso de uso de cargas de trabajo de OLTP

Parámetro tipo TPCC de HammerDB

SQL Server Oracle Total

Factor de escala de la base de datos

10,000 15,000 25,000

Tamaño de la base de datos (TB)

2 (VM1 + VM2) 1.5 3.5

Cantidad de usuarios virtuales

400 500 900

Duración de la prueba (minutos)

30 30

Caso de uso 2: Carga de trabajo de DSS con el uso de un parámetro de referencia tipo TPC-H

En la segunda prueba se agrega una carga de trabajo de DSS al sistema mediante la generación de cargas de trabajo tipo TPC-H. Tenga en cuenta que una carga de trabajo “tipo TPC-C” significa que los resultados de las pruebas no están certificados. El parámetro de referencia TPC-H consta de consultas ad hoc y modificación simultánea de datos en grandes conjuntos de datos. Las empresas pueden utilizar un DSS para analizar un gran volumen de datos con el fin de generar informes que faciliten las decisiones empresariales basadas en pruebas. Las métricas de rendimiento y almacenamiento se monitorearon solamente como parte de la ejecución de una carga de trabajo de DSS. Por lo tanto, métricas como la consulta por hora compuesta de TPC-H (QphH@Size) no se revisan en este documento.

Para el caso de uso de DSS, se ejecutó una base de datos Oracle y dos bases de datos SQL Server en paralelo con el fin de generar rendimiento en el arreglo de almacenamiento PowerMax 2000. La carga de trabajo de DSS se ejecutó en paralelo con la carga de trabajo de OLTP, con lo que se creó una carga de trabajo combinada en el sistema.

http://www.tpc.org/tpcc/detail.asp

http://www.tpc.org/tpch/

http://www.tpc.org/tpch/



En la siguiente tabla se detalla la configuración de las pruebas tipo TPC-H:

Table 4. Configuración del parámetro de referencia tipo TPC-H para el caso de uso de cargas de trabajo de DSS

Parámetro tipo TPCH de HammerDB



1.000 3.000 4.000


2 (VM1 + VM2) 3 5

Cantidad de usuarios virtuales

2 1 3


30 30

Caso de uso 3: Carga de trabajo de OLTP de instantáneas con el uso de un parámetro de referencia tipo TPC-C

En la tercera prueba se crean instantáneas de almacenamiento de las bases de datos Oracle y SQL Server que ejecutan una carga de trabajo de OLTP ligera. El arreglo de almacenamiento PowerMax 2000 puede tomar instantáneas rápidas y coherentes con las escrituras de las bases de datos mediante SnapVX. Posteriormente, el DBA puede configurar las bases de datos de instantáneas y abrirlas para la empresa. Este enfoque de clonación de bases de datos permite que la organización de TI aprovisione rápidamente copias de bases de datos de producción con fines de pruebas y desarrollo. En el caso de uso de cargas de trabajo de bases de datos de OLTP de instantáneas, se crearon instantáneas de una base de datos Oracle y SQL Server desde la base de datos de prueba de OLTP de base.

La carga de trabajo de instantáneas se ejecutó en paralelo con las cargas de trabajo de OLTP y DSS para mostrar la carga acumulativa que se generó en la infraestructura de bases de datos. Dado que la mayoría de las bases de datos de prueba y desarrollo genera una carga de trabajo más ligera en comparación con las bases de datos de producción, la carga de trabajo de OLTP de bases de datos de instantáneas se configuró con recursos y perfiles de carga de bajo nivel en comparación con los dos casos de uso anteriores.

Table 5. Configuración del parámetro de referencia tipo TPC-C para el caso de uso de bases de datos de instantáneas

Parámetro tipo TPC-C de HammerDB



10.000 15.000 25.000


1 1,5 2,5

Número de usuarios 25 25 50


30 30




Niveles de servicio de PowerMaxOS

El sistema operativo del almacenamiento PowerMax, PowerMaxOS, utiliza el nivel de

servicio que se asocia con cada grupo de almacenamiento para mantener el rendimiento

del sistema. Cada nivel de servicio corresponde a un tiempo de respuesta objetivo que es

el tiempo de respuesta promedio previsto para el grupo de almacenamiento de acuerdo

con el nivel de servicio seleccionado.

PowerMaxOS define los siguientes niveles de servicio:

Diamond

Platinum

Gold

Silver

Bronze

Optimizado (predeterminado)

En los escenarios de casos de uso se asignaron diferentes niveles de servicio con el fin

de alcanzar el rango de rendimiento esencial para las cargas de trabajo de OLTP y DSS:

El nivel Diamond se asignó al grupo de almacenamiento de OLTP debido a que las

aplicaciones de OLTP requieren una respuesta inmediata a cada operación de I/O.

El nivel Bronze se asignó al grupo de almacenamiento de DSS, el cual tiene un

requisito menos estricto para los tiempos de respuesta.

En la siguiente tabla se muestran los niveles de servicio asociados con las pruebas

de los tres casos de uso que se llevaron a cabo:

Table 6. Niveles de servicio de PowerMaxOS implementados en los tres casos de uso

Caso de uso Nivel de servicio de PowerMax

Carga de trabajo de OLTP Diamond

Carga de trabajo de DSS Bronze

Carga de trabajo de OLTP de instantáneas Diamond

Dell EMC Live Optics se utilizó para recolectar datos y validar las pruebas de casos de

uso que se describen en este documento. Live Optics es software gratuito y sin agentes

que se utiliza para la recolección de datos de servidores PowerEdge. En solo minutos,

cualquier usuario puede configurar Live Optics para recolectar una gran cantidad de

información que permite analizar la configuración y la utilización de recursos. El tablero

intuitivo de Live Optics permite a los DBA monitorear y recolectar datos en las capas

de servidor y de virtualización de VMware.

En la siguiente figura se muestra un tablero de Live Optics. En el lado izquierdo se

muestra el rendimiento en los niveles de proyecto, hipervisores, servidores virtuales

y discos compartidos. En el lado derecho se muestran los datos recolectados y los

gráficos que permiten realizar un análisis visual rápido.

Dell EMC Live

Optics para

recolección

de datos



Figure 2. Tablero de Live Optics

Live Optics se utilizó durante las pruebas de validación para recopilar los datos que

se muestran en las tablas y los gráficos de toda esta guía. En la siguiente tabla se indica

el origen de datos de cada métrica de rendimiento en las pruebas de validación.

Table 7. Orígenes de métricas de rendimiento

Métrica de rendimiento Origen (informe)

Utilización de CPU Dstat

TPM HammerDB

NOPM HammerDB

IOPS Unisphere

Latencia del almacenamiento en milisegundos

Unisphere

Rendimiento en megabytes por segundo Unisphere

Chapter 4: Resultados de las pruebas de validación



Chapter 4 Resultados de las pruebas de validación


Descripción general ........................................................................................... 24

Utilización promedio de CPU ............................................................................ 24

TPM ...................................................................................................................... 26

NOPM ................................................................................................................... 29

IOPS del almacenamiento .................................................................................. 31

Latencia del almacenamiento ............................................................................ 34

Rendimiento ........................................................................................................ 37

Rendimiento combinado de IOPS, latencia y rendimiento ............................. 38

Chapter 5 Solución de respaldo y recuperación Data Domain 40

Introducción ........................................................................................................ 41

Solución de respaldo y recuperación para Oracle .......................................... 41

Solución de respaldo y recuperación para SQL Server ................................. 48



Descripción general

En este capítulo se revisan por completo las observaciones de cada prueba. En cada

sección se proporcionan métricas de rendimiento para los tres casos de uso con el fin

de mostrar cómo se desempeñó cada carga de trabajo de la solución en función de cada

métrica de rendimiento.

Cuando fue posible, las métricas de SQL Server y Oracle se combinaron en un

gráfico para mostrar el impacto de la carga de trabajo en el sistema. Esta información

es importante debido a que las pruebas de validación incremental aumentan en

complejidad y carga en el sistema para todos los casos de uso.

Utilización promedio de CPU

En la prueba del caso de uso de OLTP se muestran dos bases de datos SQL Server y una

base de datos Oracle que se ejecutan en el sistema sin otras cargas de trabajo. Esta es la

prueba de base y los resultados se usaron para comprender si la utilización promedio de CPU

en los servidores MX840c se ve afectada cuando la carga computacional aumenta en las

pruebas posteriores. Las métricas de utilización promedio de CPU se recopilaron mediante

Linux dstat. En cada VM de SQL Server había una reserva de 6 vCPU y en la VM de Oracle,

una de 10 vCPU. En la siguiente figura se muestra la utilización promedio de CPU:

Figure 3. Utilización promedio de CPU durante la prueba del caso de uso de OLTP

67%

67%

88%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

SQL Server 1

SQL Server 2

Oracle

OLT

P




En la prueba del caso de uso de DSS se agrega una carga de trabajo al sistema que analiza grandes conjuntos de datos mediante consultas complejas para proporcionar informes de análisis empresariales. En cada VM de SQL Server de DSS había una reserva de 8 vCPU y en la VM de Oracle, una de 8 vCPU. En la siguiente figura se muestra la utilización promedio de CPU para las cargas de trabajo de OLTP y DSS:

Figure 4. Utilización promedio de CPU para dos casos de uso

En la prueba del caso de uso de OLTP de instantáneas, se crearon instantáneas de PowerMax SnapVX y copias replanificadas de las bases de datos de OLTP de producción para una carga de trabajo de OLTP ligera. En la VM de SQL Server de instantáneas había una reserva de 4 vCPU y en la VM de Oracle de instantáneas, una de 6 vCPU.

Figure 5. Utilización promedio de CPU en los tres casos de uso

64%

64%

87%

73%

68%

12%

8%

9%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

SQL Server 1

SQL Server 2

Oracle

SQL Server 1

SQL Server 2

Oracle

SQL Server 1

Oracle

OLT

PD

SSSn

apsh

ot

OLT

P

63%

63%

87%

73%

72%

12%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

SQL Server 1

SQL Server 2

Oracle

SQL Server 1

SQL Server 2

OracleO

LTP

DSS



Los aumentos de las cargas de trabajo tuvieron un impacto menor en la utilización de CPU. Por ejemplo, en la prueba del caso de uso de OLTP de base, la utilización promedio de CPU de la base de datos SQL Server fue del 67 % (consulte la figura 3). Con la ejecución en paralelo de los tres casos de uso de cargas de trabajo (OLTP, DSS y OLTP de instantáneas), la utilización promedio de CPU fue solo del 64 %, como se muestra en la figura 5, con un impacto mínimo de 3 puntos porcentuales. Esta reducción en la utilización de CPU se produjo debido a la reducción en el manejo de IOPS en el caso de las cargas de trabajo mixtas, en comparación con el del caso de base. Los cambios menores en la utilización de CPU a pesar de las adiciones de cargas de trabajo demuestran que el sistema de cargas de trabajo mixtas ofrece un rendimiento constante.

TPM

En el parámetro de referencia de ingreso de pedidos tipo TPC-C, TPM indica la cantidad total de transacciones por minuto para la base de datos. Esto significa que TPM incluye transacciones del parámetro de referencia tipo TPC-C y otras transacciones en la base de datos. Por ejemplo, TPM incluye confirmaciones y reversiones. TPM no es una métrica que se pueda usar para comparar el rendimiento de las bases de datos, ya que estas implementan el rastreo de transacciones de manera diferente. Dado que TPM se obtiene de tablas basadas en la memoria en la base de datos, no afecta el rendimiento del parámetro de referencia.

En la siguiente figura se muestra el valor de TPM en la prueba del caso de uso de OLTP

de base.

Figure 6. TPM de base para las bases de datos de OLTP

Al no haber otras cargas de trabajo en ejecución en el sistema, la expectativa es que estos valores de TPM para las bases de datos SQL Server y la base de datos Oracle de OLTP sean los más altos. Cuando se agregó la carga de trabajo de DSS, en estos valores de TPM se observó una caída menor en relación con estos valores máximos.

En la prueba del caso de uso de DSS, el objetivo fue determinar el impacto que tendría la carga de trabajo de DSS en las métricas de TPM para las bases de datos OLTP. En la siguiente figura se muestra el valor de TPM de la base con bases de datos de OLTP y la carga de trabajo de DSS en ejecución en paralelo.

163,382 164,735

521,118

0

100,000

200,000

300,000

400,000

500,000

600,000

SQL Server 1 SQL Server 2 Oracle

TPM : OLTP




Figure 7. TPM de bases de datos de OLTP de base con carga de trabajo de DSS en ejecución en paralelo

La carga de trabajo de DSS en ejecución en paralelo con las bases de datos de OLTP tuvo

un impacto en el valor de TPM para las bases de datos SQL Server y Oracle de base:

OLTP de SQL Server 1 alcanzó 152.600 TPM, una diferencia de 10.782 respecto

del máximo de 163.382 de la prueba del caso de uso de OLTP.

OLTP de SQL Server 2 alcanzó 152.458 TPM, una diferencia de 12.277 respecto


OLTP de Oracle alcanzó 456.420 TPM, una diferencia de 64.698 respecto


Los clientes deben saber si la creación de una instantánea de una base de datos

con PowerMax SnapVX afectará el rendimiento de producción. Las bases de datos

de instantáneas se ejecutaron con una carga de trabajo de OLTP ligera y con el uso

del parámetro de referencia tipo TPC-C para analizar el impacto en las bases de datos

de OLTP de base. En la siguiente figura se muestran los resultados de TPM de los

tres casos de uso:

Solamente carga de trabajo de OLTP de base

Cargas de trabajo de OLTP + DSS

Cargas de trabajo de OLTP + DSS + instantánea

En la figura también se muestra la manera en que las cargas de trabajo en aumento

de cada caso de uso incremental afectaron el rendimiento de TPM de las bases de datos

de OLTP de base.

163,382 164,735

521,118

152,600 152,458

456,420

0

100,000

200,000

300,000

400,000

500,000

600,000


TPM : OLTP TPM : OLTP+DSS



Figure 8. Resultados de TPM con las cargas de trabajo de los tres casos de uso en ejecución en paralelo

En la prueba del caso de uso final, la adición de la carga de trabajo de la base de datos

de instantáneas sobre las cargas de trabajo de OLTP y DSS tuvo muy poco impacto en

el rendimiento de TPM de OLTP de base:

OLTP de SQL Server 1 alcanzó 157.536 TPM, una diferencia de 5.846 o de un 4 %

respecto del máximo de 163.382 de base.

OLTP de SQL Server 2 alcanzó 155.197 TPM, una diferencia de 9.538 o de un 6 %

respecto del máximo de 164.735 de base.

OLTP de Oracle alcanzó 521.118 TPM, igual al máximo de 521.118 de base.

Durante esta prueba del caso de uso final, las bases de datos de OLTP de instantáneas

ejecutaron una carga de trabajo tipo TPC-C ligera y alcanzaron los siguientes niveles

de TPM:

12.348 TPM para instantáneas de SQL Server

24.340 TPM para instantáneas de Oracle

En la mayoría de los entornos de cargas de trabajo mixtas, cada día se producen

variaciones menores en el rendimiento, pero el factor de éxito clave es la coherencia

del rendimiento en general. Por ejemplo, en la base de datos Oracle se observó la caída

más significativa en el valor de TPM con la carga de trabajo de DSS en ejecución. Sin

embargo, el rendimiento de la base de datos Oracle en la tercera prueba fue igual que

el rendimiento en la prueba de base de OLTP. Se esperan cambios menores en el

rendimiento, pero esta arquitectura de referencia para cargas de trabajo mixtas demostró

un rendimiento constante en todas las pruebas.

163,382 164,735

521,118

152,600 152,458

456,420

157,536 155,197

521,118

12,348 24,340

0

100,000

200,000

300,000

400,000

500,000

600,000

SQL Server 1 SQL Server 2 Oracle SQL Server 1SNAP

Oracle SNAP

TPM : OLTP TPM : OLTP+DSS TPM : OLTP+DSS+SNAP




NOPM

NOPM es una métrica que se consulta desde la tabla de distrito al inicio y al final del

parámetro de referencia tipo TPC-C. Algunas restricciones determinan si una transacción

de NOPM se puede reconocer y contar. Por ejemplo, las transacciones nuevo pedido,

pago y estado de pedido deben tener un tiempo de respuesta de 5 segundos o menos

para que se cuenten en la métrica NOPM.

NOPM se examina en esta guía porque tiene valor para el cliente. NOPM indica la

velocidad con la que una base de datos puede procesar transacciones en bases de datos

e infraestructuras distintas. En el contexto de estas pruebas de validación, las métricas

NOPM se aplican a un arreglo de almacenamiento empresarial de nivel de entrada, como

PowerMax 2000.

En la siguiente figura se muestran las métricas NOPM para la prueba de base del caso

de uso de OLTP.

Figure 9. Resultados de NOPM para la prueba de base del caso de uso de OLTP

Las dos bases de datos de OLTP de SQL Server se configuraron de manera idéntica para

la prueba tipo TPC-C, por lo que su rendimiento es muy parecido en términos de NOPM.

La base de datos de OLTP de Oracle tenía cuatro vCPU más y 48 GB más de memoria

asignada a la base de datos, por lo que su puntaje de NOPM es mayor.

La prueba de DSS no implica la ejecución de transacciones de ingreso de pedidos. Por lo

tanto, se examina la manera en que esta carga de trabajo afecta a NOPM para las bases

de datos de OLTP. En la siguiente figura se muestran las métricas de NOPM para las

pruebas de OLTP y DSS que se ejecutan en paralelo:



Figure 10. NOPM para la carga de trabajo de OLTP con la ejecución en paralelo de la carga de trabajo de DSS

Ambas bases de datos de OLTP de SQL Server mostraron una pérdida menor en NOPM:

OLTP de SQL Server 1 alcanzó 25.115 NOPM, una diferencia de 1.740 respecto

de la primera prueba de OLTP.

OLTP de SQL Server 2 alcanzó 24.989 NOPM, una diferencia de 2125 respecto

de la primera prueba de OLTP.

En el valor de NOPM de la base de datos de OLTP de Oracle se observó una

mejora en el rendimiento cuando la carga de trabajo de DSS se ejecutaba en

paralelo. La base de datos Oracle alcanzó 162.246 NOPM, un aumento de 2.605.

Las bases de datos de OLTP de instantáneas simularon actividad de prueba y

desarrollo mediante la ejecución de una carga de trabajo de OLTP ligera en el sistema.

En la siguiente figura se muestran los resultados:

Figure 11. NOPM con cargas de trabajo de OLTP, DSS y OLTP de instantáneas en ejecución en paralelo

26,855 27,114

159,641

25,115 24,989

162,246

0

20,000

40,000

60,000

80,000

100,000

120,000

140,000

160,000

180,000


NOPM : OLTP NOPM : OLTP+DSS

26,855 27,114

159,641

25,115 24,989

162,246

25,930 25,513

159,641

1,937 1,556

0

20,000

40,000

60,000

80,000

100,000

120,000

140,000

160,000

180,000

SQL Server 1 SQL Server 2 Oracle SQL Server 1SNAP

Oracle SNAP

NOPM : OLTP NOPM : OLTP+DSS NOPM : OLTP+DSS+SNAP




Con todas las cargas de trabajo en ejecución en paralelo, en ambas bases de datos

SQL Server de OLTP se observó una diferencia de rendimiento positiva:

SQL Server OLTP 1 alcanzó 25.930 NOPM: un aumento de 815 respecto

de la prueba anterior.

SQL Server OLTP 2 alcanzó 25.513 NOPM: un aumento de 524 respecto

de la prueba anterior.

En la base de datos de OLTP de Oracle se observó una leve pérdida de 2.605

NOPM respecto de la prueba anterior. (Casualmente, el valor de NOPM coincide

con el de la primera prueba).

En las dos bases de datos de instantáneas en las que se ejecutó una carga de trabajo

de OLTP ligera se generaron los siguientes resultados de NOPM:

La base de datos de instantáneas de SQL Server alcanzó 1937 NOPM.

La base de datos de instantáneas de Oracle alcanzó 1556 NOPM.

En términos de NOPM, en los servidores MX840c y en el arreglo PowerMax 2000 se observó

un rendimiento constante. Hubo fluctuaciones menores, tanto positivas como negativas,

pero estas no indicaron un impacto significativo en el rendimiento. En términos generales, la

arquitectura de referencia para cargas de trabajo mixtas demostró el rendimiento constante

necesario para la consolidación de bases de datos y cargas de trabajo.

IOPS del almacenamiento

La cantidad de IOPS demuestra la carga en un sistema de almacenamiento. Las

innovaciones, como SSD y unidades flash NVMe, han aumentado las densidades

de IOPS, lo que permite que los arreglos de almacenamiento admitan más bases

de datos y una mayor diversidad de cargas de trabajo.

Para esta solución se estructuraron pruebas incrementales, de modo que, en términos de

carga del almacenamiento, la carga de trabajo de IOPS más exigente, es decir, las bases

de datos de OLTP, fue la primera en probarse. Luego, todas las demás cargas de trabajo

incrementales tendrían un impacto mínimo en las bases de datos de OLTP. Una leve pérdida

de IOPS no representa un impacto significativo en el rendimiento de la base de datos.

En las observaciones de la prueba del caso de uso de OLTP se aprecia que las bases

de datos SQL Server de OLTP 1 y 2 generaron 16.627 y 17.304 IOPS, respectivamente,

en el arreglo de almacenamiento PowerMax 2000, y que la única base de datos Oracle

generó 42.145 IOPS. Debido a que estas tres bases de datos cuentan con la asignación

de la infraestructura completa para su rendimiento durante la primera prueba, la

expectativa fue que se alcanzaran los máximos valores de IOPS durante las pruebas.

En la siguiente tabla se resumen las IOPS de cada base de datos de OLTP:

Table 8. IOPS de las bases de datos de OLTP

Carga de trabajo

Base de datos IOPS

OLTP SQL Server 1 17.304

SQL Server 2 16.627

Oracle 42.145

Total 76.076



La adición de cargas de trabajo de DSS genera una carga de IOPS adicional en los arreglos de almacenamiento. Sin embargo, también se debe tener en cuenta el tamaño promedio de I/O de lectura y escritura. En la siguiente tabla se muestra el tamaño promedio de I/O de lectura y escritura para cada una de las bases de datos:

Table 9. Tamaños promedio de I/O de lectura y escritura para cada base de datos en las cargas de trabajo de OLTP y DSS

Base de datos de DSS Tamaño de I/O de lectura (KB) Tamaño de I/O de escritura (KB)

SQL Server 1 180,17 64,2

SQL Server 2 157,97 63,99

Oracle 127,82 184,70

Base de datos de OLTP Tamaño de I/O de lectura (KB) Tamaño de I/O de escritura (KB)

SQL Server 1 12,95 8,90

SQL Server 2 13,04 8,98

Oracle 10,48 10,94

A pesar de que las cifras de IOPS de las cargas de trabajo de DSS parecen bajas en comparación con las cifras de IOPS de las bases de datos de OLTP, los tamaños más grandes de lectura/escritura de I/O significan que se transfieren más datos en cada operación de almacenamiento. De este modo, en el caso de DSS, la cantidad de IOPS es menor que la de OLTP, pero la carga en el arreglo de almacenamiento es significativa debido a que los datos que se transfieren son más grandes. Por lo tanto, el rendimiento de las cargas de trabajo de DSS, en general, se mide en términos de rendimiento capturado como MB/s en lugar de IOPS.

En la siguiente tabla se resumen las cifras de IOPS para las cargas de trabajo de OLTP y DSS:

Table 10. IOPS para las cargas de trabajo de OLTP y DSS

Carga de trabajo

Bases de datos IOPS


SQL Server 2 16.410

Oracle 40.387

DSS SQL Server 1 6.783

SQL Server 2 6.720

Oracle 13.842

Total 100.559

En comparación con las cifras de IOPS de las dos cargas de trabajo de bases de datos de OLTP, se produjo una leve pérdida de un 3,5 % en promedio en IOPS cuando se agregó la carga de trabajo de DSS. De manera previsible y razonable, colocar más carga en un arreglo de almacenamiento tiene un leve impacto en las cargas de trabajo de bases de datos. El punto clave es que el rendimiento permanece en un rango que cumple con los SLA de la empresa.




Las cargas de trabajo de bases de datos de OLTP de instantáneas representan las bases de datos de prueba y desarrollo. En la siguiente tabla se muestran los resultados de IOPS de las tres bases de datos con casos de uso de cargas de trabajo mixtas en ejecución en paralelo:

Table 11. Resultados de IOPS con los tres casos de uso de cargas de trabajo en ejecución en paralelo

Carga de trabajo Base de datos IOPS


SQL Server 2 16.177

Oracle 42.234

DSS SQL Server 1 6.375

SQL Server 2 7.587

Oracle 13.688

OLTP de instantáneas

SQL Server 1 1.332

Oracle 3.103

Total 106.139

Al comparar la nueva combinación de cargas de trabajo con la combinación anterior, se produjo una leve pérdida de aproximadamente un 4 % en IOPS para las bases de datos de OLTP cuando aumentó la carga de trabajo. En las observaciones de la prueba se aprecia que, a medida que aumentó la carga de trabajo en el arreglo PowerMax, el rendimiento de IOPS se mantuvo estable (consulte la tabla 8, la tabla 10 y la tabla 11). La funcionalidad del arreglo de almacenamiento para mantener el rendimiento de IOPS a medida que la carga de trabajo aumentó demuestra la solidez de la plataforma PowerMax para la consolidación de bases de datos y cargas de trabajo mixtas.

En el mapa de árbol de la siguiente figura se muestra la distribución de IOPS para cada base de datos en los tres casos de uso de cargas de trabajo que se ejecutan en paralelo. Como indican los mosaicos azules, de las tres bases de datos de OLTP, Oracle generó la mayor cantidad de IOPS, mientras que las dos bases de datos SQL Server generaron IOPS que variaron entre 15.643 y 16.177. Los mosaicos naranjas representan la adición de las bases de datos de DSS, y los mosaicos grises, la adición de la base de datos de OLTP de instantáneas.



Figure 12. Mapa de árbol de IOPS en función de los resultados de las pruebas de los tres casos de uso de cargas de trabajo

Latencia del almacenamiento

La latencia del almacenamiento es el tiempo que tarda un arreglo de almacenamiento en completar una solicitud de lectura o confirmar una escritura en la base de datos. Las innovaciones en los medios de almacenamiento han reducido la latencia del almacenamiento. Por ejemplo, antes de SSD flash, las latencias del almacenamiento solían medirse en milisegundos. Las unidades flash, en las que se lograron latencias inferiores a 1 ms, representaron un avance significativo. Las unidades NVMe ofrecen una mayor eficacia y permiten reducir aún más las latencias de lecturas y escrituras. El objetivo general de las pruebas de esta arquitectura de referencia fue alcanzar 1 ms o menos en todas las latencias del almacenamiento en promedio tanto para las lecturas como para las escrituras.

En el caso de las cargas de trabajo de OLTP, las lecturas físicas desde el almacenamiento suelen ser operaciones de I/O aleatorias de bloques pequeños. El rendimiento de las bases de datos y las aplicaciones depende de la rapidez con la que se pueden leer los datos desde el almacenamiento. Por lo tanto, mientras menor sea la latencia de lectura, más rápido podrán acceder los usuarios de las aplicaciones a los datos cruciales. Por lo general, las bases de datos SQL Server y Oracle realizan miles o millones de lecturas por hora, según la carga de la empresa. En la prueba de validación de base de OLTP, la expectativa fue que las bases de datos SQL Server y Oracle demostraran la latencia probada más baja, ya que durante esa prueba no hubo otras cargas de trabajo en el arreglo PowerMax 2000. En las siguientes tablas se muestran las latencias de lectura y escritura promedio de la carga de trabajo de OLTP:

Table 12. Latencias de lectura promedio para la carga de trabajo de OLTP

Carga de trabajo Base de datos Latencias de lectura promedio (ms)

LUN de datos LUN de registros

OLTP SQL Server 1 0,47 0,21

SQL Server 2 0,47 0,23

Oracle 0,47 0,29




Table 13. Latencias de escritura promedio para la carga de trabajo de OLTP

Carga de trabajo Base de datos Latencias de escritura promedio (ms)




Oracle 0,35 0,64

La latencia de lectura promedio para los LUN de datos y registros de las bases de datos

SQL Server y de la base de datos Oracle se mantuvo por debajo de 0,5 ms. La latencia

de escritura promedio para los LUN de datos y registros fue menos de 0,4 ms, excepto

para el LUN de registros de Oracle, el cual promedió 0,64 ms. Durante las pruebas se

destacaron algunas latencias promedio excepcionalmente bajas:

Las latencias de lectura de las bases de datos SQL Server y Oracle en los LUN

de registros promediaron 0,29 ms o menos.

Las latencias de escritura de las bases de datos SQL Server en los LUN de datos

promediaron 0,2 ms o menos.

Las latencias de escritura de las bases de datos SQL Server en los LUN de registros

promediaron 0,18 ms o menos.

En las pruebas del caso de uso de DSS, el rendimiento es la métrica de rendimiento

clave, ya que la base de datos analizaba tablas grandes y solicitaba bloques de datos

grandes desde el arreglo PowerMax 2000. En las siguientes tablas se documentan las

observaciones de las pruebas, en las que se muestra el impacto de la adición de la carga

de trabajo de DSS en las latencias de las cargas de trabajo de OLTP de base.

Table 14. Latencias de lectura promedio para la carga de trabajo de OLTP con la ejecución en paralelo de la carga de trabajo de DSS

Table 15. Latencias de escritura promedio para la carga de trabajo de OLTP con la ejecución en paralelo de la carga de trabajo de DSS





Oracle 0,31 0,69

Carga de trabajo

Base de datos Latencias de lectura promedio (ms)




Oracle 0,60 0,47



La adición de la carga de trabajo de DSS causó el aumento de las latencias de lectura

promedio, pero esto se esperaba debido al aumento de la carga en el arreglo. Todas

las latencias de lectura promedio se mantuvieron por debajo del objetivo de 1 ms.

La adición de la carga de trabajo de DSS tuvo un impacto menor en las latencias de

escritura promedio para los datos y el registro. Las latencias de escritura promedio se

mantuvieron coherentemente bajas, debido a que la caché de PowerMax acelera todas las

escrituras en el almacenamiento. En este caso, las latencias de escritura se mantuvieron

por debajo de 0,24 ms para todas las bases de datos SQL Server y, para Oracle, por

debajo de 0,35 ms para los LUN de datos y de 0,69 ms para los LUN de registros.

Para el caso de uso final, se agregaron las cargas de trabajo de OLTP de instantáneas sobre

las cargas de trabajo de OLTP y DSS. En las observaciones de la prueba se aprecia un

aumento menor en las latencias de lectura promedio para los datos. Por ejemplo, la latencia

aumentó 0,08 ms para los LUN de datos de SQL Server y Oracle. Las latencias de lectura

promedio para los LUN de registros de SQL Server no aumentaron, mientras que las del LUN

de registros de Oracle aumentaron en 0,08 ms. Para la carga de trabajo de OLTP, todas las

latencias de lectura promedio se mantuvieron por debajo del objetivo de 1 ms, como se

muestra en la siguiente tabla:

Table 16. Latencias de lectura promedio para las cargas de trabajo de OLTP y OLTP de instantáneas con la ejecución en paralelo de la carga de trabajo de DSS

Como se muestra, la base de datos SQL Server de OLTP de instantáneas tuvo una

latencia de lectura promedio de 1,10 ms para los datos, pero, debido a que esta base

de datos simulaba un entorno de prueba y desarrollo, el objetivo de latencia fue menos

crítico. Para la misma base de datos, las latencias de registros fueron de 0,83 ms,

lo que está por bajo del objetivo de 1 ms.

En la base de datos Oracle de OLTP de instantáneas se observaron latencias de

lectura y escritura promedio bajas de 0,51 ms y 0,26 ms, respectivamente, para los LUN

de registros. Además, todas las latencias de lectura y escritura promedio para Oracle

estuvieron por debajo del objetivo de rendimiento de 1 ms.

Carga de trabajo Base de datos Latencias de lectura promedio (ms)




Oracle 0,68 0,55



Oracle 0,82 0,51




Estas observaciones de la prueba muestran la funcionalidad de la caché de PowerMax

para acelerar la mayoría de las escrituras en el arreglo de almacenamiento. Todas las

latencias de escritura promedio para SQL Server y Oracle fueron de 0,31 ms o menos,

con excepción de los 0,75 ms de los LUN de registros de Oracle, como se muestra

en la siguiente tabla:

Table 17. Latencias de escritura promedio para las cargas de trabajo de OLTP y OLTP de instantáneas con la ejecución en paralelo de la carga de trabajo de DSS


Datos Log



Oracle 0,31 0,75

OLTP de instantáneas SQL Server 1 0,26 0,24

Oracle 0,25 0,26

Durante las pruebas, surgió un patrón de latencias muy bajas para las I/O de escritura

en el arreglo. Se observó que las latencias de escritura eran considerablemente menores

que las de lectura. Esto es algo previsto debido a que el arreglo PowerMax tiene una

caché de gran tamaño que acelera las I/O y que da preferencia al almacenamiento en

caché de todas las solicitudes de escritura. Además, todas las escrituras en la caché

de PowerMax se confirman inmediatamente en la aplicación de base de datos.

Rendimiento

Además de la ejecución de cargas de trabajo de OLTP, se ejecutó una carga de trabajo

de DSS mediante el parámetro de referencia tipo TPC-H de HammerDB.

Nota: La prueba “tipo TPC-H” significa que los resultados no están certificados.

La prueba de carga de trabajo de DSS simula consultas ad hoc que están diseñadas para

ayudar a la empresa con el análisis de decisiones. Además, la prueba también simula las

modificaciones simultáneas de datos, en las que se modifican varios conjuntos de datos

en paralelo. Las consultas son complejas, lo que refleja que la base de datos debe unir

y agregar (filtrar o agrupar) grandes conjuntos de datos para ayudar a la empresa con

el análisis de decisiones.

Se utilizó un factor de escala (SF) de 1000 para SQL Server y de 3000 para las pruebas

de DSS de Oracle. El SF define el tamaño de la base de datos. Por ejemplo, un SF de

1 indica 1 GB. Dado que se utilizó un SF de 1000 en la prueba, el tamaño de la base

de datos fue de 1000 GB para SQL y de 3000 GB para Oracle. El SF también define la

cantidad mínima de flujos de consultas. Por ejemplo, especifica un mínimo de siete flujos

de consultas para un SF de 1000 y un mínimo de ocho flujos de consultas para un SF

de 3000. Un flujo de consultas es un conjunto de consultas que se deben ejecutar en

serie, una tras otra. En el caso de cada base de datos SQL Server, se ejecutó solamente

un flujo de consultas y se ejecutaron 17 de las 22 consultas. Para cada base de datos

Oracle, se ejecutó un flujo de consultas en el que se ejecutó un subconjunto de consultas.



No se recopilaron métricas tipo TPC-H formales, como Throughput@Size, porque el alcance de la prueba de validación se centró únicamente en el rendimiento del almacenamiento.

El enfoque en la ejecución de la carga de trabajo de DSS fue generar rendimiento en el arreglo PowerMax 2000. El rendimiento es la cantidad de datos sostenidos que se transfieren de acuerdo con lo que admite la infraestructura.

En la siguiente tabla se muestran los resultados de las pruebas de rendimiento que se obtuvieron del informe de almacenamiento de PowerMax para los LUN de datos de SQL Server y Oracle:

Table 18. Resultados de las pruebas de rendimiento

Base de datos de DSS OLTP y DSS en paralelo

OLTP, DSS y OLTP de instantáneas en paralelo

IOPS MB/s del host IOPS MB/s del host

SQL Server 1 6.783 631 6.375 644

SQL Server 2 6.720 625 7.587 714

Oracle 13.842 1.731 13.688 1712

En las bases de datos SQL Server y Oracle se observó un rendimiento e IOPS estables o mejorados a medida que la carga de trabajo aumentó y se hizo más compleja. Por lo tanto, en las pruebas se demuestra que el nivel de rendimiento mejora con un mayor tamaño y complejidad de la carga de trabajo.

Rendimiento combinado de IOPS, latencia y rendimiento

Por lo general, las organizaciones de TI y los equipos de DBA se ocupan de las variaciones entre IOPS y latencia. Por ejemplo, cuanto mayor sea la cantidad de bases de datos, más IOPS habrá en el arreglo de almacenamiento y mayor será la latencia. Esta variación entre IOPS y latencia se presenta con el tiempo. Inicialmente, el rendimiento del almacenamiento es bueno y las bases de datos tienen tiempos de latencia bajos. Con el tiempo, se agregan más aplicaciones al arreglo y la variación se inclina hacia las IOPS, lo que afecta negativamente el rendimiento de las aplicaciones y las bases de datos.

Al probar esta arquitectura con bases de datos y cargas de trabajo mixtas, se consolidaron ocho bases de datos (cinco bases de datos SQL Server y tres bases de datos Oracle) para determinar dónde se producía la variación entre IOPS y latencia en el arreglo PowerMax 2000. Con ocho bases de datos en ejecución en paralelo, se generó un total de 106 139 IOPS para 24 unidades flash NVMe. En la siguiente tabla se combinan las IOPS, las latencias y los resultados de las pruebas de rendimiento de todas las cargas de trabajo mixtas en las pruebas de validación:

Table 19. IOPS, latencias de lectura promedio y rendimiento en todas las cargas de trabajo

Carga de trabajo Base de datos IOPS

Latencias de lectura promedio (ms) Rendimiento

del host (MB/s) Datos Log

OLTP SQL Server 1 15.643 0,87 0,26

SQL Server 2 16.176 0,87 0,27

Oracle 42.234 0,68 0,55

DSS SQL Server 1 6.375 631

SQL Server 2 7.587 625

Oracle 13.688 1.712


SQL Server 1 1.332 1,10 0,26

Oracle 3.103 0,83 0,51




Con todas las cargas de trabajo en ejecución en paralelo, el arreglo PowerMax admitió más

de 105 000 IOPS y mantuvo latencias de lectura promedio inferiores a 1 ms para todas las

bases de datos, con excepción de la base de datos SQL Server de OLTP de instantáneas

1. Para forzar más lecturas físicas desde el almacenamiento, se asignó una cantidad de

memoria mínima a las bases de datos. Por ejemplo, se asignaron solamente 8 GB a las

bases de datos SQL Server. La mayoría de los clientes proporcionará más memoria a sus

bases de datos, por lo que sus latencias de lectura promedio serán menores.

Las latencias de escritura promedio en todos los casos de uso de cargas de trabajo

fueron coherentemente bajas, en su mayoría inferiores a 0,31 ms. La única excepción

es la latencia de escritura promedio de la base de datos Oracle de OLTP, la que fue

de 0,75 ms para el LUN de registros. Todas las latencias de escritura promedio se

mantuvieron muy por debajo del objetivo de 1 ms o menos para el rendimiento del

almacenamiento, como se muestra en la siguiente tabla:

Table 20. IOPS, latencias de escritura promedio y rendimiento en todas las cargas de trabajo

Carga de trabajo

Base de datos IOPS

Latencias de escritura promedio (ms) Rendimiento

del host (MB/s) Datos Log

OLTP SQL Server 1 15.643 0,24 0,22

SQL Server 2 16.176 0,24 0,20

Oracle 42.234 0,31 0,75

DSS SQL Server 1 6.375 631

SQL Server 2 7.587 625

Oracle 13.688 1.712


SQL Server 1 1.332 0,26 0,22

Oracle 3.103 0,25 0,26

En las observaciones se demuestra que no hubo variación entre IOPS y latencias del

almacenamiento a pesar de que la configuración de PowerMax 2000 de nivel de entrada

con 24 unidades flash NVMe tuvo que admitir ocho bases de datos y una combinación

de cargas de trabajo de OLTP y DSS. Los clientes pueden confiar en que una solución

de bases de datos y cargas de trabajo mixtas del tamaño correcto basada en servidores

PowerEdge MX840c y arreglos PowerMax 2000 puede escalar y, a la vez, proporcionar

un sólido rendimiento del almacenamiento.

Chapter 5: Solución de respaldo y recuperación Data Domain


Chapter 5 Solución de respaldo y recuperación Data Domain


Introducción ........................................................................................................ 41

Solución de respaldo y recuperación para Oracle .......................................... 41

Solución de respaldo y recuperación para SQL Server ................................. 48




Introducción

Las infraestructuras de bases de datos almacenan y administran los datos esenciales de

la empresa. Cualquier tiempo de inactividad de estas bases de datos afecta negativamente

a la empresa y la experiencia del cliente de muchas maneras. Por lo tanto, es esencial

proporcionar soluciones de respaldo y recuperación óptimas que puedan manejar cualquier

circunstancia imprevista que pudiera paralizar las operaciones empresariales. También puede

usar soluciones de respaldo y recuperación para crear ambientes de pruebas que simulan

sistemas de producción con diversos fines, como las actualizaciones y la determinación del

dimensionamiento. El equipo de diseño validado de Dell EMC probó una solución de respaldo

y recuperación que puede admitir las cargas de trabajo de bases de datos que se analizan

en esta guía.

Solución de respaldo y recuperación para Oracle

Tecnología DD Boost

Durante la operación de respaldo de una base de datos con Oracle RMAN, la base de

datos Oracle envía respaldos al sistema Data Domain por medio de la red Fibre Channel

o Ethernet. Se seleccionó el protocolo DD Boost mediante Ethernet para aprovechar las

funciones probadas de rendimiento y desduplicación de la tecnología DD Boost. En esta

configuración, tanto la función DD Boost como el procesamiento distribuido de segmentos

(DSP) están habilitados. El software DD Boost se ejecuta en el servidor de base de datos

Oracle y en el sistema Data Domain. Como se muestra en la siguiente figura, para cada

segmento respaldado, el software DD Boost determina si el segmento es único (es decir,

no se ha almacenado anteriormente en el sistema Data Domain). Cuando DD Boost

confirma que el segmento es único, este se comprime, se transfiere a través de la red

y se almacena en el sistema Data Domain. Los procesos de desduplicación y compresión

garantizan que solamente los datos únicos se compriman, se envíen a través de la red

y se almacenen en el sistema Data Domain.

Durante el primer respaldo completo de la base de datos, debido a que no hay datos

de esta base de datos almacenados en el sistema Data Domain, todos los segmentos

de datos del respaldo son únicos. En consecuencia, cada segmento de datos del primer

respaldo completo se comprime, se envía a través de la red y se almacena en el sistema

Data Domain. A partir del segundo respaldo completo, el software DD Boost respalda

solamente los segmentos de datos únicos que no se han almacenado anteriormente en

el sistema Data Domain.

Consideraciones

de diseño



Figure 13. Software DD Boost determinando si el segmento es único

Almacenamiento y sistema de archivos

El sistema Data Domain incluye un conjunto de discos para almacenar respaldos

de bases de datos. Durante la configuración inicial de Data Domain, estos discos

se asignaron a grupos de discos, de modo que se pudieran usar para crear sistemas

de archivos con el fin de almacenar respaldos de bases de datos.

El sistema Data Domain DD9300 que se utilizó en las pruebas tiene una unidad

principal con 12 discos y cuatro gabinetes de discos (DS60) con 60 discos cada uno.

En la unidad principal, se utilizan cuatro discos como los discos del sistema y ocho

como nivel de caché. A partir de los cuatro gabinetes de discos, se crearon 15 grupos de

discos, cada uno con 14 discos y un disco de repuesto. Cada grupo de discos tiene una

capacidad de almacenamiento útil de 38,21 TiB. Los 15 grupos de discos proporcionan

un total de 573,15 TiB de capacidad de almacenamiento físico útil que se puede usar

para almacenar las imágenes de respaldo de las bases de datos.

Durante el proceso de inicialización del sistema Data Domain, el sistema de archivos se

habilitó mediante la ejecución de un comando de habilitación en la línea de comandos

del sistema Data Domain. En el siguiente comando se muestra un ejemplo del uso del

espacio del sistema de archivos en un sistema DD9300.

Figure 14. Ejemplo de uso del espacio del sistema de archivos en DD9300




Mtree y unidad de almacenamiento

Se creó una unidad de almacenamiento en el sistema Data Domain que se usará con

el agente de aplicación de base de datos en el servidor de base de datos para respaldar

los archivos de la base de datos, como se muestra en el siguiente ejemplo:

Figure 15. rman de la unidad de almacenamiento creado en DD9300 con fines de pruebas de respaldo y recuperación

Las unidades de almacenamiento se muestran como una partición lógica del sistema

de archivos Mtree:

Figure 16. Unidades de almacenamiento vistas como particiones lógicas del sistema de archivos Mtree

Para implementar la función de desduplicación optimizada de Oracle en un sistema

Data Domain, el valor de la opción app_optimized-compression se configuró

en <user_name> en Mtree con este comando:

mtree option set app-optimized-compression <user_name> mtree

<storage_unit_name>

Por ejemplo, estos comandos se ejecutaron en la línea de comandos del sistema

Data Domain para la unidad de almacenamiento rman:

$mtree option set app-optimized-compression oracle1 mtree rman

Diseño de la red IP

El dispositivo Data Domain se conecta al servidor de base de datos Oracle dentro del

chasis de infraestructura MX7000 de esta arquitectura de referencia mediante cuatro

interfaces de 10 GbE de front-end distribuidas en dos NIC instaladas en el sistema

DD9300. Estas cuatro interfaces de 10 GbE de front-end dentro de DD9300 se conectan

a los mismos switches centrales a los cuales se conectan los IOM de red MX9116n

dentro del chasis MX7000.

Dentro de DD9300, se creó un nuevo grupo de interfaces de red y se agregaron a él

estas cuatro interfaces de front-end, como se muestra en la siguiente figura. Para que

el servidor de base de datos Oracle pudiera comunicarse con el dispositivo de respaldo,

estas interfaces de front-end de DD9300 se configuraron dentro del mismo rango de

direcciones de red IP que las direcciones IP de la red pública de la base de datos Oracle.



Figure 17. DD9300: Configuración de la red IP mediante grupos de interfaces

Nota: En Protocols -> DD Boost -> IP Network, como se mostró anteriormente, el nombre

de host de la base de datos Oracle se agregó bajo Configured Clients y se comprobó que usara

el grupo de interfaces de 10 GbE que se creó.

Para registrar y conectar el servidor de base de datos como un cliente con el sistema Data

Domain, se seleccionó la dirección IP estática asignada a una de las interfaces en Data

Domain. Al habilitar internamente el balanceo de carga y la funcionalidad de conmutación por

error entre las interfaces de red configuradas dentro de un grupo, la configuración del grupo

de interfaces proporcionó un ancho de banda de red sólido y una red de respaldo de alta

disponibilidad entre los servidores de base de datos y el sistema Data Domain.

Parámetros de respaldo y restauración de RMAN

Para probar el respaldo y la recuperación, se usó el caso de uso 1: Configuración

de la base de datos de OLTP de Oracle que se describe en el capítulo 3: Objetivos,

configuración y casos de uso de las pruebas de validación. Se utilizaron los siguientes

ajustes de Oracle RMAN en las pruebas de respaldo y restauración de la base de datos

OLTP de Oracle.

Table 21. Ajustes de Oracle RMAN

Operación Parámetro Configuración

Respaldo de la base de datos de OLTP de Oracle

PARALLELISM 8


SECTION SIZE

4 GB


BLKSIZE 1.048.576

Recuperación de la base de datos de OLTP de Oracle

PARALLELISM 32

Recuperación de la base de datos de OLTP de Oracle

BLKSIZE 1.048.576




Se realizaron varias pruebas de respaldo y recuperación en el sistema DD9300 con

el uso del caso de uso 1: Configuración de la base de datos de OLTP de Oracle que

se describe en el capítulo 3: Objetivos, configuración y casos de uso de las pruebas de

validación. En las siguientes descripciones se proporcionan los detalles de tres casos

de prueba o casos de uso de respaldo y recuperación que se llevaron a cabo en esta

arquitectura de referencia.

Caso de uso 1: Primer respaldo completo de la base de datos de OLTP independiente

Se realizó un respaldo completo de una base de datos Oracle de 1,8 TB mediante el

software DD Boost. DD Boost se integra con RMAN y permite la desduplicación basada

en host de respaldos de bases de datos en el dispositivo Data Domain. Un respaldo

completo elimina la dependencia de otros respaldos, lo que simplifica la administración

y la restauración de respaldos después de una falla no planificada.

En este caso de uso, se utilizó el dispositivo DD Boost para realizar el primer respaldo

completo de la base de datos de producción. En la configuración probada, se utilizó una

conexión LAN de 4 puertos de 10 GbE a DD9300, como se muestra en la siguiente figura.

Figure 18. Caso de uso 1: Diagrama de la arquitectura del primer respaldo completo

El primer respaldo completo de una base de datos Oracle es único en su totalidad; por

lo tanto, todos los datos se protegen en el sistema DD9300. El valor de la desduplicación

basada en host comienza con el segundo respaldo completo. En el segundo respaldo,

solamente los datos nuevos o modificados son únicos; por lo tanto, el software DD Boost

envía solo un pequeño subconjunto de información al sistema Data Domain para su

protección. A pesar de que el primer respaldo completo es único, una vez que los datos

se han protegido en Data Domain, se comprimen.

En la siguiente figura se muestran los ahorros debido al factor de compresión local

en función del algoritmo predeterminado (rendimiento maximizado) en el sistema Data

Domain. Existe una relación entre la cantidad de datos únicos y el factor de compresión

local: cuanto mayor sea la cantidad de datos únicos, mayor será la oportunidad de

compresión y el factor de compresión. Por ejemplo, el primer respaldo consta de datos

completamente únicos y tiene el mayor factor de compresión.

Metodología

y resultados

de la prueba



Figure 19. Tasa de compresión del primer respaldo completo

Esta compresión ahorra espacio significativo en el sistema Data Domain. En los resultados de las pruebas de ingeniería de Dell EMC se observa que el factor de compresión fue de 1,4 veces: un 29,9 % de ahorro de espacio para el primer respaldo completo. La configuración de la arquitectura de referencia logró realizar esta tarea de respaldo completo y compresión de 1,8 TB en 38 minutos, con un rendimiento del respaldo de 815 MB/s.

Caso de uso 2: Segundo respaldo completo de la base de datos de OLTP independiente

El objetivo de este caso de uso fue realizar un segundo respaldo completo de la misma base de datos Oracle para mostrar el valor de la desduplicación basada en host de DD Boost. La desduplicación basada en host significa que el software DD Boost se comunica con el sistema Data Domain para determinar si un bloque de datos es único. Si el bloque es único, se envía al sistema Data Domain para su protección. Si el bloque no es único, no se envía a Data Domain. El valor de la desduplicación basada en host es que ahorra utilización y espacio de la red en el dispositivo Data Domain. La tecnología DD Boost funciona de manera transparente con RMAN, lo que significa que RMAN ve un respaldo completo de la base de datos en el sistema DD9300.

Antes de ejecutar un segundo respaldo completo, los datos existentes se modificaron mediante la ejecución de algunas transacciones. Para simular condiciones reales, se utilizó HammerDB y se ejecutaron transacciones de OLTP durante 10 minutos con el fin de crear aproximadamente un 5 % de datos modificados. Estos datos modificados consistieron en un 1 % de inserciones y un 4 % de actualizaciones para asegurarse de que el software DD Boost respalde datos nuevos y modificados.

En la siguiente figura se muestra la arquitectura del caso de uso 2.




Figure 20. Caso de uso 2: Segundo respaldo completo con un 5 % de modificación de datos

En la siguiente figura se muestran los ahorros debido al factor de compresión local que se

obtienen con el algoritmo predeterminado (rendimiento maximizado) en el sistema Data

Domain para el segundo respaldo completo. En las pruebas se observa que se enviaron

solamente datos únicos a Data Domain y que, después de la compresión local, el tamaño

final fue de 109 GB. La desduplicación basada en host de DD Boost combinada con la

compresión local en Data Domain permiten ahorrar una cantidad significativa de espacio. La

ejecución de respaldos completos diarios es sencilla debido a que el espacio que se utiliza en

el sistema Data Domain es un pequeño subconjunto del tamaño real de la base de datos.

Figure 21. Tasa de compresión del segundo respaldo completo

La compresión y la desduplicación permiten ahorrar espacio significativo en el sistema

DD9300. En los resultados de las pruebas de ingeniería de Dell EMC se observa que el

factor de compresión fue de 16,7 veces: un 94 % de ahorro de espacio para el segundo

respaldo completo.

El segundo respaldo completo tardó significativamente menos tiempo en comparación

con el primer respaldo completo. El segundo respaldo completo de una base de datos

Oracle de 1,8 TB tardó solamente 25 minutos, 13 minutos menos que el primer respaldo

completo (38 minutos) y logró un rendimiento de 1191 MB/s. Es importante que el tiempo

necesario para los respaldos de las bases de datos se mantenga predecible y minimizado

con el fin de reducir el impacto en la empresa.



Caso de uso 3: Restauración y recuperación de la base de datos de OLTP a partir de un respaldo completo

Las fallas imprevistas pueden representar un riesgo significativo para la empresa debido

a la detención de las operaciones de back-office, lo que afecta los ingresos. El respaldo

y la protección de las bases de datos preparan a la empresa para recuperarse de una

falla imprevista. En esta prueba se realizó una restauración desde el sistema Data

Domain respaldada en los servidores de base de datos Oracle. El objetivo de este caso

de uso fue probar cuán rápida y satisfactoriamente esta arquitectura de referencia puede

restaurar y recuperar una base de datos Oracle de 1,8 TB que se protegió mediante el

sistema Data Domain.

En la siguiente figura se muestra la arquitectura del caso de uso 3:

Figure 22. Caso de uso 3: Diagrama de la arquitectura de la restauración de la base de datos completamente respaldada

En este caso de uso, el tiempo total capturado incluye lo siguiente:

El tiempo necesario para la “restauración”, lo que incluye copiar los archivos de

la base de datos completamente respaldada desde el sistema DD9300 a la base

de datos Oracle principal y

El tiempo necesario para la “recuperación”, lo que incluye la aplicación de registros

de reconstitución en línea y archivados a los datos restaurados mediante RMAN

y la apertura de la base de datos para el procesamiento.

En esta prueba, la base de datos Oracle de 1,8 TB se restauró por completo y se

recuperó correctamente desde el respaldo en 25 minutos, con solo un 15 % de utilización

promedio de CPU en el servidor de base de datos Oracle.

Solución de respaldo y recuperación para SQL Server

El agente Data Domain Boost for Enterprise Applications (DDBEA) se integra con la utilidad

de administración nativa de aplicaciones y permite realizar respaldos y restauraciones

eficientes entre el host de aplicaciones y el sistema DD9300 mediante el protocolo DD

Boost. El agente DDBEA de SQL Server en Windows es compatible y está disponible

para su descarga. Si tiene más preguntas, póngase en contacto con el representante

de cuentas local.

https://cpsdocs.dellemc.com/bundle/P_DP_PG/page/GUID-DD1F697B-85A2-40CB-AE68-5F6C5713D159.html

https://download.emc.com/downloads/DL91864_Microsoft_App_Agent_4.7_(Windows_x64).zip?language=en_US&source=Coveo

Chapter 6: Conclusiones de los resultados de las pruebas



Chapter 6 Conclusiones de los resultados de las pruebas


Rendimiento a escala ......................................................................................... 50

Observaciones sobre el rendimiento de PowerEdge MX840c ....................... 50

Observaciones sobre el rendimiento de PowerMax 2000 .............................. 50

Observaciones sobre el respaldo y la recuperación de Data Domain .............. 51

Resumen de los resultados ............................................................................... 51

Para obtener más información .......................................................................... 52



Rendimiento a escala

Este sistema de bases de datos y cargas de trabajo mixtas, que utiliza dos servidores

PowerEdge MX840c y un arreglo de almacenamiento PowerMax 2000 de nivel de

entrada con 24 unidades flash NVMe, es una solución potente y rentable. El sistema

proporcionó más de 105.000 IOPS con latencias inferiores a 1 ms. La configuración

de PowerMax puede escalar a 96 unidades flash NVMe, lo que supera en cuatro veces

a la configuración que se utilizó en estas pruebas.

Observaciones sobre el rendimiento de PowerEdge MX840c

Entre los aspectos importantes del rendimiento del chasis modular PowerEdge MX7000

con servidores MX840c se incluyen los siguientes:

Se destinó un servidor MX840c a las bases de datos Oracle. De los 160 procesadores

lógicos que estaban disponibles, las tres bases de datos Oracle utilizaron 24 núcleos

o un 15 % de los recursos computacionales. Por lo tanto, el 85 % o 136 núcleos

estuvieron disponibles para la consolidación de bases de datos adicionales.

El servidor MX840c que se destinó a SQL Server tenía 160 procesadores lógicos.

De los procesadores disponibles, las cinco bases de datos SQL Server utilizaron

32 núcleos o el 20 % de los recursos computacionales disponibles. Esto deja

128 núcleos o el 80 % de los recursos computacionales disponibles para la

consolidación de bases de datos SQL Server adicionales.

En el servidor MX840c que se destinó a Oracle, las tres bases de datos utilizaron

188 GB en reservas de memoria. De los 1,5 TB de memoria disponible, las bases

de datos utilizaron el 12,5 % y dejaron el 87,5 % o 1.312 GB de memoria para la

consolidación de bases de datos adicionales.

En el servidor MX840c que se destinó a SQL Server, las cinco bases de datos usaron

un total combinado de 88 GB de memoria o un 6 %. Esto deja 1.412 GB o un 94 % de

memoria disponible para la consolidación de bases de datos adicionales.

Los servidores MX840c ofrecieron de manera coherente un rápido rendimiento de

computación. La utilización de CPU en las tres pruebas para las VM de SQL Server

y Oracle se mantuvo coherente, sin impactos significativos en el rendimiento.

En los resultados de rendimiento obtenidos que se documentan en esta guía

se utilizó el diseño de red MX de LAN y SAN convergentes. Este diseño logra

mayores ahorros en términos de TCO, ya que no requiere IOM MX LAN y SAN

dedicados ni switches LAN y SAN de la parte superior del rack.

Observaciones sobre el rendimiento de PowerMax 2000

Entre los aspectos importantes del rendimiento del arreglo de almacenamiento PowerMax

2000 se incluyen los siguientes:

El arreglo de almacenamiento PowerMax 2000 generó 106 139 IOPS con una

pequeña configuración de 24 unidades flash NVMe.

El rendimiento de IOPS se mantuvo coherente entre la prueba de OLTP de base

y las pruebas con todas las cargas de trabajo en ejecución. Durante la ejecución de

todas las cargas de trabajo en paralelo, las IOPS se mantuvieron dentro del 4 % de

la base.




La latencia de lectura promedio para todas las bases de datos se mantuvo por

debajo de 1 ms con una excepción: SQL Server de OLTP de instantáneas 1.

Debido a que esta base de datos simulaba una carga de trabajo de prueba

y desarrollo, la latencia levemente mayor no fue significativa en la evaluación

del rendimiento general.

La latencia de escritura promedio para todas las bases de datos se mantuvo por

debajo de 1 ms. La mayor parte de las latencias de escritura estuvieron por debajo

de 0,31 ms. La excepción fue la base de datos Oracle de OLTP con escrituras

promedio de 0,75 ms para los registros (aún inferiores a 1 ms).

Observaciones sobre el respaldo y la recuperación de Data Domain

Durante el primer respaldo completo, DD Boost tardó 38 minutos en comprimir una

base de datos Oracle de 1.810 GB en 1.269 GB: un ahorro del 29,9 %.

En el segundo respaldo completo con un 5 % de datos modificados, DD Boost

comprimió aún más los datos y almacenó solamente 109 GB en el sistema DD9300

en 25 minutos: un ahorro de espacio del 94 %.

Una base de datos Oracle de 1,8 TB se restauró por completo y se recuperó

correctamente en 25 minutos con el uso de solo el 15 % de la capacidad de CPU

disponible en el servidor de base de datos de Oracle.

Resumen de los resultados

Entre los aspectos importantes de las observaciones de las pruebas de validación

se incluyen los siguientes:

El valor de TPM se mantuvo coherente a medida que aumentó la carga. Las bases

de datos SQL Server se mantuvieron dentro del 6 % del rendimiento de TPM de

base, incluso con todas las cargas de trabajo en ejecución en paralelo.

En la base de datos Oracle se observó el mismo rendimiento de TPM durante la

prueba de base y durante las pruebas con todas las cargas de trabajo en ejecución.

El aumento de la carga de trabajo no produjo ninguna pérdida de rendimiento.

El valor de NOPM para las bases de datos SQL Server se mantuvo dentro del 6 %

del rendimiento de NOPM de base con todas las cargas de trabajo en ejecución.

El valor de base de NOPM de Oracle fue el mismo que el valor de NOPM con todas las

cargas de trabajo en ejecución en paralelo, lo que significa que no se produjo ninguna

pérdida de rendimiento, ni siquiera con el aumento de la carga de trabajo.

El rendimiento y las IOPS se correlacionaron directamente: cuando aumentan las

IOPS o la carga de trabajo, también aumenta el rendimiento. En las observaciones,

se apreció una mejora en el rendimiento con la mayor complejidad que plantean

las cargas de trabajo mixtas. Por ejemplo, con 6.720 IOPS (OLTP + DSS), el

rendimiento fue de 625 MB/s, y con 7.587 IOPS (OLTP + DSS + instantánea),

el rendimiento fue de 714 MB/s.

El aumento de las cargas de trabajo no afectó el rendimiento de la base

de datos Oracle.



Para obtener más información

Para obtener más información, póngase en contacto con el representante de ventas local

de Dell EMC. Dell EMC cuenta con expertos en bases de datos que pueden trabajar con

usted para diseñar y dimensionar correctamente esta solución de cargas de trabajo

mixtas de bases de datos para su empresa. Los expertos de SQL Server y Oracle usan

herramientas que pueden recolectar información de sus sistemas de bases de datos

existentes. Con los datos recopilados, los expertos pueden desarrollar de manera rápida

y precisa una solución personalizada de bases de datos mixtas que se basa en la

infraestructura descrita en esta guía.

Chapter 7: Referencias



Chapter 7 Referencias


Documentación de Dell EMC ............................................................................. 54

Documentación de VMware ............................................................................... 54

Documentación de Oracle ................................................................................. 54

Documentación de Microsoft ............................................................................ 54

Documentación de HammerDB ......................................................................... 54

Chapter 7: Referencias


Documentación de Dell EMC

En las siguientes páginas web y documentación de Dell EMC se ofrece información

adicional y pertinente. El acceso a estos documentos depende de sus credenciales de

inicio de sesión. Si no tiene acceso a un documento, comuníquese con su representante

de Dell EMC.

Dell EMC Ready Solutions for Oracle

Dell EMC Ready Solutions for Microsoft SQL

Almacenamiento de datos Dell EMC PowerMax NVMe

Dell EMC PowerEdge MX

Documentación técnica Mejores prácticas de implementación para la base de datos

Oracle con Dell EMC PowerMax

Almacenamiento Dell EMC PowerMax para bases de datos SQL Server críticas

Guía de conectividad de hosts de Dell EMC para VMware ESX Server

Sistema Dell EMC Data Domain DD9300

Documentación de VMware

En la siguiente documentación de VMware se proporciona información adicional

y pertinente:

VMware ESXi 6.7 Installation and Setup

vCenter Server Installation and Setup

Oracle Databases on VMware Best Practices Guide

Quickstart: Install SQL Server and create a database on Red Hat

Documentación de Oracle

En la siguiente documentación de Oracle se proporciona información adicional

y pertinente:

Grid Infrastructure Installation and Upgrade Guide for Linux

Guía de instalación de la base de datos para Linux

Documentación de Microsoft

En la siguiente documentación de Microsoft se proporciona información adicional

y pertinente:

Installation guidance for SQL Server on Linux

Performance best practices and configuration guidelines for SQL Server on Linux.

SQL Server availability basics for Linux deployments

Documentación de HammerDB

Para obtener información acerca de las herramientas de HammerDB, consulte

Documentación de HammerDB.

https://www.dellemc.com/es-mx/solutions/business-applications/oracle/index.htm

https://www.dellemc.com/es-mx/solutions/business-applications/sql/index.htm

https://www.dellemc.com/es-mx/storage/powermax.htm?mkwid=s5Mke8egP&pcrid=266959812225&pkw=dell%20emc%20powermax&pmt=e&pdv=c&slid=&product=&pgrid=58603687801&ptaid=kwd-634054841432&VEN1=s5Mke8egP,266959812225,901qz26673,c,,,58603687801,kwd-634054841432&VEN2=e,dell%20emc%20powermaxcid=316176&lid=5960407&dgc=st&dgseg=COM&acd=12309215337205630&cid=316176&st=dell+emc+powermax&gclid=EAIaIQobChMIkrvi-NfD4QIVFbaWCh0lww9KEAAYASAAEgIzQvD_BwE&lid=5960407&ptaid=kwd-634054841432&VEN1=s5Mke8egP%2C266959812225%2C901qz26673%2Cc%2C%2C%2C58603687801%2Ckwd-634054841432&VEN2=e%2Cdell+emc+powermax&pgrid=58603687801&dgc=st&dgseg=cbg&acd=12309215337205630&VEN3=110404402522542603

https://www.dellemc.com/es-mx/servers/modular-infrastructure/poweredge-mx/index.htm#accordion0

https://www.dellemc.com/es-mx/collaterals/unauth/white-papers/products/storage/h17390-deployment-bp-for-oracle-with-powermax-wp.pdf

https://www.dellemc.com/es-mx/collaterals/unauth/white-papers/products/storage/h17390-deployment-bp-for-oracle-with-powermax-wp.pdf

https://www.dellemc.com/es-mx/collaterals/unauth/white-papers/products/storage/h17234-powermax-sql-server-wp.pdf

https://www.emc.com/collateral/TechnicalDocument/docu5265.pdf


https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-esxi-671-installation-setup-guide.pdf

https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-vcenter-server-67-installation-guide.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-on-vmware-best-practices-guide.pdf

https://docs.microsoft.com/en-us/sql/linux/quickstart-install-connect-red-hat?view=sql-server-2017%202017%20on%20Linux

https://docs.oracle.com/en/database/oracle/oracle-database/18/cwlin/index.html

https://docs.oracle.com/en/database/oracle/oracle-database/18/ladbi/index.html

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-performance-best-practices?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-ha-basics?view=sql-server-2017

https://www.hammerdb.com/document.html

Appendix A: Hardware y software de la solución



Appendix A Hardware y software de la solución

En este apéndice se presentan los siguientes temas:

Componentes de hardware ............................................................................... 56

Componentes de software ................................................................................. 58



Componentes de hardware

La arquitectura de referencia para esta solución incluye los siguientes componentes de

hardware principales:

Chasis modular Dell EMC PowerEdge MX7000 con lo siguiente:

1 bahía de computación PowerEdge MX840c para una base de datos Oracle

1 bahía de computación PowerEdge MX840c para una base de datos SQL Server

2 módulos de I/O PowerEdge MX9116n para el tráfico convergente de LAN y SAN

Arreglo de almacenamiento Dell EMC PowerMax 2000

Dispositivo de respaldo Data Domain DD9300

En las siguientes tablas se enumeran los detalles de los componentes de hardware,

firmware y controladores de los servidores de computación y los módulos de I/O de

red que se usaron en la configuración probada de esta arquitectura de referencia.

Table 22. Componentes de computación y red

Componente Descripción

Chasis modular 1 chasis modular Dell EMC PowerEdge MX7000

Se accede a las fuentes de alimentación

6 fuentes de alimentación redundantes de 3000 W

Bahías de computación

Hosts ESXi de las bases de datos 1 Dell EMC PowerEdge MX840c para la base de datos Oracle

1 Dell EMC PowerEdge MX840c para la base de datos SQL Server

Subcomponentes de cada bahía de computación

Chasis 0F0F

1 Chasis de 2,5 in con hasta 8 discos duros SAS/SATA/NVMe

Procesador 4 procesadores escalables Intel Xeon Gold 6148 20c/40T HT 2,4 GHz

Memoria 1536 GB (24 LRDIMM de 64 GB QR DDR4 a 2666 MT/s)

Discos locales en el servidor 3 SAS de 1,2 TB, 10 000 r/min, 12 Gb/s y 2,5 in HDD (incluye un hot spare)

Controladora RAID PERC H730P MX

iDRAC iDRAC9 Enterprise

Tarjetas de I/O para los fabrics A/B

4 tarjetas mezzanine o CNA QLogic FastLinQ 41262HMKR DP de 10/25 GbE con descargas de almacenamiento (iSCSI y FCoE)

Módulos de red o I/O dentro del chasis modular MX7000

Módulos de I/O (LAN y SAN convergentes) (ranuras de fabric A1 y B1)

2 motores de conmutación de fabric Dell EMC MX9116n de 25 GbE, 12 QDD28, 2 Q28 y 2 FC Q28/32 Gb

1 Se admiten otras configuraciones de chasis.

Componentes

de computación

y red




Nota: Se admiten versiones de BIOS y firmware más recientes y actualizadas, si están disponibles.

Para obtener la versión más reciente, visite el servicio de soporte en línea de Dell EMC.

Table 23. Firmware y controladores de los componentes de PowerEdge MX7000

Componente Firmware/sistema operativo

Controlador1F1F

2

Nivel de chasis modular

Módulo de administración 1.00.01 N/D

Se accede a las fuentes de alimentación

00.36.6B N/D

Bahías de computación (se aplica a ambas bahías MX840c)

BIOS 1.6.11 N/D

Lifecycle Controller y iDRAC9 Enterprise

3.20.21.20 N/D

Tarjeta mezzanine o CNA QLogic FastLinQ 41262HMKR DP de 10/25 GbE

14.07.07 3.7.9.2 (controlador Ethernet qedentv)

1.2.24.6 (controlador FCoE qedf)

PERC H730P MX 25.5.5.0005 7.705.10.00 (lsi-mr3)

Módulos de I/O de red

MX9116n FSE 10.4.0E.R3S.268 N/D

En la siguiente tabla se enumeran los detalles de hardware del arreglo de almacenamiento

que se utilizó en la configuración probada de esta arquitectura de referencia:

Table 24. Componentes del arreglo de almacenamiento PowerMax 2000

Componente del arreglo de almacenamiento

Detalles

Versión de sistema operativo PowerMaxOS

Cantidad de bricks 1

Módulos de I/O de front-end 4 FC QP de 16 Gb/s (dos módulos de I/O por director)

Caché por motor 1 TB (512 GB por director)

Cantidad de discos 24 unidades flash NVMe

Tipo de RAID RAID 5 (7+1)

Capacidad cruda/útil 88,69 TB/73.35 TB

2 Se utilizó una imagen ISO personalizada por Dell EMC de VMware ESXi 6.7 U1 (versión

de Dell: A03, compilación n.º 10764712) para implementar el hipervisor ESXi. Se utilizaron

controladores incluidos en los sistemas operativos huéspedes de Oracle y SQL RHEL 7.

Arreglo de

almacenamiento

https://support.emc.com/



En la siguiente tabla se enumeran los detalles de hardware del sistema de respaldo

DD9300 que se utilizó en la configuración probada de esta arquitectura de referencia:

Table 25. Componentes del sistema de respaldo DD9300

Componente del sistema de respaldo Detalles

Versión de sistema operativo 6.1.0.1-560996

Cantidad de unidades principales 1 (con 12 discos)

Cantidad de gabinetes (DS60) 4 (con 60 discos en cada uno)

Cantidad de adaptadores de red de front-end

2 adaptadores de 10 GbE de puerto cuádruple (QP)

Cantidad de puertos de red de front-end (en uso)

4 de 10 GbE (dos de cada adaptador QP)

Discos del sistema 3 HDD SAS de 3,64 TiB + 1 HDD SAS de 3,64 TiB (repuesto)

Discos de caché 8 SSD SAS de 0,728 TiB

Discos de nivel activo (en uso) 210 HDD SAS de 2,73 TiB

Discos de nivel activo (repuesto) 15 HDD SAS de 2,73 TiB

Componentes de software

En la siguiente tabla se especifican las versiones de los componentes de software

de esta arquitectura de referencia implementados en la configuración probada.

Nota: La versión de ESXi se aplica a los hosts de bases de datos ESXi de Oracle y SQL Server.

Table 26. Componentes de software

Software Versión

Sistemas operativos de hipervisor VMware ESXi 6.7 U1 [imagen ISO personalizada por Dell EMC (versión de Dell: A03, compilación n.º 10764712)]

Sistemas operativos huéspedes VM de base de datos Oracle: Red Hat Enterprise Linux 7.4 kernel 3.10.0-693 x86_64

VM de base de datos SQL Server: Red Hat Enterprise Linux 7.6 kernel 3.10.0-957 x86_64

Grid Oracle y base de datos Oracle en Linux Oracle Grid Infrastructure 18c (18.3.0)

Oracle Database 18c (18.3.0) (independiente)

Bases de datos Microsoft SQL Server en Linux SQL Server 2017 (RTM-CU13)

Dell EMC Unisphere for PowerMax (incluye el recolector de estadísticas CloudIQ y Database Storage Analyzer integrados)

9.0.2.7

Dell EMC Live Optics 2.5.16.467045

Agente de aplicación de base de datos DD Boost 4.7.1.0-1

Sistema de

respaldo DD9300

Appendix B: Detalles de diseño y configuración



Appendix B Detalles de diseño y configuración

En este apéndice se presentan los siguientes temas:

Diseño de computación y red ........................................................................... 60

Configuración del almacenamiento PowerMax ............................................... 66

Configuraciones de VM y sistemas operativos huéspedes de Oracle .......... 72

Configuraciones de VM y sistemas operativos huéspedes de SQL Server .... 76



Diseño de computación y red

Ambos servidores de base de datos PowerEdge MX840c, uno para Oracle y el otro para SQL

Server, se instalaron y configuraron con ESXi 6.7 U1 mediante la imagen ISO personalizada

por Dell EMC (versión de Dell: A03, compilación n.º 10764712). Esta imagen está disponible

en el servicio de soporte en línea de Dell EMC en VMware ESXi 6.7 U1.

Configuración de adaptadores de red convergente

En esta solución, la convergencia del tráfico de LAN y SAN se realizó dentro de los

servidores blade mediante cuatro CNA QLogic QL41262 de dos puertos y 25 GbE. Estos

CNA admiten varios protocolos de tráfico de red (Ethernet, descarga de FCoE y descarga

de iSCSI) y proporcionan una gran cantidad de ancho de banda para admitir las diversas

funcionalidades de red LAN y SAN en esta solución. Estos CNA se particionaron con

NPAR, la función de particionamiento de red del adaptador, lo que permitió usar el alto

ancho de banda de red combinado disponible en los CNA y, a la vez, proporcionar alta

disponibilidad. Los CNA se particionaron en los hosts de Oracle y SQL Server con la

siguiente funcionalidad y asignaciones de ancho de banda:

Table 27. Configuración de CNA en hosts de bases de datos de MX840c

Ranura de mezz./CNA

Número de puerto

Número de partición

Tipo de partición

Porcentaje de ancho de banda asignado

Función de aplicación

Mezz. 1A Puerto 1 Partición 1 NIC 0 % (0 Gb) Ninguna (administración inicial de ESXi)

Partición 2 FCoE 100 % (25 GbE) SAN de base de datos/FCoE 1

Mezz. 1B Puerto 1 Partición 1 NIC 0 % (0 Gb) Ninguna

Partición 2 FCoE 100 % (25 GbE) SAN de base de datos/FCoE 2

Mezz. 2A Puerto 1 Partición 1 NIC 20 % (5 Gb) Administración de ESXi y enlace ascendente de red de VM 1

Partición 2 NIC 20 % (5 Gb) Enlace ascendente de vMotion de Oracle/SQL 1

Partición 3 NIC 60 % (15 Gb) Enlace ascendente de red pública de Oracle/SQL 1

Mezz. 2B Puerto 1 Partición 1 NIC 20 % (5 Gb) Administración de ESXi y enlace ascendente de red de VM 2

Partición 2 NIC 20 % (5 Gb) Enlace ascendente de vMotion de Oracle/SQL 2

Partición 3 NIC 60 % (15 Gb) Enlace ascendente de red pública de Oracle/SQL 2

Nota: De manera predeterminada, la función NPAR crea cuatro particiones en cada puerto del

adaptador. Las particiones que no se enumeran en la tabla se deshabilitaron.

Configuración

del host ESXi

https://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverId=53N67&osCode=XI67&productCode=poweredge-r740xd




Para conocer los pasos detallados sobre cómo crear particiones en los CNA QLogic,

consulte uno de los siguientes documentos:

QLogic User's Guide for Fibre Channel Adapter, Converged Network Adapter and

Intelligent Ethernet Adapters

Dell EMC PowerEdge MX Series Fibre Channel Storage Network Deployment with

Ethernet IOMs

Nota: Las ranuras de fabric de I/O MX A2 y B2 no se completaron con ningún IOM porque no se

necesitaban en esta solución. En consecuencia, el segundo puerto de cada tarjeta mezzanine o CNA

que se conecta de manera interna a estas ranuras de fabric no estuvo disponible o no se utilizó.

Como se muestra en la tabla 25, ambos hosts de bases de datos se configuraron con el

siguiente diseño y mejores prácticas de LAN y SAN:

Tráfico de LAN y SAN (FCoE) en CNA independientes

Dos particiones FCoE de 25 Gb/s (50 Gb/s en total) en dos CNA independientes, lo que

permite un alto ancho de banda y una conectividad de red SAN de alta disponibilidad

Dos particiones NIC de 15 GbE (30 GbE en total) en dos CNA independientes, lo que

permite un alto ancho de banda y una conectividad de red pública de base de datos o

LAN de alta disponibilidad


permite un alto ancho de banda y una conectividad de vMotion de alta disponibilidad


permite un alto ancho de banda y una conectividad de red de VM y administración de

host ESXi de alta disponibilidad

En la siguiente figura se muestra cómo los CNA que se utilizan para el tráfico de LAN (las

tarjetas mezzanine en las ranuras 2A y 2B dentro de cada uno de los servidores blade

MX840c) están conectados internamente a los IOM MX9116n dentro del chasis MX.

También se muestra cómo los IOM están conectados a switches de enlace ascendente

para acceso y conectividad LAN externos.

Figure 23. Red LAN: Conectividad interna y externa

https://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverid=fp87m&oscode=xi67&productcode=poweredge-mx840c

https://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverid=fp87m&oscode=xi67&productcode=poweredge-mx840c

https://www.dell.com/support/article/us/en/19/sln314800/dell-emc-poweredge-mx-series-fibre-channel-storage-network-deployment-with-ethernet-ioms?lang=en




Como se muestra en la figura anterior, la primera partición de NIC (5 GbE) que se creó en

cada una de las tarjetas mezzanine o CNA se utilizó para el tráfico de administración de

VM y hosts ESXi, la segunda (5 GbE) se reservó para el tráfico de vMotion y la tercera

(15 GbE) en cada uno de los CNA se utilizó para el tráfico público de las bases de datos.

Para proporcionar conectividad externa y ancho de banda Ethernet suficiente para las

tres funciones de NIC en ambos hosts ESXi de bases de datos, se configuró un puerto

QSFP28 externo (100 GbE) en cada MX9116n en modo de 4 conexiones de 10 GbE. Los

puertos se enlazaron de manera ascendente a switches centrales en el centro de datos

con cables de múltiples conexiones QSFP+ a SFP+ (conectividad púrpura).

Diseño de la red virtual de ESXi

En el siguiente diagrama se muestra la topología del diseño de switch virtual que se

implementó en los hosts ESXi para la conectividad de red que se requirió para las bases

de datos Oracle y SQL Server. Los vmnics en el siguiente diagrama son las respectivas

particiones de NIC que se crearon en los CNA que aparecen como adaptadores físicos

dentro de los hosts ESXi.

Figure 24. Diseño de la red virtual en los hosts ESXi




Como se muestra en la figura 14, el diseño de la red virtual en los dos servidores de base

de datos MX840c consta de lo siguiente:

Tráfico de VM y administración: el tráfico de administración de la red de VM

y ESXi utiliza el switch virtual (vSwitch) estándar predeterminado, el cual contiene

dos grupos de puertos estándares predeterminados. El grupo de puertos de red de

administración proporciona el puerto VMkernel vmk0 para administrar el host ESXi

desde el dispositivo VMware vCenter Server. El grupo de puertos de red de VM

proporciona las interfaces virtuales para la administración dentro de banda de las

VM de las bases de datos. Con fines de alta disponibilidad y ancho de banda, se

utilizaron dos puertos de enlace ascendente de 5 GbE (partición 1) en dos CNA

independientes (en las ranuras 2A y 2B) en los servidores de base de datos ESXi

MX840c para el enrutamiento del tráfico de administración.

Tráfico público: se creó un vSwitch estándar dedicado adicional para el tráfico

público de las bases de datos en cada uno de los hosts de bases de datos ESXi

para las bases de datos Oracle y SQL Server. Con fines de alto ancho de banda,

disponibilidad y balanceo de carga, se utilizaron dos puertos de enlace ascendente

de 15 GbE (partición 3) en dos CNA independientes (en las ranuras 2A y 2B) en los

servidores de base de datos ESXi MX840c para el enrutamiento del tráfico público

de las bases de datos. Dentro de cada vSwitch público, se creó un grupo de

puertos estándar (oraPub-PG y oraSQL-PG, respectivamente) que proporciona las

interfaces de red virtual para el tráfico público de las bases de datos Oracle y SQL

Server dentro de sus respectivas VM de bases de datos.

La imagen ISO de ESXi 6.7 personalizada por Dell EMC que se usó contiene el

controlador FCoE qedf para el CNA QLogic QL41262. Este controlador garantiza

que la partición de FCoE que se creó en los CNA QLogic para el tráfico de SAN se

reconozca automáticamente como HBA virtuales (vmhba64 y vmhba65) o adaptadores de

almacenamiento FCoE dentro de los hosts ESXi, como se muestra en la siguiente figura:

Figure 25. HBA virtuales o adaptadores de almacenamiento FCoE reconocidos en hosts ESXi

En la siguiente figura se muestra la conectividad FCoE interna entre los CNA o las

tarjetas mezzanine dentro de los servidores blade MX840c y los IOM FSE MX9116n.

También muestra la conectividad FC directa externa entre los IOM FSE MX9116n

y el arreglo de almacenamiento PowerMax.

Conectividad

y zonificación

de FCoE a FC



Figure 26. Diseño de la conectividad de fabric para SAN de FCoE a FC

Como se muestra en la figura anterior, el primer puerto de ambas tarjetas mezzanine en las

ranuras 1A y 1B de cada servidor MX840c se configuró para el tráfico FCoE mediante

conectividad interna de 25 GbE a los respectivos IOM MX9116n en las ranuras de fabric MX

A1 y B1. Los dos puertos unificados QSFP28 (100 Gb) externos de los IOM MX9116n se

configuraron en modo de 4 conexiones FC de 16 Gb/s. Los puertos se conectan directamente

a los puertos FC de front-end de PowerMax mediante cables de conectores de múltiples

fibras (MPO). Este diseño de conectividad SAN recomendado garantiza alto ancho de banda,

balanceo de carga y alta disponibilidad en los dos fabrics para SAN de FCoE a FC: fabric

para SAN A (conectividad roja) y fabric para SAN B (conectividad azul).

Dell EMC recomienda la zonificación de un único iniciador (partición FCoE en el CNA, en este

caso) de conjuntos de zonas en los switches FC (MX9116n, en este caso). Con fines de alta

disponibilidad, ancho de banda y balanceo de carga, cada partición FCoE de iniciador o CNA

en el host ESXi se zonifica con cuatro puertos de almacenamiento PowerMax de front-end

que se distribuyen entre las dos tarjetas SLIC y los dos directores de almacenamiento, como

se muestra en la siguiente representación lógica de conjuntos de zonas:

Figure 27. Zonificación de FC: Representación lógica




Como se muestra en la figura anterior, para proporcionar la misma alta disponibilidad

y un acceso equitativo al ancho de banda de front-end del almacenamiento para las

bases de datos Oracle y SQL Server, cada iniciador se zonificó con un puerto de front-

end único distribuido en todo el arreglo. Este diseño garantizó que tanto el host ESXi

de la base de datos Oracle como el de la base de datos SQL Server tuvieran ocho

rutas únicas al arreglo de almacenamiento.

Para conocer los pasos detallados sobre cómo configurar la conectividad de FCoE

a FC entre PowerEdge MX7000 y el arreglo de almacenamiento PowerMax, incluidas

las mejores prácticas, consulte las siguientes guías.

Nota: A pesar de que las siguientes guías de implementación de FCoE a FC utilizan diferentes

arreglos de almacenamiento (Unity) de Dell EMC y switches (S4148U) de redes (unificadas)

de Dell EMC, los conceptos y los pasos de configuración de red se aplican al arreglo PowerMax

y a los IOM MX9116n que se utilizan en esta solución.

Dell EMC PowerEdge MX Series Fibre Channel Storage Network Deployment with

Ethernet IOMs

Dell EMC Networking FCoE-to-Fibre Channel Deployment with S4148U-ON in

F_port Mode Deployment Guide

Aplique los pasos de configuración de QoS (DCBx) recomendados según se especifica en

cualquiera de las dos guías para asegurarse de que la configuración de FCoE no tenga

pérdidas. La configuración de QoS se aplica automáticamente cuando los dos IOM MX9116n

se configuran en modo de fabric inteligente (Dell EMC PowerEdge MX Series Fibre Channel

Storage Network Deployment with Ethernet IOMs). Sin embargo, la configuración se debe

aplicar manualmente en el modo de switch completo (Dell EMC Networking FCoE-to-Fibre

Channel Deployment with S4148U-ON in F_port Mode). En esta solución, la conectividad de

FCoE a FC en los dos IOM MX9116n se configuró manualmente.

Las múltiples rutas en el host ESXi 6.7 se configuraron de acuerdo con las siguientes

mejores prácticas:

Se usó vSphere Native Multipathing (NMP) como el software de múltiples rutas.

Se mantuvo la selección predeterminada de round robin para la política de

selección de rutas nativas (PSP) en los volúmenes de PowerMax que se presentan

a los hosts ESXi.

Se cambió del valor predeterminado 1000 a 1 la frecuencia de paquetes de I/O del

cambio de ruta round robin de NMP. Para obtener información sobre cómo

configurar este parámetro, consulte Guía de conectividad de hosts de Dell EMC

para VMware ESX Server.

En vSphere 6.7, el administrador puede agregar latencia a la configuración de NMP como

una subpolítica para hacer que vSphere monitoree la latencia en las rutas. De manera

predeterminada, el ajuste de latencia en vSphere 6.7 está deshabilitado, pero podría

estar habilitado en vSphere 6.71 actualización 1. El ajuste de la subpolítica de selección

de ruta en latencia permite que la política de round robin seleccione dinámicamente la

ruta óptima en términos de latencia con el fin de lograr mejores resultados. Para obtener

más información, consulte vSphere 6.7 U1 Enhanced Round Robin Load Balancing.

Configuración de

múltiples rutas



https://downloads.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_networking/networking-s4148u-on_deployment-guide2_en-us.pdf








https://storagehub.vmware.com/t/vsphere-storage/vsphere-6-7-core-storage-1/vsphere-6-7-u1-enhanced-round-robin-load-balancing/



Configuración del almacenamiento PowerMax

Para facilitar la administración y el monitoreo, se crearon dos hosts de almacenamiento

en el arreglo PowerMax: uno de ellos contenía los dos iniciadores del host ESXi de la

base de datos Oracle (MX840c en la ranura 1 de MX) y el otro, los dos iniciadores del

host ESXi de SQL Server (MX840c en la ranura 3 de MX).

Como se describe en Conectividad y zonificación de FCoE a FC, el diseño de conectividad

y zonificación de FC garantiza la conexión del host ESXi de Oracle y de los hosts ESXi de

SQL Server a ocho puertos de front-end únicos en el arreglo PowerMax. En consecuencia,

se crearon dos grupos de puertos de almacenamiento en el arreglo PowerMax: uno de ellos

contenía los ocho puertos de front-end que se zonificaron con los iniciadores de host de la

base de datos Oracle y el segundo, los otros ocho puertos de front-end que se zonificaron

con los iniciadores de host de la base de datos SQL Server. Este diseño garantiza la igualdad

en el ancho de banda, la alta disponibilidad, la facilidad de administración y monitoreo, y la

seguridad para las bases de datos Oracle y SQL Server.

Para consolidar las cargas de trabajo mixtas de las bases de datos Oracle y SQL en un

único arreglo de almacenamiento PowerMax, se adaptaron los siguientes principios para

el diseño de grupos y volúmenes de almacenamiento para tres bases de datos Oracle:

base de datos de OLTP de Oracle, base de datos de DSS de Oracle y base de datos

de instantáneas de Oracle. Estos principios de diseño simplifican la administración

y el monitoreo del rendimiento de los volúmenes de almacenamiento.

Se creó el grupo de almacenamiento primario para cada base de datos, como ORA-

OLTP-SG para la base de datos de OLTP de Oracle.

Se creó un grupo secundario por separado para cada tipo de volumen, como los

volúmenes DATA, REDO, FRA y TEMP, dentro de cada grupo de almacenamiento

primario. Se creó la cantidad de volúmenes correspondientes en cada grupo

secundario; por ejemplo, se crearon cuatro volúmenes de datos en el grupo secundario

ORA-OLTP-DATA.

Se creó un grupo de almacenamiento primario especial, ORA-OS-OCR, que consolida

los discos virtuales del sistema operativo para todas las VM huéspedes de las bases

de datos Oracle y para el OCR y los discos con voto de Oracle Clusterware. Se crearon

grupos secundarios dentro de este grupo primario para cada volumen de sistema

operativo de VM y para cada volumen de OCR y disco con voto de Oracle Clusterware.

Teniendo en cuenta estos principios de diseño, se desarrollaron los siguientes grupos y

volúmenes de almacenamiento para estas bases de datos Oracle de cargas de trabajo mixtas.

Para la base de datos de OLTP de Oracle, se creó el grupo de almacenamiento primario

ORA-OLTP-SG y los siguientes grupos de almacenamiento secundarios dentro del grupo

primario:

ORA-OLTP-DATA para archivos DATA

ORA-OLTP-REDO para registros REDO

ORA-OLTP-FRA para FRA

ORA-OLTP-TEMP para archivos TEMP

Hosts y grupos

de puertos

Grupos y

volúmenes de

almacenamiento

para cargas de

trabajo de Oracle




También se crearon los grupos secundarios ORA-OLTP-OS y ORA-OLTP-OCR dentro

del grupo primario ORA-OS-OCR común. En la siguiente tabla se muestran los grupos

de almacenamiento y la cantidad y los tamaños de los volúmenes para esta base de

datos de OLTP de Oracle:

Table 28. Grupos y volúmenes de almacenamiento para la base de datos de OLTP de Oracle

SG primario SG secundario Tamaño de cada volumen (GB)

Cantidad de volúmenes

Tamaño total (GB)

ORA-OS-OCR ORA-OLTP-OS 500 1 500

ORA-OLTP-OCR 50 3 150

ORA-OLTP-SG ORA-OLTP-DATA 500 4 2,000

ORA-OLTP-REDO 25 4 100

ORA-OLTP-FRA 100 2 200

ORA-OLTP-TEMP 500 1 500

De manera similar, para la base de datos de DSS de Oracle, se creó el grupo de

almacenamiento primario ORA-DSS-SG y los siguientes grupos de almacenamiento

secundarios:

ORA-DSS-DATA para archivos DATA

ORA-DSS-REDO para registros REDO

ORA-DSS-FRA para FRA

ORA-DSS-TEMP para archivos TEMP

También se crearon los grupos secundarios ORA-DSS-OS y ORA-DSS-OCR dentro del

grupo primario ORA-OS-OCR común. En la siguiente tabla se muestran estos grupos de

almacenamiento y la cantidad y el tamaño de los volúmenes para esta base de datos de

DSS de Oracle:

Table 29. Grupos y volúmenes de almacenamiento para la base de datos de DSS de Oracle

SG primario SG secundario Tamaño del volumen (GB)


Tamaño total (GB)

ORA-OS-OCR ORA-DSS-OS 500 1 500

ORA-DSS-OCR 50 3 150

ORA-OLAP-SG ORA-DSS-DATA 500 8 5,000

ORA-DSS-REDO 25 4 100

ORA-DSS-FRA 100 2 200

ORA-DSS-TEMP 2.000 1 2,000



En este diseño de arquitectura de referencia, se adaptaron los siguientes principios para

el diseño de grupos y volúmenes de almacenamiento para cinco bases de datos SQL

Server: dos bases de datos de OLTP, dos bases de datos de DSS y una base de datos

de instantáneas:

Se creó el grupo de almacenamiento primario para cada base de datos, como

SQL_OLTP_VM1_SG para la base de datos de OLTP de SQL Server.

Se creó un grupo secundario por separado para cada tipo de volumen, como los

volúmenes de datos, registro, datos de tempdb y registro de tempdb, dentro de

cada grupo de almacenamiento primario. Se creó la cantidad de volúmenes

correspondientes en cada grupo secundario; por ejemplo, dos volúmenes de datos

en el grupo secundario SQL_OLTP_VM1_Data.

Se creó un grupo de almacenamiento primario especial, SQL_OS_SG, que

consolida los discos virtuales del sistema operativo para todas las VM huéspedes

de las bases de datos SQL Server. Los grupos secundarios se crearon dentro de

este grupo primario para los volúmenes del sistema operativo de cada VM.

Estos principios de diseño simplifican la administración y el monitoreo del rendimiento

de los volúmenes de almacenamiento, incluidos los volúmenes que se crearon a través

de instantáneas para la carga de trabajo de SQL Server en ejecución junto con la carga

de trabajo de Oracle.

En la siguiente tabla se muestran los grupos y los volúmenes de almacenamiento para

las cargas de trabajo de las bases de datos de OLTP de SQL Server.

Table 30. Grupos y volúmenes de almacenamiento para las bases de datos de OLTP de SQL Server

SG primario SG secundario Tamaño del volumen (GB)


Tamaño total (GB)

SQL_OS_SG SQL_OLTP_OS1 500 1 500

SQL_OLTP_OS2 500 1 500

SQL_OLTP_VM1 SQL_OLTP_VM1_Data 1.024 2 2.048

SQL_OLTP_VM1_Log 300 1 300

SQL_OLTP_VM1_TempData 400 1 400

SQL_OLTP_VM1_TempLog 300 1 300

SQL_OLTP_VM2 SQL_OLTP_VM2_Data 1.024 2 2.048

SQL_OLTP_VM2_Log 300 1 300

SQL_OLTP_VM2_TempData 400 1 400

SQL_OLTP_VM2_TempLog 300 1 300

Grupos

y volúmenes de

almacenamiento

para cargas de

trabajo de SQL

Server




Para la base de datos de DSS de SQL Server, se creó un diseño de almacenamiento

similar. En la siguiente tabla se muestran los grupos de almacenamiento y la cantidad

y los tamaños de los volúmenes para las dos bases de datos de DSS de SQL Server:

Table 31. Grupos y volúmenes de almacenamiento para las bases de datos de DSS de SQL Server

SG primario SG secundario Tamaño de cada volumen (GB)


Tamaño total (GB)

SQL_OS_SG SQL_DSS_OS1 500 1 500

SQL_DSS_OS2 500 1 500

SQL_DSS_VM1 SQL_DSS_VM1_Data 1.024 2 2.048

SQL_DSS_VM1_Log 300 1 300

SQL_DSS_VM1_TempData 400 1 400

SQL_DSS_VM1_TempLog 300 1 300

SQL_DSS_VM2 SQL_DSS_VM2_Data 1.024 2 2.048

SQL_DSS_VM2_Log 300 1 300

SQL_DSS_VM2_TempData 400 1 400

SQL_DSS_VM2_TempLog 300 1 300

En la siguiente figura se ilustra la arquitectura de las instantáneas de SnapVX de los

volúmenes de las bases de datos de producción (origen). Se muestra cómo estas

instantáneas están enlazadas a otro conjunto de dispositivos de destino, a los que

accede el host de base de datos de instantáneas, para formar una base de datos

de instantáneas, como una base de datos de desarrollo o pruebas.

Figure 28. Creación de instantáneas de SnapVX y montaje de bases de datos de instantáneas

Volúmenes de

las bases de

datos de

instantáneas



Para las bases de datos de instantáneas, se crearon dos tipos de grupos de almacenamiento:

Nuevos grupos de almacenamiento: se crearon nuevos volúmenes en estos

grupos de almacenamiento para la base de datos de instantáneas. Estos grupos

de almacenamiento incluyen los volúmenes del sistema operativo huésped, el

OCR y los discos con voto de Oracle, los volúmenes TEMP de Oracle y el sistema

operativo huésped y los volúmenes TEMP de SQL Server, como se muestra en la

siguiente tabla:

Table 32. Nuevos grupos de almacenamiento para bases de datos de instantáneas

Nuevo grupo de almacenamiento Volúmenes

Nombre primario Nombre secundario Tamaño (GB)

Cantidad Tamaño total (GB)

ORA-OS-OCR ORA-SNAP-OS 500 1 500

ORA-SNAP-OCR 50 3 50

ORA-SNAP-TEMP NONE 500 1 500

SQL_OS_SG SQL_SNAP_OS 500 1 500

SQL_OLTP_SNAP_VM SQL_OLTP_SNAP_VM_ TEMPDATA

400 1 400

SQL_OLTP_SNAP_VM_TEMPLOG 300 1 300

Grupos de almacenamiento de instantáneas o SnapVX: estos grupos de

almacenamiento son instantáneas de grupos de almacenamiento de bases de datos

existentes. Los volúmenes en estos grupos de almacenamiento incluyen instantáneas

de los volúmenes de origen DATA, REDO y FRA de Oracle, y DATA y LOG de SQL

Server correspondientes. Se crearon dos instantáneas de SnapVX: una de la base de

datos de OLTP de Oracle existente y otra de la base de datos de OLTP de SQL Server

existente. Sin embargo, los servidores de base de datos host acceden a los grupos

o los volúmenes de almacenamiento de instantáneas mediante los grupos de

almacenamiento de destino de enlace de SnapVX que se crearon para las respectivas

instantáneas de Oracle y SQL Server. En la siguiente tabla se muestran los grupos

de almacenamiento de origen, instantáneas y destino de enlace de SnapVX que

se crearon para las bases de datos de instantáneas de Oracle y SQL Server:




Table 33. Grupos de almacenamiento de origen, instantáneas y destino de enlace para las bases de datos de instantáneas

Grupo de almacenamiento de origen Nombre de

instantánea

Grupo de almacenamiento de destino de enlace de SnapVX Volúmenes

Primario Secundario Primario Secundario

ORA-OLTP-SG ORA-OLTP-SNAP-SG

ORA-OLTP-SG_LNK_SG_001

ORA-OLTP-SG-DATA

instantáneas ORA-OLTP-SG-DATA-SG_001

4

ORA-OLTP-SG-REDO

instantáneas ORA-OLTP-SG-REDO_SG_001

4

ORA-OLTP-SG-FRA

instantáneas ORA-OLTP-SG-FRASG_001

2

SQL-OLTP-VM1 SQL-OLTP-VM1-SNAP

SQL-OLTP-VM1_LNK_SG_001

SQL-OLTP-VM1_Data

instantáneas SQL_OLTP_VM1_Data_SG_001

2

SQL-OLTP-VM1_Log

instantáneas SQL_OLTP_VM1_Log_SG_001

1

Nota: La administración de almacenamiento de Unisphere crea automáticamente la estructura de

grupos de almacenamiento de destino de enlace de SnapVX de modo que sea igual que aquella

a partir de la que se creó. Por lo tanto, la cantidad y el tamaño de los volúmenes de instantáneas

son idénticos a los volúmenes de la base de datos de origen.

A continuación, todos los grupos de almacenamiento nuevos y los grupos de

almacenamiento de destino de enlace de SnapVX que se crearon para las bases de datos

de instantáneas se mapearon a sus respectivos hosts ESXi de bases de datos mediante la

creación de las vistas de enmascaramiento apropiadas. Dentro de los respectivos hosts

ESXi, todos los volúmenes se agregaron manualmente a la VM apropiada que se creó para

la base de datos de instantáneas. Dentro de las respectivas VM huéspedes de las bases de

datos, estos volúmenes se montaron en la base de datos de instantáneas.

En la siguiente figura se ilustra el proceso de creación, enlace y montaje de instantáneas

con el uso de la base de datos de OLTP de Oracle y su base de datos de instantáneas

como ejemplo.



Figure 29. Proceso de creación, enlace y montaje de instantáneas

Configuraciones de VM y sistemas operativos huéspedes de Oracle

Se utilizaron los siguientes principios de diseño y mejores prácticas para crear las

VM para las bases de datos Oracle.

Controladoras SCSI y discos duros virtuales

Se recomiendan varias controladoras SCSI de tipo VMware Paravirtual para optimizar

y equilibrar las I/O de los diferentes discos duros de las bases de datos Oracle, como

se describe en esta sección.

Diseño

y configuración

de VM




En la siguiente tabla se muestra el diseño recomendado de las controladoras SCSI para las

VM de las bases de datos de OLTP e instantáneas. Los discos DATA y REDO se distribuyen

entre controladoras SCSI dedicadas independientes, ya que, en una carga de trabajo de

OLTP de Oracle, estos tipos de discos generan un alto nivel de I/O en el almacenamiento.

Por el contrario, los discos OCR, FRA y TEMP generan relativamente pocas I/O y, por lo

tanto, pueden coexistir en una controladora SCSI dedicada independiente.

Table 34. Propiedades de las controladoras SCSI en las VM de las bases de datos de OLTP e instantáneas

Controladora Propósito Uso compartido de bus SCSI

Tipo de controladora

SCSI 0 Disco de sistema operativo huésped Ninguno

VMware Paravirtual

SCSI 1 Discos DATA de Oracle

SCSI 2 Discos REDO de Oracle

SCSI 3 Discos OCR, FRA y TEMP de Oracle

En la siguiente tabla se muestra el diseño recomendado de las controladoras SCSI para

la VM de la base de datos de DSS. Las cargas de trabajo de DSS generan principalmente

I/O de lectura en los discos DATA y pocas I/O en los discos REDO. Por lo tanto, como se

muestra en la siguiente tabla, los 10 discos DATA se distribuyen entre las tres

controladoras SCSI dedicadas con fines de balanceo de carga, mientras que el resto

de los discos con tipos de I/O ligeras (los discos del sistema operativo huésped, OCR,

REDO, FRA y TEMP) coexisten en la primera controladora SCSI.

Table 35. Propiedades de las controladoras SCSI en la VM de la base de datos de DSS


Tipo

SCSI 0 Discos del sistema operativo huésped, OCR, REDO, FRA y TEMP

Ninguno

VMware Paravirtual

SCSI 1 3 discos DATA de Oracle



Los discos duros virtuales para el sistema operativo huésped de las VM se crean como

un almacén de datos VMFS6. Todos los volúmenes o los discos duros virtuales para

las bases de datos Oracle (discos DATA, REDO, FRA, TEMP y OCR) se agregan

directamente a sus respectivas VM como dispositivos crudos o por medio del mapeo

de dispositivos crudos (RDM). Para estos dispositivos crudos, a pesar de que ESXi

crea un archivo de mapeo con la extensión .vmdk y lo guarda en un almacén de datos

VMFS, el archivo de mapeo contiene solo información de mapeo, mientras que los datos

propiamente tal se almacenan de manera directa en el LUN de almacenamiento.

Configuración de vCPU, vMem y vNIC

Todas las propiedades de vCPU y vMem en todas las VM de las bases de datos Oracle

se dejaron en sus valores predeterminados, con excepción de la reserva de memoria.

Se asignaron distintas cantidades de vCPU, vMem y reservas de memoria a los diferentes

tipos de VM de bases de datos. Para obtener más información sobre los valores asignados

durante las pruebas de cada uno de los casos de prueba, consulte la tabla 2 y la tabla 7.



Se agregaron dos adaptadores de red virtual a cada una de las VM de las bases de datos: uno para la administración de VM dentro de banda y otro para el tráfico público de Oracle. Los dos adaptadores se configuraron con el ajuste de tipo recomendado de VMXNet 3. Para obtener más información sobre la configuración de switches virtuales y adaptadores físicos, consulte Diseño de la computación y la red en el apéndice B.

Habilitar el UUID de disco

Para cada VM, en los ajustes avanzados de las opciones de VM, se agregó el parámetro de configuración disk.enableUUID y su valor se configuró en TRUE. Este ajuste garantiza que el VMDK siempre presente un UUID de disco coherente a la VM.

En esta arquitectura de referencia se utilizaron las siguientes mejores prácticas para implementar y configurar Red Hat Enterprise Linux 7.4 como el sistema operativo huésped en las VM que ejecutaron las bases de datos Oracle independientes:

El sistema operativo, la red, los discos de almacenamiento, Oracle 18c (18.3.0) Grid y Oracle Database 18c (18.3.0) independiente se instalaron y configuraron dentro de la VM, cómo se indica en el siguiente artículo de la base de conocimientos de Dell EMC: Cómo implementar Oracle 18c Grid y una base de datos independiente en RHEL 7.x (en inglés).

Configure los requisitos de software de Oracle Grid y de la base de datos (RPM del sistema operativo, usuarios, grupos, parámetros de kernel, etc. necesarios) usando la información y el paquete de implementación que se incluyen en el siguiente artículo de la base de conocimientos de Dell EMC: RPM de implementación de Oracle de Dell EMC para Oracle 18c en RHEL7.x (en inglés).

También se siguieron estas importantes mejores prácticas:

En el sistema operativo huésped, para cada disco virtual de Oracle, se creó una única partición que abarcó el disco completo y que tuvo un desplazamiento inicial de 2048 sectores.

Se utilizaron reglas UDEV para establecer propiedades y permisos en los discos de Oracle dentro de la VM. En el siguiente ejemplo se muestra un conjunto de reglas UDEV para uno de los discos de Oracle (disco REDO) dentro del archivo de reglas UDEV /etc/udev/rules/60-oracle-asmdevices.rules personalizado:

KERNEL=="sd[a-z*[1-9", SUBSYSTEM=="block",

PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent",

RESULT=="3600601600f004300accaed5bd9741db5",

SYMLINK+="oracleasm/disks/ora-redo1", OWNER="grid",

GROUP="asmadmin", MODE="0660"

Como se describe en Diseño y configuración de VM, todos los LUN relacionados con las bases de datos Oracle que se presentaron al host ESXi desde el arreglo de almacenamiento PowerMax se mapearon directamente como dispositivos crudos a sus respectivas VM de base de datos por medio del mapeo de dispositivos crudos (RDM). De acuerdo con los requisitos de las bases de datos Oracle, la propiedad de los dispositivos crudos se asignó al usuario grid a quien pertenecen Oracle GI y Oracle Automatic Storage Management (ASM). El enlace del dispositivo para estos dispositivos crudos relacionados con Oracle es /dev/oracles’/disks/oral-XXX. Por ejemplo, /dev/oracle’s/disks/ora-redo1 es el enlace del dispositivo para el LUN/dispositivo crudo REDO1.

En la siguiente tabla se muestran los grupos de discos de Oracle que se crearon para la base de datos de OLTP usando los dispositivos crudos o los discos virtuales que se presentaron a la VM desde el arreglo de almacenamiento. Con excepción del grupo de discos OCR que utiliza la redundancia normal (con espejeado triple), todos los demás grupos de discos usaron el ajuste de redundancia externa. Se recomienda el ajuste de fraccionado grueso para los grupos de discos DATA, FRA y OCR, y el ajuste de fraccionado fino para los grupos de discos REDO1, REDO2 y TEMP.

Configuración

del sistema

operativos

huésped y

Oracle ASM

https://www.dell.com/support/article/my/en/mybsd1/how16915/how-to-deploy-oracle-18c-grid-and-standalone-database-on-rhel-7-x?lang=en

https://www.dell.com/support/article/my/en/mybsd1/how16915/how-to-deploy-oracle-18c-grid-and-standalone-database-on-rhel-7-x?lang=en

https://www.dell.com/support/article/my/en/mybsd1/sln316873/dell-oracle-deployment-rpms-for-oracle-18c-on-rhel7-x?lang=en

https://www.dell.com/support/article/my/en/mybsd1/sln316873/dell-oracle-deployment-rpms-for-oracle-18c-on-rhel7-x?lang=en




Table 36. Diseño de grupos de discos de ASM para la base de datos de OLTP

Grupo de discos de ASM

Propósito Redundancia Fraccionado de ASM

Tamaño del grupo de discos de ASM (GB)

LUN Tamaño del LUN (GB)

DATOS Archivos de datos, archivos de control y espacio de tabla de deshacer

Redundancia externa

Grueso 2,000 DATA00 500

DATA01 500

DATA02 500

DATA03 500

FRA Archivos de registro del archivo

Redundancia externa

Grueso 200 FRA0 100

FRA1 100

REDO1 Registros de reconstitución en línea

Redundancia externa

Fino 50 REDO0 25

REDO1 25

REDO2

Registros de reconstitución en línea

Redundancia externa

Fino

50 REDO2 25

REDO3 25

TEMP

Archivos temporales

Redundancia externa

Fino

500 TEMP

500

OCR OCR, disco con voto y GIMR

Redundancia normal

Grueso

50 OCR0 50

OCR1 50

OCR3 50

Nota: El diseño de grupos de discos de ASM para la base de datos de DSS y la base de datos de

instantáneas es idéntico al diseño de grupos de discos de ASM de la base de datos de OLTP que

se muestra en la tabla, con la siguiente excepción: en el diseño de grupos de discos de DSS, el

grupo de discos DATA tiene ocho discos de 500 GB para un tamaño total del grupo de discos de

4 TB, y el grupo de discos TEMP tiene un disco de 2 TB.

Oracle ASM incluye una función a través de la cual puede transferir los datos a pistas con

mayor rendimiento de los discos giratorios en la fase compacta al final del rebalanceo de

discos de ASM. Esta función no tiene ningún beneficio para el almacenamiento Dell EMC

PowerMax cuando se virtualiza el almacenamiento físico y se utilizan dispositivos flash.

Puede deshabilitar la función de rebalanceo mediante la ejecución del comando alter

diskgroup para todos los grupos de discos. En el siguiente ejemplo se muestra el

comando para el grupo de discos DATA:

SQL> alter diskgroup DATA set attribute '_rebalance_compact' =

'FALSE';

Para obtener más información acerca del rebalanceo compacto de ASM, consulte

la nota de soporte 1902001.1 de Oracle.

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=392647068805231&id=1902001.1&_adf.ctrl-state=emdpuym0_110



Configuraciones de VM y sistemas operativos huéspedes de SQL Server

Se utilizaron los siguientes principios de diseño y mejores prácticas para crear las VM para las bases de datos SQL Server.

Controladoras SCSI y discos duros virtuales

Se recomienda usar varias controladoras SCSI de tipo VMware Paravirtual para optimizar y equilibrar las I/O de los diferentes discos duros de las bases de datos SQL Server, como se describe en esta sección.

En la siguiente tabla se muestra el diseño recomendado de las controladoras SCSI para las VM de las bases de datos de OLTP e instantáneas. Los discos DATA y LOG se distribuyen entre controladoras SCSI dedicadas independientes, ya que, en una carga de trabajo de OLTP de SQL Server, ambos tipos de discos generan un alto nivel de I/O en el almacenamiento. Por otra parte, los discos de la base de datos TEMP generan relativamente pocas I/O y, por lo tanto, pueden coexistir con el volumen del sistema operativo en una controladora SCSI dedicada independiente.

Table 37. Propiedades de las controladoras SCSI en las VM de las bases de datos de OLTP e instantáneas


Tipo

SCSI 0 Disco del sistema operativo huésped, datos de tempdb y discos de registro

Ninguno

VMware Paravirtual

SCSI 1 Disco DATA de SQL 1

SCSI 2 Disco DATA de SQL 2

SCSI 3 Disco de registro de SQL

En la siguiente tabla se muestra el diseño recomendado de las controladoras SCSI para la VM de la base de datos de DSS. Las cargas de trabajo de DSS generan principalmente I/O de lectura en los discos DATA y pocas I/O en los discos de registro. Además, el uso de tempdb aumenta significativamente durante la carga de trabajo de DSS y puede generar una cantidad considerable de I/O. Debido a esto, como se muestra en la siguiente tabla, los discos DATA y los volúmenes tempdb se distribuyen entre las tres controladoras SCSI dedicadas con fines de balanceo de carga, mientras que los discos del sistema operativo, registro de tempdb y registro de la base de datos de DSS se ubican en conjunto en la primera controladora SCSI.

Table 38. Propiedades de las controladoras SCSI en las VM de DSS


Tipo

SCSI 0 Disco del sistema operativo huésped, registro de la base de datos de DSS y disco de registro de tempdb

Ninguno

VMware Paravirtual

SCSI 1 Discos de datos de SQL 1

SCSI 2 Discos de datos de SQL 2

SCSI 3 Discos de datos de tempdb

Todos los discos duros virtuales para las VM se crearon como almacenes de datos VMFS6. A continuación, cada almacén de datos se asignó a sus respectivas VM.

Diseño y

configuración

de VM




Configuración de vCPU, vMem y vNIC

Todas las propiedades de vCPU y vMem en todas las VM de las bases de datos SQL Server

se dejaron en sus valores predeterminados, con excepción de la reserva de memoria. Se

asignaron distintas cantidades de vCPU, vMem y reservas de memoria a los diferentes tipos

de VM de bases de datos. Para obtener más información sobre los valores que se asignaron

durante las pruebas de cada uno de los casos de uso, consulte la tabla 2 y la tabla 7.

Se agregaron dos adaptadores de red virtual a cada una de las VM de las bases de

datos: uno para la administración de VM dentro de banda y otro para el tráfico público

de SQL Server. Los dos adaptadores se configuraron con el ajuste de tipo

recomendado de VMXNet 3. Para obtener más información sobre la configuración de

switches virtuales y adaptadores físicos, consulte Diseño de la computación y la red en

el apéndice B.

Habilitar el UUID de disco

Para cada VM, en los ajustes avanzados de las opciones de VM, se agregó el parámetro

de configuración disk.enableUUID y su valor se configuró en TRUE. Este ajuste

garantiza que el VMDK siempre presente un UUID de disco coherente a la VM.

Para instalar y configurar los sistemas operativos huéspedes Red Hat Enterprise Linux 7.6,

consulte el documento Installing and Configuring Linux Guest Operating Systems de VMware.

Durante la configuración del sistema operativo huésped Red Hat Enterprise Linux 7.6

para SQL Server, se realizaron las siguientes tareas:

Se utilizó la herramienta de línea de comandos tuned-adm para configurar el perfil

de rendimiento de latencia para una carga de trabajo de OLTP.

Se utilizó la herramienta de línea de comandos tuned-adm para configurar el perfil

de rendimiento para una carga de trabajo de DSS.

Se siguió el documento Performance best practices and configuration guidelines for

SQL Server on Linux de Microsoft. Además, se agregaron los parámetros de

configuración relacionados con el rendimiento que recomienda Microsoft para el

sistema operativo Red Hat Enterprise Linux al perfil de rendimiento de latencia.

Además, para la carga de trabajo de OLTP, vm.dirty_background_ratio se

configuró en 20.

Se cambió la etiqueta del disco (el valor predeterminado DOS) a GPT.

Se crearon particiones de disco mediante la utilidad fstab o parted en los

dispositivos de almacenamiento. Se eligió el sistema de archivos EXT4 durante el

formateo de los discos.

Se mantuvieron todas las entradas de archivos montados en /etc/fstab para

permitir el montaje automático tras el reinicio del servidor.

Para instalar y configurar la base de datos independiente SQL Server 2017, consulte

las siguientes instrucciones de Microsoft: Quickstart: Install SQL Server and create

a database on Red Hat.

Instalación y

configuración

del sistema

operativo

huésped y de

SQL Server

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/linux_install_config.pdf







Después de la instalación de SQL Server 2017 en Red Hat Enterprise Linux 7.6, se

realizaron los siguientes cambios en la configuración:

Min server memory y Max server memory se configuraron en el mismo valor

y se dejó espacio para la sobrecarga del sistema operativo. Para obtener más

información, consulte SQL Server Max Memory Best Practices.

Se cambió la opción de configuración maximum degree of parallelism

(MAXDOP) y la opción cost threshold for parallelism después de la correcta

validación, debido a que el requisito de paralelismo de las consultas cambia según

el conjunto de datos y la naturaleza de las consultas. Para obtener más

información, consulte Recommendations and guidelines for the “max degree of

parallelism” configuration option in SQL Server y Configure the cost threshold for

parallelism Server Configuration Option. Durante este estudio, la opción MAXDOP

se mantuvo en su valor predeterminado de 0 para la carga de trabajo de OLTP

y en 8 para la carga de trabajo de DSS. Además, la opción cost threshold for

parallelism value se mantuvo en su valor predeterminado de 5.

El valor max worker thread se configuró de acuerdo con la carga de trabajo

y el procesador que se asignaron a la instancia de SQL Server. Para obtener

más información, consulte Configure the max worker threads Server Configuration

Option. Durante este estudio, la opción max worker thread se mantuvo en su

valor predeterminado de 0.

Se usaron varios archivos de datos en diferentes discos virtuales y LUN dentro del

mismo grupo de archivos.

Se asignaron varios archivos de datos de tempdb para abordar los problemas de

contención de tempdb. Para obtener más información, consulte Recommendations

to reduce allocation contention in SQL Server tempdb database. En este estudio,

se asignaron ocho archivos en una unidad independiente que se destinó a tempdb

con 8 GB por archivo.

Los archivos de datos de la base de datos, los archivos de registro de la base de

datos y los archivos tempdb se separaron en unidades independientes mapeadas

a discos virtuales y volúmenes dedicados. En este estudio, se crearon dos archivos

de datos y un archivo de registro en unidades dedicadas.

https://straightpathsql.com/archives/2017/02/sql-server-max-memory-best-practices/

https://support.microsoft.com/en-us/help/2806535/recommendations-and-guidelines-for-the-max-degree-of-parallelism-confi

https://support.microsoft.com/en-us/help/2806535/recommendations-and-guidelines-for-the-max-degree-of-parallelism-confi

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-cost-threshold-for-parallelism-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-cost-threshold-for-parallelism-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-max-worker-threads-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-max-worker-threads-server-configuration-option?view=sql-server-2017

https://support.microsoft.com/en-us/help/2154845/recommendations-to-reduce-allocation-contention-in-sql-server-tempdb-d

https://support.microsoft.com/en-us/help/2154845/recommendations-to-reduce-allocation-contention-in-sql-server-tempdb-d

consolide y simplifique las cargas de trabajo mixtas de ......tradicionalmente, las cargas de...

Documents