1Budapesti Műszaki és Gazdaságtudományi EgyetemMéréstechnika és Információs Rendszerek Tanszék

Benchmarkok és szolgáltatásbiztonság

Autonóm és hibatűrő informatikai rendszerek

2

Benchmarking„In computing, a benchmark is the act of running a

computer program, a set of programs, or other operations, in order to assess the relative

performance of an object, normally by running a number of standard tests and trials against it. The

term 'benchmark' is also mostly utilized for the purposes of elaborately-designed benchmarking

programs themselves.”

(wikipedia)

3

Benchmarking [...]

Another type of test program, namely test suites or validation suites, are intended to assess the correctness of software.

Benchmarks provide a method of comparing the performance of various subsystems across different chip/system architectures.

4

Benchmarking Cél: SW/HW teljesítmény-összehasonlítása

o Kapacitástervezési döntéstámogatás o Kvalitatív teljesítménytesztelés • != valódi teljesítménytesztelés

Összehasonlítás!o „Akármilyen” metrikát használhatunko Viszont nem „abszolút” teljesítmény• metrika-definíció• Mérési környezet, terhelés

5

Benchmarking N.B. benchmarkolni szokás még...

o Üzleti folyamatokato Hitelkihelyezési eljárásrendeketo Szervezeti hatékonyságoto ...

A koncepció nem informatika-specifikus

6

Benchmark terminológia Macrobenchmark

o nagy összetett alkalmazás/szolgáltatáso relevancia biztosításával közvetlenül használható

eredményeket ad

Microbenchmarko alkalmazás kis része/adott kódrészlet

Nanobenchmarko atomi műveletek teljesítménymérése

7

Benchmarkok Szabványosság, auditálás, verifikálás

o Transaction Processing Performance Council (TPC)o Standard Performance Evaluation Corporation (SPEC)o Business Applications Performance Corporation

(BAPCo)o ...

Nem ipari szervezethez kötötto VMMark, openbenchmarking.org, Dhrystone,

Whetstone, ...

8

TPC Benchmarkok TPC-C

o kereskedelmi jellegű adatbázis-tranzakciók + felhasználó-populációo Tranzakció-ráta: tpmC, $/tpmC

TPC-Eo OLTP, „brokerage firm”o tps

TPC-Ho Döntéstámogatási rendszereko „TPC-H Composite Query-per-Hour Performance Metric

(QphH@Size)” TPC-Energy

o Additív opcionális benchmark Obsolete: TPC-A, TPC-B, TPC-D, TPC-R, TPC-W, TPC-App

9

SPECBenchmark: szolgáltatás

„forráskódot adnak, nekünk kell fordítani”Licenszdíj!

10

SPEC

11

Tudományos/műszaki rendszereko number crunching, párhuzamosság

Tranzakciókezelés (OLTP)o kliens-szerver környezet, párhuzamos tranzakciók

Batch jellegű adatfeldolgozáso riport készítés nagy mennyiségű adatból

Döntéstámogatáso kevés, bonyolult lekérdezés; ad hoc műveletek; „big data”

Virtualizációo Kompozit teljesítmény (VM mix); deployment dinamika; interferencia-

védelem Cloud?

o Adatelérés, fel- és leskálázás, durva párhuzamosítás, költséghatékonyság

Benchmark terhelési modellek és szempontok

12

Database single-VM measurements10 users

20 users 50 users

13

Example: database + dbench

Difference with „disturbance”Baseline (10 users)

This is the effect in the QoS.Relationship with platform metrics?

14

Hogyan specifikáljuk?o Megkötések a mért objektum környezetén (HW/SW)o „Szolgáltatás” definíciójao Munkaterhelés definíciójao Üzemviszonyoko Metrikák mérése/számításao Dokumentáció

Alapelveko kölcsönös zavarás minimalizálása (üzem közben)o terhelés közelítse a valós mintát (profilok)

Bechmark környezet

15

Tipikus problémák Túl kicsi problémaméret A felhasználási terület számára releváns

eredmény? „Rejtett” paraméterek

o konfigurációs beállításoko adott környezet specifikus tulajdonságai

Elfogultság Hiányos specifikáció

16

Benchmark elvégzése Relevancia biztosítása

o Tényleg azt az alkalmazást mérjük, amit kell• Különböző macrobenchmarkok eredményei többnyire nem

vihetőek át egymás között.o Terhelésgenerálás jellege közelítse a valódi terhelést

• Főleg macrobenchmarkoknál fontos, időben szétosztott valódi terhelést félrevezető lehet egy összefüggő batch terheléssel helyettesíteni.

• Ügyeljünk a terhelésgenerátorra ható visszacsatolásokrao Minimalizáljuk a zavaró tényezőket

• Főleg microbenchmarknál fontos, Pl.: ne mérjünk bele véletlenül diszk I/O-t a memória áteresztőképességébe, ne fusson más alkalmazás közben

• Futási eredmények szórását kezelni kell

17

SPECweb2009

18

SPECjvm2008 Ingyenes! JRE teljesítmény

o CPU / memóriao Kevés állomány I/O, nincs hálózati I/O

Alkalmazásoko Javac, LZW, Startup, MPEGaudio, Xml (transzformáció

és validáció), Crypto

19

SPECvirt_sc2010 2009Q4: a szerverek 18%-a virtualizált

Skálázhatóság / energiahatékonyságo „Hány VM konszolidálható egy hosztra?”

1 „tile”: 6 VM Munkaterhelés

o Tile-ok számának növelése telítődésig / QoS határig Metrika

o komponensek normalizált áteresztőképesség-metrikái

20

SPECvirt_sc2010

21

SPECvirt_sc2010

22

Demo TPC-C publikus eredmények

23

Dependability benchmarking A szolgáltatásbiztonság is benchmarkolható Jellemző megközelítés:

o Teljesítmény-benchmark +o „Hibaterhelés” (fault load) +o szolgáltatásbiztonság metrikái• Ismétlés: mik ezek? (Lehet implicit!)

24

Mérési kampány struktúrája

25

Metrikák DBench-OLTP

o TPC-C alapú

„baseline performance”: tpmC, $/tpmC Hibaterhelések alatti (átlagos) teljesítmény

o Tf, $/Tfo Értelmezési tartomány: Phase 2

Szolgáltatásbiztonsági metrikáko Ne: integritásellenőrzésnél feltárt adathibáko AvtS: SUT oldali rendelkezésreállás (válaszidő-korlát!)o AvtC: kliensoldali rendelkezésreállás (válaszidő-korlát!)

26

Hibaterhelés

27

Hibaterhelés Itt: operátori hibákkal közelítés

Okok:o SW/HW hibák elfogadható emulálásao Adatbázis-kiszolgálók közötti hordozhatóság!

• A TPC-C munkaterhelésnél ez nem probléma

„Miért nehéz a Software Implemented Fault Injection (SWIFI)” – másik tárgy

Figyelem: a funkcionalitás mellett a detektálás + helyreállítás is a SUT részeo Horribile dictu implicit módon még folyamatokat is mérünk

28

Néhány eredmény

G. Pintér, H. Madeira, M. Vieira, I. Majzik, A. Pataricza:A Data Mining Approach to Identify Key Factors in

Dependability Experiments, Dependable Computing - EDCC 5, LNCS

29

The Autonomic Computing Benchmark Nagyvállalati környezet „rugalmasságának”

vizsgálata (resilience)o Self * mérése (önmenedzselés)o Hibainjektálássalo A rendszer robosztusságát és automatizáltságát

vizsgálja

Cél: kevés metrikao Rendszer evolúciójának vizsgálatao Különböző rendszerek összehasonlítása

30

Architektúra Elvben bármi lehet Példa: SPECjAppServer2004 architektúra /

benchmarkoWebszervero Alkalmazásszervero Adatbáziso Üzenetküldő szerver

31

Metrikák Áteresztőképesség index

o Zavarok hatása az áteresztőképességre

Érettségi index (maturity index): mennyire automatizált ao hibadetektálás,o hibaanalízis,o helyreállás

32

Mechanizmus 3 fázis:

Tesztfázis: Egymás utáni slot-okban hibainjektálás

33

Mechanizmus – 1 slot Állandósult állapotba kerül a rendszer Hibainjektálás Hibadetektálás

o Automatikuso Bizonyos idő elteltével (emberi interakció szimulálása)

Helyreállítás Újraindítás Rendszer futtatása

o Degradálódott-e a szolgáltatás?

34

Hibafajták Hibák (példa):

o Váratlan leállás (hw, os, sw)o Erőforrás versenyhelyzet (CPU, mem)o Adatvesztés (file, DBMS)o Terhelésváltozás („karácsonyi roham”)o Sikertelen újraindítás detektálása

35

Metrikák (folyt) Áteresztőképesség index: P_i / P_base

o Figyelem! Nem rendelkezésre állás. Fejlettség index

o Kifejezi mennyire automatizált a rendszeroMennyi emberi beavatkozás kello A SUT egy lista alapján pontokat kapo Nemlineáris skálao Átlagolunk, normalizáljuko Index 0—1 között• 0 nincs automatizmus• 1 nem kell emberi közbeavatkozás

36

Nehézségek Zavar megtervezése

o Zavarok katalógusának összegyűjtéseo Szimuláció?

Eredmények összehasonlításao Terheléso Skálázódás• a metrika nem skálázódik feltétlenül együtt a

rendszermérettelo Ár• Robosztus és automatizált rendszer nagyon költséges

Benchmark során: emberi interakció becslés!

37

Érettségi szintek