Daca ati implementat sarcini de lucru SQL Server pe platforma Microsoft Azure folosind masini virtuale, este posibil sa fi observat ca nu toate masinile virtuale, unitatile de stare solida si componentele de retea sunt create egale. S-ar putea sa apara probleme in sabloanele de implementare care ar putea duce la performanta SQL Server la fel de asteptat. De exemplu, intr-o prezentare sustinuta de Andre Arko la StrangeLoop 2016, Andre sustine ca Netflix face referinta la instantele AWS EC2 pe care le folosesc pentru productie si, daca trece, il folosesc. Daca instanta EC2 nu trece valoarea de referinta, atunci acestea incheie instanta si creeaza un inlocuitor. Potrivit lui Andre, motivul este ca Netflix a descoperit ca acelasi tip de instanta ar putea fi de pana la 5 ori mai lent decat valoarea de baza stabilita. Pentru numarul de instante pe care le creeaza Netflix, asta reprezinta un cost de exploatare semnificativ. Avand in vedere acest lucru, oferim acum un serviciu cu valoare adaugata de validare a implementarilor Azure SQL Server folosind HammerDB. In acest fel, clientii nostri stiu ca obtin cea mai buna masina virtuala Azure posibila pentru a-si conduce sarcinile de productie.

Acest post de blog descrie un nou serviciu pe care il oferim clientilor pentru utilizarea sistemului de referinta HammerDB TPC-C ca un proces de „burn-in” pentru rularea instantelor SQL Server 2017 de productie pe masinile virtuale Azure. Vom arata cum comparam rezultatele cu biblioteca noastra de baza si vom determina daca masina virtuala poate fi utilizata pentru productie sau inlocuita.

The problem with traditional CPU benchmarks like PassMark, or disk benchmarking tools like Windows Diskspd, or other open-source suites from places like https://openbenchmarking.org/, is that they don’t stress the system the way that SQL Server running an online transaction processing (OLTP) would. At DB Best, we’ve been using HammerDB for benchmarking physical, virtual, and cloud-based deployments of SQL Server for years. We’ve also used it to test deployments of Oracle, MySQL, IBM DB2, PostgreSQL, and Amazon Redshift as well. Depending on whether our customer is running OLTP or data warehouse (DW) solutions, HammerDB is ready for both. HammerDB includes an OLTP benchmark that is patterned after the original TPC.org TPC-C benchmark. HammerDB also includes a DW benchmark that is based on the original TPC-H benchmark.

Vrem sa precizam foarte clar ca HammerDB nu este un instrument oficial de evaluare comparativa care poate fi utilizat pentru a compara public rezultatele de referinta intre produsele sau platformele bazei de date.

Cu toate acestea, am descoperit ca HammerDB este un instrument excelent care ofera rezultate consistente pe o platforma tinta pentru care dorim sa implementam solutii SQL Server pentru clientii nostri. In acest fel, ne putem asigura ca obtin performantele asteptate pentru implementarea lor de productie. Daca exista o slabiciune in infrastructura platformei sau un server SQL configurat gresit, HammerDB va prinde sistemul cu probleme.

In plus, recent am facut un proiect cu Western Digital si DataON folosind HammerDB pentru a arata cum functioneaza noile solutii SQL Server 2017 ale DataOn folosind Windows Server Hyper-Converged Infrastructure (HCI). Echipa de inginerie DataON utilizeaza acum cadrul de testare de referinta pe care l-am dezvoltat si il foloseste pentru sisteme de ardere inainte de a le expedia clientilor.

Unul dintre arhitectii nostri de solutie a venit cu ideea, de ce sa nu facem acelasi lucru pentru implementarile SQL Server pe Azure ? Am creat deja un cadru pentru automatizarea HammerDB pentru a rula masini de referinta. Singurul lucru pe care trebuie sa-l facem este sa cream un mediu de productie de baza si apoi sa-l testam impotriva instantelor populare Azure VM pe care le folosim pentru implementarile clientilor in diverse centre de date si sa le folosim pentru aceste evaluari de referinta pentru o evaluare de sus sau in jos a tintei. VM.

Urmatoarea diagrama reprezinta o imagine de ansamblu a unei implementari de productie cu un singur server pentru validarea implementarilor Azure SQL Server folosind HammerDB.

Retelele accelerate permit virtualizarea I / O single root (SR-IOV) la o VM, imbunatatind considerabil performantele sale de retea. Aceasta cale de inalta performanta ocoleste gazda de pe calea datelor, reducand latenta, bruiajul si utilizarea procesorului. Acest lucru ofera o mai mare consistenta atunci cand se executa etalon.

Configurarea valorii de referinta HammerDB TPC-C

HammerDB ofera o varietate de parametri pentru configurarea rularii de referinta. Mai intai, am creat o baza de date tpcc cu 1000 de depozite. Rezulta o baza de date cu dimensiunea de aproximativ 80 GB. Urmatoarea imagine arata distributia inregistrarilor pentru baza de date tpcc.

Ramanem etalonul cu o serie modificata de utilizatori virtuali Fibonacci incepand de la 3 pana la 233. Cu 1 si 2 utilizatori virtuali, nu obtinem rezultate consistente statistic, asa ca le ignoram in analiza costurilor noastre. Executam etalonul cu doua minute de timp de rampare, urmate de trei minute de timp de executie pentru a determina tranzactiile pe minut pentru fiecare din cele 10 configuratii ale utilizatorului. Desfasurarea completa dureaza 100 de minute.

Configurarea SQL Server pentru benchmark

In configurarea SQL Server pentru benchmark, nu incercam in mod necesar sa optimizam SQL Server pentru a rula cel mai bine benchmark-ul. Cu toate acestea, vrem sa ne asiguram ca vom profita la maxim de infrastructura Azure. Microsoft ofera un articol intitulat Indicatii de performanta pentru SQL Server in masinile virtuale Azure pe care le luam in considerare pentru valorile noastre de referinta si implementarile clientilor.

In loc sa utilizam sabloanele Azure pentru SQL Server, ne cream propria imagine bazata pe o imagine instantanee a unei versiuni instalate a SQL Server 2017 cu cea mai recenta CU. In cazul nostru, CU12 construieste 14.0.3045.24. Apoi, configuram diverse configuratii de actionare care acopera dimensiunea de 1,75 TB la 2 TB pentru a permite o crestere suficienta. In functie de dimensiunea VM, vom utiliza urmatoarele configuratii de disc:

  • 5 × 2 – Cinci unitati P15 (256 GB) cu dungi pentru unitatea de date si doua unitati P15 (256 GB) cu dungi pentru unitatea de jurnal.
  • 7 – Sapte unitati P15 (256 GB) in dungi atat pentru date cat si pentru fisierele de jurnal
  • P30 – Doua unitati P30 (1024 GB) in dungi, atat pentru fisiere de date cat si pentru jurnal
  • P40 – O unitate P40 (2048 GB) atat pentru date cat si pentru jurnal

Am folosit spatii de stocare Windows pentru a stripa unitatile. Apoi am descoperit ca Spatiile de stocare au un efect mai bun (de la 1% la 3%) decat folosind Windows Disk Manager. In general, suntem bine sa combinam datele si unitatile de jurnal pe aceeasi unitate din cauza redundantei incorporate a stocarii Azure. Totusi, totul depinde de volumul de lucru, de transfer, de dimensiunea VM, etc., si evidentiat in postarea de blog de catre echipa SQL Server Engine intitulata Ghid de configurare pentru stocare pentru SQL Server pe Azure VM.

Pentru definitia bazei de date SQL Server, am folosit mai multe fisiere de date pentru grupul de fisiere PRIMAR, dupa cum urmeaza:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

————————————————– —————-

– –

– File: CREATE_DATABASE.SQL –

– –

– 1.000 depozite TPC-C 100 GB –

– –

– ————————————————– ————–

SETI ANSI_NULL_DFLT_OFF ON

GO

UTILIZEAZA MAESTRU

GO

—————————–

– crearea principalelor fisiere de baza de date

————— ————–

CREATE DATABASE tpcc

ON PRIMARY

(NAME = TPC_C_ROOT,

FILENAME = ‘D: \ Data \ TPC_C_ROOT.mdf’,

SIZE = 20GB,

FILEGROWTH = 0),

(NAME = TPC_C_DATA_1 ,

FILENAME = ‘D: \ Data \ TPC_C_DATA_1.mdf’,

SIZE = 20

GB , FILEGROWTH = 0),

(NUME = TPC_C_DATA_2,

FILENAME = ‘D: \ Data \ TPC_C_DATA_2.mdf’,

SIZE = 20GB,

FILEGROWTH = 0),

(NAME = TPC_C_DATA_3,

FILENAME = ‘D: \ Data \ TPC_C_DATA_3.mdf’,

SIZE = 20

GB , FILEGROWTH = 0),

(NAME = TPC_C_DATA_4,

FILENAME = ‘D: \ Data \ TPC_C_DATA_4.mdf’,

SIZE = 20

GB , FILEGROWTH = 0),

(NAME = TPC_C_DATA_5,

FILENAME = ‘D: \ Data \ TPC_C_DATA_5.mdf’,

SIZE = 20

GB , FILEGROWTH = 0),

(NAME = TPC_C_DATA_6,

FILENAME = ‘D: \ Data \PC .mdf ‘,

SIZE = 20

GB , FILEGROWTH = 0),

(NAME = TPC_C_DATA_7,

FILENAME =’ D: \ Data \ TPC_C_DATA_7.mdf ‘,

SIZE = 20

GB , FILEGROWTH = 0)

LOG ON

(NAME = TPCC_H_LOG,

FILENAME = ‘E: \ Log \ TPCC_LOG_1.ldf’,

SIZE = 20

GB , FILEGROWTH = 0)

GO

Alte configuratii includ:

  • Mutarea TEMPDB pe unitatea de stocare temporara folosind dimensiunile implicite si numarul de fisiere recomandat in functie de dimensiunea VM.
  • Setarea MAXDOP = 1. Am constatat ca nerespectarea acestui lucru poate provoca blocaje la un numar mai mare de utilizatori.
  • Setarea modului de recuperare din baza de date pe completa. Desi nu luam copii de rezerva ale fisierelor de jurnal de tranzactii in timpul valorii de referinta, este probabil modul in care am configura baze de date pentru clientii nostri cu sarcini de lucru OLTP.

Definirea configuratiei de baza

In scopul acestei postari pe blog, ne vom concentra pe trei configuratii comune pe care le consideram populare, in functie de debitul tranzactional pentru clientii nostri.

Instance ClassInstance NamevCoresRAM (GB) VM w / Windows $ / moTemp de stocareMax cache IOPS / MBps (dimensiune in GiB) NIC max. 256 (400) 8 / 8,000LargeE64s v364488 4953,78864128,000 / 1024 (1600) 8 / 30,000

Pentru analiza costurilor noastre, nu includem costul licentei SQL Server efectiv. Deoarece in multe cazuri, clientii nostri transfera licentele negociate existente in Azure.

Pentru configuratiile noastre de stocare si preturi incepand cu 6 noiembrie 2018 in US West 2, utilizam urmatoarele:

Configurare disc Dimensiune disc Pret pe lunaIOPS pe discMB / sec stocare totala Pret pe luna5 × 2 si 7256 GBP 34.561.1001251.75 TB 241,92 USD (7 * 34,56 USD) P301 TB 122.885.0002002 TB 245,76 USD 235,76 $ T2,55,55,55 USD

Prezentare generala a procesului nostru de automatizare a testelor

Nu incercam sa obtinem cel mai bun rezultat posibil pentru referinta OLTP. Practic, economisim reglarea sistemului atunci cand mergem sa implementam solutia bazei de date a clientilor nostri. Incercam pur si simplu sa producem un rezultat consecvent, care poate fi comparat cu baza noastra istorica pentru tipul de instanta din centrul de date Azure vizat.

Iata fluxul general pentru automatizarea procesului de referinta.

Un exemplu de ce conteaza Read-Cache pentru unitatile de discuri de date

Una dintre recomandarile de la Microsoft pentru rularea sarcinilor de lucru OLTP este de a folosi memorie in cache numai pentru citire pentru unitatile de date. Pentru a vedea cum face acest lucru diferenta, am executat configuratia noastra 5 × 2 cu si fara cache pe disc numai de citire pentru unitatile de date pentru configuratiile noastre VM mici, medii si mari.

Urmatorul grafic arata o comparatie a datelor noastre de baza pentru masina virtuala mare, una cu No-Cache si alta cu cache doar de citire reprezentata in Tranzactii pe minut, astfel cum este inregistrata de jurnalul HammerDB.

Dupa cum puteti vedea, utilizarea cache-ului numai in citire pentru unitatile de date realizeaza o performanta de peste doua ori mai buna decat utilizarea stocarii premium cu No-Cache. Pentru a pune acest lucru in perspectiva pe o perioada de o luna, convertim tranzactiile pe minut in tranzactii pe luna (B) prin inmultirea valorilor inregistrate pentru fiecare utilizator rulat cu 525.600 minute pe an impartit la 12 luni pe an impartit la 1 miliard .

Sa asociem acum o cifra in dolari pentru fiecare configuratie a utilizatorului. VM-ul mare E64 v3 pentru West US 2 ruleaza 4.953,78 USD pe luna. 7 unitati P15 asociate de 256 GB ruleaza 241,92 USD pe luna pentru un pret total de VM – fara a include licenta SQL Server – de 5.195,70 USD.

Stabilim costul pe miliard de tranzactii pe luna, luand costul VM pe luna impartit la tranzactiile pe luna (miliarde) pentru fiecare configuratie a utilizatorului. Iata cum arata rezultatele pentru VM-ul mare.

In cele din urma, trebuie sa stabilim un numar complet pentru rezultatul care poate fi folosit pentru un rezultat fara rezultat. Pentru a face acest lucru, luam suma costurilor pe un miliard de tranzactii pe luna pentru fiecare dintre utilizatorii virtuali ruleaza pentru 3, 5, 8, 13, 21, 34, 55, 89, 144, 233 si apoi impartim la 10 Aceasta abordare modeleaza un numar variabil de utilizatori de-a lungul lunii care efectueaza tranzactii cu explozie reprezentata de numarul mai mare de utilizatori. Urmatorul grafic arata valorile noastre de baza pentru tipurile VM mari, medii si mici folosind modelul descris.

Dupa cum puteti vedea, costul utilizarii memoriei cache pe disc numai pentru citirea discurilor este semnificativ mai mic decat utilizarea implicita a No-Cache. Atunci cand facem analiza no-go sau no-go, aceasta este prima verificare pe care o facem usor de corectat – presupunand ca valoarea pentru VM si stocare se incadreaza in criteriile noastre de baza. Putem apoi rula din nou parametrul de referinta cu unitatile reconfigurate.

Configuratiile de disc conteaza, dar la fel si dimensiunea VM

In testarea noastra am constatat ca alegerea combinatiei de discuri potrivite poate face o diferenta semnificativa in alegerea dvs. pentru VM-uri. Sa aruncam o privire la modul in care utilizarea configuratiilor de disc 5 × 2 (P15), 7 (P15), 2 (P30) si 1 (P40) poate face diferenta in costul dvs. pentru un miliard de tranzactii. In graficele urmatoare, vom arata rezultatele de baza TPM (K) pentru compararea diferitelor configuratii ale discului cu tipurile VM mari, medii si mici.

Cand mergem mai departe si calculam costul lunar pentru un miliard de tranzactii, puteti vedea cum se aliniaza diferitele configuratii ale discului cu dimensiunile VM diferite.

Dupa cum puteti vedea, cu VM-ul mare, unicul disc P40 a functionat cel mai bine atunci cand a fost calculat in medie in configuratiile utilizatorului, chiar daca 2 unitati P30 au valori TPM mai mari la capatul inalt. Cu VM Medium, configuratia unitatii 2 P30 a avut cea mai buna valoare in general, deoarece a functionat constant in diferite configuratii ale utilizatorului. Configuratia VM mica a aratat un usor avantaj in utilizarea configuratiei discului 5 × 2 P15.

Utilizarea liniei de baza pentru a determina VM si adecvarea stocarii

Avand valori de baza pentru diferite tipuri de VM si configuratii de disc, putem stabili o modalitate de a determina pe baza costului pe luna pentru un miliard de tranzactii daca infrastructura Azure este potrivita pentru clientii nostri. Folosind o cifra in dolari, este relativ usor sa intelegeti impactul pe care il are infrastructura slaba.

Aplicatii mai ample ale acestei tehnici

Exista si alte scenarii in care putem folosi HammerDB pentru a crea rezultate de baza pentru scenarii precum:

  • Compararea rezultatelor cu o implementare a grupului Always On Availability
  • Testarea rezultatelor SQL Server care ruleaza in containerele Docker pe Windows sau Linux
  • Compararea rezultatelor cu baza de date SQL simpla si replicata Azure SQL si instantele bazate pe baza de date SQL Azure pentru PaaS versus analiza costurilor IaaS
  • Testarea sarcinilor de lucru DW in raport cu linia de baza pentru SQL Server 2017 pe IaaS, Azure SQL Data Warehouse si Azure SQL Database Hyperscale cu Clustered Columnstore

Cadrul nostru de evaluare comparativa este proiectat sa functioneze impotriva tuturor acestor scenarii.

Beneficiile cheie ale acestei abordari

Pe scurt, clientii nostri beneficiaza in urmatoarele moduri:

  • Configuratiile de masina virtuala si de stocare indeplinesc sau depasesc configuratia de baza pentru debitul dorit in tranzactii pe minut si valoare.
  • Pentru clientii care se aboneaza la serviciul nostru gestionat, folosim platforma DBMSys pentru a monitoriza continuu VM si pentru a efectua verificari de sanatate pentru a valida daca VM ruleaza in API-urile clientului nostru.
  • Prin combinatia dintre analiza DMO si referinta noastra de referinta, putem oferi clientilor nostri o mai buna intelegere a costului pe tranzactii pe luna inainte, pentru a arata valoarea imediata a executarii SQL Server pe Azure.

Daca sunteti interesat de cum puteti beneficia de validarea noastra de evaluare comparativa, va rugam sa ne contactati astazi!

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR