Consolide e simplifique cargas de trabalho mistas de banco de … · 2020. 9. 17. · Capítulo 1: Resumo executivo Consolide e simplifique cargas de trabalho mistas de banco de dados

Internal Use - Confidential

Consolide e simplifique cargas de trabalho mistas de banco de dados

Com bancos de dados Oracle 18c e Microsoft SQL Server 2017 na infraestrutura modular do Dell EMC PowerEdge MX, no storage array Dell EMC PowerMax 2000 e no sistema de backup Dell EMC Data Domain 9300

Julho de 2019

H17744.1

Guia de arquitetura de referência

Resumo geral

Este guia de arquitetura de referência descreve como projetamos e testamos cargas de trabalho mistas de banco de dados SQL Server e Oracle em uma infraestrutura que inclui uma infraestrutura modular do Dell EMC PowerEdge MX e o storage array PowerMax 2000. Ele também descreve a proteção de dados usando o sistema Dell EMC Data Domain DD9300 para fazer backup e recuperar um banco de dados Oracle.

Soluções Dell EMC

Copyright

2 Consolide e simplifique cargas de trabalho mistas de banco de dados Com bancos de dados Oracle 18c e Microsoft SQL Server 2017 na infraestrutura modular do Dell EMC PowerEdge MX, no storage array Dell EMC PowerMax 2000 e no sistema de backup Dell EMC Data Domain 9300 Guia de arquitetura de referência

As informações nesta publicação são fornecidas no estado em que se encontram. A Dell Inc. não garante nenhum tipo de informação contida nesta publicação, assim como se isenta de garantias de comercialização ou adequação de um produto a um propósito específico.

O uso, a cópia e a distribuição de qualquer software descrito nesta publicação exigem uma licença de software.

Copyright © 2019 Dell Inc. ou suas subsidiárias. Todos os direitos reservados. Dell Technologies, Dell, EMC, Dell EMC e outras marcas comerciais são marcas comerciais da Dell Inc. ou de suas subsidiárias. Intel, o logotipo da Intel, o logotipo Intel Inside e Xeon são marcas comerciais da Intel Corporation nos EUA e/ou em outros países. Outras marcas comerciais podem ser marcas comerciais de seus respectivos proprietários. Publicado no Brasil 07/19 Guia da arquitetura de referência H17744.1.

A Dell Inc. assegura que as informações apresentadas neste documento estão corretas na data da publicação. As informações estão sujeitas a alterações sem prévio aviso.

Conteúdo

3 Consolide e simplifique cargas de trabalho mistas de banco de dados Com bancos de dados Oracle 18c e Microsoft SQL Server 2017 na infraestrutura modular do Dell EMC PowerEdge

MX, no storage array Dell EMC PowerMax 2000 e no sistema de backup Dell EMC Data Domain 9300 Guia de arquitetura de referência

Conteúdo

Capítulo 1 Resumo executivo 5

Visão geral executiva ............................................................................................ 6

Público e finalidade ............................................................................................... 7

Valor das arquiteturas de referência validadas ...................................................... 7

Nós valorizamos seu feedback ............................................................................. 8

Capítulo 2 Visão geral do projeto e da arquitetura da solução 9

Diagrama da arquitetura da solução ................................................................... 10

Chassi modular PowerEdge MX7000 .................................................................. 11

Storage array PowerMax 2000 ............................................................................ 12

Equipamento de backup Data Domain DD9300 .................................................. 13

Redundância ....................................................................................................... 13

Capítulo 3 Objetivos do teste de validação, configuração e casos de uso 14

Objetivos de teste e configuração ....................................................................... 15

Caso de uso 1: Carga de trabalho OLTP usando benchmark do tipo TPC-C ...... 20

Caso de uso 2: Carga de trabalho DSS usando benchmark do tipo TPC-H ........ 20

Caso de uso 3: Carga de trabalho OLTP de snapshot usando benchmark do tipo TPC-C .......................................................................................................... 21

Níveis de serviço do PowerMaxOS ..................................................................... 22

Capítulo 4 Validação dos resultados dos testes 24

Visão geral .......................................................................................................... 25

Utilização média da CPU .................................................................................... 25

TPM .................................................................................................................... 27

NOPM ................................................................................................................. 31

IOPS de armazenamento .................................................................................... 33

Latência de armazenamento ............................................................................... 36

Throughput ......................................................................................................... 39

Desempenho combinado de IOPS, latência e throughput ................................... 40

Capítulo 5 Solução de backup e recuperação Data Domain 43

Introdução ........................................................................................................... 44

Solução de backup e recuperação para Oracle ................................................... 44

Solução de backup e recuperação para SQL Server ........................................... 51

Capítulo 6 Conclusões a partir dos resultados dos testes 52

Desempenho em escala ..................................................................................... 53

Conteúdo


Resultados de desempenho do PowerEdge MX840c .......................................... 53

Resultados de desempenho do PowerMax 2000 ................................................ 53

Resultados de backup e recuperação do Data Domain ....................................... 54

Resumo dos resultados ...................................................................................... 54

Para obter mais informações .............................................................................. 55

Capítulo 7 Referências 56

Documentação da Dell EMC ............................................................................... 57

Documentação da VMware ................................................................................. 57

Documentação da Oracle.................................................................................... 57

Documentação da Microsoft ................................................................................ 57

Documentação do HammerDB............................................................................ 57

Apêndice A Solução de hardware e software 58

Componentes de hardware ................................................................................. 59

Componentes de software .................................................................................. 61

Apêndice B Detalhes de projeto e configuração 63

Projeto de computação e rede ............................................................................ 64

Configuração de armazenamento do PowerMax ................................................. 71

Configurações do sistema operacional guest e das VMs do Oracle ...................... 77

Configurações do sistema operacional guest e das VMs do SQL Server ............ 82

Capítulo 1: Resumo executivo



Capítulo 1 Resumo executivo

Este capítulo apresenta os seguintes tópicos:

Visão geral executiva .......................................................................................... 6

Público e finalidade ............................................................................................ 7

Valor das arquiteturas de referência validadas ................................................ 7

Nós valorizamos seu feedback .......................................................................... 8



Visão geral executiva

A consolidação das cargas de trabalho de bancos de dados tem muitos benefícios.

Talvez o maior benefício seja que ela permite à empresa aumentar a utilização da

infraestrutura sem sacrificar o desempenho e, ao mesmo tempo, manter a elasticidade

e a agilidade para responder às novas solicitações. No entanto, o maior desafio para

o projeto e a entrega de uma solução de consolidação é a incerteza de como todos

os componentes serão integrados e se eles fornecerão retorno do investimento.

As complexidades da integração, do suporte e da otimização de um projeto de vários

fornecedores podem exigir um investimento inicial significativo que pode não ser

retornado por algum tempo.

As CI (Converged Infrastructures, infraestruturas convergentes) e as HCI

(Hyperconverged Infrastructures, infraestruturas hiperconvergentes) foram criadas para

reduzir as complexidades dos bancos de dados modernos, oferecendo uma solução

totalmente projetada com gerenciamento do ciclo de vida. Os bancos de dados são

exclusivos, pois as considerações sobre licenciamento e desempenho são igualmente

importantes para os negócios. O posicionamento do licenciamento do banco de dados

em soluções convergentes pode representar incerteza ou risco significativo para os

negócios. No entanto, muitas empresas executam com sucesso banco de dados na CI,

comprovando que essa abordagem funciona.

Uma combinação das abordagens de vários fornecedores e de CI oferece uma solução

integrada e testada criada para cargas de trabalho de banco de dados. Essa arquitetura

de referência para cargas de trabalho mistas foi criada e testada para bancos de dados

SQL Server e Oracle executados na mesma infraestrutura validada, que inclui produtos

Dell EMC PowerEdge e PowerMax. A infraestrutura modular do Dell EMC PowerEdge MX

permite que você dedique servidores a bancos de dados específicos. Nessa solução,

demonstramos como os bancos de dados SQL Server e Oracle usam servidores

dedicados para proporcionar simplicidade de gerenciamento, escalabilidade e eficiência

no licenciamento ao usar um storage array Dell EMC PowerMax 2000 para dar suporte

a cargas de trabalho mistas.

Cargas de trabalho mistas de banco de dados, como OLTP (Online Transaction

Processing, processamento online de transações) e DSS (Decision Support System,

sistema de suporte a decisões), tradicionalmente eram difíceis de gerenciar na mesma

infraestrutura. Cada uma dessas cargas de trabalho impõe diferentes demandas no

sistema de armazenamento. O sistema de armazenamento não pode ser ajustado para

uma carga de trabalho ou para outra; em vez disso, ele deve dar suporte a cargas de

banco de dados em níveis de desempenho que atendam aos Acordos de Nível de

Serviço. O PowerMax 2000 com unidades flash NVM Express (NVMe) apresenta

melhorias no desempenho e no paralelismo que proporcionam uma correspondência

ideal para cargas de trabalho mistas de banco de dados. As unidades flash NVMe

oferecem maior velocidade e a capacidade de atender a mais solicitações em paralelo.

Este guia descreve três testes de validação que projetamos para levar o sistema a limites

realistas de nível de serviço. Um dos principais objetivos desses testes foi gerar a

quantidade máxima de carga sobre a arquitetura de referência sem a maioria das

Desafio da

empresa

Infraestruturas

convergente

e hiper-

convergente

Cargas de

trabalho mistas

de banco de

dados




atividades de leitura e gravação que excedem 1 milissegundo (ms) de latência. Os testes

de validação superaram nossas expectativas, especialmente para uma configuração de

storage array de nível básico que foi criada para manter baixo o investimento inicial de

um cliente. O capítulo 6 resume os resultados do teste.

As falhas de banco de dados podem representar um risco significativo para os negócios

devido à interrupção das operações, afetando a receita. Fazer backup e proteger bancos

de dados prepara a empresa para recuperar-se de uma falha espontânea. A equipe de

validação da Dell EMC testou uma solução de backup e recuperação usando o software

DD Boost e o sistema de backup Data Domain DD9300 que podem dar suporte às cargas

de trabalho de banco de dados discutidas neste guia. O capítulo 5 discute os casos de

teste e os resultados do teste.

Público e finalidade

Este guia é destinado a qualquer pessoa que esteja interessada em aprender sobre os

benefícios dessa arquitetura de referência, inclusive arquitetos de soluções, DBAs SQL

Server e Oracle, administradores de armazenamento e administradores de Linux. Ela

oferece:

Detalhes da configuração física

Resultados dos testes de desempenho de cargas de trabalho mistas de bancos de

dados SQL Server e Oracle

Práticas recomendadas e configuração de armazenamento do PowerMax

Configuração do Red Hat Enterprise Linux para desempenho otimizado

Além disso, esse guia é importante para qualquer pessoa que queira avaliar, adquirir,

gerenciar, manter e operar ambientes mistos de bancos de dados.

Valor das arquiteturas de referência validadas

A equipe de projeto validado da Dell EMC consiste em um grupo de especialistas com

ampla experiência em bancos de dados. Nosso objetivo é criar soluções focadas para as

cargas de trabalho mais difíceis que uma empresa possa exigir. Isso é exclusivamente

diferente da maioria das soluções atuais, que são projetadas para trabalhar com tudo.

Para aumentar o valor para nossos clientes, validamos nossas soluções executando

vários testes:

Executamos bancos de dados SQL Server e Oracle OLTP na arquitetura de

referência em paralelo.

Executamos cargas de trabalho OLTP e DSS de ambos os bancos de dados na

arquitetura de referência em paralelo.

Nós testamos o recurso de snapshot do PowerMax criando snapshots de ambos os

bancos de dados e executando uma carga de trabalho OLTP nos snapshots.

Testamos o DD Boost, bem como o desempenho do sistema DD9300 e a

capacidade de fazer backup e restaurar um banco de dados Oracle de 1,8 TB.

Principal

objetivo de

testes de

validação

Backup e

recuperação

de bancos

de dados



Como parte dos testes de validação, ajustamos e otimizamos todos os componentes de

software e hardware dessa arquitetura de referência para maximizar o desempenho.

Documentamos como práticas recomendadas neste guia todas as alterações que

aprimoraram o desempenho.

Essa arquitetura de referência beneficia os clientes oferecendo:

Uma solução de banco de dados especializada — sem algo único que sirva

para tudo. Essa arquitetura de referência foi projetada, testada e validada

especialmente para cargas de trabalho mistas de banco de dados.

Testes de validação do banco de dados — realizamos testes usando os

executáveis que os clientes usam em seus bancos de dados. Nenhuma E/S de

banco de dados foi simulada neste teste.

Dimensionamento para atender aos requisitos — você pode personalizar a

configuração testada para atender às necessidades de sua carga de trabalho mista

de banco de dados.

Solução testada e comprovada de backup e recuperação — esteja preparado

para falhas não planejadas do banco de dados e minimize o tempo de inatividade,

que custa caro.

Menos risco — nós integramos, testamos e documentamos esse sistema

validado.

Usamos a ferramenta de benchmark HammerDB para criar cargas de trabalho OLTP e

DSS na nova solução de banco de dados. O HammerDB é gratuito e está disponível para

ser usado por qualquer pessoa na condução de seus próprios testes.

Nós valorizamos seu feedback

Para a Dell EMC e os autores deste documento, seu feedback sobre a solução e a

documentação é bem-vindo. Entre em contato com a equipe de soluções da Dell EMC

por e-mail ou envie seus comentários preenchendo nossa pesquisa sobre documentação.

Autores: equipes de engenharia Oracle e SQL, Indranil Chakrabarti, Anil Papisetty, Sam

Lucido, Reed Tucker

As seguintes páginas dos espaços Oracle e SQL Server no site Dell EMC Communities

fornecem links para documentação adicional desta solução:

Hub de informações Oracle

Hub de informações Microsoft SQL

Principais

benefícios

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

Capítulo 2: Visão geral do projeto e da arquitetura da solução



Capítulo 2 Visão geral do projeto e da arquitetura da solução


Diagrama da arquitetura da solução ................................................................ 10

Chassi modular PowerEdge MX7000 ............................................................... 11

Storage array PowerMax 2000 .......................................................................... 12

Redundância ..................................................................................................... 13



Diagrama da arquitetura da solução

A figura a seguir fornece uma visão geral do projeto dessa arquitetura de referência:

Figure 1. Visão geral do projeto e da arquitetura da solução

Como mostrado, a infraestrutura de chassi modular do PowerEdge MX7000 oferece os

recursos de computação e rede, o PowerMax 2000 é usado como storage array da SAN

e o Data Domain DD9300 é usado como equipamento de backup nessa arquitetura de

referência.




Chassi modular PowerEdge MX7000

Usamos o chassi modular Dell EMC PowerEdge MX7000, que oferece infraestrutura de

data center de alto desempenho, para recursos de computação e rede nessa solução.

Os recursos de computação ou servidor para essa arquitetura de referência são:

Um blade do PowerEdge MX840c para bancos de dados Oracle —

implementamos esse servidor blade de quatro soquetes com o hypervisor VMware

ESXi 6.7 e o configuramos para executar três máquinas virtuais de banco de dados

Oracle de único nó. Implementamos cada VM com a Oracle 18c (18.3.0) Grid

Infrastructure (GI) e um Oracle Database 18c (18.3.0) independente em execução

no Red Hat Enterprise Linux 7.4 como o sistema operacional guest. Configuramos

as VMs da seguinte maneira:

Configuramos a primeira VM para executar a carga de trabalho de banco de

dados de produção Oracle OLTP.

Configuramos a segunda VM para executar a carga de trabalho de banco de

dados Oracle DSS.

Configuramos a terceira VM para executar uma carga de trabalho de banco de

dados OLTP que criamos como um snapshot do banco de dados de produção

OLTP no storage array PowerMax.

Para obter detalhes sobre o host ESXi, as VMs para bancos de dados Oracle e a

configuração de rede virtual, consulte o Apêndice B: Detalhes de projeto e

configuração.

Um blade do PowerEdge MX840c para bancos de dados SQL Server —

implementamos esse servidor blade de quatro soquetes com o hypervisor VMware

ESXi 6.7 e o usamos para executar cinco máquinas virtuais de banco de dados

SQL Server de único nó. Implementamos uma instância independente do SQL

Server 2017 em cada VM com Red Hat Enterprise Linux 7.6 como sistema

operacional guest. Configuramos as VMs da seguinte maneira:

Configuramos as duas primeiras VMs para executar a carga de trabalho de

banco de dados de produção OLTP SQL.

Configuramos a terceira e a quarta VMs para executar a carga de trabalho de

banco de dados SQL DSS.

Configuramos a quinta VM para executar uma carga de trabalho de banco de

dados OLTP que criamos como um snapshot do banco de dados de produção

OLTP no storage array PowerMax para simular um ambiente de teste ou

desenvolvimento, ou ambos.

Para obter detalhes sobre o host ESXi, as VMs para bancos de dados SQL Server

e a configuração de rede virtual, consulte o Apêndice B: Detalhes de projeto e

configuração.

Subcomponentes do blade do MX840c — cada blade do MX840c usado para os

bancos de dados Oracle e SQL Server é composto por 4 CPUs físicas

dimensionáveis Intel Xeon 20c, 1.536 GB de RAM e 4 placas de mezanino de

25 GbE com duas portas QLogic QL41262 ou CNAs (Converged Network

Camada de

computação

ou servidor



Adapters, adaptadores de rede convergente) para tráfego de LAN e SAN.

Configuramos duas das placas de mezanino para FCoE (Fibre Channel over

Ethernet) ou tráfego de SAN. Configuramos as duas placas restantes para o

tráfego de LAN. Criamos NPAR (NIC Partitioning, particionamento de NIC) em

todas as placas de mezanino. Para obter detalhes sobre a configuração do CNA,

consulte Configuração do adaptador de rede convergente no Apêndice B.

Usamos a infraestrutura modular do PowerEdge MX7000 para fornecer a camada de

switch de rede nesta solução. A camada de rede consiste em:

Dois módulos de E/S (IOMs) ou comutadores FSE (Fabric Switching Engine,

engine comutador de fabric) MX9116n — configuramos dois IOMs MX9116n

instalados no fabric slot A1 do MX e no fabric slot B1 do MX para executar o

tráfego de SAN e LAN convergente nesta solução. Configuramos os dois IOMs no

modo VLT (Virtual Link Trunking). Configuramos as duas portas unificadas

QSFP28 (100 Gb) de acesso externo em 4 no modo "breakout" FC (Fibre Channel)

de 16 Gb/s e as conectamos diretamente ao storage array PowerMax 2000.

Configuramos a porta QSFP28 de acesso externo em 4 no modo "breakout" de

10 GbE e a conectamos aos comutadores spine para conectividade externa da

LAN. Configuramos as portas de 25 GbE de acesso interno que conectamos às

portas CNA nos blades do MX840c para realizar o tráfego de FCoE e LAN. Para

obter detalhes sobre a configuração de rede de LAN e SAN, inclusive o

zoneamento de FC, consulte Projeto de computação e rede no Apêndice B.

Módulo redundante de gerenciamento do MX — conectamos módulos

redundantes de gerenciamento do MX de 1 GbE a comutadores de 1 GbE.

Usamos esse módulo de gerenciamento para gerenciar o chassi MX7000 e os

IOMs do MX9116n, e para se conectar aos iDRACs nos blades do MX840c. Para

obter detalhes sobre o gerenciamento do chassi MX7000, consulte o Guia do

usuário do chassi Dell EMC OpenManage Enterprise-Modular Edition Version

1.00.01 for PowerEdge MX7000.

Storage array PowerMax 2000

Usamos um storage array PowerMax 2000 único como armazenamento FC SAN para

hospedar bancos de dados Oracle e SQL Server. O array PowerMax 2000 nesta

arquitetura de referência consistia em:

Um brick ou mecanismo do PowerMax 2000, que consiste em dois directors

16 portas FC front-end de 16 Gb/s diretamente conectadas a IOMs MX9116n

separados para oferecer dois SAN fabrics para alta disponibilidade e

balanceamento de carga

Dois grupos de portas front-end, um para o tráfego do banco de dados Oracle e

outro para o tráfego do banco de dados SQL Server, com oito portas FC separadas

em cada um

24 unidades flash NVMe de 3,8 TB em uma configuração RAID 5 (7+1) para

oferecer uma capacidade de armazenamento utilizável de 73,35 TB

Camada de rede

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






Grupos de armazenamento separados para bancos de dados Oracle e SQL Server

para balanceamento de carga por meio de diferentes grupos de portas, facilidade

de gerenciamento e monitoramento

Para obter detalhes sobre os grupos de armazenamento e a configuração de volume,

consulte Configuração de armazenamento do Powermax no Apêndice B.

Equipamento de backup Data Domain DD9300

Usamos o DD9300 como equipamento de backup para testar o backup e a recuperação

de um banco de dados Oracle nesta arquitetura de referência. 4 interfaces front-end de

10 GbE distribuídas entre duas NICs instaladas no DD9300 foram conectadas aos

mesmos comutadores spine aos quais os switches de rede do MX estavam conectados.

Isso fornece conectividade altamente disponível e largura de banda suficiente entre os

servidores de banco de dados do MX840c e o equipamento de backup DD9300. As

interfaces configuradas para o tráfego de rede pública nos servidores de banco de dados

foram usadas também para o tráfego de backup e recuperação. Para que essa

comunicação aconteça, as interfaces de 10 GbE no DD9300 também foram configuradas

dentro desse mesmo intervalo de endereços de rede IP pública.

Para obter detalhes sobre o DD9300 e a configuração do servidor de banco de dados, a

metodologia e os resultados dos testes de backup e recuperação, consulte o Capítulo 5

Solução de backup e recuperação do Data Domain.

Redundância

O projeto de LAN e SAN apresenta componentes e conectividade redundantes em todos

os níveis para garantir que não haja nenhum ponto único de falha. O projeto permite que

o application server e o sistema de backup alcancem o servidor de banco de dados, e o

servidor de banco de dados alcance o storage array, mesmo se houver falha em algum

dos seguintes componentes:

Uma ou mais portas de CNA ou da placa de mezanino nos blades de computação

do MX840c

Um IOM ou comutador do MX9116n

Uma ou mais portas front-end do PowerMax

Uma controladora de armazenamento do PowerMax

Uma ou mais interfaces front-end de 10 GbE no sistema de backup DD9300

Capítulo 3: Objetivos do teste de validação, configuração e casos de uso


Capítulo 3 Objetivos do teste de validação, configuração e casos de uso


Objetivos de teste e configuração ................................................................... 15

Caso de uso 1: Carga de trabalho OLTP usando benchmark do tipo TPC-C .. 20

Caso de uso 2: Carga de trabalho DSS usando benchmark do tipo TPC-H . 20

Caso de uso 3: Carga de trabalho OLTP de snapshot usando benchmark do tipo TPC-C .................................................................................................... 21

Níveis de serviço do PowerMaxOS .................................................................. 22




Objetivos de teste e configuração

Nosso objetivo em testar essa solução de carga de trabalho mista era simular uma plataforma

de banco de dados consolidada para uso pelas equipes de Oracle e SQL Server.

Geralmente, a consolidação de ecossistemas de banco de dados tem prioridade menor do

que o desempenho e a proteção, pois os riscos percebidos e a complexidade que estão

envolvidos na consolidação de bancos de dados são assustadores. No entanto, a introdução

de CPUs mais rápidas e mais potentes, bem como novas tecnologias de armazenamento em

uma arquitetura de referência testada e comprovada permite que as empresas consolidem

bancos de dados sem preocupações com riscos.

O storage array PowerMax 2000 usa unidades flash NVMe, que são significativamente mais

rápidas do que os tradicionais SSDs (Solid State Drives) SATA. As unidades flash NVMe

oferecem vários aprimoramentos que aceleram as operações de armazenamento, inclusive

um paralelismo maior e um barramento atualizado que permite uma transferência de dados

mais rápida. Ao testar essa plataforma de banco de dados, criamos um ambiente misto

usando Oracle e SQL Server, e um ambiente de cargas de trabalho mistas, inclusive cargas

de trabalho OLTP e DSS. Essa combinação de bancos de dados e cargas de trabalho

diferentes simula o que um cliente pode encontrar durante um trabalho de consolidação de

banco de dados.

O chassi modular MX7000 hospeda blocks desagregados de servidor e armazenamento,

o que o torna ideal para consolidar bancos de dados. Na configuração de teste, usamos

dois servidores PowerEdge MX840c no chassi modular MX7000. Nós dedicamos um

servidor MX840c ao banco de dados SQL Server 2017 Enterprise Evaluation Edition

RTM-CU13 e o outro ao banco de dados Oracle 18c Enterprise Edition. Dedicar um

servidor MX840c a cada banco de dados otimiza o licenciamento limitando os custos e

nos permite testar a consolidação do banco de dados. Em nossos testes, configuramos

identicamente cada MX840c com 4 CPUs e 1,5 TB de memória. Cada CPU tinha 20

núcleos; portanto, 80 núcleos estavam disponíveis para cada banco de dados.

Implementamos VMs de bancos de dados SQL Server e Oracle com o Red Hat

Enterprise Linux 7 como sistema operacional guest. A Microsoft permite que os clientes

do SQL Server movam gratuitamente suas licenças de banco de dados do Windows para

o Linux. Padronizamos o sistema operacional, usando Linux em ambos os bancos de

dados, para simplificar o gerenciamento. Em termos de testes de bancos de dados

mistos, usando a mesma execução simplificada do sistema operacional e permitimos

uma análise mais rápida dos resultados de desempenho.

Configuramos o storage array PowerMax 2000 com 24 unidades flash NVMe, o que

representa uma configuração de armazenamento de nível básico. O uso de uma

configuração de nível básico para nossos testes demonstra que os clientes podem

começar com um investimento mínimo e fazer o scale-up para atender às demandas

crescentes. A tabela a seguir mostra o tamanho da configuração de armazenamento que

usamos e os tamanhos máximos para o array PowerMax 2000, conforme detalhado na

specification sheet da família Powermax:

Configuração de

infraestrutura

validada

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



Table 1. Configuração compatível máxima do PowerMax 2000 versus configuração testada

Componentes do PowerMax 2000

Configurações máximas compatíveis com suporte

Configurações testadas

Número de bricks ou mecanismos 2 1

Cache do sistema (bruto) 4 TB (com mecanismo de 2 TB)

1 TB

Número de módulos de E/S de front-end por array

16 4

Portas de host FC de 16 Gb/s por array 64 16

Número de unidades flash NVMe 96 24

Ao testar o desempenho de armazenamento do array PowerMax 2000, tínhamos os seguintes

objetivos:

Gerar uma carga de trabalho de banco de dados mista significativa para desafiar o

PowerMax 2000.

Impulsionar uma combinação de IOPS e latência inferior a um milissegundo que é

representativa da demanda em um ecossistema de cargas de trabalho mistas.

Capturar os resultados dos testes e transformar nossa análise em práticas

recomendadas para os clientes.

O array PowerMax 2000 dá suporte a unidades flash NVMe. As unidades flash NVMe

permitem um armazenamento em block em grande escala para dar suporte aos

adaptadores de rede e adaptadores de barramento de host existentes. Uma das

principais vantagens das unidades flash NVMe é o desempenho aprimorado. Outros

benefícios do armazenamento baseado em NVMe incluem:

Maior IOPS e menor latência

Suporte a filas profundas: 64 comandos por fila, até 64.000 filas

Interface de registro simplificada que minimiza a utilização da CPU necessária para

gerenciar as operações de E/S

Transparência para bancos de dados para que você possa obter os benefícios do

desempenho do NVMe sem etapas adicionais

Obs.: a Dell EMC também oferece o sistema PowerMax 8000, que tem ainda mais recursos de

dimensionamento e desempenho do que o PowerMax 2000, que usamos nos testes desta

solução.

Nós usamos o VMware vSphere nessa arquitetura de referência para impulsionar

maior consolidação, acelerar o provisionamento de bancos de dados e simplificar

o gerenciamento. A virtualização permite que você agrupe os recursos de computação

e armazenamento para impulsionar maior eficiência de hardware. Nessa solução de

carga de trabalho mista, usamos o vSphere para virtualizar os bancos de dados SQL

Server e Oracle, bem como atribuir recursos de CPU e memória.

NVMe

VMware vSphere




Em nossos testes, os recursos de CPU e memória não eram os mesmos entre SQL Server e

Oracle, nem o número de bancos de dados. Nosso objetivo não era comparar o SQL Server

com o Oracle, mas colocar bancos de dados mistos e cargas de trabalho de banco de dados

nos servidores MX840c e no array PowerMax 2000 para mostrar como essa solução de

infraestrutura única acelera os bancos de dados consolidados. A tabela a seguir mostra as

configurações de VM do Oracle e do SQL Server:

Table 2. Configuração de virtualização para bancos de dados

Tipo de carga de trabalho

Tipo de banco de dados

Número da máquina virtual

Alocação de vCPU

Alocação de vMem (GB)

Reserva de memória do banco de dados (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

Snapshot OLTP Oracle VM 1 6 150 36 (28 SGA + 8 PGA)

Snapshot OLTP SQL Server VM 1 4 64 8

Cada banco de dados virtualizado usava um subconjunto dos núcleos de computação

disponíveis nos servidores MX840c. Atribuímos 24 núcleos de computação para VMs

Oracle, deixando 136 núcleos para consolidação adicional de banco de dados no servidor

MX840c, que foi dedicado a Oracle. Da mesma forma, atribuímos 32 núcleos de

computação para VMs SQL Server, deixando 128 núcleos disponíveis para outros bancos

de dados.

Usamos reservas de memória para dedicar memória a cada banco de dados virtualizada.

Definimos reservas de pouca memória para cada banco de dados a fim de gerar

atividade no storage array PowerMax 2000. Se esses bancos de dados fossem

aplicativos reais de produção de clientes, recomendaríamos reservar mais memória, pois

as operações em memória são mais rápidas do que as operações de armazenamento.

Assim como as configurações de CPU, as configurações de memória usavam um

subconjunto da memória disponível no servidor. Em todos os bancos de dados Oracle

virtualizados, a quantidade de memória utilizada era de 188 GB, e a memória total

disponível no servidor MX840c era de 1,5 TB. Para todos os bancos de dados SQL

Server virtualizados, a quantidade de memória utilizada era de 88 GB, e a memória total

disponível no servidor MX840c era de 1,5 TB.

Os núcleos de computação podem ser limitados na camada do banco de dados usando

a restrição de CPU da Oracle ou o SQL Server Resource Governor, ou na camada do

sistema operacional Linux com cgroups. No entanto, a virtualização do vSphere simplifica

o gerenciamento de recursos, o que faz dele a melhor opção para atribuir núcleos de

computação e memória.

O storage array PowerMax 2000 é compatível com a tecnologia vSphere NMP (Native

Multipathing Plug-In). Os múltiplos caminhos aumentam a eficiência do envio de dados

por meio de caminhos de hardware redundantes que conectam os servidores PowerEdge



ao armazenamento do PowerMax. Os benefícios incluem a alternância de E/S usando

round-robin para otimizar o uso dos caminhos de hardware e distribuir os dados de

maneira mais uniforme. Outro benefício é que, se algum componente falhar ao longo do

caminho de armazenamento, o NMP redefinirá a conexão e passará a E/S usando um

caminho alternativo.

Testamos três casos de uso incrementais:

Caso de uso 1: Carga de trabalho OLTP usando benchmark do tipo TPC-C

Caso de uso 2: Carga de trabalho DSS usando benchmark do tipo TPC-H

Caso de uso 3: Carga de trabalho OLTP de snapshot usando benchmark do tipo

TPC-C

As medições de desempenho para esses testes incluíram:

Núcleos de CPU — geramos cargas de trabalho semelhantes às de produção

usando o mínimo possível de núcleos de CPU. Os bancos de dados Oracle e SQL

Server usam licenciamento com base em núcleo. À medida que o número de

núcleos aumenta, também aumenta o custo de licenciamento. Usar a combinação

dos servidores MX840c e do storage array PowerMax 2000 nos permitiu gerar uma

carga de trabalho de banco de dados significativa com menos núcleos de

computação.

Utilização da CPU — capturamos a utilização da CPU na camada Linux usando

dstat. Os valores de utilização da CPU que capturamos representam a soma de

todos os trabalhos que eram compatíveis com os núcleos atribuídos às máquinas

virtuais. A geração de relatórios de utilização da CPU oferece noções básicas da

carga de processamento que foi realizada pelos núcleos de CPU nesses testes.

Não havia metas pretendidas para a utilização da CPU, pois o uso de menos

núcleos em cada VM era uma prioridade mais alta; no entanto, capturamos essa

medição para fornecer percepções sobre a carga de trabalho de processamento.

TPM — capturamos o número de TPM (Transactions Per Minute, transações por

minuto) para mostrar a rapidez com que um banco de dados OLTP processava as

transações. Um valor mais alto de TPM indica que o banco de dados estava

processando mais transações comerciais. Ao testar a solução de cargas de

trabalho mistas, o objetivo era gerar TPM suficiente para dar suporte a uma carga

de trabalho típica de produção. Essa medição aplica-se apenas às cargas de

trabalho OLTP e é capturada no relatório HammerDB.

NOPM — NOPM (New Orders per Minute, novos pedidos por minuto) é uma

medida de throughput no benchmark TPC-C. Cada transação consiste nos

seguintes tipos de transação: novas ordens, pagamento, status da ordem, entrega

e transações em nível de estoque. Assim, o NOPM indica quantas transações de

ordens foram concluídas em um minuto como parte de um processo de negócios

serial. Essa medição aplica-se apenas às cargas de trabalho OLTP e é capturada

no relatório HammerDB.

IOPS — o número de IOPS indica a carga em um sistema de armazenamento.

Você pode usar IOPS para entender a quantidade de carga que cada banco de

dados e aplicativo está colocando no array e se elas estão se aproximando da

carga máxima no storage array. IOPS junto com latência fornece uma visão

Teste de

medição de

desempenho

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




abrangente do desempenho do armazenamento. Nesses testes, o objetivo era

mostrar a IOPS que é apropriada para o suporte de bancos de dados de produção.

Latência inferior a um milissegundo — a latência indica como os dados são

lidos e gravados no storage array. A latência de armazenamento é uma medida

importante para aplicativos OLTP, pois quanto mais rápido o sistema de

armazenamento puder responder às solicitações de leitura e gravação, mais

responsiva será a experiência do aplicativo para os usuários. A meta de latência de

armazenamento para esta solução era de 1 ms ou menos para leituras e

gravações em todos os arquivos de log e dados em cargas de trabalho OLTP que

estavam simulando cargas de trabalho de produção.

Throughput em megabytes por segundo (MB/s) — o throughput é uma medida

usada para cargas de trabalho DSS a fim de indicar com que rapidez o sistema

pode processar grandes volumes de dados usando consultas complexas. Quanto

maior o throughput de um sistema, mais dados ele poderá processar e mais rápido

poderá realizar uma análise complexa dos dados. Nosso objetivo era gerar um

nível moderado de throughput na solução para mostrar que os clientes podem ter

cargas de trabalho DSS e cargas de trabalho OLTP em execução em paralelo.

Compactação e desduplicação — desabilitamos a compactação e a

desduplicação do Powermax no nível do grupo de armazenamento para todos os

casos de uso. Portanto, não observamos redução de dados neste teste de

validação. Na fase de teste de estresse, executamos os piores cenários de teste

com 100% de dados ativos no PowerMax 2000. Esse perfil de carga de trabalho

não aproveita os recursos de desempenho de redução de dados do PowerMax.

Um ambiente de produção de banco de dados típico com cargas de trabalho

mistas se beneficia do mecanismo de compactação e desduplicação do PowerMax,

que oferece vantagens de desempenho e consolidação. Você pode preferir usar

esses recursos ao implementar a solução.



Caso de uso 1: Carga de trabalho OLTP usando benchmark do tipo TPC-C

O primeiro teste estabeleceu uma linha de base executando uma carga de trabalho de

banco de dados OLTP que geramos usando um benchmark do tipo TPC-C em ambos os

bancos de dados Oracle e SQL Server. Observe que um benchmark "tipo TPC-C"

significa que os resultados do teste não são certificados. O benchmark TPC-C é uma

carga de trabalho OLTP complexa. As cargas de trabalho OLTP simulam os aplicativos

corporativos que as empresas usam para gerenciar todos os processos operacionais.

Usamos a ferramenta popular HammerDB para gerar a carga de trabalho tipo TPC-C.

Para o teste do caso de uso de OLTP, executamos um banco de dados Oracle e dois

bancos de dados SQL Server em paralelo para gerar uma carga de trabalho OLTP no

sistema. As medições de desempenho que capturamos servem como linha de base

para determinar como outras cargas de trabalho afetam a carga de trabalho OLTP. A

configuração da carga de trabalho OLTP do TPC-C é mostrada na tabela a seguir:

Table 3. Configuração de benchmark tipo TPC-C para o caso de uso de carga de trabalho OLTP

Parâmetro tipo TPC-C do HammerDB

SQL Server Oracle Total

Fator de escala de banco de dados

10.000 15.000 25.000

Tamanho do banco de dados (TB)

2 (VM1 + VM2) 1,5 3.5

Número de usuários virtuais

400 500 900

Duração do teste (minutos)

30 30

Caso de uso 2: Carga de trabalho DSS usando benchmark do tipo TPC-H

O segundo teste adiciona uma carga de trabalho DSS ao sistema gerando cargas de

trabalho tipo TPC-H. Observe que uma carga de trabalho "tipo TPC-C" significa que

os resultados do teste não são certificados. O benchmark TPC-H consiste em

consultas ad-hoc e modificação simultânea de dados em grandes conjuntos de dados.

As empresas podem usar um DSS para analisar um grande volume de dados a fim de

gerar relatórios que facilitem as decisões de negócios baseadas em evidência.

Monitoramos as medições de throughput e armazenamento somente como parte da

execução de uma carga de trabalho DSS. Portanto, não analisamos as medições,

como Query-por-hora (QphH@Size) composta do TPC-H neste documento.

Para o caso de uso de DSS, executamos um banco de dados Oracle e dois bancos

de dados SQL Server em paralelo para gerar throughput no storage array PowerMax

2000. A carga de trabalho DSS era executada em paralelo com a carga de traba lho

OLTP, criando uma carga de trabalho combinada no sistema.

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

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




A tabela a seguir detalha a configuração dos testes tipo TPC-H:

Table 4. Configuração de benchmark tipo TPC-H para o caso de uso de carga de trabalho DSS

Parâmetro tipo TPC-H do HammerDB



1.000 3.000 4.000


2 (VM1 + VM2) 3 5

Número de usuários virtuais

2 1 3

Duração do teste (minutos)

30 30

Caso de uso 3: Carga de trabalho OLTP de snapshot usando benchmark do tipo TPC-C

O terceiro teste cria snapshots de armazenamento dos bancos de dados Oracle e SQL

Server executando uma carga de trabalho OLTP leve. O storage array PowerMax 2000

pode obter snapshots de bancos de dados rápidos e consistentes com gravação usando

SnapVX. O DBA pode configurar os bancos de dados de snapshot e abri-los para os

negócios. Essa abordagem de clonagem de banco de dados permite que a organização

de TI provisione rapidamente cópias de bancos de dados de produção para teste e

desenvolvimento. No caso de uso de carga de trabalho de banco de dados OLTP do

snapshot, criamos snapshots de um banco de dados Oracle e de um banco de dados

SQL Server a partir do banco de dados OLTP de teste.

Executamos a carga de trabalho de snapshot em paralelo com as cargas de trabalho

OLTP e DSS para mostrar a carga acumulada que foi colocada na infraestrutura do

banco de dados. Como a maioria dos bancos de dados de teste e desenvolvimento gera

uma carga de trabalho mais leve em comparação com os bancos de dados de produção,

configuramos nossa carga de trabalho OLTP do banco de dados de snapshot com

recursos de baixo nível e perfis de carga em comparação aos dois casos de uso

anteriores.

Table 5. Configuração de benchmark tipo TPC-C para o caso de uso de banco de dados de snapshot

Parâmetro tipo TPC-C do HammerDB



10.000 15.000 25.000


1 1,5 2,5

Número de usuários 25 25 50

Duração do teste (minutos) 30 30



Níveis de serviço do PowerMaxOS

O sistema operacional de armazenamento do PowerMax, o PowerMaxOS, usa o nível de

serviço que está associado a cada grupo de armazenamento para manter o desempenho

do sistema. Cada nível de serviço corresponde a um tempo de resposta de destino, que é

o tempo médio de resposta esperado para o grupo de armazenamento com base no nível

de serviço selecionado.

O PowerMaxOS define os seguintes níveis de serviço:

Diamante

Platinum

Ouro

Prata

Bronze

Otimizado (padrão)

Em nossos cenários de caso de uso, atribuímos diferentes níveis de serviço para atingir

a faixa essencial de desempenho das cargas de trabalho OLTP e DSS:

Atribuímos o nível de Diamante ao grupo de armazenamento de OLTP porque os

aplicativos OLTP exigem uma resposta imediata para cada operação de E/S.

Atribuímos o nível Bronze ao grupo de armazenamento de DSS, que tem um

requisito menos rígido de tempos de resposta.

A tabela a seguir mostra os níveis de serviço que estão associados aos três testes de

caso de uso que realizamos:

Table 6. Níveis de serviço do PowerMaxOS implementados nos três casos de uso

Caso de uso Nível de serviço do PowerMax

Cargas de trabalho OLTP Diamante

Carga de trabalho DSS Bronze

Carga de trabalho OLTP de snapshot Diamante

Usamos o Dell EMC Live Optics para coletar dados e validar os testes de caso de uso

que estão descritos neste documento. O Live Optics é um software gratuito e sem agente

usado para coletar dados de servidores PowerEdge. Em questão de minutos, qualquer

usuário pode configurar o Live Optics para coletar uma ampla variedade de informações

para fins de análise de utilização de recursos e configuração. O painel de indicadores

intuitivo do Live Optics permite que os DBAs monitorem e coletem dados em todas as

camadas de virtualização de servidor e VMware.

A figura a seguir mostra um painel de indicadores do Live Optics. O lado esquerdo mostra

o desempenho nos níveis de projeto, hypervisor, servidor virtual e disco compartilhado.

O lado direito mostra os dados coletados e os gráficos que podem ajudar com uma

análise visual rápida.

Dell EMC Live

Optics para

coleta de dados




Figure 2. Painel de indicadores do Live Optics

Usamos o Live Optics durante o teste de validação para reunir os dados mostrados em

tabelas e gráficos ao longo deste guia. A tabela a seguir lista a fonte de dados de cada

medição de desempenho em nossos testes de validação.

Table 7. Fontes de medição de desempenho

Medição de desempenho Fonte (relatório)

Utilização da CPU Dstat

TPM HammerDB

NOPM HammerDB

IOPS Unisphere

Latência de armazenamento em milissegundos Unisphere

Throughput em megabytes por segundo Unisphere

Capítulo 4: Validação dos resultados dos testes


Capítulo 4 Validação dos resultados dos testes


Visão geral ......................................................................................................... 25

Utilização média da CPU .................................................................................. 25

TPM .................................................................................................................... 27

NOPM ................................................................................................................. 31

IOPS de armazenamento .................................................................................. 33

Latência de armazenamento ............................................................................ 36

Throughput ........................................................................................................ 39

Desempenho combinado de IOPS, latência e throughput ............................. 40




Visão geral

Neste capítulo, analisamos cada resultado dos testes em sua totalidade. Cada seção

fornece medições de desempenho de todos os três casos de uso para mostrar o

desempenho das cargas de trabalho na solução em termos de cada medição de

desempenho.

Combinamos as medições de SQL Server e Oracle em um gráfico, sempre que possível,

para mostrar o impacto da carga de trabalho no sistema. Essas informações são

importantes porque nossos testes de validação incrementais aumentam em

complexidade e carga no sistema para todos os casos de uso.

Utilização média da CPU

O teste do caso de uso de OLTP demonstra dois bancos de dados SQL Server e um

banco de dados Oracle em execução no sistema sem nenhuma outra carga de trabalho.

Esse é o teste de linha de base, e usamos os resultados para entender se a utilização

média da CPU nos servidores MX840c é afetada quando a carga computacional aumenta

nos testes subsequentes. Coletamos as medições de utilização média da CPU usando

Linux dstat. Cada VM do SQL Server tinha uma reserva de 6 vCPUs, e a VM do Oracle

tinha uma reserva de 10 vCPUs. A figura a seguir mostra a utilização média da CPU:

Figure 3. Utilização média da CPU durante o teste de 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



O teste do caso de uso de DSS adiciona uma carga de trabalho ao sistema que analisa

grandes conjuntos de dados usando consultas complexas para fornecer relatórios de

lógica analítica de negócios. Cada VM do SQL Server do DSS tinha uma reserva de 8

vCPUs, e a VM do Oracle tinha uma reserva de 8 vCPUs. A figura a seguir mostra a

utilização média da CPU para as cargas de trabalho OLTP e DSS:

Figure 4. Utilização média da CPU para dois casos de uso

No teste de caso de uso de OLTP de snapshot, criamos snapshots do PowerMax

SnapVX e realocamos cópias de nossos bancos de dados OLTP de produção para uma

carga de trabalho OLTP leve. A VM do SQL Server de snapshot tinha uma reserva de 4

vCPUs, e a VM do Oracle de snapshot tinha uma reserva de 6 vCPUs.

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

Oracle

OLT

PD

SS




Figure 5. Utilização média da CPU em todos os três casos de uso

Os aumentos nas cargas de trabalho tiveram um impacto secundário sobre a utilização

da CPU. Por exemplo, no teste do caso de uso de OLTP de linha de base, a utilização

média da CPU do banco de dados do SQL Server era de 67% (consulte a Figura 3). Com

todos os três casos de uso de carga de trabalho (OLTP, DSS e OLTP de snapshot)

sendo executados em paralelo, a utilização média da CPU foi de apenas 64%, como

mostrado na Figura 5, com um impacto mínimo de 3 pontos percentuais. Essa redução

da utilização da CPU ocorreu devido à redução do manuseio de IOPS no caso de carga

de trabalho mista, em comparação com a que está no caso de linha de base. Pequenas

mudanças na utilização da CPU, apesar das adições de carga de trabalho, comprovam

que o sistema de carga de trabalho mista oferece desempenho consistente.

TPM

No benchmark de entrada de ordem tipo TPC-C, TPM indica o número total de

transações por minuto para o banco de dados. Isso significa que o TPM inclui transações

do benchmark tipo TPC-C e outras transações no banco de dados. Por exemplo, o TPM

inclui tanto confirmações quanto reversões. O TPM não é uma medida que podemos usar

para comparar o desempenho do banco de dados, pois os bancos de dados

implementam o monitoramento de transações de maneira diferente. Como o TPM é

extraído de tabelas baseadas em memória no banco de dados, ele não tem impacto

sobre o desempenho do benchmark.

A figura a seguir mostra o TPM no teste do caso de uso de OLTP de linha de base.

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



Figure 6. TPM de linha de base para bancos de dados OLTP

Como nenhuma outra carga de trabalho estava em execução no sistema, a expectativa é

que esses valores de TPM para os bancos de dados SQL Server OLTP e o banco de

dados Oracle sejam os mais altos possíveis. Quando adicionamos a carga de trabalho

DSS, esses valores de TPM mostram uma queda secundária desses valores máximos.

No teste do caso de uso de DSS, o objetivo era determinar o impacto que a carga de

trabalho DSS teria nas medições de TPM para os bancos de dados OLTP. A figura a

seguir mostra o TPM da linha de base com bancos de dados OLTP e a carga de trabalho

DSS em execução em 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

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 7. TPM de bancos de dados OLTP de linha de base com carga de trabalho DSS em execução em paralelo

A carga de trabalho DSS em execução em paralelo com os bancos de dados OLTP teve

impacto no TPM dos bancos de dados SQL Server e Oracle de linha de base:

SQL Server OLTP 1 atingiu 152.600 TPM — uma diferença de 10.782 do valor

máximo de 163.382 do caso de uso de OLTP.

SQL Server OLTP 2 atingiu 152.458 TPM — uma diferença de 12.277 do valor

máximo de 164.735 do caso de uso de OLTP.

Oracle OLTP atingiu 456.420 TPM — uma diferença de 64.698 do valor máximo de

521.118 do caso de uso de OLTP.

Os clientes precisam saber se a criação de um snapshot de um banco de dados que usa

PowerMax SnapVX afetará o desempenho da produção. Executamos os bancos de

dados de snapshot com uma carga de trabalho OLTP leve usandoo benchmark tipo TPC-

C para analisar o impacto nos bancos de dados OLTP da linha de base. A figura a seguir

mostra os resultados do TPM de todos os três casos de uso:

Somente carga de trabalho OLTP de linha de base

OLTP + cargas de trabalho DSS

OLTP + DSS + cargas de trabalho de snapshot (SNAP)

A figura também mostra como o aumento das cargas de trabalho de cada caso de uso

incremental afetou o desempenho do TPM dos bancos de dados OLTP de linha de base.

Figure 8. Resultados do TPM com todas as três cargas de trabalho de caso de uso executadas em paralelo

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



No teste final do caso de uso, adicionar a carga de trabalho do banco de dados de

snapshot sobre as cargas de trabalho OLTP e DSS teve bem pouco impacto sobre o

desempenho do TPM do OLTP de linha de base:

SQL Server OLTP 1 atingiu 157.536 TPM — uma diferença de 5.846 ou 4% do

valor máximo de 163.382.

SQL Server OLTP 2 atingiu 155.197 TPM — uma diferença de 9.538 ou 6% do

valor máximo de 164.735.

Oracle OLTP atingiu 521.118 TPM — igual ao valor máximo de 521.118 da linha de

base.

Durante esse teste final do caso de uso, os bancos de dados OLTP de snapshot

executaram uma carga de trabalho leve tipo TPC-C e obtiveram os seguintes níveis

de TPM:

12.348 TPM para snapshots do SQL Server

24.340 TPM para snapshots do Oracle

Na maioria dos ambientes de cargas de trabalho mistas, variações secundárias no

desempenho ocorrem diariamente, mas o principal fator de sucesso é a consistência

geral do desempenho. Por exemplo, o banco de dados Oracle mostrou a queda

mais significativa no TPM com a carga de trabalho DSS em execução. No entanto,

o desempenho do banco de dados Oracle no terceiro teste foi igual ao desempenho no

teste de linha de base de OLTP. Pequenas alterações no desempenho são esperadas,

mas essa arquitetura de referência para cargas de trabalho mistas demonstrou um

desempenho consistente em todos os testes.




NOPM

NOPM é uma medição consultada a partir da tabela de distritos no início e no final do

benchmark tipo TPC-C. Algumas restrições se qualificam se uma transação de NOPM

pode ser reconhecida e contada. Por exemplo, as transações de nova ordem, pagamento

e status da ordem devem ter um tempo de resposta de cinco segundos ou menos para

serem contadas na medição do NOPM.

Neste guia, examinaremos o NOPM porque ele tem valor para o cliente. O NOPM indica

a rapidez com que um banco de dados pode processar transações entre bancos de

dados e infraestruturas diferentes. No contexto desses testes de validação, as medições

do NOPM se aplicam a um storage array corporativo de nível básico, como o PowerMax

2000.

A figura a seguir mostra as medições do NOPM no teste de linha de base do caso de uso

de OLTP.

Figure 9. Resultados do NOPM para o teste de linha de base do caso de uso de OLTP

Configuramos os dois bancos de dados SQL Server OLTP de modo idêntico para o teste tipo

TPC-C, portanto o desempenho deles está muito próximo em termos de NOPM. O banco de

dados Oracle OLTP tinha mais 4 vCPUs e 48 GB de memória alocada para o banco de

dados; portanto, sua pontuação de NOPM é maior.

O teste de DSS não envolve a execução de transações de entrada de ordem. Portanto,

examinamos como essa carga de trabalho afeta o NOPM para os bancos de dados

OLTP. A figura a seguir mostra as medições do NOPM para os testes de OLTP e DSS

em execução em paralelo:



Figure 10. NOPM para carga de trabalho OLTP com carga de trabalho DSS em execução em paralelo

Os dois bancos de dados SQL Server OLTP mostraram uma pequena perda no NOPM:

SQL Server OLTP 1 atingiu 25.115 TPM — uma diferença de 1.740 do primeiro

teste de OLTP.

SQL Server OLTP 2 atingiu 24.989 TPM — uma diferença de 2.125 do primeiro

teste de OLTP.

O valor de NOPM do banco de dados Oracle OLTP mostrou uma melhoria de

desempenho quando a carga de trabalho DSS era executada em paralelo. O banco

de dados Oracle atingiu 162.246 NOPMs — um ganho de 2.605.

Os bancos de dados OLTP de snapshot simulam a atividade de teste e desenvolvimento

executando uma carga de trabalho OLTP leve no sistema. A figura a seguir mostra os

resultados:

Figure 11. NOPM com cargas de trabalho OLTP, DSS e OLTP de snapshot executadas em 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




Com todas as cargas de trabalho em execução em paralelo, os bancos de dados OLTP

SQL Server mostram uma diferença positiva de desempenho:

SQL Server OLTP 1 atingiu 25.930 NOPM — um ganho de 815 em relação ao

teste anterior.

SQL Server OLTP 2 atingiu 25.513 NOPM — um ganho de 524 em relação ao

teste anterior.

O banco de dados OLTP Oracle mostrou uma pequena perda de 2.605 NOPM em

relação ao teste anterior. (Coincidentemente, esse valor de NOPM corresponde ao

do primeiro teste.)

Os dois bancos de dados de snapshot em que executamos uma carga de trabalho OLTP

leve geraram os seguintes resultados de NOPM:

O banco de dados de snapshot SQL Server atingiu 1.937 NOPM.

O banco de dados Oracle de snapshot atingiu 1.556 NOPM.

Em termos de NOPM, os servidores MX840c e o array PowerMax 2000 mostraram um

desempenho consistente. Ocorreram flutuações secundárias, positivas e negativas, mas

elas não indicaram nenhum impacto significativo no desempenho. Em geral, a arquitetura

de referência de cargas de trabalho mistas demonstrou o desempenho consistente que

é necessário para a consolidação de bancos de dados e de cargas de trabalho.

IOPS de armazenamento

O número de IOPS demonstra a carga em um sistema de armazenamento. Inovações

como SSDs e unidades flash NVMe aumentaram as densidades de IOPS, permitindo que

os storage arrays deem suporte a mais bancos de dados e a uma maior diversidade de

cargas de trabalho.

Nós estruturamos os testes incrementais para esta solução, de modo que, em termos de

carga de armazenamento, a carga de trabalho de IOPS mais intensiva — os bancos de

dados OLTP — fosse a primeira a ser testada. Todas as outras cargas de trabalho

incrementais teriam um impacto mínimo sobre os bancos de dados OLTP. Uma pequena

perda na IOPS não representa um impacto significativo no desempenho do banco de

dados.

Os resultados do teste do caso de uso de OLTP mostram que os bancos de dados SQL

Server OLTP 1 e 2 geraram 16.627 e 17.304 IOPS, respectivamente, no storage array

PowerMax 2000, e o banco de dados Oracle único gerou 42.145 IOPS. Como esses três

bancos de dados têm toda a infraestrutura dedicada ao desempenho durante o primeiro

teste, a expectativa era que esses de valores IOPS fossem o máximo alcançado durante

os testes.

A tabela a seguir resume as IOPS de cada banco de dados OLTP:

Table 8. IOPS de bancos de dados OLTP

Carga de trabalho

Banco de dados IOPS

OLTP SQL Server 1 17,304



Carga de trabalho

Banco de dados IOPS

SQL Server 2 16,627

Oracle 42,145

Total 76,076

A adição de cargas de trabalho DSS coloca uma carga adicional de IOPS nos storage

arrays. No entanto, também devemos considerar o tamanho médio da E/S de leitura

e da E/S de gravação. A tabela a seguir mostra o tamanho médio de E/S de leitura

e o tamanho de E/S de gravação para cada um dos bancos de dados:

Table 9. Média de tamanhos de E/S de leitura e gravação para cada banco de dados nas cargas de trabalho OLTP e DSS

Banco de dados DSS Tamanho de E/S de leitura (KB)

Tamanho de E/S de gravação (KB)

SQL Server 1 180.17 64.2

SQL Server 2 157.97 63.99

Oracle 127.82 184.70

Banco de dados OLTP Tamanho de E/S de leitura (KB)

Tamanho de E/S de gravação (KB)

SQL Server 1 12.95 8.90

SQL Server 2 13.04 8.98

Oracle 10.48 10.94

Embora os números de IOPS para as cargas de trabalho DSS pareçam baixos em

comparação com os números de IOPS para os bancos de dados OLTP, os tamanhos

maiores de E/S de leitura/gravação significam que mais dados são transferidos para cada

operação de armazenamento. Portanto, no caso de DSS, o número de IOPS é menor do

que de OLTP, mas a carga no storage array é significativa, pois os dados transferidos

são maiores. Portanto, o desempenho da carga de trabalho DSS, em geral, é medido em

termos de throughput capturado como MB/s em vez de IOPS.

A tabela a seguir resume os números de IOPS para as cargas de trabalho OLTP e DSS:

Table 10. IOPS para cargas de trabalho OLTP e DSS

Carga de trabalho

Bases de dados IOPS


SQL Server 2 16,410

Oracle 40,387

DSS SQL Server 1 6,783

SQL Server 2 6,720

Oracle 13,842




Carga de trabalho

Bases de dados IOPS

Total 100,559

Comparando os números de IOPS das duas cargas de trabalho de banco de dados

OLTP, ocorreu uma pequena perda de 3,5% em IOPS quando adicionamos a carga de

trabalho DSS. Conforme esperado e adequado, colocar mais carga em um storage array

tem um pequeno impacto nas cargas de trabalho de banco de dados. O ponto-chave é

que o desempenho permanece em um intervalo que atenda ao Acordo de Nível de

Serviço dos negócios.

As cargas de trabalho de banco de dados OLTP de snapshot representam os bancos

de dados de teste e desenvolvimento. A tabela a seguir mostra os resultados de IOPS

de todos os três bancos de dados com casos de uso de carga de trabalho mista em

execução em paralelo:

Table 11. Resultados de IOPS com todos os três casos de uso de cargas de trabalho executadas em paralelo

Carga de trabalho Banco de dados IOPS


SQL Server 2 16,177

Oracle 42,234

DSS SQL Server 1 6,375

SQL Server 2 7,587

Oracle 13,688

Snapshot OLTP SQL Server 1 1,332

Oracle 3,103

Total 106,139

Comparando a nova combinação de cargas de trabalho com a combinação anterior,

ocorreu uma pequena perda de cerca de 4% em IOPS dos bancos de dados OLTP

quando a carga de trabalho aumentou. Os resultados do teste mostram que quando

a carga de trabalho aumentava no array PowerMax, o desempenho de IOPS permanecia

estável (consulte a Tabela 8, Tabela 10 e a Tabela 11). O recurso do storage array de

sustentar o desempenho de IOPS conforme a carga de trabalho aumentava demonstra

a força da plataforma PowerMax para consolidação de cargas de trabalho e bancos de

dados mistos.

O mapa de árvore na figura a seguir mostra a distribuição de IOPS para cada banco de

dados em todos os três casos de uso de carga de trabalho em execução em paralelo.

Conforme indicado pelos blocos azuis, dos três bancos de dados OLTP, o Oracle gerou

o maior número de IOPS, enquanto os dois bancos de dados SQL Server geraram IOPS

com variação de 15.643 a 16.177. Os blocos laranja representam a adição dos bancos

de dados DSS, e os blocos cinza representam a adição do banco de dados OLTP de

snapshot.



Figure 12. Mapa de árvore de IOPS com base nos resultados do teste para os três casos de uso de carga de trabalho

Latência de armazenamento

A latência de armazenamento é o tempo que um storage array leva para concluir uma

solicitação de leitura ou reconhecer uma gravação no banco de dados. As inovações na

mídia de armazenamento impulsionaram uma latência de armazenamento mais baixa.

Por exemplo, antes dos SSDs flash, as latências de armazenamento normalmente eram

medidas em milissegundos. As unidades flash, que geraram latências abaixo de 1 ms,

representaram um avanço significativo. As unidades NVMe oferecem maior eficácia,

reduzindo ainda mais as latências para leituras e gravações. A meta geral para do teste

dessa arquitetura de referência era que todas as latências de armazenamento médias

fossem de 1 ms ou menos para leituras e gravações.

Para cargas de trabalho OLTP, as leituras físicas do armazenamento geralmente são

operações de E/S de blocks reduzidos. O desempenho do banco de dados e do aplicativo

depende de como os dados podem ser lidos a partir do armazenamento. Assim, quanto

menor a latência de leitura, mais rápido os usuários de aplicativos podem acessar dados

críticos. Os bancos de dados SQL Server e Oracle, em geral, executam milhares ou

milhões de leituras por hora, dependendo da carga de negócios. No teste de validação de

linha de base de OLTP, esperávamos que os bancos de dados SQL Server e Oracle

demonstrassem a menor latência testada, pois não havia outras cargas de trabalho no

array PowerMax 2000 durante o teste. As tabelas a seguir mostram as latências médias

de leitura e gravação para a carga de trabalho OLTP:




Table 12. Média de latência de leitura para a carga de trabalho OLTP

Table 13. Média de latências de gravação para a carga de trabalho OLTP

Carga de trabalho

Banco de dados Média de latências de gravação (ms)

LUNs de dados LUNs de registros

OLTP SQL Server 1 0,20 18.

SQL Server 2 0,20 16.

Oracle 0,35 0,64

A latência média de leitura das LUNs de dados e registro para os bancos de dados SQL

Server e o banco de dados Oracle permaneceu em 0,5 ms. A latência média de gravação

das LUNs de dados e registro foi menos de 0,4 ms, exceto para as LUNs de registro de

Oracle com uma média de 0,64 ms. Algumas latências médias excepcionalmente baixas

se destacaram durante os testes:

As latências médias de leitura dos bancos de dados SQL Server e Oracle nas

LUNs de registro foram de 0,29 ms ou menos.

As latências médias de gravação dos bancos de dados SQL Server nas LUNs de

dados foram de 0,2 ms ou menos.

As latências médias de gravação dos bancos de dados SQL Server nas LUNs de

registro foram de 0,18 ms ou menos.

No teste do caso de uso de DSS, o throughput é a principal medição de desempenho,

pois o banco de dados estava examinando grandes tabelas e solicitando grandes blocks

de dados do array PowerMax 2000. As tabelas a seguir documentam os resultados de

nossos testes, mostrando o impacto da carga de trabalho DSS adicionada nas latências

das cargas de trabalho OLTP de linha de base.

Table 14. Média de latência de leitura para a carga de trabalho OLTP com a carga de trabalho DSS em execução em paralelo

Carga de trabalho

Banco de dados Média de latências de leitura (ms)


OLTP SQL Server 1 0,47 21.

SQL Server 2 0,47 0,23

Oracle 0,47 0,29

Carga de trabalho



OLTP SQL Server 1 0,79 0,27


Oracle 0,60 0,47



Table 15. Média de latência de gravação para a carga de trabalho OLTP com a carga de trabalho DSS em execução em paralelo

Carga de trabalho

Banco de dados Média de latências de gravação (ms)



SQL Server 2 0,23 19.

Oracle 0,31 0,69

A adição da carga de trabalho DSS causou o aumento das latências médias de leitura,

mas isso era esperado porque a carga no array aumentou. Todas as latências médias de

leitura permaneceram abaixo da meta de 1 ms.

A adição da carga de trabalho DSS teve um impacto menor nas latências médias de

gravação tanto para dados quanto para registro. As latências médias de gravação

permaneceram consistentemente baixas porque o cache do PowerMax acelera todas as

gravações no armazenamento. Nesse caso, as latências de gravação permaneceram

abaixo de 0,24 ms para todos os bancos de dados SQL Server e, para Oracle,

permaneceram em 0,35 ms para as LUNs de dados e 0,69 para LUNs de registro.

Para o caso de uso final, adicionamos as cargas de trabalho OLTP de snapshot sobre as

cargas de trabalho OLTP e DSS. Os resultados do teste mostram um aumento

secundário nas latências médias de leitura dos dados. Por exemplo, a latência aumentou

em 0,08 ms para LUNs de dados SQL Server e Oracle. As latências médias de leitura

para as LUNs de registro de SQL Server não aumentaram, enquanto a LUN de registro

de Oracle aumentou em 0,08 ms. Para a carga de trabalho OLTP, todas as latências

médias de leitura permaneceram abaixo do objetivo de 1 ms, como mostrado na tabela

a seguir:

Table 16. Média de latência de leitura para cargas de trabalho OLTP e OLTP de snapshot com a carga de trabalho DSS em execução em paralelo

Como mostrado, o banco de dados OLTP SQL Server de snapshot teve uma latência

média de leitura de 1,10 ms para dados, mas, como esse banco de dados estava

simulando um ambiente de teste e desenvolvimento, a meta de latência era menos

crítica. Para o mesmo banco de dados, as latências de registro foram de 0,83 ms, o que

está abaixo da meta de 1 ms.

O banco de dados Oracle OLTP de snapshot mostrou as latências médias de leitura e

gravação de 0,51 ms e 0,26 ms, respectivamente para as LUNs de registro. Além disso,

Carga de trabalho





Oracle 0,68 0,55

Snapshot OLTP SQL Server 1 1,10 0,83

Oracle 0,82 0,51




todas as latências médias de leitura e gravação de Oracle estavam abaixo da meta de

desempenho de 1 ms.

Os resultados desses testes mostram a capacidade do cache do PowerMax de acelerar

a maioria das gravações no storage array. Todas as latências médias de gravação para

SQL Server e Oracle foram de 0,31 ms ou menos de 0,75 ms para as LUNs de registro

de Oracle, como mostrado na tabela a seguir:

Table 17. Média de latências de gravação para as cargas de trabalho OLTP e OLTP de snapshot com a carga de trabalho DSS em execução em paralelo

Carga de trabalho Banco de dados

Média de latências de gravação (ms)

Dados Registro



Oracle 0,31 0,75

Snapshot OLTP SQL Server 1 0,26 0,24

Oracle 0,25 0,26

Durante o teste, surgiu um padrão de latência muito baixa para E/S de gravação no array.

Observamos que as latências de gravação eram consideravelmente menores do que as

latências de leitura. Isso é esperado porque o array PowerMax tem um cache grande que

acelera a E/S e é contrabalançado no armazenamento em cache de todas as solicitações

de gravação. Além disso, todas as gravações no cache do PowerMax são imediatamente

confirmadas de volta para o aplicativo de banco de dados.

Throughput

Além da execução de cargas de trabalho OLTP, executamos uma carga de trabalho DSS

usando o HammerDB TPC-H, como benchmark.

Obs.: o teste "tipo TPC-H" significa que os resultados não são certificados.

O teste de carga de trabalho DSS simula consultas específicas que são projetadas para

ajudar as empresas com a análise de decisões. Além disso, o teste também simula

modificações simultâneas nos dados, em que vários conjuntos de dados são modificados

em paralelo. As consultas são complexas, refletindo que o banco de dados deve juntar-se

a e agregar (filtrar ou agrupar) grandes conjuntos de dados para ajudar os negócios com

a análise de decisões.

Usamos um SF (Scale Factor, fator de escala) de 1.000 para o SQL Server e 3.000 para

testes de Oracle DSS. Ele define o tamanho do banco de dados. Por exemplo, um SF de

1 indica 1 GB. Como usamos um SF de 1.000 em nosso teste, o tamanho do banco de

dados foi de 1.000 GB para SQL e 3.000 GB para Oracle. O SF também define o número

mínimo de fluxos de consulta. Por exemplo, ele especifica um mínimo de sete fluxos de

consulta para um SF de 1.000 e um mínimo de oito fluxos de consulta para um SF de

3.000. Um fluxo de consulta é um conjunto de consultas que devem ser executadas em



série, uma após a outra. No caso de cada banco de dados SQL Server, executamos

apenas um fluxo de consulta e executamos 17 das 22 consultas. Para cada banco de

dados Oracle executamos um fluxo de consulta que executava um subconjunto de

consultas.

Não reunimos as medições formais do tipo TPC-H, como Throughput@Size, porque o

escopo do teste de validação se concentrava apenas no throughput de armazenamento.

Nosso foco na execução da carga de trabalho DSS era gerar throughput no array

PowerMax 2000. Throughput é o volume de dados sustentados transferido conforme

compatível com a infraestrutura.

A tabela a seguir mostra os resultados do teste de throughput que vieram do relatório

de armazenamento do PowerMax para as LUNs de dados de SQL Server e Oracle:

Table 18. Resultados do teste de throughput

Banco de dados DSS

OLTP e DSS em paralelo OLTP, DSS e OLTP de snapshot em paralelo

IOPS MB/s do host

IOPS MB/s do 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 1,712

Os bancos de dados SQL Server e Oracle mostraram throughput e IOPS estáveis ou

aprimorados à medida que a carga de trabalho aumentava e ficava mais complexa.

Portanto, nossos testes comprovam que o nível de throughput melhora com o maior

tamanho e a maior a complexidade da carga de trabalho.

Desempenho combinado de IOPS, latência e throughput

Normalmente, as equipes de TI e DBAs lidam com vantagens e desvantagens entre IOPS

e latência. Por exemplo, quanto maior o número de bancos de dados, mais IOPS no

storage array e maior a latência. Essa compensação entre IOPS e latência acontece ao

longo do tempo. Inicialmente, o desempenho do armazenamento é bom, e os bancos de

dados têm tempos de baixa latência. Com o tempo, mais aplicativos são adicionados ao

array, e a compensação é ponderada em relação à IOPS, o que afeta negativamente

o desempenho do banco de dados e do aplicativo.

Ao testar essa arquitetura com bancos de dados e cargas de trabalho mistos,

consolidamos oito banco de dados (cinco banco de dados SQL Server e três bancos de

dados Oracle) para determinar onde ocorria a compensação entre IOPS e latência no

array PowerMax 2000. Com oito banco de dados em execução em paralelo, geramos um

total de 106.139 IOPS para 24 unidades flash NVMe. A tabela a seguir combina as IOPS,

as latências e os resultados dos testes de throughput para todas as cargas de trabalho

mistas nos testes de validação:




Table 19. IOPS, média de latência de leitura e throughput em todas as cargas de trabalho

Carga de trabalho

Banco de dados IOPS

Média de latências de leitura (ms) Throughput do

host (MB/s) Dados Registro

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

Snapshot OLTP

SQL Server 1 1,332 1,10 0,26

Oracle 3,103 0,83 0,51

Com todas as cargas de trabalho em execução em paralelo, o array PowerMax aceitou

mais de 105.000 IOPS e as latências de leitura médias foram mantidas abaixo de 1 ms

para todos os bancos de dados, exceto o banco de dados OLTP SQL Server 1 de

snapshot. Alocamos o mínimo de memória para os bancos de dados a fim de forçar mais

leituras físicas do armazenamento. Por exemplo, alocamos apenas 8 GB para os bancos

de dados SQL Server. A maioria dos clientes fornecerá mais memória para seus bancos

de dados, portanto, suas latências médias de leitura serão menores.

As latências médias de gravação em todos os casos de uso de carga de trabalho foram

consistentemente baixas com mais de 31 ms. A única exceção é a latência média de

gravação do banco de dados Oracle OLTP, que é 75 ms para a LUN de registro. Todas

as latências médias de gravação ficaram bem abaixo da meta de 1 ms ou menos para

o desempenho de armazenamento, conforme mostrado na tabela a seguir:

Table 20. IOPS, média de latência de gravação e throughput em todas as cargas de trabalho

Carga de trabalho

Banco de dados IOPS

Média de latências de gravação (ms) Throughput do

host (MB/s) Dados Registro

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

Snapshot OLTP

SQL Server 1 1,332 0,26 0,22

Oracle 3,103 0,25 0,26

Nossas descobertas mostram que não há nenhuma compensação entre IOPS e latências

de armazenamento, independentemente da configuração de nível básico do PowerMax



2000 com 24 unidades flash NVMe com suporte a 8 bancos de dados e uma combinação

de cargas de trabalho OLTP e DSS. Os clientes podem ter a certeza de que uma solução

de carga de trabalho mista/banco de dados misto baseada em servidores PowerEdge

MX840c e PowerMax 2000 pode ser dimensionada enquanto oferece um sólido

desempenho de armazenamento.

Capítulo 5: Solução de backup e recuperação Data Domain



Capítulo 5 Solução de backup e recuperação Data Domain


Introdução ......................................................................................................... 44

Solução de backup e recuperação para Oracle .............................................. 44

Solução de backup e recuperação para SQL Server ...................................... 51



Introdução

As infraestruturas de banco de dados armazenam e gerenciam dados essenciais da

empresa. Qualquer tempo de inatividade desses bancos de dados afeta negativamente

a experiência do cliente e dos negócios de diversas maneiras. Portanto, é essencial

fornecer soluções ideais de backup e recuperação que podem lidar com todas as

circunstâncias imprevistas que poderiam paralisar as operações de negócios. Você

também pode usar as soluções de backup e recuperação para criar ambientes de teste

que simulam sistemas de produção para uma variedade de finalidades, como upgrades

e determinação de dimensionamento. A equipe de projeto validado da Dell EMC testou

uma solução de backup e recuperação que pode dar suporte às cargas de trabalho de

banco de dados discutidas neste guia.

Solução de backup e recuperação para Oracle

Tecnologia DD Boost

Durante a operação de backup de banco de dados com o Oracle RMAN, o banco de

dados Oracle envia backups para o sistema Data Domain por meio da rede Ethernet

ou Fibre Channel. Selecionamos o protocolo DD Boost sobre Ethernet para aproveitar

os recursos comprovados de desempenho e desduplicação da tecnologia DD Boost.

Nessa configuração, o recurso DD Boost e o DSP (Distributed Segment Processing,

processamento distribuído de segmentos) são habilitados. O software DD Boost é

executado tanto no servidor de banco de dados Oracle quanto no sistema Data Domain.

Conforme mostrado na figura a seguir, para cada segmento de backup, o software

DD Boost determina se o segmento é exclusivo (ou seja, ele não foi armazenado

anteriormente no sistema Data Domain). Quando o DD Boost confirma que o segmento

é exclusivo, o segmento é compactado e transferido pela rede, depois armazenado no

sistema Data Domain. Os processos de desduplicação e compactação garantem que

apenas dados exclusivos sejam compactados e enviados pela rede, e armazenados no

sistema Data Domain.

Durante o primeiro backup completo do banco de dados, como nenhum dado desse

banco foi armazenado no sistema Data Domain, todos os segmentos de dados do backup

são exclusivos. Como resultado, cada segmento de dados do primeiro backup completo

é compactado, enviado pela rede e armazenado no sistema Data Domain. A partir do

segundo backup completo, o software DD Boost faz backup somente dos segmentos de

dados exclusivos que não foram armazenados anteriormente no sistema Data Domain.

Considerações

do projeto




Figure 13. Software DD Boost determinando se o segmento é exclusivo

Armazenamento e file system

O sistema Data Domain inclui um conjunto de discos para armazenar backups de bancos

de dados. Durante a configuração inicial do Data Domain, atribuímos esses discos aos

grupos de discos a fim de serem usados para criar file systems para armazenar backups

de bancos de dados.

O sistema Data Domain DD9300 usado em nossos testes tem uma unidade principal com

12 discos e quatro compartimentos de disco (DS60) com 60 discos cada. Na unidade

principal, quatro discos são usados como discos do sistema e oito discos são usados

como nível de cache. A partir dos quatro compartimentos de disco, criamos 15 grupos de

discos, cada um com 14 discos mais um disco sobressalente. Cada grupo de discos tem

uma capacidade de armazenamento utilizável de 38,21 TiB. Todos os 15 grupos de

discos oferecem um total de 573,15 TiB de capacidade de armazenamento físico

utilizável que pode ser usada para armazenar as imagens de backup do banco de dados.

Durante o processo de inicialização do sistema Data Domain, habilitamos o file system

executando um comando ativador de file system na linha de comando do sistema Data

Domain. O comando a seguir mostra um exemplo do uso de espaço do file system em

um DD9300.

Figure 14. Exemplo de uso de espaço do file system no DD9300



Mtree e unidade de armazenamento

Criamos uma unidade de armazenamento no sistema Data Domain para usar com o

agente de aplicativos de banco de dados no servidor de banco de dados a fim de fazer

backup dos arquivos, conforme mostrado no seguinte exemplo:

Figure 15. Unidade de armazenamento rman criada no DD9300 para fins de teste de backup

e recuperação

As unidades de armazenamento são exibidas como uma partição lógica do file system

da Mtree:

Figure 16. Unidades de armazenamento vistas como partições lógicas do file system da mtree

Para implementar o recurso de desduplicação otimizada de Oracle em um sistema Data

Domain, definimos o valor da opção app_optimized-compression para

<user_name> na Mtree com este comando:

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

<storage_unit_name>

Por exemplo, executamos esses comandos na linha de comando no sistema Data

Domain para a unidade de armazenamento rman:

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

Projeto de rede IP

O dispositivo Data Domain se conecta ao servidor de banco de dados Oracle dentro do

chassi da infraestrutura MX7000 dessa arquitetura de referência por meio de 4 interfaces

front-end de 10 GbE distribuídas em duas NICs instaladas no sistema DD9300. Essas 4

interfaces front-end de 10 GbE no DD9300 se conectam aos mesmos comutadores spine

aos quais os IOMs de rede do MX9116n no chassi MX7000 se conectam.

Dentro do DD9300, criamos um novo grupo de interface de rede e adicionamos essas

quatro interfaces front-end a esse grupo, como mostrado na figura a seguir. Para que o

servidor de banco de dados Oracle possa se comunicar com o equipamento de backup,

configuramos essas interfaces front-end do DD9300 no mesmo intervalo de endereços de

rede IP que os endereços IP de rede pública do banco de dados Oracle.




Figure 17. DD9300: Configuração da rede IP usando grupos de interface

Obs.: em Protocols -> DD Boost -> IP Network como mostrado acima, adicionamos o

hostname do banco de dados Oracle em Configured Clients e garantimos que ele usasse o

grupo de interface de 10 GbE que criamos.

Para registrar e conectar o servidor de banco de dados como um client com o sistema

Data Domain, selecionamos o endereço IP estático atribuído a uma das interfaces no

Data Domain. Ao habilitar internamente o balanceamento de carga e o recurso de failover

entre as interfaces de rede configuradas em um grupo, a configuração do grupo de

interface forneceu uma largura de banda de rede robusta e uma rede de backup

altamente disponível entre os servidores de banco de dados e o sistema Data Domain.

Parâmetros de backup e restauração do RMAN

Para testar o backup e a recuperação, usamos o Caso de uso 1 - configuração de banco

de dados Oracle OLTP descrita no Capítulo 3 Objetivos do teste de validação,

configuração e casos de uso. Usamos as seguintes configurações do Oracle RMAN em

nossos testes de backup e restauração do banco de dados Oracle OLTP.

Table 21. Configurações do Oracle RMAN

Operação Parâmetro Configuração

Backup do banco de dados Oracle OLTP

PARALLELISM 8


SECTION SIZE

4 GB


BLKSIZE 1,048,576

Recuperação do banco de dados Oracle OLTP

PARALLELISM 32

Recuperação do banco de dados Oracle OLTP

BLKSIZE 1,048,576

Realizamos vários testes de backup e recuperação no sistema DD9300 usando o Caso

de uso 1 - configuração de banco de dados Oracle OLTP descrita no Capítulo 3 Objetivos

do teste de validação, configuração e casos de uso. As descrições a seguir fornecem os

detalhes de três casos de teste de backup e recuperação ou casos de uso que foram

realizados nesta arquitetura de referência.

Metodologia

de teste e

resultados



Caso de uso 1: Primeiro backup completo do banco de dados OLTP independente

Realizamos um backup completo de um banco de dados Oracle de 1,8 TB usando o

software DD Boost. O DD Boost integra-se ao RMAN e permite a desduplicação baseada

em host dos backups de banco de dados para o equipamento Data Domain. Um backup

completo elimina a dependência de outros backups, simplificando o gerenciamento

e a restauração de backups após uma falha não planejada.

Nesse caso de uso, usamos o equipamento DD Boost para executar o primeiro backup

completo do banco de dados de produção. Na configuração testada, usamos uma

conexão de LAN 4 x 10 GbE com o DD9300, conforme mostrado na figura a seguir.

Figure 18. Caso de uso 1: Diagrama de arquitetura do primeiro backup completo

O primeiro backup completo de um banco de dados Oracle é totalmente exclusivo;

portanto, todos os dados são protegidos no DD9300. O valor da desduplicação baseada

em host começa com o segundo backup completo. No segundo backup, somente os

dados novos ou modificados são exclusivos; portanto, o software DD Boost envia apenas

um subconjunto reduzido de informações para o sistema Data Domain para fins de

proteção. Embora o primeiro backup completo seja exclusivo, depois que os dados são

protegidos no Data Domain, eles são compactados.

A figura a seguir mostra a economia de fator de compactação local com base no

algoritmo padrão (throughput maximizado) no sistema Data Domain. Existe uma relação

entre o volume de dados exclusivos e o fator de compactação local: quanto maior o

volume de dados exclusivos, mais oportunidade de compactação e maior o fator de

compactação. Por exemplo, o primeiro backup consiste em dados inteiramente exclusivos

e tem o maior fator de compactação.




Figure 19. Taxa de compactação do primeiro backup completo

Essa compactação economiza um espaço significativo no sistema Data Domain. Os

resultados do teste de engenharia da Dell EMC mostram que o fator de compactação foi

de 1,4x: uma economia de 29,9% de espaço para o primeiro backup completo. A

configuração da arquitetura de referência obteve esse backup completo de 1,8 TB e a

compactação em 38 minutos, apresentando um throughput de backup de 815 MB/s.

Caso de uso 2: Segundo backup completo do banco de dados OLTP independente

O objetivo desse caso de uso era executar um segundo backup completo do mesmo

banco de dados Oracle para mostrar o valor da desduplicação baseada em host do DD

Boost. A desduplicação baseada em host significa que o software DD Boost se comunica

com o sistema Data Domain para determinar se um bloco de dados é exclusivo. Se for

exclusivo, ele será enviado ao sistema Data Domain para proteção. Se não for exclusivo,

ele não será enviado ao Data Domain. O valor da desduplicação baseada em host é que

ela poupa a utilização da rede e o espaço no dispositivo Data Domain. A tecnologia DD

Boost funciona de modo transparente com o RMAN, o que significa que o RMAN vê um

backup completo do banco de dados no DD9300.

Antes de executar o segundo backup completo, modificamos os dados existentes

realizando algumas transações. Para simular condições reais, usamos o HammerDB

e executamos transações de OLTP por 10 minutos para criar dados aproximadamente

5% modificados. Esses dados modificados consistiram em 1% de inserções e 4% de

atualizações para garantir que o software DD Boost fizesse backup de dados novos

e modificados.

A figura a seguir mostra a arquitetura do caso de uso 2.



Figure 20. Caso de uso 2: Segundo backup completo com 5% de modificação de dados

A figura a seguir mostra a economia de fator de compactação local derivada do algoritmo

padrão (throughput maximizado) no sistema Data Domain para o segundo backup

completo. Os testes mostram que apenas dados exclusivos foram enviados para o Data

Domain e, depois da compactação local, o tamanho final era de 109 GB. A desduplicação

baseada em host do DD Boost combinada com a compactação local no Data Domain

economiza uma quantidade significativa de espaço. A execução de backups completos

diários é fácil, pois o espaço usado no sistema Data Domain é um pequeno subconjunto

do tamanho real do banco de dados.

Figure 21. Taxa de compactação do segundo backup completo

A compactação e a desduplicação economizam espaço significativo no DD9300.

Os resultados do teste de engenharia da Dell EMC mostram que o fator de compactação

foi de 16,7x: uma economia de 94% de espaço para o segundo backup completo.

O segundo backup completo demorou muito menos tempo em comparação com

o primeiro. O segundo backup completo de um banco de dados Oracle de 1,8 TB levou

apenas 25 minutos, 13 minutos menos do que o primeiro backup completo (38 minutos)

e apresentou throughput de backup de 1.191 MB/s. É importante que o tempo necessário

para backups de bancos de dados permaneça previsível e minimizado para reduzir

o impacto para os negócios.




Caso de uso 3: Restauração e recuperação do banco de dados OLTP a partir do backup completo

As falhas não planejadas podem representar um risco significativo para os negócios

devido à interrupção das operações de back-office, afetando a receita. Fazer backup

e proteger bancos de dados prepara a empresa para recuperar-se de uma falha não

planejada. Nesse teste, realizamos uma restauração a partir do sistema Data Domain que

teve backup nos servidores de banco de dados Oracle. O objetivo desse caso de uso era

testar a rapidez e a forma com que essa arquitetura de referência pode restaurar

e recuperar um banco de dados Oracle de 1,8 TB que foi protegido usando o sistema

Data Domain.

A figura a seguir mostra a arquitetura do caso de uso 3:

Figure 22. Caso de uso 3: Restaurar o diagrama da arquitetura de banco de dados com backup completo

Nesse caso de uso, o tempo total capturado inclui:

O tempo necessário para "restaurar", que inclui cópia dos arquivos do banco de

dados com backup completo do DD9300 de volta para o banco de dados Oracle

primário e

O tempo necessário para "recuperar", que inclui a aplicação de redo logs

arquivados e on-line sobre os dados restaurados usando o RMAN e abrindo

o banco de dados para processamento.

Nesse teste, nosso banco de dados Oracle de 1,8 TB foi totalmente restaurado

e recuperado com sucesso a partir de um backup em 25 minutos com apenas

15% de utilização média da CPU no servidor de banco de dados Oracle.

Solução de backup e recuperação para SQL Server

O agente DDBEA (Data Domain Boost for Enterprise Applications) integra-se ao utilitário

de gerenciamento nativo de aplicativos e permite backups e restaurações eficientes entre

o host de aplicativos e o DD9300 usando o protocolo DD Boost. O agente DDBEA para

SQL Server no Windows é compatível e está disponível para download. Se tiver mais

dúvidas, entre em contato com seu representante de conta 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

Capítulo 6: Conclusões a partir dos resultados dos testes


Capítulo 6 Conclusões a partir dos resultados dos testes


Desempenho em escala .................................................................................... 53

Resultados de desempenho do PowerEdge MX840c ..................................... 53

Resultados de desempenho do PowerMax 2000 ............................................ 53

Resultados de backup e recuperação do Data Domain ................................. 54

Resumo dos resultados .................................................................................... 54

Para obter mais informações ........................................................................... 55




Desempenho em escala

Esse sistema de banco de dados misto/de carga de trabalho mista, que usa dois

servidores PowerEdge MX840c e um storage array PowerMax 2000 de nível básico com

24 unidades flash NVMe, é uma solução avançada e econômica. O sistema forneceu

mais de 105.000 IOPS com latências inferiores a 1 ms. A configuração do PowerMax

pode ser dimensionada para 96 unidades flash NVMe, que é quatro vezes maior do que

a configuração que usamos em nossos testes.

Resultados de desempenho do PowerEdge MX840c

Os destaques de desempenho do chassi modular PowerEdge MX7000 com servidores

MX840c:

Um servidor MX840c foi dedicado a bancos de dados Oracle. Dos 160

processadores lógicos que estavam disponíveis, os três bancos de dados Oracle

usaram 24 núcleos ou 15% dos recursos computacionais. Assim, 85% ou 136

núcleos estavam disponíveis para consolidação de banco de dados adicional.

O servidor MX840c, que foi dedicado a SQL Server tinha 160 processadores

lógicos. Dos processadores disponíveis, os cinco bancos de dados SQL Server

usavam 32 núcleos ou 20% dos recursos computacionais disponíveis. Isso deixa

128 núcleos ou 80% dos recursos computacionais disponíveis para consolidação

adicional do banco de dados SQL Server.

No servidor MX840c, que foi dedicado ao Oracle, os três bancos de dados usavam

188 GB em reservas de memória. De 1,5 TB de memória disponível, os bancos de

dados usaram 12,5%, deixando 87,5% ou 1.312 GB de memória para consolidação

de banco de dados adicional.

No servidor MX840c, que foi dedicado ao SQL Server, os cinco bancos de dados

usaram um total combinado de 88 GB de memória ou 6%. Isso deixa 1.412 GB ou

94% de memória disponível para consolidação de banco de dados adicional.

Os servidores MX840c forneceram, de maneira consistente, um desempenho rápido

de computação. A utilização da CPU em todos os três testes de VMs do SQL Server

e Oracle permaneceu consistente, sem impactos significativos sobre o desempenho.

Obtivemos os resultados de desempenho documentados neste guia usando

o projeto de rede convergente LAN e SAN MX. Esse projeto tem uma maior

economia em termos de TCO, pois não requer IOMs dedicados de LAN e SAN MX

nem comutadores LAN e SAN top-of-rack.

Resultados de desempenho do PowerMax 2000

Os destaques de desempenho do storage array PowerMax 2000 incluem:

O storage array PowerMax 2000 gerou 106.139 IOPS usando uma pequena

configuração de 24 unidades flash NVMe.

O desempenho de IOPS permaneceu consistente entre o teste de linha de base

e o teste de OLTP com todas as cargas de trabalho em execução. Quando todas

as cargas de trabalho foram executadas em paralelo, a IOPS permaneceu dentro

de 4% da linha de base.



A latência média de leitura para todos os bancos de dados permaneceu abaixo

de 1 ms, com uma exceção: SQL Server OLTP de snapshot 1. Como esse banco

de dados estava simulando uma carga de trabalho de teste e desenvolvimento,

a latência ligeiramente maior não foi significativa para avaliar o desempenho geral.

A latência média de gravação para todos os bancos de dados permaneceu abaixo

de 1 ms. A maioria das latências de gravação estava abaixo de 0,31 ms. A

exceção foi o banco de dados Oracle OLTP com gravações médias de 0,75 ms

para registros (ainda abaixo de 1 ms).

Resultados de backup e recuperação do Data Domain

Durante o primeiro backup completo, o DD Boost compactou um banco de dados

Oracle de 1.810 GB para 1.269 GB em 38 minutos: uma economia de 29,9%.

No segundo backup completo com dados 5% modificados, o DD Boost compactou

ainda mais os dados e armazenou apenas 109 GB no DD9300 em 25 minutos:

uma economia de espaço de 94%.

Um banco de dados Oracle de 1,8 TB foi totalmente restaurado e recuperado com

sucesso em 25 minutos ao usar apenas 15% da capacidade disponível da CPU no

servidor de banco de dados Oracle.

Resumo dos resultados

Os destaques dos resultados do teste de validação incluem:

O TPM permanece consistente conforme o aumento da carga. Os bancos de

dados SQL Server permaneceram dentro de 6% do desempenho do TPM de linha

de base, mesmo com todas as cargas de trabalho em execução em paralelo.

O banco de dados Oracle exibiu o mesmo desempenho de TPM durante o teste de

linha de base e durante os testes com todas as cargas de trabalho em execução.

Não houve nenhuma perda de desempenho resultante da maior carga de trabalho.

O NOPM para os bancos de dados SQL Server permaneceu dentro de 6% do

desempenho do NOPM de linha de base com todas as cargas de trabalho em

execução.

O valor da linha de base do NOPM do Oracle foi igual ao valor de NOPM com

todas as cargas de trabalho em execução em paralelo, o que significa que

nenhuma perda de desempenho ocorreu, mesmo com a carga de trabalho mais

elevada.

O throughput e as IOPS foram correlacionados diretamente: Quando a IOPS ou a

carga de trabalho aumenta, o throughput também aumenta. Em nossos resultados,

observamos que o throughput melhorou com a complexidade dimensionada das

cargas de trabalho mistas. Por exemplo, quando a IOPS (OLTP + DSS) foi 6.720,

o throughput foi de 625 MB/s, e quando a IOPS (OLTP + DSS + SNAP) foi 7.587,

o throughput foi de 714 MB/s.

As cargas de trabalho crescentes não afetam o throughput do banco de dados

Oracle.




Para obter mais informações

Você pode saber mais entrando em contato com seu representante de vendas local da

Dell EMC. A Dell EMC tem especialistas em banco de dados que podem trabalhar com

você para projetar e dimensionar corretamente essa solução de carga de trabalho mista

de banco de dados para sua empresa. Os especialistas em SQL Server e Oracle usam

ferramentas que podem coletar informações de seus sistemas de banco de dados

existentes. Com os dados coletados, os especialistas podem desenvolver com rapidez

e precisão uma solução personalizada de banco de dados misto com base nessa

infraestrutura, descrita neste guia.

Capítulo 7: Referências


Capítulo 7 Referências


Documentação da Dell EMC ............................................................................. 57

Documentação da VMware ............................................................................... 57

Documentação da Oracle ................................................................................. 57

Documentação da Microsoft ............................................................................ 57

Documentação do HammerDB ......................................................................... 57

Capítulo 7: Referências



Documentação da Dell EMC

A documentação e as páginas da Web da Dell EMC a seguir apresentam informações

adicionais e relevantes. O acesso a esses documentos depende de suas credenciais de

log-in. Caso você não tenha acesso a determinado documento, entre em contato com

o representante da Dell EMC.

Dell EMC Ready Solutions for Oracle

Dell EMC Ready Solutions for Microsoft SQL

Armazenamento de dados de NVMe com Dell EMC PowerMax

Dell EMC PowerEdge MX

White paper sobre práticas recomendadas de implementação para o banco de

dados Oracle com o Dell EMC PowerMax

White paper sobre armazenamento do Dell EMC PowerMax para bancos de dados

SQL Server de missão crítica

Guia de conectividade de host da Dell EMC para servidor VMware ESX

Dell EMC Data Domain DD9300 System

Documentação da VMware

As seguinte documentação da VMware especifica informações adicionais e relevantes:

Instalação e configuração do VMware ESXi 6.7

Instalação e configuração do vCenter Server

Oracle Databases on VMware Best Practices Guide

Quickstart: Instalação do SQL Server e criação de um banco de dados no Red Hat

Documentação da Oracle

A documentação da Oracle a seguir apresenta informações adicionais relevantes:

Guia de instalação e upgrade da infraestrutura em grid para Linux

Guia de instalação do banco de dados para Linux

Documentação da Microsoft

A documentação da Microsoft a seguir apresenta informações adicionais relevantes:

Orientação de instalação do SQL Server no Linux

Práticas recomendadas de desempenho e diretrizes de configuração do SQL

Server no Linux.

Noções básicas de disponibilidade do SQL Server para implementações Linux

Documentação do HammerDB

Para obter informações sobre as ferramentas HammerDB, consulte a documentação do HammerDB.

https://www.dellemc.com/pt-br/solutions/business-applications/oracle/index.htm

https://www.dellemc.com/en-sg/solutions/business-applications/sql/index.htm

https://www.dellemc.com/pt-br/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/en-us/servers/modular-infrastructure/poweredge-mx/index.htm#accordion0

https://www.dellemc.com/pt-br/collaterals/unauth/white-papers/products/storage/h17390-deployment-bp-for-oracle-with-powermax-wp.pdf

https://www.dellemc.com/pt-br/collaterals/unauth/white-papers/products/storage/h17390-deployment-bp-for-oracle-with-powermax-wp.pdf

https://www.dellemc.com/pt-br/collaterals/unauth/white-papers/products/storage/h17234-powermax-sql-server-wp.pdf

https://www.dellemc.com/pt-br/collaterals/unauth/white-papers/products/storage/h17234-powermax-sql-server-wp.pdf

https://brazil.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/pt-br/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/pt-br/sql/linux/sql-server-linux-setup?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-performance-best-practices?view=sql-server-2017


https://docs.microsoft.com/pt-br/sql/linux/sql-server-linux-ha-basics?view=sql-server-2017

https://www.hammerdb.com/document.html

https://www.hammerdb.com/document.html

Apêndice A: Solução de hardware e software


Apêndice A Solução de hardware e software

Este apêndice apresenta os seguintes tópicos:

Componentes de hardware .............................................................................. 59

Componentes de software ............................................................................... 61




Componentes de hardware

A arquitetura de referência desta solução inclui os seguintes componentes primários de

hardware:

Chassi modular Dell EMC PowerEdge MX7000 com:

1 SLED de computação do PowerEdge MX840c para um banco de dados

Oracle

1 SLED de computação do PowerEdge MX840c para um banco de dados SQL

Server

2 módulos de E/S do PowerEdge MX9116n para o tráfego convergente de LAN

e SAN

Storage array Dell EMC PowerMax 2000

Equipamento de backup Data Domain DD9300

As tabelas a seguir listam os detalhes dos componentes de hardware, firmware e driver

dos servidores de computação e dos módulos de E/S de rede que usamos na

configuração testada dessa arquitetura de referência.

Table 22. Componentes de computação e rede

Componente Descrição

Chassi modular 1 Chassi modular Dell EMC PowerEdge MX7000

As fontes de alimentação 6 fontes de alimentação redundantes de 3.000 W

Sleds de computação

Hosts ESXi de banco de dados 1 Dell EMC PowerEdge MX840c para o banco de dados de Oracle

1 Dell EMC PowerEdge MX840c para o banco de dados SQL Server

Subcomponentes em cada SLED de computação

Chassi0F0F

1 Chassi de 2,5 pol. com até 8 unidades de disco rígido SAS/SATA/NVMe

Processador 4 processadores dimensionáveis Intel Xeon Gold 6148 20c/40T HT 2,4 GHz

Memória 1.536 GB (24 LRDIMMs QR DDR4 de 64 GB, 2.666 MT/s)

Discos locais no servidor 3 SAS de 1,2 TB e 10.000 SAS, 12 Gb/s 2,5 pol. HDDs (inclui um hot spare)

Controladora RAID PERC H730P MX

iDRAC iDRAC9 Enterprise

1 Outras configurações de chassi são compatíveis.

Componentes

de computação

e rede



Componente Descrição

Placas de E/S para fabrics A/B 4 placas de mezanino ou CNAs QLogic FastLinQ 41262HMKR DP 10/25 GbE com descarregamentos de armazenamento (iSCSI, FCoE)

Módulos de rede ou E/S dentro do chassi modular MX7000

Módulos de E/S (LAN e SAN convergentes) (fabric slots A1 e B1)

2 mecanismos de fabric switch Dell EMC MX9116n 25 GbE, 12 QDD28, 2 Q28, 2 FC Q28/32 Gb

Obs.: versões mais recentes e atualizadas de BIOS e firmware são aceitas, se disponível. Para

obter a versão mais recente, acesse o suporte on-line da Dell EMC.

Table 23. Firmware e drivers dos componentes do PowerEdge MX7000

Componente Firmware/sistema operacional

Driver 1F 1F

2

Nível de chassi modular

Módulo de

gerenciamento

1.00.01 N/D

As fontes de alimentação 00.36.6B N/D

Sleds de computação (aplica-se a ambos os sleds do MX840c)

BIOS 1.6.11 N/D

Lifecycle Controller e iDRAC9 Enterprise

3.20.21.20 N/D

Placa de mezanino ou CNA QLogic FastLinQ 41262HMKR DP 10/25 GbE

14.07.07 3.7.9.2 (driver Ethernet qedentv)

1.2.24.6 (driver FCoE qedf)

PERC H730P MX 25.5.5.0005 7.705.10.00 (lsi-mr3)

Módulos de E/S de rede

MX9116n FSE 10.4.0E.R3S.268 N/D

A tabela a seguir lista os detalhes de hardware do storage array que usamos na

configuração testada desta arquitetura de referência:

Table 24. Componentes do storage array PowerMax 2000

Componente do storage array Detalhes

Versão do sistema operacional PowerMaxOS

Número de bricks 1

2 Uma imagem ISO personalizada pela Dell EMC do VMware ESXi 6.7 U1 (versão Dell: A03, Build

10764712) foi usada para implementar o hypervisor do ESXi. Os drivers de caixa de entrada foram

usados nos sistemas operacionais guest Oracle e SQL RHEL 7.

Storage array

https://support.emc.com/




Componente do storage array Detalhes

Módulos de I/O de front-end 4 FC QP de 16 Gb/s (dois módulos de E/S por director)

Cache por mecanismo 1 TB (512 GB por director)

Número de discos 24 Unidades flash NVMe

Tipo de RAID RAID 5 (7+1)

Capacidade bruta/utilizável 88,69 TB/73,35 TB

A tabela a seguir lista os detalhes de hardware do sistema de backup DD9300 que

usamos na configuração testada desta arquitetura de referência:

Table 25. Componentes do sistema de backup DD9300

Componente do sistema de backup Detalhes

Versão do sistema operacional 6.1.0.1-560996

Número de unidades principais 1 (com 12 discos)

Número de compartimentos (DS60) 4 (com 60 discos em cada um)

Número de adaptadores de rede front-end

2 adaptadores de quatro portas (QP) 10 GbE

Número de portas de rede front-end (em uso)

4 de 10 GbE (duas de cada adaptador QP)

Discos do sistema 3 HDDs SAS de 3,64 TiB + 1 HDD SAS de 3,64 TiB (sobressalente)

Discos de cache 8 SSDs SAS de 0,728 TiB

Discos de nível ativo (em uso) 210 HDD SAS de 2,73 TiB

Discos de nível ativo (sobressalentes) 15 HDD SAS de 2,73 TiB

Componentes de software

A tabela a seguir especifica as versões dos componentes de software da arquitetura de

referência, conforme implementados na configuração testada.

Obs.: a versão do ESXi se aplica tanto aos hosts de banco de dados do servidor ESXi de Oracle

quanto de SQL Server.

Table 26. Componentes de software

Software Versão

Sistemas operacionais do hypervisor VMware ESXi 6.7 U1 [imagem ISO personalizada pela Dell EMC (versão Dell: A03, Build 10764712)]

Sistema de

backup DD9300



Software Versão

Sistemas operacionais guest VM de BD Oracle — Red Hat Enterprise Linux 7.4 kernel 3.10.0-693 x86_64

VM de BD SQL Server — Red Hat Enterprise Linux 7.6 kernel 3.10.0-957 x86_64

Oracle Grid e banco de dados Oracle no Linux Oracle Grid Infrastructure 18c (18.3.0)

Oracle Database 18c (18.3.0) (independente)

Bancos de dados Microsoft SQL Server no Linux

SQL Server 2017 (RTM-CU13)

O Dell EMC Unisphere para PowerMax (inclui coletor de estatísticas do CloudIQ e Database Storage Analyzer incorporados)

9.0.2.7

Dell EMC Live Optics 2.5.16.467045

Agente de aplicativo de banco de dados do DD Boost

4.7.1.0-1

Apêndice B: Detalhes de projeto e configuração



Apêndice B Detalhes de projeto e configuração

Este apêndice apresenta os seguintes tópicos:

Projeto de computação e rede ......................................................................... 64

Configuração de armazenamento do PowerMax ............................................ 71

Configurações do sistema operacional guest e das VMs do Oracle ............... 77

Configurações do sistema operacional guest e das VMs do SQL Server ..... 82



Projeto de computação e rede

Nós instalamos e configuramos os servidores de banco de dados do PowerEdge MX840c

— um para Oracle e outro para SQL Server — com o ESXi 6.7 U1 usando a imagem ISO

personalizada da Dell EMC (versão Dell: A03, Build 10764712). Essa imagem está

disponível no suporte on-line da Dell EMC em VMware ESXi 6.7 U1.

Configuração do adaptador de rede convergente

Nesta solução, o tráfego de LAN e SAN foi convergido nos servidores blade por meio

de quatro CNAs de 25 GbE e duas portas QLogic QL41262. Esses CNAs dão suporte

a vários protocolos de tráfego de rede (Ethernet, descarregamento de FCoE e iSCSI)

e fornecem muita largura de banda para dar suporte a várias funcionalidades de rede

LAN e SAN nessa solução. Nós particionamos esses CNAs usando NPAR, o recurso

de particionamento de rede do adaptador, que nos permitiu usar a grande largura de

banda de rede combinada disponível nos CNAs e, ao mesmo tempo, fornecer alta

disponibilidade. Nós particionamos os CNAs nos hosts Oracle e SQL Server com as

seguintes funcionalidades e atribuições de largura de banda:

Table 27. Configuração do CNA nos hosts do banco de dados do MX840c

Slot de mezanino/CNA

Número da porta

Número da Partição

Tipo de partição

Porcentagem de largura de banda atribuída

Função do aplicativo

Mezanino 1A

Porta 1 Partição 1 NIC 0% (0 Gb) Nenhum (gerenciamento inicial do ESXi)

Partição 2 FCoE 100% (25 GbE) SAN de banco de dados/FCoE 1

Mezanino 1B

Porta 1 Partição 1 NIC 0% (0 Gb) Nenhum

Partição 2 FCoE 100% (25 GbE) SAN de banco de dados/FCoE 2

Mezanino 2A

Porta 1 Partição 1 NIC 20% (5 Gb) Gerenciamento do ESXi e uplink de rede da VM 1

Partição 2 NIC 20% (5 Gb) Uplink do vMotion para SQL/Oracle 1

Partição 3 NIC 60% (15 Gb) Uplink de rede pública para Oracle/SQL 1

Mezanino 2B

Porta 1 Partição 1 NIC 20% (5 Gb) Gerenciamento do ESXi e uplink de rede da VM 2

Partição 2 NIC 20% (5 Gb) Uplink do vMotion para SQL/Oracle 2

Partição 3 NIC 60% (15 Gb) Uplink de rede pública para Oracle/SQL 2

Obs.: o recurso NPAR, por padrão, cria quatro partições em cada porta do adaptador. As

partições que não estão listadas na tabela foram desabilitadas.

Configuração do

host ESXi

https://www.dell.com/support/home/br/pt/19/drivers/driversdetails?driverId=53N67&osCode=XI67&productCode=poweredge-r740xd




Para obter as etapas detalhadas sobre como criar partições nos CNAs QLogic, consulte

um dos seguintes documentos:

Guia do usuário do QLogic para adaptador Fibre Channel, adaptador de rede

convergente e adaptadores Ethernet inteligentes

Implementação de rede de armazenamento Fibre Channel da série Dell EMC

PowerEdge MX com IOMs Ethernet

Obs.: os fabric slots A2 e B2 de E/S do MX não foram preenchidos com nenhum IOMs porque

eles não são necessários nesta solução. Como resultado, a segunda porta de cada placa de

mezanino ou CNA que se conecta internamente a esses fabric slots ficou indisponível ou não

utilizada.

Conforme mostrado na Tabela 25, configuramos os hosts de banco de dados com as

práticas recomendadas e o projeto de LAN e SAN a seguir:

Tráfego de LAN e SAN (FCoE) em CNAs separados

2 partições FCoE de 25 Gb/s (total de 50 Gb/s) em dois CNAs separados para grande

largura de banda e conectividade de rede SAN altamente disponível

2 partições NIC de 15 GbE (total de 30 GbE) em dois CNAs separados para grande

largura de banda e conectividade de rede pública de banco de dados ou LAN

altamente disponível


largura de banda e conectividade com VMotion altamente disponível


largura de banda e conectividade de rede da VM e gerenciamento de host ESXi

altamente disponível

A figura a seguir mostra como os CNAs usados para o tráfego de LAN (mezanino nos

slots 2A e 2B dentro de cada um dos servidores blade MX840c) são conectados

internamente aos IOMs do MX9116n dentro do chassi MX. Ele também mostra como os

IOMs são conectados aos comutadores de uplink para conectividade e acesso da LAN

externa.

https://www.dell.com/support/home/br/pt/19/drivers/driversdetails?driverid=fp87m&oscode=xi67&productcode=poweredge-mx840c

https://www.dell.com/support/home/br/pt/19/drivers/driversdetails?driverid=fp87m&oscode=xi67&productcode=poweredge-mx840c

https://www.dell.com/support/article/br/pt/19/sln314800/dell-emc-poweredge-mx-series-fibre-channel-storage-network-deployment-with-ethernet-ioms?lang=en




Figure 23. Rede LAN: Conectividade interna e externa

Conforme mostrado na figura anterior, a primeira partição NIC (5 GbE) que foi criada

em cada placa de mezanino ou CNA foi usada para o tráfego de host ESXi e de

gerenciamento da VM, a segunda (5 GbE) partição NIC foi reservada para o tráfego

do vMotion e a terceira (15 GbE) em cada um dos CNAs foi usada para o tráfego público

do banco de dados. Para fornecer conectividade externa e largura de banda Ethernet

suficiente para todas as três funções de NIC em ambos os hosts do banco de dados

ESXi, configuramos uma porta QSFP28 (100 (GbE) voltada para o lado externo em cada

MX9116n no modo 4 10 GbE. Nós vinculamos as portas aos comutadores spine no data

center usando os cabos de comunicação QSFP+ a SFP+ (conectividade roxa).

Projeto de rede virtual ESXi

O diagrama a seguir mostra a topologia de projeto do comutador virtual que implementamos

nos hosts ESXi para a conectividade de rede que era necessária para os bancos de dados

Oracle e SQL Server. As vmnics no diagrama a seguir são as respectivas partições NIC que

foram criadas nos CNAs que aparecem como adaptadores físicos dentro dos hosts ESXi.




Figure 24. Projeto de rede virtual nos hosts ESXi

Conforme mostrado na Figura 14, o projeto de rede virtual nos dois servidores de banco

de dados do MX840c consiste em:

Tráfego de gerenciamento de VM — a rede de VM e o tráfego de gerenciamento

do ESXi usam o comutador virtual padrão (vSwitch), que contém dois grupos de

portas padrão. O grupo de portas de rede de gerenciamento fornece a porta vmk0

do VMkernel para gerenciar o host ESXi a partir do equipamento VMware vCenter

Server. O grupo de portas de rede da VM oferece as interfaces virtuais para o

gerenciamento de banda interna das máquinas virtuais do banco de dados. Para

alta disponibilidade e largura de banda, duas portas de uplink de 5 GbE (partição 1)

em dois CNAs separados (nos slots 2A e 2B) nos servidores de banco de dados do

ESXi do MX840c foram usadas para rotear o tráfego de gerenciamento.

Tráfego público — criamos um vSwitch padrão adicional dedicado para o tráfego

público do banco de dados em cada um dos hosts do banco de dados do ESXi

para os bancos de dados Oracle e SQL Server. Para grande largura de banda, alta



disponibilidade e balanceamento de carga, usamos duas portas de uplink de 15

GbE (partição 3) em dois CNAs separados (nos slots 2A e 2B) nos servidores de

banco de dados do ESXi do MX840c para rotear o tráfego de público do banco de

dados. Em cada vSwitch público, criamos um grupo de portas padrão (oraPub-PG

e oraSQL-PG, respectivamente) que fornece as interfaces de rede virtual para o

tráfego público de bancos de dados Oracle e SQL Server em suas respectivas VMs

de banco de dados.

A imagem ISO do ESXi 6.7 personalizada pela Dell EMC que usamos contém o driver

FCoE qedf para o CNA QL41262 QLogic. Esse driver garante que a partição FCoE que

criamos nos CNAs QLogic para o tráfego de SAN foi automaticamente reconhecida como

HBAs virtuais FCoE (vmhba64 e vmhba65) ou adaptadores de armazenamento nos hosts

ESXi, como mostrado na figura a seguir:

Figure 25. HBAs virtuais FCoE ou adaptadores de armazenamento reconhecidos em hosts ESXi

A figura a seguir mostra a conectividade do FCoE interno entre as placas de mezanino ou

CNAs dentro dos servidores blade MX840c e os IOMs FSE do MX9116n. Ela também

mostra a conectividade FC direta externa entre os IOMs FSE do MX9116n e o storage

array PowerMax.

Figure 26. Projeto de conectividade de FCoE com FC SAN Fabric

Conectividade e

zoneamento de

FCoE para FC




Conforme mostrado na figura anterior, configuramos a primeira porta em ambas as placas

de mezanino nos slots 1A e 1B de cada servidor MX840c para o tráfego de FCoE via

conectividade interna de 25 GbE com os respectivo IOMs do MX9116n nos fabric slots A1 e

B1 do MX. Configuramos as duas portas unificadas QSFP28 (100 GB) de entrada externa

nos IOMs do MX9116n no modo "breakout" em 4 FC de 16 Gb/s. As portas são conectadas

diretamente às portas FC front-end do PowerMax usando cabos de comunicação MPO (Multi-

fibre Push On). Esse projeto de conectividade SAN recomendado garante grande largura de

banda, balanceamento de carga e alta disponibilidade em dois FCoE para FC SAN Fabrics —

SAN Fabric A (conectividade vermelha) e SAN Fabric B (conectividade azul).

A Dell EMC recomenda o zoneamento de um iniciador único (partição FCoE no CNA,

nesse caso) de conjuntos de zonas nos comutadores FC (MX9116n nesse caso). Para

alta disponibilidade, largura de banda e balanceamento de carga, cada iniciador ou

partição FCoE CNA no host ESXi é zoneado com quatro portas de armazenamento front-

end do PowerMax distribuídas entre as duas Slics e os dois directors de armazenamento,

conforme mostrado na seguinte representação lógica de conjuntos de zonas:

Figure 27. Zoneamento FC: Representação lógica

Conforme ilustrado na figura anterior, para fornecer a mesma alta disponibilidade e igual

acesso de largura de banda front-end para armazenamento para os bancos de dados

Oracle e SQL Server, zoneamos cada iniciador com uma porta front-end exclusiva

distribuída em todo o array. Esse projeto garantiu que tanto o host ESXi do banco de

dados Oracle quanto do SQL Server tivesse oito caminhos exclusivos para o storage

array.

Para conhecer as etapas detalhadas sobre como configurar a conectividade FCoE com

FC entre o PowerEdge MX7000 e o storage array PowerMax, inclusive as práticas

recomendadas, consulte os guias a seguir.

Obs.: embora os seguintes guias de implementação de FCoE para FC usem storage arrays

Dell EMC (Unity) e comutadores de sistema de rede Dell EMC (unificados) (S4148U) diferentes,

os conceitos e as etapas de configuração de rede são aplicáveis ao array PowerMax e aos IOMs

do MX9116n que são usados nesta solução.

Implementação de rede de armazenamento Fibre Channel da série Dell EMC

PowerEdge MX com IOMs Ethernet





Guia de implementação de FCoE para Fibre Channel do sistema de rede Dell EMC

com S4148U-ON no modo F_port

Aplique as etapas de configuração recomendadas de QoS (DCBx), como especificado

em qualquer um dos dois guias, para garantir a configuração de FCoE sem perdas. A

configuração de QoS é aplicada automaticamente quando os dois IOMs do MX9116n são

configurados no modo Smart Fabric (Implementação de rede de armazenamento Fibre

Channel da série Dell EMC PowerEdge MX com IOMs Ethernet). No entanto, a

configuração deve ser aplicada manualmente no modo Full Switch (Implementação de

FCoE para Fibre Channel do sistema de rede Dell EMC com S4148U-ON no modo

F_port)). Nesta solução, configuramos a conectividade FCoE para FC nos dois IOMs do

MX9116n manualmente.

Configuramos múltiplos caminhos no host ESXi 6.7 de acordo com as seguintes práticas

recomendadas:

Usamos o NMP (vSphere Native Multipathing, múltiplos caminhos nativos do

vSphere) como software de múltiplos caminhos.

Retivemos a seleção padrão de round-robin para a PSP (Path Selection Policy,

política de seleção de caminhos) nativos nos volumes do PowerMax que são

apresentados aos hosts ESXi.

Alteramos a frequência de comutação de caminhos round-robin dos pacotes de

E/S do valor padrão de 1.000 para 1. Para obter informações sobre como definir

esse parâmetro, consulte o Guia de conectividade de host da Dell EMC para o

servidor VMware ESX.

No vSphere 6.7, o administrador pode adicionar latência à configuração do NMP como

uma subpolítica a fim de direcionar o vSphere para monitorar os caminhos em busca

de latência. Por padrão, a configuração de latência no vSphere 6.7 está desabilitada,

mas pode ser habilitada no vSphere 6.71 Update 1. Definir a subpolítica de seleção de

caminhos para latência permite que a política de round-robin selecione dinamicamente

o caminho ideal em busca de latência, a fim de obter melhores resultados. Para saber

mais, consulte Balanceamento de carga round-robin aprimorado do vSphere 6.7 U1.

Configuração

de múltiplos

caminhos

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/




Configuração de armazenamento do PowerMax

Para facilitar o gerenciamento e o monitoramento, criamos dois hosts de armazenamento

no array PowerMax, um contendo os dois iniciadores a partir do host ESXi do banco de

dados Oracle (MX840c no slot 1 do MX) e os outros que contêm os dois iniciadores do

host ESXi do SQL Server (MX840c no slot 3 do MX).

Conforme descrito em Conectividade e zoneamento de FCoE para FC, o projeto de

conectividade e zoneamento de FC garante que tanto o host ESXi do Oracle quanto os

hosts ESXi do SQL Server sejam conectados a oito portas front-end exclusivas no array

PowerMax. Como resultado, criamos dois grupos de portas de armazenamento no array

PowerMax, um contendo as oito portas front-end que foram zoneadas com os iniciadores

de host do banco de dados Oracle e o segundo que contém as outras oito portas front-

end que foram zoneadas com o iniciadores de host do banco de dados SQL Server.

Esse projeto garante a mesma largura de banda, alta disponibilidade, facilidade de

gerenciamento, monitoramento e segurança para os bancos de dados Oracle e SQL

Server.

Para consolidar as cargas de trabalho mistas de bancos de dados Oracle e SQL no

storage array PowerMax único, nós adaptamos os seguintes princípios para o grupo de

armazenamento e o projeto de volume de armazenamento para três bancos de dados

Oracle: banco de dados OLTP Oracle, banco de dados Oracle DSS e banco de dados

Oracle de snapshot. Esses princípios de projeto simplificam o gerenciamento e o

monitoramento de desempenho dos volumes de armazenamento.

Criamos o grupo de armazenamento pai para cada banco de dados, como ORA-

OLTP-SG para o banco de dados Oracle OLTP.

Criamos um grupo filho separado para cada tipo de volume, como volumes DATA,

REDO, FRA, e TEMP, dentro de cada grupo de armazenamento pai. Os números de

volumes correspondentes foram criados em cada grupo filho, por exemplo, criamos

quatro volumes de dados no grupo filho ORA-OLTP-DATA.

Criamos um grupo de armazenamento pai especial, ORA-OS-OCR, que consolida os

discos virtuais do sistema operacional para todas as VMs guest do banco de dados

Oracle, bem como para Oracle Clusterware OCR e Voting Disks. Os grupos

secundários dentro desse grupo pai foram criados para cada volume do sistema

operacional da máquina virtual e cada volume de Oracle Clusterware OCR e Voting

Disk.

Com esses princípios de projeto em mente, desenvolvemos os seguintes volumes e

grupos de armazenamento para esses bancos de dados Oracle de cargas de trabalho

mistas.

Para o banco de dados Oracle OLTP, criamos o grupo de armazenamento pai ORA-

OLTP-SG e os seguintes grupos de armazenamento filho dentro do grupo pai:

ORA-OLTP-DATA para arquivos DATA

ORA-OLTP-REDO para registros REDO

ORA-OLTP-FRA para FRA

Hosts e grupos

de portas

Grupos e

volumes de

armazenamento

para cargas de

trabalho Oracle



ORA-OLTP-TEMP para arquivos TEMP

Também criamos os grupos filho ORA-OLTP-OS e ORA-OLTP-OCR dentro do grupo pai

em comum. A tabela a seguir mostra os grupos de armazenamento, bem como o número

de volumes e os tamanhos de volumes para esse banco de dados Oracle OLTP:

Table 28. Grupos de armazenamento e volumes para o banco de dados Oracle OLTP

SG pai SG filho

Tamanho de cada volume (GB)

Número de volumes

Tamanho 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

Da mesma forma, para o banco de dados Oracle DSS, criamos o grupo de

armazenamento pai ORA-DSS-SG e os seguintes grupos de armazenamento filho:

ORA-DSS-DATA para arquivos DATA

ORA-DSS-REDO para registros REDO

ORA-DSS-FRA para FRA

ORA-DSS-TEMP para arquivos TEMP

Também criamos os grupos filho ORA-DSS-OS e ORA-DSS-OCR dentro do grupo pai

em comum. A tabela a seguir mostra esses grupos de armazenamento, o número de

volumes e o tamanho dos volumes para esse banco de dados Oracle DSS:

Table 29. Grupos de armazenamento e volumes para o banco de dados Oracle DSS

SG pai SG filho Tamanho do volume (GB)

Número de volumes

Tamanho 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




Nesse projeto de arquitetura de referência, adaptamos os seguintes princípios para o

grupo de armazenamento e o projeto de volume de armazenamento para cinco bancos

de dados SQL Server: dois bancos de dados OLTP, dois bancos de dados DSS e um

banco de dados de snapshot:

Criamos o grupo de armazenamento pai para cada banco de dados, como

SQL_OLTP_VM1_SG para o banco de dados SQL Server OLTP.

Criamos um grupo filho separado para cada tipo de volume, como volumes data,

log, tempdb data e tempdb log, dentro de cada grupo de armazenamento pai.

Criamos os números de volumes correspondentes em cada grupo filho, por

exemplo, dois volumes de dados no grupo filho SQL_OLTP_VM1_Data.

Criamos um grupo de armazenamento pai especial, o SQL_OS_SG, que consolida

os discos virtuais do sistema operacional para todas as VMs guest do banco de

dados SQL Server. Criamos os grupos filho dentro desse grupo pai para os

volumes do sistema operacional de cada VM.

Esses princípios de projeto simplificam o gerenciamento e o monitoramento de

desempenho dos volumes de armazenamento, inclusive os volumes que foram criados

por meio de snapshots para a carga de trabalho do SQL Server em execução junto com

a carga de trabalho do Oracle.

A tabela a seguir mostra os grupos de armazenamento e os volumes para as cargas de

trabalho de banco de dados SQL Server OLTP.

Table 30. Grupos de armazenamento e volumes para os bancos de dados SQL Server OLTP

SG pai SG filho

Tamanho do volume (GB)

Número de volumes

Tamanho 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 de

armazenamento

e volumes para

cargas de

trabalho SQL

Server



Para o banco de dados SQL Server DSS, criamos um layout de armazenamento

semelhante. A tabela a seguir mostra os grupos de armazenamento, o número de

volumes e os tamanhos dos volumes para os dois banco de dados SQL Server DSS:

Table 31. Grupos de armazenamento e volumes para os bancos de dados SQL Server DSS

SG pai SG filho

Tamanho de cada volume (GB)

Número de volumes

Tamanho 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

A figura a seguir ilustra a arquitetura de snapshots SnapVX dos volumes de bancos de

dados de produção (origem). Ela mostra como esses snapshots estão vinculados a outro

conjunto de dispositivos de destino, que são acessados pelo host do banco de dados de

snapshot, para formar um banco de dados de snapshot, como um banco de dados de

desenvolvimento ou teste.

Figure 28. Criação de snapshots SnapVX e montagem do banco de dados de snapshot

Para bancos de dados de snapshot, criamos dois tipos de grupos de armazenamento:

Volumes de

banco de dados

de snapshot




Novos grupos de armazenamento — criamos novos volumes nesses grupos

de armazenamento para o banco de dados de snapshot. Esses grupos de

armazenamento incluem os volumes do sistema operacional guest, Oracle

OCR/Voting Disk, volumes TEMP do Oracle, o sistema operacional guest e os

volumes do SQL Server TEMP, conforme mostrado na tabela a seguir:

Table 32. Novos grupos de armazenamento para bancos de dados de snapshot

Novo grupo de armazenamento Volumes

Nome do pai Nome do filho Tamanho (GB)

Quantidade

Tamanho total (GB)

ORA-OS-OCR ORA-SNAP-OS 500 1 500

ORA-SNAP-OCR 50 3 50

ORA-SNAP-TEMP NENHUM 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 armazenamento de snapshot ou do SnapVX — esses grupos de

armazenamento são snapshots de grupos de armazenamento existentes do banco

de dados. Os volumes nesses grupos de armazenamento incluem snapshots dos

volumes de origem DATA, REDO e FRA do Oracle, além de DATA e LOG do SQL

Server. Criamos dois snapshots do SnapVX: um do banco de dados Oracle OLTP

existente e outro do banco de dados SQL Server OLTP existente. Os servidores

de banco de dados do host, no entanto, acessam os grupos de armazenamento

ou os volumes de snapshots usando os grupos de armazenamento de destino do

SnapVX que criamos para os respectivos snapshots do Oracle e do SQL Server.

A tabela a seguir mostra os grupos de armazenamento de origem, snapshot e

destino de link do SnapVX que criamos para os bancos de dados snapshot Oracle

e SQL Server:

Table 33. Grupos de armazenamento de origem, snapshot e destino de link para bancos de dados de snapshot

Grupo de armazenamento de origem Nome do

snapshot

Grupo de armazenamento de destino de link do SnapVX Volumes

Pai Filho Pai Filho

ORA-OLTP-SG ORA-OLTP-SNAP-SG

ORA-OLTP-SG_LNK_SG_001

ORA-OLTP-SG-DATA

snapshots ORA-OLTP-SG-DATA-SG_001

4

ORA-OLTP-SG-REDO

snapshots ORA-OLTP-SG-REDO_SG_001

4



Grupo de armazenamento de origem Nome do

snapshot

Grupo de armazenamento de destino de link do SnapVX Volumes

Pai Filho Pai Filho

ORA-OLTP-SG-FRA

snapshots ORA-OLTP-SG-FRASG_001

2

SQL-OLTP-VM1 SQL-OLTP-VM1-SNAP

SQL-OLTP-VM1_LNK_SG_001

SQL-OLTP-VM1_Data

snapshots SQL_OLTP_VM1_Data_SG_001

2

SQL-OLTP-VM1_Log

snapshots SQL_OLTP_VM1_Log_SG_001

1

Obs.: o gerenciamento de armazenamento do Unisphere cria automaticamente a estrutura de

grupo de armazenamento de destino de link do SnapVX para ser igual à da estrutura da qual ele

é criado. Portanto, o número e o tamanho dos volumes de snapshot são idênticos aos volumes do

banco de dados de origem.

Em seguida, mapeamos todos os novos grupos de armazenamento e os grupos de

armazenamento de destino do SnapVX que foram criados para os bancos de dados de

snapshots em seus respectivos hosts ESXi de banco de dados por meio da criação de

exibições de mascaramento apropriadas. Dentro dos respectivos hosts ESXi,

adicionamos manualmente todos os volumes à máquina virtual apropriada que foi criada

para o banco de dados de snapshot. Dentro das respectivas VMs guest do banco de

dados, montamos esses volumes no banco de dados de snapshot.

A figura a seguir ilustra o processo de criação, vinculação e montagem de snapshots,

usando o banco de dados Oracle OLTP e seu banco de dados de snapshot, por exemplo.




Figure 29. Processo de criação, vinculação e montagem de snapshots

Configurações do sistema operacional guest e das VMs do Oracle

Utilizamos os princípios de projeto e as práticas recomendadas a seguir para criar as

VMs para os bancos de dados Oracle.

Controladoras SCSI e discos rígidos virtuais

Recomendamos várias controladoras SCSI do tipo VMware Paravirtual para otimizar e

equilibrar a E/S para os diferentes discos rígidos do banco de dados Oracle, conforme

descrito nesta seção.

A tabela a seguir mostra o projeto recomendado de controladora SCSI para as VMs de

banco de dados OLTP e de snapshot. Os dados e os discos de REDO são distribuídos

Projeto e

configuração

de VM



em diferentes controladoras SCSI dedicadas, pois em uma carga de trabalho OLTP

Oracle, esses tipos de discos geram um alto nível de E/S para o armazenamento. Por

outro lado, os discos OCR, FRA e TEMP geram relativamente pouca E/S e, portanto,

podem existir juntos em uma controladora SCSI dedicada separada.

Table 34. Propriedades da controladora SCSI nas VMs de banco de dados OLTP e de snapshot

Controladora Objetivo Compartilhamento de barramento SCSI

Tipo de controladora

SCSI 0 Disco do sistema operacional guest

Nenhum

VMware Paravirtual

SCSI 1 Discos DATA do Oracle

SCSI 2 Discos REDO do Oracle

SCSI 3 Discos OCR, FRA e TEMP do Oracle

A tabela a seguir mostra o projeto recomendado de controladora SCSI para a VM de

banco de dados DSS. As cargas de trabalho DSS geram, em grande parte, a E/S de

leitura para os discos DATA com pouca E/S para os discos REDO. Portanto, conforme

mostrado na tabela a seguir, os 10 discos DATA são distribuídos entre as três

controladoras SCSI dedicadas para balanceamento de carga, enquanto o restante dos

discos tipo E/S leve (sistema operacional guest, discos OCR, REDO, FRA e TEMP)

existem juntos na primeira controladora SCSI.

Table 35. Propriedades da controladora SCSI nas VMs de banco de dados DSS


Tipo

SCSI 0 Sistema operacional guest, discos OCR, REDO, FRA e TEMP

Nenhum

VMware Paravirtual

SCSI 1 3 discos DATA do Oracle



Os discos rígidos virtuais para o sistema operacional guest das VMs são criados como

um datastore VMFS6. Todos os volumes ou discos rígidos virtuais para os bancos de

dados Oracle (discos DATA, REDO, FRA, TEMP e OCR) são diretamente adicionados

a suas respectivas VMs como dispositivos brutos ou por meio de RDM (Raw Device

Mapping). Para esses dispositivos brutos, embora o ESXi crie um arquivo de

mapeamento com a extensão .vmdk e salve-o em um datastore VMFS, o arquivo

de mapeamento conterá apenas as informações de mapeamento, enquanto os dados

em si serão armazenados diretamente na LUN de armazenamento.

Configuração da vCPU, vMem e vNIC

Deixamos todas as propriedades da vCPU e vMem em todas as máquinas virtuais de

banco de dados Oracle de acordo com seus valores padrão, exceto para reserva de




memória. Alocamos diferentes quantidades de vCPUs, vMems e reservas de memória

para diferentes tipos de máquinas virtuais de banco de dados. Para obter detalhes sobre

os valores alocados durante os testes de cada um dos casos de teste, consulte a Tabela

2 e a Tabela 7.

Adicionamos dois adaptadores de rede virtual a cada uma das VMs de banco de dados:

um para o gerenciamento de VM de banda interna e outro para o tráfego público do

Oracle. Configuramos os dois adaptadores com a definição de tipo recomendada do

VMXNet 3. Para obter detalhes sobre a configuração de comutadores virtuais e

adaptadores físicos, consulte Projeto de computação e rede no Apêndice B.

Habilitar a UUID de disco

Para cada VM, nas opções configurações avançadas de Opções de máquina virtual,

adicionamos o parâmetro de configuração disk.enableUUID e definimos seu valor

como TRUE. Essa configuração garante que o VMDK sempre apresente uma UUID de

disco consistente à VM.

Nesta arquitetura de referência, usamos as seguintes práticas recomendadas para

implementar e configurar o Red Hat Enterprise Linux 7.4 como o sistema operacional

guest nas máquinas virtuais que estavam executando os bancos de dados Oracle

independentes:

Instalamos e configuramos o sistema operacional, a rede, os discos de

armazenamento, o Oracle 18c (18.3.0) Grid e o Oracle Database 18c (18.3.0)

independente na máquina virtual, conforme instruído no seguinte artigo da base de

conhecimento da Dell EMC: Como implementar o Oracle 18c Grid e o banco de

dados independente no RHEL 7.x.

Configure os pré-requisitos do Oracle Grid e do software de banco de dados Oracle

(RPMs do sistema operacional, usuários, grupos, parâmetros de kernel requeridos

e assim por diante) usando o pacote de informações e implementação no seguinte

artigo da base de conhecimento da Dell EMC: Implementação de Oracle na Dell

EMC para Oracle 18c no RHEL7.x.

Também seguimos estas importantes práticas recomendadas:

No sistema operacional guest, para cada disco virtual Oracle, criamos uma partição

única que abrangia o disco inteiro e tinha uma diferença inicial de 2.048 setores.

Usamos regras de UDEV para estabelecer a propriedade e as permissões nos

discos Oracle dentro da máquina virtual. O exemplo a seguir mostra um conjunto

de regras de UDEV para um dos discos Oracle (disco REDO) no arquivo

personalizado de regras de UDEV /etc/udev/rules/60-oracle-

asmdevices.rules:

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"

Conforme descrito em Configuração e projeto da VM, mapeamos todas as LUNs

relacionadas ao banco de dados Oracle que foram apresentadas ao host ESXi do storage

Configuração

do sistema

operacional

guest e do

Oracle ASM

https://www.dell.com/support/article/br/pt/brbsdt1/how16915/how-to-deploy-oracle-18c-grid-and-standalone-database-on-rhel-7-x?lang=en

https://www.dell.com/support/article/br/pt/brbsdt1/how16915/how-to-deploy-oracle-18c-grid-and-standalone-database-on-rhel-7-x?lang=en

https://www.dell.com/support/article/br/pt/brbsdt1/sln316873/dell-oracle-deployment-rpms-for-oracle-18c-on-rhel7-x?lang=en

https://www.dell.com/support/article/br/pt/brbsdt1/sln316873/dell-oracle-deployment-rpms-for-oracle-18c-on-rhel7-x?lang=en



array PowerMax diretamente como dispositivos brutos para suas respectivas VMs de

banco de dados usando RDM (Raw Device Mapping, mapeamento de dispositivos

brutos). Em conformidade com os requisitos do banco de dados Oracle, atribuímos a

propriedade dos dispositivos brutos ao usuário grid que possui o Oracle GI e o Oracle

ASM (Automatic Storage Management). O link do dispositivo para esses dispositivos

brutos relacionados do Oracle é /dev/oracles’/disks/oral-XXX. Por exemplo,

/dev/oracle’s/disks/ora-redo1 é o link do dispositivo para o dispositivo REDO1

LUN/raw.

A tabela a seguir mostra os grupos de discos Oracle que criamos para o banco de dados

OLTP usando os dispositivos brutos ou os discos virtuais apresentados para a máquina

virtual a partir do storage array. Exceto o grupo de discos OCR que usa a redundância

normal (com espelhamento triplo), todos os outros grupos de discos usavam

a configuração de redundância externa. A configuração de particionamento abrangente

é recomendada para os grupos de discos DATA, FRA e OCR, e a configuração de

particionamento granular é recomendada para os grupos de discos REDO1, REDO2

e TEMP.

Table 36. Projeto do grupo de discos do ASM para o banco de dados OLTP

Grupo de discos do ASM

Objetivo Redundância Particionamento do ASM

Tamanho do grupo de discos do ASM (GB)

LUN Tamanho da LUN (GB)

DATA Arquivos de dados, arquivos de controle, desfazer tablespace

Redundância externa

Abrangente 2.000 DATA00 500

DATA01 500

DATA02 500

DATA03 500

FRA Arquivos de registros do arquivamento


Abrangente 200 FRA0 100

FRA1 100

REDO1 Redo logs on-line


Granular 50 REDO0 25

REDO1 25

REDO2

Redo logs on-line


Granular

50 REDO2 25

REDO3 25

TEMP

Arquivos temporários


Granular

500 TEMP

500

OCR OCR, Voting Disk, GIMR

Redundância normal

Abrangente

50 OCR0 50

OCR1 50

OCR3 50

Obs.: o projeto do grupo de discos do ASM para o banco de dados DSS e o banco de dados de

snapshot é idêntico ao projeto do grupo de discos do ASM do banco de dados OLTP mostrado na




tabela com a seguinte exceção: No projeto de grupo de discos de DSS, o grupo de discos DATA

tem 8 discos de 500 GB para um tamanho total de grupo de discos de 4 TB e o grupo de discos

TEMP tem um disco de 2 TB.

O Oracle ASM inclui um recurso por meio do qual você pode mover os dados para

módulos de desempenho mais alto dos discos giratórios na fase compacta no final do

rebalanceamento de discos do ASM. Esse recurso não traz benefícios para o

armazenamento do Dell EMC PowerMax quando o armazenamento físico está sendo

virtualizado e os dispositivos flash estão sendo usados. Você pode desabilitar o recurso

de rebalanceamento executando o comando alter diskgroup para todos os grupos

de discos. O seguinte exemplo mostra o resultado do comando para o grupo de discos

DATA:

SQL> alter diskgroup DATA set attribute '_rebalance_compact' =

'FALSE';

Para obter mais informações sobre o rebalanceamento compacto do ASM, consulte a

Nota de suporte da Oracle 1902001.1.

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=392647068805231&id=1902001.1&_adf.ctrl-state=emdpuym0_110



Configurações do sistema operacional guest e das VMs do SQL Server

Utilizamos os princípios de projeto e as práticas recomendadas a seguir para criar as

VMs para os bancos de dados SQL Server.

Controladoras SCSI e discos rígidos virtuais

Recomendamos usar várias controladoras SCSI do tipo VMware Paravirtual para otimizar

e equilibrar a E/S para os diferentes discos rígidos do banco de dados SQL Server,

conforme descrito nesta seção.

A tabela a seguir mostra o projeto recomendado de controladora SCSI para as VMs de

banco de dados OLTP e de snapshot. Os dados e os discos de LOG são distribuídos em

diferentes controladoras SCSI dedicadas, pois em uma carga de trabalho SQL Server

OLTP, os tipos de discos geram um alto nível de E/S para o armazenamento. Por outro

lado, os discos de banco de dados TEMP geram relativamente pouca E/S e, portanto,

podem existir junto com o volume do sistema operacional em uma controladora SCSI

dedicada separada.

Table 37. Propriedades da controladora SCSI nas VMs de banco de dados OLTP e de snapshot


Tipo

SCSI 0 Disco do sistema operacional guest, discos de dados e registro tempdb

Nenhum

VMware Paravirtual

SCSI 1 Disco SQL DATA 1

SCSI 2 Disco SQL DATA 2

SCSI 3 Disco de registro SQL

A tabela a seguir mostra o projeto recomendado de controladora SCSI para a VM de

banco de dados DSS. As cargas de trabalho DSS geram, em grande parte, a E/S de

leitura para os discos DATA com pouca E/S para os discos log. Além disso, o uso de

tempdb aumenta significativamente durante a carga de trabalho DSS e pode gerar uma

quantidade significativa de E/S. Por esse motivo, como mostrado na tabela a seguir, os

discos DATA e os volumes tempdb são distribuídos entre as três controladoras SCSI

dedicadas para balancear a carga, enquanto os discos do sistema operacional, registro

tempdb e registro do banco de dados DSS estão localizados juntos na primeira

controladora SCSI.

Projeto e

configuração

de VM




Table 38. Propriedades da controladora SCSI nas VMs de DSS


Tipo

SCSI 0 Disco do sistema operacional guest, registro de banco de dados DSS, disco de registro tempdb

Nenhum

VMware Paravirtual

SCSI 1 Disco de dados SQL 1

SCSI 2 Disco de dados SQL 2

SCSI 3 Discos de dados tempdb

Todos os discos rígidos virtuais para as VMs foram criados como datastores VMFS6.

Em seguida, cada datastore foi atribuído a suas respectivas VMs.

Configuração da vCPU, vMem e vNIC

Deixamos todas as propriedades da vCPU e vMem em todas as máquinas virtuais de banco

de dados SQL Server de acordo com seus valores padrão, exceto para reserva de memória.

Alocamos diferentes quantidades de vCPUs, vMems e reservas de memória para diferentes

tipos de máquinas virtuais de banco de dados. Para obter detalhes sobre os valores alocados

durante os testes de cada um dos casos, consulte a Tabela 2 e a Tabela 7.

Adicionamos dois adaptadores de rede virtual a cada uma das VMs de banco de dados:

um para o gerenciamento de VM de banda interna e outro para o tráfego público do

SQL Server. Configuramos os dois adaptadores com a definição de tipo recomendada

do VMXNet 3. Para obter detalhes sobre a configuração de comutadores virtuais

e adaptadores físicos, consulte Projeto de computação e rede no Apêndice B.

Habilitar a UUID de disco

Para cada VM, nas opções configurações avançadas de Opções de máquina virtual,

adicionamos o parâmetro de configuração disk.enableUUID e definimos seu valor

como TRUE. Essa configuração garante que o VMDK sempre apresente uma UUID de

disco consistente à VM.

Para instalar e configurar os sistemas operacionais guest Red Hat Enterprise Linux 7.6,

consulte o documento da VMware Instalando e configurando sistemas operacionais guest

Linux.

Ao configurar o sistema operacional guest Red Hat Enterprise Linux 7.6 para SQL Server,

realizamos as seguintes tarefas:

Usamos a ferramenta de linha de comando ajustada para definir o perfil de

desempenho de latência para uma carga de trabalho OLTP.

Usamos a ferramenta de linha de comando ajustada para definir o perfil de

desempenho de throughput para uma carga de trabalho DSS.

Seguimos as práticas recomendadas de desempenho e diretrizes de configuração

do SQL Server no Linux da Microsoft. Além disso, adicionamos os parâmetros de

configuração relacionados ao desempenho recomendados pela Microsoft para o

Configuração

e instalação

do SQL Server

e do sistema

operacional

guest

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/linux_install_config.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/linux_install_config.pdf





sistema operacional Red Hat Enterprise Linux ao perfil de desempenho de latência.

Além disso, para nossa carga de trabalho OLTP, definimos

vm.dirty_background_ratio para 20.

Alteramos a legenda do disco (DOS, por padrão) para GPT.

Criamos partições de disco usando o utilitário parted ou fstab nos dispositivos de

armazenamento. Escolhemos o file system EXT4 ao formatar os discos.

Mantivemos todas as entradas de arquivos montadas em /etc/fstab para

permitir a montagem automática quando o servidor for reinicializado.

Para instalar e configurar o banco de dados independente SQL Server 2017, consulte as

seguintes instruções da Microsoft: Quickstart: Instalação do SQL Server e criação de um

banco de dados no Red Hat.

Depois de instalarmos o SQL Server 2017 no Red Hat Enterprise Linux 7.6, realizamos

estas alterações de configuração:

Definimos Min server memory e Max server memory para o mesmo valor e o

espaço deixado para sobrecarga do sistema operacional. Para obter mais

informações, consulte Práticas recomendadas de memória máxima do SQL Server.

Alteramos a opção de configuração maximum degree of parallelism (MAXDOP)

e a opção cost threshold for parallelism após a validação adequada, pois o

requisito de paralelismo de consulta muda de acordo com o conjunto de dados e a

natureza das consultas. Para obter mais informações, consulte as recomendações

e diretrizes da opção de configuração do "max degree of parallelism" no SQL

Server e Configurar o limite de custo para a opção de configuração do servidor de

paralelismo. Durante nosso estudo, mantivemos MAXDOP com o valor padrão de

0 para a carga de trabalho OLTP e 8 para a carga de trabalho DSS. Além disso,

mantivemos cost threshold for parallelism value em seu valor padrão de 5.

Definimos o valor max worker thread de acordo com a carga de trabalho e o

processador que foram atribuídos à instância do SQL Server. Para obter mais

informações, consulte Configurar a opção de máximo de threads de operador da

configuração do servidor. Durante nosso estudo, mantivemos max worker thread

em seu valor padrão de 0.

Usamos vários arquivos de dados em diferentes discos virtuais e LUNs dentro do

mesmo grupo de arquivos.

Alocamos vários arquivos de dados tempdb para resolver problemas de conflito de

acesso de tempdb. Para obter mais informações, consulte Recomendações para

reduzir o conflito de acesso de alocação no banco de dados tempdb do SQL

Server. Para nosso estudo, alocamos oito arquivos em uma unidade separada que

era dedicada a tempdb com 8 GB por arquivo.

Arquivos de dados do banco de dados segregado, arquivos de log do banco de

dados e arquivos tempdb em unidades separadas que foram associadas a volumes

e discos virtuais dedicados. Para nosso estudo, criamos dois arquivos de dados e

um arquivo de log em unidades dedicadas.



https://straightpathsql.com/archives/2017/02/sql-server-max-memory-best-practices/

https://support.microsoft.com/pt-br/help/2806535/recommendations-and-guidelines-for-the-max-degree-of-parallelism-confi



https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/configure-the-cost-threshold-for-parallelism-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/configure-the-cost-threshold-for-parallelism-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/configure-the-max-worker-threads-server-configuration-option?view=sql-server-2017

https://docs.microsoft.com/pt-br/sql/database-engine/configure-windows/configure-the-max-worker-threads-server-configuration-option?view=sql-server-2017

https://support.microsoft.com/pt-br/help/2154845/recommendations-to-reduce-allocation-contention-in-sql-server-tempdb-d



Documents

Consolide e simplifique cargas de trabalho mistas de banco de … · 2020. 9. 17. · Capítulo 1: Resumo executivo Consolide e simplifique cargas de trabalho mistas de banco de dados